Skip to Content
Author's profile photo Former Member

Should the term ‘RICEFW’ be Eliminated ?

It’s worth considering what impact using the term RICEFW or FRICE has on actual SAP projects, and when forming personal impressions about SAP products for that matter.


Are there any benefits to under-estimating, over-simplifying, and under-mining development efforts which make up such a big piece of SAP projects — by conveniently wrapping them up into this common term ‘RICEFW’? 


Through this blog, I ask you to think about whether we should even use ‘RICEFW’ or ‘FRICE’ at all?


For a good crash course on this acronym, Salai Sivaprakash has captured some helpful background about the term in this wiki.



  • The Problem with RICEFW

The issue lies in the letters. As with all acronyms, each letter represents a specific word or concept (in the case of RICEFW — a development object).


I would contend that referring to all objects as ‘RICEFW’ often leads to development efforts being misconstrued or overlooked when implementing / upgrading SAP technology — thereby leading to inefficient / ineffective object development.


What does RICEFW really stand for?


RICEFW stands for something very complex:

Each letter represents a critical component of most SAP projects.

Such a simple acronym reveals a world of complexity in terms of the possible tools and technologies to use. Furthermore, we now have so many choices for object development (each one having its associated pros and cons), given the capabilities of SAP’s latest platform. This wasn’t necessarily the case in the R/3 era or before.


See the below image, in which ‘Interfaces’ alone has 6+ different tools/options for development:





































This image provides just a sample of tool choices for each object type. Every tool / approach has their own set of features & processes to work with — so how can they be generalized so much by throwing around the acronym RICEFW just for the sake of convenience? (or perhaps ignorance??)



RICEFW stands for 6 completely separate object types:

When estimating development effort required or level of complexity in a solution approach using the term RICEFW, practitioners often overlook each object’s importance and its independent significance within the whole development approach. So all the object types end up getting clumped together as ‘RICEFW’.


Can Reports really be tacked in the same way (and with the same set of skills) as Interfaces? Not really. So then why are they so casually combined as part of the overall development effort?


Again, the term ‘RICEFW’ is to blame for generalizing the approach when developing these totally separate objects.



  • The impact of RICEFW on projects

This habitual use of RICEFW can have serious consequences on the way projects are carried out. It is all too common for project teams to under-estimate the effort involved in each object type by assembling them into of 1 not-so-simple acronym.


How RICEFW is ruining SAP implementations:


1)   Under-mining the role of an ABAPer because he/she is deemed to be able to develop ‘everything under the sun’ when assigned to the vague term RICEFW.  In fact, this terribly non-specific term actually deflates the ABAP SKILLSET. So individual or specialized ABAP skills are not really given their due importance when factoring and executing RICEFW object development, since it’s treated as just one big animal.


2)   Inhibiting the process of performing important ANALYSES that would determine the most suitable tools for each of these development objects.


3)   Not completely satisfying the customer’s requirement when the incorrect TOOLS end up being selected — which likely results in way too many customizations / codes.


4)   Diminishing the importance of INNOVATION in SAP. There’s an unfortunate trend that not enough project teams take the time to select the right tools that are right for the requirements. This would suggest that SAP’s efforts and money spent on introducing innovative tools and methods are not being effectively utilized.



  • The need to eliminate RICEFW

Some negative outcomes of using RICEFW:


1)     Invites unnecessary customization. Since the correct tools are not selected according to development object type, it can lead to SAP getting a bad rap due to the negative impression that it creates for end users: “SAP is too complex and not user-friendly.”


2)     The ABAP skillset has become highly commoditized. Particularly in the context of RICEFW, specific ABAP skills around the relevant tools often get disregarded. It’s like saying “Since RICEFW objects are in scope, we need an ABAPer” (therefore any ABAPer will do).  It’s a shame that ABAP developers generally get herded under the whole RICEFW umbrella, which really de-values what they bring to the table for actual SAP projects.



  • Possible solution…?

I would propose to either ban RICEFW altogether or start analyzing each ‘letter’ as a separate entity when planning SAP Projects.


And let’s not forget that SAP has evolved a lot over the years and has introduced more innovative ways of implementing their software. So as SAP practitioners, it should be a challenge and goal (if not a responsibility) to assimilate those changes into the way we approach projects.


Spelling out RICEFW is a small step in that direction and ideally will lead to more clarity in project planning. We owe it to our customers and the developers in our current and future projects to give attention and due importance to the details behind this acronym.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Bill Wood
      Bill Wood
      The graphic is really great!  Good illustration...


      Having said that though, since starting with SAP in '94, I have only ever seen a handful of really good developers.  Lots of fair to decent ones, and a LOT of sloppy coders.

      As a functional consultant I'm still baffled by how few ABAP coders have any real skill at the critical tools of their trade. 


      For example, as a functional consultant I have had to do a LOT of my own data conversions and reports.  That has required me to learn how to use the CATT tool previously (before it was disabled in the ECC versions) and now LSMW.  I'm still completely baffled by the number of ABAP programmers who insist on writing completely custom conversion programs when standard ones are available.  I'm still baffled by how few of them have any idea on how to use MS Access to do their data cleanups / data transformation rules.  And even more floored that of the ones that do have some exposure to LSMW don't know how to code decent conversion rules.  And I'm NOT a coder!


      Same here, I'm so tired of projects where as the functional consultant I literally have to spell out every table, every field, all of the calculation logic, and all of the pseudo-logic for coding.  So, again, as a functional consultant I've learned how to use SAP standard Query tools to develop my own ALV reports, even doing some of the custom coding in them as necessary. 


      Ditto above.  I can't believe how many times I've seen "experienced" ABAP coders completely trash the SAP provided print program and try to re-invent the wheel.  It's not so bad for some of the simple things, but for more complex forms like sales related forms the pricing alone can cause nightmares for most ABAP coders.  Then there is the issue of smartforms.  What a terrible waste.  So many coders I've seen have very little idea on how to do forms.


      WAYYYYYyyyyyyyyyyyyyyy way overused.  To this day I'm still surprised by the amount of functionality the standard system provides.  And how much of it can be carried out with re-purposing other fields or functionality.  Too often niether the functional consultant nor the coder have a good idea of what might be available to solve a particular problem so down the custom coded road we go.  Or worse still, when custom coded requirements do come up, rather than using table driven solutions, or the standard SAP option table, they hard code values in the programs.

      Anyway, I could go on.   I think the bigger issue is with the quality of BOTH functional and technical consultants ensuring that they are doing what is truly in a customer's interests.  Too often I see lots of bandaid patchwork, or get called in to clean up messes left behind by others.  Not a fun job.

      So, instead of eliminating FRICE maybe the standards for SAP consultants should be raised.  After all, the application is very mature and even with each new release there is not a radical departure in functionality.


      Author's profile photo Former Member
      Former Member
      <<I think the bigger issue is with the quality of BOTH functional and technical consultants ensuring that they are doing what is truly in a customer's interests. Too often I see lots of bandaid patchwork, or get called in to clean up messes left behind by others. Not a fun job.>>

      I hear ya on this point, Bill - it really should be a hand-in-hand effort between both technical & functional consultants who 'know their stuff' in order to get the job done right.

      As to your other points (and to the techies' defense:) - I know a good number of both ABAP & JAVA developers who can practically code backwards, and that too, using most of the latest tools offered by SAP. These folks can also provide business logic to support any development decisions taken when approaching all of the development objects mentioned.

      Example: anyone who's familiar with Enterprise Services MUST understand the processes behind those services. So it's not just that 'trashing programs' & 'reinventing the wheels' are necessarily at play here (meaning, there could possibly be some good reasons behind those decisions). The priority should really be to utilize tools that satisfy the requirement COMPLETELY, with minimal effort/coding.

      A couple of other observations/issues that affect developers’ ability to effectively 'deliver':

      -- It’s common practice to involve technical consultants only after **blueprint** phase. Therefore, they don’t really get a 'seat at the table' when it comes to making critical decisions (they’re just brought in during **realization** to tackle the RICEFW monster).

      -- Still A LOT of people are not aware of the latest tools available for SAP development. Taking Forms for instance - while BSP is very rich indeed, it’s not necessarily a good option if the same thing can be done in Visual Composer (which is arguably much easier & efficient).

      So...while you make some good claims about how developers need to be up-to-speed on using these tools effectively (which I consider to be a given), it’s really more up to the project PLANNING folks to align the right resources and accurately capture the efforts involved, in order to truly raise the standards of how SAP is implemented (and not necessarily the CONSULTANTS executing that plan).

      Author's profile photo Former Member
      Former Member
      The graphic is really great! Good illustration...

      Really? My corporate firewall recognizes the site where the picture is hosted as one which is also related to *p*o*r*n material and therefore blocks it.

      so, no chance to see it ...

      Author's profile photo Juergen Puhane
      Juergen Puhane
      Hello! Partly you are right that SAP each letter describe different content. But from my nearly 20 years of program manager expiries I saw too many projects being stopped or delayed, because nobody thought about these nice letters: RICEFW.
      The related effort and duration is so often under- or over estimated - pending which expierence people had in the past with these topics.
      Author's profile photo Former Member
      Former Member
      We have been working on new documentation templates at work based on the standard methodology. The basic problem is that a given task doesn't fit neatly into one of the pigeon holes.

      A given project may spawn some new objects and/or functions, a few new tables/structures and all sorts of new programs. At the technical level they all fit together, with pieces in "reports", "interfaces" and "enhancements". Which hole you put a piece of work in is arbitrary and not actually very helpful.

      I completely agree that this artificial and antique nomenclature has to die and be replaced by something that more accurately relates to reality. Once that has happened we can then look at the commoditisation of ABAPers and the tendency to hire tha "I have a hammer, everything is a nail" approach to programming...

      Author's profile photo Former Member
      Former Member
      Thanks for quoting my wiki. I used to wonder if anyone read it.

      A very interesting perspective, I would say. However, I will have to disagree! I had started my career as an ABAP developer, 10 years back, but I still find the FRICEW classification very useful to blueprint any project.

      Though the acronym just stands for 5-6 types, in projects we use many more. Like A-Application; G-User Interfaces (like Flash, Silverlight, Portal); S-Security; J-Jobs; X-Extracts; O-Process; D-Documents (like Strategy, Reference, Standards); B-Database; M-Maintenance objects; T-Tools (IT); U-Reusable Components etc. and many more.

      These align very well with BPM modelling and managing the SAP software. And Business understands this.

      Neither is the mapping between a repository object and FRICE object One-to-One, nor is a repository object always in the same category. An web dynpro can be a Report; an executable program (report) can be a workflow (say mass approvals); an include can be part of 2 different enhancements; A function can be part of an interface as well as an enhancement.

      I agree that FRICE may be an old term and can be renames as "Software Inventory" or "Customization Inventory" etc.

      We should also note that FRICE classifications are an ERP term and not just SAP term.

      Using FRICE classification blindly for estimating and pigeon holing are bad practices that has to be done away with. But FRICE is here to stay...

      My 2c