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. 

Cerner Acquisition to Launch Oracle Higher into Healthcare

Earlier this month, Oracle and Cerner jointly announced an agreement for Oracle to acquire Cerner, a provider of digital systems to healthcare providers. The deal of approximately $28 billion will be the largest in Oracle’s history, nearly three times the size of its PeopleSoft acquisition in 2005.

To understand the rationale behind the deal and what it means for the two companies, the industry, and especially for Cerner customers, we interviewed Avasant partners, consultants, and fellows who focus on the healthcare industry.  This research byte summarizes our point of view.

Read this post on the Avasant website: Cerner Acquisition to Launch Oracle Higher into Healthcare

Enterprise Buyers Not Looking for a One-Stop Shop

There's been an interesting discussion on Twitter over the past few days, which I started with this deliberately ambiguous tweet. 

IMO, very few enterprise buyers are really looking for a "one-stop shop." 

As intended, that brought out replies from several friends and associates, such as Vijay Vijayasankar, Oliver Marks, Holger Mueller, Jody Lemoine, Shane Bryan, John Appleby, and others. 

So, what did I learn from the dialog? 

First, I was thinking back to client meetings I've sat through over the decades, where business leaders positioned "one-stop shop" as a key element of their desired strategy. 

In other words, in the market we serve, customers are typically looking for 10 things.  But today, we only offer seven. If we can offer all 10 things, we can become a one-stop shop! Customers will not have to go anywhere else but will have the convenience of having us satisfy all their needs. 

In enterprise software, this might translate to an ERP system vendor attempting to offer a CRM system or supply chain management suite, or product data management, or a host of other complementary products. Invariable, because these systems take years to develop from scratch, in practice this means acquiring those complementary products. It may also mean offering other elements of a complete solution, such as a development platform, tooling, system integration services, even databases or hardware. 

I don't know if Oracle ever used the term "one-stop shop," but it certainly behaved as if it had. It has been on a multi-decade acquisition spree, not only in business applications, but also in databases (its roots), infrastructure software (BEA), even hardware (Sun). To be fair, it also plowed profits from those products into new development, such as for its Fusion cloud applications. And it is now competing with Amazon for cloud infrastructure services. It is a poster child for the one-stop shop. 

SAP has had its own version of the one-stop shop, acquiring a variety of systems (Holger calls some of them the seven sisters). It also built its own proprietary database, and it also has its own development tooling. 

What About One Throat to Choke? 

One can imagine why such a strategy might be attractive to technology sellers.  But is it attractive to technology buyers? 

I say, no.  In decades of consulting, I don't think I've ever heard a client say, I just wish I could buy everything I need from a single vendor. What I need is a one-stop shop. 

But isn't a one-stop shop the same as "one throat to choke?" I say no. One throat to choke means that in a system implementation, for example, there is a prime contractor or service provider ultimately responsible for delivery. If another partner in the deal is not meeting its commitments, the prime contractor or service provider serving as overall program manager is responsible.  It doesn't mean that there is only one service provider or vendor in the deal. 

What About Integrated Suites? 

Holger asked, "Are you saying that [integrated] suites are done?" Not at all. But I have two responses to this. First, many integrated suites are anything but.  Especially if, as noted above, the vendor built its suite from piece parts that it acquired over time. It takes years to integrate software acquired from various sources. So, buying from a vendor attempting to be a one-stop shop does not ensure you are really getting an integrated suite. 

Second, I have seen very few large deals where there was only a single software provider in the deal. There are almost always complementary products whether they be for sales tax reporting, factory data collection, data analytics, or countless other niche requirements. 

Third, no IT organization's application portfolio only has software from a single vendor, not even a handful of vendors. Even small companies buy software from dozens of vendors. There is no one-stop shop in enterprise software. 

What About Application Rationalization? 

But what about vendor consolidation? Maybe one vendor isn't reasonable, but isn't it a good idea to limit the number of software providers and rationalize the applications portfolio?  Certainly, many companies need to consolidate applications, especially if they grew through mergers and acquisitions and now have two, three, or more ERP systems, for example. 

