Janelle Hill from Gartner asked: “Do You Understand the Difference Between Workflow and BPM?“. I enjoyed the comment saying that her answer “makes it easy to show that BPM is not just workflow on steriods as some call it.”

According to Gartner, the ideal BPMS implements 10 technologies of which workflow is only one:

1. Process Execution and State Management Engine - a component that implements workflow.
2. Model-Driven Development Environment. But workflow products usually has a graphical modeling tool too. Limited (usually only the orchestration without choreography), not following standards (BPMN), but it’s there. Hence the score should be 2/10 instead of 1/10.
3. Document and Content Management. In my opinion, there are structured data, unstructured content and processes. For each of them we have, respectively, DBMS, ECM and BPMS. It’s better to respect the borders: neither manage content via BPMS nor manage processes via ECM. After all we do not include Data Management into BPMS because DBMS is perfect fit for this task, so why the content should be different? 2/9.
4. User and Group Collaboration. Yes indeed, but again - why considering this as part of the BPMS? Do we only collaborate within the process context? Of course not - there are projects for example. It’s absurd to have separate collaboration environments for processes and projects. 2/8.
5. System Connectivity. BPMS treats the work done by people, document processing activities and actions performed by automated systems consistently, without bias towards the first (human workflow) or second (docflow). I’d place items 3 and 4 above here too as integration with content management and collaboration tools.
6. Business Events, BI and BAM. Strictly speaking, only BAM is tightly coupled with BPMS, the other two can be used independently.
7. Inline and Offline Simulation and Optimization. I guess only Gartner knows what “inline and offline” means here but it’s OK.
8. Business Rules Engine. In theory it can be used as a global variables repository by any (preferably by each) corporate application. But in practice it’s mainly used by BPMS.
9. System Management and Administration. Well any system has one form of it or another: 3/8.
10. Process Component Registry/Repository. There is some kind of process repository in a typical workflow system, too. On the other hand it’s probably not the best idea to have a process repository within BPMS separated from SOA services repository. 4/8.

The final score I got is 4:8 rather than 1:10. But the scoring idea is silly indeed: there is something more than just technology at BPM side. Before comparing BPMS vs. Workflow one should stress that BPM != BPMS. BPM consists of:

1. Methodology: hierarchy of organization’s goals, value chain, cross-functional business processes, process discovery, cycle of continuous improvement.
2. Implementation: a program comprising a series of projects, agile development.
3. Technology (BPMS).

Without the competence in methodology or implementation a BPM project is doomed even with the best BPMS.

You just won’t figure out how to use it right. BPM is integral and holistic discipline where three parts above perfectly fit to each other. For example:

• There is no efficient process discovery (methodology) without rapid prototyping (technology).
• There is no continuous improvement (methodology) without agile development (implementation).
• There is no agile development (implementation) without process notation acceptable by business analysts (technology).

Unfortunately most of those who doesn’t see the difference between BPM and workflow believe “methodology” is a dirty word. The arguments above won’t impress them because they only believe in the technology of their own:

• Continuous improvement? Nonsense, we must design carefully and most importantly - specify requirements thoroughly!
• The graphical process diagram? The true program is made of the code, not by arrows and boxes.
• We automate whatever business says.
• Agile Development? Our users agree to work only with a system having full functionality.

Since workflow is nothing but technology it’s more comfortable for these kind of people than obscure, overhyped and overcomplicated (from their point of view) BPM.

Yet being limited by just technology is a weak spot of workflow. It’s typical usage is the automation of routine operations at the department level. It saves efforts and brings more order to the office but the company’s bottomline is not affected, the competitive advantage is not gained. In order to reach these targets we must deal with the value chain and end-to end processes, resolve resource conflicts around cross-functional processes, design a network of communicating processes…

So complexity doesn’t come from BPM but rather from business processes. The complexity of BPM is adequate to the complexity of business and the complexity of workflow is insufficient. Since the complexity of the control system can never be less than the complexity of the system being managed the complex task of business transformation in case of workflow is inevitably reduced to the office automation.

Getting back to technology, I would not say that BPMS wins workflow 10-to-1. But it doesn’t need to because there is another important aspect: BPMS is generally the next generation of technology. Thin client, XML and web, modern standard platforms (J2EE or .NET) and standard notations (BPMN, BPEL) instead of proprietary ones. In the rapidly changing IT world even a relatively small technology gap is fatal: when the majority of developers start treating some direction as obsolete, it quickly becomes marginal simply because nobody wants to deal with it without extra reward or pressure. Whether you like workflow systems or not, only those will survive who can switch to the mainstream: migrate to a modern platform, accept standard notation, implement the missing features from Gartner’s list, i.e. become a BPMS.

Banking and telecom were the first BPM adopters. How valuable is these pioneers’ experience for other industries?

