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:

• Separate Business Methodology from Process Discipline
• Action vs. Feedback
• Choosing Betwen Competencies of Same Level
• Inhouse vs. Borrowed Competence
• Business-IT Consulting Gap

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

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

Business is like war, war is like chess. Of course any analogy is lame but why not playing with analogies for fun?

Businessman: we make decision on the basis of a payback or ROI assessment.

Chessplayer: sure one must calculate in advance how much material gains - pawns and figures - may result from a move. We calculate combination too. Yet our game consists not only of combinations. There are forced moves when you calculate rather possible losses than gains. There are moves aimed to pure position improvements. A player may sacrifice a pawn for position improvement. After all if your position does not develop, you won’t have a chance for the attacking combination and ROI would be simply out of question.

Militaryman: we call it getting into a strategic funnel: move after move one has fewer and fewer possible moves that are not leading to defeat.

Businessman: we have company’s strategy too.

Chessplayer: we call it a game plan. Yet in our case the same player build and perform the plan and you calculate win/loss balance after every few moves and depending on the result the chair can take another CEO. It would be interesting to watch your team at the chess board.

Militaryman: a chess game corresponds to the battle or campaign level. A commander may be replaced in the course of the battle only under exceptional circumstances. But a change of command is not uncommon if a war lasts long enough. Business strategy expands beyond the next war so it’s out of our scope, being equivalent rather to geopolitics.

Chessplayer: by the way we calculate not only material gains. There is also a tempo: gaining a tempo means that a player has spent one move less than the opponent. As the result the player gains the initiative: he has many moves to chose from while most of opponent’s moves are forced. Besides there is game’s time limit so we search not the best move but a good enough move that can be found at a shorter time possible.

Militaryman: we calculate the operation’s tempo too. A classical example is mobilization and deployment timings that become the cornerstone of the famous Schlieffen Plan of the German General Staff for the war that was called later First World War. We also know how to drive an enemy under the pressure of chess clock’s flag: by flooding its headquarters with contradictory information and misinformation leave him no time to digest it which eventually leads to complete paralysis of command and control.

Businessman: ok, guess now I’ve got what this “business agility” thing I heard so much is about…

This post continues ”ROI of ERP and BPM” topic. BPM is a speedy, combinational, attacking game while a corporate systems deployment is struggle for the position which alone makes combinational play  possible. Or a forced move at bad cases.

BPM advocates like to point out that, unlike typical IT projects, BPM gives a quick financial return. For example, according to Gartner data quoted by Jim Sinur, half of BPM projects demonstrate ROI at 20% or more. He saw “wild” numbers of 220% and 360% which he discarded to not skew the average.

Unfortunately this nice picture makes harm rather than contributes to the perception of BPM if not supported by analysis. Potential customers are well aware of reported bottom line numbers value and don’t trust another “silver bullet”.

I guess I can explain why BPM projects ROI is good on average, and why it shows such a large spread: it all depends on the corporate information system.

Let’s consider a company that implemented an ERP system. It may not even cover planning (after all, “P” in ERP stands for “Planning”), just accounting in the areas of finance, customers and suppliers relations and inventory - this seems to be a typical case. With BPM not only users of accounting and finance are engaged into end-to-end business processes but also management, engineering, purchasing, manufacturing, sales and marketing. Traditional corporate systems are ”passive”: it is able to answer almost any question, but only if you know how to ask. BPM makes it active by assigning tasks in accordance with the approved business process scheme, it controls timings, triggers escalations etc. All process activities are reflected in the appropriate records of a single database. As a result, instead of a «corporate data cemetery», we obtain an efficient tool to improve the quality of services, to increase sales and to respond quickly to changing business environment.

As shown by E. Goldratt in his book “Necessary but Not Sufficient” most of commonly declared economic value of ERP - increased transparency and productivity, attractiveness to investors, inventory reduction – is a fiction. The corporate system is necessary but not sufficient condition for achieving the bottom line results. Sure ERP has the potential to improve the economic efficiency of the company but only when supplemented with BPM this potential becomes a reality.

