Do We Really Need Another Acronym? The Case for “ERPaaS”

Believe it or not, it’s been over 10 years since Amazon & Google launched their first cloud products, and what started out as fairly basic infrastructure offerings (IaaS) have literally transformed the software industry.  Today we have development platforms in the cloud (PaaS), applications on demand (SaaS), virtualized desktops (DaaS), and a whole host of specialized services available via a subscription model.  It seems like everyone is pushing to get their customers “to the cloud”, and ERP heavyweights like SAP and Oracle are no exception.

Improvements in technology are clearly a primary driver of this shift, as service availability, performance, and security have all reached levels that make the cloud model attractive from a risk/reward standpoint.  When you combine these advancements with the promise of a lower total cost of ownership (TCO), it’s easy to see why recent studies project that 80% of enterprise IT will be cloud-based by 2020.  Quite simply, the big hardware and software vendors are able to leverage economies of scale that individual organizations just can’t match, all while offering higher levels of agility, efficiency, and predictability.  At least that’s the theory.

In his recent blog on key protections you should build into your SaaS contracts, Adam Mansfield makes this observation:

“SaaS vendors promised there would be no more drawn-out implementation cycles and large infrastructure demands; instead, users could have new or upgraded tools and modules within a few weeks, at a fraction of the cost and with a higher degree of flexibility. More traditional (and disruptive) implementations and upgrade cycles would become a thing of the past, giving IT departments more time to focus on business process improvement and other high-value, strategic initiatives tied to their core activities and competencies.”

When it comes to “ERPaaS”, though, these promises remain largely unfulfilled.  It is not uncommon for “ERPaaS” implementations to last a year or more, and large, global organizations can expect their S/4HANA implementations to take roughly two years.  Why the continued disconnect between the vision and the reality?  Because ERP offerings aren’t really SaaS.

Not All SaaS is Created Equal

The proliferation of “smart” devices over the past decade has made “apps” part of our daily lives.  Mobile phones continue to be the primary catalyst, but today we find “apps” embedded in everything from cars, to refrigerators, to home automation systems.  They are literally all around us, thanks to the miracle that is SaaS.  We simply download the app and then basically forget about it…at least until we lose our network connection.

The reason that the SaaS model works so well for apps is because they are effectively utilities.  You are a pure consumer of the system: you have no control over the application’s features, how the app is built, or how it’s delivered.  All of those details are handled by someone “in the cloud”, and if you find any aspects of the apps’ performance unsatisfactory–including whether or not its features meet your needs–you simply uninstall it and find a new one.  The only part of the equation that you “own” is your data.

When you think about the various service models from the standpoint of what you control/own versus what the provider controls/owns, you get a matrix like the one below:

Now consider S4/HANA versus Office365 in light of this matrix:

• Both are billed as “SaaS”, but there is a clear difference between running Word365–which runs exactly the same for all users everywhere–and S/4HANA, which is intended to be configured to match your business requirements.
• With Word365, the only thing you own are the files you create, whereas companies buy ERP platforms with the goal of implementing solutions that differentiate them from the competition.  You own the application as well as the data.
• You are probably going to invest a significant amount of effort integrating your S4/HANA solution into your existing application landscape.  This is because even though you own the data in the ERP platform, you can’t leverage it in other/legacy applications without building the integration yourself…which then becomes part of the solution.  With Office365, integration is a function of the file formats supported by the applications, something which you neither control nor build.

In short, since you have to build the “Application Functionality” layer in and around your ERP platform, you’re dealing with PaaS rather than SaaS.   Suppose this was not the case.  If S/4HANA functioned exactly the same for every organization that implemented it, then it would be true SaaS…and SAP would probably be out of business.

Ownership Means Accountability

Granted, ERP platforms are more sophisticated than general-purpose development platforms like .NET or Java, but they are still platforms, nonetheless.  The value that they provide–when compared to developing a purely customized system–is that they have addressed most of the “basics” for you.  In other words, they have “solved” the parts of running a business that are essentially standard so that you can focus your energy on what makes your company unique.

Practically speaking, this means that “ERPaaS” falls somewhere between PaaS and SaaS,  since you own not only your data, but also the application configuration/functionality.  Where things get complicated with ERPaaS is that the platform dictates, at least in part, the functionality of your solution:

This shared ownership of the application functionality has some important implications on the effort required to implement, maintain, and support your application.  Here are just a few:

• Integration:  Bad data erodes the value you get from any system, but in today’s cloud-based world the stakes are even higher.  Why?  Because as your “ERPaaS” system interfaces with other “HRaaS” or “CRMaaS” systems, it’s neither possible nor feasible to build workarounds into these systems to deal with data errors.  That doesn’t mean that data problems go away, they just aren’t something that the IT department can insulate the business from.  Make sure you implement rigorous data governance processes that address not only ongoing data maintenance, but also data checkups.
• Upgrades: “Innovation cycles” sound great in concept, since your organization is able to benefit from improvements in the base platform sooner rather than later.  However, your ERPaaS provider probably receives as much value from the relationship as you do simply by virtue of linking your company to their development cycles. Backward compatibility is expensive for both parties, and they are highly motivated to get you on their schedule and not vice versa.  This cadence is unavoidable with cloud solutions, so be sure that you set aside adequate time to fully test your solution with each release — including the integration with other components of your application landscape.
• Customizations: Customization has always been expensive, but it is even more costly in a cloud-based architecture.  Quite simply, you can’t tweak the platform and expect things to go smoothly over time.  Will your customization work when the next innovation cycle comes along?  Furthermore, even if you develop enhancements within the constructs that are “approved” by the provider, will the provider still stand behind the contractual language around system performance/SLAs?  If you are considering customizations/enhancements of any kind, be sure you are working with the provider to ensure forward compatibility of the solution as well as to secure commitment to honor their contractual obligations.

Conclusion

Without a doubt, the cloud is here to stay; but contrary to the headlines it hasn’t “changed everything.”  Application development still takes planning, discipline, and time, so if you are embarking upon ERPaaS, make sure you are prepared to dedicate the resources required to make it a success.  Even though there is tremendous value to be realized from leveraging cloud solutions, long-term success with ERPaaS (or HRaaS, CRMaaS, etc.) still requires long-term thinking during the selection, contractual, and design stages of an implementation.

Follow me on Twitter @sstamp_ue.  Find my other UpperEdge blogs and follow UpperEdge on Twitter and LinkedIn.

Related Posts

• Beware of Dante’s (ERP) Inferno
• Twelve IT Project Disasters Demonstrate There are No “Safe” Choices 
• Taking Care of Business: Your Business Case Isn’t Shelfware
• Don’t Bite Off More Than You Can Chew: Too Much Change Is a Recipe for Project Failure