Anwendungen und Informationen zu einer tragfähigen Architektur verbinden
Wir ordnen ERP-, CRM-, BDE- und Fachanwendungen nach ihrer Aufgabe im Geschäftsprozess. Dabei klären wir, welche Systeme führend sind, wie Informationen zwischen ihnen fließen und wo Standardfunktion, Konfiguration, Erweiterung oder Individualentwicklung erforderlich sind.
Über einzelne Anwendungen hinaus betrachten wir operative Daten, Staging, Integration, Historisierung, Datawarehouse und Auswertung als zusammenhängende Informationsarchitektur.
Wie wird aus einzelnen Anwendungen ein zusammenhängendes Informationssystem?
Unternehmen betreiben selten eine einzige Anwendung. ERP, CRM, Betriebsdatenerfassung, Planung, Produktion, Qualitätssicherung, Dokumentation und Auswertung erfüllen unterschiedliche Aufgaben. Viele dieser Systeme greifen jedoch auf dieselben Geschäftsobjekte zu und verändern deren Daten aus unterschiedlichen Perspektiven.
Ohne eine gemeinsame Architektur entstehen widersprüchliche Bestände, mehrfache Datenpflege, unklare Zuständigkeiten und schwer beherrschbare Schnittstellen. Änderungen an einem System wirken dann unerwartet auf andere Prozesse und Anwendungen.
Wir verbinden Geschäftsprozesse, Anwendungen und Informationsflüsse zu einem nachvollziehbaren Gesamtbild. So können notwendige Veränderungen dort angesetzt werden, wo sie fachlich und technisch sinnvoll sind.
01 · Anwendungsaufgaben
Anwendungen nach ihrer Aufgabe einordnen
Zunächst betrachten wir, welche Aufgabe jede Anwendung im Geschäftsprozess erfüllt und welches Ergebnis sie erzeugt.
Dazu gehören beispielsweise:
ERP-Systeme für Ressourcen, Aufträge, Beschaffung und Abrechnung
CRM-Systeme für Kunden, Kontakte und Geschäftsvorgänge
BDE- und Produktionssysteme für Betriebs-, Maschinen- und Fertigungsdaten
Planungs- und Dispositionssysteme
Revisions- und Dokumentationssysteme
Mess-, Qualitäts- und Nachweissysteme
individuelle Fachanwendungen
Datawarehouses und Auswertungsplattformen
manuelle Ergänzungs- und Ersatzverfahren
Wir ordnen die Anwendungen ihren Geschäftsprozessen, Nutzergruppen, Verantwortlichkeiten und Informationsbeständen zu. Damit wird sichtbar, welche Funktionen mehrfach vorhanden sind, wo Anwendungen voneinander abhängen und welche Systeme für das Unternehmen besonders kritisch sind.
02 · Informationsverantwortung
Führende Systeme und Informationsverantwortung bestimmen
Ein Geschäftsobjekt kann in mehreren Anwendungen verwendet werden. Dennoch muss nachvollziehbar bleiben, welches System welche Information erzeugt, verändern darf und verbindlich bereitstellt.
Wir untersuchen unter anderem:
Kunden, Lieferanten und Geschäftspartner
Produkte, Leistungen und Verträge
Aufträge und Geschäftsvorgänge
Anlagen, Maschinen und technische Objekte
Standorte und organisatorische Einheiten
Ressourcen und Kapazitäten
Mess-, Betriebs- und Qualitätsdaten
Status, Gültigkeiten und Historien
Für wesentliche Informationsbestände klären wir:
Wo entsteht die Information?
Welches System ist für sie führend?
Wer trägt die fachliche Verantwortung?
Welche Anwendungen dürfen sie verändern?
Welche Systeme erhalten Kopien?
Wie werden Abweichungen erkannt?
Welche Historie und Nachweise müssen erhalten bleiben?
Damit wird Informationsverantwortung von bloßem Datenbesitz unterschieden.
03 · Standard und Individualisierung
Standardfunktion und Individualisierung abwägen
Bei Standard- und ERP-Systemen ist nicht jede fachliche Besonderheit ein ausreichender Grund für Individualentwicklung. Umgekehrt kann ein erzwungener Standardprozess geschäftskritische Abläufe verschlechtern oder notwendige Differenzierung verhindern.
Wir unterscheiden deshalb:
vorhandene Standardfunktion
mögliche Konfiguration
herstellervorgesehene Erweiterungen
erforderliche Schnittstellen
kundeneigene Anwendungen und Datenbankobjekte
organisatorische Prozessanpassungen
verbleibende funktionale Lücken
Für wesentliche Abweichungen bewerten wir Nutzen, Aufwand und dauerhafte Folgen. Dazu gehören Wartbarkeit, Releasefähigkeit, Abhängigkeit vom Hersteller, notwendiges Spezialwissen und langfristige Betriebskosten.
Das Ergebnis ist keine automatische Entscheidung für Standard oder Individualisierung. Es ist eine nachvollziehbare Grundlage für die passende Lösung im jeweiligen Geschäftsprozess.
04 · Informationsflüsse
Informationsflüsse über Systemgrenzen ordnen
Zwischen Anwendungen werden nicht nur Datensätze übertragen. Es werden fachliche Zustände, Verantwortlichkeiten und zeitliche Gültigkeiten weitergegeben.
Wir beschreiben deshalb:
Quelle und Ziel der Information
fachliche Bedeutung und Verbindlichkeit
Zeitpunkt und Häufigkeit der Bereitstellung
Transformationen und Verdichtungen
Abhängigkeiten zu weiteren Datenbeständen
Kontroll- und Abstimmungsbedarf
Fehler- und Wiederanlaufwege
Verantwortlichkeiten für Inhalt und Verarbeitung
So wird erkennbar, welche Informationen unmittelbar für operative Prozesse benötigt werden und welche zeitversetzt integriert, historisiert oder ausgewertet werden können.
05 · Operativ und analytisch
Operative und analytische Nutzung unterscheiden
Operative Anwendungen unterstützen laufende Geschäftsvorgänge. Analytische Systeme führen Daten aus unterschiedlichen Quellen zusammen, bewahren historische Entwicklungen und ermöglichen übergreifende Auswertungen.
Diese Aufgaben stellen unterschiedliche Anforderungen an Aktualität, Struktur, Datenqualität und Verarbeitung. Werden operative und analytische Nutzung unkontrolliert vermischt, können Produktionssysteme belastet und Auswertungsergebnisse widersprüchlich werden.
Wir unterscheiden daher:
operative Anwendungssysteme
Übergabe- und Staging-Bereiche
Integrations- und Harmonisierungsschichten
Operational Data Stores
historisierte Datawarehouses
thematische Auswertungsbestände
Reporting und analytische Nutzung
Architekturmodelle wie Bill Inmons Corporate Information Factory helfen, Herkunft, Integration, Historisierung und Verwendung von Informationen in einen gemeinsamen Zusammenhang einzuordnen. Sie stehen nicht auf derselben Ebene wie ERP, CRM oder BDE, sondern beschreiben deren Einbindung in eine übergreifende Informationsarchitektur.
06 · Migration
Migration und Weiterentwicklung vorbereiten
Gewachsene Anwendungslandschaften lassen sich selten durch einen einzigen Systemwechsel verändern. Daten, Funktionen, Schnittstellen und Verantwortlichkeiten müssen schrittweise in eine neue Ordnung überführt werden.
Wir betrachten:
weiter zu nutzende Bestandsanwendungen
zu ersetzende oder stillzulegende Systeme
übergangsweise erforderliche Schnittstellen
zu migrierende Daten und Historien
temporäre Mehrfachführung
notwendige Datenbereinigung
Abhängigkeiten zu laufenden Geschäftsprozessen
fachliche und betriebliche Voraussetzungen
mögliche Übergangs- und Rückfallszenarien
Damit wird die Zielarchitektur nicht als isoliertes Zukunftsbild beschrieben. Sie wird mit einem realistischen Weg aus der bestehenden Landschaft verbunden.
07 · Betriebsfolgen
Dauerhafte Betriebsfolgen sichtbar machen
Eine neue Anwendung oder Integration verändert nicht nur Technik. Sie erzeugt dauerhafte Aufgaben, Kosten und Verantwortlichkeiten.
Wir machen deshalb sichtbar:
benötigte Betriebs- und Supportleistungen
Abhängigkeiten zu Herstellern und Lieferanten
erforderliche Kompetenzen und Ressourcen
Pflege kundeneigener Erweiterungen
Monitoring und Fehlerbehandlung
Berechtigungs- und Sicherheitsanforderungen
Backup, Restore und Wiederanlauf
Datenpflege und Abstimmung
Release-, Wartungs- und Migrationsaufwand
dauerhafte Lizenz- und Infrastrukturkosten
Der betriebliche Owner muss beurteilen können, ob die Architektur nicht nur fachlich überzeugt, sondern auf Dauer organisatorisch und wirtschaftlich getragen werden kann.