All Posts in Cognitive Enterprise

|In: Cognitive Enterprise|Last Updated:

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.

Comments

|In: Cognitive Enterprise|Last Updated:

Want to volunteer?

Enterprises need to become more cognitive — a point made in The Cognitive Enterprise and reinforced in quite a few of our weekly conversations.

And yet so far as I can tell, enterprises are, if anything, becoming less and less like organisms that act with intention. They aren’t even doing a good job of acting like mechanisms, as my process-oriented consulting brethren recommend.

No, taken as a whole, your average enterprise seems bent on devolving into a collection of semi-autonomous squabbling siloes.

It’s like this: If OODA loops are how enterprise cognition operates, informal collaboration is the cultural attribute that allows it to happen. And organizational siloes with high walls and impermeable boundaries are the single biggest organizational barrier to informal collaboration.

It’s time to do something about it. Here’s what I have in mind.

The Challenge

We need a metric — a way to measure silo height that satisfies the 6 Cs of good metrics. In case you haven’t read chapter 3 of the KJR Manifesto, they are:

  • Connected to important goals.
  • Consistent, always going one way when getting closer to the goal and the other way when getting further away.
  • Calibrated, so the act of measurement yields the same results whoever takes the measure.
  • Complete, because anything you don’t measure you don’t get.
  • Communicated because otherwise, what’s the point? Metrics drive behavior — that’s the most important reason to have them.
  • Current, because business goals change, but not if how the business measures itself doesn’t.

Fortunately, while we’re pretty much starting from scratch when it comes to measuring silo height, we do have a model we can use to help jumpstart the process — the Net Promoter Score.

Most business leaders understand that customer satisfaction matters, which means measuring it matters too. But measuring the psychological state of a customer is no easy task. It’s more like a fool’s errand than a difficult but rewarding undertaking.

And so was born the Net Promoter Score (NPS) (credit to Fred Reichheld) — a tool based on an easy-to-ask, easy-to-answer question: How likely is it that you would recommend this company to your friends?

If the NPS stopped with giving companies a measurement it would have limited value. But it doesn’t: Companies that participate in the NPS project also see statistics for their industry as a whole, which provides a sense of how they’re situated in their competitive landscape.

This is invaluable.

And finally, Bain & Company, the folks who own and administer NPS, are in a position to correlate NPS with business performance. No, correlation doesn’t prove causation, but it’s better evidence than just taking it all on faith.

The Silo Height Index Project (SHIP)

Here’s the plan, such as it is. We need to:

  • Develop a simple question or short set of questions that can be answered on a 1 to 10 or equivalent scale and that will reliably reveal an organization’s silo height — it will be a calibrated measure.
  • Promote the concept widely enough to reach critical mass — enough participants to do some statistical slicing and dicing with the results so the results are interesting enough to matter.
  • Establish a repository to manage the data. Following the principle of permeability, this should be made widely accessible at no charge, to give anyone interested the ability to play with the data. But, the public database can’t contain any … what shall we call it … Corporately Identifiable Information (CII) … so we’ll also need a private database that does contain CII. This will allow for follow-up research of a more sensitive nature, should that prove desirable.
  • Flesh out the business model. I’d like this to be an open-source-like effort without it being a crowdsourced effort. I’ll take initial responsibility for curation, but there’s always the danger of success — it by some strange combination of circumstances this catches on in a serious way, I don’t want to become a pothole in the road of progress.

If you find the concept appealing enough that you’d like to work on it … and I do mean work; this won’t happen without real effort … please send me an email letting me know what aspects of SHIP you’d like to participate in, and what qualifications you have for doing so.

One more thing: If you like the idea, spread it around. There’s no time to start promoting this like the present, so please forward this edition of Keep the Joint Running to anyone and everyone you know who might want to be in on it.

Launching this SHIP (I had to) is going to be a long shot, but what the heck. Even long shots sometimes find their target, and this target is certainly worth shooting at.

Comments