In the knowledge economy, more and more the problems of interest for automation focus on white-collar work.  That trend will only increase — and increase rapidly — over time.  The goal for white-collar work is to standardize the results and make them repeatable.  But consistency in customer experience on knowledge-based work is hard to achieve with humans in the loop. White-collar workers make operational business decisions day-in and day-out.  Many people think such white-collar work is a matter of art, not engineering.  They're being proven wrong.  In this first part of a three-part Q&A I answer some questions on the latest developments in business rule and decision engineering.

Q:  You've often said that business processes and business rules are highly complementary.  Any change in your views on that?

A:  No, not in the least.  Each technique complements and enhances the other.  But we're now expanding the envelope in new and exciting ways.

Here's what we already know.  Separating the capture and analysis of business rules and decisions simplifies a business process model dramatically — often by an order of magnitude or more.  We've proven that many, many times with our clients.  It also provides new points of leverage and remarkable benefits in achieving agility, consistency, and re-usability.  It's a big win-win.

Q:  What's the latest in the space?

A:  New ideas are emerging at a blistering pace, driven by the broad need for significant business innovation.  Much of the focus we're seeing these days is on white-collar work.  Companies are looking to automate things never automated before.  What that means is tackling the implicit know-how in workers' heads and making it explicit.  How?  As business rules of course.

So we need to be very clear about the distinction between the white-collar aspect of work vs. the blue-collar aspect.  Seems obvious, but I'm not so sure it always is.  If you are not directly running an industrial or manufacturing process, or operating heavy machinery, then chances are the process is a white-collar one.

It's not that white-collar work hasn't already been addressed by automation — it has.  It's that the degree of automation in most cases remains very basic compared to what can be done — and what will be done in the near future.

Q:  Can you clarify exactly what you mean by white-collar work and white-collar processes?

A:  A great many problem domains are purely white-collar — for example, approving home mortgages, adjudicating claims, providing financial services, etc.

To take a different kind of example, suppose you are managing repairs to a city's water supply or sewage system.  That means identifying, prioritizing, and scheduling job tasks, then organizing appropriate follow-up to determine whether the work was properly done.  That's white-collar work.  The actual repair work is blue-collar; the organizing of the work is not.

Or suppose you are organizing inspections of ships for safety, to provide certifications for insurance purposes.  The actual inspections might be blue-collar, but the larger problem of organizing inspections and awarding certifications is white-collar.

In a knowledge economy, more and more of the processes of interest for automation these days are white-collar.  And that trend will only increase — and increase rapidly — over time.

Q:  What are the drivers behind this fresh look at white-collar work and processes?

A:  To bring it into proper perspective we have to go back in time.  The father of scientific management in manufacturing was Frederick W. Taylor, who around 1900 brought tremendous efficiency to the steel industry.  His goal for blue-collar processes was essentially to dumb-down the work as much as possible, to remove all decisions from the actual production activities.

The emphasis was not just on standardizing work and making it repetitive, but in many respects to make it mindless.  Taylor naturally produced storms of protest and resistance from labor in promoting his approach, and it became a major political issue of the day.

For white-collar work today, the goal is similarly to standardize the results and make them repeatable.  There's also the same focus on efficiency.  Those goals are not so different.

But there are other new drivers.  One is the need for consistency in customer experience.  That's hard to achieve with humans in the loop.

Another is what I call white-collar entropy — the tendency of people doing knowledge-based work in large organizations to become less-and-less well organized over time.  Companies are starting to look seriously at reversing that effect.  Managing entropy at scale becomes virtually impossible — even if an organization happens to have plentiful resources.

Q:  Where do business rules fit into the picture?

A:  In white-collar work, people are making operational business decisions, day-in-and-day-out.  You can't simply dumb-down that work.  But computers are so much more powerful these days you can now harness them for the task.  In other words, you can let machines make the operational business decisions.

To do that though, first you need to capture the know-how to make those decisions and encode it.  The only practical, scalable approach to capturing and automating such know-how is as business rules.  Companies are taking a hard look at doing just that.

Q:  How does taking a fresh look at white collar work and processes typically unfold in an organization?

A:  Companies often discover some grim realities.

For example, what's written in policy & procedures manuals quite often isn't at all aligned with what's actually happening in the field.  Nor does it align with what's currently implemented in the computer systems.  As a result there is significant variation across the organization about how the decisions are made.  There's far-ranging inconsistency, low repeatability, and much less transparency and accountability than you would imagine or desire.

As a consequence, companies are finding they must contemplate what rules they actually should be following.  That leads to even deeper thinking about core strategies and business policies with respect to the marketplace.  That thinking isn't easy, but it always turns out to be a very healthy exercise.

Q:  What are the implications for business process modeling?

A:  As I've said, white-collar processes are generally decision-making processes, so it is absolutely essential you know what the business rules are.

So the question arises:  How can you model a decision-making process without knowing what the business rules are?  The business rules dictate what inputs you need.  That certainly turns things on their head.  It's a huge insight.

