Технология внедрения ERP-систем (продолжение)*

Первая часть статьи>>>

• Принцип «Семь раз отмерь – один раз отрежь» в ИТ не имеет уже той силы, как при строительстве. Резать и перекраивать гораздо проще, даже на живой, работающей системе. Программы — чрезвычайно податливый материал. Особенно на 1С :) . Достаточно подгрузить обновленную программу. Или изменить регламент работы сотрудников. А вот попробуйте к дому, в котором уже живут, «подгрузить» подвал!
• Выше было указано, что практика – критерий истины. В данном случае это значит, что только практическое использование инструмента (программы) дает окончательное понимание что и как должно работать. Теоретические изыскания – это всего лишь измышления и суждения, гипотезы. Но как известно, гипотезы не имеют силы, пока они не подтверждены экспериментом!

Итак,  новые технологии создания ERP-системы основываются на научном подходе – создании системы в результате цепочки экспериментов, иначе говоря практического опыта.

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

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

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

Новая технология предлагает простую формулу – «Начните работать в программе — и сразу станет ясно, чего не хватает».

Начало: Функциональное моделирование — поиск решения

Исследование вопроса «Как использовать типовое решение на данном предприятии , какие нужны доработки» — это следующий этап работ «Функциональное моделирование».

Разумеется, если типовое решение устраивает (а это становится ясно после тестовой эксплуатации) — этап функционального моделирования пропускается.

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

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

Решение вырабатывается как компромисс между желаемыми изменениями бизнес-процессов (такие желания у заказчика обычно всегда есть, да и консультант может предлагать референтные модели) и рамками возможностей типового решения:

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

Какова роль эксперимента, практики в этом процессе?

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

Итак, результатом данного этапа «Функциональное моделирование» является Функциональная модель «To Be»: («Как будет»).

Модель может быть записана в виде схемы в нотации eEPC ARIS. Фрагмент такой схемы:

Итого на этапе «Функциональное моделирование» рождается:

• Схема и описание бизнес-процесса «To Be», привязанная к возможностям типового решения, находящаяся в его рамках, объектах и понятиях, но тем не менее достигающая целей этих процессов.
• Подробное описание бизнес-процесса – как он будет выполняться пользователями в типовом решении, со скриншотами входных и выходных форм.
• Мини-моделирование в типовом решении на ограниченной выборке данных заказчика, в тех режимах, которые наиболее близки к требованиям модели.
• Зафиксированные требования – где именно требования к системе вышли за рамки типового решения. Обозначаются будущие доработки типового решения, которые  потребуется детализировать в Техническом задании.
• Понимание заказчиком методик типового решения. Понимание, как система будет работать.

Отметим, что как правило, полное понимание не приходит при чтении документов — ТЗ, моделей и так далее. Понимание приходит только в процессе практической совместной работы над моделью в системе, что и имело место – совместном построении модели с консультантами.

Контрольный вопрос :)

Если пропустить этап функционального моделирования, а сразу поручить консультантам написать техническое задание на доработки, то какие гарантии получает заказчик, что недоработанная часть типового решения решит все его задачи? 

Подытожим.

Этапы тестовой эксплуатации и функционального моделирования на 90% определяют результаты проекта на последующих этапах, поэтому именно в них заложен краеугольный камень нашей технологии

Читать полное описание технологии ИТРП>>>