All Posts in Organizational Effectiveness

|In: Industry Commentary|Last Updated:

The value of information struck me while I was waiting for an elevator.

In the lobby of most buildings each elevator’s position is displayed above its door. Armed with that information you can intelligently decide whether to wait for it or climb the stairs instead.

But elevators give you no positional information on any other floor, forcing you to guess whether waiting or using the stairwell is the better vertical travel decision.

Fixing this is trivial engineering. As the Rutles once sang, all you need is cash.

Not so for the New York subway system, as explained in “Why New York Subway Lines Are Missing Countdown Clocks,” (James Somers, The Atlantic, November, 2015), a charming and fascinating article that explains the answer to the author’s question, “I honestly just wanted to know why the F train didn’t have clocks. I never expected it to be so complicated.” (And thanks to long-time correspondent Leo Heska for calling the article to my attention.)

Turns out, the answer isn’t what’s complicated. The New York subway system relies on early 20th century technology whose architects had a clear and well-chosen design goal: Subway trains must not collide.

To accomplish this goal they engineered an elegant combination of sensors, switches, and on-track displays, through which drivers know whether the next section of track is occupied by another train. If so they slow down. If they don’t, a mechanical relay tied to the train-detection sensor automatically applies the brakes.

The system, that is, was designed for Operations, and relies on a highly decentralized combination of human and automated decision-making. Nothing about it identifies individual trains and their positions, so there’s nothing in it to repurpose to tell passengers when the next train will arrive, let alone support any management analytics.

Solving this is a non-trivial problem.

If these were trucks, a GPS receiver, IoT chip, and Google Maps hack would make it pretty easy. But we’re talking about subway trains. They don’t have line of sight to any GPS satellites, and so, never mind.

Maybe there’s nothing to solve. Knowing each train’s position and velocity is, after all, a luxury, not a necessity. Well, okay, except for this small detail: The entire system is worn out, there’s no source of spare parts, and even the wiring’s insulation is about shot.

Oh, and the estimates for replacing this 1930’s vintage technology with something modern start at $20 billion.

Does any of this sound familiar — a legacy system that would be good enough except its architecture is obsolete, the platforms it runs on aren’t around anymore, and:

  • “Lift-and-shift” replacement provide no new features, and so no business-driven value to justify the expense?
  • Nobody can describe important new features that would justify anything more than a lift-and-shift replacement?
  • Investing in any kind of replacement system would drain needed capital away from other efforts that are also important for the organization’s ongoing survival and success?

Of course it does.

We’re dealing with a linked pair of seldom-discussed IT disciplines: Lifecycle management and migration management. Lifecycle management is about detecting incipient obsolescence and preventing it. Migration management is about becoming excellent at replacing obsolete or near-obsolete systems.

Together they make obsolescence avoidance an operational matter, from both a budgeting and an execution perspective.

Competence at migration management is what makes IT very good at moving from obsolete technology to something modern enough to last a while. Lifecycle management is what says it’s time to repeat the cycle.

Here’s how they might have helped New York’s Metropolitan Transit Authority:

By 1985 (to pick a year out of the air), the subway system relied on 50-year-old technology. Computerization was by then mainstream. The subway control system was clearly obsolete.

So imagine if the MTA had started migrating to a modern system in 1985 through a phased, route-by-route plan.

By now it would probably be time to start the next migration … but it would be from a far better base state, with no looming crises from a lack of spare parts and failing insulation driving a high-risk replacement project along.

Depreciation is the mechanism through which the general ledger depicts how a capital asset … the New York subway system’s control system being an example … loses value over time.

What’s strange is how many business executives consider it an accounting fiction. If they just believed their financial statements they’d bank the funds needed for capital asset replacement as standard operating procedure instead of lifecycle management starting with hat-in-hand supplication.

That’s right: The problem isn’t executives managing by the numbers.

It’s executives choosing to ignore them.

Comments

|In: Cognitive Enterprise|Last Updated:

It’s time for businesses to think.

The Cognitive Enterprise (Bob Lewis and Scott Lee, Meghan-Kiffer Press) has been released into the wild. The questions of the hour: (1) What makes an enterprise cognitive? (2) Why does it matter?

There seems to be a strong negative correlation between the size of an organization and its ability to respond in sensible ways to changing circumstances. And this lack of good organizational sense seems to be independent of how smart the organization’s leaders and staff are.

It’s as if there’s an impenetrable barrier that prevents the considerable intelligence available in a business from influencing the behavior of that business.

Superimposed on this is the industrial model of business management — the notion that businesses should be “designed by geniuses to be run by idiots.”

This is the driving philosophy of most business process design: Simplify, simplify, simplify. Which, depending on the process and its goals, often is the best answer. In truly industrial situations — manufacturing and its analogs, where the goal is to create large numbers of identical work products — simplification and standardization make all kinds of sense.

But (you know “but” was just floating in the air, waiting to be uttered …)

With a few exceptions, business is first and foremost a game. It’s about winning and losing. In the short term, it’s pretty close to a zero-sum game, where one company selling more products to more customers means some other business will find itself selling fewer products to fewer customers.

There just aren’t that many games where success comes from streamlining, simplifying, and standardizing. In football, the winning teams aren’t the ones with the skinniest playbooks. In baseball, pitchers don’t throw every pitch exactly the same. If they did, they’d get shelled.

If you don’t like athletic metaphors, consider chess. Think a grandmaster is going to win by always playing the same opening?

* * *

Business designers follow a well-worn formula: People, process, technology.

Except it’s really PROCESS, Technology, people. No, it’s worse. People are an actual impediment. Carefully designed processes, written standard operating procedures, and automation are all established to overcome the limitations of we pesky human beings.

This worked just fine in the past because of a key and rarely explored metric — the stay-the-same to change ratio.

That business cycles are compressing isn’t a new insight. What’s often missed: Establishing well-defined and (more important) well-practiced business processes, supported by optimized automation, takes an investment of time, effort, and money. Having invested, businesses need a long enough period of stability to recoup that investment.

Business cycles are compressing — the stay-the-same piece of the ratio is shorter — but the change side of the ratio hasn’t compressed anywhere near as much.

Same investment, less time to get a return from it.

Which is why Scott and I are proposing a new framework. Instead of people, process, technology, cognitive enterprises will emphasize customers, communities, and capabilities.

Start at the end: A capability is anything an organization can do, independent of whether it’s doing it right now. Capabilities are what let an organization adapt to changing circumstances.

Communities next. More and more, the men and women who contribute their efforts to an organization’s success have less loyalty to their employer. (Employers, of course, jettisoned the quaint idea that they owe their employees any loyalty long ago.)

Supplanting, or perhaps augmenting employees’ relationship with their employer is their relationship with their profession and their peers in that profession. Developers, for example, constitute a thriving community, whose members are better at their trade in proportion to their community participation.

And their employers benefit from this by getting better programmers with a smaller investment in training.

Communities build capabilities.

And then there are customers. It might seem strange that customers need mentioning, but they do. Industrial businesses have a strong internal focus — so much so that most of the business considers other parts of the business to be their customers. This internal-customer focus is the source of untold mischief.

In a cognitive enterprise, everyone has the same customer — the real, paying customer who makes buying decisions about the company’s products and services.

And, understanding what these customers want, cognitive enterprises are able to marshal their capabilities to deliver it, whether or not they have a well-define process in place to do so.

Is this all there is to it? Of course not. If it was, Scott and I wouldn’t have had to write an entire book.

And we wouldn’t be asking you to read it.

Comments