Q: Why is it such a hot topic right now to discuss alternatives to BPM?

It is the right time to discuss, if classical BPM has delivered on the promises. BPM is now around for some while and has been applied in many projects. BPM technology has been used in practice. It is a natural process to ask: what have we learned from it? Where did BPM work and where did it not work as expected? What are the reasons? Which basic BPM assumptions are there, which are limitations that should be questioned?

It turns out, that one basic BPM assumption was that work is to some degree repetitive. And some work is. BPM proved successful within processes which are repetitive and the profit of BPM is the economy of scale – i.e. the more often a BPM process is executed, the more profit comes from it. But on the other hand it becomes obvious, that a growing percentage of the work in today’s industry is not repetitive – especially knowledge work is not. Furthermore unpredicted events lead to discontinuation of previously repetitive work and the need to manage the unpredictable. Therefore alternatives to BPM should be discussed right now.

Q: What is knowledge work, and why does it require a new approach?

A knowledge worker is a professional – that is my personal definition – whose flow of work depends on decisions based on knowledge, which he or persons of his professional network create, collect and distribute. Therefore by nature it is not predictable a priori, because succeeding work depends on the outcome of preceding work. It is a chain of processing knowledge, decide based on the acquired knowledge and process knowledge again. The work is explorative, not prescribed. A new approach is needed, because classical BPM assumes, that a flow of work can be designed a priori and executed later.

Q: How important is knowledge work?

The number of knowledge workers is constantly increasing. According to Thomas H. Davenport (Thinking for a Living) it was about a quarter to half of the workforce of the U.S. in 2005. In my opinion it is decisive for the developed countries, to make knowledge work more effective in order to stay competitive.

In my personal opinion it is no question at all, that there is a overwhelming amount of knowledge work which can and must be made more effective. In my opinion the problem so far was and still is that the technology needed to make it more effective was and is not available yet. As soon as the technology is available, it will certainly be needed.

Q: What is a specific example of the kind of knowledge work that might be supported?

A specific example is described in my chapter “Improving Knowledge Work” in the book “Mastering the Unpredictable”. There is Leona who works for a telecommunications company as an engineer and she needs to do phone support. The work she does in the support area is described with examples, as customer complaints need to be solved. Some tests need to be executed and some countermeasures need to be taken. The work is unpredictable, because the tests and the countermeasures depend on the situation. However the work can still be supported with Adaptive Case Management.

Other exampled mentioned by Davenport are:

• Management
• Business and financial operations
• Computer and mathematical
• Architecture and engineering
• Life, physical and social scientists
• Legal
• Healthcare practitioners
• Community and social services
• Education and Training

I will discuss more questions in other posts.

To my surprise Why do Process Modeling Projects fail? made it quite high in the ranks. But if I think about it – yes – I understand the question very well.

I had my own share of failed projects, especially when I was novice in the area. And each failed project taught me something that I did not know before. After a while trying again and again I discovered stunning facts that were the foundation for succeeding success.

In my eyes this is absolutely natural in the area of knowledge work. And modeling is knowledge work. Therefore it is inevitable to try, to fail, to learn and finally to succeed.

If somebody promises: “I have the silverbullet method.” something is wrong. Either the task is too simple and therefore mainly irrelevant, or it is a lie. Business Processes are far from being simple, and if they are, then they are not worth modeling them, because they describe an area where only commodity business is done.

It looks so simple on the first glance. But it isn’t. For example take the other question: How to model one process with different variations at once? It is not so simple to answer this question. In my experience what is necessary to succeed in business process modeling is a deeper understanding about the laws of the business processes domain. Otherwise the result will be too complex to be used in practical terms. For example a car can be engineered, if the engineer understands the underlying laws of physics. Even if the car modeling tools look simple in the first place, they alone are not sufficient, nor are “methods” to model. Tools can help, methods can help. But they are not sufficient. Many training classes teach tools or methods. But to achieve a deeper understanding of the laws of the business processes domain in general, and the laws of the business processes from the special domain that I am modeling, they do not suffice.

The need for methods and tools is also expressed in the questions What are the 5 golden rules of process design? And Which business process management tool and notation suit my needs best? Given what I said I would answer this:

