Migration von einem ERP-System zu einem anderen

Sehr oft stoppt der Übergang des Unternehmens zu einem neuen ERP-System nicht die finanziellen Kosten für den Kauf und die Fertigstellung, sondern die Notwendigkeit, vom alten System zu migrieren. Sie haben Hunderte oder sogar Tausende von Benutzern, die ihre Geschäftsprozesse in einem Programm ausführen, und irgendwie müssen sie alle ohne Unterbrechung für das Geschäft auf ein anderes übertragen werden.

In den letzten Jahren sind wir mehrere Dutzend Mal diesen Weg gegangen, und wir haben bereits den am wenigsten schmerzhaften Weg entwickelt, dies zu tun.

Schwierigkeiten

Der Tag, an dem Bison Ihr Dorf mit seiner Anwesenheit ehrte, wurde für Sie das Wichtigste im Leben. Aber für mich war es Dienstag.
- Bayson, Straßenkämpfer

Der Übergangsprozess wird oft dadurch erschwert, dass viele besonders eindrucksvolle Mitarbeiter des Kunden zum ersten Mal in Panik geraten, da dies für sie höchstwahrscheinlich die erste Migration in ihrer Karriere ist. Für uns ist dies ein gewöhnliches Ereignis, das in der Regel nach demselben Szenario stattfindet.

Wenn jemand ein Produkt gegen ein anderes austauscht, bemerkt er als erstes, dass er von ihm genommen wurde und noch nicht weiß, was er erhalten hat . Daher lautet die erste Reaktion oft: "Was für ein Unsinn, den Sie mir hierher gebracht haben - tun Sie, was es war." In der Praxis hatten wir eine Situation, in der sich ein Benutzer beschwerte, dass er mit der neuen Aktion, die im alten System in fünf Übergängen zwischen Formularen ausgeführt wurde, nicht zufrieden war. Aber er ließ es zu einem solchen Automatismus perfektionieren, dass es für einen Menschen zunächst wirklich schneller war, es zu tun, als zwei neue, aber viel einfachere Aktionen auszuführen.

Eine weitere Schwierigkeit besteht darin, dass Kunden während des Übergangs gerne Geschäftsprozesse auf ihre Vision umstellen. Dies sollte mit großer Sorgfalt behandelt werden, da die aktuellen Ist-Prozesse garantiert funktionieren. Die im Produkt eingebetteten Prozesse funktionieren in der Regel auch so, wie sie von anderen Kunden genutzt werden. Aber neue Erfindungen mögen theoretisch schön aussehen, aber in der Praxis werden sie auf eine Kleinigkeit stoßen, wodurch der gesamte Prozess ins Stocken geraten kann.

Szenarien

In der Praxis gibt es zwei Hauptszenarien für den Wechsel von einem System zu einem anderen:

Momentan

Das Datum des Übergangs zum neuen System wird festgelegt. Alle Funktionen wurden entwickelt, um Daten aus dem alten System zu entladen und in ein neues zu laden. Am Tag X beginnt die Migration nachts, und am Morgen beginnen alle Benutzer mit allen Geschäftsprozessen, auf neue Weise im neuen System zu arbeiten.

Auf dem Papier ist alles schön. In der Praxis gibt es jedoch mindestens vier Kategorien von Problemen:

1. Schulung . Zum Zeitpunkt des Übergangs vergessen viele geschulte Benutzer in der Regel völlig, was ihnen beigebracht wurde. Sie fangen an, alles zu stupsen, und als Ergebnis beenden sie ihre Arbeit mit den Worten „nichts funktioniert“. Dieses Problem kann mit Hilfe von First-Line-Support-Mitarbeitern gelöst werden, die in diesem Moment helfen können. Am ersten Tag der Versetzung wird es jedoch so viele solcher Anfragen geben, dass es unmöglich sein wird, diese mit der verfügbaren Anzahl von Mitarbeitern zu erfüllen. Oder Sie müssen eine Möglichkeit haben, ihre Anzahl während der Übertragung irgendwie schnell zu erhöhen, was auch ziemlich schwierig ist.
2. Verbesserungen und Fehler . Ein neues ERP-System bringt in der Regel neue Geschäftsprozesse mit sich (andernfalls warum ändern). Es ist klar, dass sie kurz vor der Implementierung irgendwie vertrieben wurden, aber im Moment eines echten „Battle Checks“ kommt normalerweise eine große Menge von Nuancen heraus, aufgrund derer die Prozesse oft nicht ausgeführt werden können. Dementsprechend wächst die Anzahl solcher Verbesserungen mit unmittelbarer Priorität wie bei einem Schneeball, und es besteht ein starker Bedarf an Programmiererressourcen, die eine solche Anzahl von Anforderungen physisch nicht schließen können.
3. Daten . Normalerweise sind die Entwickler des alten Systems nicht sehr daran interessiert, beim Hochladen von Daten zu helfen (für sie ist dies im Allgemeinen ein trauriges Ereignis, wenn ein Client verloren geht), und wenn sie helfen, lässt die Qualität des Uploads zu wünschen übrig. Und Inkonsistenzen treten in der Regel in den ersten Betriebstagen eines neuen Systems auf. Infolgedessen ist es erforderlich, das Entladen zu korrigieren und die Daten irgendwie neu zu laden, wobei zu berücksichtigen ist, dass sie sich bereits während des Betriebs geändert haben.
4. Leistung . Während des Testprozesses ist es nicht so einfach, die vollständig „echte“ Belastung des Systems zu reproduzieren. Wenn die Grundfunktionalität des Produkts normalerweise bereits getestet wurde und normale Leistungsparameter anzeigt, können „persönliche“ Verbesserungen des Clients unter bestimmten Umständen den Server „hinsetzen“. Dies erfordert wiederum Programmiererressourcen zur Optimierung.

