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 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
In BRS Question Charts (Q-ChartsTM) we refer to an operational business decision by the question it answers (a very nifty idea we pioneered). Does that mean a decision is a question? Shouldn’t decision refer either to the answering of a question or to the answer itself?
To be clear, we definitely do not think or say that the question is the same as the decision.
However, if decision is understood properly in a business rules sense (the trick), there is only one question a decision answers. So as a (very) convenient shorthand, you can use the question as the name of the decision.
With that issue aside, so which should decision refer to, the answering of a question or the answer itself? The dictionary will support you either way you go. From MWUD:
1a: the act of deciding
1b: a determination arrived at after consideration : SETTLEMENT, CONCLUSION
If you’re a process person, you’d probably pick the first definition. But if you’re a true business rules person, you have to pick the second. From a business rules perspective, a decision is the answer (conclusion) you produce, not the act of producing it. The “act of” is something else altogether.
So a decision is an answer. But is answer alone enough? No. Digging a little deeper into MWUD we find these definitions:
determination : the resolving of a question by argument or reasoning
decide [c] to infer or conclude from available indications and evidence
Here’s the point. For business rules it’s crucial to capture the logic path (reasoning, inferences) that gets you to the answer.
To say that differently, for business rules just knowing the conclusion isn’t very useful; the determination must be directly traceable (from conditions or cases to conclusions or outcomes, and vice versa). So focusing on answer in isolation for decision doesn’t quite get you where you want to be. The bigger picture is that the answers are traceable.
P.S. That’s me in the picture, standing at the Cape of Good Hope, pointing toward Antarctica.
 I mean the meaning of the question, not the way it happens to be expressed. There are many ways, even in the same language, to express the same meaning.
I was reading some discussion about data models the other day and came across the following:
“The relationships between entities define the rules about which entities relate to others, as well as the number of minimum and maximum occurrences on each side of the relationship.”
Rules is definitely the wrong choice of word here. The misconception that relationships per se in data models represent (business) rules goes all the way back to the 1980s. It’s simply wrong. Instead I would say:
The relationships between entities provide structure for the data model, specifically indicating which entities relate to which and how. Specifications for a relationship typically indicate the number of minimum and maximum occurrences allowed on each side of that relationship – i.e., their cardinalities.
Of the three typical cardinality values – zero, one and many – only one removes any degree of freedom, and thus could be said to represent a rule. In any case, cardinality per se is a specification device; the business rule is in the meaning – for example:
A customer may be related to at most only one sales area.
Caveat: I reserve the right to change my mind on this at any time and would love to be proven wrong.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!) So for that reason and others, I doubt that IBM Watson and peers will prove viable platforms for execution-time support of business rules.The engineering of rules themselves – rule engineering – will remain professional work for humans to do (hopefully assisted by machines). Fortunately effective techniques for rule engineering have been proven in practice.I know some experts are calling for smart processes or intelligent processes these days. But if they’re not addressing business rules, they’re not really that smart. We want to enable smartbusiness, not just smart processes.
 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
My Answer: 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 that silver bullet syndrome will always be with us. In any case, making tacit know-how explicit as business rules is first a business and communication problem, then and only then a platform problem.
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 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.
The two fundamental kinds of business rules relevant to business analysis are definitional rule and behavioral rule. These two kinds of rule come from OMG’s SBVR (Semantics of Business Vocabulary and Business Rules) standard. They have very precise meanings based on formal logic. Here’s some background about that – more than business analysts really need to know, but informative nonetheless. At the end of the discussion I give pragmatic definitions. And the answer to the photo quiz.The SBVR definition for rule is deeply embedded in formal logic, which deals with propositions. In modal logic, propositions can claim different modes. For business rules the two relevant modes are alethic and deontic.
Alethic rules are true ‘by definition’. As such they cannot be violated. They are about how concepts, knowledge or information are defined or structured.
Deontic rules are rules that can be violated. They are rules about behavior, not concepts, knowledge or information. Deontic rules are really about people, what they must and must not do, even if their activity (and the rules) are automated.
Both kinds of rules are important, of course, but deontic rules – people rules – are especially so since ultimately, businesses are about the activity of people. This situation is very different than in the semantic web, for example, where it’s all about only knowledge.Under modal logic, every rule must therefore ‘claim’ one of two modes. (In practice, the ‘claim’ arises naturally from the syntax of a rule statement or as a meta-property.)
Alethic implications (rules) are established by ‘claiming’ necessity. Things are necessarily true. A concept is what it is; says what it says. That’s just the way things are.
Deontic implications (rules) are established by ‘claiming’ obligation. Behavior is ‘obliged’ to follow the rule. But of course, people don’t always follow the rules, so there can be violations. Major difference.
So a rule ‘claims’ either necessity or obligation, which establishes what kind of rule it is. Therefore the SBVR definitions for the two kinds of rule are:
Definitional rule: rule that is a claim of necessity
Behavioral rule: business rule that is a claim of obligation
Why doesn’t the definition for definitional rule say “business rule” like the one for behavioral rule? Because some definitional rules are not ‘under business jurisdiction’ (in other words, business has no choice about them). Examples include the ‘law’ of gravity and all the rules of mathematics. Those rules are simply universally true. I recommend the following pragmatic definitions for business analysts.
Definitional rule: a rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge or information
Behavioral rule: a business rule that places an obligation (or prohibition) on conduct, action, practice, or procedure; a business rule whose purpose is to shape (govern) day-to-day business activity
Synonyms: Early in the development of SBVR I introduced the terms structural rule and operative rule for the two kinds of rules, respectively. That was before the full implications of modal logic became clear. Since then the terms definitional rule and behavioral rule have become preferred, even in all internal SBVR discussion. The synonyms, however, remain valid.
P.S. Did you guess correctly which kind of rule is represented in the photograph? Behavioral, of course. And the photo itself is a violation of the rule.
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“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.”