The new knowledge paradigm, business knowledge engineering, is based on three fundamental insights:

Insight 1:  Your organization is in business because it knows something special.  It has the core operational business knowledge to carry out its mission.  That knowledge is invaluable.

Insight 2:  No new channels will ever emerge for which you will not need to know that operational business knowledge.

Insight 3:  That operational business knowledge is your business rules, criteria used in daily business operations to shape behavior or to make decisions.

What IT mostly implements under today's software platforms are not true business rules; rather, they are encoded representations of business rules.  If IT intervention is required to 'read' the stuff, you're not looking at true business rules.

True business rules are written in structured natural language (e.g., RuleSpeak^®) using standard business vocabulary.  They are about communicating knowledge, not requirements for software implementation.  True business rules are about running the business, not its systems.

Technologies come and go.  Your core operational knowledge, your business rules, will be with you for the long haul.  Ceding them to IT to be encoded in unfamiliar languages is no longer a viable solution.  Hardcoding them in yet another generation of platforms, digital or otherwise, comes with a long-term price tag we simply can't afford.

Challenge for Operational Excellence #1: 
Know your Customer

The first Big-5 challenge for operational business excellence is know your customer.

Achieving excellent customer experience requires a holistic view of customers.  Basing interactions on silo-ed channels can never achieve it.  You will be unable to unify their experiences with you or to leverage what you already know about them.

A simple case study illustrates.  What's true at a modest scale compounds itself many times over at mega-company scale.

Case Study:  We recently visited a county government of relatively-modest size in the Mid-West.  This county government administers six different programs for residents of the county, including social benefits, health care, job training, and so on.  One 'service' is incarceration — one you probably wouldn't want to use voluntarily (!).

Their six programs had emerged at different points in time and are supported by completely silo-ed organizational units using unintegrated apps.

What are the consequences for the individual citizen or resident of the county?  It basically means six different sign-up apps, each with its own rules and very little sharing of data.  As you might imagine, that looks pretty dumb to anyone who has already signed up for another program.

We gave the county a report card on its current state of affairs.  They got a C– on detecting fraud and abuse, a D– on routing calls and coordinating benefits, and a flat F on training new staff.

Why did this organization call us in?  Many of the usual factors were at play — key workers nearing retirement age, needing to do more with less, dissatisfied citizens and taxpayers (and state regulators).  To their credit they did realize that they had a basic knowledge problem on their hands — not merely a process problem, a data problem, or a 'digital' problem.  Kudos!

Now scale that case up orders of magnitude to an (anonymous) global mega-corporation.  Same symptoms, same diagnosis — through all their many channels for worldwide operations we found the same inability to produce a holistic view of international customers.  They weren't managing that basic operational knowledge as an asset.

Solving the know-your-customer challenge at any scale requires two essential ingredients:

1. A shared, structured, business-level vocabulary covering customers and products (a.k.a. a concept model).  Vocabulary is the most fundamental ingredient of sharable, retainable knowledge.


2. Business rules to govern both interactions with customers as well as dissemination of products and services to them — so that people can be taken increasingly out of the loop.

These two ingredients add up to a scalable, unified, sustainable approach to the knowledge necessary to achieve excellent customer experience.

Challenge for Operational Excellence #2: 
Closing Communication Gaps

The second Big 5 challenge for operational business excellence is closing communication gaps.  Note I purposely said close communication gaps — you want to close, not simply 'bridge' communication gaps (!).

In many respects professionals in our field have a very a limited view of 'communication'.  Yes, of course we need to close communication gaps on every project, and among all stakeholders, and with IT.  Though never easy, working to close those kinds of communication gaps should be a 'given'.

Instead, we need to talk about a broader kind of communication — the communication of operational business knowledge over time and space.  That requires some engineering.  Let me put this challenge into perspective.

I recently read an interesting post in social media by Angela Wick about user stories and their role in agile and other requirements methodologies.  The post depicted their role as addressing the tip of an iceberg, as in Figure 1.^[1]

    Figure 1.  The Role of User Stories in Agile and Other Requirements Methodologies.

Many agile gurus describe a user story as a placeholder for a conversation, or a promise of a future conversation.  That's a great characterization because it highlights the crucial point that user stories address only the 10% that you can 'see' above the requirements waterline.  Over time, each user story must be fully explored and all the hidden detail, the submerged 90%, filled in.

The crucial question is what does all that hidden detail represent?  A very sizable portion, certainly far more than half, is operational business knowledge — in other words, business rules.

