Максим Смирнов и ваш покорный слуга уже высказывались на тему ACM в своих блогах. Также эта тема была одной из центральных на неконференции BPMS.ru в прошлом году. За это время утекло много воды, и созрела идея посвятить ей целиком очередной семинар BPMS.ru. Приходите, будет интересно:

Тема: “Adaptive case management - недостающее звено BPM”
Дата: 16 марта 2011 г.
Время: с 19:00 до 21:00.
Место: РОСНОУ, г. Москва, ул.Радио, 22.
Докладчик: Максим Смирнов
Оппонент: Анатолий Белайчук
Регистрация: livents.ru

Это третья и завершающая часть исследования на тему управления кросс-функциональными процессами. Предыдущие части:

1. Вульгарное представление о кросс-функциональных бизнес-процессах
2. Кросс-функциональные паттерны

Во второй части мы рассмотрели два основных способа организации работы смежных участков в рамках кросс-функционального бизнес-процесса:

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

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

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

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

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

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

» читать дальше

Спонсор одного из наших BPM-проектов как-то сказал в самом начале, когда мы только обсуждали возможный проект: “моим сотрудникам не нужно чтобы их контролировали, им нужно чтобы им помогали”. В тот момент я заспорил, но потом понял - он прав!

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

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

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

Это сложные задачи. Реально сложные.

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

Пример:

• Небольшая торговая компания, специализирующаяся на товарах «с изюминкой» - гаджетах, прикольных подарках, дизайнерских аксессуарах для ванн и т.п.
• Группа процессов под названием «Управление ассортиментом»: несколько сотрудников постоянно мониторят интернет, ходят на выставки, заглядывают в магазины конкурентов - ищут новые идеи, бренды, новых поставщиков. С одной стороны, в силу специализации компании ассортимент должен постоянно пополняется модными штучками, а с другой - ассортимент не может быть слишком большим, его надо постоянно прореживать.
• Эти несколько человек ежемесячно оценивают до тысячи кандидатов на включение в ассортимент. Компания выработала трехступенчатое сито отбора: сначала экспертная экспресс-оценка, бракующая большинство идей. Затем переговоры с поставщиком, проработка логистики и оценка возможной прибыльности. Затем - раз в месяц - ранжирование идей, прошедших первую и вторую квалификацию, и отбор кандидатов на пробную закупку и реализацию с учетом имеющегося на данный момент бюджета на расширение ассортимента.
• Параллельно, также примерно раз в месяц, весь текущий ассортимент анализируется с точки зрения фактической продаваемости, разнообразия и т.д.

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

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

1. узнать цены у поставщика
2. узнать условия поставки
3. оценить продаваемость
4. назначить рейтинг
5. принять решение о пробной закупке

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

Во вторых, какой в смысл в такой схеме, если все шаги выполняет один человек? Это ведь махровый микроменеджмент. Что, разве проблема тут в том, чтобы проконтролировать последовательность задач? Ясно ведь, что не в этом, а в том, чтобы уследить за сворой одновременно и асинхронно протекающих процессов: сотнями процессов, проходящими первый этап квалификации, десятками - второй, процессами отбора в и отсева из ассортиментами. А для этого нужно реализовать не workflow, а достаточно сложное межпроцессное взаимодействие.

Люди хотят не чтобы их контролировали под видом процессов, а чтобы им помогли контролировать действительно сложные процессы.

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

Но по пути вам придется преодолеть их недоверие - изначально внизу никто ничего хорошего от словосочетания «бизнес-процесс» не ждет. Вот как я это делаю в разговорах с людьми:

Представьте себе, что у вас появился робот-помощник. Безотказный и безошибочный. Он возьмет на себя самую нудную, канцелярскую часть вашей работы. Например, вы сможете ему сказать:

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

Кто, скажите мне, откажется от такого помощника?

К тому же BPM-робот безопасен, потому что он подчиняется законам - хотя и не тем, что у Айзимова.

Законы робототехники BPM:

1. Робот никогда не сможет сделать все то, что можете сделать вы.
2. Робот будет делать только часть того, что делаете вы.
3. Робот будет делать только ту часть вашей работы, которую вы сами не захотите делать.

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

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

В данной статье мы рассмотрим паттерны, характерные для кросс-функциональных процессов.

Воспользуемся следующим примером:

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

В простейшем виде процессная диаграмма может выглядеть так:

» читать дальше

В своей недавней заметке “BPM Skills” Адам Дин написал:

Самое ценное, что вы можете добавить к своему предложению в части BPM, это квалификация.

У меня есть возражение.

По моему опыту, самая большая проблема BPM-инициатив это целеполагание. Люди выбирают цель для BPM-проекта - т.е. конкретный бизнес-процесс - на основе интуиции или политики, но не тщательного анализа.

