Are Data Tools Magical?

Have you ever installed a magical data tool – a tool that will fix every data problem you have?  It always surprises me to talk to people who think that data tools are plug-and-play and they just need to install the right tool so all their data problems will magically go away.  Maybe they think installing an MDM tool will resolve all master data issues overnight or a data quality tool will resolve all quality issues.  There are some great tools out there, but you still have to configure them correctly and use them correctly.  Without that, you've installed "something" and it's going to do what it was programmed to do.  If you configured the tool to merge certain records, it will merge the records that meet that criteria, so you better make sure you gave the tool the right instructions.  Sometimes, a tool can feel magical because you had so many problems before that were eliminated when you installed it, but we all know that there isn't a magical leprechaun (or my personal favourite, the Icelandic huldufólk) sitting in a corner fixing our data for us.

Expectations

When you decide to use a tool, you have to go into it with the right expectations.  You need to understand what the tool can and can't do for you.  Expectations are often where people go wrong.  They might think a tool can do everything.  In reality, the tool often has some great capabilities, but then you need another tool to do something else.  If you don't fully understand the capabilities of the tool, you might be trying to configure it in some twisted way to do something it was never meant to do in the first place.  Also, the tool might point out potential data problems to you and you still need to resolve those issues.  It would be horrible if the tool was pointing out that some data was erroring out and you never bothered to check the error log.

I've seen expectation issues from both the business and IT sides.  The business might not understand exactly what they need, but heard about things like MDM tools or data quality tools.  They ask their IT department to get one.  If they haven't fully explained what the problem is, IT is going out looking for generic tools that they think might fix the problem, but might not necessarily solve the actual business problems.  The business needs to take the time to explain what the issue is and what they need resolved.  How many of us have received business requirements on the back of a napkin (and memorialized it in the project documentation binder)?

Configuration

You need to allow time to understand what the tool can do, collect business requirements, configure the tool correctly, test it thoroughly, and then implement it.  The tool is going to function based on how you configured it, so you need to make sure you configure it correctly.  Even with thorough testing, there might be some test scenarios you never dreamed up, so you may need to review your configuration on an interim basis after implementation.  And make sure you truly use test scenarios that test all the problems the business has.  Don't try to shortcut things by taking a subset of production data and crossing your fingers that every single problem is in that subset.  You need to do your due diligence so that the business has confidence in the tool being installed for them.

IT also needs to know where their strengths lie.  When you start getting into sophisticated and complex data issues, the skill set may not reside within the IT department and consultants need to be hired to properly configure the tools.  These days, many companies are choosing not to have specialized skills within IT, but use consultants on an interim basis when they need them.

Data Governance

The other key component of data tools is data governance.  You can buy a tool, but if you don't have the appropriate data governance in place, your tool investment could wither and die.  If you don't have any data governance in place, you should build it in parallel with your tool implementation.  The people you recruit for your data governance organization will be helping you define the requirements for the tool, test it, perhaps use it in production, benefit from it, and potentially deal with operational issues.  These are the people you need.  You need to be a storyteller in telling them how the tool will help them.  Once the tool is implemented, you should have time to expand the reach of your data governance organization beyond what you accomplished with the single tool.  You can expand on what you govern and recruit even more people.

When you need to configure the tool, whether this is being done in-house or with consultants, the team needs to work with the business people you identified in your data governance organization who understand the business rules.  Data tools aren't necessarily designed for business people to understand how to configure them, but they are the people who understand how the business works and what the business rules are that need to be configured in the tool.  The key is that the tool configuration, like data governance, be business owned and IT supported.  It's important to involve the business to get the right rules implemented.  Often, IT people might think they understand the rules and try to do the configuration themselves to save the time of the business people.  While that thought comes from people trying to be helpful, you're probably going to miss some business rules and implement some incorrect business rules, so make sure you take the time to work with the true decision makers.

You need to think about how the tool will be used in production.  Who will be hands-on with it and who will be using reports coming from the tool?  The people in your data governance organization need to be the ones who come together to figure out what actions you're going to take.  If a data quality tool identifies potential issues, the data governance organization should be involved in reviewing the issues, making decisions, and taking action.  Likewise, data governance team members need to respond to issues coming from an MDM tool.

The Reality

Tools can be powerful, but they're going to do exactly what you tell them to do.  That's how computer programming works.  Tools don't live at the end of rainbows beside pots of gold.  Remember to engage tools with eyes wide open, be realistic in what they can do for you, communicate to your stakeholders so they know what to expect, make use of data governance, and implement correctly.