It's All In The Interpretation

So a friend sent me this hilarious spoof about automatic transmissions, and it goes something like this...

A guy calls up the car service hotline and asks for help with his car.

What's the matter?

Well the car works perfectly in the daytime, but it refuses to drive at night. 

The lady on the customer service line is baffled.

Then he explains:

- During the daytime, I just put the car into "daytime" (D) mode, and it drives fine.

- But then at night, I put it into the "nighttime" (N) mode, and it doesn't move.

- What's worse yet, when another car tried to jump ahead of him, he puts the transmission into "race" (R) mode, and he ends up hitting the car behind him!

At this point, the customer service representative is completely cracking up laughing. 

Apparently not everyone has the same notion of "drive" (D), "neutral" (N), and "reverse" (R)--and frankly, maybe we shouldn't take so much in life for granted.  ;-)

(Source Photo: here with attribution to AliExpress)

It's All In The Interpretation

Pain is Relative

I've always found it a little strange when the doctor (or nurse) asks you, "On a scale of 0 to 10, how much pain are you in?"

Why?

Because pain (like many emotions) is relative to our understanding of it. 

To me, when someone says a 10 for pain, I think of someone under the most excruciating pain--like when someone, G-d forbid, is being tortured. 

However, someone else may think of 10 as just being really sick and uncomfortable. 

That's why I like this graphic that is used to level-set what each number in the scale represents. 

Using this simple graphic, our definition of pain is not purely subjective, but rather each person can look at the faces and expressions and see how they relate to them. 

Of course, the goal on the right for zero pain is a great goal, even if not always achievable. 

In a sense this is a very basic personal architecture--where you have your "as-is" on the scale and your "to-be" which is your goal. 

Then the doctor and patient work together to figure out a transition plan on how to get there (medicine, rehabilitation, healthier living, etc.). 

While pain is usually just a symptom, it is a beginning to get at the root cause of what is bothering us and needs to be fixed. ;-)

(Source Photo: Andy Blumenthal)

Pain is Relative

Big Data, Correlation Or Causation?

Gordon Crovitz wrote about Big Data in the Wall Street Journal (25 March 2013) this week.

He cites from a book called "Big Data: A Revolution That Will Transform How We Live, Work, and Think," an interesting notion that in processing the massive amounts of data we are capturing today, society will "shed some of its obsession for causality in exchange for simple correlation."

The idea is that in the effort to speed decision processing and making, we will to some extent, or to a great extent, not have the time and resources for the scientific method to actually determine why something is happening, but instead will settle for knowing what is happening--through the massive data pouring in.

While seeing the trends in the data is a big step ahead of just being overwhelmed and possibly drowning in data and not knowing what to make of it, it is still important that we validate what we think we are seeing but scientifically testing it and determining if there is a real reason for what is going on. 

Correlating loads of data can make for interesting conclusions like when Google Flu predicts outbreaks (before the CDC) by reaming through millions of searches for things like cough medicine, but correlations can be spurious when for example, a new cough medicine comes out and people are just looking up information about it--hence, no real outbreak of the flu. (Maybe not the best example, but you get the point). 

Also, just knowing that something is happening like an epidemic, global warming, flight delays or whatever, is helpful in situational awareness, but without knowing why it's happening (i.e. the root cause) how can we really address the issues to fix it?

It is good to know if data is pointing us to a new reality, then at least we can take some action(s) to prevent ourselves from getting sick or having to wait endlessly in the airport, but if we want to cure the disease or fix the airlines then we have to go deeper, find out the cause, and attack it--to make it right. 

Correlation is good for a quick reaction, but correlation is necessary for long-term prevention and improvement. 

Computing resources can be used not just to sift through petabytes of data points (e.g. to come up with neighborhood crime statistics), but to actually help test various causal factors (e.g. socio-economic conditions, community investment, law enforcement efforts, etc.) by processing the results of true scientific testing with proper controls, analysis, and drawn conclusions.

Big Data, Correlation Or Causation?

Treating the Root Cause and Enterprise Architecture

All too often, when there are issues in our organizations, we treat the symptoms instead of the problems. Just like this is bad medicine in treating illness and healing patients, so too it is ineffective in architecting our organizations.

The Wall Street Journal, 22 September 2008, has an article entitled “Making the Most of Customer Complaints.”

The quick-fix problem resolution:

