Why A Data Warehouse is not about Data

With today's technologies, it is not hard to get a data warehouse loaded with data from your operational systems. There are many tools available to get data and if your organization uses any of the popular operational systems like SalesForce, Marketo, EBS, Microsoft Dynamics, ServiceNow, and so on, then you have many plug and play adapters and extraction modules available to you.

The challenge that remains is user adoption! The main challenges that prevent user adoption are:

1. Data Quality – In a data warehouse, data is coming from many disparate sources from all facets of an organization. When a data warehouse tries to combine inconsistent data from disparate sources, it encounters errors. Inconsistent data, duplicates, logic conflicts, and missing data all result in data quality challenges. Poor data quality results in faulty reporting and analytics necessary for optimal decision making.
2. Understanding Analytics – The powerful analytics tools and reports available through integrated data will provide leaders with the ability to make precise decisions that impact the future success of their organizations. When building a data warehouse, analytics and reporting will have to be taken into design considerations. In order to do this, the business user will need to know exactly what analysis will be performed. Envisioning these reports will be difficult for someone that hasn’t yet utilized a BI strategy and is unaware of its capabilities and limitations.
3. Quality Assurance – The end user of a data warehouse is using Big Data reporting and analytics to make the best decisions possible. Consequently, the data must be 100 percent accurate or leaders could make ill-advised decisions that are detrimental to the future success of their business. This high reliance on data quality makes testing a high priority issue that will require a lot of resources to ensure the information provided is accurate. The organization will have to develop all of the steps required to complete a successful Software Testing Life Cycle (STLC), which will be a costly and time-intensive process.
4. Performance – Building a data warehouse is similar to building a car. A car must be carefully designed from the beginning to meet the purposes for which it is intended. Yet, there are options each buyer must consider to make the vehicle truly meet individual performance needs. A data warehouse must also be carefully designed to meet overall performance requirements. While the final product can be customized to fit the performance needs of the organization, the initial overall design must be carefully thought out to provide a stable foundation from which to start.
5. Designing the Data Warehouse – People generally don’t want to “waste” their time defining the requirements necessary for proper data warehouse design. Usually, there is a high-level perception of what they want out of a data warehouse. However, they don’t fully understand all the implications of these perceptions and, therefore, have a difficult time adequately defining them. This results in miscommunication between the business users and the technicians building the data warehouse. The typical end result is a data warehouse which does not deliver the results expected by the user. Since the data warehouse is inadequate for the end user, there is a need for fixes and improvements immediately after initial delivery. The unfortunate outcome is greatly increased development fees.
6. User Acceptance – People are not keen to changing their daily routine especially if the new process is not intuitive. There are many challenges to overcome to make a data warehouse that is quickly adopted by an organization. Having a comprehensive user training program can ease this hesitation but will require planning and additional resources.

Get these right and you will succeed!