Knowledge Ownership: Wissen im Unternehmen sichern

Viele Unternehmen stehen nicht vor der Frage nach neuer Software, sondern vor einem anderen Risiko: Der Softwarebetrieb hängt von wenigen Personen ab, sodass wichtiges Wissen verloren gehen kann. 

Ein Entwickler geht in Rente, fällt länger aus oder verlässt das Unternehmen. Plötzlich wird ein System, das jahrelang zuverlässig lief, zum Risiko, weil kaum noch jemand weiss, wie es aufgebaut ist, gewartet wird oder bei Änderungen angepasst werden muss. Besonders kritisch ist das bei älteren Technologien wie Delphi oder Access. Geht internes Wissen verloren, sind passende Spezialisten oft nur schwer zu finden. Das eigentliche Risiko besteht darin, die Software nicht mehr zuverlässig betreiben, warten und weiterentwickeln zu können.

1. Incident: Eine Störung, die den Softwarebetrieb beeinträchtigt und aktiv bearbeitet werden muss.
2. Runbook: Eine klare Schrittfolge zur Diagnose und Behebung eines typischen Vorfalls.
3. Restore-Test: Eine Prüfung, ob ein Backup erfolgreich wiederhergestellt werden kann.
4. Systemübersicht: Überblick über Systeme, Abhängigkeiten, Datenflüsse und Verantwortlichkeiten.
5. Deployment: Ein definierter Prozess, um Änderungen sicher in die Produktivumgebung zu bringen.

Diese Seite beantwortet Dir folgende Fragen:

• Woran erkenne ich, ob unser Softwarewissen nur bei wenigen Personen liegt?
• Welche Risiken entstehen dadurch im Betrieb und in der Fertigung?
• Wie sichere ich den Softwarebetrieb, wenn niemand das System wirklich versteht?
• Welche Verantwortlichkeiten braucht es, damit alles stabil läuft?
• Welche Dokumentation brauche ich wirklich, damit der Softwarebetrieb zuverlässig läuft?
• Wie kann ich Systemwissen wieder aufbauen, wenn der Entwickler weg ist?
• Wie übernimmt soxes ein bestehendes System, damit Betrieb und Updates wieder planbar sind?

Systeme wachsen über Jahre und Wissen landet dabei fast automatisch in Köpfen statt in klaren Strukturen. Wenn wir das in Erstgesprächen ansprechen, hören wir fast immer ähnliche Sätze: «Ja, das ist bei uns auch so. Aber bisher hat es irgendwie funktioniert.»

Genau darin liegt das Problem. Es funktioniert, bis es nicht mehr funktioniert. In KMUs ist das besonders häufig, weil Teams klein sind, Zuständigkeiten breit verteilt sind und Stellvertretungen selten bewusst aufgebaut werden. Der Softwarebetrieb läuft parallel zum Tagesgeschäft und bekommt oft nicht die Aufmerksamkeit, die er eigentlich bräuchte. Solange Prozesse funktionieren, bleibt fehlende Ownership unsichtbar. Bei Legacy-Systemen wie Delphi oder Access verschärft sich die Situation. Das verfügbare Know-how ist geringer, die Einarbeitung dauert länger und ohne saubere Übergabe wird der Betrieb schnell unberechenbar.

Wenn Wissen und Verantwortlichkeiten fehlen, wird der Betrieb nicht nur unsicherer. Er wird teurer. In Produktion wird er schneller kritisch, weil ein Ausfall Prozesse stoppt.

Diese Risiken entstehen, weil in der Praxis meist zwei Dinge fehlen, die den Betrieb erst wirklich stabil machen: Betriebskompetenz, also die Fähigkeit, das System im Alltag und im Ernstfall aktiv zu steuern. Und Knowledge-Ownership, also Wissen und Verantwortung, die im Unternehmen verankert sind, statt in einzelnen Köpfen oder nur beim Dienstleister.

Bevor wir über Lösungen reden, klären wir kurz die Begriffe und deren Bedeutung im Alltag. Betriebskompetenz bedeutet, dass Du jederzeit handlungsfähig bist, auch ohne Schlüsselperson. Du kannst im Alltag und im Störfall verlässlich beantworten:

• Was passiert gerade im System?
• Warum tritt der Fehler auf?
• Welche Auswirkungen hat das auf Prozesse und Produktion?
• Was ist der schnellste sichere Weg zur Behebung?
• Wie kommen Updates in die Produktion, ohne Stillstand zu riskieren?

Knowledge Ownership (übersetzt Wissenshoheit) bedeutet, dass dieses Wissen nicht bei einer Person oder nur bei einem Dienstleister liegt. Wissen ist im Unternehmen verankert. Mit klaren Zugängen, klaren Verantwortlichkeiten und Unterlagen, die im Ernstfall genutzt werden.

Das Problem entsteht selten an einem einzelnen Punkt. Es entsteht über Jahre.

Wissen ist vorhanden, aber nicht nutzbar

Viele Unternehmen haben Dokumente, Tickets oder Wikis. Im Ernstfall helfen jedoch keine langen Beschreibungen, sondern klare, aktuelle Schritte.

Betrieb ist nicht als Verantwortung verankert

Betrieb passiert nebenbei. Aufgaben verteilen sich informell. Das funktioniert, bis mehrere Systeme betroffen sind oder eine Schlüsselperson fehlt.

Projekte liefern Ergebnisse, aber keine betreibbare Übergabe

Nach dem Go Live gibt es oft keine klare Betriebsübergabe. Das System läuft, aber Zugänge, Abläufe, Verantwortlichkeiten und typische Fehlerbilder sind nicht so festgehalten, dass ein Team es sicher betreiben und weiterentwickeln kann.

Übergaben werden unterschätzt

Partnerwechsel oder Personalwechsel passiert, aber die Übergabe ist nicht verlässlich. Dann fehlt nicht nur Wissen, sondern auch Zugang, Rechte, Entscheidungslogik und Routine.

Wenn ein System ohne Schlüsselperson plötzlich unsicher wird, braucht es wieder Klarheit im Betrieb. Ziel ist, dass Du Updates und Weiterentwicklung wieder sicher steuern kannst.

Kurz die Reihenfolge, die sich bewährt:

• Stabilisieren: Zugänge und Rechte klären, Backups und Restore prüfen, Logs und Monitoring sichtbar machen, Incident-Ablauf festlegen
• Verstehen: Systemübersicht pro kritischen Prozess erstellen, typische Fehlerbilder erfassen, erste Runbooks aufbauen
• Absichern: Rollen und Stellvertretungen definieren, Deployment und Release Ablauf festlegen, Eskalation und Onboarding etablieren

So setzt soxes das um

Wir übernehmen solche Systeme mit Fokus auf Betrieb. Das heisst: zuerst Stabilität, dann Systemverständnis, dann Ownership, damit Du nicht mehr von Einzelpersonen abhängig bist, auch bei Legacy-Systemen wie Delphi, Access, PHP oder LabVIEW.

Wenn ein System kritisch ist, reicht «die IT kümmert sich» nicht. Du brauchst klare Verantwortlichkeiten, die auch in KMUs funktionieren.

Ein praxistaugliches Rollenmodell sieht oft so aus:

• Incident Lead: steuert den Incident und sorgt für Struktur und Tempo
• System Owner: entscheidet nach Business Auswirkung und priorisiert, was zuerst wieder laufen muss
• Technischer Owner: führt Analyse und Behebung und koordiniert technische Massnahmen
• Kommunikation: informiert betroffene Teams und Stakeholder und koordiniert Updates nach innen und falls nötig nach aussen

Warum ist die Produktion besonders anfällig?

In der Produktions- und Industriebranche zeigt sich fehlende Ownership schneller als in klassischen Office-Prozessen. Weil Systeme nicht nur unterstützen, sondern direkt beeinflussen, ob gefertigt, verpackt oder ausgeliefert werden kann. Oft hängen ERP, MES, Maschinen-Daten, Scanner, Etikettierung, Lager und Qualitätssicherung zusammen. Wenn an einer Stelle Wissen oder Verantwortung fehlt, wird aus einem kleinen Fehler schnell ein Stillstand.

Genau deshalb braucht Produktion nicht nur stabile Systeme, sondern Betriebskompetenz, die auch im Störfall trägt, unabhängig davon, wer gerade verfügbar ist.