Бизнес-процессы. Моделирование, внедрение, управление - Владимир Репин

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

Рис. 4.9.4. «Процессная грыжа»

Можно предложить следующие решения проблемы:

• разделить процесс на несколько частей и описать их в виде отдельных моделей, увязав между собой;

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

В первом случае возникает вопрос, как быть со сквозными процессами. Ответ прост. Сквозной процесс, как и любой другой, можно декомпозировать на несколько процессов. Каждый из этих подпроцессов, в свою очередь, может быть описан в виде кросс-функциональной схемы (см. главу 2). Важно только корректно установить связи между ними (информационные потоки, события).

4.9.5. Примитивизация – рисование процесса по «хвостам»

Одна из распространенных ошибок неопытного бизнес-аналитика – попытка описать бизнес-процесс, последовательно характеризуя операции по работе с документом (рис. 4.9.5). Если цель работы – создать маршрут движения документа, то это нормально. Если же надо описать именно бизнес-процесс, то такой подход приводит к ошибкам. Ведь кроме операций по работе с документом в процессе существует еще множество важных действий: получение информации, ее анализ, различные согласования, принятие решений. Бизнес-аналитик должен видеть картину целиком, а не только маршрут движения одного документа.

Рис. 4.9.5. Схема документооборота вместо схемы процесса

4.9.6. Однородность процесса

Однородность процесса – один из тех важных аспектов, на которые стоит обращать внимание при описании. Все определенные в рамках процесса операции должны по возможности соответствовать друг другу по длительности, трудоемкости, количеству потребляемых ресурсов. Так, некорректно отображать на схеме одного процесса две операции, одна из которых заключается лишь в передаче документа исполнителям, а вторая означает работу целого отдела по формированию пакета документов в течение двух недель. В данном случае неоднородность возникает по таким параметрам, как исполнители, состав работ, время их выполнения.

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

Рис. 4.9.6. Различный масштаб процессов

4.9.7. Связи между процессами, оборванные входы/выходы

Бизнес-аналитик должен ясно осознавать, что между процессами всегда существует взаимодействие. На схеме его можно показать через обмен данных. Это означает, что из процесса выходят и, наоборот, в процесс входят документы (в бумажном или электронном виде). При этом очень важно понимать, что эти документы не берутся из воздуха, а появляются в каком-то одном процессе, используются другим процессом, передаются третьему и т. д. Если бизнес-аналитик рисует на схеме процесса документы, не отдавая себе отчета в том, откуда они берутся, не уточняя их название и содержание, то схема будет мало соответствовать реальности.

На схеме процесса не допускаются оборванные входы и выходы (рис. 4.9.7). Всегда должны стоять ссылки на соответствующие процессы поставщиков и потребителей информации/документов.

Рис. 4.9.7. Оборванные входы/выходы процессов

4.9.8. Нарушение нотации моделирования

Нарушение нотации моделирования создает проблемы – схема становится нечитаемой, возникают неоднозначные моменты в ее интерпретации и т. д. Если в организации установлен стандарт моделирования бизнес-процессов, то обязательно нужно его придерживаться. Чем сложнее выбранная нотация, тем больше вероятность, что неопытный бизнес-аналитик нарисует схему, содержащую множество ошибок (рис. 4.9.8).

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

Рис. 4.9.8. Чрезмерно сложные схемы процессов

4.9.9. Проверка на здравый смысл

Даже самому опытному бизнес-аналитику полезно оценить полученную схему процесса с точки зрения здравого смысла (рис. 4.9.9). Это означает, что нужно, например, проверить процесс на физическую реализуемость: мы показываем, что сотрудник делает то-то и то-то, а он в это время давно уже занят чем-то другим и т. п.

Целесообразно обратить внимание на:

• ненужное повторение операций;

• перегрузку исполнителей;

• контрольные операции, от которых можно отказаться;

• возможность параллельного выполнения операций;

• возможность упрощения алгоритма выполнения процесса;

• неоправданное усложнение (лишние, устаревшие операции);

• узкие места различного характера;

• недостаточное обеспечение ресурсами;

• прочее.

Рис. 4.9.9. Проверка на здравый смысл

4.10. Рекомендации по внедрению среды моделирования процессов

Внедрение среды моделирования процессов в масштабах организации – важный и сложный проект. Для его успешного выполнения нужно разработать план, адекватный задаче. Предлагаю один из возможных вариантов такого плана[103].