IT-Landschaft analysieren und absichern

Die folgenden Beispiele aus der Praxis beschreiben konkrete Situationen, in die KMU geraten können:

Know-how-Verlust beim externen Partner

Ein Unternehmen lässt sich von einem Kleinbetrieb mit drei bis vier Software-Entwicklern ein ERP-System implementieren. Die Stabilität des Systems wird immer schlechter und Zwischenfälle mit inkonsistenten Daten häufen sich. Der Kopf der Lösung bei der Partnerfirma hat das Unternehmen vor einiger Zeit verlassen, die verbliebenen Entwickler beherrschen die Komplexität des indivi­duell aufgesetzten ERP-Systems nicht oder nur unzureichend. 

Legacy-System verhindert Wachstum

Die Standardlösung eines Unternehmens entwickelt sich langsamer als das eigene dynamische Geschäftsmodell. Neue Kunden könnten gewonnen werden mit zusätzlicher Funktionalität. Das Unternehmen kauft den Quellcode und entwickelt diesen mit eigenen internen und externen Ressourcen weiter. Schnell können neue Lösungen angeboten werden. Hierfür müssen jedoch mehr und mehr Eingriffe in die grundlegenden Strukturen von Software-Architektur und Datenbankmodell gemacht werden. Die Anpassungen erfolgen dort, wo es am schnellsten und billigsten geht. Nach wenigen Jahren benötigen zwingende regulatorische Anpassungen immer mehr Aufwand und führen zu unabsehbaren Folgefehlern, welche aufwendig behoben werden müssen. Der Testaufwand steigt ins Unermessliche. Der externe Entwicklungspartner ist in der Defensive, Konflikte häufen sich und mit dem Ende der Partnerschaft stehen wichtige Wissensträger nicht mehr zur Verfügung.

Entwicklerstolz als Stolperstein

Eine Standardlösung existiert nicht. Das schnelle Wachstum des erfolgreichen Geschäfts macht eine digitalisierte Lösung unabdingbar. Zwei initiative Software-Entwickler bauen mit verschiedenen Tools ein geeignetes System. Sie führen das System erfolgreich ein und betreuen den Geschäftsbereich über viele Jahre zur vollen Zufriedenheit. Laufend kommen Erweiterungen hinzu. Es werden immer wieder Möglichkeiten gefunden, neue Anforderungen auf der heterogenen Systemplattform zu realisieren. Einige der verwendeten Komponenten werden von den Herstellern nicht mehr weiterentwickelt und der Support entfällt. Entsprechend kommt der Zeitpunkt, da auch das Betriebssystem, auf welchem diese Komponenten betrieben werden, am «End of Life» angekommen ist. Nun muss das System zwingend ersetzt werden. 

Heute gäbe es Standard-Software hier­-für. Doch die hohe Individualisierung ist ein massives Hemmnis für den Geschäfts­bereich und die Software-Entwickler, welche sich mit ihrer Lösung identifi­zieren, die notwendigen Abstriche oder Anpassungen zu akzeptieren. Es muss mit dem Weggang der beiden Wissensträger gerechnet werden.

Problematische Übernahme

Ein erfolgreiches Unternehmen expandiert nach Nordamerika, indem es ein in der gleichen Industrie tätiges Unter­nehmen in Kanada aufkauft. Beide KMU haben hochindividualisierte Lösungen in Betrieb, welche den grössten Teil der Wertschöpfungskette abdecken. Um die internationalen Kunden global und einheitlich bedienen zu können, müssen Umgehungslösungen erarbeitet werden, da das Ersetzen von einer der beiden hochintegrierten Lösungen unwägbaren Aufwand für die jeweilige Organisation bedeuten würde. Zudem kündigen wichtige Wissensträger im neuakquirierten Unternehmen. 

Risiken analysieren

Wie können Betriebe solche Situationen entschärfen oder verhindern, dass es erst so weit kommt? Hier hilft eine Analyse. Diese genannten Fallbeispiele weisen einige Gemeinsamkeiten auf, die typisch sind für Probleme im Zusammenhang mit Legacy-Systemen. Die Problematik lässt sich auf folgende Eigenschaften und Umstände eingrenzen:

• schnelles Wachstum von Funktionalität
• keine geeignete Architektur und keine angepasste Anwendungsstrategie
• mangelnde Qualität aufgrund des forcierten Vorrangs von Zeit und Kosteneffizienz
• kein Verständnis für technische Schulden und die dadurch resultierenden späteren Kosten oder gar grundlegenden Betriebsrisiken
• Zentralisierung von Know-how
• Diese Risiken intensivieren sich mit der fortschreitenden Digitalisierung aufgrund des Druckes im Markt und der Fülle an neuen technologischen Möglichkeiten und Verheissungen. Grafisch lässt sich dies wie in der Abbildung gezeigt darstellen (Pace-Modell von Gartner).

Struktur einer IT-Landschaft

Dieses Modell verbildlicht, wie eine IT-Landschaft optimalerweise strukturiert werden soll. Wo ist Standardisierung gefragt, wo geht es um Differenzierung und wo ist Innovation notwendig?

Systems of Record

Auch mit der fortschreitenden Digitali­sierung verändern sich grundlegende Daten und Prozesse kaum. Betriebliche Ef­fizienz steht im Vordergrund. Die Notwendigkeit für Veränderungen ergibt sich meist aus regulatorischen Anpassungen sowie im Zusammenhang mit dem Wachstum des Unternehmens – insbesondere auch durch eine zunehmende Internationalisierung des Geschäfts. 

