In this first in a series of three articles, I’ll present a small excerpt from the chapter dedicated to integrating SAP CRM with other SAP systems (e.g., SAP ERP and SAP NetWeaver Business Intelligence [SAP NetWeaver BI]). The material presented here briefly addresses the native integration within the SAP suite of products, while the book’s content delves into several other aspects, including integrating non-SAP CRM software packages with your SAP ERP. The native integration available when implementing a homogenous SAP solution is one of the most critical, but least advertised, aspects of a CRM project.

SAP Middleware

SAP Middleware is the underlying technology that enables systems such as SAP CRM and SAP NetWeaver Business Intelligence (SAP NetWeaver BI) to natively integrate with one another. For example, let’s assume you create your customers (Sold-To parties) in SAP ERP. Those customers flow in near real time to SAP CRM through this middleware.

SAP Middleware is probably the single most important technology aspect of any SAP CRM project that’s never mentioned (at least to start with). However, it would be a mistake not to take it into account when considering interfacing non-SAP CRM systems with SAP ERP.

The middleware analyst or consultant has to combine both technical and functional knowledge. While the administration and maintenance of SAP Middleware does not require writing ABAP code, it is necessary to understand the typical data structures available in SAP CRM, such as tables and fields. This function requires some basic functional skills, so it’s best to think of this role as a “techno-functional” one.

The best way to understand this topic is to use an example: Let’s say that in your environment you do not employ the more advanced functions available in Solution Manager that allow you to automatically match the configuration between SAP ERP and SAP CRM. So, when the ERP Sales and Distribution team changes the configuration for the Customer Group field (add a new group), you should match that configuration in your CRM system. If the ERP team does not update the CRM team (and you do not have Solution Manager monitoring tools in place), the first time you change a customer in SAP ERP that references that new customer group type, you’ll have an error in the middleware.

Similarly, if your configuration is not in perfect sync between SAP ERP and SAP CRM, you may see a situation like the one shown in Figure 1.

Figure 1

Standard middleware error reporting (transaction SMW01)

What you can see in Figure 1 is that one of the users has created a Contact Person in SAP ERP, but the name was missing (the last name, actually). SAP CRM’s configuration deems the name of the Contact Person as mandatory.

The advantage of using SAP’s standard middleware is probably clearer now — all this functionality, including the error reporting, has to be custom built when using non-SAP systems. This custom design and implementation effort adds significant cost to your project.

Probably the best characteristic of an integrated SAP solution, as opposed to a hybrid (SAP + non-SAP) one, is that SAP is one-stop shopping for your company. You won’t have to deal with the additional interfacing work, you won’t have to employ different technical teams to support the different systems, you won’t have to deal with multiple software vendors (pointing to each other in case of issues), and thus you attain a lower total cost of ownership (TCO).

Running Parallel SAP ERP and CRM Projects

Most SAP CRM projects are run by companies that have previously implemented SAP ERP (or R/3 4.6C or higher). In this case, the configuration in SAP ERP is relatively stable and you should have very few issues adjusting the SAP CRM configuration to match the existing SAP ERP one.

However, if you are running your SAP ERP and SAP CRM projects in parallel, you have to expect to see some issues between the two teams. It is imperative to make sure the two teams have one common project manager (or some form of common oversight). The SAP ERP team will probably experiment with various configuration choices, and each time it changes a configuration option, that change might adversely affect the SAP CRM system. The ideal organization in this case is to have the teams structured by process and not by the SAP system.

While this is the most logical approach, most of the time the teams are structured based on the system, so you have an ERP team and a separate CRM team. At a minimum, you’ll have to insist on the common oversight, making sure the lines of communication between the two teams are open at all times.

If you have to run the SAP ERP and SAP CRM implementations in parallel, it’s advisable to have all the SAP CRM parts of the project run behind the SAP ERP side for a month or two (thus allowing for a more stable configuration on the SAP ERP side before you start configuring your SAP CRM system). Because most of the business processes in SAP CRM are somewhat less complex than their ERP counterparts, your CRM team should be able to compress its project schedule and end up with a common go-live date between the two projects.

CRM and ERP — Always a 1:1 Relationship?

The vast majority of SAP users have a 1:1 relationship between their SAP ERP and SAP CRM systems. It’s a logical approach, and it definitely simplifies your landscape. The following are two scenarios possible (other than the standard 1 SAP CRM to 1 SAP ERP):

• N : 1 Scenario (or the so-called Multiple CRM [MCRM] scenario — Multiple CRM systems connected to one ERP)
  
  
• 1: N Scenario (one CRM system connected to multiple ERP systems)

The good news is that it’s possible to implement either the “N : 1” and the “1 : N” scenario. The bad news is that experienced CRM consultants in these types of non-standard-type options are few and far between. If your consulting partner doesn’t have direct experience with the scenario you’re looking to implement, you are better off seeking SAP’s assistance in the matter, or at least hiring a contractor with proven experience in the domain.

If your company’s IT back end is structured around multiple ERPs, there are probably very good reasons for that structure (i.e., maintenance and availability needs, timing differences in implementations, the holding company approach, etc.). At the end of the day, it won’t matter much why you have that structure, but the main question is if you really need one CRM system. If there are really good business requirements that demand one worldwide CRM system, it is doable to connect one CRM system to multiple ERP back ends.

However, if the business requirements demanding one global CRM are not very strong, you are better off maintaining the 1:1 relationship between the various ERP systems and their CRM system counterparts. The simplicity gain in your landscape, both from a technical and a business process standpoint, pays off handsomely. If you do need one CRM system, please make sure your implementation partner has documented experience in this area. If they do not, you are better off seeking outside help for this particular area, either directly from SAP’s consulting arm or from another one of SAP’s top-tier implementation partners.

Even if you do end up with multiple CRM systems, it is advisable to use a global template, roll it out, and then adjust it to the local conditions. This approach is definitely more efficient than starting from scratch for each country or region.

A somewhat less-typical situation is having one global ERP and multiple CRM systems. One possible reason for such an environment could be having one global ERP for a multi-business unit company, but because the CRM needs are so different from the business units’, it might be better to have one CRM system per business unit. Another reason would be segregating the CRM on a country-by-country basis.

At the end of this small excerpt from the integration-dedicated chapter, I can only hope the content reviewed has given you a taste for the type of information presented throughout the book. The other chapters in the book address many other important topics for your SAP CRM projects (or upgrade, international rollout, or embedding the requirements from an acquired company). In the second article I’ll discuss architecture design.

George Fratian

George Fratian is a CRM project manager with more than 11 years of experience in the SAP arena (CRM and R/3). The past five years were dedicated to various projects implementing mySAP CRM systems in different industries such as Oil & Gas, Health Care, and High Tech. He has designed and implemented complex mySAP CRM-based solutions for Fortune 20 companies in the areas of Internet Sales and Online Sales, Sales Force Automation, Case Management, and Interaction Center WebClient.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.