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:
- Adding major functionality. This can include a robust application for which the base system does not have advanced functionality, such as a content management system (CMS) integrated with an ERP. The CMS might become the main repository for all SKU attributes including website, catalog and promotion copy, pricing by season and promotion, and colors and sizes.
The payback in modifying both systems might be consolidating all the data from product master files, creative systems, offline and online images and descriptions. The objective is to minimize redundant file maintenance, eliminate double and triple entry and manual errors that occur when data is dispersed throughout the enterprise. Often you may achieve synergy between the two applications that wouldn’t happen without modifications.
- Online integration versus batch interfaces. Websites and OMS systems tout their ability to share data. Most times this is through batch summarized files that are exchanged on a periodic basis. The time period can be anywhere from several times per day to every couple of minutes. On the other hand, real-time integration lets you have a single customer file that resides on the OMS or ERP and the website, retrieving data as needed for existing customers and adding new ones. This eliminates updates to the two customer files that occur in many traditional OMS and website software.
Other System Modification 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:
1. Develop functional specifications
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.
2. Have the vendor write technical specifications
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.
3. Have vendor estimate proposed cost and schedule
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.
4. Develop return on investment/business case
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.
5. Consider impact on upgrade to new releases
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.
6. Assign internal project management
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.