Make no mistake, the future lies with automation of white-collar work. Fewer and fewer business problems these days focus on manufacturing and production processes, i.e., the nothing-but-widgets category. For all the non-widget-centric business activity in the world – which includes just about all every conceivable form of white-collar work – the following needs become paramount.

1. Ensuring the quality of meta-data.
2. Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
3. Retaining, teaching and repurposing intellectual capital.

What would I do to correct the shortcomings of BPM for non-widget-centric business activity? Our answer is to become more why-centric, as opposed to narrowly how-centric.[1] You should focus on business capabilities, not just business processes. That shift has several essential features:

• Understanding business strategy as something distinct from business processes (and BPM). Business goals and business risks should be drivers of business process design – not the other way around. You need to be strategy-driven, not simply process-driven.
• Designing core metrics around business goals and business risks – the things that concern C-suite executives the most.
• Realizing that for white-collar work the 3-D world of widgets has vanished, and that tolerances and quality can be expressed only in terms of business rules.
• Treating business rules as a first-class citizen, externalized from process models.[2]
• Identifying operational business decisions (based on encoded business rules) as a crucial focal point in re-engineering business processes.
• Including a Why Button as part of every business solution. Pressing the Why Button leads immediately to the business rules that produced the results you see from any process.

~~~~~~~ Read more about the future for processes: BPM and the Knowledge Economy: Nothing But Widgets? http://www.brsolutions.com/2015/11/16/bpm-and-the-knowledge-economy-nothing-but-widgets/ What is the Future for Processes? http://www.brsolutions.com/2015/11/09/what-is-the-future-for-processes/ 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

	Interrogative	Basic Business Question	Kind of Model
1.	What	What inventory of things needs to be managed to support business activity?	structural model (e.g., concept model[1], data model)
2.	How	How do transforms of things in business activity need to take place to add value?	process model
3.	Where	Where does business activity occur?	network model
4.	Who	Who collaborates with whom to undertake business activity?	interaction model (e.g., organizational chart, use case)
5.	When	When does business activity take place?	temporal model (e.g., schedule, event model, milestone model)
6.	Why	Why are results of business activity deemed appropriate or not?	strategy model (e.g., Policy Charter[2], constraint model)

  If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others. Your overall approach and architecture will reflect that. You will naturally gravitate toward BPM. That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:

• Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks. E-suite executives tend to be much more focused on the latter.
• Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them. As a result your process models will be unnecessarily complex and your overall solutions un-agile.
• You approach will fall woefully short in addressing the intellectual capital that underlies your processes. Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.

Fewer and fewer business problems these days fall into nothing-but-widgets category. Even for widget-centric businesses, at least three needs are increasingly urgent:

1. Ensuring the quality of meta-data.
2. Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
3. Retaining, teaching and repurposing intellectual capital.

These are not strengths of common BPM practices. ~~~~~~~ Read more about the future for processes: What is the Future for Processes? http://www.brsolutions.com/2015/11/09/what-is-the-future-for-processes/ 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

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. ~~~~~~~~~~~~~~~ www.BRSolutions.com

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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

My December 8 blog post about classifying business process approaches generated an avalanche of responses. See the 2×2 matrix itself (from John Mansfield of Fidelity Investments) and the stream of Comments about it on http://www.brsolutions.com/2014/12/08/a-10000-foot-view-of-the-business-process-space-is-it-correct-is-it-complete/. In the guest post below, Brett Champlin shares his evaluation of the matrix. ~~~~~~~~~~ There are many things wrong with the matrix. 

• Lean and Six Sigma are both process improvement methodologies and are frequently combined as Lean Six Sigma. So they can all be subsumed into a category of process improvement methods.
• The matrix leaves out classic process redesign methods which are very commonly used. These methods go beyond improvement methods to respond to things like automation, new products, M&A, etc. where the basic process is modified or extended to accommodate some new situation.
• Process improvement and redesign methods along with reegineering (aka process transformation and/or innovation and/or reinvention) are all process change methods. Change management should certainly accompany them all.
• The matrix also leaves out Business Process Management as an all-encompassing discipline that deals with all types of process change as well as strategy, monitoring and measurement, and process portfolio management.
• It also leaves out Customer Experience Design, which over the last several years has been incorporated into many BPM toolkits as a precursor to any process change effort.

