FRICE or CFRIE? That is the question!
For those not familiar with the acronym, F.R.I.C.E stands for Forms, Reports, Interfaces, Conversions and Enhancements. Sometimes you’ll see this with a “W” on the end of it, which stands for Workflow. These are critical items you develop during an SAP implementation or other project. The important thing about FRICE is understanding when to develop each item during a project. Most of the FRICE items require development and all are required for go-live, but often there is a difference between when the steps should be completed and when they actually are completed in a traditional project timeline.
In my opinion and experience, conversion – at least a solid portion of it – should be done first. In many projects, conversion is typically done after development on the others letters in FRICE has already begun. At the beginning of a project, reports may start first as they are seen as ‘quick wins’ to show that the project is moving along since reports can be developed faster than conversion items.
When you are developing your reports, you typically have to load SAP with test data. From your perspective, this is fine for testing development. The issue sometimes arises when you show what you’ve developed to the client. You have vision and foresight into the development as you’ve done this before. The client is new to the system and it’s tough for them to visualize test data in its production form. Often, they will not approve your work until they see their data on the screen. The client is mostly scared of approving something that does not look exactly like something they have in their production environment today, so it is somewhat understandable and acceptable in my opinion. You will now have an open item on your development list until the production data is in a test environment so the client can see the report. Although you developed the report, you will not be able to mark it off your list without approval.
When implementing an ERP like SAP, you’ll have to build interfaces with vendors that have been interfacing with the legacy system for years. These interfaces will have been changed many times (but specs not updated) and mostly likely no one will be around who knows how they work. You’ll get the vendor’s standard generic spec on how the interface will work. You’ll spec out your requirements, get the interface built and you’ll think it runs great. Then you’ll load production data and it will all go poorly. There will be so many variations of a specific master data element that you had no idea existed. It’s an impossible task for almost anyone. Having the actual production data to look at and run through your interface would have prevented this from happening and saved a lot of break fix time on the interface item.
So where am I going here? I’m saying that the C in FRICE should be the first letter that is addressed in a project or implementation. Conversion typically comes toward the end of the project. Everyone rushes around to get it right and it causes total headache at go-live. Do conversion first if you can. If your blueprint is strong, this is the best way to do it. The reason the blueprint needs to be strong is that for conversion you need to have vetted out all the portions of the ERP you will be using in order to dictate what data you are converting from the legacy system.
Most of you, especially those who have done a project before, may be under the impression that I’m slightly crazy. Not crazy because this idea is bad, because some of you may have even thought of this before. The craziness come in by trying to adjust the expectation of the project to do conversion first as it will take longer up front. Again, building reports first is nice as it gives a quick win by knocking some stuff off the development list, but it’s really not off the list until you have seen the report with production data.
When you really think about it, it’s a no-brainer. Although you spent more time up-front working on the conversion, you will save a lot of time developing the rest of the FRICE items because you are dealing with actual production level data.