First companies created their own code to handle their business. The serious problem with this approach was that the people who wrote code and the people who needed data processed rarely knew enough about each other’s jobs to effectively process data. The earliest computer systems were little more than ways to have machines put the marks on papers that people used to do.
As some programmers/analysts and some users began to learn more about what the users needed and the programmers could actually do with computers, the systems began to (slowly) get better. Once a few of them thought they actually understood what was going on, some companies began to offer to write systems for other companies so that the systems would actually serve a purpose other than to reduce the number of underpaid accountants making marks on papers. Then some of those people began to form their own companies to write and sell systems to other companies.
However, since each company has its own corporate culture and its own way of doing business, the systems, (or packages), had to be written with very open-ended requirements with hundreds of modules that had to be selected or bypassed to fit into the companies’ businesses. When company A and Company B each bought System XYZ, they would use some critical parts from it, then tailor other parts to meet their own needs. The advantage to this approach is that a company can hire one or two programmers to babysit the purchased systems, relying on the vendor company to continually make upgrades, while the company can use the rest of their programming staff to handle the bridges among different outside systems or to create reports and other functions that the package does not handle well, (or at all). The disadvantage to this approach is that no outside vendor’s package ever meets all the needs of a company, so they are forced to keep using internal programmers to keep the data flowinging where it is needed. In addition, every time the vendor upgrades the system, some part of the staff has to scurry around and make sure that the changes are not going to destroy a bridge or a function on which the company had built part of its business model.
SAP’s brilliant/insane/diabolical solution was to write a system that actually did do every single thing, (in theory), that any company could desire in its data systems, with the spectacular catch that SAP would not write an open-ended system that could be adapted so that anyone could use it. Instead, SAP wrote a single set of comprehensive systems, then told all its customers that they had to change the way they did business to match the SAP software.
So, one of two things typically happens: either the company does try to revamp its entire business model to follow the SAP software–causing massive consternation among the customers, the vendors, and the employees as business practices that may have decades of institutional tradition are tossed aside–or, (more typically), the company simply refuses to believe that they need to do that and they wind up spending six or seven times the energy, time, and money making enormous ad hoc changes to all the data flows so that they can try to do business the old way while donating a significant portion of their capital to the SAP retirement funds.
I have seen claims of successful SAP installations, but I have never seen claims that any SAP installation was not excruciatingly painful.