- ERP systems that are sold by proprietary vendors result in a high degree of control over the customers by the vendor.
- Open source ERP vendors do not impose these highly expensive restrictions on customers.
Open source ERP pays so many dividends because ERPNext does not control customers for how they adjust the system. This is one of the great underappreciated benefits of open source ERP. If you go with any of the closed source ERP options, you get locked in. Now you are taking orders from the vendor in terms of how to manage things. This is what Oracle did to companies in the database space. This article may interest people, and it describes what happens when you, as a customer, get locked into a proprietary development language by a vendor.
See our references for this article and related articles at this link.
Getting Customers to Disinvest in Their Systems Under False Assumptions
ERP vendors got companies to disinvest in their own systems — which were custom-designed for their needs. They convinced them to implement their ERP systems instead — an then when the claims they made about being able to meet nearly all requirements “out of the box,” (as we cover in the article The Myth of ERP Being 90% Out of the Box) they then baited and switched them, and got these companies to migrate their “legacy” systems into the ERP system as we cover in the article Why SAP Customers Followed SAP’s Advice on Coding in ABAP.
Hiding How Much IT Departments Take Orders from Software Vendors
All around the world, IT departments try to hide the degree to which they drank the Kool-Aid on going with proprietary vendor code, related applications, etc.
Purchasing More Than One Should from One Vendor
Another benefit is you don’t have the ERP vendor ramming other applications they have down your throat. This article describes how ERP systems became a Trojan Horse for ERP vendors. ERP vendors and consulting companies had a way of locking in companies to ERP systems once they had agreed to implement ERP systems on the basis of false information, as we cover in the article How ERP System Was a Trojan Horse.
This also led to the increased acquisitions by ERP vendors like Infor and Epicor, who went shopping for vendors, that they could then ram down their customer’s throats, to copy Oracle and SAP’s account control.
What is Wrong With Purchasing from a Closed System ERP Vendor?
Closed source ERP vendors do lock in their customers. They do it with their behavior, but they also tell me they do it. That it is a specific strategy to do this, and they do it because it is profit-maximizing to do it. They don’t publish this fact, but they follow it as a strategy. A smaller ERP vendor that has not acquired other vendors has less of an ability to do it. Still, the ERP system is particularly susceptible to lock-in — because it is so central to what the company does.
If people and organizations were not corrupt, then buying from a closed system from an ERP vendor could work.
But that is sort of the problem.
I think the answer to why buying into a closed system is bad is because power corrupts. This switches the power over to the vendor/consulting firm. This ends up with less competitive solutions being used alongside the ERP system.
And this gets to how companies run their businesses. The corporate charter is to maximize profits. Not to look out for the interests of one’s customers. There is no way around this — this is precisely what corporate charters say. If one were buying a closed source ERP system from a non-profit, then it could be different.
But that is not the case.
This gets into a topic of, for example, why governments purchased closed source software when they are supposed to be in the public domain. Why are tax dollars going to purchase closed source options, when the US Government has so many excellent custom-developed applications like VistA at the VA, the Social Security system (mostly Cobol based systems running on mainframes that the OMB complains about their age — without observing that the systems have been running for four decades and providing good service levels).
Open Source ERP
Purchasing closed source ERP systems is particularly problematic because, in the vast majority of instances, there is a far lower coverage of requirements by the ERP system — which means that ERP systems tend to be the most customized of applications. That is, cost-effective and efficient customization is one of the most important, if not the most important feature of any ERP purchase.
A major part of closed source ERP sales proposals is to convince the prospect that the system will require very little customization. We cover this in the article The Myth of ERP Being 90% Out of the Box. After the sale is made, and because normally so little analytical effort is put into fact-checking claims by the vendor, the beginning of the implementation is where the customer learns that the discrepancy between the real functionality of the ERP system and the requirements is much larger than originally anticipated. In many cases, vendors will try to cover up this deception by using the term How SAP Uses Best Practices to Control the Implementation. This is used to switch the narrative and pivot, such that the percentage of fit of the application to the requirements is “not the issue” but that the customer should be using “best practices” (that is functionality in the ERP system that does not match requirements). No evidence for the functionality being a best practice is ever given — and in fact, it cannot be, as best practices do not exist as we cover in the article When Should a Company Use ERP Best Practices Versus Custom Code.
Closed Source ERP Vendors
In essence, closed source ERP vendors that have many products, such as SAP, Oracle, Microsoft, Epicor, Infor, SAGE, and others — know that they will force poorly fitting other applications down their customer’s throats, but that is part of their strategy. It is profit-maximizing, and they don’t care. This is one of the many liabilities of not only using closed source ERP software but also of purchasing closed source ERP software from a vendor that has many applications to sell. In nearly all cases, the applications forced don’t have much to do with each other. In the case of Oracle, they own a hodgepodge of applications that the vendor happened to purchase. In each case, the applications are less prominent than they were when Oracle made the acquisition.
In the case of SAP with SuccessFactors, if SAP had not come to terms with SuccessFactors for HR, they would have simply purchased another HR vendor and would be crowing about how XYZ vendor was far better than SuccessFactors, which they (in an alternate universe) were simply unable to acquire. The question is rarely asked —
Why should the ERP vendor have influence over other applications or databases or middleware which are purchased?
Customer Lock-In as a Business Strategy
If we look again at Oracle, this was a company that acquired ERP vendors like JD Edwards and Peoplesoft, due to its monopoly profits from its database. However, why does it make sense to purchase one’s ERP system from their database vendor? Under the proprietary model, the vendor only makes their own ERP system work well with their database.
This is, in fact, the case with SAP, with the introduction of the HANA database, SAP made the reverse argument that companies should buy their database from their ERP vendor. And one of their arguments was that their database would work better than any other database with their ERP system. Extensive research by us later exposed this to not only not be true, but for the opposite to be true.
Closed source ERP systems are dangerous for the well being of customers. Software acquisitions do not benefit anyone but the software vendor, and if US antitrust law were enforced, they would be disallowed. Software acquisitions, like other acquisitions, are monopolistic attempts to control the market and control customers by focusing on deceptive and account controlling sales strategies versus the product. Software acquisitions are a way for the largest software vendors to apply monopolistic power to the software market.
While they don’t have to have this outcome, more often than not, the closed source ERP vendors use the sale of the ERP system to push in other applications that are even less appropriate for their customers, based upon exaggerated claims around integration. The more the software that a company purchases from one software vendor, the more control that vendor assumes over the customer. The vendor salesperson tends to view software acquisitions as “belonging to them.” Firms with large stables of products to offer can often combine many applications into bulk purchases. This has two important features.
- It causes each subsequent application to be even less critically analyzed as there tends to be a “home field advantage” with the incumbent ERP software vendor.
- It tricks procurement and IT directors and CIOs into pushing for purchasing suites — even though they are bad for customers because they allow each to brag about how they saved money in software acquisition. Both procurement (which is primarily measured on acquisition costs) and IT directors and CIOs continue to think this way, even though both TCO estimates by Brightwork R&A and other TCO studies place the software acquisition percentage at only 10% of overall TCO for software projects. When I participated in sales proposals, I found it was extremely rare for prospects to focus on anything by the initial purchase cost. If you could bring down the initial purchase cost, you could effectively saddle a company with high long term maintenance and support costs.
ERP vendors got companies to disinvest in their own systems — which were custom-designed for their needs. They convinced them to implement their ERP systems instead — and then when the claims they made about being able to meet nearly all requirements “out of the box,” (as we cover in the article The Myth of ERP Being 90% Out of the Box) they then baited and switched them, and got these companies to migrate their “legacy” systems into the ERP system as we cover in the article Why SAP Customers Followed SAP’s Advice on Coding in ABAP.