http://www.ciovp.com/RICEF-on-SAP-Projects-and-Estimations.

php

Previous postNext post

Should the term 'RICEFW' be Eliminated ?

Posted by Ranjan Baghel in ranjan.baghel on Apr 20, 2010 4:40:35 PM
inShare

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." 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.

2)

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.
865 Views

Average User Rating (0 ratings)

inShare

6 Comments

Bill Wood Apr 21, 2010 10:43 AM

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. CONVERSIONS... 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! REPORTS 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. FORMS

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. ENHANCEMENTS 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. JMO...
Like (0)

o
Ranjan Baghel Apr 21, 2010 4:32 PM (in response to Bill Wood)

<<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': -- Its common practice to involve technical consultants only after **blueprint** phase. Therefore, they dont really get a 'seat at the table' when it comes to making critical decisions (theyre 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, its 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), its 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).
Like (0)

o
Anton Wenzelhuemer Apr 22, 2010 5:57 AM (in response to Bill Wood)

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 ...
Like (0)

Juergen Puhane Apr 22, 2010 4:07 AM

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. Regards, Jrgen
Like (0)

Adam Trickett May 28, 2010 6:56 AM

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...
Like (0)

Salai Sivaprakash Jun 4, 2011 8:22 PM

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 Salai

What is RICEFW ?

Mon, 09/06/2010 - 04:09 mac

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 extraspecific. 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.