But that does not mean they need to only buy from one vendor. 

Vendors love to talk about vendor consolidation, as long as the surviving vendor is them. They call this gaining in their "share of wallet," as in the buyer's wallet. 

In my view, when it comes to vendor consolidation you can have too many vendors and you can also have too few. You don't want to have so many vendors that you have redundant types of systems. On the other hand, you don't want to have too few vendors to the point that they gain leverage over you.  

To this point, I've heard of customers engaging in multi-year programs specifically to reduce dependence on certain Tier I vendors, as they become too powerful and attempt to engage in wallet fracking, as my friend Brian Sommer calls it. 

Is there a way to have the benefits of integration and applications rationalization without becoming overly reliant on a single vendor?  I think there is.  Modern cloud systems have become API-oriented. And to be fair, the major vendors, even those aspiring to a greater share of wallet, are building with this model. They have to, if they want market acceptance. Cloud leaders, such as Salesforce, do it by providing a platform that partners can write to, even leveraging Salesforce objects, to provide that integration. Oracle's NetSuite offers a similar capability. Cloud ERP vendors, like Acumatica, Plex, and Sage Intacct are very integration-friendly. Oracle's cloud applications and SAP's offer open APIs, as does Workday. Microsoft has similar capabilities. 

If this is the future, then maybe vendors will give up the strategy of the one-stop shop. 

Why Would Oracle Want TikTok?

Oracle is reportedly in talks to acquire the certain operations of social video service TikTok. 

I'm hearing through the back channel that the move is not being well received within Oracle itself this morning. 

From the Verge: 

Oracle has expressed an interest in acquiring TikTok, according to the Financial Times, giving Microsoft a potential competitor in its bid to control the Chinese social video app in the US. Larry Ellison’s enterprise software giant has reportedly held preliminary talks with TikTok’s parent company ByteDance already, working with venture capital firms including General Atlantic and Sequoia Capital, and is “seriously considering” acquiring its business in the US, Canada, Australia, and New Zealand.

So why would Oracle acquire a business that is so far out of its market space? 

I've heard speculations from various quarters. It could be motivated by a desire to leverage TikTok's user data to enhance Oracle's marketing products. It could be motivated by a desire to get into a consumer business. It could be motivated by a desire to hurt Microsoft--something that would fit Ellison's competitive nature. 

There's one more possible motivation I haven't heard mentioned, and that is to get TikTok's huge workload for Oracle Cloud Infrastructure (OCI). Oracle's market share lags far behind Amazon, Microsoft, and even Google's. There is a bit of a chicken-and-egg problem facing Oracle, however. Cloud infrastructure providers need large workloads to realize economies of scale, making them price competitive. But how can Oracle achieve that scale? One way is to buy the workloads. And what bigger workload than a video-sharing service? 

This is likely the reason that it offered a deal to host some of Zoom's workloads on OCI. So, it might also be the primary motivation for Oracle to pitch for TikTok. 

Anyone with me?  

Google Getting Serious about Enterprise IT

This just in: Google has just announced hiring of Rob Enslin as President of Global Customer Operations for its Google Cloud unit.

Why is this a big deal? Because Enslin only in the past month announced his departure from SAP, where he spent 27 years and was most recently in charge of SAP's entire cloud portfolio. He was also a member of SAP's executive board.

Enslin will be reporting to Thomas Kurian, who was recently hired on by Google as the CEO of Google Cloud. Kurian, of course, was highly regarded during his 22 year career at Oracle, where he was most recently the President of Product Development. He was also the brains behind Oracle's Fusion line of cloud applications, which represent Oracle's future as a cloud applications services provider.

Kurian writes:

Today, it is my pleasure to introduce Robert Enslin, Google Cloud’s new President of Global Customer Operations. Rob’s expertise in building and running organizations globally, business acumen and deep customer and partner relationships make him a perfect fit for this crucial role. Rob will report to me, and he starts on April 22. Rob spent the last 27 years at SAP in leadership roles across sales and operations, most recently as the President, Cloud Business Group and Executive Board Member. He developed and managed SAP’s entire cloud product portfolio, led the field revenue and enablement efforts across multiple geographies, and oversaw core functions including professional services, ecosystem, channel, and solutions. Rob brings great international experience to his role having worked in South Africa, Europe, Asia and the United States—this global perspective will be invaluable as we expand Google Cloud into established industries and growth markets around the world.

Just today in a private message a fellow analyst said, in another context, that the "enterprise software boat is being rocked." I replied that it needs to be rocked, and maybe it needs to be capsized.

Perhaps Google getting serious about enterprise technology is just what the market needs. For now, Google's immediate objective appears to be to take on Amazon and Microsoft for cloud infrastructure services. But with hiring of Kurian and Enslin, will Google also start moving into enterprise applications? Or will it be content to just be a platform provider>

Watch for who are the next new hires. That will give us a clue.

Big Shift: NetSuite Moving to Oracle Cloud Infrastructure

In recent years, Oracle has been intensely focused on its cloud strategy as the key to its growth. At Oracle Open World 2016, with the announcement of Oracle’s second-generation cloud infrastructure, Larry Ellison said, “Amazon’s lead is over.” It was an ambitious goal: At the time, Oracle’s cloud infrastructure (OCI) business was bringing in less than $200M per quarter.

Uptake of Oracle’s cloud applications is great, but when it comes to Oracle really competing with Amazon or Microsoft as a platform for independent software vendors (ISVs), the story is different.

The absence of multitenant ISVs on OCI is not because of a lack of capabilities. Oracle’s flagship database, since v12c was released in 2013, has built-in multitenancy in the form of database containers, which allow multiple tenants to share a single Oracle database, with individual containers assigned to each tenant. This approach puts the multitenancy into the infrastructure layer, allowing developers to focus their efforts on application development, not on the mechanics of multitenancy.

Oracle’s lack of commercial SaaS providers building on OCI is about to change.

Read the rest of this post on the Strativa blog:
NetSuite on Oracle Cloud Infrastructure: What It Means for Customers

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

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

Oracle v. Rimini Street Lawsuit Verdict: Good for Third-Party Maintenance

Earlier this month, the jury in Las Vegas reached its verdict in the Oracle v. Rimini Street lawsuit, a closely-watched case involving third-party maintenance (3PM) in the enterprise software industry.

Although the jury awarded Oracle approximately $50 million in damages, the amount was far below what Oracle expected. Moreover, the jury found that Rimini Street’s copyright infringement was “innocent,” not “willful,” that Oracle suffered no lost profits as a result, and that neither Rimini Street nor its CEO, Seth Ravin, engaged in any tortious business conduct.

Assuming the jury’s verdict stands up against potential appeals, the case sets an important precedent for how 3PM providers should operate to ensure they are not violating the intellectual property rights of software owners. We expect customer use of third-party maintenance will increase as a result of this verdict.

Read this entire post on the Strativa blog: Oracle v. Rimini Street Verdict Clarifies Ground Rules for Third-Party Maintenance

Oracle Sued by Customer over Source Code Access

Oracle was hit by a customer lawsuit earlier this month in conjunction with its MICROS Systems business, which Oracle acquired in 2014.

The dispute involves access to the source code for the MICROS Open Commerce Platform.  Aero maintains that when it licensed OCP, MICROS (not yet acquired by Oracle) knew that Aero intended to build customizations and new features to integrate with OCP.

Aero alleges that MICROS personnel represented that Aero would have ongoing access to OCP source code in order to build its customizations and maintain them going forward.

Although we do not yet know all of the facts, there is a lesson in this case for companies seeking to become digital businesses.

Read the rest of this post on the Strativa blog:
Oracle Sued by Customer over Access to MICROS Source Code

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

A Guide for Cloud ERP Buyers

In working with clients over the last decade, I've watched as cloud ERP vendors have been steadily encroaching on the territory of traditional ERP providers. As a result, ERP selection projects today are more and more becoming evaluations of cloud ERP providers.

