Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Cross-Functional Process Optimization

This is third and last part of a study on managing cross-functional business process. Previous parts:

  1. Vulgar Interpretation of Cross-Functional Business Processes
  2. Cross-Functional Patterns

In the second part we introduced two basic ways to organize work within cross-functional business processes:

  • Synchronous - the performing unit starts work as soon as it received an internal order. Technically it’s implemented by a single process.
  • Asynchronous - orders are first accumulated in the input buffer unit of the performing unit, then extracted and processed with some frequency. Technically it’s implemented by two (when there is a single resource) or larger number of processes.

Synchronous mode grants minimal process execution time while asynchronous maximizes the performance (measured by the number of process instances completed per unit of time).

According to my observations asynchronous mode prevails in real life because departments and people both feel more comfortable when they are not chased by a continuous flow of a variety of tasks but have an opportunity to somehow organize and plan their activities.

Business and process analysts prefer synchronous schemes - not with something special in mind but because they just follow the path of least resistance: these schemes are plain simpler. This may lead to conflicts at the process implementation: people are pushed into the process framework which they feel uncomfortable.

Now if we look at it from the organization’s goals perspective (i.e. process performance) then the synchronous scheme is preferred because it provides the highest quality of customer service. A performer may not feel comfortable but it doesn’t matter on the condition that he/she isn’t overloaded (which does not happen as often as it may seem). Improving an individual’s performance may be a sub-optimization which is a bad word.

How can we bring these views together? I’m going to give some recommendation about optimal process schemes

» read the rest

02/17/11 | Articles | ,     Comments: 8

(Русский) Семинар BPMS.ru 24.02.2011

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

02/12/11 | News |     Comments: closed

Laws of BPM Robotics

One of our BPM project’s sponsor said at the very beginning, when we discussed the possible project: “my employees don’t need a control, they need help”. I argued at the moment, but later I realized that he was right.

What do we mean when we are talking about controlling a business process? Should we consider paranoid participants suspecting that the ultimate goal is to control them?

After all, the prevailing view of a process management is this: let’s draw a process diagram and make everyone do what’s written in a box assigned to him. And a manager will get a nice picture: the speed of the corporate machine is running and the amount of fuel it consumes.

But the real life is much more complicated: it’s always about a network of processes communicating via data, signals and messages. In the absence of computer-aided control it’s people who control these processes: they watch the bills to be paid, the orders to be delivered timely and in accordance with specs, the capacity and materials to be synced with orders accepted. They also deal with non-standard situations: customer revoked the order or paid several bills with one transactions, supplier changed delivery date etc.

These are complicated tasks. Really complicated.

And now comes a business process specialist who doesn’t know how to do anything yet knows how to do it better. But if he only knows how to draw a primitive workflow then it’s no use.

Example:

  • A small company reselling “cool stuff”: gadgets, special gifts, designers’ accessories for bathrooms etc.
  • A group of processes “Assortment Management”: several employees permanently monitor internet, visit trade shows, get into competitors’ stores looking for new ideas, brands, suppliers. On one hand, due to the business profile, the assortment must be updated by trendy things regularly but on the other the product line shouldn’t be too large, it must be trimmed also regularly.
  • These several people assess up to a thousands of candidates per month. The company developed a three-stages filter: first an express assessment made by an expert who throws away most of the income. Then negotiations with vendor, logistics work-out and possible profit estimate. And finally all ideas that passed first two stages are ranged once per month and the top candidates are selected for sample purchasing with the total available budget in mind.
  • In parallel, the whole current assortment is analyzed also monthly in terms of diversity, profitability etc.

A lot of aspects are taken into consideration both during selections and assortment revsions. E.g. a number of items within a single assortment group shouldn’t be neither too small (a buyer doesn’t trust when there is no choice) nor too wide (the buyer becomes confused and goes away). The assortment is limited by the physical dimensions: all goods should be placed on the shelf which is limited in size. And other completely informal things like an intuition saying to the expert that particular good is going to be a top-seller.

What can be done here if the path of the least resistance is taken? Well one may automate the assessment with a five-steps process:

  1. Get the quotation from the vendor
  2. Find out logistics terms
  3. Evaluate merchantability
  4. Assign rating
  5. Make a decision about sample purchasing

