Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: Александр Вадимович Самарин, к.т.н., корпоративный архитектор в кантональном правительстве Швейцарии.

Резюме. Опыт показывает, что пользователи предпочитают быстрое внедрение отдельных требований на модификацию существующих программных систем. Эти изменения небольшие с точки зрения бизнеса и непредсказуемые с точки зрения ИТ департамента. В случае использования процессного подхода к работе предприятия, все фазы жизненного цикла бизнес-процессов должны быть соответствующим образом организованы, чтобы успешно справляться с потоком модификаций  с приемлемой для пользователей скоростью. Цель этой статьи состоит в том, чтобы разделить с читателями практический опыт работы с архитектурным подходом [1-8] к усовершенствованию систем управления бизнес-процессами предприятий. В статье предлагаются рекомендации, примеры, принципы, которые могут вам помочь при реализации легко изменяемых бизнес-процессов предприятия.

Ключевые слова: BPM, SOA, бизнес-процесс, артефакт, гибкость

1. Введение

Повышение эффективности предприятия – это постоянная и нетривиальная задача, успешное решение которой требует некой организации работы предприятия. Наиболее современным подходом к такой организации работы является процессный подход, представленный в настоящее время дисциплиной «Управление бизнес-процессами» (Business Process Management – BPM).

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

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

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

Мир бизнеса давно понял (см. такие методики, как TQM, BPR, 6 Sigma, Lean, ISO 9000), что процессы и службы – это основа функционирования большинства предприятий. ИТ мир недавно заново «открыл» понятие «служба» (service), что привело к развитию архитектуры, ориентированной на службы (Service Oriented Architecture – SOA). Но ИТ мир еще не полностью освоил понятие «процесс».

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

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

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

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

2. BPM-система предприятия должна быть спроектирована

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

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

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

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

1. Все артефакты постоянно улучшаются или усовершенствуются (оцифровываются, экстернализируются и виртуализируются).
2. Любой артефакт может иметь много версий для отражения изменения артефакта в течении его жизненного цикла.
3. Все взаимозависимости между артефактами моделируются явным образом.
4. Все модели делаются исполняемыми. Это означает, что, например, бизнес-процесс действует как координатор или организатор согласованного исполнения различных служб с целью получения определенного результата.

Конечно, чтобы гарантировать высокий уровень гибкости BPM-системы предприятия, необходимы дополнительные начальные усилия, но эти затраты существенно ниже, чем выгоды, получаемые за все время существования BPM-системы предприятия. Рис. 1 показывает изменение соотношения относительных затрат между разработкой и сопровождением ИТ приложений при использовании архитектурного подхода. (Эти затраты вычисляются относительно полной стоимости ИТ приложения на всем его жизненном цикле – Total Cost of Ownership – TCO.)

Рис.1 Каждое последующее решение более дешево,
потому что оно снова использует те же самые инструменты,
те же самые службы и ту же самую архитектуру

Средняя величина этого соотношения в ИТ отрасли – это 20 % - тратится на разработку ИТ приложения и только 80 % – на его сопровождение. Использование архитектурного подхода значительно уменьшает затраты на сопровождение ИТ приложения и, таким образом, уменьшает его полную стоимость.

Рис. 1 получен на основе практического опыта использования архитектурного подхода для сопровождения производственной системы, автоматизирующей производство приблизительно 3 000 сложных электронных продуктов ежегодно (среднее время подготовки продукта составляло несколько лет). Эта производственная система включала около 50 сотрудников, более 50 типов работ, 3 производственные линии, 40 ИТ-служб и 6 хранилищ данных и документов. Она развивалась несколько лет, в течение которых были проведены многочисленные функциональные расширения и несколько успешных и нетрудоемких замен версий основных ИТ продуктов. Обслуживание и развитие этой производственной системы потребовало в несколько раз меньше ресурсов, чем при традиционном подходе.

3. Единое понимание артефактов

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

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

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

Ниже приведен список бизнес-артефактов, важных для BPM-системы предприятия:

• события
• процессы
• правила
• действия
• роли
• объекты (структуры данных)
• объекты (документы)
• аудиторские отчеты
• индикаторы производительности
• службы

4. Улучшение артефактов

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

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

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

В-третьих, артефакты должны быть виртуализированы, то есть быть доступными независимо от специфических ИТ ресурсов, таких как серверы, базы данных, форматы, браузеры, и т.д. Например, как использовать в Java программе бизнес-правило, определенное в Excel?

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

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

Говоря о совместном использовании дисциплины BPM и SOA, необходимо подчеркнуть, что дисциплина BPM, выявляя артефакты и взаимозависимости между ними, обеспечивает необходимый контекст для определения служб (например, степень их детализации). SOA, в свою очередь, обеспечивает рекомендации для реализации, выполнения и руководства службами.

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

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

5. Структурирование взаимозависимостей между артефактами

Между артефактами имеется много взаимозависимостей. Некоторые из них следуют из того, как дисциплина BPM рассматривает бизнес:

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

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

