Die Anwendungslandschaft im Unternehmen ist nie „aus einem Guss“, sondern „historisch gewachsen“: sie entsteht im Lauf der Zeit durch Projekte mit ihren Auswahlentscheidungen und Implementierungen. M&A-Aktivitäten tragen oft zusätzlich zur Heterogenität der Anwendungslandschaft bei, weil Komponenten aus den beteiligten Unternehmen zusammenkommen und selten vollständig ineinander aufgehen. Diese Heterogenität ist kein Makel, sondern der Normalzustand. Denn: Unternehmen entwickeln sich im Zeitablauf, und ihre Anwendungslandschaften mit ihnen – zusammen mit den Geschäftsprozessen.

Die Anwendungen unterstützen die Geschäftsprozesse im Unternehmen. Unternehmensplattformen wie beispielsweise SAP, Salesforce oder Oracle haben den Anspruch, ein breites Spektrum von Prozessen zu unterstützen. Daher bilden sie oft wesentliche Komponenten solcher Anwendungslandschaften. Weil sie nicht alle Funktionen abdecken, kommen weitere Anwendungen mit ihren jeweiligen funktionalen Schwerpunkten zum Einsatz, meist von verschiedenen Anbietern. Je mehr wir digitalisieren, desto länger werden die Prozessketten. Und desto häufiger überschreiten die Geschäftsprozesse die Grenzen zwischen verschiedenen Anwendungen (oder gar zwischen verschiedenen Unternehmen). Um die Prozessabläufe gut zu unterstützen, müssen die Anwendungen daher gut zusammenwirken.

Dieses Zusammenwirken wird allgemein als Integration bezeichnet. Gelungene Integration ist ein Schlüsselfaktor für eine erfolgreiche IT. Gefühlt ist Integration einer der meistgenutzten Begriffe in der IT. Was bedeutet er genau? Der Begriff wird im Regelfall ohne eine präzise Erläuterung verwendet. Wir haben aber eine recht gute intuitive Vorstellung davon. Erinnern Sie sich an klassische Prozessablaufbilder? Jeder (Teil-)Prozess verarbeitet Input zu Output, der dann wieder zu Input für den nächsten Teilprozess wird. Wir halten fest: Integration wird über den Austausch von Daten zwischen den Anwendungen realisiert. So unterstützen mehrere Anwendungen gemeinsam einen Geschäftsprozess. 

Wir betrachten nun die Gesamtheit aller Daten eines Unternehmens (und bezeichnen sie im Folgenden als Unternehmensdaten). Jede Anwendung hat eine eigene Datenhaltung für den jeweils relevanten Ausschnitt von Unternehmensdaten. Daher sind die Unternehmensdaten über die eingesetzten Anwendungen verteilt. Einfache Beispiele sind Stammdaten wie Produkte und Kunden, aber auch Bewegungsdaten wie Aufträge und Lieferungen. Verschiedene Unternehmensfunktionen arbeiten mit diesen Daten und haben ihre je eigenen Sichten darauf. Die Sichten materialisieren sich in den verschiedenen Anwendungen: Technische Produktinformationen befinden sich beispielsweise in den Anwendungen der Produktion und meist nicht in der Anwendung für die Auftragsabwicklung. Auch wenn all diese Anwendungen mit dem Produkt arbeiten.

Anbieter von Anwendungssystemen stellen in ihren Werbebroschüren regelmäßig heraus, dass ihre Produkte reibungslose Integration ermöglichen: die hoch gelobte seamless integration. Bei diesen Aussagen gibt es allerdings einen kleinen, folgenreichen Haken: Sie beziehen sich auf die technische Ebene. Auf dieser Ebene gewährleisten offene Standards, also frei zugängliche Normen und Protokolle, den Datenaustausch zwischen verschiedenen Systemen und Anwendungen. Beispiele sind die Formate XML für den strukturierten Datentransfer, HTML zur Strukturierung von Webseiten oder die Abfragesprache SQL.

Offene technische Standards zu nutzen garantiert allein allerdings nicht, dass Integration wirklich funktioniert. Denn oft weisen verschiedene Anwendungen unterschiedliche Datenformate auf. Noch gravierender ist es, wenn vermeintlich gleiche Datenelemente in verschiedenen Anwendungen nicht genau dasselbe bedeuten. Auch die Standardschnittstellen, die viele Anwendungen „mitbringen“, beheben solche Bedeutungsunterschiede natürlich nicht.

Sehen wir uns die Beispiele von oben genauer an. Festzulegen, was ein Unternehmen als Produkt betrachtet, ist nicht so trivial, wie wir im ersten Moment denken. Entwicklung und Produktion arbeiten vor allem mit einer technischen Spezifikation; Beispiel: Kopierpapier 100 g/m², weiß*.  Marketing und Logistik denken in Verkaufseinheiten, im Beispiel: 500-Blatt-Packung Kopierpapier, 100 g/m², DIN A4, weiß. Oder auch 500-Blatt-Packung Kopierpapier, 100 g/m², Letter-Format, weiß – für den US-Markt. In der Finanzbuchhaltung fließen weitere Aspekte wie die Produktionsstätte in die Produktdefinition ein.

Ebenso sieht die Logistik „den Kunden“ durch den Standort (eine Lieferadresse) festgelegt. In der Finanzbuchhaltung steht das jeweilige Kundenkonto im Vordergrund. Natürlich kann ein Kundenunternehmen mit einem Kundenkonto mehrere Standorte haben. Je größer das Kundenunternehmen ist, umso mehr führen diese Aspekte zu unterschiedlichen Ausprägungen.

