Особенности создания корректных схем бизнес-процессов

Оригинальная статья: «Особенности создания корректных схем бизнес-процессов», В.В. Репин

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

Корректное определение границ процесса

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

Привязка к системе процессов

В предыдущем случае мы говорили о том, что процесс «ушел не туда». Еще одной из причин такой ситуации является отсутствие системного видения бизнес-процессов организации. Если иерархического справочника процессов нет, то при попытке описать какой-то процесс, скорее всего, возникнет ситуация «захвата» областей из других процессов и т.п. Далее следуют малопродуктивные споры, как провести границы. Поскольку переделка схем требует времени, появляется искушение согласовать «кривые» границы процессов и т.п.

Декомпозиция – слишком «длинные» процессы

Неопытные бизнес-аналитики часто «рисуют» слишком длинные схемы процессов. Так получается, если начать задавать вопросы сотруднику и ту же пытаться формировать схему. Лучше сначала выслушать описание деятельности в целом, делая пометки в блокноте. Затем обдумать ситуацию, структурировать описание деятельности «в голове» , выделяя процессы и предварительно определяя состав их операций. Только после этого приступать к формированию графических схем. Кстати, велика вероятность, что при структурировании информации, полученной от сотрудников, окажется, что целесообразно выделить и описать не один, а несколько процессов.
Если схема процесса все-таки получилась слишком длинной (более 12-15 операций), следует внимательно ее проанализировать. Возможно, что:
• на схеме представлено несколько процессов, а не один;
• операции процесса сильно неоднородны (по длительности выполнения, по требуемым ресурсами т.п.);
• в процессе появилась «грыжа» (см. ниже);
• прочее.

В любом случае, схему процесса стоит переделать. Исключения составляют ситуации, когда схемы специально рисуют на бумаге формата А3, чтобы отразить все детальные шаги и взаимодействия. Но увлекаться увеличением формата листов для схем процессов не стоит. А3 – это максимально допустимый размер. «Рисовать» и потом печатать схемы процессов на А2 или на А1 категорически не рекомендуется.

«Процесс в процессе» или процессная «грыжа»

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

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

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

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

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

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

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

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

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

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

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

Использование типовых процессов

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

Автор: Владимир Владимирович Репин, к.т.н., доцент, Исполнительный директор ООО «BPM Консалтинг Групп», зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru.