Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

How Many Different Ways Can Your Organization Be ‘Silo-ed’? Why You Need to Address Every ‘Silo-ing’

‘Silo’ is so common as an industry buzzword we mostly just take it for granted. The usual sense is ‘functional’ silo or ‘organizational silo’. I recently heard ‘no man stands alone’ (‘alone’ = ‘silo-ed’) as a common-sense justification for Big-P process. (See http://goo.gl/Cuk3s) That logic is simply flawed. Here are other ways your business can be fundamentally ‘silo-ed’.
  • You can stand alone (silo-ed) in your strategy – goals not aligned, tactics not aligned, policies not aligned.
  • You can stand alone (silo-ed) in your timing – events, intervals and schedules not coordinated.
  • You can stand alone (silo-ed) in your logistics – locations isolated, connections and transport linkages not optimized.
  • You can stand alone (silo-ed) in your language – different vocabularies and meanings, producing semantic silos (a.k.a. a Tower of Babel).
And of course, you can stand alone (silo-ed) in your business rules. Any one of these ‘silo-ings’ can be worse than ‘functional’ or ‘organizational’ ones. My bias, of course, is toward language (nothing gets done effectively in a Tower of Babel) and strategy (if you’re storming the beaches, you’d better hope the generals already got it together strategy-wise). But that’s not the point. If an approach doesn’t evenly addresses all the ‘silo-ings’, it’s trouble. As we say in our new book (http://www.brsolutions.com/b_building_business_solutions.php) you need a well-factored approach. (And of course, John Zachman has been saying that for 25+ years.) The Big-P process view steers you in a harmfully simplistic direction … and probably right into the waiting arms of some eager consultancy or services provider.

Continue Reading

How Business Processes and Behavioral Rules Relate: The Fundamental Insight of Business Rules

In football, when a referee throws a flag, the results of the most recent transform (play) are undone. In effect, by enforcing a rule, the referee prevents or negates the new state (yardline and sometimes the down) and enforces some other state. That’s the way behavioral business rules[1] work. Speed through a school zone and see if your desired state isn’t modified if some policeman happens to be watching. The relationship between behavioral rules and business processes is an indirect one, through state. Business tasks try to produce new states; behavioral rules step in to modify or prevent the new state if a violation occurs … just like the policeman parked in the school zone with a radar gun. More precisely, business tasks precipitate events that try to change state (the outputs, final or interim), and behavioral rules ‘watch’ for the particular events that produce violations. A violation produces a response, which can be another process – e.g., the referee jumping in to whistle the play dead or the policeman putting down his doughnut and chasing you. Yes, it’s important know which business tasks can violate which behavioral rules, but their relationship more complexly networked than you might think. In general, every behavioral rule expressed declaratively can be analyzed to produce two or more events (I call them flash points) where it can be violated and needs to be evaluated. I can provide endless examples. (Refer to http://www.brcommunity.com/b623.php?zoom_highlight=flash+point or to Chapter 8 of Business Rule Concepts, 3rd ed.) These events are likely to be in different business processes (or procedures or use cases) … and sometimes a given process may not have been modeled at all (or the event occurs ‘spontaneously’). The fact that each behavioral business rule can be violated at two or more flash points is a fundamental insight of the business rule approach. It’s precisely where current platforms, tools and methodologies fall short, and why consistency and compliance are so difficult to achieve. In other words, it’s an essential idea in really ‘getting’ business rules.

[1] In SBVR, there are two kinds of business rules; the second kind is definitional rules. As their name suggests, definitional business rules shape concepts and provide criteria for making decisions.

Continue Reading

What Should Business Stakeholders and Business Analysts See (and Not See!) in a Business Process Model?

I was recently asked the question above. It’s a good one. It arose in response to another post, “What is the best way to simplify business process models?”. See http://goo.gl/gWnO0 for a very brief, very dramatic case study. Here’s my answer. Business people (and business analysts) should see only the core set of transforms (business tasks) that respond to some business event, and that lead transform-by-transform to appropriate business end-results through conditional flows. Many process modellers also try to include the criteria that resolve those conditional flows, which in a true business process model, are always business rules. The result is embedding the business rules procedurally within the model, rather than expressing them declaratively (and separately) in their natural form. The more scenarios the model covers, the more hopelessly complex it becomes. The issue has nothing to do with conventions per say, or with the media of presentation – electronic, paper or otherwise. I’m talking about the core stuff of the model itself. Just transforms, transforms, transforms!

Continue Reading

Externalizing Semantics from Business Processes … Why the Procedural Approach is a Flawed Paradigm for the Knowledge Economy

For IT professionals the state of processes has always reigned supreme. In procedural approaches the internal state of a process is represented by some token. Most computer languages use that approach (the token generally falls through lines of code sequentially). Many current approaches to business process modeling do as well, at least implicitly. But why should business people care about the internal state of any process? For example, if a business person asks How far along are we in processing this order? the person is really asking: Has the order been credit-checked? Has it been filled? Has it been shipped? (etc.). In business operations it’s the state of each operational business thing that matters. True business agility cannot be achieved so long as business processes are perceived as managing state internally (privately). That’s a fundamentally flawed paradigm for business operation today. Instead, business processes must externalize semantics so business people can understand and manage the state of operational business things directly. Externalizing semantics is accomplished by means of SBVR-style structured business vocabularies (concept models) and single-sourced business rules. ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

Continue Reading

Want to Make Your Business Process Models Less Complex and More Approachable? There’s a Proven Solution!

The best way to simplify business process models is to take the business rules out and address them separately. Example: For a large pharmaceutical client, we reduced a complex 28pp model to just under 4 pages by doing that – nearly an order-of-magnitude reduction in size (and probably even more in terms of complexity). Everyone loved the results. There was nothing unusual or atypical about the result – we’ve seen it happen many, many times. By the way: If you know of similar cases, I’d love to hear about them!

Continue Reading 2 Comments

How Business Process Models and Business Rules Relate … What State Are You In?

Business Process Models: A completed transform often achieves a business milestone and a new state for some operational business thing(s). Example: claimant notified. Fact Models: In fact models (structured business vocabularies) such states are represented by fact types, for example, claimant is notified (or claimant has been notified if you prefer). A fact model literally represents what things the business can know (remember) about completed transforms and other operational business events. Business Rules: Business rules indicate which states are allowed or required. They should not reference business processes or business tasks by name, just the states they try to achieve. For example, a business rule might be: A claimant may be notified that a claim has been denied only if the specific reason(s) for denial have been determined.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

Continue Reading 1 Comment

The ‘Process’ of Business Analysis is a Great Example of a Social Process

In a recent post, Jonathan ‘Kupe’ Kupersmith said:

“In manufacturing following a process step by step is a good thing. In our world [business analysis] this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project.”.

I believe what Kupe is saying is that the ‘business analysis process’ is not a traditional straight-line process (like old-style manufacturing). Instead, it is what is currently being called (variously) a ‘social process’ or ‘dynamic process’ or ‘case-based process’. Such a process is:
  • Social in that interactions at various times with various people with various kinds of know-how must be orchestrated for optimal results.  
  • Dynamic in that the ‘flow’ is highly situation-based rather than predictably straight-through (static).  
  • Case-Based in that the ‘flow’ of events is based on the particular characteristics of the case (project) at hand, rather on forced conformance with some ideal.
Let me make a couple of observations (which are not points of disagreement with Kupe): 
  • There are many, many companies (even in manufacturing) now beginning to understand that their core business processes should be organized as social/dynamic/case-based rather than traditional/static/straight-line. Customization and personalization of products and services demand it.  
  • Achieving manageable customization and personalization at scale requires an appropriate infrastructure that is business-based.  
  • The need for infrastructure leads inevitably to business vocabulary (business semantics) and business rules. (What’s the alternative??) So business rules are probably even more essential for social/dynamic/case-based processes than traditional/static/straight-line ones.
What do these observations specifically mean for the ‘business analysis process’? I would suggest the following: 
  • Having a standard business vocabulary for the ‘business analysis process’ is key. How many organizations really have one? I see this omission as a huge hole in current BA standards and practices. (Plug: Our new book, Building Business Solutions: Business Analysis with Business Rules, has a 55pp Annotated Glossary. We practice what we preach. http://www.brsolutions.com/b_building_business_solutions.php)  
  • The know-how to support a social/dynamic/case-based ‘business analysis process’ should be expressible as rules. If the know-how can’t be articulated and properly communicated, then how can the process be repeated, learned and scaled? Tacit know-how is simply no longer adequate in a knowledge economy.
~~~~~~~~~~~~~~~  You can find Kupe’s original post on: http://www.batimes.com/kupe-kupersmith/why-business-analysis-processes-are-a-waste-of-time.html

Continue Reading 2 Comments

The Debate Continues … Business Rules in Zachman 3.0 … and the Upcoming Business Architecture Summit at BBC2011

At the Business Architecture Summit in Ft. Lauderdale (BBC2011 – Oct 31 – Nov 4) I will be joining John Zachman and Roger Burlton for one of our rabble-raising 3Amigo sessions. The session is only an hour long, so I’m sure there will be some fast talking(!). One of the first questions I want John to address is: “Where are the business rules in Zachman 3.0?” The following recent exchange represents my current understanding on the matter. I plan to come back on the record after the event to say what I got right and what I got wrong. Question: Can rules address more than one primitive (column) in the Framework? My Answer: Yes, atomic rules can address multiple primitives – e.g., An accounting must be given by the CFO in Delaware on March 15, 2012. (By ‘atomic’ I mean ‘can’t be reduced into two or more rules without losing meaning.’) In this rule you have a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). So even atomic rules are composites, not primitives. Question: Does rules not being a primitive mean that business rules shouldn’t be treated as a first-class citizen? My Answer: What ‘first-class citizen’ has always meant in the Business Rule Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) and elsewhere is that business rules shouldn’t be subordinate to other kinds of requirements for system design in general, and to what I call ‘Big-P’ processes in particular. Big-P processes are not primitive (think ‘input-process-output’), but rather they amalgamate (think ‘mash-up’) some or even all the other primitives. In other words, Big-P processes are also composite. Composites are about the configuration of the enterprise at any point in time. Business rules are one candidate for that capacity. I believe business rules are a far better choice in that regard than Big-P processes (think ‘business agility’). In any case, business rules being a composite in no way diminishes their importance. The enterprise is not built on primitives alone. If you had only primitives, there would be no configuration, and literally no enterprise.

Continue Reading 1 Comment

Is There Always a Process for Everything That Happens? … Definitely Yes and No

A restaurant sometimes allows members of a party to split the bill for a meal so each person can pay just part. Business Rule: The amount paid for a meal may be split among the members of the party served the meal only if all the following are true:
  • Each member initials his or her portion of the amount paid on the bill for the meal.
  • Each member provides the room number in which he or she is currently registered in the hotel
Does the restaurant have some business process for collecting payment? Of course. The bill for meals usually does get paid (usually involving a transform of my personal financial resources!). But that’s not the right question. The real question is whether the business process is simply ad hoc, or modeled and prescribed (or somewhere in between). No matter, the business rule always applies. That’s important because there will always be at least some ad hoc business activity – and perhaps quite a lot. ~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading

Does Your Business Have a 1000 Business Processes? … Not!

A practitioner recently wrote: ” … businesses typically have over a thousand different business processes. There are often variations of business processes for different regions, products, exceptions and business areas as well as other reasons, that’s why there are so many …”. What kind of “process” could he possibly mean!? A business couldn’t possibly have over a thousand business processes. Such a business would be unmanageable. (Unfortunately, some businesses probably aren’t.) The practitioner’s view misses the crucial insight that for both operational and financial reasons, a business must have a small set of core business processes that are standard. Variations can be handled … within what is acceptable … by business rules. Such variation might have to do with geography, products, best practices, etc. Without business rules, the complexity is simply unmanageable.

Continue Reading 2 Comments