Ни одна система не может сама определить для себя цель. Поэтому только BPM-квалификации для успеха BPM недостаточно.

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

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

Но послушайте: какая доля возможных процессов способна повлиять на итоговые цифры в балансе компании? Теория Ограничений постулирует, что в системе обычно есть небольшое число узких мест (или даже всего одно). Следовательно, результаты проекта BPM будут заметны на уровне компании только если он был нацелен на одно из этих немногих процессов - узких мест (или даже на единственный). В противном случае успех проекта BPM будет чисто локальным: он увеличит производительность звена, но производительность цепочки создания ценности останется прежней, так как она ограничена каким-то другим звеном.

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

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

Большая часть работы в этих проектах делается самим клиентом - рабочая группа обычно включает от 15 до 20 человек, от руководства до ключевых специалистов. Мы ставим правильные вопросы, а ответы - их собственные.

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

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

Напомню, что кросс-функциональным называется процесс, в котором участвуют несколько подразделений верхнего уровня (по-английски «функций» – отсюда название). С точки зрения процессной методологии, именно на такие процессы в конечном счете должны нацеливаться инициативы BPM, поскольку именно здесь обычно кроются самые большие проблемы, а следовательно, наличествует самый большой потенциал улучшения. Ведь любая иерархическая организация, достигая определенного размера, сталкивается с тем, что собственные интересы подразделений начинают преобладать над интересами компании в целом.

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

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

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

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

Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:

Рис. 1. Функции и кросс-функциональные процессы.

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

Рассмотрим в качестве примера – процесс «от заказа до оплаты»: приняли заказ – произвели – отгрузили – произвели расчеты. Попробуем смоделировать его для случая производства на заказ, буквально следуя картинке  на рис. 1:

1. Процесс начинается, когда отдел продаж получает заказ клиента.
2. Получив и оформив заказ, отдел продаж передает его в производство.
3. Производство приступает к выполнению заказа.
4. Изготовленный товар доставляется заказчику.
5. Финансовый отдел производит расчеты.

Рис. 2. Кросс-функциональный процесс «от заказа до оплаты», workflow-версия.

Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.

Более правдоподобной выглядит следующая схема:

1. Отдел продаж оформляет заказ клиента и размещает его в производстве.
2. С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
3. Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.

В графическом виде:

Рис. 3. Кросс-функциональный процесс «от заказа до оплаты», BPM-версия.

У нас появилось два процесса, взаимодействующих через данные (БД заказов) и сообщения (уведомление о выполнении заказа). Реализовать эту схему в рамках одного пула (одного процесса) принципиально невозможно, так как у процессов «клиентский заказ» и «производство» разные триггеры: поступление заказа от клиента и таймер, соответственно.

Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса «клиентский заказ». То есть технически процессов (пулов) тут не два, а больше.

Workflow, BPM и многопоточное программирование

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

Технически эти задачи решаются при помощи процессных паттернов, один из которых изображен на рис. 3. А на уровне методологическом картинка, изображенная на рис. 1, может выглядеть так:

Рис. 4. Кросс-функциональный процесс как координатор функций.

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

Переходя от workflow к межпроцессному взаимодействию, мы переходим от однопоточного к многопоточному программированию.

К сожалению, для многих это становится непреодолимым барьером.

• Кто-то этот барьер не видит. Бьется об него, набивает шишки, но не понимает, с чем столкнулся.
• Кто-то барьер инстинктивно обходит: выполняет пилотный проект BPM с процессом типа «Оформление заявление на отпуск». Пилот получается успешный, только какое он имеет отношение к бизнесу?

Отсюда, как мне кажется, проистекает большая часть разочарований в BPM: те, кто сводят его к workflow, терпят прогнозируемое поражение.

Технически, многопоточность – это то, что отличает BPM от worflow. Уберите из BPM взаимодействие асинхронно исполняющихся процессов через данные, сообщения и сигналы, и это будет не BPM, а «workflow на стероидах».

К большому сожалению, это относится ко многим современным программным продуктам с агрессивным маркетингом, позиционирующим их как BPMS. Для меня главный критерий полноценной BPMS – это наличие в продукте поддержки сообщений в стиле BPMN. Есть и другие критерии, но этот на практике оказывается самым полезным, так как со всем остальным – графическим моделированием, workflow-движком, веб-порталом, бизнес-аналитикой – лучше или хуже справляются все разработчики, а с поддержкой межпроцессного взаимодействия – единицы. Скорее всего не потому, что это так уж сложно, а потому, что никто не объяснил насколько это важно.

Но сказать «осваивайте многопоточное программирование процессов» легче, чем последовать этому совету. В ответ раздается стон: «какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!».

Сложен не BPMN – сложен бизнес!

