SAP provides customers with a powerful system capable of modelling the most common business processes. A SAP system like R/3 could be seen as a semi-standard software: It is oriented on global players resp. representative proxies and their favors. As I heard, SAP often designs its software by taking the needs of their most important customers into account as best as it can be done, generally speaking. That is the theory.
Practically, a customer with some thousand employees cannot run a software system coming out-of-the-box. That's not the fault of SAP. It should be crystal clear that a huge company needs to modify a proper solution serving basic needs.
There are several mechanisms within a SAP system allowing a customer to sort of customize the system to individual requirements.
I don't want to enumerate all, but here is a collection: BAdI's, customer exits, customizing capabilities in general, screen modifications and pre-definable customer variants.
In one of my projects there is the strong need for adjusting the "legacy" SAP system to specific requirements. For the customer - as for any serious software developer - it is seen as given that a big and sophisticated system is open to modifications without hassling around too much. This expectation was disappointed seriously. Function modules available originally from SAP are partly working with global variables. As it might be known, those global variables are not available globally in the whole system. They are only accessible from within the corresponding function group. That means: if you want to use an already implemented functionality, sometimes the only way to do so is copy the whole *%;/ and then use it in your own scope. Who invented this? Such mechanisms are out of anyone's understanding, I believe strongly. And I tell you what: Those function modules in question were implemented by SAP in Juli, 2004! Do you believe me?
Another favor is the concept of BAdI's (Business Add-In). It is similar to a customer exit: SAP foresaw the need for a customer to adapt a standard logic. Therefor a "method" will be called, which can be implemented by the customer. If there is no implementation by the customer it means that the system will not do anything special. But if the customer implemented it, it will be executed. One problem here is the input parameters supplied for the called functionality. Again, the customer is dependent on the ingeniality of the system designers. If they have not foreseen all the possible cases - which sounds impossible - then the customer most probably must implement a work-around. A bad thing if it is based on a modification as you latest will notice when applying a hot fix being correlated with a modified piece of code.
In recent weblog entries (The Future is OO - Travel Back to the Past? and Perspectives on ABAP/Objects), I wrote about ABAP/Objects. Now, if we compare the alignment of object-orientation with reality in several SAP industry solutions, then we can realize a discrepancy. It is fact, that some industry solutions are not extendable in a reasonable fashion. ABAP/Objects claims something different. But a huge system being many years old and containing myriads of lines of code cannot be transformed into a new paradigma. Even SAP noticed that and did some work-arounds. Example: Some includes exist in two stampings: one for the use in a procedural environment and one to be included into an ABAP/Objects class.
It should be considered to tell the customers explicitly the possibilities and dangers of extending a SAP solution. In one of my projects there was not one single line of documentation available on the subject of extending the system's logic significantly, which I did not only prove by myself but let prove a SAP SI consultant who again called SAP developers that were involved in implementing dedicated pieces of the solution beforehand! And they would not be quiet without reason concerning documentations!
So, either try to replace all legacy SAP systems with NetWeaver or help the customer by supplying valuable documentation as a matter of course. Both ways do not ensure a clean cut but a bird in the hand is worth two in the bush.
