This site is not optimized for Internet Explorer 9 and lower. Please choose another browser or upgrade your existing browser in order get the best experience of this website.

The Danger of Human-Based Knowledge Graphs

The Danger of Human-Based Knowledge Graphs

Imagine being asked to collect and maintain vast quantities of data, even though your title couldn’t be any further from “engineer” or “data scientist.” Having the responsibility of overseeing both supply chain and activity and internal processes to understand why product isn’t going out the door fast enough. Trying to strategize on next quarter’s objectives to improve the customer experience and getting a different story from each department—plus a lot of finger-pointing.

It’s the taxing reality for today’s knowledge workers. They’re asked to make sense of impossible quantities of data and solve logistical problems that no one person can fully understand.

The challenges for those who “think for a living” are compounded by unexpected transitions in the way (and where) we work, the sheer number of tools available and forced upon them, rapidly-changing technology, and the sheer diversity of their work:

  • They often work from home: In 2021, Gartner predicted that 51% of all knowledge workers would be working remotely, up from 27% in 2019. Without a common physical space in which to discuss data, knowledge workers must either conform to existing conversational tools—think email or Slack—or internal knowledge bases like Confluence, to share their insights and hope others can work from them.
  • They have varied titles and even more varied TODOs: When the concept of knowledge workers originated back in the 1950s, its definition was fairly limited to technologists, engineers, designers, editors, and academics. But with rapid changes in technology that gives more employees access to data, and with the pace of business demanding more change and quicker, knowledge workers now include marketers, developers, salespeople, IT staff, security analysts, and much more.
    Modern, technology-driven organizations are now staffed almost entirely by those who do knowledge work, which means there’s no “one size fits all” solution to help them gather and share knowledge.
  • They struggle with the tools available to them: A 2019 study from 8×8 found that 57 percent of employees have difficulty finding the right information to do their jobs, which prevents them from understanding data and creating knowledge at the speed their organization demands. 49 percent of them spend between 30 minutes and two hours looking for the information they need for ongoing knowledge work.
    In 2021, Okta, an enterprise identity and authentication platform found that large organizations often deployed more than 100 applications for their employees.

When organizations ask knowledge workers to operate under these conditions, they fall into a dangerous trap. When they do find the information they need and use the tools available to make net-new insights about the business, their unique knowledge—the very core of their job—gets trapped inside their heads or on notes scattered around their desk or their hard drive. That’s what we call human-based knowledge graphs.

While they may not be actively harmful to your organization, they certainly restrict you from flexing the true skills of your knowledge workers and taking the utmost advantage of the data you already have.

How people tend toward human-based knowledge graphs

In the face of major headwinds, knowledge workers narrow their focus and “stay in their lane.” It’s like Maslow’s hierarchy of needs, but for meeting the needs of their particular department.

To improve their organization’s customer experience, a knowledge worker might drill into sentiment analysis on transcripts with customer service representatives or build networks of customer contacts to understand who purchases their product versus who actually uses it.

The first problem is that they’re focused only on their immediate business need, not exploring potentially new knowledge. And if they do uncover an insight that could be useful to help the design and front-end engineering teams improve the UX, or for marketing to more appropriately phrase a product’s feature set, they’re unlikely to recognize its value, much less know how to properly share it.

What drives this tendency?

First, is the inconsistency in how organizations talk about data. Each department looks at the same problems with a different vocabulary based on their most immediate needs. To make and share cross-departmental knowledge, the analyst from the example above needs to understand how a UX designer describes their work, how a customer experience specialist helps navigate customers through the platform, and manually create a bridge between them. The difference between a final product and the nuts-and-bolts or even processes makes it possible.

Second, there’s a distinct lack of knowledge-sharing tools. Organizations can invest in knowledge base platforms or internal wikis that anyone can edit and supplement, but they’re disconnected from the data itself. Knowledge workers need to translate their insights into a common language, if there is one, and provide the breadcrumbs in the form of SQL queries to help someone else trace their steps.

And third, there’s the pace of modern business. Customers have extraordinary demands, and every process seems to happen just in time, which means knowledge workers are continually moving into the next project. There is no prioritization on analyzing and surfacing what they’ve just learned. With the bit of time knowledge workers might have, any technical or cultural hiccups tend to put sharing insights on the back burner.

