I've done a lot of these ERP implementations and the first thing the project heads say is: we aren't going to change the software, we are going to change our bu

I've done a lot of these ERP implementations and the first thing the project heads say is: we aren't going to change the software, we are going to change our business processes. The company has just paid a lot of money for the software, which was chosen through an evaluation process where the vendors showed that they could support the existing business processes, which made up the RFP. They chose one vendor and tied them up in a contract to say that the software would meet the RFP. Then the project starts, and the company notices that the software doesn't really meet the RFP, so they get the vendor/consultancy to customize it. Otherwise they wouldn't be getting their contract's worth, you know. The earlier claims of not changing the software get thrown out the window. Plus you have the business people who have been seconded to the project, they don't want to tell their colleagues they are delivering a clunkier system than the old one so they fight for the customizations. Fair enough. IMO, any software that is absolutely critical to your company's special way of doing business (i.e. your competitive advantage) you shouldn't customize an ERP product to do it - you should build it yourself. Anything that is generic and not a point of difference between you and your competitors, you should keep as standard as possible. The bit where they join up, make sure you abstract it properly. As soon as you create barriers for upgrading your ERP, you lose the value of the maintenance (which is the ERP vendor's developers working hard to add new platform and application features, instead of your guys).