Weil schlecht gestaltete Informationssysteme jede Prozessverbesserung wieder auffressen: Medienbrüche, Schatten-Excel, doppelte Datenerfassung, unklare Verantwortlichkeiten und lange Entscheidungswege entstehen nicht trotz, sondern wegen der vorhandenen Systemlandschaft. Sie erkennen das an Szenen aus Ihrem Alltag. Eine Entscheidung wartet auf eine Zahl, die erst aus drei Systemen zusammengetragen werden muss. Zwei Berichte über denselben Sachverhalt widersprechen sich, und die Runde diskutiert über die Herkunft der Daten statt über die Maßnahme. Dieselbe Information wird an drei Stellen erfasst, weil keine Schnittstelle sie weiterreicht. Und wenn ein Datensatz falsch ist, ist niemand zuständig, weil IT und Fachbereich sich die Verantwortung gegenseitig zuschieben. Keine dieser Szenen taucht in einem Projektstatus auf. Kosten verursachen sie trotzdem, nur verteilt und unsichtbar.

Diese Symptome sind keine IT-Pannen, sondern das erwartbare Ergebnis einer Landschaft, die aus Tools statt aus Prozessen entstanden ist. Ein Tool allein löst kein Prozessproblem. Wer Software kauft, bevor Abläufe, Entscheidungen, Rollen und Informationsbedarfe geklärt sind, digitalisiert die bestehende Unklarheit und erhöht den Aufwand, statt ihn zu senken. Wer Schnittstellen unterschätzt, zahlt doppelt: Eine unklare System-of-Record-Logik und Punkt-zu-Punkt-Verbindungen führen zu Fehlern, Verzögerungen und hohem Wartungsaufwand. Und wer fehlende Schnittstellen durch manuelle Übertragungen ersetzt, erhöht Fehlerquote, Durchlaufzeit und Frustration in einem Zug.

Erst vor diesem Hintergrund lohnt die Einordnung. Informationssysteme sind nicht nur IT-Anwendungen, sondern das Nervensystem Ihrer Organisation: Sie erfassen Ereignisse, strukturieren Daten, unterstützen Entscheidungen und ermöglichen transparente Zusammenarbeit. Operational Excellence verbindet Strategie, tägliche Steuerung, Standardarbeit, Problemlösung und kontinuierliche Verbesserung, und alle fünf laufen über Ihre Systeme. Deshalb sind Informationssysteme für Operational Excellence keine Begleitfrage, sondern die Voraussetzung: Die Balance aus Business-Nutzen, Datenqualität, Systemqualität, Sicherheit, Servicefähigkeit und Akzeptanz entscheidet, ob Ihre Prozessarbeit trägt.

Damit wird aus einem Effizienzthema ein Haftungsthema. Audit Trails, Dokumentation, Datenschutz, regulatorische Anforderungen und Nachweisführung müssen verlässlich verfügbar sein, und zwar in dem Moment, in dem geprüft wird, nicht drei Wochen später. Ein System, das Daten sammelt, aber Änderungen nicht nachvollziehbar macht, erzeugt genau das Risiko, das es beherrschen sollte. Für Sie als Entscheidungsträger:in heißt das: Die Qualität Ihrer Informationssysteme entscheidet mit darüber, wie belastbar Ihre Nachweise im Prüffall sind und wie schnell Sie sie vorlegen können.

Für österreichische Unternehmen ist diese Nachweisfähigkeit auch datenschutzrechtlich relevant: Verantwortliche müssen Verarbeitungstätigkeiten dokumentieren, Risiken bewerten und angemessene technische und organisatorische Maßnahmen umsetzen. Diese Maßnahmen sind regelmäßig auf ihre Wirksamkeit zu überprüfen. Informationssysteme müssen deshalb nicht nur Daten speichern, sondern Zuständigkeiten, Zugriffe, Änderungen und Nachweise so abbilden, dass sie im Prüf- oder Vorfallsfall nachvollziehbar vorliegen.

Das Ziel ist keine weitere Softwareeinführung, sondern eine integrierte Steuerungslogik: Prozessarchitektur, Datenmodell, Applikationslandschaft, Integrationslogik, Informationssicherheit, Service Management und Change Management folgen einer gemeinsamen Logik statt jeweils einer eigenen. Der Weg dorthin lässt sich in sechs Stufen gliedern. Jede Stufe liefert ein Ergebnis, das die nächste voraussetzt.

1. Ausgangslage und Business-Fokus verstehen. Sie nehmen Ihre Kernprozesse End-to-End auf, gemeinsam mit Entscheidungsbedarfen, Pain Points, Medienbrüchen und der tatsächlich genutzten Schatten-IT. Informationsflüsse, Datendomänen, System-of-Record und Schnittstellen werden visualisiert, damit sichtbar wird, wo eine Information entsteht und wo sie gebraucht wird. Business-Ziele und messbarer Nutzen werden entlang von Qualität, Geschwindigkeit, Transparenz, Compliance, Kosten und Resilienz definiert. Dazu kommen die betroffenen Rollen, Anwendungsgruppen, Werke, Standorte und Partner.

