Einleitung

Im vorherigen Teil haben wir bestätigt, dass EUC die „Urform des Citizen Developments“ ist und dass Kami Excel eines seiner Sinnbilder darstellt. Die nächste Frage lautet daher: War Kami Excel wirklich der Bösewicht?

Kurz gesagt: Kami Excel selbst war nicht böse. Zum Zeitpunkt seines Auftritts war es ein Retter für die Teams vor Ort und sorgte für eine explosionsartige Produktivitätssteigerung. Dass es später in ein „negatives Erbe“ abglitt, lag nicht an den Grenzen oder Fehlern von Excel, sondern an mangelndem organisatorischem Management und an der niedrigen IT-Literacy in der Gesellschaft.

Geht man noch weiter, ist die Bezeichnung Kami Excel im Kern nichts weiter als ein späterer Spottbegriff. Hätte eine Gesellschaft existiert, in der alle Formeln und VBA verstehen, hätte es sogar als ideales, reaktionsschnelles Automatisierungsfundament funktioniert.

Die gesamte Serie

Warum Kami Excel ein Retter war

In den 1980er- und 1990er-Jahren standen viele japanische Unternehmen vor einer unbequemen Realität: Die IT-Abteilungen konnten nicht sämtliche Prozesse des Unternehmens tragen.

  • IT-Fachkräfte waren chronisch knapp.
  • Die Kernsysteme waren starr, Änderungen dauerten Monate.
  • Gleichzeitig änderte sich die Arbeit an der Front täglich – Geschwindigkeit war alles.

In dieser Lage entfaltete Excel als Ad-hoc-Werkzeug enorme Wirkung. Die Teams entwarfen Eingabemasken, automatisierten Berechnungen mit Formeln und schrieben bei Bedarf Makros – damit konnten sie den „operativen Stillstand“ aus eigener Kraft verhindern.

Kami Excel war damit die Waffe, mit der die Teams die IT-Engstelle ihrer Organisation durchbrachen.

Woher der Begriff „Kami Excel“ stammt

Wichtig ist: Den Namen „Kami Excel“ verwendete damals niemand. Für die Anwender war Excel schlicht ein Lebensretter – ein cleverer Trick, eine Form des praktischen Wissens.

Der Begriff verbreitete sich erst später. Als hochgradig personalisierte Dateien zurückblieben, die niemand mehr lesen konnte, begannen die Menschen, sie sarkastisch so zu nennen. Kami Excel ist daher kein Begriff, der die damaligen Probleme der Teams beschreibt, sondern ein nachträglich aufgeklebtes Spottlabel.

Im Kern war es ein „für alle lesbares System“

Bei nüchterner Betrachtung sind Excel-Formeln und VBA keine geheimen Codes. Mit einer grundlegenden IT-Literacy kann jede Person sie nachvollziehen.

Wäre die Kultur entstanden, dass „Formeln und Skripte lesen und schreiben“ selbstverständlich ist, wäre Kami Excel keine „unverständliche Blackbox“ geblieben, sondern ein transparentes Automatisierungsgerät, auf das Teams direkt reagieren könnten.

Mit anderen Worten: Kami Excel hätte das ideale Produktivitätswerkzeug sein können – doch mangelnde Literacy machte es zum paradoxen Bösewicht.

Wie der Retter zum negativen Erbe wurde

Die Realität sah jedoch anders aus.

  • Selbst IT-Fachleute mieden Excel-spezifische Funktionen und VBA.
  • Dateien, die „eigentlich jede Person verstehen sollte“, wurden zu unantastbaren Blackboxen.
  • Spätere Generationen konnten nur noch spöttisch auf sie zeigen und sie Kami Excel nennen.

Das Phänomen Kami Excel war also kein Excel-Fehler, sondern ein Trugbild aus fehlender Schulung und Governance.

Der Abstieg in das negative Erbe

Mit der Zeit verwandelte sich die improvisierte Waffe in ein Risiko für die Organisation.

  1. Aufblähung und Blackboxing
    Tausende Zellen waren mit Formeln gefüllt, niemand hatte mehr den Überblick.

  2. Personenbindung
    Wechselte die Erstellerin oder der Ersteller die Position oder das Unternehmen, ging das Wissen vollständig verloren.

  3. Fehlende Governance
    Die IT-Abteilung stufte es als „Wildwuchs aus der Linie“ ein und ließ es laufen – mit Sicherheits- und Auditlücken im laufenden Betrieb.

So wurde Kami Excel zu einem unvermeidlichen negativen Erbe für die Organisation.

Technische Grenzen, die das verstärkten

Strukturelle Grenzen von Excel selbst befeuerten den Blackbox-Effekt.

  • Kein Schema: Es gibt keine databasetypischen Typen und Constraints, Spalten wachsen chaotisch.
  • Schwierig zu versionieren: Historien entstehen nur durch Dateikopien; Änderungen lassen sich weder verfolgen noch zusammenführen.
  • Fehlendes Betriebsdesign: Zugriffsrechte oder Transaktionssicherheit fehlen, die Grundlage als produktives System ist schwach.

Excel als Ersatz für Geschäftssysteme oder Datenbanken zu nutzen war damit ein Bruch mit den Grenzen des Werkzeugs – und dieser Bruch beschleunigte das Kami-Excel-Phänomen.

Eine universelle Struktur der Geschichte

Die Geschichte von Kami Excel zeigt, dass „kurzfristige Rettung“ und „langfristige Verschuldung“ stets Rücken an Rücken stehen.

Wir dürfen aber nicht vergessen, dass Kami Excel ursprünglich ein Spottbegriff späterer Generationen ist – in einer Gesellschaft mit verbreiteter IT-Literacy wäre es ein Held geblieben. Es ist keine reine Misserfolgsgeschichte, sondern das Faktum, dass die Heldinnen und Helden an der Front Früchte schufen, die niemand pflegte.

Und das wird sich kaum ändern. Eine Gesellschaft, die über Nacht echte IT-Literacy erlangt, ist wenig wahrscheinlich. Darum müssen wir bei moderner No-Code-/Low-Code-Entwicklung oder RPA darauf achten, nicht denselben Mechanismus zu wiederholen.

Retter und Legacy-Fabriken liegen immer nur Papierdünn auseinander – diese historische Lehre sollten wir nicht vergessen, wenn wir über die Zukunft des Citizen Developments nachdenken.

Nächster Teil: Licht und Schatten moderner Citizen-Development-Plattformen (3/7)