The Enterprise System Spectator

Tuesday, February 25, 2014

Drilling Deep into Healthcare ERP

Most enterprise software providers today claim to target certain industry sectors. But when you scratch below the surface you find that their so-called industry focus is not much more than a market strategy. There is little if any support for the core operations of those industries. At best, such providers give a tip-of-the-hat to certain industries in their horizontal applications, such as accounting or
HR management.

The problem is not so much in the manufacturing industries, where ERP started. Indeed, there are ERP providers with strong operational support for, say, or engineer-to-order manufacturers with native PDM integration, or, for metal processing centers, with nesting logic.

The problem is when you get outside manufacturing. For example, some vendors claim to support the financial services sector, but you can't find a core banking or insurance claims module in their portfolios. Ask about those, and the vendor will give you a list of partner solutions. In other words, there is not a serious effort to support those industry-specific operational requirements.

Infor as an Example

One example of a provider that is putting some weight behind its industry strategy is Infor, the third largest provider of enterprise software, after SAP
and Oracle. Since Charles Phillips took the helm as CEO in 2010, Infor has been building out its capabilities to match its tagline, which reads in part, "Specialized by Industry." Its website lists 12 industries, from aerospace and defense to public sector. But when you drill deeper, you find not just "food and beverage," but "bakery, grain, and cereals," and "confectionery." I've worked with manufacturing systems for over 30 years, and even I'm not sure how the requirements for those sub-industries would be different. But I'll take Infor's word for it.

So far, so good. But Infor has taken the concept of industry specialization beyond manufacturing and is applying it to the non-goods-producing sectors as well, such as in healthcare. The firm has already acquired and built out solutions for hospitals, extended care providers, and health insurers, along with data integration functionality between healthcare providers and from medical devices. These solutions go a long way to address the day-to-day operational activities of healthcare providers, not just their administrative support needs.

Today, Infor took another step to build out its operational support for healthcare providers, announcing its intent to acquire GRASP Systems International. It's an interesting move. Infor already supports healthcare workforce management (e.g. nursing staff scheduling) through systems it picked up with its Lawson and Workbrain acquisitions. But its acquisition of GRASP will take that a step further.

GRASP goes beyond simple scheduling of, say, nursing staff based on the number of patients. Rather it provides "automated patient
acuity," which means it takes into account "the unique set of interventions required for each patient." In other words, a patient in critical condition will need more attention than one in less critical condition. Even two patients with the same condition may require different levels of attention, depending on other factors. The ability to more precisely allocate healthcare staff not only improves productivity, thus saving money. It also improves outcomes by allocating staff according to actual needs of patients.

Infor's acquisition of GRASP goes beyond just picking up its software products. GRASP also has a significant professional services group, which means Infor is acquiring some good healthcare industry talent as well.

A Blueprint for Growth

ERP is by every definition a mature market. The need for horizontal solutions such as basic accounting and HRMS are more than adequately provided by a set of well established competitors. Of course, there is an opportunity for new cloud upstarts to displace these incumbent providers, as I've pointed out recently.

But in addition to cloud deployment, another way for enterprise software providers to grow is to better serve specific industry sectors, drilling down beyond administrative support into deep operational processes. There are hundreds of small providers, such as GRASP, that have taken this approach. Infor is one larger provider that is attempting this at scale, in a number of industry sectors.

Wednesday, February 19, 2014

The Cloud ERP Land Rush

Oklahoma Land Rush

For those unfamiliar with US history, in 1889 the US government opened unoccupied lands in Oklahoma to settlement. Settlers could claim up to 160 acres, live on and improve the land, and then legally obtain title to it. Such an opportunity led to a land rush, in which thousands of settlers raced into Oklahoma to make their claims.

Today, cloud ERP is like Oklahoma in 1889, mostly unoccupied land, and there is a race as cloud vendors rush in. NetSuite and Plex were two early settlers. Today NetSuite has more acreage (number of customers), while Plex has fewer acres but more development of those acres (functionality)--at least in manufacturing. Cloud-only providers such as Rootstock, Kenandy, AscentERP, Acumatica, Intacct, and SAP (ByDesign) are also in the race. Traditional providers such as Microsoft Dynamics, Infor, Epicor, Oracle, UNIT4, and QAD have also entered the land rush, although they are moving more slowly, as they need to pull wagons full of their traditional on-premises software along with them.

