When Should a Company Use ERP Best Practices Versus Custom Code?

Executive Summary

• Vendors have done an excellent job of selling the false construct of best practices.
• In this article, we answer a question related to best practices versus custom code.

Introduction

The following is a question we received through the website.

Under what circumstances should we code in the firm’s idiosyncratic way of doing something into our ERP instead of the best practice provided by the ERP.

The first thing to establish, is that best practices do not exist.

See our references for this article and related articles at this link.

The Evidence for The Existence of Best Practices?

This is explained in detail in the article How Accurate Was SAP on Containing Best Practices?, and the article How SAP Uses Best Practices to Control the Implementation.

Best practices have been thoroughly investigated in academic literature and have been found to be an illegitimate concept. The problems that arise include:

1. When a claim of a best practice is made, the evidence is almost never presented.
2. Who is the body that declares what a best practice is and what it isn’t?
3. What is often described as best practices are often very situational? That is they apply to a narrow area of application. Once even on environmental variable changes, the “best practice” is often not a desirable method.

In the history of ERP, best practices have always been merely asserted. No ERP vendor has ever made any attempt to provide evidence to support the best practice contention. And in fact, this is normally not required as people tend to accept claims of best practices without evidence. Unsupported claims like this are very common in the enterprise software space. Many vendors claim their software will lower TCO and increase ROI. They don’t bother to provide evidence.

Within the construct of best practices, is a mental trick, that is designed to get the provider to have the buyer accept whatever they have developed, and therefore without performing custom development. A vendor’s development is just custom development that is packaged and sold to multiple customers. When custom development is used at one company it is custom, when the same software is resold to a customer, it is now a “packaged solution.” But nothing magic occurred to the code itself when the code changed hands and gained customers.

As we cover in the article Why Custom Development Should Be Expected for Nearly All Applications, nearly all applications are oversold by vendors regarding the percentage of the requirements of a company that will be filled or met “out of the box.” ERP vendors are notably some of the worse offenders in this regard because they claim that their systems cover such a large area of functionality.

How Research Views Best Practices

I have reviewed many applications in my life and many ERP systems. I have been hired to compare Dynamics versus S/4HANA and perform many other comparisons as a researcher. There are parts of various systems that I like, and parts I don’t like, but would not propose that one particular functionality is a best practice.

This type of thinking seems to work in an executive setting or during a sales presentation, but has no basis or place in researching systems.

Let us take a look at a “good practice.” The method of planning a supply network called inventory optimization and multi-echelon planning (MEIO). This is an advanced way of planning a network that is based upon service levels. It is the most sophisticated method of planning that is used in this category. So is it a “best practice.” Well, in actual implementation, MEIO systems have proven too complicated to explain or to manage — and secondly, a basic assumption of these systems is that sales have some logical way of setting service levels. In fact, sales leadership does not have this. Extensive interaction with sales leadership at a number of companies led me to conclude that service levels by choosing high numbers that “feel good.” And of course to ensure a high in-stock position, which helps salespeople meet quotas. Salespeople do not care about costs, and this leads them to set excessive service levels.

So what was the effect of most MEIO software, even though it was based on strong mathematical principles? The answer is companies that implemented MEIO software were probably worse off because it was so expensive to implement these systems.

I have analyzed many problematic implementations at customers, that were sold on the basis of best practices and told they had purchased best practices software and all they needed to do was enable those best practices.

IBM Will Lie To You About Best Practices

I have also witnessed IBM sell best practices as a consulting service, and then months into the implementation have the client tell me that IBM did not seem to have any best practices. And many of the IBM consultants seemed to be making up best practices as they went.

One IBM consultant stated that..

“Twice a week delivery is a best practice.”

The IBM consultants were grasping at straws to come up with best practices, because their partner had oversold best practices consulting to the client.

Once again, the term best practice seems to find the most acceptance during the sales stage.

Trusting the Various Sources

Vendors are not a good source of information on what percentage of their applications can meet requirements. Given the pressure to “make the sale” vendor salespeople will invariably overestimate the coverage their application provides over any company’s requirements.

Secondly, salespeople lack expertise in matching functionality to requirements, and any technical support they do receive, such as a presales resource, may also not have had this experience outside of creating demos. I have worked with many presales resources and never found that they cared about the implementation. They viewed their job very narrowly, which was to showcase the application or database and please the salesperson.

Furthermore, presales report up through sales within virtually all software vendors. Therefore, they will feel the same pressure to overstated the fit between the application and the prospect or customer as the salesperson does.

Consulting Firms to the Rescue?

Unfortunately no.

Most consulting firms are vendor aligned, and therefore will also seek to overstate the coverage of requirements. They seek to staff resources on the software project. No software sale means no staffed resources. And a consulting firm cannot warehouse every possible software implementation skill, therefore, they seek to redirect their clients to products for which they have consultants to staff. Large consulting companies will often make recommendations for applications without even reviewing the client’s requirements. The requirements they reviewed is their requirements to get consultants off of the bench, and the margin of each consultant.

Companies cannot have either vendors or consulting firms drive the requirements mapping.

The Real Point of the Usage of the Term Best Practices

One of the fundamental issues is that the term is an evidence-free assertion. If something is “good,” then evidence should be presented as to why it is good. So, for instance, if someone proposes why I state that forecast error should be monetized, I explain why. It is to keep from focusing on low dollar value items. I don’t recall you saying best practice, so I am not sure how you have used it. But it is very, very frequently used to assert a good thing without evidence. Vendors and consulting firms (from the reading of many articles over the years), almost have an obsession with making assertions without providing evidence. It is easier for them to do that. Best practices allow a vendor to say that whatever they developed is the best — and is better than all other vendors (who by the way often also claim best practices) and that their functionality is also better than all internally developed applications — which are of course “legacy.”

Conclusion

There is no exact answer to the question posed above, but the first step figuring it out is debasing the myth of best practices. Best practices are a marketing gimmick. Custom development needs to be determined on a cost-benefit basis. Some areas of ERP functionality may not meet requirements, but they are “good enough.” In fact, all ERP systems really just provide “good enough” functionality. In each case when we have analyzed either specialized applications or custom development, they have readily exceeded the functionality provided in any area of ERP systems.

For example, we can easily replace the MRP functionality with our MRP Ninja, and it is easy to improve the functionality offered in MRP. Again, ERP vendors don’t really need to try very hard in any one area, because they sell a “suite.” They don’t compete on the basis of specific areas of functionality, or at least minimally.

Therefore, the assumption of ERP vendors is simply not correct, which is that they provide a broad amount of excellent or at least “good enough” functionality with minimum need for custom development or other applications.

In the early years of ERP they made even bolder statements, that their ERP systems would be..

The last system that any company ever needed to buy.

Now that that myth has been exploded, and it would engender snickers if stated in 2020, they tend to not make this proposal. However, the fact remains that back in the 1980s when few had experience with ERP implementations and usage, they did make this assertion. All of this is covered in my book The Real Story Behind ERP: Separating Fiction from Reality. 

But the final answer to the question posed is that requirements to be custom developed must be evaluated on a case by case basis. Non-fitting or marginal functionality matches in the ERP system or any other system for that matter should be identified early, by testing the system. Secondly, custom development should be expected, rather than accepting the entirely sales based assumptions that a high percentage of the functionality offered by the vendor will meet requirements.