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.
- 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?
- 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.
- 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.
Nick:
Never, ever, BPMN was intended to be used that way. I don’t know how Microsoft manages its processes, but in most mature organizations processes are simply and only modeled from the "people’s view", i.e. it tells people what to do. There is never a system’s view either baked in or inferred from the people’s view.
As you rightfully say, this is a "business continuity" problem. If something bad happens the business has to go on and a user would know what to do, capture, communicate and act.
Now it is very unlikely complex rule sets (pricing engines,…) could be manually run in a business continuity event. Another set of rules will have to be applied.
The problem that you can’t seem to grasp is that there is no formalism known to man that would let you transparently express business logic spread over humans and systems. It’s like saying I could generate "Word" from it’s user manual. Have you tried that? Has anyone ever attempted this? Strangely enough this is what people are trying to do with BPM.
One of the key problems (as I told you many times) is the programming model. How can you ever think you would succeed in achieving some of the things you are talking about in an MVC world where the programming model has no understanding of activity boundaries? When a developer writes a line of code, he has in general just a very vague idea about what the user would be doing or what activity will be performed.
You seem to constantly think that you will fix IT by a better, more refined methodology. You even went as far as asking wsper "to go away", when indeed, this is the only viable way forward (not wsper, but the underlying service oriented, process centric, model driven programming model behind concepts such as wsper).
Now, the other issue is of course to think that there is something called "The" process for doing something. How many times have you heard users complaining about the systems preventing them to do something that would be perfectly logical to do (specially during exception management).
In reality, what you call "the" process, is a "common" way of doing something. It does not have to always be that way. The tragic mistake system designer make is that they are trying to map "the" process and by default eliminate large amounts of valid paths that at some point a user will want to take to solve a customer problem.
This is why business object lifecycles are so critical to this programming model. Systems should be designed based on the activities that can be performed from any given business object state. A pricing activity could then be automated or not, from the lifecycle perspective, it does not matter.
As long as, as an industry, we will perpetuate a corny programming model, deeply and totally misaligned with the way information systems operate and the tasks that are performed to change their state, IT will deliver less and less value to the business. It is not a question of boxes, arrows or ownership.
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.
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.
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
Upon rereading JJ’s criticism, it occurs to me that he may be under the mistaken impression that we are attempting to use a process engine to execute business process automatically.
Nothing could be further from the truth. It’s a dumb idea. Yes, I’m aware of the work at QIT to map BPMN and BPEL. Yes, I’m aware of all the people and vendors hyping the idea that we could, should, or would ever want to, create some kind of automatic path so that a mapped business process auto-magically becomes software. I’m aware of the concept and have, internally, discarded it outright.
Just like JJ, I have been involved in the development of process engines. I, too, had been one of the folks calling for process automation as some kind of holy grail. But I don’t believe that is a useful endeavor any more.
My approach these days is radically different. The BPM models you see are BPMN only, are stored in a repository for other business teams to see, learn from, and perhaps use, but not to automate.
I work with teams that model human behavior, not for the sake of automation, but for the sake of improving customer satisfaction and communicating across diverse teams of people.
So, JJ, and all of the other folks in the BPM community who may chance to read this blog, please consider that I am not attempting to automate these processes. I’m using them to describe requirements. I’ll post in another blog what I mean.
I hope that clears things up.
— Nick
I agree that it is vitally important to ensure that you leave the business logic with the department that has responsibility for defining and understanding it rather than with IT.
When it comes to modelling your business services that will be the basis for a common understanding between your business architecture and information systems architecture you will want to ensure that the logic is implemented in the appropriate service.
In order to guarantee high cohesion and loose coupling between services, we must have our related logic together in the same business service.
A business service contains not only IT systems, but people and process as well. Thus business logic pertaining to a given business area must be defined in the same place whether it be automated or not.
Automating a task creates a dependency to an IT system – it does not restructure the process model.
Well said, Bill.
As a process practitioner myself, I too often find myself looking for a better way to model a "Business" process. However, there’s a fundamental point in your argument Nick that I don’t fully agree with.
Just because an Activity is in a System swimlane does not mean that IT owns the activity. I agree with all your points about BPMN is for communication and understanding; Swimlanes are for responsibility and ownership, etc.; but the key point is that the entire process is own by the Business, not just a swimlane.
Swimlanes are also very useful in depicting boundaries of roles/groups. One can quickly denote who’s doing what. If a Get Pricing Activity is in a user swimlane, does the reader think a human is involved in that step, or are they supposed to understand the technologists rendering of a dotted line dependency to a "system box". And does that dependency mean the user is interacting with that system or does it mean that system is actually performing that activity with no human interaction? These complexities in the model begin to reduce the communication value I think.
Again, I totally agree with your opinion that the Business must continue to own the process and the process improvement efforts, but I don’t think moving a box into a System swimlane changes that responsibility. It should be the case that IT does not really own any system (outside of infrastructure and enablement technologies of course), rather, the business commissions IT to produce solutions which often involves technology and the construction of systems. But it’s always the business that owns (and should pay for) those systems.
Oh, and one other note. I think it’s totally possible to take a BPMN model and actually turn that into an executable, run-time business process that renders high value to the business and the enterprise as a whole….. but that’s another blog.
In a prior post, I described a process modeling antipattern which I called " Blame the Computer
Exactly: Someone THINKS that it is possible to take a BPMN model and turn that into an executable the renders high value to the business. But it is no more than a thought. There is NO PROOF. I have been bugging experts, analysts, universities and whoever I can find to come up with the empirical evidence that BPM is actually good for a business. It does not exist!
I fully go with Nick Malik. Business is about people. Automation is not about people it is about cost. I see a lot of people pulling the quality card out when discussing and they completely forget that normal business activity is not like manufacturing where you need to nail down the physics. Yes, on the factory floor automation and robotics have dramatically increased quality – along with miniaturisation, but that is not transportable to services. People are individuals and every relationship is special and can not be modelled. Trying to do so kills the business.
Automated BPM is a service quality killer. We need support systems in the collaborative sense that allow us to run processes as they are needed in real-time but not as they are modelled. People – employees and customers – need to be enabled and not cost has to be reduced. We need some basic semantic models to structure the activities as without metadata there is no information content, but that should be it.
Large scale BPM will NEVER work.
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.
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
I can’t resist the proverbial "head in the sand" comment here.
As for implementing BPMN in a run-time model … I understand your resentment to jump on the BPM hype curve, but it’s no longer theory. I not only talk about, I’ve implemented several BPM solutions that delivered high value and return to the Business, IT, and the Enterprise. Unfortunately, it’s not at my discretion to share with you examples of proprietary solutions, ROI and project plans as "proof"… but believe, I’m not the only BPM soldier with a success story.
Furthermore, it seems the gist of this thread is about "automation"…. BPM is NOT just about automation. In fact, I will submit that automation is often a bi-product of the business process discovery that happens in a BPM project. BPM is all about people and the way people work in concert with one another. The problem is that all too often, the business loses site of the relation ships between groups, roles, departments, even worker to supervisor. That’s were BPMN brings value in the documentation and enlightenment area. Then, the ability to execute on that BPMN model brings value in quality control, process improvement, capability measurement, statistical analysis … and more.