When smartphones disrupt medical devices

I'm here at the Medical Design & Manufacturing (MD&M) West conference, one of several shows running concurrently in the Anaheim, CA convention center this week.

Along with the trade show, there is an excellent conference program. I am especially interested the tracks on disruptive technologies in the medical device industry as well as updates on the regulatory environment with the US Food and Drug Administration and other regulatory bodies globally.

Here are some highlights of what I've heard so far.

Global competition for innovation

Tracy Lefteroff of Pricewaterhouse Coopers outlined opportunities and barriers in worldwide medical device innovation, based on a PwC survey.

The results are not good for the US.

• The US is becoming increasingly unfriendly to innovation. Israel is the easiest place to get regulatory approval for new medical device technologies, followed by the EU and India. The US ranks lower down the list. So, if you need treatment involving innovative technology, you may need to go outside the US.
• The US carries the highest cost per hospital bed, and fewer beds per capita than any other global region--by far.
• Industry participants expect that the regulatory environment in the US will become even more restrictive in the future.
• On the positive side, the US is still the best place to raise money for new medical technologies and it also one of the easiest markets to enter, once you have an approved product.

There may be hope, however. Lefteroff reports great interest in Washington to see the regulatory environment improve. Why? Jobs in the medical device industry are leaving the US for more friendly jurisdictions, and in the current environment, anything we can do to improve the employment situation is attractive, on both sides of the political aisle.

Disruptive technologies in the medical device industry

Jeff Brown from UBM TechInsights followed with an insightful look at how consumer technologies are disrupting established ways of addressing patient needs. Brown showed as new technologies reach critical mass, their IP is often transfered into other established technologies, disrupting them and driving down the cost and size of the established products. For example, digital camera capabilities increased and the cost dropped to the point that the technology could be incorporated into cell phones. Today, many consumers do not carry digital cameras, as the cameras in their cell phones are "good enough."