1. We need to find out the laws of business processes domain and the special domain that I am modeling.
2. We need to find 5 rules that respect these domain laws.
3. We need to identify the notation, that best fits to these domain laws and
4. We need to build or select a tool that supports this notation and is convenient to use.

Of course this has been tried many times. BPMN 2.0 and BPMN in general is just another attempt towards this goal. But still one of the most asked questions is: Why do Process Modeling Projects fail? I have my own opinion about the natural laws of business processes. I have modeled many hundreds Business Processes with 1000+ models from the areas of Customer Relationship Management, Supplier Relationship Management, Logistics, Supply Chain Planning, Financial Accounting, Project Management, Human Resources and others. I think BPMN respects some of the laws of business processes, but not all. For example Flexibility and Extensibility is not respected enough. It is not respected enough, that the result of a process is more important than the steps within the process, because the result is needed for another process, but the steps are irrelevant. Therefore there are too many variations of the processes, which are actually not needed, if the results of processes are modeled instead of the steps leading to the result. Another opinion about BPMN type of modeling I have is that most processes are over specified. This means the model is much less flexible than the reality.

In these days the Workflow Coalition will publish a book “Mastering the Unpredictable”. There we – process thought leaders from industry – argue that today’s process technology does not yet reflect the laws of unpredictable business processes and that there exist many of those.

Two recent Gartner key Predictions give insight in this very interesting and emerging part of process technology:

By 2012, 20 per cent of customer-facing processes will be knowledge-adaptable and assembled just in time to meet the demands and preferences of each customer, assisted by BPM technologies.

By 2013, dynamic BPM will be an imperative for companies seeking process efficiencies in increasingly chaotic environments.

So the whole process technology topic is still making very necessary progress. New domain specific languages will emerge, of which BPMN is but one. These new languages will respect the now known laws of the business process domain in a better way than today.

This all is nice and good. But what should I do today? Wait for a better future? Certainly not.

What are practical findings from using BPMN? is a very clear question and it is the most asked question. And in my opinion this is the best question. Because it is possible to use BPMN in a way, that respects the domain laws of business processes, even if they are not yet built into the notation. And this knowledge is exchanged by practical tips solving practical problems. Yes, there is a need to better understand the theory as the question What is new in BPMN 2.0? indicates. But even more there is the need for practical tips.

In my experience this can be achieved by coaching and governance. This is supported by the question What is required for BPMN coaching and governance? which is also quite high in the ranks. The answer is another question: Why you need a center of excellence BPM? The answer is: To provide the necessary coaching and governance. Of course there is much more to know about what is required for BPMN coaching and governance.

In some weeks I will start a coaching program. You are invited to it. You should have theoretical background already and you should have some practical experience already as well. The number of participants is limited to 7 for one year. It includes a Kick off meeting, weekly Web-Meetings as well as monthly meetings in a city somewhere in the middle of all participants. I addition to this coaching program I will offer training classes for the public as need arises. One training class will certainly address BPMN 2.0, another probably about how to organize coaching and governance inside your company- all with a very pragmatic approach. Of course the blog also will continue and I may publish another book or articles once in a while. I am looking forward to meet many of you in person who are reading this blog now for a while.

Elaborating more on what I said before about loosely coupled processes, I want to emphasize today, that the cut of the processes is of major importance – i.e. which parts are loosely coupled and which parts are tightly coupled. Furthermore if process parts are loosely coupled, it is of big importance which process parts are public and which are private. Public process parts constitute a contract, that the other participant can rely on (when to request, when to confirm), while private processes are only needed within the operations of one participant’s organization – for example an approval or a special form of approval that is irrelevant to the other partner. This has these benefits:

• Flexibility: It is possible for one participant to adapt the private process to changes as business requires it without the need to negotiate with the other partner, as long as the change still complies to the public process.
• Stability: The participant can rely on the behavior of the opposite participant, even when the opposite participant makes changes that comply to the public process.
• Visibility: In Process Monitoring internals are not visibible because they should not. It is a decision of discretion which parts of the process should be visible to other partners. However I believe that BPMN 2.0 might be amended for this purpose, because for this it might be necessary that also non-communication activities can be part of a public process.
• Decoupling: The number of private processes that comply to a public process needs not to be multiplied with the number of choreographies, that comply to a public process. Say you have 3 choreographies that you want to combine with 3 private processes. Then without decoupling you have 3*3=9 process models. With decoupling you have 3 + 1 + 3 = 7 process models.

It is important to understand, that the Choreography is an abstract process while the private process is a concrete process – i.e. can be executed by a process engine and has process instances. So the Choreography Model will never be executed by a process engine. It is the summary view of the participants. It never proceeds on it’s own. It proceeds, if one of the participants proceed (as far as the public process is concerned).

If you ever tried to build a central process with process instances that decide about the message flow, you might have tasted how difficult that is. For simple processes this might still be possible. However you always find these difficulties:

• Either the central process does not have enought information to decide – and that are business decisions in the end – or
• The central process needs to know nearly everything.
• As soon as information reaches the central process by means of messages, it is already outdated (because the sender might have evolved in the mean time).
• Also in many decisions it is necessary to involve humans, not just rules.
• If humans are involved, they might not only to decide left-right, but regroup – solve differently (e.g. create return instead of lowering delivery quantity).

This all leads to the conlusion, that I have made for myself: If there is a middle tier, it needs to be a full fledged business application in the end. With business objects, UIs and the like.

Then we have 3 partipants instead of 2 – which is fine. Then we have 2 Choreographies between them, which are still abstract.

This is my BPMN 2.0 Overview Map.

It shows a Choreography model in the middle, Orchestration with public Processes and private Processes, that belong to the public Processes.

Systems integration is the realization of the underlying business processes. This sounds so simple. But in reality there is often a misalignment between the business process design and the systems design. It is the wrong way to just implement business processes, that are as they are today or that are designed without discretion of the principles of loose coupling.

Often system designers need knowledge about how business processes work, but on the other hand business process designers need knowledge about how system integration works. As long as both sides are willing to learn and willing to share the knowledge, it is possible to come up with common principles of modeling, that avoid the most common mistakes, that lead to project cost overrun or failure.  I say it clearly what I mean: using BPMN 2.0 choreography modeling language in itself is no gurantee for success. But: It is a VERY useful tool for the communication between the business and system experts, which is a necessary condition of success.

So in other words, it is necessary, that the process design follows the principles of loose coupling of business processes. That is no design task, that can be solved by system designers alone, if the business process is modeled in a tightly coupled way. In other words: If the business process is designed in the right way – in the loosely coupled way – then the system design is without a hitch. If the business process is designed in the wrong way – there is no way to save the project on the system design level.

So are business experts forced to design business processes different, just to make the job of system designers easier? No. If it is designed that way, it is a better business process. It would work even better even if there was no system, but just paper and phone. It is more tolerant to errors. It gives the individual more freedom to decide. It makes it easier to reach the goal. Yes, it requires a little bit more brain power than just modeling the sunny day case. But in the end it pays off abundantly.

And in my eyes this is good news. It is NOT the system programming that dominates the design and dictates the constraints. It can be the business process needs again, that prescribe the way to go. And that is why BPMN 2.0 is so helpful, because it starts with the business process model.

If you are german speaking, you might like this short video explaning the new possibilities of BPMN 2.0.

Neue Möglichkeiten mit BPMN 2.0 from AdaPro GmbH on Vimeo.

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

That was when I made my statement, knowing about my yearlong successful experiences in behavior modeling. I said that probably the domain chosen was too broad. In my opinion we should concentrate on a specific domain – business processes – and model the behavior of it. That is because to model, it is necessary to know and describe the laws of nature of the domain – in this example business processes – in advance. Then as a result the modeling method will be very effective and successful. I said that for example in BPMN 2.0 major steps forward have been made recently.

We believed that following this approach it will be possible to achieve much better ROI of MDA than in the past. Practically this will mean that it will be possible to provide an application wireframe within days and an application within weeks instead of month or years. Through this productivity boost Custom Software will be cheap to build – therefore companies do not have the choice between standard software or high cost, but they can have what they specifically need at a low price. This is not out of reach.

Reference

