Software Modification Conform or Not?
This is not a technical post but rather a high level opinion based on twenty five years serving the distribution and manufacturing industries with ERP and our own WMS Software. This is an age old subject with many opinions. Let’s discuss this in detail.
Best Practices
In general there are industry accepted procedures for every area of inventory, production and accounting processes. Most commercial ERP and WMS Solutions support these processes. In most cases a thorough investigation into your own processes prior to a modification is a good idea. Especially for growing companies who have reached the size of at minimum fifty employees or more. Many times an adjustment to your processes allowing you to adapt to the packaged software will be a win for you in many areas. The first being expenses. Not only do software modifications cost money initially but there can be ongoing costs for upgrades, testing and unknown effects of modifications to other touch points. Also, best practices have evolved for a reason. Introducing an industry standard process may have an extremely positive effect in your operational efficiency. A good software vendor will help you thoroughly evaluate and consider a modification rather than just jumping into it for development revenue.
Configuration and Options
In our published software DCWarehouse, there are many configurable options that can be set to a named user based on their log in or user group. These options can include various methods for picking, packing, shipping, receiving and other transactions. You can even specify specific printers for labels or reports to be directed to. Part of our new implementation process is to analyze each and every department of your company, every warehouse (if you have multiple warehouses) and your product and service offerings. This allows us to make the best use of what exists in our solution. We then document those set ups for conference room piloting, testing and training prior to a go live.
One example that is fairly quite common is picking methodologies. We have customers that have different types of orders (Big Box and Smaller Parcel Shipments). So we very well may recommend multiple picking methodologies to accomplish the most efficient order to ship cycle. Our solution also offers set ups and configurations at both the item and customer level. For example, you may have a customer that prefers you use their shipper account. That is a simple one time set up in our system. You can also set up specific documentation for them such as their shipping label, BOL or Packing Slip. So prior to investigating a modification make sure your vendor has a thorough knowledge of their software’s capabilities and configuration options.
Your Company and Industry Are Unique
With everything being said, you know your company better than anyone. With each and every company there are nuisances’ that cannot fit into shelved software no matter how robust that system is. I know this because the most challenging ERP sales in my past were with companies that maintained an in-house “home grown system.” Did some of the features in those systems represent common features in ERP Systems? Yes, many features were typical features that you could find in most ERP Systems but some of the functionality was extremely specific to that company. So before even trying to implement new software and replace that system it was absolutely critical to understand the system inside and out. In a case where a specific feature supports a very lucrative or profitable opportunity that is when software modifications are indeed necessary.
If you do need modification there are considerations for short term and long term success. In our solution, each and every implementation was unique and most of the time, if a client needed a modification that we felt could be used across the board for other similar clients we negotiated a fair price and put it into our standard product so our customer did not have to pay for upgrades. This was always clearly stated in our technical scope and quite frankly contributed to the growth of our software. In some cases the customization was not something that could be used so we were clear in the technical scope that there will be a cost usually based on a percentage of the original development cost.
When It Get’s Ridiculous
The best advice that I can give regarding modifications or not is to have an open mind and discuss this with a vendor you have a good relationship with. I’ve seen firsthand where companies highly modified their ERP Systems in a manner which affected the actual source code. They used a “Cowboy” code approach (no documentation, no long term thought process or considerations.) This made it way to costly and disruptive to upgrade. Let’s face it as much as anyone detests an upgrade there are far way too many benefits to it. This includes updated technology, fixes, modern features etc.
The Moral to the Story
1.) Consider adapting to a best method prior to a modification.
2.) Make sure that all modifications are thoroughly documented and agreed upon.
3.) Make sure that you negotiate with your vendor before signing off on a modification and clearly understand if it will be incorporated into to their standard product and if not; what will be the ongoing costs to move it up for future upgrades.
4.) If you are doing development work in house and have a packaged ERP try to leverage the tools and technologies that allow you to work with the system in parallel and not touch the existing source code.
