Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Knowledge Worker vs. White-Collar Worker: Opinions Needed

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

Continue Reading 7 Comments

A Follow-Up Note to Business Analysts about ‘Decision’

In a recent blog post I called attention to the fact that there’s a major collision of terminology with respect to the term decision as used by different communities. See: http://www.brsolutions.com/2014/07/06/a-note-to-business-analysts-about-%e2%80%98decision%e2%80%99/ My basic observation was that both communities are correct in their own context – but since the contexts intersect the result is a significant potential for confusion.
  • Business Analyst Community. Decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
  • General Business Community. Decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
Let me make some additional observations. A first question one should ask to clarify decision is what is the time horizon? Is it strategic or operational? A second question one should ask is what does decision actually refer to when used by each community for a given time horizon? Table. What Decision Refers to Based on Community and Time Horizon
Time Horizon of Decision

General Business Community

Business Analysis Community

strategic

strategic business decision strategic project decision or change initiative decision or option analysis

operational

operational business decision  —
  In contrast to operational decisions, strategic decisions are always longer in time horizon, and generally made only once (which isn’t to say they can’t be revisited sometimes). This point is true for both communities. The distinguishing characteristics of an operational business decision is that it:
  • Is highly repetitive (100s, 1000s, or more per day, hour, etc.).
  • Can be encoded as practicable business rules.
Note: My analysis doesn’t address operational decisions for the Business Analysis Community (the cell show with dashes). That’s not because decision isn’t applicable in that context, but rather simply because it’s outside the scope of the present discussion. I recently saw the following draft definition of decision, which illustrates the problem of mixed meanings quite clearly.

An activity to answer a question or select an option from a known or knowable set of possible options. Typically defined in terms of business rules and made in response to events or at defined points in a business process.

  • The first part of the definition is reasonable for decision in any usage. It applies to both communities and to any time horizon.
  • The second part of the definition pertains only to the meaning of operational business decision. Strategic decisions, whether for the General Business Community or for the Business Analysis Community, are generally not based on specific business rules and are not made in response to events or at defined points in a business process. Strategic decisions are simply different in kind from operational business decisions.
The focus of a strategic decision is also quite different for each of the two communities.
  • General Business Community: The focus is on conducting future business in a certain way.
  • Business Analysis Community. The focus is on conducting a proposed initiative in a certain way to change the business itself.
Bottom Line: For clarity, I would always qualify decision to indicate which kind is meant. We certainly don’t need any more confusion in business engineering than already exists! www.BRSolutions.com

Continue Reading

A Note to Business Analysts about ‘Decision’

Perhaps the following point about the term decision is already clear to all, but at the risk of stating the obvious, I’ll make it anyway. There’s a major collision of terminology with respect to decision as used by different communities.    
    • In the business analyst community, decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
    • In the larger business community, decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
In the context of their own communities both usages are correct. Unfortunately, the collision often results in confusion about the appropriate focus – and about which methods to use – for both audiences. In situations such as this, the best practice is to define the concept in question for each community. Terms considered to be obvious usually aren’t. It’s not clear to me that this has been done explicitly in the business analyst community. Another best practice is to qualify the term every time it’s used. So we always say operational business decision when talking about the business context, not just decision. That also distinguishes the concept we mean from other potential sources of confusion – e.g., strategic business decisions and system-level decisions or IT decisions. I believe what the business analyst community means by decision is strategic project decision or strategic change decision. But I can’t really be sure since as I say the term doesn’t seem to have been defined. www.BRSolutions.com

Continue Reading 3 Comments

Decision Analysis: Don’t Drown in Decisions

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!  

Continue Reading

Is a Decision-Based Approach Sufficient for Business Rules?

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.      

Continue Reading 5 Comments

Why can’t standards use the real-world meaning of ‘decision’?

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

Continue Reading

Feeling Feisty Today. Any of These Points a Burr Under Your Personal Saddle?

1. No government or regulatory or similar body should issue operational policy unless the vocabulary is fully and precisely defined (in people language, as possible under SBVR) and the business rules are spelled out in practicable form (as in RuleSpeak). Try to imagine the amount of time and energy wasted because everybody has to do their own interpretation. Ridiculous in a knowledge economy. (Same basically true for legal contracts and agreements, etc.) There ought to already be an eMarket in off-the-shelf, industry-specific know-how models (vocabulary and rules). It will happen … sooner or later. 2. Is the DMN standard going to solve all your problems? No, of course not. It’s an important step in the revival and reinvigoration of decision tables, but you can already see all-too-familiar patterns of hype and misguided thinking. Yes, I would like the standard … needed badly (if it turns out to be good — an open question, but I sure hope so). 3. The OMG mission focuses on machine interoperability. When people need so badly to speak to other people precisely, and in a day and age when machines have become so powerful that they can begin to speak limited people language, isn’t perhaps the OMG mission a bit outdated or incomplete?

Continue Reading 1 Comment

The DMN definition of ‘decision’ … Sorry, I don’t think so(!)

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

Decisions in DMN can be automatic, they can be used for detection, the logic they use can concern the violation of constraints; I see no problem with any of this.

My Response
  • A motorist goes thundering down the motorway, well over the speed limit. A radar gun detects it. What “decision” was made? Would a business person ever say the radar gun “decided” the motorist was speeding? … “Determined” maybe; “decided” no.
  • A company has the (behavioral) business rule:

 A customer that has placed an order must have an assigned agent.

An agent servicing customers who have placed orders retires and moves to Florida (this last part irrelevant). What “decision” is it that says, hey, now have some unrepresented customers and somebody ought to do something about it ASAP?? What “decided” there are now violations?? … “Detection yes”, “decision” no. 

P.S. That definition of decision seems a bit circular. To know what a “decision” is I need to know what “decision logic” means. But since “decision logic” says “decision”, seems like I need to know what “decision” means. Hmmm.

Continue Reading

A Playful Riff on “Decide”

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

I can’t see how you can object to the idea that decisions can be automatic, or used for detection, unless you maintain that decisions can only be taken by people?

  My Response Putting theological questions aside, in the beginning there was man. Well, people. Well, animals and people. As far as science is currently aware, there is nothing else in the universe that can “decide” something. Well, let’s put quantum mechanics aside. How things get “decided” there is just plain weird. That’s not human scale anyway (as far as science is currently aware). My point is that the concept “decide” makes absolutely no sense unless you acknowledge that “deciding” is a human concept. People decide stuff (or decide when things have been “decided”.) When Machines “Decide” Can machines “decide” things? Of course. Can they often “decide” things better than humans? Of course. Can they often “decide” things instead of people? Of course. Would you call what it is the machines do in such cases “deciding” if there were no people who could do the thing we call “deciding” in the first place? Of course not. “To decide” is fundamentally a human characteristic. If you try to remove the “human” sense of “to decide” from the verb, it’s not how the average person would understand it. This sense comes across clearly in the real world definition of “decide” [MWUD]: to dispel doubt on. When Machines “Doubt” Can machines “doubt”? I’ll let the philosophers decide that (yes decide). I’ll just say this: I doubt (yes doubt) it would be called “doubt” unless people experienced “doubt” in the first place. So when you use the word “decide”, even for what machines are doing, use it for things that people would call “decide”. If you want to use the word “decide” for machines in some other way – for things that people wouldn’t call “decide” in the real world – then please, just plainly admit you’re in systemland, not in peopleland.

Continue Reading

The DMN definition of ‘decision’ … I don’t think so(!)

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.

Continue Reading