Оригинал блога: http://mainthing.ru/ru/item/401/

В 2010 году Adaptive Case Management был одной из самых обсуждаемых тем в области BPM. В итоге за прошедший год из мутноватого маркетингового шума он превратился в более-менее цельную концепцию.

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

Позитив концепции ACM

Она распространяет идеи процессного управления на области, которые до сих пор поддавались ему с трудом - на процессы а) быстро меняющиеся и б) принципиально непредсказуемые.

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

В результате осознания этих проблем появился BPM в его сегодняшнем понимании - как дисциплина, сочетающая управление на основе процессов и управление самими процессами, т.е. их исполнение, анализ и оптимизацию в непрерывном цикле. Непосредственно исполняемые процессные диаграммы улучшили взаимопонимание между бизнесом и ИТ, что дало возможность разбираться со сложными процессами, а быстрое прототипирование в BPMS и выполнение проектов в духе agile позволяет оперативно вносить изменения в бизнес-процессы.

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

Но как быть, если этого недостаточно - если изменения в процесс необходимо вносить еще быстрее? Или, что более вероятно, если сложность задачи такова, что мы раз за разом сталкиваемся с тем, что упустили из виду какой-то переход или задачу?

Наконец (главный аргумент в пользу ACM), как быть, если процесс принципиально непредсказуем? Примеры: дело в суде, история болезни пациента, обращение пользователя в техподдержку. Вы не можете спланировать свои действия, поскольку завтрашний день принесет новые действия, предпринятые противной стороной на судебном заседании, и новые анализы пациента. Это даже трудно назвать процессом, поскольку процесс предполагает повторяемость, а у этих “процессов” нет двух идентичных экземпляров, поэтому их называют кейсами.

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

Или мероприятие по продвижению, которое проводит отдел маркетинга: как бы по шаблону, но со своими особенностями у каждого. Или разработка нового продукта… вообще, таких проектов-процессов в жизни любой компании множество.

Что делать с непредсказуемыми процессами

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

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

Иванов Иван Иванович

Решаю проблемы.

Это люди натренированные на решении проблем, умеющие это делать и получающие за это зарплату.

Как пытались решать проблему изменчивых и непредсказуемых процессов до сих пор:

1.   В лоб: редактированием схемы процесса «на лету» бизнес-пользователями.

Например, Interstage BPM от Fujitsu позволяет прямо в браузере отредактировать схему данного конкретного экземпляра процесса. И мало того - потом вы можете превратить эту схему в новую версию шаблона процесса. Но как выяснилось, это оказалось слишком сложно, пользователи просто не стали этим пользоваться. Кит Свенсон по этому поводу замечает: «Внести изменение в процесс должно быть не сложнее, чем отправить электронную почту. Потому что иначе сотрудник именно ей и воспользуется».

2.   Методом игнорирования: существует масса программ, которые облегчают работу пользователей в таких процессах, но они не оперируют понятием процесса.

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

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

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

Деление на бизнес-аналитиков и бизнес-пользователей упраздняется: предполагается, что сами пользователи будут создавать шаблоны и помещать их в библиотеки, делая доступными для других.

Все бы хорошо, но у меня есть ряд сомнений в верности предлагаемого пути.

Сомнение 1: Технология вместо методологии?

Адепты ACM (возможно не все, а только самые радикальные), похоже, искренне верят, что все, чего не хватает организациям, чтобы стать более эффективными - это более совершенная технология: BPMS устарел, ACM всех спасет.

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

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

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

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

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

Возвращаясь к ACM: складывается впечатление, что вместе с процессными диаграммами на свалку выкидывается процессная методология. Больше не нужны навыки процессного анализа, не нужны их носители - бизнес-аналитики. Зачем? «Умные работники» (knowledge workers) настолько умны, что сами лучше всех знают как лучше делать дело.

Возможно. Только для кого лучше - для компании или для них самих?

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

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

В последнем интервью аналитикам Гартнер процессный гуру Гэри Раммлер критиковал BPM за невнимание к бизнес-контексту:

«Я думаю, есть только одно непременное условие успеха - наличие критической бизнес-проблемы (CBI, critical business issue) в клиентской организации. Если CBI отсутствует (во что трудно поверить) или руководство пребывает в глухом отказе от признания его существования, тогда, будем откровенны, BPM не приведет к трансформации бизнеса. Точка. Могут быть ни к чему не приводящие «демонстрации» и «тестирования концепций», но ничего существенного не произойдет. Да и как оно может произойти? Серьезный BPM стоит денег, отнимает время и может перевернуть множество горшков, поэтому вы не можете им заниматься без достойного бизнес-обоснования. Вы можете возразить, что второе условие - или фактор - тот, кто занимается BPM внутри организации, должен быть на 70% человеком, разбирающимся в бизнесе, и на 30% BPM-экспертом. Потому что ключ к успеху заключается в том, чтобы найти CBI, понять как BPM может с ним справиться, и убедить высшее руководство сделать инвестиции. Полагаю, есть два условия: возможность и кто-то, кто способен этой возможностью воспользоваться.»

Боюсь, пренебрежение к процессной методологии в ACM может привести к игнорированию этой технологии бизнесом.

Сомнение 2: Избавиться от программистов?

С точки зрения ACM, надо обходиться не только без бизнес-аналитиков, но и без программистов.

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

Снизить - да, но полностью избавиться?

