Long-time correspondent Bob Ernst writes, “It hit me that what has become a major function of a corporate IT department is enabling your company to comply with the rules of doing business with another company. Without this capability, the efforts of manufacturing, sales and marketing are unable to sustain the customer relationship.”

I agree, with the proviso that “has become” should read “should have become.” In my experience, it’s often someone well-hidden from IT, using Excel spreadsheets to keep track of customer-specific product and service requirements, and more Excel spreadsheets to take care of customer-specific reporting requirements.

For example: Whenever I’ve worked with non-profit organizations built around winning grants, I’ve seen pretty much the same systems mess: handcrafted grant reporting managed as a monthly panic attack when the non-profit is small, and as a swarm of satellite spreadsheets “connected,” if I might abuse the term, to the enterprise ERP system, which is utterly incapable of handling the task on its own.

But as you’d expect from someone named Bob, Mr. Ernst isn’t wrong.

For example, sometimes the rules are a matter of keeping track of parameterized product and service features, as when you travel on business and your preferred rental car provider keeps track of contractually specified rental options, such as which forms of additional insurance employees should and shouldn’t sign up for.

Or, for that matter, if your customer is enterprise IT and requires the PCs and laptops it buys from you to all have the same, standardized set of key components (I presume — I don’t work in that part of Dell, but was responsible for PC acquisition earlier in my career).

But there are plenty of businesses that rely on negotiated contracts to define the terms and conditions of doing business. Some are insurance companies, some are in the transportation business, others are manufacturers, and one I worked with quite a few years ago managed rebate programs.

Then there was the company that didn’t have any of this, but which did have eleven bargaining units (unions, if you don’t belong to the Magic Buzzword Club), each of which negotiated unique compensation and benefits terms for its members, all of which had to be hard-coded into the payroll system.

What all these situations had and have in common is that each contract signing was a new and often unique scramble for IT, calling for custom, contract-specific code.

Except for the life insurance businesses I’ve worked with; their underwriting and policy administration systems provided the business with what amounted to an insurance contract description language. This provided enough flexibility to handle most contracts, at this cost: New business staff needed at least three months to become at all productive, and a couple of years to become truly proficient.

And, sales force ingenuity was (and, I’m sure, still is) nothing to be trifled with — some contracts still result in a need for IT to extend the language.

What I find interesting about this need for information technology to manage unique customer requirements is that there is, to the best of my knowledge, no body of theory to accommodate it.

It’s quite the opposite, in fact: The prevalent guiding theories are such stalwarts as Lean and Six Sigma, both of which preach standardization and simplification. My experience working with consultants schooled in these disciplines suggests their solution would be to simplify, standardize, parameterize, and limit customer choices to the result.

It isn’t that they’re wrong. It’s that, they are, as someone once said, insufficiently right.

To draw an inexcusable analogy, it’s as if Lean and Six Sigma are the Newtonian physics of business. In the world of everyday forces, temperatures, sizes, masses, densities, and accelerations they handle things just fine.

But just as a lot of the universe operates at quantum and cosmological scales, near-light-speed velocities, ferocious accelerations, and light-capturing gravitation — situations where Newtonian physics breaks down — so there are plenty of business situations that don’t fit the simplify and standardize formulation.

As when, for example, that isn’t what customers want to buy.

Changing metaphors, your average process consultant is the clichéd hammer owner, for whom all problems look like nails.

If your business depends on selling customers what they do want to buy, even when what they want to buy will take custom code and one-off business processes, you’re looking at the situation from the other side.

As yours truly once said, when all you have are thumbs, every hammer looks like a problem.

A couple of decades ago, when I joined Perot Systems, I greatly admired the weekly employee newsletter.

It was entirely prosaic — a text-only email layout-and-design tragedy where bold-face and italicized letters were the boundaries of formatting sophistication.

It was concise and readable, told employees the essentials of what was going on, and, every edition included a story. Not a tale of Ross and how brilliant and fabulous he was, but of a team that had done something that exemplified the company’s aspirations, goals, and values.

Which was far more effective in making sure all employees understood what constituted “how we do things around here” than any mission statement posters, values cards, or other empty gestures.

Perot Systems wasn’t a cognitive enterprise, but its employee newsletter was a step on the right path to making sure whoever made decisions on behalf of the company made decisions Ross Senior and his inner circle would agree with.

It’s no small challenge, and the bigger the company, the harder it is to push and prod the organization so it acts like an organism — a single entity with a single purpose. Large enterprises tend to be more like ecosystems than organisms. Why? Like ecosystems, the component parts of an organization are diverse, self-interested individual organisms — those pesky human beings you’ve probably had to work with once or twice in the course of your career.

Just in case you still aren’t convinced: Your brain, stomach, kidneys, and spleen all have different functions, but they all have the same goal — your survival and success.

Your company’s supply chain, IT, accounting, and manufacturing departments also have different functions, but there’s no reason to assume their managers and staff even care about the survival and success of anything beyond their little silo, let alone agree in any way, shape or form on how to achieve the survival and success of the enterprise as a whole.

One place to start is the golden rule of design: Form follows function, which is to say, understand the problem you’re trying to solve before you start designing solutions.

With a cognitive enterprise, one of the problems you’re trying to solve is how to give customers the impression they’re interacting with the equivalent of a person that acts with intention, not the complex, hard-to-navigate bureaucracy that’s the underlying reality.

There’s no single magic bullet for this. Creating a cognitive enterprise is a tough, tough challenge, as Scott and I discovered while writing the book. One starting point among many: Design the default sequences through which you expect typical customers to pass, and the mechanisms for exiting the default sequences when they don’t fit the situation.

Doing so enumerates what the customer touchpoints are. The next step is deciding what the customer experience should be within each one, for each channel through which customers can interact.

There are, as you might imagine, quite a few different variables to take into account. For example: Should you maximize the number of required touchpoints so as to create a soft, we-care-about-you impression, or should you minimize them so you don’t waste your customers’ time?

The answer, and you knew this was coming: It depends.

For example: If you’re an Emerald Club member and rent a car from National you can walk right past everyone, grab a car, and drive out. National caters to customers who appreciate convenience.

Enterprise, on the other hand, which is part of the same car-rental conglomerate, takes the opposite approach: Someone accompanies you to your car, walking you through every step of the rental process up to and including looking for dings and dents.

Enterprise figures its customers want the personal touch.

Which company is right? They both are. Different kinds of customer have different preferences. What the two companies have in common: Both started with what they wanted their customers to experience, then designed their processes and systems … and educated their employees … to provide that experience.

What else? Three rules:

  • If something interrupts the flow, what changes is the touchpoint sequence, not the touchpoints themselves.
  • Touchpoints are functionally identical, regardless of the channel. What customers do doesn’t depend on whether they’re using the phone, the web, or a mobile app.
  • Touchpoints might initiate or rely on back-office processes, but they do everything possible to hide those processes so customers don’t know anything about them.

Once you escape the one-dimensional mindset that everything is about cutting costs, creating the appearance of cognition really isn’t all that complicated.

In principle, that is. Making all this work in practice is as difficult as business gets.