Although Brown covered several disruptive technologies in the medical device industry, much of his presentation focused on how smartphones (e.g. Apple's iPhone) are becoming and will become part of future so-called mobile health (mHealth) solutions.

For example:

• The AliveCor EKG sleeve turns your iPhone into an electrocardiogram monitor. Note however that the device is not cleared for marketing in the US. More on that issue in a minute.
  
• iStethoscope Expert, a free primitive iPhone application, uses the native microphone in the iPhone to listen to and record your heartbeat.
  
• Hearing aids, which at the high-end can cost thousands of dollars, are about to be disrupted by blue tooth earpieces connected to smartphones.

In these and many other examples, Brown pointed out the tremendous improvement in capability that comes when standalone devices (e.g. hearing aids, stethoscopes, EKG monitors) are replaced by devices that connect to smartphones. They not only perform the same function as the device they are displacing but they can go beyond with their ability to record and store data and to communicate with other devices.

For example, a traditional hearing aid can only do one thing: help you listen better. But a hearing aid that is connected to a smart phone can take advantage of the smart phone's capability to record and store conversations. In fact, a smartphone could take that recorded conversation and convert it into text and email it to you. One can imagine many applications, even for people that are not hearing impaired.

Innovation vs. regulation

Brown briefly covered the regulatory issues that constrain the convergence of new technologies with medical device solutions. Current FDA regulations treats many of these new applications and distruptive technologies as medical devices, depending on their intended use to diagnose or treat disease, or to affect the structure or function of the human body. This classification puts FDA squarely in the middle of commercialization of such products.

As Lefteroff indicated earlier, other jurisdictions are friendlier environments for introduction of these new converged technologies. It may be that some of these solutions will take hold first in developing countries, where their low cost and "good enough" capabilities will allow them to be perfected and proven.

It is ironic that, while the underlying technologies may have been developed by US companies (e.g Apple), their application as medical devices may only come to the US after they have been established and proven in other geographies.

Related posts

FDA still enforcing regulations for validation of enterprise software

Avoiding project death by ROI

I had an unusual experience recently: a client demanded an exhaustive ROI calculation for a project, and the client approved the investment.

How to kill a project

Why is that unusual? First, some background. Over the years, my consulting firm, Strativa, has developed a methodology for building the business case for enterprise IT projects (or, any initiative for that matter). We identify the perceived benefits of the new system (for example), trace them back to features/capabilities of the new system, then quantify the direct financial impact. We also identify the time-phased project costs so we can calculate the ROI, whether by a simple break-even calculation or a more sophisticated internal rate of return. The whole methodology is implemented in an elaborate Excel workbook.

Although we are quite proud of this tool, I have noticed a pattern in cases where we use it. Often, when a client demands an exhaustive ROI calculation ("show me the money"), the project does not get approved. This is true even in cases where our calculations show a strong ROI.

Although I am a great believer in the need to demonstrate financial return, I have come to the conclusion that, in practice, too many executives ask for the business case not to determine whether they should make the investment, but to find an excuse for why they should not.

Now, having said that, there are some cases where an organization's capital expenditure processes require a formal business case. Here, the project sponsor requests the business case not as a means to kill the project but merely to get funding for a project that he or she already wants to do. But apart from these cases, what explains the correlation between client demands to see an ROI and projects being killed?

The "ROI Trap"

My hypothesis is that, due to a reluctance to say "no" directly, ROI calculations are often a convenient way to refuse projects that management simply doesn't want to do.

This "ROI trap" can take several forms:

• Management argues the project budget is underestimated
• Management argues the benefits are overly optimistic
  
• Management argues the benefits cannot be connected to the proposed initiative

That final point is the most subtle. For example, benefits involving increased sales are the most difficult to get by management review. A new sales force automation (SFA) system, for example, might be justified in part by increased revenue from new sales. The rationale would be that sales people today only spend about 50% of their time selling. The rest of their time is spent looking for information, administrative activities, and reporting to management. By providing faster access to information and automating much of this administrative overhead, sales people can spend more time selling, which should result in increased revenue per salesperson.

The problem, however, is that the organization is planning to do all sorts of things to increase sales, such as any number of marketing programs and new product introductions. If sales do increase after the new system is implemented, how will management know that the improvement is due to the new system and not to other things that the organization is doing? Therefore, when presented with a SFA business case that relies in part on increased sales, the easiest thing for management to do is to say, we don't see the connection.

Who owns the business case?

Is there a way out of this trap? We have found that there is one important key to having a business case approved: management ownership of the benefits statement.

Here is how we now prepare the business case for a new system or business initiative. We hold a series of workshops to collaborate with the client's project team and stakeholders around five questions:

1. What the objectives for the proposed investment?
2. How will the project meet those objectives?
3. What financial metrics would improve if those objectives were met?
4. What are the baseline measurements for those metrics today?
   
5. What percentage improvement would be achieved in those metrics if the project is approved?

We often find, however, that even among the project sponsor, project team, and key stakeholders there can be significant disagreement, especially in answering the fifth question. The reason is simple: stakeholders are going on record that they believe the project will yield certain benefits, and if the project is approved they are in effect taking responsibility for meeting those improvements in performance.

A success story

Now, back to our recent client project, which involved selection and approval of a new customer relationship management (CRM) system.

Early in the project, the client made it clear that a strong business case would be needed for a new CRM system to be approved. Based on my past experience, alarm bells went off in my head. What were the chances that this selection would end in "no decision," to the disappointment of the project team and the vendors asked to bid on the project?

Knowing about "the ROI trap," our consultants took a collaborative approach to the business case. Instead of going off in a corner and coming back with the proposed business case, they brought the client's team into the room and asked the five questions outlined above. The CFO was particularly strong in telling the team: if you say these things are benefits, you can expect your sales quotas and budgets to reflect what you say. Translation: they would be held accountable. The CFO even went so far as to ask us to break down the benefits by region, so that the regional sales managers could be held accountable.

The result? A business case that, perhaps, was understated (due to the desire not to set too high a bar) but one that was still quite positive, and most importantly, one that had the ownership of the stakeholders who would be responsible for implementation.

In the end, the project was approved, and contracts have been signed.

Lessons learned

No one likes to be held accountable, and if the business case for a new initiative is the consultant's work only it becomes an easy excuse for stakeholders to escape responsibility. Collaboration is the key: combining the consultant's methodology and industry knowledge with the client's ownership of the goals and metrics. Then, when it comes time to present the business case, it is not the consultant's presentation but the project team and stakeholders arguing in favor of the investment.

Footnote: way back in 2004, I explored the psychological dynamics of the ROI trap, based on the work of Max Bazerman. These are still quite relevant today. See the related posts below for more discussion.

Related posts

Escaping the ROI trap
Escaping the ROI trap, Part 2

*Image courtesy of Ramberg Media Group.

Apply for Our 2011 IT Spending Survey

For more than two decades, the annual Computer Economics IT spending survey has been the authoritative source for IT spending and staffing benchmarks for IT executives.

Our 2011 survey is now underway, but we're looking for additional survey respondents.

What's in it for you? We've sweetened the deal this year. If you qualify for and complete the online survey, we'll send you nearly $2,500 worth of research publications, including the composite benchmarks from this year's study.

Click here to see if you qualify, and to apply online >>

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.

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.

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

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?

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

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

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

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

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