Softwaredokumentation mit KI nachholen und Wissen nutzbar machen

Der Auftrag ist erledigt. Jedenfalls steht das so im System. Trotzdem kann die neue Disponentin ihn nicht abschließen. Eine Kollegin rät, den Status zurückzusetzen. Der Support verweist auf eine Anleitung, deren Bildschirmansichten nicht mehr passen. Der Entwickler, der die Funktion damals gebaut hat, arbeitet längst woanders. 

Diese Szene stammt aus einem mittelständischen Wartungsbetrieb. Seine Auftragssoftware wurde über Jahre erweitert: mobile Rückmeldungen, zusätzliche Prüfungen, neue Schnittstellen. Das Wissen darüber steckt in Code, Tickets und den Köpfen erfahrener Beschäftigter. Die folgenden Beispiele führen diesen Betrieb durch den nachträglichen Wissensaufbau. 

Eine umfangreiche Softwaredokumentation könnte hier Orientierung schaffen. Für die Disponentin entscheidet sich ihr Wert jedoch an einer konkreten Frage: Was muss sie jetzt prüfen und tun? Eine Knowledge Base ist deshalb noch kein Enablement. Als geordnete, durchsuchbare Wissensbasis liefert sie Informationen. Software-Enablement schafft die Voraussetzungen, diese Informationen in einer Arbeitssituation sinnvoll anzuwenden. 

Der Weg führt vom Verstehen der Software über die Rekonstruktion und Strukturierung ihres Wissens zur zielgruppengerechten Übersetzung, zur Befähigung der Mitarbeitenden und zur laufenden Pflege. An jedem Übergang verändert sich die Aufgabe. Dafür braucht es die Zusammenarbeit von Entwicklung, Fachbereich, Support und Personalentwicklung.

Am Anfang steht eine Bestandsaufnahme der Anwendungen, ihrer Verantwortlichen und der verfügbaren Wissensquellen. Dazu gehören Repositories, Handbücher, Anforderungen, Supporttickets, Schulungsunterlagen und freigegebene Gesprächsnotizen. Erfasst werden auch Alter, Gültigkeitsbereich und bekannte Widersprüche. Eine alte Anleitung ist eine historische Quelle; ihr Inhalt wird dadurch noch nicht zur aktuellen Arbeitsregel. 

Ein Pilot sollte eine überschaubare, relevante Aufgabe abdecken. Im Wartungsbetrieb ist das der Auftragsabschluss. Wiederkehrende Rückfragen, hohe Fehlerfolgen oder die Abhängigkeit von einer einzigen Wissensträgerin sind sinnvolle Auswahlkriterien. Alle Systeme gleichzeitig dokumentieren zu wollen, erschwert dagegen die fachliche Prüfung und die spätere Pflege. 

Entwicklung, Application Management, eine erfahrene Disponentin und eine neue Nutzerin gehen den Vorgang gemeinsam durch. Sie sammeln Fragen, an denen die Arbeit tatsächlich stockt: Was bedeutet "erledigt"? Welche Unterlage fehlt? Wer darf den nächsten Status setzen? Wann braucht es Unterstützung? Die neue Nutzerin macht Voraussetzungen sichtbar, die für erfahrene Kolleginnen längst selbstverständlich geworden sind. 

Das Ergebnis ist eine priorisierte Liste offener Fragen mit zuständigen Personen und geeigneten Quellen. HR oder Personalentwicklung ergänzen, welche Aufgaben im Onboarding beherrscht werden müssen. Die Projektleitung reserviert Zeit für die Wissensarbeit. Ohne diese Entscheidung konkurriert sie dauerhaft mit dem Tagesgeschäft.

Für die technische Rekonstruktion braucht das Team einen definierten Ausgangsstand: Welche Version läuft produktiv, welcher Code gehört dazu, welche Konfiguration ist aktiv? Ein aktueller Entwicklungszweig kann Funktionen enthalten, die noch niemand nutzen kann. Auch Berechtigungen, Hintergrundprozesse und Konfigurationsschalter beeinflussen das Verhalten. Der Quellcode allein bildet die konkrete Betriebsumgebung daher nicht vollständig ab. 