Let’s consider a manufacturing company. Roughly speaking, it consists of a shopfloor and an office. The demand for BPM comes from the office: the customer-centric business processes, the issues of cross-functional cooperation, the interaction between people and automated systems are all here.

The shopfloor has processes, too. But these processes have specific issues, specific methods and technologies: production lines, automatic machines, process control software. There is no cross-functional issues - it’s a single function after all. There is no need for BPM here, rather industrial automation and robotics.

Now look at the bank. It has the office, too. The processes here are basically the same as at the manufacturing company’s office: interactions with clients, personnel on/off-boarding, advertising campaigns planning and execution, computers maintenance, bookkeeping etc. Therefore we may expect that BPM is applicable in pretty same way.

The bank’s ”shopfloor” is a place where accounts and transactions are stored and processed. The principal difference from the real shopfloor is that it doesn’t need people: only servers, databases, automated systems and networks. Computers instead of humans and machines, ATMs and SWIFT instead of delivery service. Unlike the real shopfloor, it’s possible to fully automate the bank’s shopfloor.

Since a single automated system can’t satisfy all needs and besides we interact with other banks’ systems, there is a need of processes at the bank shopfloor to coordinate actions performed by different computer systems. A human is either not involved at all (STP - straight-through processing) or only handles relatively rare exceptions.

No humans - no pain: the most part of the process complexity goes away with humans. Therefore the complexity of bank’s shopfloor processes is much less than the complexity of the office processes. On the other hand the shopfloor processes’ performance, reliability and scalability requirements are much higher. The process consisting of calls to three or four systems and databases, several business rules and couple of logical gateways is relatively easy to model, it doesn’t change frequently due it its simplicity but it must be processed in milliseconds and the system must handle a huge flow of such processes. This is a perfect fit for BPEL while process methodology and agile implementation are of no use. It is a pure IT project.

A telecom company has a human-less “shopfloor”, too: a client makes a phone call - the process runs from the beginning to the end - the data are stored into one or more systems of one or more (e.g. in the case of a roaming call) companies.

Historically, both the systems used to manage specific processes at banks and telecoms “shopfloors” and the systems designed for office processes are called BPMS. It pleases those vendors who have chosen a strategy to satisfy the banks’ needs first and then try to adapt the product for the rest.

So when a vendor reports on successful BPM implementation at the bank or telecom, it is often about the “shopfloor” processes really. But due to the human-less nature of these processes such experience is hardly applicable to other industries. We may call such projects “BPMS without BPM”: BPMS is involved but the other two components of BPM - a process methodology and agile implementation - are absent.

I don’t mean that all BPM implementation in banks and telecom are of this kind. For example the initial phases of “Issue a Loan to an Individual” (application processing, customer verification, decision making) is a typical office process with human activities and complicated logic, long-term yet relatively low-intensive. When the credit is approved and the contract is signed, the end-to-end process continues at the “shopfloor”: the information is stored in information systems, the SMS notification is sent to the client etc.

So better get deeper into vendors’ cases, try to figure out whether it’s BPM or just BPMS.

There is confusion in the classification of software used to manage business processes:

• Enterprise Architecture (EA) tools target the following aspects of enterprise architecture:
  1. Business architecture - business goals, organizational structure, functions, processes, roles, etc.
  2. Application Architecture - enterprise systems and interfaces
  3. Data architecture - logical and physical
  4. Technology infrastructure - hardware, software, networks
• Modeling abilities of Business Process Analysis (BPA) tools cover a subset of EA: business architecture. But in addition to modeling BPA may include specialized tools like process simulation or statistical analysis.
• Business Process Management Suite (BPMS) must include business processes modeling, execution (process engine) and monitoring/analysis. Optionally it may include simulation, business rules and much more.
• Some vendors define their product as “BPM Software”. Usually this means that the system doesn’t fit into BPMS category - for example there is no engine - but marketing wants it to be labeled with BPM.

BPMS enthusiasts (including myself) believe in the power of executable business processes, in “what you model is what you run” principle. The process engine is a must for them so they can’t live with EA tools only.

On the other hand, enterprise architects have no idea how to handle business processes apart from the organizational structure, data and applications architecture. While many BPMS allow modeling the organizational structure, roles and external systems, it is fragmented to the level of “project” - that is, a logical business process (there may be several physical processes in the project) and do not cover the entire organization. Therefore BPMS doesn’t fit architect’s needs.

Now what shall we do about it? Maybe it’s a temporary issue and BPMS will eventually grow up to EA or EA will include the BPMS functionality some day?

I’d be glad to be wrong but I won’t expect this. Let’s forget about processes for a moment and look at the data architecture. DBMS is much more mature technology compared to the BPMS yet the divide between EA and DBMS is not going to disappear. Enterprise architecture deal with databases but their internal structure is modeled by specialized tools.

