Analyzing and modeling operational business decisions has become a new industry focal point in the past few years. Business-and-rule-friendly techniques have emerged[1], and just this year an OMG standard[2]. These resources address such important questions about operational business decisions as:

• How are they structured?
• How can they be decomposed?
• How can you capture related business rules?

Decision engineering also provides an opportunity for a fresh look at decision tables. Just to be clear, decision tables themselves are not new. They’ve actually been around longer than software engineering, at least back to the 1960s. What’s emerging today is a fresh way of looking at decision tables from a business rather than a software perspective, and important new ideas about how they can help address complexity.[3] ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

There are two fundamental kinds of business rules: behavioral rules and decision rules.[1] Behavioral rules are rules people can violate; decision rules are rules that shape knowledge or information. Decision rules cannot be violated – knowledge or information just is what it is defined to be. Common to all business rules, no matter which category, is that you want them directly traceable for compliance and other purposes. How do  behavioral rules and decision rules apply differentially to service workers vs. white-collar workers vs. gold-collar workers? Service workers are primarily subject to obeying behavioral rules, or are charged with applying them. Examples:

• A counter attendant must not accept a credit card for a purchase under $10.
• A flight attendant must ensure passengers have buckled their seat belts for each take-off and landing.

Service workers are subject to operational business decisions made by white-collar workers, but do not play a significant role in making such decisions themselves. White-collar workers are typically involved in business processes where operational business decisions are made. Examples:

• Should this loan applicant be given a mortgage?
• What flight crew should be assigned to this flight?

White-collar workers generally do not define decision rules themselves – that’s typically work for gold-collar workers. Where such rules are incomplete, unspecified or contradictory, however, white-collar workers generally rely on personal heuristics and experience to make decisions. This approach puts the main goals for white-collar work – consistency and traceability – at jeopardy. White-collar workers, like all workers, are subject to behavioral rules. Examples:

• A loan officer must not handle a loan application placed by a family member

• The website description for a new product must be approved by two senior managers.

Gold-collar workers (for explanation see http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/)[2] are responsible for non-routine, knowledge-intensive work. The primary goals for such work is that it be insightful (e.g., as in the case of medical diagnosis that fits the available data better) or creative (e.g., as in the case of a new marketing strategy). This type of work is generally beyond the scope of decision rules. Although gold-collar workers often conduct their work in relatively independent fashion, the work is generally subject to “very close normative control from organizations they work for” [Wikipedia]. Think medical malpractice or following generally accepted principles of accounting. These normative controls, since they can be violated, are sets of behavioral rules. www.BRSolutions.com

Pink-collar worker is a term sometimes used (in the U.S. at least) to refer to a job in the service industry. Many people find the term off-putting because it traditionally referred to jobs relegated to women. I avoid the term for several other reasons. The category includes:    

• Such people as nurses and teachers, who are clearly gold-collar. (For explanation of gold-collar work, see http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/)
• Such roles as buyers, loan interviewers, dieticians, administrative assistants, etc., whose work at the high-end should be considered white-collar.
• Many workers providing personal services on an individual basis, rather than business services in the usual sense. Examples include midwives; hairdressers and barbers; baby sitters and nannies; personal shoppers and fashion stylists; etc.

Clearly many businesses do have extensive staff that is neither white-collar nor gold-collar working to deliver services. Examples include retail workers, sales staff, flight attendants, hotel housekeepers, counter attendants, receptionists, etc. I just call them service workers since they don’t have any traditional uniform color – white, blue or otherwise. Are service workers subject to business rules? Absolutely. Generally these rules are behavioral rules rather than decision rules, however, since their jobs do not focus on operational business decisions. More about that in my next post. www.BRSolutions.com

Some people argue that a knowledge worker is someone who gets paid to improvise or innovate, a factor distinct from the amount of training the worker receives. By this criterion even blue-collar workers can be considered knowledge workers if they constantly improvise or innovate. I don’t find the notion helpful. In my mind, a blue-collar worker who is constantly improvising or innovating, for example, has become an engineer – which is gold-collar, not blue-collar. (For explanation of gold-collar work, see http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/) With respect to white-collar work, what I see in many organizations is white-collar entropy, all resulting from continuous and counterproductive ‘improvising’. A vacuum of coordination filled with too much information simply does not translate into a more productive organization. The more likely result is inconsistency, the enemy of good customer experience. The improvise-and-innovate argument also holds that knowledge workers don’t just apply rules – they invent rules. Hang on a minute. To take a real-life example, do we really want police officers (officers on the beat) inventing rules?! I think not. Their job is to apply rules (laws), not invent them. Otherwise we’d be living in a police state. In a well-run organization, just as in society, above all you want consistency at the operational level. If I call my bank ten different times, I should get the same answer ten different times. If I apply for a mortgage from the same bank at ten different branches, I should get the same result ten different times. In my experience, that’s hardly the norm. Why? If staff works in an environment where many of the rules are tacit, contradictory, ambiguous, poorly implemented, inaccessible, and/or unintelligible, of course the staff will improvise. Contrary to what some believe, well-defined rules do not lessen creativity (space to improvise and innovate about how to get desired results). That’s not the way it works. Absence of rules is literally anarchy – and only the bad guys look clever in that context. www.BRSolutions.com

