The AI-Powered Enterprise. Seth Earley

mechanisms of action, and biochemical pathways, among other things. In each case, the ontology describes the various concepts and buckets of information along with relationships between those concepts—for example, “risks in a region” or “treatments for a disease.” Taxonomies describe each concept, and the ontology consists of all the taxonomies and all the relationships among them. But even for companies within the same industry selling to the same customers and with similar products and services, there are differences. Their competitive differentiation comes from differences in how they interact with their customers and how they present solutions, communicate, and position their brand in the marketplace. Their ontologies will reflect those differences and embody their competitive advantages.

       BUILDING AND APPLYING THE ONTOLOGY

      Ontologies have to solve specific, meaningful business problems. It takes time and money for organizations to develop the necessary detailed use cases and scenarios with the associated content models and ontology. However, building ontologies using a holistic approach that correctly identifies information flow dependencies can solve many related problems at little additional cost. I will describe two ways to begin building an ontology: a “user- and problem-centric” approach, which focuses on the users and their challenges, and a “data- and content-centric” approach, which focuses on organizing the data. Enterprises have to use both approaches to some degree or another; user challenges deal with information and data, and data has to be organized around a user need or context.

       The User- and Problem-Centric Approach to Creating an Ontology

      The user- and problem-centric approach, focusing on users and their challenges, includes nine steps:

      1.Observe and gather data (pain) points. Many of the world’s greatest thinkers have stated that identifying the problem constitutes most of the work toward finding a solution.⁵ Identification of the main problem establishes the context for the ontology and relates it to any other problems you’re working on. When solving a problem, one gathers observations and data points from multiple perspectives. Problems have symptoms, and grouping those symptoms together and identifying the root cause for that grouping provides the context for the ontology. The symptoms (data points/observations) can come from anywhere, including customer complaints, interviews with people at the front lines, executive interviews, surveys, journey maps, call logs, search logs, working sessions, strategic plans, competitive analyses, quality problems, usability metrics, and heuristic evaluations. Identifying the source of each observation or data point is important so that executives and other stakeholders (especially the owners of a process that may not be functioning optimally) can see the source and the observation or symptom can be justified. This is part of the audit trail of the ontology.

      2.Summarize into themes. Since we don’t solve one issue at a time and multiple issues can have the same cause, you must group and categorize the problems. (Categorization is a major part of ontology and this is the first categorization exercise!) Themes are a step toward diagnosing a problem; finding the root cause of as many problems as possible is the objective of this part of the exercise. The categorization process also helps people in the organization understand how problems and processes are related and how addressing one class of problem will make many others disappear.

      3.Translate themes into conceptual solutions. Developing conceptual solutions by considering all the possibilities gets people thinking creatively and without constraints. A solution can be as obvious as asking, “Wouldn’t it be great if we could . . . ?” and answering the question with the absence of the problem. For example, my problem is that I can’t find things. Wouldn’t it be great if I could find the document I wanted within 30 seconds? But of course, we need more detail than that—what things are we trying to find? During what process? To accomplish what task?

      4.Develop scenarios that comprise solutions. This is getting to the next level of detail. What does the solution look like? What do people need to do? What would a day in the life of a worker look like if this new capability were in place? How exactly would people go about solving their problem or doing their job?

      5.Identify audiences whom the scenarios affect. Sometimes the scenario involves just a few audiences (e.g., customers and marketing), while at other times, it has an effect on every department. When the solution or problem impacts many other groups, that means the value of the new capability extends beyond solving the initial problem. This step also identifies other potential stakeholders, decision-makers, process owners, funding sources, operational bottlenecks, constraints, benefits, and dependent processes.

      6.Articulate tasks that audiences execute in scenarios. This is another layer of granularity to the context and solution scenarios. Now we are at the ground level of detailed tasks that people have to accomplish. As we go deeper, we are uncovering more layers of detail and more nuances.

      7.Build detailed use cases around tasks and audiences. Use cases are the next layer of detail. These are the testable assumptions about what an individual has to do to achieve the outcome described in a step-by-step manner. This level of detail is not always needed and can become painstakingly elaborate. However, after you develop use cases, you can categorize and generalize them so that one type of use case can become a model for dozens of similar ones.

      8.Identify content needed by audiences in specific use cases. We are finally at the level of understanding what people need. Where do they go for answers, information, or inputs? What piece of information do they need? What do they call it? What do others call it?

      9.Develop organizing principles for data and content. Now we can describe a piece of information. Imagine that I hand you a document or fact. What is it? Is it a contract? A policy? A risk profile? A customer record? That is what we call the “is-ness.” The next question you need to ask is, If I had one thousand pieces of that thing, how would I tell them apart? If they are contracts, what kinds of contracts? What piles would I put them in? How many different types of piles could I create? For example, I could classify them by contract type, by region, by customer type, by issue, by topic, and so on. These characteristics are what we call the “about-ness” of the information. Is-ness and about-ness are the metadata descriptors of the content. Each kind of is-ness forms a vocabulary. Each kind of about-ness also forms a vocabulary. Those vocabularies are also organized into hierarchies—taxonomies. When you have created the relationships among taxonomies and described all of the different types of information and ways of describing that information, you have developed your ontology. Table 2-1 summarizes this method.

       The Data- and Content-Centric Approach to Ontologies

      The user- and problem-centric approach to ontologies is more generally applicable, but it doesn’t always create a complete picture. The data- and content-centric approach can be helpful as well.

      Sometimes the ontology problem is presented as a pile of data that needs to be better organized—perhaps a website, an intranet, a knowledge base, or a content or document repository. This approach, while starting with the data, still needs a context, though that context can be quite broad. A starting point for analyzing that context is to gather groups of stakeholders together and provide packages of sticky notes and markers to each person in the room. The objective is to write down, as quickly as possible, everything that they work with on a day-to-day basis. You must be thinking, “Seriously? That would take forever.” This is actually a speed-and-volume exercise. Recall that I started with context—the context could be a department, such as marketing, sales, engineering, or finance. Each of these groups will be able to write down at least 20 or 30 items on sticky notes that represent their information interactions.

      The exercise can be very revealing. Sometimes people stay at too high a level and say things like “documents,” “email,” or “communications.” In that case, we go back and say “Try again”: What kinds of documents? What are the emails about? The goal is to get as granular as possible. Then the group places their sticky notes on a wall of flip-chart pages and tries to group them into logical groupings. Sometimes they end up with very