Читать книгу The AI-Powered Enterprise - Seth Earley - Страница 9

CHAPTER 2

BUILDING THE ONTOLOGY

It costs over a billion dollars to build a “fab”—a semiconductor fabrication plant. At a price like that, it had better be up and running every possible hour of the day and night.

That’s the problem that Applied Materials was struggling to manage. The company bills itself as “the leader in material engineering solutions used to produce virtually every new chip and advanced display in the world.”¹ Its field service technicians are tasked with getting fabs running after problems have taken them offline. A down fab can cost its owner millions of dollars per day in lost business. If Applied Materials can’t fix the problem quickly, it can end up on the hook for large penalties for failing to deliver on its service-level agreements—not to mention the damage to its reputation. It’s a tough job, because semiconductor manufacturing processes are mind-bogglingly complex.

The know-how to keep a semiconductor fab running was spread throughout so many systems and processes within Applied Materials that up to 40% of its field service technicians’ time was spent searching for the information they needed. Each plant was unique, so technicians needed to be able to locate the exact configuration of the equipment and procedures for any plant they were working in. The technicians work in dust-free, ultraclean environments and have elaborate and time-consuming processes for getting in and out of the plants. Some fabs even prohibit laptops or tablets, so technicians had to equip themselves with all the information they would need to solve any suspected problem before entering the plant.

Techs in this environment hedged their bets. They stocked their service vehicles with a wide variety of costly components, since not having the right part ready would lead to expensive additional delays. With 3,000 technicians in the field, this practice tied up tens of millions of dollars of inventory. Technicians became frustrated with attempting to locate service information across 14 different systems. Adding complexity, Applied Materials technicians working for one customer might have to maintain trade secrets for that customer, making it impossible for them to share all their information with other technicians.

Because this challenge threatened Applied Materials’ brand and reputation, it’s no surprise that the company tried to solve the problem on three separate occasions over a five-year period. All three attempts failed.

When Applied Materials brought my company in to help them, it became clear that the missing piece of the puzzle was how to organize diverse sources of information and unify the field technician experience. The key was finding ways to remove friction from the process of accessing exactly the information that was needed to solve the problem at hand. The magnitude of the problem seemed overwhelming because the company had so much information in so many places

We discussed the problem with one of the company’s senior finance executives and outlined a solution, including an ontology and its subsidiary classification systems, known as taxonomies. The ontology would enable an AI-powered semantic search approach to organize the information for retrieval in the context that a technician would need when servicing a fabrication plant. The finance executive was dubious. He asked, “Why do we need taxonomies? Why don’t we just get Google?”

I responded to his question with one of my own: “Do you have a chart of accounts for your finance organization?” Naturally, he did. So I asked, “Why don’t you get rid of your chart of accounts and just get Google?” He laughed at such a preposterous idea. “Well,” I responded, “what we want to build is like a chart of accounts for field service knowledge. It organizes information far better than a random search ever could. It will help the service people locate exactly what they need when they need it.”

Consider the parallels for a moment. A chart of accounts organizes financial information for the accounting department and helps financial managers identify patterns in the numbers, make predictions about the future, and decide how to allocate resources. It provides the organizing principles to eliminate noise (such as irrelevant trends, anomalies, onetime events, or variations that are immaterial) and identify the important signals (trends in leading indicators like leads, success of promotions, effectiveness of advertising, and the impact of pricing changes). By providing a structured way to interpret corporate data, an ontology does for knowledge what the chart of accounts does for financial information.

We helped Applied Materials create the required ontology. Once the company had identified the multiple vocabularies, hierarchies, and relationships that comprised the ontology, the next step was to integrate it with the organization’s technologies and apply it to the data. Various elements of the techs’ experience needed to be designed to reflect the organizing principles of the ontology. Information about parts had to be tagged consistently: a part could not be called by a short name in one system and a stock number in another. Similarly, documents for troubleshooting had to be reclassified using a form of AI called “text analytics.” Text analytics starts with example documents that have been tagged with information from the ontology, and then automatically applies the same tags to documents containing similar text.