But to start with, as was shown in the previous post, when the budget is constrained the purchase decision may only be made on the basis of the whole set of candidates and no way in the frame of a single candidate assessment process.

Next, what’s the use of this scheme if all steps are performed by a single employee? This is pure micromanagement. Is it the issue here to control the sequence of tasks? Of course not - the issue is to control the bunch of processes running simultaneously and asynchronously: hundreds of first stage assessment instances, dozens of second stage assessments, selection into and trimming from the assortment. What we need for this task is not a workflow but a complicated enough interprocess collaboration.

People don’t want to be controlled, they need help in controlling really complicated processes.

If you give it to them then there’d be no opposition, people will gladly use a BPM system. Verified by practice.

Yet you’ll need to overcome their distrust on the way - no one at the shop floor a priory expects anything good when “business process” is mentioned. Here is how I break it talking with people:

Imagine that you’ve got a robot assistant. Trouble-free and error-free. It will take the most tediuos, clerical part of your job. You’ll be able to tell it:

  • «Robot, make sure this application got the right desk.»
  • «Robot, prepare an invoice using these data and post it into accounting DB.»
  • «Robot, let me know when we got the payment by this invoice.»
  • «Robot, what is the production schedule for this order?»
  • «Robot, calculate this client’s rating by our standard procedure.»
  • «Robot, watch this order and let me know if it stucks.»
  • «Robot, give me all payment requests for tomorrow sorted by contractors.»
  • «Robot, what did the boss say last week about this complain?»
  • «Robot, the client revoked the order - withdraw it from production if it’s not too late.»

Now tell me - who would not accept such a helper?

Besides the BPM robot is safe because it obeys the laws. Not the Asimov’s law however.

The Laws of BPM Robotics:

  1. A robot will never be able to do what you are able to do.
  2. A robot will do only a part of what you are doing.
  3. A robot will do only a part that you won’t like to do yourself.
02/11/11 | Articles | ,     Comments: 6

Cross-Functional Patterns

It’s time to pay the debts - returning to cross-functional processes modeling as promised.

Remindment: the first part stated that it’s usually impossible to implement cross-functional processes by orchestration only (i.e. within a single BPMN pool). The borders betwen departments are material, they mark differences in manner and rhytm of different kinds of work. Because of these differences the fragments of a process belonging to each department are technically implemented by separate pools while the cross-functional process as a whole is implemented by a set of such pools communicating via messages and data.

In this article we’ll consider common cross-functional process patterns.

Let’s use the following example:

Under routine financial planning all bills received by a company are processed by the finance department first: they determine validity of the claim, check the amount and date, assign priority in accordance with established business rules. Then the bill is submitted for approval to CFO or some other manager who makes a decision about payment taking into account priority, amount and term.

The simplest process diagram may look like this:

» read the rest

02/09/11 | Articles | , ,     Comments: 19

The Most Valuable Player on BPM Ground

Adam Dean wrote in his recent post “BPM Skills“:

The biggest “added value” you can add to the BPM offering is BPM Skills.

I have an objection.

From my experience, the biggest issue of BPM initiatives is poor targeting. People pick up a target for the BPM project - i.e. a specific business process - on a basis of intuition or politics but not a thorough analysis.

No system is able to set the goal for itself. Hence BPM skills are not enough for BPM to be successful.

It depends on how you define what constitute BPM skills indeed so I’ll be more specific: one needs to be professional in analysing company performance, structuring enterprise value chains, identifying critical business issues, connecting business issues to process issues to personal performance issues for a BPM project to be successful. I guess these competencies are beyond BPM for most people.

As I already said here on the blog, this is a kind no-man’s zone between business consulting and process consulting: business consultants know what should be done eventually but have vague understanding of how strategic goals can be achieved with the help of BPM methodology and technology. BPM folks either expect that a customer will pick the target process or assist him with vague recommendations like “pick up a low hanging fruit”.

But look: how many of candidate processes will affect the company’s bottomline figures? The Theory of Constraints (ToC) postulates that there are generally a small amount of (or just one) bottlenecks within a system. Therefore a BPM project results would be visible at the company level only if it was targeted at one of these few (or even a single one) bottleneck processes. Otherwise the BPM project would be successful only locally: it’d increase the productivity of a link but the value chain constrained by some other link will remain the same.