However, buyers need to realize not all ERP systems that are labeled “cloud” are the same. To help buyers better understand these differences, I've just completed a new report for my research firm, Computer Economics, entitled Understanding Cloud ERP Buyers and Providers, based on my experience in selection deals as well as extensive analysis of vendor offerings over the years.

Figure 2 from that report sums up the differences:

In brief:

• Cloud-Only Providers: These are the “born-in-the-cloud” ERP vendors that do not have an on-premises offering and include such companies as NetSuite, Plex, Workday, Rootstock, Kenandy, FinancialForce, Intacct, and several others. These tend to be newer, smaller vendors (although Workday and NetSuite are each in the range of $500 million in annual revenue). Because cloud-only vendors have a single deployment option, they each can focus their entire business—from product development to sales to implementation and ongoing support—on the cloud. As a result, they make fewer compromises and tend to deliver the maximum benefits of cloud solutions in speed, agility, and scalability.
   
• Traditional ERP Vendors: These are larger, more established providers such as SAP, Oracle, Infor, Microsoft, and a number of others. They are growing more slowly than cloud-only providers. They have more complex businesses as they have to support their on-premises customers as well as their hosted or cloud customers. Because they have developed their solutions over many years or even decades, their functional footprint tends to be more complete than those of cloud-only providers.

There is much more in our analysis of the cloud ERP market, which describes these two major categories of cloud ERP providers in more detail. In addition, the report also segments cloud ERP buyers into two categories: first-time buyers looking for their first ERP systems and established companies replacing their legacy systems. As it turns out, generally speaking, these two categories of buyers have different pain points and different criteria driving their decision-making. 

At this stage of cloud ERP market maturity, each of these provider categories has its advantages and disadvantages, and there is no one right answer for a given buyer. Organizations considering cloud ERP need to carefully consider their requirements, their choices, and what tradeoffs they are willing to make. We, therefore, conclude with recommendations for buyers looking at cloud ERP. We also have some advice for providers that seek to serve these two types of buyers.

As a practical aid to buyers, the full report includes two lengthy appendices, which provide profiles of the key ERP vendors of hosted and cloud solutions today, along with an assessment of their market presence. Cloud-only ERP providers profiled include Acumatica, AscentERP, FinancialForce, Intacct, Kenandy, NetSuite, Plex Systems, Rootstock, and Workday. Traditional ERP providers with cloud/hosted solutions include Epicor, IFS, Infor, Microsoft Dynamics, Oracle, QAD, Sage, SAP, Syspro, and UNIT4.

Related posts

The Cloud ERP Land Rush
Computer Economics: Choosing Between Cloud and Hosted ERP, and Why It Matters

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.

Related Posts

Computer Economics: Cloud Users Spend Less, Spend Smarter on IT
Four Cloud ERP Providers on the Salesforce Platform
NetSuite Manufacturing Moves on Down the Highway
Kenandy: A New Cloud ERP Provider Emerges from Stealth Mode
The Simplicity and Agility of Zero-Upgrades in Cloud ERP (Plex)
Plex Online: Pure SaaS for Manufacturing
Computer Economics: Cloud Players Storm the Gates of ERP
Key success factor for SaaS suites: functional parity

Oracle's Partial Victory Against Rimini Street and Customer Implications

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:

1. 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”)."


2. 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.
    
3. 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.
    
4. 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.
    
5. 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 material
   fact 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.
    
6. Concerning Novell, the Court denied Oracle's request for summary judgment, ruling that Novell's license agreement allows Rimini Street to maintain copies of Siebel software on its own servers.
   
   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.
    
7. 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. 

Related posts

Rimini Street to Oracle: don't expect us to roll over
SAP and third-party maintenance: good for me but not for thee
Legal basis for third-party ERP support industry
Oracle slams Rimini Street with lawsuit over third-party maintenance

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.

1. 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.
    
2. 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.
    
3. 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.
   
   
4. 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.

Related Posts

Vendor application integration tools are no silver bullet
Implement EAI, or just roll your own?  

Photo Credit: www.seewellcn.com

Plex's Growth Strategy: Glass Half Full

