- ABOUT
- VIDEOS
- TOPICS
- JOBS & TALENT
- TESTIMONIALS
- COMMUNITY
- EVENTS
- NOMINATIONS & LISTS
- SPONSORSHIP
- ABOUT
- VIDEOS
- TOPICS
- JOBS & TALENT
- TESTIMONIALS
- COMMUNITY
- EVENTS
- NOMINATIONS & LISTS
- SPONSORSHIP
Today’s business leaders know that data is important to their company. Naturally, they want a sound strategy that allows them to grow maturity with data. Unfortunately, data strategies rarely achieve their objectives. Often, this is because the stated objectives are focused on technology. More frequently still, the strategy is focused on maturating the IT organization to the exclusion of the business organization.
This article will answer three fundamental questions:
Where could your data strategy be falling short?
How should data strategy objectives change to better frame the strategy?
What should you expect to see in a successful data strategy?
Earlier this year, I sat down with the CIO of a Fortune 1000 company. We talked about his vision for how data would transform the enterprise, and immediately came up against a wall of thorns. He lamented that, despite spending $1 million-plus on analytics the prior year, they had very little to show.
The business organization simply did not trust the reports and often repeated their mantra that ‘the data was bad.’ Business leaders treated IT as a transactional service provider; business people would not engage with the data team beyond sending their report requests. Automation? “Forget that!” he said. They are not mature enough with the basics to even contemplate artificial intelligence.
When I suggested that he consider investing in a data strategy, the response was that they had previously done so with little success. They made the recommended investments in data governance, data warehousing, and business intelligence, but the old problems persisted. The data strategy had, from his perspective, failed.
Every year, some version of this conversation occurs in most large organizations. Accountability often falls to IT, and this could be well placed. However, organizations need to broaden their view of accountability to include business operations.
The greater a company’s ability to convert data insight to business outcomes, the more benefits they produce, and the faster the company will produce them. Creating greater ROI from data strategy is simple: instead of focusing on data solutions, focus on business outcomes.
As the beneficiaries of the data inheritance, it is incumbent on businesspeople to participate in making data effective. This need eclipses requests of reports and data extracts.
Let’s discuss where data strategies break down and how we can get them on track.
Data strategy is necessary and important: it guides technology investment, technology execution, and defines an organizational structure. Executives often believe that a data strategy will help fill data insight gaps by virtue of good execution within IT. Experience has shown that this approach falls short.
You may recognize several common data strategy initiatives described below.
Visualization tools can generally perform one of three functions: reporting, visualization, and discovery. While some products on the market may perform double duty, few products natively perform all three.
Most organizations grew accustomed to reporting during 1990-2010. Reporting tools include products such as IBM Cognos, Microsoft Reporting Services, SAP Business Objects and Crystal Reports. They are successful at producing multi-page reports with complex layouts. The tools excelled at displaying tables of data but were not built to support meaningful data visualizations. In the modern world of data, “reporting” is often considered an anachronism; consumers expect a more interactive experience with their data.
In 2010 we saw the emergence of Tableau, a premiere visualization tool. Tableau changed our understanding of what was achievable with data and held a growth position in the market for the next 5-7 years. QlikView emerged as a competitor followed by Microsoft Power BI. Unlike their predecessors, visualization tools provided a new experience, allowing end-users to rapidly explore, filter and drill into visualizations. Business users finally began to feel some independence from IT.
Discovery tools entered the market in mid-2010. They pushed visualization and analysis capability fully out of IT and into the hands of business users. They provided a friendly interface for importing data and applying stepwise transformations. From there it was possible to slice and dice your data in a myriad of ways, unencumbered by what an IT developer might prescribe. Many visualization tools listed above include discovery capabilities. New entrants to the market include Looker and Alteryx.
Occasionally, we observe organizations purchasing a new analysis tool to fix the problem of business adoption. This approach is seldom effective at increasing access to data and/or adoption of business intelligence for the following reasons:
A new tool cannot improve the quality of data. While it is true that modern tools can aid in data discovery and visualization, the underlying quality of that data, especially when it is sourced from operational databases, will defy usability by business people. Joining tables and interpreting obscure operational coding is hard to get right even for skilled technologists.
A new tool cannot create business context. Most people struggle to analyze data to drive process improvement or strategy. This makes sense: their jobs focus on executing an operational process to achieve a business goal, not enriching or innovating on the process. This is also the reason why business people traditionally struggle to provide good reporting requirements to IT.
KPIs are difficult to produce in analysis tools. Some metrics can be produced by a summation or counting (e.g., revenue, gross margin); these are simple to implement in a tool. Many of the most important operational KPIs (e.g., customer retention, inventory balance, 30-60-90-day outstanding AR) are quite challenging to correctly implement. They require specialized skills to develop. As a result, business analysts often resort to Excel where they can manually build step-by-step transformations of data.
In summary, new analysis tools will not by themselves drive significant business intelligence adoption.
Data lakes are composed of several operational databases copied into an environment where data can be blended by an analyst. Data lakes are especially attractive to people who are adept at analyzing data. These skills are typically found in IT, data science teams, finance, and actuarial departments.
Combined with replication technologies, data lakes can provide a near real-time analysis of data from across the enterprise. There is no question that they are an essential component of modern data architecture. Business users — notably from operations, sales,and marketing — will experience a high degree of difficulty employing a data lake.
Data lakes present many challenges:
Operational data tables are complex. Most operational databases optimize their data structure to support an application interface. This results in obscure data structures: cryptically named tables and columns; multiple transaction types combined into a single table; abstraction (e.g., use of “party” tables), fields containing large amounts of data, code lookups, and more.
Data characteristics morph over time. Application interfaces, business logic and data all change as the business evolves. These changes are often small, myriad and perpetual. The consequence is that the database may require a different method of querying as the user looks further back in time: table joins, column values and filter methodology continually morph. Data quality often improves with time, meaning that older data can be perceived as much lower quality than more recent data.
Bridging data across operational databases can be complex. The value of a data lake is that you can blend data from multiple operational databases. Blending, however, requires that data values from one operational database can bridge to data values in another. At a minimum, this requires analysis to match coded values between systems. In more difficult cases, there is no way to effectively bridge similar data between operational databases. For example, consider one system that manages sales territories at that city/county level whereas another system manages at a postal code level. Because postal codes can cross provincial boundaries, and vice-a-versa, it will be challenging to blend data across sales territories.
Raw operational data and hence, data lakes, present a variety of other issues that are beyond the scope of this article to describe. Suffice it to say that data lakes should only be used by people who are skilled at querying complex data structures; who deeply understand how to interpret raw data into meaningful business concepts; and who are attuned to the complexities of connecting data across systems.
A data warehouse can be defined as a centralized store where data from many sources has been cleansed, integrated, and labeled to match official business definitions. They are often used as a single source of truth for reporting, visualization, data extracts and ad-hoc analysis. While data warehouses are among the most expensive investments a company will make around data, they provide tremendous benefit. Data warehouses increase reliability of reported data and reduce the time required to answer business questions.
Technologists love data warehouses. They love making data seem easy and perfect. Indeed, data warehouses have provided careers to countless data practitioners.
In data warehousing circles there is a commonly heard bromide: “if you build it, they will come”. In other words, if IT builds a high-quality data warehouse, business stakeholders will be attracted — like bees to honey — requesting reports and using it themselves to answer business questions. Perhaps this is viewed internally as a new, highly valued business function that can be serviced from IT.
When it comes to data warehousing, however, the disastrous truth is that if you build it, they won’t come. In fact, they probably will find a problem with the data and lodge complaints. Meanwhile, the data practitioners remain oblivious to the matter and will happily pile in more data tomorrow.
This pattern repeats itself endlessly in IT departments around the world. The cause is rooted in a chain of conditions commonly seen at the outset of the data warehouse initiative:
Business people aren’t engaged. Data requires business context to be useful for analysis. Context comes from understanding how data will be filtered, how data will be aggregated and how metrics are defined. To build context into a data warehouse, you need the engagement and insight of front-line business stakeholders; not IT people who “know the business,” but individuals who embrace the day-to-day challenges of executing a business process. Most organizations skip entirely the step of including business stakeholders when assembling their data warehouse. Everyone is culpable: IT too often does not ask, and in the rare instance they do, business people are too busy to give their attention.
Data warehouses become an exercise in loading data. Data practitioners love data, and they often deeply understand data to a greater degree than those running the business. This can lead data practitioners to a generally false notion that they deeply understand business processes represented by the data. The result is a data warehouse as a collection of well-managed data elements. It embodies the perspective of data practitioners and ignores that of business people. Data practitioners, blind to their own blindness, continue to add ever more data into the data warehouse, realizing too late that no one cares to use it.
Data warehouses are not trusted. The two prior conditions inevitably lead to this one. Trust is the currency of data warehousing. Anyone in the data warehousing field can tell you that a single instance of incorrectly reported data will destroy trust and alienate that group of users. The problem inherent in data warehouses is that data is quite difficult to get right. Getting it right requires crystal clear explanation from data consumers on what makes the data right to them. Simply loading data straight into the warehouse almost never suffices; some transformation must be applied. Further complicating the matter is that previously used reporting sources (typically legacy reports or Excel spreadsheets) are assumed to be accurate by default. It is largely immaterial whether these assumptions are valid; the business expects their data to match, or they require a detailed explanation for why it does not. Lack of trust is the single greatest contributor to abandonment of data warehouses.
Reverting to the old ways. Business stakeholders always obtain the data necessary to run their corner of the enterprise. They may scrape report data into Excel, load Access databases or request data extracts from IT; but they get the data somehow. As painful as these methods may be for analyzing data, they are well-worn and comfortable. When the data warehouse becomes untrusted, it is simple to revert to the old way of doing things. This easy-out is a major vulnerability of new data warehouses.
The consequence of these conditions is that many data warehouses tend to languish, abandoned by the people they were created to help. A few analysts may still use them but scant few others. This unfairly brings the ROI of the data warehouse into question. Fortunately, the benefits of data warehousing can be realized by addressing the challenges described above.
Master data management describes a set of technologies focused on building a “golden record;” dynamically updating that “golden record” when data changes in operational systems; and then propagating the “golden record” back into other critical systems. The “golden record” typically is a complex data structure describing a business concept (e.g., customer, product).
Master data management (MDM) is useful in many scenarios. For example, it can improve the quality of service delivered to customers; it is necessary for proper maintenance of inventory and regulatory compliance; it can reduce costs and errors in marketing.
MDM is often prematurely undertaken. While the goals are admirable, they are difficult to meet without the context of solving a business problem. For example, customer MDM created without context could capture a contact name, “SMITH, ROBERT J.” However, this name is not useful in marketing where a customer’s first name (non-uppercase) is used in a salutation. It is not useful when displaying the last name on a tax form. It is not useful for updating a system that stores a non-collated version of the full name, such as “Robert J. Smith.”
This is a crude example but illustrates the point that business context is necessary to drive effective master data management.
In this author’s experience, no one likes data governance committees. Start one up and you’ll soon believe this is true based on meeting attendance. The only people who reliably attend data governance meetings are data governance leads, who are, as it happens, equally and reliably lonely in their meetings.
One of the challenges of data governance committees is that they can feel like a fruitless exercise. Meetings get hung up on negotiating the definition of words like “customer” and “sales.” Everyone in the meeting is pretty sure these definitions are obvious, at which point they look at their watch and wonder why they bothered to show up in the first place.
In fact, the definitions of words like “customer” and “sales” are much less obvious than people think. It is an accurate cliché that every department in any organization will define them differently.
If the goal is to establish trust in reports and data, getting the definitions correct is inestimably important. By extension, this means that data governance is also important.
Why then is it so difficult to make happen? The reason is that data governance often lacks business context. A consistent definition of “sales” rises to a very serious matter in the boardroom when two reports show a different number. It matters to the salesperson who is struggling to retire their quota. It matters to the plant manager who is forecasting production schedules.
It is in those moments of need that people are ready to sit down and negotiate definitions. Until that moment, negotiating such things will seem frivolous.
The rationale goes something like this: if we hire a team of incredibly smart people, each with a Ph.D. in statistics, for instance — and give them access to all our corporate data — something great is bound to happen. They will search through our data and find opportunities to grow markets, cut costs, run more efficiently, and make everyone’s year-end bonus bigger. This line of thinking is more common than you may think.
The challenge is that, while many organizations assemble the right people and data infrastructure, they fail to properly position data science teams for success. Often, the data scientists themselves reject external input into their work.
When building predictive models (or any other kind of models) it is crucial to start with business context. Data scientists need to understand what problem they are trying to solve. They need to understand levers to solve the problem. Finally, they need to run experiments in the business to determine if the levers make a significant difference in business outcomes.
Business stakeholders must be highly engaged in defining the problem. Furthermore, they must be committed to participate in controlled experiments. Management must be committed to innovate in ways that affect real customers — this is the most effective way to prove models work.
The data scientists alone with their data can accomplish relatively little. It is only with true partnership across the business that magic will happen.
This outlook on data strategy may at first appear dismal. Realistically, the data strategy initiatives listed above should be viewed as mandatory for long-term maturity with data. They are important to do correctly.
The singular common theme observed in the downfall of data strategy initiatives is that business context is missing. Business context comes from business engagement and partnership with IT. This is what The Intelligent Enterprise seeks to instill.
We often hear that we must treat “data as an asset.” Technologists often repeat this phrase to garner support for their data initiatives. Across the table, executives roll their eyes, wondering why technologists think data is so much more important than running the business.
If we think critically, we realize that “data as an asset” is not universally true and leads to some misguided behaviors.
Data warehouses are among the most expensive data investments a company will make. Yet 60% or more of data elements in every data warehouse are never queried for any purpose. Should those never-queried data elements be considered an asset? If 75% of data lake elements are never queried, should we consider them an asset?
Around 85% of data in the enterprise is not used for any purpose beyond the functioning of operational applications. No one analyzes that data, and few people care about it. Nor should they.
It is true that we don’t always know what data is going to be beneficial, which is why data lakes are so valuable. They offer cheap storage for all the data. Deciding which of the data should be kept versus discarded would be a monumentally time-consuming task. Better to keep every bit until its lack of value is glaringly apparent (sometimes 20 years later), at which time we can dispose of it en masse.
However, storing data of dubious value does not elevate it to the status of an “asset.”
Here is an alternative viewpoint: “Data that helps us measure and improve the business is an asset.” If we had a way to identify this kind of data, then we could laser focus our investment on a much narrower spot.
Traditionally, data strategies focus on topics such as data architecture, business intelligence, and data governance. This view is narrow and often diverts attention from the big ROI opportunities. While these topics are important, the data strategy should begin by understanding how value is created from data.
Opportunities abound across the enterprise, such as:
Improving Your Products
Vast quantities of internally generated data allow for innovation in products and services. By identifying when customers abandon products or avoid beneficial features, products can be honed. This will directly drive greater market penetration and profitability.
Optimize Marketing Spend
Acquiring more customers and acquiring the right customers are central goals of marketing. This is possible through deep analysis of the current customer base as well as inclusion of third-party data. Customer acquisition costs mandate continuous improvement in targeted ad spending and other expenditures.
Delighting Your Customers
Improved customer satisfaction leads to retention and increased Lifetime Value of your customers. Given the high cost of customer acquisition, it is more practical to retain customers than to find new ones. The average cost of obtaining a single new customer can exceed thousands of dollars, so once you have them, you better keep them. A rich digital experience, customer support, retention and targeted concessions are crucial areas in which to improve customer satisfaction.
Increasing Accountability
Managers often bring years of experience in multiple functional areas including employee supervision. An individual’s experience is quite limited compared to the diversity of problems they need to solve every day. For that reason, management depends on their intuition. Results based on applying intuition are a mixed bag. Measuring business performance and providing this insight to management allows them to make decisions based on business facts. It also provides a method of holding individuals accountable.
Outpacing the Competition
Designing a sound business strategy requires a deep understanding of markets and customers; their loyalty will make or break any company. As more companies embrace AI, automation, and other new technologies, their ability to steal your market share grows. Combatting market share attrition requires that you monitor the pulse of the market, as well as the pulse of your competitors.
Most companies are sitting on a goldmine of potential improvement that had previously been tapped out by business process improvement. Once operational excellence programs have reached their zenith, further process improvements yield only incremental benefits. The easy-to-reach fruit has been picked from the vine.
The correct objectives for a data strategy should not be technology, architecture, tools, or IT processes. These are only a few of the logical steps leading to the objective. Data strategy objectives should major in areas of the business that need improvement, opportunities for growth, and profitability. Some questions to ask are:
How does the business intend to grow in the next 5 years?
Where are the greatest opportunities for cost savings?
Where should we make the business more efficient?
How can we delight our customers?
Once we know the problems to solve, we can determine how to apply data to solve them better. It is important to note that “data” should never be the entirety of any solution but should play a lead part in business and process transformation.
In summary, the objectives of data strategy should be solvingbusiness problems rather than focusing on data itself.
Once you are oriented to the correct objectives, it’s time to define the data strategy.
This section does not deal with IT and technology maturity. It is important to reiterate that IT topics such as data architecture, data governance, and business intelligence will be essentialcomponents of a successful data strategy. These will reflect the business objectives as well as the complexity of managing data within your corporate ecosystem.
This section addresses business maturity with data. The business side of the data strategy should focus on developing business maturity in the following areas:
Identify business processes that could be created or redesigned by incorporating data insight. Artificial intelligence can be the foundation for a new process that otherwise would not exist without it.
For a given process, how could we make the process more efficient (or automated) through the introduction of data or AI?
What is the approach for reviewing processes for redesign?
How are data professionals in your organization consulted in process redesign initiatives?
Reimagine Business Processes Vignette: The HR team recognizes that technicians are rapidly leaving the organization. HR engages an internal data science team to predict which employees are likely to leave and why. This leads them to correct systemic issues related to management and then coach individual employees before they exit.
Identify how existing business processes could be enriched through the addition of analytical insights.
How can we enrich a given process by introducing insights or automation?
How do we encourage business stakeholders to engage in a discussion around process improvement?
What are the expectations of management to enforce adoption of analytics insights?
What is our tolerance for incorporating analytical insights into our ERP based processes?
Who is tasked with assessing existing processes for improvement opportunities?
Modernize Business Processes Vignette:Supply chain procures parts from a comprehensive list of manufacturers and then fulfill from warehouse to the field technicians. Balancing inventory levels is a challenge. The procurement application presents visualization of breakage rates by vehicle and AI-predicted geographic demand. Now, the right parts are in the right place at the right time.
Identify cases where management should hit KPI targets and hold them accountable financially. Leading metrics can be a powerful way to hold individuals responsible for week-by-week activities.
What KPIs should our executive team be focused on to ensure business goals are met?
What activity (vs. outcome) metrics should be monitored to ensure future KPI targets are met?
What is the expectation of management to understand metrics and hold their teams accountable?
How is management financially held accountable for achieving KPI metrics?
How can we give all employees insight into the metrics that measure their performance, or the performance of their department?
Manage With Accountability Vignette:A field technician supervisor has a goal of increasing customer NPS from 7.5 to 9.0 during the current fiscal year. She is automatically provided a list of five technicians whose performance needs to improve along with service call metrics. She helps each technician create a custom plan to improve their performance and NPS.
Identify cases where manual effort can be replaced by automation, resulting in equal or better business outcomes.
What is the tolerance of management to investigate automation opportunities?
Where can we improve customer experience by automating process-based decisions?
How do we identify cases when a person’s intuition is routinely relied upon to deal with exceptions in a business process?
How do we systematically review processes for automation opportunities?
Automate Everywhere Vignette:Reconciling invoices and purchase orders has long been repetitive, time-intensive and error prone activity. Robotic software is trained to accurately recreate this activity by observing humans. As a result, the AR team has freed up time to focus on value-added work.
The questions listed above are a sampling of those that a robust data strategy should be asking. Most importantly, the questions do not have technology answers, but rather business answers. They are intended to drive discussion around the business maturity with data.
Data strategies are crucial for creating a data-driven culture. While they must include technical aspects such as architecture and governance, the technical aspects should take a back seat to the business role in driving outcomes.
A successful data strategy starts by having the right objectives, which are focused on business outcomes. Typically, objectives reflect the organization’s business strategy, or business problems which must be addressed.
The data strategy must illuminate a path to grow business maturity with data. Excluding this side of the data strategy means relegating it to a data exercise that will never realize its potential. It is incumbent on the business — rather than IT— to develop awareness and skills for how data can be leveraged to benefit the company.
In conclusion, including the business maturity side of data strategy will align all interests throughout the company and springboard you to a data-driven culture. Your customers, executives, management, and workforce will all be beneficiaries.
Jeff Kanel is a Director of Data & Analytics for Centric Consulting. Through his work as a consultant, he challenges clients to see new possibilities from data. Jeff regularly works with executive teams to help them create practical data strategies and create a data-driven culture.
With 30 years’ industry experience, Jeff has a rock-solid foundation in business process maturity, machine learning, business intelligence and modern analytics. He is the author of “The Intelligent Enterprise” business maturity model for data.
Outside of work, Jeff enjoys spending time with his wife and children, playing in a band, and exploring innovations in data.