Кто бы вам не обещал простые средства решения бизнес-проблем, будь то BPM или что-то другое – не верьте! Бизнес – это конкурентная область человеческой деятельности: талантливые и изощренные люди соревнуются в ней за то, кому будет житься хорошо, а кому – не очень. Поэтому бизнес был, есть и останется делом сложным.

Сложность BPMN не чрезмерна – она адекватна сложности бизнеса. У слушателей моего тренинга по BPMN не остается вопроса зачем столько событий: все нужны! И кстати, обратите внимание: в части workflow BPMN 2.0 практически не отличается от 1.x – стандарт развивается в направлении более изощренной поддержки многопоточного программирования: choreography, conversation.

Если бизнес и можно запрограммировать, то только как многопоточную систему.

BPM и ACM

Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): «Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!»

Может быть можно, может быть нельзя… Скорее всего, в каких-то случаях можно, а в каких-то нет.

Вот говорят, что доля knowledge work постоянно растет. Но где именно она растет? В США, активно выводящих всю рутинную деятельность в Азию. Вот и сообщают нам сидящие в США аналитики о своих вполне прогнозируемых наблюдениях. Но ведь насколько выросла доля knowledge work в одном месте, ровно настолько же выросла доля routine work в другом. А управлять рутинными процедурами, исполняющимися на другом конце глобуса – это ведь самая подходящая для BPM задача.

В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?

Потому что в этом случае их провал предсказуем, но он вовсе не означает, что BPM указывает неверный путь. Просто тщательнее надо работать.

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

Продолжение следует

В нем я планирую рассмотреть основные паттерны межпроцессного взаимодействияю, а также предостеречь от противоположной крайности – чрезмерного увлечения межпроцессным взаимодействием. Оставайтесь на связи.

• Часть 2: Кросс-функциональные паттерны
• Часть 3: Оптимизация кросс-функциональных процессов

Крайне распространенная ситуация: сотрудник выполняет задание, руководитель проверяет и имеет возможность отправить обратно на исправление. Обычно ее моделируют так:

Я рекомендую чуть более изощренную схему:

При этом содержание заданий “Сделать” и “Переделать” может не отличаться, т.е. разница только в названиях. В чем смысл:

• В первом случае сотрудник видит у себя в списке задач, условно говоря, “Сделать дело”. Делает его, жмет на кнопку и… через 15 минут снова видит у себя эту же задачу, относящуюся к этому же экземпляру процесса. Это сбивает с толку, особенно если за эти 15 (или 30, или 130) минут он успел позаниматься какими-то другими делами.
• Еще вторая схема лучше с точки зрения мониторинга: в ней легко посчитать число переделок и потраченное на них время и бороться за то, чтобы свести их к нулю. Положим, число переделок можно подсчитать и в первой схеме - просто вычесть из числа исполнений задачи число экземпляров процессов. Но суммарное потраченное время (т.е. неоправданные затраты) в первой схеме подсчитать будет затруднительно.

Вот такой получился паттерн: почти тривиальный, но зато (или как раз поэтому?) потенциально широко применимый.

Бизнес-процессы иногда называют «генетическим кодом организации».

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

В рамках этой аналогии BPM – это генная инженерия:

• мы расшифровываем геном организации (анализ и моделирование бизнес-процессов)
• мы идентифицируем отдельные хорошие и плохие гены (процессные паттерны и антипаттерны)
• мы удаляем плохие гены, заимствуем хорошие у одних живых организмов и прививаем их другим

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

Четвертое по счету подобное мероприятие CNews на этот раз проходит под заголовком “BPM в России: мода или потребность”.

Нам удалось привлечь к нему в качестве спонсора BizAgi. И не просто привлечь, а убедить приехать в Россию первое лицо компании (CEO) Густаво Игнасио Гомеса. Планируется, что мы с ним сделаем совместный доклад.

Компания BizAgi и ее продукт BizAgi BPM Suite очень интересные; на мой взгляд, недооцененные. Судите сами:

1. Самая полная реализация BPMN в исполнительном движке. В частности, реализованы сообщения (message flow), циклы по объектам (multi-instance), сигналы, транзакции и компенсации. На фоне множества вендоров, которые декларируют BPMN, а на деле реализуют только самые базовые конструкции, это впечатляет.
2. Очень лояльная по отношению к клиенту ценовая политика. Ценового барьера как такового нет: младшая конфигурация стоит $100 за пользователя. Приятный контраст по сравнению с BPM-системами, для которых за “входной билет” просят сто-двести-триста тысяч долларов. Есть бесплатная пробная версия, не ограниченная ни по функциональности, ни по срокам.
3. Поддержка одновременно и .NET, и J2EE. Опять-таки, другого такого вендора я не знаю.

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

Резюмируя, я считаю, это тот продукт и тот вендор, которых не хватало российскому рынку.

Так что приходите - для представителей компаний-заказчиков мероприятие бесплатное. Регистрация >>