Fieber, F., Regnat, N., & Rumpe, B. Assessing usability of model driven development in industrial projects. In T. Bailey, R. Vogel, & J. Mansell (Hrsg.), 4th European Workshop on “From code centric to model centric software engineering: Practices, Implications and ROI” (S. 1-9). University of Twente, Enschede: Centre for Telematics and Information Technology.

Nevertheless this is a conviction, that has grown over time and a goal to which I can even see the path to the solution already now.

My prediction is, that in the future there will not be Applications on the one side and Business Process Management on the other side. But Business Process Management enabled Applications.

My prediction is, that in the future, there will not be the decision “Should I implement it as an Application or model it in a Business Process Management Suite?” any more. Because with BPM enabled Applications this is the same thing.

Business Objects will be Process Objects and Processes will be Business Objects.

And it will solve many of the discontinuities we have today trying to unify the two worlds.

This is my prediction.

Problems, that occur in the area of message exchange often have their reason in the designed Business Processes or – lack of design of them.

For example, there might be a Purchase Order Request message and a Purchase Order Confirmation Message. Then after a while the buyer sends a Purchase Order cancellation. But at the same time the seller has sent the message, that the Purchase Order now has been delivered. Therefore there might be a problem.

However in my opinion the business process is not designed flexible enough. For example the Business Process should also be designed for cancellation rejection. For example if the Purchase Order has already been delivered. So if the Business Process is designed flexibly enough, then the problems, that can occur in message exchange also are able of being resolved.

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.

1. Is BPM a business Discipline or software engineering?
2. Whose responsibility is it to implement (automate) a business process?
3. Should we aim to move from design to deployment with no programming?
4. Whose responsibility is it to maintain a business process?

I have some opinions on these questions.

Is BPM a business Discipline or software engineering?

In my opinion it is foremost a business discipline. It  is about managing business processes, as the term says. It is identifying processes, understand them (model them), define a roadmap for process changes, design new processes, implement and monitor then. This all can – theoretically – be done without IT. Actually most of our day to day processes (drive to work, go to the supermarket on saturdays) are without an electronic workflow (well – some might have . Also the people of old had very much the same principles when they organized their kingdoms and businesses – without IT. They weren’t sending XML messages back and forth – but herolds and messengers on a horse and the like. This of course were also business processes which were also managed and clearly defined. They did not call it BPM back then, but it was in it’s essence.

But is it a question of scale and speed. In practical today’s business life it is inevitable to use IT to reach the needed performance of the business process execution and the needed information pool for the monitoring of it. Therefore the question of how to transfer modeled business processes from the business discipline of BPM to IT is crucial.

Whose responsibility is it to implement (automate) a business process?

In my opinion it is the responsibility of the process owner. The process owner in my opionion is foremost a business person. He is responsible to design and implement the business process. Design – I don’t mean necessarily the modeling with BPMN for example. This of course can be delegated. But the process owner is in the end responsible for the performance of the process and the profit it yields.

If the process owner decides, that a particular part of the process or the whole process should be supported by automation, then of course this part can be delegated.

Should we aim to move from design to deployment with no programming?

This is in my opinion unrealistic. Also it is a question of definition. What is programming and what is not programming? Typically people associate programming with imperative programming (like in C#) or with character based input. Modeling is on the other side which is more declarative and more graphical. But what about rules for example? They are character based and declarative. Also they can usually call subroutines, which are imperative. In some sense a BPMN model is also imperative. So what does this question mean? Probably it is, that it must be made easier for business experts to express which process they have and which they want. Of course it is a big benefit, if these models can be used in runtime or transformed in some canonical way into runtime. The success depend on if it is possible to express the process in the languange of the domain of the business process owner. This is why I think that Domain Specific Languages must be desiged with the greatest care and intelligence. And I think that this area is much less expoited than it could be. In my opinion much more is possible that we have achieved on the great scale already.

Whose responsibility is it to maintain a business process?

In my opinion it is the Business Process owners responsibility, who is a business person. And he might delegate it to someone of IT. However the model is the common communication channel between the two. So the model must be accurate, understandable, detailed, summary, and optimally simulateable. Especially the part of  interactive simulation has been much underestimated in my opinion, because it is able to show the behavior of a system implementation of a business process before it is implemented.