Since we came to this logical conclusion about a year ago, we developed a missing methodology for systematic identifying the right target for a BPM project based on the ideas of Gary Rummler and Eliyahu Goldratt. We use it in pre-BPM projects that give the answer to the question asked by every top manager considering a BPM initiative: “what exactly would I get from your BPM thing in terms of hard dollars”?

The methodoly doesn’t answer the question directly of course - after all, every company has its own performance gaps - but we are able to articulate in advance how and where the answer will be found. The prospective sponsors are just fine with this approach.

The most part of the job at these projects is done by the customer itself - the workgroup usually consists of 15 to 20 people from top management to key specialists. We just set the right questions and the answers are all theirs.

The great co-product of this job is the empowered team. When the complicated and important task of identifying the company’s bottlenecks is completed, they are eager to close the revealed performance gaps with the help of BPM. It’s the best condition for a BPM project one could imagine.

01/28/11 | Notes |     Comments: 7

ACM: Paradigm Or Feature?

Adaptive Case Management was one of the most discussed BPM topics in 2010. It transformed from fuzzy marketing noise into a more or less consistent concept over the past year.

Why “more or less”? Because even the authors of “Mastering the Unpredictable” - probably the most authoritative book on ACM to date - say in the preface that there is no consensus among them, so the book in essence is a collection of articles. Nevertheless there are more similarities than differences in their positions, hence the consistent concept.

Positive Side of ACM

ACM extends the idea of process management into areas that were tough so far: processes a) rapidly changing and b) essentially unpredictable.

Re-engineering once emerged as the idea of managing business via processes that were perceived as once yet very carefully planned procedured. Life has shown the limited applicability of this concept. It turned out that end-to-end and cross-functional business processes - that is, processes presenting the greatest value in terms of bottomline figures - are a) too complicated to program them in one iteration, and b) changing more rapidly than we are able to analyze them by traditional methods.

As soon as these concerns where perceived BPM appeared in its current form - as a discipline that combines managing business by processes and managing processes themselves i.e. their execution, analysis and optimization within continuous loop. Executable process diagrams improved communications between business and IT opening the way to deal with complex processes; rapid prototyping via BPMS and agile project implementation allowed rapid business processes changes.

Exactly how rapid? We have reached a three-week cycle in our projects which I believe is a good result taking into account the inevitable bureaucracy of release management, testing and production system upgrade control.

But what if this is not enough - if changes to the process should be introduced even faster? Or more likely if a process is so compicated that we repeatedly find that some transition or activity is missing in the diagram?

And here is the final argument in favor of ACM: what if the process is fundamentally unpredictable? Examples: a court case, the history of a medical treatment or technical support dealing with user’s issue. You can’t plan activities here because tomorrow will bring new actions taken by the opposing party at trial or patient’s new test results. It’s even hard to call it a process because process implies repetition, yet no two instances of these “processes” are identical.

These are standard ACM examples. I would also add the no man’s zone between processes and projects e.g. construction work. In a sense, construction of a house is a process because it consists of simiar activities. But at the same time, no construction work goes without troubles and complications which make each object a unique project.

Or let’s consider a marketing event: there is a template indeed but each particular event is peculiar. Same for new product development… there are many such half-projects/half-processes in every company.

What Shall We Do With Unpredictable Processes

If you can’t foresee then act according to the situation. We must give user the ability to plan further actions for himself, his colleagues and subordinates “on the fly”, as the case unfolds.

Luckily the user in such processes is not an ordinary homo sapience but so called knowledge worker. A doctor (recalling House M.D.), support engineer or construction manager - any of them could write on a business card:

John Smith

Resolve issues.

These are people trained to solve problems and paid for this job.

How the problem of volatile and unpredictable processes was approached so far:

1. By editing process scheme by business users on the fly.

For example Fujitsu Interstage BPM lets authorized users edit the schema of a particular process instance right in a browser. And even more: the modified scheme can be later converted into a new version of the process template. But it turned out to be too complicated - users simply don’t use this functionalty. Keith Swenson says on the matter: “Creating an activity at runtime needs to be as easy as sending email message; otherwise, the knowledge worker will send email instead.”

2. By ignoring the problem: there is software automating case work but it doesn’t operate in terms of processes.

