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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подытожим.

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

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