It took a lot of work to implement the ontology in multiple systems and processes; incorporate it into workflows for content publication and approval; connect it to enterprise resource planning and digital asset management systems for visual part identification; and incorporate dozens of content libraries by ingesting them, automatically classifying content, and manually mapping relationships.

But once this work was complete, the architecture of the Applied Materials solution allowed field technicians to get the information they needed when they needed it. It helped them locate exactly what would be most useful by building logical groupings of content—surfacing the troubleshooting guides according to the process the tech would be troubleshooting, for example. The ontology enabled this by creating hierarchies—lists of concepts that are grouped logically—so that technicians could scan groupings and infer what they needed just by scanning the list. These hierarchies also allowed ambiguous queries to be clarified by asking questions about the parts and their applications. When they searched, the search results were grouped in a way that made sense to the technician—that fit their “mental model” of the problem and solution. These changes enabled the computer to give the technicians what they were seeking using the terms they were likely to be thinking about, rather than forcing them to root through masses of information with terms they might not recognize, organized in incompatible ways more accessible to computers than to humans. The result was a system that reduced the time that field technicians spent searching for information by half. The company estimated their savings at tens of millions of dollars per year. We enabled technicians to reduce their component and replacement part inventories and speed turnaround time for down fabrication plants.

And Applied Materials was able to live up to its reputation as a global leader in chip manufacturing, an essential element for its future business success.

WHY ONTOLOGIES MATTER

With the speed and effectiveness of the company at stake, building an ontology is not just an IT project. It is one that should matter to every CEO, CMO, and senior manager inside your company. Once you create the framework for the ontology, you can get more from your current investments in technology and apply emerging artificial intelligence techniques to drive your business. The ontology is the tool that teaches intelligent machines how your business runs. Without it, neither your systems nor your employees can truly understand how to access and organize the lifeblood of the business—the knowledge and information that provides value for your customers and the marketplace.

Ontologies are the secret weapon that will bring you victory in the battle for customers by transforming your company into an AI-powered enterprise. AI capabilities, supported by an ontology, will allow employees and the systems they use to function faster than ever before. It becomes a supercharger for your business. It helps you get products and services to market faster, serve customers more efficiently, and take advantage of quickly emerging opportunities in the marketplace. With the streamlined information flows that the ontology supports, both automated systems and humans can make better decisions.

Your ontology has the potential to accelerate your enterprise whether you work in retail, finance, health care, government, or any other sector. Once ontology-powered AI is in place, you can create:

•apps that suggest exactly the right product for each customer, based on history, context, inventory, and even the weather;

•tools that facilitate team meetings by suggesting the best solutions to your toughest problems;

•audience insights based not on superficial attributes like age but on people’s secret motivations—along with product improvements that match those motivations;

•sales improvements that prioritize the leads that are most likely to generate more profit and make this determination more quickly than any other method now available;

•systems that predict when equipment will fail and proactively order maintenance before disaster strikes;

•virtual assistants that provide new capabilities and levels of service at a lower cost than previously possible; and

•bots that will help engineers solve challenging design and manufacturing problems by embodying the knowledge and expertise currently in the heads of your own experts—much as Applied Materials did.

Ontologies speed the information metabolism of the enterprise, forming the foundation for improved search, information management, and digital asset retrieval. They support mechanisms that improve communication among systems by acting as the Rosetta Stone of system integration.

Think of an ontology as a “knowledge chart of accounts” for marketing, engineering, finance, human resources, operations, and sales. Ontologies form the source of features for predictive analytics programs to improve their performance. They are the source of labels for navigational elements on an ecommerce website. They are the foundation for improved customer service since they contain knowledge of customers, problems, processes, and solutions. They provide improved business insights and intelligence by allowing for consistent analysis of products, revenue, costs, efficiencies, and metrics across the enterprise. They are the source of rights-management attributes and can help manage risks, exposures, and compliance.

Since the virtual world is entirely composed of data, victory will go to the organizations that can best control, manipulate, and exploit that data to attract customers and provide what those customers need, sometimes before they know they need it. Companies that do this will gain an edge in the AI future, while other companies will suffer competitive losses. Organizations cannot gain this edge and do so successfully, cost-effectively, and at scale without investing in the foundation of correctly designed and applied ontologies.

