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.

First picking the moment to ask an account from Google, then waiting it for two months and looking for a time slot to dig into Google Wave and experiment with it… OK, finally I’m ready to share my first impressions.

Let me start with the conclusion: a useful thing, too bad I didn’t join earlier.

Now to the details. The primary references:

• About Google Wave
• When to use Google Wave

A quote from the above: “Google Wave is an online tool for real-time communication and collaboration.” Got it? Damned if I did. So let me compare it with familiar things. Google Wave consists of… hm… waves.  In order to avoid confusion I’ll call them “gwaves” and the service itself “GW”.

So what is a gwave? Please imagine a MS Word text. Now imagine that:

• It’s stored on a Google server and you access it via GW webpage from your browser.
• Formatting features are very basic: fonts, colors, margins, headers, lists, images. You may have attachments though like you do with email.
• All changes are recoded (who, what, when).
• It is filled with comments, questions, answers, discussions. Not aside of the text like in Word but framed text blocks right in it. Formatting capabilities are the same as for the main text.
• The text and comments can be deleted by any participant so you can get the accurate text output at the end if you wish. But all the moves are recorded and there is a replay button showing how the document progressed.
• Participants are the gwave creator and other GW users he invited into the gwave.
• The real-time means this: when one participant is doing something with the gwave you can see how letters are typed and words are added to the document, provided that your GW page is open.
• Collaboration means that I can enter text into one section while others fill theirs and in so doing we throw each other comments, remarks and questions. No locking and hopefully no conflicts, thanks to real-time communication (didn’t try to provoke conflicts though).

Is such a combination better enough than MS Word + email to justify studying another tool? I believe yes. GW avoids the questions like “where is the latest version of the document?” or “does it contain my last edits?”. As Keith Swenson rightly points out (here and here) we are exposed to “email addiction” so this is the right cure.

The first gwaves I experimented with:

1. At work we discussed whether to accept an invitation to a conference. We decided to go and hence the discussion went further: the event schedule, assignments, brainstorming, etc. connecting more and more people. Without GW everything would have been in the email - much less convenient and efficient.
2. At home we discussed the movie player upgrade with the son. It lasted a few days: defining the criteria, comparing models and looking for a good price. Again, more handy than email indeed.

What else a gwave can be compared with:

• A forum thread. A gwave with large number of comments resembles it. Comments hierarchy (comments to the comments) is supported. The difference is thatyou can edit the main text and comments any time.
• A photo site with comments. You can publish a photo as a gwave and discuss it with friends.
• A Document Management System in general and wiki in particular. The same teamwork but the difference is the real-time in GW. The discussion is not on a separate page like in wiki but embedded into the text. I like both features. Trivial access policy: members can do everything, the rest nothing. No contents pages or rigid classification, only tags. Conclusion: wiki is for memories and GW is for ad-hoc temporary things.
• A bugtracking system - it’s arranged by cases, too with attached files and ongoing discussions. By contrast, GW has no structure which is hardly acceptable in bugtracking.

GW pros:

• Very easy to learn, the user interface is problem-free. Only one essential hint: double-click into the text body to edit it or add a comment.
• Extensibility. Plugins (gadgets) are actively developed by third parties; didn’t get into it yet. By default there are Google maps and voting (yes/no/maybe). So if you are thinking about skiing with a company of friends then you’ll be able to mark the place and discuss who goes, who doesn’t  not, when exactly etc.

Cons and questions. (Some of them may be my problems rather than GW’s because I didn’t explore it fully yet.)

• No notification of changes in your gwaves. If the GW page is opened in a browser, the tab title indicates changes: “Google Wave (3)” means there are thress changes in the waves you follow. People comment on this intensively on GW’s ideas webpage. Some say that Google tries to kill email this way. Dont think so, they must be realists and consider it as a supplement, not replacement. So I hope to see email and RSS notifications in the final version. In fact I’d prefer the latter because I keep the Google Reader page open anyway.
• Permanent address (URL) of the gwave is another must-have. Right now I can’t see how to integrate a gwave into the web e.g. to embed the link into email message or blog post.  By linking to a gwave we’ll be able to add ad-hoc functionality wherever we may need it. SAP has made it with the Gravity plugin (BPMN designer for GW). Yet I believe it’s more natural to go opposite way - it’s much easier to reference a gwave say by the “Link” field of MS Project task rather than implement Project as a plugin. <updated>gwave’s URL is displayed in the browser address field when a gwave is selected. That easy!</updated>
• Numbered lists are not supported. It’s weird because there is a bulleted list in the formatting toolbar.
• The biggest problem: all gwave  participants must be registered GW users. This is quite a barrier. By contrast, you don’t need an account to start using Google maps or search. The Google mail, too doesn’t require the adressee to have gmail account. Google’s picasaweb photobank lets you send a “secret” reference to your private album to grant access to it - it’d be great if something like this was implemented in GW finally to let a casual participant without permanent account see the gwave. I am sure Google will do something to facilitate GW adoption.

