Не секрет, что разные люди понимают под BPM очень разные вещи. Некоторые называют BPM старый добрый реинжиниринг с его «as-is» и «to-be», другие - регламентацию бизнес-процессов и/или внедрение Системы менеджмента качества, третьи - автоматизацию бизнес-процессов в ERP-системе, четвертые - покупку и внедрение BPMS, пятые - workflow в ECM-системе и т.д.
Мне лично ближе позиция тех, кто понимает BPM в духе книги Смита и Фингара «Business Process Management: The Third Wave» - как цельную дисциплину, включающую в себя методологическую и технологическую (BPMS) составляющие, а также (добавляю я от себя) принципы реализации проектов Agile. Ключевые классифицирующие признаки BPM в этой трактовке - 1) управление изменением бизнес-процессов в замкнутом цикле и 2) устранение разрыва между бизнесом и ИТ. Такая трактовка мне больше нравится по той простой причине, что я считаю расточительством вводить новый термин для обозначения практик, существующих уже добрый десяток лет. (Аббревиатура BPM стала широко распространяться примерно с 2003 г., в то время как реинжиниринг существует с начала 90-х, а идеи TQM относятся к 80-м.)
BPM в широком и узком смысле слова
Таким образом, мы имеем две основные трактовки BPM:
- BPM в широком смысле слова, или BPM как имя нарицательное, или BPM как зонтичная концепция - управление бизнес-процессами (business process management) во всех его проявлениях.
- BPM в узком смысле слова, или BPM как имя собственное, или BPM как целостная дисциплина (методология плюс технология плюс принципы реализации), сложившаяся в первом десятилетии XXI века.
В свое время Александр Самарин предлагал выработать общеупотребительное определение BPM. К сожалению, общеупотребительное определение может только сложится само, его нельзя «выработать». Достижению консенсуса мешает то, что каждый вендор и консультант в конечном итоге претендует на то, что BPM - это то, чем занимается он или его организация. Ведь BPM - достаточно раскрученный бренд.
Конечно, такое положение дел не способствует росту рынка BPM (в любой из трактовок этого термина). Ведь что должен думать потенциальный спонсор проекта BPM, слыша эту разноголосицу? «Если вы все такие умные и беретесь учить меня, то что же вы друг с другом договориться не можете?!»
Доходит до курьезов: недавно на семинаре bpms.ru один из участников, представлявший крупную российскую страховую компанию, говорил, что BPM-а у них нет, а другие участники семинара убеждали его, на основе его же собственных слов, что есть. Что же такое этот BPM, если мы даже не можем решить, есть он в нашей собственной компании или нет?!
Полагаю, нам следует смириться с тем, что единой трактовки термина BPM нет и не будет - как, к слову сказать, нет и уже не будет единой трактовки термина «бизнес-процесс». Соответственно, каждый желающий высказаться на эти темы, предложить или запросить услугу в этой области, должен начать с определения: что лично он называет BPM и, заодно, что он называет бизнес-процессом. Как минимум, ответственный специалист должен уточнить, имеет ли он в виду BPM в широком или в узком смысле слова.
Но желательно было бы позиционироваться более точно.
Трехуровневая классификация BPM
За основу классификации я предлагаю взять шкалу зрелости BPM по Гартнеру (Gartner BPM Maturity Model).
В 2006 г. Гартнер предложил 6-уровневую (от 0 до 5) модель зрелости BPM, которую, дабы не нарушать авторские права, я перескажу своими словами:
- Фаза 0. Функциональное управление. Организации еще только предстоит осознать, что ее эффективность как целого зависит не только от того, как выполняются те или иные функции, но и от того, насколько хорошо выполнение этих функций координировано друг с другом, т.е. от качества связывающих их бизнес-процессов.
- Фаза 1. Осознание бизнес-процессов. Организация познает саму себя через призму бизнес-процессов. Выделяются сквозные бизнес-процессы, им назначаются владельцы. Все увлеченно рисуют схемы бизнес-процессов. Разрывы и явные узкие места выявляются и устраняются, причем без привлечения средств автоматизации процессов (BPMS).
- Фаза 2. Автоматизация исполнения и контроля отдельных бизнес-процессов. Организация учится управлять процессами в непрерывном цикле моделирование - исполнение - анализ, добиваясь повышения их эффективности, пока на уровне отдельных бизнес-процессов.
- Фаза 3. Исполнение и контроль сквозных бизнес-процессов. Расширяя границы процессов, находящихся под управлением BPMS, и налаживая межпроцессное взаимодействие, компания выстраивает управление сквозными процессами, пронизывающими организацию насквозь и замыкающимися на внешних заказчиков/партнеров и/или взаимодействующими с их бизнес-процессами.
- Фаза 4. Явная и автоматическая связь между бизнес-целями и бизнес-процессами, в том числе на основе имитационного моделирования и динамических бизнес-правил. Изменение целевых показателей бизнеса влечет за собой автоматическое перестроение сети бизнес-процессов.
- Фаза 5. Адаптивная бизнес-структура. Способность быстро реагировать на происходящие в бизнес-окружении изменения, а также предвидеть такие изменения и самим создавать благоприятные возможности благодаря глубокой интегрированности в различные рынки и партнерские экосистемы.
Последние две фазы я бы отнес к разряду научной фантастики. Подозреваю, их до сих пор никто, включая аналитиков Гартнер, в глаза не видел, и не факт что когда-нибудь увидит. Нулевая фаза - непроцессная. Итого остается три:
BPM-1: Описание и моделирование бизнес-процессов
BPM-2: Управление отдельными бизнес-процессами
BPM-3: Управление сетью сквозных бизнес-процессов
С этим уже можно работать. Все-таки исходная шкала Гартнер столь громоздка и изложена таким языком, что объяснить ее свежему человеку «на пальцах» я лично не способен.
При желании можно выделить подуровни:
- На уровне BPM-1 некоторые ограничиваются текстовыми регламентами, более продвинутый вариант - графическое моделирование бизнес-процесса, из которого текстовый регламент генерится автоматически, и единый репозитарий бизнес-процессов.
- На уровне BPM-2 не всегда реализуется цикл усовершенствования, зачастую дело сводится к однократной автоматизации.
Если бы и заказчики, и вендоры/консультанты формулировали свои запросы и возможности, ссылаясь на эту шкалу, то это способствовало бы лучшему между ними взаимопониманию. Например, заказчик мог бы для себя определиться так:
Мы сейчас находимся на уровне BPM-1, в основном пользуемся текстовыми регламентами. Для регулярной сертификации по ISO9000 нам нужна собственная компетенция в полном объеме BPM-1, с графическими моделями и единым каталогом процессов.
Для вспомогательных процессов в области управления персоналом нам нужен внешний консультант с подтвержденной отраслевой компетенцией и квалификацией BPM-2.
Для операционных процессов «от заказа до оплаты» нам нужен внешний консультант с квалификацией BPM-3. Помимо работы над процессами, он должен помочь нам создать собственный центр компетенции, который через 12 месяцев сможет взять на себя 80% работ.
После этого можно подбирать исполнителей среди консалтинговых компаний, работающих на уровнях BPM-1, BPM-2 и BPM-3, и присматриваться к инструментарию:
- для уровня BPM-1 необходим моделер/дизайнер процессов, для целей каталогизации полезным также будет инструмент класса Enterprise Architecture
- для уровня BPM-2 достаточно workflow-движка, встроенного в ECM или CRM-систему
- уровень BPM-3 требует полноценной BPMS, причем задачи уровней BPM-1 и BPM-2 она тоже сможет решать
При этом не следует смотреть на это дело таким образом, что нижние уровни - это плохо, а верхние - хорошо, и что мы изо всех сил должны стремиться достичь верхних уровней зрелости BPM для всех своих процессов. У меня большая претензия к шкале Гартнера из-за того, что она создает именно такое представление.
Ключевые слова - «для всех процессов». Пытаться равномерно поднимать зрелость всех процессов - это верный путь к краху. Закон Парето никто не отменял - условно говоря, 20% процессов отвечают за 80% эффективности компании. Не лучше ли сфокусироваться на этих 20%?
Конечно, BPM-3 обеспечивает намного более полный контроль над процессами по сравнению с BPM-1. Но он ведь и обходится намного дороже! Полноценная реализация сквозного бизнес-процесса в BPMS - это, помимо всего прочего, заказная ИТ разработка. А заказная ИТ разработка дешевой не бывает.
Консультант BPM-3 может добиться более глубокого контроля над бизнес-процессом, но это не дает ему права смотреть свысока на коллег, работающих на уровне BPM-1, так как он способен добиться результата только на относительно узком фронте, а они могут охватить, пусть и не со столь глубоко, деятельность компании в широких границах.
Вторая моя претензия к шкале зрелости Гартнер: она создает представление, что ее надо проходить последовательно, ступень за ступенью. Совершенно не обязательно!
Организация, заразившаяся идеями процессного управления, вполне может поставить себе цель перейти от нулевого уровня BPM на третий. Да, это займет некоторое время, потребует накопления собственной компетенции, но делать промежуточные остановки на уровнях 1 и 2 вовсе не требуется.
BPMN как связующая нить
Все, что относится к бизнес-процессам, принципиально изменчиво. Например, мы должны быть готовы к тому, что через полгода мы придем к выводу, что какие-то процессы, для которых мы определили достаточным уровень BPM-1, требуют уровня BPM-3. Естественно, хотелось бы видеть преемственность: чтобы результаты работы на уровне BPM-1 были бы использованы при переходе на уровень BPM-3.
Рецепт прост: используйте BPMN.
Принципиальной особенностью этой нотации является методологическая нейтральность - проще говоря, ее можно использовать очень разными способами для очень разных целей.
- чтобы рисовать аналитические диаграммы BPM-1, используйте минимальное подмножество элементов BPMN
- на уровне BPM-2 понадобится BPMN-оркестровка в полном объеме
- уровень BPM-3 потребует полной палитры BPMN - сообщений, сигналов, обработчиков событий, транзакционных подпроцессов и т.д.
Что ценно - между этими, достаточно разными, диаграммами будет сохраняться преемственность: превратить аналитическую BPMN-диаграмму уровня BPM-1 в исполняемую BPMN-диаграмму уровня BPM-2 будет проще и намного надежнее, чем, скажем, перерисовывать IDEF0 в BPMN. На уровне BPM-3 альтернативы BPMN практически нет, поэтому лучше придерживайтесь его на всех уровнях.
Да, и чуть не забыл - мы (Бизнес-Консоль) специализируемся на BPM-3.
Good post, as always!
I don’t agree with many things in the Gartner BPM Maturity model. It’s not even worth commenting all of them. But one of those things you sort of keep in your three-level model: “BPM-3 requires a full-scale BPMS”. I don’t think so. Companies can have successful BPMS implementation and still be immature in BPM and just as well could be quite ahead in BPM without using BPMS. And I’m not talking hypothetically.
Ivo
You are right - this aspect deserves to be considered in more details. May be in next posts.
There are number of BPM without BPMS cases indeed but the ones I’ve seen can’t be attributed to level 3. They don’t cover a processes end-to-end and/or don’t provide agility.
As for BPMS without BPM, I had it mind it when saying “BPM-2 doesn’t always implement continuous improvement cycle, in many cases it is reduced to one-time process automation”.
Hi Anatoly,
I agree with your comment that the definition of BPM will necessarily ‘emerge’ as market demands and technologies evolve. In that regard, Gartner’s Phases 4 and 5 are looking ahead to some confluence of Adaptive Processes and BPMx that becomes the new definition of BPM. The term Business Process Management is general enough and entrenched enough to be a blanket reference.
Given that you accept that definitions evolve, and your later statement “Everything relating to business processes is fundamentally volatile”, it seems you would appreciate that some applications could benefit from Adaptive Processes, where execution is not constrained to a flowchart so processes themselves can emerge.
I’m not making an absolute comment here. If there are processes that have low volatility (variance/change) and can go six-twelve months between updates, then flowchart-based automation with fixed process definitions are a legitimate approach. However, in higher-volatility environments that can benefit from greater human involvement, then Adaptive Process approaches, related to Gartner’s Phases 4 and 5, without fixed control flows should be considered to enable emergent process definitions.
Is that a balanced view? It would be great to get your feedback.
Best,
Dave
Thank you for sharing thoughts, Dave.
Regarding the definition - in fact, I said quite the opposite: it’d be great to have a widely agreed definition but I personally don’t believe it will ever hapen. Just like there is no single definition of a business process.
You are right: I had “traditional” processes in mind, with lifecycle measured in months and predictable enough to make flowchart usable. Including adaptive processes into classification is an interesting idea, however I can see two obstacles here:
1) BPM levels as defined in the post above are built on top of each other: process modeling from level 1 is also used on level 2; process orchestration techniques from level 2 are used on level 3.
ACM is another story: it shares certain things with traditional BPM e.g. task lists or activity monitoring but it leaves behind all techniques dealing with process diagram. Hence it can hardly be presented on a same scale. Guess we’ll need something two-dimensional.
2) I seriously doubt that Gartner’s report has anything to do with what we call ACM today - after all it’s dated 2006. I believe they meant a different kind of agility; however it’s just my opinion - the language of the report is so vague that it leaves quite a room for interpretations.
Thanks for the response Anatoly.
I did understand that you were saying a single definition for BPM was unlikely, and I agree. Sorry if I was unclear, I was simply conjecturing on Gartner’s use of the term relative to their 5 Phases. They weren’t thinking about ACM, that’s why I stuck with the term Adaptive Process, but by 2006, with SOA, BRMS, EDA already on the scene folks were already starting to see the potential for loosely-coupled Tasks.
Your BPM maturity model is aimed at the development of a sound BPMN-specific practice. Adaptive Process fits in one of two ways: 1) as an extension of the practice for those operations that have the greater volatility for select processes and/or select activities within certain processes - the 2nd dimension you referenced; or 2) as evolution through decomposition of Task sequences and definitions.
Is that a fair assessment?
Dave
Cannot disagree.
Thanks Anatoly for the ref.
My offer is still open and as shown in the post ( http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html ) BPM (as a discipline) is much richer than “rigid flowchart”. Also, thanks to BPMN and “social”, there is a better understanding that different activity-coordination techniques (i.e. template-based, event-based, data-based, rule-based, role-based, intelligence-based, community-based, etc.) should be used together. Of course some BPMSs (as technology) do not implement all this richness.
I looked again at this Gartner article and found interesting their description of motivations for different phases.
“The primary motivation of Phase 3 is to optimize the relationships between business processes across functional barriers, partners and customers.” – sounds like the “social” aspect of the managing by processes.
“The primary motivation of Phase 4 is to link process results to desired operational and strategic outcomes.” – sounds like “goal-oriented” aspect of the managing by processes.
Agree with Anatoly’s remark about “…we should put all efforts in advancing to higher levels for all our processes.” – This classification is a tool/guidance, but not a dogma. Each company should select the desired levels for its processes. In some industries, 3-4 is OK, in other industries it is necessary to go higher than 5.
My interpretation of process-based maturity models is in http://www.samarin.biz/pubs/BPM_for_CMMI.pdf — at the beginning of the curve BPM-as-discipline is necessary, then BPM-as-technology should be added and to reach the top of the curve a proper architecture is mandatory.
Happy climbing,
AS
Alexander
Enjoyed your comment, thank you.
A small remark: my point was not exactly that each company have to select the process level which is best for its processes. Each company should “sit on several chairs” - operate at several process levels at once, deciding which processes which level deserve.
The overall maturity then may be defined as the highest level the company is able to reach, yet the majority of its processes (80/20 rule) would remain below this level.
Considering this, it’s better to talk not about “BPM Maturity” as Gartner does but about “BPM Capability Maturity” - we are capable of doing something yet it doesn’t necessarily mean we do.
Anatoly, we are on the same page - “…desired levels for its processes” - not all processes within a company require to be the same level of agility at the same time. Just an extra optimisation issue (or optimal agility) which may be a bit more sophisticated than 80/20 rule.
Thanks,
AS
Anatoly, I agree and I like your syllabus of the BPM stack.
I’m not so sure instead about proposing BPMN as the panacea for all the problems and interpretations. It can be a common ground as you say, but for sure will not enable all you mention “per se”.
Marco
Marco
Thank you. Frankly, I wasn’t sure it’ll be accepted by the expert community.
Agree with your note. BPMN has clear advantages over alternatives but definitely isn’t a a panacea.
As an example, BPMN doesn’t work for me when I need a high-level process architecture diagram. I use plain old DFD for this purpose, each DFD process referring to a separate BPMN diagram.
Anatoly,
I think I have to agree with you. We should start a new movement to make al those gurus. gartners, etc aware that we don’t care about maturity models. We want to know why BPM is good for us. And if we decide to implement it we want to know how we have to do it.
Indeed some processess need more management (is that maturity?) and some don’t.
Personally I am very happy I am not so mature ;-))
Procesje
Анатолий,
Позволю высказать мысль, которая мне пришла по прочтению вашего поста.
По поводу шестиуровневой модели зрелости и Вашего упрощения ее до трехуровневой.
Думаю тут уместно оглянуться на аналогию: любую модель жизненного цикла компании. Такую модель используют не как расчетную, а как ориентирующую.
По моему мнению, модель Гартнера полезна в плане ориентации: куда должно приводить BPM. Вендоры и внедренцы должны использовать ее как стратегический ориентир в текущих проектах с оглядкой на перспективы. При этом в голове формируется понимание отличия workflow от BPM. Использование только workflow не может привести к уровням 4 и 5 по Гартнеру. BPM же способно на это, хотя пока и без практических примеров.
Сергей
Спасибо за Ваше мнение.
Гартнер конечно могуч, и я не без внутреннего трепета позволил себе с ним не согласиться. Но у меня была веская причина: в разговоре с потенциальными заказчиками оперировать этой моделью не получается. Не для людей она.
А потребность в какой-то единой модели есть, потому что слишком много процессных гуру говорят слишком разные вещи. Одни ратуют за бумажную регламентацию, другие за автоматизацию документооборота, третьи за исполняемые процессы.
Что касается уровней 4 и 5 - Вы читали оригинальный документ? Я вроде по-английски понимаю, но то что там написано - это муть голубая.
Причем в модели Гартнера прослеживаются явные параллели с 5-уровневой моделью CMMI, к которой у меня претензий нет - все понятно, все разумно. А у Гартнера какие-то, простите, фантазии: BPM-системы, которые сами перестраиваются, когда президент компании задает новые целевые ориентиры. Вы хотите сказать, что это полезно в качестве стратегического ориентира? Сомневаюсь.
В реальности BPM эволюционирует совершенно в направлениях совершенно иных, чем это виделось аналитикам Гартнер пять лет назад: ACM, облака, мобильные приложения.
Согласен насчет Гартнера - мутная классификация.
По классификации Анатолия, мы работаем на уровне BPM-1. При этом, работы более чем достаточно. Разработка архитектуры процессов, описание процессов под регламенты, выполняемые людьми, - эти задачи продолжают оставаться актуальными. Но кроме описания процессов и формирования регламентов на уровне BPM-1 еще очень много другой работы: разработка методов контроля регламентов, разработка показателей, анализ и оптимизация, нормирование, мотивация персонала на исполнение стандартов и проч.
Не предполагал, что Анатолий найдет место всем уровням BPM в своей концепции. Еще года 3 назад он, имхо, считал реальным BPM-ом только BPM-3. Хорошо, что взгляды поменялись, и в концепции нашлось место всем.
Кстати, про BPM-1 много информации на сайте http://www.finexpert.ru
Владимир
Рад, что предложенная классификация не вызвала у тебя протеста.
> кроме описания процессов и формирования регламентов на уровне BPM-1 еще очень много другой работы: разработка методов контроля регламентов, разработка показателей, анализ и оптимизация, нормирование, мотивация персонала на исполнение стандартов и проч.
Разумеется. На остальных уровнях тоже деятельность многогранная, просто тут я не стал входить в подробности.
> Еще года 3 назад он, имхо, считал реальным BPM-ом только BPM-3.
Честно говоря, я и сейчас так считаю
Но признаю, что это экстремизм - http://mainthing.ru/ru/item/500/
В конечном счете, это ведь вопрос терминологии. То, что деятельность такая востребована множеством организаций, вопроса не вызывало и не вызывает. Но дело в том, что BPM в первоначальном значении этого термина (в духе манифеста “The Third Wave”) - это то, что я здесь назвал BPM-3. А потом BPM превратили в зонтичную концепцию, охватывающую BPM-1, 2 и 3. Нравится это кому-то (мне например) или нет, но таково существующее положение вещей: термин растянули.