Taxonomy
of Data

Level 01


Unstructured Data

Level 02


Structured Data

Level 03


Information

Level 04


Knowledge

Level 05


Wisdom

In 1992, I completed my Master of Science degree in engineering with a concentration in artificial intelligence. At that time, creating a practical application for AI was difficult because the discipline and its technology were in their infancy. One of the things we were trying to do is develop a clear and consistent set of definitions. To that end, my professor had me develop a five-level taxonomy as part of my master’s thesis. I’m sure there are other versions, but this is how I have always looked at data and its downstream evolution.

Level 1: Unstructured Data

Data is a representation of facts, symbols, values and attributes. It is fundamental and represents the elements of our reality (whether we are conscious of it or not). Unstructured data is data that is not stored in a table or database and is not accessible or available for processing.


For instance, I could measure the temperature outside and learn that it’s 72 degrees F. This is data. But if it’s just captured on my thermometer and not entered into a database, there’s very little I can do with it. It’s just a fact. For data to be usable for further processing or analysis, it needs to be structured.

For data to be usable for further processing or analysis, it needs to be structured.

Level 2: Structured Data

Structured data is stored in a database (table) and easily accessible for processing. Again, data is just facts. Better data means better (or more accurate) facts. Usually when we speak about data, we mean structured data.


To move from Level 1 to Level 2, unstructured data needs to be captured. You can do this via user entry into an ERP—for example, when an inside sales representative takes a sales order over the phone, she is dealing with unstructured data. When she enters the parameters of an order into the ERP, it is now structured.

There’s also automated collection: voice recognition entering the same order automatically, a programmable logic controller (PLC) gathering data from shop-floor machines, a transducer capturing ambient temperature and storing it, Internet of Things (IoT)devices collecting outside data.


Because data represents raw facts, we want it to be as good as possible: accurate, timely and stored in a system so we can analyze it to support decisions. But facts alone aren’t enough, so better data, although necessary, is not sufficient for better decision-making.

Because data represents raw facts, we want it to be as good as possible: accurate, timely and stored in a system so we can analyze it to support decisions.

Level 3: Information

Simply put, information is the answer to a question, or query. We obtain information by using a reporting engine to process structured data. “What time did the customer place sales order number 12345?” is a query. “At 9 a.m. EDT today” is information.


Good information—the ability to see and get to the data, process it and extract the answer—is essential to better decision-making as well as the reduction of uncertainty. There are two common challenges to getting information:

  1. The data wasn’t easily accessible; usually a function of having multiple systems that aren’t integrated or data that simple wasn’t captured (structured). We tend to hear this problem from clients as “We have poor visibility.”
  2. Reporting structures aren’t defined effectively, typically because needs change over time. Traditionally, key users have had to define those structures well in advance, so in real time, the resulting reports often don’t serve their needs.

Let’s say we have a predefined report that gives users the time a customer placed a sales order. Now assume that someone needs to know how much time elapsed between order entry and confirmation of delivery date. This apparently simple additional requirement is often not simple to implement.

Relying on traditional methods, that isn’t possible without modifying the report or creating a new one. You have to call IT, which logs, prioritizes and schedules a ticket—and if you’re lucky, several weeks later you get the report. Then you need to know how many orders the customer placed for the same item in the past 90 days. Here we go again.

One of the biggest benefits of SAP’s S/4HANA (in-memory) architecture is the ability to define the query in real time and push that capability to an informed end user. This, in addition to ERP’s automating repetitive tasks and creating end-to-end (vertical and horizontal) transparency is crucial to

improving the quality and speed of information delivery so the organization can make better decisions. Having a system that doesn’t need predefined reports and can answer any question the business user has in real time is the vision we pursue as we strive to create the ultimate decision support environment.

We believe that one of the biggest benefits of SAP’s S/4HANA (in-memory) architecture is the ability to define the query in real time and push that capability to an informed end user.

Level 4: Knowledge

Knowledge is familiarity and understanding of a specific subject or area. It is associated with the adverb “How”. In the ERP world, it covers how something works or how to do something. You can acquire knowledge through education (codification or configuration), or by learning from experience. Codification is a mature discipline, and coding/configuring best practices is a way of “teaching” the system how to behave under normal conditions. We can even code exceptions, setting up parameters for thresholds where the process changes accordingly.

Learning happens when feedback is received (and promptly after a decision and its subsequent action have taken place.


In traditional ERP usage situations, when we didn’t like a given outcome, we would recognize the issue (feedback) and code a new rule or exception into the ERP (learning). Although this doesn’t look like artificial intelligence (it is not AI) it is still a form of “learning”. Swift feedback is crucial for organizational learning. That includes the people getting better at their jobs, making

changes to configuration or coding exception as well as machine learning, where the system is self aware and makes changes to the “rule” without the intervention of a human programmer or operator.


To summarize, knowledge in an ERP is configuration and customization of processes (knowledge about the system), coupled with the information from effective reporting (knowledge about the business situation). We leverage this information to make better decisions.

Level 5: Wisdom

The dictionary definition of wisdom is “the quality of having experience, knowledge, and good judgment; the quality of being wise. Synonyms: Sagacity, sageness, intelligence, understanding, insight, perception, perceptiveness…”

Building on Level 4, knowledge, my definition is that wisdom represents the ability to:

  1. Learn experientially, taking feedback from actual outcomes and self-adjusting the rules and parameters of decision-making and execution in order to improve.
  2. Diagnose past events. This mean explaining, proactively or on demand, why something behaved the way it did.
  3. Predict possible future events.


This is the pinnacle of data utility. If knowledge focuses on “how,” wisdom focuses on “why.” Understanding why something behaves the way it does or why something will happen in the future are foundational to wisdom.


Why your ERP Implementation Partner Matters

Finding the right ERP Implementation Partner can be a complex process. In this video we will explore key considerations when identify the right partner. Why does your implementation partner matter? Dror Orbach, COO at Illumiti, addresses the need for an expert to identify the right priorities for your business and determine the most effective outcomes.