Strategy and Tactics – Page 27 – IS Survivor Publishing

The world is Digital?

Tom Friedman discovered the Internet ten years ago (The World is Flat, 2007). I’m sure you were as pleased for him as I was.

But to be fair to Friedman, he’s a smart feller who sometimes does have useful insights, like, for example, about Digital stuff. Without using the term once — and good for him, especially for not using it as a noun — he recently provided as neat a synopsis of how we should all be using the Digital adjective as I’ve seen (“Folks, We’re Home Alone,” New York Times, 9/27/2017).

Here’s the exact text:

We’re moving into a world where computers and algorithms can analyze (reveal previously hidden patterns); optimize (tell a plane which altitude to fly each mile to get the best fuel efficiency); prophesize (tell you when your elevator will break or what your customer is likely to buy); customize (tailor any product or service for you alone); and digitize and automatize more and more products and services. Any company that doesn’t deploy all six elements will struggle, and this is changing every job and industry.

Let’s take a closer look:

Analyze: In Friedman’s view this means finding patterns, presumably through the use of multivariate statistical techniques, leading to the well-known logical fallacy of thinking correlation proves causation.

For businesses, though, the framework of causality that leads to a pattern often doesn’t matter. If the data reveal a pattern — say, that the presence of fire fighters correlates with the presence of fires — it really doesn’t matter if the fire fighters are setting the fires or putting them out. What matters is that this is a good place to put a lemonade stand, because the data also reveal the pattern that fire fighters who are near fires are often thirsty.

Optimize: I know the route to the airport. But I still use Google Maps to get me there. Why? Google will route me around traffic snarls to get me there faster.

More broadly, we’re leaving the age of fixed-flow linear processes in favor of processes that dynamically adapt to changing situations. Take, for example, the OODA loop we’ve discussed in this space from time to time (observe, orient, decide, act).

More and more data (observe) means you need to use Digital technologies to analyze it for meaning (orient), followed by self-learning AI choosing a course of action (decide) and learning from the results (back to observe). Humans might or might not be involved in implementing the decision (act), depending on whether the action takes place in the physical or virtual world.

Prophesize: Look at the figure. It shows white noise. Since business first started eons ago, the best strategic decision-makers have learned to ignore noise, searching for the signal within it.

But as algorithmic traders have figured out, if you can make decisions fast enough the noise can be the signal. You just have to be able to respond to each change of direction fast enough. Do this and it counts as prophesy: “For the next x units of time we should expect our markets to follow this very short-term trend.”

Customize: Here’s something I’ve been writing about for years. Especially with increasing wealth stratification, the ability to tailor and customize, driven by affluent customers’ desire for uniqueness, will be a critical competitive differentiator. Luxury is, after all, relative, not absolute, which is why even the snazziest-looking Timex watch that keeps perfect time is not a luxury, while a Rolex, which, having a mechanical movement, keeps nothing resembling perfect time, is a luxury for those few who can afford one.

Digitize and Automate: I don’t know what the difference is between “digitize” and “automate.” I’m pretty sure one, the other, or both mean “have the computer do it, not human beings.”

Either way, the idea is that businesses can reconfigure themselves more quickly when everything is done in software. And they can, assuming modern application architecture, modern integration architecture, and short-cycle-time techniques like the Agile/DevOps combination.

Collaborate: This is a big one, and Friedman missed it. Individuals can’t do everything all by themselves. That takes teams, and teams of teams. Not groups. Teams. The difference: Members of a team trust each other and collaborate. Members of a group trust nobody, and negotiate. This slows everything to a crawl.

Companies can’t do everything all by themselves either, so the teams and teams of teams in question often consist of employees from more than one company. If they can and do trust each other they can collaborate. If they can collaborate they can deliver terrific results together. If they can’t they probably can’t.

So let me ask you: How much is your company willing to invest in trust?

No matter where you turn, it’s complicated

It’s always more complicated than it looks.

Case in point: Houston

Your hypothetical challenge: Bring the city back on line. What does this entail?

Lots and lots of lots and lots, that’s what.

Understand, I know nothing at all about civil engineering, or emergency management, and not all that much about enterprise risk management. What I do know is that nobody else can keep the list of everything that has to come back on line in their head either, let alone the interdependencies that could lead to creating a proper Gantt chart.

Oh, by the way, a half hour of Googling failed to uncover anything resembling a disaster recovery plan for the city of Houston. An emergency management plan yes, a recovery plan no.

Which isn’t necessarily bad management. As with IT’s ancient habit of trying to create comprehensive software designs before beginning to write any code, so disaster recovery plans of metropolitan scale or larger for disasters of inordinate magnitude are probably pointless. If, that is, they do much more than list the organizations that need a recovery plan, specify what one should encompass, and insist they have them.

Even then there are limits. As everyone who’s involved in disaster recovery and business continuity knows, a plan that isn’t tested isn’t a plan.

And along came Harvey.

Case in point: New York City.

I worked with a client there several years ago, enough that a corporate apartment made more sense than staying in hotels. The result, though, was that for a couple of years I qualified as a resident, meaning I owed New York City taxes. These were (1) substantial, and (2) business expenses, not directly deductible from my Minnesota state tax bill.

This sawed me off. Until, that is, I saw a sign in the midtown Whole Foods that explained New York City creates enough garbage every day to fill the Empire State Building.

It occurred to me then that I had not the slightest idea how to go about removing that quantity of garbage every day, and that garbage removal is far from the most complicated challenge in running New York City.

As I had no idea how to run NYC I certainly had no idea how to run it at a lower cost, which meant I should put up and shut up. I benefited from services I didn’t even know were being provided. My New York City tax burden was how I paid for them.

Case in point: Any legacy retirement

Over and over again, companies make this mistake: They decide to retire the ancient mainframe batch COBOL system the whole company has been running on for forty years. And from this decision comes a logistical nightmare, because no matter how you go about it, you can’t shift the entire company from the old system to a replacement at the flip of a switch. It has to be phased and staged.

And no matter how you go about the planning it turns out many business areas will be running in a mixed environment for a year or more.

But unlike New York City or Houston, a lot of this complexity is a self-inflicted wound, the result of looking at exactly the wrong end of the horse.

The problem is the decision to retire the mainframe. Not that the company should stay on it. No the problem is that this focuses everyone’s attention on what they’re migrating from. In addition to the logistical migraines this thought process creates, it results in something even worse than the planning nightmare: When the project is done and the mainframe has been retired, the business runs pretty much the same as it ran before it invested the zillion or so direct dollars, plus sweat and opportunity costs, that were needed to make it all happen.

Much of which would have been avoided had everyone focused on the opposite question: What to migrate to.

Even better, they should be focused on how each business manager at every level wants to run his or her part of the business differently and better, leading to an applications portfolio plan that will mostly let them do so.

Taking this approach, things still aren’t simple. They are, however, simpler — a lot simpler, because (for example) moving Sales to a modern CRM system is, at a minimum, clear in what has to happen.

And moving Sales to a better sales process that’s possible because of the modern CRM system’s features has actual business benefit beyond a modest reduction in the IT operating budget.