Any business that strives to use data in their decision making process needs to create a “single source of truth” for the business. Pooling the data from multiple sources and creating the APIs needed for it so synchronise with other platforms.
This solution will outline how I plan to take ownership of this project and crucially, my plans to make full use of it after it’s launched.
Why centralise?
Simply put, a centralised database is one where the information is collected, stored, and maintained in one location, but is accessible from many points. As a rule, this means using one central database system or mainframe.
With everything in one place via centralised data, the overall IT infrastructure system is streamlined, and reduces costs in maintaining legacy systems, time for staff to find and use the correct information.
Related: See why and how BNYM’s team approached data centralisation
Benefits
- A single source of truth for the organisation
- Client data used across-platforms
- Instant information for client-facing teams
- Faster report creations
- More accurate sales pipelines
- The begging of automation for client reporting
Considerations
- Vendor compatibility
- Server architecture and SQL version
- API types
- Data overwrite rules (which data is more correct?)
- Caching times (how often will the data write back?)
- Encryption and access levels
Deliverables
Centralised data should be pooled in a CRM like Salesforce, MS dynamics or Adobe Data studio. Having the data sit in Salesforce makes it easier to develop bridges (APIs) to other software, like your email platform, or a private client area.
The below is an example of what to prioritise when centralising the data in Salesforce Engage.
Define lead scoring and qualifications
Having the data collected in Engage will be pointless unless Engage knows which leads and actions are valuable.
It’s crucial to set up and add the relevant scores to the user journey. E.g. A visitor downloading a press release, wouldn’t score as highly as someone who requested to be contact.
Customising fund and prospect reports
Setting up the scoring categories for products will need to be mapped. This will require working with senior stakeholders and aligning the business’ objectives with score weights of products being viewed by clients.
E.g. Which products or services should be marked a “priority” in 2020, and do the reports include enough information?
Create custom fields for “Salesforce objects” for APIs
Salesforce Engage is part of Pardot and has over 20 separate APIS which can be integrated into other tools.
However, objects will need to be created to send data including opportunities, prospects, visitors, and more.
Scoping and analysis
Understand what stage the process of the migration is at. More importantly ensure, Alcentra has what it needs to move to a production environment.
This means looking at the gaps and proposal in more detail and, if there are no urgent gaps or problems, move to the next phase.
- A vendor and consultancy has been chosen
- Work has begin preparing Engage to receive the data
- Work has begun to prepare the data sources to connect to Engage
- Alcentra has identified what custom objects to create and report against.
Target
50
20
100
Move into production environment
With testing complete and the API’s correctly pulling data – it’s time to move into the production environment.
Teams should be trained on how to find the data and how to run reports. I would look to create policy, and have guidelines on how the data is managed and edited.
At this point I would also look to introduce a third API, like Stoneshot into the development environment
- Phase one should be complete.
- Data should be syncing to core systems and a production environment should be pulling live data.
- Test using the data in 3rd party solutions like Mailchimp, Campaign monitor etc.
- Create a policy and technical guide for regional teams