Oracle Apps User Survey now live

Our new survey for users of Oracle Applications is now online.

If your organization is a user of ANY of Oracle's applications systems--whether E-Business Suite, JDE, PeopleSoft, Siebel, or others--please help by taking this easy 10-minute survey.

The survey is to solicit the views of Oracle customers on several "hot topics," such as Oracle's maintenance and support programs, Fusion Apps, and the Sun acquisition.

Take the Oracle Applications User Survey Now >>

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.

Only IT professionals directly involved with Oracle Applications should participate in this study. If you are a software vendor, VAR, reseller, or consulting firm, please feel free to forward this request to any Oracle customers you know.

If there is someone within your organization more qualified to take this survey, please feel free to forward this request to them.

Thank you in advance!

Calling all Oracle Apps customers

I'm getting ready to launch a short survey for Oracle Applications customers. If your organization is a user of ANY of Oracle applications systems--whether E-Business Suite, JDE, PeopleSoft, Siebel, or others--please let me know if you'd like to respond to the survey. It should take less than 10 minutes. My email address is in the right-hand column.

What it's about. We are interested in the views of Oracle Apps customers relative to several "hot topics," such as Fusion Apps, Oracle's maintenance and support, and the Sun acquisition. We will use this information to prepare a special report to be published by Computer Economics.

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.

Only IT professionals directly involved with Oracle Applications within their organizations should participate in this study. If you are a software vendor, VAR, reseller, or consulting firm, please feel free to forward this request to any Oracle customers you know.

If there is someone within your organization more qualified to take this survey, please feel free to forward this request to them.

Factors that affect ERP implementation cost

The CEO of a small software vendor contacted me last week with a simple question. Did I know of any recent research that provided typical ratios for Tier II ERP implementation cost to software license cost? He didn't say why he was asking, but I assume it was in order to position his own customers' experience against some sort of industry benchmark.

My reply was simple. I wrote:

Dear XXX, Unfortunately, I do not have current stats on implementation to license fee revenue. It is something we should survey, as we do get asked this a lot. I usually quote a range from about 75% to 200%, typically. But as you can imagine, discounts on the software license fees affect that, and also the extent of data conversion and interfaces/integrations and modifications. Also the amount of business change being introduced.

A few moments later, I tweeted a short status update, "Chatting with a vendor about implementation cost to software license cost ratios." That triggered an interesting three-way discussion between Dennis Howlett, Martijn Linssen, and myself on the subject.

Martijn has already followed up in a blog post. In short, Martijn's position is that "there is a clear, direct and fairly linear relation between the initial cost of a product, and the additional cost(s) involved servicing it" [emphasis mine]

Not a direct relationship
I agree with Martijn that there is a relationship between the cost of the software and the cost of implementation. But I do not agree that it is a direct relationship. For example, if Company A pays more for SAP than Company B does, you can expect Company A will pay more for implementation. This might be because Company A has more users or is installing more modules. These factors will cause the software cost as well as the implementation cost to be greater for Company A. But what if SAP greatly discounts the software cost for Company A? Will that bring the implementation cost down for Company A? Of course not.

What drives implementation cost?
In fact, I have been in deals where software vendors have basically offered to sell the software at little or no cost. Does that mean the vendor or systems integrator will be willing to support the implementation for little or no cost? Of course not.

This thought experiment essentially proves that the relationship between software cost and implementation cost is not a direct relationship. There is no cause and effect. Rather, based on our ERP selection and ERP implementation project management experience at Strativa, we find that total ERP cost is affected by a number of factors.

First, there are two factors that affect both the cost of the software and the cost of implementation:

• Number of users. Software is often priced by the number of users. The number of users is also a factor in implementation cost, as more users generally means more user functions affected, more business processes affected, and more training required.
  
• Number of modules/amount of functionality. Similarly, software is often priced by the scope of functionality included. Software with more functionality is generally more expensive than software with less functionality. Likewise, implementing software that supports a broader set of business functions will cost more.

In addition, there are several other factors that affect implementation cost but do not generally affect software license cost. These include the following:

• Amount of data conversion or interfaces required. An organization that can implement the new system cleanly, without a lot of data conversion from the old system and without building interfaces to legacy or third-party systems, will get by with a lot less implementation budget than an organization that requires much data conversion or integration.
  
• Amount of business change required. An organization with well-defined business processes that conform to the business processes defined in the software will generally pay less for implementation than an organization that needs a lot of business process change.
  
• Skills and availability of the internal project team. An organization that has a well-formed internal project team with skilled resources will generally pay less for implementation than an organization that depends mostly on outside contractors to undertake implementation activities. (The organization with the well-formed team is also at less risk of project failure.)
  
