Nehmen wir an, ein Unternehmen führt ein neues ERP-System ein, sagen wir Odoo. Im Laufe des Projektes werden neue Geschäftsprozesse erarbeitet und geübt. Zum einen, weil Dinge im neuen ERP-System anders funktionieren als im alten System oder weil sich gewisse Dinge überlebt haben und jetzt die Gelegenheit für einen Hausputz genutzt wird.
Die Herausforderung dabei: Selbst nach ausgiebiger Schulung fehlt zu Beginn einfach die Routine in dem neuen Werkzeug. Das führt, je nach Persönlichkeit, zu Unsicherheit und Stress, bei der Erledigung alltäglicher Aufgaben. Kommt dann noch direkter Kundenkontakt zu der empfundenen Unsicherheit hinzu, bekommt der eine oder andere schon im Vorfeld Panik. Im Ergebnis wird dann oft auf die neue Lösung geschimpft und die alte über den Klee gelobt – ein schwerer Start für das neue Tool.
Hinzu kommt, dass oft keine formalen Geschäftsprozessbeschreibungen oder gar Standard Operating Procedures (SOPs) existieren. Bestehende Abläufe sind nur mündlich überliefert („Das haben wir schon immer so gemacht“) oder existieren in veralteten Dokumenten, die längst nicht mehr zur Realität passen. Wenn dann das neue Tool eingeführt wird, muss vieles gleichzeitig gelernt und angepasst werden – und genau hier entstehen Probleme.
Was kann man da tun?
Ich will es nicht schönreden, die Einführung einer neuen komplexen Software, welche gewohnte Prozesse teilweise grundlegend ändert, ist immer eine Herausforderung für ein Unternehmen und das Team. Aber ich bin fest der Überzeugung, dass man den Geburtsschmerz eines solchen Projektes entschieden mindern kann, wenn man neben ausreichender vorbereitender Schulung dem Team eine einfach zugängliche und praxisnahe Dokumentation zum schnellen Nachschlagen an die Hand gibt.
Warum Anwender ihre eigene Dokumentation schreiben sollten
Statt dass nun ausschließlich Projektleiter oder externe Berater Dokumentationen verfassen, sollten die Anwender selbst die eigene Dokumentation erarbeiten. Das hat mehrere Vorteile:
- Verständlich in eigenen Worten – Die Erklärungen sind praxisnah und so formuliert, dass das Team sie nachvollziehen kann.
- Fokus auf das Wesentliche – Anwender wissen, welche Arbeitsschritte wirklich relevant sind, und sparen unnötige Details aus.
- Erfahrungswissen wird gesichert – Praxisfälle und Sonderlösungen landen in der Doku, nicht nur theoretische Abläufe.
- Schnell nachschlagbar – Eine gut geführte Dokumentation reduziert Unsicherheit und spart Zeit bei der Einarbeitung.
- Geteiltes Wissen – Hilft beim Onboarding neuer Mitarbeiter und bei Vertretungen in Abwesenheit.
- Wissensvertiefung – Wer einen Ablauf erklären muss, versteht ihn selbst noch besser.
Dabei sollte einfach und hemdsärmelig mit der Dokumentation begonnen werden, denn Perfektionismus ist auch hier der Feind von einer guten Lösung. Ein Artikel kann zunächst nur aus dem wichtigsten Bulletpoints, einem Screenshot oder einem Link bestehen, Hauptsache, es wird begonnen. Ist das Thema relevant, wird der Artikel mit der Zeit erweitert und verbessert werden. Auch hier gilt: Content is King. Nur wenn ich hilfreichen und sinnvollen Inhalt bereitstelle, wird die Lösung benutzt. Und sinnvoll ist zu Beginn jeder kleine Schnipsel und jede Gedankenstütze zu einem alltäglichen Problem.
Das richtige Tooling
Damit dieses Prinzip funktioniert, muss das Dokumentationswerkzeug einige Anforderungen erfüllen:
- Einfache Bedienung – Die Hemmschwelle zum Mitschreiben muss gering sein und Abruf des Wissens maximal einfach.
- Klar strukturierbar – Eine gute Suchfunktion, klare Kategorien und sinnvolle Navigationswege sind Pflicht.
- Rechtemanagement – Einfacher Zugang, aber Schutz sensibler Informationen.
- Versionierung – Änderungen müssen nachvollziehbar bleiben.
- Schnelle Verfügbarkeit – Die Doku muss während der Arbeit leicht erreichbar sein, nicht in einem unübersichtlichen SharePoint-Ordner verstauben.
Tools wie z. B. BookStack bieten hier einen guten Kompromiss: Sie sind einfach genug, um von allen genutzt zu werden, aber flexibel genug, um komplexe Inhalte zu strukturieren.
Herausforderungen bei der Einführung
Nach meiner persönlichen Erfahrung gibt es bei der Einführung häufig ähnliche Widerstände, die überwunden werden müssen:
- Der Wert und die Sinnhaftigkeit einer eigenen Dokumentation werden zunächst nicht erkannt.
- Der Aufwand wirkt abschreckend, weil oft das Bild eines umfassenden Kompendiums im Kopf entsteht.
- Schreibhemmung – Die Sorge, sich vor Kollegen zu blamieren oder bewertet zu werden.
Zusätzlich zu diesen eher allgemeinen Anfangshürden, müssen aber auch die Rahmenbedingungen passen. Die Erstellung der Dokumentation darf nicht als Nebentätigkeit „irgendwann mal“ stattfinden, sondern sollte Teil der Zielvorgaben sein. Führungskräfte müssen Zeit und Priorität dafür freigeben.
Meine Empfehlung zur Einführung
Ich baue die Erstellung der Dokumentation in der Regel bereits während der Workshops unangekündigt ein. Sobald die ersten Grundlagen vermittelt sind, fordere ich spontan auf, doch jetzt mal die wichtigsten Bulletpoints kurz mit einem Screenshot in einem Artikel zusammenzufassen. In der Regel nehme ich mir dazu kleine einfache Themen, bei denen ich Unsicherheiten bei den Anwendern bemerkt habe.
Zum einen kommt so schnell eine kleine, aber kritische Menge an relevanten Artikeln zusammen. Diese Artikel / Themen sind dann häufig bei der nächsten Gruppe oder beim nächsten Workshop relevant und ich fordere zum Nachschlagen in der Doku auf. Darüber hinaus kommt es dann im Team häufig schnell zu einer Ergänzung und Erweiterung der bestehenden Artikel. Dadurch gibt es schnell ein positives Erlebnis und auch Erleichterung bei den Anwendern.
Dafür ist aber entscheidend, dass das gewählte Dokumentationstool in jeglicher Hinsicht so simpel wie möglich zu bedienen ist und keine zusätzliche Hürde für die Anwender darstellt.
Meine Tipps daher:
- Die Dokumentation muss parallel zur Arbeit an einem Thema entstehen – nachträglich passiert es eigentlich nie.
- Führungskräfte müssen die Zeit fürs Mitschreiben freigeben und es nicht als eine Nebensächlichkeit sehen.
- Manche Anwender sehen den Nutzen erst, wenn die Dokumentation ihnen konkret hilft – daher sofort mit kleinen kritischen Themen beginnen.
Fazit
Bei komplexen IT-Projekten – etwa einem neuen ERP-System – entscheidet oft nicht die Software allein über den Erfolg, sondern die Qualität der internen Wissensweitergabe. Wenn Anwender ihre eigene Dokumentation schreiben, entsteht eine lebendige Wissensbasis, die mit der Praxis wächst.
Das mindert Stress, reduziert Fehler, beschleunigt das Onboarding und macht das Unternehmen unabhängiger vom Wissen einzelner Personen.
Meine Empfehlung ist daher, dass jedes Unternehmen grundsätzlich seine Standardprozesse dokumentieren sollte und so seine eigenen Standards schafft.