Die Analyse folgt einer fachlichen Frage durch das System. Beim Auftragsabschluss betrachtet sie die Eingabemaske, die aufgerufene Schnittstelle, die Prüfung von Rolle und Auftragsstatus sowie nachgelagerte Verarbeitungsschritte. Tests, Schnittstellenbeschreibungen und Beobachtungen in einer geeigneten Testumgebung ergänzen das Bild. Tickets liefern Hinweise auf ursprüngliche Absichten und bekannte Fehler; Gespräche erklären Entscheidungen und informelle Abläufe. 

Eine KI kann dabei relevante Stellen suchen und Zusammenhänge beschreiben. Intent ist ein konkretes Beispiel: Laut offizieller Dokumentation bindet die Plattform Git-Repositories an und indexiert deren Inhalte. Fragen lassen sich über mehrere Repositories hinweg untersuchen. Für den dokumentierenden Einstieg benötigt der gemeinsame Git-Zugang Leserechte. Die Dokumentationsansicht unterstützt Themenvorschläge aus dem Code sowie Entwürfe, Bearbeitung und Freigabe. Veröffentlichte Inhalte lassen sich als Markdown oder HTML exportieren [1]. 

Laut Changelog lassen sich Anwenderdokumentation, Beschreibungen der Softwarearchitektur sowie technische Dokumentation für Administratoren erstellen. Außerdem ist eine semantische Suche über Dokumentationsinhalte möglich [2]. Das bietet einen nutzbaren Ausgangspunkt für eine Wissensbasis. 

Eine geeignete Analysefrage wäre: "Welche Voraussetzungen prüft das System beim Auftragsabschluss? Nenne die relevanten Fundstellen und kennzeichne offene Fragen." Die Antwort liefert Prüfmaterial. Ob eine technisch mögliche Aktion fachlich erlaubt ist, entscheiden die Prozessverantwortlichen. 

Fehlt der Zugriff auf den Quellcode, etwa bei einer zugekauften Anwendung, trägt dieser codegestützte Ansatz nur begrenzt. Dann bilden Herstellerunterlagen, verfügbare Schnittstellen, Konfigurationen und beobachtete Abläufe die Grundlage. Vor jeder Anbindung wird außerdem geklärt, welche Code- und Geschäftsdaten verarbeitet werden dürfen. Zugangsdaten und vertrauliche Inhalte gehören nicht ungeprüft in einen Analysebestand.

Die größte Gefahr liegt in einer Beschreibung, die überzeugend klingt und trotzdem eine entscheidende Bedingung auslässt. Das Team behandelt KI-Ergebnisse deshalb als Entwürfe. Für wichtige Aussagen hält es fest, worauf sie beruhen: eine konkrete Codeversion, ein Test, eine freigegebene Prozessregel oder eine noch zu bestätigende Auskunft. 

Im Wartungsbetrieb ergeben sich beispielsweise zwei Aussagen: "Das System prüft, ob ein Anhang vorhanden ist" und "Der Betrieb verlangt ein fachlich geprüftes Prüfprotokoll". Das sind unterschiedliche Anforderungen. Eine Datei kann vorhanden sein, ohne den geforderten Inhalt zu haben. Die Dokumentation muss diese Differenz sichtbar machen. Wenn die Software die fachliche Regel nicht ausreichend absichert, entsteht zusätzlich ein Änderungsbedarf. 

Die Prüfung hat entsprechend zwei Verantwortungsbereiche. Eine technisch qualifizierte Person bestätigt das beschriebene Systemverhalten. Die fachlich verantwortliche Person prüft Begriffe, Zuständigkeiten und erlaubte Vorgehensweisen. Repräsentative Fälle decken den normalen Ablauf, fehlende Angaben, unzureichende Rechte und relevante Ausnahmen ab. Ungeklärte Widersprüche bleiben als solche erkennbar und werden einer verantwortlichen Person zugewiesen. 

