Everyone has a story.

I was re-reading Eliyahu Goldratt’s Theory of Constraints. It’s the principles he first elucidated in his groundbreaking “business novel,” The Goal, rewritten as prescriptive methodology.

Goldratt’s Theory of Constraints (ToC) is, as process improvement methodologies go, quite brilliant and sadly underappreciated. And yet, early in the book appears this disturbing statement about the value of ToC success stories:

Who would be helped by such testimonials? The people that have already been persuaded by The Goal do not need them, they have their own real-life proof. Those who were not moved by the common sense logic in The Goal will certainly find it easy to demonstrate that their situations are different and that these ideas will not work in their environment.

I say disturbing because Goldratt appears to be asserting that fiction not only is more persuasive than fact, but that it should be.

It probably is — when I talk to clients about DevOps, for example, more cite The Phoenix Project than any company’s real-world experience.

By this logic, if, in a debate about military strategy and tactics, my opponent were to support a point with Grant’s victory at Vicksburg as described in his personal memoirs, my best counterargument should come from the battle of Helm’s Deep as described in The Lord of the Rings.

Fiction can be an excellent way to illustrate a point. But offered as evidence it’s a cheat. Fictions’ authors are puppeteers, able to make their characters say and do whatever is necessary to “prove” whatever point they’re trying to make.

Not that business case studies are much better. They aren’t, because those presenting them (1) start with the conclusion they’re trying to prove rather than starting with evidence and using it to guide their opinions; and then (2) sort through the available stories to find those that support the predetermined outcome, ignoring all the others that don’t.

Then there are the anecdotes we consultants tell. We all have them.

I recall (but couldn’t track down) a bit of braggadocio from a Lean consultant who described his experience on a construction site. After a brief period of observation he was able to use Lean principles to save the construction firm oodles of time and sacks of cash by repositioning the concrete mixers.

In my own consulting we once saved a client the time, expense, and aggravation of a multimillion dollar process reengineering project through the simple expedient of having IT educate a business department in the use of an already-installed feature of the software package they used.

Twenty minutes later the problem the reengineering project was supposed to fix was taken care of.

We all have these stories. They’re fun to tell. We hope they convince potential clients that we’re adept at finding “low hanging fruit” — quick and easy improvements that can justify and fund the hard stuff.

Quick and easy improvements that, astonishingly enough, never require significant investments in new or changed information technology. In fact I’ve yet to hear an apostle of any of the major process improvement methodologies explain the importance of cleaning up and modernizing the organization’s portfolio of business applications. I have often heard them explain how they’ll work their magic without requiring major investments in information technology.

There is, for example, this little ditty, found in Six Sigma Daily. It does a nice job of presenting some Lean Six Sigma principles Jeff Bezos relies on for making Amazon hum.

Don’t get me wrong. The principles and examples extolled in the article, while not the sole province of Lean Six Sigma, are good principles and examples.

It’s just that, reading the article, you’d be forgiven for concluding Amazon runs its warehouses with stacks of 3×5 index cards and not highly sophisticated information systems.

Why are these tales of easy, IT-free success so popular? That, at least, is easy to explain: it’s confirmation bias in action. That is, most people, most of the time, including you and including me, tend to accept without much scrutiny anything that tells us what we want to be true, while we nitpick to death anything that tells us anything else.

Fiction, case studies, and anecdotes of the “all you gotta do is …” variety tell business decision makers what they want to hear the most: making revenue grow, costs shrink, and risks disappear is going to be cheap and easy.

Against this “logic” there’s this simple but unattractive fact: When you’ve picked all the low-hanging fruit there’s a tree-full of peaches left that’s going to need a lot more effort to harvest.

Someday I’ll have to write a business novel about picking them.

Customer Elimination Management … CEM … is CRM’s evil twin.

We all have memories of companies doing their utmost to drive us away. If you’re like me, my family offers its sympathies to your family.

No, wait, that wasn’t it. If you’re like me you might have wondered just when the first instance of CEM took place.

Wonder no more. While it might not have been first, science has pushed the date of the earliest known gripe back to 1782 BCE. That’s the approximate date of a clay tablet found in the ruins of the Sumerian city-state of UR …

In the clay tablet, a man named Nanni whined to merchant Ea-nasir about how he was delivered the wrong grade of copper ore. “How have you treated me for that copper?” he wrote. “You have withheld my money bag from me in enemy territory; it is now up to you to restore [my money] to me in full.” (“World’s Oldest Customer Complaint Goes Viral,” Christina Zhao, Newsweek, 8/24/2018.)

Even with the best efforts of digital technology, I doubt your calls to customer service, recorded as they are for training and improvement purposes, will be discovered for translation by even the most diligent of 5918’s archeologists.

In the meantime we’re left to wonder if Nanni received a response that began, “Your clay tablet is important to us …”

We’re also left to wonder, with a bit more relevance to the world of modern commerce, if Digital technologies and practices (no no no no no, not “best practices!”) can, as promised, transform customer service.

But we aren’t left to wonder very long, because the answer is obvious. For companies already dedicated to providing outstanding customer service, Digital technologies won’t transform it, but they will undoubtedly improve it.

For companies that didn’t give an infinitestimal damn before Digital strategies and technologies became the Next Big Thing, Digitization will make their already awful customer service even worse.

In theory, business intelligence technologies, applied to masses of data gleaned from social media, might make a persuasive executive suite case that current service is putrid and customers are defecting in droves because of it while blackening the offending company’s reputation among those who, without the benefit of Yelp, might have given it a shot.

In theory, these same technologies, combined with the near-future capability to interpret telephone conversations for both substance and emotional content, might give that same company’s decision-makers, who couldn’t enter the Clue Store with a plutonium American Express card and leave with any merchandise, the clues they need to figure out why their cost of sales is so much higher than that of their competitors while their customer retention and walletshare continue to plummet.

But in the wise words of 1882 Yale University student Benjamin Brewster, in theory there’s no difference between theory and practice, while in practice there is.

The service a company provides its customers is an inextricable component of the overall value they receive when they buy its products and services. Digitize a business whose leaders don’t personally and intrinsically care about it … who care only about the impact bad customer service has on their annual bonuses and options awards … and the result will be the same bad service, available through more channels.

We’re entering a post-Turing world of chat ‘bots, email autoresponders, and, very soon, AIs with synthetic voices, all poised to correctly interpret what we’re saying or writing so as to accurately diagnose their product’s defects and scour our databases of successful resolutions so as to find the one that precisely fits our situation.

More often than not, though, what these capabilities will give customers are the same useless non-solutions to the problems they contacted the service channel to complain about, delivered a wider variety of more convenient channels but not providing more useful information.

Only now, the IT organization’s name will be on whatever complaints do filter through to top management. Which in turn suggests it isn’t too early to think about the brave new world of software quality assurance. Because in addition to the litany of tests IT already applies to its software … unit, integration, regression, stress, and end-user acceptance being the most prominent … we’ll need to add another.

Call it AIIQ testing. Its purpose will be to determine if the artificial intelligences we’re deploying to support buyers of the company’s products and services are just too stupid to expose to the outside world.

Maybe we can figure out how to use artificial intelligence technology to automate the testing.