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

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

Записи в рубрике ‘Статьи’

Второе пришествие BPM

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

В результате сформировался класс программного обеспечения BPMS — эта аббревиатура изначально расшифровывалась как Business Process Management System, затем, с легкой руки Gartner, System превратилась в Suite. На рынке BPMS представлены как «гранды» (IBM, Oracle, SAP, Software AG), так и десятки компаний ‒ узких специалистов (pure-play vendors). Появление программных продуктов Open Source стало свидетельством зрелости рынка.

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

Рынок BPM систематически отставал от прогнозов, а предложения вендоров превышало спрос. С этим надо было что-то делать — такое положение дел не могло устроить ни вендоров, вложившихся в разработку, ни аналитические агентства, чьи прогнозы оказались под вопросом.

Может быть, ошибочной была сама концепция BPM? Для сравнения: за 10 лет увлечения реинжинирингом было накоплено достаточно опыта применения, чтобы выявить и сильные, и слабые его стороны. BPM же практикуется уже почти 15 лет, но каких-то существенных изъянов в нем не обнаружилось и новой процессной парадигмы за это время не предложено.

Если только не считать таковой концепцию кейс-менеджмента (ACM, Adaptive Case Management).

Процессы для клерков и для креативных сотрудников: ACM

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

Ничего особенно нового в кейсах нет: когда в организацию приходит письмо и начальник «расписывает» его замам, а те, в свою очередь, ставят задачи подчиненным — это и есть кейс, т. е. просто «дело» на русском канцелярском. Или когда пользователь пишет заявку в техподдержку вида «не печатается отчет» — это ведь может означать что угодно, от закончившегося картриджа в принтере до планового обновления SAP. На верхнем уровне можно представить работу над заявкой в виде процесса — ввести первую и вторую линию техподдержки, определить нормативные сроки и SLA — но сами действия по устранению проблемы будут планироваться на ходу. Про кейс говорят, что он «развертывается во времени» — вы не можете заранее определить все, с чем столкнетесь, поэтому планируете только первый шаг, а по его результатам смотрите, что делать дальше.

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

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

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

В поисках правильного лейбла: iBPMS & Low-code

Если товар под старым лейблом продается плохо, а нового нет — надо обновить лейбл. В начале 2010-х Джим Сайнур из Gartner предложил новую аббревиатуру: Intelligent BPMS. По сути, речь шла о том, что современные BPMS обязаны были соответствовать общим ИТ-трендам, наметившимся к этому моменту: SMAC — Social, Mobile, Analytics, Cloud, т. е. поддержка социального взаимодействия, доступ с мобильного устройства, «облака», «продвинутая аналитика» (с последней ясности было меньше).

Вендоры, бывшие в числе «любимчиков» Gartner, с энтузиазмом поддержали это движение (кто сказал «сговор»?!), но надо признать, что такого единодушного признания, как исходная концепция BPMS, новинка не получила, и рейтинги iBPMS выпускает только Gartner. Хотя по факту все те BPM-вендоры, которые продолжали активно развивать свои продукты, добавили в них и мобильность, и «облака», и поддержку социального взаимодействия, и функциональность кейс-менеджмента.

Через несколько лет компания Forrester, вечный конкурент Gartner, предложила новый лейбл: Low-code, или системы с минимальным кодированием.

Ключевых идей в этой концепции можно выделить две: во-первых, центр тяжести усилий по разработке процессных бизнес-приложений переносится с программистов на аналитиков. Действительно, BPMS-системы, ориентированные на программистов, плохо соответствуют методологии BPM и из-за этого демонстрируют ограниченный успех. С точки зрения бизнеса это выглядит как всего лишь еще одна ИТ-система: раньше процессы кодировали в АБС или ERP, теперь в BPMS — что изменилось-то? (Тем более что АБС и ERP никуда не делись.) Чтобы BPM дал эффект, должен измениться стиль взаимодействия между бизнесом и ИТ, старая модель «бизнес пишет ТЗ и перебрасывает его через стену в ИТ-отдел» должна смениться аджайлом с его быстрыми итерациями и тесной вовлеченностью бизнеса в проектирование бизнес-процессов.

Чтобы этого добиться, нужно минимизировать объем кодирования, максимально использовав программирование от графических моделей и сделав среду разработки максимально дружественной по отношению к «гражданским» разработчикам. Другими словами, это должен быть не Eclipse, java и XML, а разработка от диаграммы BPMN, простой и удобный редактор форм, и желательно, чтобы все это было реализовано в браузере.

