This insightful article from Thomas Wailgum at CIO.com summarizes the typical situation organizations face when having to adapt commodity software to a changing business and to their specific processes.
Do not change ERPs
Traditional software packages (ERP suites the best example) are, by definition, not meant to be customized. The strategy of ERP vendors is to embed in their software, business processes that are common enough to be deployed in the largest possible number of companies. The continuous addition of new functionality produces a bloated mass of alternative code with very complex product release cycles.
Organizations that customize a package create a private "code branch" that needs to be maintained in-house. This is like diving into the gates of hell. From that point on, you inherit part of the vendor's complex development cycle. You make it very difficult to merge your own changes with the next product release of the vendor. Your maintenance cost sky rockets and your meager resources get sucked by these packages. The wise and experienced IT professional only needs to go through this process once to never again dare to customize an ERP.
But if you use packages to only implement commodity processes how do you support the processes that are your own? And how do you support processes that are the result of internal innovation and represent your own strategic competitive differentiation?
Commodity vs. Competitive
Innovative processes, strategies and ideas and their supporting IT, flow from the Invent, up to Deploy To Scale. In time they become a commodity (as they are copied by others) and move sideways to Manage Scale. Finally some of these processes stop being mission critical and can be Offloaded.
Packages are a good fit if applied to processes in the Context quadrants. And, in this case it is acceptable that the organization actually adapts to the ERP processes. Hey, it is commodity, so except for some reengineering discomfort, why not?
Build Custom Software
IT applied to the Core quadrants however, needs to reflect the innovation that is created inside the organization. In this case you need to build custom software. You need to have the software adapt to the organization processes. There is really no way around it.
ITs that support fast changing organizations, are already doing this. A typical enterprise architecture tends to divide itself between packages and custom built systems. A zoo of Java and/or .Net systems, Sharepoint customized portals, and Process Workflow tools support the two left quadrants. Web Services (I don't dare use the term "SOA") glue these things together.
So, is this a good strategy? Isn't there anything to hate about custom systems? Yes, there is. I will blog about it later.
Besides my daily job as CEO of 
Along the years, i noticed that a big problem with software customization is users. Everyone tends to expect the shampoo methodology, it's does this and this and that...
Many of the customization software hell is integration. Why does everything as to be integrated?
It's like the concept of you grow up and get a girl, get married and have kids... not everyone likes that.
Enterprise software tends to be built on top of the wrong basis, it's all about microsoft and it's poor documentation. How can someone expect microsoft to agilize integration... it's bad for business.
Along the years, i noticed that a big problem with software customization is users. Everyone tends to expect the shampoo methodology, it's does this and this and that...
Many of the customization software hell is integration. Why does everything as to be integrated?
It's like the concept of you grow up and get a girl, get married and have kids... not everyone likes that.
Enterprise software tends to be built on top of the wrong basis, it's all about microsoft and it's poor documentation. How can someone expect microsoft to agilize integration... it's bad for business.