For example you can create a folder in the ECM for each case and upload documents, attach tasks and notes. Or you can treat a case as a project and draw a Gantt chart. But both options won’t give process monitoring and analysis and most importantly - the knowledge of what tasks a particular type of cases consists of will not be accumulated and reused.

ACM inherits BPMS approach to process execution, monitoring and analysis but replaces “hard” templates with “soft”: ACM template doesn’t dictate what should be done but rather prompts what the user could do in current situation. The user may reject these clues and pave his own way. He may use more than one template or instantiate a case from scratch and not use any template.

Graphical process diagram is thrown away and replaced by a tasks list (tasks may be nested). Apart from the tasks list a template defines the data structure: entities, attributes, relationships.

There is no more business analysts and business users: it’s assumed that users create templates themselves and organize them into a library, thus making available to others.

So far so good but I have some concerns about this proposal.

Concern 1: Technology Instead of Methodology?

ACM advocates (or maybe only the most radical only) seem to believe that more advanced technology is all what organizations need to become more efficient: BPMS is outdated but ACM is the solution.

I don’t know… maybe I’m too unlucky but the business people that I meet are indifferent to technology, at best. Techies are speaking about how a new technology works but business people are only interested in what they will get. Productivity increase and processes transparency sound good but how will they affect the bottomline figures?

The bottomline result of a BPM initiative depends on two things: 1) quality of proposed solutions - how efficient is it in managing and optimizing processes and 2) what process was selected for the initiative. Typically, an organization has a small number of processes or just one process which is a bottleneck. Improvements in this process directly affect the company totals while any other improvements affect them at a minimal degree.

If your BPM consultant is professional enough then the first component is secured. But the problem is that the second component of success is beyond his responsibility.

And as a matter of fact, it’s beyond anyone’s responsibility. Business consultants generally know what to do (which processes to deal with) but they have little knowledge of the process technology. BPM consultants, by contrast, know how to do, but don’t have a clear vision of what to do. No system (BPM system is no exception) can establish the goals for itself - it can only be done at super-system level.

After recognizing that there is a competence gap some time ago, we developed the value chain analysis and productivity gap identefication methods to be applied before the BPM project starts. The project takes about a month and results in clear vision of where the BPM initiative should be targeted for best results and what these results shall be.

Getting back to the ACM: it seems that it discards process methodology along with process diagrams. Process analysis skills and process professionals are not needed any more because knowledge workers are so knowledgeable that they know how to do the job better than anyone else.

Maybe they do but let me ask: better for whom - for the company or for themselves?

I am afraid that orientation to the customer doesn’t come automatically. I’m afraid that knowledge workers as well as clerks engaged in routine work tend to create comfort zone for themselves rather than clients. I believe there is still much to be done in process methodology and promising new ideas - e.g. the Outside-In approach - have yet to become common practice.

ACM proponents criticize the “process bureaucracy” - business processes change approvals and other regulations. Bureaucracy is certainly bad… but it’s even worse without it. I don’t believe in empowerment as much as ACM people do and I don’t trust that knowledge workers will self-organize and the library of case templates and business rules will emerge magically. In my opinion, this is utopia. There must be strong leadership and process professionals trained to analyze company’s activities in terms of benefit to the customer, quality and cost.

In his last interview to Gartner analysts process guru Gary Rammler criticized BPM for the lack of business context:

“I think there is only one critical condition for success that must exist - and that is the existence of a critical business issue (CBI) in the client organization. If there is no CBI (hard to believe) or management is in deep denial as to the existence of one, then serious, transforming BPM is not going to happen. Period. There may be misleading “demonstrations” and “concept tests,” but nothing of substance will happen. How can it? Serious BPM costs money, takes time, and can upset a lot of apple carts, and you can’t do that without an equally serious business case. I guess you could argue that a second condition - or factor - is that the internal BPM practitioner is about 70% a smart business person and 30% a BPM expert. Because the key to their success is going to be finding the critical business issue, understanding how BPM can address it, and then convincing top management to make the investment. I guess those are the two conditions: an opportunity and somebody capable of exploiting that opportunity.”

I’m afraid that neglect of a process methodology in ACM will result in ignoring this promising technology by business.

Concern 2: No Programmers?

ACM assumes that not only business analysts are not needed but programmers as well.

Sure it would be great. BPMS vendors try to reduce the need of programmers in business process implementation, too.

Reducing is OK, but eliminating them completely?

