Cyril on Business Intelligence

We all know that every enterprise needs automated CRM, and BI is a big part of that.  All the IT gurus on or off payola, marketing white papers, and newsletters tell us so.  As the saying goes: “It must be true, it’s in all the papers”.

Most of this advice avalanche accepts as axiomatic:

1. Successful CRM, like Minerva, springs full-panoplied from the brow of Jove , or

2. Implement any CRM software package and, bingo, we have instant lift-off, etc.

But, of course, CRM success isn’t automatic, there’s a lot of hard work.  As I have posted before, my mantra in these situations is drawn from the late Peter Drucker:

Efficiency is doing things right.

Effectiveness is doing the right things

This is most important when considering how to design or, more likely in today’s enterprise, make more effective, the CRM environment.   There are very many options, and they can often be implemented quickly, so they are efficient – but they don’t do the job as it needs to be done.  Effective CRM is complex, elusive and requires careful thought, not rushed procurement.

This post is rather lengthy, but I strongly believe that there is too much written on the net about this topic that is a series of common knowledge checklists, without the accompanying detail that suggests, or occasionally prescribes, how the essential components can/should/must be implemented.

Of course, I’m banging on again about the need to define the requirements before you build BI solutions.  Here, however, it is especially true, for defining CRM is essentially about defining its BI component. Why?  Let’s consider what is involved.

CRM‘s context and solutions involve much more than BI reporting.  We all know, truly this time, that for good CRM we potentially need some or all:

• Data Warehouse content detailing some or all transactions and static profiles with:
• Customer “touches” including SFA data; the statistics plus the sales representative contact reports
• Sales transactions and associated accounts receivable
• Customer intelligence;  the statistics, order patterns, etc. plus what the customers themselves and the industry is saying about our customers
• Service calls and results; not just numbers, but also the comments from service personnel on issues as they arise
• Customer complaints and resolutions; not just the numbers, but also the content and especially the trends
• Call-center and telemarketing activity and intelligence; what the operators are learning from contacts, and the relevant statistics
• Marketing promotion performance; how our marketing and promotional efforts are paying off,
• Competitor intelligence; what competitors are doing and saying and what the industry is saying about them

Note that these data, in full scope, are drawn from both hard and soft (tacit) sources. Regular readers will know my conviction, and emphasis, that tacit information is a vital part of an effective BI environment, and CRM is no exception – in fact it is a prime example of a field where collection and dissemination of tacit information plus collaboration on its significance, Knowledge Management if you will, is absolutely key.

 

I’ll deal with all the above categories of data collection in more detail in later posts.

 

It is obvious that only the largest corporation can afford to collect all the above material in its finest detail.  So the “some or all” filter is critical.  Even with all the data, the “can’t see the wood for the trees” syndrome often leads to failure.

 

CRM for each enterprise, large or small, needs access to some or all of these databases, BUT it is the executive interface to them for reporting, inquiry, alerting and analysis that determines success or otherwise – effectiveness or not.  Make no mistake, the executive interface determines what must be collected and stored in the data warehouse.

 

THEREFORE, the BI specification for on-demand reports, pre-formatted inquiry responses, alerting messages, collaboration between sales, marketing, service and product professionals, decision support environment, etc. must drive the specification for the data warehouse content and the CRM application software.

 

BI requirements definition is not everything in CRM planning, but when it comes to ensuring success, it is truly the only thing that’s important.  All the rest is relatively straightforward; just connect the dots and you’re done, courtesy of the plethora of software that’s just waiting to be turned on.

 

So how do we go about defining the CRM BI requirements?  We have the two basic options I’ve discussed in earlier posts, but I repeat some of it here – see the June 30 and some earlier contributions.

 

Top-down, or “waterfall” is the logical process for the green-field site with time and resource for planning activity.  Bottom-up is for everyone else.

 

Both approaches have the same objectives.  They require that we interview executives and carry out research into data availability to establish:

•  What information needs to be reported routinely, or available to be reported on-demand?

• How can potential problems or opportunities be detected and executives alerted to them?

• What reporting and models are required for Drilldown – especially diagnosis analysis and decision support (see post of Aug 27)?

• What data items are required in the data warehouse cubes to satisfy the above reporting needs?

• What degree of detail, i.e. the data dimensions, is required for the above?

• What additional dimensions are required for Drilldown?

The comprehensive nature of top-down analysis should produce the best result, but it will take time and may unacceptably delay that Holy Grail – the quick ROI.  Bottom-up will almost always give a sub-optimal result, but quicker.  I’ll compare them briefly after presenting the general principles.

 

The differences are in the effort involved and the starting point. CRM BI reporting specifications include the following:

 

• Pre-formatted reporting for routine and on-demand inquires: This is intended to give the client executives comfort that they are fully informed about the customer relationship status. 

• Pre-specified alerting: This is intended keep executives up-to-date with any unusual existing or forecast situations that could imply problems. 

Prespecified CRM BI therefore involves some or all of:

Summarization of KPIs and other metrics dealing with customer relations

Comparitive analysis of KPIs and metrics with CRM pre-specified benchmarks

Forecasts of key variables

Trend analysis of relevant KPIs and metrics

Alerting to unusual situations

Determination of the data items and dimensions required for the above

 

In all cases, it is vital to ensure that the tacit information – collected from sales people from calls and industry gossip, meeting minutes, rumors, opinions, etc. is assembled, assessed, communicated and escalated in a structured context.  It is the early warning system for the enterprise, and especially important when the topics are customer related.

 

• Drilldown reporting is the other CRM BI specification component:  modeling and forecasting desirably (IMHO) follows the principles discussed in my August 27 post.  It involves some or all of:

Scenario building to predict potential problem situations

Assessment of the inquiry, statistical analysis and data mining capabilities required for resolving situations in those scenarios

Assessment of the additional data and data dimensions required by these capabilities

Assessment of the additional access to tacit information and collaboration capability; particularly the identification of subject experts who can comment on emerging problem situations.

 

I return now to the methodologies involved. Top-down methods for requirements definition involve significant interaction with executives, to understand the business processes and how the executives use information to manage them adequately.   The data resource and dimension design for the data warehouse cubes follow naturally from the information requirements as they are determined.  Of course, the overall design is iterative, as some of the required data and its dimensions will not be readily available at the outset.

 

For those interested in the detail of this approach, the processes and documentation I use in CRM and other BI projects is described at www.bipathfinder.com.

 

Bottom-up methods focus on what is available in the data warehouse cubes for reporting and the existing reports.  Although the process is abbreviated, compared with top-down, it follows the same general steps, and has the same objective – that is to prepare a requirements definition to guide the CRM environment development. 

Basically, Bottom-up methods involve answering the questions:

• Where are we with CRM reporting now?

• What data is available, in what detail?

• Where does it come from, how good is it; who uses it?

• What better use can be made of the existing resources?

• How should we structure the project to obtain maximum ROI in the shortest time?

The first step in Bottom-up approaches to CRM BI must be documentation of the existing data warehouse meta data, including the links to source data resources – such as legacy transactions processing systems and their databases.

 

 

There are several products that do this.  However, recognizing this imperative, I have helped specify, and now use, a new product – it works at this time only for Microsoft environments – called BI Documenter to document the SQL meta data and the links to cubes, reports and sources.  If you want more detail it is given at www.bidocumenter.com.  There is a free version that documents SQL database content, and an Enterprise version that includes all the BI metadata content for Analysis Services and Integration Services.

I’ll amplify these concepts, especially the data requirements and pre-specificied reporting content in a later post.