Altsysteme ablösen, ohne den Betrieb anzuhalten

Die Anwendung, mit der Ihre Disposition arbeitet, ist eine Access-Datenbank auf einem Netzlaufwerk. Gebaut hat sie jemand aus der Technik, nebenbei, vor über einem Jahrzehnt. Er ist inzwischen in Rente. Eine Dokumentation gibt es nicht. Die Datenbank läuft trotzdem, jeden Tag.

Altsysteme werden selten abgelöst, solange sie laufen. Der Auslöser ist fast immer ein Risiko, das irgendwann größer wird als der Aufwand der Ablösung. Der Hersteller kündigt eine Version ab. Die einzige Person, die den Datenbestand versteht, kündigt. Der Wirtschaftsprüfer fragt, wie eine Buchung nachvollziehbar bleibt. Oder ein Fachbereich braucht eine Auswertung, die das System nicht liefert, und baut sie daneben in Excel.

Woran Sie merken, dass der Zeitpunkt da ist

• Der Hersteller stellt den Support für Ihre Version ein. Ein Upgrade wäre faktisch eine Neueinführung.
• Die Software läuft auf einem Server, den niemand anfassen will, weil unklar ist, ob er wieder hochkommt.
• Änderungen an Stammdaten oder Auswertungen kann genau eine Person vornehmen. Deren Urlaub ist ein betriebliches Thema.
• Neue Anforderungen aus Gesetz oder Vertrag lassen sich nicht mehr abbilden, etwa die E-Rechnung, geänderte Abrechnungslogik oder Nachweispflichten gegenüber Behörden.
• Zwischen den Systemen wird per Export und Import gearbeitet. Dieselbe Information wird an drei Stellen gepflegt.
• Die eigentliche Fachlogik ist über die Jahre in Tabellen neben das System gewandert.

Der schwierige Teil eines Ablöseprojekts ist selten die neue Anwendung. Schwierig sind die Daten und das Wissen, das nirgends steht: warum Status 7 bedeutet, dass ein Vorgang ruht. Warum Datensätze mit der Kundennummer 99999 aus jeder Auswertung fliegen müssen. Warum in einem Adressfeld manchmal ein Ansprechpartner steht.

• E-Rechnung: Pflichten und Fristen

Excel und Access sind gute Werkzeuge. Sie stehen nur an einer Stelle, für die sie nie gedacht waren: mitten im Tagesgeschäft, mit mehreren Leuten gleichzeitig daran. Entstanden sind sie, weil jemand ein Problem hatte und niemand ein Budget. Das verdient Respekt. Zur Frage wird es erst, wenn mehr als eine Person davon abhängt und ein Fehler darin Geld kostet.

Der Punkt, an dem es kippt

• Mehrere Personen wollen gleichzeitig arbeiten. Die Datei ist gesperrt, es entstehen Kopien mit Namenszusatz.
• Es lässt sich nicht rekonstruieren, wer wann welchen Wert geändert hat. Für Abrechnung, Personal oder Buchhaltung ist das ein Problem.
• Formeln beziehen sich auf Zeilennummern. Jemand sortiert, und die Zahlen stimmen still nicht mehr.
• Jeder mit Zugriff auf das Netzlaufwerk sieht alles, auch personenbezogene Daten, die er nicht sehen darf.
• Makros brechen nach einem Office-Update. Reparieren kann sie niemand mehr.
• Andere Systeme brauchen die Daten, es gibt aber keine Schnittstelle, nur einen manuellen Export.

Jede Tabelle ersetzen zu wollen, wäre Unsinn. Eine Aufstellung, die eine Person einmal im Quartal für sich selbst führt, kann bleiben. Und wo ein Standardprodukt den Fall vollständig abdeckt, ist es die günstigere Antwort. Sie hören das von uns, bevor ein Angebot über Eigenentwicklung entsteht. Die Abwägung dazwischen beschreibt der Beitrag im Wissensbereich.

• Individualsoftware oder Standardsoftware

Eine Migration beginnt bei der Arbeit, die mit dem System erledigt wird, und erst danach beim Datenmodell. Vor der ersten Zeile Code gehören ein paar Fragen beantwortet. Sie klingen banal. Die Antworten sind es selten.

