Three Decades of Software Vendor Selection

This post continues my series on lessons learned in my career. Chronologically, we left off with my work on a major system development project at Smith Tool. By the time I finished, I had been an independent consultant for about six years. But during that time, I also began to branch out to other clients. These included travelling around the US and beyond, doing mainframe conversion training, 4GL software development, and other consulting engagements.

All these clients had one thing in common. They all came directly or indirectly by referrals from former coworkers at Smith. As it turns out, I was lucky. When a sole proprietor, like me at this time, is busy with project work, it is difficult to develop new opportunities. And when a project ends, it is not easy to develop a new opportunity on short notice. Those independent consultants I know who have been successful over many years generally have reputations as experts. They also tend to have multiple revenue streams in addition to their consulting work, such as paid speaking engagements, books, or paid media contributions. Balancing project work with business development is easier for a consulting firm with some scale, something I would learn later in my career.

But in 1989, there was still one more referral for me. A former coworker from Smith Tool, Rick McGough, had just been hired as the top IT executive for Toshiba America Medical Systems (TAMS) [1]. TAMS was the U.S. distribution and field services unit for Toshiba’s medical diagnostic imaging device business [2]. Rick was looking to replace a homegrown business management system with a commercial ERP system. TAMS already had two Deloitte consultants on the project [3], but Rick wanted “his own guy” on the project team as well. So, he brought me in. This would my first real exposure to a full-blown ERP selection project, and this was the basis for my continuing this type of work over the following three decades, evaluating and selecting all manner of software, including ERP, but CRM, HCM, supply chain, and other categories of enterprise systems.

Lesson #1: Focus on Differentiators

The Deloitte consultants had recycled a requirements document of several hundred pages from a previous client and attempted to modify it for use at Toshiba. This turned out not to be a great approach, as the document included a number of requirements that didn’t apply to TAMS, and it missed several important requirements.

One key requirement was serial number tracking, which is an FDA regulatory mandate. Each unit of equipment and even critical components within a finished assembly need to be tracked with a unique identifier. So, if Toshiba receives 10 X-ray tubes from Japan, it’s not enough just to record a receipt of 10 units. It must record the serial numbers of those 10 units and track them in inventory and through distribution to the installed customer base. But guess what. The system that the team ultimately chose (BPCS from System Software Associates, or SSA) did not have serial number tracking. It did have lot number tracking, and the reseller’s proposed solution was to use the lot number as the serial number and modify the source code to force a lot quantity of one. They also had to do a modification to the inventory receipt program to allow the data entry user to enter the individual serial numbers at time of receipt. As you can imagine, there were other modifications needed for inventory management, sales, and distribution to accommodate the “lot number as serial number modification.”

To make a long story short, this was an example of a requirement that was so important that it normally should have disqualified that vendor from consideration [4]. I now call these types of requirements “differentiators.” They are more than priority A. They are show-stoppers. As a result, BPCS did not last long at Toshiba. It was replaced a few years later by Oracle Applications (today, E-Business Suite), which could satisfy the serial number tracking requirement as well as other differentiators.

Based on this lesson learned, I made a practice of identifying five to 10 differentiators for the client. I would use that to qualify vendors for the initial short list. In developing a short list, you really don’t need an RFP with hundreds or thousands of requirements. But you do need to know these key criteria. You can specify additional requirements (though I recommend avoiding hundreds) later in the selection process. Over the years, I had other experiences where the client made a vendor selection decision without following this best practice [5].

Lesson #2: If You Must Modify, Do It with Bolt-on Modifications

Another concept I developed during this project was the difference between good modifications and bad modifications. I recall standing at a whiteboard, discussing this with the Deloitte consultants. I told them we should avoid customizing vendor source code. The reason is that it may disrupt the logical integrity of the system—it may break the system in unanticipated ways. Second, it makes it difficult to upgrade to new releases of the software, because all those customizations will need to be carried forward to the new version.

Instead of customizing the vendor’s source code, I said that we should develop what I called “bolt-on modifications.” I drew a diagram on the white board, showing the modifications as a separate program or subsystem external to the vendor’s code, and calling it by means of an API. This approach is common today in what is known as a service-oriented, modular, or composable architecture [6].

Sadly, the modification to the lot number logic I mentioned in the previous lesson could not be accomplished with a bolt-on modification. It required modification of the core source code. As a result, it took the project team six months shortly after the initial implementation to do an upgrade to the next version.

Lesson #3: ERP Can Be Hard to Justify with Tangible Benefits

An ERP implementation is a major expenditure, and as such it would need management approval in the form of a capital expenditure request, which would need to budget both the costs and the anticipated benefits. The cost side of the equation is usually easy—hardware, software, and implementation costs could all be estimated based on vendor proposals.

The benefits side, however, is more difficult, especially if you want to identify tangible benefits. The project team for improvements in inventory accuracy, order fill rates, customer service improvements, and other areas. Time and again, we would identify a possible improvement but would conclude, “it doesn’t move the needle” [7]. Later in my career, our research at Computer Economics confirmed this finding [8].

When there are tangible benefits, they are mostly in two areas:

• Productivity savings. If the organization required 15 accounts payable personnel and the new system could cut that number to 10, that would be a productivity improvement. But few organizations really want to bank on that—they hate to lay off people. They would rather redeploy them into other roles. Or, they would rather say that the new system could allow future growth without adding to administrative headcount.
• Discontinuation of legacy systems. If the new system is replacing an old system—and preferably several old systems, there will be savings in the hardware, software, and personnel that supported the old system. If the system was highly modified, the new system might require fewer personnel, although this is often not the case, especially in the early years.

Therefore, in selection projects over the years, I’ve concluded that ERP benefits are mostly intangible—difficult to put a dollar value on. If done right, they give management better data to support decision-making, and they provide a single source of truth. Most importantly, they provide a better platform for future systems that rely on ERP data, such as business intelligence. There are also other more strategic drivers: the old system might no longer be supported by the vendor, or it might be on a legacy hardware platform. I’ve seen more situations where this was the driving force for a system replacement than I have with a business case based on tangible benefits [9].

Lesson #4: Software Selection Is More Than Selecting Software

But the greatest lesson learned from this first selection project and over the following three decades is that software selection projects are really mis-named. They are not just about selecting software—they are about business transformation. As such, there are some key success factors:

• Business sponsorship. Just because computers are involved does not make these projects computer projects. They should be driven by the business, with the IT organization as part of the project team. Top management should actively sponsor the project and not delegate it to middle management.
• Strategic alignment. Many ERP selections arise from organizations changing their business model, acquiring new lines of business, or expanding into new markets. To provide context, ERP selection should start with a review of the current and future business strategy and how IT is aligned to support it.
• Application portfolio rationalization. Many clients have dozens of enterprise systems, and many of them are inter-connected. When replacing a major system, should those other systems stay or go? Most organizations would do well to first address the entire portfolio of applications and lay out a strategic road map to understand which should be replaced or consolidated.
• IT organizational impact. Does the current IT organization have the needed skills to support the future applications road map, including the new system? If not, what new skills are needed and how should the IT staff be organized?
• System integrator selection. Selecting the new software is not the only decision. Most organizations will need to select an ERP implementation partner. Having the right ERP system but the wrong implementation partner often leads to failure. In fact, some of my projects over the next 30+ years involved finding a new implementation partner to replace the one that failed.
• Client-side planning. Generally, the system integrator will have a good handle on what it needs to do. But the client’s project team must also plan for the activities required on the client side, such as training, data conversion, procedure writing, and acceptance testing. The system integrator will generally expect the client to be responsible for these activities.
• Business process improvement. New systems can involve major changes in business processes--hopefully for the better. The selection team should also anticipate what business process improvement will be needed as part of the new system and include those in the project plan.
• Change management. Enterprise software implementations rarely fail because of technology problems (though, it does happen). They often fail because of organizational resistance to change. Engaging the organization during new system selection is how you gain buy in for the decision, setting the stage for cooperation during the implementation.