Simply replacing the process diagram with the task list probably isn’t enough because there still are:

1. Process architecture.

When dealing with process problem the most difficult is to figure out how much processes are there and how do they interact with each other - for an example, please refer to my “Star Wars” diagram. If you did that then the remaining job - internal process orchestration - is no difficulty. If not then whatever you do with rectangles and diamonds within the process, it won’t work well.

Cases are no exception - one have to set up the architecture first. And I don’t believe that a business user without analytical mindset and not trained in solving such problems will do the job. And without that, there will be chaos instead of case management system.

2. Data architecture.

ACM advocates stress the critical importance of data constituing the case context. Arguably, for BPMS process is primary interest and data is secondary while for ACM it’s vice versa.

I do not agree with this - in my view, the process is a combination of the model visualized in a diagram,  structured data (process table in the database) and unstructured documents (process folder in ECM) where all parts are equally important.

But anyway - they recommend first and foremost to determine the nomenclature and structure of the entities in your problem. Excuse me for asking, but who will do the job - a business user?

Once again: I don’t buy it! Data structures analysis and design has been and remains a task for trained professionals. Assign it to an amateur and you’ll get data bazaar instead of data base, for sure. Something like what they create with Excel.

3. Integration with enterprise systems.

Well, everyone seem to agree that this will require professionals.

So where did we come? To bureaucracy once again, this time the IT bureaucracy. It’s evil but inevitable eveil because the chaos is worse.

Concern 3: Two Process System?

Here is the question - how many process management systems do we need (assuming that cases are processes, too): two (BPMS and ACM) or one? And if one, how shall it be developed: by adding ACM functionality into BPMS or by solving all range of process problems with the ACM?

ACM proponents (well, at least some of them) position it as a separate system - they want to differentiate ACM from BPMS technology.

They argue that BPMS tries to “program” business but this is impossible in principle when dealing with unpredictable processes. Therefore BPMS is no good and we need a different system - ACM.

It reminds me something… got it: a new TV set commercial! “Just look at these bright colors and vivid images! Did you ever see something like this on your old TV?” - Of course I didn’t… But wait! Am I watching your commercial and see these bright colors and vivid images right on my old TV set?

Same here: of course, unpredictable processes can’t be programmed by a stupid linear workflow. ACM proposes more advanced way to program them, but still it’s programming. And who said that BPMS can execute only stupid linear worflows?

BPM allows to model much, much more than linear workflows. Citing Scott Francis -

“The BPM platforms that I’ve worked with are Turing Complete. Meaning, within the context of the BPM platform, I can “program” anything another software program can do.”

For example, one can model a state machine in BPMN which is presumably the most adequate representation of a case. Besides there are ad-hoc sub-processes that allow a user to choose which tasks to schedule for a particular process instance. The combination of a state machine and ad-hoc sub-processes serving transitions between the states produces something quite similar to the case.

Apart from that, stay away from micromanagement or unpredictability will hunt you everywhere.

Existing BPMS lack the ability to add a new task to the ad-hoc subprocess by one click (remember: it shouldn’t be more difficult than sending e-mail). But it seems to be fairly easy to implement. Not harder than BPMN transactions compensation, anyway.

And there is also “delegation” and “notes” functionality in the BPMS which help making a process less rigid, too.

Some ACM supporters believe that existing BPMS with their process diagrams are outdated - arguably, if ACM can manage unpredictable process then it’ll be able to cope with traditional processes for sure. But the majority seems to recognize that both management of traditional and unpredictable processes are vital.

Besides, there are processes that can be partially modelled but some other parts should be managed as cases. For example, a medical treatment is a typical case but specific test is a process that can be well-defined. This is the argument for a single system able to manage traditional predictable processes, cases and arbitrary combinations of both. And chances are that this system will be developed on the basis of existing BPMS.

Such ACM-enabled BPMS would provide some additional bonuses not mentioned above:

Bonus 1: BPM During All Stages of the Organization Lifecycle

Applicability of BPM is limited today even in regard to predictable processes: small companies simply can’t afford a business analyst and consequently BPM. This mines a future problem: with the company growth the process problems will pile up until falling down one day.

ACM-enabled BPMS would be a great solution to the problem: a small company or startup may work with cases only initially and then, as it grows, the organization structure develops and more clerks coming, a company will be able to transform seamlessly the patterns accumulated in cases into formally determined process diagram, optionally preserving the desired amount of unpredictability.

