To-be или As-is?

 

Большинство сталкиваются с этим вопросом при моделировании бизнес-процессов и не знают ответа. Основная проблема заключается в следующем. Большинство случаев, когда необходимо моделировать деятельность, происходит в рамках проектов по внедрению информационных систем. Моделирование бизнес-процессов ради других целей (организация управления процессами, регламентация и т.д.) отпочковалось от целей автоматизации позже, а подходы в моделировании стали скорее не полезными методами, а стереотипами моделирования. Столпы методологий внедрения так и продавливают варианты, в которых сперва моделируется деятельность как есть, без прикрас, а только затем проводится анализ и оптимизация БП (в некоторых методологиях оптимизация, т.е. To-be моделирование производится уже после внедрения ИС).

Это ещё вызвано тем, что основная цель проекта внедрения ИС  - это внедрение ИС! Т.е. у To-be моделирования есть четкие цели: подгонка бизнеса под референтные бизнес процессы ИС, а первоначальное As-is моделирование при таком подходе необходимо лишь как исследование бизнеса и подготовка плацдарма для перехода на To-be модель. При этом очевидно, что описание существующих процессов происходит семимильными шагами.

Справедливы ли те же подходы при моделировании деятельности в рамках проектов внедрения процессного подхода в управлении БП, внедрении СМК, внедрении регламентации деятельности и т.д.?

Основная трудность при моделировании в рамках вышеперечисленных случаев возникает в случае, когда рабочая группа пытается жестко прибиться к одному из берегов: только As-is  и потом To-be или сразу To-be, а существующие процессы признаны порочными и неэффективными.

Оба варианта на практике оказываются крайностями. В то время как на самом деле оптимальным является разумный компромиссный подход. Я называю его “Optimized as-is+”. Т.е. на этапе моделирования ни в коем случае нельзя уходить от описания бизнеса как-есть, если вы только не организуете бизнес-процесс с нуля, но и не всегда целесообразно описывать все в точности как есть: особо вопиющие случаи неправильной работы, дублирования функций и т.д. Плюс необходимо обязательно сохранять все идеи в тех случаях, когда все таки процесс описан как есть, но требуются слишком глобальные изменения. Т.е. на этапе планирования проекта должны быть выработаны критерии и процедуры касающиеся оптимизации выявленных недостатков (немедленной или в будущем), а именно:

• Должна быть определена процедура внесения немедленных корректировок и превентивных мер при выявлении вопиющих случаев неправильного выполнения бизнес-процесса (анализ, согласование, корректировка, существующей на тот момент, управляющей документации, необходимые приказы и т.д.) и отражение в модели уже нового оптимизированного процесса.
• Сформирована база знаний по выявленным недостаткам, которые требуют тщательного анализа на этапе последующего To-be моделирования (описание процесса таким образом, чтобы все возникшие идеи на этапе моделирования не были потеряны и доступны потом).
• Выработаны критерии, по которым бизнес-аналитик сможет принимать решения, запускать немедленную процедуру оптимизации или откладывать её на потом. Здесь нужно учитывать временные ограничения проекта, т.к. иногда может оказаться что оптимизировать будет быстрее чем описать как есть, или наоборот. Четкие критерии должны помочь избежать затягивания проекта из-за чрезмерно большого кол-ва оптимизаций на этапе первоначального моделирования (гонкой за лучшим, которое как известно враг хорошего)
  

Как известно именно на этапе моделирования выявляется большинство недостатков, и бизнес-аналитики могут именно на этом этапе накопить наибольшее число идей по оптимизации, которые лежат вне предметных областей экспертов и не требующих глубокого анализа. Именно эти идеи будут востребованы при последующем этапе глубокого анализа и оптимизации бизнес-процессов.

Полученная оптимизированная модель как есть уже сама по себе становиться важной вехой в любом проекте, т.к. является самодостаточной для внедрения ИСО или в рамках других проектов. Накопленный опыт по организации процедур оптимизации может быть перенесен на дальнейшие этапы проекта и вообще регулярной деятельности, например в качестве обязательных документированных процедур требуемых системой менеджмента качества и т.д.