Now how to get a GW account? To start with, you should have a google mailbox (@gmail.com). The easiest way is to ask someone already having GW account - each of us have 25 invitations. Alternatively you can apply directly to Google but be prepared to wait. It may happen Google will make the service generally available before you got your invitation. By contrast, an invitation from existing GW account comes almost immediately.

<updated>Usefull links:

• Google Wave 101
• The Complete Guide to Google Wave
• Ultimate List of Google Wave Gadgets and Tools
• How to Install a Google Wave Gadget Extension

Happy waving!</updated>

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.

QHJNDDH3UF9Q

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.

When downloading a BPMS trial or demo, keep in mind that when it comes to production, the resulting system will differ from out-of-the-box version in many essential aspects:

1. The user portal - web application that starts processes, displays the list of tasks assigned to the user, manage activity forms for these tasks, monitors and administers processes. It will have different design in production and most likely different functionality too. If you’re lucky you will be able to customize out-of-the-box portal but be prepared to rewrite it from scratch at some point. Or to get away from a standalone BPM portal completely and wire process functionality into corporate applications. The reason: users typically do not accept BPMS suppier’s opinion that BPM should be the center of user’s universe.
2. In particular, you should eventually get rid of “start process” button. From user’s perspective, he doesn’t “start a process” but do something real e.g. accepts the incoming order or submits a request for vacation. The system must start the appropriate process transparantely.
3. Be prepared that activity forms generated by BPMS in few mouse clicks will no longer meet the functionality, usability and design requirements at some point. So it’s better to have an idea how will you eventually develop these forms in terms of tools, labor force and costs. The importance of this issue can not be overestimated: what good is that the process scheme is depicted in two days if forms development for this process then takes say two months? (I do not play down the importance of rapid prototyping of screen interfaces - it’s the must for BPM, one won’t even come close to production without it.) By the way you probably would like to use the same tools to rewrite the BPM portal.
4. Similarly you will no longer be satisfied with out-of-the-box reporting and monitoring tools at some point.
5. Demo and pilot processes typically store all data in process attributes, process variables or operands (different systems use different terminology) but only relatively insufficient and/or temporary information will be stored this way in production. Most data will go into a traditional database and only the primary key of the corresponding record will be stored within the process. Considering the process of client purchase order negotiation as an example, the information about the client and the order items are likely to be stored in a database while customer and order identifiers will remain in process attributes together with the deadline date for the call to the client. The reason to act this way is obvious: data which may be of interest after the process instance has ended must be stored so that they could be accessed independently from the process instance. This also means a separate user interface to this data independent from process screen forms. As for the process screen forms, they should access both process attributes via BPMS API and database fields via DBMS API.
6. Building on the previous item, most likely the part of the long-term information (but usually not all) already have a room at your existing enterprise applications. Accordingly, the process attributes will store only the identifiers of the appropirate business objects and process screen forms will access the data stored within the application. (The latter isn’t an absolute requirement - the total integration is often very time-consuming so partial integration may be more justified.)
7. Similarly, while a demo or pilot most likely will store related documents (usually Word or Excel files) as attachments to a process instance, you’ll have to consider something more solid for production. The reason is the same: if the document may be of interest after the process instance has ended, then it must be kept independently from the process instances and user access to it must be provided independently from the user interface to the process. However you don’t need the full-blown ECM system: because BPMS takes care about the workflow you need only documents storage functionality with basic interfaces (user’s and programming) and services (search, archiving, security).
8. Users authentication and authorization in a demo or pilot is usually done via independent LDAP directory, database or even a static list stored in the XML file. It is obvious that production system should utilize your existing user directory. But a bad surprise may be the amount of effort it requires. To start with there are usually several such directories. A typical example: an Active Directory, a separate authorization system within the legacy accounting system and a database keeping the users of remote offices and partner companies. As the project evolves additional requirements may arise e.g. the planned absence and automatic rerouting of the tasks. It is known that for a company having about a hundred of users Active Directory implementation alone is a non-trivial project and now we are facing more difficult task. As a result as much as 50% of total BPM project costs are spent on authorization and authentication issues at some projects. Imagine for a moment that it happened in your project and you didn’t take it into account in project schedule: you are out of schedule and budget for as much as 100%!
9. For obvious reasons not the most complex business processes are taken for demos and pilot projects. That would be all right but worse than that, they are usually technically implemented as a single process thread. But in reality even the relatively simple employee onboarding process technically consists of several processes communicating with each other (it’s enough to notice that processing the incoming resumes is not directly related to the publication of vacancies). This is even more true for end-to-end processes that are of greatest interest in terms of business (see “End-to-end Process Orchestration” antipattern and “Internal Order” pattern). Accordingly, you will need more functionality from your BPMS pretty soon - not only the orchestration but also choreography. Modern BPMS are fine with that but if a rudimentary worflow and/or document management built into your accounting system is all what you have then you may be in trouble.
10. And finally, a production system differs from a pilot by reliability, performance, security … but these are standard requirements not specific to BPM.

But don’t be scared: these issues are typically resolved one by one in incremental fasion; all companies that are successfull in BPM (and any vendor can provide dozens of references) did the job. It’s just better to know in advance what’s awaiting you after successful BPM pilot and to address the appropriate questions to yourself and to your supplier.