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

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

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

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

Текущее состояние

Часто сквозные процессы делят на модули, исполняемые целиком внутри организационных единиц компании, — их называют бизнес-процессами подразделения [1]. Такой способ локализации бизнес-процесса в рамках одного структурного подразделения свойственен функциональному подходу к управлению организацией и может противоречить основной цели моделирования — переходу к процессному управлению. Рекомендуется выявлять процессы с помощью цепочек создания ценностей [2]. Для этого предлагается: выявить клиентов компании; определить, какие продукты потребляют эти клиенты; определить поток преобразования продуктов или услуг, итогом которого является результат, ценный для клиента компании. Если компания выпускает материальный продукт, то определение цепочки создания ценности является относительно простой задачей, однако если компания предоставляет  услугу, то обнаружение цепочки ее создания существенно сложнее.

Чтобы сделать схему процесса читаемой и понятной, предлагается создавать иерархическую модель, где верхний уровень дает самое общее представление о ходе исполнения процесса, а все детали исполнения «спрятаны» на нижних уровнях [3]. Идея правильная, однако непонятно, как построить иерархию процесса, раскрывая его снизу вверх.

В качестве критерия разделения сквозного процесса на цепочку взаимодействующих подпроцессов ряд авторов советуют анализировать выходы одного этапа процесса и входы следующего [4]. Действительно, если вход и выход соотносятся как 1:1, то процесс можно рассматривать как монолитный, но если соотношение имеет вид 1:М или М:1, то это свидетельствует о разделении процесса на подпроцессы.

Таким образом, на сегодняшний день нет общепринятого критерия деления сквозного процесса на подпроцессы, и при отсутствии системного подхода аналитики полагаются на интуицию, а не на методологию. Как следствие, многие модели содержат ошибки, например до 20% моделей, включенных в справочник референтных моделей SAP, ошибочны [5].

Объект управления

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

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

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

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

Декомпозиция процесса

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

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

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

Примеры деления на подпроцессы

Рассмотрим типичный пример процесса заключения договора в нотации BPMN [6]. В примере имеются две точки старта, причем одна из них ведет в середину процесса, и несколько завершающих событий, некоторые из которых находятся в середине процесса (рис. 1). Сквозной процесс имеет два объекта управления: коммерческое предложение и договор — внимательный аналитик увидит смену объекта управления и предположит, что сквозной процесс распадется на два подпроцесса: «Согласовать коммерческое предложение» и «Заключить договор».

Рис. 1. Сквозной процесс от заявки до договора

В качестве второго примера, иллюстрирующего предлагаемый подход, рассмотрим бизнес-процесс присуждения Нобелевской премии, взятый из альбома типовых моделей в нотации BPMN [7]. В этом процессе можно выделить следующие объекты управления:

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

Анализ бизнес-процесса показывает, что по ходу исполнения происходит многократная смена и перегруппировка объектов управления: в ответ на одно объявление происходит сбор заявок, причем их число меняется из года в год. Каждая заявка может включать несколько кандидатов, количество которых заранее не известно. После отбора часть кандидатов попадет в список номинантов, размер которого зависит от обстоятельств. Это означает, что соотношение между объявлением о выдвижении кандидатов, числом заявок на выдвижение и количеством запросов на экспертизу заранее неизвестно. Следовательно, в модели должны быть выделены соответствующие подпроцессы: «объявить о сборе заявок», «собрать заявки», «провести экспертизу кандидатов». Вместе с тем заранее известно, что одному объявлению о выдвижении кандидатов всегда соответствует один список номинантов. В этом случае разделение на подпроцессы необязательно. Этот пример показывает, что выделение объектов управления и анализ связей между ними помогают разделить процесс на подпроцессы и правильно организовать их взаимодействие.

Этапы исполнения процесса

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

Декомпозиция процесса по этапам жизненного цикла объекта управления позволяет расположить этапы исполнения в естественном порядке следования. Они связаны безусловными переходами и образуют основной сценарий исполнения процесса [8], который не предполагает показывать альтернативные маршруты и варианты ветвления. Поэтому следующим шагом нужно уточнить модель: расширить — добавить в основной сценарий пропущенные варианты исполнения и углубить — детализовать каждый из подпроцессов. Можно оформить каждый этап как подпроцесс в нотации BPMN, тогда основной сценарий будет изображаться цепочкой подпроцессов, связанных безусловными переходами (рис. 2). Например, объект управления «Заказ» имеет следующие этапы жизненного цикла: оформление, проверка реализуемости, согласование условий, исполнение, передача заказчику и завершение финансовых расчетов. Затем основной сценарий следует уточнить: (а) расширить — добавить пропущенные варианты исполнения, (б) углубить — детализовать каждый из подпроцессов.

Рис. 2. Основной сценарий исполнения процесса

Моделирование организационных обязанностей

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

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

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

Следующий пример (рис. 3) показывает схему взаимодействия сотрудников одного подразделения. Обычно руководитель подразделения играет сразу несколько ролей: «Распределяющий», «Информируемый», «Проверяющий», «Визирующий». Если руководитель хочет иметь возможность самостоятельно исполнять задание, он должен быть приписан к роли «Исполнитель».

Рис. 3. Организационное взаимодействие участников

***

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

Литература

1. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М.: Манн, Иванов и Фербер, 2012.
2. Сооляттэ А.Ю., Репин В. В. Цепочка создания ценности — основа для построения сети бизнес-процессов компании // Финэксперт.
3. Silver B., BPMN Method and Syle, 2009.
4. Sharp А., McDermott P., Workflow Modeling. Artech House Publishers, 2001.
5. Mendling J., Neumann G., Van der Aalst W., Understanding the Occurrence of Errors in Process Models Based on Metrics // In: Proceedings of the OTM Conference on Cooperative information Systems (CoopIS 2007). Berlin: Springer-Verlag, 2007.
6. Белайчук А. Процессный паттерн: Cнова здравствуйте! [Электронный ресурс]. URL: mainthing.ru/ru/item/537/#more-537. 2012. (Из BPM-блога «Главное не результат, главное процесс»). 
7. OMG. BPMN 2.0 by Example. OMG Document Number: dtc/2010-06-02. www.omg.org/spec/BPMN/2.0/examples/PDF
8. Федоров И.Г. Системный подход к выявлению бизнес-процессов методом «сверху вниз» // Прикладная информатика. — 2012. No. 5 (41), — C.5–13.

Игорь Федоров (IFedorov@mesi.ru) — профессор, Московский государственный университет экономики, статистики и информатики (Москва).