In my most recent post, I distinguished between white-collar and gold-collar workers. See http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/ Can you differentiate between white-collar work and gold-collar work by whether it can be automated? In a day and age when IBM Watson can win at Jeopardy, I think it’s probably foolish to try. But I don’t think that’s the right question. Instead, I would ask whether the problem spaces are sufficiently distinct that they require different approaches. The answer to that question is definitely yes. That’s one reason I think it’s important not to say simply “knowledge worker” in process models. Companies pay gold-collar workers for their professional insight, creativity, and ability to digest huge amounts of knowledge on a continuous basis. Novel, unexpected results that fit the data better are at a premium. That’s not what companies pay white-collar workers for – or at least it shouldn’t be. Instead, they should pay white-collar workers to produce consistent results on decisions reached through directly traceable logic – that is, business rules. Unexpected results represent a failure – of an individual worker, a training regimen, or the rules themselves. More often than not, I think the problem actually lies with the rules. In many companies, we ask humans to make operational business decisions in a fog of byzantine rules – rules often far more complex than reasonable (or profitable). In addition, the ‘real’ rules are frequently more tacit or inaccessible than anyone cares to admit. In my view we simply have never been serious about defining, organizing and managing the rules in white-collar decision-making in a reasonable, scalable manner. And we certainly haven’t yet harnessed the power of computers to help with the business-side problem of rule management. www.BRSolutions.com

In a day and age where the automation of operational business decisions is increasingly the goal, I maintain that knowledge worker is the wrong term for business process modeling. The term is simply too broad. Instead I use the terms white-collar worker and gold-collar worker. What’s the key differentiation?    

• Gold-collar workers. The work of gold-collar workers involves non-routine problem solving, which requires a “a combination of convergent, divergent, and creative thinking” [Wikipedia].
• White-collar workers. The work of white-collar workers involves fairly repetitious sets of tasks, which at least in theory should produce relatively consistent results. Also, white-collar workers generally receive much less training than gold-collar workers.

Although the boundary between the two categories is somewhat fuzzy, I believe they generally can be distinguished. Relevant questions include:

• How routine is the work?
• How consistent should results of the work be?
• How much training is required?

As an example, consider loan officers in a bank handling applications for mortgages. White-collar or gold collar?

• Routineness. I’d call their work relatively routine. Even though each loan application is different and might involve special cases or exceptions, the work is always about mortgages.
• Consistency. You’d like to think different loan officers could produce consistent results on similar kinds of loan applications. Although certainly true in theory, it’s often not the case in practice. More about that momentarily.
• Training. Although loan officers do receive significant training and mentoring, it’s not on the order of years as for gold-collar workers.

Based on this analysis I believe loan officers fall into the white-collar category. What about consistency of results? I’ve seen studies comparing results across peers with roughly the same training and experience. The numbers are significantly lower than you might expect. That’s not at all a good thing for either customer experience or the well-being of their organizations. So why not automate the white-collar decision-making work?! Automating white-collar decision-making work well is exactly the focus of business rules and decision engineering. From experience, I’m certain that at least 50% to 80% (maybe more) of the decision work for mortgage applications can be automated, especially if a company is willing to standardize and simplify the adjudication rules some. Huge benefits can be achieved in terms of consistent customer experience, higher productivity, and directly provable compliance. P.S. Mortgage applications are not automated well if rules simply refer applications to humans when the rules cannot handle them. www.BRSolutions.com

Comment by DMN proponent: In common business use the term “decision” is often overloaded to mean “decision output”. So I “make a decision to do X” is the act, whereas I “use the decision as input to another decision” is referring to the decision output. I’m not sure there are any semantic issues with (i.e. possible problems caused by) this overloading? My response: Since DMN is a standard (and in particular claims to be a business standard), then it must stick with its own definition of terms in all cases. Otherwise, in what sense is it a standard (especially a business standard)? In defining “decision” DMN had two fundamental choices (from Merriam-Webster Unabridged dictionary): 1. a : the act of deciding; specifically : the act of settling or terminating (as a contest or controversy) by giving judgment 1. b : a determination arrived at after consideration : SETTLEMENT, CONCLUSION DMN explicitly chose the first meaning. I strongly prefer the second, but then I’m a big fan of all things declarative. So in BRS TableSpeak[1] an outcome by definition is a decision. Since DMN explicitly chose the first meaning, however, an outcome (conclusion) is by definition *not* a decision. A decision is an act, never the result of the act. Hey, I’m just reading what is written in the standard. If DMN somehow allows ‘overloading’ of the term “decision” — the central term in the standard — all bets are off. A term that you can use any way you want when it happens to suit you is a term that has not been standardized at all. The result is semantic muddle. Pretty big deal. Sorry! www.BRSolutions.com  