Der Fachbereich, denn Daten entstehen im Fachprozess und brauchen dort benannte Data Owner mit Definitionen, Qualitätsregeln und Pflegeprozessen, während die IT Werkzeuge, Integration und Kontrollen bereitstellt. Diese Zuordnung ist das Ergebnis der Stufen zwei und drei.

2. Zielarchitektur, Verantwortung und Sicherheit definieren. Sie erstellen ein Zielbild für Prozess-, Daten-, Applikations- und Integrationsarchitektur und legen Entscheidungsrechte und Ownership fest: Product Owner, Process Owner, Data Owner, Security Owner und Service Owner. Sie identifizieren die Entscheidungen, die durch bessere Informationen besser werden sollen, legen Erfolgskennzahlen und Informationsempfänger:innen fest und machen Systemgrenzen und Abhängigkeiten transparent. Auf dieser Stufe, nicht später, gehören außerdem Risikoanalyse, Zugriffskonzept sowie Backup- und Notfallkonzept als Anforderung in die Architektur. Sicherheit und Datenschutz, die erst nach dem Go-live nachgezogen werden, sind teuer, langsam und selten vollständig.

3. Daten- und Integrationsfundament bauen. Datenobjekte, Stammdatenregeln, Datenqualitätskriterien und Pflegeprozesse werden verbindlich festgelegt und dokumentiert. Dazu kommen ein Schnittstellenkatalog, einheitliche Integrationsmuster, Monitoring und ein Fehlerhandling, das Störungen sichtbar macht, statt sie zu verschlucken. Datenmigration, Archivierung und Historisierung planen Sie früh, weil sie später weder billiger noch einfacher werden. Dokumentierte Daten- und Prozessdefinitionen sind anschließend die Grundlage für jedes Reporting und jede Automatisierung, die darauf aufsetzt.

4. Pilot definieren und Anwendungskreis bestimmen. Sie wählen einen Pilotprozess mit hoher Wirkung und beherrschbarer Komplexität. Auch der Anwendungskreis wird bewusst festgelegt. Anwender:innen werden früh eingebunden, Prototypen getestet und Rückmeldungen in kurze Verbesserungszyklen überführt. Trainings, Rollenbeschreibungen, Arbeitsanweisungen und Supportkanäle stehen bereit, bevor der Pilot startet. Nach dem Go-live werden Nutzung, Prozessqualität und Datenqualität aktiv gemessen, statt auf Beschwerden zu warten.

5. Betrieb und Verbesserung verankern. Den Go-live begleiten Sie eng. Datenqualität und Nutzung werden gemessen, eine Support- und Verbesserungsroutine wird etabliert, Standards, Rollen und Schulungsunterlagen werden aktualisiert. Auf der Sicherheitsseite bleibt hier der Betriebsteil: Zugriffsrechte turnusmäßig prüfen, Backup und Notfallkonzept tatsächlich testen. Gesteuert wird über ein festes Set an Betriebs- und Wirkungskennzahlen, das früh zeigt, ob das System trägt oder ob die alten Workarounds zurückkehren.

6. Skalierung und kontinuierliche Weiterentwicklung. Erst danach skalieren Sie. Der Rollout wird nach Wertbeitrag, Risiko, Prozessreife und Datenreife priorisiert, nicht nach der Lautstärke einzelner Anforderungen. Ein Governance-Board entscheidet über Priorisierung, Architektur, Security, Daten und Change. Automatisierung, BI, KI und Self-Service erweitern Sie schrittweise und ausschließlich auf stabiler Datenbasis. Parallel bauen Sie Alt-Systeme, Doppelstrukturen und manuelle Workarounds konsequent ab, führen regelmäßige Prozess- und Systemreviews durch und spielen Lessons Learned in Standards und Systemlogik zurück.

Rund 90 Tage, wenn Sie in fünf Phasen vorgehen und den Piloten nicht nebenher laufen lassen. Das Ergebnis dieser 90 Tage ist kein fertiges System, sondern ein Beleg: ein Kernprozess, der messbar besser läuft, und eine Roadmap, die auf gemessenen Ergebnissen beruht statt auf Annahmen. Entscheidend ist die Reihenfolge. Die Security-Anforderungen stehen bereits im Design und nicht erst in der Stabilisierung.