In the larger suite of enterprise applications, such as CRM and HCM, the land rush is further along. Salesforce for CRM and Workday for HCM have already staked out large claims and are rapidly developing them. But Microsoft with Dynamics CRM, SAP with SuccessFactors, and Oracle with its Fusion HCM are also adding to their acreage. Core ERP functionality, on the other hand, is earlier in the land rush. There is still a lot of open territory with a lot of unclaimed land.

FinancialForce Staking Its Claim

One provider that is clearly in the land rush is FinancialForce, which today announced new branding to signal its claim in cloud ERP.

The company is now referring to its suite of enterprise applications as FinancialForce ERP. The new branding is necessary
because FinancialForce long ago ceased to be a provider only of
financial management systems.

FinancialForce previously added professional
services automation to its portfolio and late last year acquired Less
Software, which provides inventory management and order. Vana
Workforce is another acquisition from last year, which adds human
capital management (HCM) functionality. FinancialForce also added its
own functionality in areas outside of financials, such as advanced
quoting and revenue recognition. With this broader footprint,
FinancialForce now qualifies as a cloud ERP provider.

Building on the
Salesforce.com platform, FinancialForce has direct integration to the
Salesforce cloud applications as well as to all of the other providers
in Salesforce's AppExchange marketplace. The recent evolution of this
platform to Salesforce1 gives FinancialForce additional capabilities for
building out its mobile deployment options.

How many acres will FinancialForce claim? The signs are hopeful. The company is
reporting strong results: 80% growth in its revenue run rate, and 62%
growth in headcount year-over-year, bringing it to over 260 employees
globally. FinancialForce now has customers in 27 countries with users
in 45 nations worldwide. By all accounts, the company is on a strong
growth trajectory.

Plenty of Land for Everyone

The economic and strategic benefits of cloud computing accrue to end-user organization that completely or at least largely eliminate their on-premises IT infrastructure. Our research at Computer Economics shows that cloud user companies save more than 15% in terms of their total IT spending, and the money that they do spend goes more toward innovation and less towards on-going support. But it is difficult to move away from on-premises infrastructure if an organization's core ERP system is still on-premises. Therefore, the move to cloud ERP is essential if organizations are to fully realize the benefits of cloud computing. You can move your CRM and HCM systems to the cloud--but if you are still running on-premises ERP, you still have one large foot stuck in the old paradigm.

In my view, there does not need to be one clear winner in cloud ERP. Just as there were dozens of on-premises ERP vendors in the 1990s, especially when sliced by industry sector, there is plenty of room for many more cloud ERP providers. There is plenty of land for everyone.

Monday, February 17, 2014

The US District court in Las Vegas issued a ruling in the Oracle vs. Rimini Street lawsuit last week. Oracle issued a press release on it this morning, pointing out the parts of the ruling in Oracle's favor, but did not provide a complete view. I've since received an actual copy of the Court's ruling and have had a chance to digest it.

I've contacted Rimini Street, and they indicate that a statement will be coming later today. I'll update this post when I receive that.

Summarizing the Court's Findings

The Court's rulings are complex, as is fitting in this case (full text here). Let me summarize them as I see them:

The Court's ruling is largely focused on Rimini Street's alleged copyright infringement of Oracle's PeopleSoft software in serving four customers:

"Oracle’s claim for copyright infringement, as it relates to the present motion, arises from Rimini’s copying of Oracle’s copyright protected PeopleSoft, J.D. Edwards, and Siebel-branded Enterprise Software programs on Rimini’s company systems in order to provide software support services to four separate customers: the City of Flint, Michigan (“City of Flint”); the school district of Pittsburgh, Pennsylvania (“Pittsburgh Public Schools”); Giant Cement Holding, Inc. (“Giant Cement”); and Novell, Inc. (“Novell”)."

Whether Rimini Street has the right to copy Oracle's software depends on the terms of the license agreements to these four companies.

