Избранные паттерны BPM

Анатолий Белайчук, президент компании «Бизнес-Консоль»

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

BPM-системы позволяют реализовывать разные схемы бизнес-процессов, но не все схемы будут одинаково хорошо работать, и так же, как, например, при проектировании баз данных, для создания оптимальной архитектуры надо обладать специальными знаниями. Однако, если проектирование баз данных — уже сложившаяся дисциплина с классическими работами, учебниками, несколькими поколениями специалистов-практиков, то при работе с BPMS (Business Process Management Suite) аналитики и программисты до сих пор идут каждый своим путем, повторяя одни и те же ошибки и решая однотипные проблемы. За какой процесс браться в первую очередь? С какого уровня начинать и до какого детализировать процесс? Где использовать подпроцессы? Как должны запускаться процессы? Как грамотно совместить BPMS с существующими базами данных, бизнес-приложениями, с SOA и т.п.?

Литературы по BPM почти нет, специалистов мало, опыт накапливается по крупицам, а сама методология располагается на стыке нескольких областей знания — для грамотного проектирования бизнес-процессов с прицелом на их исполнение в BPMS надо разбираться и в бизнесе, и в технологиях, и в процессном, и в проектном управлении, попутно ориентируясь в TQM, ISO 9000, CMMI, Six Sigma и Lean. Одновременно быть специалистом во всех этих областях невозможно, поэтому возникло разделение на бизнес-аналитиков, системных архитекторов и процессных инженеров. Но и полностью замыкаться в одной роли не стоит, надо иметь хотя бы общее представление о смежных дисциплинах. Иначе мы по-прежнему будем автоматизировать то, что неинтересно для бизнеса, и рисовать процессные диаграммы, которые невозможно исполнить.

Кстати, не стоит ожидать интегрального взгляда на организацию бизнес-процессов и от поставщиков BPM-систем — те, кто разрабатывают BPMS, сами их не используют, и производители демонстрируют свои продукты на примере процессов либо представляющих слабый интерес для конкретного бизнеса, либо сильно упрощенных. В результате у потенциального заказчика возникает вопрос: как применить BPMS к реальной жизни? Дать на него исчерпывающий ответ в рамках статьи затруднительно, поэтому мы ограничимся рассмотрением типовых решений для нескольких типовых проблем.

Что такое «паттерн»

Английское слово «pattern» иногда переводят как «шаблон», что приводит к неоднозначности, ведь одному русскому слову «шаблон» соответствуют два английских: template и pattern. Template — «шаблон изготовления», то, что упрощает изготовление однотипных предметов. Например, шаблон процесса — это то, из чего «изготавливается» экземпляр процесса. Pattern — это «шаблон узнавания», некий обобщенный «рисунок проблемы» (pattern recognition — распознавание образов). Анализируя бизнес-процесс, мы ищем в нем сходство с известными нам по предшествующему опыту паттернами, и если находим, то применяем соответствующее решение. Применяя шаблон, мы идем от решения к задаче, а паттерн подразумевает ход мысли от проблемы к решению.

В программной инженерии используются паттерны дизайна и архитектурные паттерны. Архитектурные паттерны отличаются большим масштабом, например Three-Tier, Model-View-Controller и Service Oriented Architecture. Паттерны дизайна успешно применяются в объектно-ориентированном программировании начиная с 1994 года [1]. Используется также термин «антипаттерн» — для обозначения решения, кажущегося очевидным и даже иногда приносящего какие-то выгоды на начальном этапе, но в конечном итоге далекого от оптимального.

Термин process pattern в ИТ-литературе зачастую употребляется в узком смысле — применительно к процессам разработки, тестирования, внедрения и сопровождения программного обеспечения. При всей своей важности эти процессы не являются основными для большинства компаний, поэтому здесь будем говорить о паттернах универсальных, не привязанных к конкретной отрасли. С 1999 года работы в области процессных паттернов ведутся в Университете Эйндховена (www.workflowpatterns.com). Ван дер Аалст и другие исследователи каталогизировали свыше 100 паттернов. Широкую известность получили выполненные в 2002-2004 годах на основе этих паттернов сравнительные исследования процессных нотаций и языков BPEL, BPML, XLANG, WSFL, WSCI, BPMN и UML2.

