When it comes to software packages, generally, one size does NOT fit all. It is not unusual for a company to purchase a software package that includes up to 80% of the functionality they need, and then rely on Keller Schroeder for some customization to handle their unique business needs. We have also developed 100% custom solutions for our customers. This happens when many of the required features are not included in a packaged solution. It also happens when the price of a packaged solution plus the additional cost for customizations, ongoing support, and frequent upgrades and retrofits to the packaged solution exceeds the cost of a purely custom solution. The latter leads to a high level of adoption and satisfaction, as the custom solution provides another unique distinction for the business and a competitive advantage.
If the choice is made to purchase a packaged solution, the next decision the Information Technology group needs to address is where to add the desired customization. Changes can be made to the software package or the developer can create a stand-alone software solution tailored to your business processes. There are several things to consider before a direction is chosen.
Customizations to a vendor’s software package will need to be reapplied with each software upgrade. This can be an extremely time-consuming retrofit process if you have heavily modified the base software. In addition, future upgrades may have a significant impact on your customized software and could result in existing customization that no longer “fits” with the latest packaged software release. Do you currently have support from the software vendor when issues arise? Probably, the answer is yes. You should, therefore, be warned they may not be willing to provide support if they see their base software has been altered.
On the other hand, if the existing software “mostly” meets your functional requirements, needing only minor revisions, this is probably the most cost-effective, time-efficient method. You do not want to “reinvent the wheel” in creating a new process if most of the required features are within the existing software package.
If you choose to create a stand-alone process, you need customization to walk hand in hand with standardization. For example, design all new processes with similar naming conventions and coding styles, enabling developers to easily follow each other’s code. Custom code should be homogeneous, so it appears as if one person coded all the programs. The code will be easier to maintain and debug.
Also, consider if your new process has a component that future processes might utilize. If so, design it as a separate module for easy inclusion in existing and future processes. For example, a financial institution uses customer name and address data for many business processes. If you have a request for a new process requiring a customer name/address, using a separate customer name/address retrieval module can ensure all processes are retrieving the information in a consistent manner. An added benefit is the reduction of repetitive code. If you ever need to change your customer name/address process, there is only one module to revise, rather than a plethora of processes.
In summary, always weigh the value of your innovation, feature, or improvement against the impact, cost, and time involved in keeping those customizations up to date when purchasing a packaged solution or choosing a purely custom solution. Asking, “Do our systems drive our business processes or do our business processes drive the systems?”, may help with your Customization decision.
Keller Schroeder’s Digital Transformation Framework includes tenets to help you identify, prioritize, execute, and learn from transformational initiatives to better prepare you for the next disruption – whatever it may be!