In this action, it is undisputed that Rimini does not have its own software license from Oracle for any of the identified Enterprise Software programs copied on its systems. Instead, Rimini contends that Oracle’s software licensing agreements with the four customers at issue in this motion expressly authorize it to copy, keep, and maintain copies of the copyrighted software on its company systems and under its control in order to provide contracted software support services to those customers. .... As each customer’s software licensing agreement is different, the court must evaluate Rimini’s express license affirmative defenses separately for each customer at issue in this motion.

Concerning the City of Flint, the Court rules in Oracle's favor, that the City's license agreement with Oracle does not permit Rimini Street to maintain copies of Oracle's PeopleSoft software.

Based on the court’s rulings above, none of Rimini’s asserted license provisions (Sections 1.2(b), 1.2(c), or 14.2) expressly authorize Rimini’s copying of Oracle’s copyrighted PeopleSoft-branded software as a matter of law. Therefore, the court finds that Oracle is entitled to summary judgment on Rimini’s express license affirmative defense as it relates to the City of Flint, and the court shall grant Oracle’s motion accordingly.

Concerning Pittsburgh Public Schools, the Court rules in Oracle's favor, in regards to Rimini Street's copying of Oracle's PeopleSoft software.

Here, the court finds that the Pittsburgh Public Schools’ license contains language similar to the City of Flint’s license....

Based on the rulings above, the court finds that none of Rimini’s asserted license provisions (Sections 1.1, 1.2, or 10.2) expressly authorize Rimini’s copying of Oracle’s copyrighted PeopleSoft-branded software as a matter of law. Therefore, the court finds that Oracle is entitled to summary judgment on Rimini’s express license affirmative defense as it relates to the Pittsburgh Public Schools, and the court shall grant Oracle’s motion accordingly.

Concerning Giant Cement, the Court denied Oracle's request for summary judgment against Rimini Street, refusing to find that Rimini Street had used copies of Giant Cement's in ways conflicting with Oracle's license agreement for J.D. Edwards.

Based on this record, the court finds that there are disputed issues of materialfact as to whether Rimini’s use of the development environment associated with Giant Cement was for archival purposes or whether Rimini accessed the software’s source code. Accordingly, the court shall deny Oracle’s motion for summary judgment on Rimini’s express license affirmative defense as it relates to Giant Cement.

First, the court finds that the plain language of Section 2.1(iv) authorizes Novell to make archival, emergency backup, or disaster-recovery testing copies. Further, the court finds that the plain language of Section 2.1(viii) permits Novell to allow Rimini, or another third-party, to install the software for archival, emergency back-up, or disaster recovery purposes.

Therefore the court finds that Novell’s license allows for archival and/or back-up copies of the software on a third-party system. Accordingly, the court shall deny Oracle’s motion for summary judgment on Rimini’s express license affirmative defense as it relates to Novell.

The Court also ruled on Rimini Street's claim that Oracle's shipping of software to Rimini Street locations granted an "implied license" to Rimini Street. Here, the Court did not agree with Rimini Street's claim and granted Oracle's motion for summary judgment against Rimini Street.

In its affirmative defense, Rimini argues that for years Oracle shipped back-up copies of its customer’s software installation media to Rimini’s facilities with full knowledge that the installation media were not only being shipped to Rimini’s facilities, but that Rimini was using the installation media to create copies of the software on its own systems to provide support services to Oracle’s customers....

The court has reviewed the documents and pleadings on file in this matter and finds that the evidence before the court does not support Rimini’s affirmative defenses of implied license and consent of use....

First, other evidence before the court establishes that these back-up copies, although ultimately shipped to Rimini, were shipped after Oracle’s customers submitted requests to Oracle describing Rimini’s address as the customers’ “secondary offsite backup location.”...

Second, Rimini admits that the purpose behind the obfuscated shipping requests was to allow Rimini to create development environments to service Rimini’s customers without Oracle’s knowledge....

Additionally, there is no evidence that Oracle knew of Rimini’s use of the shipped installation media to create copies of the software on Rimini’s systems. Rimini admits that the shipping requests were designed so that Oracle would not know that Rimini was using these backup copies of the licensed software.