Despite their best intentions, organizations are actively training their knowledge workers to avoid asking the right questions because they don’t have the time or energy to put up the necessary resistance to push through. That’s why most organizations only use 10% of their data—knowledge workers have a subset of data they’re comfortable with and rely on again and again, to the detriment of the organization’s collective knowledge.

As knowledge workers investigate potential insights, they turn inward, piecing together knowledge in their own heads rather than in the open.

How technology leads to human-based knowledge graph

People, processes, and organizations aren’t entirely responsible for the human-based knowledge graphs that secretly populate your organization.

The biggest challenge for traditional data storage technology is that modern organizations are extraordinarily complex machines. They have countless people, parts, products, apps, and third-party relationships. Stuffing those components and their relationships into tables, rows, and columns is essentially an impossible task. Who owns the schema? Do you have a consensus about what to capture and call it? Without that, organizations fall back to data silos full of duplicated or outdated information.

When the technology doesn’t invite difficult, cross-departmental questions, it creates what some call the McNamara fallacy, the instinct to make decisions based solely on what can be easily measured and ignore everything else—or pretending it doesn’t exist.

Technology like data lakes, promising a single platform to query and understand all an organization’s data, do help. Same for machine learning-based tools for deriving insights or low/no-code platforms to help “citizen developers” build integrations without developer help. But for all the initial advantages, this technology helps knowledge workers answer what they already know how to measure, not the unknowns they could have been exploring otherwise.

How collaborative knowledge graphs can help

A knowledge graph tells you the people, places, and things that matter. By breaking knowledge graphs out of an employee’s head and translating them into platforms, organizations can help their knowledge workers ask relevant-but-difficult questions and share their insights freely.

A knowledge graph unifies the information across an organization, adds real-world context and semantics, and makes it accessible to people, applications, and ML-based analytical tools. Unlike SQL databases, with their rigid schemas, knowledge graphs are based on graph databases, which store information as nodes. The relationships between nodes are defined by edges, which have various properties based on the type of relationship. There are no limits on what goes into a knowledge graph or how people—or AI—define those relationships.

Because knowledge graphs aren’t defined by a schema first and then filled up with data, organizations can build a consensus around their data language and adapt their graph accordingly, creating new edges or updating properties as needed. Knowledge workers aren’t stuck in the translation, trying to understand what different people mean when they say “customer.”

And when it comes to inputting that data, a knowledge graph like GraphGrid CDP works directly with natural language processing (NLP) technology to automatically ingest, parse, and analyze new data as it’s created inside or outside of your organization, not as your data analysts have the time and willingness to clean and upload it.

Once you have your organization’s data in a connected, collaborative knowledge graph, it becomes an open book for even the knowledge workers with the least technical skills and no understanding of database queries. Anyone can explore the web-like “map” of nodes and edges, revealing the contextual connections as they go, to uncover the kinds of insights they would have been too afraid to ask before.

And for unlocking even more unknowns, knowledge graphs are also an open book for AI/ML tools for generating knowledge based on useful problems that are too difficult or time-consuming for knowledge workers to worry about. These systems can operate on existing data or trigger on change data capture, pushing not only the deltas but also automated insights, to your knowledge workers.

By extracting individual knowledge into one shared knowledge graph, and enabling more people to contribute to the ongoing effort, you immediately break down the data barriers that have kept your organization from utilizing the 90% of your data, especially unstructured data, that you’re paying to store but getting no value from. Even better, a collaborative knowledge graph creates a more complete picture of knowledge due to the convergence of many diverse opinions, which has been proven numerous times to drive business value and make for happier organizations.

Time to break free of human-based knowledge graphs

The quickest way to start extracting knowledge from your employees and freeing them to ask difficult questions of your data is GraphGrid CDP, an extensible and developer-friendly suite of connected data capabilities.

You can download it entirely free of charge to start pulling in your organization’s data and building relationships. Whether you choose the Enterprise or Ecommerce edition, you can deploy CDP clusters in production with up to 8 CPU cores, 32 GiB memory, and a single GPU. For options to run in the cloud, connect with our enterprise support team.