 |
Управление бизнес-процессами является инструментом реализации бизнес-стратегии и уже стало важным составным элементом конкурентного преимущества предприятий [1].
В настоящее время существуют две взаимно дополняющие друг друга парадигмы управления бизнес-процессами:
- в центре одной из них находится процесс, ориентированный на предопределенную многократно повторяющуюся последовательность действий; для ее формального описания разработан стандарт BPMS;
- в центре второй парадигмы находятся данные о процессе, основанные на концепции Case Management (управление последовательностью операций на основе состояния систем, в которых выполняются эти операции); для ее формального описания разработан стандарт CMMN.
В первой парадигме жесткий алгоритм предписывает, в какой последовательности должны выполняться действия бизнес-процесса с обязательным описанием всех вариантов. Во второй декларативно описывается, что должен выполнить бизнес-процесс, а последовательность действий определяется в ходе его выполнения и зависит от информационного контекста процесса.
Программные системы, реализующие первую парадигму (BPMS — Business Process Management System), неплохо работают в сферах, в которых действуют жесткие регламенты по типу конвейера: все действия заранее предопределены и минимально зависят от изменений в окружающей среде. Наибольшее распространение эти системы получили в банковской сфере. Программные системы, реализующие вторую парадигму (Case Management), ориентированы на поддержание гибких бизнес-процессов за счет декларативного подхода к их описанию. Этот подход актуален фактически для всех видов бизнеса, где нет жестких неизменных предопределенных регламентами бизнес-процессов. К данной области можно отнести прежде всего позаказное производство, например строительство или изготовление мебели, страховой бизнес, медицину и право.
На практике при реализации второй парадигмы (парадигмы Adaptive Case Management — ACM) возникает потребность в своеобразном «навигаторе», который в каждом конкретном состоянии мог бы подсказывать шаги для достижения поставленной цели. Об этой потребности прямо указывается в работе [2]. Базовую основу для построения такого навигатора должен обеспечить системный взгляд на бизнес, в котором стратегические цели, инструменты их достижения, процессы и данные были бы представлены в единой модели во взаимосвязи.
Предлагаемый подход
В основе предлагаемого подхода лежит построение комплексной поведенческой модели предприятия, рассматриваемого как сложная система (в математическом смысле). Функционирование бизнес-системы представляет собой движение в ее пространстве состояний, направленное на достижение поставленных целей. Изменение состояний бизнес-системы осуществляется в результате выполнения ее сервисов (функций). Состояние бизнес-системы определяется состоянием ее ресурсов, а также выполняемых, выполненных и запланированных к выполнению бизнес-процессов. Бизнес-процесс обеспечивает реализацию одного из сервисов бизнес-системы. В предлагаемом подходе он рассматривается как цепочка переходов бизнес-системы из одного состояния в другое в результате скоординированного взаимодействия ее подразделений в рамках реализации соответствующих сервисов по созданию информационных и материальных ресурсов и обмену ими. Сервис бизнес-системы предлагается определять как ее возможную реакцию на попадание в соответствующее состояние. Окончательное решение о выполнении сервиса принимается сотрудником с соответствующими полномочиями. Представление о функционировании бизнес-системы как о движении в своем пространстве состояний открывает возможность применения экспертных систем (при условии соответствующей формализации пространства состояний и бизнес-процессов) для определения предпочтительных реакций бизнес-системы на попадание в то или иное состояние.
В качестве основы формализации бизнес-процесса в предлагаемом подходе используется нотация IDEF0. Каждый переход бизнес-системы между состояниями осуществляется одним или несколькими ее подразделениями, реализующими IDEF0-функцию (далее именуемую сервисом).
Рис. 1. Метамодель сервиса
Переход между состояниями осуществляется в рамках ограничений, накладываемых на время, используемые и расходуемые ресурсы, свойства (качества) выходного результата. Совокупность ограничений определяет цель перехода. На рис. 1 приведено формализованное представление сервиса, включающее в себя входные ресурсы {Xi} (материалы, комплектующие, документы), выходные ресурсы {Yj} (продукцию, документы), цели {Gk}, используемые ресурсы {Mu} (персонал, оборудование, инструмент). Выполнение сервиса начинается в состоянии Si (аналог Guards [3]) и завершается в состоянии Ss (аналог Milestones [3]), соответствующем успешному завершению выполнения сервиса, или в состоянии Sa, соответствующем аварийному завершению сервиса. Например, если рассмотреть сервис позаказной поставки продукции, то Si может быть определено как получение заказа, содержащего перечень продукции к поставке, и получение предоплаты; Ss — как отгрузка продукции в соответствии со спецификацией заказа и получение отгрузочных документов, подписанных заказчиком; Sa — как состояние, в котором произошло нарушение условий оплаты заказа или условий отгрузки. В метамодели сервиса также предусмотрено состояние Sp, соответствующее такому состоянию бизнес-системы, в котором уже начавший выполняться сервис не может продолжить свое выполнение из-за состояния ресурсов {Xi}, {Yj}, {Mu}. В качестве примера Sp можно привести такое состояние бизнес-системы, когда в ней закончились ресурсы, необходимые для завершения выполнения сервиса, или такое, при котором начавшаяся отгрузка продукции не может быть продолжена в связи с задержкой оплаты, превышающей установленные лимиты. Состояния Si, Ss, Sa совместно с набором целей {Gk} образуют фрагмент траектории бизнес-системы в ее пространстве состояний.
Для построения формального описания семантики ресурсов, целей и пространства состояний бизнес-системы в предлагаемом подходе в качестве базовой используется нотация IDEF1x. Её основными элементами являются сущность и отношение. Семантика сущности определяется набором отношений с другими сущностями. Если мы наложим ограничения на отношения сущности путем определения некоторого логического высказывания относительно значений этих отношений, то получим определение некоторого множества экземпляров этой сущности — класса. Например, заказ на поставку продукции — сущность, заказ на поставку продукции с определенным графиком ее производства — класс спланированных заказов. Классы могут использоваться в качестве операндов операций над множествами: объединение, пересечение, разность, декартово произведение. Каждый ресурс сервиса может быть представлен в виде сущности или класса. Свойства ресурса определяются отношениями соответствующей сущности или класса и могут при этом устанавливаться или вычисляться. Например, заказ на поставку продукции имеет номер (устанавливаемое свойство) и валовую прибыль, являющуюся суммой валовой прибыли по каждому пункту заказа (вычисляемое свойство).
Рис. 2. Фрагмент информационной модели заказа
Рассмотрим фрагмент информационной модели заказа. Заказ (Order) имеет отношение со спецификацией (Specification). Спецификация состоит из пунктов (SpecificationItem), которые имеют отношения со спецификацией материалов (MaterialsSpecification), перечнем операций (OperationList) и единицами измерения (Unit). Спецификация материалов в свою очередь также состоит из пунктов (MaterialSpecificationItem), у которых есть атрибуты «количество» и «цена» (qty, price). Аналогично перечень операций состоит из операций (Operation), у которых есть атрибуты «трудозатраты» и «стоимость» (effort, cost). Если рассматривать обращение к свойству как вызов функции: contents (S) = S.contents, где S — спецификация, а contents — свойство, определяющее ее состав, то можно построить функцию расчета валовой прибыли спецификации на основе свойств связанных со спецификацией сущностей в виде дерева (см. рис. 2), которое может быть представлено в виде лямбда-выражения.
Рис. 3. Пример вычисляемого свойства спецификации (MarginalProfit)
Типы вычисляемых свойств не ограничиваются простыми типами (числами, датами и строками). Например, пусть заказчик X настаивает (рис. 4) на специальной процедуре подготовки сертификатов на готовую продукцию. Мы можем добавить вычисляемое свойство productcustomer (ЗаказчикПродукции) к сущности Product (Изделие), которое определит экземпляр сущности Customer (Заказчик) для каждого экземпляра сущности Product (Изделие) путем последовательного «прохождения» по свойствам: orderitem, contents, orderspecification, ordercustomer.
Рис. 4. Вычисляемые свойства непростых типов
Тогда при подготовке сертификата свойство productcustomer может быть использовано при выборе процесса подготовки сертификата. «Последовательное прохождение по свойствам» может быть формально представлено в виде продукционного правила.
Сущность, отношение и класс образуют основу информационной метамодели бизнес-системы. Формат данной статьи не позволяет включить ее графическое представление в полном объеме. (Метамодель доступна по адресу). Информационная метамодель бизнес-системы построена с использованием логики предикатов первого порядка. Выбор этого математического аппарата обусловлен следующими причинами: а) необходимость единого языка описания сложных систем, (б) необходимость определения логических выражений и проверки отношения следования между ними, (в) необходимость обеспечения формальной проверки непротиворечивости модели бизнес-системы, (г) простота модификации модели в ходе выполнения бизнес-процессов, (д) простота интеграции с корпоративными информационными системами.
Таким образом, информационная модель сервиса, построенная на основе предложенной метамодели, представляет собой семантическую сеть, состоящую из набора фактов (экземпляров отношений), продукционных правил и лямбда-выражений.
Построенную модель бизнес-процесса реализации сервиса (включающую в себя информационную модель) предлагается использовать в качестве базы знаний прототипа экспертной системы. Поскольку цели, ресурсы и состояния в соответствии с предлагаемым подходом описываются в виде фактов и продукционных правил, то возникает возможность построения алгоритма, который, анализируя текущее состояние бизнес-системы, будет определять актуальность того или иного сервиса. При наличии логического следования между текущим состоянием и условием запуска сервиса алгоритм может выводить пользователю описания текущего состояния бизнес-системы, соответствующий сервис и описание его начального состояния с предложением запустить этот сервис в качестве реакции на текущее состояние. При этом количество реакций на одно и то же состояние бизнес-системы ограничено лишь количеством описанных сервисов. Проверка выполнения логического условия может осуществляться любым интерпретатором языка Prolog, допускающим интеграцию с корпоративной БД (либо напрямую, либо через конвертер). При реализации предлагаемого подхода использовался собственный интепретатор, построенный с помощью универсального транслятора языков ANTLWorks, транслирующего высказывание на языке Prolog в SQL-сценарий.
Еще раз подчеркнем, что мы описали подход к реализации управления бизнес-процессами на основе ACM-парадигмы. Он основан на построении и исполнении комплексной поведенческой модели предприятия как движения сложной системы в пространстве состояний. Подход позволил построить прототип экспертной системы, способной определять предпочтительную реакцию бизнес-системы на текущее состояние. Этот прототип используется в качестве своеобразного навигатора, подсказывающего конечному пользователю действия, которые ему следует предпринять в текущей ситуации.
Сервис «под микроскопом»
Сервис (рис. 1) реализуется в виде бизнес-процесса, состоящего из двух взаимодействующих подпроцессов: процесса управления и процесса реализации. Процесс управления формирует плановую траекторию движения бизнес-системы в виде набора целей, назначенных сервисам {Gk}, и обеспечивает соответствие фактической траектории движения плановой. Процесс реализации обеспечивает переход бизнес-системы из состояния Si в состояние Ss в соответствии с целями {Gk} путем выработки выходных ресурсов {Yj} из входных ресурсов {Xi} с использованием ресурсов {Mu}. В соответствии с принципами IDEF0 каждый из этих процессов может быть представлен в виде графа сервисов, выполняемых подразделениями бизнес-системы, которые взаимодействуют друг с другом путем обмена ресурсами. Поэтому переход из состояния Si в состояние Ss может быть определен как граф переходов, образующих траекторию движения бизнес-системы в своем пространстве состояний. Для определения сервисов, реализующих эти переходы, и взаимосвязей между ними в предлагаемом подходе каждая из целей Gk рассматриваемого сервиса декомпозируется на совокупность подцелей {Gki}. Gk достигается только тогда, когда достигнуты все цели Gki, на которые она разбита. Более того, каждая Gki должна быть определена таким образом, чтобы ей соответствовала Gm одного из сервисов подразделений, входящих в бизнес-систему, реализующую рассматриваемый сервис. Предлагаемая декомпозиция целей позволяет избежать конфликта интересов, неизбежно возникающего в сквозных бизнес-процессах в функционально-ориентированных оргструктурах. Более того, иерархическая структура целей обеспечивает «точки контроля» на каждом уровне управления. Отображение подцелей на сервисы, реализуемые подразделениями бизнес-системы, обеспечивает формальную основу определения зоны ответственности для каждого руководителя подразделения.
|
Пример
Рассмотрим пример формализованного бизнес-процесса, реализующего производство и поставку продукции (далее — сервис поставки). Будем считать, что сервис поставки обеспечивает переход бизнес-системы из состояния Si (получен заказ на поставку) через множество промежуточных состояний, включающих: Ss (I.1) (материалы были заказаны), Ss (I.2) (транспорт был заказан), Si (I.3) (материалы были получены), Ss (I.4) (изделия были произведены), Ss (I.5) (изделия были отгружены) и т.д. Последовательность переходов между состояниями заранее не определена (и не может быть определена). Например, заказ материалов может никогда не произойти, если поменялась конфигурация изделий и необходимые материалы оказались в наличии на складе. Заказ транспорта может никогда не произойти, если заказчик примет решение об использовании собственного транспорта. Последовательность выполнения сервисов также не определена. Например, если некоторое количество необходимых материалов имеется в наличии на складе, то производство может начаться до поступления материалов, которые будут заказаны при выполнении соответствующего сервиса (чтобы исключить простои). Подобным образом если на складе имеется в наличии некоторое количество заказанной продукции, отгрузка может начаться, не дожидаясь выполнения сервиса производства. Сами сервисы реализуются следующими подразделениями бизнес-системы: отделом закупок, цехом, складом. Чтобы определить траекторию движения бизнес-системы, описания ее состояний должны быть дополнены описаниями целей. На рис. 3 у сервиса поставки определены две цели: G (1, i) — валовая прибыль по заказу i и [G (2, i, j)] — время поставки изделия j по заказу i. Цель G (1, i) декомпозируется на следующие подцели: [G (1, i, M, j)] — предельно допустимая стоимость материалов в изделии j по заказу i, G (1, i, O, j) — предельно допустимые трудозатраты в изделии j по заказу i.
Цель G (2, i, j) декомпозируется на следующие подцели: [G (2, i, u)] — установленные сроки поставки материала для изделий заказа i; [G (2, i, v)] — установленные сроки предоставления транспорта; [G (2, i, j, t)] — установленные сроки производства и т.д. Процесс управления состоит из стандартных функций управления (сервисов управления): планирование, учет, анализ, мониторинг и регулирование в контексте рассматриваемого сервиса (цикл Деминга). Общие ресурсы и выполнение различных экземпляров бизнес-процесса одними и теми же подразделениями бизнес-системы требуют единого процесса управления выполнением всех экземпляров реализации рассматриваемого сервиса.
Процедура определения сервиса и его управляемой реализации может быть повторена для каждого сервиса, входящего в декомпозицию рассматриваемого, за исключением сервисов, выполняемых одним сотрудником на одном рабочем месте (терминальные сервисы). Терминальные сервисы соответствуют элементарным операциям по созданию и модификации материальных и информационных объектов. Терминальные сервисы, создающие и модифицирующие материальные объекты, реализуются учетными системами, которые регистрируют выполнение соответствующих элементарных операций. Терминальные сервисы, создающие и модифицирующие информационные объекты, реализуются специализированным программным обеспечением (CAD/CAM, PDM, системы документооборота, системы календарного планирования и т.д.). Реализация терминальных сервисов требует интеграции существующего или разработки нового ПО на основе информационной модели сервиса, определяющего все ресурсы, цели и состояния бизнес-системы, относящиеся к сервису.
|
Литература
- Bhattacharya K., Hull R., Su J. A Data-centric Design Methodology for Business Processes // Handbook of Research on Business Process Management: Information Science Publishing, an imprint of IGI Global. Hershey, PA, USA, 2009.
- Bider Ilia, Perjons Erik, Elias Mturi. Untangling the Dynamic Structure of an Enterprise by Applying a Fractal Approach to Business Processes // Proc. of PoEM, 2012.
- Hull R., Damaggio E., De Masellis R. e. a. Business Artifacts with Guard-Stage-Milestone Lifecycles: Managing Artifact Interactions with Conditions and Events // Proc. ACM Intl. Conf. Distributed Event-Based Systems (DEBS), 2011.
Об авторе:
Вадим Кузин, заместитель генерального директора по ИТ компании «Мосфлоулайн»
|
|
