In den meisten polnischen KMU gibt es Dutzende kleiner Werkzeuge, die darüber entscheiden, ob heute überhaupt eine Rechnung rausgeht. Excel-Makros, Access-Datenbanken, PowerShell-Skripte, SQL-Prozeduren, die irgendwann ein ehemaliger IT-Mitarbeiter ergänzt hat. Was sie genau tun, weiß niemand mehr. Solange sie laufen — fragt niemand.
Wir nennen das Shadow Development: Software, die außerhalb der offiziellen IT entsteht und läuft, ohne Dokumentation, ohne Versionskontrolle, oft ohne das Wissen des Inhabers. Das ist nicht dasselbe wie Shadow IT (SaaS-Käufe an der IT vorbei). Shadow Development ist leiser und gefährlicher, weil es meist mitten im Prozess sitzt — in der Rechnungsstellung, in der Abrechnung, im Export zur Buchhaltung. Und es hat in der Regel genau einen Autor, der sich daran erinnert, warum ein bestimmtes IF so aussieht, wie es aussieht.
Richtig auffallen wird dir das erst an dem Freitagnachmittag, an dem dieser Autor nicht mehr im Haus ist und der Vertrieb dich fragt: „Warum sehen die Provisionen heute komisch aus?"
Wie es im Alltag aussieht
Bei einem unserer Kunden — einem 28-köpfigen Hersteller von Kunststoffverpackungen, der mit enova365 und ein paar Google Sheets arbeitet — haben wir genau diese Werkzeuglandschaft auditiert. Ergebnis: 34 Skripte und Makros, davon hatten nur 9 einen aktiven Autor im Unternehmen. Der Rest stammte von einem früheren Haus-ITler, zwei inzwischen gegangenen Buchhalterinnen und einem Praktikanten vor vier Jahren.
Das größte Risiko steckte in einer einzigen Excel-Datei: dem Makro, das die Vertriebsprovisionen berechnet. Der Autor war 18 Monate vorher gegangen. In der Zwischenzeit unterschrieb der Vertriebsleiter Monat für Monat die Provisionsabrechnungen — ohne zu wissen, dass seit einem Vertragszusatz aus 2024 ein Bonus anders berechnet wurde, als es der Zusatz vorsah. Die Firma hatte Provisionen in Höhe von 47.000 PLN zu viel ausgezahlt, bevor jemand es überhaupt bemerkte. Und nicht der Vertrieb bemerkte es, sondern das Steuerbüro beim Jahresabschluss.
Platz zwei: ein PowerShell-Skript, das jede Nacht lief und Dateien von einem Netzwerkordner auf den FTP-Server eines Großkunden kopierte. Welcher Kunde, welcher Server, was passiert, wenn es ausfällt — wusste niemand mehr. Es war tatsächlich ein Jahr zuvor ausgefallen — und niemand hatte es gemerkt, weil der Kunde die fehlenden Dateien nie reklamierte.
Platz drei: eine Access-Datenbank, in der die Produktionsplanung fünf Linien verwaltete. Sie funktionierte, bis jemand ein neues Material eintragen musste. Dann stellte sich heraus, dass das Feld „Materialcode" in einer Tabelle 10 Zeichen hatte und in einer anderen 12 — und dass auch der merkwürdige Schritt, in dem der Planer „die Abfrage Q7 öffnet und dreimal den Pfeil nach unten drückt", Teil des Prozesses war.
Das ist keine Pathologie. Das ist der Normalzustand eines Unternehmens, das zehn, fünfzehn Jahre lang schneller gewachsen ist als seine IT.
Warum das passiert
Shadow Development entsteht aus denselben Gründen wie Shadow IT: Die offiziellen Werkzeuge decken nicht ab, was die Leute tun müssen. Mit einem Unterschied: Die Einstiegshürde ist niedriger. Wer eine Excel-Formel schreiben oder ein Makro aufzeichnen kann, kann sich selbst „helfen". Und weil es funktioniert — protestiert niemand.
Drei typische Quellen:
- Das ERP kann nicht, was gestern gebraucht wird. Der Vertrieb bekommt aus dem ERP einen Umsatzbericht, aber keine Provisionsberechnung. Also baut jemand ein Makro, das macht, was das ERP nicht macht. Das Problem von heute ist gelöst. Das Makro bleibt und wird Teil des Prozesses.
- Der frühere Haus-ITler liebte PowerShell. Jedes Problem wurde ein Skript. Jedes Skript startete aus dem Task Scheduler irgendeines Servers. Eine Liste hat nie jemand bekommen. Nach seinem Weggang weiß das Unternehmen nicht einmal, was heute Nacht passieren wird.
- Eine Person hat sich „ihr eigenes System" gebaut. Meist eine Access-Datenbank oder ein Google Sheet mit Apps Script. Es funktioniert — und irgendwann nutzen drei weitere Personen es mit. Spätestens dann ist es ein produktives System des Unternehmens, nur ohne Vertrag und ohne Backup.
So geht die Inventur
Dafür brauchst du keine Werkzeuge für 20.000 PLN. Du brauchst eine Person, die sich zwei bis drei Wochen Zeit nimmt, und ein schlichtes Blatt mit vier Spalten: Name, was es tut, wer es kennt, was kaputtgeht, wenn es ausfällt.
Schritt 1 — Liste die Orte auf, an denen Code lebt. Suche nicht nach Code, suche nach Orten. Die üblichen Verdächtigen im polnischen KMU:
- Verzeichnisse wie
\\server\daten\makros,\\server\it\skripte,C:\Scriptsauf dem Server, - Task Scheduler auf jedem Server (auch auf den ERP-Applikationsservern),
.xlsm-,.accdb-,.mdb-Dateien auf Abteilungsfreigaben (Vertrieb, Buchhaltung, Planung),- cron- oder systemd-Timer auf Linux, falls vorhanden,
- Apps Script in Google Workspace, Power Automate und Power Query in Microsoft 365,
- Stored Procedures und Jobs in der SQL-Server-Datenbank des ERP (Comarch Optima, enova365, Subiekt — bei allen kann man Prozeduren ergänzen),
- „Outlook-Makros" auf den Arbeitsplätzen langjähriger Mitarbeiter.
Schritt 2 — frage für jeden Eintrag drei Personen: wer hat es geschrieben, wer versteht es heute, was passiert, wenn es ausfällt. Wenn auf eine dieser Fragen „keine Ahnung" die Antwort ist — markiere den Eintrag rot.
Schritt 3 — stelle für jeden roten Eintrag eine Frage: berührt der Prozess, den dieses Werkzeug stützt, Umsatz, Steuerpflichten oder Sicherheit? Wenn ja, wandert er ganz oben auf die Reparaturliste.
Das ist alles. Zwei Wochen, eine Tabelle, keine Magie. Die erste Version muss nicht vollständig sein — sie muss ehrlich sein.
Was du mit dem Fund anfängst
Es gibt keine einzige richtige Antwort. Es gibt vier, je nach Wert und Risiko:
- Dokumentieren und stehen lassen. Wenn ein Skript einfach ist, seit Jahren läuft und mindestens eine Person es versteht — reicht ein Absatz Beschreibung und eine Kopie in einem Repository (auch ein OneDrive-Ordner mit Versionshistorie reicht). Nicht alles muss umgeschrieben werden.
- In eine kontrollierte Form überführen. Berührt das Werkzeug Geld (Provisionen, Rechnungen, Preislisten, Lieferantenabrechnung) oder Sicherheit (Zugänge, Backups, Export an die Buchhaltung) — gehört es in etwas mit Versionskontrolle, Tests und einem klaren Verantwortlichen. In der Regel: ein schlichtes Skript in einem Git-Repo oder das Makro umgeschrieben als Prozedur im ERP.
- Durch eine Funktion des offiziellen Systems ersetzen. Manchmal existiert das Provisionsmakro nur, weil nie jemand das Provisionsmodul im ERP aktiviert hat. Statt umzuschreiben, zuerst den ERP-Anbieter fragen, ob das inzwischen nicht Standard ist.
- Abschalten. Ein beträchtlicher Teil der Skripte tut nichts Nützliches mehr — sie erzeugen einen Bericht, den niemand liest, oder kopieren eine Datei, die niemand braucht. Eine Woche aus — fragt niemand, bleibt aus.
Für jedes Werkzeug, das bleibt, bestelle einen zweiten Menschen. Keine Dokumentation — einen Menschen. Dokumentation veraltet, ein zweiter Mensch stellt Fragen.
Wie es weitergeht
Shadow Development verschwindet nicht, weil dein Unternehmen weiter schneller wächst als seine offizielle IT. Es geht darum, zu wissen, was du hast — und dafür zu sorgen, dass die wichtigen Dinge einen Verantwortlichen, einen zweiten Menschen und einen offiziellen Platz haben.
Wenn du nicht weißt, wo du anfangen sollst — fang mit einer Stunde Gespräch an. Wir führen diese Art von Audit regelmäßig durch; es taucht fast immer etwas auf, womit niemand gerechnet hat. Besser, es taucht beim Audit auf als an einem Freitagnachmittag, an dem die Provisionen komisch rauskommen.
Solange es läuft, fragt niemand. An dem Tag, an dem es ausfällt, fragt meistens schon der Kunde.