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) and on business rules expressed in structured natural language. 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/
Quality must be viewed very differently in the white-collar world. The traditional view simply doesn’t fit.
In Henry Ford’s day, for example, central to the concept of mass production was standardization of parts. That idea leads directly to the notion of manufacturing tolerances – i.e., upper and lower limits for parts in 3-dimensional space. The goal is to ensure physical interchangeability of physical parts. That idea is now standard practice, of course, across manufacturing and production sectors.
But what are the ‘parts’ in white-collar work? White-collar processes simply don’t deal with physical things. How can you identify tolerances for them in 3-dimensional space? You can’t! In a very real sense, the ‘parts’ in white-collar work are literally just bits and bytes.
If not tolerances as a basis for quality, then what’s the proper focus? My answer: consistency and reliability of results.
For example, if I visit ten different branches of the same bank about getting a mortgage for my dream home, shouldn’t I get the same answer on my application from all 10 branches?! As you perhaps have experienced yourself, that’s not the way it works in many banks today. So one aspect of quality in white-collar work is the consistency and reliability of operational business decisions.
Another aspect of quality concerns compliance. Every business is subject to ever growing numbers of (take a deep breath here) … acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, prospectuses, citations, certifications, receipts, legal notices … and the list goes on.
Shouldn’t I expect consistency and reliability of results with respect to all those obligations and commitments? I believe we should. If it’s not about quality, then what?!My conclusion:When there isn’t any physical product from a business process, quality and defects must be measured by consistency and reliability of results, which are in turn always purely a matter of business rules.
For background on this post, see: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/
Everyone wants high quality from their business processes. But what exactly does quality mean these days? Let me tell you a quick story that recently got me thinking.
I like to eat toasted raisin bread in the morning. I even have a favorite brand. Every morning when I’m at home I eat several pieces. Over the years I’ve become so experienced with the brand’s quality that I can spot defects. I know when they’ve laid on the cinnamon a little too heavily, or when the dough didn’t rise quite enough. Every morning I look forward to doing my little AM taste test.
But one morning recently I suddenly realized the large majority of client processes we’ve worked with over the last decade are not ones I can perform any taste test for. There’s nothing physical from the process I can taste or hear or touch. There’s nothing whatsoever to directly assess quality by.
That’s because some clients simply have no physical products at all – e.g., insurance, finance, taxation, etc. But a good number do – e.g., electrical equipment, trucking, railroads, and so on. For these latter clients the processes of immediate concern didn’t directly involve those physical things however – only just white-collar stuff.
So the question becomes how do you assess quality from a business process when there’s no physical product? How do you identify defects when there isn’t any physical result?
My conclusion:When there isn’t any physical product from a business process,quality and defects are purely a matter of business rules.
If you’re not documenting and managing business rules as part of your BPM or quality management approach (or elsewhere) you’re missing a crucial part of the picture.
I wouldn’t go so far as to say that process and BPM are meaningless across the board in the digital economy. If you’re manufacturing or producing a physical product, you still do need to think in terms of a modeled and managed business process.
Other the other hand, if your products are non-physical – for example, money, time, skills, information, meta-data, etc. – you’d better have a major re-think. The old rules of the game simply don’t apply to white-collar work. Nor do they apply if your business model is about digitally leveraging other people’s idle assets – think Uber.
You must still consistently satisfy contractual obligations and regulatory constraints in this new digital world of course. But that’s a business rules problem, not a process problem.
A major characteristic of the new digital world is that activity is never static in any sense of the word. You simply get no points for hardwiring repetitive behaviors. You must:
Continuously make informed operational decisions in the blink of an eye (actually often faster than that).
Selectively respond to changing circumstances with subtle adjustments.
Be as dynamic as possible, yet still produce outcomes of predictable, consistent quality.
These too are business rule problems, not process problems.
Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php
Get it on Amazon: http://goo.gl/HXxN1fWhat It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide.
Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ
New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3.
The standard Semantics of Business Vocabulary and Business Rules (SBVR) offers fundamental insights about how to express business rules well. These common-sense insights can and should directly inform all expression of business rules – and any language that purports to support them. The first of these insights is the notion of practicable, which I discussed in my previous post. See: http://www.brsolutions.com/2015/06/29/practicable-insight-for-expressing-business-rules-well/The second of these insights is the principle of wholeness. The descriptive text below is taken directly from SBVR itself.Wholeness essentially means each business rule statement can be taken as fully trustworthy even in isolation from all other rules. The principle precludes priority schemes and rules that disable other rules, both of which can act to make any given rule less than fully trustworthy.~~~~~~~~~~~~~~~~~~~Principle: An element of guidance means only exactly what it says, so it must say everything it means.
Explanation: Each element of guidance must be self-contained; that is, no need to appeal to any other element(s) of guidance should ever arise in understanding the full meaning of a given element of guidance.
The full impact of an element of guidance for a body of shared guidance, of course, cannot be understood in isolation. For example, an element of guidance might be in conflict with another element of guidance, or act as an authorization in the body of shared guidance. The Wholeness Principle simply means that if a body of shared guidance is deemed free of conflicts, then with respect to guidance, the full meaning of each element of guidance does not require examination of any other element of guidance. In other words, each element of guidance can be taken at face value for whatever it says.
The standard Semantics of Business Vocabulary and Business Rules (SBVR) offers fundamental insights about how to express business rules well. These common-sense insights can and should directly inform all expression of business rules – and any language that purports to support them. The first of these insights is the notion of practicable. The descriptive text below is taken directly from SBVR itself.Practicable essentially means all ambiguity has been resolved. As a result, a practicable business rule can be given either to workers to apply ‘manually’, or to IT to implement under some platform, and the results will be exactly the same either way (barring human error or malfeasance).~~~~~~~~~~~~~~~~~~~~~~~~~~Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is understood
Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [Oxford Dictionary of English] Notes:
The sense intended is: “It’s actually something you can put to use or apply.”
The behavior, decision, or calculation can be that person’s own.
Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it.
For a behavioral rule, this understanding is about the behavior of people and what form compliant behavior takes.
For a definitional rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others.
A practicable business rule is also always free of any indefinite reference to people (e.g., “you,” “me”), places (e.g., “here”), and time (e.g., “now”). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to “tell” time), and (b) external clarification.
What is done to create value-add (business processes).
What ensures value-add is created correctly (business rules).
Many professionals are unclear about the respective roles of business processes vs. business rules. At the risk of stating the obvious, let me make the following points.
Business processes and business rules are different. They serve very different purposes: A business process is about doing the right things; business rules are about doing things right.
There is no conflict whatsoever between business rules and business processes. In fact, they are highly complementary. Each makes the other better. If they don’t fit hand-in-glove, somebody is simply doing something wrong.
You need both. Neither can substitute for the other. Period.
Rule Independence means that business rules are expressed directly, rather than embedded (and lost) in the flow of processes or application programs. That way the rules can be managed as an asset in their own right, separately from other artifacts.When people hear ‘separately’ sometimes they think that business processes and business rules are isolated from one another and never ‘talk’. No. You simply want to let them ‘bind’ as close to real-time business operation (‘run-time’) as possible.‘Separately’ also means you can:
Represent business rules in their natural form – declaratively – rather than procedurally.
Simplify processes hugely, while at the same time create far more agile solutions.
Rule independence yields another benefit – reusability. By externalizing business rules from applications, you can single-source your business logic.
Methodologies for business analysis that are comprehensively rule-friendly do exist and have been proven in practice. They show you how to:
Capture, express and validate business rules.
Work with the business rules in the context of other deliverables.
Set up the business rules to be managed for the long term.
Charles Darwin is reported to have said, “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” Becoming more responsive to change is simply not optional these days. Consider the current state of affairs in IT today. The statistics are depressing. Reliable sources indicate that over 75% of all IT resources go toward system ‘maintenance’. That’s not agile! In the second of edition of Building Business Solutions: Business Analysis with Business Rules, Gladys Lam and I describe this world as like living in change deployment hell.You might say that legacy systems are poorly engineered, but I believe that misses the mark. Rather, perhaps they are be over-engineered. What happens when you over-engineer something? The solution you produce is too stiff or too rigid or too cumbersome for the real-world problem. Think ‘tree that doesn’t bend with the wind’. The speed of business is accelerating, yet the architecture of traditionally-built systems is rigid and static.The fundamental problem in this regard is embedding business rules within the systems themselves. If you hard-code business rules into application logic, they will be hard to find, hard to understand, and even harder to change. Do we really want to keep building systems that way?!Make no mistake about it – many business rules will change. So if you continue hard-coding business rules into systems, you will be revisiting the code … a lot! That might be a good thing for service providers, but it’s not a good thing for the business.The obvious solution is to engineer business rules separately from functional requirements. Can you do that cleanly and effectively? Absolutely. It’s been proven many, many times. ~~~~~~~~~~~~~~~~~~~~~~~~~www.BRSolutions.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.”