Vielen IT Strategien fordern Standardisierung und Komplexiätsreduktion zur Senkung von IT Kosten. Prinzipiell eine gute Idee. Aber die Erfahrung zeigt, dass Standards einerseits die Qualität bei geringeren Kosten erhöhen können, andererseits aber Freiheiten und Flexibilität beim Fachbereich einschränken. Viele IT Abteilungen haben Schwierigkeiten dem Fachbereich zu vermitteln, warum in globalen Standards einige Wünsche nicht adäquat erfüllt werden können. Der Fachbeich fühlt sich von der IT eingeschränkt und schimpft. Die Kernfrage also lautet, was kann die IT wie weit Standardsieren und wo muss sie Freiheiten erlauben, damit das Business in seiner Handlungsfähigkeit nicht eingeschränkt wird?

Business Capabilities als etabliertes Planungsartefakt

Bei vielen Enterprise Architekten haben sich in den letzten Jahren Business Capabilties als zentrales Planungsartefakt etabliert. Business Cabilities beinhalten Geschäftsfunktionen, die über Applikationen oder Services dem Fachbereich zur Verfügung gestellt werden. Eine Business Capability ist beispielsweise das „Angebotsmanagement“ und eine Business Funktion innerhalb der Capability wäre „Angebot erstellen“. Innerhalb der Bebauungsplanung wird dann entscheiden, welche Applikationen die Business Capability bereitstellen. Business Capabilities können fachlich je nach Kunden-, Produktgruppen und Vertriebskanälen unterscheidlich ausgeprägt sein und somit von verschiedenen Applikationen bedient werden.

Das Problem der der Übersimplifizierung

standards1Fordert nun die IT Strategie „Standardisierung und Komplexitätsreduktion“ betrachtet sie häufig Business Capabilities und stellt fest, dass man doch bestimmt die vielen Applikationen auf einen Applikationsstandard reduzieren kann. Aus IT Sicht ist ein Angebot ein Angebot. Durch Ablösung des Applikationsparallebetriebs, könne man doch sicherlich viel einsparen, ist die Meinung.

Prinzipiell ist das korrekt. Aber die Erfahrung zeigt, dass ein Angebot aus interner IT Tunnelsicht vielleicht ein Angebot ist, aber nicht aus Markt- und Kundensicht. Viele Projekte habe ich scheitern sehen, die zuviel „gleich“ machen wollten. Man fängt dann an mit einem Standard, möglichst auf Basis von Standardsoftware und führt mitgelieferte Prozesse ein, die gecustomizt werden. Das Projektteam hält das häufig nicht lange durch, weil durchsetzungstarke Geschäftsbereiche diese Standards nicht akzeptieren und Sonderlösungen fordern. Es wächst eine neues Applikationsmonstrum heran mit vielen Ausnahmen- und Sonderbehandlungen. Wenn es ganz schlecht läuft, ist die neue Lösung insgesamt schlechter und teuerer, als vorher die unabhängigen Einzellösungen. Man ist in die Falle der fachlichen Übersimplifzierung getappt und hat damit noch höhere technische Komplexität geschaffen.

Der optimale IT Standardisierungsgrad

Wie aber findet man heraus, welche Applikationen zusammengefasst oder standardisiert werden können und welche nicht? Wofür verwende ich Kaufsoftware und was entwickle ich lieber selber?

Innerhalb meiner Standardisierungprojekte entwickle ich mit Hilfe meiner Bebauungsplanngsmethodik spezialiserte Sichten auf das Geschäftsmodell aus Bebaungsplanungssicht. Diese Sichten setzen verschiedene strategische Dimensionen in Beziehung zueinander, wie strategische Geschäftsfelder, Business Cababilities, Wertschöpfungsarchitekur, Vertriebskanäle und die Wettberwerbposition. Aus diesen Sichten geht deutlich hervor, was aus Geschäftsmodellsicht fachlich gleich und was fachlich untscheiderlich zu behandeln ist. Über die Wettbewerbsposition wird zusätzlich festgelegt, welche Bereiche der Wertschöpfungsarchitektur wettbewerbsdifferenzierend (Differentiators) sind und in welchen der Marktstandard (Commodities) ausreichend ist, um Kunden nicht zu verlieren. Aus einer Sicht lässt sich beispielsweise Ableiten, dass für Commdodities Prozesse einer Standardsofware ausreichend sind, für Differentiator aber unbedingt nicht standardisierete wettbewerbsdifferenzierende Prozesse implementiert werden sollten.