Без паттернов не обходится изучение нотации BPMN (Business Process Modeling Notation, www.bpmn.org), на что есть объективные причины — хотя BPMN сегодня является наиболее прогрессивным стандартом в области BPM, он страдает от неоправданной сложности, избыточности, внутренней противоречивости, логических ошибок. Одну и ту же процессную логику в нем можно реализовать разными способами, а некоторые элементы являются сугубо теоретическими и не поддерживаются ни одной из распространенных BPMS.

Рассмотрим по два паттерна и два антипаттерна, обобщающие опыт автора в реализации процессного управления при помощи таких BPMS, как Fujitsu Interstage, Oracle BPMS (ранее BEA AquaLogic), Software AG WebMethods и TIBCO iProcess, Unify NXJ. Паттерны представлены в виде диаграмм BPMN и могут быть реализованы практически в любой современной BPMS.

Антипаттерн «Оркестровка сквозного процесса»

Методология BPM нацеливает на работу с так называемыми «сквозными» (end-to-end), или «корпоративными» (enterprise) бизнес-процессами, нацеленными на внешнего заказчика и охватывающими несколько служб предприятия. Классический пример — процесс «от заказа до оплаты»: получение аванса, производство, отгрузка, расчеты.

Рис. 1. Оркестровка сквозного процесса

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

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

Антипаттерн «Бесконечный процесс»

Рассмотрим процесс, охватывающий взаимодействие компании с контрагентом (покупателем или поставщиком) от заключения договора через его исполнение до прекращения.

Рис. 2. Бесконечный процесс

В чем изъян здесь? Нет учета изменчивости бизнес-процесса. Рассмотрим достаточно распространенную ситуацию, когда характерная продолжительность экземпляра бизнес-процесса (в данном случае это срок действия договора) составляет не дни и недели, а месяцы и годы. Если мы действительно реализуем стратегию постоянного усовершенствования, то неизбежно в течение этого срока схема процесса изменится — либо в обработке заказа, либо в отгрузке, либо в финансовых расчетах. Таким образом, мы регулярно будем сталкиваться с тем, что исполняющиеся экземпляры процесса не соответствуют его текущему шаблону. Лучше избегать схем, которые провоцируют расхождение между экземпляром и шаблоном процесса (см. паттерн «Конечный автомат»). А упомянутую возможность внесения исправлений «на лету» приберечь для нештатных ситуаций.

Паттерн «Внутренний заказ»

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

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

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

Рис. 3. Внутренний заказ

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

Системный подход к решению этой задачи предложен Эли Голдратом в классической работе [3]. Предложенные в ней теория «бутылочного горлышка» и модель «барабан-веревка-буфер» — основа для выработки оптимального решения. Упрощая, можно сказать, что службы, обладающие избытком мощностей, должны работать синхронно, а узкие места — асинхронно, при этом число узких мест заведомо мало.

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

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

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

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

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

Паттерн «Конечный автомат»

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

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

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

Иногда вместо иерархии «головной процесс–подпроцессы» используется «цепочка»: процесс «Заключение договора» в случае успешного завершения запускает процесс «Получение аванса по договору» и т.д. Рассматриваемую проблему такой подход не решает, а сбор статистики показателей «сквозного» процесса затрудняет.

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

Рис. 4. Конечный автомат

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

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

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

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

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

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

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

Литература:

1. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2007.

2. Silver, Bruce. BPMN’s Three Levels, Reconsidered. 2008. www.brsilver.com/wordpress/2008/12/03/bpmns-three-levels-reconsidered/.

3. Голдрат Э. М., Кокс Дж. Цель: процесс непрерывного совершенствования. М.: Попурри, 2004.

Источник: Открытые системы, 5 марта 2009