Как выполнить моделирование системы 1С при внедрении?

Что такое моделирование и зачем его делать?

Особенностью проектов по внедрению программ на базе платформы 1С является то, что в большинстве случаев, программа не создается «с нуля».

Как правило, за основу берется некоторое типовое решение от производителя (фирмы 1С) и в него уже вносятся корректировки и доработки.

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

Такой подход позволяет существенно упростить внедрение системы, уменьшить бюджет проекта и сократить сроки внедрения.

Для уточнения порядка работы пользователей с целевой АС проводится этап моделирования.

Моделирование выполняется целенаправленно,  то есть,  моделируются только определенные границами проекта бизнес-процессы, а остальные особенности работы целевой АС не рассматриваются.

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

Участники моделирования

Со стороны Заказчика в моделировании принимают участие и согласовывают его результаты ключевые пользователи.

Состав ключевых пользователей устанавливается отдельным протоколом по каждой моделируемой подсистеме.

Обычно, в качестве ключевых пользователей выступают функциональные заказчики системы (см. план управления проектом) и некоторые из их заместителей.

Со стороны Подрядчика в моделировании принимают участие Аналитики.

Как правило, моделированием одной подсистемы занимается один Аналитик.

Подготовка к моделированию

На основании входных данных Аналитик проводит подготовку к моделированию:

• Разворачивает базу модельного примера при ее отсутствии
• Режиссирует модельный пример по каждому бизнес-процессу и отражает выработанный сценарий в виде программы моделирования
• Готовит черновик функциональных разрывов

Ознакомление

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

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

Результаты встреч фиксируются в виде протоколов моделирования.

Аналитик направляет ссылки на протоколы моделирования участникам встречи на согласование.

Участники встречи в виде комментариев к протоколам указывают свои замечания и дополнения.

Дополнительные (ранее не предоставляемые) запрошенные материалы прикладываются участниками встречи к странице с протоколом встречи в комментариях.

Модельный пример

Задача второй фазы моделирования (модельный пример) — внести все необходимые уточнения в модельный пример и получить полную и достоверную картину моделирования целевой АС.

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

Аналитик на основании полученных данных уточняет модельный пример и проводит встречу для его окончательного согласования с ключевыми пользователями Заказчика.

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

Структура документа «Программа моделирования»

1. Список сокращений, терминов и определений
   1. Сокращения, принятые в документе
   2. Термины, используемые в документе
2. Информация от Заказчика
   1. Контактные данные владельца процесса
   2. Перечень моделируемых бизнес-процессов
3. Программа моделирования (по каждому бизнес-процессу)
   1. Данные по контрольному примеру
   2. Документы, регламентирующие контрольный пример:
4. Сценарий моделирования

Функциональные требования

После уточнения модельного примера Аналитик вносит изменения и дополнения в программу моделирования, модельный пример, формирует в законченном виде и систематизирует функциональные требования к целевой АС.

На встрече (финальной) Аналитиком и ключевыми пользователями АС совместно прочитывается весь перечень функциональных требований, уточняются их описания, добавляются не учтенные ранее функциональные требования, все функциональные требования систематизируются и приводятся к финальному виду.

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

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

Структура документа «Функциональные требования»

1. Список сокращений, терминов и определений
   1. Сокращения, принятые в документе
   2. Термины, используемые в документе
2. Реестр функциональных разрывов.

В разделе «Реестр функциональных разрывов» приводится таблица следующего содержания:

Приемка

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

Каждому функциональному требованию присваивается приоритет  и признак включения в реализацию проекта.

Результаты моделирования утверждаются Управляющим Комитетом.

Оценка трудозатрат на этап моделирования

Методика оценки следующая:

Формируется реестр процессов требующих моделирования.

Для этого берутся функциональные области заявленные к автоматизации, например:

• Бюджетирование
• Управление закупками
• Казначейство
• Управление продажами

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

Перечень процессов берется из целевой системы 1С для того, чтобы уже на ранней стадии синхронизировать с будущими пользователями системы термины и определения.

Если перечь процессов неизвестен, то нужно исходить из предположения, что используется не менее 75% (три четверти) процессов из целевой подсистемы.

Если например,  в подсистеме управления продажами всего 18 процессов, то предполагается, что моделироваться будет 14 процессов.

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

Далее по каждому процессу проставляются поправочные коэффициенты.

В случае необходимости формирования ТЗ (технического задания) расчет трудозатрат на формирование ТЗ строится по принципу 30% от объема трудозатрат на этап моделирования.