Eric Kimberling in his article “ERP Software Customization: The Ulitimate Sin of Enterprise Software?”, provides an interesting fact from a 2008 ERP Report.

“Only 23% of organizations implement vanilla ERP software with little or to no customization. The reaminder of organizations in our study customized their software, with 34% indicating heavy customization.”

“Every company is unique and no single ERP solution is goign to meet 100% of a company’s requirements.”

The post includes tips on how to mitigate customization problems, including defining requirements, understanding configuration versus customization, and controlling your ERP project.

Our Addition: As Eric mentions, some customizations are inevitable. So, buy software that allows you to separate customizations from core business logic. This will allow you to port changes to your next deployment and easily eliminate customizations if you change your business processes later. SaaS vendors have made it standard practice to develop in this way because they have to pay to upgrade customers. Unfortunately, many SaaS vendors limit the customizations that you can make, so as we said in Part II, remain flexible!

“Given my fixation on cloud applications, I did close our meeting by asking the team whether they had plans to offer a software-as-as-service (SaaS) version. The executives said that while the company has a version available now, it’s had very little demand because of the high amount of customization requested by customers for its core products.”

Mr. Richardson was talking to an ERP vendor that noticed “very little demand for its SaaS offering” because ERP requires customization.

Point 1: The ERP vendor is right on – ERP requires extensive customization – this is true from the mid-market on up.

Point 2: Do we have to concede that SaaS cannot be customized?

It’s true that most SaaS players limit customization, even when the application architecture is single tenant, because updating or upgrading customized code is much more costly and doesn’t scale as well. But, this is only true for most SaaS players, especially vendors who are retro-fitting existing code to SaaS. Newer software models allow you to maintain customizations separately from the source code.

When customizations are maintained on top of core logic, the SaaS vendor can run an efficient upgrade process without breaking your customizations. This means that you can add database fields, change business logic, or configure workflow. In a single tenant architecture, it’s even possible to interface with other systems. In a multi-tenant system, the vendor can upgrade all customers at once – which may result in operational savings that can get passed on to you.