Chapter 10. Microsoft CRM Reports

In this chapter

Report Navigation

Report Creation and Modification

Use Case Corner—C360 SearchPac for Microsoft CRM

Summary

Reporting is traditionally an area that has been extremely problematic for CRM applications and customers of CRM applications. Perhaps the biggest reason for this is that CRM is so prone to customization that it is normally difficult to arrive at a set of one–size-fits-all reports. Another reason is that many CRM vendors have enough to do maintaining their applications that creating a reporting solution takes a backseat.

Microsoft has approached the CRM reporting issue by incorporating Crystal Reports into Microsoft CRM. The core Microsoft CRM Professional Product lists 138 canned reports and charts, 120 of which are unique. These reports and charts are all displayed through a Web browser and are accessible through the Microsoft CRM Web client.

Before we look at the Microsoft CRM reports, let's discuss some prerequisites to good reporting. Ultimately, meaningful reporting comes down to three things:

• Capturing the right data

• Getting the data into structures conducive for reporting (in other words, using defined fields and not stuffing everything into Notes fields)

• Selecting and developing expertise with a reporting tool that is capable of manipulating the data in a manner you can use

The third point has been decided for us, so let's focus on the first two. If you are serious about really using the CRM data you will collect in Microsoft CRM, then pay extra attention to how you set up the system. Talk through every field and every value on every field and determine what it will be used for and why. Organize this information and use it to educate your users so they are entering data consistently. Use business rules (workflow) and field constraints (required fields) to ensure that the data is entered properly and consistently.

A good CRM implementation project should consist of the following stages:

• Requirements Gathering— Arriving at a detailed list of everything you want the system to be able to do for your business. This detailed functional requirements list will include the specific reports that will be needed to use the system.

• System Design— Taking the requirements and designing how the system will be configured to meet these requirements. The output of this stage should be a detailed design specification outlining configurations and customizations, workflows, mappings, and so on.

• Construction— Building the system using the document developed in the previous phase.

• Testing— Unit testing each component (customization, mapping, workflow, and so on) and developing test cases for system and user testing. Test cases should map back to the functional requirements to validate that the system can do what is required.

• Deployment— Bringing the system into production by performing migration, final data conversion, and user training among other implementation-specific tasks.

It is important that during the requirements gathering stage you obtain a list of all reports to be delivered and a fairly detailed idea of the data each report should contain. Without this, there will be no way to design how those reports will be built and, more importantly, there will be no way to ensure that the data needed to produce the reports is being captured.

Data capture is an important issue that must be approached pragmatically. For example, if you decide that you want to report on specific details of each client sales meeting, including internal and external attendees, you'll be creating a lot of data-entry work for your sales personnel. You run the risk that the data will rarely get entered, and the report you've built will not have enough data to be meaningful. If you attempt to correct this by designing the system so that the sales users are required to enter the data, you might find yourself in a situation where your users do not adopt the system because it is requiring them to do too much data entry. Things will have gone from bad to worse.

The point here is that with every reporting requirement you should ask yourself two questions:

• Do we have the data in place, or can we arrive at a realistic plan to capture the data?

• If we are able to collect this data how will we use it and how will our use of it add value to our business?

Take an example that we all see on a regular basis. You are filling out a paper form of some sort: an application, a warranty card, a Web form, whatever. Nine times out of ten you are asked for your fax number. Probably only one time out of ten does the organization requesting that information actually need it. They've thought through the first point (can they get the data—yes, they require you to fill it in) but they've not really thought about why they are requesting it. The most probable reason they are asking for it is because the person developing the form was looking for fields to take up space.

Model your system interactively with your project team and think through all the fields. If you have a good reason to keep track of Freight Terms for Contacts, leave the field on the form and educate your users about why that is important information to track, and how it will be used. If you don't need it, take the field off and simplify the system. With CRM, less is really more.

One theme that seems to run through most CRM implementations is the “eyes bigger than the stomach” syndrome. During the sales process and project design, everyone wants to track everything. A year after the system has been put in place, most companies can't even pull a complete customer list. It's true; in their fury to track everything they've ended up not even effectively tracking the most basic data points. Pick the right level of detail and track it with realistic plans.