Preventing Ownerless Activities -- the "Blame the Computer" process modeling antipattern - part 2

In a prior post, I described a process modeling antipattern which I called "Blame the Computer."  The feedback helped me to realize that there's a deeper problem that we need to consider: alignment of ownership between process and IT.

Ownership of a process

We all do this.  We say things that are true at one level of abstraction, but counterproductive or simply not true at another.  One good example: "the business owns business process."  Obviously true, right?  Not so fast.

Let's look at a fictitious finance department for a $1B public company with Maria at the head, and Thomas in charge of Credit and Collections.  Staff members report to each of the team managers (not illustrated). 

Under Thomas, there are some interesting processes for handling the granting of credit, and he wants to optimize those processes because some customers have complained about long delays.

Who owns the processes for "granting credit?"  Thomas, or Maria? 

Let's ask another question: who owns the IT budget approval process?  If Thomas has his own IT budget approval authority, then I would say that Thomas owns the business processes for his team. 

On the other hand, if Maria owns budget authority for the finance team (as is typical in most companies), then I would say that Maria owns the business processes, not Thomas. 

So the answer is nuanced.  Yes, the business owns process, but if one person owns the IT budget, and another person owns the business processes, then we run some fairly sizable risks. 

The activities that fall into the 'white space'

One major source of inefficiency in business occurs when we take the responsibility for cost away from the person or team that most directly drives that cost.  Let's say that Thomas, with Maria's consent, sets up an expensive IT requirement.  Doing so looks good in the short term, but increases the cost of data center operations dramatically.

Where does that budget impact occur? 

In the worst of all worlds, IT continuity is paid for by a separate line item in the IT budget, and neither Maria nor Thomas see it.  If they don't see the cost, they can't put pressure on it, and IT can't justify a major (and costly) innovation designed to reduce it.  Basically, the business will do something quick-and-dirty, for short term gain, and live with it forever.  Sound familiar?  If so, this problem is at work in your company.

The average (bad) situation uses the antipattern I described in a prior post (See Blame the Computer).  Maria owns both the overall finance budget, and the finance department's share of the IT budget, but Thomas owns the business processes for credit and collections.  To complete the scenario: the Business Process Models reinforce the mistaken belief that some activites belong within the swimlane of a system, and not a business team.

The models look like this (click image to enlarge):

So, when Maria is considering the budget requests for her team, who does she turn to?  Her staff, of course.  Their budgets roll up to hers.  Their work (their swimlanes) are her responsibility.  She looks to Thomas, Savita, Brock and Juan.

And the activities that are listed in the "System" swimlanes do not belong to her staff.  They belong to systems.  They have no owner, no defender.  These activities are in the "white space."

The activities inside a swimlane are defended, sometimes passionately, by Maria's staff, but not the activities in the swimlanes marked "IT System X."  Yet, the entire process model, with all of the activities, rolls up to Maria.  These activities are "owned" in name only.  It is not enough to say "the business owns the process." 

A cure worse than the disease: Drag in IT

So who will own these 'orphan activities?'  One trick: get IT in the room.  Drag in a 'solution manager' or a 'product owner' or even an 'architect' from the IT staff and tell them to represent the activities that have been delegated to systems. 

But these activities, by themselves, do not solve business problems.  Business systems automate little bits of processes that, by themselves, do nothing.  Systems have no value without the business processes that require them.  

So when a developer or an architect comes to a solution manager and says "invest here," the answer is always "put that in business terms" or "show me the value."  There isn't any, because the activities don't "belong" to one of Maria's staff anymore.  There is no value in improving a tiny bit of a process by itself. 

Value to the business comes when the business is invested in the activities, and that happens when those activities are still "owned" by the business.   No activities in the cracks. 

Codifying a mistake

The business process folks who would prefer to place activities in 'system' swimlanes are not trying to screw things up.  They are communicating, and they are saying the things that the business expects to hear.  They are mirrors, reflecting the prejudices of the business people who have let some activities slip away into IT.  Business people are not trying to screw things up either, but no business person will ever be rewarded for taking activities INTO their swimlane without an increase in budget.  Even if it belongs there.

But the moment a model appears that show 'activities' in the 'system' swimlane, those errors in judgement gain credibility.  The dysfunction of the 'Blame the Computer' antipattern is propagated with the authority that these models bestow. 

A BPM model created in this way creates a false accuracy.  A BPM model is formal.  Modelers use specific rules, and many will argue passionately about the style and use of particular icons.  The models "look formal" and the business folks who see the models place a higher confidence on them than on their own 'napkin' drawings.

And when those modelers, in their attempt to gain acceptance, innocently or not, place an activity in the "system" swimlane, the myth goes on. 

Counteracting the pattern

As BPM modelers, we have a higher responsibility than simply 'reflect the business.'  A modeler's responsibility is to help document the business, as part of a larger picture: to improve the business.  That means more than just creating a useful model. 

That means understanding the overall implications of the prejudices of the business and counteracting them.  That means understanding the dysfunction that occurs when Maria 'owns' an activity that no one her staff is responsible for improving.  And refusing to give in to that prejudice.

It is easy to communicate with the business if I say what they want to hear. 

It is better to communicate with the business when I say what they need to hear. 

Placing all of the activities within the scope of a team, and not in the scope of a system, is the first step towards health.  Being willing to ask about the efficiency and sequence of those activities is the next step.  

This is what health looks like (click image to enlarge):

Because now, the business will want to change the order of the activities, and improve them, even though some are formalized inside a system.  IT folks have probably been dying to do just that, for ages.  Now there is context for the discussion.

This brings the IT and Business folks together, because the business folks can see the IT folks as wanting the same things: to improve the activities of the business, even when some of those activities happen to be embedded in code.

It ends with coming together.  It starts with saying the right thing.