What I Learned About KPIs, Data, and a Cloud Data Warehouse
How Important is a KPI Dashboard to Your Digital Transformation?
A key deliverable that many IT departments have when migrating to the cloud is building a KPI dashboard for senior leadership.
When a cloud migration is sold to the business as an opportunity to create a KPI dashboard, the requested KPI dashboard requires a modernized data warehouse or some other dynamic; many cloud migrations come with a requirement from senior leadership to create a KPI dashboard.
My own experience was a little of both. Senior leadership had been requesting a KPI dashboard for some time while IT was independently exploring a consolidated data warehouse in the cloud. The objective became migrating data into the warehouse with initial success defined as having a KPI dashboard for leaders to use to determine if the company was winning or losing. This seems to be a fairly common scenario with other IT managers that I have talked to.
KPIs — Where I Went Wrong
As my team worked with others to begin migrating to the cloud, we fast-tracked the KPI requirements to meet senior leadership’s mandate. The excitement was high, and expectations were higher.
In a matter of weeks, we pulled off a minor miracle. We delivered the company’s first true KPI dashboard to senior leadership. We were able to satisfy almost all requirements ahead of schedule and under budget. Unfortunately, it landed with a resounding failure. Here is where we went wrong:
- We designed the dashboard only to reflect the KPIs. When leadership started asking questions, the data had been ingested at such a high level. The details had been lost. We could report on KPIs, but the context was missing.
- We set the business up for failure. Because the underlying data had not been positioned for teams to drill down into the details, the business could not answer senior leadership’s questions. The trust we had with the business deteriorated significantly because they felt like we had used their data against them to curry senior leadership’s favor.
- The KPIs were extremely inflexible. Our focus on generating the KPIs in question and only the KPIs in question backfired because adjusting on the fly was nearly impossible. The data had been contextualized to only service the specific questions we had been asked to answer. Adding additional functions or slight contextual changes required a rebuild of the entire dashboard.
These three issues were bad enough, but the problems continued to build. As leadership walked through the KPIs provided, they started wanting to revise KPIs and build on to the dashboard. Each iteration was a complete rebuild that required roughly 30 days of rework. Senior leadership grew more exasperated, and our cloud migration project began spiraling into a KPI project that sucked in more resources from IT and operations each week.
Fortunately, our leadership saw that we were struggling, they paused the project, and they asked us to put together a proposal.
KPIs — Win the Battle, Win the War
Our proposal to senior leadership was that the successful delivery of any dashboard would require the following:
- Departments, business units, and the field would be able to use the same data to:
a) create their KPI dashboards
b) answer questions and provide clarity up the chain of command - Delivery of a dashboard meant that the data presented had reached a maturity level that allowed leadership to use the dashboard to make critical decisions based on the information provided.
- Data provided to leadership was accessible across the organization so that leadership could hold individuals and teams accountable.
- Adjusting KPIs and adding new KPIs should be a relatively easy undertaking, provided that the underlying data was already available in a source system.
Leadership agreed so we went to work. Instead of focusing on the KPIs, we prioritized the data that was needed to generate the KPIs. We knew that we would need to provide the data to answer questions, at the same time, we would also need to empower the broader organization to do the same.
Building a Process for Data
Our priority was to create a process that data would go through to enter the data warehouse. Data would be labeled based on the level of rigor that each data element went through:
- Gold — the highest level of rigor. Gold meant that data had been classified, cataloged, lineage had been documented, and data quality rules had not only been established, but the data met those data quality rules. A process had also been established to address any data that violated any of the data quality rules.
- Silver — data had been classified, cataloged, and lineage had been documented.
- Bronze — data had been classified.
We also created a process that allowed the organization to request data be made available in the cloud data warehouse, and then assign what level of classification it needed to be for its intended use. We worked with our data families and our data stewards to determine the appropriate rigor level for data to ensure that we did not apply too much rigor. We did not want to overburden our resources, and we did not want to slow the organization down in getting to their data.
The data required for building out KPI dashboards would receive priority within the process.
As requests for data started coming in from the business, we found a core set of data required for at least 50% of all reporting and analytics to include the KPIs that had helped kick off our journey into the cloud. As we worked to deliver the data for our KPIs, we found that we were delivering what the broader organization needed to drive their reporting and analytics.
Data Classification, Catalog, Quality, and Lineage
I’ll dive more into these items in future articles, but here is a summary of each:
- Data classification — data family had determined what security classification was needed for the data, allowing us to extract data from the source and load it into the cloud.
- Data Lineage — documented what source the data came from
- Data Catalog — included the data lineage, any additional logic or transformations applied to the data, and a data glossary definition.
- Data Quality — measure data using rules defined by the business.
Business Before IT
As we worked with the business, the last change we made around how our organization interacted with data gave the business full access to the data layers. This allowed IT to focus on working with data that brought the organization's highest value without being a bottleneck to individual teams. Even though the data may have been in a more raw form, it was still available. This resulted in a win-win for IT and the business. IT was no longer a bottleneck and the business had whatever data they needed. As the business worked with data, they helped mature it for IT. When it came time to apply additional rigor to data in order to move it to bronze or from bronze to silver, much of the work had been completed by individual departments.
We developed a standard nomenclature for data to help the business and IT understand what data layer they were operating in. For example, source data tables would be labeled as .source, staging tables would be labeled as .stage, and enterprise data would be labeled as .enterprise. Each data element in .stage and .enterprise would have a flag indicating gold, silver, bronze, or N/A.
The Result
I want to say that once the project was complete, everyone was satisfied, and we had all of the data needed to drive the business forward.
The reality was messier, but we did have a solid foundation of data for the organization to use. We had exposed more data and applied more rigor around that data than ever before. We were able to level up the broader organization's technical skills so that they could innovate without waiting on IT. Data is always evolving, and for every question you answer with data, ten more questions come up. The journey is never over, but we could set our organization up with a strong and solid foundation to move quickly into the future.
Don’t hesitate to bring in an outside team, like Hashmap, that has this as a core competency. They can help not only stand up the warehouse (which is deceptively easy), but they can help you configure it in ways to anticipate the future while keeping costs low.
Hashmap’s Data & Cloud Migration and Modernization Workshop is an interactive, two-hour experience for you and your team to help understand how to accelerate desired outcomes, reduce risk, and enable modern data readiness. We’ll talk through options and make sure that everyone has a good understanding of what should be prioritized, typical project phases, and how to mitigate risk. Sign up today for our complimentary workshop.
Ready to Accelerate Your Digital Transformation?
At Hashmap, we work with our clients to build better together.
If you are considering moving data and analytics products and applications to the cloud or if you would like help and guidance and a few best practices in delivering higher value outcomes in your existing cloud program, then please contact us.
Hashmap, an NTT DATA Company, offers a range of enablement workshops and assessment services, cloud modernization and migration services, and consulting service packages as part of our data and cloud service offerings. We would be glad to work through your specific requirements.
Feel free to share on other channels and be sure and keep up with all new content from Hashmap, an NTT Data Company, here. To listen in on a casual conversation about all things data engineering and the cloud, check out Hashmap’s podcast Hashmap on Tap as well on Spotify, Apple, Google, and other popular streaming apps.
Other Tools and Content You Might Like
Scottie Bryan is a Delivery Manager with Hashmap, an NTT Data Company, providing Data, Cloud, IoT, and AI/ML solutions and consulting expertise across industries with a group of innovative technologists and domain experts accelerating high-value business outcomes for our customers. Connect with Scottie on LinkedIn.
