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.

I came to the conclusion that we should more agressively offer the express analysis of business processes as a phase preceding BPM projects.

The big issue are potential customers shying away like the devil from holy water as soon as they hear about business processes analysis. I understand why: too many analysts have already been there so the company which paid once for a many man-months project aiming at analysis and/or documenting the business processes hierarchy is unlikely to go on it again.

But catching a business process that happened to be at hand means falling into another extreme. The company will save time and resources by not performing the analysis of upper-level business processes but it will suffer from a risk that much greater resources spent to a BPM project will not be aimed at the spot able to deliver the greatest outcome.

Let’s consider the business processes constituing the value chain:

1. Idea to product
2. Product to inquiry
3. Inquiry to order
4. Order to cash
5. After sale

Just as a chain is only as strong as the weakest link the performance of a company as a whole may be determined by the performance of the bottleneck - the least efficient process (the “constraint” in terms of Goldratt’s Theory of Constraints). An increase of the constraint’s productivity say by 10% would increase company’s throughput by about the same 10%. The increase of productivity of any other process of the chain gives nothing. Hence the extreme importance of choosing the right target for a BPM initiative.

Typically the market is the constraint in a modern economy. But how exactly it’s constraining - by the rate of the inquiries (item 2 above)? Or by our ability to convert an inquiry into the order (item 3)? Or maybe we should pay more attention to after-sale processes (item 5)? It may happen that we perform excellent at the sales process (item 4) but lose the client and another 10 potential ones due to bad claims processing.

I guess most managers know intuitively where their company’s bottleneck is at the upper level. But upper-level processes are too huge to aim a BPM project at them directly. The bottleneck process should be refined to subprocesses and the bottleneck should be found at that level. Will the intuition work there too?

The major concern at the preliminary stage is keeping the timeframe and costs low. We offer two mini projects that precede the main BPM project:

1. The value chain analysis. The value chain template above is adapted to the company’s business(es) and vocabulary. The top-level processes dictionary and diagram are created. E.g. generic “product to inquiry” process is mapped to specific company’s processes of new product promotion, marketing campaigns etc. Major supporting processes are identified too.
2. Process gap analysis and setting priorities. By questioning managers and specialists we figure out how well each of the processes identified at step 1 is executed if compared to the theoretical maximum achievable with the resources available. Then performances of the processes are compared to each other, revealing the bottleneck. A series of workgroup meetings and brainstorming sessions are aimed at discovering quick fixes as well as directions for long-term continuous improvement.

Each project lasts two weeks. The most part of the job is done by the customer’s managers and employees themselves, our role is as follows:

• Provide the essential background in BPM, value chain, theory of constraints, agile methodologies
• Facilitate and moderate meetings and brainstorming sessions
• Wrap the results into documents

In addition to the main goal of identifying the most promising target for BPM these activities result with a team able to develop the generated ideas and to convert them into executable business processes. Which remains the goal after all, not the analysis for it’s own sake.

It was Gartner’s analyst Bill Rosser who pushed me to promote this approach more agressively. His abstract “Gartner Identifies Seven Major Guidelines to BPM Project Success” introducing the upcoming BPM conference says:

“A small number of limited-scope projects is best to provide concentrated focus on achieving results and to spread the word regarding a high-value payoff. In order to surface smaller candidates, it is important to first create a higher-level contextual business process model to find the best opportunities.”

So true.

(This post adds to proposed concept of management competence stack.)

Holy Grail of BPM is so-called bridging (or closing) the gap between business and IT. The gap means a situation where business submits requirements  which are fuzzy from IT point of view, IT implements them as good as it can, but eventually, after some months, business gets not what was expected.

BPM copes with this problem by:

1. directly executable business processes diagrams ( “What You See Is What You Run”)
2. rapid prototyping and short development cycles

This way BPM closes the gap at technology and methodology levels. But what should we do with the gap in consulting practices? To date, business consultants and IT consultants are isolated and have little understanding of each other.

To be fair, IT consultants try to repeat some of business consulting casts, which sounds like: “The SOA solutions delivered by XYZ company increase business agility and adds to business competitive advantage!” But it impresses only IT guys at the customer’s side. As for the business people, such motto causes confusion at best.

