Это сообщение меня побудил написать более глубокий разбор стандарта Case Management Model and Notation и презентация с прошлогоднего PegaWORLD 2013, которая так и называется Stage-based Case Management.
Я все больше склоняюсь к суждению, что уже привычные нам рассуждения приверженцев адаптивного управления кейсами о непредсказуемых процессах могут многих ввести в заблуждение. Четыре года назад я обратил внимание на adaptive case management не потому, что он позволял работать с волшебными unpredictable процессами. Просто, традиционные BPMS системы не могли удовлетворить наши потребности. Мы потратили много времени на то, чтоб повыбирать решения этого класса. Сделали пару пилотных проектов, но не получили желаемого результата. И дело здесь не в том, что нам требовались средства, автоматизирующие преимущественно совершаемые людьми операции. Скорее наоборот. Основная деятельность была и так автоматизирована в полном объеме. Поэтому внимание было сосредоточено не на процессах предоставления сервиса, они и так работали, а на процессах продажи, обслуживания и поддержки. И вот эти, ориентированные на клиента, процессы и не ложились в рамки стандартного BPMS.
Но это совсем не значит, что такие процессы непредсказуемы. Просто изначально они описывались другими моделями. Возьмите процесс продаж. Существует множество материалов о том, как правильно продавать, что такое воронка продаж, на каком этапе кто и что должен делать. Просто этот процесс обычно не рисуется в виде блок-схемы. Но он содержит вполне внятные этапы. Аналогичным образом выстроена модель работы с дебиторской задолженностью. Процедура collection состоит из этапов или stages. Уровни поддержки в ИТ, работа с обращениями клиентов, стадии любого проекта – все это примеры таких процессов. В последнее время такие процессы принято визуализировать на Kanban board (см. ниже рисунок из Stage-Gate New Product Development)
Общими для таких процессов является наличие определенных этапов, по которым проходит кейс. Внутри этапа задачи могут быть разные, но результат этапа четко определен. На прошлогодней конференции Pega показала пользовательский интерфейс для дизайна процессов такого типа и высказала предположение, что он позволит отказаться от промежуточных документов и активностей при разработке процессов (Не знаю, случится ли это, но аналитикам бизнес-процессов стоит подумать о замене своих традиционных блокнотов набором стикеров)
Примерно такая же модель прослеживается в стандарте CMMN. Ключевыми объектами кейса являются вехи, на достижение которых и направлены реализуемые в рамках кейса активности. Что удивительно, если вы посмотрите как пишут инструкции и процедуры обычные люди в организациях, то увидите в их текстах тоже самое: этапы, а рамках которых могут делаться некоторые активности.
Одним словом, думаю что не стоит пугать конечных пользователей и бизнес-аналитиков разговорами о непредсказуемых бизнес-процессах. Лучше уделить внимание стандартизации и упрощению описаний реальных дел, в которых организации хотели бы навести порядок. Не надо магии и философских рассуждений, нужны инструменты, упрощающие текущую работу людей.