Von Tag 0 bis 15 legen Sie Scope, Sponsor:in, Zielbild, Business Case, Kernprozess und Erfolgskriterien fest. Von Tag 16 bis 30 folgt die Ist-Aufnahme: Prozess, Systeme, Datenobjekte, Schnittstellen, Medienbrüche, Risiken und Anwendungsgruppen. Von Tag 31 bis 45 entstehen Soll-Prozess, Datenmodell, Rollen, Zielarchitektur, Kennzahlenset, Security-Anforderungen und Pilotdesign. Von Tag 46 bis 70 konfigurieren Sie Prototyp oder Pilot, prüfen die Datenqualität, testen die Schnittstellen und bereiten Training und Support vor. Von Tag 71 bis 90 stabilisieren Sie den Piloten, messen Nutzung und Wirkung, schließen Fehlerursachen und erstellen die Rollout- und Verbesserungsroadmap.

Den Rahmen bilden ISO/IEC 38500:2024 für IT-Governance, ISO/IEC 27001:2022 für Informationssicherheit, ISO/IEC 20000-1:2018 für Service Management, ISO/IEC 25010:2023 für Produktqualität, ISO/IEC 42001:2023 für KI-Einsatz, ISO 9001:2015 für Prozesslenkung, die DSGVO für personenbezogene Daten und COBIT 2019 als Governance-Framework.

Diese acht Regelwerke beantworten Fragen, die in jedem Systemprojekt ohnehin auftauchen: Wer entscheidet über die IT-Nutzung? Womit belegen Sie, dass Zugriffe kontrolliert sind? Was gilt als ausreichende Dokumentation? Wer den Rahmen kennt, muss ihn nicht in jedem Projekt neu erfinden und vermeidet, dass ein technisch gelungenes System in der Prüfung auffällt.

Eine Systemlandschaft, die einer gemeinsamen Steuerungslogik folgt, zahlt auf sechs Achsen ein: Qualität, Geschwindigkeit, Transparenz, Compliance, Kosten und Resilienz. Im Alltag merken Sie das an vier Ergebnissen.

Entscheidungen fallen schneller. Die Diskussionen über die Herkunft einer Zahl gehen zurück, weil es für jede Kennzahl eine eindeutige Quelle gibt. Ihr Führungskreis spricht über die Maßnahme statt über den Datenstand. Die Reibung im Prozess sinkt, weil Informationen dort verfügbar sind, wo die Arbeit stattfindet, und nicht erst zusammengesucht werden müssen. Wer eine Zahl braucht, findet sie meist selbst, statt sie anzufordern.

Doppelarbeit geht zurück. Wo Schnittstellen tragen, sinkt die Zahl manueller Übertragungen, und mit ihnen sinken Fehlerquote, Nacharbeit und Durchlaufzeit. An die Stelle zweier Wahrheiten über denselben Auftrag tritt eine, die alle Beteiligten sehen. Das senkt den Aufwand und zugleich die Zahl der Konflikte, die nur aus widersprüchlichen Daten entstanden sind.

Ein öffentlich dokumentierter Fall bei BASF zeigt, wie diese Logik wirkt: Prozessaufträge liefen aus dem ERP in das MES, das daraus Steuerungsrezepte ableitete und Statusmeldungen zurückgab. Probenanforderungen wurden an das LIMS übermittelt, Checklisten über Scanner erfasst und der Versandprozess einschließlich Etikettendruck automatisch im ERP ausgelöst. Dadurch entfielen manuelle Dateneingaben sowie die damit verbundenen Fehler und Verzögerungen. Das Ergebnis ist eine um 5 bis 10 Prozent verkürzte Chargenproduktionszeit und fünf Tage weniger manuelle Papierarbeit pro Monat. Der Hebel war die durchgängige Prozess- und Datenlogik, nicht ein isoliert eingeführtes weiteres Tool.

Prüfungen verlieren ihren Ausnahmecharakter. Audit Trails, dokumentierte Definitionen und nachvollziehbare Änderungen liegen vor, wenn geprüft wird, statt kurz davor erzeugt zu werden. Datenschutzanforderungen sind im System abgebildet und nicht in einer Nebenakte. Was ISO/IEC 27001:2022 und die DSGVO verlangen, wird damit zum Nebenprodukt des Normalbetriebs.

Ausfälle bleiben Vorfälle. Serviceprozesse, Monitoring, geprüfte Zugriffsrechte sowie ein getestetes Backup- und Notfallkonzept sorgen dafür, dass eine Störung eine definierte Reaktion auslöst und keine Krisensitzung. Ihre Systemlandschaft wird belastbar gegen genau die Ereignisse, die sonst einen ganzen Standort ausbremsen. Der Unterschied zeigt sich nicht im Normalbetrieb, sondern am Tag des Vorfalls.

Und der Nutzen bleibt überprüfbar. Verfügbarkeit, Ticketvolumen, Durchlaufzeit, Datenqualität, die Zufriedenheit der Anwender:innen und die Prozesswirkung zeigen, ob die erwartete Wirkung tatsächlich eingetreten ist. Damit ist die Investition kein Vertrauensvorschuss, sondern eine Position, die sich belegen lässt.