RICEF

R-Reports (this refers to the a requirement which cannot be met by the standard reports provided by
SAP....including report painter/writer)

I-Interfaces (this refers to a requirement where SAP needs to be integrated with some other non-SAP
system....the best example that comes to my mind is the banking interface...where SAP has to be integrated with a bank's system in order to automate the payments.)

C-Conversion (this refers to the data conversion...when a company decides to phase out a non-SAP
application all the data from the non-SAP app including the master data as well as transactional data needs to be converted into SAP.The data volume will depend upon how big is the non-SAP system which is being phased out and how many functionality does it support.)

E-Enhancements (this refers to the changes which can be made to the SAP programs to change the
way a transaction is carried out...SAP provides enhancement points in programs which are also known as user-exits, which can be used to tweak the calucations which take place in the background...for example vanilla SAP uses the posting date to derive the exchange rate for a foreign currency document...but if a user wants this translation to happen based on the document date instead this can be achieved by activating the user-exit and making program changes to pick uo the exchange rate using the document date.)

F-Forms (this refers to the various forms...like the sales invoice,commercial invoice,customers
invoice,vendor invoice,purchase orders, customer open AR statements etc...all of these if needed to be issued as a physical copy on the company letterhead, will generate a rek for a form....SAP has provided some utilities to develop the forms like SAP Script and Smartforms...smartforms are more recent...SAP Scripts are a little outdated..)

A requirement associated with any of the above is also referred to as RICEF object.For each of the RICEF object to be incorporated a functional SAP guy has to write a functional spec, and then the ABAP developers use this spec as a reference to carry out the necessary program changes associated with the RICEF object.

Effective Management of RICEF Development on SAP Projects RICEF objects stand at the core of any SAP implementation. RICEF is an acronym for Reports (R), Interfaces (I), Conversions (C), Enhancements (E) and Forms (F) which for the most part represent development objects in SAP that need to be designed and developed to fulfill the software gaps and ancillary business requirements. RICEF is also referred to as RICEFW (with W representing workflows) or FRICE.

We are not going to discuss how RICEF development should be done, but rather focus on measures every SAP project leadership and executive sponsor should take to ensure high quality RICEF design and development. If these measures are adopted correctly then it should help your project leadership to identify and mitigate any project risks that could potentially jeopardize a successful go-live. As a SAP Project Executive Advisor (QA, Validation and Verification), one of the key aspect I closely monitor is execution, governance and delivery of RICEF objects. I will cover all these three areas as we discuss various steps along the lifecycle of the SAP implementation that involves or directly impacts RICEF development. High Quality Blueprint Providing clarity and depth into your business requirements Detailed Business Requirements Emphasize on "what" your company needs to run your business operations in SAP and not "how" these needs will be realized in SAP. "What" precisely refers to your business requirements and "how" is how these requirements will be configured or designed and built in SAP during realization phase. Very often business teams raise a pain point in realization phase complaining about the quality of functional specifications indicating the designs are inaccurate or business requirement interpretation is incomplete in the functional designs. This situation arises when business requirements are not at a sufficient level of detail that SAP functional consultants can clearly understand and interpret your business needs. From my perspective, detailed business requirements are absolutely a must on every SAP implementation which holds the key to go-live success. Remember that RICEF design and build on most SAP projects are done by offshore teams located in countries like India, Philippines, Europe, etc. So it is important that each business requirement document in blueprint should be at a very detailed level that any person who is not part of your project or business can read and explain the business need back to you without

anything lost in translation. Day in life examples with business scenarios should be included when explaining complex business requirements. If your business requirement says "I need to build a new custom mid size car to deliver pizza.". If we design based on this incomplete requirement lacking details, you could get a MERCEDES or FORD designed and built that could meet this vague requirement. The company chief executive must be looking for low cost and fuel efficient cars to deliver pizzas. Now a good business requirement could look like this. "New mid size fuel efficient and economical car need to be built to deliver pizza. The car gas mileage should be in 25-40 mpg range. Low cost interior and no air conditioning needed. Car needs to be 4-door to accomodate pizza delivery bags for 3-5 customers at a time. Cost of car should not exceed $15000.". Now you know that the car being designed will be low cost fuel efficient car that can accomodate enough pizza delivery bags per your company needs. That is why for a good RICEF design and build quality, it is very important to have detailed business requirements with business examples where required for more clarity. Good SAP Software Fit-Gap Analysis RICEFs are technical objects that need to be designed and built to address the "gaps" in the SAP software. These gaps may represent SAP functionality that needs to be modified or custom. So what constitutes a good fit-gap analysis? Well! There is a twofold perspective. First of all a good fit gap analysis can only be done by an SAP techno-functional expert in the modules that are being used on the project. This resource must be at the level of an SAP solution architect who also possesses an in-depth expertise about specific SAP modules and all the functionality that has been added in later releases. SAP customers often ignore this fact and you tend to trust that the resource performing fit-gap has the required expertise.

Next thing that should be emphasized is how the fit gap analysis is carried out. Fit-gap should be done on each detailed level business requirement (L3 requirements) and also at the "L2" and "L3" business process steps. Why on process steps? Just because SAP may have an enhanced or alternate solution to execute the same process step that may meet all underlying business requirements in a slightly different manner but still meeting essential needs of the core business process. If your project has a independent advisor, I recommend that you verify the quality of fit gap analysis and resulting RICEF inventory.

On large or complex (w/significant custom development) SAP projects that I have overseen, I have always recommended to the CIOs that fit gap analysis be reviewed by IBU (Industry Business Unit) or IS (Industry Solution) experts from SAP America or SAP AG that are not typically part of professional consulting services but who work in the product development and field services departments at SAP.

RICEF Estimations Work effort associated with RICEF design, build and testing usually account for 50-70% of project budget during the realization phase. So it is very important that objects in the RICEF inventory are classified correctly to represent correct work effort. System integrators often only include effort required from their own resources to design and build the RICEF objects. I suggest that you ask the project manager and SI delivery lead to verify that effort includes hours required from business team SME and other project team members to complete the work. Also estimates for each RICEF object should include functional requirements (if not done in blueprint), technical design, development and unit testing. Allow 15-20% of total effort for each RICEF object for performing modifications and fixes based on business, technical and advisory QA reviews. All "very large" RICEF objects especially enhancement which could also be classified as custom development are estimated separately and not using the SI estimation tools. Because very large enhancements could men 200 hours or also 1000+ hours depending on the scope and complexity and later could blow the project budget out of bounds.

For conversions, ensure that estimations include effort required for cleansing and extraction from legacy systems, transformation and loading of data into SAP. Effort for cleansing the legacy system data can be overwhelming if the quality of data is not as clean as you hoped. If your project believes that your organization will require extra effort then ensure you adjust the work effort for each "high/medium/low" conversion object. Make sure you are not double counting for technical development that is needed to support conversions which may also be included in other enhancements and ABAP reports.

Most RICEF "interfaces" can also be used for loading the data from legacy systems and hence the conversion effort should not be duplicated. In this case conversion (if any) estimates should only include effort required to clean and extract data.

Realization Phase Staffing Model (for RICEF) Balance between onsite and offshore Balance within technical team architect, senior developers, developers and junior dev Architects should know in-depth technical know how of all development classes, available BADIs /user exits, DDIC and other technical objects that are available in standard SAP solution Senior developers should be experts in ABAP/ABAP OO along with tools and solutions along with good understanding of standard functionality. Developers should be able to take directions from architects and senior developers. Implement the code independently. Junior developers and technical

analysts can be fresh out of college or less than 2 years of experience with SAP ABAP, PI, etc. Junior developers should not exceed 15% of your total technical team composition. Having junior team members above 20% could wreck the quality and delivery of your RICEF development.

Project Management of RICEF Development Project Plan and RICEF WBS I expect to see two project plans with different level of granularity to provide me with 100% transparency into the actual progress. One at the PMO, with WBS showing each RICEF object and underlying tasks one each for functional specification, technical design and development. The project plan also have a milestone for each RICEF signifying approval by business lead upon review from SMEs. This will provide a good insight for the project leadership showing the RICEF objects that are complete have also been checked and verified by the business thereby acknowledging the development.

Example WBS in PMO project plan Application development(RICEF)team leads on the project should have a more granular project plan for each RICEF objects. Sample work breakdown structure (WBS) for a typical object may include: RICEF E278: [name of enhancement] Functional specification Technical design Build and unit test Business review Signoff

Project plan should include dependencies on other related RICEF objects and it is important to especially show the progress of RICEF objects on critical path to your project sponsor and advisors. Tracking RICEF Design and Development First, lets discuss about what need to be designed and built first. Make sure RICEF objects that are driving the core business process and SAP functionality be done in first cycle followed by the ones that have lesser business critical significance. Keep the report, forms and enhancements to the last that have

lesser business impact if project decided to go-live without these objects in place. Please refer to our recommendations on "Sequencing RICEF development in realization phase" for more information.

Reporting Accurate Progress to Project Leadership SAP transformation projects are usually quite large enterprise wide undertaking and hence it is important all parts and pieces of the project are completed in a timely fashion to deliver the overall project in time and within budget. RICEF development is one of these critical part and all pieces i.e. key RICEF objects that are in project critical path be completed on time. I often see system integrators that show the project in "GREEN" status during early to mid realization phase where in reality it should be at least "YELLOW" because of delays. Here is what I like to see in terms of weekly status reporting about RICEF objects in the project leadership meetings. Your SAP project manager should have a few slides in the weekly PMO deck that shows the RICEF progress dashboard. First set of slides should show the total number of reports, forms, interfaces and enhancements that were supposed to be completed till date as per original plan and showing the actual completion count till date. All the RICEF objects that are delayed should be listed in the following deck one by one with reason for delay, extra effort required and target completion date. All risks and issues around any RICEF delays that could potentially impact the project should be logged in issues and risk management tool. Next set of slides should show the status of in-progress RICEF objects with just the list of objects and target completion date. Any change requests, issues or risks around the RICEF objects that could potentially impact the project budget and timeline should be in the final concluding slides that show RICEF development status. As a project advisor, I expect a little more detailed weekly report on the RICEF development and this be reviewed with me prior to preparing the above project leadership status report. I ask the project manager (periodically include project sponsor) to walk through the project plan. For each RICEF object that is completed, I like to see that the design has been verified and approved by the business before marking the same as complete. If the development (build) has been complete, I like to see that senior technical team members have done QA review on the implementation. I may pick a few key objects to conduct design and code review with the technical team. For RICEF objects that are delayed, I would like to see the detailed explanation on what has caused the delays in the completion of design and build. I investigate some of these items further with the SAP project manager and team members to ensure that delays are not caused by lack of SAP expertise or unnecessary bottlenecks being caused by business teams. Ensure that there is a collective (or well grouped) weekly change requests that reflect the delays or extra effort required to complete the RICEF objects. I might conduct one-on-one meetings with the RICEF development teams and leads to identify and mitigate any risks that affecting completion of certain RICEF objects.

If the project has outsourced the RICEF development then I expect to meet with the offshore delivery lead and the project manager on a weekly basis to discuss status and some of the above points. I suggest that your IT lead or advisor visit the offshore development center whether it be in India or Philippines if there are major delivery issues. Historically I have travelled to India on some projects and also made some tactical and personnel changes to bring the project back on track with minimal possible impact on delivery time and budget.

One thing that I often see on projects is that systems integrator begin the realization by focusing on simple and low effort RICEF objects first in order to report "GREEN" status in project leadership meetings. This results in more business critical RICEF development that is in critical path to be delayed there by causing overall project delays.