Во-вторых, системы Low-code не зациклены на процессах, ведь при всей важности процессной логики, корпоративные приложения состоят не только из нее. Сложилась странная ситуация: в любой системе BPMS есть средства проектирования базы данных и редакторы экранных форм, но воспользоваться ими, чтобы разработать традиционное приложение для ведения банального учета, например, нельзя — вы должны все делать через бизнес-процессы. Это нелогично, и в системах Low-code это ограничение снято.

При этом использование реляционных баз данных здесь нецелесообразно, ведь скорость внесения изменений — не самая их сильная сторона. Например, в графовой базе добавить атрибут можно мгновенно, без реконфигурирования. Также графовая база умеет отвечать на запросы вида «покажи все процессы и задачи, связанные с данным бизнес-объектом — машиной, клиентом, товаром…».

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

Идея минимального кодирования не нова — SQL в свое время создавался под этим же флагом: иметь возможность обращаться к БД без программирования, на языке, максимально близком к естественному человеческому. Также можно вспомнить аббревиатуру RAD — Rapid Application Development. Так что системы Low-code продолжают давнюю традицию.

Идея Low-code оказалась удачной — ее хорошо восприняли и заказчики, и вендоры. Кое-кто пошел дальше, заявив о Zero-code или No-code, но это больше похоже на маркетинговый шум, чем на работающую технологию.

BPM и цифровая трансформация

Концепция BPM- и BPM-систем, предложенная без малого 15 лет назад, выдержала проверку временем. Но проблема тех, кто ее предложил и развивал тогда, в том, что они «бежали впереди паровоза» — пусть концепция у вас правильная, но большого спроса на нее не будет, пока есть более простые способы повышения эффективности бизнеса, начиная с банального сокращения персонала и наведения порядка в управленческом учете.

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

Человек, однажды воспользовавшийся услугами Яндекс-такси или сервисом Google docs, уже не будет прежним. И когда он приходит к себе на работу, у него возникают вопросы: «Какого черта?! Почему в туалете почти неделю течет кран, а моя бумажная заявка ходит неизвестно где? Почему я не могу сфотографировать на смартфон, отправить заявку одной кнопкой так же, как я одной кнопкой вызываю такси, и на смартфон же получить отчет о том, что кран починен или заменен?» (Кстати, это реальный кейс.)

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

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

Таким образом, сегодня можно говорить о «втором пришествии» BPM — второй волне интереса к процессной методологии и информационным технологиям, поддерживаемым стремлением современного бизнеса к цифровизации своих операций.

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

Вторая новость — очень хорошая: это надолго! Речь ведь не идет о том, чтобы заменить старые «аналоговые» бизнес-процессы на новые «цифровые» и на этом успокоиться — прогресс в области цифровизации ускоряется! Вчера это были приложения на смартфонах и «облака», сегодня — элементы искусственного интеллекта, чат-боты, интернет вещей, завтра — беспилотный транспорт и самые разнообразные роботы. Все это потребует массовой и быстрой перестройки бизнес-процессов, а значит, спрос на компетенции и информационные технологии BPM будет продолжать расти.

Межпроцессное взаимодействие с помощью события-условия

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

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

(English) Why BPM Lags Behind

Этот контент доступен на языках: English.

Необходимые и избыточные элементы BPMN: события

В прошлой заметке мы выяснили, что при всем многообразии развилок в BPMN, строго необходимыми являются две из пяти: “или/или” и “и”.

Перейдем к событиям. События в BPMN классифицируются по типу (13 вариантов) и по месту (8 вариантов). Рассмотрим классификацию по типам:

1. Простое событие

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

Тонкий слой под названием “процесс”

Как это не парадоксально, но термин “процесс” остается самым неоднозначным в BPM - недавняя дискуссия на форуме BPM.com это наглядно демонстрирует.

  • Когда мы разрабатывали профстандарт, одно из рабочих вариантов названия было “Специалист по управлению процессами”. И на одном из обсуждений мы получили замечание: “Уточните, о каких процессах идет речь - процессами пищеварения вы собираетесь управлять?” В самом деле, на бытовом уровне мы процессами называем все что угодно, от пищеварения до образования галактик.
  • Среди консультантов по управлению распространен взгляд на процессы как на любую упорядоченную деятельность, нацеленную на получение определенного результата. В таком определении есть смысл - если в фокусе нашего внимания находится эффективность бизнеса, то для нас нет большой разницы между деятельностью в рамках функциональных подразделений, кросс-функциональных процессов или проектов. Но если погружаться в конкретику, то такое определение процесса становится непродуктивным: конечно, мы можем принять, что проект - это тоже процесс, просто нацеленный на однократный результат, но методы управления проектами и процессами ведь существенно разные, как ни крути. К слову, в последнее время для обозначения широкого спектра деятельности вместо термина “процесс” стали употреблять “бизнес-способность”. Мне этот термин нравится, поскольку позволяет объединить процессы и проекты, не сливая их в одно.
  • В контексте BPMN определение процесса сужается еще больше. Во-первых, в BPMN есть четкая разница между процессом и подпроцессом: первый инициируется внешним событием (сообщением, таймером или просто волевым решением), второй вызывается. Во-вторых, BPMN в упор не видит уровни выше отдельного процесса - такие сущности, как, например, “цепочка создания ценности”, “вспомогательные бизнес-процессы” или “продвижение продукции”. В BPMN нет средств для моделирования групп процессов.

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