Erst danach erhält ein Inhalt den Status "freigegeben". Jeder Beitrag braucht eine Kennung, den Gültigkeitsstand, eine zuständige Person, ein Prüfdatum und Links zu seinen Belegen. Die Versionshistorie hält Änderungen nachvollziehbar. Für eine bereits korrigierte Fehlfunktion muss außerdem klar sein, ab welchem Release die neue Beschreibung gilt. 

So entsteht eine belastbare Verbindung zwischen Beleg und Erklärung. Das erleichtert spätere Korrekturen und verhindert, dass eine vermutete Regel durch wiederholtes Kopieren zur scheinbaren Gewissheit wird. Die Qualität bemisst sich an überprüften Aussagen und nutzbaren Antworten, nicht an der Zahl erzeugter Seiten.

Die Struktur eines Repositories eignet sich selten als Einstieg für Anwender. Wer einen Auftrag abschließen möchte, sucht nach seiner Aufgabe oder einer Fehlermeldung. Die Wissensbasis braucht deshalb Zugänge nach Funktionen, Prozessen, Nutzerrollen und typischen Problemen. Ein gemeinsames Glossar verbindet fachliche Ausdrücke mit den Bezeichnungen in der Software. 

Administratoren benötigen beispielsweise Informationen über Konfiguration, Rechte, Schnittstellen und Diagnose. Key User brauchen zusätzlich Prozesszusammenhänge, Abweichungen und Eskalationswege. Reguläre Anwender finden kurze Anleitungen für ihre Aufgaben. Für neue Mitarbeitende wird daraus eine überschaubare Einstiegsseite mit den ersten relevanten Vorgängen. Rollen helfen bei der Orientierung; innerhalb einer Rolle unterscheiden sich Erfahrung und Unterstützungsbedarf weiterhin.

Der Ablageort kann ein vorhandenes Wissenssystem sein. Atlassian beschreibt für Confluence Wissensbereiche mit Vorlagen für Anleitungen und Problemlösungen [3]. Microsoft erläutert für SharePoint eine Navigation nach Tätigkeiten, Themen und Zielgruppen sowie die Einbettung von Dokumenten in verständliche Seiten [4]. Solche Systeme können die Bereitstellung unterstützen. Bei exportierten Inhalten braucht es einen festgelegten Weg für Übernahme und spätere Aktualisierung; eine automatische Verbindung darf nicht vorausgesetzt werden. 

Für den Pilot genügt eine kleine, zusammenhängende Sammlung: Prozessüberblick, Anleitung zum Auftragsabschluss, Erklärung der Statuswerte und Hilfe bei typischen Blockaden. Verwandte Beiträge verlinken aufeinander. Gemeinsame Regeln haben eine führende Quelle, damit sie nicht in mehreren Fassungen auseinanderlaufen. 

Zugriffsrechte werden unabhängig von der Navigation umgesetzt. Eine ausgeblendete Administratorenkategorie ist noch kein Schutz vertraulicher Inhalte. Auch eine ergänzende KI-Suche sollte nur die für die jeweilige Person freigegebenen Quellen verwenden und deren Stand kenntlich machen. Suche macht Wissen erreichbar; seine Verlässlichkeit entsteht durch die vorherige Prüfung.  

Nun beginnt die eigentliche Übersetzungsarbeit. Eine funktionale Beschreibung beantwortet, unter welchen Bedingungen die Software etwas zulässt. Eine Arbeitshilfe muss zusätzlich erklären, woran die Person die Situation erkennt, welche Entscheidung ansteht und welches Ergebnis sie anschließend kontrolliert.

Im Beispiel bedeutet "erledigt", dass der technische Einsatz zurückgemeldet wurde. Der Auftrag kann trotzdem auf eine fachliche Prüfung warten. Wer beide Zustände gleichsetzt, wird eine Sperre möglicherweise als Softwarefehler deuten. Eine verständliche Erklärung trennt deshalb Ausführung, Prüfung und endgültigen Abschluss und zeigt, wer jeweils übernimmt. 