Further Industry Specialization

I look back at my experience with Toshiba as a major steppingstone in my career. As was my habit, once again, I immersed myself in the business—in this case medical devices. I interviewed business leaders and studied the various imaging system modalities, such as X-ray, MRI, CT, and ultrasound. Short term, this enabled me to continue consulting for Toshiba on the business side after the implementation was finished. I moved into the customer service group, defining requirements for future field service systems. Longer term, my experience at Toshiba became a foundation for my later industry focus on medical devices and life sciences in general, including FDA regulatory compliance.

Photo credit: Frank Scavo.   

End Notes

[1] Rick had had been hired at Smith Tool as a programmer analyst in 1978, about the same time I was. But whereas I took a career path to get deeper into the business, eventually leaving the IT department, Rick chose an IT management path. He rose through the ranks eventually becoming the IT director. As noted in an earlier post, the 1980s were a tumultuous time for Smith, and in 1989 Rick left to take the top IT job at Toshiba. He is now retired after holding several senior IT positions at other firms.

[2] Toshiba Medical was acquired by Canon in 2016 and is now Canon Medical Systems Corp. The US headquarters is still located just a few miles from where we lived at the time.

[3] One of those two Deloitte consultants was John Olszewski. John became a good friend, and we worked together on and off for something like six to eight years for other clients. He continued with Toshiba long after my work there was completed. He eventually played a leading role in replacing BPCS with Oracle Applications. With that experience, he then went to work for Oracle, where he is now Senior Director E-Business Suite Service Product Management.

[4] There was one key requirement that tipped the scales in favor of BPCS and that was its ability to specify sales features and options in a multi-level planning bill of material. None of the other systems on our short list, which Toshiba had restricted to IBM midrange systems, could satisfy that requirement.

[5] Several years later, I had another client where the chosen vendor did not satisfy a show-stopper. Coincidentally, John Olszewski and I worked together on this project. We came in after the vendor selection to help with the implementation. Here the client was a well-known multi-level marketing (MLM) company. In this industry, customers (i.e., independent distributors) would deposit cash into their accounts against which they would place orders for their customers. The MLM company would then fulfill those orders. In other words, the independent distributors had to pay in advance. But the chosen system was a typical B2B system. It assumed the independent distributor would place an order, and then the MLM company would fulfill it, invoice the distributor, collect the payment, and apply it to the invoice. As a result, we had to modify the system to accommodate this fundamental process misalignment. In retrospect, this system should have been dropped from consideration just based on this one showstopper.

[6] The term “bolt-on modification” is in common use today, but I am convinced that I invented the term. I have searched and have not been able to find a reference to the use of this metaphor prior to 1989. Yes, it was used in the automotive industry, but I can’t find anyone using it relative to software engineering. If anyone can find it, I will be happy to give up my claim. But until then, I am claiming authorship.

[7] As in the previous note, I’m convinced that I coined the phrase, “it doesn’t move the needle.” In trying to come up with the business case, I used it as shorthand for, “Yes, that may be a benefit, but it is too small to really make a difference.” I had in mind an automobile fuel gage where adding a small amount of fuel would not be enough to make the needle move. Again, I have not been able to find use of this term as a metaphor prior to 1989. But I’m willing to see evidence otherwise.

[8] Our research at Computer Economics (now part of Avasant) over the years compared the ROI and TCO experience of a number of IT investments. We found consistently that ERP ranked dead last in economic success. We argue that this does not mean organizations should not invest in ERP, but rather that the benefits on the one hand can be difficult to quantify and that the costs need to be carefully controlled to stay within budget.

[9] What about growth in revenue? In my experience, it is difficult to claim top line benefits from ERP systems, which are mainly focused on back office processes. If a new ERP system is needed to support a new line of business, there would be top line benefits, of course, but the contribution of ERP is indirectly tied to that outcome. CRM systems on the other hand might be justified in terms of improved customer service, improved upsell/cross-sell performance and other measures that increase revenue. 

Deploying Low-Latency Applications in the Cloud

Cloud has become the preferred deployment option for most categories of enterprise systems. But conventional wisdom is that some systems that require low latency and a high degree of system availability, such as warehouse management systems (WMS) or manufacturing execution systems (MES), are best deployed on-premises.

The argument is that response time over the Internet is never as fast as over a local area network and that such systems cannot tolerate any level of unscheduled downtime inherent in using a cloud application. 

Nevertheless, cloud systems are invading even this category of software. Although still in the minority, there are some vendors providing such low-latency applications as a cloud service. 

One example is Plex Systems.  And, interestingly, it is not a new example. 

Read the rest of this post on the Avasant website: Deploying Low-Latency Applications in the Cloud.  

Getting ERP Users to Upgrade—Cloud vs. Traditional Systems

One of the great challenges facing traditional ERP vendors is getting customers to keep up with the latest version. Cloud ERP systems are supposed to solve this problem, by making the vendor responsible for upgrades and keeping all customers on a single version.

However, sometimes, even SaaS providers need to make changes that are so significant and potentially disruptive that customers resist the change.

Read the rest of this post on the Strativa blog: Getting ERP Users to Upgrade—Cloud vs. Traditional Systems

Why Is Open Source Not More Successful for Enterprise Applications?

Although open source software now completely dominates some categories of software, this has not been true for enterprise applications, such as ERP or CRM. What is it about enterprise applications that makes them so resistant to open source as a business model? 

My friend and fellow-analyst Holger Mueller has a good post on Why Open Source Has Won, and Will Keep Winning.  Read the whole thing. In Holger's view, which I agree with, the battle between open source and propriety software is over, and open source won. In just a short fifteen years or so, it is hard to find any commercial software vendor attempting to build new platforms based on proprietary code. He writes:

Somewhere in the early 2000s, Oracle dropped its multi-year, 1000+ FTE effort of an application server… to use Apache going forward… that was my eye opener as a product developer. My eye opener as an analyst was in 2013, when IBM’s Danny Sabbah shared that IBM was basing its next generation PaaS, BlueMix, on CloudFoundry… so, when enterprise software giants cannot afford to out-innovate open source platforms, it was clear that open source war-winning. As of today, there is no 1000+ people engineering effort for platform software that has started (and made public) built inhouse and proprietary by any vendor. The largest inhouse projects that are happening now in enterprises, the NFV projects at the Telco’s, are all based on open source.

Holger's observation is certainly true for software at the platform or infrastructure level of the technology stack. All the examples that Holger cites, and nearly any other that he could cite, are in these categories.

But what about enterprise business applications, such as ERP or CRM. One of the best examples is SugarCRM, but even there, it lags far behind the market leaders. Open source ERP is in even worse shape. Players such as Compiere (now owned by Consona), Adempiere (a fork of Compiere), Opentaps (an ERP and CRM system), xTuple (formerly, OpenMFG), and Odoo (formerly, OpenERP) barely move the needle in terms of market share. Where is the Linux of ERP?