Wenn die Anwendungen der Bereiche miteinander kommunizieren, werden an den Integrationspunkten (sprich: Schnittstellen) diese unterschiedlichen Ausprägungen jeweils von der Sender- in die Empfängersicht übersetzt.

Kommen wir auf das Kopierpapier-Beispiel von oben zurück. Wir brauchen dafür mindestens drei Produkt- oder Materialnummern: eine für die Rollenware, je eine für die beiden verschiedenen Verkaufseinheiten, vielleicht auch noch separate Nummern für Kartons mit je zehn 500-er Packs. Und Regeln für den „Übergang“ von der Rollenware zu den konfektionierten Verkaufseinheiten. Und Vereinbarungen, auf welchen Leveln geplant, Bestand geführt, abgerechnet wird – das alles machen die beteiligten Fachabteilungen untereinander aus. Diese Regeln sind ebenfalls Bestandteil der Unternehmensdaten. Sie sehen schon: da sind viele Absprachen und nennenswerter Datenpflegeaufwand nötig, damit alles wirklich reibungslos zusammenspielt.

Ungenaue Absprachen oder Pflegefehler verursachen Unterbrechungen im Prozessablauf, manuelle Nachbearbeitung, Informationsverluste. Nach unserer Beobachtung fällt ein substanzieller Teil des in Unternehmen geleisteten IT-Aufwands in diesem Bereich an. Etwas provokativ formulieren wir: Die Integration der Anwendungssysteme ist DER Aufwandstreiber in der IT.

Machen wir ein Gedankenexperiment: In einer idealen Welt wäre jedes Datenelement nur einmal und in einheitlicher Bedeutung vorhanden. Bei der Pflege dieser Datenbasis wäre sofort erkennbar, welche Absprachen nötig sind. Alle Anwendungen würden auf die gleichen, abgestimmten Daten zugreifen. Der Austausch von Daten über Schnittstellen wäre durch den Zugriff auf eine gemeinsame Datenbank ersetzt. Eine übliche Bezeichnung für dieses eher abstrakte Konstrukt ist single source of truth. Angesichts der Heterogenität von Anwendungslandschaften ist dies – zumindest für die operativen Anwendungen – praktisch nicht zu realisieren. Die verteilte Datenhaltung bleibt also der Normalfall.

Ein Zwischenfazit lautet also:

• Die fortschreitende Digitalisierung führt zu komplexen Anwendungslandschaften. Integration erfolgt durch Schnittstellen, an denen je zwei Anwendungen Daten austauschen.
• Die Softwareanbieter erleichtern die technische Integration dadurch, dass sie offene Standards verwenden.
• Die Integration auf der inhaltlichen Ebene erfordert Umsetzungsregeln, die verschiedene Sichten auf Daten kompatibel machen. Das bleibt eine dauerhafte und oft aufwändige Aufgabe im Unternehmen.

Mit diesem Zwischenfazit stehen wir vor der Frage, wie wir den Integrationsaufwand begrenzen können. Mit anderen Worten: Können wir trotz einer über Anwendungen verteilten Datenhaltung die Daten inhaltlich harmonisieren?

Wenn Sie die Entwicklung der IT über längere Zeit verfolgt haben, erinnern Sie sich womöglich an die Idee eines übergreifenden Unternehmensdatenmodells (UDM). Wir sehen, dass sich diese theoretisch bestechende Idee nicht etablieren konnte. Dies ist auf den hohen Aufwand zurückzuführen, dem kein direkt messbarer Nutzen gegenübersteht. Die Menge aller Unternehmensdaten ist kaum überschaubar. Und selbst wenn Sie in einem Kraftakt ein UDM erarbeitet hätten: Es ist nicht praktikabel, es konsistent und zeitnah weiterzuentwickeln. Der Zeitdruck der verschiedenen Einführungsprojekte spricht dagegen. Außerdem brauchen Sie dazu hochqualifizierte Mitarbeitende, die dann anderswo fehlen.

Müssen wir die Idee des UDM also komplett verwerfen? Wir meinen: nein. Sie kann sehr wohl in stark eingeschränktem Umfang umgesetzt werden. Statt „alle“ Unternehmensdaten zu modellieren, wählen Sie nur die wichtigsten Datenelemente aus, die für mehrere Anwendungen relevant sind. Mit gemeinsamen Definitionen dieser Datenelemente lassen sich die Umsetzungsregeln für die Schnittstellen deutlich einfacher erstellen. Fehler bei der Umsetzung werden reduziert. Das vereinfacht die Integration und reduziert den damit verbundenen Aufwand. 

Stammdaten wie Produkte und Kunden zählen sicher zu den Kandidaten für so ein Kern-UDM. Auch Bewegungsdaten wie der Kundenauftrag und Warenbestände sind Kandidaten. Nach unserer Kenntnis fehlt für eine derartige Vorgehensweise aktuell ein weithin akzeptiertes Vorgehensmodell. Wir sind überzeugt, dass es sich lohnt, an einem solchen Modell zu arbeiten.

Erkenntnis zum Mitnehmen:
Integration in heterogenen Anwendungslandschaften ist der wesentliche Aufwandstreiber. Das liegt vor allem daran, dass unterschiedliche Unternehmensfunktionen zwangsläufig ihre jeweils eigene Sicht auf die Geschäftsprozesse haben. Eine durchgängige Prozessunterstützung fällt daher nicht vom Himmel. Vielmehr müssen die beteiligten Fachabteilungen sie erarbeiten. Es erleichtert die Integration deutlich, wenn es für wichtige Datenelemente gemeinsame, von allen Fachabteilungen geteilte Sichten gibt.
(rs/cdf)

*Lesende aus der Branche mögen uns die grobe Vereinfachung verzeihen.