Business process management system что это
Сравнительный обзор BPM-систем
На внедрение любой IT-системы требуется много времени, сил и средств. А когда речь идет о таком глобальном решении, как BPM-система, внимания приходится уделять еще больше.
Нельзя запускать проект, опираясь на возможности наскоро выбранного продукта и обещания вендора, есть масса аспектов, которые нужно обдумать и взвесить. А последствия неправильного выбора и осознание своей ошибки уже во время работы, «на половине пути» может стоить дорого.
При выборе BPM-системы нужно опираться на требования ваших процессов и учитывать возможности по дальнейшему их развитию и улучшению. Надеюсь, что этот обзор поможет быстрее сориентироваться, какая система подходит именно вам, и сделать свой выбор, исходя из ее функциональных особенностей.
Обзор BPM-решений
Рассматриваемые BPM-решения: ELMA BPM Suite, Bizagi BPM Suite и Bonita Open Solution. Все они являются популярными и востребованными. Кроме того, данные решения во многом схожи функционально.
Рассмотрим их главные компоненты:
В статье мы рассмотрим реализацию этих возможностей, а также:
Моделирование бизнес-процессов
ELMA BPM
ELMA BPM – разработка российской компании ELMA, предназначенная для управления бизнес-процессами.
Моделирование бизнес-процессов в системе ELMA осуществляется в специальном графическом редакторе «Дизайнер ELMA» в нотации BPMN 2.0, которая, к слову, была целиком переведена на русский язык именно специалистами данной компании и доступна для свободного скачивания на сайте ELMA.
После создания графической модели, выбора параметров процесса и определения данных, с которыми работает бизнес-процесс, он публикуется на сервере системы и становится исполнимым в веб-интерфейсе. Каждый запущенный экземпляр бизнес-процесса создает пользователям системы карточки задач, в которых они должны отчитываться о своей деятельности. Карточки, кстати, гибко настраиваются, поэтому с ними удобно работать.
Почти все действия для автоматизации исполнения бизнес-процессов можно сделать мышкой, но иногда приходится прибегать к скриптам. Для реализации наиболее сложных вещей можно использовать сценарии, то есть программирование. Плюс в том, что сценарии создаются на популярном языке C#, так что разобраться в написании скриптом для ELMA не составит труда. И специалистов, знающих этот язык, на рынке предостаточно.
К сожалению, вендоры очень часто вставляют в свой софт какие-то собственные языки, руководствуясь ошибочным представлением, что там работать легче. В итоге получается такая система, под которую найти разработчика просто невозможно. На рынке их может вообще не быть, поэтому остается два варианта – или идти к тому же вендору за помощью (на то он наверняка и рассчитывает), или пытаться вырастить своего специалиста (что, опять же, без привлечения вендора почти нереально).
Поэтому использование популярного языка смело можно назвать большим плюсом системы.
В ELMA поддерживается импорт и экспорт в формат XPDL – это универсальный формат, который позволяет выгружать и загружать модели бизнес-процессов.
Попробовав в качестве эксперимента загрузить в ELMA процесс, ранее нарисованный в Business Studio, убеждаюсь (после небольших доводок), что все работает без каких-либо проблем.
Добавлю, что в системе ELMA реализована отладка процессов и инструменты для их тестирования (верификации). При публикации модели процесса автоматически выполняется верификация синтаксиса – проверка правильности модели и проверка сценариев на наличие ошибок.
Кроме того, в отличие от остальных решений, в ELMA возможна пошаговая отладка процессов, сценариев и пользовательских форм, что экономит массу времени.
Рис. 1. Интерфейс графического редактора «Дизайнер ELMA»
Рис. 2. Форма заполнения заявки (в режиме отладки) в системе ELMA
Процессы в ELMA можно непрерывно улучшать, причем прямо «на ходу», без остановки исполнения. Так что есть возможность учитывать все особенности организации.
Если в системе обнаружены «проблемные» процессы или наметился срыв показателей, то есть два варианта устранения проблемы:
улучшение текущего процесса (постоянные улучшения) с последующей оценкой показателя, или изменение самого показателя процесса.
Возможно, плановое значение изначально задано неверно, и стоит его скорректировать, как и сам процесс.
Также всегда можно вернуться к более ранним версиям и просмотреть историю улучшений бизнес-процесса – система хранит все версии. Вносить изменения в процессы можно даже после внедрения этих процессов в работу. Вы быстро вносите коррективы в структуру процесса и сразу проверяете эффективность изменений на практике.
Следующий участник обзора – Bizagi – тоже отличается своими механизмами исполнения процессов.
Bizagi BPM Suite
Система весьма известная и популярная. Bizagi BPM Suite состоит из компонентов, выполняющих отдельные функции:
Моделирование бизнес-процессов осуществляется в нотации BPMN. Поддерживается наиболее полный уровень соответствия спецификации BPMN. Но самая сильная сторона продукта – красочный графический редактор.
«Рисовать» простые схемы удобно, но как только увеличивается их сложность, так возникают трудности, например могут быть потеряны описания событий и потоков, либо объекты при копировании «приклеиваются» друг к другу, и в таком случае помогает только загрузка предыдущей версии схемы.
Есть возможность коллективного проектирования. Готовая модель процесса загружается в Bizagi Studio, где можно определить всю информацию, нужную для автоматизации процесса. Этот же модуль позволяет интегрировать систему с прочими корпоративными приложениями. Автоматизация процессов осуществляется в графических интерфейсах, необходимость программирования есть только при спецификации скриптовых задач.
Далее автоматизированный процесс загружается на сервер, где происходит его дальнейшее исполнение. Эта процедура несложная в том случае, если вы хорошо ознакомились с документацией. Сходу догадаться о многих нюансах непросто.
В веб-интерфейсе выполняются пользовательские задачи и производится контроль исполнения процесса. Система создает подробные отчёты по процессу в целом и отдельно по каждой задаче. Отчёты доступны в веб-интерфейсе.
Внесенные изменения процесса в модуле Studio немедленно отражаются на сервере, и все запущенные экземпляры процесса начинают работать по новой модели, без остановок.
Bizagi дает возможность обмена моделями между приложениями, поддерживается импорт и экспорт в форматы XPDL и MS Visio.
Рис. 3. Моделирование процессов в Bizagi BPM Suite
Затрудняет работу необходимость постоянного переключения между окнами редакторов, при таком количестве окон требуется постоянная смена фокуса внимания. Это все очень сложно, особенно, для человека, впервые открывшего систему.
Важно учесть, что Bizagi BPM Suite испанская разработка, и в России у компании нет официального представительства. Это довольно серьезный недостаток, ведь когда вендор находится в другом государстве, тяжело внедрять его продукт.
Bonita Open Solution
Bonita Open Solution – французский вендор. Представительства в РФ, как и у предыдущего решения, нет. Не так давно, по некоторым данным, была переведена только пользовательская часть системы, в целом, российской локализации нет.
В opensource-версии системы отсутствуют средства мониторинга процессов. В свою очередь, в коммерческом варианте системы они есть. Решение состоит из трёх основных компонентов, разделенных по назначению:
Моделирование процессов Bonita Open Solution происходит в нотации BPMN. Поддержка нотации довольно полная. Решение поддерживает импорт диаграмм из формата XPDL, но без возможности экспорта в него. Также нет и поддержки BPEL.
Моделирование и автоматизация процесса в Bonita Studio производится в одном окне, что очень удобно. Выбор данных и участников, генерация интерфейсов к этапам процесса производится в том же окне, что и создание графической модели. Нет необходимости постоянно переключаться между окнами редакторов, это ускоряет разработку процесса.
Рис. 4. Моделирование бизнес-процессов в Bonita Studio
Интеграция с другими корпоративными приложениями
ELMA BPM
Одно из неоспоримых преимуществ BPM-систем – возможность интеграции с различными программными решениями. Они позволяют увеличить гибкость создаваемых моделей бизнес-процессов. В частности, применяется SOA – Сервис-ориентированная архитектура, позволяющая легко интегрировать модели бизнес-процессов в другие приложения.
В системе ELMA есть средства интеграции с основными корпоративными приложениями (SOA, CRM, почтовые сервисы, оповещения на почту и по sms). Для российских пользователей плюс системы состоит в тесной интеграции с «1С: Предприятие». У системы богатая поддержка работы с веб-сервисами, что полностью задокументировано разработчиком. Поэтому интегрировать ELMA с любой внешней системой не составляет труда. Кроме того, есть поддержка работы с сервисной шиной (ESB) и интеграция с шинами передачи данных на уровне моделирования бизнес-процессов (JMS, MSMQ). Портлеты ELMA встраиваются в корпоративные Порталы: SharePoint, Bitrix.
Bizagi BPM Suite
Стоит отметить гибкие возможности BizAgi BPM Suite по интеграции с внешними системами и приложениями. Эти возможности позволяют связать процессы с любой другой системой. Такие возможности конфигурации включают в себя различные механизмы на уровне интеграции данных и на уровне процессов. Поддерживаются следующие виды интеграций:
Bonita Open Solution
BOS может взаимодействовать с большим количеством приложений и сервисов с помощью программных соединителей – коннекторов. Поддерживаются базы данных, почтовая служба, веб-сервисы и др. Коннекторы позволяют системе подключаться к внешним базам данных (к примеру, данные справочников, информация о заказах или клиентах), а также получать информацию из внешних систем в интерфейс процесса и записывать данные во внешние системы по результатам исполненного процесса.
Интерфейс
ELMA BPM
Интерфейс системы в целом удобный, простой и понятный. Это касается всех ее компонентов. К ней легко адаптироваться, потому что интерфейс Внутреннего Портала одинаковый для работы со всеми приложениями системы. Его можно легко сделать очень простым и удобным для конечных пользователей. Любая информация может отображаться в красивом и понятном формате.
Рис. 5. Создание заявки в интерфейсе системы ELMA 3.5
Настраиваются и формы задач, и документов, и карточек произвольных объектов. Для разных групп пользователей система может выглядеть по-разному. Есть конструктор форм, который работает без дополнительной верстки html-страниц.
В интерфейсе портала можно работать с мобильных устройств (смартфонов и планшетов). Кроме того, в интерфейсе возможно настроить аналитику и другие функции портала.
Bizagi BPM Suite
Пользовательский интерфейс Bizagi BPM Suite представляет собой набор настраиваемых форм, которые привязываются к операциям бизнес-процесса и отображаются для получения и ввода данных при выполнении соответствующей операции.
Часто систему позиционируют как имеющую простой и интуитивно понятный интерфейс, но мне сложно с этим согласиться, да и в интернете есть много высказываний о том, что настройка интерфейсов сопровождается сложностями (в основном это низкое быстродействие, трудности с выделением и перемещением объектов, добавлением подписей и др.) Нет как таковой настройки портала, внешнего вида главных страниц, как, например, это реализовано в ELMA. Конструктор экранных форм Bizagi подходит для быстрого создания и ввода данных в рамках процесса, но с ограниченной сложностью презентационной логики. На более сложные задачи уходит больше времени и сил.
Рис. 6. Интерфейс системы Bizagi
Bonita Open Solution
Продукт имеет удобный графический интерфейс для моделирования бизнес-процессов. Можно моделировать бизнес-процессы и создавать собственный интерфейс. В Bonita Studio встроен графический конструктор экранных форм Bonita Form Builder, он позволяет создавать веб-интерфейсы для работы с бизнес-процессами.
С помощью конструктора Bonita Form Builder возможно изменять внешний вид интерфейса для конечного пользователя. Bonita Portal позволяет протестировать разработанный бизнес-процесс в веб-интерфейсе, настроить права доступа пользователей к процессам. В веб-интерфейсе портала пользователи получают задачи и работают с экранными формами, разработанными в Bonita Form Builder, также интерфейс портала доступен пользователям с мобильных устройств (смартфонов и планшетов). Дополнительно в интерфейсе возможно настроить аналитику и другие полезные функции портала.
Рис. 7. Интерфейс Bonita Studio
Недостатки систем
Нотация BPMN 2.0 русифицирована, и русские названия элементов модели процесса значительно облегчают общение с бизнес-пользователями, но соответствие нотации у ELMA BPM менее полное, чем у Bizagi. Разработчики ELMA сконцентрировались только на тех элементах, которые реально можно автоматизировать, а поддержка неисполнимых элементов довольно слабая.
При этом всё актуальнее для компаний становится вопрос реализации нотации BPMN, поскольку неполная ее поддержка может затруднять пользователю разработку модели процесса. Графический редактор системы довольно тяжелый. Если нужно просто сделать что-то неисполнимое, приходится ставить большую тяжелую систему, ждать пока запустится сервер, все это требует времени.
Bizagi BPM Suite
У Bizagi тяжелый интерфейс. Конечно, удобно рисовать процессы, но со всем остальным дела обстоят хуже. Тяжело адаптироваться к системе. Нет средств верификации процессов, это при том, что система позволяет моделировать весьма сложные процессы, которые требуют проверки. Нет и возможности симуляции бизнес-процессов, поэтому увидеть, как процесс исполняется, можно лишь исполнив его.
Процедура запуска процессов в работу в целом более сложная. Для этого требуются квалифицированные специалисты. В лучшем случае этим занимаются специалисты вендора, который находится как правило в существенном удалении. Партнеров, которые находятся в России и смогут помочь, крайне мало, и их квалификация зачастую вызывает сомнения.
Bonita Open Solution
Нет средств статической верификации процессов (доступна их симуляция с различными параметрами и формированием отчётов по результатам).
Недостатком BOS также является отсутствие поддержки динамического изменения бизнес-процесса, затрудняющее оптимизацию процессов. Данное упущение является существенным для BPM-системы, поскольку после запуска системы в работу любое изменение намного сложнее реализовать. Возможность изменения процесса во время его исполнения входит в число ключевых концепций BPM.
Пользователи отмечают сложности с использованием русского языка в системе. Если название процесса написать русскими символами, он не находится при запуске в отдельном окне. Нельзя прописать по-русски и элементы процесса, поскольку может возникнуть конфликт имен при совпадении количества символов в пределах процесса. Все имена в таком случае переводятся на английский язык и символы заменяются на «нижнее подчеркивание». Цветовая гамма – красный, черный, белый… И вообще, внешний вид системы какой-то агрессивный. Думаю, это очень сильно утомляет, к тому же нельзя быстро его перенастроить.
Стоимость систем
Есть бесплатная версия на пять рабочих мест. Также вендор предлагает коммерческие версии: легковесную Экспресс-версию на бесплатном СУБД Firebird. В качестве базовой предлагается «Стандарт» версия на MS SQL. Версия Стандарт стоит примерно в полтора раза дороже «Экспресса».
Стоимость лицензии – менее 10 тысяч за 1 рабочее место. А в случае с версией «Экспресс» — значительно ниже.
Также ELMA предлагает корпоративную версию, которая поддерживает кластерную архитектуру для обеспечения высокой производительности в больших организациях. Данная версия работает как на корпоративной версии MS SQL, так и на Oracle. Цены на корпоративную версию на сайте разработчика найти не удалось.
Bizagi BPM Suite
Система доступна в двух вариантах:
Enterprise Edition. Корпоративные решения BizAgi BPMS разработаны для крупных предприятий. Они обеспечивают все функции, необходимые в большом количестве BPM проектов. В системе могут работать от сотен до тысяч пользователей.
Xpress-издание – BizAgi BPMS Xpress – сравнительно недорогое решение для малых и средних предприятий. Позволит оценить преимущества BPM небольших (пробных) проектах, прежде чем начать работу со всеми функциями BPM. BizAgi BPMS Xpress может одновременно использовать максимум только 50 пользователей.
Стоимость лицензий – около 100$ за одного пользователя.
Bizagi Process Modeler – дизайнер бизнес-процессов распространяется бесплатно.
Bonita Open Solution
Решения системы – Bonita Portal, Bonita Studio и Bonita Engine платные, на официальном сайте есть подробное описание всех модулей, но нет информации по их стоимости. Есть бесплатная Opensource-версия.
Выводы
Все три рассмотренные системы достаточно близки функционально и нельзя сказать, что какая-то намного лучше или хуже другой. У каждой из них есть свои недостатки и преимущества. Например, отладка бизнес-процессов есть только у ELMA, а в остальных системах данный механизм не реализуется.
За красотой интерфейса в ряде систем скрывается неудобная настройка. Усложняет внедрение BPM-решений и территориальная удаленность вендоров. Что же касается функциональных возможностей, здесь во многих вопросах, конечно, Bizagi держит уверенное первенство. Но, что особенно приятно, отечественная разработка – ELMA BPM уже не только может поравняться силами со своими западными коллегами, но и в чем-то их превзойти.
Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
Продолжаем размышлять «что такое BPM», это который «Business Process Management» и какие они бывают. Парадокс: про него столько уже десятилетиями понаписано — книжек, статей, дискуссий, но что это такое – сегодня так и остаётся загадкой, причем: чем больше пишут – тем более загадочнее становится.
Не помогают ни книжки из серии «Для чайников», ни заветы CBOK, ни магические квадраты от Гартнера (BPM: BPA, BPMS, iBPMS и т.п.), в которых, как и в черных квадратах Малевича (а у него только черных было несколько «разных» вариантов) – каждый норовит увидеть что-то великое и таинственное, ведомое только ему.
В главе предлагается вариант классификации BPM-подобных сущностей. В информационной войне с «алхимией 21 века» продолжаем развенчивать популярные мифы о Business Process Management, Enterprise Architecture (ЕА) и иже с ними. Делаем очередной шаг на пути становления BPM как обычной (повседневной, повсеместной, тривиальной) инженерной дисциплины: process technology, «процесс-техника».
В первой главе «Бизнес-процессы: Как все запущено и запутано» мы посмотрели на «BPM» глазами маркетинга и показали его ключевые мифы. На станицах cnews (см. комментарии к статье) подискутировали на тему «BPM – EA – Alchemy».
Во второй главе попытались отделить «мух от котлет» и показали крайности (головы и хвосты): BPM это не про бизнес-менеджмент (там скорее что-то «из опер» BIZBOK-ов, BABOK-ов и т.п.) и не про «ИТ-фишки» (SOA, ESB и иже с ними). BPM даже не про автоматизацию, что на классических языках программирования (от «си», до «явы» под контролем SWEBOK-и), что на «новомодных» инструментах, — основанных на BPMN или даже на «ничего» («no code», где якобы кодить не нужно). Обсуждение второй главы с участием «Алхимика 80-го уровня» на bpmsoft.org
Когда половина «умной книжки про BPM» посвящена SOA, ESB и т.п., думаешь: если их нет в компании, то и BPM в компании тоже невозможен? Или: будет ли «жить BPM» в компании, где нет (мало) автоматизации? На эту тему фрагмент из книжки Управление бизнес-процессами. Практическое руководство по успешной реализации проектов
Глава 2 Что такое управление бизнес-процессами
На этот вопрос надо ответить в самом начале, тем более что у каждого поставщика, аналитика, ученого, преподавателя, журналиста и клиента имеется свой ответ на него.
Хотелось бы сразу разъяснить, что, по нашему мнению, BPM не приравнивается к технологическому инструментарию или инициативному проекту в области бизнес-процессов. Наш опыт подсказывает, что значительное усовершенствование бизнес-процессов может быть достигнуто и без применения технологий автоматизации.
Послание «Чайникам» от IBM.
Какие же откровения нам поведал голубой гигант в своей Business Process Management For Dummies, IBM Limited Edition?
Введение и первая глава: написаны в стиле: «Счастливые обладатели BPM», «Только BPM может помочь вашей организации стать …» (выше, дальше, сильнее и т.п.) … супер-пупер и т.п. Причем в рекламной стилистике книжки так и напрашивается подмена созвучного термина «BPM» на «IBM», без какого-либо изменения смыслового содержания (точнее рекламы): «Если вы дочитали главу до этого момента, то вам теперь ясно, что BPM (точнее IBM) — это круто».
Собственно этому подходу была посвящена целая глава «Бизнес-процессы: Как все запущено и запутано. Глава первая». Одним словом, всем «чайникам» после прочтения «BPM для чайников» должно стать ясно, что им очень нужен BPM (это же «круто»), но что это такое знать им не обязательно (в книжке я не нашел ответа). Остальные главы вторят то же самое и, конечно, далее дается «гениальный» вывод, что «IBM предлагает самый широкий спектр решений BPM». Неудивительно, что «правильный BPM» = IBM BPM. По секрету скажу, что настоящего BPM у IBM вообще нет.
Послание «Чайникам» от нового хозяина ARIS. Продавать BPM нужно, поэтому не только вендоры, но и продажники делают книжки для «Чайников»: BPM Basics
For Dummies Software AG Special Edition
В указанных «основах» собрано все: адаптивные и гибкие процессы, визуализация и управление сквозными процессами в реальном времени (даже оркестровка и хореография процессов в real-time и кросс-функциональная видимость), «автоматизация — симуляция — оптимизация», связь по формуле <люди, информация, услуги, системы, процессы>.
Конечно не забыты Непрерывное совершенствование процесса (CPI), Real-time monitoring (BAM), KPI-BSC и т.п., а также недавно «пришитые» к BPM: WYMIWYR и DMAIC.
Типовая ошибка в книжке, где сказано, что «BPM является широкой дисциплиной». BPM должна быть «узкая», конкретная и понятная дисциплина. Только это позволит сделать ее практической и повсеместно применяемой инженерной дисциплиной. Вынесите смежные области, придумайте к BPM «чердаки» и «подвалы», составьте четкий стек BPM (по аналогии сетевым протоколам), но не нужно под вывеской «broad discipline» мешать все в одну кучу.
Пока же нам преподносят «слишком большой BPM, что бы его можно было понять» (слишком большой, что бы его съесть).
Если сперва сказали, что BPM — это «инфраструктура бизнеса» (это верно), то видимо этому и нужно следовать, а не смешивать инфраструктуру с бизнесовыми сущностями и не рассматривать в BPM «The BPM Business Architecture».
3 Общая классификация BPM
3.1 Популярные взгляды на классификацию BPM
Одни говорят, что BPM — это просто философия менеджмента, позволяющая сфокусировать внимание на процессах или стратегия руководства для успешной трансформации бизнеса, другие, что это некая многоликая дисциплина: то ли документирования, то ли разработки, то ли внедрения, то ли еще чего, но под универсальным термином «дисциплина управления». Третьи (артисты видимо) уверяют, что это нечто, лежащее рядом с SOA и Web 2.0 и любят упоминать про оркестровку и хореографию.
Чаще всего: BPM преподносится в «трех лицах», где бизнес-процесс:
— задокументировали и проанализировали (design & analysis tools);
— сымитировали и промоделировали (simulation engine);
— развернули и исполнили (execution engine).
Рядом стоит «прислуга»: dashboard, repository и т.п., а в VIP-ложе: CPI, BSC-KPI и т.п.
Популярные, но «раскосые» взгляды профи на классы BPM (направления и соответствующие инструменты) предполагают цветную картинку из набора многочисленных и известных маркетинговых терминов.
Показательный пример запутанности и не «простого и понятного» BPM приведен на рис. 3.1. Взгляд на BPM из KPMG
Подобных архитектур и представлений о BPM много, как и этой: яркой, красивой картинке (дизайнерам – презентаторам пятерка), но непонятной.
Рис. 3.1 Взгляд на BPM из KPMG
На Рис. 3.2 показана картинка с www.what-is-bpm.com, где отражен более понятный (хоть и менее «художественно») подход к классификации BPM — инструментария.
Рис. 3.2 Взгляд на BPM – инструментарий из what-is-bpm.com
Картинка читается примерно так (немного с иронией, чтобы лучше донести ее суть):
1) от Understanding — понимания своих процессов («знай свой процесс»), что поддерживаются составлением карт процессов (Process Mapping) и инструментами документирования;
2) к совершенствованию процессов — через Analysis (куда же без анализов то?) и имитационное моделирование (не путать с просто «моделирование» = «документирование» в контексте Understanding);
3) к автоматизации \ модернизации (эдак их почти синонимами сделали) через BPMS разновидности, с интеграцией через SOA и разработкой «прикладных гибридов и композитов»;
4) и непременно, — все это «постоянно оптимизируя» и реинжинеря, снова оптимизиря и снова «переосмысливавшая коренным образом», т.е. зацикливая процесс на непрерывное – «вечное» совершенствование. Не понимаю, зачем так нужно – видимо в таком BPM «тормозов нет» (забыли предусмотреть), но во многих книжках именно так написано.
К тому же, в чем отличие п. №4 от п. №2?
Небольшая добавка: если ВСЕ ЭТО нужно для «небольшой тусовки» (workgroup), – то всего вышеуказанного «сыпь понемногу», а если для «крутого» Enterprise-Wide – то «помногу» (вектор «Scope» показывает «Масштаб»), плюс еще нужен репозита(о)рий процессов и некое «взаимодействие процессов» (самая верхняя «плюшка»).
3.2 Упрощенная классификация BPM-систем
Учитывая разнообразие BPM-направлений исключим из рассмотрения BPM составляющие, непосредственно не относящиеся к описанию процессов, такие как: совершенствование (CPI), оптимизация, всевозможное не четко формализованное «управление» и т.п., а сконцентрируемся лишь на описании процессов и простейшем их анализе (без «бизнес-составляющей»).
Т.е. BPM в терминах «процессный уровень», «процесс-техника», показанными во Второй главе настоящего цикла.
Выделим три направления:
— базовый BPM, «BPbase», — в основе которого лежат:
— — формализация БП, «BPdoc» и
— — вторичная обработка и анализ формализованных сущностей, BPana;
— симуляция БП, «BPsim»;
— исполнение БП, «BPexe».
Задача BPdoc — формализовать процессы (показать образы реальных процессов в виде схем). BPsim — «оживить» процессы через динамическую модель процесса или отразить характеристики процесса на статических моделях (не описание и регламентация).
BPexe — нужен чтобы получить исполняемый программный код, т.е. «сделать процесс программой». «Светлая мечта» любой автоматизации (мечта №1), включая BPexe «сделать сказку былью», — это когда ВСЯ логика «зашита» в исполняемом коде и вся работа оператора ЭВМ (участие в бизнес-процессе исполнителя) сведена к одному нажатию «большой красной кнопки».
Рис. 3.3 Упрощенная классификация BPM-систем
В исходном качестве
Классификацию поясняет следующая «танковая» аналогия:
— BPdoc — изображение танка как рисунка или чертежа. В случае эскиза или наброска, выполненного мазками (импрессионизм), — понятного только при взгляде «издалека» (с высоты птичьего полета, high-level). В случае рабочего чертежа (т.е. по которому можно работать) — как комплект конструкторской документации (танк в AutoCAD): возможна любая детализация, вплоть до всех размеров и разрезов (разрезов процесса), «поворот процесса» (можно «крутить» процессы) и т.п., картинка процесса в 3D (точнее в n — измерениях, плоскостях) и т.п. Это «конструкторская документация» на процесс (в терминах ЕСКД), процессная документация «в бумаге», рабочий проект на изделие «процесс», спецификация процесса и т.п.
— BPsim — уменьшенная модель танка с дистанционным управлением: вроде бы игрушка, но «движется и стреляет пластмассовыми пульками». Такой танк похож на настоящий — все детали точь в точь (реплика), можно даже массогабаритный макет выполнить, но на фронт его не отправишь (только как ложную цель). Другой пример – это игрушки с «крутой физикой» типа World of Tanks или профессиональные авиа\авто\танковые-симуляторы. Тоже — все почти как настоящее, но входные данные (высота, скорость) — вымышленные (расчетные) и здоровью (реальному процессу) не навредить «если что-то пойдет не так».
Примерно, как и в сегодняшнем BPMS: простые вещи изготавливаются в исполняемых BPMS-ках (и внедряются), но для сложных – используют традиционные технологии (классические системы программирования, готовые ERP/ECM и т.п.). Возможности современных BPMS – пока сильно ограничены, по прогресс не стоит на месте.
Термин «BPMN» можно относить к другим «исполняемым» нотациям, включая оригинальные наборы значков (фигур) от наших «сэ один» и буржуйских «кэ два» (1С & K2). Не важно, как много они взяли непосредственно из начертаний стандарта BPMN 2.0, как правило, суть та же самая: «печать процессов на 3D-принтере BPMS» (некий Process Blueprint).
3.3 Подробности «BPbase — Bpsim — Bpexe»
BPdoc основан на графическом представлении формализуемых процессов (моделирование в графических нотациях). Процесс на схемах обычно представляется в терминах потока работ (workflow), правил (логики ветвления) и потока информации (dataflow) и документов (docflow).
Обычно инструменты BPdoc определяют как Business Process Modeling (тоже BPM) Tool. Но в понимании что «modeling» это не «simulation», т.е. «модель» – просто как схема со связями объектов входящих в нее объектов и хранящихся в общем репозитарии (архиве). Связность как с другими схемами, справочниками объектов (процессами и другими сущностями).
BPdoc не включает:
а) всю нормативную базу компании или даже полный комплект текстовых регламентов, т.к. подразумеваются лишь текстовые и графические «процессные вкрапления» (процессные регламенты);
б) структуры, в составе (страшно произнести) Enterprise Architecture напрямую не связанные с процессами.
В предельном случае BPdoc есть «большой» Processes Map, хотя не понимаю, как без текстовых описаний возможно полное описание процесса. Более точно, BPdoc — это операционная модель компании, под которой будем понимать связанное описание процессов (функций), должностей (ролей), документов (обрабатываемой информации) и инструментов (информационных систем, ИС).
Как правило, подробное описание орг-структуры и ИС для этого не требуется, а достаточна лишь иерархия (иерархический справочник) с объектами, задействованными на схемах класса «облегченный EPC». В «облегченном EPC» из всего многообразия EPC (Событийная цепочка процессов) кроме «функции» и «события» ограничиваются 5-6 типами объектов: роль, документ, информационная система.
Читать (описывать) конечный процесс без орг-штатной (ролевой) структуры, без набора (дерева) инструментов и без входящих \ выходящих (в \ из процесса) документов – неэффективно (малоинформативно). Исключения – схемы, показывающие логику ветвления. Поэтому нужна «обвязка» элемента «Функция» («окружение функции») и сводка этих обвязок в простенькой структурной схеме (хотя бы орг-штатной и структурной схеме ИС). Подробности см. в «Соглашении по моделированию» любого АРИС — проекта.
Выше упор сделан на нотации для фиксации процессов (во главе с EPC), но в BPdoc применяются любые другие, в том числе, класса «исполняемые» (BPMN).
BPM «исполняемый» (BPexe) содержит как минимум дизайнер (модуль разработки приложений) и «среду исполнения» (движок, BPM-Engine) и фактически представляет собой разновидность систем программирования. А именно, — направление «программирование без программирования» средствами визуального конструктора программ (хотя часто в BPMS требуется добавлять много кода). Такой процесс хоть и касается BPM, но ближе к среде программирования с графическим языком в виде BPM-нотации (BPMN) и с «исходником» в виде схемы процесса и экранных форм. Сегодня вендоры BPMS нас убеждают, что это «самый настоящий» BPM», но это была кража бренда «BPM» («лже-BPM» см. рис. 3.4).
Рис. 3.4 Подделка термина BPM
Разработчики и продажники «компиляторов новой волны» (BPMS, где — «графика в код») отобрали у системотехников (SE) бренд «BPM», а взамен бросили «кость» — BPA. Business Process Analysis
Подмена проведена по сценарию: «дадут палец, руку откусим». «Сдача» (без боя) бренда BPM на «милость кодерам» (SWE) сопровождалась компрометацией исходных идей BPM — как управленческой методологии и высокоуровневых компонентов «Архитектуры предприятия», которые в программной инженерии или вообще не нужны или малозначимы (точнее у победителей «своя EA»).
Это была ремарка к истории и философии BPMS в контексте противоречия «as is» vs «as really is».
В итоге получился «лже-BPM» с сомнительными ориентирами на классический BPM, т.к. BPMN 2.0, like BPMN и другие исполняемые нотации пока:
а) малоэффективны для бизнес-анализа (в сравнении с BPA),
б) сомнительны для программирования силами бизнес-пользователей.
Часто обычная автоматизация процессов «необычными» средствами разработки ПО — «исполняемыми BPMS», позиционируется как «удачный проект BPM» (лавры «чужой победы»). Уже подчеркивалось: прямой связи «BPM» и автоматизации — нет. Внедрение «исполняемой BPMS» и построение с помощью нее программы — это «типа BPM», а построение во встроенном BPM-редакторе (дизайнере) CRM, ECM, ERP такой же схемы процесса в похожей или такой же нотации — не считается внедрением BPM. Почему? Это просто Embedded BPM. Практически все современные CRM, ECM, ERP имеют конструкторы workflow, как минимум «похожие на BPM». Бизнес-процессы компании: ECM, CRM, BPM – какая разница?
Внедрение нового приложения, собранного в дизайнере BPMS и запущенного на BPM-движке, мало чем отличается от классической автоматизации. Существует множество систем визуального программирования и конструкторов программ (включая мастер интернет-сайта и детский Scratch), где «программист» может не видеть ни строчки кода, что формально тоже BPMS — «no code».
Основные принципы автоматизации современных BPexe (BPMS) представляют собой двадцатилетней давности аналог SCADA систем, используемых при автоматизации технологических процессов (в BPexe — административных, управленческих процессов). Такой же визуальный конструктор программ, с разницей, что вместо документов – электрические сигналы, а «живые исполнители» (роли) – это задвижки (исполнительные механизмы в АСУТП) или датчики.
Во многих сегодня «уже давно немолодых» SСADA, включая отечественный TraceMode, изначально был подобный BPMS визуальный редактор [для «программиста», который не знал программирования], графическая схема технологического процесса, свой Business Activity Monitoring (BAM) — мониторинг, показывающий в реальном времени предельные (контрольные) и реальные значения температуры, давления, скорости, объема и т.п.:
Где-то уже слышали нечто подобное, но про «бизнес-технолога»? Визуальное проектирование рабочего процесса компании (BPM) аналогично визуальному проектированию технологического процесса (АСУ ТП).
Симуляторы BPM (BPsim) — в большинстве случаев, — это некая промежуточная категория между BPdoc (регламентом реального БП) и BPexe (реальной программы, т.е. автоматизированного БП и документированного, например, через BPMN). Симуляторы позволяют «почувствовать» динамику процесса (динамическое моделирование), запустить «упрощенные» экземпляры процесса.
К сожалению для BPsim также как и для BPdoc используют термин «моделирование» (simulation — как имитационное моделирование), причем моделирование «бизнес-процессов» возможно как в «настоящих» BPA-BPMS (ARIS Simulation, PBexe), так и в универсальных (классических) системах моделирования. Моделирование возможно как посредством графических нотаций, признанных BPM-сообществом, так и в «непризнанных» или вообще средствами неграфических абстракций, включая языки моделирования, например, GPSS: Имитационное моделирование бизнес — процессов
BPmon — средства «мониторинга процессов».
3.4 Причины популярности BPMS или «на пути к великой цели человечества»: создание программ без программистов
При описании процессов средствами BPdoc, BPsim, BPexe ключевое слово — «графическая схема процесса». Хотя процесс можно описывать не только квадратиками или мощью русского языка: описание процесса буквами — он же текстовый процессный регламент.
Для формализации процессов и событий существуют специализированные языки, особенно распространённые в системах имитационного моделирования, но они скорее придуманы для программистов, а не для аналитиков, методологов и других «фиксаторов и хирургов бизнес-логики от бизнеса». Даже несмотря на то, что некоторые языки содержат в своем названии заветное слово «бизнес-процесс», например, Business Process Execution Language (BPEL).
Это относится и к «самым-самым великим» BPM-нотациям: Аббревиатура BPMN скорее расшифровывается не как Business Process Execution Language, а как «Business People May Not understand», то есть «люди бизнеса могут и не понимать» эту нотацию (Джим Синур)
На протяжении долгих лет не угасает стремление (мечта №2) — найти простой путь моделирования процессов непосредственно их участниками (задействованными в процессе) без привлечения BPM-специалистов «по отрисовке квадратиков и кружков», а также выполнение построенных таким образом процессов. Отсюда и сильная тяга (надежда) к формату BPMS (BPexe).
К сожалению, пока это остается мечтой, хотя периодически про нее вспоминают, например, именно под этой идеей стартовал BPMN. Но BPMN сильно проигрывает тому же EPC для целей фиксации и анализа алгоритмов на уровне бизнес-пользователей (критерий интуитивно-понятности) и «топов» и не достиг изначально поставленных целей.
На трудно-читаемость BPMN также оказывает влияние вынужденная высокая детализация описываемого процесса: если в EPC можно за деталями отсылать в текстовый регламент, то в случае с исполняемым BPMN приходится «все нести с собой».
Очередной виток делается «новым современным вызовом BPM»: S-BPM, парадигма «subject-oriented BPM» от очередного мавра (тоже немецкого профессора).
Другой миф заключается в том, что раз используется BPMS, то на выходе «эффективность, помноженная на оптимальность». Ибо дизайнер процессов «шайтан-BPMS» сразу создает «эффективный процесс» (видимо через стелс-библиотеку гипер-когнитивного анализа), а среда выполнения BPMS делает бизнес-логику процесса оптимальной и «прямо на лету».
«Уши растут» из гипотезы, что большинство программистов пишут программы не для человека, а для «себе подобных». Считается, что его программы удобны (понятны) только такому же программисту, а не целевому потребителю-пользователю (бизнес-подразделению). Популярна концепция, обеспечивающая «упаковку» алгоритма программы не в код, а в интуитивно понятные непрограммисту (методологу, пользователю) графические нотации и соответственно отсутствие, как кода, так и эффекта «испорченный телефон» на протяжении процесса разработки: Суровая правда любого нетипового проекта (качели)
Более того, есть желание обеспечить работу полученной программы (исполнение) без участия ИТ-службы («публиковать» в «prod» по кнопке самим юзером). Как мы видим, реализация концепции еще далека от идеала, но и прогресс также нельзя отрицать в этом довольно древнем направлении «Программировании БЕЗ программирования»
Указанные выше чаяния заключены в «трендах»: BPMS, «low-code», no-code» (программы с нулевым объемом кода, возможно появятся даже «с отрицательным кодом»). В реальности все проще: «Ничего личного, Просто маркетинг». Например, не принимают нас в ряды «настоящих BPMS», т.к. например, не поддерживается BPMN-нотация, значит, назовем это «low-code» (включая, «один сэ» и «кэ два»). Или хотим «открыть» новый рынок сбыта (фактически того же самого), то первыми «прыгаем» в тапки «code.net».
Та же «один форма» (1forma.ru) позиционируется и как BPMS и как система управления класса Workflow, да и от «low-code» не открещивается — если покупателю так больше нравится.
Часто продажи делаются примерно так:
— Купите этого замечательного щенка! (soft)
— А каких размеров он вырастет?
— А Вам нужна большая собака? Да? Конечно, наш щенок вырастет и станет огромным псом! (BPMS)
— Ах, Нет? Вам нужна крошечная собачонка? Так Вы нас неправильно поняли: наш щенок расти больше не будет — таким же и останется («low-code» & «no-code»)! Только купите его у нас!
Ключевая «фишка» систем «low-code» — создание приложения, путем перетаскивания нужных функции из библиотек функций и построение логики приложения без необходимости кодирования с помощью визуального конфигуратора.
Пока современные BPMS не очень дружат с «человекоподобными разрабами» (непрограммистами), поэтому подобно любым иным системам программирования (начиная от Си), они еще требуют много кода, а также с легкостью из «просто хаоса» делают «хаос автоматизированный». Последний еще опаснее.
Были и остаются в моде (чаще мечтой) «делающие код» системы (в том числе, «no-code»), языки, нотации и другие абстракции (включая языки описания бизнеса, процессов и вообще жизни) для методологов бизнес-подразделений компании, т.е. инструменты не для IT-служб и программистов, а для рядовых «юзверей». Последние должны хотя бы легко читать свои процессы по этим нотациям и абстракциям. Иногда это называется «формализация на языке бизнеса», причем самим «Business user» (non-technical users).
Нотации и абстракции должны быть практичными, стандартными и понятными даже непрограммистам (ребенку), но позволять построение моделей (описание), адекватных реально происходящим процессам.
Интересно, что аналогичным путем развивается направление «программирование для детей», например, Мой опыт обучения детей 8-10 лет программированию на Scratch
BPexe (BPMN, «low code» и прочее). Учитывая, что BPexe поддерживает как минимум стадии: моделирование, имплементацию (фактическую реализацию программы) и ее развёртывание, то модели под «exe» (execution) – по факту ВСЕГДА адекватны реальному процессу, причем автоматизированному. Обзор лидеров BPMS
BPana, анализ процессов — «широкое» направление для творчества. Примером тривиального анализа может служить запрос к БД: сколько и где встречается такой то процесс (объект) или в каких процессах задействовано подразделение «А» или документ «Б»? Кстати, многие запросы можно делать и в системах класса «рисовалка», например, в Visio (там также использованы объекты и есть система поиска), а если к схеме процесса в Visio привязан файл Excel или Access с данными процесса, то возможности по тривиальному анализу могут быть сопоставимы с «крутыми» BPM, т.е. BPA и BPMS (в устоявшейся классификации).
В любом случае BPana является «вторичным» и требует «первичку» — BPdoc. При этом, вдумчивый взгляд на карту процессов (BPdoc) — уже подразумевает «анализ» (BPana), поэтому грань иногда условна.
3.5 Леса, деревья, листья
Процессы имеют разную детализацию. Как минимум: верхнего уровня и детального. Схемы (модели) класса BPexe — все детальные, иначе программа не заработает. Это «по определению», т.к. — «exe» = «execution».
Но и детализация далеко не всегда хороша: «за деревьями — леса не видно», поэтому BPdoc можно разделить на две задачи (категории): задачу описания «леса» (процессы в «крупную клетку», взгляд с высоты «птичьего полета») и достаточно детальных «процессов — деревьев», но, как правило, еще не таких подробных, как в BPexe (BPMN), где формализуется каждая «гайка» (иначе «не взлетит»). Средствами BPMN можно описывать не только «листья» (гайки), но и «деревья», но никак не «лес».
С одной стороны, за деталями (детальными процессами – «деревьями» в EPC и «листьями» в BPMN) теряется общая картина на весь процессный ландшафт предприятия (лес). С другой стороны, описать все «процессы — деревья» (не говоря о «листьях») также сложно, как и зарисовать, хотя бы схематично, все деревья даже в небольшом лесу.
На эту тему — аналогия Карты процессов с географической картой: Дотошное описание бизнес-процессов — это хорошо или плохо?
Полное описание бизнес-процессов крупной компании — это утопия. Во всяком случае, посредством современных технологий описания бизнес-процессов: что в виде многостраничных текстовых регламентов, что в виде квадратиков и кружков (моделей, нотаций).
В первом случае, многотомные талмуды будут без связей и наглядного масштабирования (от high-level до «отправить уведомление по email»).
Во втором, схемы EPC (BPMN, UML и т.п.) придется рисовать очень долго и большим составом рисовальщиков (бизнес-моделистов\ модельеров) и все-равно без гарантии получить «как есть в реальности» (см. картинку в заголовке статьи).
Даже если все процессы автоматизированы с помощью BPMS (PBexe) и имеется полный комплект схем (моделей) процессов в BPMN, то для понимания «картины» в целом (показать «лес») их придется обобщать, укрупнять, систематизировать и т.п.
Кроме того, оригинальные «рабочие процессы» (предельно детальные процессы) в формате BPMN, как уже отмечалось, будут непонятны большинству сотрудников бизнес-подразделений. В целом BPbase – это наука как по описанию и анализу леса, так и деревьев. И основная нотация для BPbase – это не BPMN, а скорее EPC (в прошлом IDEF). В инете много сравнений EPC vs BPMN.
В целом если «лес» — высокоуровневые процессы — описать достаточно несложно (VAD, EPС, но не BPMN) и ценность такой работы наиболее высока, то детальные — «деревья» (EPC, для BPMN — не как «исполнение», а лишь как «иллюстрация») — колоссальный объем работы с уже меньшей ценностью (в задачах BPA), хотя бы потому что эти схемы дублируют (должны) текст инструкций (регламентов).
Описывать «процессы для непосредственного исполнения» с помощью исполняемых нотаций типа BPMN — это формализовывать элементарные операции, т.е. все те, которые не требуют более детального описания, т.к. компилятор уже может переложить их в код. Если «тупой» компилятор может переложить схему в рабочий код, то это уже однозначный «финиш» детализации (предел для машины, человека иногда сложно остановить и он готов детализировать до бесконечности путем повторов).
Внешне у процесса моделирования BPdoc (EPC) и BPexe (BPMN) много общего: визуально отличий мало – почти такие же квадратики и кружки. Во многом это и позволило заимствовать (прямым текстом — украсть) раскрученный термин «BPM». Хотя BPexe частично решает ту же задачу – документирование процесса (на рис. 3.3 результат «побочный», BPdoc’), но все же у них принципиально разные назначения и «собственная философия».
Первым нужно показать человеку как примерно работает управленческий процесс («в целом», а многие детали – смотри в тексте регламента, поэтому в нем и «много букф»).
Вторым — дать четкую инструкцию компилятору (пусть даже и через графические образы) «что делать» (а многие детали, все равно присутствуют только в коде).
Со временем грань между BPexe (BPMS) и BPdoc (BPA) должна постепенно стираться. Возможно, из современного BPexe, который пока все-же «для программиста», выделится отдельный класс систем, который будет для «человека»: для бизнес-аналитика, не знающего вообще «страшных слов из мира ИТ». Другими словами: BPexe станет штатным инструментом бизнес-специалиста, а не программиста (ИТ-службы).
Надеюсь, что такая же участь будет ждать и BPdoc: не нужно будет иметь штат «модельеров» (или нанимать EPC-консультантов), рисующих схемы процессов, а модели процессов будут генерироваться из штатных регламентов, возможно даже «незаметно» для пользователя.
В совсем далеком будущем: автоматически – прямо из самого процесса по аналогии: топокарты по спутниковым снимкам («аэрофотосъемка» процессов компании) или раскрытие сетей (OpenView Network Node Manager и т.п.). Хотя бы научиться считать число процессов компании, наподобие — овец через спутники NASA, как в известной притче про консультантов («Около стада овец приземляется вертолет. »).
Формализация процессов (BPdoc) имеет разные задачи: от тривиального регламентирования отдельных операций в графической форме до выстраивания Enterprise Processes Architecture. Иногда BPdoc проводится под последующую автоматизацию формализуемых процессов, т.е. является первой стадией Business process automation (не путать с «BPA», где «А» = analysis). Как подчеркивалось: описание процессов существует само по себе, вне зависимости — «автоматизированный процесс» или ручной и «будет ли он автоматизирован» или нет.
При «автоматизации по схемам» (BPdoc), подготовленным в EPC (IDEF и т.п.) этот подход противопоставляется подходу «одним выстрелом двух зайцев» (PBexe), когда схемы под автоматизацию разрабатываются уже изначально в исполняемых нотациях BPMN и подобных, т.е. «execution». Выбор между BPA (EPC) или BPE (BP execution) в пользу последнего (BPMN) — не столь очевидный, как может показаться на первый взгляд: сложности восприятия «бизнесами» (специалистами не из мира ИТ) исполняемой нотации (BPMN и подобных), несовершенство самой технологии (инструментов BPMS).
BP-BP (Business Process — Best Practice) — это не книжки типа BPM CBOK, а практические шаблоны и прототипы (в т. ч. просто примеры для тиражирования, типовые наборы процессов с детальным описанием), референтные модели из конкретной области, классификаторы процессов (например, APQC PCF Process Classification Framework) и т.п. В целом это основа, на которой может (должно) быть построено эффективное производство товаров (услуг), а не конвейер спекуляций. Это отдельная глобальная тема обсуждений о будущем BPM (хорошо забытым прошлом): Global BPM.
3.6 Близкие понятия
Для BPdoc часто используется «Process Map»/ «Process Mapping» (Картирование производственного процесса), выраженный или иерархическим деревом или графикой. Далее Process Map может быть использован как «подложка из процессов», на которую наносят некие метрики. Если на подложку наносить данные ВАМ, то получится мозаика индикаторов на фоне «процессной карты». Близкие названия Process Dashboard, BI Dashboard, Process Measurement и другие.
BPana — к нему могут «присоседиться» многие из Business Process \ Performance Improvement, всего «самого непрерывного» улучшайзинга и просто реинжиниринга. Но это находится уже за пределами «чистого BPM».
3.7 За бортом «чистого BPM»
Чтобы «не ломать копья»: «BPM это или нет», выделяем отдельной категорией BPMextra (extraordinary, «необыкновенные»), и «сольем» туда все, что не вошло в понимание «чистого BPM» (см. рисунок 3.3) и BPexe.
Первый набор претендентов — это большинство терминов (модных «фишек») из «Hype Cycle for BPM» («кривая обмана»)
Второй — все что «приклеилось» к BPM(s) через ИТ («хвосты»), включая разнородные «BPM-интегрейшены» типа integration-centric BPM, ориентированные на интеграцию системы управления бизнес- процессами
В категорию BPextra включим малопонятные и «звездные» термины и процессы под них: все BPM-окружение, связанное со «стратегией» (Business Strategy), «управление управлением» («руководство», Governance Mgmt., Process Governance), «отслеживанием стратегических целей развития бизнеса», «общекорпоративными правилами по управлению», в том числе, бизнес-процессами. Согласно терминологии Второй главы настоящего цикла — это «Business-ацетон» («головы» при процессе дистилляции BPM).
Кто не может оторвать от BPM все «самое-самое» прогрессивное и принимает это как BPM, может включать это в BPextra: Кайзены, всеобщее управление качеством (TQM, СМК), «самые» бережливые производства Lean, «все сигмы» (Six Sigma и семь сигма, т.е. которые + Lean), и другие «совершенные» технологии всеобщего совершенствования, в том числе, совершенствования бизнес-процессов, но которые не основаны на документировании, регламентации и стандартизации конкретных бизнес-процессов компании.
Классификацию методологий «трансформации», «совершенствования» (самого передового «улучшайзинга»), «Тойота» и т.п. см. Методология управления бизнес-процессами (BPM)
К «самому-самому» прогрессивному и «like BPM» также примешивают:
— Business-driven development, это такая методология, в которой разрабатываются ИТ-решения, непосредственно отвечающие требованиям бизнеса (видимо все остальные программы, построенные вне BDD, этому не отвечают и, следовательно, бесполезны);
— x_BOK-и, особенно, где «х» включает заветное слово «Business»:
— — BIZBOK (Guide to the Business Architecture Body of Knowledge)
Обратите внимание, что там много чего — как из BPM, так и EA;
— — REBOK (Requirements Engineering Body Of Knowledge), инженерия требований, там такие же Business Strategy, Business Case, Business Rule, Business Process и др.),
— — BABOK iiba.ru/category/babok (Business Analysis Body of Knowledge), тоже инженерия требований, но позиционируется как бизнес-анализ «с целью выявления требований»), кстати, на указанном сайте приличная библиотека, в том числе, по разделу BPM;
— Service-oriented modeling + «х», где
«x» = «and architecture», тогда это уже SOMA,
«x» = «framework», тогда SOMF, есть service-oriented analysis and design (SOAD), есть Service-oriented modeling sub-ontology (SOMsO) и конечно BPM sub-ontology (BPMsO) и много чего подобного в книжках подобных: «Service-Oriented Computing ICSOC/ServiceWave 2009 Workshops»;
— и много-много подобного: иной раз создается впечатление, что любую технологию можно подвести под «многогранный» (многоликий) BPM. К BPextra («like BPM») отнесем «архитектурные картинки» из мира ЕА и все остальное «правильное и похожее» на BPM, но что не вошло в «pure BPM» (Natural BPM). Наводить порядок в самом BPextra будем в другой раз и видимо уже вне плоскости (layer) BPM.