Since the early 2000s, I have been hoping that open source would catch on as an alternative to the major enterprise apps vendors, such as SAP, Oracle, Microsoft, Infor, and others. I would like to see open source as a counterweight to the major vendors, putting more market power on the side of buyers. 

So, why hasn't open source been more of a contender in enterprise applications?  I can think of three factors, for a start.

1. Open source needs a large set of potential users. But enterprise applications do not have as broad a potential user base as infrastructure software. Although the ERP market is huge, when you break it down by specific industries, it is small compared to the market for, say, Linux.
    
2. Enterprise apps require a large effort in marketing and sales. Buyers put great weight on name recognition. But open source projects do not generally show much interest in the sales and marketing side of a business. If a project is truly community-developed, who is interested in marketing it? As a result, very few people know what Odoo is, for example, let alone, how to acquire it.
    
3. Open source is labor-intensive. It is great for organizations that have time but no money. My impression is that open source ERP adoption is somewhat more successful in some developing countries, where there are very smart people with good technical skills willing to spend the time to implement a low-cost or no-cost solution. Here in the U.S., such companies are rare. Most would rather write a check. 

Ironically, open source is very popular among enterprise application providers themselves. Software vendors, whether cloud or on-premises providers, love open source and many now build nearly all of their systems on it, because it scales economically. Yet, when they sell their own enterprise applications, the last thing they want to do is offer them as open source.

So, why hasn't open source been more successful for enterprise applications? Perhaps readers can come up with other reasons. Please leave a comment on this post, or tweet me (@fscavo), or email me (my email is in the right hand column).

---

Update, Jan. 18: My friend Josh Greenbaum has posted a lengthy response on his blog, here: Open Source, Enterprise Software, and Free Lumber. Please read the whole thing, as it is quite thoughtful.

Josh agrees that open source software (OSS) has been more successful for infrastructure components than for enterprise applications. But he goes off in a different direction to argue that it's not right for commercial software vendors to make money from their use of OSS. I have two basic disagreements with Josh on this point. First, most OSS licenses (GNU, for example) mandate that creation of software incorporating the OSS must be provided under the same OSS license. So commercial software providers go to great lengths to ensure that their developers do NOT incorporate OSS into their software products. Now, OSS providers CAN incorporate OSS in their own operations (e.g. use of Linux or MariaDB in their provision of cloud services), and they can include OSS as a supported platform.. In both cases they are not violating the terms of the OSS license.

My second disagreement is that Josh objects to OSS on what I consider to be more or less moral grounds, that it is wrong for others to make money from the free contributions of others (a "sucker's game," he calls it). Putting aside the fact that commercial software providers (think, IBM, Microsoft, Facebook, Google, and hundreds of others) are the largest contributors by far to OSS, no one is holding a gun to the head of any individual developer forcing him or her to work for free. If OSS contributors find it acceptable for others to make free use of their labors, who am I to say that it is wrong for others to do so? The fact that OSS has been wildly successful (at least for infrastructure-like components) tells us that there must be something in the economic model of open source that works to benefit both contributors and users of OSS.

Update, Jan 18: Some email correspondence from my friend Vinnie Mirchandani, led me to send this email reply, lightly edited here:

Yes, the large tech vendors, such as Google, Microsoft, IBM, etc., have benefited enormously from open source, but they also contribute enormously to open source projects, because it is in their best interest to do so. You know that IBM contributed key IP from its decades-old work in virtualization. Microsoft open sourced Visual Studios Code, and it is now one of the most widely-adopted development environment. Oracle, IBM, and others contribute to Linux because it ensures that it runs on and is optimized for their hardware. They all contribute because it is in their self interest to do so. Moreover, senior open source developers, especially those who have commit-privileges, are in high demand and are often hired by these same large tech companies. So the whole open source movement has become a virtuous ecosystem where everyone benefits.

Update, Jan 19: Over at Diginomica, Dennis Howlett riffs on our discussion in, Why you should take notice of the open source in enterprise suckers conundrum. On my question of why open source has not been more successful in enterprise applications, he points to the lack of real marketing and sales efforts. He writes:

I’d go one step further and as a nuanced view of Frank’s (2) element. In most cases, enterprise software is sold, it’s not bought. What I mean is that troupes of vendor reps, marketers and other hangers on line up to convince you about taking on one or other solution. In the open source world you are ‘buying’ not being sold. There is no real money for marketing and sales. You either take it (for free) and then work on it yourself, or you enlist the help of specialists who both understand your processes and the software code itself. And despite the early success of Salesforce as a cloud vendor from whom you bought applications at the departmental level on your credit card, the majority of enterprise deals are sold.

Strategies for Dealing with Legacy Systems

Developing an IT strategy for some organizations can be difficult because of the presence of a legacy system. Legacy systems that are old, out-of-date, and difficult to maintain are a huge obstacle to innovation. As a result, business leaders become increasingly frustrated by their inability to roll out new mobile apps, connect with customers, analyze business performance, or become a digital business.

In recent years, it has become popular to describe organizations with an out-of-date legacy system as being in “technical debt.” I would take this a step further. If an organization ignores the need to update the system for too long, it can lead to what I refer to as “technical bankruptcy.”

We can define technical bankruptcy as a situation where the organization cannot, or finds it exceedingly difficult to, pay off the technical debt. It does not mean that the organization is in financial bankruptcy but rather that its systems are broken or held together in a way that makes them extremely difficult to upgrade.

Significant Percentage of Organizations Are at Risk of Technical Bankruptcy

In work with our clients at Strativa over the past several years, we have gained new insights into challenges facing organizations that have out-of-date legacy systems. We recently took the opportunity to combine those insights with survey data from our sister IT research firm, Computer Economics, to produce a new report, Avoiding Technical Bankruptcy in Legacy Systems. (Click the link to download the report free from the Strativa website.)

Figure 3 from the full report shows the magnitude of the problem as it applies to ERP systems. A small but significant percentage (7%) of organization have not upgraded their ERP systems for 10 or more years. These are likely to already be in technical bankruptcy. But the 13% of organizations that have not upgraded their systems in the five-to-nine-year time frame are in the danger zone: Technical debt is building, and if the organization does not undertake a major upgrade, it risks falling into technical bankruptcy.

Signs of Technical Bankruptcy

What are typical signs that a legacy system has reached the stage of technical bankruptcy? We found five characteristics:

• Extensive modifications, extensions, and interfaces.
• Poor understanding of the system by users and IT alike
• Direct involvement of IT personnel in business processes.
• Legacy system atrophy as shadow IT emerges.
• Upgrade or replacement hard to justify.

In the full report, we explore the symptoms of technical bankruptcy and the devastating effects that it has on the organization. We continue by quantifying the scope of the problem specifically for ERP systems, using our research on the typical age, frequency of upgrades, and extent of modification of these systems.

Most importantly, we conclude with recommendations on how to avoid technical bankruptcy and, for organizations that have reached this stage, strategies for getting out and staying out of technical bankruptcy going forward.  

Download the full report, free from the Strativa website:
IT Strategies for Legacy Systems: Avoiding Technical Bankruptcy.
 

---

Bonus: Watch a Datamation's James McGuire in a video interview with me about the report.

Manufacturing Is a Huge Opportunity for Cloud ERP

In many markets for enterprise software, the battle between cloud and on-premises (or hosted) systems is over. Salesforce, the market leader in CRM, will soon pass the $10 billion mark in annual revenue. Workday, with its cloud HCM offering and growing financial management applications, expects to hit the $2 billion mark in 2018. Traditional Tier I providers, SAP and Oracle, are certainly not out of the race. But the only way they have been able to compete is by building, or buying, their own cloud services for CRM and HCM. Cloud has won.

