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.