A couple years back I had an idea for a book on the technical aspects of implementing and supporting SAP CRM. The title for one of the chapters was called the “Zen of SAP CRM”. Although that chapter title never made it into the book that was published, I personally liked the name. In the recent months I have wanted to create some new technical content on SAP CRM. However I’m challenged to do something that doesn’t cover what was in the book.
During the end of my writing process for the book, I came up with a way to reverse and flip all the content based on the project lifecycle by functional requirements instead of coding examples. During this blog and hopefully a few more we can explore more of the thought process before I write the code. Let’s start with business process design basics for SAP CRM.
Getting Started
Most of my projects to solve a business problem with SAP CRM, start out with a specific need or issue surrounding sales, service or marketing. These problems could include tracking customer complaints, recording information about customers and many other types of customer related issues. In evaluating these requests we have to determine whether SAP CRM should be used in the first place. The major deciding factor on whether SAP CRM can be used to solved the problem is that the problem involves a management of interactions between two business partners.
If you don’t know lot of about SAP CRM or do know and have your thoughts on SAP CRM, you may sometimes focus too much on the C in the acronym and less about “RM” in CRM. The relationship management tools in SAP CRM do not have to always be used for “traditional” customer relationship management scenarios. This concept is key in being able to think about handling requirements that don’t match standard processes. In order to do this I need to think creatively on how business partners and business transactions can be used in SAP CRM.
Standard Process or System as Template
I think in an ideal world we would all love to use standard pre-delivered processes. The issue is that how each business wants to interact with their customers is different. When I implement a new business process in SAP CRM, I use the existing processes as a template. You might argue that takes a lot of work, but honestly I have configured prototypes of a new process very quickly. The other part is that sometimes we box our minds into thinking the system can’t do something when in fact it’s just configuration and we are unwilling to go in a different direction. I have used this approach to model new types of business partners that are “things”, but not materials.
Mapping out the process
The biggest problem today is we think “user interface” = “business process”. That’s a huge issue because data entry is only a few steps of a business process. I prefer to sit down and map out the target process in abstract. As you can imagine the design includes what to track, validation rules during tracking and steps involved during a normal lifecycle of that process. During this process we ignore the user interface of the system and focus on business scenario. Our goal is to drive the requirements based on business need and not making the business necessarily match the system.
My goal is always to figure a place in standard SAP CRM that can store/manage the requirements of the business process. That being said certain business scenario templates require a more specific design process that tailors to that basic scenario. Depending on the initial requirements we can “personalize” or “custom build” a solution. In my terminology “personalize” is adding on a few dealer OEM options while “custom build” is like getting car from “Gas Monkey” or custom chopper from Paul Jr Designs. The custom build scenarios are how I got started with SAP CRM and fuel my development work. I must admit a vanilla SAP CRM system would be very boring and not provide as much business value as a custom build.
Gap/fit analysis
It’s always the gap fit analysis where the difference is shown between those who understand how to utilize the system to the maximum with minimal coding and those who don’t understand the system, but code to solve problems. When I wear my developer hat my goal is not to write code. That’s my number objective is to make sure that any code written is only for true gaps. I personally only say no to a requirement in this phase if it does not have business value or I figured out via previous work that the system just doesn’t handle that requirement in fashion beneficial to the business. Understanding some of these system limits is part learning, research and trial/error. There are some pieces of functionality that look great on paper, but can be a pain when used productively.
Going Further
In order to really understand this further I am going to stop here for now, and will come back later with understanding how to map/analyze a business process to existing business process delivered in the system. I will try to look to at the key parts of how we take an abstract process and turn it into a fully configured business transaction. Keep in mind I’m not going to explain how to do the configuration, but rather what questions I ask or think of while doing the configuration and how that thought process works. I haven’t written that blog yet, so if you provide feedback on process challenge for me I will take that into consideration. I’m going to warn you that if you ask me to do standard activity management, complaint management or opportunity management I’m going to yawn.
Final Thoughts
I’m going to be at Teched/D-code Las Vegas next week. If you are attending please join me at lunch to talk more about SAP CRM.
