The ERP Software Development Mistakes Made by Companies
Executive Summary
- ERP software development mistakes are a common part of the selection that drive to an inappropriate ERP vendor and that bring up problems in the implementation.
Introduction
One of the major errors in ERP readiness checking and software selection is underestimating the degree of software development required to make ERP systems work for companies. We cover the common issues below.
Our References
See our references for this article and related articles at this link.
Mistake #1: Selecting an ERP Selection Advisor Who Hides ERP Customization
For example, the major IT consulting firms. It is impossible for any of these companies (Accenture, Deloitte, Infosys, etc..) to claim independence, as each of them has public partnership agreements and practices with specific software vendors. They are so connected to ERP vendors that they collaborate with the ERP vendor to make the customer underestimate the necessary software development degree. Often the ERP selection advisor will not want to bring up the full complications of the implementation for fear of scaring off the customer from making a purchase.
Mistake #2: Not Considering Open Source ERP
One of the first things the ERP selection advisors will do is rule out open source ERP from the ERP selection process. The major IT consulting firms only want to implement commercial ERP solutions to make the highest profits. Even supposedly non-implementing advisors like Panorama Consulting rule out open source, as is covered in the article How Predictable Was Panorama Consulting’s Opinion on Open Source ERP?
Open-source ERP can be far more easily customized than proprietary ERP systems. Therefore by removing the open source ERP options off the table, the selection advisor makes the development work more costly and time-consuming. And this gets to the next mistake.
Mistake #3: Underestimating the Amount of ERP Customization
Both the IT consulting firms and the ERP software vendors make a big effort to delude the customer into thinking that there will be far less software development required of an ERP system than there will be in practice.
There are several reasons for this.
- The ERP vendor will, without fail, overstate how much of a match their functionality is for the requirements as they are trying to sell an ERP system.
- The IT consulting firm is essentially a proxy for the ERP vendor and will agree with the sales information that they provide to the prospect.
The point is to get the customer to buy and then worry about dealing with the repercussions of these false claims later. Once the customer begins implementation, they are locked in to continue, so there is virtually no negative business from the perspective of either the ERP vendor or the IT consulting firm about misrepresenting the coverage.
One of the worst situations is where the ERP vendor ends up prescribing the development language and environment. This is how SAP does things, and they state they require customers to use their proprietary language called ABAP. This simply pulls the customer into more dependency with SAP. Companies implementing ERP systems should insist that they control the development language and choose an open language to perform this development.
Any ERP vendor should allow open development languages, and not impose a proprietary language on the customer. Any ERP vendor that does is creating a liability. ERP development is going to have a significant impact on timelines and budgets. No ERP vendor can possibly offer a set of proprietary development tools and languages that are as efficient as what is available on the open market, where one can choose from a variety of tools and languages.
The high degree of software development required to get non-open source packaged niche solutions to work correctly is why we are a proponent of open source ERP for niche solutions. Look at ERPNext. The software is open-source, and they have easily addressed APIs.
https://erpnext.org/docs/current/api
It is developed in Python, a perfect language for math. They have project functionality already.
https://erpnext.org/docs/user/manual/en/projects
With something like this, which is free to use, now you can start with a lot of functionality, and at a low cost, add what you want because you can use a Python developer. If you want to customize 50% of it, you can do that. If you’re going to add a packaged construction management application to cover a specific area, you can do that. And it is already cloud. One can get an open-source ERP system that we have rated quite highly and begun using. Build a prototype based on your requirements.
Conclusion
The fundamental problem is that the customer, the selection advisor, the ERP vendor, and the consulting firm normally all underestimate the amount of custom development involved. This is on the project after project. The proposals of the coverage that the ERP functionality will provide as nearly comprehensive and wishful thinking make it a standard practice in the ERP industry to do this. However, some ERP systems are complicated to customize or now which to perform custom development. If a company goes into the selection under the impression that development will be minimal and that most of their previous system functionality can simply be retired (another exaggerated claim by the ERP vendor and their partner in the delusion the IT consulting firm), it means less time will be spent in analyzing each of the ERP systems to see which is the best at being integrated to custom development. There are many areas to analyze to answer this question. This includes the flexibility to use generally available rather than propriety development languages, the degree of lock-in to other development paradigms by the ERP vendor, the clarity of documentation of the ERP system, and a host of other factors that can allow an ERP vendor to be scored on the customizability of their systems. Evaluating ERP vendors in this one area is extraordinarily rare on ERP selections.
How We Do Things Differently
Our ERP analysis focuses on what the company is ready for and is not designed to simply onramp people to a cloud ERP system. And unlike all the ERP advisors, we are a true research entity. Being dedicated to research means focusing on what is true and using evidence to draw conclusions.