"Companies have customer service sort out the immediate problem, offer an apology or some compensation, then assume all is well. This approach does nothing to address the underlying problem, practically guaranteeing similar failures and complaints.”

This “has enormous impact on customer satisfaction, repeat business, and ultimately profits and growth.”

The three actors and their conflicting approaches:

The customer—“can be left feeling their problem was not addressed seriously, even when they’ve received some form of compensation.” Customers are fairness-minded; they want to know why the problem occurred and that it will not happen again.

The service rep—“can start seeing complaining customers as the enemy, even though they point out flaws that need fixing.” Customer service reps are yelled at and abused by frustrated and angry customers who hold the service reps responsible for failures that are out of their control.

The managers—“can feel pressure to limit flows of critical customer comments, even though acting on the information will improve efficiency and profits.” Managers need to learn from failures and reengineer the processes to correct problems, but instead they fear reporting negative customer satisfaction and shun reporting these. In essence, they are taught to just make the problem go away!

The result:

“Fewer than 8% of the 60 organizations” in the wall Street Journal study did well integrating these actors and their perspectives to resolve problems at their root cause.

The focus unfortunately is on short term results instead of architecting long term success.

“Our experience with managers interested in improving service recovery indicates that most hope for a quick fix…but quick fixes only treat the symptoms of underlying problems. Real resolutions should involve closer integration among the three stakeholders, such as gathering more information from customers and sharing it throughout the company, and adopting new structures and practices that make it easier to spot problems and fix them.

There is an important enterprise architecture lesson here:

While executive management often want to achieve a quick turnaround and show results ASAP, and getting the low hanging fruit is often quite tempting, it is not often going to lead to substantive improvement in our organizations without a commitment and plan to address root cause.

Sure, in architecting the organization, we need to start somewhere, show progress, and continuously build on initial success (i.e. it’s an evolutionary process). However, there must be a long term plan/architecture that deals with genuine, deep-seated organizational issues, improves our underlying processes and their technology enablement, and leads to fundamental growth and enterprise maturation. A quick fix just will not do!

Treating the Root Cause and Enterprise Architecture

Customer Service and Enterprise Architecture

Good customer service is worth its weight in gold and indeed, many people are willing to pay extra for this.

In fact, I would venture to say that most of us are usually willing to pay extra if we know that the customer service will be there to protect our purchase or investment.

The Wall Street Journal, 25 April 2008, introduces a new book called “The Best Service is No Service” by Bill Price and Dave Jaffe that discusses what real customer service is all about.

How bad is customer service these days (despite all the technology)?

“When calling an 800 number, we expect to find ourselves in voice-response hell. We dutifully follow instructions to key in a 10-digit policy number—only to be asked by the customer-service rep for the same darn number. Waiting on hold for 25 minutes? Well, that’s what speakerphones are for.”

How have companies responded to calls for better customer service?

“There is more to helping customers than picking up the phone within three rings or emailing within 24 hours.” And these measures are often gamed; here are some examples:

• “At one company, where managers imposed a target ‘average handle time (call time) of 12minutes, phone calls miraculously shortened to just under 12 minutes: As the 12-minute mark approached, agents simply said whatever it took to get the caller of the phone.
• The call center at another company hit on the idea of reducing the number of phone lines so that the excess callers simply got a busy signal-and went unmeasured.”

“In other words: don’t just ask how long it took to help the customer, ask how often the customer needed help and why. The goal is to avoid the need for a customer to contact the company [about problems] in the first place.”

The authors contend that the goal for good customer service is for there to be no need for customer service—i.e. the customer is happy with the product or service being provided and there are no problems and therefore, no complaints. This to me sounds akin to Six Sigma and the quest for zero defects.

And if zero (or close to zero) defects are not the reality, then good customer service is about finding out the “root causes” of the problems and solving them, not just appearing responsive to the complaints, but doing nothing to ensure they don’t happen again.

Good customer service is a strategic competitive advantage, and organizations should include improvements to this area as a goal in their plans.

From a User-centric EA perspective, good customer service is like a sister to User-centricity. We put the user/customer/stakeholder at the center of the organization’s value proposition.

We are here to serve the user and that should mean more than just paying lip service to them. It must mean that we continuously improve processes, products, and service and make the end-user experience zero-defect, problem and hassle free.

Customer Service and Enterprise Architecture