This is yet another attempt to answer the damned question about BPM: why, albeit being successful in so many projects, it never matched the analysts’ growth predictions and still haven’t become mainstream?

There must be something wrong deep in the core. It can’t be just prospects’ ignorance, non-perfect software products or greedy consultants. Nobody would say that BPM methodology is inadequate or unusable (well, except ACM proponents but their voices aren’t loud nowadays).

I blogged on the matter already… well, it was 8 years away: 10 Reasons Why BPM Market Doesn’t Meet The Expectations. It wasn’t a final explanation obviously - 10 answers means one doesn’t have the killing answer.

What turned me back to the matter is a thought that I’ve read recently. It was about the real value delivered by a good business consultant. It’s not a specific business receipt or advice; ultimately, it’s about making complex business issues simple.

Now what do we BPM professionals offer in this respect, do we simplify business issues? I’m afraid not.

BPM software isn’t an issue here (IT people love complex toys) but we proudly bring a full-blown discipline, we suggest extensive training programs and introduce new roles to the organization. We create process diagrams. They turned out to be rather complex but we rightfully assure that they are as complex as business is - no more, no less.

This is all true, but… does it make a customer happy? Well, it does - those who are paranoid to do more with less, be more efficient today than yesterday etc. Are they majority of business leaders? I don’t know the big picture but for the selection that I observe the answer is negative.

And what is decision maker’s best alternative? Sweeping garbage under the carpet: keep it as-is, more or less. Imitate a BPM initative by purchasing BPMS software is OK but pulling out business processes from employee’s brains and making them explicit is way too hard, creates too much tension on the way and too much complexity at the end.

Indeed, implicit processes have numerous hidden weak points and hence are less effective, less efficient and way less agile… but who cares, as soon as the majority of organizations around operate this way. See no evil, hear no evil. Not that efficient but simple and manageable from C-level perspective.

Current Digital Transformation trend should break this modus operandi because digital business models implies digital business processes. So hiding processes complexity by delegating them to performers shouldn’t be an option any more.

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

The process maturity model is probably the most underappreciated concept of the Business Process Management discipline.

Virtually every company becomes caught by the business process idea, sooner or later. The BPM promises – sales up! costs down! unprecedented agility! – make people eager to implement the “BPM thing” as soon as possible, if not yesterday.

But here is the trap: people tend to view BPM as an ocean of opportunities where almost any course may be charted. While in reality it’s rather a railroad line named “BPM maturity scale”. Knowing the map of this line is absolutely critical because the process maturity is a part of company’s culture so it can’t be picked up arbitrary or changed easily – only step by step. One should honestly evaluate at what station the organization currently stays and then buy a ticket to the next one. Taking what seems to be a short way may derail the company’s BPM train. » read the rest

Shelly Sweet (i4process) published a great article about Change Management in Business Process Improvement (BPI) projects: part 1, part 2. » read the rest

Scott Francis wrote a great post that very much resonates to our experience.

BPM projects are special because business processes are volatile by their nature. They are changing because (1) the business environment is ever changing and (2) our own understanding of what is the best way to do our job and to serve our customers is changing.

It happens all the time: as soon as the customer’s process is discovered and mapped, people at the customer side say: “do we really work this way?!” Meaning that it’s so obviously inefficient and ineffective. Yet it only becomes obvious after the analysis is done by a competent process team, not in advance.

This is why an attempt to do the process work traditional way - on the basis of rigid specifications and contract terms - is doomed. Here is how Scott describes it:

1. Incredibly detailed specifications for the software, regardless of the native capabilities of the underlying software platforms.
2. Named resources (staff) on the project, in the contract.
3. The contract includes most or all of the specifications, binding the vendor to an exact implementation definition, and removing all doubt about what is desired.
4. Having secured very rigorous contracts, with performance penalties and exacting specifications, the contract will also specify an extremely aggressive average rate for the personnel on the project.

» read the rest

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…

Process vs. Project Management distinction is in fact very artificial - at a closer look one doesn’t exist without the other.

Both for projects and processes two levels of management can be specified:

1. managing business/company (or its part)
2. managing the management system - let’s call it meta-management

For example, managing the new shop construction is about creating timely and accurate schedule, back it up with resources, make everyone know what he/she should do, where and when. Reporting and control, addressing deviations and adjusting schedule - this is the project management routine. It’s the first level of the project management. » read the rest

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

In the previous article we divided the collaborative work continuum into projects, processes, cases, document-oriented workflows and issues.

We also noted that it was made for analysis purposes only; in reality, they are interrelated. As an illustration, the PMBOK (Process Management Body of Knowledge) talks about processes more than about projects; similarly, the big part of BPM CBOK (Business Process Management Common Body of Knowledge) is devoted to processes improvement and process transformation projects.

This interrelation shows itself in the following: » read the rest

Interestingly, when you meet a certified project manager, he/she almost immediately starts talking about how important is to manage projects and how it should be done. Similarly, a process management expert looks at the world through processes.

In reality, however, most organizations have to deal with processes, projects and cases which are somewhere between the two. Therefore they need a balanced, unbiased view of projects, processes and cases that in essence are just different kinds of collaborative work. Projects, projects and cases have more in common than it may seem at the first glance: whatever approach is taken, there always is an initial state, resources and goals to be reached.

Yet it’s hard to be an expert in different knowledge areas. One can learn the theory but it takes years to become an experienced practitioner. That’s why it’s relatively easy for an organization to find a project or process experts but there is risk that they will overestimate the importance of one approach at the expense of the other. » read the rest