Once you get that point, a next question naturally arises.  Do you really want business analysts and system developers to re-invent and re-specify and re-design all that knowledge from scratch on each new project?!  No!  There's nothing agile about that whatsoever (!).  That's simply re-inventing the wheel — over and over and over again.

We have clients telling us that they have achieved proven savings of 75% or more by having relevant business rules available before a project starts.

Pre-existing business rules allows project sponsors to launch projects on the basis of known facts rather than guesswork.  It can reduce the difficulty of a project by an order of magnitude and improve the chances of success dramatically.

You should want — actually you should demand — ready-to-reuse, fingertip business rules for projects.

That's where over-time-and-space communication comes to play.  Ready-to-reuse, fingertip business rules represents communication of operational business knowledge across organizational boundaries and through the passage of time.  Business excellence in the digital age is all about turning core knowledge from obstacle to accelerator by simply making it explicit.

Challenge for Operational Excellence #3: 
Business Agility

The third Big-5 challenge for operational business excellence is business agility.  Ask yourself, where is your company today with respect to agile business?  Not agile projects, not agile business analysis, but agile business?

• Do your business managers spend all their time making pinprick corrections to ongoing processes?


• Are they so consumed by fighting fires they have no time to attend to the bigger picture?


• Do they refrain from making simple course corrections because the IT costs are simply too high?

If these problems apply to your organization, your company has a knowledge problem.  It's time to start innovating with the right kind of approach, rather than always just reacting to what's broken or chasing the next big thing.  A new perspective based on managing operational business knowledge is the key to sustainable operational business excellence in the digital age.

What is true business agility?  We define it as follows:

business agility:  being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and business analysts can determine the full business impact of the change and assess whether the change makes good business sense

Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing.  All artificial (IT-based) production-freeze dates for deployment disappear and the software release cycle becomes irrelevant.  The only constraint is how long it takes business people and business analysts to think through the change as thoroughly as they feel they need to.

I'm deeply concerned that agile software development is taking us giant steps backwards in terms of achieving true business agility.  At some companies we visit, things are simply out of control.  The software development tail wags the business dog.

It's not just me who thinks so.  Here are some comments from recent conversations on social media:

"The business is now at complete mercy of IT Agile to the point where it's cut out of critical product and service decisions.…  IT agile delivery being seen as equivalent to agile/entrepreneurial business which is very far from the case."

— Donna Luehrman, MBA, CBAP

"Agile software development methodology is often antithetical to longer-term business agility and a short-sighted antagonist to the discipline required to achieve it."

— Howard Wiener, President, Codiscent Americas

Agile software development will never get you to agile business because it does not address operational business knowledge (business rules) in a direct or innovative fashion.  By coding faster and faster, many businesses are simply becoming more and more un-agile.  Untold millions of dollars are being sunk into instant legacy.  Worse, it may take untold billions of dollars to service that legacy over time.  That's not operational excellence; that's operational negligence.

If your current approach is based on user stories and use cases and the like, ask yourself these questions:

Question 1.  Do you address business rules directly in your requirements approach?  By 'directly' I mean in a systematic, traceable way.  Or, do you implicitly assume IT will just somehow just get them right?!  I think that's a very bad idea and a very big risk for operational business excellence.

Question 2.  What are you doing to ensure governing rules (see Challenge 5) are understandable by business workers and SMEs in the specific way that the business wants them to be interpreted and applied?  What are you doing about rules that aren't automatable?  Aren't those important?  And what are you doing to coordinate and disseminate this knowledge to line workers in a systematic, repeatable way?

Is there a place for agile software development?  Of course.  Just not when it comes to basic operational business knowledge (business rules).

Look at it this way.  Your business is in business because it knows how to do something.  That knowledge is the bulk of the iceberg.  Either you come to grips with that knowledge to steer your course or one day it could sink your ship.

Challenge for Operational Excellence #4: 
Knowledge Recovery, Renewal, & Retention

The fourth Big 5 challenge for operational business excellence is knowledge recovery, renewal, and retention. A senior manager at a major insurance company recently told us this:

"More than 60% of all our staff who know our tribal knowledge will retire in the next three years."

Hordes of baby-boomers are within their window of retirement.  Will you just sit and watch core operational business knowledge walk out the door?!

That's not all.  Organizations often spring a trap on their very best knowledge workers.  Lack of explicit, fingertip business rules pushes hero-professionals with deep tacit knowledge into static roles, narrow boxes with glass ceilings and no exits.  These workers simply become too valuable to re-purpose.  Their potential loss to the company puts it at great risk.

Companies need to be rediscovering what their business rules actually are, whether in the heads of hero-professionals or embedded in legacy code.

