Построение модели бизнес-процесса

Артур Хедж,

президент консалтинговой компании Castle Ventures LLC

Первый шаг к повышению эффективности процесса: определите, где вы сейчас находитесь.

Краткое описание процесса построения модели бизнес-процесса

Этап подготовки.

●  Определить границы процесса

●  Определить конечного потребителя процесса

●  Установить состав участников

Этап разработкимодели процесса.

●  Определить инициирующее событие

●  Определить результат процесса

●  Создать диаграмму процесса

●  Определить исключения

Этап проверки (валидации).

●  Проверить соответствие диаграммы процесса действительности

●  Определить исключения

Ранее я уже представлял несколько статей об управлении бизнес-процессами (BPM) и об инструментальных средствах, что служат для управления  бизнес-процессами. Эти инструментальные средства предназначены для разработки приложений, необходимых для решения бизнес-задач. Первым шагом в процессе создании ВРМ-приложений является разработка модели бизнес-процесса. Полученные модели в дальнейшем будут использованы для построения диаграмм, отражающих текущее состояние той или иной задачи, и подсказывающих, какие имеются возможности для усовершенствования, а также, что нужно сделать, чтобы оптимизировать и автоматизировать данную задачу. Эта статья призвана ознакомить читателя с процессом построения диаграмм бизнес-процесса (BPD), которые, в конечном счете, являются руководством при создании приложения.

В этой статье обсуждается построение модели с помощью нотации графического представления бизнес-процессов (BusinessProcessModelingNotation - BPMN). Стандарт BPMN представляет собой типовой набор символов и правил для описания бизнес-процессов. Стандарт поддерживается консорциумом Object Model Group (OMG), спецификацию стандарта можно найти на сайте консорциума www.omg.org. BPMN  - хороший вариант  для применения, ибо многие разработчики программных средств для  данной отрасли уже поддерживают этот стандарт. Кроме того, BPMN позволяет производить преобразование  в дополнительный набор стандартов, который называется языком для выполнения бизнес-процессов BPEL (BusinessProcessExecutionLanguage). Этот командный язык позволяет серверу процессов выполняет код, генерируемый непосредственно из BPMN. Для организации, инвестирующей значительные средства в BPM, использование открытых стандартов для разработки имеет долгосрочное стратегическое преимущество. Со временем такой подход позволит создавать модель процесса при помощи одного инструмента, а выполнять при помощи другого, исходя из того, что все они поддерживают указанные стандарты.

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

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

Подготовка

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

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

После корректного описания бизнес-процесса необходимо определить все задействованные в нем стороны. В BPMN они называются «участниками» («participants»). Те, кто знаком с UML, могут рассматривать их как “actors” (исполнители, субъекты). Термин «участник» при описании процесса относится к лицу или системе, а термин «область» («pool») - к существующей диаграмме. Участники – это люди или вещи, принимающие участие в процессе, который моделируется. Людей лучше идентифицировать не по именам, а по ролям, которые они играют. Например, если декан Роберт Смит, отвечающий за набор студентов, хочет принять всех абитуриентов, находящихся в списке ожидания, то соответствующая дорожка («swimlane») диаграммы будет называться «декан, отвечающий за набор студентов», а не «Роберт Смит». Абитуриенты на BPD представлены в виде областей, и к областям можно обращаться так же, как к дорожкам.

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

Начинаем составлять диаграмму

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

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

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

Если инициирующих событий несколько, попробуйте разбить событие на части и разработать новую высокоуровневую модель, включающую все инициирующие события. Конечно, это может оказаться коварной задачкой, с которой не так просто справиться. Например, в нашем примере с процессом поступления в колледж, возможно, будет необходимо доработать нашу модель, чтобы она предусматривала подачу заявления абитуриентом через Web или по обычной почте, и, таким образом, могла отслеживать процесс рассмотрения заявления с наступлением любого из вышеприведенных событий. Закономерно возникает вопрос: это два разных инициирующих события или одно, имеющее две разновидности? При построении модели существующего процесса, скорее всего, нет необходимости решать эту частную задачу, ибо цель данного этапа – определение критических областей существующего процесса, явно нуждающиеся в усовершенствовании. Однако, на этапе создания оптимизированной модели, которая уже будет использоваться в управлении производственными процессами, решение все же надо будет принять.

Определяем шаги процесса

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

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

Проверка

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

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

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

1. Артефакт (от лат. artefactum — искусственно сделанное) — явление, процесс, предмет, свойство предмета или процесса, появление которого в наблюдаемых условиях по естественным причинам невозможно или маловероятно. Появление артефакта, следовательно, является признаком целенаправленного вмешательства в наблюдаемый процесс, либо наличия неких неучтённых факторов (взято из Wikipedia).

Перевод компании DIRECTUM