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

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

Добавьте в закладки: bpmntraining.ru/news

Для тех, кто жалеет, что на этом блоге стало мало публикаций: я не перестал писать, просто по ряду причин теперь чаще публикуюсь на bpmntraining.ru.

Если вам интересны мои мысли по поводу BPM/N/S, подпишитесь на новости.

08.03.23 | Заметки |     Комментарии: закрыто

Информационные системы в BPMN: взгляд снаружи и изнутри

Мой самый популярный пост на bpmntraining.ru: Информационные системы в BPMN: взгляд снаружи и изнутри. » читать дальше

Событие-сообщение, сигнал или условие?

В своей недавней заметке Брюс Силвер поделился соображениями относительно условного события в BPMMN.

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

Рис. 1. Пример стартового события-условия.

Процесс стартует, когда указанное логическое условие становится истинным, т.е. когда зима вступает в свои права. (К слову, это реальное правило, действующее в Москве.)

Типичный пример промежуточного события-условия::

Рис. 2. Пример промежуточного события-условия.

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

Брюс пишет, что он предпочитает не пользоваться событием-условием и исключил его из “Method and Style” - сборника лучших практик моделирования, который он создал, поддерживает и рекламирует своей знаменитой книгой (лучше книгой по BPMN, на мой взгляд).

При всем моем уважении к Брюсу, которого я считаю своим учителем в BPMN, у меня другое мнение на этот счет: я считаю, что для определенных достаточно распространенных сценариев межпроцессного взаимодействия это лучшее решение. (Точнее, речь пойдет о промежуточном событии-условии; стартовое событие не представляет большой ценности и далее не будет рассматриваться.) » читать дальше

(English) BPMN None intermediate - throw or catch?

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

Второе пришествие 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 будет продолжать расти.

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

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

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

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

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

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

(English) Why BPM Lags Behind

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

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

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

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

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

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

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

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

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

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

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

См.также

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

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

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

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

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

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

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

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