The dimensions mapped in the matrix are really those that are the core focus of the two improvement methods: Six Sigma focuses on defects and variation, while Lean focuses on waste and flow. In those terms, the diagram is more or less accurate, but it hardly covers the Business Process space in its entirety. I have used the matrices in Figures 1 and 2 (below) for that purpose.  Jeston & Nelis presented several 2×2 grids mapping different process change methods relative to time and cost and degree of change. These grids give a different perspective and are more complete, but still don’t cover the entire business process space. See Figures 3 and 4 (also below). Most of these types of analyses are continuations of industrial engineering perspectives. They are fine if that aligns to your needs, but today many businesses are looking beyond ‘faster, better, cheaper’ as the only way to measure their processes. These days many businesses take control of quality, waste and flow as a ‘given’. They are looking at other things such as customer attraction/engagement/retention, business agility (not IT agility), strategic positioning, etc. All of these perspectives are not easily represented in a simple 2×2 grid. Figure 1.                     Figure 2.                       Figure 3.                         Figure 4.

Knowledge worker is a term bandied about in discussion of business process management (BPM). Is it synonymous with white-collar worker, or different? How do you use the term? I ask because there’s significant new and significant interest in automating new areas of white-collar work so as to render it more consistent, traceable and scalable. That requires capturing and encoding the know-how as business rules and on a broader scale, engineering and automating operational business decisions. Knowledge is a very far-ranging term, and there are many forms of knowledge beyond day-to-day operations of a business. Does it confuse the issue to call white-collar workers “knowledge workers”? Is knowledge worker perhaps a broader term than white-collar worker? Which term works best in your organization? Here is some background information from Wikipedia. I confess I have never heard the term gold collar before, but it seems to me there’s an important potential difference there. White-Collar Worker

A white-collar worker is a person who performs professional, managerial, or administrative work. Typically, white-collar work is performed in an office or cubicle. Other types of work are those of a blue-collar worker, whose job requires manual labor and a pink-collar worker, whose labor is related to customer interaction, entertainment, sales, or other service oriented work. Many occupations blend blue, white and/or pink (service) industry categorizations.

Knowledge Worker

Knowledge workers are workers whose main capital is knowledge. … What differentiates knowledge work from other forms of work is its primary task of “non-routine” problem solving that requires a combination of convergent, divergent, and creative thinking.

Knowledge workers are employees who have a deep background in education and experience and are considered people who “think for a living.” They include software developers, doctors, lawyers, inventors, teachers, nurses, financial analysts and architects. As businesses increase their dependence on information technology, the number of fields in which knowledge workers must operate has expanded dramatically.

Even though they sometimes are called “gold collars”, because of their high salaries, as well as because of their relative independence in controlling the process of their own work, current research shows that they are also more prone to burnout, and very close normative control from organizations they work for, unlike regular workers.

www.BRSolutions.com

The best way to simplify business process models is to take the business rules out and address them separately. Example: For a large pharmaceutical client, we reduced a complex 28pp model to just under 4 pages by doing that – nearly an order-of-magnitude reduction in size (and probably even more in terms of complexity). Everyone loved the results. There was nothing unusual or atypical about the result – we’ve seen it happen many, many times. By the way: If you know of similar cases, I’d love to hear about them!

Here’s a short clip about business rules from an interview in Amsterdam not too long ago. I actually agree with what I said … http://www.youtube.com/watch?v=fhv7bGf3r3Y&feature=related There are several related clips there with John Zachman, Roger Burlton, and Silvie Spreeuwenberg (LibRT) worth a few minutes of your time — business rules, decisions, business processes, enterprise architecture, and more.

