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

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.

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

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.

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.

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

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.

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

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

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.