Traditional process reengineering methods don’t work for enterprises for many of the same reasons that knowledge graph engineering methods don’t work in a business setting. As I detailed in the last article in this series, if we take an outcomes-centric approach, it makes both processes more feasible. There’s also good reason to combine both efforts, and in this article, I’ll get into more details of the how and why.
Keeping pace with all the developments in AI is hard. Stuart Winter-Tear and I make it easier with our new podcast, Unhype AI. Get up to speed with everything that happened last week on Spotify or YouTube.
Processes are best evaluated as systems. Every system can be optimized, but we must understand it well to know what changes will lead to optimization. We must also understand how changes to one system or process will impact upstream and downstream systems. The upfront barriers that enterprises face:
Not every process and its outcome(s) are well understood.
Impacts of process changes are unclear.
Many processes do not create value in the way the business thinks they do.
The goal of knowledge graph engineering is to document what’s known and fill gaps in understanding. That makes knowledge graph engineering and process reengineering complementary processes. I will begin this article by defining some parts of the knowledge engineering cycle to make the connection more obvious.
Mind The Information Gaps
Traditional knowledge graph engineering starts by stitching together the connections between data points and defining the relationships. As I explained in the last article, businesses don’t know what information they need. They may not have access to it yet either. Asking experts to stop doing their day jobs and spend significant amounts of time helping to map and define processes doesn’t work for long either.
Given real-world starting conditions like those, it’s better to begin with outcomes, but even those aren’t entirely transparent. Knowledge graphs and ontologies are great conceptually, but the big question remains: How do you get access to all this high-quality information about processes and outcomes?
My approach begins by defining the gaps. Before I build a new knowledge graph segment around an outcome or reengineer a process, I ask:
Do we really understand the outcome? What information do we have about it?
Does the outcome produce the value we think it does?
What information do we have about the process that creates the outcome?
What access do we have to the process? Can we gather contextual data or information about it?
Do we have access to process experts who can give us a baseline definition?
Asking these questions reveals information gaps and often leads to an uncomfortable realization. The business doesn’t have sufficient access to the process, or the technical infrastructure isn’t in place to begin gathering information. Many process reengineering and knowledge graph engineering initiatives fail at step 0.
Every process must be audited (defining the gaps) for where it falls on the maturity model before we start process reengineering or knowledge graph engineering. Often, the maturity level isn’t high enough to dive directly into either effort, and we must put foundational pieces in place first. How do we get buy-in for that work? How do we quickly move from foundations to work that generates significant returns?