Why is it important to have a framework for organizing information? It can provide a competitive advantage based on how you envision your business, and you can differentiate your company by anticipating what your customers will need and by doing some of the heavy lifting for them. If your company is dependent on an individual for facilitating customer interactions, developing an effective ontology can buffer the impact if the individual leaves the company, or it can help you scale up to reach more customers.

In the rest of this chapter, I’ll show you more about why ontologies matter, what they include, and how to build them.

UNDERSTANDING ONTOLOGIES

The term ontology refers to a domain of knowledge and the relationships among different concepts. The idea originally comes from philosophy, where ontology is the study of the nature of relations and being.

An ontology allows people and systems to understand relationships between concepts, just as a reference librarian can guide someone looking for information at a library. Someone seeking information may not know that valuable information about a subject can be found in a particular section of the library, or they may not know the best place to locate information that is less commonly available. This is similar to a book index, in which the “see also” entries guide the reader to another location that they might not have otherwise found or looked at.

Ontologies are built up from taxonomies. A taxonomy is a clearly defined hierarchical structure for categorizing information. Most people are familiar with the taxonomic classification system for animals, which includes invertebrates and vertebrates, and within the vertebrate category, birds, fish, reptiles, amphibians, and mammals. Similarly, the Dewey Decimal System is a taxonomy for categorizing books.

Taxonomies and ontologies have different purposes and uses. On a website for home products, a taxonomy could classify different departments such as lumber, tools, lighting, and appliances. Within each category, there could be subcategories such as hand tools and power tools, or refrigerators and stoves. In many cases, a taxonomy like this is sufficient for prospective customers to locate the items they need. However, a different level of sophistication can be achieved by overlaying this information with an ontology that adds richer information on products. This step would be required to respond to answers to questions such as “What are you trying to do?” If the answer is “Build a deck,” then the store could present a suggested list that included supporting posts, decking lumber, deck screws, and a circular saw. Ontologies are a key ingredient for personalization and proactive marketing.

Ontologies Power Meaningful AI Capabilities

Ontologies begin as a holistic understanding of the language of the business and the customer, and are then designed into processes, applications, navigational structures, content, data models, and the relationships between concepts. They contain language variations, alternative spellings, translations, acronyms, and technical terms. They can describe “is-ness” and “about-ness”—this is a contract, it is about a services engagement, it is also about this vendor, for example. Ontologies can also support advanced capabilities to drive intelligent virtual assistants (bots). They can form the basis for inference engines—mechanisms to essentially answer a question that has not been preprogrammed into the bot. Bots powered by ontologies are faster to deploy, more scalable, and more cost-effective. Every aspect of business requires contextualized knowledge. The role of AI is to use the ontology to assist with this contextualization.

Here’s an example scenario. Imagine a bot that answers questions about support problems.² For this to work, the bot needs to understand “intent”—the thing that the customer is trying to achieve. According to P.V. Kannan’s AI book The Age of Intent, intent is the fundamental concept that drives all intelligent virtual agents. As Kannan defines it, “Intent is a determination of what a customer wants from an interaction with a company.”³ Once an AI determines that, it can supply an appropriate answer.

For example, a customer may not be able to connect a printer to the network. The troubleshooting bot can determine the customer’s intent by first extracting the elements of the problem from the customer statement (called the utterance). “I cannot connect my printer to the network” contains the entity “printer” and “network” and the symptom “cannot connect.” These elements are captured in the ontology along with synonyms and variations such as “unable to connect” or “not connecting.” The intent, which the bot determines from this information, is “fix printer connection problem.” Having determined the intent, the bot can walk the user through steps to solve the problem.

There is also a relationship between the symptom and a solution. The solution may require more information, which the bot can request from the customer. If the customer is logged in, the bot can look up information from the list of equipment they own. With this knowledge, the system can better identify and present the appropriate troubleshooting steps.

