What to Do When ERP Turns SaaS
I once sat in at a sales conference for an ERP vendor and listened as the CEO explained sales strategy as it related to their ongoing movement to the cloud. He described the situation as one of configurability vs. customizability. There were some customers who could live with and work within the configurable features and capabilities of the base application as they existed “out-of-the-box.” These customers would be targets for the vendors single-tenant and multi-tenant cloud (or SaaS) offerings. For the subset of customers whose needs extended beyond the system’s base configuration, and were in need of custom functionality and integrations, the vendor would still offer the traditional perpetual license. This would allow customers with more complex needs to deploy their applications on-premise or in a private cloud.
That was the CEO’s perspective. Customers have their own perspective.
Configuration & Customization to Order
I recently talked with a customer who was struggling to implement the cloud version of an ERP to the vendor’s public cloud. The customer had purchased the software based on a set of assumptions, assumptions that were not instantiated by the vendor’s public cloud (or SaaS) platform. For one, the customer had come from a highly customized in-house suite of applications, and had a highly developer-centric approach to application implementation: if the app didn’t do what you need, customize it so that it would do what you need.
This approach is anathema to ERP implementations in general, and as a customer implementing on a public cloud SaaS platform, the shock was only intensified. The customization toolset to which they believed themselves to be privy to was less than advertised. And the documentation that explained just what was and was not possible was all but nonexistent. As the customer put it, his team’s vast C# skillset went largely underutilized.
Frustrations abounded on all fronts. Creating the necessary reports and labels, whether through Bartender or SSRS had been a disaster, as both the licensing and underlying architecture made for an untenable situation. Development and deployment of new solutions was cumbersome and time-consuming, as it required the vendor to perform the deployment every time a change was made. Similarly, the approved third-party applications that they had purchased in conjunction with the base package didn’t integrate as well as advertised, and they turned out to be even less configurable than the base ERP system.
Worse still, the customer was a user of the ERP’s product configurator module. This mode was itself a mini-development platform, but its features were largely server-side and thus greatly hampered in the vendor’s SaaS platform. The ability to use the module to look up and retrieve data, for instance, was greatly limited on the SaaS architecture, and the customer struggled to construct configurators to handle their complex product needs. Beyond functionality, the overall performance of the application was a drag. For many customers, the move from whip-fast, green-screen legacy platform to a contemporary ERP brings an unfortunate surprise when it comes to basic performance at a user interaction level. But in this case, it was magnified by the performance of the underlying cloud platform.
It was a disheartening conversation and I struggled to offer suggestions, outside of a reimplementation under a perpetual license model. The strange thing was that the customer did not really even come to me looking for help. He was really just venting his frustrations. He had learned enough of the application, its architecture, and the Service-as-a-Software (SaaS) deployment model to know that whatever help he might receive, he was constrained by the architecture to which he had bound himself. The cloud, whose name implies boundless opportunity and possibility, had become a crippling constraint.
Different ERP systems provide different levels of configurability and customizability. Some systems offer a basic platform with robust tools to use to build custom functionality with which to tailor the base platform. Others provide extensive configurability, as to avoid the need for additional tailoring. The systems that best combine configurability and customizability capabilities stand the best chance of supporting the needs of complex organizations. Even still, the unbridled requirements of a given company can often exceed the combined abilities of an ERP system to handle it.
This may necessitate the need for third-party integrations, to atone for liabilities in the base system. It may require integration to a pre-existing home-grown system, to address the specific needs of the organization. In the most extreme of cases, customers may look to modify the system’s source code to make the system do what it needs. At some point, it should be considered whether such extreme measures justify the investment in ERP at all. Sometimes it is simply a cultural conundrum: if an organization is unable to bend some of its needs to the will of the application, they may truly be better off with a homegrown system, and live with the liabilities that come with such a decision.
DRaaS for SaaS: When the Public Cloud Vendor Needs to Adapt
Beyond configurability and customizability, the questions of functionality and integration as they relate to an ERP system’s deployment model complicate matters further. The textbook cases regarding ERP customization nightmares from the 1990s all occurred within an on-premise context. The evolution of cloud computing had not yet thrown this new variable into the mix. But with the improvement of server processing power, the expansion of data centers, and the ability to pass larger and larger amounts of data over networks, ERP vendors were able to construct ERP applications that conformed to the public cloud software-as-a-service (SaaS) deployment model.
This shift toward a SaaS model allowed for highly available and highly scalable ERP solutions, whose subscription-based model provided ERP services for a monthly rate. But in doing so, the features and capabilities that these vendors offered were often scaled back significantly, when compared to their on-premise, perpetual license predecessors. Similarly, the integration capabilities of such platforms were drastically reduced to the web APIs that the ERP SaaS platform supported. This made the extension of the application’s capabilities much more difficult to achieve. For customers needing robust and expansive ERP functionality, as was the case with my customer above, the results of a mismatch between business requirements, customization tendencies, and deployment models can lead to a perfect storm of failure and disillusion.
How does one avoid such a problematic situation? To begin with, there are some key questions to answer at the time of software selection before you’ve signed the dotted line:
- Firstly, you need to understand the background of your own organization. Are you coming from a standard system or from a highly-tailored home-grown system? Are your business requirements of the variety that are commonly managed by a packaged system? Is the shift from your current system to the future system a small shuffle or a quantum leap?
- You also need to understand your own expectations for the new system: are you trying to fit your organization into the system, or are you trying to tailor the system to fit your business? Do you see an ERP system as a packaged application or a custom development platform? Companies differ in this approach, and this greatly affects how they intend to use the system, so you need to be explicit about your expectations.
- Finally, it should be noted that in many cases, a software’s public cloud version will differ markedly in functionality from its cloud cousin. As such, be careful to understand the version from which the Sales Engineers are basing their demonstrations. If you’re looking at a cloud deployment, ensure that the sales team demonstrates the application, as you will experience it as a customer, and not the products more robust, on-premise version.
Cloud services are as unique as business processes, and SaaS companies / SaaS, or public cloud, applications aren’t always as “internet connection, web browser, go” like they’re often advertised to be.
If your corporate office is mandating some form of “cloud” solution, understand that not all clouds are created equal. A system’s deployment mode is not as simple as choosing between an on-premise dinosaur and a public cloud popsicle. One significant alternative to the SaaS vs on-premise dichotomy is a private cloud deployment. Private cloud allows an ERP customer to install an on-premise, perpetual license version of the software, but in a virtual cloud environment. This allows customers to leverage the full set of capabilities, functionality, and integration opportunities that the software offers. For customers bent on heavy tailoring and customization, this allows them to leverage the full set of tools tailor the application to the customer’s specific needs. Further still, this model makes integrations much easier, as it provides access to the application and database server layers, as needed, which can greatly simplify integration architectures.
Cloud Customs of Custom Code
A company’s implementation story should be neither a laughable comedy nor a disheartening tragedy. With planning and discretion, companies can formulate a successful narrative. Are you in search of an ERP story with a happy ending? Talk to us, and we’ll spin you a yarn.
You can consolidate everything from software licensing and updates to hardware inventory management with EstesCloud Managed Application Hosting. We offer custom solutions for web-based transactions. We might not be famous like Amazon web services, but our private cloud, hybrid cloud, IaaS, and PaaS solutions offer you the personal attention of world-class IT and ERP consultants.
ERP Deployment Options & Cloud Services
Infrastructure as a Service
Platform as a Service
Software as a Service
In pure form, a public cloud deployment limits your control and troubles cybersecurity and compliance management efforts. Know your enterprise resource planning options before you deploy. The cloud should be one of your most powerful tools as you move your company forward. But cloud computing terminology is hazy, and cloud migration can be a step backward if the deployment model isn’t a good fit. Do you understand your cloud options? Our cloud ERP experts can walk you through the cloud spectrum and help you find the best platform for your business. When a complex ERP like Epicor’s Prophet 21 is going through client-server architecture changes, EstesGroup consultants are here to answer questions so that you can focus on your business, rather than on its supporting software.