1. Welche Prozesse laufen tatsächlich über das System, und welche laufen längst daneben?
2. Welche Datenobjekte gibt es, wie hängen sie zusammen, und welches System ist heute das führende für welches Objekt?
3. Wer liest die Daten außerdem? Reporting, BI-Werkzeuge, direkte Datenbankabfragen aus Excel, Nachbarsysteme, Meldungen an Behörden oder Marktpartner.
4. Welche Felder tragen eine Bedeutung, die im Feldnamen nicht steht?
5. Welche Daten unterliegen Aufbewahrungspflichten, und ab welchem Zeitpunkt gerechnet?
6. Was passiert, wenn das System einen Tag steht? Und was, wenn es eine Woche steht?

Die Antwort auf Frage drei ist der häufigste Grund für böse Überraschungen. An einem Altsystem hängen fast immer mehr Abnehmer, als in der Projektskizze stehen.

Beim Big Bang wird das Altsystem an einem Stichtag abgeschaltet und das neue System übernimmt vollständig. Bei der schrittweisen Ablösung laufen beide Systeme eine Zeit lang nebeneinander, und die Fachlichkeit wandert Modul für Modul hinüber. Beide Wege sind legitim. Sie kosten unterschiedlich viel, an unterschiedlichen Stellen.

Wann der Big Bang die richtige Wahl ist

• Das Altsystem lässt sich technisch nicht parallel betreiben, weil die Lizenz endet, die Hardware abgeschaltet wird oder der Hersteller den Betrieb einstellt.
• Der Datenbestand ist überschaubar und das Datenmodell klar. Es gibt wenige Objekte mit sauberen Beziehungen.
• Es existiert ein natürlicher Schnitt: Jahreswechsel, Ende einer Abrechnungsperiode, Umzug, Ausgründung.
• Es gibt kaum Schnittstellen zu Nachbarsystemen, die synchron gehalten werden müssten.
• Der Fachbereich kann ein definiertes Fenster im Notbetrieb überbrücken, notfalls auf Papier.

Wann die schrittweise Ablösung die bessere ist

• Viele Schnittstellen, an denen Marktpartner, Behörden oder Kunden hängen.
• Mehrere Fachbereiche, die unterschiedlich schnell mitgehen können.
• Unklare Datenqualität. Jeder Schritt bringt Erkenntnisse, die den nächsten günstiger machen.
• Betrieb rund um die Uhr, kein realistisches Stillstandsfenster.
• Der Nutzen wird früh gebraucht, und das Budget verteilt sich über mehrere Haushaltsjahre.

Der teuerste Weg ist ein Big Bang, der scheitert und mitten im Projekt in eine schrittweise Ablösung umgebaut wird. Legen Sie die Entscheidung am Anfang schriftlich fest, zusammen mit dem Kriterium, an dem sie gekippt wird.

Der Name stammt aus der Botanik: Die Würgefeige wächst um einen Baum herum, lebt zunächst mit ihm und steht am Ende allein. Übertragen auf Software heißt das, dass das Altsystem weiterläuft, während das neue System Stück für Stück übernimmt, bis vom Alten nichts Gebrauchtes übrig bleibt.

An einem Fachsystem für Lieferstellen und Verbräuche sieht das konkret so aus:

1. Die neue Anwendung wird davorgesetzt. Anwender arbeiten ab sofort in der neuen Oberfläche, dahinter antwortet zunächst weiterhin das Altsystem. Fachlich ändert sich nichts, die Anwender gewöhnen sich an die Bedienung.
2. Das erste Modul wird lesend übernommen. Lieferstellen und Stammdaten liegen jetzt auch im neuen System und werden dort angezeigt. Führend bleibt das Altsystem. Ein täglicher Abgleich vergleicht beide Bestände, Abweichungen landen auf einer Liste, die eine benannte Person durchsieht.
3. Die Schreibrichtung dreht sich um. Wenn die Abweichungsliste über mehrere Wochen leer bleibt, wird das neue System für dieses Modul führend. Änderungen werden ins Altsystem zurückgespiegelt, damit die daran hängenden Auswertungen und Meldungen weiterlaufen.
4. Das nächste Modul folgt nach demselben Ablauf, etwa Zählerstände. Der Weg ist bekannt, deshalb geht jeder weitere Schritt schneller als der erste.
5. Nach und nach wandern Verträge, Objekt- und Dokumentenverwaltung sowie die Verbrauchs- und Kostenauswertung hinüber.
6. Am Ende hat das Altsystem keine schreibenden Anwender mehr. Offen ist dann nur noch die Frage nach der Historie, und die sollte zu diesem Zeitpunkt längst geklärt sein.