См.также

Необходимые и избыточные элементы BPMN: развилки

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

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

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

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

Начнем с развилок.

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

Потоки сообщений, события-сообщения и задачи-сообщения

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

Опасно! Не пытайтесь повторить.

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

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

Неправильно:
email через сообщение
Правильно: email через пользовательскую задачу
(ручной процесс)
Правильно: email через задачу-сценарий
(процесс, реализованный в BPMS)

Если вам надо показать, что какая-то задача взаимодействует с внешним миром (например, с заказчиком или поставщиком), то можно использовать пул - черный ящик и сообщения, прикрепленные непосредственно к задаче:

Но лучше не засорять диаграмму потоками сообщений и черными ящиками. Ведь если задача называется “Get customer’s commitment”, то и так понятно, что она взаимодействует с клиентом:

Использование черных ящиков и сообщений имеет смысл только в одном случае: если вам надо отобразить ВСЕ сообщения, входящие в / исходящие от внешнего контрагента, чтобы специфицировать “коммуникационный контракт” с ним.

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

BPMN с ручным приводом

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

В качестве примера, исполнитель A должен передать эстафетную палочку либо B, либо C в зависимости от результатов выполнения назначенной ему задачи Task 1:

Исполнитель A должен отдавать себе отчет, что он отвечает за исполнение не только задачи, но и следующей за ней развилкой “или-или”. Он должен знать и понимать что означает следующий элемент и как его обрабатывать. В примере выше это достаточно очевидно - догадаться, что это развилка, способен каждый - но другие элементы BPMN не столь очевидны.

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

Задачи на вызов сервиса, задачи на выполнение сценария? Забудьте, они вам не понадобятся; автоматическая процедура, запускаемая пользователем - это пользовательская задача, а не сценарий или сервис.

Элементы BPMN, которые можно рекомендовать для использования в процессах, которые будут исполняться без движка:

  • пулы и дорожки
  • объекты данных, хранилища данных, потоки данных
  • аннотации и ассоциации
  • потоки управления и потоки сообщений
  • задачи: пользовательские и ручные; никаких сценариев, сервисов, бизнес-правил, отправки и получения сообщений
  • цикл по объектам необходим; стандартный цикл избыточен и поэтому не рекомендуется
  • подпроцессы: встроенные и повторно-используемые, только свернутые (развернутые не рекомендуются), “по требованию”; подпроцессы-обработчики избыточны, сложны и поэтому не рекомендуются
  • развилки: “или-или”, “и”; никаких комплексных и по событиям; развилки “и/или” избыточны и нетривиальны и поэтому не рекомедованы
  • события: простое, таймер, сообщение (включая прикрепленные прерывающие и непрерывающие), останов, ошибка
  • полностью за рамками: транзакция, компенсация, отмена

Дополнено: задачи-сообщения и события сообщения лучше оставить за рамками сокращенной палитры. Подробнее о сообщениях в BPMN >>

Как видим, лишь небольшое число элементов BPMN пригодны для использования в схемах процессов, которые будут исполняться вручную.

С другой стороны, поразительно как много можно смоделировать даже со столь ограниченной палитрой. Чем более профессиональны вы в BPMN, тем меньше элементов вы используете на постоянной основе.

Быстрая разработка в эпоху Digital

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

Для бизнеса эти изменения в ожиданиях потребителя являются вызовом такого масштаба, аналог которому и не подберешь. Под каток «цифрового переворота» (Digital Disruption) попадают отрасль за отраслью: сначала электронные СМИ и индустрия развлечений (цифровой аудио- и видеоконтент), за ними розница (онлайновые гиганты Amazon, Aliexpress) и телекоммуникации (проводная связь стала анахронизмом). На наших глазах перекраиваются рынки финансовых услуг (онлайн-банкинг и финтех) и образования, гостиничный (booking.com, Airbnb) и транспортный (Uber, Yandex-такси). На очереди — производство (встраиваемые датчики, Интернет вещей, 3D-печать) и здравоохранение (носимые датчики). » читать дальше

(English) BPM Maturity Model: Go Deep vs. Go Wide Strategy

Этот контент доступен на языках: English.

08.05.16 | Статьи |     Комментарии: закрыто

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