Mining business rules from legacy code raises special challenges.  They're often implemented in arcane, highly-procedural languages.  The person or team who wrote the code is often long gone (or perhaps in India somewhere).  Bringing them back into a form that business people and business analysts can understand is hard.

To illustrate, here is an as-coded example from a major bank:

For Primary Borrower or any Guarantor, IF [Processing Date – Credit Bureau File Since Date] is < 12 months AND the total # of Type Code of 'R' and 'O' trade lines is 3 or less AND the total # of 'I' and 'M' trade lines is zero AND the Industry Code = OC, ON, OZ, DC, DV, DM, DZ,
    Then result is Refer.

Obviously most business workers are not going to understand that specification or be able to validate what it says.  Actually, this example is well above average in readability — most coding languages are even farther removed from daily business parlance.  If you want to have real conversations with business partners, core business knowledge needs to be expressed in structured natural language (e.g., in RuleSpeak), making careful use of common business vocabulary.

The example above is interesting for another reason.  Note the outcome of the specification, the portion after the then, is "Refer", meaning that the matter in question cannot be resolved.  This specification actually does nothing but kick work back out to a human!

A specification that simply escalates a case to a human is not a true business rule at all.  Rather, it's an acknowledgement the actual business rule(s) still haven't been captured and encoded.  That knowledge lingers in somebody's head, maybe that hero-professional in the box with the glass ceiling and no exits.

Our broad experience in reverse-engineering business rules has exposed us to harsh reality.  First, there are no silver bullets.  Once business rules have been encoded procedurally, semantics are lost that cannot be resurrected automatically.  You've made a bargain with the devil.

Second, it is appalling, even frightening, how often the implemented business rules, once resurrected, prove to be wrong.  Here's one report from a highly-capable business analyst at a major insurance company:

"When we looked hard at business rules currently implemented in existing systems, we found at least 30% were flatly wrong."

That's not operational excellence; that's operational negligence!

The business analyst told us two more things.  First, he had asked IT whether they could solve the problem.  IT replied they couldn't because it was a business issue, not a software issue.  (And they were absolutely right!)  Second, he told us the actual figure was significantly higher than 30%, but he wasn't allowed to say so publicly.  Frightening!

Operational business knowledge can become lost or corrupted very, very easily.  Peter Drucker once said:

"Knowledge is infinitely more perishable than any other resource we have ever had."

Fundamental to this view is that knowledge is a corporate asset.  Like any asset it needs to be managed as a living-and-breathing resource — kept evergreen.

Translated into practice, managing operational business knowledge means capturing business rules, making sure they are right, and keeping them right over time.  You must work to ensure their deployment is timely, effective, selective, repeatable, pervasive, traceable, and retractable.

To achieve those objectives, you need business-side rule management.  Responsibility cannot be ceded to IT because it's not an IT problem!  Our current methods and mindsets require major adjustments in this regard.  We need to put ourselves on a true path to business excellence in the digital age.

Challenge for Operational Excellence #5: 
Compliance

The fifth and final Big 5 challenge for operational business excellence is compliance.  When I say 'compliance' I mean compliance in a broad sense, not just regulatory compliance — though that kind of course is often critical.

Compliance in a broad sense simply means always delivering on promises.  Even high-quality customer service involves compliance of this kind — your products and services are always what you say they are, and your delivery of them meets customers' expectations.

Three critical observations are necessary to come to grips with the compliance challenge.

Observation 1:  Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent obligations, the very essence of business rules.

Observation 2:  These obligations are constantly amended, extended, and (sometimes) terminated, so you need direct traceability for them.

Observation 3:  The typical IT view of traceability is far removed from what the business actually needs to manage obligations.

Many professionals are so immersed in system development they cannot easily separate the notion of obligations (business rules) and requirements — e.g., specifications for modifying some system feature or procedure.  Say 'traceability' and they immediately think traceability for requirements.

How system development needs to trace requirements into system designs is a very different proposition than the traceability needed for business obligations.  The two kinds of traceability can and should be separated.  Requirements are about building systems, whereas business rules are about running the business.  Requirements generally fade into the background when a system is delivered, whereas deployment sparks a whole new phase of life for business rules.

We need to carefully examine the form of traceability needed for business obligations.  Figure 2 sketches the lay of the land.

    Figure 2.  Lay of the Land for Traceability of Business Obligations (Business Rules).

The starting point in this landscape (at top) is all the sources of governing rules.  Governing rules provide the baseline for running the business.  These governing rules must be interpreted and supplemented, ultimately getting implemented in a wide array of platforms and tools (at bottom).