For the BPMS vendors it’s an opportunity to enter the market of small and medium-sized companies by offering a product falling into office automation category, not a heavy-weight enterprise platform as today. Support of cloud computing would additionally contributed to the success indeed.

Bonus 2: Artificial Intelligence

I do not trust that business users are willing and able to organize a library of template cases. I believe it’ll end with something similar to a bunch of Excel files. How many people are using templates in Microsoft Word, by the way? It’s a nice and usefull thing yet nobody cares.

More promising for me is the idea of implementing elements of artificial intelligence in ACM:

  • To start small, a simple advisor can be implemented like the one at online bookstores saying “people buying this book also bought…”.
  • More sophisticated implementation may take case data into account. For example a tech support case may suggest one tasks set or another depending on the service level of the current customer.

In essence, the system treats the whole set of case instances of a certain type as a mega-template.

Automatic analysis of the mega-template can be supplemented with manual ratings so that the user would receive not just a plain list of tasks that were performed at the similar situation but the list marked with icons saying e.g. which tasks are recommended.

Conclusion: Thank you!

ACM enthusiasts are doing the great job: they investigate the possibility of expanding the process management into previously inaccessible areas. Sincere thans for this!

Marketing considerations force them to differentiate from “close relatives” BPMS and ECM and to position ACM as an independent class of software. It seems to me that this is irrational both from technology and methodology perspective and it’s unlikely to succeed.

There was a similar story in IT history. Once relational databases have become mainstream a number of works appeared, calling further: post-relational database, semantic databases, non-first-normal-form databases, XML databases… They contained generally fair criticisms of certain aspects of relational database technology. But relational databases proved to have solid potential for evolution: missing functionalities were implemented one way or another, thereby putting alternatives into niche areas.

So here is my prediction for ACM: it won’t become a new paradigm but a new BPM feature that will expands its applicability significantly.

01/21/11 | Articles | ,     Comments: 31

BPMN In Outer Space

My friend deals with telecom processes. There is a specificity that I covered before: a lot of coordination between systems and relatively little human participation.

Anyway, he was interested in BPMN and wanted to assess it with a test case. Here is the case as I’ve got it; if you found it incomplete or contradictory, that’s fine and normal for a real-world cases.

A case based on the Star Wars: two space cruisers are on alert to repel a possible aliens attack.

a) Ship paths are plotted centrally and synchronized on the basis of data obtained in real time, aiming at maximum security and full dangerous zones coverage.

b) The appearance of an alien object on the radar is recorded and replicated to the mate ship’s tracking system - this way each target receives its own individual id. When it’s lost by both ships the target obtains lost status - there is no means to differentiate a new target from a target that once has been tracked and then lost.

c) The system that assigns targets to one cruiser or another is centralized and works on the basis of priorities (no matter which ones). The system may transfer a target from one cruiser to another if priorities have changed - that is, each target is marked with 1 or 2, indicating to whom it is assigned at any given time.

d) A command to open fire is displayed on a touch screen display and the operator makes a decision by pressing the button. Even at this moment the system may reassign the target to another cruiser.

e) If the target is hit then the workflow ends, otherwise the failed attempt is logged and the process continues. It’s assumed for simplicity that the laser weapon is used and the outcome of a shot is determine promptly enough.

It’s assumed that the whole process runs continuously.

Rather unusual domain for BPMN, right? So the questions arise:

  • Can the task be solved with a help of BPMN?
  • Is it worth it?
  • Well, the solution itself, if any.

Hope you found the case interesting; I was intrigued.

My version of the BPMN diagram (click to open in a new window):

» read the rest

12/29/10 | Articles |     Comments: 8

Modeling Human Routing in BPMN

Unfortunately, the question “how to model human decisions in BPMN” isn’t frequently asked.

“Unfortunately” because the intuitive answer is wrong. This is not a fork but a parallel execution:

After exiting the “Approve Claim” task the process will continue in parallel on the outgoing flows whatever is written on them.

Valid BPMN diagram looks like this:

It’s implied that the process has a boolean attribute “Approved”. User sets this attribute at the “Approve Claim” task, the gateway checks its value and the process continues in one of the flows.