Getting back to the processes: they can be modelled both in EA and BPMS. As for today BPMN may be used in both. Typical business analyst knows EA/BPA tools better so the natural way to go for him is:

1. Draw BPMN diagram within EA
2. Two possible options:
   • If BPMS directly executes BPMN, export-import via XPDL
   • If BPMS supports BPEL, translate BPMN->BPEL

For example, model in ARIS and export to WebMethods. Or model in Casewise and translate to Oracle BPEL.

This workflow is simple, logical, but… not working well. Both options work only if we consider a single pass: draw - handover - execute. Yet BPM is not a one-time process automation excercise but management of ever-changing business processes.

What does it mean in practice? Once the model is loaded into BPMS, the developer edits it to specify certain details required by the execution engine. At the same time the original process model in EA tool doesn’t remain unchanged because analyst improves it continually. (I strictly recommend a series of posts started with “Model Strategy: Preserving vs. Transforming” at Keith Swenson’s blog to anyone interested in the matter.)

Now we must either transfer the details of physical implementation back to EA and find a room in the repository for them (so-called “round-trip” problem) or merge changes made in both models (like branch merging in version control systems). In theory the problem can be solved but as a matter of fact it wasn’t for years. Shall we wait more?

I propose to accept that:

1. EA-BPMS divide exists and will remain for the foreseeable future.
2. There will be no satisfactory automatic artifacts passing between them in the foreseeable future.

So where should we draw this division? There is certain freedom because the tools overlap. It’s better indeed to minimize the volume of information transmitted.

Suggestion: let’s divide at the level of a single process -

• The value chain analysis and inter-process communication (via events and/or data) modeling is done within EA tool
• The internal process logic is modeled within BPMS

This way only the list of processes and their interfaces will be transferred from EA to BPMS. Automatic export-import is not necessary for this task, we may utilize “export-import via the printer”.

Every business analyst should obey the red line: never use EA tools to model business process internals if BPMS is present.

There is better application for BPMN capabilities of EA tools. BPMS mostly focus on modeling the internal logic of the processes (orchestration), it’s poorly suited for interprocess communication modeling (process choreography). But the orchestration alone can only solve the tasks at the “office automation” level; as soon as you target the end-to-end business processes - i.e. the processes of real value - you can’t do much without choreography. (See process anti-pattern “End-to-End Process Orchestration”.)

Interprocess communications can be modeled by EA tools using the so-called “black box BPMN diagram” - modeling technique presenting each process as a blank BPMN pool. Communications through messages is modeled by message flow, communications through the data is modeled by associations.

BPMN diagram of interprocess communication (black box diagram) produced by EA tool may look like this:

For each process of the above diagram a BPMN diagram is created in BPMS. It deals with the internal logic of the process (white box diagram):

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.

Summary

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.

An example:

We can draw whatever we wish of course but as soon as we tried to make this diagram executable we’d find out that in the real world the payment doesn’t always arrive. As well as in the case of “one-way activity” antipattern, we communicate with an independent subject having a free will (the buyer) and we can’t assume that it will follow our prescriptions.

We should consider at least three outcomes in this example:

1. payment arrived
2. buyer informed about refusal to pay
3. neither payment nor refusal arrived in due time

There is a special BPMN construct exactly for such a case called “exclusive event gateway”:

The beauty of this construct is that the process executes in parallel after passing the gateway, expecting all three events simultaneously. But as soon as one event happens, the other branches stop executing automatically and immediately.

The big regret is that BPMS vendors tend to consider the event gatway as luxury. I know several systems being declared as supporting BPMN yet not supporting this construct.

This is mistake I’m afraid because alternative messages processing can’t be avoided! The only possible way to solve the task in the absence of the event gateway is parallel gateway. But here we hit the problem of stopping other routes as soon as one of possible events happens. It can only be resolved with ugly diagram constructs and/or program code. Of course the process visibility and standard compiance become lost on the way.

This antipattern is special because it comes not from process analysts but from BPMS developers. On the other hand, it’s BPMS vendors will to eliminate this antipattern - they only need to change their attitude towards the event gateway.

As long as particular BPMS does not support the exclusive event gateway, one cannot effectively utilize the message flow. The software supports orchestration but not choreography. An old good workflow to me, whether it has the BPMN label or not.

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

This anitpattern is almost trivial. Yet watching how different people make the same mistake at different projects I come to conclusion that it’s quite popular

Example 1: Concluding a contract. The draft must must be signed on behalf of our company by CEO:

Please respect the boss by giving him the opportunity not to sign the contract - put the gateway immediately after “sign by the CEO” activity.

Example 2: while processing a customer’s order, an agent company places an order with a partner:

Recognize that the partner has a free will and take into account the the possibility that he will not accept our order - add the gateway to the process.