Nevertheless, there is no cloud ERP provider the size of Salesforce or Workday, and there is certainly no cloud ERP provider for the manufacturing industry with that scale. NetSuite was founded in 1998, around the same time as Salesforce. But it only reached the $741 million revenue mark in 2015, before being acquired by Oracle. Claiming more than 30,000 companies, organizations, and subsidiaries in more than 100 countries as customers, it is by far the largest cloud ERP provider. Although it has done very well with professional services firms, software companies, and other services-related businesses, manufacturing companies form only a small part of that number. Plex Systems has a pure cloud ERP system for manufacturers dating from 2000 and has been rapidly growing over the past four or five years. But its customer count is under 600. After NetSuite and Plex, the number falls significantly: Cloud-only systems such as SAP’s Business ByDesign, Rootstock, and Kenandy,  each have even fewer manufacturing customers.

To understand how great the market opportunity is for cloud ERP in manufacturing, consider that, according to the U.S. Census, there were about 63,000 manufacturing firms in the United States in 2014 with 20 or more employees, as shown in Figure 1. Considering that the estimated customer counts by vendor in the preceding paragraph include customers outside of the U.S.,  it is safe to say that manufacturing cloud ERP probably has less than 2% market share in the U.S. The market opportunity going forward, therefore, is enormous.

Read the rest of this post on the Strativa blog: Manufacturing Is a Huge Opportunity for Cloud ERP

Software Vendor Implementation Services Not Always Best Choice

In our software selection consulting, clients often seek our advice on implementation partners. In fact, our experience over several decades tells us that the choice of an implementation team is as important, sometimes more important, than the choice of a new system.

In choosing an implementation consulting group, clients often start out thinking that it’s best to choose the vendor’s own professional services group. They think that no one can know the software as well as the vendor’s own personnel. They think that when problems arise, the vendor’s consultants will be in a better position to deal with the software vendor. They also think that there will be less finger-pointing: the consultants blaming the vendor, or the vendor blaming the consultants.

These considerations have merit. But there are other factors to consider, factors that may make an implementation partner, or even an independent consulting firm, a better choice.

Read the rest of this post on the Strativa blog:
Software Vendor Implementation Services Not Always Best Choice.

New Customer-Facing Systems Extend the Reach of Small, Midsize Businesses

Small businesses play a vital role in the economy and are often the leading innovators in new products and services. According to the U.S. Census Bureau, organizations with fewer than 500 workers account for over 99% of businesses, and companies with fewer than 20 workers make up nearly 90%.

But small business doesn’t always mean simple business. Like larger companies, small and midsize businesses (SMBs) need to reach new markets, develop new products, satisfy customers, and control costs. The main difference is that SMBs need to do these things with fewer resources.

In recent years, however, software vendors have announced new products to address the challenges facing small businesses. This post outlines two of them.

Read the rest of this post by Strativa consultant Dee Long: New Customer-Facing Systems Extend the Reach of Small, Midsize Businesses

The Growing Circle of Cloud ERP

Traditional providers of ERP systems typically sought to expand their functional footprint to include complementary applications outside of core ERP. Now cloud ERP vendors are adopting a similar strategy, bringing significant benefits to buyers.

For most companies, an ERP system is generally at the center of the business systems strategy. But a comprehensive applications portfolio includes much more than ERP. Most companies, even small and midsize businesses, have a surprising number of important systems outside of ERP.

By way of example, Figure 1 shows our proposed future applications landscape for a current client of my consulting firm, Strativa. (Company-specific references are removed). Although just a midsize company, it has plants and distribution centers around the world. As a result, the future applications portfolio will be quite extensive. At the core, within the red circle are the core ERP functions. Outside the circle are other enterprise system
s that must interact with the core ERP system. Nearly all of these systems will be new, or replacements of current systems.

Read the rest of this post on the Strativa blog: The Growing Circle of Cloud ERP

Oracle Acquisition of NetSuite Is a Mixed Bag

Oracle took another step in its strategy of growth by acquisition by announcing a bid for NetSuite, the leading player in the cloud ERP marketplace in terms of number of customers. At $9.3 billion, the deal is the second biggest in Oracle’s history, after PeopleSoft in 2005 for $10.3 billion.

The deal was long expected, for several reasons. Oracle Chairman Larry Ellison was NetSuite’s original investor, and Evan Goldberg, NetSuite’s founder came out of Oracle. CEO Zach Nelson was an Oracle marketing executive. Oracle’s database is an integral part of NetSuite’s infrastructure.

But apart from helping Oracle in its race with Salesforce.com to get to $10 billion in cloud revenues, what are the benefits of the deal to Oracle? How does it help NetSuite, and what does it mean to the broader marketplace? Looking at the big picture, there are certainly benefits, but there are also several concerns.

Read the rest of this post on the Strativa blog: Oracle Acquisition of NetSuite Is a Mixed Bag

The Role of Fear in ERP Implementation

Photo Credit

One of Deming’s 14 points for management was, “Drive out fear, so that everyone may work effectively for the company.” By this he meant that employees should not be afraid to point out problems, provide feedback, or make mistakes in an effort to improve. Business leaders should engage employees positively in continuous improvement.

But when it comes to business leaders themselves, fear can be a powerful motivator. And, nowhere is a healthy fear more needed than in ERP implementation.

It is difficult to think of a major project that is riskier for an organization than an ERP implementation. It ranks right up there with a major strategic merger or acquisition in terms of potential to disrupt the business. This is because an ERP implementation touches nearly every function of the business, nearly every business process, and nearly every employee. Although ERP systems involve computers, they are not IT projects: they are business change initiatives. Do it wrong, and you may find yourself as a case study on the front page of the Wall Street Journal.

Hopes and Fears

I recently co-led a half-day workshop for a large client in the manufacturing industry that is about to embark on a wholesale replacement of their aging ERP system. The participants were 18 of the firm’s business leaders. We covered the history and role of ERP, reasons for failure, lessons learned from successful implementations, typical processes most in need of improvement, and the roles and responsibilities of business users in the implementation.

At the end of the workshop, we conducted a short exercise that I call, “Hopes and Fears.” We invited the participants to list the things that they hoped would result from the implementation. They responded with a variety of benefits, such as improved efficiency, lower inventory, better planning, and a more modern user experience.

We then asked them to list the one thing they were most worried about, the thing they most feared as they looked forward to the implementation. Here the mood turned more serious as they expressed their fears, such as that they might not get enough training, that inventory might actually increase during the transition, that employees might not speak up when things weren’t going well, and that customer delivery schedules might be disrupted.

But the one thing that worried this group the most was that they wouldn’t have the resources to get the implementation finished while still taking care of their regular duties. Would they have the bandwidth? We had told them that they had to put their best people on this project, but could they afford to do that? Where would they get additional personnel? The top executive in the room spoke up and assured the group that the company was ready to spend the money to make those resources available.

At this point, I told them that I had accomplished my unspoken objective. My goal in conducting this workshop was to put some fear into them, as business leaders. Nothing concerns me more than when I see a company begin an ERP implementation thinking that it is no big deal, that they can delegate the project to the IT department, or to the system integrator. Or, thinking that they can treat an ERP implementation as just another project, like installing a new production line, or implementing a new safety program.

Address Fears in Contingency Planning

Healthy fear can be a strong motivator in ERP implementation. At the same time, fear should not lead to paralysis, leading an organization to not move forward with new systems.The right response is to address each of those fears in the project plan, in the form of contingency planning.

