The things that IT implements under today’s software platforms are mostly not true business rules; rather, they are encoded representations of business rules. Don’t underestimate how pervasively across your organization business rule is misunderstood. What are true business rules?

 

• True business rules are about running the business, not its systems. Your company would need its true business rules even if it had no software. True business rules are simply criteria used in daily business operations to shape behavior or make decisions.
• True business rules are not meta-data or information. Only through gross misinterpretation or misunderstanding do they fall under that umbrella (and the related organizational function). Instead, true business rules are a form of knowledge. They are about what you need to know to make things work properly in daily business operations. Knowledge is knowledge. Information is information. They are simply not the same thing.
• True business rules are about human communication – people-to-people communication, people having business conversations. True business rules enable business people to communicate operational business knowledge, not just things IT can implement. Such communication is especially important if (as is so often the case these days) the people are displaced by time and space.

Achieving these knowledge-related goals requires two things:

1. Business rules must be written. (If you are part of an agile project that believes otherwise, you need to rethink.)
2. Business rules must be written in declarative form using structured natural language. Here is an example of how a true business rule is written.

An account may be considered overdrawn only if cash withdrawal is greater than the current balance of the account.

When it comes to communicating knowledge, Murphy’s Law definitely applies. If something can be misinterpreted it will be misinterpreted. Capturing and expressing true business rules completely and accurately is a rich skill. (By the way, machines should certainly be able to help us with that.)

The need to communicate business rules in structured natural language led our company to create a world-wide set of conventions called Rulespeak® (free on www.RuleSpeak.com, now in 6 languages). There’s simply no substitute for precise, unambiguous communication of operational business knowledge. It’s central to business knowledge engineering.

~~~~~~~~~~~

Read about the new knowledge paradigm: http://www.brcommunity.com/articles.php?id=b900

Let’s put you on the hot spot. You are forced to agree or disagree with the following statement, and defend your answer. What would you say?

Deep subject matter expertise is irrelevant for a business analyst, especially in agile business analysis.

Here’s how I answer: I disagree. How about you?

My reasoning: Actually I agree that deep subject matter expertise is generally irrelevant for a business analyst. Where I disagree (strongly) is that it’s especially true for agile business analysis.

Agile business analysis is no silver bullet. It doesn’t imbue you with magical powers to learn faster. Failing faster to learn faster is simply churn. There’s no end to it.

We’re missing the big picture. Exploring ‘deep subject matter expertise’ you’re not familiar with is a matter of having the right architectural tools to probe knowledge. It’s that deep operational business knowledge that makes subject areas hard.

So you simply need the right architectural techniques to map the knowledge of a domain explicitly. You need to be able to ask probing questions about the domain intelligently without wasting SMEs’ time.

The architectural techniques you need are true business rules and concept modeling (structured business vocabulary). By the way, business rules and concept models can be made to work equally well for both agile and waterfall – and anything in between.

~~~~~~~~~~~~~~~~~~~~~~

Mark Your Calendar: The annual Building Business Capability (BBC) conference is November 6-10, 2017 at the Loews Royal Pacific Resort, Orlando, FL. The BBC is the place to be for professional excellence!

To understand the future of processes, you must dig a little deeper than many people do. Process thinking goes back well over a 100 years, to the origin of modern iron and automobile production. The raw materials and finished goods of such manufacturing and production processes are literally spatial – 3-dimensional. What can you do to significantly improve productivity in a 3-dimensional world? The answer these days is simple: You build robots. Robotization has literally changed the world during the past 30-40 years. Rather than manufacturing and production processes, however, the world is now increasingly focused on white-collar and digital processes. What 3-dimensional presence do the raw materials and finished goods of these processes have? Well, exactly none. The raw materials and finished goods of these processes aren’t physical and simply have no spatial presence whatsoever (except maybe for paper artifacts). Robots (at least physical ones) aren’t an option. That fact of life makes a huge difference in how you have to think about automation for such processes. Instead, the raw materials and finished goods of such processes are all about your operational business knowledge – your intellectual capital – and your capacity to express and apply it. That capability, in turn, depends directly on your business terminology and business language. For white-collar processes you have no choice – the world is semantic. So you must deal with the subject matter semantically. That takes us in a very different direction than most professionals currently foresee. For one thing it takes us toward natural language and away from diagrams-for-everything. That’s a huge shift in mindset. Imagine having a business conversation with your smart phone about gaps and ambiguities in business policies and in the meanings of the vocabulary you use to talk about subject matter knowledge. Don’t think that’s possible? Have you watched your kids talking to their smart phones lately? Sooner or later businesses will realize that operational business knowledge differentiates their product/services and enables their ever-more-automated processes to function. Capturing, managing and re-using that intellectual capital puts a premium on structured business vocabulary (concept models[1]) and on business rules expressed in structured natural language[2]. Those business rules are the only way you have to ensure quality from white-collar and digital processes. ~~~~~~~ Read more on this topic: Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

