In this excerpt from Chapter 9 of Planning Your SAP CRM Implementation, I discuss a case study for one of my recent sales force automation (SFA) projects. The content here is specific to that case study, but in the book you can see how this master data management topic is incorporated in the big picture of how to implement CRM projects.

One of the toughest issues my team and I deal with in this project is data management. If your company already has an ERP system with clean data, then your CRM project is in good shape to start with, because most of the CRM data is downloaded from ERP (e.g., accounts, products, and prices).

External Data Sources Might Be an Option

However, in our particular case, we can’t rely on an ERP with clean account data, and to mitigate the risk associated with maintaining and constantly cleaning this customer master data, we decided to “outsource” this work. “Outsource” is probably a bit misleading term, because what we actually did was select an industry standard database for customers, and standardized on it.

There are de facto standards for most industries, and the typical example is Dun and Bradstreet (D&B, www.dnb.com).D&B is a well-respected company that operates in the financial realm. If you want to find out the credit rating of a company, its database is probably the first option you should consider. Similarly, for the healthcare industry, there are at least two major database vendors, Verispan SMG (www.smg.com) and MII (www.marketinginitiatives.com).

So, if your company does not have a clean customer database to start with, a relatively cheap and simple solution is to buy it from a well-respected provider. This will simplify your environment, reduce the number of people that have to maintain this data (because the vendor provides regular updates), and reduce the risk of getting bad or duplicate data in the system. This is of particular interest to merging companies, especially if neither has very clean data to start with. You will, however, have to deal with the exceptions, as in the typical case when a given customer is not available in the database provided by the vendor.

Most companies prefer to maintain their own customer master data for two main reasons: control, and the “we are different” syndrome. The first reason is a reasonable one, but the second one is not. Most companies think they’re different than any other enterprise, and their own requirements are not found anywhere else in the industry’s realm (or at least they’re different enough). Most of the time this is false; in reality companies in the same industry are much more similar than different, and perhaps it makes sense to standardize on a third-party solution.

But why is clean master data such an important aspect of your CRM project? Let’s start with an obvious example: let’s say you’re looking to find a company or person in the Yellow Pages or the White Pages book. Can you imagine how frustrating it would be to deal with garbled data, such as misspelled names, incorrect addresses, or old phone numbers? The same thing translates very well in the business world — and having clean data is a prerequisite for any successful CRM project.

If you’re contemplating starting your own CRM project and you cannot rely on clean data from your ERP system, the best course of action is to name a master data czar to take care of the clean-up activities. Make sure this person is empowered to make decisions and has the proper support from management, because it’s probable that he’ll have to make unpopular decisions and ruffle a few feathers in the process. In case your environment has multiple SAP and non-SAP production systems sharing the same data, it is advisable to use the SAP NetWeaver Master Data Management (SAP NetWeaver MDM) or a similar product as the master data source, and feed that data into all the other systems.

While the customer master data is probably the most visible data for the entire enterprise, there are other master data elements that have to be treated just as carefully:

• Contacts
• Territory management data (linking the customer master with the territory and the employee assigned to that territory)
• Product and product hierarchy data
• Competitors, partners, and their respective products (optional, but important for some companies)

Depending on your business requirements, your data needs will differ from this list. One thing’s for sure, without regard to a specific data element: data has to be clean.

Territory Management Considerations

SAP calls the hierarchical relationships between people, territories, and accounts “territory management.” Many businesses refer to this as more of a “territory structure” or “territory repository,” because the management portion of that term is done outside of the CRM system. For example, if you want to make sure the territories covered by your reps are fairly balanced, you can do this manually, or use one of the systems specializing in this particular area. It’s interesting to note that the SAP system does not currently have any partners in this area listed on their partner program, but hopefully this will be addressed soon.

Figure 1 shows what the territory management, or territory structure, looks like when viewed in the SAPGUI. Note the typical perks when working with SAP software — such as the clean structure, the validity periods, and the use of standard objects.

Figure 1

Territory structure (maintained in the SAPGUI)

From a logical standpoint, Figure 2 shows what the relationship looks like.

Figure 2

Logical representation of relationships for a territory

As shown in Figure 2, the territory is the link between the accounts and employees (linked through the position object). The territory hierarchy itself is represented as in Figure 3.

Figure 3

Logical representation for territory hierarchy/structure

As always, Gartner is a very good source to consult for possible Territory Management vendors (e.g., ZS Associates, Tactician).

Legacy Data Sources and Quality Control

If your project relies on data coming from other sources, above and beyond the SAP ERP or SAP NetWeaver MDM systems, you should probably strengthen your data management team. The role of this team is to make sure data is cleaned, standardized, matched, and merged, before loading it into SAP CRM. For example, let’s discuss one of the data elements used in our SFA project — the contact person.

These contacts were available prior to rolling out the SFA system in a variety of systems: personal Outlook databases, Excel spreadsheets, Act and Goldmine databases, and even paper organizers. Of course, you can’t directly load data from such a multitude of sources into SAP CRM. What we did was extract all these contacts to a standard template. After merging the various data extracts into a master extract, the fun part started: we had to clean, match, and deduplicate the data. Some of this work can be done manually, but for sizable data volumes you should consider automatic tools (and there are a variety of tools that specialize in one or more of the data management area).