Those interested in cloud ERP know that Plex was the first provider to offer a cloud-only manufacturing system. Yet Plex has had nowhere near the growth of other cloud enterprise system providers, such as NetSuite. SAP receives a lot of criticism for only having sold 1,000 or so customers its Business ByDesign system--but ByD has only been in general distribution for three or four years. Yet Plex, which launched its cloud offering over 10 years ago, has fewer than 500 customers.What's wrong with this picture?

Last year, encouraged by Plex's new private equity owners, CEO Jason Blessing and his management team formulated a growth strategy, which they presented at the Plex user conference. Afterwards, I outlined what I thought Plex needed to do to execute on it.

Following up now half a year later, Jason circled back to give me another briefing, and it was a good opportunity also to see what progress Plex was making. Here is my take: 

1. Management changes are part of the growth plan. Plex this week announced the appointment of Don Clarke as its new CFO. He appears to be a great candidate for the job. He comes most recently from Eloqua, a leading marketing cloud vendor, where he oversaw Eloqua's growth to nearly $100M in annual revenue, its initial public offering, and its eventual sale to Oracle last year, which put Clarke out of a job.
   
   I joked with Jason that Oracle's acquisition strategy has been serving Plex well in terms of recruiting, as several of Plex's top management team have come from companies that Oracle acquired: Heidi Melin, Plex's CMO, also came from Eloqua, Karl Ederle, VP of Product Management spent time at Taleo, which Oracle acquired in April 2012, and Jason himself came from Taleo.
   
   If Plex's growth strategy is successful, there is likely to be an IPO in Plex's future. Clarke's experience in taking Eloqua public will serve Plex well.
    
2. Plex added 59 new customers in 2013, bringing its customer count to "nearly 400." As mentioned earlier, in my view, the total customer count is well below where it should for a decade-old cloud provider. Jason compares it favorably with the 500 or so customer count for Workday, overlooking the fact that Workday launched in late 2006 and that its typical customer is several times larger than Plex's.
   
   Still, Plex's growth in 2013 represents a 15% increase in its customer base and signals that its growth strategy is beginning to take hold.
   
   The new customer count includes some accounts that are larger than Plex has sold to in the past, such as Caterpillar, which is running Plex in a two-tier model for some smaller plants. In my previous post, I outlined some of the functionality improvements that Plex would need to make to better serve these large customers, and there are signs that these enhancements are underway.
    
3. Plex doubled its sales force last year. This, no doubt, is behind the uptick in new customer sales. The new sales headcount is serving primarily to expand the geographic coverage outside of Plex's traditional Great Lakes concentration to the South and also to the West Coast. (As part of the expansion, Plex opened a Southern California sales office, which happens to be a short walk from my office near the John Wayne Airport.) There are also increased sales to organizations outside North America, another hopeful sign.
    
4. Plex's industry focus remains in three industry sectors: motor vehicles, food and beverage, and aerospace and defense. In my view, this is probably the greatest constraint to Plex's growth strategy. Short-term, having more feet on the street and expanding geographically are low-hanging fruit. But at some point, there will be diminishing returns. Manufacturing contains dozens of sub-sectors, many of which are adjacent to Plex's existing markets. It is not a big jump to build out support and sell into these sub-sectors. We discussed a couple of these, and hopefully, Plex's product management team will have the bandwidth to address them.
    
5. Plex's platform remains a weak spot. Most cloud systems today provide a platform for customer enhancements and development of complementary functionality. For example, Salesforce.com offers Salesforce1, a mature platform-as-a-service (PaaS) capability that has spawned an entire ecosystem of partners. NetSuite, likewise, has its SuiteCloud platform.  Although Plex has the beginnings of such a platform, it is still limited to use by Plex's own development team and a few carefully-vetted partners. Jason knows this is a need, and hopefully we will see more progress in this area. 

There is a lot to admire about Plex. Of the few cloud-only ERP providers that are addressing the manufacturing sector, Plex has the most complete footprint of functionality, rivaling mature on-premise manufacturing systems. In addition, customer satisfaction is readily apparent when I speak to installed customers, both new and old. Hopefully, Plex will build on these strengths and see growth accelerate.

