Many companies implement ERP, order management and warehouse management systems without programming major modifications. In order to implement systems in a broad range of industries and minimize the modifications, software vendors have designed applications that can be configurable to your situation most of the time.
Configuration settings set the individual options as functions. While this doesn’t deliver all the intended functionality, it may achieve the needed functionality in more than 80% of the use cases. This has big benefits in terms of speed of implementation, reduced programming cost and reduced risk from untested programming.
However, there are certain circumstances where modifying a major ecommerce fulfillment system will give you higher usage, increasing sales and savings. In general, our experience has shown that you should not try to copy or mimic legacy system functions because of the cost and risks inherent in too many changes. But it does make sense to modify a system when you can yield a higher ROI and cost savings. Here are some examples:
Another example is having your ecommerce site access inventory availability on the OMS rather than periodically via batch loads. This will lead to better inventory accuracy especially if you also accept telephone orders. When SKU quantities are low the inventory will be more accurate since it’s real time.
Another example of valuable modifications might be to add functionality to item retail pricing routines driven by promotional calendars. Or in B2B entities, pricing which is quantity based by vendor and tied to transportation costs and minimum freight costs.
You may see inventory management and forecasting functionality which can be expanded, eliminating the need for spreadsheets. This could include multiple years of history by vendor and SKU, as well as dynamic calculation of quantity requirements based on sales and lead time. Would these benefit the merchandising and purchasing functions and eliminate dependence on spreadsheets?
Here are 6 considerations to weigh when managing the modification process:
Your company and the affected user departments should write a detailed description of the requested changes to the functionality and what the desired outcomes are. Don’t worry about the technical aspect of the application (that’s the next step). Simply write the spec in a way that communicates how you want to change or increase functionality. This can be done with tables of existing functionality as you understand it, as it exists, and as you want it to operate. If it affects inputs or outputs from other systems, specify those. Mark up displays or report samples with the changes. Include any changes to calculations. Both the vendor and your company should sign off before proceeding with the next step in the process.
At this step, the vendor should come back to you with a technical document detailing how they will design and program the modification. This includes any input and database changes, output and display changes, calculations and a list of things they can’t accommodate. When you’re in agreement, have both parties sign off.
Before proceeding with programming, the vendor should give you a change request with tech specs, costs and the implementation schedule. Once again, both the vendor and your company have to sign off on all of this before program development begins.
However beneficial modifications may sound, you should only undertake major changes and integrations if there is a sufficient incremental sales increase or major labor savings that result in a favorable ROI.
As part of evaluating a modification’s feasibility, it’s important to know how the vendor will handle software updates. Will they make these changes part of the base application included in future releases for all customers? Will you handle programming changes for new releases internally, or will the vendor do so for a fee? If the added functionality has high benefits across the vendor’s customer base, you will have a one-time cost. If they will not make the functionality part of the base you need to consider the annual cost of upgrades.
As we have written in this blog many times, project management is the responsibility of your company. The vendor’s programming and implementation teams work for their project manager. But only your project manager is responsible to your management for ultimate training and delivery, including budget performance, schedule and meeting expectations. We have found that good project management of modifications includes the types of specifications outlined, thorough testing by IT and users and sign off on all results.
From a budget perspective, have the vendor report the percentage complete at least weekly on your project task plan and at least monthly on modification costs to date. We have found it may take vendors longer than a week to formally summarize costs.
Modifying systems always runs the risk of higher costs, risks from poorly tested new programming and elongation of the original schedule. Be prudent and manage the process to achieve the added benefits.