--- title: "Quick Tips: Turning Implicit Knowledge Into Process" description: Why handbooks fail to capture expert knowledge — and five ways to record judgement so the next case is decidable by someone who is not an expert. image: https://blog.noreja.com/hubfs/blog/featured-images/.png-4.png --- [Skip to content](https://blog.noreja.com/en/turn-implicit-knowledge-into-processes#main-content) ![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/.png-4.png?width=1820&height=1024&name=.png-4.png) Quick Tips GenAI BPM # Quick Tips: Turning Implicit Knowledge Into Process ![Lukas Pfahlsberger](https://app.hubspot.com/settings/avatar/6b6ceb34347ba3ac2667e67af4e9f63f) Lukas Pfahlsberger September 29, 2026 Every organisation runs on knowledge that exists nowhere in writing. Which customer accepts a partial delivery and which one escalates to the board. Why the second approval is skipped for orders under a certain value, except in one country. Which field in the system is unreliable and what people check instead. None of it is in the process documentation, all of it is essential, and most of it lives in the heads of a handful of experienced colleagues. That is not a documentation failure — it is how expertise works. The problem starts when the organisation depends on that knowledge without knowing it does: when one person's absence stalls a process, when a new hire needs five months to become useful, when the same question is answered by email for the fourth time this quarter. This edition of Quick Tips is about five practical ways to convert implicit knowledge into explicit process — without producing another document nobody reads. ## Why Most Attempts to Document Knowledge Fail Consider a claims team of nine people. Two of them have twelve years of experience and handle everything unusual. After a near-miss during a summer holiday, management commissions documentation: a workshop is held, a process map is drawn, a forty-page handbook is written and stored in the intranet. Eight months later, the handbook has been opened three times. The two experts are still the process, and nobody feels the effort was wasted, because the document exists. Three things went wrong, and they go wrong almost every time. The documentation described the ideal process rather than the actual one, because it came from a workshop where people say what should happen. It captured steps rather than judgement, so it explains the sequence anyone could infer and omits the decisions that actually require experience. And it was stored away from the work, in a place people would have to remember to visit while under time pressure. The useful reframing is this: the goal is not to write down what experts know. It is to make the next case decidable by someone who is not an expert. That is a much narrower target, and the five tips below aim at it. ## Tip 1: Start Where the Knowledge Is Expensive, Not Where It Is Easy Documentation projects tend to start with the process that is easiest to describe, which is usually the one that needs it least. A better starting point is exposure: where does undocumented knowledge cost you money, delay or risk right now? Three signals locate it quickly. First, single-person dependency — steps that halt when one specific person is unavailable. Second, question volume: which topics generate repeated internal questions from otherwise competent colleagues? A recurring question is a piece of missing process, and the internal chat history is a surprisingly precise map of where knowledge is thin. Third, variance: cases of the same type that take wildly different amounts of time depending on who handles them, which usually means the routing decision is a judgement call nobody has written down. Pick one area with high exposure and work only there. A two-page description of the decision that stalls without your key expert is worth more than a complete handbook covering everything evenly. We looked at the risk side of this pattern in the edition on [when one person is the process](https://blog.noreja.com/en/when-one-person-is-the-process?hsLang=en). Ask yourself: which single absence in your team would slow a process most this month — and is anything about that person's decisions written down? ## Tip 2: Observe the Work Instead of Interviewing About It Asking an expert to describe their process produces a cleaned-up version. Not through dishonesty — memory summarises, and experts have automated exactly the judgements you want to capture, which makes them genuinely hard to articulate. "It depends on the case" is usually a true answer to a badly posed question. So use two better sources. Sit with the person while they work through real cases and write down every point at which they made a choice, including the ones they do not notice making. Then triangulate against the system record. The timestamps in your ERP, CRM or ticketing system show what actually happened: how many variants of the process exist, which steps get skipped in practice, where cases loop back. Process mining turns that into a measured picture, and AI-supported platforms such as [noreja](https://topai.tools/t/noreja) can point to the drivers behind a variant, which is a fast way to find the informal rule producing it. The combination is what works: the data shows where the process deviates, and the observation explains why. A variant that occurs in eighteen percent of cases and always at the same customer segment is not chaos — it is an undocumented rule, and now you can write it down. Ask yourself: does your description of the process come from what people said in a workshop, or from what the cases and the system actually did? ## Tip 3: Capture Decisions, Not Steps Most process documentation records sequence, which is the cheap part. The expensive part is judgement — the small set of decisions where an experienced person chooses differently from a novice, and where choosing wrongly is costly. For each of those decision points, write four things: what triggers the decision, what information you need to make it, the rule including its thresholds, and what happens in the exception. The rule is the piece that experts rarely volunteer and that novices most need. "Escalate high-value claims" is not a rule; "escalate above 25,000 euros, or above 10,000 if the customer has an open complaint" is one. A rule with a number is testable, teachable and correctable. A principle without one is a preference. Expect to discover disagreement, and treat that as the main benefit rather than an obstacle. When two experienced people state their thresholds out loud, they frequently differ — which means the process has been running on two rules and nobody knew. Resolving that is an improvement in itself, independent of any document. Ask yourself: for the three hardest decisions in your process, can you state the rule with a number in it? ## Tip 4: Put It Where the Work Happens Knowledge stored away from the work has to be remembered to be used, and under time pressure it will not be. A wiki page is a reference; what people need at the moment of deciding is a prompt. So aim for the smallest artefact that fits into the flow. A four-line checklist in the ticket template. A tooltip on the field where the judgement is made. A required entry that asks which rule was applied. A one-page decision guide pinned in the team channel. If your captured knowledge cannot be reduced to something that fits on one screen at the point of use, it is not yet finished — long documents are usually a sign that decisions and background have not been separated. This also changes the maintenance question. Documentation that lives inside the tool gets corrected when it is wrong, because being wrong is immediately visible to whoever is working. A handbook can be wrong for years without anyone noticing, which is the pattern we described in the edition on [processes that exist only on paper](https://blog.noreja.com/en/processes-exist-only-on-paper?hsLang=en). Ask yourself: at the moment someone has to make the decision, is the guidance on their screen — or in a system they would have to go and find? ## Tip 5: Make Updating Part of the Work, Not a Project Explicit knowledge decays. Rules change, thresholds shift, systems get replaced, and a description that is eighteen months old is treated — correctly — as unreliable, which sends everyone back to asking the expert. The fix is not an annual review cycle; it is a trigger attached to the work itself. The most effective trigger is the exception. Whenever a case is handled outside the documented rule, that is by definition new information: either the rule is wrong, or the exception belongs in it. Make a one-line note mandatory at that moment — what was decided and why — and give one person the standing job of folding those notes into the rule every few weeks. That is fifteen minutes of work, and it keeps the knowledge current in the only way that scales. Two supporting habits make it stick. Give every documented decision a named owner rather than a team, so correction has an address. And use new joiners as the test: whatever a new colleague still has to ask about, after reading what exists, is the part that is not yet explicit. Their questions are the most honest audit of your process knowledge you will get, and they are free. Ask yourself: when someone handles a case outside the rule, does that fact reach the documented process — or only the person who made the call? ## Food for Thought If your most experienced colleague were unavailable for a month, which decisions would stall — and what would people do instead? Which question does your team answer internally most often, and why has it never become part of the process? How many of your documented process rules contain an actual number? Where does your process guidance live, and when was the last time someone corrected it because it was wrong? What is your newest colleague still asking about, and what does that reveal about which knowledge is still implicit? ## Conclusion: Make the Next Case Decidable, Not the Handbook Complete Implicit knowledge is not a documentation gap to be filled with volume. It is a set of judgements that a few people can make and most cannot, and it becomes a business risk exactly when a process depends on those judgements without saying so. Converting it is narrower work than it looks: find where the dependency is expensive, observe real cases instead of asking for descriptions, write down the decisions and their thresholds rather than the steps, put the result where the work happens, and let every exception update the rule. Done that way, the output is not a handbook — it is a process a competent newcomer can run. One concrete starting point: take the last ten internal questions your team answered by email or chat, and check which of them a written rule would have answered. That list is your documentation backlog, ranked by real demand — and it usually takes an afternoon rather than a project. [Contact us](https://outlook.office365.com/book/Kennenlernen@noreja.com/?ismsaljsauthenabled=true) ## FAQ #### What is implicit knowledge in a business process? The judgement that experienced people apply without it being written down: which cases are exceptions, which thresholds trigger an escalation, which data is unreliable and what to check instead. It is normal and unavoidable — it becomes a risk when a process depends on it and the organisation has not noticed. #### Why do documentation projects usually fail to capture it? Because they describe the ideal process from workshops rather than the real one from cases, they record steps instead of the decisions that require experience, and they store the result away from the work, where it has to be remembered to be used. The result is a document that exists and is not read. #### How do you decide which knowledge to make explicit first? By exposure. Look for single-person dependencies, recurring internal questions, and cases of the same type whose duration depends on who handles them. Those three signals identify where undocumented judgement is currently costing time, money or risk — and they point to a small area worth doing properly rather than a broad survey. #### How does process mining help make implicit knowledge explicit? It shows what actually happens: how many variants of the process exist, which steps get skipped, where cases loop back, and which segments behave differently. A variant that recurs consistently is almost always an undocumented rule. The data locates it and observation of real cases explains it, which is far faster than interviewing people about their process. #### How do you keep process documentation from going stale? Attach the update to the work rather than to a review cycle. Require a one-line note whenever a case is handled outside the documented rule, and give one named person the standing task of folding those notes into the rule every few weeks. New joiners' questions are the cheapest audit of whether the result is still complete. ## Share this post [mailto:https%3A%2F%2Fblog.noreja.com%2Fen%2Fturn-implicit-knowledge-into-processes](mailto:https%3A%2F%2Fblog.noreja.com%2Fen%2Fturn-implicit-knowledge-into-processes) ## Keep reading ### [![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/.png-3.png?width=1820&height=1024&name=.png-3.png) GenAI BPM Process Intelligence Business Case: How to Cut Customer Onboarding Time](https://blog.noreja.com/en/cut-customer-onboarding-time-saas?hsLang=en) ### [![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/.png-2.png?width=1820&height=1024&name=.png-2.png) Two-For-One GenAI BPM Two for One: Every New Tool Inherits the Old Bottleneck](https://blog.noreja.com/en/new-tool-inherits-old-bottleneck?hsLang=en) [![noreja\_logo\_white](https://blog.noreja.com/hs-fs/hubfs/noreja_logo_white.png?width=300&height=78&name=noreja_logo_white.png "noreja_logo_white")](https://blog.noreja.com/?hsLang=en) [Privacy Policy](https://noreja.com/en/privacy) · [Legal](https://noreja.com/en/imprint) · © 2026 Noreja. All rights reserved. ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Lukas Pfahlsberger", "url" : "https://blog.noreja.com/en/author/lukas-pfahlsberger" }, "dateModified" : "2026-09-29T07:00:01.140Z", "datePublished" : "2026-09-29T07:00:00.000Z", "headline" : "Quick Tips: Turning Implicit Knowledge Into Process", "image" : [ "https://blog.noreja.com/hubfs/blog/featured-images/.png-4.png" ], "mainEntityOfPage" : { "@id" : "https://blog.noreja.com/en/turn-implicit-knowledge-into-processes", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.noreja.com/hubfs/noreja_logo_white-1.png" }, "name" : "Noreja Intelligecne GmbH" } } ```