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.
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.
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 vice-versa, 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.
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.
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.
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.
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.