Sometimes, a really good idea gets pushed too far with really bad results. For example, someone once invented a bathroom computer workstation so you can skip the newspaper and roll a computer workstation in front of you and use the Internet, check emails or write a memo to staff or family. There’s nothing wrong with inventing a computer workstation, but designing it for bathroom use is taking it too far. It’s the same thing with a multi-tenant ERP solution – multi-tenant applications make sense, ERP solutions make sense, but a multi-tenant ERP solution is a fundamentally bad idea.
The ERP Cloud News article “Multi-tenant versus Single-tenant ERP – a comparison” defines multi-tenant application, in simple terms, as a single piece of software shared by multiple users. Internet applications you use every day – like Gmail from Google – use a multi-tenant approach to make it easier and faster to deliver new features (and fixes) to all users of the system at the same time. Based on some clearly successful multi-tenant applications, some analysts and ERP solution providers have erroneously concluded that ERP solutions must be multi-tenant applications to be successful.
There has been a lot published on every side of the argument. Phil Wainwright, at ZDNet, argues passionately that a multi-tenant architecture is as critical to a SaaS application as the WinTel standard is to a PC. Josh Greenbaum, from Enterprise Matters, disagrees completely, and says it’s really just a vendor issue. Meanwhile, Oracle’s Larry Ellison is trying to change the definition of cloud computing to suit Oracle’s marketing objectives. The question here, however, is whether a multi-tenant architecture is a good idea for an ERP solution delivered through the cloud.
The primary benefit of a ‘complete’ multi-tenant architecture is efficiency, with the presumption that greater efficiency translates into cost savings for the vendor that are passed on to the customer. (Even this simple conclusion is likely wrong. The application software market is not very efficient – just look at the profit margins of Oracle and SAP and try to justify the view that cost has anything to do with price.) The gains in efficiency come from the ability of the vendor to perform software upgrades and system maintenance one time for the entire community of users, rather than going through the effort to perform upgrades and maintenance for each customer’s system separately. Clearly, this is a more efficient way to approach the problem, but does it work for ERP solutions?
Technically, yes, but one of the primary responsibilities of an ERP solution is to account for the flow of money, materials, and time through a modern organization. With this comes the responsibility to manage and present the financial statements of the organization. I emphasize ERP solution – not software – because ERP software doesn’t make the financial statements accurate and complete. ERP software enables the policies, procedures, and processes of the organization to be consistently applied with reliable results (like accurate and complete financial statements). The financial statements are accurate and complete when the organization’s policies, procedures, and processes are effectively adhered to by the organization’s people. The people held accountable for the policies, procedures, and processes (and for their organization’s ability to adhere to them) are the senior managers of the organization – not the software vendors.
This distinction between software and solution is critical. The SOX regulations that govern every public company in America (and many of the private ones) don’t care much about whether the software is on-premise or hosted, whether you pay a lot up front or less each month, or whether the solution is single or multi-tenant. In the words of Renee Boucher Ferguson at e-Week Magazine, get your “…house in order for compliance, lest your company executives wind up in jail.” In plain English, management must be able to assure shareholders that the policies, procedures, and processes used to generate the financial statements (on which investment decisions are made) are being adhered to, or face legal penalties.
As a result, ERP customers facing SOX regulations are reluctant to upgrade their systems without careful planning. They must carefully consider each change to a procedure or process caused by the upgrade, review and document the internal changes that will result, and have the changes reviewed and approved by outside auditors. Consequently, an upgrade to financial systems (and any systems that affect the financial systems) is frequently held off until a fiscal year end, when newly documented and approved processes and procedures can be effectively deployed to the staff. The truth is, many organizations today would prefer not to upgrade their financial solutions until the benefits of the upgrade to their organization dramatically outweigh the cost and grief of upgrading and deploying new the policies, procedures, and processes that go with it.