eyetoit

Trends in the CIO's Place In The Organization (Reporting to the CFO, That Is)

A couple of recent news items on the changing role of the CIO in the enterprise may be worth sharing. The first portion is on the self-reported changing role of the CIO in the enterprise. The second portion addresses the changes in CIO reporting structures, and the return to the model of the CIO reporting to the CIO.

Last week, META Group released a study, "Driving the Business Value With IT." According to META, only 58% of CIOs feel their role is that of the "traditional CIO" (whatever "traditional" means for a role that is less than two decades old as a common job title). The remainder of CIOs felt they had responsibilities that crossed into HR or Facilities Management, and 29% felt their job responsibility included leading and supporting business transformation. I would have thought that supporting business transformation would be a "traditional" role of the CIO, which leads me to believe that the "traditional CIO" role as META defines traditional CIO to be a position that shouldn't even be a true executive role.

META attributes the growth of CIO responsibilities as being driven by a combination of factors, including an improved perception of IT, the increased importance of compliance and risk management (largely IT-enabled functions) and the improved market and increasing IT spending.

HP's CIO on the ERP Problem & the Art of Diplomacy

A few weeks back I wrote about an AMR Research note on the significant problem HP encountered with an ERP migration; the problems had a material impact on HP's financial results last quarter. This week, Computerworld has an interview with Giles Bouchard on what went wrong with the migration. It's a decent interview, and there are some things to which I would like to draw attention.

The first thing is that the ERP migration that caused the problem was the 35th such migration HP had performed as part of the broader project. The prior 34 obviously went well enough to not cause a major disruption to the business (however, we don't know exactly how smoothly, given that Bouchard also says they planned on three weeks of significant business disruption for this migration). Regardless, the key take-away is that, as they say, shit happens, and even with a proven methodology and approach, it is still critical to plan for contigencies.

One cynical observation I would make about the interview reminded me of a former client, a CIO at a global medtech company, who remarked to me (to paraphrase) "Some of these CIOs I read about must be masterful politicians. You read about projects that completely explode and there's no accountability anywhere in the IT organization." Bouchard certainly could be accused of this. Consider the following exchange:

Business Sponsor Responsibility in Offshore Projects

David Blake and Lance Travis of AMR Research this week released a note titled: "Offshore Outsourcing: Get It Right the First Time." [PDF] It discusses the importance of getting a company's offshore arrangements right, especially given the political backlash against offshoring. They make no mention of the practical backlash against offshoring (i.e. that it doesn't tend to really be better, faster, and cheaper) as I discussed in "Return to Sender" a few days ago.Blake and Travis identify six suggestions for laying the right groundwork with the prospective offshore partner, including:

Technology Innovation vs Business Innovation through Applied Technology

