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

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

Однако достаточно большая часть работ, выполняемых сотрудниками совместно, во взаимодействии между собой, слабо структурирована, требует обсуждений, выдачи поручений на основе анализа текущей ситуации и контроля сроков исполнения задач и поручений. Для решения подобных задач коллективного взаимодействия сотрудников, управления социальными бизнес-процессами и предназначены системы ACM (Adaptive Case Management).

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

“Pidgin-BPM” или недостающее звено BPM?

“BPMs vs. ACM” — противопоставление или интеграция? ACM это часть BPM или самостоятельная концепция? Многочисленные дискуссии на эту тему буквально вспыхивают в разных концах Интернета и на страницах ИТ-изданий.

Ответ на этот вопрос зависит от позиционирования ACM. Я наблюдаю две тенденции среди экспертов. Немного утрирую для наглядности.

Одни эксперты считают, что ACM это “Pidgin-BPM”, примитивная версия BPM, вульгарным способом решающая те же проблемы, что и BPM. “Серьезные специалисты”, отдавшие годы BPMN, BPEL etc., принять такую концепцию ACM не готовы, максимум, на что они вынуждены идти — это считать ACM опцией, дополнительным “бантиком” к BPM. Что интересно, большой вклад в популяризацию такой концепции ACM оказывают посты некоторых известных апологетов ACM (Max J. Pucher), считающих, что “Adaptive /Case Management/ does not suppose collaboration” (sic!). Однако именно практическим внедренцам прекрасно известно, что реальные системы BPM имеют вполне реальные проблемы с целостностью, под которой в данном случае понимаем возможности удовлетворения всех требований заказчика к автоматизации бизнес-процессов. Хорошо известно, что частенько происходит при возникновении непредвиденных (для системы BPM) проблем. Отодвигаемся в сторону от компьютера с его BPM-игрушками и беремся за телефон, чтобы “контролировать ситуацию” — со всеми вытекающими последствиями, в том числе и с последствиями для такой системы.

Естественно, поставщики давно видят наличие недостатков у “традиционных” BPM-систем. Изобретаются различные возможности добавлять в экземпляр бизнес-процесса в режиме реального времени ad-hoc activity, появляются расширения BPEL для учета коллективного взаимодействия, такие как BPEL4People, однако эти возможности обладают общими недостатками BPM в сравнении с ACM — требуют сложных настроек (а в ACM их минимум), в них затруднены средства контроля доступа, адресации и фильтрации таких ad-hoc activities, нет средств загрузки файлов, фотографий пользователей, средств для ведения дискуссий — все это элементарные средства, которые обязаны быть в любой ACM.

Результатом такого подхода является ненужный антагонизм между ACM и BPM.

Другие эксперты считают, что ACM — это collaborative BPM, social BPM, agile BPM, в которой следующий шаг процесса определяется в социальной среде решением человека. А этот как раз то “недостающее звено”, чего не хватает традиционному BPM и почему изобретаются BPEL4People etc. В такой интерпретации ACM это как раз то, чего жаждет BPM, я бы сказал, без чего BPM не сможет развиваться, чтобы наконец стать эффективным инструментом. И интеграция BPM и ACM в этом случае расширяет сферу применения BPM, делает системы BPM более привлекательными и эффективными. И те вендоры и интеграторы BPM, кто начинает интегрироваться с ACM, получают конкретные конкурентные преимущества

BPM без ACM “выражает одну из основных черт буржуазного мировоззрения — его бесчеловечность, стремление превратить трудящихся в придаток машины, заменить живого, мыслящего, борющегося за свои интересы человека машиной” (1954, Краткий философский словарь о кибернетике) . Ну, а если это выразить более современно, то ACM привносит в BPM необходимую гибкость социальных сетей, “очеловечивает BPM” (не зря же я вспомнил философский словарь советского времени), позволяя средствами Web 2.0 интегрировать системы BPM с возможностями систем коллективной работы, помогающих принимать решения о следующих шагах бизнес-процесса в социальной среде с помощью обсуждений и поручений.

Преимущества интеграции

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

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

Такая тактика, как выясняется (уже могу сослаться в этом на свою практику), является успешной и позволяет за счет ACM сгенерировать новую волну интереса и к BPM, которая при наличии в ней “недостающего звена” ACM становится существенно более функционально привлекательной для заказчиков и более презентабельной внешне.

Добавление гибкости, адаптивности и collaboration в систему BPM, как уже совершенно очевидно, очень существенно повышает value такой системы BPM. Унаследованные приложения уже с трудом конкурируют с новыми системами Web 2.0, имеющими схожие функции, а “офейсбученный офисный пипл” жаждет привычного интерфейса и на работе тоже.

Из-за множества исключений, сопровождающих бизнес-процессы в реальной корпоративной жизни далеко не все удается автоматизировать традиционными BPMS. Реализации получаются очень громоздкими из-за множественности и неопределенности этих исключений. В обычной системе BPM вы должны изначально, до начала процесса, тупо и детально перечислить все возможные варианты, в ACM эти варианты подгружаются из библиотеки паттернов или создаются вручную по мере их появления в реале. Это как сравнивать простую статичную HTML-страницу, которая содержит сразу все нужное и ненужное, и HTML-страницу с AJAX, которая подгружает данные на страницу по мере необходимости. В принципе, можно как-то и простыми HTML-страницами обойтись, зачем этот AJAX? Однако с ним лучше получается. Так и ACM проявляет процесс по мере его исполнения.

