When Should You Buy Packaged Software Versus Custom Development?

Executive Summary

• Consulting firms and vendors present packaged software as if it is always the right decision.
• This article questions that viewpoint and addresses the financial bias of those that propose it.

Introduction

The overall software industry has become incredibly oriented around packaged solutions over custom development. The primary reason for this is not any superiority of packaged software but the packaged solution vendors’ financial bias and the associated consulting partners that make so much money from packaged solutions.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

The Logic of Packaged Solutions Versus Custom Development

In this book, Software Wasteland, Dave McComb lays out the criteria and logic for when it makes sense to buy a packaged solution versus performing custom development.

“You should buy package software when:

1. You can use it as is with no modification and simple customization.,
2. In contains internal logic that far exceeds your own organization’s ability to develop.
3. It has simple or uniform interfaces that could be made to conform to your firm’s data model, rather than forcing your to adopt yet another variation.
4. The purchase price is at least ten times less than your estimate of what it would cost ot build the functionality in house.
5. You have real time pressures that would mean the time to implement would be a key factor in an implementation.” – Software Wasteland

The Story of ERP

There is a multi-billion dollar industry all focused on forcing companies to purchase packaged solutions. What SAP or Oracle or Accenture, or Gartner do not want buyers to even think about is under what circumstances do packaged applications made sense. This is true even though, after decades, the following has been proven true.

It was recognized in the 1980’s that integration between applications was a problem, and that one potential solution was to have single integrated database. If you could build all of your applications on a single database, there would be no need for integration. Thus was born ERP. As one watches the evolution of the ERP market, a few fascinating trends emerge.

First, the systems became more and more complex. Each generation added features and tables to cover more and more possibilities “out of the box.” The data schemas have become immense. A typical SAP installation now has 90,000 tables and 1,000,000 columns. – Software Wasteland

This is negative for database management. This is referred to as the monolithic design and leads to inefficient custom development and data management.

Why Has the Scope of a Typical ERP Implementation Shrunken?

Another fascinating thing is how the scope of an ERP project continues to shrink even as the cost of the project increases. It used to be that an ERP system was firm-wide, and covered most of the functions touched by the supply chain and the manufacturing process and order to cash cycles.

Nowadays, most ERP implementations are single function. We often see an HR implementation touted as an ERP implementation or a Finance project as an ERP implementation. – Software Wasteland

This feature was noted in our analysis of all of the S/4HANA case studies that form the basis of the S/4HANA implementation research. (this is paid research, but the description of the research be seen at The S/4HANA Implementation Buyer Intelligence Highlights) Many of the case studies only implemented the finance module of S/4HANA. Unless one is a bank or insurance company, this imposes high duplicate integration costs as it means the finance module must be integrated into other applications. At a later point (in many cases, at least), those integrations will have to be discarded.

This brings up why an ERP system is being implemented if only part of it is being implemented. The point of ERP is to implement most of the system — so that it is “integrated.”

Would You Like to Implement a Sliver of an ERP System?

Indeed, more and more ERP implementations are now with firms that don’t manufacture anything. The current growth market for ERP systems is government agencies, which are they ill-suited to address. The amazing thing is that very few large firms have managed to get even all of their manufacturing-related functionality onto a single integrated database. We rarely see more than around 20-30% of the core functionality managed by the ERP system. What this means is that the original benefit (of avoiding integrated costs by having everything on the single database) have not been achieved and the firm must still invest a great deal in integration. The sad thing is that having chased the ERP dream, they are now saddled with an environment that is very hard to integrate because of its internal complexity. – Software Wasteland

This also came out in the S/4HANA implementation study.

1. An amusement park implemented S/4HANA.
2. A Turkish grocery chain implemented S/4HANA.
3. Banks implemented S/4HANA.

Why?

ERP systems were originally designed for manufacturing entities. Now it seems the plot has been entirely lost, and they are being implemented in many industries for which they were never designed.

If you have a Ferris wheel on-premises and sell tickets to rides, should you be implementing an ERP system? Amusement parks have attractions that have to be maintained. The procurement is all indirect (there is no MRP and no production orders), the sales orders are straightforward (most often, people show up at the amusement park window). How does this scenario call for an ERP system? 

I was about to joke by saying that consulting companies would sell an ERP system to an assisted living facility. Still, I quickly realized that the joke is not usable because the German assisted living company Diakonie Michaelshoven did purchase S/4HANA.

These seniors can feel safe knowing that their supplies and furniture will be ordered through S/4HANA. However, they will have to pay more because S/4HANA or any ERP system, for that matter, does not match the requirements of an assisted living facility. The nice seniors probably won’t mind, as long as much of the excess goes to Accenture or IBM. 

Accessing SAP’s Finance Module

The proposal for using ERP, even if only for one module, is that some ERP systems have very mature finance modules. This is true of both SAP and also Netsuite. This point is brought home in the following quotation.

In the criteria pro packaged solutions, IMHO there is the reason missing why so many companies use SAP FI even outside the producing industry, at least in Germany. The software is proven, accepted and kind of certified the obey regulations, here correct accounting, so you don’t have to expect trouble with financial auditors. It would be a large effort to get this status for custom development.

In Germany there is not yet a sufficient widespread alternative. German tax law is probably special. But this is only a question of a few years until SAP is losing this  – Dr. Rolf Paulsen

As I know nothing about German tax law, I will leave that to others to determine. However, there are several fine pure finance applications such as FinancialForce, which we review at the Brightwork Financial Force MUFI Rating, and Intacct, which we reviewed at Brightwork Intacct MUFI Rating.

The issue is that more and more ERP implementations are using less and less of the ERP footprint. This is showing cracks in the facade of ERP systems being integrated systems that can meet all of a company’s needs, and in the words of ERP salespeople (at least up until the 2000s), were to be “the last system any company would ever buy.”

Customization is Ok….if You Are Customizing a Packaged Solution

These entities will support customization, but only when that customization is applied to packaged applications.

The website Diginomica is paid by just about every major software vendor in the enterprise space. They write basically whatever promotes vendors.

ABAP was a brilliant invention by co-founder Hasso Plattner’s team in the days of R/2. That’s pre-1992 to you. It was brilliant because it provided developers with a relatively easy (if, by modern standards) verbose way of building applications around the SAP core.

ABAP is only meant to work directly with SAP systems. This has the side effect of creating a closed – as opposed to open – development environment. It is, in my view, the primary technical mechanism by which SAP locks its customers into its own environment. At the time it was being popularized, there was no internet and there was very little by way of integration as an imperative. So that lock-in was not obvious or even that important.

Actually, ABAP is a simple language, but it is also a highly ineffective language. It is only used on SAP customers, and any other company would have to be bonkers to use ABAP because it is so uncompetitive.

If ABAP were actually good, people outside of SAP would use it. But SAP does not exist outside of SAP circles. This means that SAP forced an inefficient language onto customers. It means that all customizations and integration costs far more than they needed to because of this development language decision on the part of SAP. 

The only logic for using ABAP seems to have been intended to increase account control over SAP’s customers.

Who Was ABAP and Advantage For?

The problem is that SAP’s massive advantage of the 90s and 00’s has suddenly become a liability. The rise of the internet as the primary transport over which we all get our ‘stuff,’ the emergence of cloud, the development of SaaS, the emergence of easy to use, open source platforms and, most recently, the explosion in API-based microservices fueling the XaaS economy has left SAP vulnerable.

First, ABAP was always a disadvantage for customers — but this article, funded by SAP, does not mention this fact.

On the one hand, the closed nature of SAP systems continues to provide the company with an advantage and one that it has tried to leverage through the concept of ‘indirect access.’ We have debated that issue here many times and it is a topic that remains very close to buyers’ hearts.

Right, but what about the customer. Notice how the customer is entirely left out of this discussion. Not only did SAP saddle companies with inefficient applications, but it also mandated a closed and inefficient programming language, as we covered in the article Why SAP Customers Followed SAP’s Advice on Coding in ABAP.

Indirect access is another liability for customers based upon illegal behavior on the part of SAP, as we covered in the article SAP Indirect Access as a Tying Arrangement Violation. Diginomica has been a primary media entity that has distributed false and SAP sided information about indirect access. SAP used Diginomica to distribute PR information, as we covered in the article SAP’s Recycled Indirect Access Damage Control for 2018.

Let us now add up the ways SAP bamboozled their customers.

1. They sold them an ERP system to a large percentage of their customers that would have been better off staying with their previous systems (i.e., using custom-coded systems and then updating them.)
2. They mandated one of the least efficient and least capable development languages to their customer, massively increasing the cost of implementation to customers (which companies like Deloitte and Accenture quickly profited from)
3. They punished customers with the illegal concept of indirect access — to keep customers away from purchasing from vendors that would better suit them.

And to Diginomica, the media entity that like Gartner is paid to promote packaged solutions over internal development and open source options (as we covered in the article How Gartner Undermines Open Source for its Own Benefit), this is all great but has only recently (ABAP) that is become a disadvantage because of you know…the arrival of the Internet. But this is a disadvantage only to SAP that Diginomica, the fact it has been a long-term disadvantage and the very definition of technical debt to SAP customers is completely irrelevant to Diginomica. Neither Accenture nor Deloitte (which makes money off SAP projects), Gartner or Forrester or TechTarget or ComputerWeekly (which takes money directly from SAP) will cover these topics.

Conclusion

Packaged vendors and their coterie of consulting firms, research, and media entities have pushed out most custom development — making companies think the only reasonable choice is to purchase packaged applications. However, as per the introduction of this article, this is the opposite of the truth. Applications have their place, but they have come to dominate IT in a highly wasteful way. Interestingly, the analysis of whether to use custom development for requirements versus purchasing a package is actually deliberately dissuaded.