SAP CRM Marketing for Utilities – Object based Segmentation without ADS and BW
One of the limitations of SAP CRM: Marketing when used in the utilities context is that segmentation based on objects (Segmentation Based on Relationships) is only supported using either ADS or SAP BW data sources. This is a quite a severe limitation as even in simple scenarios in the utility context, object information is required. The reason is, that it is quite common for utilities customer to hold several contract on several premises.As an example consider a father that pays the electricity bill of his son living in a student apartment. This father will have at least two electricity contracts, one for his home and one for the student apartment. Additionally, he will most likely have further utilities contracts, e.g. water and/or gas for his home. For any marketing scenario beyond a simple use latter therefore information regarding the contract and the premise is required when addressing the customer. For example, it is not enough to write an email to a customer about a his electricity product X as the question for a lot of customers will be “About which premise are you talking?”. Instead information regarding the premise needs to be included in the email. This is a significant difference to, e.g. an automotive context. If one writes to a customer about his blue 2015 BMW 3 series, it is usually clear which car is meant. Only very few customers will own several of those.
As an result of this limitation, it is quite impossible to start small with SAP CRM Marketing in the utilities context. Instead, up front always a SAP BW connection is required. Therefore, especially smaller utilities companies do not use the features of SAP CRM Marketing.
What is the reason for this limitation?
According to the SAP documentation for Segmentation Based on Objects (Objects in CRM) the following is required to perform object based segmentation with only CRM data:
The selection of objects is always performed via InfoSets. An InfoSet must be created for each object family. The InfoSet interface must return the following field information:
- Business partner GUID
- Object GUID
- Relationship type
- Object family
- Attributes and attribute values
However, for utilities contracts and the technical object (ie. connection object, premise and point of delivery) no connection via a relationship type exists in SAP CRM. Instead, special tables are used to store this information (e.g. table ecrm_isu_to_idx or isu_pod). consequently, object based segmentation with only CRM data is not possible.
Is there a solution?
While preparing a presentation of SAP CRM Marketing for one of our customers recently I had the idea to use CDS views (CDS – Core Data Services – ABAP Development – SCN Wiki) to implement a InfoSet. There reason was mainly that I’d rather would code a complex join in CDS than model it in SQ02. The first thing I did was to ask on twitter if anyone had experiences with doing this (ceedee666 auf Twitter: To all the #CDS and #ABAP experts:…):
However, I didn’t receive any responses to the question. This could mean two things; either the question is so stupid that nobody dares to answer, or not many people tried it and have experiences with it. For the sake of my self esteem I will go with the latter of the two options 😉 .
While playing around with CDS views and InfoSets I stumbled across a CDS feature that I hadn’t used before: Literals. This made me think is using CDS Literals it might be possible to overcome the current limitation of SAP CRM Marketing for Utilities.
CDS views to the rescue
The first thing I did was to create the following CDS view (available in text format at #10815517 – Pastie):
This CDS view is basically a complex join of the tables ECRM_ISU_TO_IDX, ISU_POD, CRMD_ISUEXTA4 and the BUT000 to link business partners, utilities contracts (table CRMD_ISUEXTA4) and point of delivery data (tables ECRM_ISU_TO_IDX and ISU_POD). The interesting part is line 24. Here, the partner function 00000001 (= contract partner) is added to the result of the view. Furthermore, the parameters in lines 28 – 30 limit the selection to contracts and PoDs.
Note, that this CDS view is a quick hack used as a prove of concept. I wouldn’t recommand using it in a productive scenario as several border cases (e.g. contract already ended) are not taken into account.
Next I created a InfoSet on the basis of the CDS view that returns all the elements of the CDS view.
Segmentation based on object data in CRM
Using this InfoSet it is now possible to perform object based segmentation based only on CRM data. As an example consider the segmentation model shown in the following screen shot. In this example I select all business partner that have a contract in the medium water in a street starting with the string “MAAS*”.
The next screen shot shows the details of the created target group. Here it is obvious that a single business partner is indeed linked to several objects in the target group. So using just the rather simple CDS view shown above, segmentation based on object data in CRM is suddenly possible.
Executing campaigns based on the object data
The final step is now to execute a campaign based on the object data. In order to do this I first created a custom attribute context in SPRO->CRM->Marketing->Marketing Planning and Campaign Management->Personalized Mail->Maintain Attribute Contexts for Mail Forms. For the prove of concept I simply added all fields of the structure CRM_ISU_TEC_CO to the context.
Next I created a custom implementation of the BAdI CRM_IM_ADD_DATA_BADI (#10815549 – Pastie):
In this BAdI implementation a select to the CDS view is performed for each of the business partners and some attribute values are filled based on the resulting data. Again, note that this is only a proof of concept. The implementation should in this form not be used in productive scenarios as e.g. no buffering is performed.
With the custom attribute context and the BAdI in place I executed a simple campaign with file export using the target group shown above.
The following screen shot shows details of the resulting file export. In this screen shot the main feature of object based segmentation is visible. For one business partner several entries are present in the result file, one for each technical object.
In summary it is possible to overcome the limitation for object bases segmentation in a utilities scenario with just one CDS view and and a few lines of code. Consequently, this approach should simplify the adoption of SAP CRM Marketing in the utilities context.
Great blog, Christian!
In automotive industry we use read program based infosets to accomplish the same. E.g. to segment vehicles (which are individual objects) based on their attributes. Believe me, there are plenty of people/companies who own many cars with same attributes (for example, model year or color). In this case we create complex joins in this read program (for example,joining z-attribute set type table, comm_product, comm_il_prdbp etc.), select desired individual objects (e.g. vehicles) and provide all appropriate fields back to the infoset structure (GUIDs, relationship type, product family and attributes).
But CDS definitely is a way better to model such complex infosets for segmentation! Thanks again. Need to try it!
thank you for this blog, using CDS is indeed a new approach.
For a customer we've implemented a solution using a remote InfoSet to perform the segmentation. From CRM we're calling an InfoSet in ERP (here: IS-U), which is based on a program (custom code) - most probably similar to the comment above, but for the Utilities industry.
The logic in this custom code is too complex to be expressed in a CDS view. The resulting query is optimized for performance and supports selection options.
This implementation gives the marketeer access to a lot of additional fields, which wouldn't be available in the standard, e.g. segmentation based on the Tariff Type.
So for the end user this solution is quite powerful and convenient.
This blog post is wonderful! In my opinion you're the perfect candidate to post improvement ideas on http://influence.sap.com/SAPforUtilities. Did you give it a look already?
Somehow I missed the current improvement round for SAP for Utilities. Thought I had registered already.... Will definitely have a look now and see if I can add something.
As I read your article about utilities process framework calling in background and had some things to point out - here I am really impressed :-). Finally someone with creative idea - I am going to test it myself, but really good job!