When I first heard the term RICE, during a large ERP implementation, I thought it was a joke. What do you mean you want RICE? Do you want it with butter or soy sauce?
It was explained to me later that RICE stands for:
- Reports
- Interfaces
- Conversions
- Extensions
Come to find out, I was used to dealing with these, but using the acronym helped clarify and organize these key implementation functions. You need to properly plan for RICE and you need to address these elements during your implementation for the project to succeed. All RICE aspects need to be tested and validated by the users of the system. If they are not, then there will be problems. Let’s look at them one by one.
Reports
First, you have Reports. All of your business reporting should be examined to ensure that you go live with at least as much information as you use today. The question is though, do you need the report or can you live with the new systems processes and online lookups? Often reports are generated to support a manual process that takes some human intervention. For example, a min-max report was printed to help the buyer make purchase decisions. “Not with the new MRPII system; the system provides suggested buys through an online lookup.” So do you need that old report?
The best thing to do is to catalog all of your current reports and go through each of them and determine what the business need for that report and working with your implementation consultants, find out if there is a better way to get the same information. If there isn’t, then mark that report as a necessary report for going live. (Chances are it is already in the system.) If the report is not currently in the new software, then a custom report will need to be made. These too should be prioritized. Some may not be critical to going live and are “nice-to-have” reports. There are many reporting factors to consider in a Successful Packaged Software Implementation.
Interfaces
Second is Interfaces. How many other systems will be linking with the new ERP solution? Interface development takes some software architecting, but you can see which software will be replaced by the new system and which software will remain. Does the legacy software have a need to be integrated into the new ERP? What is the cost of integrating that new solution, versus a manual entry? These are some of the decisions that you will face.
Linking two systems together can be as simple as a data export and data load, to as difficult as a synchronized data movement between the systems. Often it is the first option. Export the data from the external system on a set schedule and then import the export file into the ERP system. There is usually an intermediate program that does the task automatically of file format conversion. This is common in EDI. The EDI data is downloaded, is run through a translator, and then uploaded into the ERP system. The reverse also happens (as in the case of shipping notices). A data file is exported from the ERP to the translator, which then maps and prepares the upload file to the EDI system.
Conversions
Third, you will need to look at conversions. Conversions are one of the most deceiving areas of an implementation. It might seem simple at first. “Oh, we just are converting the Items, Customers, and Vendors.” Okay, simple enough. But do you have all of the data fields that the new system requires? Do you have good and valid data to be brought over? One of the key factors of implementations (regarding labor) is the data clean up. Most ERP implementers have a standard data import template. You can then map your data fields to that model. Sometimes it is even in Excel. You just cut and paste your exported data into Excel. But what if your legacy system is an old green screen with the only export are reports written to a file? Then you have to have a program written to parse that text file to pick up all the correct data. Even then, there will be dirty data that needs to be cleaned. If you have a lot of records, then this will be very time-consuming.
The other option is not to even export and import. You can manually enter data too. The rule of thumb I go by is if there are less than 500 records in a data file, then it should be manually entered. If it is more than that, then you should look at an automated data load.
Extensions
Extensions are additional programming functionality. Sometimes referred to as Enhancements they provide functionality that doesn’t exist in the core ERP package. Often this is due to a very particular task that the old system did to satisfy a customer need or to meet a legal regulation that is specific to a niche industry. These custom programs are not written into the core ERP since that will break the upgrade path in most cases. Instead, a separate program is developed using the same tools that the ERP system uses and data hooks are created to link the extension to the core ERP.
Extensions should be avoided if possible, but if there is a unique functionality that cannot be handled by the system, then an extension is the preferred way to address it.
RICE Summary
In summary, Reports, Interfaces, Conversions, and Extensions are key aspects of any Successful Packaged Software Implementation and should be properly scoped in the initial planning phase. Insufficient time or resources can have a detrimental impact on the overall implementation budget. If you are about to embark on an implementation, be sure to look at all aspects of RICE before you begin.