Blame the Computer: A Business Process Modeling Anti-pattern

Whenever you model a business process, it is inevitable that, sooner or later, you will come to an activity that is entirely automated.  As time goes on, more and more of the activities slip quietly into the technology.  However, I'm noticing a troubling practice in how these automated activities appear on some business process models.  I'd like to weigh in on what I see as an anti-pattern in the process design space.  I'll use a scenario to illustrate.

Scenario

In 1975, when Fabrikam started selling specialized parts, each special order was hand-checked.  The order was compared with the pricing agreement that the customer signed, and a special price, based on their agreement, was calculated.  Gradually, as time went on, this activity ('calculate special order price') was automated.

Here is an image of the process as it stood in 1975 (click image to enlarge):

Back in those days, Fabrikam used filing cabinets, so the purchase order was added to a manilla folder in a file cabinet.  The folder had the words "Outstanding orders" on it.  It was, therefore, the "Outstanding Orders" file. 

Fast forward to today.  Fabrikam enters their orders into an order management system.  (in fact, a large number of orders are entered directly by the customers themselves, using the web, but that flow is not illustrated here... this is just for people who insist on mailing in the purchase orders).

One of the key activities is now completely automated. 

The problem

I have seen two different ways to model the notion of an 'automated activity.'  I believe that one of them is better than the other.  Here are the two alternatives.

Alternative one: systems get their own process activities... (once again, click the image to enlarge).

Alternative two: the automated activity stays where it is, and a system FEATURE or system REQUIREMENT is placed in a container that represents the technology.

So which one is better?  Which one should we aim for? 

Who is responsible?

The goal of a model is to communicate.  Let's start there, and let's look at the language we are communicating with: Business Process Modeling Notation.

In BPMN, we have swimlanes that illustrate that a team or department or organization are responsible for performing the activities within it.  Summary: Swimlane = Responsibility for Performance.

This is pretty important.  A swimlane is more than a picture of who "does" what.  It is a picture of who is "responsible" for performing an activity. 

When we automated the work of 'calculating prices on special orders,' did the responsibility actually change?  It is clear that technology is contributing to the system, but are different people responsible?  If power fails, will the IT department calculate the prices for special orders, or will the Order Accounting Department do it?

Clearly, it's not IT. 

And this is why I believe that the second image (Alternative 2) is correct.  I take the view that IT, by automating a process step, does not relieve the original business department of the responsibility for accomplishing that activity.  IT has simply provided a fast and efficient way for the business to do the job.  The business team, in this case, the "Order Accounting Department" remains responsible for performing the activity of "Determine Special Pricing".

Why should anyone care?

Is this an argument about pictures?  I don't think so. 

1. First off, by leaving the activity where it belongs, in the department that is responsible for it, we are clear about the ownership of that activity.  We answer the questions: who defines requirements? Who is on the hook for exception conditions? Who picks up the slack if the system is down for an extended period of time? Who helps create failover and business continuity plans in the event of a natural disaster? 
     
2. Secondly, by leaving the activity where it belongs, we let the responsibility for process improvement remain with the business.  We do not take away that responsibility by saying "IT handles automated processes, so inefficiencies are no longer a business problem."  That would be borderline insanity. 
     
3. Lastly, I've come upon a number of cases where, through the long-standing use of automation, the business has lost their institutional memory.  They do not know how to do their business without the computer.  This is a terrible situation, and one that cannot be rectified easily.  By modeling all of the activities involved in a business process, and tying each activity to a feature, we help document what is actually going on.  This is critical information if we ever expect to replace the computer system (a near certainty) or if we ever want the business to innovate (necessary for long term survival).

In conclusion: We (in IT) do a disservice to our business customers by hiding the automated activities in a separate 'system' process swimlane.  Responsibility does NOT shift with automation, nor should it.  That includes the responsibility for knowing, the responsibility for innovating, and the responsibility for handling the process in a crisis. 

One thing that IT can never, should never, do... take responsibility for running the business.

Comments

• Anonymous
  June 28, 2008
  The comment has been removed

• Anonymous
  June 28, 2008
  Hi JJ, For a moment, it looked like you were going to say nice things to me... and then you added in this statement, "The problem that you can't seem to grasp is" Why do you insist on responding to my blog if your responses include insults?  There is no problem that I am unable to grasp.   The programming model is always open to innovation.  Feel free to demonstrate the power of that innovation, JJ.  Once you demonstrate value, everyone will join you.  Until you do, you are sharing opinions... and we ALL have opinions.  WSPER is a nice try.  Get it adopted.  I'll come around if there is value there. You are suffering from the "golden hammer" pattern, my friend.  You have a solution that will fix all problems... a golden hammer. But your solution will do nothing for business process engineering.  There will still need to be BPM, even if you get the world to change the programming model.  Because, in my world, people matter more than computers.  BPM is about PEOPLE. People need to be trained... they need to have the correct tools, and their organizations must have policies and practices that favor positive results.   People count.  So does BPM.  The programming model will not fix that. Lastly, you suggest the following "Systems should be designed based on the activities that can be performed from any given business object state" What are those activities?  Where do they come from?  I'll answer: from the BUSINESS PROCESS.  Until a business understands their business process, and agrees on the opimal approach to it, the intended activities cannot be developed... and your precious programming model will deliver no value. Trust me on this, JJ.  Your model, which is an innovation over and above SOA, cannot succeed without people who understand the business processes.  SOA and BPM are joined at the hip.  In the final count, one will not succeed without the other.

• Anonymous
  June 28, 2008
  Actually, I believe that responsibility lies with multiple departments / people not one department. For example, the responsibility of the database going down because of power failure etc should go only to a specific group (DBAs in this case). While some other issue with data should probably go to the Accounting department. It is simplistic to suggest that only one department/group should be responsible for an activity.

• Anonymous
  June 28, 2008
  Hello Syed, Responsibility for maintaining the IT infrastructure remains with IT, but the responsibility for actually pricing a special order remains with the order accounting department.  Just because we automated that function, that does not mean that IT is EVER responsible for performing it.   IT is responsible for computers and databases.  Business is responsible for business functions. Is that more clear? --- N

• Anonymous
  June 29, 2008
  The comment has been removed

• Anonymous
  June 29, 2008
  The comment has been removed

• Anonymous
  June 30, 2008
  Well said, Bill.

• Anonymous
  July 05, 2008
  The comment has been removed

• Anonymous
  July 06, 2008
  In a prior post, I described a process modeling antipattern which I called " Blame the Computer

• Anonymous
  July 06, 2008
  The comment has been removed

• Anonymous
  July 06, 2008
  Nick - good point made. There is an additional concept known as swimpool area - it contains multiple swinlanes. The swimpool gives the name of the department normally and relating to your example - it can be accounts department and the swimlanes in that can be that of accountant, clerk and an IT System. This would solve the problem we are talking about.

• Anonymous
  July 07, 2008
  Hi Ramesh, The problem goes MUCH deeper than the use of swimpool areas.  See my recent post on Process and IT Budget.   It's a complex problem, but it sits at the core of why this pattern is so bad... activities with no owners = baaaaad. --- N

• Anonymous
  July 09, 2008
  The comment has been removed