Дьявол в мелочах: составляем техническую документацию на разработку ERP-системы

Руководитель практики ALP Group по управлению финансами Юлия Орлова рассказывает, как правильно составить и что учесть в документации, чтобы избежать ненужных проблем.

Источник: <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Funsplash.com%2F%40lunarts&postId=643710" rel="nofollow noreferrer noopener" target="_blank">Volodymyr Hryshchenko</a>, Unsplash
Источник: Volodymyr Hryshchenko, Unsplash

Недавно мой коллега Алексей Орлов рассказывал, как и зачем проводить обследование бизнеса перед началом внедрения ERP-системы. Если вы успешно завершили этот этап, пора переходить к следующему — этапу технического проектирования.

Исходим из того, что вы уже:

  • заключили Договор на внедрение;
  • сформировали Отчет о проведенном обследовании;
  • определили и уточнили требования к будущей системе;
  • концептуально утвердили архитектуру решения и подходы к автоматизации.

Теперь наша задача — составить технический документ с детальным описанием устройства будущей ERP-системы. Примерно так будет выглядеть чек-лист действий компании-интегратора:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1414
2 комментария

как правильно составить и что учесть в документации, чтобы избежать ненужных проблем

Никак. Смиритесь с этим.

Добрый день.
Конечно, проектов без сложностей не бывает, правильно подготовленная документация поможет минимизировать риски.