Представляется, что просто заменить схему процесса в BPMS на список задач в ACM для этого недостаточно, ведь останутся:

1.   Процессная архитектура.

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

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

2.   Архитектура данных.

Проповедники ACM подчеркивают особую важность данных кейса. Утверждается, что в случае BPMS первичен процесс, а данные вторичны, а в случае ACM - наоборот.

Я с этим не согласен, на мой взгляд, процесс - это единство схемы, структурированных данных (процессная таблица в БД) и неструктурированных документов (процессная папка в ECM-системе), где все составляющие одинаково важны.

Но пусть будет так. Исходя из этого, они рекомендуют, прежде всего, определиться с номенклатурой и структурой сущностей в вашей задаче. Но простите - кто будет это делать, бизнес-пользователи?

Снова: не верю! Анализ и проектирование структур данных было и остается уделом профессионалов. Хотите отдать его любителям - получите не базу данных, а базар данных, аналогичный тому, который сейчас они создают с помощью Excel.

3.   Интеграция с корпоративными системами.

Ну, с тем, что для этого понадобятся профессионалы, кажется, все согласны.

Что же получается в итоге? Опять бюрократия, на этот раз ИТ-бюрократия. Зло, но неизбежное, потому что хаос еще хуже.

Сомнение 3: Две процессные системы?

Вопрос: сколько нам нужно процессных систем: две (BPMS и ACM) или одна? И если одна, то из чего ее строить: развивать ACM-функциональность в BPMS или пытаться решать все задачи при помощи ACM?

Сторонники ACM (по крайней мере, некоторые) позиционируют ее как отдельную систему - они не желают иметь ничего общего с технологиями BPMS.

Их аргумент: BPMS пытается «запрограммировать» бизнес, но это невозможно в принципе, когда мы имеем дело с непредсказуемыми процессами, траектория которых определяется только в ходе их исполнения. Поэтому BPMS не годится, нужна другая система - ACM.

Что-то это мне напоминает… рекламу нового телевизора! «Посмотрите, какие краски, посмотрите какое живое изображение! Разве вы видели что-то подобное на вашем старом телевизоре?!»” Да, действительно, не видел… стоп! разве я смотрю эту рекламу, вижу эти хваленые краски и живое изображение не на своем старом телеке?

Так и тут: конечно, непредсказуемые процессы нельзя запрограммировать при помощи тупого линейного workflow. ACM предлагает более изощренный способ программирования, но все же это тоже программирование. И кто сказал, что BPMS способны моделировать и исполнять только тупой worflow?

BPM позволяет моделировать очень многое, гораздо больше, чем линейные потоки работ. Как пишет Скот Фрэнсис -

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

Например, в BPMN можно смоделировать конечный автомат, который считается наиболее адекватным представлением для кейса. А еще в нем есть ad-hoc подпроцессы, которые позволяют пользователю выбирать, какие из задач следует запускать в данном экземпляре процесса. Комбинация конечного автомата и ad-hoc подпроцессов на переходах между состояниями дает уже нечто очень похожее на кейс.

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

Чего существующим BPMS не хватает, так это возможности одним кликом (помним: это должно быть не сложнее, чем отправить электронную почту) добавить в ad-hoc подпроцесс новую задачу. Ну, так это ведь при желании достаточно легко реализовать! Наверное, не сложнее, чем, например, компенсации транзакций в BPMN.

А еще в BPMS есть функциональность под названием «делегирование» и «заметки» - они тоже позволяют сделать процесс не столь жестким.

Некоторые сторонники ACM считают, что существующие BPMS с их моделями процессов отжили - мол, если мы научимся управляться непредсказуемыми процессами, то с обычными справимся тем более. Но большинство, кажется, признает, что нужно и то, и другое: управление и предсказуемыми, и непредсказуемыми процессами.

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

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

Какие бонусы можно было бы извлечь из BPMS с функциональностью ACM?

Бонус 1: BPM на всех стадиях жизненного цикла организации

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

BPMS с ACM-функциональностью была бы отличным решением этой проблемы: небольшая компания или стартап вначале могут работать с кейсами, а затем, по мере роста, усложнения структуры компании, появления в ней клерков, компания сможет органично трансформировать накопленные шаблоны кейсов в формально определенные процессные диаграммы, при желании оставив в процессе элементы непредсказуемости.

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

Бонус 2: Искусственный интеллект

Я не верю, что бизнес-пользователи захотят и смогут организовать библиотеки шаблонов кейсов. Думаю, получится нечто подобное на свалку файлов Excel. А многие ли пользуются шаблонами Microsoft Word? Ведь полезная вещь, а что толку?

Поэтому более перспективным мне представляется встраивание в систему элементов искусственного интеллекта.

Начать можно с простейшей вещи вроде того, как интернет-магазин вам сообщает «вместе с этой книгой покупают также…».

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

Таким образом, вся совокупность кейсов определенного типа будет рассматриваться системой как один мега-шаблон.

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

Заключение: Спасибо!

Энтузиасты ACM делают нужное дело: исследуют возможности расширения процессного управления на прежде недоступные для него области. И за это им искреннее спасибо!

Рыночные соображения заставляют их дистанцироваться от «родственников» - BPMS и ECM и позиционировать ACM как самостоятельный класс систем. Мне представляется, что это нерационально с точки зрения и технологической, и методологической, и это вряд ли получится.

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

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