Das Excel-Problem ist zurück — diesmal baut es Software

In jedem etablierten Unternehmen gibt es irgendwo eine Tabelle, die nicht tragend sein sollte und es ist.

Ein Fehler war das nicht. Jemand brauchte eine Berechnung und hatte sie an einem Nachmittag — die damals richtige Entscheidung. Was danach geschah, war überhaupt keine Entscheidung.

Excel hat das Rechnen demokratisiert, und das war gut

Das gehört vorangestellt, weil das Argument regelmäßig für sein Gegenteil gehalten wird. Tabellenkalkulation hat Rechenleistung in die Hände von Menschen gelegt, die das Geschäft verstanden und nicht programmierten. Der daraus entstandene Wert ist enorm und weitgehend ungezählt. Jede Erklärung des Problems, die beim Werkzeug ansetzt, hat die Lage falsch gelesen.

Was Tabellen zugleich beseitigt haben, ist die Reibung, die früher ein zweites Gespräch erzwang. Als das Bauen eine Abteilung, ein Budget und sechs Wochen kostete, fragte jemand, wofür es gut sei, wem es gehören solle und was passiere, wenn es falsch liegt. Nicht weil diese Leute klüger waren, sondern weil die Herstellungskosten einen natürlichen Prüfpunkt erzeugten.

Wie aus Bequemlichkeit Infrastruktur wird

Der Ablauf ist gleichförmig genug, um ihn aufzuschreiben.

1. Eine Berechnung

   Eine Person braucht eine Antwort, die kein System liefert. Die Tabelle kostet einen Nachmittag und ist zweifellos richtig.

2. Ein Workflow

   Zwei Kollegen nutzen sie mit. Sie bekommt Reiter, Verweise und eine Farbkonvention, die alle verstehen und niemand aufgeschrieben hat.

3. Ein Prozess

   Ein Monatstermin hängt daran. Sie wird per E-Mail verschickt statt geteilt, also existieren mehrere Fassungen, und eine davon gilt aus Gewohnheit.

4. Eine Abhängigkeit

   Ein anderes Team nutzt das Ergebnis. Jemand baut einen Bericht darauf. Es gibt jetzt Abnehmer, die die Formeln nie gesehen haben.

5. Geschäftskritisch

   Der Ersteller ist weg. Der Prozess kann nicht pausieren. Seit drei Jahren hat niemand die Formeln gelesen, und niemand möchte derjenige sein, der sie ändert.

Kein Schritt dieser Kette ist unvernünftig, und keiner meldet sich an. Genau das ist das Problem. Eingeordnet wird meist rückblickend, während einer Störung, in einem Raum, in dem jemand fragt, wem das eigentlich gehört — und die Antwort dauert.

Excel war nie das Problem. Das Problem war, dass ein billiges Werkzeug die Verantwortung für einen teuren Prozess übernahm.

KI demokratisiert das Bauen, und auch das ist gut

Alles Obenstehende gibt es nun in anderer Geschwindigkeit. Ein Fachbereich erstellt eine Anwendung an einem Nachmittag, einen Freigabeprozess vor dem Mittagessen und einen Agenten, der eingehende Dokumente liest und in ein führendes System schreibt, noch bevor die Besprechung darüber zu Ende ist.

Das ist ein echter Gewinn. Die Alternative — eine Warteschlange vor einer IT-Abteilung, die im nächsten Quartal dazukommt — war nie der bessere Zustand. Unternehmen, die das unterdrücken, verlieren gegen Unternehmen, die es nutzen.

Nur ist der Weg von der Idee zur Geschäftsabhängigkeit von Jahren auf Wochen geschrumpft, während der organisatorische Apparat, der Abhängigkeiten einordnet, sich nicht bewegt hat. Die Lücke zwischen dem, was gebaut werden kann, und dem, was gesteuert wird, ist kein neues Problem. Es ist ein altes Problem, das schneller eintrifft als der Prozess, der es auffangen soll.

Der Critical Process Test

Die nützliche Frage ist nicht, ob etwas ordentlich gebaut wurde. Sie lautet, was daran hängt. Eine Frage trennt beides.

Was passiert, wenn dieses Werkzeug einen Tag lang falsch liegt?

Die Antwort ordnet es auf einer Skala ein, die konzeptionell und nicht wissenschaftlich ist — und das genügt. Bequemlichkeit: jemand ärgert sich. Produktivität: die Arbeit wird langsamer. Operative Abhängigkeit: ein Prozess steht oder liefert ein falsches Ergebnis, das gefunden und korrigiert werden muss. Geschäftskritisch: Produktion, Geld, Compliance, Sicherheit oder Kundenvertrauen sind betroffen, bevor es jemand bemerkt.

Wo ein Werkzeug oberhalb der ersten Stufe landet, folgen sechs weitere Fragen — und alle sind billig zu stellen.

• Wem gehört es — als benannte Person, nicht als Abteilung?
• Wer versteht es gut genug, um es gefahrlos zu ändern?
• Wie wird es getestet, und wogegen?
• Woran würde jemand merken, dass es falsche Ergebnisse liefert?
• Was ist die Rückfallebene, und hat sie jemals jemand benutzt?
• Von welchen Daten hängt es ab, und wer verantwortet deren Richtigkeit?

Das ist kein Governance-Programm. Es ist ein Inventar — und deutlich billiger zu schreiben, solange die Liste noch kurz ist.

Was Unternehmen tatsächlich tun sollten

Nicht: KI-erstellte Software verbieten. Diese Antwort scheitert an sich selbst — sie verschenkt die Produktivität, und gebaut wird trotzdem, nur weiter außerhalb des Blickfelds. Die brauchbare Antwort ist, nach Kritikalität einzuordnen und die Einordnung den Maßstab setzen zu lassen.

1. Geringe Kritikalität

   Frei ausprobieren. Keine Freigabe, keine Dokumentationspflicht, keine Zeremonie. Das meiste Gebaute gehört hierher, und es anders zu behandeln bringt einer Organisation bei, heimlich zu bauen.

2. Mittlere Kritikalität

   Ein benannter Eigentümer, so viel Dokumentation, dass ein Nachfolger weiterkommt, und Tests, die den offensichtlichen Fehler fangen. Der Aufwand sind Stunden, keine Wochen.

3. Hohe Kritikalität

   Architekturprüfung, eine Sicherheitsgrenze, über die jemand tatsächlich nachgedacht hat, eine Überwachung, die ein falsches Ergebnis bemerkt, und eine Rückfallebene, die mindestens einmal geübt wurde.

4. Geschäftskritisch

   Professionelle Lebenszyklusbetreuung und ausdrückliche Verantwortung. Taucht der Prozess in einem Notfallplan auf, gehört das tragende System unter dieselbe Disziplin wie jedes andere kritische Asset — unabhängig davon, wer es gebaut hat und wie schnell.

Die Einordnung zählt mehr als der daran hängende Maßstab. Die meisten Organisationen wissen, wie man ein kritisches System betreibt. Was sie nicht mehr wissen, ist, welche ihrer Systeme kritisch sind — weil die Liste schneller wächst, als jemand sie fortschreibt.

Warum das in eine Due Diligence gehört und nicht nur in ein IT-Review

Für einen Gesellschafter oder Käufer ist das keine Frage technischer Hygiene. Ein Geschäft, dessen kritische Prozesse auf undokumentierten Werkzeugen ruhen, trägt eine nicht erfasste Kostenposition: Irgendwann bezahlt jemand den Nachbau, und den Zeitpunkt bestimmt nicht das Management.

Es lässt sich zudem einfach prüfen. Fragen Sie, welche Prozesse stehen blieben, dann, was sie trägt, dann, wem diese Dinge gehören. Der Abstand zwischen der ersten und der dritten Antwort ist der Befund — dieselbe Frage, die eine Technologie- und KI-Due-Diligence einem Target stellt, und dieselbe, die ein Aufsichtsgremium über das eigene Unternehmen stellen sollte.

Demokratisiertes Bauen ist die Chance. Ungesteuerte Abhängigkeit ist das Risiko.

Die verwandte Frage — warum Herstellungskosten aufgehört haben, ein brauchbarer Anhaltspunkt zu sein — steht in Billig zu bauen. Teuer zu scheitern.