• Are you afraid you won’t have sufficient resources? Allocate budget to hire additional resources to back-fill the regular responsibilities of project team members. 
• Are you concerned that business users won’t adopt the new system? Develop and implement a change management plan as part of the implementation. 
• Are you worried that customer delivery might be disrupted? Allocate extra time in the acceptance testing phase to ensure that doesn’t happen. 

You can never completely eliminate risk in an ERP implementation. But with careful planning, allocation of resources, and management commitment you can greatly mitigate those risks.

Sage Puts Stake in the Cloud with Sage Live

Sage is one of the world’s largest providers of business applications for small and midsize organizations. Now in the cloud it has taken a big step forward, launching Sage Live, a built-from-scratch accounting system on the Salesforce.com platform.

This post outlines key features of Sage Live, the challenges it will face, and recommendations for potential buyers.

Read this post on the Strativa blog:  Sage Puts Stake in the Cloud with Sage Live

Rootstock's Momentum in Cloud ERP

Rootstock Software is an up-and-coming cloud manufacturing ERP provider, built on the Salesforce.com platform. Last year, I covered Rootstock in a post about four ERP systems in the Salesforce ecosystem. This year, the annual Dreamforce conference gave me the opportunity to interview Rootstock executives and customers about the progress the firm has made over the past year.

In short, Rootstock is showing good momentum, nearly doubling its publicly announced customer count over the past 18 months. It is also building out its product offerings by developing its own native accounting applications and extending its business intelligence capabilities utilizing Salesforce Wave Analytics.

Read the full post on the Strativa website: Rootstock Rounding Out Its Cloud ERP Offerings.

Kenandy Has a Contrarian View Toward Two-Tier ERP

Salesforce.com is proving to be a popular platform for developing ERP systems, and its annual user conference, Dreamforce, has been a great way to catch up with all of them in one place.

Last year, I provided an update on the four ERP providers building on the Salesforce platform in a single post. This year, I want to provide an update on these, starting with Kenandy.

Unlike cloud-only ERP providers such as NetSuite and Plex, Kenandy is not interested in a "two-tier ERP strategy." The strategy of "two-tier" refers to the targeting of small divisions or operating units of larger companies that are running Tier 1 solutions, typically SAP or Oracle, at headquarters and in larger divisions. The cloud provider then targets its ERP solution for smaller divisions of the company with integrated to the corporate system, usually for shared services such as financials, central order processing, or cross-company supply chain management. NetSuite points to customers such as Jollibee Foods and NBTY (China) Trading Company as multinational companies implementing NetSuite in a two-tier strategy. Similarly, Plex boasts of Caterpillar and Inteva Products as success stories in two-tier ERP.  

Going against this trend, Kenandy executives say that, although they will not turn away two-tier opportunities, they would rather work in what they consider a more strategic role with customers. This means targeting (1) large enterprises for a complete ERP solution, or (2) serving as a more agile "orchestration" solution for new lines of business within large enterprises.

Read the full post on the Strativa website: Kenandy: Against the Tide of Two-Tier ERP

Infor ERP Customers and the UpgradeX Roadmap

I was at Infor’s headquarters in New York City recently for Infor’s Innovation Summit, its annual event for industry analysts. It’s a good two day briefing, packed with a lot of information on Infor’s broad portfolio of products and its many new initiatives, along with access to all of its top executives.

One of my goals was to see what kind of progress Infor has been making on its CloudSuite program, and especially its UpgradeX initiative, which is aimed at upgrading Infor’s existing customer base to current versions deployed in the cloud. In our ERP selection consulting services, we often see Infor as the incumbent provider, so knowing the details of these offerings is important in understanding options for these clients going forward.

But Infor faces two challenges. First, it must convince a greater share of its 70,000 customers to upgrade to its latest versions. Then, if it does convince them, Infor will need to have the implementation resources trained and available to support those customer migrations.

Read the rest of this post on the Strativa website: Infor ERP Customers and the UpgradeX Roadmap

With Manufacturing ERP, the Best UI is No UI

Among industry analysts, there is much talk these days about smart devices. The story is that information technology is being embedded in a host of products, from your household thermostat to your wristwatch to your toothbrush. These smart devices can be connected to each other and to cloud-based systems, resulting in an Internet of Things (IoT) that enables a whole host of new products and services. They also throw off enormous quantities of data—big data—that can be analyzed for insights and predictions and further leveraged for information-based services.

All this is new and exciting. But there’s one industry where smart devices are very old news: manufacturing.

Yet, for the most part, today’s ERP systems do not leverage those smart devices on the factory floor. In the typical factory, the intelligence of the factory equipment is used almost exclusively by manufacturing engineers, process engineers, and quality assurance professionals to control production. But when it comes to recording transactions for production control, inventory, or accounting, they are often performed by human operators hand-entering the data.

Read the rest of this post on the Strativa blog: With Manufacturing ERP, the Best UI is No UI→

The Maturing of ERP on the Salesforce Platform

Salesforce.com held its monster user conference, Dreamforce, last month in San Francisco, and there were plenty of new announcements. For example:

• A new analytics cloud, dubbed Wave, which fills out Salesforce.com's offerings to include native business intelligence and analytical capabilities
   
• A new version of the Salesforce1 platform, Lightning, for developing mobile apps
   
• An expanded partnership with Microsoft for Windows mobile devices and new integrations with Microsoft Office, Office 365, Power BI, and Excel

But Dreamforce is not just about Salesforce. It's about the Salesforce ecosystem—hundreds of partners building complementary and in many cases completely independent solutions on the Salesforce platform.

For those that follow ERP, this post outlines the latest developments with four ERP providers building on the Salesforce platform: Kenandy, FinancialForce, Rootstock, and AscentERP along with my takeaways from each of them. I'll end with one small caveat for buyers.

Kenandy Goes Up-Market

I first wrote about Kenandy after its introduction on stage at Dreamforce in 2011, and I’ve kept in touch with its management team for regular updates. The big news this year is the success Kenandy has had in selling into large companies.

Exhibit 1 in Kenandy’s march up-market is Big Heart Pet Brands, a distributor of pet food and pet supplies, which was formed by the carve-out of the pet food business from Del Monte Foods earlier this year. Milk Bone, Kibbles, Gravy Train, and 9Lives, are just a few of its well-known brands.

I had an opportunity to interview Dave McLain, the firm’s CIO, who made it clear that this is no two-tier ERP configuration. Apart from a handful of point solutions and an on-premises warehouse management system (Red Prairie), a single instance of Kenandy will be providing all ERP functionality when fully rolled out. With $2 billion in annual revenue, this may well be the largest company running a cloud-only system as its only ERP system.

(If readers have heard of a larger example, please let me know--but before responding, please reread the preceding sentence slowly and note the words “cloud only.”)

Why would McLain trust a young vendor such as Kenandy with such a tall order? First, McLain was attracted to the Salesforce platform and its promise of rapid development. In other words, he was sold on the platform and then looked for an ERP provider that was leveraging it. In my view, it helps that McClain is not your typical CIO. He’s worked in the enterprise software industry, with stints at Aspect Development, back around the turn of the century, and at i2. He is not only comfortable working with a young vendor, but he viewed Kenandy’s youth as an advantage, as he felt he would have more influence over the product roadmap. So far, he’s happy with his choice.

