What are RICE Components?
RICE stands for:
- Reports
- Interfaces
- Conversions
- Extensions
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.
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.
No comments:
Post a Comment