For those who miss posts on this blog: for certain reasons now I publish more at bpmntraining.ru.

For the convinience of my English-speaking readers I’ll translate the most popular posts here, like this one.

A customer needs to put in order the contract approval process. Desired timeframe is “yeserday”.

But to do so they need to agree the contract with the BPM consultant

The true story…

I want to apologize to the readers of this blog for not updating it for more than six months.

If a professional blog becomes silent, it means that either the author has lost interest in the subject, or right opposite - the author has become too busy. The latter is my case.

Firstly, I’m now a BPM Evangelist at Comindware. I consulted the company for several years and now joined them. This is a very strong, professional and ambitious team and I’m proud to be a part of it. This is a chance for me to implement the ideas that i’ve got after ten years of BPM practice.

While Comindware already has two products Comindware Tracker and Comindware Project we are going to release a breakthrough product early in 2015. It will feature records keeping, support for projects, processes, adaptive cases, end-to-end resource management, social interaction and mobile interfaces. As a technology evangelist, I’m involved in defining the vision of technology and software products and translating this vision to a broad audience through articles, social media and public appearances.

In addition to this activity, I was deeply involved into Russian CBOK project initiated by ABPMP Russian Chapter. It costed me about a thousand of hours but now the translation is over and I’m able to get back to normal life.

I have published several articles during last months so the next blog posts will be the reposts. I look forward to your comments.

That was the question Peter Schoof asked at BPM.com forum. It provoked long answer that I’m copying here to get back next year.

Peter, is your question about technology? Management discipline? Capabilities and overall process maturity of today’s enterprises? All of these? Ambiguous questions provoke misunderstanding.

If accepting the widest scope (i.e. considering all three aspects) then where is the bottleneck, I wonder?

» read the rest

Sorry, this entry is only available in Русский.

Gartner, Pega and IBM are pushing new acronyms:

• IBO = Intelligent Business Operations
• iBPMS = Intelligent Business Process Management Suite

According to the experts, the concepts behind the acronyms aren’t exceptionally new - it’s evolutionary integration of related technologies: BPMS, BAM, BRE, CEP, ACM… Looks like someone decided it’s time to put new labels over the old BPM/BPMS.

I’m not personally convinced that the market will accept this labeling game. Attempts to announce the “post-BPM” solution was made in the past (Intalio) and are made today (Metasonic) without much success. This time the heavyweights are in play however.

I would like to see the breakthroughs in technology and methodology, not acronyms. From this perspective the bpmNEXT initiative looks more interesting. Quoting the memorandum by Bruce Silver and Nathaniel Palmer:

We both do not agree with the fact that BPM is dead… or that BPM is tired. In fact, innovations associated with the clouds, event-driven analytics, case management, mobile applications and social networks fed by innovations in the field of BPM with an intensity that we have not seen for years.

By contrast, 10 years ago the process management discipline has undergone radical changes both in methodology and technology:

• continuous improvement instead of one-time reengineering
• integrated BPM Suites instead of separate modeling tools and workflow engines
• agile development instead of “waterfall”

This time it’s about “in addition”, not “instead” hence the talk about “the death of BPM” is either speculation or provocation.

And this is very good actually - let’s not start it from scratch once again: TQM, reeingineering, BPM… It destroys the market as potential customers feel uncertain. What’s the point of implementing a new acronym if the previous one - pushed by the same consultants - was declared obsolete so easily?

Now when we position the post-BPM as an extension, it makes the late majority customers realize that the “basic BPM” is a task of yesterday, not tomorrow. Plus, tomorrow promises many fascinating and useful things.

Adam Dean wrote in his recent post “BPM Skills“:

The biggest “added value” you can add to the BPM offering is BPM Skills.

I have an objection.

From my experience, the biggest issue of BPM initiatives is poor targeting. People pick up a target for the BPM project - i.e. a specific business process - on a basis of intuition or politics but not a thorough analysis.

No system is able to set the goal for itself. Hence BPM skills are not enough for BPM to be successful.

It depends on how you define what constitute BPM skills indeed so I’ll be more specific: one needs to be professional in analysing company performance, structuring enterprise value chains, identifying critical business issues, connecting business issues to process issues to personal performance issues for a BPM project to be successful. I guess these competencies are beyond BPM for most people.

As I already said here on the blog, this is a kind no-man’s zone between business consulting and process consulting: business consultants know what should be done eventually but have vague understanding of how strategic goals can be achieved with the help of BPM methodology and technology. BPM folks either expect that a customer will pick the target process or assist him with vague recommendations like “pick up a low hanging fruit”.

But look: how many of candidate processes will affect the company’s bottomline figures? The Theory of Constraints (ToC) postulates that there are generally a small amount of (or just one) bottlenecks within a system. Therefore a BPM project results would be visible at the company level only if it was targeted at one of these few (or even a single one) bottleneck processes. Otherwise the BPM project would be successful only locally: it’d increase the productivity of a link but the value chain constrained by some other link will remain the same.

Since we came to this logical conclusion about a year ago, we developed a missing methodology for systematic identifying the right target for a BPM project based on the ideas of Gary Rummler and Eliyahu Goldratt. We use it in pre-BPM projects that give the answer to the question asked by every top manager considering a BPM initiative: “what exactly would I get from your BPM thing in terms of hard dollars”?

The methodoly doesn’t answer the question directly of course - after all, every company has its own performance gaps - but we are able to articulate in advance how and where the answer will be found. The prospective sponsors are just fine with this approach.

The most part of the job at these projects is done by the customer itself - the workgroup usually consists of 15 to 20 people from top management to key specialists. We just set the right questions and the answers are all theirs.

The great co-product of this job is the empowered team. When the complicated and important task of identifying the company’s bottlenecks is completed, they are eager to close the revealed performance gaps with the help of BPM. It’s the best condition for a BPM project one could imagine.

Sometimes they call business processes “company’s DNA”.

Companies vs. living organisms is a valid analogy: both live, struggle for a place under the sun and die. They may be healthy or sick, aggressive or adaptive… People come and go – the organism replace cells, yet its look and the way it interacts with the outer world is determined by business processes – DNA.

Within this analogy BPM is genetic engineering:

• we decode organization’s genes (business process analysis and modeling)
• we identify good and bad genes (process patterns and antipatterns)
• we remove bad genes and copy good genes from one organism to another

The difference is that we affect the look and the behavior of the organization itself whereas for living organisms it’s only about next generations.

Sorry, this entry is only available in Русский.

While talking with a client yesterday I failed to articulate clearly the difference between templates and patterns.

In fact, they represent two methods of problem solving:

• A template is a standard solution for a certain type of tasks. E.g. when I’m going to conclude a partnership agreement I pick up the appropriate template and it becomes a zero version of the document.
• A pattern prinicipally is a standard solution too, but it is used creatively on the basis of a “problem shape” rather than problem’s formal type. Unlike templates, patterns may come with a positive (”how to do”) or negative sign (”how better not to do”).

Vague enough, right? Trying to make it simple, I found an analogy in chess:

• Debuts are templates: learn them and use them, chessbooks plot the game 20 moves ahead from the initial position.
• Typical combinations of the middle game are patterns. E.g. fork is a pattern: if you can see an opportuntiy then use it or threaten to do so. Two rooks on the same vertical is a pattern too while two pawns is an antipattern: try to avoid such a position if possible. But no chessbook contains instructions how to make a fork starting from the initial position.

With regard to business processes, sometimes a business process model is called a process template. Process instances are created from templates about the same way as zero version of the document in the example above.

The second meaning of the term “template” is a typical, standard process model. A vendor or consultant develops a process model on the basis of previous experience and then offers it to prospective customers. Supposedly the customer will be able to use it with small customization, saving efforts in comparison with a development from scratch.

For example, my company Business Console successfully implemented a BPM solution targeting a sales process executed through geographically distributed offices and now we offer it as a template, i.e. a starting point of a BPM project to companies that manufacture and install plastic windows, metal doors, custom-made furniture etc.

Pattern in BPM is a typical process fragment of typical way of communication between processes (some examples).

One may ask: which one is more usefull? My opinion it’s a pattern:

• Templates are specific (one process - one template), patterns are universal. A good pattern can be used in a variety of business processes regardless of the industry.
• A practical benefit of using a template may be less than expected. It usually covers the happy path only and the devil is in details - various workarounds, escalations and exceptions.
• The effect of using the right pattern can be large. For example, there was a case in our practice when the process plotted at 6 A4 sheets glued side-by-side was reduced to the elegant design with just 15 activities by using the right pattern.
• The value of the antipattern is its ability to preserve you from mistakes. The price of a mistake is unlimited in theory and sometimes it’s really big in practice.

Another reason of my skepticism towards templates is the fact that in case of BPM we are targeting continuous improvement, not one-time automation. Templates, by definition, can be applied only once: during initial modeling. The ability to use patterns will remain open forever. It’s quite possible that after discovering a new pattern you will look at the processes you designed from a different perspective and will find a way to improve and/or simplify them.