[18.03.2015]
В конце 2013 года я был участником дискуссии , где приводил свои доводы в защиту BPM-систем для задач автоматического управления большими пакетами объектов процессов. В частности, в той дискуссии я рассказывал о построении BPM-системы для автоматизированного сбора долгов населения за поставленную электроэнергию. Проект, о котором шла речь, был выполнен для краевой энергосбытовой компании. За прошедший год идея процессного управления сбором долгов получила значительное развитие, что в итоге привело к серьезным изменениям, прежде всего в моей судьбе.
Процессная автоматизация так меня увлекла, что я открыл свою компанию, занимающуюся разработкой и внедрением своих процессных решений. В компании единомышленников мы на базе среды разработки «1С:Предприятие 8.3» создали собственную процессную платформу, которую назвали «АВЕС». В платформе, наряду с классической BPM-подсистемой, предназначенной для управления «совокупностями взаимосвязанных мероприятий или задач, направленных на создание определённого продукта или услуги для потребителей» (определение понятия «бизнес-процесс» из Википедии), мы реализовали и принципиально новый подход к построению процессных систем, который назвали MPM (Multi-process management) .
Дело в том, что масштабируя проект процессной автоматизации сбора долгов в краевой энергосбытовой компании в новые регионы (более миллиона объектов в управлении), а также «взяв в клиенты» крупное российское коллекторское агентство (полмиллиона дел), мы все-таки столкнулись с некоторыми принципиальными ограничениями BPMS при реализации задачи пакетного управления такими объемами.
Основные проблемы:
Индивидуальность бизнес-процесса
BPM-система все-таки работает «от конкретного процесса» (по крайней мере, как это реализовано фирмой «1С» в платформе «1С:Предприятие 8»). Это означает, что если с процессом что-то происходит (например, выполнена задача с определенным результатом), то процессный движок перехватывает это событие, «поднимает» из базы данные конкретного экземпляра бизнес-процесса, анализирует их и принимает решение о назначении следующих задач в соответствии с картой маршрута. Когда такая логика работает в системе документооборота или CRM (а это, на мой взгляд, самая распространенная практика применения BPM-систем на сегодняшний день) такое поведение системы является логичным и единственно возможным. Но что происходит, если некое однотипное событие происходит одномоментно в нескольких сотнях тысяч бизнес-процессов? Процессный движок в цикле начинает последовательно «поднимать» данные каждого процесса из базы, анализировать, принимать решение. Несколько сотен тысяч транзакций на чтение, столько же выполнений алгоритма анализа, столько же транзакций на запись новых назначенных задач. В результате такая последовательная обработка каждого бизнес-процесса катастрофически сказывается на производительности системы в пиковые моменты времени.
Необязательные задачи
В электроэнергетике иногда бизнес-процессы сбора долгов натыкаются на необходимость участия человека в выполнении какой-либо задачи (например, уточнение некорректной контактной информации или личный телефонный звонок). Понятное дело, что количество таких задач, свалившихся на оператора, в десятки и сотни раз может превышать его пропускную способность. В таких случаях часто принимается алгоритм: «отсортировать задачи по важности и выполнить за ограниченное время самые важные, сколько получится». В результате, после истечения отведенного времени, в системе каждый раз остается множество неактуальных задач, которые никогда не будут выполнены, и множество «зависших» бизнес-процессов, по которым не будет никаких действий. Это приводит к накоплению больших объемов мусора в базе данных и также снижает производительность из-за необоснованного роста размера этой базы.
Откат назад
К сожалению, такая необходимость возникает нередко. Оператор пакетом «подготовил претензии» для нескольких сотен лиц и «продвинул» все бизнес-процессы дальше, где они распараллелились на несколько нитей утверждений, согласований, оплат доставки и т.д. Потом выясняется, что весь пакет претензий сделан неправильно. При этом бизнес-процессы в этом пакете уже разлетелись кто куда, каждый в каких-то следующих состояниях. Надо все процессы вернуть в исходное состояние, но при этом ряд мероприятий отменить уже нельзя (оплата доставки), но их нужно будет учесть при повторном, правильном запуске бизнес- процессов. Интересная задачка? Сколько времени было потеряно на таких «зачистках базы данных» средствами BPM «в обратном направлении», не передать словами.
Сторонние регламенты
Практически для любого бизнес-процесса нужно автоматически не только отслеживать «совокупность взаимосвязанных мероприятий или задач», заложенных в карту маршрута, что берет на себя процессное ядро BPM-системы, но также и контролировать ряд внешних по отношению к процессу регламентных параметров. Так, например, какая бы ни была логика работы бизнес-процесса «Судебное заседание», но требуется контролировать срок давности дела, и если он будет превышен – основной процесс нужно завершить с отменой всех запланированных мероприятий из-за потери их дальнейшей актуальности. Также потребуется прекратить выполнять и все вложенные процедуры обжалования с отменой запланированных по ним мероприятий.
Последний фактор, как несложно заметить, не является именно ограничением в BPM-системах, такая задача силами BPM не решается. Сам по себе он говорит лишь о необходимости иметь некую отдельную, надзорную над бизнес-процессами, систему регламентного контроля. Причем приоритет в решениях этой надзорной экспертной системы должен быть выше приоритета задач, которые генерирует BPM. В результате для этих целей мы разработали экспертную аналитическую систему, которая в одном обращении к базе данных для всех, попадающих под анализ объектов, проводит оценку и, в случае необходимости, присваивает каждому объекту соответствие той или иной категории. Каждое правило анализа мы назвали «экспертизой» и сделали графический редактор видов экспертиз, работающий по схожим с BPM-движком алгоритму.
Через какое-то время, в процессе совершенствования экспертной аналитической системы, пришла в голову идея, которая в результате и привела к созданию нашей компанией нового класса процессного программного обеспечения. Идея заключалась в том, чтобы научить экспертную систему оценивать не только параметры объектов в работе, но также анализировать результаты последнего выполненного мероприятия каждого типа для каждого объекта, в одной транзакции, для всего пакета объектов сразу. В результате такого анализа, в зависимости от того, какие мероприятия были выполнены для конкретного объекта и их результатов, экспертная система стала выдавать предписания на будущее, что по её мнению, с объектом следует делать дальше, исходя из логики карты экспертизы. Принципиальнейший момент в том, что экспертная система, в отличие от BPM-подхода, не создает новые запланированные задачи в виде записей таблиц данных, она только создает предписания! Новая задача для исполнителя создается лишь в момент выполнения предписания, когда из статуса «запланировано» мероприятие переходит в статус «выполнено» с каким-то конкретным результатом.
Получившемуся в результате новому процессному подходу, который работает «от пакета объектов», а не «от конкретного процесса», мы дали название Multi-process management, сокращенно MPM. Причем MPM-подход практически полностью перекрывает возможности BPM-систем, гораздо гибче в управлении, характеризуется максимальной производительностью в части скорости чтения-записи информации в базе данных, принципиально лишен недостатка «необязательных задач», не имеет никаких проблем при откатах к предыдущим этапам, а также обладает множеством других полезных функций. Так, например, легко учесть в логике управления объектом процесса задачи, созданные на стороне, а не только сгенерированные бизнес-процессом. Экспертная система всегда «видит» целостную картину событий, произошедших с управляемым объектом, независимо от того, кем конкретное событие было инициировано.
На базе экспертно-процессной платформы «АВЕС» нами создана серия программных продуктов «Управление взысканием», где сочетание новых принципов процессного управления с классическим BPM-подходом позволяет осуществлять пакетное управление обязательствами компании от предупреждения возникновения задолженности до истребования ее в порядке судебного и исполнительного производства с минимальным участием персонала и максимальной автоматизацией.
Надеюсь, что наши новые методы процессного управления позволят открыть новые горизонты в применении такого рода автоматизированных систем.