Whiteboard-Wahrheiten: Warum die Systemlandschaft im Kopf des ältesten Mitarbeiters hängt

Es ist ein vertrautes Bild in deutschen Mittelstandsunternehmen: Die Geschäftsführung beschließt ein Digitalisierungsprogramm mit sechsstelligen Volumina, Beratungsmandate werden vergeben, Pilotprojekte angestoßen. Gleichzeitig hängt im Besprechungsraum nebenan ein Whiteboard, auf dem mit halb verwischten Markern die Systemlandschaft skizziert ist – Pfeile, die seit Monaten niemand aktualisiert hat, Abkürzungen, die nur der Konstrukteur selbst entschlüsseln kann. Wer nachfragt, erhält die Auskunft, das wisse schon Herr Brandt, der seit 24 Jahren im Haus sei.

Die Paradoxie der analogen Architektur

Das eigentliche Problem ist nicht das Whiteboard an sich. Whiteboards sind ein hervorragendes Werkzeug für Workshops, für gemeinsames Denken, für den Moment, in dem eine Idee sichtbar wird. Das Problem beginnt dort, wo das flüchtige Werkzeug zur einzigen Dokumentation wird. Wenn die Systemlandschaft nicht in einem gepflegten, versionierten Überblick existiert, sondern in Fotos von Flipcharts und in der Erinnerung weniger Personen, dann ist die IT-Architektur faktisch analog organisiert – trotz vollständig digitaler Systeme.

Die Folgen sind bekannt, werden aber selten systematisch benannt. Anschaffungsentscheidungen fallen doppelt, weil niemand weiß, dass eine Funktion bereits existiert. Schnittstellen werden neu gebaut, obwohl eine alte Variante still in Produktion läuft. Und bei jedem Personalwechsel – sei es durch Ruhestand, Kündigung oder Krankheit – verliert das Unternehmen unwiderruflich Wissen, das nirgendwo anders existiert. Die previous diskutierte Abhängigkeit von Eigenbau-Software und einzelnen Schlüsselpersonen erhält hier ihre Ergänzung: Nicht nur das Wissen um einzelne Systeme ist fragil, sondern der Überblick über das Ganze.

Warum die Übersicht fehlt, obwohl Werkzeuge genug existieren

Interessant ist die Frage, warum dieser Zustand so hartnäckig bestehen bleibt. Es mangelt nicht an Werkzeugen: Von einfachen Diagramm-Werkzeugen über spezialisierte Architekturplattformen bis zu ERP-eigenen Modulübersichten steht vieles bereit, oft bereits in bestehenden Lizenzen enthalten. Das Hindernis liegt woanders.

Erstens fehlt der Auftrag. Eine Systemlandschaft zu dokumentieren ist niemandem explizit zugewiesen; sie entsteht historisch gewachsen, und jeder erkennt den Bedarf, aber keiner trägt die Verantwortung. Zweitens scheitert es am Perfektionsanspruch: Viele Unternehmen glauben, eine Architekturdokumentation müsse vollständig und toolgestützt sein, bevor sie beginnt. Das Ergebnis ist, dass sie nie beginnt. Drittens wirkt der Überblick unsexy. Er erzeugt keine sichtbaren Neuerungen, keine Schlagzeile im Geschäftsbericht, keinen Effekt auf das nächste Kundengespräch.

Der pragmatische Einstieg vor der nächsten Anschaffung

Die gute Nachricht: Es bedarf keiner Großinitiative. Ein pragmatischer Einstieg lässt sich in wenigen Schritten erreichen.

1. Bestandsaufnahme in einer Sitzung: Ein Workshoptag mit IT-Verantwortlichen und je einem Vertreter der Fachbereiche reicht, um die zentralen Systeme, ihre Funktion und ihre wichtigsten Verbindungen zu erfassen. Das Ergebnis darf unvollkommen sein – es muss nur existieren und geteilt werden.
2. Ein einziges, gepflegtes Dokument: Ob Diagramm-Tool, Tabellenkalkulation oder Wiki ist zweitrangig. Entscheidend sind ein fester Ablageort, ein erkennbarer Stand und ein klarer Verantwortlicher, der Änderungen einpflegt.
3. Verknüpfung mit bestehenden Prozessen: Jede Anschaffungsentscheidung, jedes Projekt-Initiativgesuch und jede Budgetanfrage sollte die Frage beantworten: Welches bestehende System ist betroffen, und wie ist es im Überblick verzeichnet?
4. Wissen vom Kopf ins Blatt: Der älteste Mitarbeiter mit dem größten impliziten Wissen wird gezielt interviewt, bevor er in Rente geht. Nicht irgendwann – sondern jetzt.

Transparenz als Voraussetzung, nicht als Projekt

Wer diesen Überblick besitzt, verhandelt anders. Lieferantengespräche verlaufen auf Augenhöhe, weil die eigenen Schwachstellen benannt sind statt geraten. Doppelinvestitionen lassen sich vermeiden, Integrationen realistischer kalkulieren. Und die immer wieder geführte Debatte über Sanierung, Umgehung oder Neubau von Altsystemen gewinnt eine sachliche Grundlage, weil erstmals klar ist, was tatsächlich läuft und was es kostet.

Die Systeminventur ist dabei kein Selbstzweck und keine Bürokritik an Whiteboards und Flipcharts. Sie ist die Voraussetzung dafür, dass die investierten Digitalisierungsmillionen dort ankommen, wo sie wirken. Bevor die nächste Anschaffungsdiskussion beginnt, lohnt sich der Blick auf die eigene Wandtafel – und die Frage, ob das Wissen, das darauf skizziert ist, bereits einen Stellvertreter hat.