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

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

Новый рубеж BPM: динамические процессы

BPM осваивает новую территорию, которую называют по-разному: dynamic processes, unstructured processes, knowledge worker processes, barely repeatable processes, case management. (На русский не перевожу - так как термины относительно новые, перевод только запутает дело.)

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

Но только “особо одаренные” считают, что жестко структурировать можно любой процесс:

1) Сегодня мы поговорим о том, как нам улучшить наш рабочий процесс 2) Как вы знаете, хороший процесс заменяет хороших сотрудников 3) Конечная цель - упростить наши процессы настолько... 4) чтобы можно было научить кур выполнять вашу работу за комбикорм 5) Для начала обсудим наш процесс получения финансирования для новых проектов 6) Можно ли какую-то часть процесса заменить, например, нажиманием кнопки звонка клювом? 7) Да, но только ту часть, которую делаете вы 8) С планом случилась заминка - (Комбикорм)

Оставляя в стороне крайности - полностью структурированные и полностью ситуативные (ad-hoc) процессы - получаем два варианта сочетания тех и других. Либо структурированный процесс обращается к ситуативному, либо наоборот:

  1. Паттерн “помощь зала”: структурированный процесс обращается к ситуативному подпроцессу. Пример: процесс “от обращения до заказа” в компании - системном интеграторе. Менеджер по продажам встречается с потенциальным заказчиком и предположим, встреча прошла удачно: удалось нащупать одну или несколько “болевых точек” клиента - проблем, за решение которых он в принципе готов заплатить. Следующий шаг процесса - поиск такого решения. Однако проблемы клиента могут лежать в очень широком диапазоне (заметим, что ценность интегратора как раз и заключается в том, что он способен решать широкий круг задач). Начиная от простейшей ситуации, когда нужен коробочный софт, и заканчивая сложными, комплексными проектами. В последнем случае процесс пойдет по извилистой, заранее неизвестной траектории, которая может вовлекать архитектора, разработчика, менеджера по продажам, системного инженера, техподдержку вендора и т.д. Средствами традиционной BPMS можно разве что назначить задачу одному ответственному исполнителю, а с остальными пусть он разбирается сам (см. пост “Процессный антипаттерн: Театр одного актера“). Решение не самое лучшее, так как неизвестно кто занимается проблемой в данный момент, что уже сделано и когда можно рассчитывать получить решение.
  2. Обратная ситуация, паттерн “набор процессных инструментов”: на верхнем уровне процесс протекает  непредсказуемо, но на нижнем он сводится к набору достаточно хорошо формализуемых подпроцессов-инструментов. Пример: адвокатская контора. Процесс верхнего уровня - дело клиента. В какую сторону повернется дело предсказать абсолютно невозможно - например, в любой момент в нем может появиться новый документ, представленный противной стороной, который кардинально поменяет и ход дела, и наши планы действий. Но в то же время, в рамках дела ведущий его адвокат инициирует те или иные действия, которые большей частью стандартны, могут быть типизированы и формализованы в виде подпроцессов. В основном это подготовка исковых заявлений и других документов. Такие подпроцессы выполняются соответствующими специалистами, не привязанных к определенному делу в отличие от адвоката, который его ведет, а являющимися разделяемым ресурсом. С точки зрения компании интересно контролировать показатели эффективности на уровне не только дела в целом, но также подпроцессов и использования ресурсов.

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

  • На конференции Гартнер BPM’2009 была озвучена следующая оценка: до 60% процессов в организации являются неструктурированными и как следствие, неконтролируемыми, неуправляемыми, невидимыми и не регулируемыми правилами. Эти 60% похожи на среднюю температуру по больнице, но “невидимость” этих процессов действительно может быть основной проблемой с точки зрения бизнеса.
  • Обращение к коллективному знанию будет двигать вперед неструктурированные процессы” - Джим Синур (Гартнер) предсказывает, что задействование технологий накопления знаний, отраслевых и социальных сетей приведет к новой волне фундаментальных изменений в BPM и BPMS. Еще один его пост на эту же тему: “Белые воротнички и неструктурированные процессы подходят друг к другу как сыр к вину“.
  • То, как стремительно приобрели популярность социальные сети (те же “одноклассники”), подталкивает к мысли позаимствовать наработанные в них подходы для организации общения в рамках динамических процессов - см. доклад о спектре возможных применений social software в BPM на BPM-конференции в Ульме. Скажем, сталкиваясь с проблемой, я публикую вопрос в корпоративной сети (”помощь зала”). Его видят мои “френды” (в числе которых менеджер проекта и тим-лид). Автор лучшего ответа получает бонус.
  • SAP предлагает использовать для совместной работы технологию Google Wave - но не для исполнения процесса, а для его проектирования. SAP Gravity представляет собой реализацию BPMN-редактора в среде Google Wave. Что касается исполнения, то надо понимать, что возможность проектирования процесса “на лету”, в ходе его исполнения, является важным аспектом динамичности, поэтому SAP создает задел не только для выявления, но и для исполнения динамических процессов.
  • Oracle тоже говорит о collaborative BPM и dynamic BPM и при этом подчеркивает свою приверженность архитектуре SCA, позволяющей комбинировать различные процессные составляющие с бизнес-правилами, аналитикой и т.д. Что ж, учитывая, что за два года Oracle приобрел 50 компаний, продукты которых необходимо интегрировать, для них это особенно актуально.
  • HandySoft, ActionBase и другие вендоры заявляют о поддержке динамических процессов в последних версиях своих продуктов.
  • Самые авторитетные специалисты отрасли собираются, чтобы обсудить проблемы динамических процессов и в частности, их поддержку в BPMN.

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

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