On an EA LinkedIn group last week, Nick Malik wrote the following about business rules in Zachman Framework 3.0: “I’ll bite. If the ‘enterprise ontology’ is similar to the periodic table of elements, then business rules are molecules. They are compositions of elements with specific implications, embedded in event handling logic. Why would you expect to see them, or models of them, on the Zachman Framework? OK… that was my humble, and perhaps uninformed, opinion. You are the master of business rules. You tell me where you’d see them.” Nick, You know the definition of ‘master’, right? Same as ‘expert’ … someone who has made all the known mistakes. Zachman and I have had over-dinner conversations for many years about the question of where business rules fit (or don’t) in the Framework, even more so in the past couple of years. I won’t speak for John, but I think he agrees. Yes, business rules are ‘molecules’ and yes, they are ‘composites’. So you don’t see business rules anywhere in Framework 3.0. Instead, if you look at the new cross-column thin gray lines, at row 2 in particular, some or many of those could be business rules. Aside: For convenience, here’s a zipped pdf of the new 3.0 version (with permission): ZF3.0.zip [approx 1.5M]. Visit Zachman’s new website for all the latest. The thing about molecules or composites – unlike the primitives – is that they can be conceived in many different ways. Each conceptualization leads you to a different representation approach, and each representation approach leads you ultimately to a particular implementation strategy. Some implementation strategies, of course, are better than others (by a mile!). Moving Beyond the Big-P Approach At the risk of over-simplification, you have two basic choices for conceptualization, and ultimately implementation, of composites: procedural or declarative. Historically, we have embedded business rules in process models and in procedural code. We have taken the column 2 (how) primitive, process, and used it to create composites. At the scale of today’s business, this Big-P process paradigm simply doesn’t work. Why? The thin gray lines in Zachman 3.0 are really about how the business is configured for operation. (At row 6 the thin gray lines represent the current actual configuration of the operational business.) In the Big-P paradigm, all building-block ‘molecules’ become thoroughly entangled with flow (input-transform-output). The result is essentially a semantic dead zone. You’re never sure what things really mean, and you can’t easily disentangle them. There are no built-in impediments to replication … and no opportunity to use logic to automatically evaluate configurations (models/designs) for conflicts, anomalies and other logical defects. Aside: The Big-P approach also has implications for data models. In current practices, there is no way to automatically perform any meaningful verification of data models either. The future lies with granular, declarative, semantically-rich specification of building-block composites (‘molecules’) for configuration. I know I used the ‘S’ word there (‘semantics’) but I’m simply talking about structured business vocabularies (SBVR-style fact models). Fact models, by the way, must cover anything with a name, including instances from columns 2-6, so they too are composite rather than primitive. Aside: Was I happy to see John use the ‘O’ word (‘ontology’) in 3.0? I think I know why he did it – to emphasize the Framework is not a simple taxonomy, but rather something rigorous enough to potentially reason over. I’ll let others judge that choice. Re-factoring the Big-P Paradigm Clearly, business rules are one building-block composite for disentangled forms of enterprise configuration. Another thing not considered a primitive – Nick mentioned them – are events. They too possess the granular, configurable potential of business rules. And yes Nick is right – events and business rules have a very close relationship, one not widely appreciated. (If the industry did, it would already be taking a very different approach to process modeling.) Aside: But no, Nick, I would not ’embed’ business rules in ‘event handling logic’ … no more than I would embed ‘event handling’ in business rules. Unfortunately, expert systems do allow you to do that. What else do we need as building-block composites to configure an enterprise at a given point in time? Let me propose decisions – but with caution. ‘Decision” is the buzzword de jeure. No, decisions are not a cure-all, no they do not replace business rules or events, and no they do not solve all our problems. But in proper perspective, yes, they are most definitely a building-block composite. Smart Configuration Models Big-P configuration of the enterprise is like setting it in concrete. To replace that flagging paradigm we need smart configuration models. Such models will feature at least: (a) business rules, (b) business events, and (c) operational business decisions. And of course, structured business vocabularies (fact models). Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I see no alternative. By pinning down the primitives definitively in 3.0, Zachman has opened the door to a whole new realm of rich architectural potential. But there’s more. Smart configuration schemes must address additional challenges facing business today. These include business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book coming out the end of September, we call systems built using smart configuration schemes business operation systems (BOS), as opposed to ‘information systems’. I think you’ll find these new ideas quite exciting. Watch for them!

@SergeThorn asks “Are Business Process Management and Business Architecture a perfect match?” http://goo.gl/kLYvs With business rules far better! There is an important overlap of concerns between business rules and enterprise architecture. The overlap actually comes in two forms: 1. Operation-time. Here the issue is really rethinking compliance. I just blogged about this today: http://goo.gl/Gl9wT 2. Business-analysis-time. A business needs to know the rules it plays by. That inevitably brings you to rulebook management. For more: http://www.brcommunity.com/b500.php?zoom_highlight=rulebook (and other articles).