My December 8 blog post about classifying business process approaches generated an avalanche of responses. See the 2×2 matrix itself (from John Mansfield of Fidelity Investments) and the stream of Comments about it on http://www.brsolutions.com/2014/12/08/a-10000-foot-view-of-the-business-process-space-is-it-correct-is-it-complete/. In the guest post below, Brett Champlin shares his evaluation of the matrix. ~~~~~~~~~~ There are many things wrong with the matrix. 

• Lean and Six Sigma are both process improvement methodologies and are frequently combined as Lean Six Sigma. So they can all be subsumed into a category of process improvement methods.
• The matrix leaves out classic process redesign methods which are very commonly used. These methods go beyond improvement methods to respond to things like automation, new products, M&A, etc. where the basic process is modified or extended to accommodate some new situation.
• Process improvement and redesign methods along with reegineering (aka process transformation and/or innovation and/or reinvention) are all process change methods. Change management should certainly accompany them all.
• The matrix also leaves out Business Process Management as an all-encompassing discipline that deals with all types of process change as well as strategy, monitoring and measurement, and process portfolio management.
• It also leaves out Customer Experience Design, which over the last several years has been incorporated into many BPM toolkits as a precursor to any process change effort.

The dimensions mapped in the matrix are really those that are the core focus of the two improvement methods: Six Sigma focuses on defects and variation, while Lean focuses on waste and flow. In those terms, the diagram is more or less accurate, but it hardly covers the Business Process space in its entirety. I have used the matrices in Figures 1 and 2 (below) for that purpose.  Jeston & Nelis presented several 2×2 grids mapping different process change methods relative to time and cost and degree of change. These grids give a different perspective and are more complete, but still don’t cover the entire business process space. See Figures 3 and 4 (also below). Most of these types of analyses are continuations of industrial engineering perspectives. They are fine if that aligns to your needs, but today many businesses are looking beyond ‘faster, better, cheaper’ as the only way to measure their processes. These days many businesses take control of quality, waste and flow as a ‘given’. They are looking at other things such as customer attraction/engagement/retention, business agility (not IT agility), strategic positioning, etc. All of these perspectives are not easily represented in a simple 2×2 grid. Figure 1.                     Figure 2.                       Figure 3.                         Figure 4.

                      I love this nifty diagram I first saw recently by John Mansfield of Fidelity Investments. A quality vs. waste matrix seems to nicely position the major approaches in the BPM space – Continuous Improvement, Six Sigma, Lean, and Re- engineering. As useful as the diagram seems, it raises a plethora of questions, including the following:

• Is it Correct? Does it oversimplify? Does it mis-position any of the major players? If so, how?
• Is it Complete? Does it leave any important players out? If so, which ones? Is a two-axis view sufficient for covering the space? If not, why not?

My current view is that a two-axis view of the space is probably not sufficient for covering the space. It’s difficult to put my finger on what exactly is missing, but I suspect it’s a big deal. I’ve put the question on my list to explore for 2015 and beyond. At least I now have a tentative platform for a deep dive.

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.

• An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
• The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
• We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
• Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
• The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).

What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:

• Focuses on real business know-how, not just better GUIs or dialogs.
• Continues vigorously after deployment, not just during development.
• Occurs at a natural business pace, not constrained to software release cycles.

The Manifesto says it this way:  “An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.”  That’s exactly what you need for knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

---

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #7 Question: How do business rules relate to knowledge retention? The classic test of whether knowledge is tacit or explicit is this: If you lose the person, do you lose the knowledge? Clearly, you want basic business know-how to be explicit, so a basic principle of the Manifesto is …

3.3. Rules must be explicit.  No rule is ever assumed about any concept or fact.

Rules capture and encode operational business know-how in a form that can be retained, managed and re-used. What are rules really about? A well-expressed rule is based on terms and facts (or more accurately, noun concepts and verb concepts). These concepts represent the basic stuff of the business – operational-level things that are talked about, managed and processed day-in and day-out, often many, many thousands of times. Rules provide criteria that guide this operational activity in a consistent way. So the Manifesto emphasizes …

3.4. Rules are basic to what the business knows about itself – that is, to basic business knowledge.  

In business, of course, knowledge is not an end in and of itself. Rather, the goal is consistent application of the knowledge – as well as its continuous improvement. Achieving these goals requires that the people who understand the knowledge – business people, subject matter experts, and business analysts – be able to work with it directly and effectively. After all, the true test of knowledge quality is not whether an application program runs, but whether you get the right (or best) results. So the Manifesto says …

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

In the plainest possible terms, IT professionals simply shouldn’t be the ones to determine whether business logic ‘works’.