Hier werden meist Standard-Anwendungen eingesetzt (ERP-Systeme), wodurch Anpassungen durch den Software-Hersteller schnell und verhältnismässig günstig angeboten werden. Dabei handelt es sich zumeist um neue Releases, neue Daten- und Schnittstellentechnologien oder ergänzende Module.

Systems of Differentiation

Systeme zur Differenzierung müssen solide in die Basis-Systeme auf der Records-Ebene intergiert werden. Zusätzlich muss eine geeignete und robuste Abstraktionsschicht dazwischen gebaut werden, damit immer wieder angepasst werden kann. Der Bedarf an professioneller Entwicklung und Pflege ist gegeben.

Systems of Innovation

Innovative Systeme sollten nur lose verbunden werden. So können diese schnell wieder ersetzt werden. Oft werden solche Systeme durch marktnahe Funktionen im Unternehmen getrieben und mit eigenen oder externen IT-Fachleuten entwickelt. Wenn sie sich aber bewähren, also zum Differenzierungsfaktor werden, sollten sie ebenfalls sauber integriert werden. Die weitere Entwicklung und Pflege sollten professionalisiert werden.

IT-Know-how breit verteilen

Gerade im IT-Bereich verlassen sich viele KMU auf externe Partner. Doch welche Anforderungen muss ein externer Partner erfüllen? Es lohnt sich, mit externen Partnern zusammenzuarbeiten, um das notwendige Wissen verfügbar zu haben und die Kapazitäten für Projekte zeitweise zu erhöhen. Der Partner muss ergänzen, was intern an Wissen und Kapazität nicht nachhaltig aufgebaut werden kann oder soll. 

Wichtig ist, diese externen Partner kontinuierlich zu monitoren. Sind sie weiterhin innovativ und erfolgreich? Stellen die bezogenen Leistungen das Kerngeschäft des Partners dar? Wann lohnt es sich, ein eigenes Entwicklungs- und Betriebsteam beziehungsweise ein DevOps-Team (Development und IT Operations) zu unterhalten? Wann geht man besser eine langfristige Partnerschaft mit einem Lieferanten ein, welcher einem die IT-Sorgen in einem Full-Service-Package abnimmt? Diese Fragen müssen sich KMU im Rahmen ihrer IT-Strategie stellen. 

Doch wie kann auch eigenes Wissen aufgebaut und gepflegt werden? IT-Umgebungen werden immer komplexer und Know-how in diesem Feld ist ein kritischer Faktor geworden. Spezialisten werden in diesem Umfeld von Firmen aktiv um- und abgeworben. Wenn nun relevantes Wissen in einem Betrieb nur bei einer oder zwei Personen konzentriert ist, stellt dies ein regelrechtes Klumpenrisiko dar. Gerade KMU tun gut daran, das IT-Know-how breit zu verteilen. Auch Business-Fachleute müssen sich ein gutes Verständnis für IT-Zusammenhänge aneignen. 

Technische Schulden 

Als technische Schulden werden Lösungen bezeichnet, welche schnell und mit sehr wenig Aufwand realisiert wurden. Solche Lösungen längerfristig weiter­zuentwickeln und zu pflegen, ist mit viel Aufwand verbunden. Sie sind oftmals anfällig für Fehler und Qualität, Dokumentation und Nachvollziehbarkeit von Architektur und Code sind mangelhaft, und gerade in KMU sind meist nur ganz wenige Personen mit der Lösung vertraut. Kritisch wird es, wenn solche verschul­deten Lösungen dennoch ohne die notwendige Sanierung weiter ausgebaut werden und so zu einem regelrechten «Providurium» werden. 

Was also tun mit technischen Schulden? Diese müssen einem Unternehmen in erster Linie bekannt sein und entsprechend auf der – im übertragenen Sinne – Passivseite der IT-Bilanz aufgeführt sein. Die technischen Schulden müssen – um in dieser Metapher zu bleiben – laufend amortisiert werden, denn wenn die ganzen «Kosten» auf einen Schlag fällig werden, fehlt dann zumeist die nötige «Liquidität». Das Umschichten der Schulden ist nicht opportun, das heisst, es sollten keine schnellen Lösungen gesucht werden, welche dann wiederum bloss neue technische Schulden generieren.

Zielführender ist vielfach die Implementierung von Standardlösungen. Oft entstehen solche technischen Schulden auch durch den Einsatz von selbst geschrie­benen Tools. Waren diese individuellen Lösungen bei ihrer Einführung noch notwendig und sinnvoll, können sie nach ein paar Jahren zumeist mit Standardsoftware ersetzt werden. 

Zwischen Basis und Innovation

Was bedeutet nun all dies für die richtige Ausrichtung einer IT-Landschaftsstra­tegie von Unternehmen? Der Freiraum für Innovation muss gegeben sein, gleichzeitig darf die Basis des Geschäfts hier­unter nicht leiden oder dadurch sogar
gefährdet werden. 

Für die grundlegenden Systeme und Differenzierungssysteme muss eine solide und breite Basis an Ressourcen vorhanden sein. So können KMU dem Schreckensszenario eines IT-bedingten Ausfalls der Geschäftstätigkeiten vorbeugen.