Как правильно рисовать блок схемы бизнес процессов

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

Если возможности нет, а информация жизни.

Начнем с того что BPMN, EPC и IDEF - это умные слова и не более того. Попытка описывать ими бизнес-процессы приравнивается к попытке чесания ногой за ухом...

Если специалист говорит что описал процессы и в качестве результата будет показывать мне рисованные схемы, в Visio, Aris, в нотациях BPMN, EPC или IDEF и т д, то у меня в голове сразу включает сигнал тревоги: "умник прямо по курсу, от которого надо держаться по дальше".

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

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

Вот. Выговорился )))

Этот поток "комплиментов" относится именно к специалистам по BPMN/EPC/IDEF итд, но не к нотациям как таковым. Сами нотации - есть обычный инструмент. Но как и ножом - ими нужно уметь пользоваться и понимать где это нужно. К примеру бесполезно ножом есть суп, даже если у вас очень модный нож и вам очень сильно хочется им похвастаться.

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

Задача косалась процедуры входящих документов. Там есть проблема с контролем (как выяснилось из-за ошибки в ПО ДИРЕКТУМ), которую нужно было найти, определить, обосновать руководству и поставить задачу программистам. Вот под эту конкретную задачу и понадобилось написать схему.

Восстановим хронологию событий:

1. Поставлена цель: отказ от бумаги

2. Начали проработку нового порядка действий

3. Выяснили, что отказаться от бумаги не можем, т.к. в ДИРЕКТУМе нет контроля исполнения РКК

4. Начали думать над постановкой контроля в ДИРЕКТУМе, чтобы видеть показатели типа: "Средняя длительность исполнения входящих документов", "Доля документов выполненных в сроки". Ну и увиедть конкретные записи по нарушениям. Например: РКК №123 - нарушение срока на 5 дней. Ответственный: Петров и Сидоров

5. Пытаюсь вывести отчет. Но не тут то было. В отчете есть план.дата, но в 99% записей нет факт.даты. А как посчитать среднюю длительность? И как узнать нарушен срок или нет? Никак! И те РКК, где План.дата меньше сегодняшней даты = просрочены. Хотя люди говорят что все выполнили и нажали Выполнено.

6. Начинаем разбирать ситуацию, почему в 1% записей факт дата есть, а в 99% - нет. Выясняем, что факт.дата проставляется и не проставляется в следующих вариантах:

6.1. Факт дата проставляется, если реквизит "На контроле" = "Да", документы выполнен, отправлено задание контроль на руководителя и принято. Все!

6.2. А не проставляется во всех остальных случаях, включая:

6.2.1. Реквизит "На контроле" = "Да", но руководитель не принял задание-контроль. Факт дата = Пусто. Документ считается просроченным.

6.2.2. Реквизит "На контроле" = "Нет". В этом случае ПО вообще не ставит Факт.дату. Все поручения обозначаются как просроченные.

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

Именно эту картинку я и попытался отобразить в виде схемы.

Цель у этой схемы не описать процесс, а показать проблемную точку в процедуре, быстро поставить задачу программисту по поиску ошибки в ТМ и объяснить руководству, от куда завал.

Т.е. взята конкретная точка зрения на конкретное место в процессе и схема более или менее информативна.

А если при помощи таких схем описать процесс в целом, то получается каша и ноль полезной информации.