Der Preis dieses Vorgehens ist die Synchronisationsschicht. Sie wird gebaut, sie wird betrieben, sie wird getestet, und am Ende wird sie weggeworfen. Im fertigen System ist dieser Aufwand unsichtbar. In der Rechnung steht er. Dafür gibt es keinen einzigen Tag, an dem alles gleichzeitig funktionieren muss.

Damit das Muster trägt, müssen die Schnitte entlang der Fachlichkeit verlaufen. Ein Modul, das fachlich sauber abgegrenzt ist, lässt sich einzeln umziehen. Ein Modul, das an Dutzenden Stellen im Altcode angefasst wird, hält den ganzen Rest fest. Wie solche Übergänge technisch aussehen, beschreibt die Seite zu Schnittstellen und Integrationen.

• Schnittstellen und Integrationen

Eine Migration läuft öfter, als die Planung annimmt: auf Testdaten, auf einer Kopie der Produktion, im Probelauf, im Ernstfall und danach noch einmal für die Nachzügler. Alles, was dabei von Hand nachgebessert wird, fehlt beim nächsten Lauf. Deshalb steht jeder Schritt in Code, auch die Korrekturen.

Abgleichszahlen vor und nach jedem Lauf

Vor jedem Lauf wird der Quellbestand gezählt, nach jedem Lauf der Zielbestand. Die Differenz muss erklärbar sein, jede einzelne. Nützlich sind:

• Anzahl der Datensätze je Objekt in Quelle und Ziel, mit Differenz und Begründung.
• Summen über die fachlich entscheidenden Felder: Beträge, Verbrauchsmengen, offene Posten, Flächen.
• Anzahl je Status. So fällt auf, wenn beim Mapping ein Status stillschweigend verschwindet.
• Verweise, die ins Leere zeigen, gezählt vor und nach dem Lauf.
• Eine feste Stichprobe an Einzeldatensätzen, die Feld für Feld im Volltext verglichen wird, darunter bewusst die hässlichen Fälle.

Diese Zahlen werden protokolliert und aufgehoben. Ein Migrationslauf ohne Protokoll lässt sich später nicht mehr beurteilen, und beurteilt werden muss er, sobald im Fachbereich jemand sagt: Da fehlt etwas.

Testlauf mit echten Daten

Der Probelauf findet auf einer Kopie des Produktivbestands statt, in einer abgeschotteten Umgebung. Erfundene Testdaten zeigen genau die Probleme nicht, um die es geht: Umlaute aus einer alten Zeichenkodierung, Datumsangaben aus dem Jahr 1900, eine komplette Adresse in einem Bemerkungsfeld, Beträge mit vier Nachkommastellen. Eine Kopie echter Daten braucht denselben Schutz wie das Produktivsystem: eingeschränkter Zugriff, definierte Löschung nach dem Test, geregelte Auftragsverarbeitung, Hosting in Deutschland oder der EU.

Rückfallebene

Vor dem Umstieg wird schriftlich festgehalten, wann abgebrochen wird. Dazu gehören eine Uhrzeit, zu der die Entscheidung fällt, ein Kriterium, das den Abbruch auslöst, und eine Person mit Namen, die entscheidet. Das Altsystem bleibt lesend erreichbar, mindestens bis der erste Monats- oder Periodenabschluss im neuen System fehlerfrei durchgelaufen ist. Erst danach wird über das Abschalten gesprochen.

Eine Rückfallebene, die nie geprobt wurde, ist keine. Der Rückweg gehört einmal durchgespielt, bevor der Hinweg live geht.

Die Frage kommt meistens spät und meistens von der Buchhaltung: Und was ist mit den alten Vorgängen? Zu diesem Zeitpunkt ist das Budget verplant. Dabei ist die Historie oft der größere Teil des Datenbestands, und sie ist fast immer der unordentlichere. Alte Datensätze stammen aus Zeiten, in denen das System anders aufgebaut war, Felder anders hießen und Regeln anders galten.

Es gibt im Wesentlichen diese Wege, und jeder hat einen Preis:

