eyetoit

KISS

This post is neither romantic in nature or talking about the iconic 70's band by the name Kiss. Rather, this is about the good advice of KISS: Keep It Simple, Stupid.

Complexity is one of those paradoxical things that in business tends to be verbally opposed - but actions speak louder than words, and all of us in business have a tendency toward adding complexity just one bit at a time - draining the productive blood from the organization through a series of paper cuts. This month, Ken Keverian, Vikas Tenaja and Bob Victor of the Boston Consulting Group have an interesting article, "As Simple as Possible" [PDF Link] that has some intereresting food for thought on complexity.

While complexity can lurk anywhere in an organization, Keverian et al, seem to see most of it driven by a form of customer-responsiveness. This makes sense, it would be rare (and rather irrational) to introduce complexity for no reason. They provide three quick warning signs to look at your company to see whether you may have too much complexity. Do any of the following sound like your company?

RFID - Value Beyond Supply Chain Management

Wharton professors Peter Fader and Eric Bradlow recently released a paper in the International Journal of Research in Marketing entitled "An Exploratory Look at Supermarket Shopping Paths." A PDF draft of the paper can be found online. I was alerted to the paper via this reasonably detailed highlights article from Knowledge@Wharton.

There were some findings that may be interesting to retail grocery marketers, and may be surprising if you haven't actually done any grocery shopping. As might be expected, while some of these findings offer insight, most of them could have been captured just be actually spending time watching customers. Possibly the most amusing part is just how wrong conventional wisdom about shopper behavior was. Some findings:

Technology Is Not for Babysitting

Dr Carsten Sorensen of the London School of Economics has recently released a report comissioned by Microsoft. The report titled, "The Future Role of Trust in Work" [PDF] has some findings that are potentially troubling, and not for the reasons privacy activists may be concerned.

In a nutshell, the report observes that network technolgy such as cell phones, e-mail, instant messaging and phone-based text messaging have created an environment in which managers are more prone to micromanage. From the LSE press release:

He describes how the old classical management hierarchies of the past are being replaced by flatter networked structures. He explained how micromanagement causes people to spend a lot of time proving that they are working, instead of getting on with actually working. The trick will be setting up a system where the workers see a benefit in being monitored. ’But building the kind of trust between management and workers can take years, and it can be erased in a second,’ Sorensen notes.

Infrastructure Complexity

Swapnil Shah has an "opinion" piece in Computerworld this week on the challenges of complexity in corporate computing infrastructures, "Defying the IT 'Butterfly Effect.'" I put the scare quotes around "opinion" because in all fairness, Shah is the CEO of mValent, a company that, not surprisingly, has tools for managing complex corporate computing infrastructures (imagine that!).

However, Shah's economic interest in solving the problem doesn't diminish the truth of much that he writes, and it is good food for thought when thinking about the real cost of excessively complex architectures. And while Shah focuses on the value of tools from vendors such as mValent for solving some of the problems this complexity creates, it is also worth considering the long-term savings that can result from rationalizing a complex architecture, as I wrote about some weeks ago in "ROI and IT Architecture"

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.

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:

Crazy But It Just Might Work

Computerworld has an article on the revolutionary idea of CIOs working with their fellow executives to educate them on certain aspects of IT. There are some goofy bits in the article, including an IBM sales VP referring to people as "cats," which I thought was quite retro. There is also an interesting sidebar on a the basic syllabus for the educated business executive according to Mark Jeffery at Kellogg (Northwestern). His main items are:

• What can happen if you don't manage technology well.
• The language of technology
• Corporatewide systems like ERP and CRM
• Why CXOs need risk management skills
• What can happen if you botch security
• Technology trends

I think this is a good list, although I think it misses one of the most critical aspects which is the actual role of the business in strategy development and execution of IT.

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.