All Posts in Organizational Design

|In: Cognitive Enterprise|Last Updated:

OODA loops aren’t limited to competing strategies, and there’s more to an enterprise being cognitive than making use of OODA loops.

Sorry for starting in the middle. Regular readers will recall Colonel John Boyd’s OODA loop. For the rest, it stands for Observe, Orient, Decide, and Act, after which you review the results of your Action … you Observe, starting the cycle again.

OODA holds sway in time-bound competitions, where whichever side has the faster OODA loops wins, because the faster side’s actions invalidate the slower side’s observations, orientation, and decisions, forcing it to start over.

But OODA isn’t restricted to competitions, and in fact it’s a decent general-purpose model for cognition, which is why The Cognitive Enterprise — the book I co-authored with Scott Lee on this subject — uses OODA as a general-purpose way of making an enterprise more cognitive.

Time to take a step back, because OODA is a mechanism — a way for enterprises to become more cognitive. It isn’t the essence. At the heart of the concept is that the enterprise acts with intention — it’s akin to an organism that has a purpose and acts so as to achieve it.

Look at two enterprises, one industrial, the other cognitive, as a customer, from the outside in. An industrial enterprise looks like what it is — a collection of processes you as a customer have to figure out in order to do business. If the processes aren’t designed to deliver what you want to buy, you either live with the frustration or take your business elsewhere.

A cognitive enterprise, in contrast, interacts with each customer as if the interaction was a person-to-person conversation. The ability to act with intention in ways that adapt to each customer’s needs is what lets entrepreneurships survive while surrounded by much larger competitors. Cognitive enterprises figure out how to make entrepreneurship scale — not only when it comes to strategy, but throughout.

Take, for example, Amazon’s “Customers Who Bought This Item Also Bought …” and Netflix’s “Because you watched …” features. They’re excellent examples of enterprises being cognitive, right down at the level of one-on-one customer interactions. They follow the OODA model quite nicely, too — they observe what you shop for, interpret your behavior so as to infer your preferences (they orient), decide on what to offer you, and then show you the offer in a persuasive way.

Down at the level of individual customer interactions, the most successful companies right now all seem to be as cognitive as they can be.

Your challenge: Quite obviously, no business of any size can achieve cognition without a lot of information technology, some of which interacts with customers directly, the rest of which supports employees who interact with customers directly.

Is your IT department ready to provide it?

* * *

And on a completely different topic, there’s Delta.

In case you somehow missed the story, Delta had a complete systems meltdown last week, grounding its fleet and stranding thousands of travelers for days.

Delta initially blamed the problem on a power outage, leaving all of us who know anything at all about the subject scratching our heads.

You don’t get to run a data center at the Delta scale without having sophisticated power management. Decades ago, when I was directly responsible for some of this, we made sure we were getting power from two separate substations so that a single transformer failure wouldn’t affect us; this in addition to our UPS and backup generators.

And, we tested all of the above from time to time to make sure they worked — this in a relatively small, 2,500 employee corporation.

Among the many puzzling aspects of this story, two stand out.

The first is that Delta’s explanation of what happened seems to change every day. First it was a power outage. Then it was a transformer. Then it was a failed electrical component that took down the transformer that provided power to the data center. That’s the transformer, not one of the transformers, which would mean Delta’s power distribution system was built with a single point of failure.

Then, maybe, there was a fire in the data center, too.

Which brings us to the second source of puzzlement: I’ve read few complaints about Delta’s ever-changing account of these events, but lots of speculation as to what might have been the “real” problem, even though Delta’s ever-changing account of things is an observable fact while the speculation — which includes the usual Strongly Held Opinions about Why Delta Should Be Ashamed of Itself — is largely fact-free opining.

The view from here: Let’s find out why Delta should be ashamed of itself first.

Comments

|In: Industry Commentary|Last Updated:

If you want technology changes to be successful you need an effective change management process. If you want a business change to be successful you need  organizational change management.

For years, this similarity of names for very different processes was confusing.

Now it’s a good idea.

ITIL, in case you’ve never run across it, provides a comprehensive framework for understanding IT’s moving parts, how they fit together, and how IT management should handle them.

In the land of ITIL, change management is how IT operations takes the finished modules produced by dev teams and moves them to the test environment where software quality assurance can have its way with them, and from there into production.

Meanwhile, in another part of town, the folks responsible for OCM have been making sure the business areas that will be affected by the new software are properly prepared and ready to embrace the coming change.

The point of ITIL change management is to make sure software changes don’t blow up the IT production environment. The point of organizational change management is to make sure process changes that are the reason for software changes don’t blow up the business production environment.

They’re different things. One is about IT. The other is about the business. What could possibly go wrong?

Once upon a time, the answer was, not all that much. So long as the end-user training schedule coordinated so it preceded software’s move into production but not by much, there wasn’t much harm in considering these to be independent responsibilities.

But now we have DevOps, with its delivery model of continuous integration and continuous delivery — in some cases dozens of changes every day. As applied to a company’s internal systems, we’re talking about a potential mess, and not a small one.

The core of the problem is that DevOps as usually described is only appropriate for software companies and B2C eCommerce systems. These are the situations where software delivery is the same thing as business change.

For software companies it’s the same as business change because the direct result is an improved product, and the desired business change is the improved product.

Software delivery is the business change for B2C eCommerce systems, too. The purpose is to get the cash register to go ching more often and with more in the shopping cart. Yes, shoppers might get a slightly different experience each time they visit Amazon, ThinkGeek, or pick-your-shopping-site, but so what? On-line shoppers expect this and don’t get thrown by it.

The rest of the time, software delivery enables but doesn’t accomplish the desired business change. It’s a necessary but not sufficient condition for the change to happen.

If the difference isn’t clear, imagine you’re a sales rep. IT in your company has embraced DevOps, including continuous integration and delivery throughout the applications portfolio.

You use the company’s CRM system to keep track of which customers you need to contact, when, and about what. Only with DevOps everywhere, every time you open the CRM system you see a different screen layout.

Not what you’d call a dynamite productivity enhancer. Also not something you’ll find discussed very often in the DevOps literature. (I haven’t seen it discussed at all, but I’m sure I just missed it.)

The fact of the matter is, different business areas have different natural change cadences. All aspects of business change have to be orchestrated to match that cadence, from process redesign, to metrics redefinition, to deploying new equipment, to training, and to putting new and changed software into production.

And oh, by the way, even what sounds like the same old stuff really isn’t, because back when the theory for all this was being developed, work was performed by employees sitting at desks in cubicles at a company facility.

In the increasingly permeable enterprise, some affected employees work remotely, some remote and on-site workers aren’t employees at all, and some work has been shifted out of the business entirely. It’s been turned into customer self-service processes, and believe me, the folks who work in what used to be called Purchasing but is now Supply Chain Management aren’t going to have a lot of patience when the screens they use change without warning or preparation.

And so, a modest proposal: Get rid of most of the superstructure. Define projects and initiatives in terms of the desired business change, include coordinated work streams that cover all aspects of putting the change in question into production, and instead of yet another committee to speed things up (yes, the irony was intentional) just incorporate whatever the Change Advisory Board would otherwise do into project governance instead.

Simpler is, after all, usually better.

Comments