• Choice of the implementation consulting partner. An organization that engages the help of a qualified systems integrator (or the vendor's own consulting arm, if so qualified) will generally spend less on implementation than an organization that chooses an SI with lesser skills or a poor track record in delivering services within budget.

There are other factors as well, such as the degree of standardization of business processes among multiple facilities and the organization's track record in managing cross-functional business change projects.

"Complexity" of the software may be a factor
Finally, there is one other factor that is a wild-card, in my opinion. That is, the complexity of the software itself. This may or may not affect software license cost, but it often affects implementation cost.

This may be easiest to define with an example. SAP and Oracle are two well-know, so-called "Tier I" ERP systems. It is generally understood that these systems can support the largest, most complex, most geographically-dispersed organizations. They can support the widest number of industry sectors. They do this by incorporating a great deal of functionality for various industries, business processes, and local regulatory requirements. They are highly configurable. In other words, they are big pieces of software, or as I like to put it, they have a "big footprint."

This complexity comes with a price. It means that to make use of the system in a specific organization, many decisions have to be made during the implementation. These decisions cost time and money to configure the software and test it specifically for the organization's needs. This drives up the cost of the implementation.

SAP and Oracle are well-aware of this issue and have worked hard over the past decade to pre-configure their systems for specific industries and use cases. If a customer fits well into the vendor's pre-configured templates ("accelerators" in Oracle-speak, or "best practices" as SAP calls them), much of the complexity of the software can be hidden from view. Customers that fall neatly into the vendor's template can sometimes achieve very rapid and cost-effective implementations. Both vendors will gladly share references of such with prospects.

But don't the higher-end software packages still cost more than software targeted for small and mid-size businesses? This is not always the case. I have seen situations where SAP and/or Oracle were actually the low-cost bidders. In cases where a software vendor wants the deal, it is not safe to assume that the higher-end package will cost more. For this reason, I don't believe software "complexity" in itself is a consistent factor in either software license cost or implementation cost. As we consultants like to say, "it depends."

Popularity of implementation-to-license cost ratio
So, why do software vendors, customers, or systems integrators continue to use the implementation-to-license cost ratio? Because, as flawed as the ratio is, it does serve to set expectations as to implementation cost. To me, the ratio best works in hindsight. If a system implementation, on average, requires 1.5 times the software cost, a customer better not be assuming that it can do it for half the license cost.

But to really judge the prospective cost of an ERP implementation project, nothing beats doing a detailed estimate based on a realistic work-breakdown structure, with realistic estimates that take into consideration the factors outlined in this post.

Related posts
ERP implementation: plan for the worst
Epicor's Shared Benefits program: watch for unintended consequences
Revisting Epicor's Shared Benefits program
Oracle claiming ultra-fast installs in SMB market

ERP implementation: plan for the worst

Chris Kanaracus, always on the lookout for lawsuits and regulatory filings related to enterprise software, spotted this case study today: a company that was forced to delay reporting of quarterly results due to problems with a newly installed ERP system.

VAN NUYS, CALIFORNIA -- August 11, 2010 -- Superior Industries International, Inc. (NYSE:SUP) today announced that it is postponing the release of its financial results for the second quarter and year-to-date periods ended June 30, 2010, and its earnings conference call originally scheduled for today, Wednesday, August 11, 2010. The postponement is the result of delays in finalizing the quarter financial close due, in part, to the recent implementation of a new Enterprise Resource Planning (ERP) system. Superior is working diligently to finalize its second quarter results and will provide new dates and times for the earnings release and earnings conference call in a forthcoming news release.

Chris provides further details:

The problems were primarily due to closing a quarter for the first time with the ERP system, along with changes to Superior's legal structure in Mexico, it added.

The company recently implemented a product from QAD, CIO Ross Perian said in an e-mail. He did not respond to requests for further details on the project, which went live on March 29, according to another SEC filing.

Fortunately, according to Chris, it appears that only a five day extension will be necessary. And it pales in comparison to some of the catastrophic ERP failures reported over the past decade.

My take
There are several unanswered questions, and several take-aways from this mini-case study.

• According to Chris's digging, the new system went live on March 29. That's over four months ago, more than one quarter. How did the firm manage to close the previous quarter? Or, was it running the old system in parallel for purposes of financial reporting?
  
  
• The firm had four months since it went live on the new system to test the quarter-end close routines. Did it do so? If so, what were the results? Did it have any forewarning that there were problems? I have personally witnessed QAD implementations that took less than three months. Four months in QAD-land is a long time. What was the project team doing during this time period?
  
  
• Was there a contingency plan? Did anyone ask and answer the question, what will we do if the new system can't close the quarter?
  
  
• QAD's MFG/PRO is a mature product. The financial close routines should simply work. Did the firm modify the vendor's source code or make other non-standard configuration changes to the system?
  

• Finally, if I were the top executive, I'd be asking some tough questions about the new system's readiness to close out the fiscal year.
  

I don't mean to pick on Superior or QAD in particular. The fact that only a five day extension appears to be required is a good sign that the project team was not far off from success. Still, this is a publicly-held company, which doesn't need these sort of SEC filings.

Our latest Technology Trends study at Computer Economics this year shows that, among 19 technology investments, ERP is among the most risky IT initiatives. Yet, we've had 20+ years to learn how to do it right.

Unfortunately, it seems we keep learning the same lessons over and over again.

Related posts
Philly pulls plug on failed Oracle project
What went wrong with HP's SAP migration?
Four problems with ERP
Solving the four problems with ERP

Countering aggressive software maintenance terms

There are two developments this week on the analyst front, dealing with the issue of software maintenance contracts. First, Gartner issued what it calls a "code of conduct" for vendors in crafting maintenance contracts. Second, Ray Wang wrote a hard-hitting blog post dealing with what he calls "all-or-nothing" vendor maintenance agreements.

Code of Conduct
Gartner's press release on its code of conduct is quite detailed, outlining specific points that vendors should address in software contracts. In short, Gartner addresses the following points:

• The right to regular, appropriate, predictable updates to software products
• The right to clearly defined response times and stratified IT support levels based on application criticality and other business factors
• The right to reasonable, predictable percentage ranges for yearly maintenance fee increases--or decreases--as well as long-term caps on increases in maintenance costs
• The right to end or change support at any time for products that are not in use
• The right to reasonable, predictable levels of support throughout product and contract life cycles
• The right to reasonable, clearly defined maintenance and support for legacy systems
• The right to explicit statement and approval of support details at the line-item level

There's not much to argue with in Gartner's recommendations. They provide a common-sense checklist for evaluating any software vendor maintenance relationship.

If I see any lack in Gartner's code of conduct, it is that it fails to mention the third-party maintenance option. Gartner is completely silent on this point. Some vendors these days are attempting to preclude customers from seeking service and support from third-parties. A customer-friendly maintenance contract should explicitly allow customer the right to go to a third-party provider for software maintenance, without jeopardizing warranties or future support.

"All-or-Nothing" Tactics
Ray's post drills down more deeply on one tactic that he sees vendors adopting these days--that is, forcing customers to put all software licenses under contract, and paying up any back maintenance, when buying new licenses.

Ray writes:

Conversations with 11 enterprise apps customers in the past two months indicate stricter enforcement of vendor "All or Nothing" maintenance policies. “All or Nothing” maintenance policies often require customers to put all licenses on maintenance or receive no maintenance from the vendor. These policies also prevent customers from reducing the number of licenses covered by maintenance. The rationale for these policies – customers could potentially apply the patches, bug fixes, and upgrades for covered licenses to the uncovered licenses.

At first glance, it all sounds fair and reasonable. But Ray points out four cases where such clauses can cost an organization dearly. For example, one division of a large company may drop maintenance on a software product. When another division then goes to buy additional seats for the same software product, the vendor invokes the contract to demand that the entire company pay up all maintenance, or forgo buying new seats. Read Ray's entire post to see how easily an organization can run afoul of such contracts.

Ray has some good advice for negotiating hard against such tactics, and--in contrast to Gartner--includes consideration of third-party maintenance options as a counter-tactic.

My take
Ray and I and other Enterprise Advocates Vinnie Mirchandani and Dennis Howlett, have been beating the drum for years on this issue of software maintenance contracts (see the Related Posts at the end of this post for a sample). The situation over these many years has not gotten better. In fact it could be getting worse. As traditional vendors see new license revenues shrinking in the current IT spending recession they become even more adamant at pursuing revenue from their installed customer base. This motivates them to push maintenance fees even harder. There are a few exceptions, such as RightNow's Cloud Services Agreement, Infor's Flex program, and Microsoft Dynamics' separation of maintenance fees from support fees. But the big players--SAP and Oracle in particular--show no signs of softening their approach.

I am coming to the conclusion that there are only two things that will ultimately shift the balance of power to something that is more equitable between vendors and customers. Unfortunately, both of them involve the legal system.

1. A thriving third-party software maintenance industry. As long as customers have no choice in maintenance providers, there can be no competition. But the best existence proof for third-party maintenance--Rimini Street--is now mired in a lawsuit by Oracle. Oracle fired the first shot, but Rimini Street appears to be itching for a battle by filing an aggressive counter-suit. That's good news. Hopefully this case will be decided in a way that provides legal precedent for the right of third-parties to offer software maintenance that does not infringe on the OEM's intellectual property rights.
   
2. Antitrust rulings by the US Department of Justice and the European Union. Although the enterprise software marketplace is not a monopoly, when a customer commits to a certain vendor the vendor-client relationship at that point becomes less of a free market. The customer has committed enormous amounts of time, effort, and business process design that is now intricately linked to that vendor. Undoing such a decision is expensive--even prohibitive. Therefore, there needs to be some legal protections for customers once they commit to a vendor relationship. The tech industry is no stranger to such antitrust rulings in the past (e.g. the ruling against IBM, forcing it to unbundle mainframe hardware from operating systems, which provided the legal framework for the plug-compatible industry comes to mind). A legal requirement for vendors to unbundle software licenses from maintenance services and maintenance services from support services is one area crying out for similar rulings.

In the meantime, customers need to fight back. Gartner's list and Ray's recent post provide good ammunition.

Related posts
Rimini Street, SAP, and the future of third-party maintenance
Rimini Street to provide third-party support for SAP
Legal basis for third-party ERP support industry
Flash: SAP backs down on 22% maintenance fees
SAP postpones its maintenance fee price hike
Enterprise software: who wants to be the low-cost leader?
Attacking and defending software vendor maintenance fees
SAP and third-party maintenance: good for me but not for thee
SAP maintenance fees: where is the value?
Mad as hell: backlash brewing against SAP maintenance fee hike
Why vendors resist negotiating software maintenance fees
Pushing back on software vendor maintenance fees
SAP under the spotlight for "broken promises"
Vendor software maintenance programs: top 10 wish list
Mad as hell: backlash brewing against SAP maintenance fee hike
Oracle confirms: maintenance fees are virtually all profit
Oracle profits strong, thanks to your maintenance payments
Vendor maintenance fees: just say no
High software maintenance fees and what to do about them

Shifting strategy: Infor casts its lot with Microsoft

Infor came out with two significant announcements this morning. Based on a briefing that Infor gave me yesterday, they point to a major strategic shift in direction. Infor's 70,000 customers should take note.

Two announcements
First, Infor announced something called Infor ION, which is a set of software services for application integration, document-based communication, and business process management, across Infor's own applications and non-Infor systems. Infor ION subsumes (my word) Infor's previous work on Open SOA, which was aimed at integrating Infor's existing applications portfolio. Infor is promoting ION as an alternative to "high cost middleware implementations." ION is currently in development, scheduled for release in Q4.

Second, Infor is moving all new product development to Microsoft's technology stack. The elements of the stack include Windows Server, MS Single Sign-On, MS Reporting Services, SQL Server, Silverlight, and Sharepoint. Infor will continue to develop its applications that run on other platforms, such as its IBM Series i and mainframe applications. But all new development will be all Microsoft.

It also means that Infor will deliberately abandon development of its own technology and tools. For example, in the briefing Infor said it was walking away from its own workflow engine development, its own Clear UX user-interface (which it had acquired), and its own efforts to build portal technology using open-source.

A strategic shift for Infor
These two announcements, taken together, represent a major change in product direction for Infor. Here is my evaluation:

1. Infor is right to give up trying to be a tools developer. There are very few application software vendors that successfully develop proprietary tools or technologies. (The only successful vendor, to my knowledge, is SAP, with its ABAP language--but that's only because ABAP dates from the early 1990s, when client/server development tools were not adequate for what SAP needed. Oracle is another, but Oracle is a technology/tools vendor first and an apps vendor second. Same with Microsoft.)
   
   There are major benefits for Infor in walking away from tools development. First, it frees up product development funds to focus on the thing that Infor customers really need: continued development, enhancement, and integration of Infor's applications portfolio. Second, by using Microsoft standard technology, it should also allow Infor to get there quicker with its ION integration and business process management framework. Third, it allows Infor to more easily recruit and retain product development and implementation personnel, as they will be working with technologies that are broadly supported in the marketplace. Finally, it is more attractive for customers, who won't need to have their IT personnel trained in another set of tools.
   
2. Alignment with Microsoft is the probably the best choice. It's something of a surprise, as Infor has mostly been thought of as more IBM-centric than anything else. But Microsoft is a better choice than IBM for standardizing its technology. Our research at Computer Economics shows that nearly every data center has Microsoft Server in its OS mix. The same cannot be said for any other operating system. This is especially true in the small company and mid-market, where Microsoft Windows averages more than 70% of the data center processing workload. Coming to its installed based with new products based on the Microsoft stack is an easy sell--not so if the stack were IBM's.
   
   Does this bring Infor into competition with Microsoft's own Dynamics enterprise software business? No more so than for any of the many other Microsoft-based vendors, such as Epicor. Furthermore, there is a huge upside for Microsoft, as the partnership represents a potentially bigger footprint for Microsoft among Infor's 70,000 customers.

I do have one area of question, and that is concerning leadership. It's an open secret than Infor has lost several key executives recently, most notably Jeff Ralyea, formerly VP of product management and Bruce Gordon, formerly Infor's CTO. These individuals were key architects of Infor's Open SOA strategy, which is now incorporated in Infor ION.

Does Infor have the right team in place now to move forward? Infor assured me that it does. The product strategy is being headed up by Soma Somasundaram, Senior VP of Global Product Development, who has a long history with Infor, going back to when it was Agilisys. He will work closely with Jeff Abbot, who is now in charge of both product marketing and product management. In terms of developers, Infor assures me that the bench is deep, with resources worldwide.

As indicated earlier, ION is still in development with release planned for Q4. That will be a key milestone to evaluate the success of Infor's new strategy. In the meantime, I believe the strategic direction is right. But execution is key.

If you are an Infor customer or Infor partner, please let me know your view on these announcements. Is Infor on the right track? Leave a comment on this post, or email me confidentially.

Related posts
Update on Infor's Flex program: customers win
Infor juices up its maintenance program value with Infor Flex
Infor's opportunity: value in maintenance and support
Infor using SOA to breath new life into old apps

Open source not immune to ERP vendor consolidation trend

The enterprise software vendor consolidation trend has now reached the open source corner of the market, with Consona's announcement that it is acquiring Compiere, Inc.

Background on Compiere and Consona
Compiere was one of the first open source ERP developers. I interviewed Compiere's founder and then-CEO Jorg Janke back in 2006 and wrote an extensive post about the product. At the time, Compiere was facing a rebellion from some of its community "freelance" developers, who took the open source code base and forked a separate development project, dubbed Adempiere. Read the whole post for background on Compiere. And read the many comments also, which give good insight into the issues and challenges of managing an open source project.

Since that time, Janke was replaced by Don Klaiss as CEO and eventually departed from Compiere altogether. Compiere continued to demonstrate some success in the market, however, as I noted in 2009 with its win of a very large deal at La Poste, a $27B (USD) global postal processing organization.

Consona, which is Compiere's new owner, has been rolling up smaller ERP vendors for some time. Originally the parent of Made2Manage, it changed its name to Consona in 2007 and has since acquired several other ERP and CRM systems for the SMB market, notably Intuitive, Onyx, Encompix, DTR, Cimnet, and Axis. Consona, along with most or all of the traditional on-premise enterprise software vendors, has had a tough several years due to the recession.

Issues in the Announcement
A couple of issues I note in the announcement this morning. First, the press release references 130 customers of Compiere today. But in 2006, Janke indicated to me that Compiere had about 250 customers. What happened to the other 120?

Secondly, what happens to Compiere's open source offering? Though founded as an open-source project, Compiere had been focused largely on its own proprietary enhancements, add-ons, and services--in other words, making money. As I noted in my 2006 post, this was one of the factors that led to some of Compiere's community forking the code to the Adempiere project. Now with Compiere's ownership under Consona, how much effort will the new owner put into continuing development of the open source code base?

Benefit of Open Source
In a sense, it doesn't matter as much as it would if Compiere's original code base was proprietary. One of the tenents of open source is that no matter what the owner of the code does, the users of the code continue in their rights to use, extend, enhance, and distribute the code. The Adempiere fork of Compiere is evidence of this.

To my knowledge, this is the first instance of an open source ERP/CRM developer being acquired by a vendor of proprietary software. It will be interesting to see whether Compiere's users are helped or hindered by this acquisition.

Update, 12:45 p.m. Read the comments on this post for more insights on Compiere's architecture. Plus, Ned Lilly has a really good post on the Consona/Compiere acquisition. Ned is in a particularly strong position to comment, as he leads another open source ERP project, xTuple (formerly OpenMFG). Ned's ironic conclusion is that Compiere "failed as a company" not because it was open source, but "because it turned its back on open source." But, please, read the whole thing.

Update 2:30 p.m. I have been educated by three Adempiere developers regarding the inherent multi-tenant architecture of Compiere and have therefore edited this post to remove my previous comments regarding Compiere's lack of multi-tenant capabilities. I was clearly wrong there. See the comments section on this post for details. Thanks, guys!

Update, 2:47 p.m. Josh Chalifour did some analysis of activity (or lack thereof) on Compiere's user forums and finds a disappointing lack of care and responsiveness from Compiere toward its community. Not a good sign and hopefully something that the new owners at Consona can remedy.

Update, June 21: I just discovered that Jorg Janke has been maintaining a website, Compiere from the Source, and he is planning to write "a very detailed three part blog about Compiere history and potential future." Check it out.

Related posts
Big win for open source ERP project Compiere
Compiere's open source ERP business model and growth plans
Consona layoff
Open source ERP and CRM carry strong ROI
Total cost study for an open source ERP project

Beware the malicious insider

Over at Computer Economics, we've published a new special report entitled, Malicious Insider Threats: Countering Loss of Confidential Information, Fraud, Sabotage, & Other IT Security Threats Posed by Trusted Insiders.

Most organizations are aware of the IT security threats posed by outsiders. Countermeasures such as firewalls, antivirus software, and intrusion detection systems are all aimed at these threats. Yet these measures do little to counter an even greater threat--that of malicious insiders within the organization.

As our study shows, however, many organizations do not treat these threats seriously. Such threats include fraud, sabotage, and theft or loss of confidential information caused by trusted insiders. These threats go beyond negligence. They represent purposeful action on the part of insiders to act in opposition to the interests of the organization, whether for financial gain, retribution, or some other motivation.

This report, based on a survey of 100 IT executives and security professionals that we ran last year, covers four categories of malicious insider threats: accessing confidential information without authorization, disclosing confidential information, executing fraudulent transactions, and sabotage of the organization’s systems, network, or data. For each category we report how seriously organizations perceive these threats and how frequently these threats actually result in violations of security. We then examine the extent to which organizations implement four best practices for controlling user access and 12 best practices for mitigating threats from IT personnel. Finally, we analyze the extent to which organizations take action to counter malicious insider activity by monitoring of insider email, keystrokes, computer files, and Internet traffic.

Read an excerpt of the full report, in this free research byte: Malicious Insider Threats Greater than Most IT Executives Think.

Plex Online: pure SaaS for manufacturing

As software-as-a-service (SaaS) providers continue to prosper against traditional on-premise enterprise software vendors, I've been frustrated by the lack of SaaS solutions for manufacturing companies. There are a number of SaaS providers of CRM solutions, HRM and other point solutions, of course, that can work for manufacturing firms. But where is there a complete ERP, deployed as SaaS, for manufacturing operations?

Let's look at some possibilities:

• NetSuite is true SaaS, but not a fit for most manufacturing companies, as by NetSuite's own admission, it targets services businesses and lacks many fundamental features for manufacturers such as standard costing, shop scheduling, capacity planning, and MRP. (A promising start-up, Rootstock, is building extended manufacturing functionality on top of NetSuite's platform, but it is a new effort and only now being rolled out beyond its initial beta customers).
  
  
• Workday is another true SaaS provider, with ambitions to be a full ERP replacement. But like NetSuite, Workday will not target manufacturing companies. Today, Workday only offers HRM and some financial systems functionality.
  
  
• The on-premise ERP industry leader, SAP, has its Business ByDesign (BBD) offering, which has been stuck in beta for years. But like NetSuite, BBD is not targeting manufacturing companies. Furthermore, its initial deployment was as a single-tenant system (a separate instance of BBD for each customer), not a true multi-tenant SaaS offering, which services many customers on a single instance.
  
  
• Other on-premise ERP providers, such as Oracle, Microsoft, Lawson, IFS, and so on, are missing-in-action when it comes to SaaS for manufacturing. The most they offer are hosted versions of their on-premise software, like Lawson does. When they do offer true SaaS, it is only for niche functionality, such as CRM, as an adjunct to their on-premise software.
  

To my knowledge, there is only one true SaaS provider that offers a complete ERP solution today for manufacturing companies, and that is Plex Online, from Plex Systems.

Plex's PR folks have been after me for a long time to give me a briefing. I finally took some time today and spoke by phone with Mark Symonds, Plex's President and CEO. Here are some of the key points from our discussion.

Why so few SaaS solutions for manufacturing?
I asked Mark, why there are so few complete SaaS solutions for manufacturing firms? He responded that he wished there were more, as it would validate the delivery model Plex provides. He also indicated the difficulty for traditional on-premise vendors, those that have the domain knowledge, to transition to SaaS. It's not easy to completely rearchitect an on-premise solution to a multi-tenant model. In addition, giving up the initial license fee model for a subscription model, which usually goes with SaaS, is a financial disincentive for the on-premise providers to make the switch.

Plex was fortunate, however, in that when they first re-architected their formerly on-premise system to SaaS, they were able to keep new customers paying up front license fees. This allowed them to fund their development, until Plex converted to a subscription model a few years ago.

What about green-field SaaS providers that don't have an installed customer base to contend with? Well, manufacturing systems are not an easy place to start, as they are a super-set, to use Mark's term, of what's required for services businesses. Which may explain why the pure-play SaaS providers have started with the services sector.

Is Plex really pure SaaS?
The term SaaS is thrown around so much these days, I wanted to ensure that Plex Online was a true multi-tenant system. Mark assured me that it is. The system was developed beginning in the year 2000, and all new features are implemented once in the system for all customers, who can choose to "opt in" to the new functionality according to their needs. Plex also allows a high degree of configuration for individual customers and provides a visual composition environment to allow customers to create their own custom displays and reports.

The Plex literature does not call attention to the technology platform, but I did determine that the system is built on Microsoft technologies. There is a Microsoft SQL Server database on the backend, with Active Server Pages as the original development platform. New functionality being developed in C#.net. Having started development ten years ago, the technology platform appears a bit of a hybrid and a bit dated in spots, in my view. But, it works.

Plex currently runs two instances of the system, for load balancing purposes--which is not uncommon among other SaaS providers, such as Workday. I was impressed that MS SQL Server is able to scale to this degree, with hundreds of customers on each instance, and Mark indicated that scalability has not been a problem. The client user interface is all browser-based, utilizing HTML, dHTML, Javascript, and XML. The hardware platform is all HP Wintel servers.

Support for large manufacturing organizations
I had heard from Plex's PR folks that the company has recently been having some success selling into larger organizations, over $1 billion in revenue. I was interested to find out whether these represented true multi-facility, multinational organizations, or whether these were merely plant-level implementations where a traditional on-premise vendor was handling the primary corporate requirements (i.e. a two-tier ERP strategy).

Mark assured me that some of these were complete ERP replacements (although Plex is working with some larger organizations in a two-tier ERP strategy as well). For example, Inteva Products is a company of 3,600 with 17 facilities on three continents. Originally a part of Delphi Interiors, it spun off in 2008 as a separate company. Looking to replace its SAP system, Inteva chose Plex Online. The implementation in 14 global locations took just twelve months. It's a good story and an "existence proof" that Plex can address companies of this size.

The challenge of international requirements
I've seen manufacturing firms struggle with systems that do not truly support multiple facilities for material planning and costing. Is Plex a true multi-facility system? Mark indicated that Plex does allow a single company to run a separate material plan for each plant and to transfer material between plants with correct accounting for costing methods that may differ between plants.

Multinational companies may need to set up multiple tenants within Plex, but these are to accommodate different tax and regulatory requirements (localizations) not for multi-facility requirements. On this point, I questioned how Plex, as a small vendor, was able to support localizations for so many international locations. Localizations are currently provided for Mexico, Canada, China, German, the UK, and Japan ("to some extent"). Mark's response indicated that localizations are handled on an opportunistic basis--when a customer needs them, they provide them with support from Plex's partners, such as Plante & Moran , BDO Seidman, and Baker Tilly.

Prospects considering Plex should not assume, therefore, that Plex can handle all international requirements. Be specific on what's required and be prepared for Plex to propose additional time to develop the localizations needed.

Dealing with medical device and pharma manufacturers
I was especially intrigued by Mark's claim to be addressing the needs of life science companies. Based on my experience dealing with FDA regulatory requirements, I was interested to know if Plex was able to address buyer concerns about demonstrating control of system configuration. Normally, buyers have little or no say about how or when a SaaS provider makes changes to a multi-tenant system. Mark indicated success in this area, by giving customers the ability to "opt in" to system changes, as discussed earlier, and by submitting to customer qualification of Plex as an approved vendor. Plex's certification of its operations as compliant with SAS 70 Level II also helps.

My take
Whatever Plex is doing, it seems to be resulting in some good financial performance over the past three years. As a privately held firm, Plex does not publicly report performance. But Mark indicated 33% growth in the top line for 2008, 14% for 2009 and a good outlook for 2010. In a timeframe when nearly all on-premise enterprise software providers are showing negative license sales growth, Plex's results are outstanding.

Do I have any concerns about Plex as a provider? Only that buyers should check functional fit. Plex's roots are in the automotive industry, though it is now expanding into other areas such as life sciences, food and beverage, and aerospace/defense. The functional footprint may have some gaps, depending on the industry. Due diligence is always advised. The ability to support international requirements in specific locations should also be verified, as discussed earlier.

That said, I think Plex is on the right track. I only wish other SaaS providers would address the needs of the manufacturing industry.

Update, May 10: Fellow Enterprise Advocate Dennis Howlett provides his take on Plex. Dennis delves into many details I didn't go into, so please read his post.

Related posts
Lawson's cloud services: good start, but no SaaS
Workday pushing high-end SaaS for the enterprise
NetSuite a viable alternative for SAP customers?
SaaS contingency plans need more than software escrow

Lawson's cloud services: good start, but no SaaS

Lawson announced a new cloud computing program today, but it's only an incremental step in the right direction.

Extension of Lawson's existing managed services offering
For some time, Lawson has been providing managed services to customers of its traditional on-premise ERP and talent management on-premise software. Under that program, Lawson hosts its software in one of its partner's data centers and provides application management, patch management, and other service that are traditionally the responsibility of the customer. The customer buy a perpetual license to Lawson's software but lets Lawson operate it, for a fee.

The new program adds a few new twists.

• First, instead of hosting in a partner's data center, Lawson will now deploy its software on Amazon's Web Services Infrastructure (a virtual data center, if you will). In addition, Lawson is now offering a subscription option, whereby the customer can lease the software and pay for it on a monthly basis, along with the costs for Amazon's infrastructure charges and Lawson's managed services.
  
  
• At the end of the subscription period (somewhere between one to four years) the customer will now have an option to either continue the subscription or convert to a perpetual license, with an unspecified credit given for the period of subscription--sort of a "lease-to-buy" option.
  
  
• Using Amazon's cloud, Lawson is now also offering a 14-day test-drive option at an (assumed-to-be) nominal charge, whereby the prospect can work with the software for 14 days using their own business processes and data.
  

Close but no cigar
After speaking with Jeff Comport, Lawson's senior VP of product management, however, I feel there is less here than meets the eye.

1. Meeting the PR need. In my opinion, Lawson's cloud services, now give Lawson something to say when analysts, press, and prospects ask, "What are you doing about the cloud?" Beyond that, there's not much here beyond traditional software offered on a hosted basis--something that vendors have been doing since the ASP days of the late 1990s.
   
   
2. Flexibility. Lawson's press release points out the advantages to customers in being able to automate the provisioning or setup of additional Lawson software instances (e.g. for testing changes or upgrades) or to meet spikes in business volume. But these are features of Amazon's cloud infrastructure, not of Lawson's software.
   
   
3. Subscription pricing, no doubt, is something new, but that's just a contract option--it has nothing to do with how the software is designed, deployed, and maintained. And whether it actually saves money, or simply spreads it out over time--well, that will depend on the terms of the deal.
   
   
4. The 14-day test drive is a bit too short for my taste. Jeff positioned the test drive as something more than a demo but less than a full blown conference room pilot. I can see why Lawson would want to cut its presales expenses by shortening the demo cycle, but I'd rather see an option to do a full-blow prototype. I prefer RightNow's approach--unlimited capacity to do a 90 day pilot test. But that's hard to do cost-effectively without a multi-tenant offering, which RightNow has but Lawson doesn't.
   
   
5. No SaaS offering. As just mentioned, nothing in Lawson's announcement today has anything to do with software-as-a-service. It is simply the same Lawson software, deployed as a single instance, in Amazon's cloud. Every patch or regulatory update that's needed has to be applied to each customer separately--either by the customer or by Lawson. Customers still need to go through periodic version upgrades. The cost savings are only those reflected in the lower cost of the infrastructure (the smallest element of ERP TCO)--and even that will depend on how much of those savings Lawson keeps for itself, as opposed to passing on to the customer.
   

Lawson backpedals on "Collapse of SaaS"
So does this mean Lawson's CEO, Harry Debes, is retracting his 2008 proclamation that the the SaaS market would collapse in two years?

This "on demand", SaaS phenomenon is something I've lived through three times in my career now. The first time, it was called "service bureaus". The second time, it was "application service providers", and now it's called SaaS.

So, in Harry's mind, "SaaS" equals "application service providers." Well, what Lawson is now doing with Amazon looks an awful lot like an application service provider.

How does Lawson avoid calling its new program a retreat from Debes' earlier proclamation? The press release vaguely alludes SaaS competitors as offering "commodity software," while positioning Lawson's approach of offering "single-instance ownership and control" as superior.

I'm not convinced. The overhead and expense, even with Lawson's new offering on Amazon's cloud, will be far above what SaaS providers experience. True multi-tenant SaaS providers, such as Salesforce.com and NetSuite, make changes once, and the entire customer base experiences them instantly. This is especially a benefit to users of HRM and financial management systems (two of Lawson's horizontal sweet spots), where regulatory changes are not optional.

