Введение в управление проектами внедрения ERP-систем

5.3.3.Дизайн архитектуры системы

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

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

По ходу настройки прототипа уточняются места «разрывов» функциональности, которую предстоит доработать на фазе разработки.

Конечно, современные ERP-системы стремятся к покрытию всех потребностей бизнеса на уровне штатной функциональности. И в случае внедрения 1C:ERP очень многое можно настроить без дополнительного программирования, но бизнес и оперативный, и особенно управленческий, учеты не унифицированы под единые стандарты и ПБУ, потому готовые решения могут не подойти. Возможно, что какая-то особенность бизнес-процессов компании является ее конкурентным преимуществом на рынке, и тогда, конечно, нет смысла отказываться от такого процесса, а нужно поддержать его автоматизацией.

Все эти проектные решения описываются в сводном документе «Технический проект» (может называться иначе – например, «Дизайн решения»). Это еще не детальное техническое задание (ТЗ), это высокоуровневый свод, но уже и не концепция, а конкретные задачи, которые дальше могут уточняться в ТЗ на следующей фазе.

PMBOK вводит понятие иерархической структуры работ (ИСР) – детальной декомпозиции всех необходимых настроек, доработок и прочих работ. Иерархическая структура работ проекта – это дерево подзадач различного уровня, необходимых и достаточных для достижения целей проекта. Вот после фазы дизайна архитектуры системы в техническом проекте и плане-графике работ должна быть полная картина работ по ИСР. Дальше остается на последующих фазах их выполнить и по мере отметки выполнения задач мониторить ход проекта; когда все задачи будут выполнены, то и проект на этом заканчивается.

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

Документооборот и результаты фазы:

Результат (документ) Рабочий/отчетный Ответственный за создание
Актуализированная спецификация требований Рабочий РП заказчика и РП исполнителя
Настроенный прототип 1C:ERP Система РП исполнителя
Протоколы совещаний Рабочий РП исполнителя
Технический проект (дизайн решения) Отчетный РП исполнителя
Презентации архитектуры решения Рабочий РП исполнителя, консультант, системный архитектор
Устав проекта (обновление по необходимости) Отчетный РП исполнителя
Уточнение сроков и бюджета остальных фаз проекта Рабочий РП исполнителя
План-график проекта (уточненный по необходимости) Отчетный РП исполнителя
Доп. соглашения к договору (по необходимости) Отчетный РП исполнителя
Отчет о выполненных работах (месячный или по фазе целиком) Отчетный РП исполнителя
Акт выполненных работ (месячный или по фазе целиком) Отчетный РП исполнителя
Показать оглавление

Комментариев: 0

Оставить комментарий