Laws of Process

In an earlier post I mentioned how crucial the notion of business process is to enterprise architecture. Businesses are collections of processes, and EA's are often called upon to design the most efficient ways of implementing processes.

Over the years I’ve thought a lot about the concept of business process. While there are a ton of subtleties and complexities, of course, you can boil down process to three fundamental formalisms: events, tasks, and decisions (circles, rectangles and diamonds in a flow chart).Obviously the standard BPMN (Business Process Modeling  Notation) has many more shapes but I’d argue that these are instances of the core classes.

Each can be arbitrarily attributed, with concepts like duration, cost, location, and so on. But I think it’s easier to explain them with a set of concepts which I’ll pretentiously call “laws” (although the more I think about it the more I’m convinced that to some degree these are in fact laws of nature!). I’d love your comments.

First Law of Business Process: Every Process Starts with an Event. Something has to trigger the execution of a business process, in every single case. A customer calls, and starts a service process. The time is now executive-meeting - 3 weeks, so that triggers the executive meeting deck review process.

As a corollary, this law means that every event has business significance, or business semantics. No process should ever start with a “start-event” – there is no such thing.

Second Law of Business Process: Processes Consist of Events, Tasks and Decisions. To be technical for a moment, these are the core, primary procedural elements of a process and these are what make the process Turing-complete.

Third Law of Business Process: Process and Information are Inextricably Tied. Processes cannot exist without information. When a customer buys something, what they bought, who bought it, when they bought it, where, how many they bought, how much inventory is available after purchase, and so on, are all examples of information. To be crystal clear about this, processes that do not describe information flow and state changes are not processes, they are merely flow charts.

In fact, one way to define a process is to consider it as a series of state changes in data, although it’s rather less intuitive as a diagram.

Fourth Law of Business Process: Processes Can be Simulated, Measured and Optimized. As mentioned above each of the shapes (activities) in a process can be attributed in various ways – how long each takes, how much each costs, and so on. With that information it is then possible to measure (among other things) the cycle time of each path through the process, the cost of each path;  this enables simulation and optimization of processes, perhaps prior to (the very expensive step of) deploying them.

Fifth Law of Business Process: Processes Must be “Correct” to Run.   Simple process flow charts cannot be shown to be deployable. What if the “Send-Offer-Letter” task is not provided with a candidate record? What if the “Replace-Inventory” task is not provided with the name of the object to requisition? The right information must be there for the process to run – or else it won’t. The right roles (people, systems, services) must be present and have the right SLA’s for the process to run and for performance expectations to be met.

Ideally, tools can perform static analysis (not entirely unlike that of a compiler) of a process prior to deployment to determine correctness. 

Sixth Law of Business Process: Roles Determine Who Does What. Some steps in a process may be done by a computer program. Some may be done by a person or a group of people. Computers are fast but do not think. People are slow (comparatively) but apply judgment (inconsistently). A clear articulation of what role applies to each step in a process enables decisions around load balancing, speed of execution, hiring, and hardware acquisition and deployment, among other things.

Seventh Law of Business Process: Processes are Fractal. Basically, this means that every task can be decomposed into a subprocess. At one level a process might contain a “Ship-Product” task. At the next level that step might decompose to a subprocess that describes in detail how the shipper is contacted, what sort of billing is agreed upon, delivery time, and so on.

Eighth Law of Business Process: Every Process Ends with an Event, Which Always Starts Another Process. Every process ends with the achievement of some business goal. It can be demonstrated that the achievement of that goal constitutes the initiation of a follow-on process; for example, “customer ends call happy/mad” which will start some other activity, like updating a dashboard, or some additional retention activity and so on. So at the end of every business process should be a BPMN circle with a business-significant result described (and ideally, the process that gets kicked off thereafter).

What do you think? Do you agree? Did I miss a "law" or two? Let me know!

Comments

• Anonymous
  July 15, 2014
  Hi I agree with you the Law concept is true and we can see when we are modeling. Great Blog!

• Anonymous
  October 27, 2014
  Overall, I'm in agreement. But, I think you are missing the most important law. Law of Process Change: Implementation of Process Change will not deliver expected benefits [Improved Output, Lower Risk, Lower Cost, Improved Timeliness and or Improved Agility] without Change Leadership