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 BADI�s /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, let�s 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.