Big Heart Pet Brands is only the first and most visible example of Kenandy’s move into larger companies. In a briefing, Kenandy executives shared with me several large deals they have in implementation and several that are in the pipeline. Although the names are still confidential, they are large and in some cases very large, well-known, global companies.

One point that may keep SAP executives awake at night: some of these prospects are reportedly approaching Kenandy because of a determination to halt further implementation of SAP’s Business Suite in new regions of the world.

My takeaway from Kenandy is that cloud ERP is not just for small and midsize businesses.

FinancialForce Goes Deeper

FinancialForce is another young ERP vendor, founded in 2009 as a joint venture between UNIT4 and Salesforce (UNIT4 is the majority shareholder). I wrote about FinancialForce last year and commented on its acquisition of Vana Workforce and Less Software. These acquisitions expanded FinancialForce from financial systems and professional services automation into HR systems, order processing, inventory control, cost accounting, and functionality for product-based businesses.

This year, in a briefing with FinancialForce executives, I heard about the firm’s work to embed HR activities within operational transactions. Users can give other employees feedback on their performance right within the context of a project in the professional services system, for example. The feedback is then recorded in the HR system so that employee performance data is gathered throughout the year instead of during an annual performance review only. FinancialForce refers to this approach as “Everyday HCM.”

The firm also reports good uptake of the “supply chain management (SCM)” capabilities that it acquired from Less Software, tripling its number of customers for this functionality. As I pointed out last year, the term supply chain management is something of a misnomer. There is no real warehouse management, transportation management, or supply chain planning. Rather, SCM in this context really refers to the detailed tracking of physical and intangible products from supplier, through inventory, to customers.

This can best be seen with the large percentage of deals that Less Software, and now FinancialForce, have done with VARs, resellers, and other tech industry channel partners. FinancialForce can now track and process OEM rebates (a long-standing practice in channel businesses). Product costing allows costs to be accumulated by serial number (specific identification) and can include landed cost (i.e. allocated inbound freight cost). This is a huge need for solution providers that import OEM products. Filling out the needs of today’s channel partners, FinancialForce also has a full professional services automation system, and it supports subscription billing along with management of recurring revenue.

These are not trivial product features. It is a testimony to the rapid development capabilities of the Salesforce platform that FinancialForce has been able to build out these features in such a short time.

Like Kenandy, FinancialForce is also getting into larger deals, although the names are not yet public.

My takeaway from FinancialForce is that in some cases the functionality of these young cloud-only vendors now rivals that of the traditional vendors.

Rootstock Expanding Its Footprint and Presence

The founders of Rootstock have the advantage of having developed a cloud ERP system twice. The firm first developed its manufacturing system in 2008 on the NetSuite platform. In 2010, however, Rootstock disengaged from this partnership and rewrote its ERP system on the Salesforce platform. As a result of the replatforming, Rootstock developed its own customer order management product and partnered with FinancialForce for its accounting systems.

Rootstock scales well to larger companies. It claims to be the largest system on the Salesforce.com platform in terms of the number of objects,pushing the boundaries of what the platform can do. All Salesforce partners, of course, benefit from the scale-out capabilities that Salesforce is building into the platform.

In terms of functionality, Rootstock has good capabilities for purchasing, production engineering, lot and serial tracking, MRP, MPS, and capacity planning, shop floor control, manufacturing costing, and PLM/PDM integration. The system can support multiple companies, multiple divisions, and multiple sites, all within a single tenant on the Salesforce platform. It also announced this year the development of a product configurator, a module where most cloud ERP systems are still relying on third-party solutions.

The build out of functionality is making Rootstock more attractive to larger companies as well as the midsize organizations it has appealed to in the past. In a briefing with Rootstock senior leadership, they pointed to their win at CSG, a provider of print and managed services, and enterprise solutions in Australia and New Zealand. In New Zealand, it is the exclusive distributor for Konica Minolta. When fully deployed, Rootstock will be serving “hundreds” of users at CSG.

Other wins this year include Northeast Lantern, a maker of high quality brass and copper lighting fixtures; Wilshire Coin Mints, a retailer and wholesale distributor of coins for collectors and investors; Proveris Scientific, a manufacturer of test instrumentation for the pharmaceutical industry; Pioneer Motor Bearing, a maker of high performance industrial bearings; Pacer Group, a wire and electrical cable manufacturer; Plumb Sign, a job shop producing signage for businesses across the US; and Oberfield Architectural Precast, a manufacturer of precast concrete and other custom-built precast products.

In another development, Rootstock added some muscle to its advisory board this year with the addition of Jan Baan, the former founder and CEO of Baan Software, Jim Bensman, former president of SAP North America, Bill Happel, former VP of General Motors, and Lee Wylie, former CIO of Gartner.

My takeaway from Rootstock is similar to that for FinancialForce: the functionality gap in some areas is closing between the cloud-only ERP providers and traditional vendors.

AscentERP Raises Its Profile

I was not able to meet with AscentERP during Dreamforce, so I arranged a call after the show with Shaun McInerney, its co-founder and President. McInerney was positively excited about his firm’s latest developments:

• The launch of Ascent Rental, a native Force.com application for companies that rent or loan out equipment. He’s already seeing interest from current customers in the construction industries. Event organizers and medical equipment rental businesses are also targets.
   
• An iTunes app that turns Apple iOS devices (iPod Touch 5th Gen, iPhone 5, and iPad Mini) into true high-speed bar code scanners, through use of a scanner sled available from Honeywell. This plays well with AscentERP’s roots in warehouse data collection and is a key element in the case study I highlight below.
   
• Integration with Magento for e-commerce, allowing customers to take orders from the web, fulfill them and push shipment information back to customers. McInerney claims over 15 customers already for this functionality, which was only launched two or three months before Dreamforce.

McInerney reports an increase in new opportunities coming from Salesforce, with about half from outside the US. The system supports multiple currencies and base languages of English and Chinese. Like the other three vendors outlined in this post, AscentERP is also seeing its share of larger deals, which includes several in the range of 200 users, a jump from its typical user count in the past.

In my opinion, AscentERP gets the award for the most inspiring customer story. It put together a short video about its client Bosma Industries, a $55 million non-profit distributor of medical supplies, which also happens to be Indiana’s largest employer of people who are blind or have vision loss. AscentERP worked with Bosma to customize its system and to make it fully accessible to Bosma’s visually impaired workforce. This is where that iTunes app for warehouse data collection comes into play.

The best quote is from Bosma’s Adam Rodenbeck, who says, "If Siri can look at Facebook and help us get around on Twitter, why can't it help get us around the warehouse?"

Click the image below to watch the 3-minute customer story.

My takeaway from AscentERP: don't underestimate the marketing value of being part of the Salesforce ecosystem.

Buyers Should Ensure Adequate Implementation Support

One thing that none of these four vendors mentioned: a lack of new sales opportunities. In fact, they all indicated that they were awash in new prospects. This is in contrast to some of the traditional ERP vendors who periodically call me to check whether I’ve “heard of anyone looking for software.” It’s always a good sign when a vendor can afford to be picky about the opportunities it chases—it lessens the likelihood that the vendor will get into situations where it cannot compete and improves the chances of success.

But the the flip side of all these new deals can lead to problems if vendors are not adequately staffed to support them. Generally speaking, I caution clients to be sure they get adequate consulting help when they are considering these vendors. True, these new cloud-only systems are generally easier to implement, but still, they don’t implement themselves. You don't need system admins or DBAs. But you do need consultants who understand how to configure the system and help you implement your processes within it. In some cases, these vendors may have consulting partners that can assist, but they can be stretched as well. It is not an insurmountable problem, but buyers should be sure they get the help they need to have a successful implementation.