At a broader level, you begin to look at the whole problem differently.  Instead of heads-down, step-by-step process modeling, you realize you must come to grips with the complexity of the core decision.  Should we give this person a mortgage or not?

That core decision can be posed as a question, then decomposed into sub-questions to as many levels as needed to get you to the rules.  The result is what we call a business question chart — a Q-Chart for short.^[1]

A Q-Chart is a completely new kind of deliverable — one that is very clean and very business-friendly.  It is again highly complementary to business process models.

We see clients mapping their Q-Charts to end-to-end business processes in new and novel ways.  That helps them see the whole business problem differently, and to search for ways to get to the end-result decision faster, with less overall work.

The goal is what we call 'ASAP decisions' — getting the business into the position of being able to make a decision, even if only a contingent one, as soon as possible.  That's good for customers and it's good for the business itself.

Q:  Is it really possible to capture 100% of the rules needed to make operational business decisions?

A:  Maybe yes, maybe no.  The answer depends on many factors, including your tolerance for diminishing returns.

But I think the question misses the point.  The goal is not to automate 100% of the operational business decisions and to make all tacit know-how explicit.  Rather, the goal is to achieve an order-of-magnitude improvement in consistency.  That alone has huge value.

Q:  Do you encounter resistance to the approach?

A:  Of course.  There's typically some resistance from white-collar ranks, just as labor resisted the innovations of Frederick Taylor.  Many people still think most white-collar work is a matter of art, not engineering.  But they're being proven wrong.

Q:  You talk about white-collar workers, but not knowledge workers.  Why?

A:  'Knowledge worker' is a term traditionally used in BPM and related re-engineering work.  If I understand correctly, a knowledge worker is viewed as someone who has to use his or her own thinking to accomplish something, not simply perform a task.

But that's pretty much the crux of the matter.  If knowledge workers must use their own, unique thinking, then you can't capture that know-how as business rules and automate it.

That's why I prefer to say 'white-collar worker' rather than 'knowledge worker'.  You really have to be careful these days not to make assumptions about what work can be automated.

Q:  So are you suggesting we simply replace the term 'knowledge worker' with 'white-collar worker'?

A:  No, it's not that simple.  Actually, there is a whole range of workers in companies who might be called 'knowledge workers' — so large a spread that the term blurs important distinctions.  Separable from white-collar workers is a whole class of highly-educated enablers often labeled 'gold-collar workers'.  These workers focus primarily on non-routine problem solving requiring a combination of convergent, divergent, and creative thinking.

So instead of just talking about knowledge workers, I believe we'd be much better off dividing the professional world into at least white-collar workers vs. gold-collar workers.  Gold-collar workers establish the requisite conditions in which white-collar workers can make effective operational business decisions.

Q:  Can the work of gold-collar workers be automated too?

A:  I have a hard time conceiving it.  But never say never.  In any case it's not right around the corner.

Q:  Why not just let IT figure out the business rules for automating operational business decisions?

A:  Look at it this way.  If you have no explicit business rules enabling people to do something correctly and consistently, you'll have no rules for a machine to do it right.  Except for speed and memory, machines are no smarter than people.  The test of high-quality business rules is whether people could do it right.

It's shocking to me how many people think they can just use a BRMS or decision management platform to address a problem without having to express the rules clearly to other people first.

I guess the silver bullet syndrome will always be with us.  In any case, making tacit know-how explicit as business rules is first and foremost a business and communication problem — then and only then a platform and implementation problem.

Q:  Couldn't development of business rules itself be automated?

A:  Not for the foreseeable future.  Developing business rules will remain professional work for gold-collar workers — even if increasingly assisted by machines.  Fortunately effective techniques for developing high-quality business rules have been proven in practice.^[2]

Q:  What's the critical success factor for automating operational business decisions?

A:  The key characteristic of many operational business decisions is that they need to be directly traceable to business policy, regulations, contractual obligations, and so on.  You need to be able to readily demonstrate compliance in the broadest sense of the word.  That of course has always been true for business rules.  That's what they do!

Q:  Does engineering operational business decisions produce intelligent processes?

A:  I know some experts are calling for smart processes or intelligent processes these days.  But if they're not addressing business rules, their processes are not really business-smart.  We need to enable smart business, not just smart processes.

In part 2 of this three-part series, I will make the case for retiring the term 'knowledge worker'.

For further information, please visit BRSolutions.com      

References

[1]  Ronald G. Ross, "Modeling Decision Structures — Part 2:  Question Charts (Q Charts™) and Hybrid Diagrams," Business Rules Journal, Vol. 14, No. 10 (Oct. 2013), URL:  http://www.BRCommunity.com/a2013/b722.html  

[2]  These include platform-independent expression guidelines such as RuleSpeak (free on www.RuleSpeak.com).  In our book Building Business Solutions:  Business Analysis with Business Rules we explain patterns for harvesting business rules from business process models and other deliverables.  We have also developed highly effective techniques for decision engineering.  See our Primers (free):  http://www.brsolutions.com/publications.php#primers  

# # #