• Vollmigration. Alles wandert mit, auch Vorgänge aus weit zurückliegenden Jahren. Der Aufwand steigt überproportional, weil für alte Jahrgänge eigene Umsetzungsregeln nötig sind. Dafür gibt es danach nur noch ein System.
• Stichtagsmigration mit Lesearchiv. Nur der aktive Bestand zieht um, das Altsystem bleibt als Nur-Lese-Instanz stehen. Am Anfang günstig. Der Preis läuft dauerhaft weiter: Lizenz, Server, Sicherheitsupdates und eine Anwendung, die niemand mehr pflegen kann.
• Export in ein Archivformat. Die Historie wird strukturiert exportiert, als Daten plus Index plus lesbare Belegdateien, und in ein Archiv gelegt, das unabhängig von der alten Anwendung auswertbar bleibt. Aufwand einmalig, Betrieb danach schlank.

Bei der Entscheidung reden Recht und Fachlichkeit mit. Handels- und Steuerrecht schreiben Aufbewahrungsfristen vor, gestaffelt nach Art der Unterlage (§ 257 HGB, § 147 AO). Die Fristen für Belege wurden zuletzt geändert, prüfen Sie also den heute geltenden Stand statt der Zahl, die im Haus herumgeistert. Die GoBD verlangen zusätzlich, dass steuerlich relevante Daten während der Aufbewahrungsfrist maschinell auswertbar bleiben. Ein Stapel PDF-Dateien auf einem Netzlaufwerk erfüllt das nicht zwangsläufig. Klären Sie das mit Ihrem Steuerberater, bevor das Migrationskonzept steht.

Neben den Pflichtdaten gibt es die Historie, an der die Anwender hängen: Gesprächsnotizen, Kündigungsgründe, Anhänge, die Vorgeschichte einer Reklamation. Sie steht in keinem Gesetz und wird trotzdem täglich gebraucht. Fragen Sie im Fachbereich, wie weit zurück tatsächlich gesucht wird. Die Antwort ist oft kürzer als befürchtet und begrenzt den Aufwand deutlich.

Klären Sie die Historie im Angebotsstadium. Sie ist der Posten, der Migrationsbudgets am zuverlässigsten sprengt.

Wenn eine Migrationsschätzung deutlich danebenliegt, hat das fast immer denselben Grund: Die Daten sahen anders aus als angenommen. Die Technik einer Migration ist beherrschbar. Der Aufwand entsteht an den Stellen, an denen ein Wert nicht in die Zielstruktur passt und jemand entscheiden muss, was mit ihm geschieht.

Was sich in gewachsenen Beständen regelmäßig findet:

• Dubletten. Derselbe Kunde vier Mal, jedes Mal leicht anders geschrieben, mit unterschiedlichen Vorgängen daran.
• Freitext in Feldern, die eine Auswahl sein sollten: ja, Ja, j, JA mit Leerzeichen, ja (siehe Notiz).
• Fachliche Bedeutung in Bemerkungsfeldern. Sonderkonditionen, Kündigungsgründe und Zuständigkeiten stehen dort, wo sie niemand auswerten kann.
• Nummernkreise, die zweimal bei eins beginnen, weil das System vor Jahren neu aufgesetzt wurde.
• Datensätze, die als gelöscht gelten, aber nur ein Kennzeichen tragen, und in manchen Auswertungen trotzdem mitzählen.
• Verweise auf Datensätze, die es nicht mehr gibt.
• Zeichensätze, Datums- und Zahlenformate aus verschiedenen Epochen desselben Systems.

Deshalb steht am Anfang ein Datenprofiling am echten Bestand: Feldbelegung, Wertebereiche, Häufigkeiten, Dubletten, Referenzintegrität. Das Ergebnis verschiebt Schätzungen regelmäßig, in beide Richtungen. Eine belastbare Zahl vor diesem Blick in die Daten gibt es nicht. Wer sie trotzdem nennt, rechnet später nach.

Die Bereinigung selbst ist Facharbeit und gehört in Ihr Haus. Welcher der vier Kundendatensätze der richtige ist, kann kein Entwickler entscheiden. Was Entwicklung leisten kann: die Zweifelsfälle finden, sie in einer Arbeitsliste mit Kontext bereitstellen und jede Entscheidung so festhalten, dass der nächste Migrationslauf sie automatisch wieder anwendet. Niemand soll dieselbe Frage zweimal beantworten.

Planen Sie Arbeitszeit im Fachbereich ein, in Personentagen, mit Namen. Das ist der Posten, der in Projektplänen am häufigsten fehlt und Termine am zuverlässigsten verschiebt.

Ein Altsystem ist auch eine Gewohnheit. Wer seit Jahren blind über die Tastatur durch eine Maske springt, braucht für denselben Vorgang in der neuen Oberfläche zunächst länger. Diese Delle gehört eingeplant und angesprochen, sonst wird sie im Haus als Fehler der neuen Software gelesen.

• Je Modul eine Person aus dem Fachbereich, die die Abnahme macht, mit Zeit dafür im Kalender.
• Geschult wird an den eigenen Daten aus dem Probelauf, nicht an Beispielkunden mit Musterstraße 1.
• Zuerst die Vorgänge, die täglich vorkommen. Die Sonderfälle folgen, wenn der Alltag sitzt.
• Ein Ort für Rückmeldungen aus den ersten Wochen, statt Zurufe über drei Kanäle. Jede Meldung bekommt eine Antwort, auch die abgelehnte.
• Die alten Masken bleiben als Referenz zugänglich, solange das Altsystem lesend läuft. Das nimmt der Umstellung die Schärfe.

Der Umstellungstermin gehört gegen den Kalender des Fachbereichs gelegt, nicht gegen den des Projekts. Jahresabschluss, Abrechnungslauf und Urlaubszeit werden vorher markiert.

Für mexxenergie, einen Energiedienstleister in Baden-Württemberg, ist eine mandantenfähige Plattform mit vier Fachmodulen entstanden: Zählerstände und Lieferstellen, Verträge, Objekt- und Dokumentenverwaltung sowie Verbrauchs- und Kostenauswertung.

Die Altbestände sind im laufenden Betrieb umgezogen. Es gab kein Wochenende, an dem alles auf einmal wechselte. Vor und nach jedem Migrationslauf standen Abgleichszahlen: Datensätze je Objekt, Summen über die fachlich relevanten Felder, eine Liste der Abweichungen. Erst wenn die Zahlen zusammenpassten und die offenen Punkte geklärt waren, wurde der nächste Schritt freigegeben.

• Projekt mexxenergie
• Software für Energieversorger

Ein Ablöseprojekt besteht selten nur aus der Migration. Dazu kommen die neue Fachanwendung, die Schnittstellen zu den Nachbarsystemen und der Parallelbetrieb. Typischerweise liegt so ein Vorhaben in diesem Band:

Wo Sie innerhalb des Bandes landen, entscheiden vor allem die Anzahl der Systeme, die weiter versorgt werden müssen, der Umfang der Historie, die Datenqualität und die Dauer des Parallelbetriebs. Jeder zusätzliche Monat Parallelbetrieb kostet Synchronisation und doppelte Pflege.

Für die Migration selbst ist ein Festpreis vor dem Datenprofiling unseriös. Sinnvoll ist ein zweistufiges Vorgehen: Profiling und Migrationskonzept zum Festpreis, danach die Umsetzung auf dieser Grundlage, dann mit einer Zahl, die trägt. Die Abwägung zwischen den Vertragsformen steht im Wissensbereich.

• Ablauf und Kosten
• Festpreis oder Aufwand

Wie lange dauert eine Datenmigration?

Der technische Lauf ist der kürzeste Teil, er passt in der Regel in eine Nacht. Den Kalender bestimmen die Klärungsrunden mit dem Fachbereich: Welche Felder werden wie abgebildet, was passiert mit Zweifelsfällen, wie weit zurück reicht die Historie. Wer diese Runden früh terminiert und mit Namen besetzt, verkürzt das Projekt stärker als jede technische Optimierung. Bei einer schrittweisen Ablösung kommt für jedes Modul eine eigene Runde dazu.

Kann das Altsystem während der Migration weiterlaufen?

Ja, das ist bei der schrittweisen Ablösung der Normalfall. Beide Systeme laufen parallel, ein Abgleich hält die Bestände synchron, und für jedes Datenobjekt ist zu jedem Zeitpunkt festgelegt, welches System das führende ist. Diese Festlegung ist der wichtigste Punkt im ganzen Konzept. Wenn zwei Systeme gleichzeitig führend sind, entstehen Widersprüche, die sich später kaum noch auflösen lassen.

