Как составить техническую документацию по проекту разработки ERP-системы

Договор на внедрение заключен, предпроектное обследование успешно завершено, концептуальные подходы и требования к ERP-системе сформулированы. Но это только начало. Следующий этап — техническое проектирование, то есть составление технического документа с детальным описанием устройства будущей системы. Не все компании-интеграторы подходят к этому этапу в равной степени серьезно. Нужно понимать, что техническая документация — не синоним простого техзадания со списком требований. В этой статье я поделюсь своими наблюдениями о том, как должен быть выстроен грамотный процесс технического проектирования.

Примерно так будет выглядеть чек-лист действий компании-интегратора:

1. Утвердить с заказчиком шаблоны документации.

Как правило, на крупных проектах уже есть утвержденные шаблоны Технического задания и Технического проекта. Стоит заранее уточнить, готов ли заказчик предоставить свои шаблоны. Если нет, то письменно это зафиксировать и согласовать новый кастомный шаблон документации по проекту.

2. Определить перечень согласующих и сроки согласования.

Чтобы выйти на плановую дату завершения этапа проектирования, важно заранее рассчитать сроки сдачи готовой технической документации, а также проработать с согласующими лицами порядок согласования и требования к формату документов. Например, с владельцем системы техническую документацию можно утверждать в формате презентации, где будут укрупненно подсвечены разделы, в которых учитываются те или иные требования.

Важный момент: в перечень согласующих обязательно должны входить представители отдела по информационной безопасности. С учетом все возрастающего числа кибератак, в 2023 году без специалистов по безопасности уже не обойтись. Если не учесть их требования в самом начале, в дальнейшем есть риск серьезной переработки уже реализованного функционала.

3. Подготовить техническую документацию.

Другими словами, наполнить разделы, предусмотренные утвержденным шаблоном. Что обязательно должно быть в документе:

• общие концептуальные схемы решения (архитектура решения, интеграционные потоки, описание бизнес-процессов и прочее); лучше всего поместить их в самом начале документа — это даст возможность получить представление о решении, не углубляясь в чтение труда на несколько сотен страниц;
• упоминание использования типового функционала; в случае кастомизации «коробочного» продукта, а не разработки решения с нуля, должно быть указано исходное решение, а также описана работа типового функционала, который планируется задействовать в системе;
• перечень используемой нормативно-справочной информации (НСИ), точка ввода и порядок наполнения справочников историческими данными;
• решения по загрузке исторических данных помимо НСИ;
• требования к информационной безопасности, включая ролевую модель и доступ пользователей;
• интеграционные потоки;
• допущения и ограничения (лучше еще раз максимально все зафиксировать, чтобы избежать проблем на этапе опытно-промышленной эксплуатации и остаться в рамках сроков и бюджета проекта).

4. Перепроверить документацию.

Перед финальным согласованием текста интегратору стоит последний раз убедиться, что в нем предусмотрено все, что можно. Важно, чтобы текст вдумчиво прочитали руководитель проекта и системный архитектор. Нужно будет убедиться, что техническое задание соответствует требованиям Отчета об обследовании. В идеальном варианте должен получиться четкий мэппинг — какие требования каким пунктом документации реализуются.

Звучит довольно банально, но все-таки интегратору стоит проверить не только содержание, но и форматирование текста. Документ без четкой нумерации разделов и таблиц, нечитаемые шрифты, отсутствие расшифровки по сокращениям, плохое выравнивание текста и орфографические ошибки — все это не мелочи, а тревожные сигналы невнимательности интегратора, которая может сказаться и на самом проекте внедрения.

5. Согласовать готовую техническую документацию.

Этот шаг должен выполняться в соответствии с принятыми регламентами, договоренностями или Уставом. Отдельно рекомендую вести Лист изменений документации, в котором будут собраны все поступившие вопросы и решения по ним. Текст должен быть официально завизирован с помощью обычной или электронной подписи всеми участниками процесса согласования.

Кажется, что все вышеупомянутые пункты предельно очевидны. Достаточно следовать нехитрому плану — и можно будет забыть о многих проблемах и недопониманиях в будущем. Правда, здесь есть одно «но». Обратите внимание, что с учетом критичности и сроков внедрения ERP-систем на практике разработка достаточно часто начинается до того, как будет подписан финальный вариант технической документации. Поэтому все открытые вопросы важно фиксировать письменно с указанием конкретных сроков их решения.