Now let’s suppose that we spent a million to implement ERP and two hundred thousands for BPM project. If we agree that ERP is necessary then the achieved results should be referred to the total costs incurred. But if you take into account only the cost of BPM then you’ll obtain the “crazy” ROI numbers mentioned above. Let me use a telecom analogy: ERP is like the backbone and BPM is like the last mile solution. Does it make sense to improve the ISP bottom line results by ignoring the cost of the backbone?

Of course it’s impossible to be in ISP business without a backbone access. Unscrupulous Internet provider may promise a client 10Mbps connection not mentioning that it’s only the bandwidth to its network and that the actual connection to the Internet will be ten times slower. The same thing happens when a customer says: “I have heard that ERP isn’t cool any more and there are problems with the payback. You say that BPM is such a great thing so isn’t it better to implement BPM instead of ERP?” Sorry, there is no way to do it “instead of”, only “together with” ERP! BPM not supported by the foundation of a corporate information system is like a good old docflow: weakly structured data which can not be processed, found or extracted at the right time and in the right way.

Getting back to telecom analogy: local provider is usually a better choice than global operator when you are looking for home Internet connection. Trying to reach every workplace within your company by ERP is about the same: ERP consultants can do it but basically it’s not their job. They usually recommend adapting your business to ERP rather than vice-versa. Adapting the system to your business turns out to be very expensive. In contrast to setting up Internet connection which is only done once, business processes should be within constant improvements loop so you’ll have to call programmers all over again. Therefore many companies have come to the conclusion that the implementation of business processes within ERP isn’t efficient and opt for BPMS which allows their own business analysts to design business processes.

Now let’s consider perhaps the most common situation: information «zoo», no single corporate system, Excel as the primary manager’s tool. The pilot BPM project is usually successful under such conditions. If the right business process is chosen, then BPM can streamline the process, radically reduce its cycle time, ensure seamless information transfer between functions, reduce costs, improve quality and ultimately provide solid economic results. Yet after the first success the BPM initiative often slows down because BPM team have to deal mostly not with business processes but with integration and accounting automation. The timeframe increases many-fold comparing to pure BPM project and financial performance declines.

You still need a backbone which business processes would connect to but in this case there is no single corporate system for this role. There are two possible solutions: either to implement ERP or to deploy a backbone based on service-oriented architecture (SOA). Both ways are hard, long-lasting and expensive but the alternative is to leave everything as is, forget about consistent business process management and finally become uncompetitive.

Of course it’s impossible to say which way is better - a unified system from a single vendor or the integration of various “best of breed” systems. Yet the recent years’ trend is the growing adoption of the latter approach. One reason is the progress and better affordability of integration technologies - ESB, MDM. Secondly, a unified system turns out to be a mirage: once the ERP is finally implemented you found yourself in need of CRM, PDA software for mobile workforce or software to monitor vehicles via GPS+GPRS. This way you fall back to the “best of breed” situation.

Conclusions:

1. Economic impact of a BPM project depends on how much the company has spent before on the corporate system: the higher the amount, the higher return on investment can be demonstrated by BPM. But these figures are fiction because you assigned the lion’s share of total project’s costs to ERP and a large share of revenue growth and cost reduction to the BPM project.
2. In order to really improve the return on investment, one must consider not separate ERP and BPM projects but all investments in management improvements or, if you wish, in business transformation. A chain is only strong as its weakest link: if you invest only in ERP then you will get an information backbone not reaching its consumers. And if you invest only in BPM then the first success will turn into disappointment when information flows from the business users hit into inefficient corporate system.

Please also note that the weak link may be people rather than technology. Implementing even the most sophisticated systems makes no sense if employees are not prepared to creatively reconsider the way they work. How many certified professionals in Theory of Constraints, Lean Manufacturing and/or Six Sigma does your company have? Highly motivated and well-trained professionals are the driving force behind the business processes management and enterprise information systems. Not just IT professionals but also specialists in modern management methodologies. And what is the driving force behind them? Company executives indeed.