As you can see, BPMN authors didn’t provide a special construct for human decisions but implemented them rather artificially: a special attribute that must be set by a human and checked in the gateway immediately after.

The user interface for the task where the decision is made may look like this:

When “Done” button form is pressed the task is completed.

I agree with Keith Swenson that BPMN misses explicit support of human routings.

Firstly, human-based and automatic routings look alike at a diagram. Yet this is an important aspect of the process.

If it was my decision I’d introduce explicit support of human routing into BPMN. Since first diagram above is actually more intuitive than valid BPMN, I’d leverage on it:

The existing flow types - Control Flow, Conditional Flow and Uncontrolled Flow - are extended by Human Controlled Flow here, marked with a double dash.

Another issue are screen forms like the one above which provoke user mistakes: it’s tempting to press “Done” and get rid of the task without paying attention to the attributes.

If a decision is requested from a human then the form should look like this:

The buttons could be generated automatically from the process diagram above.

Yet it’s possible to utilize this technique for standard BPMN, too:

“Done” button is replaced by “Approve” and “Deny” here, each of them being bound to two actions: set the attribute value and complete the task.

Now I’m going to use this occasion to appeal to BPMS vendors: please give the opportunity to create more than one button completing the task and bind them to attributes. If you didn’t do it yet, of course.

12/27/10 | Articles | , , ,     Comments: 12

Vulgar Interpretation of Cross-Functional Business Processes

Cross-functional is a process involving several upper-level departments (or “functions”). From a process methodology perspective a BPM initiative should ultimately aim on such processes because handoffs between departments is usually the biggest source of problems and hence the greatest potential for improvement. Departmens use to rate their internal targets above the targets of the business as a whole as soon as hierarchical organizations reach certain size limit.

This idea ain’t new: “breaking down the walls between departments” is the re-engineering call of the early 90’s. An implementation proposed at that time - single radical transformation - wasn’t quite successful but it’s another story. Modern BPM got new ideas about how to reach it but the goal remains the same.

The «functional silo» metaphor is commonly used to illustrate the cross-functional problems. The analogy is following: after a hay silo is mounted one can only get a small portion of that wealth - the upper layer. Likewise, resources, information, knowledge and procedures in hierarchical companies are buried in the functional units - much of these asstes are not available to consumers from other areas and does not contribute effectively to the goals of the company as a whole.

A functional unit tends to come to the wrong view of what is “our business” and what’s not. For example it’s natural for accounting/finance to assume that accounting and reporting is their main business while invoicing is really someone else’s (e.g. sales) and for accounting core activities it’s a nuisance. Yet from a business standpoint the opposite is true: billing is part of the “Order to Cash” business process, most important in terms of value for the customer while accounting and reporting are auxiliary activities. We can’t avoid it because of the governement requirements and our own planning needs yet it does not create value and hence its cost should be minimized.

Accounting is just one example. New product development, building a commercial proposal, customer order fulfillment - there are lot of things critical to the client and hence for the business that can’t be assigned to a single business unit.

Cross-functional business processes are usually illustrated like this:

Fig. 1. Functions and cross-functional processes.

However the picture above produces a badly wrong idea of how to resolve issues located at the borders between departments. It leads to a vulgar idea of the business process as a simple sequence of steps: “do this - do that - proceed further - then stop.” Businesses does not work this way.

Let’s consider the “Order to Cash” process as an example. In case of production to order it’d contain the following steps: accept order - produce - deliver - obtain payment.

  1. Process begins when sales department receives a customer order.
  2. After processing the order sales transfers it to production.
  3. Production starts to fulfill the order.
  4. Manufactured goods are delivered to the customer.
  5. Finance department obtains the payment.

Fig. 2. «Order to Cash» cross-functional process, workflow version.

Imagine a manufacturing workshop being empty, dark and silent. Now the client’s order comes, the workshop manager switches the power on and everything starts running. Nosense? Sure. But the naive diagram above implies just this!

Now how it really works:

  1. Sales places customer’s order into production queue.
  2. Production planning starts periodically (e.g. daily), scans the orders queue and schedules production.
  3. Orders are processed one by one in accordance with the schedule and after each order is fulfilled the corresponding client order process is notified that the goods are ready for delivery.

Or graphically:

Fig. 3. «Order to Cash» cross-functional process, BPM version.