In a nutshell, although Oracle's press release does not mention the Court's refusal to grant summary judgment regarding Giant Cement and Novell, the Court's ruling is, in fact, largely in Oracle's favor. The Court granted summary judgment in the case of the City of Flint and Pittsburgh Public Schools, and in regards to Rimini's claims of "consent of use" and "implied license." At most, Rimini Street can only claim that there is no decision yet concerning Giant Cement and Novell.

[Update] Ruling Specifically Deals with Rimini-Hosted Environments

Rimini Street sent a letter to its customers today, outlining its position on the Court's ruling. In it, it points out that the legality of third-party maintenance is not at issue. Rather, the Court's ruling last week is specifically about how Rimini Street delivers those services--whether through hosting Oracle software on Rimini Street computers, or providing them directly to customers who maintain their own development environments:

This case is NOT about the legality of independent enterprise software support. Oracle agrees that it is legal for third parties to offer independent enterprise software support to Oracle licensees, and Oracle licensees have a legal right to purchase Rimini Street support services instead of Oracle annual support services. Competitive motivations aside, this case is primarily about the specific processes Rimini Street used to support a portion of its clients.

Rimini Street also points out that the terms and conditions of Oracle licenses have varied through the years and that the Court's ruling therefore does not apply to all of Rimini Street's customers that use Oracle software. In addition, Rimini Street stopped offering Rimini-hosted environments in 2012. Therefore, going forward, Rimini Street believes that its operations will comply with the Court's recent ruling.

What Does It Mean for Enterprise Software Customers?

For those hoping that this case would set a legal precedent for third-party maintenance services, the Court's ruling is not a positive development. The Court has essentially ruled that in two of the four customers in dispute, Oracle's license agreements did not give Rimini Street the rights to do what it did. Concerning the other two, the Court did not rule that Rimini Street had the rights, only that it declined to rule at this time, reserving a decision for a later point in the process.

It is too soon to tell whether Oracle will prevail at trial. But at this point, one thing is clear for customers: do not enter into a license agreement with a software vendor without ensuring that your rights to third party maintenance are explicit. As the Court's ruling last week shows, it all comes down to what rights you have in your license agreement. Sign the vendor's license agreement as-is and it's likely that your rights to third-party maintenance will be limited to having the third-party provider only able to work on your own installation of the software. [But see Update #3, below.]

Our research at Computer Economics shows widespread dissatisfaction with both the cost and the quality of service for the Tier I ERP vendors' maintenance programs. If there are not viable and healthy third-party maintenance providers in enterprise software, it will just hasten the demise of the traditional software license model.

In other words, Oracle may win the battle, but long term, lose the war.
Update: 12:30 p.m.PDT: Changed concluding section to point out that limitation is on where the software is installed.Update: 1:00 p.m. PDT: Added section on Rimini Street's customer letter.Update: 2:30 p.m. PDT. In a briefing with Rimini Street, CEO Seth Ravin insists that this particular court ruling
does not impact Rimini Street's ability to deliver maintenance services, as it is
already moving all PeopleSoft customers to client self-hosting.Update: 2:50 p.m. PDT. Dennis Howlett has a good breakdown of the court ruling, with additional perspective from Rimini Street.

Thursday, February 13, 2014

What Is Innovation? An Expansive View

On the business conference circuit today, innovation has become a buzzword. It's too bad, because organizations today need to innovate as much, if not more, than ever before. So, instead of abandoning the word, let's try to recover it.

When thinking about innovation, business leaders often set the bar too high for themselves. They hear about new technologies coming out of Silicon Valley and other tech hubs around the world and they equate that with innovation. Surely, new technologies are innovations. But I would argue that view is too narrow, and what executives need is a more expansive view of innovation. Furthermore, too much focus on technology can actually lead to a lack of real innovation.

Innovation Is Something New--For You

According to Merriam-Webster, the word innovation has two meanings. First, it is "a new idea, device, or method." This generally fits the common understanding of innovation. But the second definition is, "the act or process of introducing new ideas, devices, or methods." The first definition is the new thing itself, while the second definition is the introduction of that new thing.

