From Counting to Choosing: How Data Helps Us Make Decisions

It begins with a question

How much did we spend? How many people attended? What should we do next?

These questions sound simple. Yet each needs something different.

Imagine a research site with 100 planned visits last month. Twenty were missed. The team has a number, but it still has questions. Were some visits entered twice? Did patients face travel problems? Were the appointment times hard to manage?

Most of all, what should the team do?

This made-up example shows the journey from data to a decision. Let us start at the beginning.

Before the dashboard, there was the record

Think of a shopkeeper writing sales in a book. Each sale is a record. Adding the sales gives a daily total. Comparing totals across days may reveal a pattern.

That is a simple way to picture the roots of analytics. People record what happens, compare what they find, and use it to guide a choice.

Analytics did not begin with a dashboard. It draws on statistics, mathematics, and the study of how to use limited resources. Computers gave people new ways to store records and carry out these calculations.

There was no single moment when records became analytics. Different fields developed related ideas to answer different questions. Even today, the boundaries between analytics and other fields are not fixed.

Information needed to reach the right people

As organizations grew, information could sit in separate places. One team knew the costs. Another knew the workload. A manager needed to see how the pieces fit.

In 1958, IBM researcher Hans Peter Luhn explored a system for business intelligence. This was an early milestone in using technology to make information useful within an organization.

Business intelligence, or BI, brings together processes and tools that help teams use their data. Reports and dashboards are familiar parts of it. A shared report can help people work from the same definitions and totals.

Here, "intelligence" means useful understanding. It does not automatically mean artificial intelligence.

BI and analytics overlap. BI often provides a shared view of performance. Analytics includes methods used to explore questions and compare possibilities. Modern BI tools can include analytics, so it is too simple to say that BI only looks backward and analytics only looks forward.

Four questions help explain analytics

The INFORMS Analytics Framework describes different types of analytics. We can understand them through four questions.

Descriptive analytics: What happened?

Our site reports 20 missed visits out of 100 planned visits. That is a 20% missed-visit rate. A count tells us the size of the problem. The rate also considers how many visits were planned.

Diagnostic analytics: What might explain it?

The team checks patterns by day, time, and other relevant details. It may also ask patients about barriers. A pattern can suggest where to look, but it does not prove a cause. Missed visits alone do not tell us why someone could not attend.

Predictive analytics: What might happen next?

With suitable data, the team might estimate future missed visits. A prediction is an estimate, not a promise. It must be tested on data beyond those used to build it.

Prescriptive analytics: Which action best fits our goals and limits?

The team could compare options under a fixed budget. For example, how might different staffing schedules affect the number of appointments available? A model needs clear goals, sound inputs, and realistic limits.

These four types are useful guides, not a ladder every project must climb. A careful count may answer one question. Another may need a model.

A report could show the problem. People still needed to choose.

This brings us to decision support.

In 1971, Gorry and Scott Morton published a framework for management information systems. It helped connect information systems with different kinds of management decisions. Some decisions follow clear rules. Others require judgment because the problem or the best response is less clear.

Decision support helps people weigh options. It can draw on data, models, research, experience, and the needs of those affected.

For our research site, the options might include more flexible visit times or transport support. The team would need to check what is allowed by the trial, what patients need, and what resources are available.

A dashboard can help reveal a problem. A decision support tool may let the team change assumptions and compare options. People still need to judge whether the result makes sense.

How do we organize the work?

A framework is a guide for doing the work in a clear order. It helps prevent a common mistake: building a model before knowing which question it needs to answer.

One established guide is CRISP-DM, short for Cross-Industry Standard Process for Data Mining. It has six phases: business understanding, data understanding, data preparation, modeling, evaluation, and deployment.

In plain language, we can read them this way:

• Understand the goal. What problem are we trying to solve?
• Understand the data. What do we have, and what is missing?
• Prepare the data. Fix errors and make the records ready to use.
• Build the analysis or model. Choose a method that fits the question.
• Check the result. Does it work well enough, and does it address the goal?
• Put it to use. Make the result available where it can support action.

The work can move back and forth. Finding a data problem may send us back to an earlier phase. Not every project needs every phase to the same extent.

Keep the decision at the center

For this blog, we can turn these ideas into a simple working checklist. This is a teaching guide, not a new validated framework.

1. Name the decision. Our site needs to decide which feasible support option to test. "Build a dashboard" describes a task. It does not explain the decision the dashboard should support.
2. Check the data and the people behind it. Does a missed visit mean a cancellation, a no-show, or a visit moved to another date? Are all sites using the same definition? Ask patients and staff what the records may leave out.
3. Explore the evidence. Review the patterns and possible explanations. Use research and local knowledge to guide the options. Do not treat a prediction about who may miss a visit as proof of which support will help them.
4. Compare the choices. Consider expected benefits, costs, staff time, fairness, and patient preferences. State the assumptions. Show what could change the answer.
5. Act and learn. Choose an appropriate way to test the option. Decide in advance how success will be measured. A lower missed-visit rate afterward may be encouraging, but a simple before-and-after comparison cannot rule out other explanations.

The result may lead to a new question. That is how the work continues.

More data is not always the answer

Before collecting more information, ask what it will help you decide.

A large file can still contain errors. A detailed dashboard can still use the wrong measure. And a model can perform well overall while working poorly for some groups.

For our site, a useful review would ask: Are records complete? Is access limited to the right people? Are we measuring attendance fairly? Could our plan add new burdens for patients or staff?

Tools should fit the task. A spreadsheet may be enough for a small, clear question. A more complex question may need linked data, statistical methods, or simulation. Complexity alone does not make an answer better.

Bring the pieces together

Data provides the records. Analytics helps us explore them. BI helps teams access and understand information. Decision support helps people compare choices and act.

These parts overlap and work together. After action, new data helps us review the result.

At Master Table, we begin with the question a team needs to answer. We help connect evidence and analysis with the decision at hand, while making the assumptions and limits clear.

The goal is to help people understand their choices and learn from what happens next.

To discuss an analytics or decision support project, contact hello@mastertable.com.

References

1. INFORMS. (2016). Defining analytics: A conceptual framework. ORMS Today.
2. IBM. What is business intelligence (BI)? Includes the history of BI and its relationship with analytics.
3. INFORMS. Explore the INFORMS Analytics Framework.
4. Gorry GA, Scott Morton MS. (1971). A framework for management information systems. MIT Sloan School of Management working paper.
5. IBM. IBM SPSS Modeler CRISP-DM Guide.

Sources reviewed September 26, 2026. The research-site example and numbers are fictional. Historical examples are selected milestones, not a complete history of the field.