Vier Hebel – ein Ziel: So wird die IT-Modernisierung zum Erfolg

Vier Hebel – ein Ziel: So wird die IT-Modernisierung zum Erfolg

Migration, Neuentwicklung, Standardsoftware, Outsourcing – oder doch ein Mix? Meine Entscheidungshilfe für Ihre IT-Modernisierung.

In meinem letzten Blogbeitrag habe ich die zentralen Hürden der IT-Modernisierung beleuchtet und resümiert, dass Altsysteme mit steigender Lebensdauer immer mehr zu einer Belastung werden. Sind auch Sie zu dem Ergebnis gekommen, dass Ihre Applikationen und Entwicklungstechnologien modernisierungsbedürftig sind, und haben Sie alle Bedenken, die gegen eine Neugestaltung sprechen, aus dem Weg geräumt? Dann stellt sich jetzt die Frage nach dem Wie. Vier Wege der IT-Modernisierung habe ich Ihnen in der Vergangenheit bereits in Form einer Grafik aufgezeigt. Nun möchte ich detaillierter in das Thema einsteigen.

Stimmen Sie zu?

Wie modernisiert wird, hängt von vielen Faktoren ab – das reicht von der strategischen Ausrichtung über den Anteil der IT an den Wertschöpfungsprozessen bzw. Produkten und dem Digitalisierungsgrad des Unternehmens bis hin zu den Parametern Fertigungstiefe und Ressourcen. Jede der vier im Folgenden vorgestellten Modernisierungsalternativen hat ihre Vor- und Nachteile und die folgenden beispielhaften Aussagen sollen Ihnen dabei helfen, die Ihren Präferenzen entsprechende Option herauszuarbeiten.

1. Migration

  • Ich bin mit meiner Anwendung (Prozesse, Datenhaushalt, Funktionen etc.) grundsätzlich zufrieden.
  • Die Technologie ist zu teuer und unflexibel und/oder es ist kein Mitarbeiter-Know-how vorhanden.
  • Die Software bildet Prozesse ab, die zu den Kernkompetenzen meines Unternehmens gehören.
  • Die betreffenden unternehmensspezifischen Prozesse können oder sollen nicht in einem Standardschema abgebildet werden.
  • Aufgrund markt- oder unternehmensspezifischer Anforderungen sind keine längeren Code-Freeze-Zeiten möglich.
  • Die Softwaredokumentation ist unvollständig bzw. nicht aktuell, so dass zur Erfassung der vollständigen Funktionalität der Software ein Reengineering erforderlich wäre.
  • Um Erweiterungs- oder Änderungsanforderungen nicht zu verzögern bzw. um nicht über einen längeren Zeitraum hinweg doppelt implementieren zu müssen, ist eine kurze Projektzeit erforderlich.
  • Das Ziel ist eine stärkere Plattformunabhängigkeit (u.a. Application Server, Datenbank), um den Technologie-Stack zukünftig einfach austauschen zu können.

 2. Neuentwicklung

  • Die Altapplikation ist nicht mehr wartbar.
  • Die Altanwendung wird den Anforderungen des Unternehmens weder funktional noch prozessual oder datenseitig gerecht.
  • Im Applikationskontext sollen Differenzierungschancen am Markt erzielt werden, um damit deutliche Wettbewerbsvorteile zu realisieren.
  • Um eine Wertschöpfung zu generieren, sollen differenzierende Marktanforderungen agil und schnell umsetzbar sein.
  • Durch die Neuentwicklung wird nicht das gesamte Innovationspotenzial des Unternehmens gebunden.

3. Standardsoftware

  • Der Geschäftsprozess gehört nicht zu den Kernkompetenzen des Unternehmens und es besteht auch nicht der Wunsch, sich mit ihm gegenüber dem Markt zu differenzieren.
  • Der Anbieter der Standardsoftware verfügt über ein Standardmodell hinsichtlich Anpassung/Customizing (z.B. durch Customizing-Module, Prozessautomatisierung, Generierung etc.). Dieses ermöglicht aber auch Flexibilität und Agilität.
  • Das Preismodell (Anschaffung, Customizing und Wartung) ist attraktiver als das einer Migration oder Neuentwicklung, zudem besitzt der Anbieter eine sichere Marktposition und ist von seiner Struktur her zum eigenen Unternehmen „passend“.
  • Neue Anforderungen können durch eine am Markt befindliche Lösung (mit sehr geringem Customizing-Aufwand) abgedeckt werden.

4. Outsourcing

  • Der Partner bietet nicht nur ein Outsourcing, sondern auch eine IT-Modernisierung sowie die Option eines Re-Insourcings an.
  • Es besteht der Wunsch, die IT-technische Umsetzung von (fachlichen) Geschäftsprozessen nicht mehr selbst zu realisieren.
  • Der Geschäftsprozess ist so stark standardisiert, dass sich die Verlagerung des Geschäftsbereiches auch mit Blick auf die Transitionsaufwendungen rechnet.
  • Die verlagerten Geschäftsbereiche oder -prozesse gehören auch in absehbarer Zeit nicht zu den Kernkompetenzen des Unternehmens.

Schnellschüsse vermeiden

Im Grunde sprechen immer Punkte für die eine oder andere Option – auch deshalb findet man in der Praxis oft eine Mischung: So ist es bei einer automatisierten Migration z.B. denkbar, dass bestimmte Applikationsbestandteile über eine Neuentwicklung gelöst werden. Ich möchte Sie in diesem Kontext auf den Artikel „Softwareentwicklung: Buy or mAKE? Just BAKE!“ meiner Kollegin Anne-Kathrin Hanisch verweisen, der diesen Mix-Ansatz ausführlich thematisiert.

Generell führen die wachsenden und durch die Digitalisierung verschärften Marktanforderungen zu einem steigenden Modernisierungs- und Aktualisierungsbedarf und damit zwangsweise auch zu kürzeren Releasezyklen. Somit sind Ansätze im Vorteil, die kurze Modernisierungszeiten ermöglichen und die fachliche Weiterentwicklung nicht oder nur sehr gering beeinträchtigen. Anstatt Alternativen detailliert zu prüfen, werden in der Realität leider immer noch oft vorschnelle und falsch motivierte Entscheidungen getroffen, die am Ende im besten Fall zu einem hohen Aufwand führen und im schlechtesten das komplette Modernisierungsprojekt zum Kentern bringen. Setzen Sie Ihre Segel erfolgreich!


Bildquelle: Shutterstock

Hinterlassen Sie eine Antwort

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.