---

Here are what I firmly believe are three basic principles for business architecture. To me they are just common sense, but they are certainly not so common in prevailing industry practices. 1. Business architecture should be of, by and for the business. (Otherwise, why add the modifier “business”?!). Our rule of thumb is that if business people don’t use a methodology term naturally, then it has no place in *business* architecture. Ever hear a business person use the term “business use case” or simply “use case” without prompting from IT?! The technique is an obvious misfit for *business* architecture. This is simply a case of IT trying to elevate its own tools to a problem it frankly often doesn’t understand. 2. The blueprinting techniques used for business architecture should apply exactly the same no matter how wide the scope – project, business process, whole business, whole supply chain, etc. These are all business problems (first), just sitting in different ecosystems. Also, it should make no difference whether automation is anticipated or not. (Actually, running business operations by hand may be harder in some respects than if automated. Anyway, systems do sometimes go down.) If a blueprinting approach fails in these regards, it’s not about *business* architecture. 3. A major shortcoming in most current approaches is the absence of attention to specifying semantics and knowledge. These need not be interpreted as anything arcane – they’re not. Basically, ‘semantics and knowledge’ simply means defining business vocabulary – words – in an organized manner, and practicable rules to run the business by. Now what business person hasn’t heard of “words”, “definitions”, and “rules”?! Yet traditional IT methods treat them as alien (or not at all). In a day and age of IBM Watson, how could such practices not be seen as archaic?! ~~~~~~~~~ P.S. Yes, such blueprinting techniques for business architecture do exist, and we practice them – in-depth – all the time with our clients. This is what our book Building Business Solutions: Business Analysis with Business Rules (http://www.brsolutions.com/b_building_business_solutions.php) is all about, as well as our on-line training based on it (http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php). www.BRSolutions.com

I’ve been writing a lot recently about the knowledge economy and what makes a business smart. Let me dig a little deeper. The kind of knowledge I’m talking about might be better described as know-how.

know-how:  accumulated practical skill or expertness …  especially:  technical knowledge, ability, skill, or expertness of this sort[1]

Know-how that you can encode and retain is represented by business rules and the structured business vocabularies (concept models) on which the business rules are based.  Know-how is a subset, a small one probably, of knowledge.  Briefly, knowledge can range from practical to theoretical, from certain to probabilistic, and from frequently applicable to infrequently applicable.  At the risk of saying the obvious, you can’t run the day-to-day operations of a business on knowledge that is theoretical, probabilistic, or infrequently applicable.  In short, business rules are about know-how management, a strictly limited subset of knowledge management. Like knowledge, know-how can be either tacit (in people’s heads) or explicit.  The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’.  Obviously you want to retain know-how. As a senior manager recently put it, “No organization should depend on absent brains.”

know-how retention:  expressing know-how explicitly in a form understandable by business people and business analysts, and managing the know-how, such that it is always available for future reference or use (by those capable and authorized)

The over-time infrastructure needed to retain know-how is provided by a general rulebook system (GRBS).  It’s what rule management should really be all about. ~~~~~~~~~~~~~~~~~~~~~~~ from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs

Ask yourself …

Why should every business define its own business vocabulary even though almost everybody operates in some larger community of practice? 

Why should every business invent its own business rules even though perhaps only 20% of its business rules directly impact competitive advantage? 

Why should regulatory bodies issue regulations without adequate definitions and provably correct (anomaly-free) business rules? 

Why should contracts, agreements, and deals be signed with terms of agreement and definitions already spelled out, only to have IT implement them essentially from the ground-up? 

What’s the knowledge economy? According to Wikipedia:

“Various observers describe today’s global economy as one in transition to a ‘knowledge economy,’ as an extension of an ‘information society.’  The transition requires that the rules and practices that determined success in the industrial economy need rewriting in an interconnected, globalized economy where knowledge resources such as know-how and expertise are as critical as other economic resources.”

Catch that part about rules?! ~~~~~~~~~~~~~~~~~~~~~~~ from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs    

I am certainly interested in what makes processes smart. But I’m a lot more interested in what makes business smart. My observations:

• A process lets you interact with customers, but doesn’t guarantee those interactions are the best possible.
• A process crosses silos and boundaries of place and time, but doesn’t ensure you communicate across those silos and boundaries.
• A process produces things, but doesn’t ensure you produce the right things.
• A process pays the bills, but doesn’t find you new money.
• A process lets you play the game, but doesn’t determine whether you will win.
• A process lets you act, but doesn’t guarantee you will learn from it.

Here are things I know are directly involved in making your business smart. All of them affect processes, but none of them are processes:

• Business rules
• Core business concepts
• Operational business decisions
• Strategy
• Policy monitors (KPIs)

So as you start hearing analysts say that smart processes are the next big thing, take it with a grain of salt. Be very clear about three things:

1. The target should be smart business – not smart processes per se.
2. Smart automation won’t go very far unless you specify the right things.
3. The things you need to specify are knowledge things, not process things.

(I suppose I could add there are no silver bullets, but I’m pretty sure you already know that.)

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 For me the point of knowledge (POK) is a real place.  POK is where elements of operational business know-how — business rules — are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen.  Knowledge is power, so  you can also think about POK as point of empowerment. POK corresponds to point of sale (POS) in the world of commerce.  POK and POS are similar in several ways:

• In both, something is exchanged.  In POS, it’s goods.  In POK, it’s operational business know-how (from here on I’ll just say know-how).
• In the world of commerce, we often say that consumer and supplier are parties in point-of-sale events.  Each of us is a consumer in some point-of-sale events, and many of us act as suppliers in others.  The same is true for POK.  Each of us is a consumer of know-how in some POK events, and many of us act as suppliers in others.  Sometimes we switch roles within minutes or even seconds.
• A well-engineered experience at the point of sale has obvious benefits both for the consumer — a positive buying experience — and for the business of the supplier — real-time intelligence about sales volume, cash flow, buying trends, inventory depletion, consumer profiles, etc.  A well-engineered experience at the POK likewise has obvious benefits.  For the consumer, it means a positive learning experience.  For the business of the supplier, the benefits include real-time intelligence about the ‘hit’ rate of business rules, patterns of evolving consumer (and supplier) behavior, emergence of compliance risks, etc.

The consumer/supplier experience at  the POK is crucial to worker productivity and job satisfaction.  In no small measure, optimizing this experience is the real challenge in POK engineering.  It must  be deliberate.  After all, what’s exchanged  at the POK is know-how — something you can’t carry around in your hands. Today, much of your know-how is tacit — lose the people, you lose the know-how they carry in their heads.  How can you avoid that?  Make the know-how explicit as business rules.  That’s what POK are about. Critical success factors in engineering an effective POK include:

• Communication must be strictly in the language of the business, not IT.
• Interaction must be gauged to the knowledge level (and authorization) of each individual party.
• Less-experienced parties playing the consumer role must be enabled to perform as closely as possible to the level of the company’s most experienced workers.
• Know-how — business rules — must be presented and applied in a succinct, highly-selective fashion.
• Know-how — business rules — must be presented and applied in a timely fashion (i.e., ‘just-in-time’) to accommodate fast-paced refinement and change in business policies and practices.

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the first one: Why is it that people discussing ‘knowledge management’ seem to have so little understanding of the core know-how actually needed to run (and change) day-to-day business activity? Core operational know-how consists of business vocabulary, business policies, and business rules. That ‘knowledge’ is currently locked away in IT applications and platforms (or in people’s heads) where it is virtually immune to change. That’s a boon to service providers and IT departments, but a bane to business agility. What business really needs today is agile governance … but few seem to be talking about that. P.S. Social media won’t help much here. You simply have to ‘do’ business rules.