1.2.4 История развития описания бизнес-процессов

История описания бизнес-процессов насчитывает уже почти столетие, хотя вплоть до начала 1990-х гг., когда термин «бизнес-процесс» вошел в широкое употребление, говорили об описании того, каким образом организация осуществляет свои функции и выполняет те или иные задачи. Развитие методов графического представления и автоматизации бизнес-процессов принято разделять на три этапа, или три «волны». Началом каждой из них явился очередной всплеск интереса к повышению эффективности деятельности предприятий и процессному управлению, происходивший каждый раз на новом качественном уровне. Начало первого этапа относят к 1920-м гг. XX в. и связывают с именем Фредерика Тейлора и его книгой «Принципы научного управления». В этот период впервые была осознана необходимость исследовать бизнес-процессы, описывать их в различных документах и действовать в соответствии с этими описаниями. Описание бизнес-процессов производится в текстовом, табличном и графическом виде, причем последний все более формализуется.

В период «первой волны» для графического представления бизнес-процессов используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Блок-схемы на основе, определенной в ГОСТ 19.701-90 нотации схем алгоритмов, программ, данных и систем (в англоязычной литературе – ANSI flowcharts), остаются и сегодня простейшим, но практически важным формальным графическим языком описания бизнес-процессов. Пример описания процесса с помощью блок-схемы приведен на рис. 1.3. Блок-схемы позволяют быстро и наглядно показать шаги бизнес-процесса в понятной каждому форме, однако их нотация не предусматривает формализованного описания многих деталей процесса, в частности исполнителей бизнес-функций.

Рисунок 1.3 – Пример простой блок-схемы

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

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

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

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

Начало второго этапа ознаменовал выход книги М. Хаммера и Д. Чампи «Реинжиниринг корпорации: манифест революции в бизнесе», которая возродила в управленческой среде интерес к описанию и анализу бизнес-процессов с целью их радикальной перестройки – реинжиниринга. Реинжиниринг бизнес-процессов предполагает построение двух моделей бизнес-процесса: как есть (англ. as is) и как должно быть (англ. to be), а затем внедрение последней на предприятии.

Как следующий шаг в автоматизации бизнес-процессов в 1990-х гг. появляются системы управления потоками работ WfMS (Workflow Management System) второго поколения, предназначенные для маршрутизации потоков работ любого типа в рамках бизнес-процессов компании. Современные ERP-системы, речь о которых пойдет далее, также содержат внутри себя средства автоматизации бизнес-процессов на основании разработанных моделей, таким образом на завершающей стадии модель бизнес-процесса становится основой автоматизации бизнес-процессов. В качестве примера методологии и средства автоматизации бизнес-процессов второго поколения можно назвать соответственно методологию ARIS и распространенную ERP-систему SAP R/3. Однако существующие на тот момент ERP-системы, имели крайне ограниченные возможности по настройке и изменению процессов, предоставляли только поддерживающие управление потоками работ системы планирования ресурсов предприятия. Поэтому внесение любых существенных изменений в бизнес- процесс превращалось в весьма дорогостоящий и долгосрочный проект по проектированию и разработке программного обеспечения, а модели бизнес-процессов, построенные аналитиками, использовались для более четкой формулировки требований, которые затем передавались программистам.

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

Идея методологий и инструментов моделирования третьего поколения состоит в том, чтобы позволить руководству и сотрудникам компании создавать и самим внедрять новые процессы «на лету». Автоматизация процессов производится посредством так называемых систем управления бизнес-процессами BPMS (Business Process Management System), которые дают возможность непосредственно реализовывать бизнес-процессы в соответствии с построенной формальной моделью и не требуют разработки дополнительного программного обеспечения.

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

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

«Третья волна» принесла в моделирование бизнес-процессов стремление к стандартизации. Методологии построения исполняемых моделей разрабатываются и выпускаются организациями по стандартизации и международными консорциумами:

– OASIS (Organization for the Advancement of Structured Information Standards, осн. в 1993 г.) выпускает спецификации ebXML и BPEL, а также различные стандарты для электронного бизнеса на базе XML и веб-сервисов;

– OMG (Object Management Group, осн. в 1989 г.) выпускает стандарты BPMN и UML, а также MDA и CORBA;

– W3C (World Wide Web Consortium, осн. в 1994 г.) выпускает стандарты WS-CDL, WSCI, а также спецификации XML, технологии веб-сервисов и многие другие;

– WfMC (Workflow Management Coalition, осн. в 1993 г.) выпускает стандарты Wf-XML и XPDL.

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

1.3. Моделирование бизнес-процессов

1.3.1 Основные принципы моделирования бизнес-процессов

Давайте теперь разберемся, что означает моделирование бизнес-процессов на практике. Моделирование бизнес-процессов в компании может быть направлено на решение большого числа различных задач:

– Точно определить результат бизнес-процесса и оценить его значение для бизнеса.

– Определить набор действий, составляющих бизнес-процесс. Ясное определение набора действий, которые необходимо выполнить, чрезвычайно важно для детального понимания процесса.

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

– Произвести разделение зон ответственности: определить и отслеживать, какой сотрудник или подразделение компании несет ответственность за выполнение того или иного действия или процесса в целом.

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

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

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

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

– Более эффективно внедрить стандарты качества, например, ИСО 9000, и успешно пройти сертификацию.

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

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

– Разобравшись в совокупности бизнес-процессов, понять и описать деятельность предприятия в целом.

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

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

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

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

На рисунке 1.4 показаны основные шаги при построении модели бизнес-процесса.

Рисунок 1.4 – Шаги построения модели бизнес-процесса

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

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

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

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

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

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