Продолжаю рассказывать об этапе Моделирования, первая часть по ссылке.

Следующий шаг - предоставить возможность команде Заказчика самостоятельно проработать в прототипе системы. Это необходимо для того, что бы пользователи могли в спокойной обстановке, своими руками поработать в системе. При необходимости Исполнитель на этом этапе оказывает поддержку Заказчику, консультирует, отвечает на вопросы. По итогам этой активности так же может возникнуть новые функциональные требования, функциональные разрывы и открытые вопросы. На эту активность как правило планируется 1-2 недели. Здесь стоит отметить, что долго проверять не получиться. т.к. в системе на тот момент занесен минимальный набор исходных данных и НСИ, т.е. Заказчик полноценно может проиграть самостоятельно только лишь те сценарии, которые были согласованны.

Пока Заказчик "играется" с прототипом Исполнитель не сидит сложа руки, а рисует и описывает схемы бизнес процессов To Be (как будет), начинает формировать отчет о Моделировании - основной документ являющийся формальным результатом этапа. Систематизирует выявленные функциональные разрывы, формируется Реестр функциональных разрывов, уточняет формулировки и описание ФР и самое важное выполняется их ранжирование и оценку стоимости их реализации.

При ранжировании обычно используется три ранга Высокий приоритет - без устранения этих ФР целевое состояние системы недостижимо. Это своего рода обязательная программа. Средний приоритет - без реализации этих ФР система будет работать, однако может иметь некие неудобства для пользователей. Низкий приоритет - интерфейсные "бантики", удобство пользователя и сюда же попадают ФР, по которым пока неочевидна необходимость их реализации, либо Заказчик еще не дозрел до такой функциональности.

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

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

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

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

Продолжение следует....

#проектное #1с