In most companies today there is virtually no traceability for obligations through the middle layer of the landscape.  There's an abyss, a big black hole, where there should be ready knowledge.  Where does that leave the company?

• Companies' corporate memory is riddled with disconnects and gaps.  Going back in time, it is difficult or impossible to determine who interpreted what governing rules into what implementation components, or why they did it the way they did.


• Companies consequently are deeply dependent on hero-professionals to retain tacit knowledge, the workers who live in those cramped, glass-ceiling boxes.  You hope they remember things correctly and thoroughly — and that they don't leave the company.

To speak plainly, most companies have no coherent strategy for integrated compliance.

A solution to the compliance challenge requires rethinking and reworking the traceability landscape for obligations.  A re-engineered landscape is illustrated in Figure 3.

    Figure 3.  Re-engineered Landscape for Compliance and Traceability.

This re-engineered landscape features three layers of rules, not just two.  The middle layer, practicable rules, is key.

practicable rule:  an expression of a business rule that a capable (authorized) worker can read and understand and decide directly whether or not the business is in compliance in all circumstances to which the rule applies

Practicable rules are ones you can run the business by, whether or not ultimately automated.  They should be expressed in structured natural language (e.g., RuleSpeak) based on business (not IT or data) vocabulary.  Here is an example:

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

The acid test for whether a business rule is practicable is this:

You can give the statement either to a knowledgeable worker for use in day-to-day business operations to apply manually, or give to IT for implementation in an automated system, and get the same results either way.

Is that possible?!  Absolutely!  We do it all the time.

The re-engineered landscape for compliance and traceability reveals the two distinct interpretations (the red arrows in Figure 3) that need to be tracked:

• First, governing rules are interpreted into practicable rules.


• Second, those practicable rules that can be automated (by no means all of them) are interpreted into specifications that automated platforms can execute.

Perhaps the need for the second interpretation will be eventually eliminated by software platforms — that's the goal of the standard Semantics of Business Vocabulary and Business Rules (SBVR).  It's absolutely required today, however, under virtually all platforms, including rule engines.

The number of rules at each layer of the traceability landscape expands significantly.  Figure 4 presents a rough sketch based on work we did at a Ministry of Health in Canada.

    Figure 4.  Sample Traceability Map.

The expansion in the number of rules occurs for two reasons:

• As governing rules are interpreted into practicable rules, greater granularity and specificity is required from a business perspective.


• As practicable rules are interpreted into automated rules, the expansion can become quite significant depending on what kind of platform (and how many) are used for deployment.  Individual practicable rules may require multiple points of evaluation and become highly disassociated.

The key to operational excellence for compliance is committing both kinds of interpretations explicitly to automated corporate memory right as they happen.  (By the way, business-side rule management does not have to be pursued at an enterprise scale.  You can start out at any scale, including the project level.)

Compliance people have told us many times they don't really want to know how you get the results you do, rather they want to know why you get the results you do.  That's exactly what business rules and traceability maps do — they tell you the why not the how.

If you're doing work where compliance is any kind of factor and you're not managing business rules, you're in over your head.  As a compliance manager at a major financial company recently said, "With business rules we have finally found an approach that really works."

A Single Source of Business Truth

Where are your business rules today?  For most companies the answer is everywhere in general and nowhere in particular.  The new knowledge paradigm, business knowledge engineering, is ultimately based on the notion of a single source of business truth.

Say 'single source of business truth' and many professionals immediately think it's about data or information or meta-data.  No!  I mean explicit operational business knowledge in the form of business rules along with comprehensive traceability.

What are the goals for a trusted single source of truth?

• Empower compliance


• Retain operational knowledge


• Enhance business agility


• Reduce 'maintenance' costs

Who would a single source of truth serve?  One audience is IT, but by no means is IT the only or even the primary audience.  A sample of various audiences is presented in Figure 5.

    Figure 5.  Sources and Audiences for a Single Source of Business Truth.

All audiences in an organization should be able to work off a single trusted source of truth for operational business knowledge no matter what their specific responsibilities.  No one should be reinventing the wheel at every go.

The new knowledge paradigm offers boundless opportunities.  Think about the potential for rapidly mainlining new business products.  Consider how it could be used to produce timely and highly accurate training materials for line workers.  When you start thinking about managing core business knowledge as an asset you'll be amazed at the ideas cropping up.  Digital won't get you there alone — knowledge is the fodder.

References

[1]  Angela Wick, User Stories:  You Don't Have to Be Agile to Use Them!
http://www.batimes.com/angela-wick/user-stories-you-don-t-have-to-be-agile-to-use-them.html  

For further information, please visit BRSolutions.com      

# # #