Крошка сын к отцу пришёл, и спросила кроха: — Что такое хороший BPM?
Business Process Management. Предлагается из всего многообразия «BPM-наукообразия» выделить «чисто инженерную составляющую», исключив лукавый маркетинг и высокоуровневые бизнес-абстракции, бизнес-надстройки и прочую «бизнес-шелуху» на BPM — инженерии (как инженерной дисциплины), а также вынести за скобки ИТ-составляющую. Вводится понятия процессная инженерия, процессная система, процессные технологии, Process BPM (Natural BPM). Process technology рассматриваются комплексно: Операционная деятельность — Разработка — Внедрение — Контроль.
Вводная
Крошка сын к отцу пришёл, и спросила кроха: — Что такое хороший BPM?
Термин BPM, Business Process Management так «заговорили», что понять, «что же это такое» — уже совсем не просто. В первой главе был показан «Business Process Management маркетин говый» (PR-bpm). Главу первую можно было долго развивать, например, тему (проблему) путаницы терминологий вокруг BPM и тезис «BPM vs [всего и самого себя]»:
Вариант 1: «BPM vs BPM», где буква «M» = {Management vs Modelling vs Mapping}.
Вариант 2: "BPM vs BPM", где в одном из вариантов «P» = Performance.
В «современном» термине «BPMS», буква «М» вообще «не к месту» и что бы людей не путать заглавная буква от «Management» должна быть заменена или на «А» (Аutomation) или на «Е» (Еxecution), т.к. речь там в основе — о разработке программ. Последнюю — букву «S» можно читать как угодно и без потери смысла: suite, system, software (даже в разных версиях BPM CBOK по-разному).
Если «рыть вглубь», используя поиск в google «BPM vs», найдешь много разнообразных сочетаний, например, iBPMS vs BPMS или BPM vs ACM («Agile BPM»)
Другие варианты: BMP versus OpX (Operational Excellence)
Много «BMP versus» в обзоре по BPM стандартам: Business process management (BPM) standards: a survey
Хотим «рыть вширь» — смотрим на смежные глобальные направления (но по сути такие же «IT-фишки»), например, «Архитектура предприятия»: BPM vs EAM, Enterprise Architecture Management
Одни говорят, что BPM это часть EAM (ЕА), другие считают наоборот и задаются вопросом, EAM: Standalone or part of BPM?
Конечно «лучше» (в части продаж решений и консалтинга), когда «одно и одновременно» и для управления бизнес — процессами (BPM) и для анализа бизнес — процессов (BPA) и вдобавок для управления архитектурой предприятия (EAM) и еще чем-нибудь «модным».
«Грамотный лекарь», т.е. алхимик, разламывая одну таблетку пополам, предупреждает: этой половинкой тебе лечить голову, а этой — хвост, но смотри — не перепутай! В тоже время, искусственно созданы разные «поляны», чтобы друг другу не мешать, продавая одно и то же, но под разными соусами. Причем чем бОльшую долю рынка у BPA отъедает BPMS, тем активнее BPA «заходит» на поляну EA под вывеской «BPM».
Говоря по простому: BPM aka BPMS нагло отобрал «Brand-name BPM» у BPM aka BPA, а последний вместо борьбы за него развернул фронт в сторону «Enterprise Architecture». Даже книжки про ARIS (флагман BPA) уже называют «Архитектура предприятия»
Сложно разобраться: где кончается «обыкновенный» BPM и начинается «Enterprise Architecture» (EA). Поэтому в EA тоже все «совсем не просто», в смысле запутано (под монетизацию, конечно же) и понять «что такое EA» сложно точно также как и «что такое BPM»: 10-definitions-enterprise-architecture
Часто читая про BPM (тот, который BPA-ARIS-EPC и т.п.) думаем про EA, а читая про EA вспоминаем, что про это же точь в точь было уже прочитано в «каком-то» BPM. А когда замешивается Enterprise BPM, BPM Governance, Management BPM и т.п., то напрашивается: «зарытая собака то одна, только клички и нее разные».
«BPM Governance Framework»
или «Enterprise-wide BPM», BPM аж «масштаба предприятия», почему не вселенной то? Кроме «Управление управлением» — BPM Governance, есть «бизнесовый бизнес-процесс» — Business BPM (см. первую главу).
Наводнение «разных» «одного и того ж» имеет всепланетный масштаб. Чтобы провести разграничение зон ответственности «с пришлыми» как по периметру, так и внутри BPM, исключить повторы и просто ахинею — требуется колоссальная работа. Приведу фрагмент, с которым согласен, причем вместо многоточия можно поставить многие BOK-овские организации и родственные им «гильдии-секты»:
… довольно типичная организация по написанию и продаже дорогих книжек, развитию региональных представительств и многоуровневых систем сертификаций. Все подобные организации, правильнее их было бы назвать сектами, сделаны по одному шаблону. И проблемы у них у всех одинаковые: изменения освещаемой ими темы происходят намного быстрее, чем издаются очередные релизы их главных книжек. Адепты такого кунг-фу сильно рискуют обнаружить абсолютную ненужность приобретенных навыков к моменту достижения черного пояса. Впрочем, каждый зарабатывает, как умеет.
Обсуждение на тему «современная алхимия» и «BPM-EA гербалайф» в комментариях к первой главе на cnews.ru
'Non-alchemysts' aller Länder, vereinigt euch!
Современные алхимики в монетизации своего ремесла поднаторели и научились все делать «грамотно», — через заумные термины: business-словечки и «IT-фишки». Термин, который «выстрелил», обеспечивает престиж и право: Кто раньше встал — того и тапки!
Модные «фишки» и их волатильность иллюстрируют «свечки» на картинках Hype Cycle for BPM (за 2011 и 2015 г. см. в комментариях к первой главе на habrahabr.ru). Если бы не «всемогущая рука маркетинга», то многих из них, сразу и навсегда накрыло бы «корытом разочарования» (trough of disillusionment). Правильный перевод Hype Cycle — не «цикл зрелости технологий», а «круговорот обмана».
Ниже попробуем углубиться в терминологию, показать, где наукообразие, а где рациональное зерно (качественный BPM-дистиллят, см. картинку в заглавии). Что же такое BPM и вообще — «бизнес-процесс»?
2 Общая терминология и высокоуровневая классификация. Окружение BPM
Первейшей задачей управления является выбор правильных названий… Если названия неверны, то язык не будет соответствовать правде. Если язык не будет соответствовать правде, тогда вещи не достигнут совершенства. …
Поэтому начальник должен давать только такие названия, которые могут быть выражены словами, а приказывать только то, что может быть выполнено на практике.
Конфуций
Призывы к единству терминологии все чаще слышны как в статьях о BPM (и тех BPM и этих), так и EA: Архитектура предприятия: основные определения
Неспроста это. Видимо, не все «так называемые» BPM «одинаково полезны» (из известной рекламы). Посмотрим откуда «уши растут» у «общепринятой» BPM-терминологии.
2.1 Борьба с маркетингом за термин «бизнес-процесс»
Причина наукообразия в «BPM мире» — это желание сделать «воду мутной» и вбрасывать туда «дорогостоящие» (очень «весомые») термины для более успешной монетизации в данном случае BPM-продукции и консалтинга. Прибыльнее продавать «бизнес-процессы» (БП), чем просто «процессы» (дешево слишком).
Первые — значительно «статуснее», «круче» и, соответственно, дороже, хотя ничем не отличаются от вторых. Убери из BPM(S) — первую букву и продажи упадут, как количественно, так и по маржинальности.
Монетизаторы «всего и вся» идут в силовые структуры и там моделируют, анализируют и оптимизируют «бизнес-процессы» заказчика (войск и сил), хотя «какой у нас может быть бизнес» — удивляются силовики? В армии «правильно» понимают «бизнес — терминологию» консалтеров видимо только «передовики» типа «Сердюков \ Васильева».
Делаются попытки сказать, что «бизнес» — это вообще и не бизнес, а, например, «люди работающие вместе для того-то …» — Что такое бизнес-процесс, что такое BPM: трактовка ABPMP
Подобное остается на уровне обсуждений, ибо гуру BPM не позволят никому «резать бизнесовый жаргон» по «живому» (приносящее статус и прибыль) и приземлять высокопарные «бизнес-процессы» и иже с ними: «управление бизнесом», «бизнес-среда», «стратегический анализ бизнес-процессов», а также всевозможные Business Event Management, Business Rules Management и т.п.
После такой «диверсии» (убрать волшебную приставку «Business») значимость термина и «капитализация» всего направления снизятся (рухнут как когда-то dot.com-ы). Всем давно внушили, что «моделирование» (управление, улучшение и т.п.) бизнеса и вообще всего, где есть приставка «Business», по определению — дешевым не бывает. В отличие от «простого» моделирования, включая математические модели. «Дешевая» математика – это вам не «серьезная» наука о бизнес-процессах. Чего бы, в конечном счете, «намоделировано» не было бы, но главное чтобы «под бизнес».
Пара аналогий
Слово «business» используется только для того, чтобы отделить процессы, имеющие прямое отношение к созданию экономической ценности, от всех прочих процессов: химических, физических, математических и т.д.
Если в обсуждениях «про процессы компании» есть вероятность, что кто-то может случайно подумать, что речь идет о химических процессах или о процессах всемирного тяготения или о марковских (направление в теории вероятности), то видимо действительно следует уточнить: речь, о не о «хим-физ-мат-процессах», а о «бизнес – процессах», которые к бизнесу отношения не имеют (в общем случае), или просто назвать их «пэ-процессами» (англ. «P-» будет далее использоваться для ассоциации с «процессами»).
Подобная проблема при обсуждении «сетей»: не путать сети электросвязи с сетями рыболовные или Петри.
Примерно это же отражает термин «схема электрическая структурная», Э1 (ЕСКД), на которую не наносят ни дискретные элементы (транзисторы), ни микросхемы, а просто изображают «черные ящики» без признаков электричества.
Э1 также широко используется как в 34.ххх гостах, так и ЕСПД: на схемах дается качественное понятие об общей структуре, поэтому «электрическая» — просто условность.
По указанной выше ссылке также правильно показана суть: функциональный подход versus процессный подход.
В нашем случае, приставка «бизнес» может быть легко отброшена (идем не по магистрали монетизации, а «инженерной тропой»), и далее будем просто говорить про «процессы». Причем не так важно различать: процесс, подпроцесс, процедура, поток работ, функция, задача, операция и т.п. Все это выражает некое действие (модное словечко «активность») в целях какого-либо результата. Черный ящик «Функция», преобразующий «что-то на входе» в «что-то на выходе» с использованием ресурсов и каких-то правил — алгоритмов. В названии квадрата, — кратко «что он делает», внутри квадрата (при декомпозиции) — «как это делается».
Управленческая функция мало чем отличается от математической функции. Изначально алгоритмы управления, описания деятельности, взаимодействие (ролей, сущностей) описывались блок-схемами как и математические и другие логические алгоритмы (алгоритмические методы описания трудового процесса).
Потом добавили событийность и некоторые «бантики» — и получили «нотации BPM», например, нотация EPC, Event-driven Process Chain.
В простейшем вариации (типе) нотации EPC — «окружение функции» производится увязка самой функции, исполнителя работ, инструмента работ (например, информационная система или механические счеты) и связанного с ней набора документов или информации. Таким образом, кроме самого workflow (алгоритм действий) добавляются элементы из орг-штатной структуры, средств автоматизации (средств механизации), движение документов (docflow) и информации.
Итого, процесс – это то, «что вы делаете». По шагам: делай раз, делай два, делай три …
Процессы — это «серия последовательных неслучайных действий (операций). Это набор шагов, выполняемых в повседневной трудовой деятельности. Не соглашусь, что „Процессы — это какие-то содержательные группировки деятельностей (activities) людей …“
Почему обязательно «людей», скорее любых „активностей“, в том числе, „не людей“ и машин: е-исполнителей с „технической учетной записью“, демонов (daemon), роботов и т.п.
Когда процессы описаны, можно получить «карту процессов», которая подобна рентгеновскому снимку организма предприятия, но где видны не только сами органы (статика), но и их взаимодействие (кто и что делает). Такая карта (Process Map верхних – средних – детальных процессов) с одной стороны, отражает то, что сложно «показать буквами» (например, в текстовых регламентах), но вместе с тем, полностью не заменяет подробного описания процесса.
Лучше использовать старый термин „реорганизация“ БП (процессов), который был заменен на „реинжиниринг“ БП (кому-то понадобился новый непонятный, но модный и поэтому более „удобный“). Из используемой терминологии лучше исключить термины, содержащие: менеджмент и управление.
Опасно употребление „модель“, „метамодель “, „моделирование“ — они имеют слишком много значений, и возникает неоднозначность понимания (полное непонимание).
Например, Corporate Process Model просто отражает идею, что есть некий набор моделей (причем не только процессов), где конструкция «модель» используется для представления объекта (в том числе, процесса) в разных проекциях (представлениях, view): процессной, данных, документов, ролей, инструментов и т.п. в виде схем разных нотаций и детализаций. Поэтому «Process Model» это просто «Комплекс объектов» (диаграмм) плоскости «Process View», как правило, с взаимосвязями.
Кроме отсева явного маркетинга, в плоскости » Process BPM" постараемся по возможности дистанцироваться от всего, что не относится к обычной логике и математике — типа бизнес-анализ, цели бизнеса, стратегия развития и т.п. и постараемся рассматривать BPM как инженерную дисциплину, а не финансовую, маркетинговую, философскую или алхимию. А также не как составную часть ИТ.
В слове «BPM» нужно убрать первую и последнюю буквы, т.к. к «бизнесу» инженерная дисциплина прямого отношения не имеет (как и любые научные направления, типа логики, математики и т.п.), а термин «управление» = «management» — скорее путает, чем вносит ясность. Я бы вообще запретил упоминание этих слов при обсуждении темы BPM.
2.2 Процессная инженерия
Введем понятие «Процессная инженерия» (process engineering) — подобие или как элемент «Системной инженерии»: «процесс-техника» как элемент системотехники.
Процессная система предприятия, процессные технологии, процессный слой архитектуры предприятия и т.п. Не путать с процессным подходом. Это другое. Процессная архитектура есть и у предприятия с функциональной схемой (принципом) управления, но предприятий без процессов не существует (пока).
Учитывая разнообразие «оккультных» BPM-направлений (терминов), основная задача термина «процессные технологии», исключить из рассмотрения «BPM составляющие», непосредственно не относящиеся к описанию процессов, такие как: оптимизация, всевозможное не четко формализованное «управление» и т.п., а сконцентрируемся лишь на описании процессов и простейшем их анализе (без «бизнес-составляющей»). Также исключить наукообразие, алхимию и ИТ-составляющую.
Что такое «Traditional BPM» — уже давно тайна (таинственная история), сегодня слышны термины BPM Governance и Management BPM, Business BPM и Technical BPM. См. первую главу или BPM comes in two forms: Business BPM and Technical BPM
Отделить «мух от котлет» позволяет выделение «Process Level» (из чего-то большого и многоуровневого, видимо EA), он же "Process BPM" (тоже тавтология, но …) он же "Natural BPM" (патентовать эти термины и PTSM?). Process BPM это не Business BPM и Technical BPM.
За рамками «Process BPM» оставим многое из Business BPM, в том числе, «высокоуровневый BPM», «BPM Governance», всевозможные «фишки-заманухи» про возврат инвестиций (как правило, в ИТ) и всего подобного «мега-эффективного», как правило, с пришлепкой «Business», " Performance", «Enterprise» (BPM, Architecture и т.п.), «Strategy», «Governance» и т.п. Mission, Objective …
В результате у нас должна получиться «очищенная» инженерная дисциплина — «процессные технологии» или процессная инженерия, посредством которой создается Процессная система предприятия — как процессный слой архитектуры предприятия. «Очищенная» от «жаргонов»: бизнес-жаргона и ИТ-жаргона.
«Process Level» = Process View, процессный слой, технологический слой и т.п.
Сверху будет расположен «бизнес-слой», ниже — инфраструктура, включая информационную систему (ИС). Информационные технологии — такие же «технологические» элементы, как и канцелярские технологии, хозяйственные технологии и другие обеспечивающие (инфраструктурные) технологии для реализации исполнения основных и обеспечивающих процессов компании.
Несколько поясняющих картинок (рис. 1 и 2) из книжек:
— "Combining Business Process Management and Enterprise Architecture for Better Business Outcomes" (IBM Redbooks)
— "Management Cybernetics and Business Process Management" (ERCIS)
Рис. 1. BPM drives business and IT alignment and responsiveness (IBM Redbooks)
IBM Redbooks говорит, что «BPM» — для того чтобы обеспечить:
• Взаимодействие для прогнозирования и оптимизации результатов процесса с помощью моделирования и имитационного моделирования;
• Оперативную настройку процессов силами бизнес-пользователей с помощью политик вместо кода;
• Улавливать бизнес-события и реагировать на них автоматически в режиме реального времени или для поддержки принятия решений человека;
• Быстрое развертывание новых решений из повторно используемых строительных блоков, которые могут быть изменены «на лету».
Рис. 2. Static view on BPM — „Level of concerns“ (ERCIS)
Нечто похожее «трехуровневое» можно встретить:
— The State of the BPM Market – 2014 (стр. 10)
Strategy and Enterprise Level \ Process Level \ Implementation Level (Employee Level + IT Level)
— Combining BPM and EA in complex ERP projects (стр. 2)
Business Architecture \ Process Architecture \ Information Architecture.
— Business Process Management (BPM)
Strategy \ Process \ Systems (еще и «Management BPM»)
Однако изобразим место «Процессных технологий» немного иначе, как показано на рис. 3. Слой процессных технологий — «Process BPM» — «Natural BPM».
Рис. 3. Слой «процессных технологий» — «Process BPM» — «Natural BPM»
На картинке в заглавии показано тоже самое, но в юмористической форме: качественная «дистилляционная BPM-колонна» позволяет отобрать «головы», т.е. ацетон, в нашем случае — Business Level (View), и «хвосты», т.е. «IT-сивуху» и прочие сивушные масла — инфраструктуру по отношению к Process Level. В итоге получим качественный (очищенный) продукт — "Natural BPM".
Как и в любом качественном самогоне, небольшой остаток сивушных масел останется. В нашем случае, это, например, элементы — названия прикладных систем и их модулей корпоративной ИТ-системы (модное слово ИТ-ландшафт), присутствующие на схеме EPC (как инструменты) и сведенные в общую структурную схему, например, схему деления на составные части прикладного ПО компании.
Дистиллят «Natural BPM» не должен содержать алхимии, экстрасенсорики и других маркетинговых примесей и вендорных специфик, а также «разбодяжен» общими фразами «за мир во всем мире» (конкурентное преимущество, гармоничнее развитие, обреченность на успех и т.п.).
За рамками «котлеты Process BPM» оставим «BPM -суррогаты», типа «Technical BPM» со всеми вместе взятыми «SOA, ESB и web-сервисами» (непонятным образом прицепленными к BPM), а также системами разработки ПО (BPMS), в том числе, на основе графических нотаций (BPMN). Точнее, описания процессов (Design & Modeling) может войти в «Process BPM» (смотря, «что» описывается), а все что касается исполнения и генерации приложений – останется за рамками «Natural BPM».
Комплексно Natural BPM представим как набор взаимосвязанных процессных систем (кругов) предприятия, как показано на рисунке ниже.
Рис. 4. Шесть кругов BPM
Концепция «Six Circles» (не путать с Six Sigma) отражает взгляд не только на процессный слой. Это общий подход к производственной деятельности, где нужно что-либо эксплуатировать, разрабатывать и внедрять (в нашем случае процессы). А также когда все это нужно контролировать и управлять качеством, как конечной продукции (услуг), так и полуфабрикатов, в том числе, процессов и сервисов.
Разные «круги – системы» отражают разные подходы к «процессам», к «управлению» ими в самом широком смысле этого слова. Одно дело процессы эксплуатировать, совсем другое их разрабатывать: «как будет» и «как должно быть, если делать грамотно», или хотя бы формализовывать: «как есть» и «как есть в реальности». Свои подходы к внедрению и контролю (аудиту) процессов. «Круги – системы» — это тоже подход — как разделить «мух от котлет».
2.3 First Step. PTSM a la ITSM
Нужна четкая и вневендорная теория технологии процессов. Пусть плохая, но честная (независимая, без лукавства). Логично предположить, что вендоры не заинтересованы в «вендоро — независимости». Как сделать первые шаги к построению инженерной дисциплины по управлению процессами? Изобретать новый велосипед? Видимо лучше попытаться что-то заимствовать.
Среди наиболее продвинутых ИТ-учений выделяется теория ITSM — ITIL. Конечно и там все «не гладко», когда читаем Введение в Реальный ITSM. Роб Ингланд The IT Skeptic
Однако теория ITSM (ITIL) куда более проработана и апробирована, чем учебник по алхимии BPM CBOK или откровения по EA разных сект. Дисциплина ITSM достаточно неплохо описывает собственные процессы ИТ-слоя, почему бы используя тот же подход (ITIL) не построить систему описания процессов более высокого уровня в рамках отдельной дисциплины?
При этом абстрагируясь как от ИТ и другой инфраструктуры, так и от всевозможных «высоких материй» (business) и маркетинга. Т.е. «взять чуть выше» ИТ. Главное, что бы получилась практическая теория.
Ключевые принципы в ITSM и PTSM схожие, а «процессности» в каждом процессе из «ITIL Mgmt.» — через край, например, workflow процессов управления изменениями или проблемами. Поэтому из «information technology» в «process technology» (IT на PT) и берем базовые подходы из ITSM-ITIL.
Термин PTSM (Process Technology Service Management) точнее отражает суть. Например, «управление бизнес-процессами» в BPM буквально (формально) означает, что происходит непосредственный запуск экземпляра процесса: пришел клиент — и запустили процесс «обслуживание клиента». Старт процесса: девушка на рецепшен должна увидеть клиента и улыбнуться ему.
Но BPM как раз непосредственно процессами не управляет (в общем случае, не рулит экземплярами процессов), это скорее управление самим сервисом запуска (задание маршрута), остановки процесса и т.п. Следовательно, добавка «Service» по существу.
Многие схожие элементы из ITSM присутствуют в PTSM. Например, CMDB — это аналог репозитария моделей \ объектов в BPM. Нет принципиальной разницы в том, что в CMDB — сервера и ПО с их паспортами, а в репозитарии BPM функции, события и документы с их паспортами (свойствами — атрибутами). Суть та же. В принципе можно строить объединенную CMDB (и там связать «все и вся»).
Самые главные процессы — это так называемые «продуктовые» процессы, на выходе которых конечные «продукт» или «услуга» из Каталога продуктов и услуг предприятия. Общая идея Ресурсно-сервисной модели в ITSM — аналог «цепочки добавленного качества» (VAD), где на каждом этапе видна обеспечивающая система, текущая и вышерасположенная, вплоть до реализации конечного сервиса (продукта).
В обоих случаях наглядно видны «сквозные» взаимосвязи объектов (неважно, серверов или процессов) и можно найти «слабое звено», определить кто для кого «обеспечивающий».
Подобные подсистемы: управления потребностями (P-Demand Management — как обратная связь с «бизнесовым слоем», BTSM), управление каталогом PT-услуг (process tech) и т.п.
Зону ответственности PTSM ограничим лишь операционной деятельностью предприятия (эксплуатационной составляющей), она на рисунке показана как Ops-P.
Здесь же выделим элемент «mon» (process monitoring), отвечающий за мониторинг процессов. Обычно (в том же ITSM) мониторинг рассматривается отдельно. Видимо, чтобы потом собрать все в одну большую систему «комплексного мониторинга»: конечных бизнес-сервисов, бизнес-процессов, прикладных систем, Middleware, ОС, Hardware, проводов связи, источников электричества и т.п.
Dev-P отвечает за разработку и документирование процессов (процессный дизайн-центр). Dev-P Может быть разбито на две подсистемы: технические (процессные) писатели, которые отвечают за отрисовку «as is» (лучше «as really is») и дизайнеры (проектировщики) процессов «to be». В компании направление Process engineering может вообще отсутствовать (по аналогии с Software engineering, программистами), т.к. изменения могут происходить в рамках PTSM.
PTSM включает аналогичные Mgmt с приставкой или суффиксом «P-»: Change management, Configuration management и т.д., а вместо «собственной» разработки процессов, комплексы процессов (настоящие типовые референтные модели) могут быть заимствованы.
В целом аналогия с собственной разработкой ПО vs ПО покупное & Open Source.
Система внедрения процессов отвечает за внедрение новых процессов или «глубоко реинжиниринговых» старых. Это может быть группа «процессный офис» в проектном офисе или наоборот.
PM-P — это во многом подходы из PMBOK, но раскрывающие специфику «процессной плоскости», т.е. внедрения процессов. Сейчас формально внедряют ИТ-системы, т.к. вендоры поставляют не процессы, а системы (железо и софт), но негласно внедряются все же процессы. Если это не происходит, то проекты, как правило, обречены.
Фактически «внедрение процессов» остается в тени, а внедрение «вендоро-независимых» процессов – вообще эксклюзив. Но это отдельная тема обсуждения.
Кстати, консалтеры тоже не продают процессы, они, как правило, продают нечто из притчи "Около стада овец приземляется вертолет..." (гуглите).
Без системы управления качеством и аудита — на крупном предприятии не обойтись. Есть бизнес-аудит и IT-аудит, значит, будет «PT-аудит», например, построенный на схожих принципах с Cobit. Направление не путать с СМК по ISO 9000: мои представления о внедрении ISO 9000 — «просто развод» или «для галочки» (впрочем, как и многое другое, включая, большинство MBA — контор).
Деление на рис. Шесть кругов BPM подчеркивает, что указанные «процессные» зоны (системы) — самостоятельные и даже где-то:
Операционная деятельность Vs Разработка Vs Внедрение Vs Контроль.
Привязать это к циклу Деминга — не совсем верно, т.к. контроль обеспечивает не только «контроль внедрения», но и контроль на стадии разработки (если есть подразделение Dev-P) и на стадии Ops-P и даже PM-P (как «процессный» элемент системы контроля проектной деятельности организации).
2.4 Заключение ко второй главе
В заключение хочется подчеркнуть, что из уст великих «вендоров и консалтеров» — «Что такое BPM» не ясно и с каждым годом становится все более туманным. Также до настоящего времени отсутствует пусть и простой, но полноценный открытый инструмент BPM aka BPA.
Поэтому вижу первостепенные задачи:
а) выстроить народную теорию BPM (раз профессионалы не могут справиться);
б) создать общедоступный инструмент (про ARIS Express знаю), хотя бы для обучения, апробации подходов и экспериментов.
Таким образом, нужна вневендорная позиция и четкая мЕтода (дистилляционная колонна), позволяющая отделить от целевого продукта (Natural BPM) лишнее: business — составляющую и IT-составляющую («головы» и «хвосты»), маркетинг и алхимию. С другой стороны, народный BPM — инструмент (воплощение методы), как и самогонный аппарат, должен быть: простой, понятный, надежный, эффективный (практичный) и доступный каждому (сырье — процессы компании или домохозяйства). Лучше сосредоточиться на этом, а не на пиаре промышленных вендорных решений с заоблачным ценником, гонящих продукт сомнительного качества.
В статьях хотелось бы найти ответы не только философо-методологического характера (терминология, классификация, задание границ дисциплины, разграничение зон ответственности внутренних подсистем дисциплины и т.п.), но и пути решения практико-технологических проблем. Их много. Некоторые показаны в Методология моделирования и анализа бизнес-процессов ARIS: достоинства и недостатки
Покажем подробнее одну из них на примере. Интересно, почему авторы статей по BPM и комментаторы к ним не любят примеры, особенно критические (критиканские)?
2.5 Пример проекта BPM aka BPA
Рассмотрим частую проблему, которая не под силу даже «современным высокотехнологичным» BPA – инструментам (их прогресс «заснул в одном ботинке») и гениальным алхимикам (alBPM). Ситуация следующая.
В один прекрасный солнечный день с «легкой руки» профессиональных алхимиков на предприятии внедряется «крутой» BPM aka BPA, например, что-то из «секретного» (зачем скрывают цены десятилетиями?) прайс листа BPM №1
Далее общими силами:
— собственные художники (штатные, но прошедшие у консалтера курс «натюрморт»),
— художники консалтера-интегратора, а иногда и
— художники «самого вендора» дружно рисуют миллион кружков — квадратиков (объекты орг-структуры и другие иерархии, EPC и другие workflow) и корабликов (VAD, Value-added chain diagram) и т.п.
«Боевая VAD – флотилия» под парусами BPM – это вам не примитивные бухгалтерские самолетики c дебетом и кредитом!
Часто цена пришлых художников (консультантов и вендоров) сдельная: сколько моделей нарисовал – такова и цена за работу. Если их штаб-квартира в Европе, то и ценник в евро. Когда «сдельно», да еще и за «за еврики» – тогда квадратики и кружки из «под пера» BPM-медельеров вылетают «как из пулемета»: хоть «as-is», хоть «to be», что «как есть», что «как не есть» и т.п.
Все это складывается под вывеской «Операционная модель компании», Corporate Process Map, Business Process Map и подобными, а красивые разноцветные диаграммы (схемы) публикуется на корпоративном ресурсе.
Полученные художества называются «модели бизнес-процессов», а сами художники носят титул «Специалист по процессному управлению» — «Специалист по архитектуре бизнес-процессов»
Через какое-то время энтузиазм своих — штатных сотрудников — художников угасает (и финансы тоже) и …
приходит осознание, а «что с этим добром делать то?». Большая часть всех «кружков — квадратиков» – быстро устарела, кораблики «заржавели» (а некоторые вообще затонули), цветные картинки на корпоративном паблишере стали не только не нужны, но и опасны: «что там за ахинея у вас нарисована»?
Содержать значительный штат своих художников, которые к тому же будут постоянно бегать за бизнес-спецами профильных подразделений, чтобы «под чутким руководством участников процесса» перетасовывать квадратики и «перестраивать боевые порядки корабликов» – проблематично даже для крупного предприятия. Примеры флотилий смотри начиная с пункта «3.2. Продукты и услуги»
Проблема не только в том, что изменились сами процессы и их описания значительно отстают от жизни. Просто ранее художники «очень старались» и «в творческом порыве» было очень много «чего» нарисовано: у одних «на энтузиазме», а у других через «стоимость рабочего дня, зависящей от количества нарисованных моделей». Конечно, «виноваты во всем» оказались респонденты, но от этого не легче.
Уже изначально многие «as is» были далеки от «as really is», но это стало понятно лишь спустя время. Кроме того, художникам нужно не только переделывать старое, но и рисовать новое, только незадача:
пока чинишь одно, ломается то, что недавно чинил, а на новое нет сил.
От указанных проблем не спасает ни один самый «крутой современный» инструмент. От этого не спасает сотня встроенных отчетов (шаблонов) в этот самый «крутой современный» инструмент, не спасают «методологические фильтры», семантические проверки и «соглашения о моделировании».
Не спасает даже «волшебная красная кнопка»: когда по всем этим корабликам и кружкам «по кнопке» можно «автоматом генерировать» должностные инструкции, текстовые регламенты и другие нормативные документы на основе моделей. Причем, вначале это воспринималось как «нечто сверх естественное», но потом даже при актуальных моделях (данных) пришло понимание в их никчёмности. Когда-то примерно таким же образом жрецы дурили народ солнечными затмениями.
«Половник дегтя» добавляют разные технические и организационные «накладки, несовместимые с BPM». Например, «забавно» получается, когда одна из ролей (орг-штатных единиц) делится, т.е. вместо одной становится две единицы с разделением функционала, или появляется новая с отбором части функций у существующей.
В результате во всех процессах (функциях) с участием «таковой» нужно вручную переправлять исполнителя, т.к. «автоматическая замена» невозможна (нет четкого правила для замены).
Подобная ситуация по ведению «большой модели» ограниченными ресурсами идентична что в 2016-м, что в 2001-м (ничто не изменилось). Одинакова на разных предприятиях. В большинстве случаев на нее просто «забивают» и на предприятии «проект BPM» переходит в фазу: «game over». Схемы летят в мусорную корзину или остаются «в виде памятника BPM».
Еще интереснее ситуации, когда происходит смена «парадигм» и самих инструментов: вначале рисовали в BPwin «жучков с ножками» — IDEF схемы, но прошло «озарение» и наступила «эра ЭрисЪ» и всем пришлось перерисовать процессы из «жучков» в «кораблики» (VAD) и овальчики (EPC) и другие новые «божественные символы» успеха и эффективности.
Причем перерисовывать весь миллион символов (объектов модели).
Очередные «озарения» приносят вендоры, но при поддержке их «новых заветов» ведущими консультантами и бизнес-аналитиками: IDEF0 теряет популярность?
Но выход, надеюсь, есть. «Мои знания пессимистичны, но моя вера оптимистична».
Развитие «Natural BPM (process tech) vs alchemy» в целом и продолжение классификации в частности – в следующем номере.
К сожалению в раздел «Терминология ИТ» не могу вписать, т.к. кармы не хватает.
bipiem
