In fast jedem größeren Unternehmen gibt es sie: die Excel-Datei, ohne die die Quartalsplanung nicht funktioniert. Die Access-Datenbank, in der die halbe Instandhaltung hängt. Den nächtlichen Ablauf, der Daten zwischen zwei Systemen hin und her schiebt. Sie laufen seit Jahren, ohne sie geht es nicht, und der Mensch, der sie gebaut hat, arbeitet längst woanders.
So etwas abzulösen ist selten ein Technikproblem. Es geht um Wissen, Reihenfolge und Nachweise. Hier steht, wie das in fünf Etappen geht.
Wann ein System Legacy ist
Bei Altsystem denken die meisten an einen Großrechner oder ein ERP aus den Neunzigern. In der Praxis sind es fast immer andere Dinge: hunderte kleine Werkzeuge in den Fachbereichen, gebaut in Excel, Access, VBA oder der Power Platform. Mit dem Alter hat das nichts zu tun.
Ob etwas Legacy ist, merken Sie an vier Fragen. Wer ist dafür zuständig? Gibt es eine Beschreibung, die auch jemand versteht, der das Ding nicht gebaut hat? Können Sie eine Änderung ausprobieren, bevor sie scharf geht? Und weiß irgendwer, wie man eine Änderung überhaupt beauftragt?
Viermal keine Antwort? Dann haben Sie ein Altsystem vor sich. Egal ob die App zwei Jahre alt ist oder das ERP fünfzehn. Wer nach Baujahr sortiert, fängt beim falschen System an.
Die fünf Etappen
Von der ersten Bestandsaufnahme bis zum abgeschalteten Server sind es fünf Schritte. Sie bauen aufeinander auf: Erst wissen Sie, was da ist. Dann, was davon weg soll. Dann, in welcher Reihenfolge. Dann bauen Sie um, ohne den Betrieb anzuhalten. Und am Schluss kümmern Sie sich um die Daten, die Sie behalten müssen.
Wer einen Schritt überspringt, merkt das meistens erst, wenn es teuer wird.
Etappe 1: Ist-Analyse
Bevor Sie irgendetwas ablösen, müssen Sie wissen, was Sie überhaupt haben. Klingt banal. Ist aber der Schritt, den fast alle überspringen.
Zu jeder Anwendung wollen Sie ein paar einfache Dinge wissen. Wofür ist die da? Welcher Bereich arbeitet damit? Wie viele Leute sind das? Stecken persönliche Daten drin? Wo läuft sie? Wem gehört sie? Und die wichtigste Frage: Was hängt dran?
Einen Teil davon finden Sie am Rechner: im Power Platform Admin Center, auf den Dateifreigaben, in der Aufgabenplanung der Server, in den Datenbanken. Aber so finden Sie nur, was zentral liegt. Die Excel-Datei auf dem Laptop in der Buchhaltung findet auf diesem Weg niemand. Die findet nur, wer fragt. Ohne Gespräche in den Fachbereichen bleibt jede Ist-Analyse löchrig.
Am teuersten wird fast immer das, was zwischen den Systemen läuft. Selbstgebaute Verbindungen zwischen zwei alten Anwendungen stehen in keinem Vertrag und auf keiner Rechnung. Beim Ablösen fressen sie trotzdem oft den größten Teil des Aufwands. Wer sie erst mitten im Projekt entdeckt, hat sich längst verschätzt.
Planen Sie zwei bis sechs Wochen ein. Das meiste davon sind Gespräche und die Frage, was mit was redet. Am Ende haben Sie eine Karte Ihrer Systeme, auf der auch die Verbindungen dazwischen eingezeichnet sind. Wie so etwas abläuft, sehen Sie bei unserem Technical Health Check.
Etappe 2: Bewertung
Das gängige Raster heißt TIME und sortiert Anwendungen nach zwei Dingen: Wie wichtig sind sie fürs Geschäft, und wie gut ist ihr technischer Zustand. Daraus ergeben sich vier Schubladen: behalten, investieren, umziehen, abschalten.
Für gewachsene Werkzeuge aus den Fachbereichen fehlt da etwas Entscheidendes. Nämlich: Wie viele Menschen verstehen das Ding überhaupt noch? Wir fragen deshalb drei Sachen ab und geben je einen bis fünf Punkte.
| Frage | Was Sie wissen wollen | Fünf Punkte heißt |
|---|---|---|
| Wichtigkeit | Was passiert, wenn es morgen ausfällt? | Der Betrieb steht sofort |
| Zustand | Können Sie etwas ändern, ohne dass es kracht? | Jede Änderung ist ein Risiko |
| Wissen | Wie viele Leute verstehen, was da passiert? | Keiner oder genau einer |
Was Sie damit anfangen: Wichtig, kaputt und keiner versteht es? Das ist der klare Fall zum Ablösen. Wichtig, technisch in Ordnung, aber nur einer versteht es? Da brauchen Sie keine Ablösung, sondern eine Beschreibung und einen zweiten Kopf. Unwichtig und kaputt? Dann kommt die Antwort, an die kaum jemand denkt: einfach abschalten und nichts Neues bauen.
Etappe 3: Strukturiertes Vorgehen
Der erste Reflex ist, sich das größte Risiko zuerst vorzunehmen. Das geht meistens schief. Das kritischste System ist nämlich fast immer auch das komplizierteste: die meisten Verbindungen, die längste Geschichte, die meisten Sonderfälle. Wer dort anfängt, macht alle Anfängerfehler am teuersten Objekt. Und nach dem ersten Rückschlag ist die Unterstützung im Haus weg.
Nehmen Sie stattdessen etwas Mittelgroßes, das klar etwas bringt und an dem wenig hängt. Das ist schnell fertig, alle sehen ein Ergebnis, und Sie wissen danach, wie lange so etwas bei Ihnen wirklich dauert.
Zwei Regeln gelten trotzdem. Ein System, das andere mit Daten versorgt, kann nicht als erstes weg. Und wenn für ein System der Hersteller-Support ausläuft oder ein Prüfer etwas beanstandet hat, rückt es nach vorn, egal wie groß es ist. Wie so ein erster Schritt aussieht, steht in Migration in Etappen.
Etappe 4: Pilot und Parallelbetrieb
Das übliche Muster heißt Strangler Fig, nach der Würgefeige, die langsam um einen Baum herumwächst, bis der Baum verschwunden ist. Sie setzen etwas vor das Altsystem, das am Anfang einfach alles durchreicht. Neues bauen Sie nur noch im neuen System. Altes leiten Sie Stück für Stück um. Irgendwann greift nichts mehr auf das alte System zu, und Sie können es ausschalten. Der Vorteil: Sie können jederzeit anhalten.
Jeder einzelne Schritt sollte in zwei bis vier Wochen fertig sein. Dauert er länger, haben Sie den Vorteil schon verloren.
Schiefgehen kann das an drei Stellen. Erstens: Zwei Systeme schreiben gleichzeitig dieselben Daten. Dann haben Sie zwei Wahrheiten, und das Aufräumen kostet mehr als der Umzug selbst. Zweitens: Sie schneiden nach dem, was technisch einfach ist, statt nach dem, was fachlich zusammengehört. Dann bleibt nach jedem Schritt ein halber Prozess liegen. Drittens: Für das Ding, das Sie davorgesetzt haben, fühlt sich keiner zuständig. Deshalb braucht auch die Übergangszeit einen verantwortlichen Betreiber.
Etappe 5: Archivierung
Diese Etappe vergessen die meisten, und es ist die einzige mit rechtlichen Folgen. Wenn Sie ein System ausschalten, werden Sie die Daten nicht los. Aufbewahrungsfristen laufen bis zu zehn Jahre weiter. Ob das System, das die Daten erzeugt hat, noch existiert, interessiert dabei niemanden.
Wer den Server ausschaltet und denkt, die Datensicherung reicht, hat bei der nächsten Prüfung ein Problem. Eine Sicherung ist eine Kopie für den Notfall. Ein Archiv ist ein Nachweis. Das ist nicht dasselbe.
Vor dem Ausschalten also drei Dinge. Erstens: herausfinden, welche Daten Sie überhaupt aufheben müssen. In gewachsenen Systemen ist das selten einfach. Zweitens: diese Daten in ein Format bringen, das auch ohne das alte System lesbar bleibt. Sonst sitzen sie im Dateiformat einer Anwendung fest, die es nicht mehr gibt. Drittens: dafür sorgen, dass niemand sie nachträglich ändern kann. Wenn ein Administrator einen archivierten Datensatz anfassen kann, reicht das nicht.
Erst danach kündigen Sie Lizenzen, schalten Server ab und nehmen Zugänge weg. Und erst dieser Schritt spart das Geld, mit dem Sie das Projekt begründet haben.
Warum Ablöseprojekte scheitern
An der neuen Technik liegt es fast nie. Vier Dinge gehen immer wieder schief.
Die Daten. Alte Bestände sind lückenhaft, doppelt, oder das Entscheidende steht in einem Freitextfeld. Auffallen tut das meist beim ersten echten Testlauf, und da steht der Termin schon. Schauen Sie früh rein. Ein paar Tage Stichprobe ersparen Ihnen die teuerste Überraschung im ganzen Projekt. Worauf Sie dabei achten, steht in Datenqualität.
Der große Knall. Alles auf einen Stichtag umzustellen geht nur, wenn Sie vorher jeden Sonderfall und jede Abhängigkeit kennen. Bei gewachsenen Systemen kennen Sie die nie alle.
Was keiner aufgeschrieben hat. Der nächtliche Export, den ein anderes System seit acht Jahren einliest, steht nirgendwo. Er fällt auf, wenn er ausbleibt.
Die Leute, die damit arbeiten. Sie kennen die Sonderfälle, die in keiner Beschreibung stehen. Holen Sie sie erst zur Abnahme dazu, kommen ihre Anforderungen zum teuersten möglichen Zeitpunkt.
Wie Aliru unterstützt
Wir nehmen den Bestand auf, auch da, wo es keine Beschreibung und keinen Ansprechpartner mehr gibt. Wir bewerten jede Anwendung so, dass Sie die Bewertung nachvollziehen können, und schlagen eine Reihenfolge vor, die zu Ihrem Betrieb passt. Wo Ablösen sinnvoll ist, machen wir Umsetzung und Betrieb aus einer Hand, so wie in IT-Landschaft betreiben lassen beschrieben. Und wo es nicht sinnvoll ist, sagen wir Ihnen das auch. Ein guter Einstieg ist unser Workshop, oder Sie sprechen direkt mit uns über Ihre Altsysteme.
Häufig gestellte Fragen
Was ist ein Legacy-System?
Eine Anwendung, die im Alltag gebraucht wird, die aber niemand mehr sicher ändern kann. Auf das Alter kommt es dabei nicht an. Entscheidend ist, ob es einen Verantwortlichen gibt, eine Beschreibung, eine Möglichkeit zum Testen und einen Weg, Änderungen zu beauftragen. Fehlt das, ist auch eine junge Anwendung ein Altsystem.
Wie lange dauert die Ablösung eines Altsystems?
Eine einzelne Anwendung aus einem Fachbereich mit sauberen Daten schaffen Sie in zwei bis vier Monaten. Hängt viel daran und ist das System alt, dauert es deutlich länger. Für die Ist-Analyse davor sollten Sie zwei bis sechs Wochen einplanen.
Sollte man ein Altsystem auf einen Schlag ersetzen?
Meistens nicht. Eine Umstellung auf einen Stichtag funktioniert nur, wenn Sie vorher jeden Sonderfall, jeden Datenfehler und jede Abhängigkeit kennen. Bei gewachsenen Systemen kennen Sie die nie alle. Schrittweise umzustellen hält das Risiko klein, und Sie können jederzeit anhalten.
Was passiert mit den Daten nach der Abschaltung?
Die müssen Sie behalten. Aufbewahrungsfristen laufen bis zu zehn Jahre weiter, auch wenn das System längst weg ist. Bringen Sie die Daten vorher in ein Archiv, das ohne das alte System lesbar bleibt und in dem niemand mehr etwas ändern kann. Eine Datensicherung reicht dafür nicht.
Woran scheitern Ablöseprojekte am häufigsten?
An den Daten und an Verbindungen, die keiner aufgeschrieben hat. Lückenhafte Altdaten fallen meist erst beim ersten Testlauf auf, und Schnittstellen zu Nachbarsystemen stehen in keinem Vertrag. Beides finden Sie vorher, wenn Sie sich die Zeit für eine ehrliche Ist-Analyse nehmen.
Was kostet eine Ist-Analyse?
Das hängt davon ab, wie viele Anwendungen Sie haben. Bei einer überschaubaren Landschaft sind es wenige Beratungstage. Heraus kommt eine Karte Ihrer Systeme, eine Bewertung je Anwendung und eine Reihenfolge mit Begründung.
Muss immer abgelöst werden?
Nein. Einen Teil der Anwendungen behalten Sie bewusst, einen anderen bekommen Sie mit wenig Aufwand wieder in einen Zustand, in dem man damit arbeiten kann. Ablösen ist eine von mehreren möglichen Antworten.
Sie haben Fragen zu Dynamics 365?
Wir haben die Antworten.
Vereinbaren Sie einfach ein unverbindliches Erstgespräch mit einem Dynamics-Experten.
Termin vereinbaren
