Ich erlebe immer wieder, dass beim Thema IT-Architektur die Geschäftsleitung und das Management eines Unternehmens dankend jede Diskussion dazu ablehnen. Da seien sie nicht kompetent, und das sei sowie nur etwas auf sehr technischer Ebene und nicht relevant für sie. Und es gäbe ja unten im Maschinenraum bei der IT-Organisation die Experten.

Mit einer guten IT-Architektur verschaffst Du Deinem Unternehmen Vorteile in den Prozesskosten, in den IT-Kosten und insbesondere in der Agilität und Flexibilität für Innovationen. Und auch umgekehrt kann es Deinem Unternehmen gelingen, sich mit einer schlechten IT-Architektur völlig in eine Sackgasse zu bewegen, unflexibel und nicht mehr wettbewerbsfähig zu werden.

Darf ich Dich einladen, Dich kurz mit dem Thema zu beschäftigen?

Verfügbarkeit von Standardsoftware

Hast Du bei Dir im Unternehmen noch Software-Entwickler? Dann besteht für Dich vielleicht Handlungsbedarf. Heutzutage sind die meisten Business Funktionen in den meisten Branchen durch eine Art von Standardsoftware abgedeckt. Entweder zur Installation auf Deinen Servern oder Verfügbar als "Software-as-a-Service" (SaaS) aus der Cloud.

Falls Du in Deinem Unternehmen noch selbst Software entwickeln solltest (und das nicht Dein Kerngeschäft ist), dann solltest Du genau die Wertschöpfung Deiner IT-Organisation prüfen. Schafft selbst-programmierte Software Deinem Unternehmen wirklich einen Wettbewerbsvorteil? Und wie gross sind die Nachteile, dass Ihr die notwendigen Systemerweiterungen selbst vornehmen müsst? Und wie sieht es aus mit Digitalisierung und Prozessautomatisierung: Bist Du dazu heute schon mit vernünftigem Aufwand in der Lage?

Eine Frage sollte Dich leiten: Würdest Du, wenn Du heute neu Dein Unternehmen neu gründen würdest, erneut eine solche Software selbst entwickeln? Kennst Du auch genügend den Markt möglicher Lösungen?

Eventuell reduziert sich die Frage jetzt auf: Wie schnell kannst und solltest Du Deine selbstentwickelte Software ablösen. Wirft Du heute eventuell schon gutes Geld dem "schlechten" hinterher?

KI-Vorhaben: Time-to-market reduzieren mit der richtigen IT-Architektur

Gerade in grösseren Unternehmen kann die gleiche Idee für konkrete Anwendungen der künstlichen Intelligenz für verschiedene Geschäftsfelder oder Produkte und Dienstleistungen wiederverwendet werden. Damit hier nicht jedesmal das Rad neuerfunden wird, und damit wertvolle Zeit und Ressourcen verschwendet werden, empfiehlt es sich von Anfang an, eine konsistente IT-Architektur zu entwickeln.

Das nachfolgende Beispiel zeigt, wie innerhalb eines Chemie-Unternehmens für KI-Vorhaben eine solche IT-Architektur ausgestaltet wurde. Es wurde klar zwischen technischen Komponenten unterschieden, die speziell für jede der einzelnen Initiativen entwickelt waren. Und es wurden die Komponenten identifiziert, die übergreifend über die einzelnen Initiativen gemeinsam genutzt werden.

So konnte die Projektlaufzeiten reduziert werden und Kunden früher von den neuen Services profitieren. Und gleichzeitig wurden die Kosten für die Umsetzung reduziert.

Back from the Future

Grosse IT-Systeme und -Architekturen brauchen mehrere Jahre, bis Sie abgelöst, umgebaut oder konsolidert werden können. Dies gilt es bei der Festlegung der IT-Strategie, aber auch bei der Festlegung der Geschäftsstrategie eines Unternehmens zu berücksichtigen.

