Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

ACM: парадигма или фича?

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

21.01.11 | Статьи | ,    

Комментарии (31)

  1. Michael Zobel 22.01.11 21:25

    Anatoly,

    Thanks for your analysis and for not doing away with ACM as being fully unrelated to process as seems to be the recent fashion. Your view of the artificial fragmentation of ECM, ACM, and the like is also highly appreciated because at ISIS Papyrus we have advocated this for roughly a decade now, just to be frowned upon by analysts and integrators because it’s beyond their understanding what our customers benefit from.

    Best,

    Michael

  2. Keith 23.01.11 01:28

    Great post! The description of ACM is very good, one of the best I have seen.

    However, you limit yourself because you consider the only the uses of ACM that are consistent with BPM. That is why you end up concluding that ACM will always be a feature of BPM. You are missing the uses of ACM that have nothing to do with BPM.

    How about project management? People use project management software to run business processes. Will project management software become a feature of BPM? In many ways, project management software is closer to BPM than ACM. Both BPM and PM deal with predictable processes. Why is it, then, that people are not arguing that PM software will merge with BPM in the future?

    See my detailed discussion at:

    http://social-biz.org/2011/01/22/acm-feature-or-paradigm/

    My conclusion is that ACM will really become a part of Social Business Software (a.k.a. Enterprise Social Software) not BPM. Imagine “Linked-In” with collaborative planning features. That is the kind of software that Dr. House would use (if he ever actually did any work). A doctor will never use BPM — no matter how many ACM features it has. But why are we even asking this question? What made us think that knowledge workers would use BPM in the first place? The only reason one asks if ACM and BPM are the same, is if one started with that assumption in the first place.

  3. Anatoly Belychook 23.01.11 20:10

    Alexander Samarin contributed to the discussion but didn’t give a link. Doing it for him:
    http://improving-bpm-systems.blogspot.com/2011/01/contribution-to-acm-feature-or-paradigm.html

  4. Anatoly Belychook 23.01.11 20:59

    Keith

    Thank you for detailed and thoughtfull analysis.

    I guess some of my arguments weren’t expressed good enough.

    1. I believe it’s inefficient to manage processes and cases separately because a) there are “things” that are semi-process/semi-cases like tech support example above and b) there are “things” that very likely will mutate from cases to processes when the company matured.

    2. In order to manage cases efficiently we must classify them. E.g. in tech support scenario there are tickets, bugs, builds, QA runs, releases, upgrades etc. This is what I call process architecture. If not treated with due respect, one will end up with a terrible mess of bugs inside tickets, different names for similar bug cases used by different users etc.

    3. About data architecture: of course there are corporate applications, databases etc. But anyway: as soon as one decided to manage cases (or processes) somewhere not within these systems, he will have to define case entities, their attributes and relations between entities. Probably there will be non-case entities, too. This is what I call data architecture. Without due respect, one will end up with duplicate data and other mess.

    Dana Khoyi writes at p.137 of “Mastering the Unpredictiable” in the section named “Building the Solution with ACM”: “Describe the business entities as the first step of setting up a solution with and ACM”. And later: “Describe the relations between the business entitites”.

    I agree totally: it must be done. But not by business users.

  5. Anatoly Belychook 23.01.11 21:03

    Michael, Keith

    Seems that you are on different positions about whether ACM relates to processes, am I right?

  6. AS 24.01.11 13:10

    Bravo Anatoly for the excellent post.

    Thanks,
    AS

  7. Dr. Martin Bartonitz 24.01.11 15:03

    mentioned on SAPERIONblog as comment on “Gartner pushes Case Management in the context of PBM. Old wine in new skins or …?”
    http://www.saperionblog.com/lang/de/gartner-pushes-case-management-in-the-context-of-pbm-old-wine-in-new-skins-or/3348/#comment-6211

  8. Anatoly Belychook 27.01.11 20:13
  9. Анатолий, спасибо, действительно хорошая статья. Часть комментариев уже высказана и я не будут их повторять. Но есть один момент, на который, похоже, мало кто обратил внимание. Это новые роли, возникающие в ходе исполнения и развития бизнес-процессов.
    В ACM есть роль, отсутствующая в BPM, а именно case worker. Я соглашусь с тем, что большинство участников бизнес-процесса не должно быть их архитекторами. Иначе возникнет хаос. Но должен быть кто-то «умный», способный вмешаться в ходе исполнения экземпляра процесса… главный бухгалтер, мастер на производстве (SCRUM-мастер у программистов), наставник и т.д. Ваша статья затронула тему появления новой роли. Его можно назвать менеджером процесса, можно назвать аналитиком, можно – архитектором. Главное, что этот персонаж находится внутри процесса, а не где-то за сценой и влияет на процесс в ходе его исполнения.

    Я считаю, что это самое интересное в происходящем. Кто эти люди, где их брать и как учить, каковы их полномочия, какие им нужны инструменты. Вопросы, вопросы…

  10. Anatoly Belychook 06.02.11 10:24

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

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

    Вообще же найти роль, которой нет в BPM, будет непросто. К примеру, BPM Common Body of Knowledge (BPM CBOK) описывает следующие типовые роли:
    - Process Owner
    - Process Manager
    - Process Analyst
    - Process Designer
    - Process Architect

    Там же сказано, что опрос организаций, практикующих BPM, дал свыше 100 должностей и ролей.

  11. AS 06.02.11 10:56

    About roles — maybe a super-user? See http://improving-bpm-systems.blogspot.com/2010/05/who-is-doing-bpm.html

    Thanks,
    AS

  12. Анатолий, подозреваю, что прораба (сокр. от производителя работ) в этом списке нет. Того самого Владимира Николаевича в исполнении актера Любшина из культового фильма Кин-дза-дза, способного ориентироваться в пустыне чужой планеты, современным компаниям и не хватает.

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

  13. Anatoly Belychook 06.02.11 18:14

    Максим

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

    И это не абстрактные рассуждения: у наших заказчиков роли собственников процессов и процессных менеджеров играют “нормальные” менеджеры верхнего и среднего звена, соответственно. Зачастую даже не догадываясь, что против их имен в титрах стоят такие мудреные роли :)

    Кстати, еще один совет Раммлера: собственник (process owner) нужен далеко не всем процессам, а только кросс-функциональным процессам верхнего уровня. Тоже нельзя не согласиться.

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

  14. AS 06.02.11 22:36

    My observation — we may need to distinguish between process-template owner and process-instance owner. The latter may be a “прораб”, a user, a super-user or, even, a line manager.

    Also, I noticed that some cross-functional top-level business processes may have a collective process-template owner, i.e. a committee. And no one wants to be an owner of instances of those processes.

    @Maxim — a super-user has some rights to adapt a BPM tool to the needs of the business. Sure, he/she is in some extend “технолог”.

    Thanks,
    AS

  15. Anatoly Belychook 06.02.11 22:47

    Totally agree.

    Another analogy: process owner is a judge, process manager is a police officer.

  16. Anatoly Belychook 06.02.11 22:56

    Or process owner = congressman? OK, it’s a poor analogy altogether.

  17. Anatoly Belychook 15.02.11 19:12

    Неожиданный поворот в дискуссии

    Barely a Year Old, and ACM is Dead
    http://www.bp-3.com/blogs/2011/02/barely-a-year-old-and-acm-is-dead/

    ACM is Dead! Long live ADAPTIVE!
    http://isismjpucher.wordpress.com/2011/02/14/acm-is-dead-long-live-adaptive/

  18. maxxannik 22.05.11 14:20

    Анатолий, что вы скажете вот на эту статью? http://itau.ru/2011/05/21/protsessyi-organizatsii-opisanie-formalizatsiya-reglamentatsiya-na-primere-printsipov-acm/
    Очень интересно :)

  19. Anatoly Belychook 22.05.11 22:08

    maxxannik

    Это Ваша статья?

  20. Gheorghescu 03.05.12 11:46

    Keith Swenson has authored a book on ACM caleld “Mastering the unpredictable”..and what s interesting is that it seems ACM is very similar to KM in that it talks about non-routine, unpredictable work what we call knowledge work. Another way of looking at it is when not to use BPM.

  21. Anatoly Belychook 03.05.12 12:30

    To be precise, this book was written by a number of authors.

  22. Johnker 24.07.13 05:57

    Статья замечательная. Актуальности не теряет. Перечитал снова с удовольствием.
    Анатолий, являясь признанным гуру BPM, делает в статье важный вывод, что ACM тоже имеет право на существование :).

    Сейчас, по прошествии некоторого времени, я уже могу утверждать, что ACM и Social BPM это практически одно и то же.
    Max the Papyrus Pusher будет категорически против. Keith, скорее всего, согласится.
    Max утверждает, что ACM, в отличие от BPM, позволяет достичь цели. Цель в ACM - это все, а переговоры экипажа (social networking) значения не имеют. При этом он не может формализовать понятие цели, а может лишь на страницу описывать свои ощущения, когда он думает (мечтает?) об этом понятии. Поэтому реализация цели в его продукте ничем не отличается от реализации задачи.

    При попытке формализовать понятие цели (в корпоративных процессах, не в системах наведения баллистических ракет) любой сразу поймет, что это понятие социальное и реализуется в информационной системе только с привлечением социальных сущностей - дискуссий, поручений (human tasks) etc.

    Итак, на сегодня, ACM это Social BPM. Не расширение BPM, не подмножество, а смежная область. BPM автоматизирует predictable процессы. ACM автоматизирует unpredictable human activities этих же процессов. В целом автоматизация получается более полной - сотрудники, обслуживающие эти процессы, теперь реже будут вынуждены отодвигаться от компьютера, чтобы решить вопрос по телефону.

  23. Anatoly Belychook 24.07.13 20:57

    Спасибо за комментарий и за комплименты. Продолжаю размышлять над ролью и местом кейс-менеджмента - http://mainthing.ru/ru/item/681/

    По поводу социальности, про которую “любой сразу поймет” - меня вычеркивайте, так что не любой по-любому :) Что является целью организации? Вопрос очень дискуссионный. Я лично склоняюсь к тому, что организация - это форма жизни, а целью жизни является жизнь, т.е. возможно более длительное существование. Будет организация существовать - будет и все остальное, включая пресловутый возврат инвестиций.

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

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

  24. Johnker 25.07.13 00:54

    Анатолий,

    >>любой сразу поймет” - меня вычеркивайте, так что не любой по-любому :) Что является целью организации? Вопрос очень дискуссионный.

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

    >>как социальность поможет решить проблему “корпоративного пинг-понга”?
    Очень хороший вопрос. Самый важный. Ответ на него существует. Оперировать не целями (которые часто и сформулировать нельзя, см.выше), а ответственностями. Лицо, Принимающее Решение (ЛПР, замечательный ведь термин когда-то был придуман, эх, вспоминаю с ностальгией кафедру Исследования Операций ВМК МГУ) на своем уровне компетенции принимает решение, какая активность подведомственных ему сотрудников соответствует цели, а какая нет (словесное определение таким ЛПР локальной цели и оценка действий сотрудников зависит от образования и воспитания, главное тут, что разделены сферы компетенции - люди занимаются своей непредсказуемой деятельностью и пытаются понять друг друга, а информационная система фиксирует эту деятельность и ПОНУЖДАЕТ ЛПР принимать решения, не пытаясь рулить непонятными ACM целями). И, соответственно, такое ЛПР отвечает за принятые решения перед другим ЛПР, которое действует точно так же. Вот и все. Вместо дерева целей строится дерево ответственностей, причем строится адаптивно, как часть кейсов в библиотеке шаблонов кейсов. За возникающий “корпоративный пинг-понг” всегда ответит соответствующее ЛПР (владелец процесса, в терминах BPM, но для ACM термин ЛПР лучше подходит, так как таких ЛПР с соответственными уровнями компетенции в одном кейсе может быть много). Нерешенный фундаментальный вопрос (кто, кому, на каком основании будет раздавать задачи) начнет с помощью такой ACM решаться - принятие решения по любой ерунде в реальной корпоративной жизни часто эскалируется на самый верх, а тут появляется инструмент для совершенствования этой процедуры - формирование библиотеки шаблонов кейсов, в которых начнут фиксироваться ЛПР по самым разным аспектам короративной жизни, от закупки скрепок, до приема на работу генерального директора. Термины ЛПР, ответственность - сущности социальные, и их привнесение в конструкцию ACM, собственно, и превратит ACM в социальную BPM.

  25. Anatoly Belychook 25.07.13 08:16

    По поводу ЛПР: наука не стоит на месте и изобрела термин ЛДПР: лицо, действительно принимающее решение :)

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

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

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

    Чтобы ACM был работоспособен, он должен позаимствовать методологию либо из процессного, либо из проектного подхода. Скорее из второго. Не ЛПР нужен кейсу, а менеджер проекта. Причем кокретного экземпляра кейса, а не всех кейсов данного типа.

  26. Johnker 25.07.13 09:47

    Имитация бурной деятельности и спихотехника начнут уменьшаться (но на 100% не прекратятся никогда), как только сотрудники, назначенные ЛПР в кейсах, начнут реально отвечать за невыполнение работы в соответствии с деревом ответственностей.

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

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

  27. Anatoly Belychook 25.07.13 11:26

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

  28. Johnker 25.07.13 16:03

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

    Привязка каждодневных кейсов сотрудников к структуре ответственности и немедленная эскалация проблем по принадлежности - это и есть то преимущество ACM, которое еще надо реализовать, конечно. Но на концепцию ACM такая модель стимулирования исполнения процессов организации в направлении к корпоративным целям ложится очень хорошо. Таким образом решается фундаментальный для ACM вопрос о способах достижения цели с помощью ACM - до сих пор ясного изложения того, как это надо делать в ACM, никто не предложил. Достаточно посмотреть дискуссию, предложенную Свенсоном “Do tasks, goals, and activities have to be handled differently in a plan?”, чтобы увидеть какие творятся разброд и шатание даже по базовым терминам ACM. Это очевидный нонсенс, так как ACM по определению являются goal oriented systems, а что же такое goal, никто не знает - на формальном, программируемом уровне, конечно, на вербальном мы все горазды - в блоге писать не мешки ворочать.

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

  29. Anatoly Belychook 25.07.13 17:20

    ОК, раз не получается согласиться, давайте согласимся, что мы не согласны :) Спасибо за интересное обсуждение!

  30. Johnker 25.07.13 18:11

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

  31. Marek Szelągowski 17.10.14 12:52

    Anatoly great article! For 10 years I’m working on the concept of dynamic BPM, which seems to be predicted by you “new BPM”. In fact, dynamic BPM is an extension of traditional, static BPM. Take a look at: http://www.bpminstitute.org/resources/articles/does-modern-technology-impede-modern-management
    or http://jemi.edu.pl/uploadedFiles/file/all-issues/vol10/issue1/JEMI_Vol10_Issue1_2014_Article_6.pdf
    And a great asking for your comments. Best wishes. marek

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии