Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Posts Tagged ‘management’

BPM, Metrics, KPI

I believe the role of KPI in BPM projects is exaggerated.

A common point of view: if you didn’t measure the KPI before the project started then you will have nothing to compare the result with and therefore it will be difficult to prove the project’s effect. In a recent Process Maker Blog post “Top 3 BPM Software Pitfalls to Avoid” forgetting to measure KPI is pointed out as the most common mistake of BPM projects. However in the next post on the matter “Are KPIs Necessary for BPM Success?” Ami wrote: “I imagine that a BPM project can be wildly successful without KPIs”. Which means a negative answer to the question in terms of formal logic: KPI is not a necessity.

But where exactly KPI is not a necessity?

1. When the target is business transformation rather than fine tuning of the process

Typical driver for BPM is an urgent need for major changes in the business. Dissatisfaction of customers and partners, the growing pressure of competition, increased risk of claims by regulators are forcing companies to move from functional to process management.

If the company has no issues, or they are ignored or denied or unrecognized then there is no room for improvements. I guess the efficiency of BPM will be difficult to justify in such situation either with or without KPI.

Business transformation may begin with tactical initiatives but eventually strategic changes must occur in how the company interacts with the outside world, in the way departments interact with each other and in the way the company evaluates its performance.

At the end of the day the company will reconsider the metrics it uses. For example the percentage of orders shipped on time will be measured not on the basis of terms promised by the company but rather to the terms expected by the client. It doesn’t make sence to use old metrics but the new ones will only appear at the end as the result of BPM project.

2. When it’s about successfull project launch rather than further project development

When questioned by customers about KPI and BAM we usually answer: “we’ll need to work hard before it comes to analytics.”

Opportunities for process improvements are pretty obvious during initial process discovery, implementation of process execution within BPMS and first iterations of process improvement. Eliminate duplication of functions, assign less significant instances of the process to less-skilled personnel, implement parallel execution of activities instead of sequential - these are common improvement hints.

It usuall takes about a year to eliminate obvious non-optimalities. Further progress requires numerical data about the process. This means not only the KPI as integral indicators but also the details: the duration of activities and statistical distribution of process data affecting its trajectory. By using these data and simulation tools one can suggest non-trivial improvments supported by quantitative data: how much will be saved from the process cost (or alternatively how much will be spent extra) and how it will affect the KPI.

However if wider context is considered the question arises: what is the best focus for the process team - further polishing of the process or switching to another process not touched yet?

3. When the company has manageability issues

The thesis of the importance of KPI is a variation on the theme “You can only manage what you can measure.” Sorry, I don’t buy it. When I walk with the dog I manage it without the help of instruments. When I’m driving in dense urban stream I’m too busy to pay attention to the dashboard. You can drive without a tachometer but not without brakes or steering.

Brakes and steering are part of direct (action) control channel, speedometer and fuel indicator are part of reverse (feedback) channel. Action is more important than the feedback.  It comes to the dashboard ergonomics only if you are satisfied with the brakes. If you are not then no dashboard design will save. And how do you rate the quality of the brakes - by measuring the stopping distance? Probably no - you just feel it.

I’m amazed by by business leaders stating that bottomline figures are the only importance for them. Sure they are important but what shall we do about them - pray? Even the most strong-willed leader can not order the profits to grow. You can order people, but when the organization reaches certain size and complexity this approach stops working so you have to deal with the system and with processes.

We did not command the speedometer needle to move to the mark “90″ - we press on the gas or brake, i.e. we use the direct control channel. Similarly, to achieve better bottomline results it is necessary to put hands on the business processes and manage employees and other resources better by means of improved processes.

4. When the process discovery is the primary objective

A friend CEO once said to me: “You see, business is running pretty well but I have fewer understanding of how it works. And it starts bothering me.”

His concern is business vulnerability: whenever the business environment changes or a key manager leave they’ll be in trouble. He wants science instead of magic. Or better to say, science in addition to magic because leadership is a kind of magic. BPM is a scientific organization of labor of the XXI century.

Business process discovery is a precise science and also a fascinating task. From the “happy path” to various “rainy day scenarios”, from primitive block diagrams to the interaction between asynchronously executed business processes and to the understanding of the interactions between different units within the company. It’s neither “to be” nor “as-is”, it’s “as really is”.

Valid process diagram can only be obtained via execution. ”What you model is what you run” is the principle of BPM systems. Simple ”drawing” of business processes is a fruitless exercise. Works for ISO certification but not for management decisions.

What is worse than the lack of maps for the commander? Only erroneous maps.

5. When the top management is directly involved into the project

I was taught that majority of leaders belong to the psychological type of intitive/introvert. They trust more to the intuition than analitics. This doesn’t mean they are weak in mathematics - usually just the opposite: they are good enough to realize the true value of analytics.

What can KPI give to such leader? First, KPI provides information only about the past and the present but he is interested in the future. Secondly, the relationship between KPI and bottomline are not obvious. For example, how the percentage of orders completed on time mentioned above will affect the profit or the market share?

By contrast, here the case from our practice. Company’s CEO has said at the presentation of pilot BPM project results: “During the project we managed to make profitable three orders which should have become unprofitable as several ones before.” (The optimized process guaranteed speedy calculations of costs and precise specifications which was the key to successfull negotiations with customers in their business.) Do you believe KPI would impress him? I doubt it.

The involvement of the top management is typical for a medium-sized companies. The situation is usually different in large companies: the project management and responsibility is delegated to a middle manager while senior management is only interested in outcomes. Here KPI are in demand: a middle manager isn’t in position to operate with qualitative assessments, he must provide numbers to the top. Besides, his psychological type is probably analyst.

If the top management will be able to evaluate not only achieved KPI but also the intangible benefits of BPM then everything is fine. But if he trust only the numbers then the project is in trouble.

Any strategic initiative (and BPM is a strategy) should be counted several moves ahead. It’s like in chess: some moves are material gains but more often the move is aimed at improving the position which allows a player to perform fruitfull combinations. In terms of chess the BPM project grants both material gains (fast wins) and position improvments (the possibility to implement arbitrary business innovation on the basis of acquired competence and installed tools). Evaluating BPM on the basis of short-term gains only - and this is where pushing KPI is leading - is fundamentally wrong.


KPI is a good thing but let’s not overestimate it. If you missed KPI completely - it’s a mistake. But it is a reasonable approach to sacrifice it because of the considerations above.

One may argue: “If KPI is generally a good thing, why throwing it away - it won’t hurt.” It will, actually. You can do something useless only if you are not doing something necessary. Time is a valuable resource in a BPM project; undue delays lead to loss of stakeholders’ enthusiasm. The project slows down, resulting in even less enthusiasm, etc.

Top managemer’s time is especially valuable resource. If he suspects pure formalism in what you are doing then he may lose faith in the success of BPM initiative and switch to another project, also promising. He usually has a number of options to choose from.

Business-IT Consulting Gap

(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.
02/04/10 | Notes | ,     Comments: 3

Inhouse vs. Borrowed Competence

(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.

Choosing Between Competencies of Same Level

(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.

02/03/10 | Notes | ,     Comments: 1

Action vs. Feedback

(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.

Separate Business Methodology from Process Discipline

(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.

02/01/10 | Notes | ,     Comments: 1

Management Competency Stack

Let me give an advice for companies who have both a desire and resources to improve.

Many of the leaders that I meet are overwhelmed by a huge number of available concepts, strategies and recipes to improve their business. Look at the Wikipedia page outlining modern business strategies to get the idea of choise problem they face. Which one is the best, which will return the most on invested dollar - Toyota Production System? Business Process Management? ERP? CRM? Balanced Scorecard? or may be one of dozens of other alternatives?

Yet the number of options is only part of the problem, another one is absence of a framework to fit these concepts and methodologies into. Management gurus typically don’t care to define the scope precisely neither to consider interfaces with related disciplines. Everyone sells his recipe as a comprehensive and only worthy of attention.

Where does it lead?

  • Buridan’s ass syndrome: a leader inclined to perfectionism doesn’t take anything because he is unable to make an optimal choice.
  • Silver bullet syndrome: a leader inclined to adventures accepts the first theory which hooked him and which he can afford. BTW, this is generally not a bad strategy: apply more leadership and common sense, less bigotry - and almost every theory will lead to success.

For comparison let’s look at the related area of business software and IT consulting.

They provide enough ground for cricism; their promises should be divided by 4 (or even 16) but there is a significant difference: information technologies are structured. There is so-called stack of information technologies which looks like this:

Each stack level offers a number of alternatives and competing suppliers to choose from. But we do not choose between say a cable network and CRM system. It would be foolish to opt for CRM because this is what provides a real value for a salesman while the average user does not care about the network cables and switches.

But this is what happens when business and management concepts are considered! Hence I believe it’d be usefull to introduce a notion of Management Competencies Stack. (I use term “competency” rather than “technology” because business and management are more humanitarian than IT.) Here it is:

Some examples:

  • customer relationship management, manufacturing planning, budgeting belong to functional management level (they relates to sales, production and finance respectively)
  • BPM belongs to the process management level (not to be confused with BPMS which belongs to the middleware level of IT stack)
  • Toyota System, Lean, Six Sigma and Theory of Constraints belong to the concepts level

The relationship between the levels here is the same as in IT: the bottom level without the top lacks the target while the top level without bottom lacks supporting technologies.

  • Looking top-down, the bottom level is an enabler for the top. This is a gear connecting abstract ideas to specific activities performed by specific people.
  • Looking bottom-up, the upper level is what gives a purpose to the activities of the lower level and multiply their impact.

Few examples to illustrate these relationships:

  • An ordinary company can’t exist without competencies in sales, production or services (functional level).
  • A company which has grown to certain size and level of maturity should put efforts to coordinate activities of functional units within an end-to-end business processes or projects (the process and project management level). Otherwise functional units increasingly work for themselves rather than on the client.
  • The value chain theory (concepts level) specifies the purpose for business process initiatives (the process and project management level). Such initiative shouldn’t be only about doing things right, but also about doing the right things.
  • Theory of constraints (concepts level) defines a procedure (”five steps”) which helps to pick the most promising business process for your process initiative i.e. the one which will maximise return. Business process initiatives lacking connection to the concepts level come down e.g. to analysis of six levels process hierarchy - a sound excercise indeed but not well rewarded in terms of company’s bottomline.

A lower level of the competence stack is the enabler for upper levels. But does upper levels skills have value in the absence of the lower?

I think yes, yet limited:

  • If you try to implement process management in the absence of accounting then your achievements will be limited (if any): you’ll quickly find out that every business process operates with business objects managed by enterprise databases and applications. For example, if you target the “inquiry to order” process without a CRM system then after a while you will find yourself developing your own CRM within the BPM project. (It maybe justified in some cases but be aware that packaged CRM applications will likely be superiour to in-house development.) BPM is mostly for those who have ERP and CRM but aren’t happy with these.
  • Lean implementation without competence in process management may be successfull at departmental level but it’ll be hard to extend this methodology to the enterprise level because BPM is the key competency in dealing with cross-functional business processes.

Conclusion: starting from top-level competency may only make sence to gain initial education and experience. Their full power is unleashed only when supporting competencies are presented at the lower level.

Unfortunately the existence of different levels of management competencies and relationship between them is not realized by managers and consultants. I guess this is the background of some dramatic failures.

A likely scenario:

  1. Assume that Company A has made impressive progress in transforming its business. The information about this success become public.
  2. Consultants participated in A’s project wrapped up the experience into a new methodology X and started to promote agressively the X and themselves. This is how TQM (Xerox), Lean (Toyota), Six Sigma (Motorola) were invented.
  3. Company Q decided to use the X methodology and repeat A’s success. Yet the books about X tell little about the necessary Y and Z competencies - mostly because Y and Z are taken for granted at A. Besides, any pre-conditions would have negative impact on sales of X-based services.
  4. As a result the Q’s project fails. A succeeded and Q failed because A posessed necessary low-level competencies while Q decided not to waste time and take the shortest route to “success”.

Failure to understand the relations between competence levels also leads to wrong assesment of investments effectiveness. For example, it’s widely known BPM projects compare favorably to ERP in terms of ROI. Given that ERP belong to functional competence and BPM belongs to the higher level of process competence, it is not surprising. ERP implementation gives some immediate effect but probably more important is that without ERP you can not benefit from BPM and other skills of the upper levels. Similarly, you can not effectively implement Lean without BPM.

Summing up, here are the promised advices:

  1. Do not approach full-scale implementation of upper level competency before mastering the lower-level competencies it depends on - the return will not match the expectations.
  2. Don’t stop after implementing a low-level competency - the most part of the reward comes from implementing top-level competencies that become accessible.

Single-move thinking isn’t enough in business - sometimes you need to plan combinations like in chess. Consider not only material gains (current income) but also the position in the play (acquisition of basic competencies) and the tempo (business agility).

This game isn’t for short-thinking minds indeed. There is also a risk that your successor will harvest after your combination.

Explaining such a combination to shareholders is another tough task. Yet I hope that proposed competense stack is simple yet helpfull for this task.

But probably the toughest question is - what to do if the company has came to the edge already? Well, “Only the paranoid survive.” For others it’s always too early to think forward until suddenly it becomes too late.

If you suddenly found yourself in a swamp fighting with crocodiles you have to think both about the nearest crocodile and draining the swamp.

The following posts consider various aspects of the management competence stack:

01/31/10 | Articles | , ,     Comments: 9

(Русский) Семинары НИСКУ 15.12.09 и 16.12.09

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

Do You Need Hands Or Brains?

The question is addressed to prospective sponsors of BPM projects, i.e. top managers and/or business owners. Unfortunately I don’t expect there are many of them reading this blog so we’ll hardly get the answer.

The question arose after another meeting with a prospect customer led by young, ambitious and most importantly, knowledgeable manager. Isn’t it great? I’m happy to meet an educated top manager who doesn’t need a story about business processes and BPM.

Yet there is a problem: the leaders of this type tend to specify a solution rather than a business issue. We expect to be called to deal with a problem and propose a solution, but it turns out that they consider us as “programmers”.

» read the rest

Why Business Users Change Software Requirements All The Time

I hear again and again developers’ complains on business users changing software requirements. (Especially so for business processes.) If asked “why do they?” such developer readily answers “because they don’t know what they want”. (This is a soft version of the answer indeed.)

May be so sometimes. But it’s worth to realize that business is under pressure much higher than developers are. We may require at least some degree of logic from our users but they have to deal with volatile customers, mean competitors, heartless state machine and market which is blind and deaf to our problems and arguments whatever logical they are.

So let’s be more patient to users that don’t always behave like we want them to.


11/24/09 | Notes | ,     Comments: 5

Copyright © 2008-2016 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments