Zurück zum Einblicke
Enterprise Architecture Health Assessment: ERP-Fundament prüfen
Wie Mittelständler prüfen, ob ihre ERP-Landschaft die nächste Investition trägt — und warum die Architekturprüfung vor der Toolwahl steht.
Wie Mittelständler prüfen, ob ihre ERP-Landschaft die nächste Investition trägt — und warum die Architekturprüfung vor der Toolwahl steht
Enterprise Architecture · Grundlagen
Jede Architektur altert. Dieser Beitrag zeigt, was ein Enterprise Architecture Health Assessment prüft, wie es ohne Störung des Tagesgeschäfts abläuft und warum es der logische Schritt vor jeder ERP- und KI-Entscheidung ist
Die Antwort in Kürze
Ein EA Health Assessment prüft unabhängig, ob die Architektur die Strategie noch trägt.
Geprüft werden Daten, Prozesse, Systeme und Entscheidungsrechte. Für den Mittelstand ist es die Vorsorgeuntersuchung der ERP-Landschaft: Es macht technische Schulden sichtbar, schützt die im Unternehmen kodierte Entscheidungslogik und schafft die Voraussetzung dafür, dass KI-Agenten später verantwortbar im ERP arbeiten können.
Entscheidend ist die Unabhängigkeit des Prüfers: Wer die Architektur gebaut hat oder an ihrem Umbau verdient, kann sie nicht objektiv bewerten. 33+ Jahre Beratungserfahrung, mehr als 1.200 Projekte, 100 % herstellerunabhängig.
Warum die Architektur entscheidet, nicht das nächste Release
Unternehmen stehen an einer Schwelle: vom Internet-Zeitalter mit weitgehend statischen Systemlandschaften in ein Informations-Zeitalter, in dem datengesteuerte Entscheidungen in Echtzeit über den Markterfolg mitentscheiden. Ob eine ERP-Landschaft diesen Übergang trägt, entscheidet nicht das nächste Software-Release. Es entscheidet die Architektur darunter.
Genau deshalb gehört die Architektur regelmäßig auf den Prüfstand — bevor Symptome zu kritischen Ausfällen werden.
Was ist ein Enterprise Architecture Health Assessment?
Ein Enterprise Architecture Health Assessment ist die unabhängige, strukturierte Prüfung der Unternehmensarchitektur. Daten, Prozesse, Standorte, Rollen, Ereignisse und Strategie werden gegen die Geschäftsziele geprüft — vergleichbar mit einer medizinischen Vorsorgeuntersuchung oder einem unabhängigen Finanz-Audit. Es erkennt Degradation, technische Schulden und Inkonsistenzen, bevor sie den ERP-Betrieb gefährden, und liefert einen priorisierten Aktionsplan.
Definition
Enterprise Architecture (EA) ist die explizite Beschreibung dessen, wie ein Unternehmen aus Strategie, Prozessen, Daten, Systemen und Entscheidungsrechten zusammengesetzt ist. Sie verwandelt implizite Gedankenprozesse in explizite Repräsentationen — die Blaupause oder DNA des Unternehmens. Im Verständnis von Dreher Consulting ist EA vor allem Entscheidungsarchitektur: Sie legt fest, welche Entscheidung durch wen oder was, auf welcher Evidenz, mit welcher Autonomiestufe und in welchem führenden System getroffen wird.
Wichtig ist die Abgrenzung: Eine Enterprise Architecture ist keine Landschaftsskizze und kein Ordner mit Systemdiagrammen. Sie ist ein strategisches Asset, das Abhängigkeiten, Sequenzierungen und die Ausrichtung einer komplexen ERP-Landschaft sichtbar und steuerbar macht. Und sie ist kein einmaliges Projekt: Wie jedes Asset braucht sie kontinuierliche Pflege — das Health Assessment ist das Instrument dieser Pflege.
Warum verschlechtern sich Architekturen von selbst?
Architekturen degradieren auf natürliche Weise: Jede Sonderlösung, jede undokumentierte Schnittstelle und jede Begriffsverschiebung erhöht die technischen Schulden. Dieser Prozess verläuft schleichend, bis Änderungen unverhältnismäßig teuer werden. Ein regelmäßiges Assessment macht die Degradation messbar — und schützt das geistige Eigentum, das in der Architektur kodiert ist: die Entscheidungslogik des Unternehmens.
Aus mehr als 1.200 Projekten seit 1992 kennen wir drei wiederkehrende Muster, die ein Assessment strategisch unverzichtbar machen.
Muster 1
Die Architektur ist Ihr geistiges Eigentum
Die EA ist die kodifizierte Einzigartigkeit eines Unternehmens. Diese DNA findet sich weder im Internet noch bei Wettbewerbern — und auch nicht im Standardumfang eines Softwareprodukts. Wettbewerbsvorteil entsteht nicht durch das Werkzeug, sondern durch die eigene Entscheidungslogik.
Muster 2
Komplexität und Begriffsdrift fressen Effizienz
„Kunde“ umfasst im Vertrieb auch Interessenten, in der Finanzbuchhaltung nur fakturierte Konten — und im Altsystem noch eine dritte Definition. Sobald zentrale Begriffe auseinanderlaufen, bricht die Konsistenz der Kommunikation und mit ihr die Verlässlichkeit jeder Auswertung.
Muster 3
Veraltete Strukturen wirken wie Anker
Batch-Logik verhindert Echtzeitreaktion, starre Datenmodelle blockieren neue Geschäftsmodelle, gewachsene Individualentwicklungen binden Wissen an einzelne Personen. Das Assessment benennt diese Anker explizit — als Grundlage für eine bewusste Entscheidung, nicht als Anlass für Aktionismus.
Welche sechs Dimensionen prüft ein Assessment im ERP-Kontext?
Geprüft werden Daten (Was), Prozesse (Wie), Standorte (Wo), Menschen und Rollen (Wer), Ereignisse (Wann) und Strategie (Warum). Im ERP-Kontext entscheidend sind dabei Stammdatenqualität, der Wechsel von Batch- zu ereignisgesteuerten Abläufen und die lückenlose Ausrichtung der Systemlandschaft an den Geschäftszielen.
Diese sechs Fragedimensionen sind die klassischen Interrogative des Zachman-Frameworks. Sam Holcman hat sie in der Praxis der unabhängigen Architekturprüfung weiterentwickelt — dort liegt ihr Nutzen für den Mittelstand. Im modernen ERP-Umfeld, etwa bei anstehenden Generationswechseln großer ERP-Suiten, verschieben sich die Schwerpunkte deutlich:
| Dimension | Zentrale Fragestellung | ERP-Bezug: Worauf es heute ankommt |
|---|---|---|
| Was (Daten) | Welche Informationen und Assets werden benötigt? | Stammdatenqualität, Datenverantwortung und Datenbereinigung. Sind die Daten belastbar genug, um später als Evidenz für automatisierte Entscheidungen zu dienen? |
| Wie (Prozesse) | Welche Aktivitäten liefern den Wert? | Effizienz der End-to-End-Prozesse. Sind die Abläufe zeitgemäß gestaltet — oder lediglich digitalisierte Altlasten? |
| Wo (Standorte) | Wo ist das Unternehmen präsent? | Global Templates, Cloud-Infrastruktur, Lokalisierung und regulatorische Anpassungen — etwa Zoll- und Handelsvorgaben oder E-Invoicing-Pflichten. |
| Wer (Menschen) | Welche Rollen und Fähigkeiten sind vorhanden? | Rollenkonzepte, Entscheidungsrechte, Remote-Work-Modelle und das Skillset für moderne ERP-Umgebungen. Entscheidungsrechte sind dabei mehr als Rollenbeschreibungen. |
| Wann (Ereignisse) | Auf welche Zyklen reagieren wir? | Kritischer Fokus: der Wechsel von prozess- zu ereignisgesteuerten Architekturen. Reagiert das ERP in Echtzeit auf Marktereignisse — oder ist es in Batch-Zyklen gefangen? |
| Warum (Strategie) | Welche Ziele verfolgt die Organisation? | Vertikale Integration: Ist die ERP-Strategie lückenlos an Geschäfts- und Missionszielen ausgerichtet — oder haben sich Systementscheidungen verselbstständigt? |
Wie läuft ein Assessment ab, ohne das Tagesgeschäft zu stören?
Ein wirksames Assessment braucht zwei Dinge: Unabhängigkeit und minimale Störung des Betriebs. Der Ablauf: gesicherte Übergabe der Architektur-Dokumentation, Tiefenanalyse weitgehend remote, gezielte Experteninterviews nur zur Klärung offener Punkte. Entscheidend ist, dass nicht diejenigen prüfen, die die Architektur gebaut haben — Objektivität ist die zentrale Qualitätsbedingung.
Sam Holcman bringt die Anforderung auf den Punkt: Wer den Hühnerstall gebaut hat, sollte ihn nicht bewachen. Eine Prüfung durch die ursprünglichen Ersteller — ob interne Architekten oder der implementierende Systempartner — trägt strukturell deren Voreingenommenheit in das Ergebnis. Dieselbe Logik, die eine unabhängige ERP-Beratung ohne Softwareverkauf und Implementierungsprovision begründet, gilt für die Architekturprüfung: Herstellerneutralität ist ein Architekturprinzip, keine Floskel.
Weil Fachabteilungen im Tagesgeschäft ausgelastet sind, führen wir das Assessment nach dem Prinzip der Minimal Business Intrusion durch — weitgehend als Virtual Assessment:
- Gesicherte Datenübergabe. Relevante Dokumente, Architekturbeschreibungen und Systeminformationen werden in einem verschlüsselten, gesicherten Rahmen bereitgestellt.
- Remote-Analyse. Die Tiefenprüfung entlang der sechs Dimensionen erfolgt weitestgehend ohne Störung des laufenden Betriebs.
- Liaison-Prinzip. Nur für spezifische Rückfragen werden kurze, gezielte Experteninterviews mit den Fachbereichen geführt.
- Ergebnisdokument und Managementgespräch. Befunde, Priorisierung und Aktionsplan werden mit Geschäftsführung und IT-Leitung besprochen — entscheidungsorientiert, nicht als Folienschlacht.
Da die Enterprise Architecture die DNA des Unternehmens abbildet, haben Vertraulichkeit und Verschlüsselung während der Analyse oberste Priorität. Wir behandeln diese strategischen Assets mit derselben Sorgfalt wie unser eigenes geistiges Eigentum — etwa unsere Methodik SCOReX®, die selbst Methodik ist und kein Softwareprodukt.
Welche Ergebnisse erhält die Geschäftsführung?
Das Ergebnis ist ein evidenzbasierter Aktionsplan: eine Baseline für kommende Veränderungen, explizit benannte technologische Anker, identifizierte Silos, eine Bewertung der Herstellerunabhängigkeit und ein dokumentierter Pfad vom Ist- zum Zielzustand. Auch ein positiver Befund ist ein Ergebnis — er gibt Investitionssicherheit für die nächsten Architektur- und ERP-Entscheidungen.
| Bestandteil des Ergebnisdokuments | Nutzen für die Entscheidung |
|---|---|
| Baseline für kontinuierlichen Wandel | Stabile Ausgangsbasis, um künftige Änderungen schneller und kosteneffizienter umzusetzen — vom ERP-Releasewechsel bis zur Prozessumstellung. |
| Identifikation technologischer Anker | Explizite Benennung von Altsystemen und starren Modellen, die die Geschäftsstrategie hemmen — inklusive Abhängigkeiten und Reihenfolge der Ablösung. |
| Silos gegen Synergien | Befund, ob die Organisation als integriertes Ganzes arbeitet oder in isolierten Einheiten — die häufigste Ursache für widersprüchliche Zahlen im Management-Reporting. |
| Technologische Agnostik | Bewertung, ob die Architektur gegenüber Generationswechseln flexibel bleibt. Was nur im Stack eines Herstellers funktioniert, ist Produktkonfiguration — keine Unternehmensarchitektur. |
| Messbarer Fortschritt | Dokumentierter Pfad vom Ist-Zustand zum Ziel-Zustand mit priorisierten, sequenzierten Maßnahmen. |
Warum das Assessment die Voraussetzung für KI-Agenten im ERP ist
KI-Agenten treffen Entscheidungen auf Basis der Architektur, die sie vorfinden. Eine degradierte Architektur mit inkonsistenten Daten und ungeklärten Entscheidungsrechten macht Agenten zum Betriebsrisiko. Das Health Assessment klärt vorab, welche Evidenz verlässlich ist, wo das System of Record liegt und welche Entscheidungen überhaupt delegierbar sind — Architektur vor Software.
Die Führungsfrage im Mittelstand lautet heute nicht mehr nur „Welches ERP?“ oder „Welche KI?“, sondern: Wie muss unsere Architektur definiert sein, damit wir unseren Wettbewerbsvorteil mit KI-Agenten und ERP ausbauen können — ohne uns an einen Hersteller zu ketten und ohne Governance, Datenqualität und Entscheidungsrechte zu verlieren?
- Evidenz prüfen, bevor Agenten ihr vertrauen. Ein Agent, der auf inkonsistenten Stammdaten disponiert, automatisiert Fehler — schneller und in größerem Volumen als jeder Mensch. Die Was-Dimension beantwortet, ob die Datenbasis Entscheidungsreife hat.
- Capability und Authority trennen. Dass ein Agent etwas kann, heißt nicht, dass er es darf. Das Assessment macht sichtbar, wo Entscheidungsrechte heute implizit in Köpfen und Altsystemen stecken — die Voraussetzung, um Autonomiestufen, Limits und Human-in-the-Loop-Punkte bewusst festzulegen.
- Das System of Record schützen. Das ERP bleibt führendes System; Agenten werden Akteure darin. Bevor der erste produktive Agent schreibend zugreift, muss die Architektur definieren, mit welcher Umkehrbarkeit und welchem Audit-Nachweis das geschieht — Governance zur Laufzeit, nicht auf Papier.
Wer diese Reihenfolge umkehrt und zuerst einen Hersteller-Agentenstack auswählt, verschiebt das Risiko in den Betrieb. KI erkennt Muster. Beraterinnen und Berater tragen Verantwortung — und genau deshalb steht die Architekturprüfung vor der Toolwahl.
Wann ein Assessment nicht der richtige Schritt ist
Ein EA Health Assessment ist nicht der richtige Schritt, wenn eine akute Betriebsstörung sofortiges Handeln verlangt, wenn eine Grundsatzentscheidung über das Geschäftsmodell noch aussteht oder wenn die Organisation nicht bereit ist, Befunde in Maßnahmen zu übersetzen. Eine Prüfung ohne Konsequenz erzeugt Papier — keine Architekturqualität.
Diese Ehrlichkeit gehört zur Beratung: In einer akuten Krise — etwa einem instabilen Go-live — ist Stabilisierung wichtiger als Diagnose. Steht ein Unternehmensverkauf oder eine fundamentale Neuausrichtung unmittelbar bevor, sollte erst die strategische Entscheidung fallen, dann die Architekturprüfung folgen. Und wo ein Assessment nur als Bestätigungsritual für bereits getroffene Softwareentscheidungen gesucht wird, lehnen wir den Auftrag ab — das Ergebnis wäre wertlos.
Drei taktische nächste Schritte
- Dokumentationslage prüfen (30 Minuten). Existiert eine aktuelle, für Dritte verständliche Darstellung Ihrer Daten, Prozesse, Systeme und Entscheidungsrechte? Wenn die Antwort „teilweise“ lautet, ist das bereits der erste Befund.
- Begriffskonsistenz stichprobenartig testen. Lassen Sie „Kunde“, „Auftrag“ und „Artikel“ von zwei Abteilungen unabhängig definieren und vergleichen Sie die Antworten. Abweichungen zeigen, wo Ihre Architektur bereits driftet.
- Architekturklärung vor der nächsten Investition ansetzen. Terminieren Sie eine unabhängige Ersteinschätzung, bevor die nächste Software- oder KI-Entscheidung budgetiert wird. Die Reihenfolge entscheidet: Architektur vor Software.
Eine Frage zum Schluss: Wenn Ihr Wettbewerbsvorteil in Ihrer Entscheidungslogik kodiert ist — könnte irgendjemand in Ihrem Unternehmen diese Logik heute vollständig und explizit aufzeichnen, oder existiert sie nur verteilt in Köpfen, Altsystemen und Excel-Dateien?
30 Minuten Klartext zu Ihrer Architektur — direkt mit Dr. Dreher
Trägt Ihre Architektur die nächste ERP- oder KI-Entscheidung — oder nicht? Kein Verkaufsgespräch, keine Junior-Beratung.
Weiterführende Inhalte
- Unabhängige ERP-Beratung — herstellerneutral, ohne Softwareverkauf
- Unabhängige ERP-Auswahl — wenn die Architektur geklärt ist und die Softwareentscheidung ansteht
- Enterprise Architecture — unser Beratungsfeld im Überblick
- SCOReX® — unsere Methodik für die strukturierte Auswahl
- Business Case für KI in ERP-Prozessen — wie der Nutzen gerechnet wird, wenn die Architektur trägt
Quellen und Grundlagen: Die sechs Fragedimensionen sind die Interrogative des Zachman-Frameworks; das Prinzip der unabhängigen Architekturprüfung folgt den Arbeiten von Sam Holcman zur Enterprise Architecture. Praxisbeispiele und Bewertungsmaßstäbe entstammen der anonymisierten Projekterfahrung von Dreher Consulting.
Für Fragen oder Anregungen nutzen Sie den Kontaktbutton und sprechen Sie direkt mit mir.
Ihre Rückmeldung würde mich freuen.
