Skip to Content

Some more random thoughts on CRM2007

Some time ago, I posted a blog CRM2007 : Some pain-points from a business user’s perspective on some pain points in CRM 2007. As I get more familiar with the tool, I have a few more thoughts to share with the community. I also want to thank all of those who communicated with me on these issues on SDN itself, and on email.  Some of these  are not CRM2007 issues per se, but things that have been carried over from prior releases. 


Standard implementation option is a BAdI


Although I don’t code much anymore, I used to be one for several years. I am not shy to use BAdIs when needed. That being said, I cannot find a good reason why the standard option for a certain feature is a BAdI. I also find it weird that some BAdIs are delivered as active in the system. A BAdI is costly to maintain – and I firmly believe that all standard SAP processes should run in a consistent fashion without a BAdI. They should be only used in cases where a customer wants to extend the functionality – nobody should be forced to use them.


Partner Channel management doesnot expect a person to be the contact person for two organizations within his company 


CRM uses ACE functionality to determine who gets to see what in the system. A typical use case is to determine the relationship of a user to an organization by the contact person relationship, and then determine if he can see a document that belongs to that organization. This works well if Joe is the contact person for his company’s UK branch alone. Let us say Joe is now also the contact person for his company’s office in France. Joe is created as a business partner of type person in your CRM system, and the UK and Freance organizations re created a business prtners of type organizations, and probably with a role of channel partner.


One would expect that is a normal business case, but partner channel management has an inherent assumption that one person will never be the contact person for more than one channel partner. This makes modelling the ACE rules almost impossible in the standard. The only way in standard that I could make out is to create two business partners of type person for Joe. This is a terrible way to solve the problem.  It should be noted that the system does not mind creating Joe as Contact person twice – just that rest of the processes are designed to think of this as an error !


Condition records do not persist in a transaction


Consider this example – you have a transaction that uses condition technique. You create a transaction and figured that the system found the result of the condition as 50%. You save this result as transaction 1000, and continue with folowup transactions. Now some one changes the condition record value to 25%, with the same key values. Now, if you create a trnsaction 1001 – you will get 25% as the condition value found. This is completely correct. Now let us say you go back to 1000 and simulate the pricing. What do you expect to see as a user? I would expect to see 50% -since that was the applicable value when 1000 was created. However, you would see 25%, since the system does not persist the condition record in the transaction. If I am faced with this situation as a user – I would definitely think this is an error and then call the help desk. How does the help desk solve this issue? 


Guided Procedures versus Fast Entry Screens


I love to use guided procedures – I think they are great. But I am not sure if this will be such a great feature for a user after he or she gains familiarity with the system. If I book a flight on internet, I would love to be guided. However, a professional travel agent will probably find that it is a nuisance to be guided across several pages, when he knows exactly what he needs to do upfront, and could just put them into one page and get a faster result.


Several transactions in CRM now have Guided procedures. There is no choice for an expert user to switch to an expert mode, unless you develop the application from scratch. I would like SAP to give a fast entry option for high volume transactions, with a choice to use guided procedures if a user wishes. Since CRM2007 is new, I guess SAP can take some time to do this before customers start complaining. nevertheless, I am very curious to learn if there are any plans to do this at all.

You must be Logged on to comment or reply to a post.
  • Personally I don’t find the concept of everything being implemented as BADI’s a bad thing.  You have to consider that CRM was created before tools such as the switch and enhancement framework were available.  The BADI’s you describe are almost a poor mans way of solving the problem.

    I would guess if the CRM developers went back and “re-wrote” those old sections then you probably see less use of BADI’s to solve the problem.  I guess the alternative would be to go back to the dark ages of SAPMV45A style coding, which works fine, but has its share of drawbacks.

    The only reason why IMHO that CRM has been able to transition between so many UI’s is due to the MVC design paridigm of the application.  The badi’s were just a natural extension of trying to make it that way. 

    Take care,


    • I see your point, Stephen. It is a very perceptive.

      BADI’s are not bad – but the use should be to supplement a core process. It should not be the only option around – because then there is limited reason to go for a packaged solution like SAP.