We hear all the time that having data silos is a bad thing. But are they?
The concept of having data silos means that you have data at your organization that live in a number of different places. An example of that would be: using Salesforce to track fundraising data, using another program to host all your program data, another for applications, email communications, finance… the list goes on. Sometimes the same data is duplicated in more than one place: an employee who’s a donor and also a former program participant.
There’s a lot of buzz out there that eliminating silos will bring efficiencies to your organization. Why not have all your data in one place? Without a lot of context, eliminating data silos is a great idea—you can log into one place and see the full picture of your constituents and how they engage with your organization. Sounds great!
But what about when eliminating a silo requires so many resources that your return on investment never comes around? We deal with this a lot at Pedal Lucid and as consultants at large. Software and databases are different for a reason. They’re built to handle specific processes really well. While Salesforce can be customized to accommodate lots of different processes, the lift to recreate another database in Salesforce takes a lot of resources to get up and running, nevermind maintaining a custom solution.
Therefore, we have to ask, are silos really silos if they’re connected to each other via a simple process—even if that process is manual? What if connecting two of your databases only takes 15 minutes each week to upload some data from one to another? That simple effort ties the two together and might be able to provide 95% of the benefit with a fraction of the effort. That same action as a true automated integration might take 50 hours to build and when there’s a change in either system, the integration needs to be updated or it may stop working or create bad data.
In order to get value out of an integration, it’s critical to have a strategy for how you plan to use that centralized data to create useful, actionable information. Otherwise, you’ve simply gone from two databases to one where the cost is greater than the sum of its parts.
We think there are two good reasons for removing siloed data: one is operational (staff time on duplicate data entry) and one is strategic (knowing X about someone can help you guide them to Y). Ask questions like: “What do I hope to accomplish by combining these systems? What’s the minimum needed to meet that goal? What happens if our requirements change?” The answer to these will help you determine the minimum level of integration you need to build (and maintain).
We see data integration in four different levels:
- Totally disparate data.
- Looking at data holistically, but outside of both systems (an external reporting tool with the ability to link data from multiple systems ie. Tableau or PowerBI)
- Limited transfer of data, spreadsheets or 'light' integration
- Full-blown integration and/or combining separate systems into one
We know from experience that integrations and custom Salesforce solutions can greatly benefit an organization. We also know the resources to build and maintain those solutions are not to be taken lightly. System integration is the mechanism for implementing a strategy, not the strategy in and of itself. Next time you’re considering an integration, make sure you have a clear picture of why the integration is important to your organization and why bringing the data together will help you achieve something you currently cannot.