Mit diesen speziell entwickelten Bebauungsplanungswerkzeugen konnte ich einem Kunden helfen, der in die Falle der Übersimplifizierung getappt ist. Er hat versucht alle Applikationen innerhalb einer Business Capability in eine neue Applikation zu überführen. Nach vielen Jahren und Millionen Euro hat er ein Fertigstellungsgrad von 60% erreicht. Die technische Komplexität wurde mittlerweile so hoch, dass er sich nicht mehr zutraute, die Applikation mit dem geplanten Scope fertig zu entwickeln und später effektiv zu betrieben. Mit Hilfe meiner Bebauungsplanungswerkzeuge entwickelten wir einen Ordnungsrahmen, der aus Geschäftsmodellsicht aufzeigte, was unbedingt getrennt zu behandeln ist und was gleich behandelt werden kann. Auf dieser Basis konnte die technische Komplexität fachlich entzerrt und die Appliaktion technisch in mehrere fachlich unabhängige Applikationen aufgesplittet werden. Hierüber konnten wir einen optimalen IT Standardisierungsgrad für die Business Capability erreichen .

Höhere IT Standardardisierung durch Auflösung unnötiger Komplexität im Geschäftsmodell

standards2Was unsere Bebauungsplanungssichten auf das Geschäftsmodell auch offengelegt haben, war die Komplexität der Wertschöpfungsarchitektur. Teilweise gab es sogar Inkonsistenzen in der Definition strategischer Geschäftsfelder, die zu fachlichen Widersprüchen führten. Teilweise war die Wertdisziplin eines Geschäftsfelds nicht eindeutig festgelegt. Also gewinnt das Geschäftsmodell den Kunden über Kundennähe oder über relativ höherwertige, innovative Produkte? Die erste Wertdisziplin führt zu einer Wertschöpfungsarchitetkur, die den Kunden ins Zentrum stellt, die Zweite stellt das Produkt in den Mittelpunkt. In der Wertschöpfungsarchitektur meines Kunden, war keine klare Linie erkennbar. Manche Business Capabilites waren eher auf Kundennähe ausgelegt, andere auf Produktinnovation ohne Kundenbezug. In der IT Bebbauung führte es dazu, dass ein grosses CRM installiert wurde, das aber fachlich wirkungslos bleib, weil an anderer Stelle keine sinnvollen Kundendaten generiert wurden, die eine invdivuelle Kundenansprache ermöglichten. Man stellte im Geschäftsmodell fest, dass man doch eher produktorientiert sei und lieber Produktdaten zur Produktentwicklung sammeln möchte. Das komplexe CRM System wurde abgebaut.

Durch Auflösung von Widsprüchen im Geschäftsmodell konnte die Wertschöfungsarchitektur vereinfacht und die IT Bebauungs weiter standardisiert und vereinfacht werden.

Sie möchten Ihre IT standardsieren oder die Komplexität redzuzieren?

_MDP8473b
Marina Ribke – Strategic Enterprise Architect

Mit Hilfe meiner Strategischen Enterprise Architektur Methoden kann ich Ihnen helfen zu entscheiden, was sie standardisieren sollten und was keinesfalls, um nicht in die Falle der Übersimplifizierung zu tappen. Weiter kann ich Sie mit Business Engineering/Architektur Methoden unterstützen, unnötige Komplexität im Geschäftsmodell zu reduzieren, damit Sie den Standardisierungsgrad in der IT weiter steigern können.

Sie wollen mehr zum Thema erfahren? Dann kontaktieren Sie mich gerne.