Companies implementing an enterprise resource planning (ERP) system will spend days, weeks or months testing the new system, having different departments enter data. While this is great in getting all departments familiar with the new system, but if your largest customers sends their orders electronically, you need to spend as much if not more time testing all the electronic orders.
In the early stages of electronic data interchange (EDI) adoption, companies used the 80/20 rule. The rule was that 80% of their business was done with 20% of their largest customers. Whether companies implemented EDI with these customers as a competitive advantage or were mandated to do so, 80% of their business is done electronically. Yet in almost every ERP implementation, EDI was always an afterthought. Why? If 80% of a company’s business is done electronically, why don’t they see the value in EDI testing at the beginning of an ERP implementation? Most companies do not realize the importance of EDI in their business. Because their information technology (IT) department manages EDI, it is thought of as an IT function only. They don’t stop to think that 80% of their orders come to them via EDI. Therefore, if EDI fails in the new ERP system, 80% of their business could be impacted.
Waiting until the end of the testing cycle to test EDI will guarantee an ERP implementation failure. Why? Let’s start at the beginning.
Your EDI customers are almost always your largest customers, therefore, their business is extremely valuable to your business. If your ERP implementation fails, their business may be in jeopardy. Most of your largest customers require not only sending their orders to you electronically, but also require the corresponding documents to be sent and received electronically. This means that many if not all of the following documents must be able to loaded or be generated from/to the ERP system and sent/received. Purchase orders, purchase order acknowledgement, purchase order change, purchase order change acknowledgement, advanced ship notice, invoice, warehouse inventory and withdrawal, shipping and remittance advice are the main documents part of the electronic order-to-cash process. You need to know what documents your customers require and make sure they are included in your testing scripts and cycles.
When EDI is not the critical path in your ERP implementation, you will sink more time and money into the project that you planned. These “sinkholes” can be avoided if you plan for them early.
Sinkhole 1 – Wait to contact your customers
Most ERP implementation projects fail because customers are not contacted early in the implementation. Rather than working with their customers, companies believe it is better not to alert their customers of their ERP implementation, but instead wait until they are absolutely sure they are ready to publicize their production date. Yet, every ERP implementation will have delays; production dates changes several times. Communication with your customers will always work in your favor, not against you.
Also, alert your customers of your plans early in the project. Especially your EDI customers. You need their cooperation, their testing requirements, their testing timeline, and most important, how much notice they need before you can begin to test with them. If you wait until you start testing to contact your customers, you may find out they are also implementing a large project and will not be able to test with you for months. Their requirements may dictate that they will not accept any production documents from your new system unless you do a full cycle test. Can you afford to delay your implementation for months for one or more of your customers?
If you want to minimize the testing time with your EDI customers, start to save production data from your current system. During your system integration testing (SIT) testing phases, you can use the saved data to test your new system. This can avoid delays in your project because you don’t have to wait for customers to send you data; you can be using “live data” early in your testing cycles.
Sinkhole 2 – Your customer will change their requirement to fit your schedule
You are now in your SIT2 testing and it is going well. You found several errors, but were able to fix them and continue testing. Regression testing caught a few more problems, but your core team found ways to resolve them and continued to test. However, you have waited until almost the end of your SiT2 testing before starting to test with your EDI customers. One of your largest customers sends information on their order that requires your invoice. You did not account for this in the ERP system. What do you do now? Your ERP consultant tells you “that’s not standard in our ERP system; you need to get your customer to change their requirements.” What do you think the chances of that happening? This is one of your largest customers. They have been doing EDI for years with most if not all of their suppliers. All of their suppliers, including you, have accommodated these requirements to date. Do you think they will make changes only for you? They may agree to make the changes, but would not be able to do so for months, thus pushing your implementation date out months. Or, they may refuse to make the change because of the impact it would have for their system. If you don’t get their user acceptance, are you willing to lose their business? If you did your homework and document exceptions early in the process, you could have made the provision in the ERP system to handle this customer’s requirements. Now you run the risk of major delays because this change could have a snowball effect impacting many aspects of ERP system.
Sinkhole 3 – Full cycle test incomplete
If your EDI customers send you electronic orders and require corresponding electronic documents sent to them, you must test the complete cycle. Don’t just test that the document was generated, but verify that it was generated correctly. Your customers may assess fees if your invoice is incorrect or the advanced ship notice (ASN) was not generated or late. If you saved off production EDI customer data, you can use this data to do a full cycle test. You can compare the production data to what was generated from your ERP tests. If they do not match, then the errors need to be resolved before you move on. If you have to make a major change to resolve the error, regression testing needs to occur. Don’t skip regression testing in order to stay on your project timeline; you will regret it. A successful implementation is more important that missing a date on a project timeline.
In conclusion, avoid the ERP sinkholes and do your homework. Start with your EDI customers. Most of your exceptions will be found here. Work with your customers early in your implementation project. Most importantly, set a reasonable timeline. Remember, if the timeline sounds too good to be true, it is.
