What is RICEFW ?

when you hear the term RICEF - you should think: customization / changes to std SAP. RICEFWs are used
only when std SAP cannot do the work.
Reports:

SAP has tonz of standard reports (VA05, VA14L) that show you a lot of info. But when you need info
that's NOT on a Std SAP report, you want to then create your own report. You talk to a developer /
ABAP-er, and you give him the Table-Field specs for each column that you want to see on the report.
You also tell him what your input selection criteria, are. Also give more details like - should this report
auto-execute, should it be auto-emailed, should the output be a flat file or ALV format, etc. You will also
suggest the Tcode for this new report. classic example: cut report.

Interfaces:

Assume SAP is being used in conjunction with some other non-SAP system, for ex: Manugistics. This
means that these 2 systems have to talk. In real-time and without human intereference. that in turn,
means that certain data and status values from SAP need to be accurately mapped to MANU, and viceversa, and again, in real-time. To accomplish this, complex interface programs will be developed by the
ABAP-ers, based on the specs given to them by the functional teams. These specs must be extra-specific.
For example, "In MANU, when a freight movement is goods issued, do 3 things in SAP - change the
status of the corresponding delivery to completed, show the carrier pick up time from MANU in SAP,
and also, show the exact time of goods issue on the delivery, in a custom field". These interface
programs bring data back and forth, and keep the business going.

Conversions:

When you are about to go live with SAP for the first time, all your data, history, records and functionality
are in some other, legacy system. The functionality is imitated in SAP through configuration and/or
customizations. However, you must still bring ALL the data, in the correct format, to SAP, right? If you
have 10,000 customers, and 18,000 open sales orders and 1894 materials - are you going to do this by
hand? No, you will use a conversion program. These are again custom programs. The developers will
write 1 program (again, based on ur specs) each for customers, materials, sales orders, and so on. You
will test these in Q and during Mock cutover. Each of these programs will ensure that their source
record - in the legacy system - is mapped completely and exactly onto a corresponding target record in

SAP. the customers conversion program, for example, will first read all the fields for a customer in the
legacy system, then, in SAP, open XD01, and map each of those fields to its corresponding counterpart in
SAP.

Enhancements:

When you want SAP to do something that it doesnt do in std SAP, its a customization. But when you
modify the way SAP does in std SAP, then thats an enhancement. For example, in Std SAP, when you
save a sales order, SAP already populates the shipping type (from the ship to customer master), and the
order's total weight. But when you want SAP to change the shipping type based on the order weight and
not simply populate the shipping type from the ship to customer master, thats an enhancement.
Because the values you are using are already in SAP - you are just using them differently.

Forms:

This is SAP Smartforms. Std SAP gives you readymade forms for Pick List and BOL. But lets say you want
more fields displayed on these. You would then talk to a developer - they would show you your options.
You will draw them a picture on a sheet of paper - saying that - in this section on the pick list, i want the
ship to address displayed and here on the BOL, I want the bill to address displayed. The developer will
then make these and show you, and you can then adjust things like the location of the box, the field
length and the font size. the developers will use SmartForms to do all this.

Workflow:

SAP uses a std mechanism, workflow, to inform people, when certain trigger things happen in SAP. for
example: whenever an order with a delivery block is created, a particular CSR, who handles delivery
blocks, gets an email in their SAP inbox. This is NOT their regular email inbox. This is in their SAP inbox,
Tcode: SBWP. Once they see the message there, they can double click on it and it will take them to that
sales order in change / VA02 mode. Once the CSR does whatever is required to release the delivery
block, saves the order and clicks the back button - they will be taken back to the SBWP screen - when
they hit refresh, that entry will dissapear from the list. But keep in mind that none of this is std SAP - a
workflow consultant has to come in, and define: which users will get emails when what actions occur in
SAP.

Reports - Development of customized reports in ABAP, Report Painter or BW

Interface - Some business processes may be maintained in external systems. For example Payroll,
Fixed Assets, Dispute management etc. These external activities may need postings in SAP.
Interface programs are developed to automate the postings in SAP.
Conversion - Conversion of Legacy data to loadable format into SAP. The process consists
Extraction of legacy data from legacy systems, Transformation of data into loadable LSMW format
and Loading the data into SAP. This activity is important and need accuracy. Hence, a separate
team may be assigned for conversion alone.
Enhancements - Generally in the case of large implementations a Global template Blue-print will be
prepared and followed. If a plant or company code need additional configuration to meet their
country specific or plant specific requirements, the template will be enhanced with new
configurations.
Forms - Development of layouts for Invoices, Account statements, Delivery notes etc
Workflow - Development of approval flow logic in SAP. For example GL master data changes
should follow specific approval process.