Im Fall eines Telekommunikationsanbieters hat sich das folgende Format für die Vorbereitung dieser Diskussion bewährt. Dieses Unternehmen hatte dezentral organisierte IT-Systeme. Die Konsolidierung dieser Systeme hatte zum Teil eine Vorlaufzeitzeit von bis zu 6 Jahren. Diese Szenarien wurden ergebnissenoffen auf Expertenebene definiert und bewertet und anschliessend dem Vorstand zur Entscheidung vorgelegt.

Ähnliche Ausgangssituationen finden sich nach jeder Akquisition eines anderen Unternehmens. Wie schnell sollten die Kostenvorteile durch Konsolidierung von IT-Systemen realisiert werden? Wie schnell sollen Kunden in neuer Form bedient werden? Und stehen genügend Ressourcen (finanziell, personell) für eine schnelle Konsolidierung von Systemen zur Verfügung?

Im Standard bleiben

Führt mein Unternehmen neue Standardsoftware ein, so gibt es den sofortigen Reflex, diese auf die gewohnten Abläufe im Unternehmen anzupassen. Der Gedanke dabei ist, dass das Unternehmen nur mit den historisch gewachsenen Prozessen funktionieren kann.

Klarerweise bedeutet die Umstellung von Prozessen und Gewohnheiten eine hohen Aufwand für die Belegschaft. Trotzdem ist eine Grundannahme zu berücksichtigen: Viele Unternehmen arbeiten bereits mit dieser Standardsoftware und sind mit den darin definierten Prozessen, Strukturen und Begriffen arbeitsfähig. Ein "Verbiegen" der Standardsoftware muss sich also wirklich lohnen, denn damit verliert man häufig genau die Vorteile der gekauften Software, nämlich die Release- und Upgradefähigkeit.

Daher würde ich jede Abweichung vom vordefinierten Standard einer Software, d.h. es muss etwas programmiert werden, durch ein Gremium auf Management-Ebene entscheiden lassen. Welche wirklichen Vorteile gibt es aus Kundenperspektive? Würde ein Kunde einen höheren Preis dafür bezahlen? Und wie hoch ist der Aufwand, heute - und bei jedem zukünftigen Release-Wechsel? Und dann berechne den Return-on-Invest (RoI), ob sich diese Investition für Dein Unternehmen lohnt.

Respektiere die Grenzen

Es gibt klassische Grenzen zwischen den Standard-Software-Systemen, die von den Herstellern üblicherweise eingehalten werden. Ein CRM-System wird normalerweise keine HR-Funktionalität anbieten, eine Produktionsplanungssoftware kein Kampagnen-Management, usw.

Was passiert, wenn man diese sogenannten Domänen-Grenzen überschreitet, zeigt mein Projekt-Beispiel eines Fleet-Management-Anbieters. Hier wurde - zum Teil aus finanziellen Gründen - der Anbieter des CRM-Systemen gebeten, die Funktionalität in die anderen Domänen zu erweitern. Da der CRM-Anbieter seinen strategischen Fokus natürlich auf die Marketing- und Vertriebsfunktionalitäten gelegt hat, fiel die Software-Funktionalität im Fleet-Management-Bereich deutlich hinter den Wettbewerb zurück.

Ein Software-Wechsel war für meinen Kunden kaum möglich: Er war durch das Überschreiten der Domänen-Grenzen "locked-in", denn es hätte einen Wechsel seiner gesamten Software-Landschaft bedeutet. Mein Kunde fiel in Bezug auf Customer-Self-Service und Prozessautomatisierung immer weiter im Wettbewerb zurück. Letztlich hat der Software-Anbieter die Zusammenarbeit aufgekündigt und mein Kunde war gezwungen, unter Zeitdruck die umfangreiche Migration seiner Software-Landschaft zu starten.

Solche Abhängigkeiten auf Grund falscher IT-Architekturen gilt es für Dich als Unternehmer unbedingt zu vermeiden.