Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»


    Крошка сын к отцу пришёл, и спросила кроха: — Что такое хороший 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
    Поделиться публикацией

    Похожие публикации

    Комментарии 15

      +4
      Спасибо, за сборник цЫтат и аббревиатур. Больше нечего сказать.
        0
        На здоровье.
        Надеюсь, что у всех проминусовавших хватило сил прочитать статью целиком. И хотя бы немного подумать.
          0
          Знаете, я вот минусануть не могу, но честно говоря — плюсовать тут тоже не за что. Понятно что вы старались, но скажем прямо — читать сложно, и понять, что вы хотели донести, еще сложнее.

          Ну так, просто для примера: совершенно не ясно осталось, куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.? Сами по себе большинство перечисленных аббревиатур, методик и пр. гроша ломаного не стоят. Я совершенно не хочу сказать, что без BPMN никуда, наоборот — у подобных нотаций есть масса врожденных недостатков, от которых практически невозможно полностью избавиться.

          Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение. Никуда не уйти и без существующих приложений — поэтому нужно интегрироваться с уже написанным их зоопарком. Это реальная рутина, которая вполне способна погубить любой проект.
            0
            понять, что вы хотели донести, еще сложнее.
            Картинки понятны?

            куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
            ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого, например, в том же стеке сетевых протоколов: прикладной, (другие), сетевой, канальный, физический. Вы строите IP-маршрутизацию на сетевом не зная, какой у вас канальный и прикладной.
            В принципе, точно также вы проектируете процессный уровень, без углубления в специфику ИТ (канальный) и бизнес-модель (прикладной). У каждого уровня свои задачи, свои принципы. Конечно они связаны, но проектируются независимо.

            Может вообще не будет ИТ, а все процессы ручные. Или 50 на 50: бывает основной вариант — доставка информации по е-почте, а резервный — конверт в зубы и на трамвай.

            Вопрос что первично: «процессы или ИТ» – философский, как и «бытие или сознание», «курица или яйцо» и т.п. Однако, в современном мире пока первично ИТ, но лишь благодаря причинам, указанным в обоих статьях.

            Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение.
            Посмотрите п. 2.5 Пример проекта BPM aka BPA
            Подобные проекты часто вообще не подразумевают автоматизацию, а лишь желание разобраться, что уже «на-автоматизировано». Более подробно на этом остановлюсь в третьей главе.

            Подскажите бестолковому, почему некоторые комментарии требуют премодерацию, а другие нет? Как убрать премодерацию?
              0
              Премодерация — это для лентяев типа меня, которым комментировать хочется, а статьи писать лениво или некогда.

              >>куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
              >ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого,
              Ну так ктож против декомпозиции? Вопрос только в одном — чтобы декомпозировать, особенно IT от остального, нужно формализовать на каком-то языке интерфейсы между уровнями. Мой опыт мне говорит, что скажем BPMN для этого годится плохо, и свои цели, как их декларируют, не достигает по ряду причин. Так что ждем на этот вопрос ответа дальше.
        0
        Спасибо за такой объём материала и свежий взгляд.
        Я сам пришёл к схожим выводам, будучи изначально обычным разработчиком, побыв недолго менеджером продукта и представляя сейчас объединение веток управления ИТ-подразделением и менеджмента качества в компании.

        И мне крайне близок подход PTSM. Но до появления этой статьи я начал задумываться — может быть что то не так и я не прав/нет опыта или понимания: весь мир говорит об ITIL/Lean/BPM/ISO 9000/ТОС и т.п., но никто не объединяет эти подходы и не пытается выстроить общую разумную модель. Но теперь я спокоен и полностью удовлетворён — я двигаюсь в правильном направлении и мои выводы, в целом, верны.

        По сути статьи, могу добавить, что при использовании описанного подхода в достаточно крупной компании имеет смысл в найме специального человека, который будет понимать и бизнес на уровне стратегии, и бизнес на уровне операционном и ИТ на уровне всех процессов ITIL и саму суть работы компании. Это должен быть грамотный CIO/CQO или иной CxO, который сможет организовать координацию всех участников и продвигать на всех уровнях компании разумные методы и политики.

        Проблема только в том, что таких специалистов, на мой взгляд, слишком мало и ещё меньше компаний, готовых подобный подход внедрять
          0
          весь мир говорит об ITIL/Lean/BPM/ISO 9000/ТОС
          не так давно весь мир считал, что земля плоская.

          смысл в найме специального человека ...
          Я иного мнения. Должна быть наука (дисциплина process tech), которая показала бы, что земля круглая и затмения естественные (подходы к формализации и организации трудовой деятельности), а практическая методичка позволила бы обычному студенту стать таким «специальным человеком». Пока нет ни того ни другого, а в почете жрецы и алхимики.

          Со временем букварь «Архитектура предприятия» или азбуку «процессо-ведение» будут изучать в школе. Только они будут очень далеки от сегодняшнего «привычного» понимания EA и BPM.
            0
            Это был бы идеальный мир…

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

            Я поясню, почему считаю необходимым специального человека:

            1. Как бы то ни было — бизнес-технологи и ИТ редко добавляют стоимость к продукции компании — они являются ресурсом для участников производства и, как следствие, для многих руководителей из основной цепочки — вся эта деятельность вторична.
            2. Основные задачи специалистов и руководителей, создающих продукцию и приносящие прибыль компании — это делать продукцию и приносить прибыль, а не организовывать процессы вне своей сферы деятельности
            3. Технолог всегда снаружи всей иерархии и он может видеть процессы со стороны. Особенно сквозные процессы, охватывающие несолько подразделений и часто он единственный, кроме нескольких топ-менеджеров имеет представление о проблемах, связанных именно с коммуникацией между подразделениями

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

          Конкретно бизнес-процесс — логистическое view. Пример: покупаем карандаши. Куда отправить заявку, кто ее получит и когда, куда он побежит у кого он купит. Бизнес-процесс? Бизнес-процесс. Лучше чтобы их кто-то инженерил.

          Enterprise level — это стратегия (что мы сделали, делаем и куда вообще хотим идти своей долбаной компанией) + структура предприятия.

          Business Process Level — уже понятно. Логистические схемы. Что и как покупаем, продаем, сбываем производим. Все цепочки.
          Infrastructure Level — маппинг людей, должностей и отделов на бизнес-процессы.
          IT Infrastructure Level — информационные системы нужно выделять в отдельное view.
          Financial Level — надо добавить. «токовая» модель, куда втекают денежки, куда вытекают. Чтобы мы знали что мы неубыточны своей компанией.

          Так, судя по вашему анализу, видно что это все в ужасном состоянии от одной терминологии можно шею свернуть. Так этому учить совершенно нельзя. Напрудили прудов.
            0
            Спасибо за оценку.

            Разговоры о сложном нужно начинать с простых примеров. Какая сложная функция не была бы, но подстановка в нее простых значений должна давать результат и по ним можно понять ее поведение.
            Поэтому я прошу приводить простые и конкретные примеры при описании «сложных и профессиональных подходов к BPM и EA».

            Например, есть коммерческий детский садик «Бизнес-ясли» с незатейливой орг-структурой:…

            Но меня отсылают на авторские тренинги.
            0
            Сила мысли впечатляет. В уме у тебя конечно кавардак. Если дальше будешь мыслить с такой же силой, то через 2-4 года в этой области ума наступит порядок.
            Да, процессы и бизнес-процессы это весело :) Маркетинг такой маркетинг. Ну любой более менее знающий спец по процессам в курсе этого. А другим это не особо интересно. Остается узкий слой на грани которых это может впечатлить.

            Далее, ты говоришь что шаг один, шаг два это процесс. Это не так. Это также и процедура. А в чем отличие процесса от процедуры?
            Разница лишь в том что результат процесса — продукт. А результат процедуры — все что угодно.
            Далее ты говоришь что есть продуктовые процессы. Беда в том что других нет. В бизнесе все процессы продуктовые. Абсолютно. Если нет продукта, значит это не процесс. Так написано в ИСО 9000. Ну и я с этим согласен.
            Ты говоришь продукт или услуга. Это тоже самое что сказать «собака или пудель». Нарушение логики видишь? Услуга это продукт. Не может быть союза «или» между ними.

            Ну я плюсанул чисто за силу мысли. Ценность материала очень низкая. Ты показал кашу в своей голове. Ну как бы она у нас у всех там есть. Надо брать что то узкое. Пользы будет больше.

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

              А результат процедуры — все что угодно.
              «все что угодно» — значит и продукт тоже?

              Услуга это продукт.Не может быть союза «или» между ними.
              Почему-то интернет пестрит: «Каталог продуктов и услуг», «Каталог товаров и услуг»?
              Люди не понимают, что пишут?

              За оценку «Силы мысли» — отдельное спасибо. Сам порой удивляюсь, как они все в моей черепушке умещаются и не давят.
                0
                Да, в результате процедуры в том числе может получиться продукт. Ровно тот же что и в процессе. Но состав описанных шагов в процессе и в процедуре будет отличаться. Это не простая мысль. Надо потратить не один год на описание процессов чтобы понять что такое процедура и где она нужна. В статье про 7П я приводил примеры http://systemo.biz/7p-idealnaya-biznes-model-organizatsii/

                >> Почему-то интернет пестрит: «Каталог продуктов и услуг», «Каталог товаров и услуг»?
                >> Люди не понимают, что пишут?

                Ты думаешь что все написанное в Интернете это истина? Или удивляет то что кто то в Интернете не прав? Товары и услуги, также как и товары или услуги — это верная формулировка. В ней нет противоречий. Проблема там где люди начинают противопоставлять услуги и продукты. Хотя услуга это лишь разновидность продукта, ровно такая же как и товар. Это показатель булькающего холодца в головах людей. Если ты этого еще не понял, то скоро поймешь. 99% людей не понимают значение 80% слов которые они употребляют. Они путаюст свои домыслы и шаблоны с реальностью. Не способны отличить картину мира от реального мира. 99% людей уверены что живут в реальном мире и живут так как будто что то знают.
              0
              Спасибо, впервые нашёл статью, на столько полно отражающую мои сомнения в современном классическом ИТ-консалтинге и бизнес-аналитике в частности.
              Выделю своими словами особо понравившиеся тезисы (из обоих глав), они на мой взгляд относятся не только к BPM:
              • Монетизация теологии (не всякая религия добилась такого коммерческого успеха)
              • Сапожники без сапог (обещая измерить все и вся, ИТ-шники не способны дать поддающуюся реальному подсчету единицу измерения собственных услуг)
              • Чем непонятнее тем дороже, (за новыми аббревиатурами скоро не то что Wiki, алфавит не будет успевать)
              • Нам что кухня, что космос, BPM рулит («грамотному» консультанту не важна отрасль/специфика, процесс он и в Африке процесс)
              • Умный консультант отвечает за описание/моделирование/автоматизацию контроля процесса, но ни в коем случае за его результат

              Это далеко не полный список аргументов в статье, написанной пусть и не достаточно складно/гладко, но ёмко и как говорят «в правду – матку». При этом нет цели огульно подвергнуть методологию сомнению, есть даже реальные предложения её упорядочить, правда со справедливой оговоркой, что как только она станет понятной, потеряет свою солидность и как следствие стоимость.
              Вообще, выражаю респект храбрости автора. Надеюсь Вы представляете на что замахнулись. Я не про индустрию, ей совершенно не грозят никакие сомнения. Гиганты этой индустрии подкрепили голую теометодологию реальным софтом, местами так удачно, что уже не разберёшь где курица, а где яйцо. Я про хлеб и опору тех серьезных парней, посвятивших этому жизнь и карьеру, ставших признанными гуру, сертифицированных вышеупомянутыми гигантами, всегда дорогих и востребованных на HR рынке в ИТ сфере. Думаю они будут очень недовольны таким подходом к святому.
                0
                впервые нашёл статью, на столько полно отражающую …

                Хочется верить, что «из искры возгорится пламя».

                Я про хлеб и опору тех серьезных парней, посвятивших этому жизнь и карьеру,

                Из моих диалогов с пользователями Хабра:
                < … на мой взгляд, часть алхимиков осознаёт, что они выглядят алхимиками — тот же …

                << Они почти все это понимают. Только, к сожалению, они нам не помогут.
                У нас это «на общественных началах», а для них это «хлеб насущный».

                Но хочется верить, что будут исключения.

                Думаю они будут очень недовольны

                Посмотрите профильные группы на Facebook
                Обсуждение статьи на других ресурсах:
                bpmsoft.org
                club.cnews.ru

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое