When flying into Dallas-Fort Worth, the cities seem to shoot up out of nowhere from a giant prairie. Many of the roads leading into the cities curve and bend, following no discernable logic at all. Why are they like this?

Back when Dallas was primarily a ranching town those were the paths the cattle would follow as they were driven into town. They would walk the long way around hills, cross rivers only at the low points, and follow a path of least resistance the whole way there. Over time, people started following the same paths, and eventually they paved them and made them permanent. Now, the town has all these inefficient roads just because that was the way they had always been.

I’ve heard many times that “All ERP implementations require customization”. While I believe this to be true, I also know that it is important to know the difference between customizing ERP software to improve a vital business process and customizing ERP to entrench a poor process.

To use an old adage, be careful with customizing and “don’t pave the cow paths”.

Anything that is customized has an inherently higher value, whether it is automobiles, furniture, or jewelry. ERP software is no different. Customizing the software always adds significant costs. Customization must be done as a last resort to solve a problem with the software, which addresses a key business process. To customize a bad process is a sure guarantee of runaway costs and could potentially ruin an otherwise successful ERP implementation.

Three Key Reminders About ERP Software Customizations

  1. Understand the reasons behind the customization – Are you adding significant value to the ERP solution by writing custom code or are you just entrenching a poor process that’s always been done that way. If it’s the latter, then change the process and revisit the customization. Take a lesson from the companies who understand that the more standardized their processes are, the better the ERP software will meet their needs. Just because your product is unique, doesn’t mean every business process needs to be. Take the time to learn the difference and make the best use of the standard processes in the ERP solution.
  2. Pay a lot now or pay a lot more later – Find a top-level programmer with significant coding experience. Ask to see their work and have it reviewed by other programmers. Finding and paying for a top-level coder up front, will save money down the road. Finding this person after you’ve already had a solution customized by an inexperienced person will be at a far greater expense and may even result in a failed project.
  3. Plan the work and work the plan – A little cliché perhaps, but a good programmer will gather requirements, analyze them, design the solution, and test the solution in iterations before writing one line of code. The coder who writes code first is doomed to fail. The requirements will not be met, the solution will not be robust, it will be full of bugs and may not even work at all.

So as you enter into your next ERP selection or ERP implementation project, remember the cows, my story, and your ultimate project goals.

Posts You May Like:

Rebuilding Trust After a Failed Software Project

Rebuilding Trust After a Failed Software Project

Failed software projects often disrupt operations and erode trust among employees, stakeholders, and clients. Rebuilding trust requires transparent communication, accountability, and a comprehensive recovery strategy. Transparent communication, employee engagement,...