All Posts in Metrics

|In: Industry Commentary|Last Updated:

The CIOs of most large enterprises can sympathize with New York’s Metropolitan Transit Authority. As described last week, the MTA runs its entire, vast, complex subway system on 1930s technology. Compared to this, the 1970s-vintage boat anchor IMS DBMS so many CIOs can’t get rid of because mission-critical applications run on it seems positively modern and benign by comparison.

As pointed out last week, when depreciation was first incorporated into the world’s Generally Accepted Accounting Principles (GAAP), it was supposed to represent how a capital asset declined in value over time. Were business executives to take depreciation seriously, they’d look at their balance sheets, see that the company’s asset value is declining, and do something about it.

Well, no. It isn’t that simple.

First and foremost, one of the key metrics Wall Street Analysts rely on is Return on Assets (ROA). As most 5th graders can tell you, there are two ways to improve ROA: Increase returns, or decrease assets.

It’s metrics at its finest: decrease asset value as reported on the balance sheet and voila! Without any change in actual competitiveness the company’s financial performance magically improves.

Now imagine you’re in charge, and you have a relentless focus on long-term sustainability instead. What would you do differently?

High on your list might be squirreling away the funds needed to replace obsolete business assets as they become increasingly valueless, ROA be damned.

Nice thought. One minor gotcha: Time, trends, and evolving marketplaces have made some of those assets irrelevant. Or, worse, they’re part of a business infrastructure that impedes your ability to redirect the company in a direction that’s more in harmony with changing competitive demands.

So it isn’t as simple as replacing assets as they become obsolete.

In IT it’s even less simple, because assets that aren’t the least bit obsolete … well-engineered business applications that support important segments of the business quite well … can still require platforms that for one reason or another are marketplace failures.

Like it or not, and it’s usually not, your choices are limited: Redevelop the offending application on and for platforms that seem to have some staying power, or replace it with a commercial package that will do the job and seems to have some staying power.

It’s Hobson’s Choice: Rewrite or convert.

For this case, the underlying principle seems to hold: The business needs to keep money in the bank for use replacing applications and their underlying infrastructure when one, the other, or both are reaching their limits of viability.

It’s downright strange, isn’t it? While you have to replace a perfectly serviceable application because it or the platforms it uses aren’t making it in the marketplace, your buddy down the road has to replace a major application … an ERP suite, perhaps … that’s a major marketplace player, only it’s become a liability because it can’t be configured to effectively support the company’s future business strategies and tactics.

Or, another friend finds herself retiring one application because it supports a business her company is no longer in, while also having to implement an entirely different piece of software that’s needed for the business it’s going to be in.

What do all these permutations have in common?

In every case, dealing with the situation will take time, effort, expertise, and money. It will take them because of a fact known only to a small number of highly insightful individuals who belong to a secret society called, with apologies to Drew Carey, Everyone.

That fact: The future is generally different from the present. More, it’s different in ways that are only predictable in the million-monkeys sense that if enough people make predictions, the odds are pretty good that through nothing more than random chance, a few of them will end up guessing right.

Its future being different from its past, the tools a company will need to deal with the future will be different from those it needed in the past, too, not to mention that the tools available to it will be different from those that were available in the past.

Which gets us to this: Running a sustainable business calls for constant reinvestment, and when it doesn’t that just means the investment that isn’t needed this year will be needed in spades next year or the year after.

Which is yet another reason stock buy-backs are such a terrible idea: They take cash that could be invested in sustainability and get rid of it in order to prop up the price of a share of stock. So when the company finds it needs the money after all, it only has one choice left to it:

Issue a bunch of new shares of stock.

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