Smartphones were an innovation. But the introduction of smartphones into, say, your expense reporting process, is also an innovation. In business, innovation does not just mean that you invent something new. Innovation means that you introduce a new invention into your organization.

I would take it a step further. Innovation does not just mean you do something that no one has ever done before. Innovation means you do something that you have never done before. Others may have introduced smartphones into their expense reporting process. That was innovation for them. But when you introduce them into your expense reporting process, that is innovation for you.

A few years ago, I was working as a strategy consultant to a large high tech manufacturer that wanted to "transform the customer experience." The goal was to come up with a three to five year plan of strategic initiatives, in which new technology would play a starring role. Over a period of weeks, the project team came up with a long list of ideas, such as building a customer-facing knowledge base, new mobile apps for field service engineers, and big data analytics.

But some team members were concerned that none of our ideas were "far out" enough, that top management would think we had failed to be "innovative." At one point, a team member joked about coming up with a “hologram” of a service agent, which the customer in the field could conjur up, like a spirit.

Of course, in brainstorming, no idea is too far out. But that doesn’t mean that innovation is only in far out ideas. As it turns out, the project team had many good ideas, including leveraging the company’s smart products in the field as a platform for customer service. Were other companies already doing this? Yes. But this company had not fully exploited these opportunities. Rather than worry that their ideas were not “innovative” enough, this company would be better served by actually implementing the ideas they already had. In other words, it was not a matter of inventing a new technology but of introducing a new technology to their business.

Business Process Innovation

Second, innovation is not a synonym for technology. The innovations that many organizations need today are not new technologies, but the application of available technologies to their business processes. The goal should be to simplify a process--or even better, eliminate the process.

For example, again, in customer service, what if customers could serve themselves? Or, what if customers could serve each other? The technology for customer self-service and for customer communities is now widely available from commercial software vendors. Innovation is no longer a matter of writing customer self-service applications or community platforms. The innovation today is to introduce those technologies into a specific organization.

Of course, at some point, introduction of a technology becomes so commonplace that it can no longer be considered an innovation, even if it is new for you. If you are just now getting around to using a personal computer, instead of index cards, to track your inventory, it would be hard to say you are innovating.

Nevertheless, many organizations do not focus enough on business process innovation. Even when they introduce new technologies they do not spend sufficient time ensuring that they change their business processes. The customer self-service system is installed, but service engineers do not spend time to populate the knowledge base behind it. The community platform is installed, but no one invests the time to nurture a community. The computerized inventory system is in place, but when the materials manager wants to check on-hand inventory he walks out the the warehouse, because he doesn't trust the system. In many cases, the technology does not lead to innovation because there is no business process change.

Business Model Innovation

Innovation becomes even more powerful when it means introduction of something new in the organization’s products or services. This goes beyond business process innovation to innovation in how the organization makes money. Or, in the case of a public sector organization, how it delivers its services and fulfills its charter.

Business model innovation certainly can involve introduction of a new technology. For example, Uber's business model is heavily dependent on mobile apps to match drivers with riders who are physically near by one another. Here the mobile apps do not make money directly but enable the business model.

Caterpillar is another example. Sensors built into Cat's equipment have opened up a whole new way for the company to make money by offering job site services, such as controlling compaction of soil and asphalt. Caterpillar is no longer just selling heavy equipment and maintenance contracts. The innovation is not just in the sensor technology but in the business model that it enables.

Innovation should not be a buzzword. Business leaders should take an expansive view of what innovation means for their organizations and think beyond technology to business process and business model innovation.

Thursday, February 06, 2014

Enterprise Software: Suites Don't Always Win

The major enterprise software providers promote their pre-built integration as a selling point in capturing new business from existing clients. They argue that, rather than attempting to integrate different systems from different providers, organizations should buy everything from a single provider and get the integration for free.

Why the Integration Story is Getting Old

But do suites always win? In my software vendor evaluation work, I've noticed that the integration story is not resonating with buyers as it once did. I think there are several reasons for this.

Vendor suites may not be as well integrated as vendors claim. This is especially true when the vendor's suite comprises pieces that they acquired. Both Oracle and SAP have made many acquisitions over the past decade. Is the integration of these piece parts really seamless? In some cases, yes. But in many cases, no.

