If you examine process thinking, you find it is deeply rooted in 20th century blue-collar manufacturing/production processes, starting with Federick W. Taylor (pig iron), Henry Ford (autos), Toyota Production System (autos), Six Sigma (Motorola and General Electric), Lean, and offshoots. In every case, the focus is on tangible products.But what if your products are intangible? You’d be excused for thinking that the carry-over from the manufacturing/production world is not all that it should be. To those who dissent, I say prove me wrong.In the 21st century, processes of interest are increasingly white-collar and knowledge-intensive. There’s a product, of course, but it generally has more to do with some transition in the state of a significant resource (not infrequently money) than the assembly of something new from physical parts. Rather than efficiency, machines and inventory, their operational focus is consistency, compliance and decisions.Typical examples include …
Finance: Accepting and funding a mortgage.
Insurance: Extending coverages and adjudicating resulting claims.
Taxation: Evaluating financial records and assessing taxes.
I call such processes commitment/dispersal processes. (See basis definitions below.) Commitment/dispersal processes are always about:
Making commitments and managing dispersals of resources (money, time, people, etc.).
Satisfying obligations (often contractual or regulatory), making informed decisions, and responding continuously to changed circumstances.
For such processes you must know what the rules are; otherwise, you cannot identify appropriate inputs. In short, such processes take you directly to best practices for business rules and decision engineering as a basis for process renewal and innovation.What’s in between manufacturing/production processes and commitment/dispersal processes? I suspect there’s a wide spectrum of processes – and that many of them are often not much like manufacturing/production processes either.~~~~~~~Basis definitions from Merriam-Webster Unabridged Dictionary …[commitment]3a(2): an engagement by contract or purchase order to assume a financial obligation (as to accept goods at an agreed price, to pay for subscribed stock, or to make a mortgage loan upon the completion of a building)[disperse]2a: to spread abroad from a center of supply or control : DISSEMINATE~~~~~~~www.BRSolutions.com
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.
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.
Read to the end for an interesting note about this post.1. Ad hoc rules: Most businesses have no logical approach for defining their business rules. As a result, business workers often make up the rules as they go along. This leads to confusion, contradiction, and operational inefficiency. After-the-fact resolution of these problems wastes time and resources and causes frustration for customers and staff alike. The larger the organization, the bigger the problem. Also, since many business rules involve monetary transactions (for example, whether a customer should be given a discount, and if so, how much), this problem can also directly affect the bottom line.
Business rule solution: A structured approach helps you think through rules before the fact.
2. Miscommunication: Misunderstanding of key business concepts inevitably results in miscommunication. Does preferred customer discount mean the same across all departments? If not, what are the differences? What rules apply? Do these rules differ for different areas of the business? Are the rules consistent?
Business rule solution: A clear set of concepts provides a foundation on which rules can be directly based.
3. Inaccessible rules: Finding out what rules apply to a given business situation often involves an open-ended search through multiple sources. It is not uncommon in the end to resort to the application source code. Pursuing rules in this fashion is time-consuming, inefficient, and inaccurate.
Business rule solution: A way to manage business rules provides direct accessibility.
4. Massive differentiation: Many businesses seek to support highly individualized relationships with growing numbers of customers and other partners for ever more complex products or services. How can businesses massively differentiate between business parties and, at the very same time, conduct each business transaction faster, more accurately, and at ever lower costs?
Business rule solution: A rule-based approach featuring rapid development and deployment of rules supports differentiation.
5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the Internet age, people expect almost instantaneous implementation of changes. How can line workers consumed with day-to-day activities ever hope to keep up?
Business rule solution: Real-time delivery of business logic to knowledge workers as errors actually occur creates a seamless, never-ending, self-training environment.
6. Knowledge walking out the door: By and large, baby boomers created much of the operational business capacity and operational systems we see in place in larger organizations today. Much of the related knowledge still sits in their heads—and nowhere else. What will happen when they retire? On a smaller scale, people with vital operational knowledge walk out the door almost every day.
Business rule solution: A systematic way of capturing, documenting, and retaining the business rules prevents the loss of knowledge when people leave.
~~~~~~~~~~Excerpted from Principles of the Business Rule Approach, by Ronald G. Ross, AddisonWesley, 2003, pp. xx-xxii.Note: This list of benefits was written a dozen years ago. It seems the more things change, the more they stay the same for business rules. About the only thing I would alter today is to add the following buzzwords for the respective benefits.
What’s your definition of business architecture? Here’s ours:
a structural representation of a business solution as it relates to creating business value and achieving business goals
Like most practitioners we mean a blueprint.
Actually, blueprint doesn’t completely align with the dictionary definitions of architecture. You can take your pick from the following alternatives, but not one of them refers to a representation of what is being built.
1.Art and Science:the art or practice of designing and building structures … in accordance with principles determined by aesthetic and practical or material considerations
2. Structure:formation or construction whether the result of conscious act or of growth or of random disposition of the parts … e.g., architecture and function of the cerebral cortex
3. Specific Result:instance of the exercise of the art or science of architecture … architectural product: architectural work … e.g., the mansions which comprise the entire architecture of the Square
4. Method of Style:a method or style of building characterized by certain peculiarities of structure …
The first definition above refers to architecture as an art and science. That’s what architecture students go to universities to learn, and what professional architects practice daily. Who today really thinks of business architecture as an art and science? It should be – and it probably will be eventually – but it’s not yet.
The first definition also highlights principles. Any viable approach to business architecture must enumerate its principles and adhere to them closely. That’s not just so much talk. The approach must provide proper thinking tools so that you can consistently act in accordance with the principles.
Do most current approaches to business architecture provide such thinking tools? I think not. If they did, they would feature:
Business policies (in the context of business strategy), business rules, and decision engineering. Those things represent the intellect of the organization and the fundamental answer for question why.
A carefully factored approach whose component models cover each of the facets needed to communicate effectively with all the different audiences engaged with, or affected by, a business solution.
Let’s face it. Many techniques currently offered for ‘business architecture’ frankly aren’t even really about the business. They’re about – what else – IT’s view of the business.
Some related points:
1. We think that business architecture always involves some amount (often pervasive) of organizational transformation, which can be taken to include building a new business solution completely from scratch. Organizational transformation is inevitable, so other than buzzword appeal, there’s really no need to mention it in the definition of business architecture.
2. Architect can be used as a verb (to plan and contrive as an architect). Too bad “architecting” doesn’t roll off the tongue as easily as “designing” or “modeling”. After all, architecting business solutions is exactly what business architects should be doing daily.
 These are the two basic principles of the BRS methodology IPSpeak™, which architects business solutions featuring the operational intellectual property (IP) of the business. IPSpeak is comprehensively detailed in our 2011 book Building Business Solutions: Business Analysis with Business Rules (by Ronald G. Ross and Gladys S.W. Lam).