Note: Salesforce paid my travel expenses to attend Dreamforce.

Related Posts

Four Cloud ERP Providers on the Salesforce Platform
Kenandy: A New Cloud ERP Provider Emerges from Stealth Mode

Workday’s Goal: Tier I Cloud ERP

Aneel Bushri, Co-Founder, Workday

Mention Workday to anyone involved with enterprise applications, and the first response will probably be something about cloud-based HR systems. A few might also mention accounting systems.

It is becoming increasingly apparent, however, that Workday’s ambitions go beyond human capital management (HCM) and financial management systems. From briefings at a recent Workday analyst summit, I conclude that Workday intends to become the first Tier I cloud ERP provider.

What is Tier I ERP?

The term “Tier I ERP” has been bandied about for many years. It is generally understood to refer to the largest ERP vendors that are able to serve the largest and most complex global businesses. Fifteen years ago, there were several players that could arguably be members of that club. But because of industry consolidation only two vendors remain that fit that definition: SAP and Oracle.

I am convinced that Workday wants to join that club, and it wants to join it as a cloud-only provider. SAP and Oracle may be moving as fast as they can to cloud ERP, but they will forever be, at the most, hybrid providers—offering both on-premises and cloud versions of their systems. Workday, in contrast, intends to be the first Tier I cloud-only provider.

Evidence of Workday’s Ambition

There are several things that point to Workday's objective.

• Tier I customers. Unlike NetSuite, which leads the cloud ERP market in terms of number of customers, Workday from its very beginning has been targeting large companies. I noted this way back in 2008 with Workday's wins at Flextronics and Chiquita. Since then, it hasn't stopped, signing one Fortune 500 customer after another. For example, in 2013, it won HP, with 300,000 employees in 111 countries. This year it closed Bank of America, which is now Workday's largest customer. Moreover, its big company wins are not limited the US. For example, Workday recently sold Nissan and Sony in Japan and Philips in the Netherlands. Our most recent research at Computer Economics shows that Workday's typical customer is so large that it stands head and shoulders above all other cloud ERP providers.
   
• Tier I functionality. The functionality of Workday's HCM is now approaching that of Oracle and SAP, as it builds out its global footprint. It currently claims customers live in 177 countries, with 27 offices worldwide. Translations are provided for 25 languages. Outside of the US, it still relies on payroll partners, but it is building out its own payroll for the UK and France. Its Financial Management product has now reached 100 customers. It just announced a new embedded financial reporting capability (Composite Reporting) that promises to do away with a whole host of spreadsheets and data warehouse reports that large companies typically rely upon. 
   
• Tier I cloud platform. Workday has also been building out its cloud platform into one that can handle the demands of the world's largest enterprises. It is moving its infrastructure to OpenStack, a set of open source components and architecture for software-defined data centers. This makes Workday's platform less proprietary than it has been in the past. Moreover, large companies need assurances of system availability and reliability. Therefore, like leading consumer Internet services, Workday is building its platform to quickly detect and recover from failure in any infrastructure component. Taking a page from Netflix, it will soon be randomly turning off components in the production environment as a way of ensuring its ability to recover. Phil Wainewright has more on the latest developments with Workday's infrastructure. 

Some observers view Workday as less than an ERP provider, as it only provides HCM and financial management systems. But they ignore the fact that Workday has already moved beyond these functions. It already provides purchasing, expense management, and project management functionality. It also includes embedded business intelligence capabilities that embrace data inside and outside of Workday. In one sector in particular--Higher Education--it has already pushed into operational systems, with its launch of Workday Student.

Can other functional areas be far behind? Workday's CEO Aneel Bushri made a telling comment at the end of the analyst summit, "Financials are the door to everything else," he said. "After you see us land large financial deals, you will see us moving into other areas: maybe healthcare, which is mostly workflow, plus patient accounting and billing. Layer on top of that strong analytics. It might be a year or two from now, but not five years out. But right now, we can't spread ourselves too thin."

This mimics the evolution of most other ERP providers over the past two to three decades. SAP, Oracle, and many others started as accounting systems. Once they were in the door, they then became the natural choice for expanding into operational systems in other functional areas.

Avoiding Side Streets

At this point, Workday has no lack of opportunities. In fact, one of the problems it faces is that there are simply too many good ideas that it could pursue. But if I am right that Workday's goal is to be the first Tier I cloud ERP provider, it cannot afford to take its eye off the ball.

Here are some of the ideas where Workday is saying no:

• Platform as a service (PaaS). Most of the leading enterprise SaaS vendors also offer a platform for their customers to extend the vendor's system or to build their own complete standalone systems. Salesforce.com with its Salesforce1 platform is the prime example. In its recent user conference, Oracle CTO Larry Ellison criticized Workday for its lack of a PaaS.
  
  But Workday is taking another path. First, most user development is for reporting, and Workday excels in its embedded business intelligence capabilities. Second, its applications are highly configurable, which diminish the need for customizations. Finally, where customers truly need to do new development, Workday offers an "integration cloud" to allow customers to build applications on other platforms, such as Salesforce1, and have them interoperate with Workday.  With a number of other good platforms offered by other providers, it is difficult to see the drawbacks to Workday's approach here.
   
• Commercializing Workday's cloud platform. As noted earlier, the capabilities of Workday's cloud platform are approaching those of large consumer cloud platforms, such as Google's or Amazon's. It is robust, scalable, and fault-tolerant. It is difficult to think of another enterprise software provider that can accommodate the number of simultaneous users in a multi-tenant environment and a single application code line. After Workday's briefing update on its technical architecture, I asked, "At what point do you commercialize this platform?" By this I mean, either to allow other SaaS providers to build on a separate instance of Workday's platform, or to license the platform for them to build upon and operate themselves. The short answer was, never say never, but Workday would rather focus on building applications.
   
• Manufacturing industry functionality. Manufacturing companies represent the largest industry sector worldwide. Nevertheless, Workday executives are adamant that--at least at this time--they do not plan to develop manufacturing business systems. In part, this may reflect the founders' experience at PeopleSoft, where their attempt to gain market share in manufacturing never gained traction. Way back in 2003, I wrote a post, PeopleSoft Is Tired of Being the Best Kept Secret in Supply Chain Management, which highlighted just how good PeopleSoft was in manufacturing and supply chain. But PeopleSoft never broke through in a big way.
  
  The other reason, I believe, is that manufacturing is simply a bridge too far from where Workday is today. Most of Workday's target markets today have one thing in common: they are sectors where people are the dominant costs--Financial Services; Professional and Business Services; Higher Education, Software and Internet Services; Government and Non-Profit; Healthcare; and Hospitality. These industries are best for leveraging Workday's roots as an HCM system provider. Workday could change course at any time, but right now, the leadership team feels that chasing product-based businesses would be a distraction.

Strategy is all about choices: deciding what not to do is as important as choosing a goal. Workday has no lack of those offering free advice--worth every penny!--and I've given my share in the past. Its leadership team is to be commended for keeping its focus.

What's Next?

If Workday's goal is to become the first Tier I cloud ERP provider, expect to see Workday begin to build out functionality to more fully serve its target industries, like it is doing with Workday Student in the higher education vertical. I'm speculating here, but it might mean merchandising systems for retail or revenue cycle management for healthcare.