We’ve got two processes here communicating via data (the orders database) and messages (order execution notice). It’s fundamentally impossible to implement it within a single pool (single process) because the “Purchase Order” and “Production” have different triggers: receipt of an order from a client and timer, respectively.

Same story with delivery and payment: they can hardly be implemented within “Purchase Order” pool. So technically there would be even more than two processes (pools).

Workflow, BPM, and multithreaded programming

As the example above shows, cross-functional processes can’t be implemented with a simple workflow: the boundaries between busines units can’t be ignored because they different units operate at different rhythms and utilize different routines. These boundaries can’t be eliminated simply by depicting the flow of work from one unit to another as shown in Fig. 2.

Technically, the cross-functional processes are implemented by inter-process patterns one of which is shown in Fig. 3. Getting back to the methodology, the picture shown in Fig. 1 should be drawn like this:

Fig. 4. Cross-functional process as a coordinator of functions.

The workflow only covers work within a single function. Once we go beyond it i.e once we aim at cross-functional processes and deal with handoffs between units, the interaction between workflows must be utilized.

Switching from workflow to inter-process communication means switching from single-threaded to multi-threaded programming.

Unfortunately in many cases it’s a tough barrier.

  • Some people doesn’t see this barrier. They hit it but doesn’t realize what’s the problem really.
  • Others instinctively bypass the barrier by implementing BPM pilot projects aiming at processes like “Vacation Request”. A pilot like this is going to be successful but does it have any value for business?

I believe this is the sources of most of the disappointment in BPM: those who narrow it down to the workflow end up with predictable failure.

Technically, multithreading is what distinguishes BPM from workflow. Remove the interaction between asynchronously executable processes via data, messages and signals and what you’ll get would be “workflow on steroids”, not BPM.

Unfortunately, this is the case with many software products marketed aggressively as BPMS. For me, the main BPMS criterion is the support of BPMN-style messages. There are other criteria indeed but this is the most useful at the moment. Everything else - graphical modeling, workflow engine, web portal, monitoring - is implemented ususally, better or worse, but many products totally miss inter-process communication. Most likely not because it’s that difficult but rather because no one has explained how important it is.

Yet saing “get used to the multithreaded programming of processes” is easier than following the advice. Complains about BPMN complexity are common: “who invented these damned 50 different BPMN events!”.

The name of complexity is business, not BPMN!

Whoever promises a simple solution to business issues, whether it’s BPM or something else - do not believe it. Business is a human competition by nature: smart people are competing for living better than others. Therefore business has been and will remain a complex matter.

The complexity of BPMN isn’t excessive, it’s adequate to the complexity of the business. Students of my BPMN training have no question about why there are so many events: no one is excessive. And by the way, note that BPMN 2.0 is practically no different from 1.x at workflow part - the standard evolves in supporting more sophisticated multithreaded programming: choreography, conversation.

The business can only be programmed as a multithreaded system.

BPM and the ACM

Here I deliberately step on the slippery ground because ACM (Advanced/Adaptive Case Management) fans may respond: “A-ha! We have always said that business can not be programmed!”

Maybe it can, maybe cannot … most likely, in some cases it’s possible but not in others.

They say the percentage of knowledge work vs. routine work is constantly growing. But exactly where is it growing? Mostly at US companies that offshore routine activities to Asia. A predictable observation for analysts located in US. But as soon as the amount of knowledge work grows at one place, the amount of routine work grows in another. And managing routine procedures running on the other side of the globe is the best task for BPM that one can imagine.

I would like to ask ACM enthuziasts that cricize BPM: are you sure you’re criticizing BPM and not wokflow? Aren’t the object of your criticism BPM projects either trying to solve business problems with workflow or having no business agenda at all?

If this is the case then the failure is quite predictable but it doesn’t mean that BPM points the wrong way, it just means the need to more thorough work.

ACM is a good thing indeed but only as an extension to BPM, not as a replacement. Besides ACM today is less mature than the BPM so those who make mistakes with BPM are likely to make even worse mistakes with ACM.

To be continued…

…with the major patterns of interprocess communication and a word of warining about the opposite extreme - excessive usage of interprocess communications. Stay tuned.

12/22/10 | Articles | , , ,     Comments: 28

(Русский) Несколько образчиков годного BPMN

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

12/14/10 | News | ,     Comments: closed

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