Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
BPM «Как есть» и «как не есть»
Продолжаем размышлять «что такое 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 или профессиональные авиаавтотанковые-симуляторы. Тоже — все почти как настоящее, но входные данные (высота, скорость) — вымышленные (расчетные) и здоровью (реальному процессу) не навредить «если что-то пойдет не так».
— BPexe — это уже настоящий танк, полученный из чертежей (BPMN 2.0), загруженных в 3D-принтер (BPMS). Загружай чертеж, печатай изделие (публикуй процессы в среде исполнения) и «на передовую» (развертывай программу в промышленную среду). Печать реальных танков пока еще в будущем (уже недалеком), но реальное стрелковое оружие уже печатают: Эволюция 3D-печатного оружия
Примерно, как и в сегодняшнем 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, BPsim, BPexe можно отнести многое из терминов «Process [X]», где Х=
— Model / Repository & Design / Documentation (как-то процессы же нужно формализовывать и куда-то их складывать). Не так важно разрабатывается процесс на будущее (to be) или документируется существующий (as is). Иногда это обзывают Process Understanding из серии – «знай свой процесс» (сравни: «знай своего клиента»);
— Portal / Publisher (публикация процессов, совместная работа, «делись своими процессами» и т.п.);
Для 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.
Ваш,
bipiem
Автор: