I must admit, I was a little bit surprised about the result. For me BPMN is not flexible enough and it has too many modeling elements. While this is not the majority opinion, a grave minority has the same opinion.

Some comments:

I think BPMN is great – but we just had to add on a few bits to define value add and non value add activities so that larger maps had more to narrow your focus on areas that need attention

Alan Crean, CEO @ Process Master

I agree that this is necessary to not overload the modeler with too many modeling elements.

Flexibility is a vague term that can mean many things in different situations. I would define flexibility as the ability to make changes over time as needed to respond to changes in the situation. In order to be flexible, there have to be constructs that afford the kinds of changes you will need. For instance, flexibility implies some form of control. A common pattern might be that parts of the process diagram are controlled by different people. There is no consideration in BPMN for specifying who has control over different parts. Instead, there is a built in assumption that the entire diagram is designed and maintained as a whole. That reduces flexibility.

Different people controlling different parts of the process diagram is definitely a very important part of the flexibility requirements I see. There is no concept in BPMN for this. It may well be, that it is not possible to add this concept later, because of the current semantic of BPMN.

I consider BPMN still more as a (high level) programming language for automated processes which provides rather poor support for flexible human processes.

I agree.

Just one examples of too less flexibility: Consider a process where one task can be executed by different roles (e.g. via delegation). In which Lane should I place the task? Should I show it in the “Default”-Lane? Or a copy in any other related Lane? Or even draw it across multiple Lanes?

While I know that Lanes are just a graphical partition of the process and we could easily address the problem via performers (BPMN 2.0), this is not a graphical solution. Many users (and tools too) use Lanes synonymous to performers.

Interesting case.

I guess it depends on the tool you use. We have created a new tool generation which hides the complexity of the BPMN notation against the user by using intelligent algorithms which support a highly efficient modeling process.
Our BETA was anounced on Nov 10. Innovator for Business analysts will be available shortly. C. Bergner.

It is worth trying. However my doubts are that certain limitations in the metamodel can not be overcome by a tool. However a tool can improve.

We feel the technology driven approach of BPMN when it comes to high level process landscape description. This seems to be out of scope at least in the BPMN 1.x standard.BPMN is good for visualizing low level processes that ar candidates for workflow implementations.

I agree.

It’s really interesting to see your opinion. In my opinion BPMN has a workflow modeling background. That’s why it is good for workflow type of processes. However there are a lot more of other processes.

Suddenly I felt like in a lively discussion about what I thought for some time about the inflexibility of BPM models (what if the approver is on leave?), the ad-hoc nature of real processes (like in a court trial) and the small amount of system support for these.

Yes, Business Process Modeling to a degree rests on the assumption, that there are repetitive procedures that are triggered by a business transaction, and which is described in terms of which steps to execute as a result of it. Like a machine.

Did you ever wonder why there is so little standard software for startups – or business process models? If it where a standard process, it were not a startup. The driver in the seat hopefully is the founder of the startup, not a process.
I agree to the observation, that there are much more processes like this all over the place. And maybe there should be even more again, reverting the feeling to be but a cogwheel in the engine, but a responsible contributor – even for the benefit of the whole.

Still, what we need to work effective is system support for

• our information
• Collaboration and Communication over the information
• a clear status of all of the process and all parts of it
• Decide about next steps as you go
• Decide about required information as you go
• Decide about groups and access policies as you go
• Decide about information structure as you go.
• Overview and Tracking

Only to mention the most important ones.

This is not what you can to with BPM . Therefore we need a new breed of software which is not BPM, even if it is related to it.

I want to mention two things, that were not or not deeply discussed in the meeting as an additional contribution and defence of what I said.

First: Even with all the ad-hoc type of processes it is clear that over time some of them evolve in standard processes, which is a good thing. Because that is the time to earn money for the process owner. So there must be ways to

• pick best practices and develop them into standard processes
• re-design a bunch of local best practices into a global standard process.
• impose constraints of a standard process on the business

All of that as you go – i.e. without interfering the running processes.
Which is easily said – sounds a little like marketing buzz – but certainly challenging in terms of technology. But I wouldn’t say it, if I didn’t think it’s possible.

In Process design and re-design I disagree here with Max J. Poucher’s more philosophical statements about evolution. I do not believe as much in evolution as an unguided process as he seemingly does. I believe that redesigning processes as a whole makes them more effective, and more rewarding to everybody if done right.

Second, I think that we need is a seamless integration (A word that you first learn in marketing) with structured processes – be they classical workflows or classical ERP processes. In my opinion there is much ROI to be found.

Related Blog Posts

Adaptive Case Management by Max J. Pucher

Complex Adaptive Business Process by Max J. Pucher

Ad-Hoc Processes by me

Intelligence in Business Processes by me

It is inevitable in big organizations, that there are central processes that are supported by every part of the organization. But at the same time it is desirable, to support individual processes, that respect local specialties. In this case the local units must be given the possibility to plug into the global processes. This can only be done, if the behavior of the local and the central processes is known – and by this the interaction – the choreography between them – can be defined and described. Therefore it is important to have behavior modeling languages for processes of units and of the choreography. Furthermore sometimes it is necessary to allow a local unit to describe their own processes or aspects of their own processes in their own language – a DSL – and plug them into the central processes.

If this is achieved it is a controlled powerful local flexibility with the integration into centrally controlled processes.

All of these articles and also BPMN 2.0 can help to strife towards this goal.

Therefore designing public processes gives flexibility within Participants to change processes as necessary – often without or with reduced side effects to the interation to the other Participant. This reduces cost in Process adaptations.

Integration of Software Systems is the realization of the underlying Business Processes. Realizing As-Is Processes often leads to suboptimal results. No doubt – As-Is processes Analysis needs to be done. But Process Design is ImhO the decisive part.

It must be absolutely clear, which parts of a process are tightly coupled and which parts are loosely coupled. Tightly coupled means for example: A Customer Order can not be created unless the price determination is done. Loosely coupled means: A Customer Order can be created independent from the creation of the Delivery. The delivery creation is a loosely coupled followon process.

However, of course there are interaction between loosely coupled process parts. These need to be defined – i.e. designed. BPMN 2.0 gives the possibility to model them in a way never possible before.

In BPMN 2.0 tightly coupled process parts are those within a pool. Loosely coupled process parts are those that are modeled cross pools in Collaborations or in Choreographies.

The cut of the process – thightly or loosely coupled – is decisive for success. It is not only a system modeling or implementation question. It is also a business process question. Or why do companies outsource parts of their operations? Because they want to loosely couple, what was tightly coupled earlier. This principle makes sense within companies as well, because of enhanced flexibility.

Yes, of course we can discuss about business rules and automated decisions. But in the end, the most intelligent entity on earth is still the user. Yes, we can discuss about AI and Deep Blue being Chess Champion. But my statement still holds.

Yes, it is all about decisions. But that does not imply, that the decisions need to be automated. Some can. But often the business process should push the necessary decision to the user.

And to allow for intelligent decisions, it is crucial to allow for enough decision alternatives. This may sound simplistic in the beginning. But it is not. Bare with me for a moment.

So what is as simple as an approval? Approve or Reject. The simplest decision in the world. But not so simple. Of course, if only Approve or Reject is modeled / implemented, then what should the user do, if he wants to do something else? What else could a user do other than Approve or Reject? He might want to send it back to revision for example. Another user might want to change the underlying approval object – what influence does this have on the process? A realignment of the process is necessary. What, if an approver wants to merge several approvals into one or if he wants to split one into several. Partly Approve. Partly Reject. Partly Edit. Define new Followup – Approval. Change the Approval Type. Merge unterlying objects. Split them.  And Realing the Process. Or substitute the Business Process by an equivalent different one. If you only begin to think about it, then you can hardly stop. And if you think, what that means for a process model, then I would say this is a real challenge. Certainly far more than giving only two branches: Approve and Reject.

So in my opinion adding intelligence to business process means also adding flexibility to the business process, that allows for more than simple alternatives for the user and to push decisions to the user. And to allow for automated decisions to be overruled by the user in many cases.