Wenn alle vier Probleme gleichzeitig am ersten Tag oder in der ersten Übergangswoche auftreten, können Geschäftsverluste nicht vermieden werden. Daher funktioniert ein solches System nur bei kleinen Projekten effektiv. Zum Beispiel, wenn die Anzahl der Benutzer weniger als hundert beträgt und die Prozesse nicht kritisch sind.

Es ist klar, dass Sie unmittelbar vor dem Übergang mehr Ressourcen für das Training und Testen des Systems aufwenden können, und dann treten weniger Probleme auf. Im Leben beziehen sich die Mitarbeiter des Kunden normalerweise auf diese Prozesse „ärmellos“ und verlassen sich auf „vielleicht“. Oder sie irren sich einfach und erwarten, dass ein bestimmter Prozess in einem bestimmten Umfeld Geld verdienen kann, aber tatsächlich scheinen kleinere Nuancen alles zu reduzieren.

Allmählich

Bei diesem Ansatz wird das System horizontal (nach Prozessen) oder vertikal (nach Benutzern) in Teile unterteilt, die nacheinander eingeführt werden. Auf diese Weise können Sie alle oben genannten Probleme rechtzeitig verteilen und lösen, da sie weniger Strom erhalten.

Weiter werde ich den Migrationsprozess eines ERP-Systems beschreiben, das auf der offenen und kostenlosen lsFusion- Plattform für eine Einzelhandelskette von Geschäften basiert, da wir auf diese Branche spezialisiert sind. Wir haben das gleiche Prinzip jedoch auch auf Kunden aus anderen Bereichen angewendet.

Daten lesen

Für Unternehmen, die das alte System unterstützen, ist die Nachricht, dass sie ihr Programm ersetzen und einen Kunden verlieren, in der Regel ein schwerer Schlag. Einige geraten in einen unzureichenden Zustand und drohen dem Kunden mit einem sofortigen Stopp der Unterstützung. Dies funktioniert natürlich nie und kann die Entscheidung niemals rückgängig machen. Es ist jedoch selten möglich, mit denjenigen, die das alte System unterstützen, übereinzustimmen, dass sie Tabellen bereitstellen, in denen alle für den Übergang erforderlichen Daten gespeichert sind.

Zunächst müssen Sie festlegen, in welchem ​​DBMS die erforderlichen Informationen gespeichert sind und wie Sie darauf zugreifen können. In den letzten Jahren mussten wir uns mit folgenden DBMS befassen, mit denen alte Systeme funktionierten:

• Zugang Da die Plattform in Java geschrieben ist, war es möglich, eine alte Bibliothek auszugraben, die wusste, wie man sich mit mdb verbindet (allerdings nur zum Lesen). Es funktionierte sehr eigenartig, denn trotz der Filter las es die ganze Tabelle, aber es war trotzdem genug. Wir hatten Glück, dass der IT-Service des Kunden die Datenbankstruktur recht gut kannte und uns mitteilte, was und wo gespeichert ist.
• MS SQL Das alte System war der Axapta 2000er. Wir haben den Zugriff auf das Testsystem eingerichtet, wo wir die GUI und den SQL Profiler gestartet haben. Dann wechselten wir uns in Verzeichnissen ab und schauten uns an, welche Anforderungen Axapta generiert. Von ihnen war leicht zu verstehen, wo genau diese oder jene Informationen gespeichert sind.
• Visual Foxpro Es war alles einfach, da es einen Übergang von unseren Legacy-Systemen gab und es nicht schwierig war, Informationen zu erhalten. Die einzige Schwierigkeit bestand darin, eine Java-Bibliothek zu finden, die nicht mit DBASE-Tabellen, sondern mit dem Visual Foxpro-Format funktioniert.
• Oracle Übergang vom Supermag-Boxprogramm. Wir haben nach einem Schema gearbeitet, das dem Axapta-Schema ähnelt: GUI und Abfragen in SQL Developer für die neuesten Abfragen. Die Grundstruktur und die Schnittstellen dort waren sicherlich viel einfacher als in Axapta, so dass es keine großen Probleme gab.
• Fortschritt / OpenEdge . Übergang vom Boxed Gestori-Programm. Da das DBMS, gelinde gesagt, überhaupt nicht beliebt ist, haben wir keine Profiler gefunden. Es gab jedoch einen Speicherauszug in den Textdateien. Dies ermöglichte es, einfach in die GUI des Testservers zu gehen und Textdateien zu durchsuchen, um nach Daten zu suchen, die auf dem Bildschirm sichtbar sind. Glücklicherweise besteht auf der offiziellen Website dieses DBMS die Möglichkeit, den JDBC-Treiber herunterzuladen und Abfragen an die SQL-Datenbank zu stellen. Dann war es eine Frage der Technologie.

Dank solcher Ansätze musste ich mich nie an die Entwickler des alten Systems wenden, was die Kundenkosten erheblich sparte, da sie normalerweise einfach riesige Geldbeträge für die Zusammenarbeit bereitstellten.

Stammdaten

Alles beginnt mit dem Import von Stammdaten. Insbesondere für den Einzelhandel werden als erste Importe von Verzeichnissen von Warengruppen, Waren, Auftragnehmern und Geschäften realisiert. Bei einem schrittweisen Übergang gibt es zwei Ansätze zum Importieren von Stammdaten:

• Einmaliger Datenimport und anschließende doppelte Eingabe in das alte und neue System.
• Kontinuierliche inkrementelle Aktualisierung der Daten vom alten zum neuen System.

Es gibt Fälle, in denen der erste Ansatz verwendet wird, aber er ist zu zeitaufwändig und mit der Wahrscheinlichkeit von Fehlern sehr anfällig für den menschlichen Faktor. Daher verwenden wir immer nur die zweite Option.

Im Idealfall könnte das alte System Änderungen akkumulieren und irgendwie mitteilen, dass es erneut importiert werden muss. Aber normalerweise wird niemand etwas im alten System ändern oder modifizieren. Daher verwenden wir nur das folgende Arbeitsschema:

1. Es gibt eine Anfrage an das Verzeichnis des alten Systems, das alle Daten daraus liest.
2. Die gelesenen Daten werden mit dem aktuellen im neuen System verglichen und Änderungen werden erkannt.
3. Änderungen werden in einer einzigen Transaktion in das neue System geschrieben.

Der Code auf der Plattform zum Importieren des Produktverzeichnisses sieht folgendermaßen aus:

Dies funktioniert wie folgt:

• READ berücksichtigt das gesamte Verzeichnis mit dem Code und dem Namen im Speicher
• IMPORT schreibt alle Daten in lokale Eigenschaften (nämlich temporäre Tabellen in der Datenbank).
• Im ersten Zyklus werden alle Waren erstellt, die sich noch nicht in der neuen Datenbank befinden (Suche nach Produktcode). Trotz der Tatsache, dass FOR dort geschrieben ist, wird es in eine einzelne Datenbankabfrage kompiliert, die nur mit temporären Tabellen funktioniert.
• Im zweiten Zyklus werden die Felder für alle Produkte (einschließlich neu erstellter Produkte) aktualisiert. In diesem Fall werden nur die geänderten Werte in temporäre Tabellen geschrieben.
• Die dritte Aktion LÖSCHEN erkennt alle Waren, die sich in der neuen Datenbank befinden, jedoch nicht in den gelesenen Daten, und löscht sie.
• APPLY startet die Transaktion und schreibt alle Änderungen basierend auf temporären Tabellen, die durch vorherige Befehle generiert wurden, in die Datenbank.

Tatsächlich synchronisiert diese Aktion zum Zeitpunkt des Starts das alte und das neue Verzeichnis vollständig. Es werden keine inkrementellen Informationen gespeichert, sodass es jederzeit neu gestartet werden kann, selbst wenn der vorherige Austausch mit Fehlern abgeschlossen wurde.

