Why ERP's are wrong for NGOs

The first edition of this paper was written in May 2012 and updated in May 2016.  It has since been a part of the IT Think Papers on my web site.  Though some of the figures have changed (some better and some worse), the conclusions still ring true for the nonprofits I continue to follow, now as faculty member of a university, where I teach IT leadership and management.  I’ve made further revisions to anonymize portions and rerelease it here.

Considering an Enterprise Resource Planning system (ERP, for short) is a natural event for nonprofit organizations at a certain stage of their development.  International NGOs (INGO) such as CARE, IFRC and Save the Children and UNICEF have had similar experiences with varying degrees of success and shortfalls.  Why are such run-the-business systems so difficult?  Here are some reasons to consider :

1. Too expensive. One of the first UN organizations to complete an ERP project spent an estimated $20M+ to roll out SAP to their 120 country offices.  Even limited ERP projects, with nonprofit discounts, take $2M+ to complete.  80-90% of the costs are for business process and implementation consulting.
2. Takes too long.  The typical ERP project at large NGOs takes 2.5 years or more to complete.  For 5-year strategic plans it means that the impact of the new system is limited.  One INGO  spent 3+ years to complete its donor ERP, from Blackbaud, missing its strategy window.  Confounding this is that technology changes and user needs are evolving faster than 3-year ERP development cycles, ensuring that the system once released will likely be out of date.
3. Failure rate is too high. According to the well-known Standish Chaos database, fully two-thirds of large IT projects fail.  One-third fail outright, while one-third are over time or budget.   A recent McKinsey report verifies this .  Smaller, chunked-down IT projects have higher success rates.
4. Don't meet financial objectives. The Nucleus ROI study found 57% of large SAP projects (a leading ERP) don’t achieve the ROI cited in the beginning as the justification for doing the project in the first place.   Furthermore, an analysis of 100 corporations that have implemented SAP shows that this group has significantly lower profits than peers. 
5. Too hard to change. The pain and effort to upgrade business processes and customize the ERP system results in a system that is resistant to change, in terms of time, cost and will. As a result the ERPs that often replaces a legacy system (or three), becomes itself a new legacy system.
6. Not optimized for the web. Many of the large ERP systems, like SAP, have not been optimized for the web and browser world.  Web features have often been bolted on to antiquated back-office architectures. Web users notice the difference from popular web apps immediately.
7. Almost impossible to please all departments. Given the enterprise nature of ERP systems, they cut across many departments.  Getting many departments to agree on features and functions often means a tendency to lower common denominators of need rather than an optimal solution for an individual department needs.  And yet each department wants its needs met, which often results in a high degree of customization.
8. Expensive to customize.  The short-term cost to customize large ERP systems is high, with as much as 50% of the project costs going to the analysis, definition and development of components.  However, the longer-term cost may be even higher, especially if the customizations are many.  Each upgrade to the system that the vendor provides will most likely require an upgrade to the customized components, at the organization’s cost.  This often results in a lagging behind the current market system, which gets worse over time.
9. User satisfaction is lower than for SaaS applications.  Applications that are built for a web-centered world are more likely to meet user’s expectations for how modern applications should work.  Users increasingly come to the organization with a strong experience base of using web-based applications in their education and personal lives.  ERP systems often do not measure up and don’t function in a browser as users expect them to work.
10. Many INGOs have a poor record of implementing large systems.  At one such organization, an HR SAP project, Logistics project and Web Reconfiguration project were all cases in point where large applications were over-budget and over-time estimates by significant margins. One  could take the approach of investing more in getting big systems right, or one could take the approach of chunking projects down to more fit-for-purpose solutions.  Fortunately, the organization chose the latter.
11. Not share-able with Field Offices.  For ERPs to be shareable across organizations, their customizations often need to be repeated for different country/location needs.  There is no multi-tenant model for ERPs that is comparable to SaaS applications, where each feature enhancement is made to the core code available to all.
12. Total cost of ownership (TCO) of ERP’s is affordable by only the largest organizations. For-profit organizations typically have 5 times more IT spending power per employee than large nonprofits .  With 25% of systems cost as a typical annual maintenance and support estimate, a $1M system can generate $250K in recurring costs, and this figure rises with the degree of customization.  Over five years, the TCO can more than double the cost of a project.  My advocacy position--with a bit of intentional hyperbole-- is that traditional ERPs will bankrupt Nonprofits and field and country offices, customized ERPs even more so.
13. The data integration model of ERPs is overrated.  One of the strongest selling features of an ERP is the shared database that underlies the system, providing the highest amount of systems and data integration.  However, the real-time integration needs of many organizations are rare.  If the data definitions are clear, the transfer of data among smaller applications is usually small enough for infrequent transfers of information.  Sometimes a manual transfer of data is sufficient.  Often a simple export and import of data will do. One-way integration may be needed.  Two-way integration should be avoided.  The key questions are: how often does the data change, how much of the data changes, and how many users are impacted?  A small scope demands a small solution.

As a result of these considerations, the strategic direction for applications at NGOs is clear.  The arguments are stronger for small, fit-for-purpose, web-based, loosely coupled applications.  A more agile organization is built on systems that are quick and easy to change, and faster to deliver.  Those applications that meet a specific need are more likely to succeed.  This is the most prudent use of NGO donors’ funding.

"The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated."