8 (800) 500-61-51

8 (495) 600-61-81


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

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

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

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

Грабли

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

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

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

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

Начало: обучение и тестовая эксплуатация

Данный самый начальный этап технологии называется «Обучение и тестовая эксплуатация». Цели этапа:

Пазлы

Цель № 1. Сформировать понимание типового решения сотрудников Заказчика хотя бы в основе и совместить их систему понятий с системой понятий типового решения. Поскольку эти системы понятий могут отличаться.
Цель № 2. Сформировать у консультанта видение основных сложностей при внедрении выбранной ERP-системы на данном предприятии.

Как только эти цели достигнуты – сотрудники заказчика будут готовы работать совместно с консультантами над исследованием вопроса: «Как и в каком режиме использовать типовое решение, как изменить бизнес-процессы,  какие доработки типового решения стоит сделать, в какой последовательности запускать, для того чтобы построить оптимальную ERP-систему для предприятия на основе этого решения?»

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

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

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

Синергия

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

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

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

ПроцессыТР

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

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

ДеловаяИгра

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

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

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

АРИС

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

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

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

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

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

Подытожим.

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

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

Проекты и решения на 1С для производства

1С:ERP, 1C:УПП, 1С:MES, 1C:ТОИР

Заказать демонстрацию

Предсказуемое внедрение.
Гарантированный результат.
Выверенные технологии внедрения.

Подробнее

Ближайшие вебинары, курсы, конференции

Получайте расписание новых мероприятий на свою электронную почту

Подписаться

Обсудите вашу задачу с нашим специалистом

Сможем ли мы решить именно вашу задачу? Сколько это будет стоить? Сколько времени займет проект?
Оставить заявку
youtube.complus.google.comvk.com
-->