Your ability to respond in appropriate ways to pinpoint circumstances where business rules are breached – automatically and independently of processes – provides the mechanism you need to support very smart, very friendly business systems. Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred. Can breaches occur for decision rules too? The answer is yes and no. Read on!
A breach occurs for a business rule when the business rule isn’t satisfied upon being applied to some set of circumstances (state of affairs). Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred (e.g., you violated the posted speed limit).
The potential for violations of behavioral rules raises several important questions that business analysts should answer in advance of deployment for each behavioral rule:
1. What level of enforcement should be applied.
2. What special response to a violation is appropriate, if any.
3. What special message, if any, should be returned to some worker(s) upon a violation.
Unlike behavioral rules, no definitional rule can ever be violated. Literally, things must be correct under such rules by definition.
Let’s take an example. Suppose somebody asserts “2+2=5”. According to the rules of mathematics, we know the correct answer is 4. The answer “5” is deemed irrevocably wrong. But is the asserted answer ever allowed to stand?
If the rule is defined as a decision rule, the asserted answer is never allowed to stand. More precisely, the assertion would never be recognized to have happened in the first place. If someone asserts “2+2” the answer “4” is concluded immediately. Period. No breach, no opportunity for error.
If defined as a behavioral rule (one that is not strictly enforced), the asserted answer is allowed to stand, but a violation is recognized. How might that capability be useful? Suppose the error were made by a student in grade school. It might be quite useful for the student and/or a tutor to know about it immediately and automatically. Specifying an appropriate violation response can make such notification happen.
In business, of course, definitional rules can be far more complex. Nonetheless, your ability to respond in appropriate ways to the pinpoint circumstances where certain rule-related events occur – automatically and independently of processes – provides exactly the mechanism you need to support very smart, very friendly operational business decision systems.
Decision Rules and Breaches
Decision rules are a special kind of definitional rule involving implications (e.g., A implies B). They support inferences and determinations – identifying an appropriate outcome from among a set of alternatives.
Like all decision rules, definitional rules cannot be violated. They are simply deemed true by definition.
Purely from a business perspective, however, some assertions of fact(s) may make it appear that a breach-like event has occurred. I take pains to emphasize any such perception is purely from the business perspective, not from the perspective of logic. You perceive a breach of a decision rule simply because it’s useful to do so, not because any true violation has occurred.
In evaluating some particular case (situation, set of circumstances, or matter of concern), for example, things might not follow the ‘happy path’. Think of a breach of a decision rule as a bump in the road – a gap along the happy path.
Let’s return to the three questions listed earlier. Although the first question about enforcement level obviously doesn’t apply to decision rules, adjusted versions of questions 2 and 3 remain in play.
Consider the following simple business example. Suppose a bank has this decision rule:
A credit application must be considered discrepancy-free with respect to a credit report for the applicant if all the following are the same:
date of birth
Social Security Number
Let’s suppose that an applicant uses just the initial for her middle name on her credit application. If the credit report shows her full middle name, then the names are not the same and the credit application will not be considered discrepancy-free.
Note carefully the rule hasn’t been violated; it did its ‘work’ correctly and it did reach the proper conclusion (not discrepancy-free). But a gap – a breach – for her case has been identified from a business perspective because the rule failed on one of the conditions. We should be able to take advantage of that breach to take appropriate action – selectively, automatically and in real time.
For example, the desired response to the breach might be to insert the following to-do item in the work queue of the responsible staff member: “Review discrepancy and manually ok if appropriate”. (The to-do item should naturally also provide ready access to the related documents.) The breach of the rule causes this action to occur automatically.
Think about how many decision rules might exist for determining credit-worthiness, and how many selective conditions they might have. Could you build a responsive system by incorporating the selective responses needed into the related process model(s)? Not a chance – that approach won’t scale. Instead, the selective responses need to be specified based on the business-rule side of things.
Kinds of Breach Specifications for Decision Rules
Breach specifications for a decision rule can be of the following two kinds.Breach Response. A breach response can be an action of virtually any kind. For example, a breach action might be to:
Add some task(s) to a (non-redundant) to-do list in some appropriate work queue.
Add some documentation items to a (non-redundant) not-yet-received list.
By these means very selective follow-up processing/handling (“what to do next”) can be organized pertaining to any specific issue (breach) for a given case. Such selectivity is made possible by the granularity of the rules.
Breach Message. A specially-worded breach message can be forwarded to any involved party either inside or outside the company. A breach message generally explains one or both of the following at any level of detail desired:
Why the rule or condition failed. (The rule or condition statement already indicates very precisely what the issue is, but the breach message can explain in a more friendly manner.)
What should be done to address the issue.
More Complex Example
Breach specifications apply selectively and specifically to a decision rule and/or any of its conditions. A breach specification applies if and only if that decision rule and/or condition fails (is not true) in evaluating some specific case (e.g., a specific credit application). An example of a decision rule with condition-specific breach specifications is illustrated in Table 1.
Table 1. Example of More Complex Decision Rule with Condition-Specific Breach Specifications
A fluctuating income must be considered eligible if all the following are true:
Conditions of the
the applicant has a 3-year proven track record of consistent income
the applicant is likely to have comparable income in the future
Add to-do item for that credit application: “Contact employer to verify applicant has reasonable opportunity for future income.”
the income is validated
Add required documentation items not yet received to a pending list for the credit application.
To applicant: “[date] Here’s a list of documentation items related to your income we have not yet received. [pending list].”
Using Breach Specifications
Breach specifications can be:
General for an entire decision rule including all its conditions. (The example in Table 1 doesn’t include any whole-rule specifications. If the rule did they would appear in the first row.)
Specific to a given condition.
Specific to collections of conditions (none shown for the example).
A breach is detected only if the conclusion of the rule as a whole, or some particular condition within it, evaluates to not true. Things being true should be viewed as moving the case along the desired path (i.e., no breach has occurred). Decision rules (and breach specifications) should be expressed carefully so as to preserve this positive orientation.
Generally, breach actions should be specified only if something can be done to overcome a failure (of a rule or condition). The goal is to move things forward in the case. In the example above, for instance, if nothing whatsoever can be done to correct an issue, the credit application should simply be declined. A behavioral rule to that effect should be specified.
In hierarchies of decisions (e.g., as in Q-Charts) and decision rules (e.g., as based on series of logical dependencies), breach specifications should generally be made only at the lowest level of rule reduction/decomposition. A rule at a higher level in a logical hierarchy only evaluates to not true if some rule(s) below it evaluate to not true. Define breach specifications at the lowest level of granularity.
Although rules can be specified in violation specifications for behavioral rules (e.g., to express some sanction or penalty), they should never be specified within breach specifications for a decision rule. Such ‘nesting’ of rules, especially on the basis of ‘not true’, is inappropriate.
Otherwise the advantages of overall declarative specification can be forfeited.
By default, breach specifications for a decision rule apply only the first time it is evaluated for each case. The assumption is that all business rules, including decision rules, are evaluated on a continuous basis. Re-application of any breach specification for a case therefore requires additional timing and iteration criteria. Whether a case is evaluated iteratively on the same set of decision rules based on timing criteria applied by or for some external process or platform is outside the scope of this discussion. No matter what the scheme of evaluation, the expression of the decision rules – as for all business rules – should be completely unaware of it.
I was asked to explain why Business Architecture in 75 words or less. Here’s my response (in only 65 words). Agree? Disagree? Can you do better? Your feedback most welcome!
Business innovation coupled with massive digitization is the hot topic in business circles far and wide. The challenge in transforming the organization, however, is that the complexity is far too great, and involves far too many players, to hold in any one person’s head. The need for explicit architecture thus arises – not IT architecture, but ones suited for capturing relevant aspects of the business itself.www.BRSolutions.com
Question: Can you spot the circularity among these three definitions?
Need: a problem, opportunity, or constraint with potential value to a stakeholder
Solution: a specific way of satisfying one or more needs in a context
Stakeholder: a group or individual with a relationship to a change or a solution
Answer 1: The definition of “need” references “stakeholder”, whose definition references “solution”, whose definition references “need”. The definitions don’t need to be circular. It’s simply bad definition/glossary practice.How can the circularity be removed? “Need” should simply be defined as “problem, opportunity, or constraint”. That’s the essence of the concept. Whether it has “value to a stakeholder” is an assessment. Just because one person says something (a need) has value and another person says it (the need) does not (which happens all the time by the way) doesn’t mean the thing is not a need to either: (a) the person who has it, or (b) the person who says it has no value. The latter person would say “that need has no value”. He/She just called it a “need”, so how can it not be a ‘need’?Answer 2: There is actually a second circularity in the definitions: need –> value –> stakeholder –> solution –> need. Changing the definition of “need” as I propose above will fix that second circularity too. “Need” is a very basic concept. If there were no need, there would be no reason to assess what value it has to what stakeholder (including the one who proposed it). If there were no need, there would be no solution, context or change (in the BA’s world). It’s a seedconcept.Principle: In developing a vocabulary it’s best to start from terms whose definitions use no other terms … i.e., from seed concepts.Otherwise, circularities will make Swiss cheese of your brain.www.BRSolutions.com
Want context-sensitive business rules? It doesn’t necessarily work the way you think it might. Let’s take an example: A client must have a physical address. That’s the rule; it just says what it says.
Separately from the rule itself, several things can be specified:
How strictly the rule is to be enforced. Such specification might be: ‘strictly enforced’, ‘override with prior authorization’, ‘override with explanation’, ‘guideline’, etc.
What response and/or message is appropriate when the rule is violated.
Both things can be specified to be context-dependent. Back to the example:
Suppose the rule is violated in signing up as a member of a website. The enforcement level might be “guideline” and the response might be “We encourage you to provide this information so that we may serve you better in the future.”
Suppose the rule is violated in placing an order. The enforcement level might be “strictly enforced” and the response might be “We’re sorry. But we need your address to send you this order.”
There are two fundamental kinds of business rules: behavioral rules and decision rules. Behavioral rules are rules people can violate; decision rules are rules that shape knowledge or information. Decision rules cannot be violated – knowledge or information just is what it is defined to be. Common to all business rules, no matter which category, is that you want them directly traceable for compliance and other purposes.
How do behavioral rules and decision rules apply differentially to service workers vs. white-collar workers vs. gold-collar workers?
Service workers are primarily subject to obeying behavioral rules, or are charged with applying them. Examples:
A counter attendant must not accept a credit card for a purchase under $10.
A flight attendant must ensure passengers have buckled their seat belts for each take-off and landing.
Service workers are subject to operational business decisions made by white-collar workers, but do not play a significant role in making such decisions themselves.White-collar workers are typically involved in business processes where operational business decisions are made. Examples:
Should this loan applicant be given a mortgage?
What flight crew should be assigned to this flight?
White-collar workers generally do not define decision rules themselves – that’s typically work for gold-collar workers. Where such rules are incomplete, unspecified or contradictory, however, white-collar workers generally rely on personal heuristics and experience to make decisions. This approach puts the main goals for white-collar work – consistency and traceability – at jeopardy.White-collar workers, like all workers, are subject to behavioral rules. Examples:
A loan officer must not handle a loan application placed by a family member
The website description for a new product must be approved by two senior managers.
Gold-collar workers (for explanation see http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/) are responsible for non-routine, knowledge-intensive work. The primary goals for such work is that it be insightful (e.g., as in the case of medical diagnosis that fits the available data better) or creative (e.g., as in the case of a new marketing strategy). This type of work is generally beyond the scope of decision rules.
Although gold-collar workers often conduct their work in relatively independent fashion, the work is generally subject to “very close normative control from organizations they work for” [Wikipedia]. Think medical malpractice or following generally accepted principles of accounting. These normative controls, since they can be violated, are sets of behavioral rules.www.BRSolutions.com
Based on the OMG standard SBVR (Semantics of Business Vocabulary and Business Rules). For more on SBVR see the SBVR Insider section on www.BRCommunity.com.
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”