This is the second blog of a series, trying to describe our approach to integration within our SAP solution.
One of our recurring need is the integration of our specific business process logic with the standard functions of SAP ECC solution.
A real-life example can be found in the implementation of Real Estate Flexible (I will use the RE abbreviation) module. This module is central in our implementation, because this business is central for our organization.
We have two business units operating in the Real Estate field:
- commercial Real Estate BU;
- residential Real Estate BU.
Now, let's take into consideration the standard RE General Contract. It is well designed for lease-out contracts, also classified as "occupancy" contracts (the rental unit is occupied by a business during the contract life, and cannot be lent to another customer). The General Contract can also be configured for non-occupancy situations, or several different business arrangements.
Well, this contract is ok for our commercial BU. But when we analyzed the residential BU, the things were slightly different: the sale process, for an apartment, starts usually before the beginning of the physical construction of the building.
The customer "reserves" the desired apartment, paying a first little advance payment. After a month, the reservation is accepted and undersigned by our company, the customer pays another advance amount.
After this agreement, the building is developed - during this period, the customer may be requested to pay one or more additional advance payments - and finally the apartment is ready for the customer. At this time, the official legal act, declaring that the customer is now the owner of the apartment is underwritten, and the sale process ends.
Looking at our administration process, the "contract" initial date is the first reservation date, and the end date is the day when the legal act ("rogito" according to Italian laws) is undersigned.
During this period, the apartment should be considered "occupied" (also if it is not built), but, when the contract ends, the apartment should remain "occupied", with a special status, as it is no more owned by the selling company.
In our RE implementation, all of the steps of the sales process are managed using different conditions (a condition in a contract usually originates a one-time or a recurring invoice or some different sort of posting). Using the enhancements methods built in the module, we have enriched the dataset of the contract, with some additional, legacy data.
The result is a contract where the fact that a specific cash flow, with a specific condition type, is effective, means that the corresponding step in the sales process is completed (e.g.. the customer has signed a preliminary sale agreement).
After the deployment of the project, we have developed an appropriate model for Business Intelligence, using SAP BW. Here, again, our requirements were met using a data model that represent our specific business process, extracting the relevant information from the RE Contract.
Reviewing this general approach shows that the logic governing our business process was injected in the system mainly at two points:
- the "data level", adding legacy information, or giving a specific semantic to existing data structures;
- the "business intelligence" level, reshaping the standard information extracted from ECC, in order to represent the correct status of the business processes.
I believe that this approach has the disadvantage that the knowledge of the specific meaning of some chunks of data remain outside the system, or is somehow hardcoded in the ETL process.
We can also note that our requirement was not to change the functional behavior of the standard SAP module, but only to incorporate some additional data, and to represent our business logic trough standard elements.
Now the question is: "if we want to optimize in this way the enhancement process of standard SAP functions, what is the best layer to touch, where should I inject my specific logic?"
My answer is: "where you can leverage your effort making it available to the widest range of interfaces."
Applying this answer to our original implementation, it is clear that we haven't adopted the best approach: injecting the business logic at the BI level, means that the result can only be used in the analytics world developed on top of our Business warehouse system.
I will describe, in the following post, the approach that, by my point of view, is optimal.
- SAP Managed Tags:
