Philosophy of Analytics, Lesson Two: Who Are You Working For?

Introduction

In a previous post, I discussed the first lesson in a philosophy of analytics: begin with the end in mind.  That is, keep in mind the purpose of analytics when you are starting and designing and running an analytics project.  I defined the telos, the purpose, of analytics in the following way:

The purpose of analytics is to (1) justify or change beliefs with the use of evidence in the form of data  (2) in order to generate true (or truer) beliefs that can then be used to make decisions related to one's goals, and that, (3) because they are more in accord with reality, are more effective in bringing about one's goals.

This addresses the fourth of Aristotle's causes for an object: material, formal, efficient, and final.  In this post, I will address the efficient cause, that is, what brings about, creates, or changes the object.  In our context, the question we are discussing then is, what brings about, creates, or makes changes to analytics?  Who or what creates the data, who uses the data, who controls the data, who develops the analytics, and who uses the analytics?

A Little Action Theory

Before we answer that question, let's look at the purpose of analytics more closely.  Analytics is intended to justify or change beliefs, to generate true beliefs, to help make decisions to achieve goals.  Beliefs, decisions, and goals are held by agents with intentional states (i.e., people).  We can break each aspect down further:

• Beliefs: a person's beliefs relate to facts known by the person as well as assumptions made by the person, not necessarily supported by facts.
• Goals: a person's goals relate to what that person desires, that is, what that person wants.

The belief and goal (belief and desire pair) lead to a decision (action) on the part of an agent.

• Decision: a cognitive act which results in the taking of physical action or communication in accord with the belief-desire pair.

For example, suppose I want to eat an apple (goal/desire).  If I know that the grocery store sells apples (belief), then I can decide to go to the store to satisfy my desire to eat an apple.  Taking the action of going to the store and buying an apple will satisfy my desire, and it is the belief that the store has apples along with my desire to eat an apple that leads me to act.

Applying to Analytics

Why does this matter for analytics?  Well, since analytics is about changing/confirming beliefs so that decisions can be made in accordance with goals, we need to make sure we understand the who behind the beliefs, goals, and decisions:

• Beliefs: whose beliefs are we trying to change/confirm?  Maybe just as important, whose beliefs are we NOT trying to change/confirm?
• Goals:  whose goals are we trying to meet?  Whose goals are we NOT trying to meet?
• Decisions: who makes the decisions?  Who doesn't make the decision?

It is important that we keep each of these straight and separate, for they may not belong to the same person or group.  For example, suppose I am developing analytics for my manager.  We have data that will change or confirm his beliefs about customer sales.  He reports his belief to the CEO, who makes a decision to act in a certain way using my manager's belief.  The CEO makes this decision with the goals of the stockholders in mind in hopes of achieving the goals of the stockholders.  As one can see, there can be a lot of who involved analytics.

Who is Who?

Who is the who in an analytics environment?  That is, who or what brings about, changes, uses, or creates analytics? Perhaps this is a bit simplistic, but the following analytics flow is perhaps representative of most cases when boiled down to essentials in a business context:

1. Data source: the source of the data upon which the analytics will be done.  This can be machine generated (server logs) or people generated (customer sales transactions).  Perhaps the data is already stored in a server or data warehouse, and so this specific analytics project is a little downstream and can be seen as part of a larger analytics project (analytics within analytics).
2. Data administrators: those individuals whose job is to pull from the data source the data that is needed, clean it and transform it as needed.  Usually, this data will stored in a database.
3. Data warehousers: those individuals whose job is to take the data from the databases and create data warehouses that contain aggregates of data, summaries, calculated metrics, and KPIs.
4. Report/dashboard developers: those individuals responsible for developing reports, charts, dashboards, etc. that bring out the trends, metrics, and summaries of the data.
5. Analysts: those responsible for making sense of the data in the business context, spotting trends, noting key outliers, observing the metrics, and internalizing the overall business context.  These individuals use the reports and dashboards.
6. Belief Holder (Manager, Director, CEO): responsible for using the analysis of the data to inform his or her beliefs about the business context in order to communicate this belief to others.
7. Decision Maker (Manager, Director, CEO): responsible for using his or her beliefs about the business to make a decision about how to run the business.
8. Goal Holder (Manager, Director, CEO, Stockholders, Stakeholders): the ultimate stakeholder, the one whose goals and desires are to be achieved by the decision made on the basis of belief.

Notice something very important.  Persons 1-5 are usually thought of in the context of analytics.  However, the whole purpose of analytics rests with persons 6-8.  That means that there can be (and often is) a major gap (technologically, contextually, purposefully, etc.) between those who create, change, and bring about analytics and those who use analytics for its purpose.  For example, if I am a report developer, how can I make sure that the reports I am developing are useful if I don't know what the goals of the organization are?

Bridging the Gap

How is this gap bridged?  In the following way.  As the data, analytics, belief, decision, and goal flows from 1 through 8, the reverse also needs to be true.  The goals of the stakeholders need to be communicated to the decision makers, the decision to be made needs to be presented to the belief holder, and the beliefs to be tested or confirmed need to be communicated to the analyst and beyond.  In fact, the more that 6-8 can be communicated to 1-5, the better. For example, a data administrator that knows what the CEO cares about will know how to administer the data most effectively in accord with the CEO's goals.

Conversely, the more that 1-5 can be communicated to 6-8, the better.  A decision maker that doesn't appreciate the process that the data flows through, including its difficulties and limitations, will certainly not appreciate those who provide that data, nor will he or she fully understand the context of the decision to be made.  This can lead to undesirable results.  For example, a decision maker that has a true belief that customer sales are increasing rapidly may believe this to be true across the board.  However, if the data source excludes a certain kind of product, and this kind of product is in fact decreasing in sales, then any decision in regards to that product that assumes that it is increasing in sales will likely be a bad decision.

In short, communication is crucial.  Up and down the chain there needs to be constant communication about beliefs, goals, desires from 6-8 and technological/data-related specifics from 1-5.

The Analyst's Point of View

From the analyst's point of view, you need to know who cares about analytics.  Who are you working for?  What are his or her beliefs, goals, and decisions to be made?  What is most important to him or her in the business context?  Once you know this information, make sure your analytics, from start to finish, keep this in mind.  Again, begin with the end.  You are trying to represent the business context in the most realistic way so that those who are making decisions in accordance with the desired goals will have true beliefs about the business context.  Make sure your analytics are relevant to these beliefs, goals, and decisions.

Remember that the analytics you create need to be useable, not merely true.  If the analytics platform you provide is not understandable by the person using it, then it is not fulfilling its purpose.  Who cares if it is true if it is not useable?  Who cares how pretty it is if no one understands it?  My friend tells a story in which he created a beautiful and sophisticated dashboard for an executive.  The kinds of charts he used were perfectly selected to convey the needed information.  However, the executive could not make sense of the more sophisticated charts, and asked for a simplified version.  The lesson here is that you need to know your audience, and design your analytics for your audience.  Think about the user's perspective before designing your analytics so that when the analytics are complete, the users will actually use and understand your work.

Conclusion

In short, your analytics need to relate to the beliefs, goals, and decisions being made by those who use your analytics.  Furthermore, your analytics need to be useable by these individuals.  When your analytics target the beliefs needed to make good decisions in accordance with goals, and they are useable by those individuals informing beliefs, making decisions, and setting goals, then your analytics will fulfill their purpose, their telos.