Что такое BPM?

Джон Харни

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

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

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

BPM против Workflow

Похоже, без дебатов тут не обойтись. Стив Вайсман, президент компании Kinetic Information LLC, например, утверждает, что BPM   - это набор инструментов для составления схемы, моделирования и оптимизации бизнес-процессов, в то время как workflow – это механизм исполнения. Инструментарий BPM, добавляет он, был разработан для бизнес-экспертов, а не «айтишников». «Бизнес-аналитики и люди, причастные к управлению бизнесом, используют BPM потому, что бизнес-логика должна исходить от людей, которые знают толк в бизнес-процессах». «Функционал workflow гораздо более программно-ориентированный», утверждает Вайсман. Он в большей степени используется сотрудниками IT-отделов, которые разрабатывают код, который, скажем, позволяет бизнес-пользователям работать над документами либо последовательно, либо одновременно. Вайсман также не определяет границы двух типов систем – любая из них может охватывать как одно приложение или организацию, так и несколько. Более того, он утверждает, что функционал двух типов систем пересекается.  

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

Джон Пайк, президент компании The Process Factory, поставщика сервиса приложения BPM, добавляет, что «подобно тому, как middleware выполняло функции абстракции данных, BPM является слоем «абстракции процессов». Пайк продолжает: «и вместо того, чтобы каждое приложение отвечало за определенный набор процессов и координировало бы работу смежных приложений для эффективной работы процессов, BPM берет управление процессами у индивидуальных приложений и делает их равноправными участниками, которые подчиняются работе BPM-слоя, ответственного за исполнение процессов. BPM делегирует приложениям выполнение заданий или осуществление каких-то действий в соответствии с их специализацией». Таким образом, BPM можно назвать главным управляющим слоем, координирующим процессы во всех приложениях, с которыми он интегрирован.

Типы BPM

Согласно Палмеру, организации имеют несколько альтернатив внедрения ВPM-систем. Две из них, описанные ниже, представляют два диаметрально противоположных способа внедрения BPM:

●     Готовый пакет приложений BPM или фреймворк. Эти продукты представляют собой полностью завершенные приложения с функционалом «от и до», от моделирования и имитации до оптимизации и исполнения.  

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

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

Зависимая инфраструктура, а не автономное приложение

На практике большинство организаций делают выбор в пользу BPM-пакетов. По словам Майкла Меленовского, директора по исследованиям BPM компании Gartner, эти пакеты включают в себя инструменты анализа бизнес-процессов, построения модели, мониторинга, имитационного моделирования и оптимизации, а также механизма создания правил, конечных автоматов и механизмов упорядочивания. Вместе с тем, подчеркивает Меленовский, BPM это не только и не столько технология, сколько практика, требующая предварительного определения бизнес-процессов, перед тем, как приступать к использованию большинства предложенных инструментов. То же самое можно сказать и про workflow. Однако в случае с BPM, продолжает Меленовский, как только сотрудники выработали четкое определение бизнес-процесса, они используют набор разнообразных инструментов на реальных данных для того, чтобы в интерактивном режиме моделировать, тестировать, имитировать и оптимизировать процесс до тех пор, пока он не будет работать безупречно. Более того, как только этот процесс внедрен, сотрудники продолжают отслеживать и оптимизировать его, поскольку в отличие от workflow, BPM предполагает, что процесс будет со временем изменяться.

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

Главное отличие – сложность функционала

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

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

На что стоит обращать внимание при выборе BPM-продукта

Учитывая специфику BPM, при выборе BPM-продукта организации должны обратить внимание на следующие ключевые параметры, которые приводятся в исследовательском отчете Gartner “Создание BPM и список поставщиков автоматизированных систем workflow”. 

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

Возможность взаимодействия (интероперабельность). Поскольку BPM-системы взаимодействуют одновременно с несколькими приложениями, они должны соответствовать общепринятым отраслевым стандартам и спецификациям BPM, таким как BPML, Wf-XML и BPEL. Интеграция с EAI-продуктами, директориями типа Lightweight Directory Access Protocol (LDAP) и инструментами анализа бизнес-процессов также бедет полезна.

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

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

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

Проблемы разнообразия на рынке

Очевидно, что не все поставщики BPM одинаково. «Чистые» поставщики BPM-пакетов, такие как Pegasystems, Lombardi и Fuego предлагают полный комплект BPM-функциональности, но каждый в чем-то имеет превосходство, например, в инструментах интеграции или удобных средствах моделирования. Поставщики систем управления контентом, такие как FileNet и Documentum уже занимают, либо займут в ближайшем будущем свою нишу на рынке BPM, но в части документо-ориентированных решений. Поставщики EAI, такие как Tibco, совершили стратегические приобретения (Staffware), чтобы включить BPM в ассортимент предлагаемых решений, подобно тому, как это сделали другие поставщики, которые, на первый взгляд, не имеют никакого отношения к BPM, но либо купили (Autonomy приобрела TrailerSoft), либо сами добавили (Adobe) BPM-функционал. Большинство крупных игроков на рынке (IBM, Oracle, Microsoft) разрабатывают собственные BPM-продукты. Есть даже host BPM-решения (NSite, M1 Global, The Process Factory) и opensource-решения (Intalio).

Возможно, что именно в связи с такой диверсификацией и некоторой неразберихой относительно того, какую именно функциональность производители готовы предложить, Гартнер прогнозирует, что по итогам 2005 года 80% крупных организаций, внедряющих приложения для поддержки стратегий по управлению бизнес-процессами, по-прежнему будут использовать множество продуктов для интеграции и управления задачами». Другими словами, несмотря на то, большинство организаций  делают выбор в пользу BPM-пакетов, «best-of-breed» подход в BPM (использование оптимальных решений от разных поставщиков) имеет место быть. Организация может, например, использовать Ultimus для моделирования и Pegasystems для решения остальных задач.

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

Конечная выгода и предварительные выводы

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

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

Джон Харни – бывший редактор журнала “Inform” (его предыдущее название), автор многих статей. С ним можно связаться, написав на johnharney@netzero.net.

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