Damit unterstützt sie ein mentales Modell: eine innere Vorstellung davon, wie das System funktioniert. Kieras und Bovair zeigten in Experimenten mit einem einfachen Bediengerät, dass ein passendes Funktionsmodell das Erlernen und Ableiten von Bedienhandlungen unterstützen kann. Entscheidend war, ob das Modell konkrete Handlungsschritte erschließen half [5]. Für Unternehmenssoftware lässt sich daraus die Gestaltungsregel ableiten, relevante Zusammenhänge zu erklären. Daraus folgt keine allgemeine Erfolgsgarantie für umfangreiche Systemschulungen. 

Eine gute Erklärung macht außerdem die Bedeutung für die eigene Arbeit deutlich. "Der Nachweis wird geprüft" lässt die Verantwortung offen. "Die fachlich zuständige Person prüft den Nachweis, bevor die Disposition den Auftrag abschließt" benennt Beteiligte und Reihenfolge. Verständlichkeit hängt damit ebenso von klaren Zuständigkeiten wie von einfacher Sprache ab.

Eine nachträglich aufgebaute Knowledge Base veraltet erneut, wenn ihre Pflege vom Entwicklungs- und Arbeitsprozess getrennt bleibt. Jede relevante Softwareänderung sollte deshalb eine Prüfung auslösen: Welche Beschreibung, Anleitung, Übung oder Rolleninformation ist betroffen? Ein Dokumentationsverantwortlicher koordiniert die Anpassung. Entwicklung bestätigt das technische Verhalten, der Fachbereich die Prozessregeln, Training oder Personalentwicklung die erforderlichen Lernmaßnahmen. 

Intent beschreibt dafür einen konkreten Mechanismus: Nach abgeschlossenen Feature-, Fehlerbehebungs- oder Refactoring-Changesets prüft die Plattform periodisch, ob Dokumentation betroffen ist und schlägt Entwürfe vor. Laut Nutzerhandbuch beruhen diese auf der Beschreibung des Changesets sowie dem tatsächlich geänderten Code und müssen freigegeben werden.[8] Ein Changeset bündelt zusammengehörige Änderungen. Dieser Mechanismus ersetzt weder die Prüfung des produktiven Releases noch die Anpassung externer Schulungsunterlagen. 

Praktisch erhält eine Änderung erst dann ihre organisatorische Freigabe, wenn die betroffenen Hilfen geprüft oder begründete Ausnahmen dokumentiert sind. Bei veränderten Zuständigkeiten kann eine Aktualisierung auch ohne Codeänderung nötig sein. Ergänzend sind feste Prüftermine sinnvoll, deren Abstand vom Risiko und der Änderungshäufigkeit abhängt. Besonders folgenreiche Anleitungen werden anders behandelt als selten genutzte Hintergrundtexte. 

Nutzerfeedback schließt die Lücke zwischen geplantem Inhalt und tatsächlichem Bedarf. Der Ansatz Knowledge-Centered Service empfiehlt, Wissen während seiner Nutzung zu verbessern und erkannte Mängel zu korrigieren oder zur Bearbeitung zu markieren [9]. Für den Betrieb bedeutet das: Eine unverständliche Antwort oder eine erfolglose Suche wird zum konkreten Pflegeauftrag. Ein Feedbackknopf ohne Zuständigkeit und Rückmeldung reicht dafür nicht.

Die Erfolgsmessung betrachtet Aufgaben statt Seitenaufrufe. Lassen sich ausgewählte Vorgänge korrekt bearbeiten? Werden benötigte Hilfen gefunden? Welche Rückfragen wiederholen sich? Wie lange bleiben gemeldete Wissenslücken offen? Vergleichbare Beobachtungen vor und nach dem Pilot geben Hinweise auf Verbesserungen. Weniger Tickets allein beweisen keinen Kompetenzzuwachs; auch aufgegebene Versuche oder informelle Hilfe können die Zahl senken.