Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Levels of process thinking

Bruce Silver posted an article “BPMN’s Three Levels, Reconsidered” on his blog. (It’s a fllow-up to the earlier post on the matter: “Three Levels of Process Modeling with BPMN“.) From his two-years experience of giving BPMN classes Bruce noticed that many of students (he even says “most” couple of paragraphs forward) are simply trying to document, analyse and improve their processes and don’t bother about executable models. Bruce calls this Level 1 of BPMN usage. Level 2 also covers activity flow model suitable for direct execution inside BPMS that includes conditional logic, exceptions, events, messaging (process choreography assumed yet not mentioned).

But is it about BPMN really?

I like the statement Mark McGregor made on the cover page of his new book “Winning With Enterprise Process Management” (freely available at

…process thinking takes many forms - Business Process Management, Continuous Process Improvement, Six Sigma, Lean Sigma, Business Process Reengineering and many others…

Mark is right: it’s about thinking. Process thinking. Different kinds of process thinking, to be precise.

Do you remember the times when object-oriented programming was just invented? It was noticed that it’s not about programming languages. One could write object-oriented software even with Fortran (and some people did when there were no decent C++ compilers) if he catched the idea. And of course you can (and many people actually do) write 100%-functional code on C++.

An interesting observation was made at that time: it’s much easier to teach C++ to a newbie than to experienced C programmers. The reason - it’s about installing a certain kind of mindset (object-oriented in that case) or changing it. The latter turns out to be much harder than the former.

Now I have absolutely the same experience with people trying to understand what BPMN (BPM, BPMS - you name it) is about. Those who deal with business processes for years and have strong background in BPR, ISO9000 etc. can’t grasp what’s so cool about executable process models. They always considered execution to be “implementation details”, something IT should care about. Some of them become irritated enough to say or write that BPM is nothing new, it’s pure marketing, it’s an “umbrella concept” etc.

By contrast, every student and/or junior consultant becomes excited about possibilities that this concept opens. When you just draw a process diagram you can make a dozen of them, all being valid and all being different. That’s no good. When execution is involved - even in it’s simplest form, with simple automatically generated screens and zero integration - you go from “diagrams” to “the diagram”. The analyst isn’t in position to draw an unconsistent diagram any more: if he does, the diagram returns back to him with developer’s note “sorry, can’t be executed this way, please correct”.

Getting back to BPMN Training - Bruce uses Process Modeler for Microsoft Visio by itp commerce for his classes. It could be a perfect choice: high level of BPMN compliance and strong simulation capabilities. But there is no execution. And you just can’t explain what is the execution by words and slides, without showing it.

When we realized this fact several years ago, we recorded and published a simple demo video showing BPMS modeling and execution. And it became a hit. Many people said “thank you” because it helped them understand the directly executable process model concept, regardless of BPMS used.

So Bruce, if you wish more people moved from Level 1 to Level 2, you must show them how a model can be executed in BPMS and how iterational modeling and execution is done. Don’t leave it implicit and don’t assume people know it already. Because as you say it yourself - most of them don’t and it’s the key assumption behind BPMN.

12/08/08 | Responces |    

Comments (22)

  1. Alexander Samarin 12/08/08 08:57 PM

    I think, before “moving” people from Level 1 to Level 2 and further, we have to ARCHITECT all these levels — it is not nice to invite people into a chaotic place.

    Such architecting should be done from CUSTOMER position, but not from VENDOR position.


  2. Anatoly Belychook 12/08/08 09:33 PM


    So there will be architects and ordinary people? Not my phylosophy, sorry.

    An idea (inspiration, belief, logos) is always first, artefacts are just derivatives. Every man “moved” contributes.

    Process is everything, destination is nothing :)

  3. Alexander Samarin 12/09/08 12:39 AM


    I didn’t say that.

    By definition, architects work for a client (including “ordinary people” in this case).


  4. Anatoly Belychook 12/09/08 08:48 AM

    Alexander, thank you for the comments and sorry for getting you wrong. I didn’t mean to push a particular vendor. My point is: anyone who wants to be professional in process management must have a hands-on experience with some BPMS. Any of them - there are more similarities than differences. Unfortunately many of “process people” today (majority according to Bruce) don’t have such experience and don’t even realize they should. Customer’s and vendor’s position - isn’t it a kind of hen and egg problem? You shouldn’t narrow your vision by one particular offering indeed. But if you are building something real than you can’t ignore current state of technology and build it with a future tool of your dream.

  5. Alexander Samarin 12/09/08 09:54 AM

    Sure, we have to be pragmatic — my point is that even the biggest bosses of this planet understood that building of the right thing must
    start from its architecture (G20 discussed “financial architecture”). Organise chickens to provide a better stream of better eggs?


  6. Anatoly Belychook 12/09/08 01:57 PM

    Let’s consider the “architectural architecture” instead of financial.

    When I want to build a house I hire an architect first. Yet many people don’t - they rely on their own creativity and on engineer’s knowledge of construction technologies and materials. This is no good: you may have a dozen of brilliant design ideas but for sure there will be one or two really bad ones that will lead to disaster. A professional architect would never make them. An engineer (like an IT vendor) will look for a fast, reliable and hassle-free way to build your house. Will you feel comfortable with it? Not his problem.

    This is your point if I got it right. No objections of course. The only problem is to find a good IT architect - the enterprise architecture is a new discipline so it’s harder than finding a good “architectural architect” which isn’t an easy task either.

    My point: any architect should be familiar with modern construction technologies and materials. It’s a problem sometimes because technologies and materials progress rather fast. So if you hire an obsolete man he won’t develop the best project. I can witness that many IT architects are not aware of what they can get from today’s best BPMSes. This makes them obsolete and negatively affect architectures they develop. BPMN Training if taken alone can’t help - this is expected and this is what Bruce observes.

  7. bas 12/10/08 11:29 PM


    М.б. Вы и правы продвигая идею BPM. Т.к. я люблю сравнивать разработку ПО со строительством, то пришла такая идея. Когда не было всяких 3Д графики, то после проектирования сложного здания далали его макет, чтобы лучше представлять - что же получится. Как появилась 3Д графика, то модель строят уже в специализированных программах. Так наверное и с БПМ, БМН - это бизнес архитектура, а исполняемая модель - уже макет.

    И вроде бы все хорошо, но встает следующий вопрос - если я хочу исполнять модель, то я должен покупать дорогущий инструмент для этого. А для моделирования БП я, например, ща использую полнофункциональную программу ЕА за 200 дол. для моделирования на ЮМЛ, БПМН + управление требованиями . Так могу ля использовать движок БПМ с моим любимым средством?

  8. bas 12/10/08 11:59 PM


    Кстати, Брюс говорит об исполняемых моделях только на 3ем уровне, а не как ты пишешь.

  9. Anatoly Belychook 12/11/08 11:07 AM

    По поводу русского и английского.

    1) А что, нормально когда весь мир обсуждает профессионально-ИТшные темы по английски, а русские устраивают междусобойчик в своем углу? Причем “весь мир” - это не фигурально. Я был в немецкой компании, был во французской - везде рабочий язык английский.

    2) Вот я написал отклик. На блоге у Брюса появилась обратная ссылка. По ней ходят люди (сверяюсь по статистике): из Штатов, из Германии, из Японии, из Бельгии… И что они должны видеть - что тут какие-то угрюмые русские что-то непонятное обсуждают на своем непонятном языке?

    3) Что касается Самарина, то ему по-английски подозреваю писать на профессиональные темы проще, чем по-русски (не надо подыскивать термины), и к тому же у него на рабочем месте нет клавиатуры с русской раскладкой.

    Я понимаю, кому-то может быть сложно выражать свои мысли на английском (когда мы пишем на иностранном языке, мы всегда выглядим несколько тупее чем на самом деле) - нет проблем, пишите по-русски. С чтением английских комментариев, надеюсь, проблем нет.

  10. Anatoly Belychook 12/11/08 11:40 AM

    Мне больше нравится другая аналогия: BPMS - это конструкторский софт, сопряженный со станком с ЧПУ (CAD/CAM, а не просто CAD).

    Можно использовать любую программу, да хоть на бумаге карандашом рисовать - дело не в этом, а в том, чтобы понимать что из нарисованного может быть исполнено хотя бы в принципе, а что нет. Люди в том же ARIS рисуют такие диаграммы… когда делаешь из них что-то исполняемое, просто камня на камне не остается, схема меняется до неузнаваемости.

    Причем я не против EA - наоборот, полностью “за”. Сегодня ситуация такова, что ни EA не заменяют BPMS, ни наоборот. Надо использовать и то, и другое, но по назначению. Что означает: в EA выполнять только высокоуровневое моделирование - связь процессов между собой и с другими артефактами. Но не опускаться на уровень детализации отдельного процесса - все равно ничего путного не получится, это надо делать средствами BPMS.

    А слухи о дороговизне BPMS “несколько преувеличены”. Если речь идет о моделировании и об исполнении “в песочнице”, а не в промышленно-корпоративном масштабе, то полно бесплатных вариантов.

  11. Julia Wagner 12/16/08 03:58 PM

    If you are drawing analogies in this case the architect should design not only one house (process), but a building area (enterprise arcitecture). At this stage the architect does not detail each building separately, but he projects the general infrastructure and its communication with an external world. I think that it is the first level (without BPMS). As Anatoly has told, BPMS - it is already detailed elaboration level.
    (Oh, Anatoly, I speak Russian better! :)))

  12. Dafna Levy 12/26/08 06:52 PM

    Your relating to EA reminded me of a quote I’ve read, something like:
    “Every organization has an architecture, even if it doesn’t have electricity…”
    Which means, (for me), that there is a big difference in the position and role of architects,
    as opposed to the house situation described above. Therefore a totally different approach might be needed.
    Although I appreciate the benefits of BPMN, I tend to think we might look at an organization as a person,
    with it’s uniqueness. Like a human being, they share the same “physiological systems & needs”, but each needs
    its own special solutions. Too much standardization might ignore this uniquness.


  13. Anatoly Belychook 12/30/08 10:17 PM


    Thank you for your input.

    You raised an interesting set of questions: does an organization have an architecture if they even don’t have an idea about what is it? Is it correct to say that every organization has business processes - even if what they have are only chaotic, ad-hoc, non-repeatable and non-documented ones? Should we call “level 0″ processes (according to the process maturity model) - processes?

    It reminds me the old Russian army joke:
    Soldier: sergeant, are crocodiles able to fly?
    Sergeant: of course no!
    Soldier: but our colonel has said they are?
    Sergeant: really? OK, crocodiles can fly but only at very-very low altitude! :)

    “Naturally-grown” architectures and business processes are like “low-flying crocodiles” for me.

    As for uniquieness and standartization, the ultimate (and ideal) goal of process management probably should be:
    1) we identify and divide all our processes to those we want to excel on and those we don’t
    2) we utilize BPM on the former to develop unique processes that will outperform our competitors and use best practices and packaged solutions for the latter
    3) at the end, we outsource the processes we don’t care much about and become outsourcesers for the processes that we execute better than others

  14. Dafna Levy 01/02/09 11:15 AM


    I like your response.. definitely agree with you. I guess we are “on the same page”. But the challenge is to introduce
    these perspectives and the relevant methodologies to organizations. Seems like the lack of “process orientation” or “process-thinking” is still a “global problem”.
    It amazes me to encounter managers and decision makers that still don’t know what is really a “business process”.
    BPM is also considered a “UFO”…
    I have just uploaded to Slideshare a relevant presentation with guidelines by Alec Sharp which I find to be very helpful and practical..



  15. Anatoly Belychook 01/02/09 08:47 PM

    Dafna - You are right, most people (including not only business men but also business consultants) don’t really understand what business processes are. Alec makes it very clear so thank you for the valuable link.

    But I came to the conclusion some time ago that introducing process thinking is loosing your own time. BPM is a different paradigm really. And one would only switch his paradigm if he was looking for certain ideas himself.

    So I make presentations on conferences and public seminars but never come to an existing customer to say “look, I want to share some new ideas with you, it’s about business processes”. I only meet with an organization if they alread got an interest in business processes and/or BPM. The good news is that more and more business people do become interested in process management every day.

  16. Александра 11/25/09 01:00 PM

    Анатолий, такой вопрос. Скажите, а пере[jд от уровня 2 к уровню 3 как выглядит? Программист садится и начинает писать код для реализации диаграммы? Или BPMN предоставляет какие-то интрументы для автоматической генерации работающего кода?

  17. Anatoly Belychook 11/25/09 01:43 PM


    BPMN - это нотация, она не может предоставлять какие-то инструменты. Инструмент это BPMS - Business Process Management Suite, или BPM-система.

    “Программист садится и начинает писать код” - это традиционный подход, существующий десятки лет. Можно при этом рисовать схему в BPMN вместо IDEF, но к BPM это не будет иметь отношения. Не будет быстрого замкнутого цикла моделирование-исполнение-анализ-усовершенствование.

    В случае BPM/BPMS есть два варианта:
    1) автоматическая генерация кода, например из BPMN в BPEL
    2) непосредственно исполняемая диаграмма

    Эти два подхода подробно разбирает Кейт Свенсон, настоятельно рекомендую его статью: Мне лично больше импонирует второй подход.

  18. Александра 11/25/09 02:05 PM

    Правильно ли я понимаю, что недостаток первого пути — некорректная генерация кода, который надо ещё проверять и дорабатывать, а второго — необходимость всё время обращаться к программисту при необходимости изменить или уточнить бизнес-процесс?

    Есть ли на рынке продукты, которые позволяют автоматически получать работающий код на основе диаграммы без участия программиста? То есть, программсит работает на начальном этапе и реализует какие-то моудли, но чтоб дальше он уже не был нужен для создания нового процесса или модернизации уже существующего?

  19. Anatoly Belychook 11/25/09 02:24 PM

    Не совсем так. Основной недостаток первого пути в том, что программист вносит ручные правки в сгенерированный код, а аналитик при этом продолжает исправлять диаграмму, и как потом объединить те или и другие правки - непонятно. (Есть и более тонкие материи, связанные с возможностями анализа, изменения процесса “на лету” и другие, но это основное.)

    Цель BPM не в том, чтобы полностью избавиться от программиста. Это невозможно и не нужно. Цель в том, чтобы а) не автоматизировать не до конца понятые или заведомо неоптимальные процессы, б) иметь возможность вносить в процесс определенного вида изменения (не любые!) без участия программиста.

    Системы, которые позволяют если не достичь, то приблизиться к этой цели, конечно есть. Но они очень сильно различаются по используемым технологиям, по сложности, по функциональности, по цене. Если Вас интересуют топовые системы, то я могу порекомендовать Oracle, Lombardi. Доступные по цене - Unify, ELMA. Условно-бесплатные JBPM, Runa WFE.

    Для компании какого масштаба нужна система, для каких задач?

  20. Александра 11/25/09 02:39 PM

    Меня интересует не покупка промышленного решения, а техническая реализация этих решений.

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

    Самый простой способ - посадить программиста, чтоб он сам преодолел эту семантическую разницу, вник в тонкости предметной области и реализовал работающий код в силу своего понимания. Можно заранее определить семантику каких-то элементов, чтобы они автоматически исполнялись, но это лишает гибкости и подходит только очень узкоспециализированным областям с устоявшимися процессами. А хотелось бы преодолевать этот разрыв автоматически.

    Не октаз от услуг программиста. А такая схема, где программист реализует то, в чём он специалист (функции, обращения, модули), а не сложную финансовую или иную логику, о которой он мало знает (только из схемы и разговоров с аналитиками, руководителями или специалистами других областей). А чтобы специалисты, в свою очередь, работали исключительно с теми понятиями, которые нужны им и могли не думать о том, что там есть переменная, которую надо хранить и передавать, например.

  21. Anatoly Belychook 11/25/09 02:44 PM

    Может быть Вам лучше попробовать сделать что-то своими руками при помощи одной из перечисленных BPMS? Уверяю, это даст больше пользы и понимания предмета, чем рассуждения.

  22. Александра 11/25/09 08:45 PM

    С некоторыми из перечисленных вами систем я знакома, про остальные читала (кроме, пожалуй, Lombardi). И, насколько я знаю, ни одна из них не решает проблему, которую я рассматриваю (автоматическая генерация рабочего кода на ходу сразу после создания диаграммы). С этого угла мало кто смотрит, и поэтому вопрос, вероятно, кажется странным и умозрительным. Многие вообще считают, что такой проблемы нет: «Посадим программиста и он нам реализует всё что скажем, главное — схему нарисовать». Этот аспект слишком тонкий и специфический, поэтому он не фигурирует в обычных маркетинговых презентациях. Но, тем не менее, затраты на преодоление семантического разрыва напрямую влияют на эффективность системы управления проектами, которая использует графическое моделирование.

    Спасибо за ответы.

Comments are closed

Copyright © 2008-2023 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments