Strategic Direction for SAP CRM

1
1049

Share on LinkedIn

SAP’s CRM 2007 is being touted as a major evolutionary release. The integrated Web UI, integration of Reports, enhancements in the TPM (Trade Promotion Management) and MDF (Marketing Development Funds) area do exceed customer’s wants and needs. The new UI is not only Web enabled, but also much user friendly and sophisticated. The ease of enhancing the new UI also will meet many of the customer’s wishes. However, in spite of these advancements there is a lot SAP can do to increase the customer base for CRM.

Many companies don’t pursue SAP CRM because of the cost and time involved to implement the solution. Though the solution is quite comprehensive, it carries a lot of weight too. SAP has to slim down the solution without sacrificing functionality to increase the market footprint. A typical implementation ranges from 12-18 months sometimes with extensive ongoing maintenance and support. In today’s dynamic business environment, not many companies have this extended timeframe.

The slimming of SAP CRM can reduce the implementation cost drastically and will allow companies to focus on implementing advanced business scenarios rather than just setting up the basics. In this article, I suggest three areas on which CRM practitioners spend quite a bit of their time without any added business value.

The first area is the Middleware (the message oriented communication system between SAP CRM and SAP ECC). Though Message based communications have their own glamour in terms of flexibility and scalability, the truth is they exhaust lot of resources in terms of daily maintenance and administration. It is true that they offer few restrictions in terms of the parameters that can be interchanged; however they do suffer from run time errors if the sending and the receiving party’s expectations are different. On the other hand having synchronous communication eliminates run time errors completely. Errors can be caught much earlier during development time itself. Of course it requires a tighter coordination with the development team, but then you avoid the daily hiccups of BDOCs (the message data packets) being stuck (and avoid trying to track down the Middleware Resource).

Though an argument can be made for Middleware versus Synchronous communication, the more underlying question is do we need to replicate Master data at all (Master data is the reference data to support the business processes like Customers, Vendors, Products etc). The duplication of enhancements (custom development to support a specific company’s requirements) for Customer/Vendors (Referred to as Business Partner in CRM) and Materials (Referred to as Products in CRM) in both ECC as well as CRM doesn’t add any business value at all. If a business process being executed in CRM requires the Master data, it should be able to pull the data either directly from ECC or from the Cache populated from ECC. It is also an option that the data be downloaded to the CRM database without any enhancements of the CRM application (Could be achieved through Metadata). Of course this would mean that the Customer Master in ECC is extended to the Business Partner concept which is much more encompassing and flexible. However, we already have this in the ECC systems, even though it is not used actively (Some verticals like Utilities and Media do use the Business partner itself). Similarly the Material Master will have to be scaled to be able to behave like a product.

The third point that deserves some reconsideration is the duplication of functionality within CRM which already exists in ECC. Case in point is the CRM Sales. ECC Sales (part of Sales and Distribution) not only provides most of the functionality, it also has robust and tight integration to the Shipping and Distribution functionality. In CRM Sales, we duplicate most of the functionality without any added business advantage (there are of course some benefits like multiple similar Partner Functions in transactions but again ECC should be extended to achieve this). However, even the advantage of these benefits in CRM Sales is discounted since these have to be removed before say the Order is distributed to ECC. The same goes for IPC (“Internet Pricing and Configurator” which implements the pricing and product configuration in CRM) which also doesn’t add any additional benefits other than supporting the CRM and ISA (Internet Sales Application which is part of CRM). The custom enhancements done to Pricing in ECC have to be re-implemented within IPC. ISA and CRM could have used ECC Pricing instead of using IPC which adds to maintenance without any added benefits. In fact, the approach should be that if any functionality is already implemented to a major extent in ECC, it should be enhanced to meet the CRM implementation and an RFC call should be made to trigger the appropriate functionality.

Of course, solving all of these would require lot of time and effort by SAP to enhance the ECC and to shift the burden from CRM. Though costly, it would have its own ROI benefits for ECC itself apart from gaining an edge in the CRM Marketplace. For example a major selling point for CRM Sales is the fact that the partners can be determined from multiple sources through Access Sequences. ECC also has Access Sequences and there is no reason why ECC shouldn’t be enhanced to take advantage of this benefit. The way this will help CRM, as mentioned earlier, is that the customers can now focus more of their efforts of CRM’s market oriented requirements rather just duplicating the work.

Customers today and in future are not going to invest in CRM spending their tight budgets on implementing just the basics and trying to get these to work when what they really want is advanced CRM functionality that they had originally bought the product for.

The reason for the success of lightweight CRMs like Salesforce.com is that they do not require major implementation commitment. Though a leaner CRM would still require a practical commitment in terms of time and resources, at least the customers wouldn’t be wasting their time and money on duplication of what has already been implemented in ECC.

Rajiv Chopra
Consultant
Rajiv Chopra is a SAP functional consultant with experience in FI, SD and CRM business areas. He is also experienced as a software architect for several high profile projects. He has a master's degree in electrical engineering from I.I.T. Mumbai. He enjoys sports, cycling and traveling.

1 COMMENT

ADD YOUR COMMENT

Please use comments to add value to the discussion. Maximum one link to an educational blog post or article. We will NOT PUBLISH brief comments like "good post," comments that mainly promote links, or comments with links to companies, products, or services.

Please enter your comment!
Please enter your name here