IT-Betrieb sichern, wenn Wissen fehlt

Viele Unternehmen stehen nicht vor der Frage nach neuer Software, sondern vor einem anderen Risiko: Wissen geht verloren, und der Betrieb wird abhängig.

Der Entwickler geht in Rente. Er wird krank. Er verlässt das Unternehmen. Und plötzlich steht ein System da, das jahrelang «einfach lief», aber niemand kann erklären, wie es wirklich funktioniert. Besonders heikel wird es, wenn es um ältere Systeme geht, zum Beispiel Anwendungen auf Delphi oder Access. Dann ist nicht nur das Wissen weg, sondern oft auch die Verfügbarkeit von Spezialisten. Das eigentliche Risiko ist oft nicht das System selbst, sondern die Abhängigkeit davon.

1. Incident: Störung, die den Betrieb beeinträchtigt und aktiv gesteuert werden muss.
2. Runbook: Schrittfolge zur Diagnose und Behebung eines typischen Vorfalls.
3. Restore-Test: Prüfung, ob ein Backup wirklich wiederherstellbar ist.
4. Systemübersicht: Überblick über Systeme, Abhängigkeiten, Datenflüsse und Zuständigkeiten.
5. Deployment-Ablauf: Wie Änderungen reproduzierbar in Produktion gebracht werden.

Diese Seite beantwortet Dir folgende Fragen:

• Woran erkenne ich, dass unser IT-Wissen nur bei einzelnen Personen liegt?
• Welche Risiken entstehen daraus im Betrieb und in der Produktion?
• Wie sichere ich den IT-Betrieb, wenn niemand das System wirklich versteht?
• Welche Verantwortlichkeiten brauche ich, damit der Betrieb verlässlich läuft?
• Welche Dokumentation brauche ich wirklich, damit der Betrieb funktioniert?
• 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, Verantwortungen breit verteilt sind und Stellvertretungen selten bewusst aufgebaut werden. Betrieb läuft parallel zum Tagesgeschäft und bekommt oft nicht die Aufmerksamkeit, die es eigentlich bräuchte. Solange Prozesse funktionieren, bleibt fehlende Ownership oft unsichtbar. Bei Legacy-Systemen wie Delphi oder Access verschärft sich die Situation zusätzlich. Das Knowhow ist kleiner, Einarbeitung dauert länger und ohne saubere Übergabe wird 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.