Как составить техническую документацию по проекту разработки ERP-системы
Юлия Орлова рассказывает, какие особенности следует учесть в документации, чтобы избежать впоследствии ненужных проблем.
Юлия Орлова рассказывает, какие особенности следует учесть в документации, чтобы избежать впоследствии ненужных проблем.
Договор на внедрение заключен, предпроектное обследование успешно завершено, концептуальные подходы и требования к ERP-системе сформулированы. Но это только начало. Следующий этап — техническое проектирование, то есть составление технического документа с детальным описанием устройства будущей системы. Не все компании-интеграторы подходят к этому этапу в равной степени серьезно. Нужно понимать, что техническая документация — не синоним простого техзадания со списком требований. В этой статье я поделюсь своими наблюдениями о том, как должен быть выстроен грамотный процесс технического проектирования.
Примерно так будет выглядеть чек-лист действий компании-интегратора:
1. Утвердить с заказчиком шаблоны документации.
Как правило, на крупных проектах уже есть утвержденные шаблоны Технического задания и Технического проекта. Стоит заранее уточнить, готов ли заказчик предоставить свои шаблоны. Если нет, то письменно это зафиксировать и согласовать новый кастомный шаблон документации по проекту.
2. Определить перечень согласующих и сроки согласования.
Чтобы выйти на плановую дату завершения этапа проектирования, важно заранее рассчитать сроки сдачи готовой технической документации, а также проработать с согласующими лицами порядок согласования и требования к формату документов. Например, с владельцем системы техническую документацию можно утверждать в формате презентации, где будут укрупненно подсвечены разделы, в которых учитываются те или иные требования.
Важный момент: в перечень согласующих обязательно должны входить представители отдела по информационной безопасности. С учетом все возрастающего числа кибератак, в 2023 году без специалистов по безопасности уже не обойтись. Если не учесть их требования в самом начале, в дальнейшем есть риск серьезной переработки уже реализованного функционала.
3. Подготовить техническую документацию.
Другими словами, наполнить разделы, предусмотренные утвержденным шаблоном. Что обязательно должно быть в документе:
● общие концептуальные схемы решения (архитектура решения, интеграционные потоки, описание бизнес-процессов и прочее); лучше всего поместить их в самом начале документа — это даст возможность получить представление о решении, не углубляясь в чтение труда на несколько сотен страниц;
● упоминание использования типового функционала; в случае кастомизации «коробочного» продукта, а не разработки решения с нуля, должно быть указано исходное решение, а также описана работа типового функционала, который планируется задействовать в системе;
● перечень используемой нормативно-справочной информации (НСИ), точка ввода и порядок наполнения справочников историческими данными;
● решения по загрузке исторических данных помимо НСИ;
● требования к информационной безопасности, включая ролевую модель и доступ пользователей;
● интеграционные потоки;
● допущения и ограничения (лучше еще раз максимально все зафиксировать, чтобы избежать проблем на этапе опытно-промышленной эксплуатации и остаться в рамках сроков и бюджета проекта).
4. Перепроверить документацию.
Перед финальным согласованием текста интегратору стоит последний раз убедиться, что в нем предусмотрено все, что можно. Важно, чтобы текст вдумчиво прочитали руководитель проекта и системный архитектор. Нужно будет убедиться, что техническое задание соответствует требованиям Отчета об обследовании. В идеальном варианте должен получиться четкий мэппинг — какие требования каким пунктом документации реализуются.
Звучит довольно банально, но все-таки интегратору стоит проверить не только содержание, но и форматирование текста. Документ без четкой нумерации разделов и таблиц, нечитаемые шрифты, отсутствие расшифровки по сокращениям, плохое выравнивание текста и орфографические ошибки — все это не мелочи, а тревожные сигналы невнимательности интегратора, которая может сказаться и на самом проекте внедрения.
5. Согласовать готовую техническую документацию.
Этот шаг должен выполняться в соответствии с принятыми регламентами, договоренностями или Уставом. Отдельно рекомендую вести Лист изменений документации, в котором будут собраны все поступившие вопросы и решения по ним. Текст должен быть официально завизирован с помощью обычной или электронной подписи всеми участниками процесса согласования.
Кажется, что все вышеупомянутые пункты предельно очевидны. Достаточно следовать нехитрому плану — и можно будет забыть о многих проблемах и недопониманиях в будущем. Правда, здесь есть одно «но». Обратите внимание, что с учетом критичности и сроков внедрения ERP-систем на практике разработка достаточно часто начинается до того, как будет подписан финальный вариант технической документации. Поэтому все открытые вопросы важно фиксировать письменно с указанием конкретных сроков их решения.
Автор: Юлия Орлова, руководитель практики ALP Group по управлению финансами. С 2010 года работает в ALP Group, с 2018 года является руководителем практики по управленческому и финансовому учету (FRP).
Источник: РБК Компании.