One-way modeling is OK at early stages of process discovery, it’s the so-called “happy path”. On the other hand, is there any activity with the predetermined outcome? Maybe it’s better to check the result after each and every activity?

Putting gateways everywhere will clutter the scheme. The lesson learned from this antipattern is this: as a minimum, put the checks after activities where the free will is clearly visible - for example, assigned to decision makers or organizations independent of our.

BPM conquers the new territory which is called in different ways: Dynamic Processes, Unstructured Processes, Knowledge Worker Processes, Barely Repeatable Processes, Case Management.

BPM now reached the maturity level where the management of repetitive and predictable processes has become a matter of technique. It grants reliable process execution by unreliable employees - low-paid, with low skills and low motivation. Such processes are common for state and semi-state organizations and also for businesses following an extensive path of development.

But only “very talented” individuals can believe that every process can be rigidly structured:

Leaving aside the extremes - fully structured and completely ad-hoc processes - there are two combinations: either a structured process launches the ad-hoc or vice versa.

1. “A Little Help From a Friend” pattern: a structured process launches ad-hoc subprocess. An example: system integrator’s “request-to-order” process. Let’s assume that sales rep’s meeting with a client was positive meaning that he found  ”pain points” - issues that the client will pay for if they were resolved by the integrator. The next step of the process is finding a solution. However, the client’s problems may vary at very wide range (note that integrator’s value is exactly his ability to solve a wide range of problems) starting from the simplest need of a boxed software to complex projects. In the latter case the process will follow a trajectory unknown in advance that may involve an architect, developer, sales manager, systems engineer, vendor’s tech support etc. Traditional BPMS can only represent this unpredictable subprocess as a single task (see “Process Antipattern: One Man Show“). This is a poor-man’s solution indeed because it isn’t visible who is addressing the issue at the moment, what progress has been made and what the current timeframe is.
2. The opposite situation, the “Process Toolset” pattern: unpredictable process at the top launching well-formalized subprocesses. An example: a law firm having client’s case as the top-level process. It’s absolutely impossible to predict in what direction the case will turn next day, e.g. a new document may be submitted by the opposite party that will change radically both  the case prospects and our plan for actions. Yet many of the actions initiated within the case are standard, making it possible to formalize each as a subprocess. They are mostly preparing applications or other documents for the court. Such subprocesses is executed by a dedicated specialist - a common resource not assigned to a specific case. From business perspective it’s interesting to monitor performance not only of the case as a whole but also of subprocesses and resources usage.

Going down from the top-level business processes (company’s value chain) to the lowest level (micromanagement) we must be prepared to encounter both structured and ad-hoc process. Support for the latter in today’s BPMS is far behind but this subject is widely discussed by researchers, analysts and vendors:

• The following estimate was made at Gartner’2009 conference: as much as 60% of an organization’s processes are unstructured – and probably also unmonitored, unmanaged, unknown and unruly. These 60% are like “average temperature by the clinic” but the “invisibility” of these processes can indeed be the major issue from business standpoint.
• “Tapping into Collective Knowledge Will Drive Unstructured Process Activity” - Jim Sinur predicts that organizations acceptance of collective knowledge, industry networks and even social networks will result in fundamental changes in BPM. His another post on the same subject: “White-collar and unstructured processes go together like cheese to wine“.
• The boom of social networks pushes the idea to borrow approaches evolved there for communication within dynamic processes - see the Workshop on BPM and social software at BPM conference in Ulm. For example, when confronted with a problem, I can publish the question on the corporate social network (”a help from a friend”). It’s visible to my “friends” including the project manager and team lead. The best answer gets a bonus.
• SAP shows how Google Wave collaboration technology can be used - not for process execution but for modeling. SAP Gravity is a BPMN modeler implemented within Google Wave. Taking into account that the ability to redesign a process on the fly is essential for dynamic process execution, SAP makes progress not only in process modeling and discovery but in the the execution too.
• Oracle talked about collaborative and dynamic BPM at Oracle OpenWorld’2009. They emphasized commitment to SCA that makes possible to combine different kinds of processes with business rules, analytics, etc. That’s no surprise taking into account that they have acquired about 50 companies in two years and hence face huge integration challanges.
• HandySoft, ActionBase and other vendors claim dynamic processes support in the latest versions of their products.
• The most authoritative industry experts gather to discuss dynamic processes in general and their support in BPMN.

So we can see a number of minds attacking the problem from different directions. Well the more alternative approaches, the better final solution should be.

Yet for BPMS vendors that may be a bloody battle. There is probably more BPM vendors than the market needs and now a new front  opens for the competition: dynamic processes. It’s quite wide front if all aspects of dynamics are taken into account so I’m afraid not all vendors will be able to fight it in the current economic situation. But at the end of the day those who provided full support to dynamic processes will posess a competitive advantage clearly visible for the users.

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.