Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Why BPMN Matters

BPMN became popular. Customers demand BPMN because in their view it’s modern and hence a priori more advanced process notation.

But I also understand process specialists experienced in other notations e.g. IDEF or EPC that refuse to follow the fade blindly and ask to explain why BPMN is better. I understand their skepticism - a new notation must be essentially, radically better to justify the transition, not just look nicer.

So what is BPMN -

Another Notation or The Notation?

It may sound trivial but - it depends on how are you going to use it.

A new notation emerges not to solve old problems. Or, more precisely, a new notation emerges to solve not only old problems. It should be competitive in traditional applications and open new opportunities.

So let’s sort out: why do we model business processes?

Typical Process Notation Applications

1. Architectural drawings

How do we make money in our company? How does process-functions-resources matrix look like? Which business processes are served by which IT systems? If you wish to draw a rectangle, label it with the name of your company in order to expand it into value chain and to depict links between core processes then there is nothing better than IDEF. DFD is viable option, too. But not BPMN, definitely.

2. Process drawings

If you wish to understand and manage how employees participate in particular processes in order to better manage the company or to pass a certification then there is the widest range of process instruments available: from semi-formal workflow diagrams to EPC. BPMN is an option, too. Probably not worse than other options but not better either.

3. Workflow automation

If software development is at first place and a process is just one aspect of the software then UML would be a natural choice. EPC has strong position when it’s not development but ERP implementation and customization - you’ll be able to translate process drawings e.g. into SAP.

4. Direct execution

Translation of process diagrams into software code works fine under assumption that it’s a one-way path: analysts draw process diagrams first then programmers implement the diagrams in a software application and finally we go into production.

The only question is whether such approach is realistic?

It became a common opinion recently that this key assumption isn’t met for a wide range of business processes, especially cross-functional and end-to end business processes.

Business processes change and they change often enough - say from once per week to once per quarter. And here we get a well-known -

Round-Trip Problem

Step 1. Business analysts question subject matter experts and depict the knowledge in processes diagrams.

Step 2. Programmers translate diagrams into a software code.

Step 3. A system takes off and goes into production.

Step 4. A business process changes. The regulator changes rules, competitors raises the bar, clients’ expectations grow - a process must be changed because stagnation is death.

Or even more often, its our view of a business process that changes - we understand how to do the job the best only with operational experience.

Anyway, the time comes to review the process so analyst get its scheme from the archive to modify (optimize, align with reality - whatever). But things become tough at this moment:

  1. Programmers deviated from the initial diagram while developing the system - first a little then more a more during the implementation.
  2. While it’s possible to translate a process diagram into software code automatically during the first run, translation of changes is performed manually and complexity of the translation varies from “high” to “forget about it”.

Step 5. Programmers have taken a business process into their arms not to let it go away anymore. All business process changes should be addressed to IT and they implement your wishes to the best of their understanding. Forget about business process visibility that graphical process notation promised - the process is “buried” in a software code. Business analysts and hence business does not control the process anymore.

This situation is uncomfortable for IT as well as business because IT cannot really handle this weight. At the end of the day we’ve got a set of collisions known as business-IT divide:

  • «it’s all because certain people don’t know what they want»
  • «no it’s all because certain people can’t implement what’s requested»

No matter what notation is used: it may be UML translated into C# or EPC translated into SAP. It even may be BPMN translated into BPEL so BPMN is not a panacea by itself!

We could start a theoretical discussion here about possible solutions but if a problem is here for a decade then it’s basically an experimental fact for me.

What can we do about this problem?

Keith Swenson dissected the problem in 2009 in the article “Model Strategy: Preserving vs. Transforming”.

The point is that the problem outlined above only relates to systems that transform the process model: business deals with process schemes depicted in graphical notation while IT deals with software code.

The alternative are systems preserving the process model. Business analysts deal with graphical notation here too while IT deals with process attributes that specify it’s execution and with software code explicitely tied to the model. The key difference is that both parties work not with two separate but with a single physical model, separated into levels only logically. Analysts are fully responsible for the process scheme while programmers specify the model at the lower level and don’t intervene into other party area of responsibility.

Well it’s somehow idealized picture - it’s not unusual for a programmer to request a business analyst to amend a process scheme to make its execution possible or even to make such change himself. But the point is that a process diagram remains familiar for a business analyst (and therefore for business) so he/she remains involved into a process work.

The concept of a directly executable business process in brief -

What You Model Is What You Run

This concept has gained acceptance not long ago. Couple of years ago there were vivid debates between pure BPMN vendors and proponents of using BPMN for modeling and BPEL for execution (a model transformation variant), including the industry heavyweights of SAP, IBM, Oracle.

Now what we observe today:

  • IBM acquired Lombardi (model-preserving BPMS based on BPMN) and made it a flagship BPM product.
  • Oracle acquired BEA (AquaLogic BPMS is BPMN-based and model-preserving) and made it a flagship BPM product.
  • SAP announced SAP BPM (BPMN-based model-preserving system), pushing NetWeaver aside.

Results

Applicability of different process notations in a table format:

Workflow

IDEF

DFD

UML

EPC

BPMN

BPEL

Total:

Architectural drawings

-

+

+-

-

+-

-

-

2

Process drawings

+

+-

+-

-

+

+

-

4

Workflow Automation

-

-

+-

+

+

+

+

4.5

Direct Execution

-

-

-

-

-

+

+-

1.5

Total:

1

1.5

1.5

1

2.5

3

1.5

12

This table demonstrates that the optimal notation selection depends on the task at hand:

  • if you are going to model the architecture and processes without intentions of execution then IDEF+workflow or IDEF+EPC certainly would be better choice than BPMN
  • range of selections is the best if you are interested in one-way automation
  • if you are interested in direct process execution then there is no real alternative to BPMN

Multi-purpose BPMN

As can be seen from the table, BPMN offers the widest range of applications - 3 from 4. This is an important advantage because you don’t always know how will your process initiative evolve.

E.g. we started with drawing process for documenting purposes and then move to automation or direct execution. Obviously it’s better to stay within one notation when such things happen, just by increasing the level of details. Notation change doubles expenses to instruments and competence and what’s even worse, there become two truths about the same process.

If BPMN were locked up just on executable process it’d be called BPEL and it won’t get wide acceptance.

However it would be oversimplification to say that executable business process is always better than  modeling for the sake of documenting and optimizing. Only a relatively small amount of processes should be brought to this level while the majority should be left as non-executable drawings.

That is, one should select 5-10% of processes that are most important for business and make them executable. These are the processes directly affecting company’s bottom-line.

Bringing every process to this level is simply not doable - for the majority of processes a simplified BPMN palette should be used. Comparing to modeling for the execution, the resulting diagrams are much simpler and easier to understand for business while the modeling efforts decrease dramatically.

So BPMN is two notations in one:

  • use full BPPMN palette if modeling for execution
  • use basic BPPMN palette if there is no need to detail a process to the executable level

This point is often overlooked by those who criticize BPMN for complexity. Sure it’s complex but only when you model an executable process where BPMN effectively doesn’t have an alternative. But if you face a simpler task then BPMN isn’t more complex than a workflow diagram and in contrast to EPC, basic BPMN palette is intuitive and doesn’t require a formal training for understanding.

Conclusions

BPMN has points to criticize, e.g. eclectic design or lack of tools to model high-level (architectural) diagrams. But this notation has crucial advantages, in my opinion:

  1. BPMN is the only common notation today that fosters the concept of directly executable business process.
  2. BPMN is two-in-one kind of notation: full palette for executable diagrams and basic palette for simplified, intuitive ones.
  3. Standard version 2.0 publication caused industry consolidation and pushed BPMN into mainstream. BPMN for process management today is like SQL for data management 20 years ago.

The boom around BPMN can only be understood by getting beyond traditional process application - by realizing what else can be done with business processes apart from drawing. If the concept of executable business process is new to you then get acquainted by a model-preserving BPMS like Bizagi BPM Suite. IBM BPM or Oracle BPM Suite would do the job too but Bizagi is much easier to download and install.

BPMN is competitive in traditional applications but no more than that, so don’t expect radical advantages there. If you are comfortable within this range or if IT frightens you then don’t bother - probably BPMN isn’t for you.

11/07/12 | Articles | ,    

Comments (10)

  1. Олег Гунченко 11/07/12 08:24 PM

    Анатолий, UML у Вас совсем какой-то никчёмный и сферический инструмент получается.

    1. Архитектурные картинки
    Чем Вам не подходит TOGAF или, если попроще, RM-ODP
    Имеются даже картинки уровня бизнеса. Если тогаф более подходит большим конторам, то RM-ODP вполне себе средним тоже может использоваться.

    2. Процессные картинки
    Тоже есть. Палитра хоть и меньше BPMN, но позволяет сделать всё тоже самое.

    3. Автоматизация
    Не понял о чём идёт речь.

    4.Непосредственное исполнение
    Тоже никто не запрещает это делать.
    Execuable UML не расматриваю в силу откровенной слабости и академичности.
    Инструментов из коробки нет, поэтому это скорее замечание общего характера.

  2. Anatoly Belychook 11/07/12 10:39 PM

    Олег

    Согласен, нарисовать табличку так, чтобы с ней все согласились, вряд ли получится. В оправдание скажу, что эту табличку мы нарисовали на семинаре по бизнес-процессам (не по BPMN) в Екатеринбурге в результате обсуждения примерно 20 участниками.

  3. AS 11/08/12 09:47 PM

    Anatoly,

    Workflow notations, which I saw, were “directly executable” thus suitable also for “workflow automation”.

    Thanks,
    AS

  4. Anatoly Belychook 11/08/12 10:23 PM

    Alexander

    Interesting. But 1) converse is not true and 2) it’s “exessively suitable” i.e. an overkill, which is rather common cause for criticism.

  5. Роман Дынник 11/17/12 07:33 PM

    Олег,
    TOGAF - это не нотация. Более того TOGAF сам по себе вообще жестко не определяет какие нотации и инструменты использовать для описания архитектуры. Так что упоминание этой метод отлогими здесь не совсем корректно.
    RM-ODP определяет различные viewpoints, но так же не говорит о какой то конкретной нотации.
    Нотация о которой стоит упомянуть в плане описания высоко уровненной архитектуры предприятия - это archimate от той же OMG. Она в настоящее время и получила распространение в различных инструментах для моделирования архитектуры предприятия.

  6. Anatoly Belychook 11/17/12 08:18 PM

    Роман

    Спасибо за наводку.

  7. Dmitry Batsyuro 11/25/12 01:12 PM

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

    Например, если стоит задача проработать верхнеуровневую архитектуру процессов для акционеров или высшего руководства, то наибольший вес будет у первого критерия, а у остальных могут быть вообще нули. И из этого будет следовать, что для этой задачи IDEF0, DFD и EPC рулят - так и есть. А вот если задача проработать детальные процессы и межпроцессное взаимодействие, подготовить качественные требования к их автоматизации с учетом всех мелочей и нюансов, имеющихся в этих процессах, или вообще реализовать исполняемые бизнес-процессы (пусть не сразу, но заложиться на такую перспективу), то более высокие веса буду у нижних критериев, а верхний критерий - “Архитектурные картинки” - будет менее значимым. И для архитектуры на верхнем уровне, в крайнем случае, берется другая нотация - тот же IDEF0 или DFD. И пусть переход из IDEF0 или DFD в BPMN при понижении уровня абстракции придется выполнить вручную - эта поблема меркнет с учетом того, что BPMN зато позволит на нижнем уровне все очень подробно и при этом наглядно прорисовать и качественно автоматизировать. Если правильно расставить веса, то станет видно, что BPMN еще сильнее отрывается от остальных нотаций при решении таких задач.

    Кстати, по критерию “Процессные картинки” - я считаю, надо либо полбалла отнять у EPC (но что тогда останется у IDEF0 и DFD :-) ), либо полбалла-балл накинуть BPMN. Потому что многие нюансы межпроцессного взаимодействия, которые в BPMN легко показываются, в EPC либо очень условно можно изобразить, либо крайне громоздко и не читаемо. Специально пробовали один и тот же процесс в этих двух нотациях отрисовать, и на практике получили подтверждение этому утверждению.

  8. Dmitry Batsyuro 11/25/12 01:17 PM

    Олег, Роман - помнится, когда я поверхностно знакомился с методологией TOGAF (несколько лет назад), то она делала основной упор на архитектуру информационной системы. Если взять матрицу Захмана, то архитектура ИС начинается с ее 3-го уровня. А модели бизнес-процессов в этой матрице находятся на 2-м уровне. Так что, с моей точки зрения, вообще не корректно говорить о моделировании бизнес-процессов в рамках методологии TOGAF - уже готовые модели бизнес-процессов являются входной информацией для нее. Хотя, может быть, с тех пор ее доработали и расширили на более верхние уровни матрицы Захмана.

  9. Anatoly Belychook 11/25/12 07:59 PM

    Дмитрий

    Спасибо за Ваши соображения, но стоит ли тут подсчитывать миллиметры? Для меня это скорее качественные оценки. Что с весами, что без весов главные выводы останутся те же: 1) всю палитру применений не покрывает ни одна нотация, к сожалению; 2) у BPMN область применения самая широкая.

  10. Роман Дынник 04/04/14 01:46 AM

    Дмитрий,

    В TOGAF всегда было 3 архитектурных слоя: business-information-technology.
    zachman хорошо представляет таксономию объектов с помощью различных типов моделей, но не является процесным подходом. TOGAF - напротив, это процесным подход и в стадии B как раз определены шаги подразумевающие разработку моделей бизнес процессов, организационных моделей и прочих, относящихся к бизнес-архитектуре. Более того, стадия A (vision) предполагает разработку kpi, идентификацию бизнес- драйверов, принципов и органичений.

What do you think?

Captcha

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