As a general rule, businesses should organize work into well-defined processes when the goal is creating large numbers of identical or nearly identical outcomes, as when Volkswagen needed to install the software that conned the EPA into hundreds of thousands of identical diesel Passats, Beetles, and Jettas.

Designing the software? That’s more of a practice.

As it turns out, there’s a third way to organize work that can, in some situations, give you the best of both worlds — the scalability of business processes without losing too much of the flexibility you get from business practices. We’ll get there in a minute.

But first, closure. The heating coil showed up Tuesday. Tracking number? Never got one. The service tech showed up Thursday and installed it … but didn’t need it, as he already had the replacement part in his truck. He was also kind enough to reverse the charges for the heating coil that was damaged in transit and delivered to North Carolina.

Thanks to all who offered empathy, sympathy, and advice for last week’s account of our adventures in Customer Elimination Management (CEM) and the Six Stupid Methodology so often used to implement it.

Underneath the six stupids enumerated last week is a single root cause: An intense desire to dumb down work until any gerbil can handle it. It’s a fundamental underlying assumption of well-designed business processes: Execute the steps in the proper sequence and quality automatically happens.

Cooks follow processes — recipes — to make meals. Chefs, in contrast, are practitioners of the art of haute cuisine.

Trying to turn customer service into a fixed set of steps and instructions is a recipe for customer elimination, as a certain unnamed retailer demonstrated to yours truly in the Case of the Burnt Out Dryer.

And “case” is the operative word: When a process has failed and customer service is needed, either (1) the customer service representative resolves the problem during the initial contact; or (2) the situation enters … or at least should enter … the realm of case management.

Case management is an example of a hub-and-spoke practice — a practice in which one person owns the situation and calls on whatever business processes, relationships, or resources are needed to resolve it. Had the first person we contacted in the course of attempting to repair our dryer assigned a case manager, it would have been a far smoother and satisfactory experience — admittedly a low bar to hurdle, but still.

Enter “Next Best Action,” which should probably be called “best next action,” but that ship has already sailed.

Very briefly, it’s a way to combine decision trees, rules-based AI, internal customer knowledge, additional customer knowledge gleaned from the social web, process tracking, and predictive analytics. The result is a system that replaces a fixed sequence of one-size-fits-just-a-few process steps with a flexible collection of possible actions, driven by a system that figures out what most logically should happen next.

In the case of our dryer repair, a next-best-action system would have learned that UPS redirected the initial part shipment from its initial destination in Minnesota to North Carolina due to in-transit damage, immediately ordered a replacement part, and notified us of the situation … my wife by text and me by email because it knows our preferred contact channels.

Having ordered the part it would have monitored the case for status changes, notifying us again when UPS picked up the part and assigned a tracking number.

And, it would have set a timer. When it expired and no tracking number was forthcoming, it would have assigned a human case manager to take it from there. Next best action doesn’t eliminate the need for human intervention. But it can narrow it down quite a bit.

Which leads to this potentially uncomfortable question:

Next best action is real. You can implement it before your competitors and take customers away from them, or you can implement it later and lose customers to them.

The question: Is your IT organization … your developers and business analysts … ready to implement it?

Let’s go one level deeper: Even if next best action isn’t in your future, something else new, different, and more sophisticated probably is.

Is your IT organization equipped to recognize it, incubate it, and put it into production?

We’re in the era of pervasive technology and IT has only three choices:

Lead, follow, or wonder what happened.

* * *

My expertise in next best action is distinctly limited. For a more in-depth account, look here.

Or, wait for the soon-to-be published The Cognitive Enterprise, in which next best action has a prominent part to play. My co-author, Scott Lee, has been implementing next best action since being part of GM’s OnStar design team more years ago than he’s willing to admit.

It’s a jungle out there.

Since I was young enough to be protected by Child Labor Laws, and probably before, managers have used this phrase to describe their working environment.

It’s apt too often: The enterprise is organized, if that isn’t too strong a word, as an ecosystem in which employees at all levels interact to further their own self-interest.

Furthering the interests of the enterprise is an accidental byproduct at best. More usually it isn’t a byproduct at all. The enterprise is left to look out for itself.

Business leaders have three powerful metaphors to choose from when constructing their organizations: ecosystem, mechanism, and organism. From all appearances, most choose unconsciously based on their personality, character, ego, and energy.

Ecosystems are to biology what marketplaces are to economics. They are spaces within which independent agents act so as to maximize their “utility” … their own self-interest.

Business-as-ecosystem is the logical choice for executives who think the marketplace is the solution to everything, because according to the set theory most of us learned in high school, “organizational effectiveness” is a subset of “everything.” Marketplaces are, however, no more the solution to everything than anything else is the solution to everything.

Marketplaces are just the ticket when what you need is an efficient way to balance supply and demand and you’re able to preserve competition among both suppliers and buyers. They’re a terrible way to focus energies on defined goals, though, because marketplaces have no goals of their own and aren’t supposed to. Their purpose is the exact opposite — to encourage all actors to operate independently to achieve their personal goals.

When businesses are organized as ecosystems, personal relationships are characterized by distrust, as they should be: Deer compete with each other for food and mates; meanwhile any deer that trusts a wolf is a dead deer.

And so, organizational ecosystems devolve to silos within silos within silos. It’s no way to run a railroad. Or any other organization, from an enterprise down to the smallest workgroup.

Many business executives, recognizing that siloization (it isn’t a word but it should be) inevitably leads to dysfunction, choose to view their organizations as mechanisms instead — collections of gears, cams, cogs, levers and buttons, connected so as to achieve a coherent result.

It’s business-as-automobile and business-leader-as-driver. It’s the view preferred by process consultants of all religious persuasions … lean, six sigma, lean six sigma, theory of constraints and whole-hog process re-engineering for the enterprise as a whole; ITIL for IT, and other process frameworks (I imagine) for other business disciplines.

All start by describing an organization as a collection of processes and sub-processes that feed each other’s inputs and use each other’s outputs to achieve the organization’s purpose (I’d have said “mission,” but missions lead to Mission Statements and that way lies madness).

What is that purpose? It’s the purpose of the executive in charge … the CEO for the enterprise as a whole and the other C-level executives for the organization’s major divisions.

Business-as-mechanism is far superior to business-as-ecosystem because mechanisms, whether they’re automobiles, power tools or computers, can and do achieve the purposes for which they’re designed, so long as they’re operated by people who (a) have the appropriate skills to use the mechanism; (b) know what they’re trying to accomplish with it; and (c) have chosen to try to accomplish something for which the mechanism is suitable.

Only the operator cares whether the organization achieves its purpose, though. The vision of each gear is limited to the gear turning it and the gear it turns in turn.

Contrast that with organizations that operate as organisms. Unlike mechanisms, the organism’s purpose belongs to every part of it. That’s what lets it adapt to changing circumstances. Feet build callouses, muscles harden and bulk up, skin tans when exposed to more sunlight — each part supplies its own energy and figures out the details of its operation on its own without subverting the overall purpose of the critter it’s part of.

Organizations that are organisms are rare because leaders willing to invest the effort to build them, and to forgo the gratification of being the sole driver, are rare. While evidence is sparse … Business Management theory hasn’t yet reached even the level of reliability associated with Economics … what evidence we have suggests organizations that operate as organisms are the most successful in both the short and long run.

The early Microsoft under Bill Gates is an example. It was a predator. Microsoft now, under Steve Ballmer, is by all reports an ecosystem.

Paints a picture, doesn’t it?