There is a Plex 2013 year-end recap available on the Plex website.

Update: And right on cue, Dennis Howlett has done an on-camera interview with Jason Blessing about Plex's 2014 strategy. He also comments on Plex's approach to SaaS pricing. 

Related Posts

Plex Software and Its Mandate for Growth
The Simplicity and Agility of Zero-Upgrades in Cloud ERP
Plex Online: Pure SaaS for Manufacturing

Workday Making Life Easier for Enterprise Users

Even if you don't follow developments in HR technology, you should pay attention to what Workday is doing, for two reasons. First, Workday is no longer just an HR systems provider, having expanded its footprint into financial systems, operational support for service delivery, and business intelligence. Second, as a SaaS-only provider, Workday has been, in my opinion, a leader in best practices in deploying cloud enterprise systems.

In December, the company released Workday 21. In addition to the 246 new features included in this version, it also features a major update to its user interface, which Workday starting rolling out earlier this month. 

Enterprise User Experience Overdue for Refresh

The look and feel of enterprise software has not changed much since the days of client server, when graphical user interfaces took over from the old green screen mainframe-like experience. Workers use desktop computers to access a main menu, which displays a series of icons or links that point to various subsystems. Data entry screens cram as much information as possible so that users do not have to click through to multiple panels to complete a transaction. Because of the density of information, enterprise software came with extensive user manuals, online help, and training classes.

When vendors abandoned the client-server architecture for browser-based thin clients, they did not generally change this paradigm. They just changed the back-end. They did not significantly alter the fundamental user experience.

Now vendors face a serious problem when users demand mobile access. These user interfaces do not translate at all to a smart phone or tablet display. Mobile access, if provided at all, is a completely different user interface than that on the desktop. In fact, some vendors sell mobile access as an additional product, separate from the vendor's traditional desktop access.

Raising the Bar

Workday has always paid a lot of attention to its user interface. In fact, Workday has gone through something like five major updates in its UI: from HTML/AJAX to Adobe Flex, then adding native IOS and Android, and now to HTML5.

But apart from the technology change, Workday's new interface illustrates several best practices, some of which it derived from consumer Internet services, such as Google and Facebook.These are my take-ways:

1. One interface for all platforms. The familiar "Workday Wheel" is now gone. Why? Because it did not translate well to smartphone or tablet access. The new homepage is a grid of icons that resize and scale according to the size of the screen.
    
2. Easy movement between platforms. Most of us get interrupted in the middle of our work. The new UI allows users to start a process, such as a performance review, on one platform (e.g. a desktop) and then continue or complete it on another platform (e.g. a smartphone). 
    
3. Less is more. Workday has removed less-than-essential information from panels, such as the employee profile, organizing and relegating it into tabs or linked lists, so that panels focus the user's attention on what is most important. I especially like the drop-down navigation on the left side of the header bar, which looks quite a bit like Facebook's left side navigation.
   
   
4. Inbox-driven workflow. No more jumping jumping back and forth to the Workday Wheel to complete tasks. A new unified in-box gives users a view of all notifications, with a preview pane and ability to take action right in the inbox.
    
5. Intuitive use. Viewing the user interface in action, it becomes obvious that most users will not need a lot of training on "what key do I press?" As in the past, they will need training on Workday's functionality and how it applies to their jobs. But the new interface should greatly speed the time to productivity for most users. 

These are just some of the points about the new UI. In addition, there are many functionality enhancements, which I'm not covering here.

To see quick overview of the new UI, check out this video by Workday's VP of User Experience, Joe Korngiebe (you can skip past Joe's opening remarks and start at the one minute mark, if you like). 

To be fair, other enterprise vendors, such as Infor, Oracle, and SAP, are making great strides in the user interfaces as well. Workday's most recent release provides another example of how life is getting easier for enterprise software users.

Update: Over at Diginomica, Dennis Howlett has his own take on Workday's new UI.

Related Posts 

Best Practices for SaaS Upgrades as Seen in Workday's Approach
Workday Pushing High-end SaaS for the Enterprise