Integration an IT-priority, not a business priority. Many software selection projects these days are being led by business users. This has always been desirable, but it is especially true when you get outside of core ERP to systems such as CRM, supply chain management (SCM), and human capital management (HCM). IT leaders generally put a high priority on integration because it makes their job easier (notwithstanding point #1). Therefore, when IT leads the vendor selection effort, integration rises near the top of the selection criteria. When business units lead the selection, they tend to rank process alignment, ease of use, and maximizing adoption higher than they do integration with back-end systems. Whether rightly or wrongly, business leaders often say to IT: we want System X--make it work.

Integration has gotten a lot easier. The integrated suite story was more convincing 20 or even 10 years ago, when the choices for integration were either brittle point-to-point flat file interfaces or complex middleware or integration hubs that required substantial investment before the first integration could be built. Today, application programming interfaces (APIs) and web services make integration a lot easier than it used to be in the past. SaaS providers, in particular, have gotten very good at integrating with other systems, whether cloud or on-premises, as this is a common requirement among their customers. So, the problem has gotten smaller.

Not all integration points are equally critical. In a recent CRM selection, the incumbent ERP vendor made the claim that there were something like 300 integration points between the vendor's ERP and CRM systems. Did the buyer really want to program all these touch points between ERP and some third-party CRM provider? It's a good sales pitch. But when we investigated further, we found that there were really only a handful of integration points that really mattered to this customer. For example, if pricing only changes once a year, is it really necessary to have the CRM pricing tables automatically updated from the ERP pricing tables? Investigate your real needs for integration and often you will find they are much less than your incumbent vendor will claim.

In addition, think about the benefits of not having all of your enterprise system "eggs" in one basket. True, there are benefits to having fewer vendors in your applications portfolio. At the same time, it is possible to have too few--to grant too much power to a single vendor. Behind closed doors, suite vendors talk about how much "share of wallet" they have among their customers. But is it in your best interest to have so much of your IT spending wrapped up with a single provider?

Situations Where Integration Is a High Priority

To be sure, there are situations where integration should be a high priority. I would not like to see an organization pick an accounts payable module from one vendor and a purchasing module from another. These functions are too tightly coupled. Furthermore, purchasing and accounts payable are generally not systems of strategic advantage. Customers are better off buying them from a single ERP vendor, implement them, and move on to more strategic opportunities.

Likewise, in supply chain management, I don't like to see sales and operations planning, advanced planning, and event management selected from different vendors. These functions form a closed loop with a single data model. Material planners need to be able to perform these functions simultaneously in parallel. Building interfaces to cascade information from one system to another is simply too cumbersome.

Criteria for Evaluating Integration Needs

I don't expect that the large integrated suite vendors will change their message. For them, suites always win. But for buyers, I recommend a broader perspective.

Is the system you are looking for one that must be integrated with other systems in your portfolio?

If so, can you verify that your incumbent vendor has really integrated those two systems?

How many integration points are really needed, and how many are nice-to-haves that could be satisfied with a simple work around?

For those that need automated integration, how difficult would it be for another vendor to provide that integration?

Do third party vendors have references that have done that same integration with other customers?

Do the benefits of a third-party vendor in terms of adoption, ease-of-use, and competitive advantage outweigh the benefits of pre-built integration?

Finally, is the system you are looking for one where innovation, competitive advantage, ease of use, and high adoption are top priorities? If so, the best choice may not be from your incumbent provider. The fact that the large Tier I suite vendors have been acquiring smaller best-of-breed providers is evidence that leading edge innovation is happening outside of the integrated suites.

Customers should think through the answers to these questions and make the right decisions for their businesses. If they do so, many times, suites won't win.

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision.
My consulting firm, Strativa, offers assistance that is independent and unbiased.
For information on how we can help your organization make and carry out these decisions, write to me.

My IT research firm, Computer Economics provides metrics for IT management, such as IT spending and staffing benchmarks, technology adoption and investment trends, IT management best practices, IT salaries, outsourcing statistics, and more.