Reason 3: Data
The third major cause of PSA implementations failing is poor data.
Why data? That should be the simple bit.
Well there are two aspects of data to consider in your PSA plan:
- Data quality
- Data model
But first let us consider two starting positions for this aspect of the process, both of which have good and bad aspects.
Firstly, if you’ve come from world of spreadsheets and fragmented point solutions, this may well be your first PSA venture. Here the main concern will be data quality.
As an example, let’s start with counterparty data, do you have a clean customer list? And if you do, what do you mean by a customer list? Let me give you some options to help you decide. You could have a customer list that:
- only contains customers with active current contracts; or
- includes those plus customers you regularly do business with but not on a continuous basis; or
- includes those that may have recently come off contract but you hope to sell more to again; or
- includes those that are close to signing; or
- includes those that you hope will sign; or even
- includes all those that you have ever done business with (this is probably the one you use in your accounts but not the right one to load)
And that’s before we get into the aspects of parent company, separation between business and financial counterparties etc, definition and de-duplication of sites and contacts. Now if you have this separated across many systems (which themselves may have differing counterparty data structures), you will need to both de-duplicate, clean and agree state on each customer record in each operational system. Also, sitting in your CRM system you will have companies that have not bought anything yet. Even leads can exist as companies - are they worth populating?
If you are coming from an existing system, you must also consider the data model differences between the two systems and make sure that’s been taken into account in the data cleaning. If you have a system that only allows one site per customer but you have customers with multiple sites, it is likely that you will have created duplicate customer records (this is quite common). Moving to a system that supports multiple sites, you must de-duplicate to have the right model. The same issue frequently occurs with contact records, whether they are attributes or independent objects makes a difference to data population.
So, the simplest data issue turns out to be quite complex, needing consideration and external data cleaning plus population of any custom fields you may need to analyse performance. Not focusing on these data population/data model differences early on, asking the right questions, getting the differences clear and building the right lists to populate will lead to you building an instance on bad data. This can be a cause of frustration in the implementation project, enough for it to fail.
So, don’t rush this stage, it is a great opportunity to re-baseline your data and build on a clean foundation.