- Enterprise data initiatives are filled with plenty of risks. Before looking at how to mitigate and manage those risks, we should first understand why it is that these efforts are so prone to risks. For one thing, you're shaking up the status quo and many people by nature are resistant to change in their day to day business life even when that change comes with a promise of a better way of doing things. Next, the very nature of enterprise data management requires crossing organizational boundaries. If your company has traditionally be very silo driven with very few systems being truly enterprise wide in nature, you're venturing into new territory.
And just because the benefits of managing data at an enterprise level might be obvious to you and the program executives, sponsors and stake holders, not everyone may share that perspective. Almost certainly your enterprise data program brings with it and entirely new generation of technology. Take big data for example. For all the promise big data and driving a new generation of analytics and data driven insights and actions, you'll likely encounter those who strongly believe that the traditional data warehouses and data marts build on relational databases are perfectly adequate and shouldn't either be supplanted by or required to coexist with your new big data environments.
Since enterprise data will be aligned with key business initiatives such as supply chain optimization and strategic sourcing or a new ERP implementation, your organization will inevitably be undergoing significant changes and processes on both the business and I.T. side. Even behind resistance to change or the incorporation of new technology it's always possible the new processes might need some shaking out to get them as correct and efficient as possible especially as your employees are required to change some or even much of what they do on a daily basis.
The good news, though, is that even though these risks are very real and also very significant they're also very manageable. The first thing you need to do is catalog the specific risks of your organization. You need to be as honest and as detailed as possible, now is not the time. Now is no the time to shy away from points that might be controversial or even politically unacceptable within your company. For example, this table shows four risks for your enterprise data program. Each of these risks is assigned a severity level from a value of 1 on the low end to 5 on the high end.
For each one of these risks, and your list will of course have far more than four entries as we had on our sample table, you need to develop a specific plan to mitigate that particular risk. For example, consider an identified risk of replacing custom code for extraction, transformation and loading, or ETL, with a new enterprise wide ETL tool. Here we see four different mitigation steps that have been identified along with the identified owner who will ultimately be responsible for each of those mitigation steps.
Once you've created your list of risks and for each the list of mitigation steps, you need to actively manage this list. You can't just set it aside and figure that your work is now done. Conduct frequent reviews, both informally as well as doing program status meetings. For those risks that prove to be particularly problematic, escalate the matter is necessary to your program sponsors with a request for intervention or resolution. Also, make sure that you have contingency plans in place for each item. If a new ETL tool was being implemented, for example, and if it turns out that the tool doesn't perform as advertised, what happens then? Perhaps it's reverting to your custom code while a new tool is selected or maybe other actions are called for such as adjusting the order of projects on your schedule.
Whatever they happen to be, recognize that risks are on your list for a reason. That's exactly what they are, particularly difficult challenges to your program and despite your best efforts of mitigation, problems can still arise. Don't be caught by surprise. A final point to recognize is that even after you've gotten under way people may still question specific aspects of your program. Someone may wonder, for example, why you're implementing SQL on top of a do for traditional business intelligence functions rather than leaving those capabilities on the current enterprise data warehouse platform.
Questions such as this one shouldn't be thought of as a risk to the program. While it's true that they do represent a challenge of sorts to the program as a whole, it's actually your responsibility to have adequate answers available. If questions such as this one didn't come up while you were going through the approval stage they probably should have. So don't think that just because you're now underway with your program the time to address questions about what you're doing and why has passed. Again, don't think of people asking questions as being the same as risks to your initiative.
Join Alan Simon as he shows how to build a top-notch enterprise data team, evaluate your data architecture, solicit feedback from business users and IT staff, and create a plan to manage your data going forward. He helps you build a portfolio of projects that align with business needs, and migrate your current data into a more modern big data environment.
- Compare and contrast big data technology and data warehousing.
- Explain the pros and cons of implementing enterprise big data technology.
- Understand the benefits of using a data-architecture team.
- Differentiate between master facts and master data.
- Identify the strategies used to sell a portfolio of data management initiatives.
- Recognize the roles and skills of each member of a data team.
- Recall the information required in a maturity model.