Don't get me wrong. Lawson's moving the infrastructure layer to Amazon's cloud services is a good move. In the absence of a strategy to offer true software as a service, prospects now will at least have the option of a low-cost and flexible cloud infrastructure. And for prospects that find Lawson meets their needs in terms of functionality--this may well be the best option for them.

Furthermore, Jeff is right--there are very few if any true SaaS alternatives for full-blown ERP functionality for larger companies. NetSuite, Plex, and others are focused on the SMB market. SAP's Business ByDesign is still not yet in general release, and when it is, it will also target the SMB space. Workday is targeting larger organizations, but it's stated desire to be a full ERP replacement is probably years away.

So Lawson still has time. But during this time, I just wish Lawson would establish a clear direction to at least offer some of its strong HRM and financial management systems, for example, as a true service. If it doesn't do so, it may find its lunch being eaten by the cloud-based providers such as Workday and Intacct. It may not happen tomorrow, but it will happen.

My fellow Enteprise Advocate Vinnie Mirchandani also weighs in: Lawson: I'm OK, you are not OK.

Fellow Advocate Dennis Howlete, has a similar view to mine and Vinnie's on ZDNet: Lawson teams with Amazon for cloud ERP--ahem.

Update: I pinged Naomi Bloom, who is an expert on HRM, and HRM SaaS providers in particular about this post, and she unleashed a string of Twitter messages on this subject, which I'll quote here:

• When PeopleSoft made client server de riguer, suddenly every old mainframe product was recast as client server. Remember screen scraping?
• As I'm reading all the posts on Lawson's hosting their ERP and TM apps "in the Amazon cloud," I'm having deja vu.
• Anything can be hosted, anything can be surrounded with managed services. But don't be fooled. True Saas is the future.
• Lawson had better rearchitect and quickly. Let's hope our old friend Jeff Comport knows this and is hustling big time to make it happen.
• If you have a terrific, modern multi-tenant product, it's a business decision to run it single tenant, cloud or on-premise.
• If all you have is older, single tenant software, best you can do is find lower cost hosting/managed services. I rest my case!

Related posts
Workday pushing high-end SaaS for the enterprise
A game-changing play in enterprise software
Insights from Lawson CUE 2009
Update on Lawson's strategy