Het gesprek begint vrijwel altijd hetzelfde. Een bedrijfsleider heeft besloten dat ze hun operationele kennis beter gaan documenteren. Goed voornemen. Maar in de volgende zin volgt de vraag die alles al samenperst: "We twijfelen nog tussen Notion en SharePoint, wat zou jij aanraden?"
De tool staat centraal. Het werk zelf nog niet.
Dit is de meest voorkomende fout in documentatietrajecten bij KMO's: het platform wordt gekozen voor de structuur duidelijk is, de structuur wordt gebouwd voor de kennis in kaart is, en de kennis wordt gedocumenteerd voor iemand heeft nagedacht over wie die documentatie eigenlijk gaat gebruiken en waarom.
Waarom tools zo verleidelijk zijn
Faites le Capture Check gratuit et découvrez où se trouve votre savoir critique — avant qu'il ne disparaisse.
Maar een tool lost geen kennismanagementprobleem op. Een tool is een opslagplaats. Wat erin staat, is uw verantwoordelijkheid. En als de inhoud niet klopt — niet compleet, niet actueel, niet begrijpelijk voor de persoon die hem nodig heeft — dan is de tool meer een schijnzekerheid dan een oplossing.
Ik heb bedrijven gezien met een prachtig ingerichte Notion-workspace vol pagina's die niemand leest, procedures die verwijzen naar een werkwijze van twee jaar geleden, en een structuur die logisch is voor de persoon die hem opgebouwd heeft maar voor niemand anders.
Wat er moet gebeuren vóór de tool
Goede operationele documentatie begint met drie vragen die niets met tooling te maken hebben:
1. Wat moet iemand weten om dit werk goed te doen?
Niet: wat staat er al ergens opgeschreven. Maar: wat moet iemand daadwerkelijk weten — inclusief de dingen die ervaren medewerkers vanzelfsprekend vinden maar die een nieuwe collega niet weet?
2. Wie gaat deze documentatie gebruiken, en in welke situatie?
Een procedure voor een ervaren medewerker die een zeldzame uitzondering moet afhandelen, ziet er anders uit dan een onboardingdocument voor iemand die een proces voor het eerst leert. De lezer bepaalt de vorm.
3. Hoe zorgen we dat dit actueel blijft?
Documentatie die niet onderhouden wordt, is een tijdbom. Niet omdat ze fout is op het moment van schrijven, maar omdat de realiteit evolueert en de documentatie niet meeevolueert. Wie is verantwoordelijk voor de review? Wanneer? Op basis van welke trigger?
Het veldwerk dat de meeste trajecten overslaan
Voordat u ook maar één pagina aanmaakt in welke tool dan ook, is er werk te doen. Dat werk ziet er ruwweg zo uit:
- Inventariseer welke processen bestaan en welke kritisch zijn voor de continuïteit van uw bedrijf.
- Identificeer wie de kennis draagt voor elk van die processen — niet wie officieel verantwoordelijk is, maar wie het in de praktijk het best weet.
- Voer gesprekken met die mensen: niet om meteen te documenteren, maar om te begrijpen hoe het proces werkelijk loopt, inclusief uitzonderingen en informele stappen.
- Valideer wat u gehoord heeft met de betrokkenen: klopt dit? Missen we iets? Is dit wat een nieuwe collega echt zou moeten weten?
Pas daarna heeft het zin om te gaan schrijven. En pas daarna weet u ook welke structuur, welk format en welke tool het best passen bij het type kennis dat u vastlegt.
De juiste volgorde maakt het verschil
Dit klinkt simpel, maar het is zelden wat bedrijven doen. De verleiding van de tool is te groot, de tijdsdruk te reéel, en het veldwerk te onzichtbaar om er prioriteit aan te geven.
Het resultaat is documentatie die technisch bestaat maar operationeel niet werkt. En een tool die na zes maanden "bijna klaar" is maar door niemand wordt gebruikt.
Bij Captext beginnen we altijd met het veldwerk. We gaan naar uw bedrijf, we luisteren naar uw mensen, we begrijpen hoe uw processen werkelijk lopen — en dan pas leggen we iets vast. Niet omgekeerd.
Als u wil weten hoe uw huidige documentatiepraktijk ervoor staat, kunt u doen. In drie minuten krijgt u een eerlijk beeld.
© Captext
The conversation almost always starts the same way. A business owner has decided they're going to document their operational knowledge better. Good intention. But the very next sentence already compresses everything: "We're still deciding between Notion and SharePoint — what would you recommend?"
The tool takes centre stage. The actual work hasn't yet.
This is the most common mistake in documentation projects at SMEs: the platform is chosen before the structure is clear, the structure is built before the knowledge is mapped, and the knowledge is documented before anyone has thought about who is actually going to use that documentation and why.
Why tools are so tempting
Tools are concrete. You can install them, configure them, and show them to colleagues. They give a sense of progress. Notion looks clean. SharePoint integrates with Office. Whale is built for procedures. Every platform has its story and its evangelists.
But a tool doesn't solve a knowledge management problem. A tool is a storage location. What goes into it is your responsibility. And if the content isn't right — not complete, not current, not understandable to the person who needs it — then the tool is more of a false security than a solution.
I've seen companies with a beautifully organized Notion workspace full of pages that no one reads, procedures that reference a working method from two years ago, and a structure that makes sense to the person who built it but to no one else.
What needs to happen before the tool
Good operational documentation starts with three questions that have nothing to do with tooling:
1. What does someone need to know to do this work well?
Not: what's already written down somewhere. But: what does someone actually need to know — including the things that experienced employees take for granted but a new colleague doesn't know?
2. Who is going to use this documentation, and in what situation?
A procedure for an experienced employee handling a rare exception looks different from an onboarding document for someone learning a process for the first time. The reader determines the form.
3. How do we keep this current?
Documentation that isn't maintained is a time bomb. Not because it's wrong when written, but because reality evolves and the documentation doesn't evolve with it. Who is responsible for the review? When? Based on what trigger?
The fieldwork that most projects skip
Before you create a single page in any tool at all, there is work to be done. That work looks roughly like this:
- Inventory which processes exist and which are critical for the continuity of your business.
- Identify who carries the knowledge for each of those processes — not who is officially responsible, but who knows it best in practice.
- Have conversations with those people: not to immediately document, but to understand how the process actually runs, including exceptions and informal steps.
- Validate what you've heard with those involved: is this correct? Are we missing anything? Is this what a new colleague would really need to know?
Only then does it make sense to start writing. And only then will you also know which structure, which format, and which tool best fits the type of knowledge you're capturing.
The right order makes the difference
This sounds simple, but it's rarely what companies do. The temptation of the tool is too great, the time pressure too real, and the fieldwork too invisible to prioritize.
The result is documentation that technically exists but operationally doesn't work. And a tool that after six months is "almost finished" but used by no one.
At Captext, we always start with the fieldwork. We go to your business, we listen to your people, we understand how your processes actually run — and only then do we capture anything. Not the other way around.
If you want to know how your current documentation practices stand, you can take . In three minutes, you'll get an honest picture.
© Captext
La conversation commence presque toujours de la même façon. Un chef d'entreprise a décidé de mieux documenter ses connaissances opérationnelles. Bonne intention. Mais la phrase suivante comprime déjà tout : — Nous hésitons encore entre Notion et SharePoint — qu'est-ce que vous recommanderiez ? »
L'outil passe au premier plan. Le vrai travail, lui, n'a pas encore commencé.
C'est l'erreur la plus courante dans les projets de documentation dans les PME : la plateforme est choisie avant que la structure soit claire, la structure est construite avant que les connaissances soient cartographiées, et les connaissances sont documentées avant que quiconque ait réfléchi — qui va réellement utiliser cette documentation et pourquoi.
Pourquoi les outils sont si tentants
Les outils sont concrets. On peut les installer, les configurer et les montrer — ses collègues. Ils donnent un sentiment de progrès. Notion est épuré. SharePoint s'intègre — Office. Whale est conçu pour les procédures. Chaque plateforme a son histoire et ses adeptes.
Mais un outil ne résout pas un problème de gestion des connaissances. Un outil est un emplacement de stockage. Ce qui y entre est votre responsabilité. Et si le contenu n'est pas correct — pas complet, pas à jour, pas compréhensible pour la personne qui en a besoin — alors l'outil est davantage une fausse sécurité qu'une solution.
J'ai vu des entreprises avec un espace de travail Notion magnifiquement organisé, plein de pages que personne ne lit, de procédures qui font référence — une méthode de travail datant de deux ans, et une structure qui a du sens pour celui qui l'a construite mais pour personne d'autre.
Ce qui doit se passer avant l'outil
Une bonne documentation opérationnelle commence par trois questions qui n'ont rien — voir avec les outils :
1. Que doit savoir quelqu'un pour bien faire ce travail ?
Non pas : qu'est-ce qui est déjà écrit quelque part. Mais : que doit réellement savoir quelqu'un — y compris les choses que les employés expérimentés considèrent comme allant de soi mais qu'un nouveau collègue ignore ?
2. Qui va utiliser cette documentation, et dans quelle situation ?
Une procédure pour un employé expérimenté gérant une exception rare est différente d'un document d'intégration pour quelqu'un qui apprend un processus pour la première fois. Le lecteur détermine la forme.
3. Comment allons-nous maintenir cela — jour ?
Une documentation qui n'est pas maintenue est une bombe — retardement. Non pas parce qu'elle est incorrecte au moment de la rédaction, mais parce que la réalité évolue et que la documentation n'évolue pas avec elle. Qui est responsable de la révision ? Quand ? Sur la base de quel déclencheur ?
Le travail de terrain que la plupart des projets ignorent
Avant de créer une seule page dans n'importe quel outil, il y a un travail — faire. Ce travail ressemble — peu près — ceci :
- Inventorier quels processus existent et lesquels sont critiques pour la continuité de votre entreprise.
- Identifier qui détient les connaissances pour chacun de ces processus — non pas qui en est officiellement responsable, mais qui le connaît le mieux en pratique.
- Avoir des conversations avec ces personnes : non pas pour documenter immédiatement, mais pour comprendre comment le processus fonctionne réellement, y compris les exceptions et les étapes informelles.
- Valider ce que vous avez entendu avec les parties concernées : est-ce correct ? Manque-t-il quelque chose ? Est-ce ce qu'un nouveau collègue aurait vraiment besoin de savoir ?
C'est seulement alors qu'il est judicieux de commencer — écrire. Et c'est seulement alors que vous saurez également quelle structure, quel format et quel outil convient le mieux au type de connaissances que vous capturez.
Le bon ordre fait la différence
Cela semble simple, mais c'est rarement ce que font les entreprises. La tentation de l'outil est trop grande, la pression du temps trop réelle, et le travail de terrain trop invisible pour être priorisé.
Le résultat est une documentation qui existe techniquement mais qui ne fonctionne pas opérationnellement. Et un outil qui après six mois est — presque terminé — mais que personne n'utilise.
Chez Captext, nous commençons toujours par le travail de terrain. Nous allons dans votre entreprise, nous écoutons vos collaborateurs, nous comprenons comment vos processus fonctionnent réellement — et ce n'est qu'ensuite que nous documentons quoi que ce soit. Pas l'inverse.
Si vous voulez savoir où en sont vos pratiques de documentation actuelles, vous pouvez faire . En trois minutes, vous obtiendrez une image honnête.
© Captext
