Process Knowledge Management, Part II
Collection Development and Organizing Principles
Introduction
Part One of this series established process knowledge as a distinct and critical form of organizational intelligence—one that describes what an organization knows and how it works. We examined the theoretical foundations: the interplay between tacit and explicit knowledge, the role of semantic ecosystems, and the promise of ontologies as structured representations that can guide AI systems toward valid, interpretable outputs.
This second essay turns from theory to practice and examines how to actually manage process knowledge. How do we collect process knowledge from the minds of practitioners and the rhythms of organizational life? How do we organize it into structures that serve multiple stakeholders with different needs? And how do we encode it in ways that make it actionable—for human collaborators, for search and discovery systems, and for the AI agents increasingly embedded in enterprise workflows?
The answers require us to think as knowledge engineers, information architects, librarians, information scientists and organizational anthropologists. Process knowledge does not yield itself easily to extraction. It hides in the practiced hands of experienced workers, in the margins of standard operating procedures, in the unspoken negotiations that determine how work actually flows. Bringing this knowledge to the surface, organizing it coherently, and encoding it for computational consumption demands methodologies that respect both its richness and its fragility.
Collecting Process Knowledge
The Challenge of Elicitation
Collecting process knowledge or procedural knowledge is fundamentally an act of translation—moving understanding from embodied practice into explicit form. This translation is never lossless. Every methodology for knowledge elicitation involves trade-offs between fidelity and feasibility, depth and scale.
The first challenge is access. Process knowledge lives within practitioners’ heads, who often cannot articulate what they know. As the Polanyi Paradox so aptly highlights, we know more than we can tell. An experienced claims adjuster who can instantly recognize a fraudulent pattern, a software architect who senses when a design will create future maintenance burdens, a nurse who detects subtle deterioration in a patient’s condition—these experts operate from accumulated pattern recognition that resists explicit formulation. Knowledge managers and process engineers must employ techniques that draw out this tacit understanding without forcing it into oversimplified rules.
Elicitation Methodologies: Knowledge Collection
Several complementary approaches can be combined to build a comprehensive picture of process knowledge.
Structured interviews remain foundational. These work best when they move beyond asking practitioners what they do, toward understanding why they make particular choices and what happens when standard procedures prove insufficient. The critical incident technique (CIT), developed by John Flanagan in the 1950s, proves particularly valuable. Asking practitioners to describe specific instances where processes succeeded, failed, or required improvisation, reveals the judgment calls that procedural documentation obscures.
