Технология внедрения ERP-систем (продолжение)*
- Принцип «Семь раз отмерь – один раз отрежь» в ИТ не имеет уже той силы, как при строительстве. Резать и перекраивать гораздо проще, даже на живой, работающей системе. Программы – чрезвычайно податливый материал. Особенно на 1С :) . Достаточно подгрузить обновленную программу. Или изменить регламент работы сотрудников. А вот попробуйте к дому, в котором уже живут, «подгрузить» подвал!
- Выше было указано, что практика – критерий истины. В данном случае это значит, что только практическое использование инструмента (программы) дает окончательное понимание что и как должно работать. Теоретические изыскания – это всего лишь измышления и суждения, гипотезы. Но как известно, гипотезы не имеют силы, пока они не подтверждены экспериментом!
Итак, новые технологии создания ERP-системы основываются на научном подходе – создании системы в результате цепочки экспериментов, иначе говоря практического опыта.
Эксперимент, как способ исследования, ставится в самом начале проекта. После обучения сотрудников проводится деловая игра в новой системе на типовом функционале, в ходе которой сразу становятся понятны проблемы из-за которой система не может “взлететь” и где “наступаем на грабли”.
В процессе деловой игры сотрудники заказчика получают необходимые понятия о системе, а при попытке выполнить свой бизнес-процесс моментально наталкиваются на ограничения системы, которые фиксируются консультантами.
Можно утверждать, что данные, полученные в ходе эксперимента поставляет гораздо более качественную информацию об ограничениях функциональности и “граблях” типового (шаблонного) решения, чем умозрительные изыскания, опросы и анкетирование пользователей, совещания и обсуждения.
Новая технология предлагает простую формулу – «Начните работать в программе – и сразу станет ясно, чего не хватает».
Начало: Функциональное моделирование – поиск решения
Исследование вопроса “Как использовать типовое решение на данном предприятии , какие нужны доработки” – это следующий этап работ «Функциональное моделирование».
Разумеется, если типовое решение устраивает (а это становится ясно после тестовой эксплуатации) – этап функционального моделирования пропускается.
Совместная работа заказчика и исполнителя на этом этапе – обязательна, поскольку сотрудники заказчика лучше консультанта знают предприятие, а консультант лучше знает типовое решение. Совмещение этих знаний в одной команде дает синергетический эффект.
Подчеркнем, поиск решения – обязательно совместный, заказчик подталкивает консультантов к правильному решению благодаря знанию своих бизнес-процессов, а консультанты подталкивают заказчика к оптимальному решению своими знаниями особенностей работы типового решения и знанием референтных моделей.
Решение вырабатывается как компромисс между желаемыми изменениями бизнес-процессов (такие желания у заказчика обычно всегда есть, да и консультант может предлагать референтные модели) и рамками возможностей типового решения:
- Какими-то пожеланиями к бизнес-процессам можно пожертвовать: «овчинка выделки не стоит», слишком дорого обойдется доработка ТР и так далее.
- Какие-то пожелания к бизнес-процессам напрямую, согласно предпочтениям заказчика и его стереотипам, в типовом решении без доработок не реализуются, но реализуются другим более оптимальным способом без доработок, в результате чего конечная цель все равно достигается.
- Какие-то пожелания оказываются принципиальными и если способа их реализации в ТР не найдено ни каким способом, то фиксируется требование к доработке.
Какова роль эксперимента, практики в этом процессе?
В процессе выработки модели возможно проведение деловой игры, с целью проверить те или иные идеи. Можно этого и не делать, тогда созданная модель на данном этапе будет ни что иное, как теория, которая потребует своего подтверждения последующим экспериментом – опытной эксплуатации.
Итак, результатом данного этапа “Функциональное моделирование” является Функциональная модель «To Be»: (“Как будет”).
Модель может быть записана в виде схемы в нотации eEPC ARIS. Фрагмент такой схемы:
Итого на этапе “Функциональное моделирование” рождается:
- Схема и описание бизнес-процесса «To Be», привязанная к возможностям типового решения, находящаяся в его рамках, объектах и понятиях, но тем не менее достигающая целей этих процессов.
- Подробное описание бизнес-процесса – как он будет выполняться пользователями в типовом решении, со скриншотами входных и выходных форм.
- Мини-моделирование в типовом решении на ограниченной выборке данных заказчика, в тех режимах, которые наиболее близки к требованиям модели.
- Зафиксированные требования – где именно требования к системе вышли за рамки типового решения. Обозначаются будущие доработки типового решения, которые потребуется детализировать в Техническом задании.
- Понимание заказчиком методик типового решения. Понимание, как система будет работать.
Отметим, что как правило, полное понимание не приходит при чтении документов – ТЗ, моделей и так далее. Понимание приходит только в процессе практической совместной работы над моделью в системе, что и имело место – совместном построении модели с консультантами.
Контрольный вопрос :)
Если пропустить этап функционального моделирования, а сразу поручить консультантам написать техническое задание на доработки, то какие гарантии получает заказчик, что недоработанная часть типового решения решит все его задачи?
Подытожим.
Этапы тестовой эксплуатации и функционального моделирования на 90% определяют результаты проекта на последующих этапах, поэтому именно в них заложен краеугольный камень нашей технологии
Читать полное описание технологии ИТРП>>>