Wie führt man Architektur-Kontrollpunkte ein?

Eine neue Webshop-Integration, ein Lagerterminal oder ein Fertigungsdatenerfassungssystem ist selten nur eine einzige Änderung. Es beeinflusst das ERP, die Berechtigungen, das Netzwerk, die Berichte und oft auch manuelle Schritte, von denen niemand wusste, dass sie existieren. Die Frage ist daher nicht nur, wie man Architektur-Kontrollpunkte einführt, sondern auch: Wann sollte man vor einer Entscheidung innehalten, wer sollte sie überprüfen und auf welcher Grundlage darf die Änderung weitergeführt werden?

Ein Architektur-Kontrollpunkt ist keine überflüssige Genehmigungsrunde. Richtig gestaltet, ist es eine kurze, vordefinierte Überprüfung, die verhindert, dass ein lokales Bedürfnis später zu einem systemweiten Betriebsproblem wird. Besonders wertvoll ist es dort, wo der Betrieb des Unternehmens bereits auf mehreren Systemen, Lieferanten, Standorten und dem Wissen von Schlüsselpersonen basiert.

Warum geraten Änderungen aus der Bahn?

Die meisten Fehler passieren nicht, weil ein Entwickler oder Betreiber die Technologie nicht verstanden hat. Viel häufiger entsteht die Entscheidung aus einer zu engen Perspektive. Der Handelsbereich fordert schnellere Bestellabwicklung, das Lager möchte Barcodescanner einführen und die IT möchte einen alten Server ersetzen. Jede dieser Anforderungen kann berechtigt sein, aber keine ist unabhängig von den anderen.

Nehmen wir ein einfach erscheinendes Beispiel. Die Bestellungen aus dem Webshop müssen an das ERP und dann an das Lagersystem übergeben werden. Wenn die Integration nur prüft, ob die Bestellung durchgeht, können leicht Ausnahmen übersehen werden: Was passiert bei Teillieferungen, Stornierungen, Lagerengpässen, falschen Adressen oder wenn das ERP vorübergehend nicht verfügbar ist? Wer bemerkt den Fehler, wo wird er sichtbar und wer kann ihn beheben?

Ohne Kontrollpunkt tauchen diese Fragen in der Regel erst nach dem Live-Start auf. Dann hält das Team das Geschäft mit Tabellen, E-Mails und manuellen Korrekturen am Laufen. Kurzfristig hilft das, aber gleichzeitig entsteht ein neuer, unsichtbarer Prozess, der später auf das Wissen eines einzigen Mitarbeiters angewiesen ist.

Was sollte ein Architektur-Kontrollpunkt überprüfen?

Das Ziel ist nicht, dass ein Komitee jedes technische Detail diskutiert. Der Kontrollpunkt soll Entscheidungen aufdecken, die später Kosten, Ausfälle, Datenprobleme oder schwer zu wartende Abhängigkeiten verursachen können.

Eine gute Überprüfung basiert auf vier Fragen. Erstens: Welches Geschäftsproblem löst die Änderung und sind alle geplanten Prozessschritte wirklich notwendig? Zweitens: Welche Systeme, Daten, Rollen und externen Verbindungen sind betroffen? Drittens: Wie funktioniert es bei Fehlern, Belastung oder teilweisem Ausfall? Viertens: Wer wird es in sechs Monaten betreiben, überwachen und weiterentwickeln?

Dies sind keine theoretischen Fragen. Wenn eine neue Anwendung eine separate Kundenstammdatenbank führt, während im ERP bereits eine existiert, geht es nicht nur um ein Datenmodell. Es entsteht die doppelte Datenpflege, unterschiedliche Berichte und die Diskussion darüber, welches System die Quelle der Wahrheit ist. Wenn ein Prozess durch manuelles Datei-Upload verbunden ist, mag die technische Lösung günstig erscheinen, aber die Betriebskosten zeigen sich schnell in der Administration.

Wie führt man Architektur-Kontrollpunkte in der Praxis ein?

Beginnen Sie mit den wiederkehrenden Reibungspunkten

Es ist nicht notwendig, am ersten Tag eine vollständige Unternehmensarchitektur-Richtlinie zu schreiben. Es ist sinnvoll, die Änderungen zu untersuchen, um die sich bereits heute viele Abstimmungen, manuelle Korrekturen oder nachträgliche Überraschungen drehen.

Dies könnte der Kauf eines neuen Systems, eine wesentliche Änderung eines bestehenden Systems, eine externe Partnerschaft, eine neue Datenübertragung, eine Infrastrukturverlagerung oder die Anbindung eines neuen Standorts sein. In der Regel zeigt sich innerhalb weniger Monate, an welchen Punkten regelmäßige Kontrollen erforderlich sind.

Der richtige Ausgangspunkt ist nicht, dass „jede Entwicklung genehmigt werden muss“. Vielmehr sollte ab einem bestimmten Schwellenwert eine kurze Überprüfung obligatorisch sein. Zum Beispiel, wenn die Änderung persönliche oder geschäftskritische Daten betrifft, Daten zwischen mehreren Systemen bewegt, den täglichen Betrieb zum Stillstand bringen könnte oder neue Betriebsverantwortung schafft.

Definieren Sie wenige, klare Tore