Consider the following examples of decisions arising in a regulated environment (acks James Taylor):

Government agency in Europe has regulations relating to Social Benefits. The agency itself must make decisions like “Is this person eligible for this benefit?” and “How much benefit, and for how long, is this person entitled to?”” that conform with those regulations.

An individual company might also have a decision like “Is this person entitled to paid leave to care for a sick child?” that is dependent both on company policy/practices and regulations that relate to social benefits (because they might require companies of a certain size to pay for this kind of leave).

My Analysis Indeed, these are operational business decisions. I’m not surprised, by the way, they are in effect about money. Of course money entails decisions! But here are two important observations. 1. Regulations typically include a great many one-off behavioral rules (“one-off” meaning following no particular pattern). Examples might include:

• Payment of benefits shall cease immediately upon the death of the beneficiary.
• Payment of benefits shall not be made to any beneficiary living outside the country for more than 9 months of a fiscal year.
• Payment of benefits shall not be made directly to any minor.

Is decision analysis suited to capturing/interpreting such one-off rules? Is it meaningful to have a decision such as “Should a benefit payment be made?” Shouldn’t such behavior be presumed automatic (but traceable and adaptable)? A better option is to simply have a task or action such as “Make payment”. Violations of related business rules for any particular case produces exceptions, possibly to be addressed by appropriate messages and/or procedures invoked automatically. That’s how basic business behavior becomes autonomous, so the business can concentrate on matters requiring greater skill, experience or intelligence. If you’re not careful everything becomes a decision. Where do you draw the line? Isn’t there a difference in simply being competent vs. being smart in doing business?

Aside:  Business vocabulary is as always obviously important. For example, does “payment” mean “accrual of benefit”, “act of payment”, “amount of payment”, or something else? No small issue.

(2.) Consider the following (one-off) behavioral rule:

A non-citizen may cash a payment of benefits for a citizen only if married to that citizen and the citizen is not deceased.

What happens in the case of death or divorce, and then the non-citizen tries to cash a payment? There’s no organizational decision involved there. There’s a personal decision … the non-citizen can decide to try to violate the rule … but we don’t really care about that. We only care about detecting the violation. We really don’t need or want an (operational business) decision here, do we? Again, if you have a decision for every possible kind of violation of every behavioral rule, you’ll very quickly drown in decisions. Don’t go there!  

Consider the following example.

Behavioral Rule: A student with a failing grade must not be an active member of a sports team.

This business rule:    

• Is not about selecting the most appropriate sports team for a student – i.e., not about the decision, Which sport team is best for a student?.
• Does not apply only at a single point of determination – e.g., when a student joins a team.

Instead, the business rule is meant to be enforced continuously – for example, if a student who is already active on some sports team should let his or her grades fall. What’s the business decision for when a student’s grades fall and they should be taken off a team? Be real, there’s no good answer to that question. This example is no outlier. Businesses have 1,000s of behavioral rules like this. Let’s be clear – I believe a business-decision-based approach is very powerful for decision rules. I have written much about that. And I don’t disagree that many business-rule projects have floundered due to lack of pragmatic organizing principles (e.g., “decisions”). But if you take a decision approach to behavioral business rules, either it will prove woefully incomplete with respect to integrity, or you’ll quickly start to drown in (system-level) decisions. In my opinion, an application that has to be designed and to operate to treat violations of behavioral rules as just more decisions is not a smart enough system. The detection of violation events for behavioral rules can be, and should be, completely under the covers (identified, detected and supported by a platform). Otherwise the solution won’t scale. And there will be so many decision dependencies it will steal from the very real value of a business-decision-based approach. This frankly is a sign of immaturity … or lack of imaginative leadership … or IT bias … or whatever … in some parts of the decision-model community. The detection of a violation of a behavioral rule is an event, not a decision. A business decision is a business decision; a system decision is … well … why even go there?! P.S. There are 3 specific examples and more complete discussion about this topic on http://goo.gl/NCnLi.      

A person close to the DMN (Decision Model Notation) standard recently wrote about its definition of “decision”: “This means a technical rather than business-person definition of ‘decision’, as the businessperson is not the target audience for the specification (metamodel) but of the results of the specification (models).” My Response Well, that’s a shame. Many people will be looking toward the DMN for a business vocabulary they can use in communicating with business people. So the communication gap between IT and business is not being closed in the area. My personal opinion is:

• Computers have become so powerful these days that they should be speaking *our* language (in structured, carefully defined form), not the other way around.
• Standards (and standards organizations) that fail to move the ball forward in that regard are failing its audience in the larger sense, no matter how good the standard for its chosen area. (And I do hope DMN is good in that latter sense.)