Each of these elements and the relationships that associate them form the knowledge graph—that is, a knowledge structure that contains related elements. You may be familiar with graphs of relationships from Facebook, where you may find new friends via different connections and follow those connections to another group of acquaintances based on factors like school, group membership, or interests. The movie database IMDb shows a similar set of graph relationships—you can choose a movie and look up the actors and directors to see which other movies they were in and which other actors they costarred with (useful for the game Six Degrees of Kevin Bacon⁴). The ontology becomes a knowledge graph for your organization, with the ability to answer a limitless number of questions over time.

How Ontologies and Taxonomies Worked at Applied Materials

In the case of Applied Materials, the taxonomies described every aspect of the chip manufacturing process, including these concepts:

Account	Geography	Partner	Solution
Application	Code	Platform	Status
Assembly	Security	Process	Subject
User	IP	Equipment	Technology
User Interest	Owner	Product	Units of Measure
Division	Language	Published To	Substrate
Document Type	Business Unit	Region	Sub-assembly
Plant	Configuration	Severity

(Representative list of vocabularies. Concepts and names changed or omitted for confidentiality.)

More than 30 taxonomies described Applied Materials’ world, and each taxonomy had a relationship to others—for example, Platform to Process, Assembly to Product, Partner to Region, Solution to Plant, or Severity to Status. These knowledge relationships could be mapped across content processes, allowing automated “reference librarians”—AI—to suggest resources and answers. These embedded relationships enriched the ontology to create a conceptual representation of a domain of knowledge. Taken together, all these taxonomies and all of their tens of thousands of terms and hundreds of thousands of relationships represent the semiconductor fabrication world: the knowledge domain of semiconductor fabrication equipment and methodologies.

These various organizing systems and vocabularies allowed all 14 different knowledge, content, and data systems to be unified under a semantic layer that translated inconsistent information structures into a common framework. This information architecture (or knowledge architecture) also guided the development of the technicians’ experience: in this case, a search interface that let technicians navigate and retrieve their desired content using their mental model of how they thought about the problem.

This allowed many different types of users with different problems to locate what they needed in the context of their problems. Taxonomies functioned as navigational filters and provided “see also” constructs to guide technicians to their answer. They consolidated multiple information sources from disparate systems using terminology that was mapped through the ontology.

But the ontology did more than organize content and make queries more effective. It allowed the business to use AI approaches to classify content, identify security and IP issues, and automate some aspects of relationships among parts. The same ontology allows for analysis of anomalies, powers predictive maintenance, and identifies reliability issues and field usage patterns. The data it generates feeds upstream design and manufacturing processes to further improve products and innovate in semiconductor manufacturing—and to sustain Applied Materials’ leadership in that space.

To Be a Source of Truth, Ontologies Must Be Comprehensive and Architectural

The ontology becomes a reference point for the organization that provides consistent naming, structures, and standards for applications and new technologies. It becomes a source of truth.

The ontology represents knowledge of the information structures and processes that drive information flows throughout the organization. The ontology is representative of products, services, processes, problems, tasks, intents, interests, user types, roles, content, data types, reference architectures, navigational structures, security classifications, applications, and every other entity, whether virtual or physical, in the enterprise. Any entity that someone interacts with can be part of the ontology.

But it’s not just the elements of the data that count. The ontology reflects the architecture of that data. Data fundamentally has an architecture. It has to. Financial systems have charts of accounts. They have to. Algorithms can do a great deal with messy or missing data, but they must have a reference point containing the labels and information as a basis to find patterns. Pattern matching is inherently about classification, and the ontology forms the core structure for classifications of all sorts. Data dictionaries are part of the ontology; product catalogs are part of the ontology; financial charts of accounts are part of the ontology. The ontology represents the knowledge domain of the enterprise.

Before we can apply AI, we need two things: a core understanding of the business problem we are attempting to solve and a mechanism for identifying the important signals contained in the data. The ontology contains an overall set of labels for important business concepts—product names and descriptors. Marketing, for example, must track campaigns with categories for types of promotions, events, audiences, targets, personas, segments, assets, media, channels, and so on. Engineering uses classifications for techniques, materials, designs, problems, and specifications. Ecommerce websites allow customers to shop according to the classifications that are meaningful for them, such as brand, product type, size, color, and style.

