Process, Data, Analytics
A simple model that ties them together.
Over the years, in my work in analytics (or more recently in people analytics), I’ve come across various models that connect analytics concepts. Many are useful, but I often come back to a simple one that is the most meaningful to me. Perhaps this is rooted in my previous background as a Six Sigma trainer where I spent a lot of time working to improve all types of processes. Thank you to Chris Chen, a former colleague of mine, for the ideas and conversations around this mental model.
This model is simple, but I’m convinced you can’t progress in your people analytics maturity without understanding it. I’ve often used this visual with colleagues, team members and stakeholders. Like all models, it is wrong as a simplification of reality. But like some models, I do believe it to be useful.
Process
While there is no single linear set of steps in the model, it is helpful to start with Process. You can start with data, but I find it helpful to start further upstream and consider the data source. And by data source, I'm not talking about a spreadsheet or database. Rather, I'm talking about the business process that produces data, which may be collected in a spreadsheet or database. Processes consist of steps that convert some input into an output. You may have data on the input, on each of the steps, and on the output of the process.
Consider talent acquisition and its process of attracting, onboarding, and developing employees. What are the steps that the organization takes that generate data? Do you collect data on the candidate as part of their hiring process? Are data generated at each step of the hiring process? How do these steps convert your input (a potential candidate) to the output (an employee at your company)? Perhaps the process is not consistent. Perhaps it is not well-defined. Yet there is a process generating information that can be captured as potential data, whether or not it is measured and recorded.
As another example, consider an assessment of a leadership development program. If you are collecting data to evaluate its effectiveness, what is the process you are trying to improve? Is it the process of how leaders become more effective? Is it the process for how the program is implemented across the organization? Or is it the process (e.g., manufacturing, sales, research) that leaders are responsible for? If the leadership development program doesn’t improve these processes that lead to better business outcomes, then it is not a valuable program.
Data
Next is Data. This includes all types of data, whether it be numerical, categorical, survey responses, text, video, and much more. No matter the type, it is always the result of a process. Much has been said about the value of data and the importance of data-driven decision-making. However, in and of itself, data has no value. It is only when it is used to derive analytics insight. Data is the building block that leads to information. However, it is only as valuable as how well it reflects the process of interest. Data collected because it is easy to collect will be worthless without understanding how it describes a process.
Analytics
Finally comes Analytics. The insights from data are then used to further improve processes. There are countless approaches and methods ranging from descriptive statistics and data visualizations to complex predictive models. The most powerful analytics are those that answer questions and tell you how to change and improve your processes. Returning to our talent acquisition example, consider how candidate data could be used to determine the most efficient sources of candidates. Or how data on the time it takes to complete steps can be used to reduce the time to hire.
Some would argue that AI has the potential to automatically create analytics from data. I’m a bit skeptical of that potential because so much of analytics depends on context and business knowledge. Unless you understand the process that you want to improve, it is difficult to determine the right analysis approach.
Technology and Tools
In the center of the model, we have the technology and tools. They are in the center not because they are the most important, but rather to indicate that they are often means that enable the more visible parts outside the center. Technology is always in service of the other steps, whether it is automated methods of collecting data, software tools to analyze data, or systems that enable process improvements.
The roles on the outside of each model component are loose generalizations of the people who have primary responsibility for those different steps. These roles may be combined into a single individual or may be broken out into whole teams within large organizations.
Implications
What are some implications of understanding this model?
You recognize that different processes lead to different data. When processes change, the resulting data will also change. Processes are not always consistent and reliable, and their reliability determines the reliability of your data. As the adage says, “garbage in, garbage out”.
You will understand the criticality of data governance and optimizing your data-generating processes. Instead of blaming people or ignoring data quality issues, you will dig down to the systemic causes of the issues and fix the processes, mistake-proofing them as needed.
Your stakeholders will recognize that analytics doesn’t just magically appear without work. They will recognize their role in ensuring consistent processes will benefit them downstream as they can be assured of high-quality information based on high-quality data, when they need it. The analyst does not generally own the process and often has little ability to improve the data quality. Business process owners and those who execute processes have far more influence on the data quality.
There will be no analytics for the sake of analytics. All analytics work will be tied to business outcomes and strategy. It doesn’t matter if the analytics is simple descriptive methods or the most complex AI algorithm; it is all tied to some need to answer a question or lead to a better decision.
Technology will not be implemented for the sake of technology. You won’t fall into the hype cycle of whatever is the latest technology of the month. You can avoid costly technology implementations that don’t enable the other components of the model. Technology that is narrowly focused on one element of the model must be implemented with consideration of the others.
There are many more implications of this model. In general, I find much more focus on the Data and Analytics while ignoring the Processes that generate the data. Until we understand the importance of processes, we will not do the right work to understand and improve them.
Jens, surely a process needs to be initiated by a specific and meaningful need - a problem to be solved, a question to be answered, a gap to be filled, etc.? Specific for process design and meaningful to ensure optimality, not just feasibility.