SAP Project Best Practices - Blueprint

Share with your peers, friends or project leaders

inShar e

Given the pre-planning and complexity that comes with SAP systems implementation, it is totally
understandable if the executives take longer than anticipated to select an appropriate vendor as a SI
and further negotiate the bid. This process is time consuming and can go on for a few months. By
now you may have already setup your internal business and IT teams for the upcoming
implementation. I would hate to see so many people waiting on the project to officially kick-off.
Rather I would ask your business SMEs and leads to start internal sessions meeting with business
stakeholders and further working as a team to start gathering business requirements. This will
expedite discussions during the requirements gathering workshops when blueprint is officially kicked
off.

A detailed blueprint requirements gathering workshop plan with detailed schedule and list of
participants is a must to start the blueprint phase. Make sure that the systems integrator (SI)
leadership, PMO and business leads have prepared a workplan and mutually agreed to the
approach.

Level of Details : Business requirements should be as detailed as possible such that the business
SMEs and SAP consultants can understand your exact business needs and write functional designs
based on these requirements. All these business requirements should be part of BPRD documents.

SAP BPD or BPRD : (also known as Business Process Requirements & Design document) Identify
all key end-to-end business processes that are part of your enterprise operations. Each of these
major business processes should have a dedicated BPRD document that should have all future
state business requirements clearly explained in a standardized template. The BPRD should be
signed off by the business SME, team lead and overall business lead. It may be worthwhile to
include signoff from the business stakeholder that is executive leader who owns this business
process.

Fit - Gap Analysis : I have seen projects where fit gap analysis is done in conjunction with business
requirements gathering. I would discourage performing SAP solution fit-gap analysis unless you
have clear understanding of detailed business requirements and also how the business processes
from one work stream integrate with other business processes across your organisation. It is critical
to have overall end to end picture of your future state business processes. Why ? Often the way you
want your future state business process to work may depend how other business functions use the
output of this business process and ensure smooth integration within your organisation.
Are all BPRDs (Business Process Requirements & Design documents) signed off by business? Yes
.... then you are ready to begin with the solution fit-gap analysis. You should make sure that senior
resources from SI are performing fit gap analysis such as Senior SAP consultant or Architect in a
specific SAP module. Imagine you have junior or mid-level resources that are doing fit-gap analysis
who may have much lesser knowledge of the standard SAP solution. Because they do not know
enough about the standard SAP modules, you may end up with RICEF inventory with lot of
enhancements or custom developed objects which in reality may be fulfilled by a standard SAP
functionality. If you are implementing specialty SAP modules or IS solutions with significant
enhancements or custom development, then I would recommend reviewing the RICEF inventory
with a SAP Solution Architect or Principal Consultant from SAP America or SAP AG on a short term
2-3 week engagement.

Project Estimations (or Work Effort Re-estimation)) : Now that you have better idea on the number of
RICEF and configuration objects, it is better to re-estimate the work effort for remainder of your
project based on these RICEF objects. Ask you Systems Integrator to estimation of the RICEF
object work effort and compare the estimates to the original project estimates done during the
project planning phase. If you have a independent advisor, he should do a cross check on the work
effort estimates based on type and complexity of RICEF object. Re-prioritize items in scope to meet
the budget and timeline if the work effort and costs significantly exceed the project budget. Make
sure that business stakeholders are informed of any items that may be de-scoped. Ensure you do

the re-estimation before writing RICEF functional specifications as you can save significant costs on
the items that may otherwise be descoped to reduce costs.

SAP Project Best Practices - Realization : Design, Build & Test

Share with your peers, friends or project leaders

During the realization phase of a SAP project, your main focus is on solution design (functional &
technical), RICEF development, data conversion readiness, system configuration, unit test and other endto-end testing of the SAP system with final acceptance by the business. QA testing including assembly,
integration and product testing. The ultimate goal of this phase is to build, configure and test the SAP
system and release it for go-live.

Review of RICEF estimates by SI Development Team : Most systems integrators may onboard
RICEF development team (also technical or build team) at the beginning of the realization phase.
Development team has to deliver the RICEF objects within the timeline and effort that were
estimated prior to beginning their work. It is important that you have the application development
lead and technical architects from your systems integrator review the estimates that were done at
the end of the blueprint phase and refine these numbers by working with the PMO and project
leadership.

Ensure that SI staffing model for realization phase matches with the work effort in estimations : SAP
system configuration, RICEF development and testing work effort is estimated by the SI followed by
your approval at the end of blueprint. Now make sure that the number of resources in each team
matches with the effort required to complete the deliverables as per the RICEF estimates. Other
teams such as PMO, BASIS, OCM and Training are duration based and staffing of these work
streams should match with the estimates provided by the SI at the start of the project.