Will Workday make major acquisitions to fill out its industry solutions? I don't think so. Its  acquisitions to date have mostly been for technology (e.g. Cape Clear) or what I would call capabilities (e.g. Identified). Any acquisition of business applications would need to be rewritten for Workday's platform, and I sense that Workday would rather start with a clean slate in developing new functionality. Workday's approach also allows it to build upon a single object model for each key entity, such as "person," rather than interfacing entities between acquired software. Workday's approach is another point of contrast with SAP and Oracle, which have built up their cloud portfolios largely through acquisition of disparate vendors and are now facing the challenge of integration.

There is another contrast with SAP and Oracle. Workday has a tremendous advantage in that all its customers are on the latest version. Its architecture with a single code base ensures it will never have legacy customers to support--another demand on a vendor's resources.

The Tier I ERP club today only has two members. But a third member may be joining sooner than we think.

Related Posts

Best Practices for SaaS Upgrades as Seen in Workday's Approach
Workday Making Life Easier for Enterprise Users
Workday Pushing High-End SaaS for the Enterprise
Workday: Evidence of SaaS Adoption by Large Firms

ERP Customer Deployment and License Preferences

As we all know, a major transition in the ERP market is underway, from traditional sales of perpetual licenses deployed on-premises to subscription services deployed in the cloud. But not all buyers are ready to make the switch. Some prefer to stick with the traditional model, while others are going whole hog to the new model. Others still, are somewhere in the middle, sticking with a traditional vendor offering but having the system hosted by the vendor or a third-party partner.

Customer preferences are complicated by what is offered by their chosen vendor. When a new customer selects a cloud ERP vendor, such as NetSuite, Plex, or Rootstock, are they doing so because of the cloud subscription model, or in spite of it? Likewise, when a customer selects a traditional vendor with on-premises or hosted deployment, is it because they are opposed to the cloud model, or is it because the functionality of the traditional vendor was a better fit?

Acumatica as a Test Bed

As it turns out, there is one vendor’s experience that can help us answer these questions: Acumatica. Acumatica is a newer cloud ERP vendor, and it has some interesting characteristics that make it a good laboratory for testing customer preferences.

• It is a fairly new provider, founded in 2008, that built its product from the ground up as a multi-tenant cloud system. It now has about 1,000 customers--a good sized sample--in manufacturing, professional services, and a variety of other industries. Moreover, there is no legacy installed base to influence the numbers.
   
• The system is sold exclusively by partners, and—this is the key point—partners have flexibility in how they deploy the system. They can deploy it as a multi-tenant cloud system, with multiple customers on the same system instance, or they can deploy it in the customer’s data center or a hosting data center as a single tenant deployment.
   
• The licensing model is also flexible: customers can buy Acumatica as a subscription service, or they can buy it as a perpetual license.

The combination of deployment flexibility and licensing flexibility yield three main groups of customers that I’ll refer to as follows: 

1. Perpetual License Customers: these are customers choosing the traditional license model with on-premises deployment or hosting by a partner. (Acumatica refers to these as “private cloud.” I think that term is confusing, however, as when deployed for a single customer, the system loses its cloud characteristics, such as pooled resources and elasticity.) 
    
2. SaaS Customers: these are customers choosing cloud deployment along with a subscription agreement.
    
3. Subscription On-Premises Customers: these are customers that choose traditional on-premises or hosted deployment but pay according to a subscription agreement.

In theory, according to Acumatica, there could be a fourth category: a customer could choose cloud deployment with a perpetual license. In practice, however, no customer has asked for this. If a customer were to choose this option, they would pay the license fee up-front, plus traditional maintenance fees, plus a hosting or cloud services charge on a monthly basis.

What Deployment and Licensing Options Do Customers Prefer?

Richard Duffy at Acumatica was kind enough to share with me the customer counts for each of these three categories for the years 2013 and 2014. This allowed me to calculate on a percentage basis what options customers are choosing and—just as importantly—how those preferences are changing.

As shown in Figure 1, perpetual licenses (either on-premises or hosted) form the largest category of customers. This group accounted for 63% of new Acumatica sales in 2013, but it is falling dramatically to 42% of new customers in 2014. The SaaS customer group is picking up some of the difference: 29% in 2013 rising to 33% in 2014. But the largest increase is coming from the so-called “Subscription On-Premises” group, which accounted for only 8% of sales in 2013, rising to 25% this year.

A Trend to Cloud, But Even More to Subscription

Although I am an advocate for cloud ERP, these results indicate that—at least for some customers today—the attraction of cloud ERP is more in the subscription option than it is in cloud deployment itself. Acumatica’s experience shows from 2013 to 214, the majority of Acumatica’s sales shifted from perpetual licenses to subscription agreements. But a significant percentage of those did not deploy in the cloud: they chose the subscription agreement with on-premises (or hosted) deployment.

Duffy is quick to point out that the choice of licensing and deployment options are influenced by Acumatica’s partners. Some are accustomed to selling perpetual licenses and appreciate the up-front cash that comes from license sales. Others are accustomed to on-premises deployments or hosting in their own data centers and unless challenged by the customer may steer them toward those options. But if this is the case, the trend in Figure 1 is conservative. Without partner bias toward perpetual licenses and on-premises/hosted deployment, the trend toward subscription and cloud would be even greater.

What Does This Mean for Buyers and Vendors?

As outlined in other research from Computer Economics, the benefits of cloud ERP are clear: speed of implementation, ease of upgrades and support, agility, and scalability. But do not underestimate the benefits that come from subscription pricing—whether or not it comes with cloud deployment:

• Up-front cash savings. Unlike perpetual licenses, subscription agreements give customers pay-as-you-go pricing. Some vendors may require customers to commit to an initial contract term (e.g. one year) and pay for that up front. But even so, this is significantly less than customers would pay up-front under a perpetual license.
   
• Risk mitigation. Under a perpetual license, if the implementation fails, or the customer decides to switch systems after two or three years, the customer loses its entire investment in the software. With a subscription agreement, the customer only loses subscription fees paid prior to cancellation.
   
• Alignment of vendor’s interest with customer’s. Closely following the previous point, under a perpetual license, a failed implementation does not cost the vendor anything (assuming there is no legal action requiring vendor concessions). With a subscription agreement, in contrast, vendors must continually satisfy customers, lest they lose the ongoing subscription fees. This tends to focus the vendor’s attention more closely on customer success. 

The combination of cloud deployment and subscription agreements is, no doubt, a powerful combination. But notice that the three benefits outlined above are the same, regardless of whether the system is deployed as a cloud system.

Does this mean that all customers should go for subscription pricing? Based on interviews with some Acumatica customers that chose perpetual licenses, it seems the answer is no. Some customers do not like the idea that they will be paying subscription fees for as long as they use the system. They like the thought that, if they implement successfully, they have lower out-of-pocket costs for the long run.

Personally, I think such customers are underestimating their ongoing costs, including maintenance fees and the cost of money. I also think they are under-appreciating the risk mitigation and alignment benefits of subscription agreements.

Nevertheless, Acumatica’s experience shows where customer preferences are today and where they are heading. Cloud deployment is the future of ERP, and subscription agreements are attractive, even without cloud deployment.

These findings also suggest that traditional vendors that are slow to adapt to cloud deployment may be able to benefit in the short term simply by offering and promoting subscription agreements.

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.

It is a blueprint that others will do well to emulate.

Related posts

Infor and Salesforce.com: More Than a Barney Relationship 
Infor's Two-Pronged Cloud Strategy 
New details on Infor's Lawson acquisition
Making money in software with a niche-industry strategy