Рис. 2 Видимость артефактов

Архитектурный подход рекомендует выявлять все скрытые взаимозависимости и структурировать их. Примеры таких взаимозависимостей следующие:

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

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

Два самых важных артефакта - службы и процессы - взаимно зависят друг от друга следующим образом :

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

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

Рис. 3 Взаимозависимость между процессами и службами

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

Процесс – это пример одной из наиболее сложных взаимозависимостей между артефактами.

6. Моделирование исполняемых бизнес-процессов как разработка их реализации

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

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

Небольшие итерации «моделирование-реализация-тестирование-перестройка», подобно известной модели PDCA [10], и различные технологии быстрого (agile) программирования значительно упрощают и моделирование, и реализацию. Большинство неправильных решений быстро обнаруживаются и легко исправляются; службы быстро приводятся к необходимой степени детализации и т. д. Как побочный продукт этого подхода, развитие бизнес-процессов становится намного легче – большинство модификаций осуществляется быстро, потому что все ориентировано на простоту внесения изменений. В некотором смысле стирается граница между разработкой и сопровождением.

Эта процедура моделирования была разработана для совместной работы специалистов бизнеса и ИТ. Она направлена на эффективное использование современных специализированных программных платформ BPMS (Business Process Management Suite), например Intalio BPMS (www.intalio.com). Компания Intalio одной из первых применила автоматическую генерацию BPEL [11] из BPMN [12], что открыло возможность для совместной работы специалистов бизнеса и ИТ в одной и той же системе.

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

Во время моделирования также собираются и уточняются различные артефакты необходимые для реализации данного функционального блока.

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

В реальности все обстоит намного сложнее: собираемая картинка неотчетлива и неполна, нужно одновременно собирать много паззлов, использовать фрагменты от других паззлов, создавать новые фрагменты, оптимизировать число фрагментов, преобразовать некоторые паззлы, использовать фрагменты без четких границ, обходиться просто универсальными фрагментами (как продукция LEGO) и т.д. Это очень интересно!

Процедура моделирования имеет четыре основные фазы, как показано на рис. 4 (автор использует собственный стиль [13] для BPMN).

Рис. 4 Четыре основные фазы процедуры моделирования

Обычно процедура моделирования применяется к новому функциональному блоку. Первая фаза процедуры моделирования (то есть blackboxing) является точкой решения: должен ли этот функциональной блок быть детализирован далее или следует его рассматривать как неделимый?

Если решение состоит в том, чтобы продолжить детализацию, то начинается анализ (фаза structuring) данного функционального блока, чтобы найти его внутреннюю «грубую» структуру. Далее (то есть в фазе re-construction) эта структура уточняется полным определением координации между более мелкими функциональными блоками (а это уже исполняемый бизнес-процесс!). Наконец (то есть в фазе instrumentation), скелет процесса обогащается путем добавления автоматических служб, чтобы сделать модель более функциональной.

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

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

7. Заключение

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

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

Библиография

[1] Samarin, A.: ISO: integrating the WEB and document management, presentation at Documation conference, Paris, France, 2001.

[2] Samarin, A.: Agile SOA Framework For Process Automation And Integration, www.ebizq.net, 2004.

[3] Samarin, A.: From agile development to agile evolution of enterprise systems, presentation at EuroPython Conference, Geneva, Switzerland, 2006.

[4] Samarin, A.: Three pillars of a practical architectural framework: BPM, SOA and ECM, presentation at the Open Group’s enterprise architecture practitioners conference, Lisbon, Portugal, 2006.

[5] Samarin, A.: Architecting enterprise BPM systems for optimal agility presentation at “Architecture and Process” conference www.architecture08.com, April 2008, Washington DC, USA.

[6] Samarin, A.: How to simplify the evolution of business process lifecycles In conjunction with CAiSE’08. The 9th Workshop on Business Process Modelling, Development, and Support BPMDS'08 Business Process Life-Cycle: Design, Deployment, Operation & Evaluation. 16-17 June 2008, Montpellier, France.

[7] Samarin, A.: Architecting enterprise BPM systems for optimal agility a keynote presentation at the "Architecture World 08", 18-19 June 2008, Bangalore, India.

[8] Samarin, A.: Towards executable models within BPM a track presentation at the "Architecture World 08" 18-19 June 2008, Bangalore, India.

[9] Regev, G., Wegmann, A.: A Regulation-Based View on Business Process and Supporting System Flexibility, Proceedings of the CAiSE’05 Workshop, p. 91-98.

[10] http://www.deming.org/www.deming.org<//a>

[11] OASIS (www.oasis-open.org) standard: Web Services Business Process Execution Language, 2007.

[12] OMG (www.omg.org) specification: Business Process Modelling Notation, 2008

[13] Samarin, A.: Practical Industrialisation of Information Technology (for alignment of business and IT), course lecture EPFL, Lausanne, 2007.

Комментарии