Section 2.2. What principles should be driving my IT decisions?


2.2. What principles should be driving my IT decisions?

Geoffrey Moore is a theorist and consultant who developed a very powerful operating model for how companies should assign scarce time, money, and resources in the pursuit of innovation and profit. And considering that you're reading a book about ESAa sign that indicates you're thinking long and hard about how to assign your company's critical and scarce IT resources for at least the next two to ten yearsMoore's model, illustrated in Figure 2-3, might prove of some interest. It's what SAP itself uses to make the business case for ESA. Here it is:

Any corporate activity that increases shareholder value is core. Anything that doesn't is context.

That's the handy rule of thumb, at least. It sounds simple, maybe even simplistic, but let's pause to think it through for a moment. As Moore notes in his book Living on the Fault Line (Collins), "a business process is core when its outcome directly affects the competitive advantage of the company in its targeted markets. Here is the ground upon which companies must differentiate to win power, and the goal of core work is to create and sustain that differentiation."

From that line of reasoning, Moore reaches two conclusions: "For core activities, the goal is to differentiate as much as possible.... And the winning approach to context tasks is not to differentiate, but rather to execute them as effectively and efficiently in as standardized a manner as possible." That does not mean that efficient execution of context processes is not a benefit; it's just not the differentiating benefit that will dramatically increase the company's value.

What does all of this mean in practice? Well, here's what it doesn't mean. Core doesn't necessarily refer to activities that may be critical to your business, such as customer service in some industries. Your actual customers might believe it's critical, but if that were true, you wouldn't have seriously flirted with outsourcing the entire operation to Bangalore. If customer service does not differentiate you from your competitors, it's context. (Unless, of course, you're an outsourced customer service specialist.) Back-office operations are context. Outsourced manufacturing is context you've already implicitly recognized as such. If it is core, why don't you have it in-house?

Figure 2-3. Business process life cycle


Moore's concept of core isn't about "core competencies." Ever since that term was introduced 15 years ago, it's been diluted to mean anything a company is traditionally good at or is known for. Digital Equipment Corp.'s core competency was in building minicomputers, and that didn't help much in the end. In recent years, Hewlett-Packard, which inherited Digital's legacy, has had a hard time distinguishing between its own core/context activities. The company spun off its scientific measurement arm as a separate company, Agilent, in an effort to focus on computing. Today, HP's core is arguably imaging, but what to do, then, with the company's PC and consulting businesses? You can see the dilemmas.

This is not to say that contextual activities are ultimately of secondary importance. A critical defect introduced into a product by one of your Malaysian contract manufacturers, or a bad batch of components purchased by a Chinese subsubsubcontractor, can have an immediate, powerful, and disastrous effect on your business and your ability to deliver increased shareholder value. But Moore's point is that excellence in contextual activities won't differentiate your business and will guarantee neither a competitive advantage nor a nod from the shareholders. He refers to these as hygiene. "Hygiene refers to all the things the marketplace expects you to do well," he writes, "but gives you no credit for doing exceptionally well." Remember, however, that context processes recombined in ways that differentiate can support new core processes. This framework is powerful but subtle.

Few corporations recognize this. By Moore's estimate, a typical Fortune 500 company has a core-to-context ratio of 20:80, meaning that four times as many resources are allocated to what are either best practices that the competition can copy or purchase, or essentially commodities which, from a purely competitive standpoint (the right one, in Moore's view), is a total waste of resources.

One company's context is another company's core, however. Manufacturing may be context to youwhich is why you outsource itbut obviously it's core to that contract manufacturer which must differentiate itself to win your business.

This is how and why SAP came into existence, in fact. It began life by creating the first generation of enterprise applications designed to standardize business activity on systems of record and automate common processes such as payroll and human resources that large corporations preferred not to code from scratch on their own. Its original core was the rest of the world's context.

The current IT architecture of business applications was an originally successful attempt to grapple with the core/context dilemma...up to a point. By standardizing and optimizing discrete sets of functionalityERP, CRM, SCM, and so onin single applications, corporate could deploy the pieces as needed and stabilize their own relatively inefficient contextual processes around what SAP and other vendors had focused on and nearly perfected as core. It worked for a while. TCO fell. The first few generations of ERP made good on its guarantee to endow a competitive advantage, albeit a temporary one, to those who were wise enough to install it.

However, two things happened. First, the current generation of IT essentially became commoditizedeveryone had ERP, so now what? The investments were made, the ROI was hopefully acceptable, and now everyone had a massive investment on their hands that was gradually becoming increasingly expensive, complex, and hazardous to modify in the pursuit of innovation. Second, the business models of ERP owners changed over time (some suddenly, but most gradually) and what was once considered core became contextwhich Moore predicted, but enterprise software vendors did not.




Enterprise SOA. Designing IT for Business Innovation
Enterprise SOA: Designing IT for Business Innovation
ISBN: 0596102380
EAN: 2147483647
Year: 2004
Pages: 265

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net