Nonstandard Functionality

Sometimes a business requirement does not match the available functionality in SAP CRM. The following are the recommended steps that you must go through before you implement such a requirement:

• Verify the business requirement is a firm one (if it isn’t, you can safely remove it from the list, or at least postpone its implementation — and in the meantime the business will determine if it’s really needed)
• Look for alternative options that accomplish the same basic requirement, but in a different fashion
• Investigate the option to create an enhancement
• The last option is to modify the standard behavior of the system by changing the SAP code (this should be a last resort option, because it will make your life harder — every Service Package or minor upgrade must be tested and the changed code must be retrofitted).

The sales force had an interesting requirement that was not fulfilled by standard SAP CRM functionality. The customer base was organized in a hierarchical fashion, and while the standard SAP CRM system (including SAP CRM 2007 and earlier releases) allows out-of-the-box hierarchical relationships, it does not present them in a compelling fashion on the screen — at least from an end user’s perspective.

After going through the steps presented previously, we determined that we have to enhance the standard system (note we’ve said enhance and not modify). Instead of developing our own software to graphically represent these hierarchies, we looked at the software available on the Internet. We found quite a few packages that cost next to nothing, and we bought the rights to use one that looked appealing to the client (from a UI perspective). The only hard IT requirements were that the software should be bug free, and the Java code should be easy to integrate with our CRM system (again, as an enhancement!). Figure 4 shows what a rep sees when he needs to understand the relationships between the various entities that belong to one given account.

Figure 4

Graphical representation of customer relationships (custom enhancement)

Again, as a final recommendation on this topic — you have to minimize the number of such enhancements because they’re time consuming for the project team, and it is always cheaper and safer to rely on the standard SAP code.

Speeding Up the Access — a Citrix Mini-Case Study

For the times when Internet access is slow (e.g., dial-up or non-EDVO wireless cards), we deployed a Citrix solution that significantly speeds up the perceived response time. A logical diagram on what our solution looks like is shown in Figure 5. The main downside to this approach (other than the extra cost associated with building a so-called Citrix farm, which is not insignificant) is the fact that the user will not see any benefit when downloading content to the local hard drive (i.e., downloading an attachment from the Account Profile). In a simplified fashion, Figure 5 shows how the landscape looks.

Figure 5

CRM access for low- and high-speed Internet connections

Users with low-speed connections, such as dial-up or wireless cards where EVDO coverage is not available, can have a Citrix application installed on their local machine. As shown in Figure 5, in this case there’s no need to establish a virtual private network (VPN) connection, because the Citrix infrastructure is outside the corporate firewall. Citrix only renders screen changes, usually with a reduced color palette, so the actual data transferred is significantly reduced (only screen changes are transferred — no actual data passes over the Internet link).

Firing up the Citrix client application (preinstalled on the end-user PCs), establishes a secure connection with SAP NetWeaver Portal, and implicitly with the CRM and other servers. After this connection is established, the reps can browse the Internet or call the URL for their CRM system. The SFA system responds much faster in this case than in a situation in which Citrix is not available.

Users with high-speed Internet (DSL/cable or EVDO wireless card) access the sys-tem through the typical scenario by establishing a VPN connection first. Accessing SFA through Citrix while being on a high-speed Internet connection does not provide any significant differences in the user experience (from a system response time perspective).

With a Citrix solution as the one just described, the user uses his own PC only as a “window” into the server. All of the data processing happens on the Citrix server (the screen the user sees is actually running on the Citrix server). One of the interesting outcomes that’s hard to explain to end users is that the so-called C drive visible in the Citrix session is actually the remote server’s local drive. You can find up-to-date information on this topic by visiting www.citrix.cletom.

What constitutes slow speed? If you pose that question to a sales rep, he might say that anything that’s not instantaneous is unacceptable. While in reality most people tolerate the inherent delays due to the Web environment, you still have to fine-tune your system for all conditions — from the optimal corporate LAN/WAN access, to field access from a low-speed (non- EVDO) zone.

The following are some typical Internet access speeds that can be attained in the US:

• Cable — anywhere between 700 Kbps to 6 Mbps or higher
• DSL — anywhere between 300 Kbps to 1.5 Mbps or higher
• Hotspots based on 802.11g networks (e.g., Starbucks, T-Mobile, AT&T) — limited by the bandwidth available (T1 or business Cable/DSL, and the number of users sharing the same connection), but generally more than fast enough for CRM access
• EVDO wireless cards — anywhere between 400 Kbps to 2.4 Mbps (in EVDO mode); or as low as 50-60 Kbps (in 1X mode)

It is important to note that Internet access from hotels (very important for reps) is usually decent, but it’s limited by the amount of available bandwidth at any given time.

If you do have remote users that also require SAPGUI access, a side benefit of employing a Citrix-based solution is that it also simplifies the administration of SAPGUI (assuming that’s your choice of a UI). This is because SAPGUI is not installed on client PCs anymore — it only runs on the server (the same concept as in other terminal server applications, including Citrix’s own).

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.