Enfore strict change control governance : This is where projects run into cost overruns due to
excessive or poor management of change requests. Have an independent third party advisor along
with project sponsor serve as the head of change control board. All change requests should be
analyzed and challenged with any scope/cost adjustments by the advisor and project sponsor. If
extra objects or effort is requested, you should thouroughly analyze the reasons for these changes.
Each change request should also be technically challenged if necessary. Proper governance on
change requests can lead to significant cost savings. Always have a senior SAP skilled resources to
audit change requests if you do not have an advisor on the project.

Review, approve & sign-off on all deliverables : All deliverables in the realization phase should be
reviewed and signed-off by the project SMEs and leads from the SAP customer before it can be
taken to the next step. Universal Project Deliverable Acceptance & Approval Form should be used. If

your project does not have a template, I can gladly provide one for your project.
Functional Design Technical Design Build Unit Test Integration Test

SAP RICEF functional specification should be reviewed by the business SME and signed-off by
business team lead and overall business lead.

OCM/Training plans, documents and delivery aid should be reviewed & accepted by your internal
OCM/Training Lead and business stakeholders. Business stakeholders, project manager and
internal OCM Lead should signed off on this deliverable.

RICEF technical designs should be approved to the minimum by SI RICEF Lead. This leads can be
a ABAP Lead, SAP PI Lead, BI/BOBJ Lead or Conversion Lead depending on the RICEF object
type. Your internal technical leads should review and signoff on these designs. Business may have
limited knowledge and capability to review SAP technical solution. But the business should certainly
test

and

approve

individual

RICEF

object.

I recommend you hiring your own internal SME or leads for your company who are senior level
experienced resources in SAP ABAP, SAP PI, SAP BI and SAP BASIS. This will build your internal
SAP technical system expertise to support your business post go-live.

Security and IT infrastructure deliverables should be reviewed by your internal SAP BASIS lead and
overall IT lead of your project.

Some systems integrators may try to avoid Deliverable Acceptance forms and the process of seeking
written approvals from the client. But, I strongly insist the client executive leadership to enforce
deliverable acceptance + signoff by your internal team. This sign-off and acceptance forms will serve as
your critical supporting documents if your project lands into unforseen challenges or may be even goes
into legal proceedings.

Early baseline configuration of SAP system : This will help the developers of your RICEF objects to
perform unit tests properly with basic system configuration required for testing. Review the
configuration with business process owners. Completion of SAP system configuration from the start
of baseline configuration is an iterative process. I recommend thorough documentation of each
change to the initial baseline config in the configuration rationale. This would provide the business
leadership an insight into your business process configuration and history of all changes that were
made. It will also serve as a configuration reference guide after your system go-live.
IMPORTANT: This baseline and final configuration should be part of configuration rationale. It
should be approved and signed off by the SME and business lead. Configuration Rationale should
include all changes that were done to support successful integration test of business process
scenarios.

DOCUMENT! DOCUMENT! Each SAP customer is unique and hence the system setup and
configuration : For your internal project SME and leads, I always believe in documentation as you
learn or do things in SAP system. When you learn something about SAP system configuration,
system processes, transactions, programs, etc. please document it even if it is your own raw
language. You are learning a lot during the entire project and it is natural tendency of a human being
to forget information especially when there is an overload. Documentation if needed will only help
you as your own internal reference guide.

Integration test only after completion of all unit tests : Integration tests will follow upon completion of
unit tests and overall when the RICEF development with the necessary system confuguration is
complete. SAP Integration Testing will test your end to end business process (typically multiple unit
test scenarios) is working together. It is ideal to start integration test for your entire project only when
all unit testing is completed. But many projects have tight timeline and this may need to be started
sooner. To the minimum I would recommend that all the unit tests assosciated with a integration test
scenario be complete and signed off before beginning with a specific end-to-end integration test.All
integration tests should be signed off by SME, team leads and overall business leads. Your QA lead
should coordinate and manage completion of integration tests, assembly tests and UAT.

Thorough Integration Tests: I recommend maximum business users and SME participation for
integration testing of your SAP solution. This will allow mutliple resources doing the same end-toend integration tests with broader coverage of test scenarios and natural human tendencies while
using

the

SAP

system.

Thorough Integration Testing w/multiple users = Better Quality Production System

Your SME and users from run the business (RTB) will anyway work in the new SAP system. So why not
include them a little early allowing a better knowledge transition and also benefiting the project team to
allow more users test their business processes.

Regression Testing "A MUST" : You must have heard this several times in IT projects. "I created a

fix for business process A but that broke business processes D, E & F." Well! While implementing
SAP it is no exception. If you enhance a system process or fix a system defect, please make sure all
the other processes that are affected by this change are tested thoroughly. If you are using SAP
eCATT or other automated test tools, then I suggest creating regression tests that you can run
periodically but more so when you change configuration or RICEF object. I have seen a lot of

projects run into production issues after go-live because of changes that were made during testing
phases. But these changes were made to fix a business process but it had a negative impact on
other related business processes.. Just before go-live run a final SAP integration test cycle to

ensure all the business processes are working as desired "end-to-end" after all changes have been
implemented in the system.

Start data cleansing and conversion early enough to meet system delivery deadlines : Begin
analysis and cleansing of data in your legacy system early in realization. Start with the development
of transformation and load programs early enough so that these objects are ready before integration
testing. By end of realization you should have completed loading sample data into your QA
environment and business process owners should have successfully tested their business scenrios
with this sample data. Ensure approval and sign off on the data conversion for each business work
stream upon completion of these tests.

SAP America Go-Live Readiness Check : Finally, I highly recommend inviting SAP America / SAP
AG for a quick "GoLive Check" to get a blessing that you are ready to go-live with your SAP system.
SAP America / SAP Inc over the years have reviewed, troubleshooted and fixed major
implementation problems on several thousands of projects. This check will only benefit you to avoid
any obvious system go-live problems associated with your SAP components and overall solution.

FUNCTIONAL DESIGN
To speak at macro level that is at project manager or at senior levels. The Functional Spec (Specification) which is a
comprehensive document is created after the (SRD) Software Requirements Document. It provides more details on selected
items originally described in the Software Requirements Template. Elsewhere organizations combine these two documents into
a single document.
The Functional Specification describes the features of the desired functionality. It describes the product's features as seen by
the stake holders, and contains the technical information and the data needed for the design and development.
The Functional Specification defines what the functionality will be of a particular area that is to be precise a transaction in SAP
terminology.
The Functional Specification document to create a detailed design document that explains in detail how the software will be
designed and developed.
The functional specification translates the Software Requirements template into a technical description which
a) Ensures that the product feature requirements are correctly understood before moving into the next step, that is a technical
development process.
b) Clearly and unambiguously provides all the information necessary for the technical consultants to develop the objects.
At the consultant level the functional spects are prepared by functional consultants on any functionality for the purpose of
getting the same functionality designed by the technical people as most of the times the functionalities according to the
requirements of the clients are not available on ready-made basis.

What is the LSM workbench?

The LSMW (Legacy System Migration Workbench) is a tool based on SAP software that supports single or periodic data transfer
from non-SAP to SAP systems (and with restriction from SAP to SAP system). Its core functions are:

Importing legacy data from PC spreadsheet tables or sequential files

Converting data from its original (legacy system) format to the target (SAP) format

Importing the data using the standard interfaces of SAP (IDoc inbound processing, Batch Input, Direct Input)

Which data can be migrated using the LSMW?

By means of standard transfer programs: a wide range of master data (e.g. G/L accounts, customer master, vendor master,
material master, bills of material) and transaction data (e.g. financial documents, sales orders)

By means of recording of transactions: further data objects (if the transaction can be run in batch input mode)

Is the imported data consistent?

Yes. The data is loaded via the standard interfaces of the applications. This will include all checks that are run for online
transactions. Invalid data will be rejected.

Are conversions carried out identically across the applications?

Yes. The LSMW works on the principle of central (reusable) rules. This approach guarantees that, for example, the material
number is converted in the same way
wherever the reusable rule is used for conversion.

What is Client? What is the difference between Customization and

Configuration?
The difference between cutomizing and configuration is:
- CONFIGURATION: we will configure the system to meet the needs of your
business by using the existing data.
- CUSTOMIZING: we will customise or adapt the system to your business
requirements, which is the process of mapping SAP to your business process.
- CLIENT: A client is a unique one in organizational structure, can have one or more
company codes. Each company code is its own legal entity in finance.
Configuration vs. Customization
When considering enterprise software of any type, it is important to understand the
difference between configuration and customization.The crux of the difference is
complexity. Configuration uses the inherent flexibility of the enterprise software to
add fields, change field names,modify drop-down lists, or add buttons. Configurations
are made using powerful built-in tool sets. Customization involves code changes to
create functionality that is not available through configuration. Customization can be
costly and can complicate future upgrades to the software because the code changes
may not easily migrate to the new version.Wherever possible, governments should
avoid customization by using configuration to meet their goals.Governments also
should understand their vendor's particular terminology with regard to this issue since
words like "modifications" or "extensions" often mean different things to different
vendors.