It’s reasonable to expect that BPM consultants (BP Experts as SAP calls them) will resolve this issue. Three consulting levels (IT, BPM, business) overlapping each other fully cover the corporate competencies matrix:

But to do so the consultants should understand each other’s domain and know what to expect from each other. Unfortunately, in my experience it isn’t so today. To start with, there is a gap between business consulting and BPM consulting:

• Business consultanting teaches how to set the right objectives and build a sound strategy.
• BPM consultants know how to discover a business process, how to make it executable and connect it with existing enterprise systems, how to launch the continuous improvement cycle.

In short, the former know well “what for” but little about “how” and vice versa for the latter. Although most business consultants are aware of what business processes are and recognize their role in business transformation, they have little knowledge about current BPM practice. It’s hard for a customer to tie one with another hence he would like to see more mutual understanding between business consulting and BPM consulting.

Perhaps BPM consultants should resolve the issue by mastering in business consulting, too? No, this idea should be rejected:

• It’s definitely helpful for a BPM consultant to get some knowledge of the related domain. For example, we successfully use the value chain concept and principles of the Theory of Constraints in our BPM projects. But using something differs from knowing it at professional consultant’s level. A professional consultant should not only know some concept from top to bottom but also have a broad background to be able to advice the methodology most suitable for a particular customer. It’s unrealistic to reach this level for a BPM consultant.
• Let’s not forget that BPM consultant should be educated in related IT areas: BPMS, business rules, SOA, web technologies, enterprise architecture, database and business applications development.
• Even if there was such a super-consultant knowledgeable in BPM, IT and business concepts then how would a potential customer treat him? According to my observations, super-specialists are treated with suspicion - customers figure out intuitively that if his knowledge is so broad then it must not be deep. So his talent and work will not be appreciated.

There is also a gap between BPM consulting and IT consulting. Sad but true: IT professionals and even IT managers often catch the BPM ideas slower than top managers and business people in general.

It makes no sense to blame the gap between business and IT as long as we did not overcome the consulting gap!

The only way to form a straight-through competence from business strategy to IT via business processes is consultants’ cooperation, formal and informal networks, associations and consulting community. Having this, we would be able to offer e.g. the comprehensive implementation of Lean including training, organizational change, analysis and implementation of key business processes and their connection with existing ERP system.

There is certain progress on this way: for example, the interest to BPM conferences continues to grow. Business and IT consultants coming there get an idea of what can be obtained from the BPM and from BPM consultants.

• The weak point of business consulting is the practical implementation of concepts. And this is exactly what we - the BPM specialists - have experience in and are ready to help with.
• IT, located on the lower floors of the competnce stack, face the reverse problem of infrastructure projects justification. Business doesn’t need ERP and SOA on their own, it needs business processes running predictably and efficiently. BPM links one to another so there is great potential for cooperation too.

(This post adds to proposed concept of management competence stack.)

Every business and management methodology emphasizes the necessity to engage the top management into the project and to gain company’s own competence.

But is it really achievable? Probably only the most powerfull companies can afford inhouse competencies across the management competence stack and associated information technologies:

Others shoud be pragmatic and combine inhouse and borrowed competencies. They should do certain things by themselves, engage external consultants for others and outsource some competencies. (The “inhouse competence” doesn’t imply that we develop a competence fully by ourselves - an external consultant or a trainer can provide a valuable jump-start. The question is whether we’ll rely on him forever or eventually will be able to go without him most if not all the time.)

Now which competencies should be better developed inhouse and which ones may be borrowed or leased? I’d like to propose the “rule of chessboard competencies”: if placed into the enterprise competence matrix above, borrowed competencies cells should neighbor inhouse competencies but not each other.

For example like this:

or like this:

but better not like this:

In particular, if ERP is implemented/maintained by external consultants then BPM competence should be better developed inhouse and vice versa.

The point of this rule is to keep borders between competencies under control. If an external consultant bringing competence A interacts with company’s employee possessing competence B which relates to A then everything is fine. If both competencies are borrowed then it may happen that A and B suppliers will pull the blanket over themselves. Both sides will appeal to you to judge but the lack of compentence will not allow you to decide wisely.

(This post adds to proposed concept of management competence stack.)

How to choose from methodologies occupying the same cell of the management consultancy stack?

Let’s consider the customer centricity as an example:

• it can be found in TQM (quality means meeting clients’ expectations)
• it can be found in reengineering (radical improvement of a business process which is a sequence of activities providing a valuable output to the client)
• it can be found in Rummler-Brache methodology, Toyota Production System and Lean (a value chain)
• and yet now there is a new Outside-In concept once again claiming the primacy of customer centricity

Certainly there are differences between these methodologies but here is the paradox: if we look at two capable consultants following different methodologies then the difference between what they are doing probably will be smaller than the difference between the best and average admirers of same methodology!

An illustration to this is the corruption of reengineering ideas. When reengineerng became mainstream, Michael Hammer himself was horrified and wrote in his articles repeatedly that he is not a supporter of what is being done under the reengineering flag.

This is how it happens:

1. visionary people offer a new concept
2. they and their followers apply it with success
3. this success attracts masses of consultants of, shall we say, different qualifications
4. the original concept first erode and then become corrupt
5. at some point a visionary person makes himself a name by criticyzing bad current practices and offering a new solution - see #1

So at the end of the day, who brings the methodology is more important than how it is called.

As an advice - pick up a reasonable methodology, apply it with creativity and develop it. It’s better than following management fads.

(This post adds to proposed concept of management competence stack.)

When considering a new methodology or concept for your company it’s a good idea to figure out which level of competence stack it belongs to and what low-level competencies it requires. But besides that it’s also useful to determine which control channel it supports: direct (action) or reverse (feedback)?

Action and feedback are notions from the control theory. Controller affects the process through the action channel and receives a response through the feedback channel. Controler needs both for normal operation:

For example, EPM (Enterprise Performance Management), BI (Business Intelligence) and BSC (Balanced Score Card) are all useful but they provide only the feedback channel. By contrast, BPM provides both action and feedback - the latter via BAM (Business Activity Monitoring).

When we were kids we liked to look into a car window to find out the maximum speed number at the speedometer - this is how we determined the coolness of the car. Now I realize that the dashboard isn’t the main thing neither the engine - powerfull brakes, stiff chassis, sensitive and informative steering are.

BI and BSC are just dashboard instruments - you must have BPM to make the company make a maneuver. On the other hand, BPM belongs to the second and BSC to the third layer of the stack. Therefore BPM/BAM combination with BSC should be a good idea.

(This post adds to proposed concept of management competence stack.)

I have noticed that business processes and process management is referred by a number of methodologies including TQM, Lean, Six Sigma. Books on Six Sigma and Lean contain chapters that retell basic principles of project management and/or BPM. ERP and CRM vendors like to speculate on business processes too.

But it was proven experimentally many times that business processes punish for treating them as a secondary issue. Business Process Management should be developed as a standalone discipline, not as a co-product of some business concept implementation - the latter is a sure way to failure. Management methodologies and business applications should treat business processes as a related discipline, not as part of their own proposal. Another wish to business applications vendors is making their software more SOA- and BPMS-friendly.

The reverse side of the coin: BPM doesn’t need a methodology of its own!

While many colleagues won’t agree on this, I believe that BPM should not cover the top level of the management competence stack. It should be limited by the tactics: process discovery, process patterns, specific issues of managing unpredictable processes etc. Strategic issues like setting a goal to the process initiative or developing a reference model for specific industry should be left outside BPM scope, belonging to business methodology level.

After all someone prefer Lean philosophy, others may prefer the Theory of Constraints and there are people stating that both are outdated and promote the new concept named “Outside-In”. It’s OK - BPM fits well into any of them, BPM is a kind of a gear connecting them to rotating wheels of the enterprise.

I understand those who believe that methodology should be an integral part of BPM: just like me they don’t accept pure technical BPM initiatives not tied to the company’s bottomline. Business methodology is a must but let it be a competence separated from BPM. Let business methodologies to develop on their own and to replace each other from time to time. And let business process management discipline to develop on its own pace and to remain neutral towards methodologies.