This Article was published in Harvard Business Review.
Every big company now manages a proliferation of sites, apps, and technology systems for interacting with buyers and managing everything in the business, from customers and clients to inventory and products. These systems are spitting out data continuously. But even after multiple generations of investments and billions of dollars of digital transformations, organizations struggle to use that data to improve customer service, reduce costs, and speed the core processes that provide competitive advantage.
AI was supposed to help with that. But as an executive at a major life insurance company recently told me (Seth), “Every one of our competitors and most of the organizations of our size in other industries have spent at least a few million dollars on failed AI initiatives.” Why?
My 20 years of experience working with companies on their information technology have shown me the reason: because promises of AI vendors don’t pay off unless a company’s data systems are properly prepared for AI. Data is locked in silos, inaccessible, poorly structured, and most importantly, not organized in such a way as to be used as the fuel that makes AI work. Instead, to reap the benefits of AI, companies need to create something called an ontology, a comprehensive characterization of the architecture of all of its data.
You may have read advice that you should start small with AI initiatives. (I suggested that myself a few years back.) And it’s true — the “AI Lite” approach can generate some quick wins. But as AI initiatives inevitably multiply throughout the organization, the limits of scattered experiments become more glaring. When you feed such AI programs with different types of (sometimes incompatible) data sources, the result will entangle you in complexity. Soon you’ll have a slew of one-off AI pilots connected to your existing data systems in a way that fails to deliver broader, more strategic benefits for your business.
AI is now far enough along that a more cohesive approach is needed — a key that brings together all of your company’s data. That’s where the ontology comes in.
An ontology is a consistent representation of data and data relationships within your business, a model of all the elements that go into and connect your various information systems: the products and services, solutions and processes, organizational structures, protocols, customer characteristics, manufacturing methods, knowledge, content, and data of all types. It is the master knowledge scaffolding of the organization. Without a consistent, thoughtful approach to developing, applying, and evolving an ontology, AI systems can only develop in a piecemeal, fragmented way — they will lack the underpinning that would allow them to be smart enough to make an impact. The ontology is at the heart of the information design of the AI-powered enterprise, an investment that will continue to pay off as AI becomes more pervasive.
Building an ontology at Applied Materials
Let’s look at a B2B service firm, Applied Materials, and how they developed an ontology that showcases these benefits. (I advised them on this project.)
Applied Materials works with semiconductor manufacturers to fix problems that slow or halt production at semiconductor plants — problems that can cost millions of dollars a day until they’re remedied. Because until recently the knowledge needed to keep a plant running was distributed among 14 different systems within Applied Materials, technicians spent up to 40% of their time searching for answers. Every plant is unique, so finding the right answer for a particular plant’s problem is both essential and challenging. Techs tended to hedge their bets by stocking their service vehicles with a variety of costly components, tying up tens of millions of dollars in inventory.
The techs needed a consistent, efficient experience. But to build it, Applied Materials needed a way to organize the diverse sources of information available to the techs and a way to integrate them into a single interface.
The ontology we created for the company included the all the multiple vocabularies, relationships, and hierarchies in all those systems the techs used. It defined relationships for the short names one system used to refer to a part and the stock number another system used to refer to the same part. We parsed and classified troubleshooting documents with “text analytics,” a method that learns from a model document, then extracts information from similar documents, and makes all the knowledge accessible with a common language. When we were done we had created a common language with a master set of relationships that connected the information in the company’s customer management systems, service ticket tracking systems, databases of solutions, parts catalogues, and all the other systems.
Then, once we had created the ontology, we needed to actually apply it to all the underlying data and connect it to the techs’ experience and make it accessible from a common interface. Once everything was tagged, Applied Materials incorporated the ontology in multiple systems and processes, applied it to existing documents, incorporated it into workflows for new documents and solutions, and connected it to ERP and digital asset management systems. This enabled us to create the new system we had dreamed of that empowered field techs to get exactly the information they needed, efficiently, from whatever sources were most appropriate to the task at hand. The logical groups of content — organized in ways that aligned with their way of thinking about the problems they were solving, their “mental models” — helped them locate exactly the information that would be most useful in a given context, like troubleshooting guides.
The resulting system reduced by half the time technicians spent searching for information. Applied Materials estimated that value of that savings at tens of millions of dollars per year. It even enabled technicians to reduce their component part inventories. AI was a part of the solution — but it depended on the underlying ontology to get appropriate access to the data it needed.
How to build an ontology
As you might imagine, creating an ontology that will make sense of all your company’s data isn’t an easy undertaking. Based on the many companies I’ve walked through the process, here are the key steps:
- Identify data pain points. Audit where information problems and bottlenecks are impairing the function of the business, like the Applied Materials techs’ frustrating solution searches. Look for root causes that are generating multiple problems. This helps people understand how solving the bigger data architecture problem can generate widespread benefits in the enterprise.
- Generate solutions based on root causes. Start to imagine what a potential solution could look like — such as the more efficient search system Applied Materials so sorely needed. Begin with the tasks that will have the biggest impact on the business if made more efficient.
- Understand use cases. Consider who will benefit from each solution—customer service staff, product developers, or maybe customers on an e-commerce site?—and exactly what tasks the solution will help them to perform more efficiently. Develop a model for what the individual must do to achieve their desired outcome, then validate that by testing it out with actual workers doing their jobs. Learn how they describe the ideal answer, then match up how they describe it with the ways that other workers in other roles describe the same, or related, types of problems.
- Set the ontology’s organizing principles. This is the key to the ontology. With the knowledge about how people are using the information, you can begin to architect the details of how to organize and categorize the data you have to make it part of the solutions you are creating. For example, at Applied Materials, master concepts had names like “Account,” “User,” “Business Unit,” and “Solution” that matched up to a variety of terms within the company’s legacy systems — and to the mental models that the techs had for what was going on any part of the plant.
Once you’ve created an ontology this way (and a system to maintain it), the benefits multiply. It becomes an essential part of not only the solution to today’s information problem, but to the next problem that arises, and the next. Keep in mind that the ontology is a continuously evolving entity — as products, services, markets, competitors and customer needs change, an intentional process for changing the ontology will keep it fresh and relevant.
It’s increasingly clear that AI is going to be solving many of those problems in the future, whether that’s by means of a customer service chatbot, a system that surfaces signals about business efficiencies and breakdowns, or any of a thousand other applications. The ontology, as a representation of what matters within the company and makes it unique, is what unifies those solutions and makes them more than just a quick fix that will just as quickly become obsolete. If you suspect that AI is the future of business — a conclusion I’m certain of — then creating an ontology is an essential investment to prepare your enterprise to realize the benefits of that future. It’s a concept that, managed and applied appropriately, makes the difference between the promise of AI and delivering sustainably on that promise.