If the ontology includes all of these different types of structures throughout the enterprise, then how can it be practical? The answer is that ontologies provide a consistent reference point to capture knowledge relationships. We make an ontology practical by building it piece by piece for particular purposes and to solve specific problems. The value of the ontology continues to increase as it is further refined and applied to organizational processes. Over time the ontology matures and is applied to solve customer problems and improve information flows.

Most organizations have costly and hard-to-manage problems with data quality. Because of this, technology integrations are brittle, making it slow to deploy changes to customer-facing functionality. This friction inexorably slows down the information metabolism and reduces the speed of product, service, and value creation. The ontology has the potential to vastly reduce these challenges.

The key to building a practical ontology is to focus on application and usage. Ontologies require consideration of focused problems and specific contexts. They become the North Star for new applications and systems, for new technology deployments, and for new products and services. Ontologies provide a guide point and are aspirational—they are never complete. If an ontology is not developed within an application-centric framework, it will become an academic exercise—a science project—with no end and little value.

ONLY A DELIBERATE APPROACH WILL WORK

Some AI experts actually frown on the idea of explicitly and carefully building an ontology to solve AI-related problems or power AI technologies. They imagine that the answer lies strictly in the data, and that statistical algorithms can analyze that data and automatically create a structure from it. But as you can imagine from what I’ve described so far, this approach is inadequate. A machine cannot read a random collection of data and understand the goals of the business. Though AI can help identify patterns, only a comprehensive human-driven review of the data, systems, and processes can create the Rosetta Stone that the whole business will run on.

That doesn’t mean you must start from scratch. Organizing principles and architectures are already embodied across multiple systems and embedded throughout the organization’s processes. In practice, these architectures tend to be fragmented, lacking consistent, standard ways of managing different levels of detail. This effectively makes them “accidental” ontologies. Accidental ontologies result from changes that are not governed or managed, business units that do not collaborate, vendors with inconsistent architectures, and developers who create technologies without reference standards. They can also arise from integration of acquisitions, consolidation of data sources, architecture layers evolving at different rates of change, and other changes in day-to-day operations. Frequently, they are haphazard and inconsistent because there is little awareness of how they should be integrated, cross-mapped, unified, or managed. They present many varied views of the truth, in contrast to the unified view represented by a deliberately created ontology.

How do these incompatible views develop? As I described in chapter 1, different parts of the organization have varying process clock speeds and rates of change. Social media marketing requires fast turnaround and fast responses to customer issues. The social media technology also changes rapidly within the already fast-evolving digital marketing technology ecosystem. Because the functionality of those systems will constantly evolve, the underlying architectures, organizing principles, and models will never be completely aligned.

While they may try, IT staffs rarely have the resources or skills to solve these problems in a systematic way, by applying end-to-end principles combined with metrics-driven feedback loops in ways that are appropriate to the problem. A carefully developed comprehensive ontology can help. If the social media marketing technology needs to interface with an ecommerce system, which will have slower-changing components, the ontology will provide a translation layer between faster-and slower-moving layers. The ecommerce system may sit on top of an enterprise resource planning (ERP) system that changes at an even slower rate and, once again, the ontology can act as a shock layer between those systems.

Ontologies Vary from Industry to Industry and from Business to Business

You could imagine a world in which a single organizing principle would allow all data structures to interoperate. While there are many standards to improve interoperability, a perfectly interoperable world does not exist, because businesses and their processes are diverse. The concepts and processes that comprise the world of a commercial insurance company, for example, are fundamentally different from those of a life sciences company. Insurance is about risks and regions, types of businesses, exposure, and so on. A life sciences company deals with diseases, treatments, indications, generic compounds, drug brands, 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 large buckets, a result that reveals a group of “lumpers”—people who like to combine things. At other times they are split into numerous categories—a characteristic of “splitters,” who like to separate things. You need to repeat this exercise with multiple different groups to get a sense of the elements and classifications they consider to be important. This process can inform the mental model of the user and then lead to the development of organizing principles that can be applied to knowledge bases and document repositories.

Table 2-1: Steps in the User- and Problem-Centric Method of Creating an Ontology