24.10.09 | Статьи | , , ,    

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

  1. Дима 26.10.09 13:14

    Анатолий, как вы думаете, какая из инициатив развития БПМ реально важна и уменьшает разрыв между разработкой и бизнесом, давая возможность реально управлять процессами меняющимся чаще чем раз в квартал, принося выгоды, которые обещает BPM дисциплина:

    1. Единое средство разработки процессов с различными представлениями для разработчика, аналитика, бизнес аналитика с возможностью отрисовки форм и моделирования процессов.
    2. Движки бизнес правил и бизнес событий - как средство упрощающее управление процессами для бизнеса
    3. Модной идеей были заявлены BPA “Средства обнаружения процессов”
    4. Собственно то, о чем вы пишете. Сегмент процессов срок изменений которых от одного месяца до ежедневного изменения. Или процессы которые надо изменять во время выполнения.

    Вы правильно затрагиваете вопрос о развитии, т.к. похоже наступает момент когда “тянуть” все новомодные направления развития не у всех хватает сил.

  2. Anatoly Belychook 26.10.09 15:56

    Дима

    Подход 1 оптимален для процессов, меняющихся раз в месяц - раз в квартал.

    BRE и CEP, на мой взгляд, актуальны в основном для процессов с высокой степенью автоматизации.

    Обнаружение (выявление? discovery?) - это серия коротких итераций, которая выполняется в рамках первоначального анализа процесса, а не на “длинной дистанции”.

    Управлять заранее непредсказуемыми процессами BPMS пока только учатся. Положим, мне понравился ролик HandySoft, но вендор этот у нас неизвестен, цена не детская… Если бы мне пришлось решать такую задачу, я бы попробовал использовать готовый продукт класса problem tracking.

  3. Никита Сушко 01.11.09 23:36

    Благодарю Вас, Анатолий!

    Динамические бизнес-процессы это - очень интересно.
    То, что разработчики идут по правильному пути, закладывая в свои “конструкторы” возможности “ручного управления”, отклонения экземпляров процессов от шаблонов, элементы wiki и проч. - правильно, хотя бы потому, что так усторены и биологические объекты.
    Среди генов, ответственных за выработку антител у нас есть как относительно константные, так и те, частота изменений которых выше на порядки. Есть интересные наблюдения, говорящие о том, что в неблагоприятных условиях некоторые организмы вносят “направленные” изменения в ДКН (см. напр. http://medbiol.ru/medbiol/genexp/000a72c8.htm). В любом случае, структура генома такова, что позволяет уживаться как константным так и бастроизменяющимся последовательностям. Наличие последних - туз в рукаве с точки зрения приспособления к быстро меняющимся внешним условиям.

    Что касается реализации в системах, глубоко не копал, увы, буду исправляться. Однако думается, чтобы “горшочек варил”, поддержка динамических процессов должна закладываться одновременно или даже РАНЬШЕ, чем поддержка шаблонных. А сами шаблоны в таком случае должны получаться из прошедших “отбор” экземпляров динамических процессов.

    Можно возразить - создавать шаблоны нужно после проектирования процессов “на бумаге”. Однако, тогда теряется скорость, а главное, есть соблазн отказаться от поддержки ad-hoc процессов “на данном” этапе, либо навсегда.

    Вот такие мысли, извиняюсь за сумбур.
    Статья как всегда замечательная.

  4. Anatoly Belychook 02.11.09 00:53

    Никита

    Спасибо за интересный комментарий. Аналогии между организациями и живыми организмами вполне уместны и параллели между геномом и шаблонами процессов пусть с оговорками, но провести можно. Ваша идея “естественного отбора” экземпляров процессов перекликается с автоматическим выявлением процессов (automatic process discovery), которое пропагандируют некоторые вендоры. Правда, что это такое на практике я пока не разбирался.

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

  5. Кузин Сергей 05.11.09 12:44

    Коллеги, затронута волнующая тема:
    1. С одной стороны, частое изменение БП характерно для организаций, находящихся на функциональной стадии развития; при этом инициаторами таких изменений чаще всего выступают руководители функциональных подразделений; численность самой организации обычно невелика; полагаю, что динамические БП чаще всего в таких организациях и должны возникать как ответ на неустойчивые БП;
    2. С другой стороны, наибольший выигрыш, видимо, появляется всё же при переходе от управления процессами к процессному управлению, в котором BPMS, по идее, должна проявить себя в лучшем виде как способ быстрого внедрения поддержки БП;
    3. Динамические процессы не являются ли результатом слабой работы аналитиков, не способных спроектировать корректно выполнение “реальных процессов”?

  6. Anatoly Belychook 05.11.09 13:03

    Сергей

    Я бы все-таки разделял процессы часто изменяющиеся и процессы в принципе заранее не предсказуемые.

    Вы похоже говорите о первых. Но методы борьбы с ними известны: это изменение процессов “на лету” (http://mainthing.ru/ru/item/163/), использование бизнес-правил и различные варианты позднего связывания подпроцессов (последняя тема еще ожидает раскрытия тут на блоге). Мы это все применяем на практике.

    А вот как быть со вторыми? Ожидания тут подогревается прогрессом в средствах коллективной работы, происходящему благодаря вебу. Хочется среды, в которой можно было бы обмениваться сообщениями наподобие почты или скорее форума, но при этом чтобы был контроль ответственного и сроков решения задачи и чтобы эта среда гладко стыковалась с движком BPM. Я себе это представляю как гибрид системы баг-трекинга и BPMS.

  7. Кузин Сергей 05.11.09 13:24

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

  8. Anatoly Belychook 05.11.09 13:36

    В заметке я привел два примера заранее непредсказуемых процессов. Похожи они на проекты? Как-то не очень. На классические повторяющиеся процессы впрочем тоже. Они одновременно и уникальные, и типовые: по составу шагов - типовые, а по последовательности - уникальные. Термин Гартнер “knowledge worker process” неплохо отражает суть дела. Повторюсь: на мой взгляд, это гибрид не процессов и проектов, а процессов и того, что называется “problem tracking”. Хотя гибриды процессов и проектов в природе тоже бывают, это отдельная интересная тема.

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

    “Теоретически, никакой разницы между теорией и практикой. На практике, однако, разница имеется.” :)

  9. Кузин Сергей 05.11.09 14:14

    :-) “На самом деле всё не так, как в действительности” Что ж, остаётся только подождать, чтобы увидеть, во что это выльется…

  10. Garth Knudson 06.11.09 17:21

    Anatoly, good article. HandySoft has spent about 5 years developing the market for dynamic/unstructured process execution. In 2004 we have many customers approach us to add more flexibility into process design and development. They needed to branch out of structured activities into ad-hoc tasks in order to gather information and get approvals. We built into BizFlow the ability to jump out of an activity to assign an ad-hoc task. The assignee could task another in a serial fashion. The following year a couple large Govenment agencies engaged HandySoft to extend ad-hoc tasking from simple serial activities into parallel processes in order to manage large, unwieldy projects. These agencies had to revert to email to manage projects, but with email they quickly lost visibility into action status and control over collaboration, deadlines, and follow-up. They wanted to keep the project within BizFlow becuase with BizFlow they have complete process visibility. And with BizFlow they can add rules that govern both structured and dynamic workflows. We worked with them to release a dynamic tasking application in 2006. In 2007 we incorporate the external tasking application directly into BizFlow. Now BizFlow BPM enable structured, ad-hoc and dynamic process execution.

    If you would like a demo, please let me know. We would like to get a customer in Russia to use the product.

  11. Виталий 24.06.16 16:33

    Здравствуйте! Что-то вы как-то очень вскользь на всей своей странице упоминаете о ситуативных (ad-hoc) процессах. Вы в них, наверно, сами ещё не разбираетесь? Очень бы хотелось об этом почитать на русском языке. В поисковиках на русском очень мало об этом написано. Или может я что-то не то ищу? Не могли бы вы об этом статью подробную написать? Или может быть хотя бы подробные книги на английском, а лучше на немецком посоветуете?

  12. Anatoly Belychook 24.06.16 17:25

    Вы комментируете запись от 2009 года.

  13. Виталий 25.06.16 11:53

    Анатолий Белайчук, я видел, что запись 2009 года ещё перед тем как отправить сообщение. Но если с тех пор ничего не поменялось, то я не думаю, что это имеет значение. Под страницей я имел ввиду всю страницу mainthing.ru, а не только эту статью. Пожалуйста, ответьте!

  14. Anatoly Belychook 02.07.16 21:31

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

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