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

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘simplifying business processes’

Q&A: Simplifying Business Process Models and Achieving Dynamic Business Processes – All By Using Business Rules

The OMG standard  SBVR[1] distinguishes between two fundamental kinds of business rules[2]:
    • Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
    • Behavioral rules are about shaping conduct (and can be violated).
Question: Should definitional rules be included in business process models? Answer: You might have 100s or 1,000s of business rules about determining creditworthiness. In what sense is directly including all those business rules in a model of a business process useful? (Note carefully I said business rules, model, and again business (process).) So my answer is no, don’t include them. Question: Or, to put it another way, do we simplify business process models by removing only the behavioral rules? Answer: Again, no. Question: And am I right in assuming that these behavioral rules are associated with decision points in process flow charts, and what we are being urged to do is eliminate decision diamonds from those charts? Answer: Assuming you mean binary branch points in traditional flowcharts, I’ve seen both definitional and behavioral rules modeled procedurally by those. Traditional flowcharting is spectacularly unsuccessful for behavioral rules, because as I’ve said many times, each generally has two or more flash points[3] where it could be violated and needs to be checked. Those flash points could be in completely different flow charts (or procedures or use cases). Consider this simple business rule: An agent must be assigned to a customer that has placed an order. Flash points:
    • When the first order is placed by a customer.
    • When an agent leaves the company (which could leave an order-placing customer without an agent).
How likely is the second event to be handled by the same flowchart (or procedure or use case or even business process) as the first? That’s why business rules need to be a first-class citizen in the requirements world. It is also why we need ‘watchers’ outside the process (automated as much as possible) to:
    • Detect violations of behavioral rules (like cops and referees).
    • Permit dynamic invocation of selective (read “selectively different”) responses.
Call the result dynamic process or what you will; behavioral rules are the pragmatic means to stitch together highly responsive business activity in real-time operational activity. ~~~~~~~~~~~~~~~~ If you liked this blog post you might also enjoy: http://www.brsolutions.com/2012/05/01/r-i-p-straight-line-old-school-processes/


[1]Semantics of Business Vocabulary and Business Rules. Release 1.0 of SBVR came out in Dec, 2007. For more information see the SBVR Insider section on BRCommunity.com.
[2]For logic wonks, the distinction is based (very carefully) on necessities (alethic modal logic) vs. obligations (deontic modal logic).
[3] For more on flash points see my blog post: Flash Points: Where Business Rules Meet Events http://goo.gl/pl9sT

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

Business Process Models and Business Rules … Separate the ‘Know’ from the ‘Flow’

Business Process Models and Business Rules … Separate the ‘Know’ from the ‘Flow’ Conditional flows are one of the most important features of a business process model. For example, a business process model for handling claims would include multiple conditional flows – e.g., if valid claim, if claim approved, if fraud suspected, etc. A conditional flow simply means that work follows the given path only if the condition is satisfied for a given case. The secret of effective business process modeling with business rules is never embed the criteria used to evaluate a conditional in the conditional itself. Instead, just name the conditional using an adjective (e.g., valid) or past participle (e.g., approved). The criteria for evaluating conditionals should always be expressed separately as business rules. Fortunately there’s nothing particularly hard about that. Example: A claim may be considered valid only if it has an incident date. Following this best practice is how you keep a business process model simple – often by an order of magnitude or more! Frankly, most business processes aren’t nearly as complicated as people think. What’s complicated is the know-how needed to perform the business process correctly. That know-how should be represented by business rules. P.S. I first heard the phrase ‘separate the know from the flow’ from Roger Burlton on 11/30/1999. I immediately made a note because it was so memorable and on-target.  ~~~~~~~~~~~~~~~~~~~~~~~~~~ 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