Was passiert, wenn nach dem Umstieg Daten fehlen?

Genau dafür gibt es die Abgleichszahlen und das Protokoll jedes Laufs. Damit lässt sich in der Regel schnell sagen, ob ein Datensatz nie migriert wurde, ob er bewusst gefiltert wurde oder ob er im Ziel unter anderer Kennung liegt. Solange das Altsystem lesend erreichbar bleibt, lassen sich fehlende Bestände nachziehen. Deshalb wird es nicht am Tag des Umstiegs abgeschaltet.

Müssen wir unsere Daten vorher bereinigen?

Vollständig bereinigen müssen Sie nichts. Es lohnt sich aber, die großen Kategorien vorher anzugehen, insbesondere Dubletten in Stamm- und Kundendaten. Alles, was vor der Migration entschieden wird, kostet einmal Zeit. Alles, was danach auffällt, kostet Zeit plus Korrektur im laufenden Betrieb. Welche Fälle es überhaupt gibt, zeigt das Datenprofiling, bevor jemand mit dem Aufräumen anfängt.

Was ist mit Daten, die wir gesetzlich aufbewahren müssen?

Die gehören ins Migrationskonzept, mit Angabe der Frist und des Fristbeginns je Unterlagenart. Die Fristen setzen Handels- und Steuerrecht (§ 257 HGB, § 147 AO), und die GoBD verlangen, dass steuerlich relevante Daten während der Frist maschinell auswertbar bleiben. Die Fristen wurden zuletzt geändert. Welcher Stand für Ihre Unterlagen gilt und ob Vollmigration, Lesearchiv oder Archivexport ihn erfüllt, stimmen Sie vor dem Umsetzungsstart mit Steuerberater oder Wirtschaftsprüfer ab.

Wir haben keine Dokumentation des Altsystems. Geht das trotzdem?

Fast jedes Ablöseprojekt startet ohne brauchbare Dokumentation. Rekonstruiert wird aus drei Quellen: der Datenbank selbst, den vorhandenen Auswertungen und Reports, und den Anwendern. Am ergiebigsten sind die Anwender. Wer seit Jahren mit dem System arbeitet, kennt jede Sonderregel, auch wenn er sie nie aufgeschrieben hat. Diese Gespräche werden mitprotokolliert und ergeben nebenbei die Dokumentation, die vorher gefehlt hat.

Kommen wir an unsere Daten heran, wenn der Hersteller nicht mitspielt?

Meistens ja. Der übliche Weg ist ein Lesezugriff auf die Datenbank, oft ergänzt um vorhandene Exportfunktionen oder Reports. Wenn beides verschlossen ist, bleibt der Weg über die dokumentierten Ausgaben des Systems, der aufwendiger und lückenhafter ist. Prüfen Sie früh Ihren Vertrag und die Frage, wo die Daten physisch liegen. In der Woche vor dem Umstieg ist es für diese Klärung zu spät.

Was kostet es, das Altsystem als Archiv weiterzubetreiben?

Mehr, als in der Planung steht. Zu den Lizenz- und Serverkosten kommen Sicherheitsupdates, ein Betriebssystem, das irgendwann selbst aus dem Support fällt, und Personen, die im Ernstfall noch wissen, wie das System hochfährt. Ein Lesearchiv ist eine gute Zwischenlösung mit klarem Enddatum. Als Dauerlösung ist es meist teurer als ein sauberer Archivexport.

Am Anfang steht ein Gespräch über das, was heute läuft, und ein Blick in den echten Datenbestand. Daraus entsteht ein Migrationskonzept mit Objektliste, Abbildungsregeln, Abgleichszahlen, Reihenfolge der Module und einer Aussage zur Historie. Erst dann wird über Umsetzungsbudgets gesprochen.

Entwickelt wird von festangestellten Entwicklern in Deutschland, mit einem benannten Ansprechpartner, der das Projekt vom ersten Datenprofiling bis nach dem Go-live begleitet. Der Code der neuen Anwendung gehört Ihnen ab Tag eins, betrieben wird in Deutschland oder der EU. Damit endet die Abhängigkeit, die Sie gerade ablösen, und sie wiederholt sich nicht unter einem anderen Namen.

• Individualsoftware im Überblick
• Prozesse digitalisieren
• Schnittstellen und Integrationen
• Vertrauen und Sicherheit