No. It seems almost quaint to think of it today, but back in the days before Y2K, enterprise software vendors, and, more forcefully, the management consultants who installed the stuff, sold ERP as a magic bullet that companies could use to escape the coming Y2K apocalypse, create seamless technology integration across the company and force your silos of isolated, sociopathic bureaucrats to start working together. It was an irresistible sell to businesspeople.
It’s true that ERP was designed to solve integration problems, but it worked only in the theoretical environment of the vendors’ development labs. Developers who believe they are modeling an entire business in software don’t spend much time thinking about how that system will connect with other systems. Who needs other systems when we’re creating the whole thing right here?
Of course, as soon as companies began buying these products, it became clear that enterprise software was another chunk—a much larger and better integrated chunk to be sure, but still a chunk—of software in a complex architecture of IT systems that desperately needed to talk to one another and exchange information. The vendors created clunky, proprietary methods of connecting their systems with others, which have improved over the years, but that misses the point. The architecture of these systems, in a broad sense, was just like the ones that they were intended to save you from—monolithic, highly integrated and difficult to change.
No problem, said the vendors. Some of your maintenance and support fees are going to future R&D. As we develop new pieces to add in to our highly integrated suites, we’ll let you upgrade to the next version for free and you can gradually get rid of all those other troublesome chunks. Again, it sounded great to the people buying the stuff—businesspeople.
But who could afford to install enterprise software as it was envisioned in the vendors’ R&D labs? Very few. CIOs built complex integration links from enterprise software to other systems to keep the business running. Or they chunked up the installation, building dozens or even hundreds of unique installations of the same enterprise software to meet the needs of individual departments or businesses that all had to be linked together. The high degree of integration envisioned in the R&D lab was tenuous at best inside most organizations.
Gradually, enterprise software vendors came to realize that to serve customers better, they needed to break up their suites into application components and create complex ways to link to them over the Internet so that customers would not have to rewrite connections to pieces of the suite such as financials, which didn’t change much.
The final death knell for the original enterprise software architecture model came in 2004 when the major enterprise software vendors all announced that they were offering packages of integration middleware—tacitly acknowledging the reality that had been clear since middleware was first invented decades ago: Integration happens best outside of specific software applications, not inside them. The enterprise software vendors have been conspicuously absent from the Web services standards movement, looking ever more like the Dark Princes of Lock-In while the originators of the lock-in concept, IBM and Microsoft, looked like white knights for doing the lion’s share of work to create free (so far, anyway) standards for integration in Web services. And it’s great stuff. How ironic that those companies that were going to save your CEO from integration in 1999 have been the laggards in developing truly useful enterprise integration.
This is not to say that ERP is a boondoggle, or even that the software isn’t valuable to the companies that bought it. Even though most vendors have had some big bumps in the road, most of their products work well. The happiest customers are those who used enterprise software to create new capabilities and processes that they could not express in software with their old systems. But back in 1999, many CIOs talked about ERP as an integration strategy, about replacing systems that had more and better functionality than the enterprise software they were installing in order to be more integrated, more efficient when the new software was installed. For the few companies that could afford to install enterprise software in the manner envisioned in the vendors’ R&D labs, they may have gotten there. Many are still maintaining the custom code they had to write for outraged business users who lost capabilities they had in the old software.
Kaynak: erpdanismani.com
belgesi-1292
