В 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-систем, значительно расширяющей возможности их применения.