Computerworld released their Innovative Technology awards list this week. The winners are companies with a product to sell, as opposed to companies using technology (although the vendors are nominated by their customers). Many of those products are very IT-specific. (I don't think eyetoIT readers will care too much about Storage Area Networks (SANs) or various compression technology.) Some are not actually innovative at all, based on any definition of innovative I can muster: ForeSee Results, for example, provides pop-up online customer satisfaction surveys on websites. I must just be experiencing deja vu, as I feel like I have seen web sites doing that for years. (Although, admittedly, for as pedestrian as the technology is, I am shocked at how few companies do it, or even do an adequate job of non-transactional customer interaction with their websites.)

You can find the special report online, including some thumbnail case studies of companies that have implemented some of these technologies.

CIO Magazine's Enterprise Value Awards are a better glimpse into business-aligned technology successes. Here's the start of their 2003 report and links to past winners.

The key thing to note is that some of the best innovation for many businesses is not in the core technology, but in the effective application of that technology to achieve a unique business result, for example, Liberty Mutual's legal billing project I recently described. Usually the best people to identify the problem to solve or opportunity to exploit are in the business, not in IT.  Hopefully some of these examples will help educate you in the "art of the possible" for applying technology in your enterprise.

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

Things to Think About With Integration Projects

Computerworld reported in July about a new industry group, the Integration Consortium, that aims to make systems integration projects less expensive and more successful for its members. It is a very ambitious aim, and some of their goals are of a "boil the ocean" magnitude. While we're waiting for the ocean to heat up, a better understanding of integration from a business standpoint should actually help improve an organization's integration project outcomes in the near term.

It is a good bet that systems integration, in one form or another, will continue to drive a good chunk of IT value in many enterprises. Integration is what allows more parts of the enterprise (and the extended enterprise of suppliers and customers) work together with less and less human intervention.

At the very basic end of integration is simply getting system A to send data to system B (e.g. sending filled orders to the AR system for invoicing). More advanced integration has systems A & B sending data back and forth (an inventory and order management system communicating, for example). Progressively more advanced integration projects tie together multiple disparate systems and may start to incorporate aspects of Business Process Management (BPM) such that workflows and business rules are applied to the data moving from system to system (for example, managing the return process from the customer service rep issuing an RMA to the warehouse receiving the return and all the way to accounting for credit).

According to the Computerworld piece, The Standish Group estimates 95% of all integration projects fail, that is, overrun their schedules or budgets and/or underdeliver on their goals. Now, this is one of those stats that begs a number of questions, however, even the base number indicates something is wrong with these projects. The Computerworld piece also says industry studies peg integraton costs at 35% of total IT project costs for the average company. No matter how you slice it, this is a big impact issue.

Since I think the Integration Consortium's dreams are a long way from being realized but recognize that integration should continue to be a business technology objective, here are some things the business should think about when it comes to integration in the enterprise:

The Real Value of Automating Processes

Hopefully anyone reading this knows the old yarn that you can't manage what you don't measure. We also are all aware that sometimes measurement can be expensive, sometimes too expensive to justify. But when a process is automated, there is the opportunity to capture an enormous amount of process measurement data as a byproduct of the automated process.

Timothy Smunt of Wake Forest's Babcock School and Candace Sutcliffe of Liberty Mutual Insurance have a brief piece in this month's Harvard Business Review (Sept 04, p 24; reprint F0409D; HBR subscribers) about the success at Liberty Mutual in automating their AP process for legal services invoices, including electronic invoice submission.

This was a good project by any measure: for a $900,000 investment, they estimate $750,000 annually in direct savings associated with their AP processes. But that's just the beginning. With all the data available, picking out double-billing events or noncompliant invoicing practices is a snap, saving Liberty Mutual even more. But, even that is just hitting the easy bits. Further analytics, and the correlation of billing data to case outcomes allow them to unlock even more value: which law firms do best in which cases, for example.

Imagine if while Firms A & B are each successful an average of 50% of the time, Firm A is successful 80% of the time in certain types of litigation, while Firm B is similarly successful in another type of case. Just reallocating the case load between the two firms means everyone wins (except the guys they're up against). As you can imagine, these kind of changes have the opportunity to deliver far more savings (and recoveries) than so many other sourcing approaches that just nibble around the edges by extracting small savings from suppliers.

Next time your organization is contemplating a process automation initiative, think about what you could do better if you really had all the data about that process available for analysis. And don't stop there, look at your currently automated processes as well. As the title of Smunt and Sutcliffe's note says, "There's Gold in Them [Thar] Bills."

If you have comments about this topic, suggestions for future topics, or questions related to the governance of the IT function or the business-centric use of technology, feel free to e-mail me at eyetoIT@gmail.com.

Return to Sender

Renee Boucher Ferguson reports in eWeek this week that companies are finding that offshoring might not be all it's cracked up to be. She cites research from AMR that only one-third of companies outsourcing are satisfied with the cost savings.

Some of the challenges companies experience are the language barriers, time-zone differences, and generic cultural differences. In my opinion, it is these cultural differences that sometimes become the key. As one person in the article said mentioned, the offshore developers may be good programmers, but they aren't very good at the business logic. This is very consistent with my experience as well.

Offshoring worked in some of the Y2K conversions. You could send a box over to India and say: "send me back exactly this software but with four-digit dates. Don't change anything else." It worked well most of the time. It was highly repetitive work with very clear boundaries. It also isn't work that a good programmer could really do much faster than a poor one, it was rote.

Based on that success some companies started to shift business system development abroad. In addition to incurring additional costs to manage those supplier relationships, they started to find that communicating business requirements and getting appropriate solutions back can be a challenge. What went wrong?

ROI and IT Architecture

I was a little alarmed to see an article on gantthead written by Vijay Sankaran titled "Down With ROI!" Gantthead is aimed at IT project managers and all I am thinking is IT people reading this and adopting this line of thinking in dealing with their organization. Progress for the sale of progress! Onward techie soldiers! My concern was heightened as Sankaran writes, "While I completely concur with the necessity of a business case, I wonder about the great endeavors that mankind may not have pursued if stringent ROI rules had been imposed."

Vijay, we are talking enterprise architecture, not putting a man on the moon! Is the complexity comparable when you look at the IT infrastructures of the world's largest companies? Yes, it is. But nobody is sitting around Citigroup's Network Operations Center saying "One small ATM withdrawl for man, one giant overnight loan for mankind." While the global financial system (and even Citigroup's role in it) is of significant social consequence, it lacks the historical consequence of his cited "great endeavors".

Sankaran's thesis is that when considering migrating an enterprise to a "simplified application and architecture information technology environment...ROI is not the best measure of value-justification." What is? "A systems-based approach [in which] you consider all the externalities of a particular component in a system to evaluate its effect on the overall system."

Despite Sankaran's anti-ROI rhetoric, his basic claim is simpy that one must appropriately expand the scope and the time horizon of an enterprise architecture project's ROI assessment. I think the most fair interpretation of Sankaran's real argument is that enterprise architecture projects should not be held to the same payback schedule as might be required of a more focused initiative.

With that, I can certainly agree. The value of modernizing enterprise architectures has a variety of payback parameters that companies should take into consideration, such as: