Monday, December 13, 2010

IT spending outlook for 2011 and implications for enterprise software

Over at Computer Economics, our end-of-year update on IT spending and staffing trends is showing some incrementally positive good news.

IT spending outlook

First, based on our Q4 survey of US and Canadian IT end-user organizations, we are forecasting IT operational budgets to increase 2.0% at the median. This might not seem like a big jump, but if it holds (and we'll know when we conduct our annual survey in Q1 2011), it will be an improvement over the past two years, when budgets were flat at the median.

Figure 1 shows the trend for this metric since 2006.

Median Annual Change in IT Operational Budgets: 2006-2011

However, don't expect big increases in IT staff hiring, at least in early 2011. Although 27% of IT shops say they've been adding to headcount over the past three months, 14% were cutting headcount, for a net gain in only 13% of IT organizations, as shown in Figure 2.

On the other hand, on a positive note, those IT professionals who are employed are already seeing an increase in their work hours. Over the past three months, a net 47% of IT organizations have been allowing their staff members to work more hours, which could include overtime or cessation of furlough days.

On another positive note, nearly half of all IT organizations have been increasing their work on major projects over the past three months. That, of course, could be a large part of what is driving the increasing staff hours.

Finally, in welcome news for IT staff augmentation firms and contract service providers, a net 31% of IT organizations have been increasing their use of contractors and temps over the past three months. Again, this may be tied to the renewal of major project work.

Percent Increasing Minus Percent Decreasing Each Expense Over Past Three Months

Implications for enterprise software

For customers and vendors of enterprise software, what does it mean? First, the overall trend for IT operational spending may be moderate, but it is positive. The news on the capital spending side is likewise positive, with over half of our respondents expecting to spending more for IT capital investments. Our full report has details.

Second, the underlying dynamics in IT organizations are shifting. Whereas last year, and the year before, many of our respondents were canceling or deferring major projects, laying off IT staff, and cutting work hours, the picture over the past three months is exactly the opposite. New project work is increasing, new hiring is exceeding layoffs by a small amount, work hours are being extended, and IT contractors are getting the nod. All of these are positive signs.

Bottom line

I wouldn't expect 2011 to be a boom for IT spending--not only in comparison to the late 1990s, but even compared to the 2006-2007 time period, which was sort of a mini-boom compared to today. Still, after the last two to three years, any improvement is welcome.

We know from our previous years' surveys that many organizations cut back dramatically on major new initiatives, including enterprise software projects. As a result, many needed improvements were put off, and users are clamoring for relief. While economic recovery is still weak, organizations that make those investments now will be in much better shape when business conditions improve. In addition, most vendors of enterprise software are still in a deal-making mood: prices for software and for services are still a buyers-market.

Therefore, now is a good time to be making those investments.

The full report, Outlook for IT Spending and Staffing in 2011, is available on the Computer Economics website.

Related posts
Computer Economics: IT Spending and Staffing Benchmarks 2010/2011: IT Ratios and IT Cost/Budget Metrics by Industry Sector and Organization Size

Wednesday, December 08, 2010

First impressions: Salesforce.com far outgrows its name

I'm here in San Francisco covering Dreamforce 2010, the annual conference of Salesforce.com (SFDC).

Over the past several years, and especially from the keynotes given thus far, it is apparent that Salesforce.com needs a corporate name change. With roots as SaaS provider of salesforce automation system, the firm's services have expanded to a broad set of applications and applications development platform services.

More on that in a minute, but first, check out the energy and enthusiasm on display here at Dreamforce--from CEO Mark Benioff's on-stage cheer-leading to the vigor of the exposition floor. For example, one small developer told me last night that on the first day of the expo, he walked away with 75 good sales leads. I shot some quick video, which can give you a little window into the vibe, in spite of the dreary, rainy weather outside.



Okay, back to the issue: does SFDC need a name change? Just consider the following:
  1. SFDC's own functionality has been expanded to include customer service applications, bringing its footprint further into complete CRM territory.

  2. Back in 2006, the company opened up its development platform to third-parties, allowing them to build their own commercial applications and sell them via its AppExchange marketplace. The platform itself has since been renamed Force.com. Since then, independent software vendors have developed something like 1000 products on AppExchange, either as extensions to or in addition to Salesforce.com's own products.

  3. Earlier this year, SFDC announced its intent to acquire Jigsaw Data Corp, which provides current data on businesses and contact information, putting SFDC into the data services business.

  4. Earlier this year as well, SFDC introduced its Twitter-like capability, dubbed Chatter, which provides a secure, private social/collaboration environment from within SFDC's services and systems built on Force.com.

  5. Building out its platform-as-a-service (PaaS) capabilities, SFDC earlier this year launched a joint-venture with VMware to provide Java development capabilities as part of its Force.com platform, allowing third-party developers to use Java instead of SFDC's own proprietary development language. Furthermore, just yesterday, SFDC announced its agreement to acquire Heroku, a PaaS provider for the Ruby-on-Rails development platform. Ruby is an increasingly popular development platform for rapid application development, including many social and mobile applications.

  6. Another announcement during the conference this year: SFDC is introducing something called Database.com, which gives developers a cloud-based database capability, even if they are not building on SFDC's own Force.com platform.
This is just a partial list of the ways in which SFDC has moved far beyond salesforce automation to become something of a cloud-based development environment. So, as I said, at some point, I think a name-change would be in order.

For a deeper dive on the Heroku acquisition and the Database.com announcement, see the post from my colleague, Dennis Howlett, Salesforce's Database.com as a game changer now they've acquired Heroku?

Monday, November 29, 2010

Rimini Street to Oracle: don't expect us to roll over

As everyone knows by now, Oracle won a huge ($1.3 billion) judgment in its lawsuit against SAP/TomorrowNow (TN) for copyright infringement. SAP had acquired its now-shuttered TN unit to provide third-party support for some Oracle business applications in hopes of winning those customers over to SAP. SAP is considering an appeal of the jury verdict, the largest ever in a copyright case.

In the meantime, Oracle has a lawsuit pending against another third-party support provider, Rimini Street. At first glance, Rimini Street "looks like" TN in that both are/were providers of third-party support for Oracle applications. Furthermore, Oracle's lawsuit makes similar allegations--some of it appears to have been cut and pasted from its suit against SAP.

So it would be easy to assume that Oracle's hand against Rimini Street has been strengthened by its win against SAP.

Why Rimini Street isn't TomorrowNow

It would be easy, but it would be wrong. Here's why:
  • Admission of liability. Nearly from the start, SAP admitted that something was wrong down at its TN unit. By the time the case went to trial, SAP had basically thrown in the towel, admitting not only that TN had violated Oracle's copyrights but that SAP itself knew about the illegal behavior.

    In contrast, Rimini Street is making no such admissions. It has from the beginning steadfastly rejected all allegations that it is violating or has violated Oracle's IP rights. In several interviews I've conducted with the firm's executives over the past three years, it has claimed to have established clear policies and standards to prevent such misuse and has offered to have Oracle audit its practices. Oracle has refused such offers, choosing instead to file a lawsuit. So much for allowing Rimini Street to compete fairly.

  • Counter-punching. From the start, SAP was playing defense against Oracle's allegations. It never counter-sued or alleged misdeeds on the part of Oracle.

    In constrast, Rimini Street is fighting back. In a statement sent to me by Rimini Street last week, the firm writes, "While SAP chose not to challenge Oracle's allegations of liability, Rimini Street is aggressively challenging Oracle's allegations and prosecuting its own claims against Oracle."

    It goes on, "While SAP chose not to challenge Oracle's allegations, Rimini Street has countersued, accusing Oracle of defamation and using illegal and unfair practices to stifle competition for the lucrative support and maintenance business. Rimini Street intends to stop what it believes are Oracle's illegal actions and is seeking to hold Oracle responsible for its conduct."

    In other words, if Oracle thought Rimini Street would simply roll over, it thought wrong.
I suspect Oracle would like to have these two lawsuits run together in the mind of customers, prospects, and the general public. But, Rimini Street appears determined not to let that happen.

SAP's hands were tied against Oracle

The ironic part of the Oracle v. SAP/TN case is that SAP couldn't mount a vigorous defense without shooting itself (forget about the foot!) in the head. SAP, like Oracle, is addicted to its lucrative maintenance business. It is baffling why SAP chose to acquire TN in the first place, for some tactical advantage in converting a few Oracle customers to SAP? While undermining its whole business model for sustaining revenues from its installed base? What was SAP thinking?

So, when Oracle filed suit against SAP, what was SAP supposed to do--counter-sue Oracle for restraint of trade and unfair competition, and thereby conceding to any large hungry system integrator or competitor (think, IBM or HP) that its own installed base maintenance revenues were ripe for picking? Of course, SAP had to defend itself. But it couldn't defend itself too strongly, lest it wind up giving legal precedent to the third-party support industry. As it turns out, as the case proceeded through discovery, Rimini Street announced it would begin offering third-party support services for SAP's customers in addition to the services it was offering to Oracle customers. So, SAP was stuck between the proverbial rock and a hard place.

Rimini Street has no such baggage. It can and appears to be willing to mount a vigorous defense of its own rights to offer third-party support services, based on the contractual rights of customers to self-maintain their licensed software, while respecting the IP rights of OEM software vendors.

Why Rimini Street's case is important

As Rimini Street stresses in its statement this week, "both Oracle and SAP have acknowledged that third-party support is legal." I covered this point back in 2008 in a post entitled, Legal basis for third-party ERP support industry. In a little-noticed letter filed by SAP as part of pretrial discovery, TomorrowNow strongly asserted its legal right to offer third-party support for PeopleSoft customers, and PeopleSoft backed down from its claim that such support was illegal. Furthermore, to my knowledge, Oracle has not gone so far as to argue that TN had no right to offer support. Only that it did so by stealing Oracle's IP.

Rimini Street is strongly claiming not to be infringing on Oracle's IP. If it can back up that claim in court, then, in my opinion, a strong legal precedent will be established for the third-party support industry. Furthermore, if Rimini Street is successful in its counter-claim against Oracle, it will strongly restrict the attempts of vendors to prevent customers from seeking third-party support--which, ironically, SAP itself appears to have tried to do in 2009!

Strange, isn't it? SAP was defending itself as a provider of third-party support for Oracle customers, while at the same time apparently trying to prevent its own customers from using third-party support.

So, SAP was fighting Oracle with one hand tied behind its back. As Rimini Street's statement now points out, "Had SAP availed itself of the claims and defenses pleaded by Rimini Street in its case against Oracle, SAP would have placed its own policies and third party revenues in jeopardy. "

So, why is the Rimini Street case important? Because the rights of customers to not be locked into a single source for maintenance and support needs to be preserved. As I've written many times in the past, when you buy a Lexus, you have the right to take that Lexus to any third-party repair shop. Lexus cannot try to stop you or threaten to void your warranty if you do so. If they tried, the US Department of Justice (DoJ) and 50 state attorneys general probably would file suit. Why should the enterprise software industry be any different?

DoJ is reported to be looking into the Oracle/SAP matter. If so, and while it's learning about this industry, it should also take a look at the restraint of trade and antitrust implications of both SAP and Oracle's behavior in attempting to prevent a viable third-party support industry.

Statement from Rimini Street

Here is the full statement from Rimini Street, sent to me last week.
While SAP chose not to challenge Oracle's allegations of liability, Rimini Street is aggressively challenging Oracle's allegations and prosecuting its own claims against Oracle.

We believe the resolution of the Oracle vs. SAP case does not impact Rimini Street’s case against Oracle and does not change anything in the fast-growing third-party support market.

A few key facts:

Both Oracle and SAP have acknowledged that third-party support is legal. Oracle's claims relate to the specific processes and procedures used to provide support for their products. The processes and procedures used by Rimini Street are very different from those used by SAP.

The only substantive similarity between the offerings of SAP/TN and Rimini Street is that they both provide third party support at 50% off the software vendor's annual fees. As clearly articulated in the court documents and the thousands of pages of process documents provided to Oracle by Rimini Street, every other aspect of Rimini Street’s operations is significantly different that the operations of SAP/TN. Oracle knows this to be true.

We believe the magnitude of the damages award is a result of SAP's peculiar decision to concede liability and ultimately not challenge Oracle's claims. It bears noting that SAP, like Oracle, derives many billions of dollars from maintenance and update services to its customers with profit margins not unlike Oracle’s.

SAP’s practices and conduct in their attempts to chill growth of third party maintenance are similar to Oracle’s. Had SAP availed itself of the claims and defenses pleaded by Rimini Street in its case against Oracle, SAP would have placed its own policies and third party revenues in jeopardy. SAP abandoned these claims and defenses at its own peril, as the size of the damages award illustrates. While SAP chose not to challenge Oracle's allegations, Rimini Street intends to stop what it believes are Oracle's illegal anti-competitive actions and will hold Oracle responsible for its actions.

While SAP chose not to challenge Oracle's allegations, Rimini Street has countersued, accusing Oracle of defamation and using illegal and unfair practices to stifle competition for the lucrative support and maintenance business. Rimini Street intends to stop what it believes are Oracle's illegal actions and is seeking to hold Oracle responsible for its conduct.
Update, 1:40 p.m.: Dennis Howlett has a good post on the long-term implications for customers if vendors can get away with squashing the nascent third-party maintenance industry.

Related posts

SAP and third-party maintenance: good for me but not for thee
Legal basis for third-party ERP support industry
Oracle slams Rimini Street with lawsuit over third-party maintenance

Sunday, November 21, 2010

Oracle applications customers: wedded bliss or battered wives?

The results of my Oracle Apps customer survey have just been published by Computer Economics, and I've been fielding calls from media representatives on the findings. The most common question: if customers are so unhappy with the quality and cost of Oracle apps support, why do they keep spending money with Oracle? Why do they stay in this relationship?

It's not an easy question to answer. But first, let's summarize several main findings of our study.

Three negatives for Oracle

The Computer Economics Media Alert and Research Byte provide a more complete description of the report. But let me point out three major negatives for Oracle in the findings:
  • Apps customers unhappy with Oracle support. There is no way to avoid the conclusion that there is tremendous customer dissatisfaction with the quality and cost of Oracle support. Specifically, 42% are dissatisfied with the quality, while 58% are dissatisfied with the cost. This is across the board for all products, including E-Business Suite users, but is especially pronounced among PeopleSoft customers. The respondent comments in this section are devastating.

  • Fusion apps not top-of-mind for Oracle customers. Oracle’s next-generation applications, dubbed Fusion Applications, are not on the radar for most customers, with only 10% planning to migrate to Fusion. There is substantial difference in migration plans, depending on the Oracle product currently installed.

  • Oracle apps customers not flocking to Sun hardware. Only 25% of Oracle application customers are currently users of Sun hardware, but among these customers, expectations for increasing support costs are high. Very few Oracle application customers have plans for Oracle’s new Exadata storage systems.
As I said, not good news for Oracle.

But most customers sticking with Oracle

At the same time, despite their dissatisfaction with Oracle support, their lack of interest in Fusion, and their complaints about Sun costs, only 25% of our respondents expect Oracle to have a smaller share of their IT budgets over the next three years. Another 37% indicated such factors as organic growth, purchase of additional Oracle applications, and standardization on Oracle technology would result in Oracle having an even larger share of their IT budgets. The remaining respondents judged Oracle’s share of their IT spending would be about the same in three years.

In other words, whatever their complaints, the majority of Oracle apps customers do not plan on changing course.

So why do customers stay?

This is the big question. If things are as bad as our respondents say they are, why aren't they moving en masse away from Oracle? We didn't specifically ask this question in our survey, but based on many of the comments, I can postulate three types of Oracle apps customers:
  1. Organizations that have standardized on Oracle products. These are like married couples in a committed loving relationship--they may have their squabbles from time to time, but their commitment is secure. These include died-in-the-wool "red stack" customers, those that have committed to do most new development on Oracle database and tools. Most of these customers are running E-Business Suite and have no intention of leaving. These are the ones that are most likely to be considering a migration to Fusion Apps, when they are generally available. These also include users of other Oracle applications, such as JD Edwards, PeopleSoft, and Siebel, who are generally satisfied and see no overriding reason to abandon them.

  2. Organizations that find breaking up hard to do. These are like wives that would like to divorce but decide to stick it out for the kids' sake. They are miserable, but they are going to hang in there, at least for the time being, as making a change is simply too difficult. Many customers have made substantial investments in their current Oracle systems, either in predecessor applications (e.g. PeopleSoft, JD Edwards, Siebel) that Oracle acquired, or in Oracle's own E-Business Suite. In many cases, it's not easy to replace these systems. The apps are deeply embedded as part of how business is done, or if enhancements have been built on top of these apps.

  3. Organizations that don't see an alternative. These are like wives that would like to be married to someone else, but don't see any attractive choices. These organizations are likely to be running Oracle's E-Business Suite. If they are of sufficient size and complexity, they may perceive that there is really only one other choice: SAP, another large Tier I vendor. From what they've heard--rightly or wrongly--that might not be a happy marriage either. And, they don't realize that in many cases, there are other choices, whether as a complete replacement for Oracle or as a partially replacement as part of a so-called two-tier ERP strategy.
Nevertheless, comments from respondents make it clear: a substantial minority of customers are planning to completely or partially replace Oracle in their applications portfolio. They are planning either for a total replacement of their existing apps, or to make new investments with technology from other vendors, around the edges, especially with SaaS solutions.

Make no mistake: Oracle has some great software and some great people. My own dealings with Oracle find that there are many outstanding professionals within the ranks of its applications business and its partners--smart folks that really care about serving customers.

For example, I know quite a bit about FDA requirements for electronic records and electronic signatures, and I find Oracle's approach with its E-Business Suite to be about the best I've seen from any vendor. Furthermore, by many accounts, its next-generation Fusion Apps raise the bar for ease of use, embedded analytics, and enterprise collaboration. I could list many other examples. As in any relationship--for many, being an Oracle customer has its good days and its bad days.

Chances squandered

Ultimately, though, it is hard to avoid the conclusion that Oracle is missing a major opportunity. By its own admission, Oracle makes at least 85% margin on its maintenance and support programs. In fact, it's nearly ALL profit. If Oracle would just take a 2% or 5% hit on that margin and invest it into improving the quality and reducing the cost of its support programs, it could probably reduce the level of complaints and engender tremendous good will among its installed base. Customer retention would not only increase, but it would open the door to additional purchases from these customers. And it would be a positive response to the threat of third-party maintenance.

Postscript: So, is Oracle planning any improvements in its service and support programs? It's possible. Oracle recently brought Charles Rozwat, a respected Oracle executive, back from an extended leave of absence, to head up its worldwide support organization, and he reports directly to co-President Mark Hurd. But I have no idea what changes may be planned. Oracle refused my repeated requests to make Rozwat--or anyone else--available to discuss these matters.

The full report, Go-Forward Strategies for Oracle Application Customers, is available for sale on the Computer Economics website.

Related posts

Oracle confirms: maintenance fees are virtually all profit
Oracle profits strong, thanks to your maintenance payments

Thursday, November 11, 2010

Update on Microsoft Dynamics products and plans

I'm participating today and tomorrow at Microsoft's Dynamics Fall Analyst Event--a series of briefings at Microsoft's facilities here in greater Seattle area. I won't attempt to do a complete rehash of what was presented, but rather a few key impressions.
  • CRM is where the action is. Although Microsoft Dynamics ERP products (AX, NAV, GP, SL) were presented, the discussion always seemed to lead off with MS Dynamics CRM. I'm left with the impression that many of the new deals are for CRM, although ERP deals probably carry a higher average price.

    Why would this be? It is probably no coincidence that the CRM product is the most recently developed, with the most up-to-date architecture, and the most innovative features, such as new mobility options being introduced in the 2011 version. Such characteristics garner more mind-share from partners and prospects. Some good new features are being introduced in the ERP products as well (e.g. we saw some interesting new features in AX for retail) but one senses that these enhancements do not generate the sort of excitement as what Dynamics is doing with CRM.

    It also helps that Microsoft is aggressively discounting the CRM product on a promotional basis, as discussed in a moment.

  • Microsoft Dynamics serious about going "all in" on the cloud. Traditional on-premise license sales may still account for the bulk of Dynamics sales, but the most interesting developments are in its cloud offerings. These offerings are still in a state of flux--hosted deployments are currently provided by Microsoft partners. But uptake has been good, as evidenced by the four customers Microsoft put forward to tell their stories and take questions from the analysts gathered here. Microsoft's Azure services--primarily platform-as-a-service (PaaS) and software-as-a-service (SaaS) are still being built out. But we had a fairly deep dive into what Azure's data centers look like, and what the build-out of services will include. It's an impressive initiative and an enormous investment by Microsoft.

  • Microsoft not afraid to compete on price. As just mentioned, Microsoft is offering promotional pricing on its CRM product with online deployment, starting at $34 per user per month. This is well below the entry point for Salesforce.com, generally perceived as the leader in SaaS CRM.

    I've often wondered why more vendors don't take this approach, to compete explicitly on price, especially under current economic conditions. As my late business partner, an expert on strategy, told me: there are only two basic business strategies--low-cost leader and differentiation (everything else). But most software providers choose to compete based on their claim to be able to offer something "unique"--something that demands a premium price. The reality, however, is that as the ERP and CRM markets mature, premium pricing for advanced functionality may not be the best path to success. Frankly, many prospects these days just want a good, basic product they can grow with, offered at a reasonable or low price. Never underestimate the power of lowest price.

    Now, Microsoft will never concede the uniqueness or superiority of their product offering. Nevertheless, its willingness to compete on price shows that they understand what is really driving deals these days. I've heard that Oracle is also aggressively competing on price for its Oracle CRM On-Demand offering, further confirming where the basis for competition is moving--at least for CRM.

    And, it's no coincidence that these two low-priced products are both on-demand offerings. To sustain a low-price strategy you have to have a low-cost delivery model, which only an on-demand offering can provide.

  • The partner channel continues to be a key to success. Microsoft Dynamics sells nearly all (if not all) of its deals through sales and implementation partners. For all the changes in the products, there is no change in this sales model. Nevertheless, I was interested to find that the Dynamics partner classifications of gold, silver, etc. has become muddled, with the majority of partners listed in the "gold" category. This is upside-down and absolutely of no use to prospects or customers. As in the mythical town of Lake Wobegon, all the children are above average. Or, more directly, if everyone is gold, then no one is gold.

    Microsoft realizes the problem with the classification of its partners and is taking steps to address it. However, I had one Twitter conversation with a Microsoft business partner who feels the certification exams are meaningless--a complaint we've heard concerning other vendors as well.

    To be fair, some impartial observers consider Microsoft's partner program to be better than most. Nevertheless, as critical as its partners are to Microsoft, it is essential that it put real teeth into its certification and classification processes.
Dynamics is in an interesting, and in some ways, difficult position. It is a business unit of one of the world's largest technology companies, with access to deep pockets and technology that for many organizations is "industry standard." At the same time, many of Dynamics' competitors, such as Epicor, Infor (Syteline), or Syspro, are building on the same technology--which means that the "big" Microsoft enjoys the same or similar pull-through of Microsoft technology, whether the deal is won by Dynamics or one of these competitors. So, in some ways, Dynamics is an independent software vendor (ISV) that happens to be located within Microsoft's four walls.

Current economic conditions are not easy times for Dynamics competitors, however. The new developments across all of Dynamics products show the benefits of being inside those four walls.

I'll update this post, as appropriate, based on additional insights gained tonite and tomorrow.

Related posts
Key success factor for SaaS suites: functional parity
Shifting strategy: Infor casts its lot with Microsoft
Enterprise software: who wants to be the low-cost leader?
Recession prompts great financing deals from IT vendors

Monday, November 08, 2010

Outlook for IT spending in 2011: call for survey respondents

Is the IT spending recession over, or are there still tough times ahead? Will companies hire IT staff in 2011, or are we facing more layoffs?

To answer these questions, we're looking for IT managers in the US and Canada to participate in a 10-minute survey about their IT budget and staffing outlook.

What's in it for you? A free copy of the final report, which will otherwise only be available to Computer Economics subscribers or to those who purchase the report

Take the 10-minute survey now

Friday, October 22, 2010

Best practices not always best

This article in Computerworld by my friend Tom Wailgum, The Trouble with Supply-Chain Best Practices, got me thinking again about this whole subject. What are best practices?

The problem, as I see it, is two-fold. First, the term best practices has at least two major and totally different definitions, and second, in many areas of business, there is not generally agreement on what are the best practices.

Two definitions
As just noted, practitioners often use the term best practices in two completely different ways, and you have to be sure you understand the context. The first is in the sense of "the best way to do something." The current definition in Wikipedia is typical:
A best practice is a technique, method, process, activity, incentive, or reward which conventional wisdom regards as more effective at delivering a particular outcome than any other technique, method, process, etc. when applied to a particular condition or circumstance.
For example, conventional wisdom might define a best practice in recruiting new employees as establishing a formal employee-referral program, as this channel often results in the highest quality candidates, lowest cost of recruiting, and best retention rates.

The second definition, which I run into occasionally, has to do with best practices in the sense of metrics. Here, folks use the term not to describe the best way to do something, but the best performance that is attained among peers against some metric. For example, again using the recruiting example, the median retention rate after six months for newly-hired nurses in US hospitals might be (I'm making this up) 75%. But the "best practice" (i.e. the retention rate achieved by the best performing hospitals) might be 92%.

So, when someone asks, what are best practices for recruiting, you have to ask, do you mean what are the best policies, procedures, and practices in recruiting, or do you mean, what is the best performance against some metrics by the organizations that are the most successful in recruiting.

Best practices not always universally applicable
For now, let's go with the first definition. Are there really ways of doing business that are generally accepted as best? In some cases, yes, but in many cases no.

Let me illustrate with an experience I had several years ago. My consulting firm, Strativa, was bidding on a business process improvement project for a mid-size medical device manufacturing firm. Our first meeting with the selection committee went quite well. We outlined our approach to business process re-engineering and business improvement and described some case studies for similar projects.

Based on the committee's recommendation, we then scheduled a one-on-one meeting with the President. That didn't go so well, and it came down to this issue of best practices. After describing our proposed work plan for the project, he asked, "Where do you compare our practices against industry best-practices?" I indicated where such an evaluation could take place. He then asked, what are your sources for best practices? I indicated that there are a number of professional societies that are good sources for best practices, such as APICS, which is the generally accepted source for best practices in materials management. In addition, we would use our own knowledge and experience from other clients as to where this organization could be viewed as having a need for improvement.

We went back and forth on this subject for some time, and I had the feeling that he wasn't satisfied with my answer. In a debriefing session afterward, the VP of Information Systems, who was sitting in on the meeting, confirmed that the President didn't feel our approach to best practices was strong enough.

The VP was sympathetic and still hoping we could win the deal. So I shared with him why I felt that the President's emphasis on best practices might be misplaced.

I said, "Isn't it true that your company uses significant part numbers?"

I had learned earlier that this company had the practice of letting each each digit or character of the product item number stand for something meaningful. For example the first two characters might indicate the product family, the second two might indicate the sub-family, the third digit might indicate the size of the product, the fourth digit might indicate the material, and so forth.

The VP said, "Yes, that's right. We've always done it that way."

"That's not a best practice," I replied.

"Really, says who?" asked the VP.

"APICS," I said. "They've been preaching against the use of significant part numbers since the mid-197o's. The reason is that it creates all kinds of problems. Invariably, as companies grow and their product portfolio changes, they outgrow their numbering schemes. Either the part number becomes extraordinarily long, or people just give it up. If you want to describe the product, use other fields on the item master. You don't need to make the part number work that hard. "

I continued, "Now, here's my point. In spite of what I just said, if we do this project, we're probably NOT going to try to change your part-numbering scheme. You've got it, and it's probably too difficult to change at this time, even though it's not a best-practice. A good consultant will look at what you are doing and will weigh the pro's and con's of changing it. That's how you've got to apply so-called best practices."

You can't just go to some database of best practices and say, here's what you should be doing. You need to apply judgment, based on experience.

Of course, this approach does not scale for large consulting firms, who like to staff business improvement projects with a lot of junior associates. It's much easier to give them a database of best practices and tell them, find out if the client is doing these. If not, recommend they do them. It's much harder to go in and evaluate the situation according to the client's specific situation. But that's the way to create meaningful change.

Best performance not universally attainable
There are problems also with the second definition of best practices: the best performance attained among peers against some metric. The problem is that which is common to all benchmarking exercises: defining the peer group and identifying the reasons for superior performance.

For example, my IT research firm, Computer Economics, publishes metrics on IT spending and IT staffing ratios. In addition, we provide a IT spending benchmarking service where we calculate the client's metrics, compare them to our published ratios, and provide our analysis of the gaps in performance.

Invariably, there is almost always a significant amount of judgment that we need to apply in our analysis. For example, just recently, a benchmark client (a public utility) showed that the number of users per IT help desk staff member was near the 25th percentile in comparison with other organizations of this size. The number of PCs supported by each help desk staff member showed similar sub-standard performance.

However, when interviewing the client, we discovered that the agency had an online permitting system that builders and developers used to submit permit applications. The IT help desk, which normally would only serve internal users, was also serving the general public as users of this application. Knowing our data, we were sure that this was not the case with the majority of our survey respondents.

So this client was well under what we would consider a "best performance" (something at or above the 75th percentile for this metric). But when we factored in the percentage of help desk incidents fielded from the general public, we found that the agency was, in fact, well above the median.

The concept of best practices can be useful, if properly understood and applied with judgment. Certainly, in terms of how to do business, organizations can learn from one another. And in terms of measurements, it is quite useful to have a sense for what levels of performance are achieved by peer organizations, or even by organizations outside of one's own industry.

But in both cases, there's no magic formula.

Related posts
Computer Economics: IT Management Best Practices
ERP implementation: putting processes and people first
Solving the four problems with ERP
Four problems with ERP
Business changes needed to ensure enterprise system success
Large system implementations require organizational discipline

Wednesday, October 13, 2010

Key success factor for SaaS suites: functional parity

As we all know, software-as-a-service (SaaS) has been one of the bright spots in the enterprise systems marketplace these days. The advantages are becoming more widely recognized: lower total cost, faster time-to-benefit, little to no capital expenditure, and less pain in system upgrades.

In fact, in some segments of the enterprise market, SaaS is already where most of the action is. For example, in CRM system selection it is difficult not to consider one of the leading SaaS solutions, such as Salesforce.com, Oracle's CRM On-Demand, RightNow.com and others. For HR management systems (HRMS), likewise, we see SaaS providers such as Workday, Taleo, and Success Factors gaining significant market share for net-new deals.

Reaching for full maturity
So, why haven't SaaS solutions completely taken over the enterprise software market, especially for full-suite ERP? Because there is one area where SaaS providers still lag behind: functional parity. For full-suite ERP, there are still precious few SaaS providers. And those that do attempt "full suite replacement" still have major gaps in their functional footprint.

However, the landscape is changing quickly. For example, until recently, we have been reluctant to short-list SaaS providers as full-suite options for manufacturing firms. Those that had ambitions to be full-suite providers simply lacked basic functionality needed for manufacturing, especially vertical-specific requirements. But we are now finding that SaaS providers at least deserve a look. These include the following:
  • Plex Systems was the first SaaS provider out of the gate with a full-suite ERP offering for manufacturing firms. More on Plex in a minute.
  • NetSuite is a full-suite provider. But until recently, it has only been a viable option for service businesses, because it lacked many fundamental features for manufacturers, such as standard costing, shop scheduling, capacity planning, and MRP. However, since I last visited this issue, a NetSuite partner, Rootstock, has been building extended manufacturing functionality on top of NetSuite's platform. I've spoken at length to the developers at Rootstock, whom I know from their previous work at Relevant (since acquired by Consona). They are making very fast progress, thanks to the ability to rapidly develop on NetSuite's platform. Rootstock's extensions to NetSuite are claimed to operate seamlessly with NetSuite's core financials and CRM.
  • SAP is moving in the same direction with its Business ByDesign (ByD) offering. Although SAP has been slow to move the product into general release, you can't fault the objective, which is to become a full-suite offering. I especially like the use-case for large SAP installed-base customers, which have a hard time justifying use of SAP ERP in smaller divisions. Such organizations frequently adopt a "two-tier ERP" strategy, where SAP runs at the corporate office and in larger business units, while a smaller footprint ERP, such as Epicor, QAD, or Microsoft Dynamics AX, runs in the smaller divisions. The use of ByD in this scenario, should be an attractive alternative.

    Update: Since this post was first published, I have learned that in FP 2.0 (released Sep. 2009), ByD now has what appears to be very complete functionality for manufacturing operations, including integrated quality control, as well as supply chain planning.
  • Workday is a SaaS provider, currently serving the HRMS and financials functions, but they have ambitions to be a full ERP replacement, at least for services-based organizations. With Dave Duffield as one of the founders they appear to be following the path that Dave took at PeopleSoft: start with HR, add financials and purchasing, then fill out to become a full-suite offering. Personally, I think Workday is underestimating how long it will take them to get there, but I have little doubt they will reach the goal. And they are going after the large company segment, which is unusual for most SaaS providers.
  • Update: Infor's Syteline is now being newly launched by Infor in a SaaS deployment model. Based on a lengthy briefing I received from Infor, it appears that Syteline qualifies as a full-suite SaaS offering. The new deployment option uses a single instance of Syteline's application server, with separate databases for each customer. While some might argue that it doesn't fully meet the pure definition of multi-tenancy, it more than makes up for it in functional parity with on-premise ERP suites, which is the point of this post. I'm hoping to write more on this new offering soon, as it appears to be another good option for those looking to go with SaaS for full-suite ERP.
  • Update: Epicor Express is another full-suite SaaS offering. Running as a pure multi-tenant deployment of Epicor 9, the offering today is supporting about 15 live customers, with another 15 in implementation. Epicor is currently targeting this offering at small job shops, with customer friendly subscription terms and very low fixed-fee implementation services ($7,500, including a defined set of data migrations). But I can see this product being up-sold to larger customers with more complex requirements as well.
The number of SaaS providers with full-suite offerings still pales in comparison to traditional on-premise ERP. Note, however, that I don't consider hosted versions of on-premise software in the SaaS category, such as hosted versions of Lawson's ERP products, or Oracle's E-Business Suite. Single-tenant hosted products simply do not offer the full benefits of SaaS outlined earlier.

Full-suite SaaS gaining traction
Although the number of true multi-tenant full-suite SaaS offerings today is limited, they are rapidly becoming a viable alternative to on-premise products or single-tenant hosted offerings.

The latest example is a big win for Plex Systems, at Invensys Controls, one of three business units of UK-based Invensys plc. This business unit provides components, systems, and services used in appliance, heating, air conditioning, refrigeration, and residential thermostat products. It has locations in 15 countries which include 22 manufacturing sites, two distribution centers, and seven engineering centers--and Plex Online will be implemented in all of them.

It sounded like a pretty big deal for a SaaS provider, so I followed up with Plex to find out more. Here are the details:
  • Plex will be replacing 11 different traditional on-premise ERP systems in the various locations at Invensys Controls, which has revenue of approximately $900 million.
  • The win by Plex comes not only against traditional on-premise ERP vendors--SAP, Infor, and Oracle, but also against NetSuite. So, Invensys actually was willing to consider two full-suite SaaS options: Plex and NetSuite.
  • The decision in favor of Plex came down to two factors: (1) functionality--a single, comprehensive solution that covered all of their functional areas, and (2) the SaaS deployment model with associated benefits of cost-savings, speed of implementation, and scalability.
Interestingly, according to my correspondence with Plex, Infor was de-selected as it did not have a true SaaS offering, and both SAP and Oracle were eliminated for non-response to the RFP. One can only speculate that Invensys may have become focused on going with a true SaaS offering, and neither SAP nor Oracle couldn't come up with one. If so, we may be coming to the point where even organizations as large as Invensys Controls see true multi-tenant SaaS as their preferred deployment option.

If that's the case, why didn't NetSuite win the deal? According to Plex, NetSuite had gaps in meeting key functional requirements. It would appear then that the deal came down to Plex versus NetSuite--two true SaaS offerings. If so, this underlines my point that the only thing holding back full-suite SaaS offerings from taking further market share is functional parity.

Back in the 1990s and early part of this decade, ERP selection often came down to long checklists of functionality, becoming more and more detailed as full-suite offerings matured. Eventually, such long checklists became less useful, especially for large deals, as the Tier I providers (SAP and Oracle) could pretty much check every box. (As a result, in our own ERP selection consulting at Strativa, we prefer these days to focus more on key differentiators and industry-specific requirements.)

Furthermore, in software selection deals we've worked lately, we are seeing much more interest on behalf of buyers in true SaaS deployment than we saw even one or two years ago. As buyers hear about the success of other companies with solutions such as Salesforce.com, the benefits of SaaS are much more well-understood, and the traditional objections (security, reliability, "where is my data," etc.) become less of an issue.

So, as the focus shifts to SaaS for full-suite ERP, we may be seeing functional requirements again becoming the key selection criteria. If the deployment option of true multi-tenant SaaS is superior to traditional on-premise deployment or single-tenant hosted offerings, then the only thing standing in the way of SaaS is functional parity. But, as development platforms such as NetSuite's make addition of new functionality much easier, the functional gaps are being closed much more rapidly than many realize.

Traditional on-premise vendors beware: the full-suite SaaS providers are catching up quickly.


Update, Oct. 15. Updated the post with newly-learned information about SAP's Business ByDesign and rearranged the sequence of solutions. Updated also to clarify Workday's intent to support services-based businesses with a full-suite offering.

Update, Oct. 21. Added information about Infor's Syteline offering in a SaaS deployment model.

Update, Nov. 17. Added information about Epicor Express, which is deployed as full multi-tenant SaaS offering.

Related posts
Ensuring win-win in SaaS aggregation of customer data
Plex Online: pure SaaS for manufacturing
Workday pushing high-end SaaS for the enterprise
Lawson's cloud services: good start, but no SaaS
NetSuite a viable alternative for SAP customers?
A game-changing play in enterprise software
The inexorable dominance of cloud computing
Computer Economics: The Business Case for Software as a Service

Friday, October 08, 2010

Ensuring win-win in SaaS aggregation of customer data

Proponents of software-as-a-service (SaaS) have been looking for reasons that shared architecture is superior to on-premise solutions. The latest argument is that a multi-tenant system (one where all customers share a common system instance) allows the SaaS provider to aggregate data from many customers and report general economic trends and or other statistics that add value beyond that of the service itself. Such aggregation of customer data is difficult if not impossible for on-premise vendors, which typically do not have ready access to each customer's system. It is also difficult for single-tenant SaaS providers, who would need to build an integration layer to access many separate instances of customer systems.

I first noticed this thought in the recently published book, The New Polymath, by my friend and associate Vinnie Mirchandani.

Vinnie writes in a section about a leading SaaS provider, NetSuite:
"We have some of the best leading indicators on the economy. We can aggregate order value, cash flow, and several other metrics instantly in our base of over 6,000 customers and watch trends," gushes Zach Nelson, CEO of NetSuite.... Soon, those customers will be able to benchmark themselves against aggregated data of their peers. That would obviate the need for mailed-in surveys. That capability has been the domain of benchmarking firms like Hackett, not of the software industry, so that is another innovation NetSuite is working to deliver. Nelson explains: "Take those benchmarks and some of the creative BPO [business process outsourcing] partnerships we are exploring, ...and the industry could see SLAs [service-level agreements] that don’t just monitor technical metrics like systems availability but business process metrics that have been elusive to codify."
Dennis Howlett then picked up the thought in his post on ZDNet last month, where he wrote about the value of SaaS being beyond lower total cost-of-ownership. He wrote (emphasis mine):
I have long argued that multi-tenant architectures offer transformational benefits from the ability to aggregate data. That is not possible in a single tenancy situation. Workday isn’t ready to contemplate that notion just yet any more than any other vendor. Except perhaps NetSuite and a small handful of the very small business apps vendors that are building in these capabilities. I recall a conversation where it was said that NetSuite saw the recession coming before it became public knowledge by virtue of the transaction trends it saw in its customer portfolio. Try doing that from your single tenant application.

How about selling anonymized data to banks, other financial institutions, telcos, insurance companies, healthcare organizations…the list goes on. Why would they buy these data? Application tech vendors tend to specialize in certain business sectors. Multi-tenant SaaS vendors are collecting prime data that has genuine value third parties cannot get.

A bank may see ins and outs of bank accounts but those numbers are meaningless without context. A first step I am seeing is where some vendors are suggesting giving client bank managers shared access to aggregated financial data in real-time. Why? Because the bank can marry what they are told with what they see and so make much better informed lending decisions. Add in the ability to offer comparative trend data and you’ve got something extremely powerful....

Long term, I believe the ability to powerfully slice, dice, form and reform data out of multi-tenant systems will become the place where customers see huge value that is way beyond TCO. If I can benchmark performance in real-time or spot trends and compare, again in real-time, then my ability to take corrective or revenue enhancing action is vastly improved. Do I maintain a competitive edge? Of course because it isn’t the availability of data that matters but the ability to execute plans against what I am seeing.

Does this require careful handling to ensure that confidentiality is not breached? You betcha. But just as in the consumer world we have forgone privacy in the name of getting help from Google, there is no reason to believe the same won't hold true in the enterprise. The upside potential for benefit is simply too big to ignore.

This seemed like a bit of an overstretch to me, so I commented on Dennis's post:
I am fully in agreement that multi-tenancy is in the client's best interest, for the simple reason that there is no way a vendor can deliver the service as cost effectively under a single tenant model.

However...I am having a bit of a problem with this concept of "selling anonymized data to banks, other financial institutions, telcos, insurance companies, healthcare organizations." Whose data is it? It's the customer's. The vendor has no more right to take that data in any form, shape, or level of aggregation than a telco vendor has the right to intercept my phone call. The MT vendor is a carrier of the data, that's all.

I'm pretty sure vendors who want to do this have something in their contracts to allow it. But if I'm a customer of such a vendor, I'd either say no, or demand compensation for it.
Now stirred up about this matter, I tweeted:
Having a problem with @dahowlett's view of MT vendors aggregating and selling customer data.

Seriously, ppl go ballistic about Google showing ads based on content of Gmail. Now it's OK for NetSuite to poke around cust's AR files?"
An off-the-cuff, poorly-chosen example. NetSuite--monitoring Twitter--promptly called me about it, and assured me they are doing no such thing. So, I corrected the record on Twitter: NetSuite is not poking around customers' accounts receivable files.

Actual practices of SaaS providers
That out of the way, the folks at NetSuite then offered to brief me on their actual practices as well as how their customer contracts are written. NetSuite was even kind enough to let me review its standard contract, which I won't directly quote here out of respect for confidentiality. But I did tear into it pretty aggressively. In addition, I interviewed two other SaaS providers (Workday, plus one other) to gain a broader understanding of this issue. As you'll see, the actual practice lags far behind the vision of what's possible.

Obligatory disclaimer: I am not a lawyer, I do not practice law, and nothing in this post should be construed as legal advice.

Here's what I what I've been told, based on interviews with these SaaS providers:
  • Currently, NetSuite is only looking a customer activity in terms of usage: how many users are being added or removed and how often do they log-in, for example. NetSuite has nothing in place to look at actual customer transaction data (e.g. customer A/R files).

  • NetSuite has considered the opportunity to let customers benchmark their own key metrics (e.g. average days sales outstanding in A/R) with those of other customers in aggregate, but it has not yet moved forward to do so. If it were to do so, it would allow customers to opt-in or opt-out of this service.

  • NetSuite's standard contract for customers includes prohibitions against unauthorized disclosure of customer data and against unauthorized "use" of customer data by NetSuite. Anything that NetSuite would do in the future in the way of new services to aggregate customer data would be done in a way that is consistent with its customer contracts.

  • Workday takes a similar approach. It considers customer data at three levels: (1) performance monitoring--e.g. response time, service levels, (2) usage data--e.g. what features customers use most often in the system, and (3) best practices--e..g. what is the average time for a customer to bring a new employee on-board.

  • The only customer data that Workday accesses today is performance data, as described above. Workday is considering services that would involve aggregation of customer usage data and best practices, and under Workday's standard customer contract, this would require customers to opt-in.

  • The third SaaS provider, who will remain unnamed, says the investment community has encouraged them strongly to develop customer data aggregation services, as they see this as increasing shareholder value. This provider has no current plans to develop such services, however.

  • This third SaaS provider indicated that its standard contract explicitly gives them the right to aggregate customer data and report aggregate statistics. However, this clause often gets stricken by customers in contract negotiations.
Although my research only involved three SaaS providers, it does show that the actual practice today is lagging far behind what is possible in terms of customer data aggregation.

Data aggregation not a new idea
This does not mean that there is no precedent for customer data aggregation, however. NetSuite pointed out to me that ADP, for example, has been reporting employment trends for many years, based on actual customer data in its payroll and HR systems. The description of ADP's National Employment Report shows the value of being able to aggregate a large sample of customer's day-to-day operational data.

In addition, Coremetrics, an online marketing SaaS provider, recently acquired by IBM, aggregates its retailer customers' data to provide its Coremetrics Benchmark, which it describes as follows:
[A] peer-level benchmarking solution that measures online marketing results, including commerce data, against those of the competition. More than 500 leading U.S. retailers, contribute their analytics data to Benchmark. All data is aggregated and anonymized.
Coremetrics also uses this data to provide its widely-quoted next-day flash results of sales from so-called Black Friday. ("Black Friday" is the major shopping day that occurs each year in the U.S. on the day after the Thanksgiving holiday, when many retailers finally can report sales "in the black" for their year-to-date results.)

So, in fact, the aggregation of customer data by SaaS providers is not a new idea. It's just somewhat new to most new enterprise SaaS providers.

My take
I agree there can be great value in reporting statistics based on aggregated customer data. But that value should be shared between providers and customers.

In reviewing SaaS contracts, therefore, customers should consider the following:
  • Non-disclosure. At a minimum, be sure your SaaS contract ensures confidentiality of your data. Most if not all providers appear already to have addressed this point. But verify.

  • Fair consideration. If your SaaS provider wants the right to aggregate your data with that of other customers, be sure that there is some quid pro quo for your participation. If the provider is somehow preparing benchmarks based on your data, you should be able to received the benchmarks either at a discount or at no charge in exchange for your participation. If the provider is proposing to sell aggregated statistics to third-parties, and this wasn't contemplated at the time you originally signed up, you should receive a discount against your subscription fees in exchange for your participation.

  • Opt-out provisions. If you are not comfortable participating in data aggregation, you should have the right to opt out. You should also have the right to opt out of future aggregation after having previously opted-in. This is an important check against providers getting too creative in how they use aggregated data, for example, segmenting the data so finely that it becomes uncomfortably close to identifying specific customers.
There's a lot of innovation going on with SaaS providers these days, as they search for ways to add value. That's great. But SaaS providers are still vendors, and a SaaS agreement can be just as lopsided as on-premise software agreement. As I've said before, "you don't get a pass just because you're SaaS."

Although I count myself as a SaaS proponent, first and foremost I am a customer advocate. Know what you're getting into with a SaaS provider and be sure you agree.


Considering a SaaS solution? Let me know if you would like assistance in evaluating SaaS providers or reviewing proposed agreements. My email is in the right-hand column.


Related posts
Workday pushing high-end SaaS for the enterprise
SaaS contingency plans need more than software escrow
SaaS: plan to get out before you get in

Monday, September 27, 2010

Assessing and rationalizing the IT applications portfolio

There's nothing like putting out a big hairy number to get media attention, and Gartner has just done that with its new statistic it calls "global IT debt." Gartner defines it as "the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state."

And how big a number is it? According to Gartner's press release, it's approximately $500 billion today "with the potential to rise to $1 trillion by 2015."

A bogus statistic
I first heard about the press release through my associate, Vinnie Mirchandani, who points out that this latest statistic was in keeping with a long-standing Gartner tradition:
Gartner made a name starting in the mid-90s forecasting the estimated cumulative cost of Y2K remediation. I was there – and the big numbers it bandied about helped focus enterprises on the core problem. But it also led to hype, panic buying (and exaggerated market declines on the other side of the peak) and many, many poor IT investments. Since then Gartner has picked on many events – such as the introduction of the Euro between 1999 and 2002 - and piled up potential costs to come up with a single, usually scary, related aggregated IT project cost forecast.
Vinnie goes on to point out five reasons why it may be in an organization's best interest NOT to upgrade applications to the current release. Read Vinnie's whole post.

At this point, the easiest thing for me to do would be to pile on. In fact, my first reaction upon hearing about IT debt was to call the concept "bone-headed."

For example, if IT organizations are incurring a debt, to whom do they owe it? To software vendors? If so, it would betray a very vendor-centric view of IT. Gartner's view also assumes that having a software package up to date on the current release is a desired state--a concept that Vinnie pretty much demolishes.

Rationalizing the application portfolio
But, to be fair, it appears that Gartner is using this statistic to highlight the state of disarray in the applications portfolios of many organizations and to "make the problem bigger."

With that in mind, let's stipulate that application proliferation and unsupported versions is a big problem in many organizations. What, then, should a CIO do about it?

I would recommend a formal process to evaluate the entire applications portfolio and assign them to categories, such as the following:
  1. Retirement Candidates: those applications that can simply be retired, as they may have little current usage or the business value is minimal.

  2. Consolidation Candidates: those that duplicate functionality in other applications. For example, combining two SAP instances, or an SAP system and an Oracle system. Pick one and standardize on it.

  3. Freeze Candidates: those older applications that have little business value from upgrading to the current release. Mixing metaphors here, in Gartner's concept this would be "debt forgiveness." This might be a temporary strategy for an application that ultimately is slated for retirement or consolidation.

  4. 3PM Candidates. those older applications that still need to be maintained but have insufficient business value from upgrading. These are good candidates for third-party maintenance. This wouldn't be a full "debt forgiveness" but more like "loan modification." You still need the application but are looking for a cheaper alternative to vendor maintenance.

  5. SaaS Candidates: those that would benefit from moving away from traditional on-premise to software-as-a-service. Such applications do not incur "IT debt" in the future, because the service provider keeps the application up to date at all times, unlike traditional on-premise software that requires customers to upgrade.

  6. Upgrade Candidates: those that do not qualify for SaaS conversion but represent strategic platforms that the customer wants to keep current on some sort of schedule. You should avoid making custom modifications to these applications as much as possible, as it makes them more difficult to upgrade.
Now, this is not an exhaustive list of categories, but you get the idea. You have to know what applications you have and what condition they are in and then come up with a strategy for optimizing the value of each. Of course, the list should also be prioritized to determine the criticality and business value of the proposed changes.

Conducting the assessment
On the other hand, it is not always an easy matter to put applications into the right category. Users may have one opinion on the business value or technical quality of the application, while the IT organization may have another. How to evaluate in-house written systems and modifications to packaged software further complicates the problem, as the IT organization may have considerable pride-of-ownership.

In conducting such assessments, we have found sometimes widely differing opinions about whether the problem is the application itself, how the application was installed or configured, or the business processes that use the applications--or all three. In many cases, therefore, it helps to have a neutral third-party participate in the evaluation.

My consulting firm Strativa has experience in conducting these sorts of assessments. You can also read more on our approach in the blog post I wrote several years ago, Four problems with ERP, and a follow-up post, Solving the Four Problems with ERP.

Email me if this is something of interest to your organization.

Update, Sep. 29. My colleague Dennis Howlett has a good post on ZDnet with further reaction to Gartner's IT debt proposition as well as to Vinnie's and my posts. Read Dennis's entire post.

Monday, September 20, 2010

Oracle Apps User Survey: first look at early results

Update: the final results of our survey are complete. See this post: Oracle applications customers: wedded bliss or battered wives? The full report, Go-Forward Strategies for Oracle Application Customers, is available from Computer Economics.


Over at Computer Economics, we've been running a survey for customers of Oracle Applications. We've received nearly 100 responses so far, which is enough for us to begin to see some patterns taking shape.
  1. Service and support. There is a lot of dissatisfaction among Oracle customers concerning the quality and cost of Oracle maintenance and support. For example, 48% of E-Business Suite users and 41% of PeopleSoft users express dissatisfaction.

    But what really bothers customers is the cost of support: a whopping 63% of EBS users and about half of the PeopleSoft and J.D. Edwards users say Oracle support costs too much.

  2. Stay or leave? In spite of unhappiness with Oracle's support, most Oracle Apps customers aren't going anywhere. About 75% see Oracle maintaining the same or greater share of their IT budgets three years from now.

  3. Fusion what? Oracle has its work cut out for itself in selling its product roadmap. Fusion Apps are not on the radar for most Oracle Apps customers. For example, only 25% of E-Business Suite and PeopleSoft customers are considering a migration to Fusion. This may change for the better after this Open World conference, as Fusion Apps will be getting a lot more attention. It will also help when Oracle's installed base reps are finally able to start demonstrating Fusion, after this conference.
Our survey covers several other areas as well, such as experience with Sun under Oracle, Exadata, and views toward Oracle's litigation of competitors.

Dennis Howlett videotaped me commenting on these results.



We plan to publish the full results in Q4. In the meantime, if you are an Oracle Apps customer, please take the 10-minute survey here. Qualified respondents will receive a free copy of the full final report from Computer Economics.

Related posts
Oracle Open World 2010: First Night Vibe

Sunday, September 19, 2010

Oracle Open World 2010: First Night Vibe

I'm here again at this year's Oracle Open World conference in San Francisco. The conference opened for me with my participation on a panel discussion for Oracle customers, but outside of Oracle's control, moderated by Ray Wang of the Altimeter Group. Lots of dialog there that I need to process.

I'm now listening to opening presentations, in the comfort of the blogger/press room, awaiting the much anticipated keynote by Oracle CEO Larry Ellision.

In the meantime, here's a quick Youtube video of sights and sounds around and in the Moscone center, leading up to the first night's keynote.



Update, 7:00 p.m.--Oracle's View of Cloud Computing
We're now into Ellison's keynote, which is heavily focused on cloud computing and moved quickly to covering the latest developments in Oracle/Sun hardware. At the beginning of his talk, Ellison first developed two definitions of cloud computing:
  1. Virtualized cloud computing infrastructure services, as offered by Amazon.com's Elastic Cloud Computing services, and
  2. Software applications that are offered as a service over the Internet, as typified by Salesforce.com.
Ellison says that Oracle's definition of cloud computing matches Amazon's definition, not Salesforce.com's. By then quickly moving to an overview of Oracle/Sun hardware, his purpose is clear: Oracle wants to be a providers of infrastructure hardware and software to cloud computing providers--both public clouds and private clouds (similar virtualized data center services run by large organizations for their internal purposes).

By implication, then, Oracle does not intend to broadly offer software-as-a-service, as Salesforce.com does. Ironically, Oracle does have some SaaS offerings today, such as its CRM On-Demand, which it inherited from Siebel. But as we all know, such offerings do not carry the high margins of Oracle's on-premise software applications, or the margins it thinks it can get by selling high-end database appliance boxes (i.e. Exadata). In my view, then, Oracle would rather sell the infrastructure (hardware, database, middleware) than the service (SaaS applications delivered over that infrastructure).

There's something to be said about having a clear strategy and executing consistent with it. However, I have to wonder--if SaaS becomes the norm for delivering application functionality in the future, will the hardware/database/middleware market really grow to match Oracle's expectations?

Update, 8:00 p.m: Fusion Apps on the way.
Ellison devoted the last part of his keynote to talk about Oracle's much-awaiting Fusion Applications, which he said would be released to some customers late this year, with general availability in the first quarter of 2011. I won't go into the details at this time. I see now that there's a new section on Oracle's website, with much new detail on what's in Fusion Apps.

Postscript: Oracle Apps User Survey. Our 10-minute Oracle Apps User Survey is still open for responses. If you're a customer of any of Oracle's Application products, take the survey here.

Wednesday, September 15, 2010

Rumors of the death of corporate IT greatly exaggerated

I came a blog post recently entitled, Is Enterprise 2.0 Helping to Kill Off the IT Department? (For those not up-to-date on the latest fashions, Enterprise 2.0 refers to the use of tools such as blogs, wikis, RSS, mashups, and social networks to capture and manage unstructured information in business enterprises.)

What set me off about this post was not the part about "Enterprise 2.0," but the part about "killing off the IT department." I've been reading articles like this ever since I started working with IT several decades ago.

About every 10 years or so, some new technology comes along that observers trumpet as so radical and innovative that it will result in nothing less than the death of the corporate IT department. And every time, IT ultimately adapts, though at first it may resist.

The PC revolution
As I recall, the first death knell was sounded when PCs arrived. These started showing up in businesses in a big way in the late 1970s. At the time, I was working as a manufacturing systems analyst for an oil field services firm. I was in the midst of gathering requirements for a custom system that would manage tooling inventory on the shop floor.

One day, I went out to visit the tool crib in one of our plants and found that my users had already built their own tooling inventory system using a TRS-80 PC from Radio Shack. They said they didn't need help from corporate IT. I argued with the manager, "Look, I'm not out here setting up my own tool crib--you shouldn't be out here building your own computer systems." Ultimately, we did end up building the corporate tooling system, but not without a lot of resistance from users who felt that what could build themselves was good enough.

It took more than 10 years--some might say, 15-20 years--for IT to figure out how to adapt to the PC revolution. The first big issue was "connectivity." Users were buying personal computers, then spending way too much time re-keying data from mainframe-printed reports into PC spreadsheets. So, corporate IT was given the task of connecting them while still maintaining security and integrity of corporate data.

The next challenge was to harness all that computing power sitting on the desktop, which brought in the era of client-server computing. Centralized systems would maintain master file data, while desktop systems would be used for data entry and analysis. The strengths of the server computer and the client computer would each be used where they were strongest. Response time would be faster on the desktop PC since only local processing was required, and data integrity would be maintained as master files were kept at the server level. Eventually, you had three-tier (client, application server, and database server) and n-tier systems.

Along with client-server computing, we had to deal with the need for graphical user interfaces. As users became accustomed to the Windows GUI in the late 80s and early 90s, they became frustrated with the character-based interfaces of their corporate mainframe and minicomputer systems. Some users, learning Visual Basic on their own, became better PC programmers than those of us in corporate IT. So we had a whole new set of skills to learn. But corporate IT ultimately adapted.

What corporate IT went through to adapt to the PC revolution was much greater than anything it faces today in adapting to the presence of Facebook, Twitter, and iPhones.

The Web revolution
Just around the time corporate IT figured out how to managed PCs and client-server systems, the Internet changed everything. Again, a new technology served to empower users, who were now able to build their own websites and simple web-based applications, bypassing corporate IT.

But the Internet and Web technologies turned out to be a great boon to corporate IT. The first way it helped was in simplifying system design and system management. In truth, client-server was a very cumbersome way to build and manage systems, with code sitting both on the server and on each client. Web technologies made it possible to create thin client systems, with all business logic sitting at the server tier and the desktop PC used only for user presentation. Web technologies allowed systems to be re-centralized--a return to the host-based computing of the mainframe days, but with GUI.

Second, the Internet made it possible to connecting customers, partners, and suppliers in a way that was much simpler than it was with the old electronic data interchange (EDI) technologies--the so-called e-business revolution. Some of this resulted in the dot-com boom and bust, but much still remains and has become part of doing business today.

Once again, the corporate IT department adapted and survived.

The cloud-computing revolution
Today, we're in the midst of another revolution--cloud computing--which is really just an extension of the Internet wave. As Web-based systems became mainstream, it became possible to move an application system with its entire infrastructure--data centers, servers, databases, application code, network gear, and infrastructure support personnel--out of the corporate data center to a third-party provider.

At first it was a one-for-one replacement, simply picking up the application and moving it offsite--what was called, in the late 90's, the application service provider (ASP) model. Then, providers began to build their own applications that could support multiple customers on a single instance of the application code, so-called multi-tenant systems, or software-as-a-service (SaaS). Some would say this was a return to the old time-sharing or service bureau model of the earliest days of corporate computing.

The rise of SaaS applications, from providers such as Salesforce.com, meant that user departments could go out and buy their own applications as a service, without any involvement from corporate IT.

Earlier this year, Ray Wang did a quick poll of 46 large company CIOs and found only 11 (24%) of them indicating they had SaaS applications running in their organizations. But when he polled the procurement managers from these same organizations, he found that 100% of them reporting the presence of SaaS applications in various business units. Clearly, CIOs in three-quarters of these companies were being cut out of the SaaS procurement decision.

Doesn't this mean the death of the corporate IT department? I don't think so, because nearly every one of these SaaS applications, ultimately, will need to be integrated into an enterprise architecture, just like all those PCs back in the 80's needed to be connected to the corporate mainframe. You can see this happening already. As one respondent in Ray's survey said, "The business heads keep showing up with these SaaS apps and then want us to integrate them. We need to get a handle on all this!”

The architectural role of corporate ITNo one talks about "the death of corporate HR," or "the death of corporate accounting." Why is this thought of "the death of corporate IT" constantly recurring? I think it's because many observers only see corporate IT as a manager of technology. So, every time a new technology comes along that users can deploy for themselves, it would seem to obviate the need for a corporate IT department to exist at all.

Many observers don't realize that information technology--software, hardware, networks--is just one part of "corporate IT." The other major part is designing and managing business processes--especially cross-functional business processes--that utilize technology and developing. This part also includes maintaining the enterprise architecture--the combination of technology and business processes--to support the organization's objectives.

Granted, some IT departments are not very good at the second part. But if they aren't, someone needs to be. I don't care what you call it, or who it reports to. Someone needs to be concerned about the integration of all these systems with one another, and no single user department is in a position to do that.

Back to the beginning
In thinking about these matters, I was reminded of my introduction to corporate IT. My first job was as a programmer trainee at Macy's at Herald Square in New York (as seen in the Miracle at 34th Street). Macy's was one of the first organizations to purchase an electronic computer for business purposes--one of the first National Cash Register (NCR) computers--in the early 1950s.

I reported to some of those first programmers, who were still working there when I started as a trainee in 1974. (In fact, when we had trouble with some obscure piece of logic in those core systems--which had long since been migrated from NCR to the IBM mainframe--these old boys would pull out some dog-eared pages of ancient bubble flow-charts to answer our questions.)

Interestingly, prior to the arrival of its first NCR mainframe, there was no "corporate IT department" at Macy's. Rather, Macy's assigned the responsibility for this new technology to a group that already existed within the organization--it was called (as I believe I was told), the "Systems and Procedures Department."

What was the previous mission of the Systems and Procedures Department? It was to design and maintain all business processes within Macy's. For example, the procedure for handling and accounting for returned merchandise involved several departments and required tight controls. The Systems and Procedures Department designed, tested, and implemented this procedure. When the NCR mainframe arrived, the department simply incorporated computer technology to automate parts of that process.

The "systems and procedures" roots of the Macy's corporate IT department were still in evidence when I arrived in 1974, fresh out of college as a programmer trainee. After two or three days studying programming manuals, bored out of my mind, I was ready for my first assignment--to write a program to print "Holiday Money" (those fake currency certificates that department stores used to mail during holiday season to credit card holders, allowing them to spend them like real money and have the amounts charged to their credit cards).

But rather than give me programming specs, my manager (one of the old guard) gave me my first task: go talk to the users. He said, "Around here, no one is just a programmer--you have to understand the business. Go talk to the users and see what they want. Then write it up and run it by me."

He also told me about a friendly rivalry he had with his counterpart at another well-known department store. From time to time each would visit the other's store and attempt to find weaknesses in the other's business processes.

In fact, just the previous year my manager had discovered a hole in his rival's Holiday Money process! It was possible to return merchandise purchased with holiday money and receive cash back--effectively getting a cash advance on the consumer's credit card, which was a violation of the store's policy. He then notified his rival, who plugged the hole, but lost bragging rights for that round.

Understand, these were not two "business managers." These were two IT managers.

So I learned from my first week on the job: corporate IT is not just about technology. It's about "systems and processes." So, if "systems and processes" pre-dated the introduction of computers to business, it means that this role for corporate IT will survive, even if we get rid of the computers.

Related posts
The inexorable dominance of cloud computing
IT departments face extinction
The end of corporate computing