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  

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.)

A person close to the DMN (Decision Model Notation) standard recently wrote:

In DMN a decision is deliberately defined very broadly … 

“a decision is the act of determining an output value (the chosen option), from a number of input values, using decision logic defining how the output is determined from the inputs”.

My Response I’ve already written that the DMN definition of “decision” seems to be a bit circular. (To know what a “decision” is you need to know what “decision logic” means. But since “decision logic” says “decision”, seems like you need to know what “decision” means.) Let me tell you what else I find wrong with the definition. (All dictionary definitions from MWUD.) Problem 1. MWUD defines “decision” as (1a) the act of deciding. It defines “act” as (1a) a thing done or being done. So which is it? Is a decision a thing “done” or a thing “being done”? In other words, is a decision the result of an action or process, or the performance of an action or process? Big difference! Which does the standard mean? Some clarity would be nice. Problem 2. MWUD defines “decide” as: to dispel doubt on: (a) to arrive at a choice or solution concerning which ends uncertainty or contention *decide what to order for breakfast*  (c) to infer or conclude from available indications and evidence So the real-world definition of “decide” talks about …

• Arriving at “a choice or solution”.
• Basing that choice or solution on “indications and evidence”.

Do you see anything in that definition that reduces what is used in making decisions to “inputs” and “outputs”?! That’s ITspeak, not businessSpeak. So let’s not pretend the DMN standard is really about business modeling per se. It’s business reduced to a system view. Problem 3. “Input value” is definitely ITspeak. Fields and attributes in files and databases are what have this kind of “value”. In the business world, people talk about cases, applications (appeals, requests, petitions), communications, situations, circumstances, trends, profiles, and the like. They don’t talk about “input values” to a decision. Get real. Again, the authors of the DMN standard should either be clear it’s really about system stuff … or admit to causing confusion, deliberately or otherwise.

written in response to Jacob Feldman: http://www.brsolutions.com/2013/05/07/response-to-decisionspeak-tablespeak-annnouncement/ Jacob, Thanks! And I agree with you about the ‘executable’ part. Our emphasis is on business-friendly, business-driven models. I believe DecisionSpeak and TableSpeak move things forward significantly in that regard. There’s no reason why decision models have to be oriented to IT development. If they are robust, they will nonetheless be executable. I would sound a note of caution. Decision models are no silver bullet. There are issues of semantics (vocabulary) and integrity (restrictions) to be addressed. And they don’t cover even the majority of all business rules – especially behavioral rules. If you throw everything you (should) know about business rules out the window when you use decision models, you will be in for a very rude awaking. I’m glad we did not rush to the market. We’ve taken our time to do our homework with respect to theory (which has been out there for a great many years) and to hone our approach in real-life consulting work. I think the results speak for themselves!

guest post by Jacob Feldman First of all, congratulations on your new Primers that provide very detailed convention sets for the decision management domain. I quote from your documents: * DecisionSpeak™, a set of conventions for expressing the meaning of operational business decisions. * TableSpeak™ is a set of conventions for business-friendly representation of decision tables and their meaning (semantics) in declarative fashion. Naturally, my first thought is: can we make these conventions EXECUTABLE? More precisely: Can we help subject matter experts (not programmers) to: – create documents that follow these conventions? – automatically validate (enforce) compliance to these conventions? – execute the compliant documents? After a quick walking through the documents, I think the answers are YES. We, at OpenRules, should be able to build OpenRules templates (in Excel) that supports these conventions and to direct users how to apply these templates to create, validate, and execute concrete decisions, decision tables, and other types of rules. There are certainly many details how better to address certain constructions described in TableSpeak™, but they all look solvable to me. Previously, we provided a similar implementation as soon as another decision modeling methodology (TDM) was published. Now we are working with James Taylor making business requirements created by his newest DecisionFirst Modeler executable. As you know, OpenRules is also working on a reference implementation for the DMN as this standard comes to the age. It would be only natural to provide support for the IPSpeak™ methodology. Based on our previous positive experience working with you, Gladys, and other experts from BRS, I am looking forward to making IPSpeak™ executable. http://openrules.com