The Importance of Report Designers during CRM Implementations

 

On one project I worked on, not long before we were due to go-live, there was some concern that a specific, highly important report could not be produced because of the fundamental, underlying design of the CRM system. And it made me wonder how this could have happened - that such an important factor had not been fully considered until that point. It turned out that the reason was because when the database was being designed, the report designer - i.e. the person who creates the reports, not the software - had not been consulted when they could have provided invaluable input.

When I thought more about this, my first reaction was to think that this should hopefully be a rare occurrence. One would trust that in most instances, whoever was designing the database - whether a person, a team, a company etc - would know the key reports which were required and would thus design the database so that such reports could be created. Plus, in classic systems design, one often starts with asking what reports and information are wanted and thus we work backwards to work out what fields and data need to be recorded in order that such reports can be created.

However, with larger or more complex implementations, with projects with larger teams, and also with the new CRM systems which now offer so much more flexibility with their design, I've realised that such a requirement could easily slip through a hole. It is quite feasible, if the correct person is not consulted, that a database could be designed without true understanding or consideration of some reports. Or perhaps understandably, whoever is designing the database was told by a 'third party' as to what a report needed to show, and thus they hadn't got the full picture.

This issue can also be exacerbated when a charity is implementing a new database where no-one in the charity necessarily has the in-depth experience of report creation on that system. (By the way, in this instance the charity may have to hold their hands up to accept their share of guilt as this isn't necessarily something which should be aimed purely at the supplier...)

So my advice:

• when designing databases, do make sure reports are considered early in the design phase;
• engage the relevant report designers as soon as possible, and if you don't have one in-house then consider contracting one even for a short period to do some 'sense checks' early on; 
• introduce a specific 'report workstream' in the project so that reports, outputs, mailings et al are specifically considered at all times; 
• and don’t underestimate the time or importance of this factor.

After all, if we can't report on the data or get the data out of the database in a useful format, why are we using the database in the first place?