Da alle Aktionen ohne Iteration in SQL-Abfragen kompiliert werden, ist dies alles ziemlich schnell und sicher. Normalerweise dauerte der Austausch eines Warenverzeichnisses mit 100 bis 200.000 Datensätzen einige Minuten. Da PostgreSQL versioniert ist, erfolgt derzeit keine Blockierung der Benutzerarbeit.
Ebenso werden Lieferantenpreise, Sortimentsmatrizen, Bestellpläne und andere für die Arbeit notwendige Informationen ständig synchronisiert. Hier kann jedoch ein Problem auftreten, dass die Domänenlogik im alten System nicht mit der neuen Domänenlogik übereinstimmt. In unserem System haben wir beispielsweise eine Historie von Matrixversionen und das Konzept der Produktebenen innerhalb einer Matrix. Wenn im alten System das aktuelle Sortiment von Filialen flach als Boolescher Wert für das Geschäft und die Waren gespeichert wird, wird für jedes Geschäft eine Matrix mit genau einer Ebene erstellt.

In den meisten Fällen aktivieren wir die Aktion, um alle Verzeichnisse einmal pro Stunde mit dem alten System zu synchronisieren, und bieten dem Benutzer die Möglichkeit, den Austausch manuell zu starten.

Der Prozess

Im Einzelhandel teilen wir den Übersetzungsprozess normalerweise vertikal zwischen Filialen und gleichzeitig horizontal von Filialprozessen zu Büroprozessen auf.

Der erste Schritt besteht darin, ein Geschäft auszuwählen, in dem die Übertragung auf das neue System beginnt. Importiert aktuelle Salden und Speicherpreise aus dem alten System in Form von eingehenden Dokumenten mit den entsprechenden Mengen und Preisen:


Einige Wochen vor dem Start des Geschäfts ist der Import der Implementierung von POS-Systemen verbunden. Dies ist notwendig, damit historische Daten für die Auftragsbildung in den ersten Arbeitstagen vorliegen.

Sehr oft wird der Prozess der Eigenproduktion etwas später als die Hauptprozesse übertragen. In diesem Fall wird das Entladen von Dokumenten über den Transport von Rohstoffen und den Import von Fertigprodukten von dort in das alte System implementiert.

Am Tag der Übertragung beginnt der Import nachts, und dann werden sowohl das Kundendienstpersonal als auch unsere erste Supportlinie an das Geschäft gesendet. Sie helfen Benutzern beim Einstieg in das neue System, ohne dass sie eine Vorschulung absolvieren müssen. In diesem Fall wird das Ändern von Dokumenten im alten System normalerweise für einige Zeit nicht geschlossen, da sich Benutzer irren und Fehler korrigieren müssen. Nach ein paar Wochen werden die Überreste wieder importiert, und dann besteht bereits ein Verbot von Änderungen im alten System.

Nachdem alle oben beschriebenen Probleme im ersten Geschäft identifiziert und behoben wurden, werden nach etwa ein paar Wochen weitere 2-3 Geschäfte übertragen. Wieder eine Iteration des Identifizierens und Behebens von Problemen. Und dann werden alle anderen sehr schnell übersetzt, abhängig von den Ressourcen des Kundendienstes des Kunden. Während dieser ganzen Zeit werden weiterhin Stammdaten in das alte System eingegeben, damit die Speicher auf dem alten System funktionieren können.

Wenn dann alle Filialen übertragen werden, werden entweder schrittweise oder alle Importe aus dem alten System sofort deaktiviert, und Benutzer beginnen, Stammdaten in das neue System einzugeben.

Zusammenfassende Informationen aus dem alten und dem neuen System werden entweder in der Buchhaltungsabteilung oder im BI-System abgerufen, wo beide Systeme gleichzeitig hochgeladen werden. Dort können Sie zusammenfassende Berichte für das Intervall erhalten, das die Zeit in den alten und neuen Systemen enthält.

Fazit

Trotz der offensichtlichen Komplexität des Übergangs von einem System zu einem anderen, nachdem Sie diesen Weg mehrere Dutzend Mal gegangen sind, verstehen Sie, dass mit einem debuggten Schema eigentlich nicht alles so beängstigend ist. Weitere Probleme ergeben sich aus der Tatsache, dass die meisten Mitarbeiter des Kunden recht konservativ sind und bei der geringsten Gelegenheit verlangen, „so zu sein, wie es war“. Und hier ist es sehr wichtig, dass der Kunde über eine Person mit ausreichender Autorität verfügt, die alte und neue Prozesse vergleichen, feststellen kann, welche optimaler sind, und in der Lage ist, Mitarbeiter zu „brechen“. Oder ändern Sie den Prozess gemäß dem Schema "wie es war", wenn es umgekehrt ausfällt.