Я бы сравнил существующие BPM-платформы с машиной Тюринга. В том смысле, что в рамках BPM-платформы возможно запрограммировать любые бизнес-процессы, так же как на виртуальной машине Тюринга можно теоретически запрограммировать все. Но только теоретически. Это доказано. Так и с традиционными BPMS — теоретически можно все. А вот практически… Поэтому концепция ACM и появилась. Циклами Птолемея тоже в принципе движение звездных тел описывалось — с любой наперед заданной точностью.

Принцип Оккама безвозвратно забыт

Принцип бритвы Оккама “не изобретай сущностей сверх необходимых” безнадежно забыт очень многими вендорами ИТ, нынешний мировой тренд поставщиков ПО я бы выразил фразой “новизна подменяется сложностью”. Когда сказать нечего, идей нет, а новые версии надо выпускать, чтобы поддерживать доход, тогда и выводятся на рынок софтверные монстры. И с BPM такая же история.

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

Сейчас скажу простую и важную вещь, о которой все знают, но значения которой не придают. Пользователи готовы пожертвовать функциональностью в пользу простоты. Это и есть причина появления концепции ACM. Другими словами, с BPM намучились, долго ждали чего-то простого и доступного — и так и не дождались.

Все гениальное простым становится позже, сначала оно кажется примитивным

Вместо сложных описаний бизнес-процессов весь Adaptive Case Management крутится фактически вокруг чек-листов, представляющих собой список из чек-пойнтов, или milestones, — контрольных точек, задач, которые необходимо выполнить.

Для ACM такой чек-лист из контрольных точек — это то же самое, что для традиционного BPM happy path — основной перечень действий, которые надо сделать и представление о которых имеется перед началом процесса. В ACM этот перечень по мере исполнения процесса корректируется и дополняется.

Собственно, обработка статусов контрольных точек (открытие, закрытие, отмена, деактивирование, назначение и контроль сроков исполнения) + информационные сообщения (дискуссии и отчеты о предпринимаемых действиях) — это и есть основной функционал ACM

Фильтры позволяют увидеть и на лету сформировать все такие необходимые списки контрольных точек в разных разрезах:

  • “Открытые” — актуальные сообщения;
  • “Требующие ответа” — сообщения, требующие создания ответных сообщений;
  • “Просроченные” — открытые сообщения с просроченной датой исполнения;
  • “Созданные мной” — сообщения, созданные текущим пользователем;
  • “Для меня” — сообщения, адресованные текущему пользователю.

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

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

Малому бизнесу нужны “варенки с вьетнамского рынка”

Задам два простых вопроса — какой процент крупных компаний используют системы BPM? 15%? Значит есть куда расти . А какой процент малых предприятий используют системы BPM? 0,01%? Значит, тут у традиционных систем BPM шансов нет.

“Чистые” BPMS являются элитарными, как джинсы Версаче, и малый бизнес никогда не сможет их использовать. А вот использовать системы ACM в силу их простоты и доступности смогут 90% малых предприятий — простая система управления задачами, где можно галочкой отмечать исполненные работы, нужна практически всем. Такие системы ACM будут, как “варенки с вьетнамского рынка” — дешевый и доступный товар массового спроса. Конечно, такие “варенки” не станут мейнстримом, функционал которых дотошно обсуждается крутыми ИТ-менеджерами в специализированных блогах — просто все будут их юзать без всякого почитания и ритуальных танцев с описанием бизнес-процессов и написанием толстых технических заданий.

Так что для элитарных BPMS со стороны ACM опасности никакой — BPMS на рынок SMB особо и не претендуют, их присутствия на этом рынке не ощущается — у них достаточно проблем и с крупными заказчиками пока.

И еще о мейнстриме. Я уж лет пять как пришел к выводу, что мейнстримом стали flea-markets. В Европе блошиные рынки и вьетнамские распродажи вытесняют обычные магазины. Был тут в Вене недавно — в самом центре между Оперой и Гранд-отелем был обувной бутик, куда я раньше каждый раз захаживал. Теперь там китайский магазинчик со всякой шелупонью от 2 до 10 евро! К чему бы это?

Видимо, все банально — и блошиные рынки и ACM это ответ на вызов рынка. ACM – это “BPMS для бедных"? А почему бы и нет?

И еще о сложных и простых ИТ-платформах

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

Известный факт, что сисадмина, у которого все хорошо, никто не замечает, а сисадмина, у которого все ломается, носят на руках, как героя, который всех спасает в критический момент.

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

И еще на тему влияния корпоративной психологии на ИТ-архитектуру. Есть известная поговорка: “Ни одного менеджера еще не уволили за то, что он выбрал решения от IBM”. И чем крупнее компания-заказчик, тем проще принимать такие решения. При этом такие очевидные факты, что “решениям от очень крупного вендора” свойственны очень высокая стоимость владения (TCO), сомнительный возврат инвестиций (ROI) и высокий риск провала внедрения, в расчет не принимаются — ИТ-бюджет позволяет за все заплатить. Фактический провал такого внедрения долго никем не признается — никому это не выгодно — и решение существует в вялотекущем режиме, используется 10% заявленной функциональности. Но архитектура очень крутая (и дорогая соответственно). Виноваты все, кроме принявшего “правильное” решение менеджера.

Редко публике становятся известны удивительные факты судебных исков против поставщиков ERP о возмещении убытков на сотни миллионов долларов.

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

Автор статьи — технический директор PayDox.