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?

Square Peg/Round Hole

GTSI, a government technology sales and integration firm reported recently that they will be missing their earnings targets and may have jeopardized their growth plans due to problems implementing a new ERP system.

GTSI went with PeopleSoft as their ERP platform (clearly prior to Oracle's acquisition of PeopleSoft). As a distribution firm, it is unclear why they went with PeopleSoft's platform for their ERP. I can see a couple of possible reasons, one being that PeopleSoft does have a fairly good presence in the public sector markets (although it's reputation there has not been pristine, with some challenged implementations in some state universities). Another possibility is that they bought when PeopleSoft was basically trying to buy business through extremely heavy discounting as they tried to fend off Oracle's takeover offer.

All Things In Moderation - Sensible Choices between Custom and Package Applications

I am usually considered a big fan of custom software (also known as signature software, or bespoke software to those in the UK). I think companies today often put too much reliance (faith maybe) on and poorly assess the total cost of ownership of a packaged application and concurrently overestimate the risks associated with custom development. Having a consultancy that delivers both signature software and implements Tier I ERP products gives me an unusual vantage point and a fair amount of balance in this area, or at least I think I have my bias under control.

I recently came across a case study about the IT operations at Crutchfield Corp, the electronics retailer HQ'ed in Charlottesville, Virgina. This is a company that seems to have gone overboard in the custom development activity. According to this Computerworld case study ("Closely Held Applications") Crutchfield has 18 developers supporting 300 custom applications which consitutute 85% of the running software code inside the company. (I am assuming they are excluding office productivity applications and operating systems from this figure).

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:

Project Success Rates Revisted: Gartner on Bite-Size Software

A few days ago I wrote about the downward trend in project success rates, one of the hidden reasons I mentioned was the increase in large enterprise application and ERP upgrades over the past year. As I mentioned, one of the downsides of the suite or all-in-one approaches taken by large vendors is the enormous, and consequently costly and risk-prone, projects to implement or upgrade those application suites.

Computerworld reports on Gartner Group's recommendations that software manufacturers move to offering more "bite-size" software options for companies, to give them the flexibility to upgrade components of their systems asynchronously, without having to roll out an entire new enterprise application suite just to get the new warehouse management functionality, for example. Of course the additional benefit to companies would be that such a "bite size" component approach would also reinvigorate large ERP vendor competition from Best-of-Breed niche players in particular segments. I find it questionable how much motivation the large vendors such as SAP or Oracle would have to break their applications into these bite-sized chunks, especially as they are already hungry for ways to drive additional revenue. And then of course, there is the issue of integrating all of these bite-sized pieces into a meal fit for a global enterprise. As I have written, integration projects have their own challenges as well.

Of Scorecards and Dashboards

Someone recently asked me to explain the difference between scorecards and dashboards, as this person seemed to hear them used almost interchangeably at his company regarding a portal initiative. Using the rule of thumb that for every person who asks a question there are at least ten more that also want an answer, I figured a quick discussion here might be in line. I will also provide some comments about what the role of each is, suggestions for each type of system, and which might be more relevant to your business (or business unit).

The names of each are actually very well-chosen with respect to their real-world analogs. A scorecard is usually part of a broader corporate methodology or management discipline and is a report card of how a given person, business unit or entity performed with respect to certain goals over a given time period. A dashboard is a set of indicators about the state of a process, piece of equipment, or business metric such as cash on hand or YTD sales at a specific point in time.

An example should make this very clear.

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:

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.

Enterprise Software Negotiation

This week AMR Research produced a note on negotiating with SAP. They focused on SAP because the company is doing very well despite AMR's view of the sector being weak. This idea of the Enterprise Applications (EA) sector (ERP, CRM, SCM, etc.) being generally weak does not resonate with my current experience. I am seeing a significant number of non-SAP (mostly Oracle) ERP implementations in the local market, although Oracle has a historically strong footing in these parts. I think part of the sector weakness right now may be caused by Oracle's continuing, and possibly Quixotic, designs on acquiring PeopleSoft as well some uncertainty among current JD Edwards customer caused by PeopleSoft's acquisition of JDE.

Getting back to the issue of enterprise software negotiation, it is important to recognize that incumbent package vendors have some significant advantages when they come to the negotiating table (beyond the obvious issues of frequently negotiating EA deals and having a more intimate understanding of their licensing models). Enterprise applications are expensive to implement and relatively painful to change, especially if moving to a new packaged application that would possibly need to be customized or involve substantial process change or retraining. This creates enormous switching costs, a software vendor's most significant advantage. Vendor lock-in is even more significant now as companies are further hesitant to switch because of their recent efforts in process control and documentation activities driven by Sarbanes-Oxley compliance initiatives. Does anyone really want to go through that right now?

Now, of course single-sourcing isn't all bad. The common architectural platform of a full-line vendor such as Oracle 11i or SAP R/3 (and to a lesser extent Peoplesoft) means easy integration among a wide variety of applications. Integrating disparate packaged applications proves to be a challenge (or at least surprisingly costly) for many organizations. This is the sort of thing that seems like it should be easy until you really get into the nuts and bolts of it.

However, the price paid for this ease of integration is the possible need to compromise on functionality in certain application areas. In this case, my typical advice (and what I have seen work well) is to select the suite that best meets the broad requirements and then implement custom solutions in those areas where the suite vendor doesn't have a module or where the module does not meet a defined threshold of fit for the company. This is a larger topic and one I will explore more deeply in a future post.

Now, almost all the major IT research firms (AMR, Gartner, Giga, etc.) offer consulting services to help negotiate with vendors. If your company is already a client of one of these firms, it's worth reading their vendor-specific advice. If you're not a client, or you just want a negotiating primer, here is a quick rundown of generic strategies you should consider the next time you need to negotiate with your EA vendor.