Process Step	Answer the Following	Examples
1.Observe and gather data (pain) points	What are the specific problems and challenges that users are identifying?	“We can’t locate information about policies for specialty coverage.” “We need to look in multiple systems to find prior experience data when underwriting new policies in high risk areas.” “Different terminology is used in different systems, which makes queries difficult.”
2.Summarize into themes	What are the common elements to observations? How can symptoms and pains be classified according to overarching themes?	Inability to locate policy and underwriting information using common terminology
3.Translate themes into conceptual solutions	Wouldn’t it be great if we could . . . ?	Wouldn’t it be great if we could access all policy and prior experience data across multiple systems using a single search query and return consistent results?
4.Develop scenerios that comprise solutions	What would a day in the life of a user look like if this solution were in place?	At a high level, describe how underwriters go about their work in writing policies for specialty and high-risk clients. Describe each potential situation and how they would go about their work.
5.Identify audiences whom the scenarios affect	Who are the users that are impacted?	Risk managers; underwriters; sales personnel
6.Articulate tasks that audiences execute in scenarios	What are the tasks that need to be executed in each scenario?	For a given scenario, articulate tasks (research options, review loss history, locate supporting research, etc.)
7.Build detailed use cases around tasks and audiences	What are the specific steps to accomplish tasks?	For a single task, list the steps to execute (this level of detail is not needed in all cases). Step 1: Log on to claim system. Step 2: Search for history on the coverage type in geography. Step 3: . . .
8.Identify content needed by audiences in specific use cases	What content and information is needed at each step in the process?	Claims data; policy information; underwriting standards; actuarial tables; fraud reports; etc.
9.Develop organizing principles for data and content	Arrange the things audiences need according to process, task, or other organizing principle	Begin with “is-ness.” What is the nature of the information? Then determine “about-ness,” the additional characteristics of the information. How would you tell apart 1,000 documents of that type?

This is not the only data- and content-centric approach. Here are some others:

•Start with a body of content and ask people to come up with labels.

•Come up with labels and ask people to group them within existing categories.

•Ask people to group labels into new categories.

•Sample all of the existing terminology lists and have people reconcile them.

•Hand out sample content and have people classify it with existing labels.

Each of these approaches informs the mental model of the user and helps create language and terminology that can label and tag products, services, and reference content for easier access.

The challenge with data- and content-centric approaches is that they lose the understanding of the user’s goals. The challenge with a user- and problem-centric approach is to prevent it from becoming a laundry list of user challenges. A combination of approaches is often the best way to crack the problem.

Checking the Box versus Validating the Work

How do you know when an ontology is sufficient to be useful? Here’s a story that may illustrate that question.

The head of knowledge and search at a large global services firm was having challenges with information management across the enterprise. The company’s program for searching for answers to employees’ questions was held up as a model of exemplary practices at conferences; numerous attendees would crowd around the presenter after her talk and ask questions about how her team did it. Each week, the group reported positive results and metrics showed steady improvement in measures such as improved search accuracy and precision of results. But as a head of one of the business units confided to us, “People still can’t find what they need.” The company wanted to understand why, so they hired my consulting firm.

At first, it appeared that the company had already achieved a high level of success. My consultants and I listened to their approach, and our first thought was, “They really know best practices and understand how content, knowledge, taxonomies, and ontologies work. They are applying them and following all the steps.”

But our main contact at the company suggested that we dig deeper. “Go to the end users and look at what they are trying to do,” they advised. “Evaluate their taxonomies and ontology and how they got there.”

The rest of the week was quite revealing indeed. Even though the steps that the global services firm followed were valid, problems emerged. Use cases were vague: “Users must be able to access the information they need when in the field.” That type of use case is not testable. What information? For what purpose? From where? None of the details were specified.

When it came time to build the taxonomies and ontology, a manager sent out a spreadsheet that people added terms to, and then the head of the group added his own terms and deemed the taxonomy complete. There was no validation or testing with actual users or measures of usability. The firm had not followed best practices and heuristics for ontology development. There were too many overly broad terms (such as “documents” and “content”— what is the difference between a document and content?) and too many detailed terms that had insignificant differences (“exemplars” and “examples”). Hierarchies were six or seven levels deep in some parts and one level deep in other areas, making it nearly impossible to establish a mental model of how the information was organized. And there were many other violations of accepted practices (such as large “general,” “miscellaneous,” and “other” categories—which are useless individually and nonsensical when combined).

Ontologies should not be a matter of individual opinion. They should not be deemed complete by business leaders, based only on their judgment or developed in a vacuum. Everything should be testable and measurable. No one at the global services firm tried ingesting information using the system and then measuring how people located the information on an end-to-end, holistic basis.

An even larger mistake in many organizations is a lack of a clear understanding of the customer at a level of detail that truly informs decisions and provides enough of the features that both humans and machine learning algorithms can interpret and act upon. Achieving this level of understanding and insight begins with humans applying consistent, repeatable, testable methodologies, because machines cannot understand human needs without a reference point. What is it about your services, products, and offerings that appeals to your customers? When do customers seek them out and how do they make decisions? What is most important to them and why? What exactly do they need to do from moment to moment when they are interacting with different parts of the organization? That understanding is critical and all too often insufficient, lacking in important detail, or just plain wrong.

AI can be a powerful way to contextualize the customer experience by seamlessly serving up the information, products, services, and solutions they seek, but it cannot make sense of bad data and it cannot substitute for an understanding of the customer. AI cannot make up for your sins of poor information practices and bad customer experiences. Some of the tools can help, but they need a structure, a scaffolding in which to operate and in which to contextualize information. Successful AI programs require that the organization has its data house in order and that it understands what customers and end users need.

The Promised Land: Applying the Ontology

There are thousands of ways to apply an ontology.

There is a sculpture on my desk (the inspiration for the cover image on this book) that represents the infinite ways of applying an ontology while also representing the structures within it. The piece is made of glass of varying types with different refractive characteristics. There is an easily seen cubical structure within it; it is complex but not mysterious. But when light goes through the sculpture, it creates infinite representations of that light. The ontology is the cube. The ways of using the ontology are the light that goes through it. It changes depending on perspective but in predictable ways. It is infinite in its output but made of a finite number of elements.

The ontology is the foundation of language and business terminology and concepts that are important to the organization. It becomes the knowledge scaffolding and reference point for building various applications and powering AI tools. It has to be designed into the downstream systems and be the starting point for any data definitions. For example, it contains the lingua franca and golden record for product information in an ecommerce system. It does not always house the product information, but it holds the categories of products that would also be used in marketing tools, in customer engagement applications, in analytics programs, in internal knowledge and content bases, and so on. It can be used in search to provide conceptually related results that might otherwise come from a reference librarian. Every information system should begin with consistent language, concept relationships, terminology, and organizing principles; the ontology supplies these.

Now you know what an ontology is. What’s it good for? We’ll explore the uses of ontologies in many contexts in the chapters that follow, starting with the way an ontology improves the most fundamental process of any company: delivering an excellent customer experience.

TAKEAWAYS FROM CHAPTER 2

In this chapter, I’ve described what an ontology is, how it’s useful, and how you can create one and put it to use to power your enterprise. These are the main points in this chapter:

•Ontologies help deliver the right information at the right moment, faster, and more accurately, which will give you an edge in the battle for customers.

•An ontology describes all the knowledge and data within your company and the relationships among different concepts.

•The main building blocks of ontologies are taxonomies—hierarchical classifications of various domains of knowledge.

•Ontologies power AI capabilities like chatbots by delivering a core understanding of the business problem and a mechanism for identifying reference signals within the company’s data.

•To be valuable, ontologies must reflect the architecture of the data within a company.

•Creating useful ontologies demands a careful, deliberate approach—you can’t just turn a machine loose on your data; nor can you stitch together “accidental” taxonomies that have developed throughout the business.

•Ontologies vary across industries and are unique for every business.

•One of the best ways to develop an ontology is with a nine-step user- and problem-centric approach that includes identifying problems, collecting them into themes, and developing solution scenarios.

•You can enhance ontology development by adding a data- and content-centric approach—for example, interviewing employees about the various data elements they use and how they use them.

•An ontology isn’t done until it has been tested for validity and with actual user scenarios.

•Once created, an ontology can power a limitless number of AI-driven improvements within the business.