Für eine mittelgroße Organisation sind oft drei Kontrollpunkte ausreichend. Der erste erfolgt bei der Initiierung, noch bevor die endgültige Lösung ausgewählt wird. Hier sollte geklärt werden, was das Betriebsziel ist, welchen Prozess die Änderung betrifft und ob es eine einfachere Lösung gibt.

Der zweite Punkt ist die Genehmigung des Implementierungsplans. Hier wird der Datenfluss, die Integration, das Berechtigungsmanagement, die Sicherung, das Logging, das Testen und die Wiederherstellungsmethode behandelt. Nicht jedes Projekt benötigt eine umfangreiche Dokumentation, aber die Beteiligten müssen dasselbe Verständnis von der Funktionsweise haben.

Der dritte Kontrollpunkt erfolgt vor der Inbetriebnahme. Hier geht es nicht darum, ob die Entwicklung abgeschlossen ist, sondern ob das Geschäft in der Lage ist, sie sicher zu nutzen. Ist die Einführungsreihenfolge bekannt, sind die Verantwortlichen benannt, wurden die kritischen Ausnahmen getestet und gibt es eine Entscheidung, wann zur vorherigen Betriebsweise zurückgekehrt werden muss?

Die richtigen Personen sollten anwesend sein

Architektur ist kein reines IT-Thema. Für eine Entscheidung, die einen Lagerprozess betrifft, ist auch jemand erforderlich, der den tatsächlichen Ablauf der Kommissionierung, die Inventurausnahmen und die Probleme bei Schichtwechseln kennt. Eine Entscheidung über eine Rechnungsintegration sollte nicht ausschließlich aus technischer Sicht getroffen werden, wenn die Finanzabteilung andere Anforderungen an den täglichen Abschluss hat.

Gleichzeitig verlangsamt ein zu breiter Kreis die Entscheidung. Die Teilnehmer des Kontrollpunkts sollten feste Rollen haben, keine gelegentlich eingeladenen Gäste: Geschäftsprozessverantwortlicher, technischer Verantwortlicher, Betriebsvertreter und bei Bedarf Daten- oder Sicherheitsverantwortlicher. Wichtig ist, dass jemand eine klare Entscheidungsbefugnis hat und nicht nur Meinungen gesammelt werden.

Das Ergebnis des Kontrollpunkts sollte eine Entscheidung sein, kein Protokoll

Eine Überprüfung ist nur dann nützlich, wenn am Ende ein klarer Status entsteht: kann fortgesetzt werden, kann mit Änderungen fortgesetzt werden oder es sind weitere Untersuchungen erforderlich. Offene Fragen benötigen einen Verantwortlichen und eine Frist. Ohne dies wird der Kontrollpunkt nur ein formelles Meeting sein, bei dem jeder annimmt, dass jemand anderes Maßnahmen ergreifen wird.

Es ist ratsam, ein kurzes, einheitliches Entscheidungsblatt zu verwenden. Es sollte das Geschäftsziel, die betroffenen Systeme, den Datenverantwortlichen, die Hauptabhängigkeiten, die Risiken, die Betriebsaufgaben und die Genehmigung enthalten. Eine Seite ist oft ausreichend. Die Details können in einem separaten technischen Plan sein, aber für die Managemententscheidung muss das Wesentliche übersichtlich bleiben.

Ziel der Dokumentation ist es nicht, später jemanden zur Verantwortung ziehen zu können. Sie ist erforderlich, damit auch in einem Jahr noch verständlich ist, warum eine Verbindung aufgebaut wurde, auf welchen Annahmen sie basierte und wer für ihre Wartung zuständig ist.

Bauen Sie kein zu schwerfälliges Steuerungssystem auf

Kontrollpunkte haben ihren Preis: Sie erfordern Zeit von Experten und verlangsamen bestimmte Entscheidungen. Wenn von einer Berichtsfeldänderung und einem vollständigen Lageraustausch dieselbe Detailgenauigkeit erwartet wird, wird die Organisation den Prozess früher oder später umgehen.

Die Lösung ist Verhältnismäßigkeit. Bei Änderungen mit geringem Risiko kann eine kurze schriftliche Überprüfung ausreichen. Bei größeren Änderungen, die mehrere Systeme oder kritische Betriebe betreffen, ist eine detailliertere Überprüfung und ein Inbetriebnahmeplan gerechtfertigt. Wichtig ist, dass die Regel dem Risiko angepasst ist, nicht der Menge der Dokumente.

Bei der Einführung von Kontrollpunkten sollten regelmäßig auch die wiederkehrenden Fragen überprüft werden. Wenn in jedem Projekt dasselbe Problem auftritt - zum Beispiel fehlt der Datenverantwortliche, es gibt keine Testumgebung oder die Fehlerbehandlung ist unklar -, dann handelt es sich nicht um ein einzelnes Projektproblem, sondern um ein betriebliches Defizit. Dies sollte als separate Entwicklungsaufgabe behandelt werden.

Nach den Erfahrungen von CGAT entfernt eine gute Architekturkontrolle die Technologie nicht vom Geschäft. Im Gegenteil: Sie verbindet frühzeitig die Perspektiven der Prozessverantwortlichen, des Betriebs und der Entwicklung. Ziel ist es nicht, die Veränderung zu bremsen, sondern sicherzustellen, dass das Wachstum nicht mit weiteren manuellen Umgehungen und schwer rückverfolgbaren Abhängigkeiten einhergeht.