Parallele Annahme - Parallel adoption
Die parallele Übernahme ist eine Methode zum Übertragen zwischen einem früheren ( IT- ) System und einem Zielsystem (IT) in einer Organisation. Um das Risiko zu verringern, werden das alte und das neue System einige Zeit gleichzeitig ausgeführt. Wenn die Kriterien für das neue System erfüllt sind, wird das alte System deaktiviert. Der Prozess erfordert eine sorgfältige Planung und Kontrolle sowie eine erhebliche Investition in Arbeitsstunden.
Überblick
Dieser Eintrag konzentriert sich auf den allgemeinen Prozess der parallelen Übernahme. (reale) Beispiele werden verwendet, um den Prozess bei Bedarf aussagekräftiger zu interpretieren. Darüber hinaus wird ein Prozessdatenmodell zur Visualisierung des Prozesses verwendet, das einen vollständigen Überblick über alle Schritte der parallelen Übernahme bieten soll. Der Schwerpunkt wird jedoch auf den einzigartigen Merkmalen der parallelen Übernahme liegen. Einige gemeinsame Merkmale, insbesondere die Definition einer Implementierungsstrategie, die für alle vier allgemeinen Arten der Übernahme gelten, sind in Annahme (Software-Implementierung) beschrieben .
Andere Arten der Adoption
Neben der parallelen Adoption können drei weitere generische Adoptionsarten identifiziert werden. Die Wahl einer bestimmten Adoptionsmethode hängt von den organisatorischen Merkmalen ab. Weitere Informationen zu diesem Thema erhalten Sie weiter unten. Die drei anderen Adoptionsmethoden sind: Produkt-Software-Adoption: Urknall-Adoption (auch als direkte Konvertierung, Slam Dunk- oder Cold-Turkey-Strategie bekannt) , schrittweise Adoption und Pilot-Adoption.
- Einführung von Produktsoftware: Einführung in Urknall / Einführung in Tauchgang : Bei einer Einführung in Urknall wird die gesamte Organisation in einem sofortigen Wechsel vom alten auf das neue System übertragen. Dies ist die billigste Option, aber wenn das neue System ausfällt, steckt die Organisation in großen Schwierigkeiten. Es birgt auch Risiken für das System, von seinen Benutzern nicht akzeptiert zu werden. Dies ist jedoch möglicherweise der einzige Ansatz, der gewählt werden kann, wenn die beiden Systeme nicht gleichzeitig existieren können oder die Aktivierung des neuen Systems ein Notfall ist.
- Phased Adoption (auch als schrittweise Konvertierung bezeichnet) : Bei der Implementierung der Phased Adoption wird die Organisation schrittweise in verschiedenen Phasen pro Modul oder Subsystem auf ein neues System umgestellt. Einige Systeme können nicht in Teilen eingeführt werden, da sie zu stark vom gesamten System abhängen. Die Verwendung der schrittweisen Einführung birgt weniger Risiken, verursacht jedoch die meisten Störungen, da die Übertragung vom alten auf das neue System die meiste Zeit in Anspruch nimmt.
- Pilotadoption: Die Pilotadoptionsmethode wird für große Organisationen mit mehreren Standorten oder weitgehend unabhängigen Abteilungen verwendet. Das neue System wird an einem der Standorte oder Abteilungen eingeführt und im Laufe der Zeit auf andere Standorte oder Abteilungen ausgeweitet. (begrenzte Grenze, wenn ein neues System ausfällt) (Turban, 2002)
Es gibt mehrere Fälle, in denen die parallele Konvertierung nicht als praktikable Konvertierungsstrategie angesehen werden kann. Überlegen Sie zunächst, ob das neue System wesentliche Schemaänderungen enthält. Datenelemente, die von einem System benötigt werden und nicht von dem anderen ausgefüllt werden, können bestenfalls zu Datenungenauigkeiten und im schlimmsten Fall zu Datenkorruption führen. Ein weiteres Problem besteht darin, dass das System auf die Standardtechnologie (COTS) des Verbrauchers angewiesen ist. Wenn in der Dokumentation eines COTS-Anbieters angegeben ist, dass mehr als eine Anwendung nicht dieselbe Datenbank gemeinsam nutzen kann, ist eine parallele Konvertierung keine Option. Ein Beispiel wären die Siebel-Produkte von Oracle. Andere COTS-Produkte können ebenfalls Einschränkungen unterliegen, wenn für Patches oder größere Upgrades eindeutige Lizenzschlüssel erforderlich sind. Einmal angewendet, können sie Datenbankänderungen vornehmen, die dazu führen können, dass die Anwendung fälschlicherweise ein paralleles System erkennt, das mit derselben Datenbank ausgeführt wird, um Lizenzkontrollen zu umgehen und dadurch das System zu deaktivieren.
Platz im Implementierungsprozess
Es scheint wenig Konventionen bezüglich des Prozesses der parallelen Annahme zu geben. Einige Quellen (z. B. Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999) verwenden keinen einzigen Prozessbeschreibungsnamen. Der Begriff parallele Übernahme wird in diesen Quellen bezeichnet, obwohl er pro Quelle konsistent ist als: parallele Konvertierung, paralleler Lauf, Schattenlauf, paralleler Schnitt und parallele Implementierung. Dies scheint der Fall zu sein, da für eine allgemeine Beschreibung des Prozesses keine eindeutige Klassifizierung erforderlich ist. Es gibt einige Standardimplementierungsmethoden, bei denen verschiedene Adoptionstechniken beschrieben werden, jedoch häufig in einem praktischen Kontext. reales Fallszenario oder ein umfassenderes Set von Implementierungstechniken wie Regatta: Adoptionsmethode , SIM und PRINCE2 . Im Allgemeinen kann die parallele Übernahme am besten als systemtechnische Methode zur Implementierung eines neuen Systems angesehen werden.
Grundsätzlich unterscheidet sich die Methode der parallelen Übernahme von der Entscheidung, ein System in einer Organisation zu ändern, und kann als ein mögliches Mittel zur Erreichung dieses Ziels angesehen werden. Es gibt jedoch einige Faktoren, die bei der Festlegung der besten Implementierungsstrategie berücksichtigt werden . Darüber hinaus kann eine erfolgreiche Implementierung in hohem Maße von der Adoptionsmethode abhängen. (Lee, 2004)
Der Prozess
Der parallele Übernahmevorgang kann nicht dargestellt werden, ohne die Schritte vor der eigentlichen Konvertierung zu beachten, nämlich die Erstellung eines Konvertierungsszenarios und die Identifizierung und Prüfung aller Anforderungen . Daher wird der Prozess erklärt, indem alle in Abbildung 1 identifizierten Prozesse durchlaufen werden, während kurz auf die allgemeinen Aktivitäten eingegangen wird, die für eine der identifizierten Konvertierungsstrategien erforderlich sind.
Abbildung 1 gibt einen Überblick über den parallelen Adoptionsprozess. Die linke Seite zeigt den Ablauf der Aktivitäten, die zum Prozess beitragen. Aktivitäten, die gleichzeitig ausgeführt werden, geht eine dicke schwarze Linie voraus. Wenn das parallele Ausführen von Aktivitäten beendet ist, werden die Aktivitäten erneut in einer ähnlichen schwarzen Linie verbunden. Wenn kein Pfeil von einer Aktivität zu einer anderen vorhanden ist, bedeutet dies, dass es sich um Aggregate einer größeren Aktivität oben handelt. Die Aktivitäten sind in vier Hauptphasen unterteilt:
- Definieren Sie eine Implementierungsstrategie , die sich mit der Art der Implementierungsstrategie befasst, die ausgeführt werden soll.
- Vorimplementierung , die mit der Erstellung einer Planung aller Aspekte und Anforderungen der Implementierung zu tun hat.
- Organisation vorbereiten Die Organisation sollte gemäß der vorherigen Phase ordnungsgemäß vorbereitet sein.
- Die Konvertierung befasst sich mit dem eigentlichen Konvertierungsprozess und dem Abschluss des Konvertierungsprozesses. Fahren Sie mit dem neuen System fort.
Die Hauptphasen sind in andere Aktivitäten unterteilt, die in den Tabellen 1-1 bis 1-4 kurz beschrieben werden.
Die rechte Seite des Modells beschreibt die an den Prozessen beteiligten Daten. Einige dieser Konzepte, die als Paar überlappender offener Rechtecke dargestellt werden, können in mehr als ein Konzept unterteilt werden. Ein Paar überlappender geschlossener Rechtecke zeigt ein geschlossenes Konzept an, was bedeutet, dass es in mehrere Konzepte unterteilt werden kann, aber für den parallelen Übernahmevorgang nicht von weiterem Interesse ist. Die Abbildung mit den Diamantformen zeigt an, dass das damit verknüpfte Konzept als Gesamtkonzept dient und dass dieses Konzept aus den anderen Konzepten besteht. Schließlich repräsentiert der offene Pfeil eine Beziehung zwischen Superklasse und Unterklasse. Das mit dem Pfeil verknüpfte Konzept ist die Superklasse der damit verknüpften Konzepte. Diese Syntax in Abbildung 1 entspricht den UML- Standards (Unified Modeling Language ). Die Konzepte in Abbildung 1 sind in Tabelle 2 definiert. Weitere Informationen zu diesen Unteraktivitäten im Prozess finden Sie unter den Tabellen.
| Aktivität | Beschreibung |
|---|---|
| Implementierungsstrategie definieren | Die Umsetzungsstrategie wird in diesem frühen Stadium festgelegt. (Brown, Vessey, 1999) |
| Erstellen Sie ein Master-Implementierungsskript | Die erste anfängliche Anforderungsanalyse wird durchgeführt, die aus den folgenden Anforderungen besteht. (Venture, 2004) |
| Zeitplanung erstellen | Eine erste Zeitplanung des Implementierungsprozesses wird erstellt. (Rooijmans, 2003) |
| Organisatorische Anforderungen definieren | Hier werden die organisatorischen Anforderungen definiert (Rooijmans, 2003). |
| IT-Anforderungen definieren | Die IT-Anforderungen werden festgelegt (Rooijmans, 2003). |
| Aktivität | Beschreibung |
|---|---|
| Installieren Sie die Anforderungen | Zur Vorbereitung der Organisation werden die definierten Anforderungen installiert. Die Organisation wird vorbereitet und die IT auf Testmaschinen installiert. (Rooijmans, 2003, Eason, 1988, Microsoft, 2004) |
| Testanforderungen | Die Anforderungen werden getestet, um festzustellen, ob die Organisation für die Implementierung bereit ist (Rooijmans, 2003). |
| Definieren Sie das Master-Implementierungsskript neu | Das Master-Implementierungsskript wird mit den neuen Informationen verfeinert, die im Prozess mit den folgenden Aktivitäten gesammelt wurden. (Rooijmans, 2003) |
| Kriterienindikatoren definieren | Um das neue System zu testen, werden Kriterienindikatoren erstellt. (Rooijmans, 2003, Microsoft, 2004) |
| Formulieren Sie einen Workaround- / Rollback-Plan | Außerdem wird ein Problemumgehungsplan mit einem Rollback-Szenario erstellt. Mit diesen Plänen kann die Organisation jeweils versuchen, die gemachten Fehler zu korrigieren und zurückzugreifen, wenn die Implementierung in einer bestimmten Phase des Prozesses fehlschlägt. (Microsoft, 2004, Rooijmans, 2003) |
| Führen Sie eine (segmentale) Testkonvertierung durch | In sehr komplexen Organisationen kann es vorteilhaft sein, eine Testkonvertierung durchzuführen, bevor Sie "live" gehen. (Microsoft, 2004, Rooijmans, 2003) |
| Aktivität | Beschreibung |
|---|---|
| Machen Sie Aufholjagden | Der Konvertierungsprozess wird gestartet, eine Reihe von Aktivitäten werden parallel ausgeführt. In dieser Phase werden mit dem alten System Aufholjagden durchgeführt. Das alte System ist führend, aber das neue läuft parallel. Alle Änderungen im System müssen in das neue System übernommen werden. (Microsoft, 2004, Rooijmans, 2003) |
| Kontrollsystem | Das System wird jederzeit vom Steuerungssystem gesteuert. Mit den definierten Indikatoren und Systemlaufmerkmalen werden Fehler und Irrtümer aufgespürt. (Microsoft, 2004, Rooijmans, 2003) |
| Führen Sie das führende alte System aus | Das alte System ist führend; Verarbeitung der eigentlichen Daten. |
| Führen Sie ein neues System aus | Das neue System läuft parallel zum alten System und wird genau überwacht. (Microsoft, 2004, Rooijmans, 2003) |
| Überholen Sie Aufholjagden in ein neues System | Wenn die Kriterien erfüllt sind, werden die Aufholjagden übersetzt und in das neue System übertragen, und der Konvertierungsprozess beginnt in der nächsten Phase. (Microsoft, 2004, Rooijmans, 2003) |
| Führen Sie eine Problemumgehungs- / Rollback-Strategie aus | Wenn die Kriterien nicht erfüllt sind, wird je nach Art der Fehler die Problemumgehungs- oder Rollback-Strategie ausgeführt. (Microsoft, 2004, Rooijmans, 2003) |
| Machen Sie Aufholjagden | Aufholjagden werden aus Sicherheitsgründen durchgeführt, auch wenn das neue System führend ist. (Microsoft, 2004, Rooijmans, 2003) |
| Führen Sie das alte System aus | Das alte System wird aus Sicherheitsgründen als Backup ausgeführt |
| Führen Sie ein führendes neues System aus (1) | Das neue System ist führend und voll in Betrieb. Alle Transaktionen und Änderungen im System werden hier behandelt. (Microsoft, 2004, Rooijmans, 2003) |
| Aktivität | Beschreibung |
|---|---|
| Führen Sie das führende neue System aus (2) | Alle Aufholjagden und Kontrollen sind geschlossen. Das neue System ist das einzige in Betrieb befindliche System. (Microsoft, 2004, Rooijmans, 2003) |
| Altes System deaktivieren | Das alte System wird nicht mehr benötigt und ist deaktiviert. (Microsoft, 2004, Rooijmans, 2003) |
Die Konzepte aus Abbildung 1 sind in der folgenden Tabelle 2-1 definiert.
| Konzept | Definition |
|---|---|
| Umsetzungsstrategie | Die Strategie, die zur Implementierung des neuen Systems gewählt wird. Die Optionen sind Urknall, schrittweise, parallele Übernahme, Pilotkonvertierung oder eine Kombination dieser vier. (Turban, 2002, Rooijmans, 2003) |
| Implementierungsskript | Rohversion des eigentlichen Konvertierungsszenarios, bestehend aus organisatorischen Anforderungen, IT-Anforderungen und einer anfänglichen Zeitplanung. (Venture, 2004, Eason, 1988) |
| Organisatorische Anforderungen | Anforderungen innerhalb der Organisation, die für eine erfolgreiche Implementierung vorhanden sein sollten. Sie befassen sich mit der Optimierung (Änderung) der Organisation für das neue System. Folgende Themen können behandelt werden: Personalmanagement, Änderung von Organogrammen und neue Geschäftsstrukturen. (Rooijmans, 2003) |
| IT-Anforderungen | Die Anforderungen an die Informationstechnologie sind die Software- und Hardwareanforderungen, die Plattformauswahl unter Berücksichtigung des Budgets und der vorhandenen Systeme. (Rooijmans, 2003) |
| Zeitplanung | Eine Planung, in der den Aktivitäten ein Zeitraum zugewiesen wird, in dem sie abgeschlossen werden sollen, und ein Gesamtbild des Implementierungsprojekts in Bezug auf die verfügbare Zeit liefert. (Eason, 1988) |
| Bedarf | |
| Konformität | Bei Konformität geht es darum, die Anforderungen zu erfüllen. (ISO 9000) |
| Konvertierungsszenario | Das neu definierte Implementierungsskript unter Berücksichtigung der Konformität mit den Anforderungen. Darüber hinaus besteht das Konvertierungsszenario aus einem Workaround- und Rollback-Plan. Das Konvertierungsszenario ist die Blaupause des Implementierungsprojekts. (Rooijmans, 2003) |
| Problemumgehungsstrategie | Ein Backup-Plan; Strategie im Konvertierungsszenario übernommen, um Fehler im Konvertierungsprozess zu vermeiden und zu versuchen, diese zu umgehen, damit die Implementierung weiterhin erfolgreich sein kann. (Rooijmans, 2003) |
| Kriterienindikatoren | Quantifizierbare und messbare Kriterien in Bezug auf die Anforderungen, um festzustellen, ob der Implementierungsprozess erfolgreich war. (Rooijmans, 2003) |
| Rollback-Plan | Planen Sie das Umkehren der Replikationsrichtung, um ohne Daten- oder Informationsverlust zum alten System zurückzukehren. (Microsoft, 2004) |
| Testkonvertierung | Segmentale Testkonvertierung vor der eigentlichen Konvertierung mit dem Ziel, besser auf Unsicherheiten oder Probleme im eigentlichen Konvertierungsprozess vorbereitet zu sein. (Microsoft, 2004) |
| Altes System | Das alte System: wenn führend = wahr; Das alte System verarbeitet die Systemtransaktionen live:
Die wichtigsten funktionierenden Einheiten, aus denen das Produkt besteht, z. B. Hardware, Software. Auch ein organisierter und disziplinierter Ansatz zur Erfüllung einer Aufgabe, z. B. ein Fehlermeldesystem (ISO 9000) |
| Neues System | Das neue System (Ziel): Das neue System, wenn führend = wahr; Das neue System verarbeitet die Systemtransaktionen live. Die wichtigsten funktionierenden Einheiten, aus denen das Produkt besteht, z. B. Hardware, Software. Auch ein organisierter und disziplinierter Ansatz zur Erfüllung einer Aufgabe, z. B. ein Fehlermeldesystem (ISO 9000) |
| Steuerung | Das Gesamtkontrollsystem umfasst Leistungsindikatoren sowie eine Zuverlässigkeitsbewertung und Aufholjagden. Das Steuerungssystem ist sehr breit und das zentrale Befehlssystem zum Konvertieren des alten Systems und Verwalten des neuen Systems während des parallelen Adoptionsprozesses. (Rooijmans, 2003, Microsoft, 2004) |
| Performance | Die quantifizierbare Bewertung der Leistung des alten und des neuen Systems dient als Eingabe für das Steuerungssystem. (Rooijmans, 2003) |
| Zuverlässigkeitsbewertung | Eine quantitative Bewertung der Zuverlässigkeit eines Produkts, Systems oder eines Teils davon. Bei solchen Bewertungen werden normalerweise mathematische Modelle, direkt anwendbare Ergebnisse von Produkttests, Fehlerdaten, geschätzte Zuverlässigkeitszahlen und nicht statistische technische Schätzungen verwendet. (ISO 9000) |
| Aufholjagden | Aufholjagden bestehen aus automatisch oder nicht automatisch erstellten Sicherungen des Systems unter Verwendung des alten Systems, die in das neue System übersetzt werden. (Rooijmans, 2003) |
| Automatische Aufholjagden | Automatisch erstellte Aufholjagden (Rooijmans, 2003) |
| Von Hand aufholen | Aufholjagden durch manuelle Eingabe (Rooijmans, 2003) |
Festlegung der Strategie für die parallele Implementierung
Der parallelen Übernahme geht die Festlegung der Implementierungsstrategie voraus, die nicht nur für die parallele Übernahme gilt, sondern als Teil des Änderungsmanagementprozesses angesehen werden kann, in den eine Organisation eintritt. (Lee, 2004). Einige Faktoren, die bei der Festlegung einer Implementierungsstrategie für Adoptionsmethoden eine Rolle spielen, werden in Adoption (Software-Implementierung) ausführlicher beschrieben .
Risiko versus Kosten
Der Grund für eine Organisation, sich für eine parallele Übernahme zugunsten einer Pilotkonvertierung, eines Urknalls oder einer schrittweisen Einführung zu entscheiden, ist häufig ein Kompromiss zwischen Kosten und Risiko (Andersson, Hanson, 2003). Parallele Adoption ist die teuerste Adoptionsmethode (Chng, Vathanopas, 2002, Microsoft, 2004, Anderson et al., 2003), da von der Organisation verlangt wird, dass zwei Systeme für einen bestimmten Zeitraum parallel ausgeführt werden. Der gleichzeitige Betrieb von zwei Systemen bedeutet, dass eine Investition in die Personalabteilung getätigt werden muss. Neben einer guten Vorbereitung des (zusätzlichen) Personals muss dies eine stressige Zeit des parallelen Laufens durchlaufen, in der sich die Verfahren kreuzen. (Rooijmans, 2003, Eason, 1988) Es sollten Anstrengungen unternommen werden, um Datenkonsistenz zu gewährleisten und Datenkorruption zwischen den beiden Systemen zu verhindern. (Chng et al. 2002, Yusuf, 2004) Nicht nur für den Konvertierungsprozess selbst, sondern auch für die Schulung zum Umgang mit dem neuen System.
Wenn das neue System nach einem Urknall-Ansatz implementiert werden muss, ist das Ausfallrisiko hoch (Lee, 2004). Wenn die Organisation stark verlangt, dass das alte (Legacy-) System geändert wird, sollte der Kompromiss zwischen zusätzlichen Kosten für einen weniger riskanten parallelen Ansatz zugunsten dieser zusätzlichen Kosten sein (Lee, 2004), wie wir sehen Diese ERP-Einführung folgt in den meisten Fällen einer Urknall-Einführung (Microsoft, 2004, Yusuf, 2004).
Dies bedeutet, dass eine Organisation klar über ihre Implementierungsstrategie nachdenken und diese Entscheidung in ihre Risikomanagement- oder Änderungsmanagementanalyse integrieren sollte .
Ein Implementierungsskript entwickeln
IT-Anforderungen
Um die Organisation richtig vorzubereiten, ist eine Anforderungsanalyse sowohl der IT-Anforderungen als auch der organisatorischen Anforderungen erforderlich. Weitere Informationen zur Anforderungsanalyse und zum Änderungsmanagement finden Sie an anderer Stelle. Für die parallele Übernahme ist die wichtigste IT-Anforderung (falls zutreffend) die Aufmerksamkeit für die gleichzeitige Ausführung der beiden Systeme. In der Konvertierungsphase gibt es einen Zeitschlitz, in dem das alte System das führende System ist. Um die Daten vom alten System in der Nachholphase auf das neue System zu übertragen, muss ein Übergangsmodul verfügbar sein (Microsoft, 2004). Andere Implementierungsmethoden haben diese Anforderung nicht direkt. Weitere Informationen zu den IT-Anforderungen finden Sie im Software Engineering .
Organisatorische Anforderungen
Neben den IT-Anforderungen erfordern die organisatorischen Anforderungen Human Resource Managements Themen wie, die Ausbildung von Personal , befassen sich mit einer vielleicht verändernden Organisationsstruktur , organischer Organisation oder mechanistischer Organisation Merkmalen der Organisation (Daft 1998) und vor allem: Top - Management - Unterstützung (Brown, Vessey, 1999). Brown et al. (1999) identifizieren zwei unterschiedliche Rollen, die das Top-Management initiieren kann: die sogenannten Sponsor- und Champion-Rollen:
- „Ein Projektsponsor ist für die Budgethilfe verantwortlich und stellt sicher, dass wichtige Unternehmensvertreter eine Rolle im Projektteam spielen.“
- „Der Projektchampion kann ein formelles Mitglied des Projektteams sein oder nicht, kann aber eine Schlüsselrolle bei den Bemühungen um Änderungsmanagement spielen.“
Ein paralleler Adoptionsprozess ist sehr stressig und erfordert gut vorbereitete Mitarbeiter, die mit Fehlern umgehen können, ohne konservativ auf das alte System zu achten. (Eason, 1988)
Zeitplanung
Es ist sehr wichtig, einen detaillierten Plan für die Durchführung des neuen Systems in einer Organisation zu haben (Lee, 2004, Eason, 1988). Das Wichtigste bei der Zeitplanung für eine parallele Konvertierung ist, sich nicht zu beeilen und keine Angst vor möglichen Verzögerungen in der eigentlichen Konvertierungsphase zu haben. (Lee, 2004). Es kann sehr vorteilhaft sein, auch mit klar definierten Meilensteinen zu arbeiten (Rooijmans, 2003), ähnlich der PRINCE2- Methode. Weitere Informationen zur Zeitplanung finden Sie unter Planung und strategische Planung .
Organisation vorbereiten
Anforderungsbewertung
Bei der Anforderungsbewertung wird das Implementierungsskript neu definiert. Die gestellten IT- und (wenn möglich) organisatorischen Anforderungen sollten getestet werden. Einige Tests können durchgeführt werden, bei denen die organisatorischen Verantwortlichkeiten (Rooijmans, 2003) sowie die IT-Anforderungen bewertet werden können. Auch hier ist es wieder wichtig, Unterstützung und Engagement des Top-Managements zu haben (Eason, 1988). Wenn sie keine Ressourcen zur Bewertung zur Verfügung stellen, kann die Implementierung als direkte Folge erfolglos sein. Nach dieser Auswertung wird das Implementierungsskript in ein expliziteres Konvertierungsszenario neu definiert.
Konvertierungsszenario
Das Konvertierungsszenario besteht somit aus einem Entwurf für die organisatorische Änderung in allen Aspekten. Es gibt jedoch zwei Themen, die im Rahmen der parallelen Annahme noch nicht die Aufmerksamkeit erhalten haben, die sie verdienen.
- Problemumgehungsstrategie / Rollback-Plan: Im Unterschied zu den anderen Adoptionsszenarien ist auch die Problemumgehungs- oder Notfallstrategie mit einem Rollback- Plan in das Konvertierungsszenario integriert . Die Problemumgehungsstrategie wird in einem anderen Eintrag in einem breiteren Bereich definiert. In diesem Zusammenhang wird jedoch wie in der obigen Tabelle definiert angegeben: Ein Sicherungsplan; Strategie im Konvertierungsszenario übernommen, um Fehler im Konvertierungsprozess zu vermeiden und zu versuchen, diese zu umgehen, damit die Implementierung weiterhin erfolgreich sein kann. (Microsoft, 2004). Der Rollback-Plan als mögliche Problemumgehungsstrategie wird eingeleitet, wenn in der Konvertierungsphase ein Fehler auftritt. Da die beiden Systeme gleichzeitig ausgeführt werden, gibt der Rollback-Plan in einer parallelen Übernahme an, dass die Datenbank oder ein anderes System, das die Transaktionen verarbeitet, im Legacy-System vollständig zurückverfolgbar sein sollte (Microsoft, 2004). Tatsächlich bietet die parallele Übernahme per Definition diesen Rollback-Plan aufgrund der Natur eines führenden Systems und eines (nicht führenden) Backup- Systems.
- Kriterienindikatoren: Da das Konvertierungsszenario eine Blaupause für die Ausführung der Übertragung der beiden Systeme darstellt, sind auch quantifizierbare Kriterien erforderlich. Die neu definierten IT- und Organisationsanforderungen werden in messbare Komponenten übertragen. Wenn die Kriterien bei der Testkonvertierung nicht erfüllt werden, sollte die Problemumgehungsstrategie bereitgestellt werden.
Umwandlung
Die eigentliche Konvertierungsphase ist nun abgeschlossen. Während dieses Prozesses befindet sich die Organisation in einer stressigen Zeit (Eason, 1988, Rooijmans, 2003). Die beiden Systeme laufen gemäß dem Konvertierungsszenario parallel und das neue System wird genau überwacht. Wenn die Kriterien des neuen Systems erfüllt sind, wird das alte System nicht mehr das führende System sein und das neue System übernimmt. Die Aufholjagden, die Teil der Problemumgehungsstrategie sind , sind die Sicherungen des alten Systems und bieten die Mittel für Zuverlässigkeitstechnik und Datenwiederherstellung . Es gibt zwei Arten von Aufholjagden: automatische Aufholjagden und Aufholjagden von Hand. (Rooijmans, 2003). Falls zutreffend, kann auch ein Remote-Sicherungsdienst bereitgestellt werden.
Kontrollsystem
- Automatische Aufholjagden: Aufholjagden , die von einem automatisierten System übertragen werden, das in der Vorbereitungsphase der Organisation erstellt wurde. Dieses System überträgt die Daten oder Informationen automatisch auf das neue System, wenn die Konvertierung vom alten führenden System zum neuen führenden System erfolgt. Der Vorteil eines automatisierten Systems besteht darin, dass es schnell und genau ist. Der Nachteil ist, dass es Zeit braucht, um ein Transfersystem in einem früheren Stadium herzustellen.
- Aufholjagd von Hand: Wenn die eigentliche Konvertierung nur wenig Zeit in Anspruch nimmt oder die Komplexität der Informationen, die auf das neue System übertragen werden sollen, gering ist, kann eine Organisation die Aufholjagd manuell übertragen. Der Vorteil dieses Verfahrens besteht darin, dass kein System (Softwareprogramm) erforderlich ist, um die Informationen und die möglichen Probleme, die mit einer solchen Art von Übertragungsprogramm verbunden sind, zu übertragen. Der Kompromiss ist Genauigkeit und Zeit. Die manuelle Übertragung der Aufholjagden nimmt viel Zeit in Anspruch und ist anfälliger für kleine menschliche Fehler (Rooijmans, 2003). Darüber hinaus ist die zusätzliche Investition in Arbeitsstunden bereits hoch; Ein manuelles Aufholsystem übt noch mehr Druck auf das Personal aus.
Bewertung / Praktische Relevanz
Aus Fallstudien lassen sich mehrere Lehren ziehen: Der von Lee (2004) beschriebene Fall des DMV-Systems in Nevada zeigt, dass eine Implementierung in einen neuen Prozess auch politische Auswirkungen haben kann. Wenn das System, das geändert wird, die breite Öffentlichkeit betrifft und nicht nur ein internes System geändert wird, gibt es weitere Belastungen, die die Organisation beeinflussen. In diesem Fall können sich Konzepte wie Unternehmensimage und Reputation drastisch ändern, wenn Kunden mit größeren Verzögerungen beispielsweise bei der Kommunikation oder der Bestellung von Waren konfrontiert sind. Es wird empfohlen, bei einer politischen Sensibilität des Systems der Umstellungsmethode mehr Aufmerksamkeit zu widmen und vorzugsweise eine parallele Übernahme zu wählen, da ein geringeres Risiko besteht.
Eine Reihe von Lehren aus einer Reihe von tatsächlichen Fallszenarien, in denen ein neues Portfolio-System implementiert wurde und die von einem Unternehmensberatungsunternehmen (Venture, 2004) durchgeführt wurden, zeigen einige interessante Lehren aus diesem Bereich. Sie scheinen perfekt zu den Themen zu passen, die für einen generischen parallelen Adoptionsprozess auf der Grundlage einer Kombination wissenschaftlicher Arbeiten genannt wurden. Zusammenfassen:
- Risikobewertung und Notfallplanung (Workaround) sind sehr wichtig
- Weisen Sie Projektteamrollen zu
- Erstellen Sie bestimmte Meilensteine (wie PRINCE2 ), einschließlich Schulungs- und Testplänen
- Identifizieren Sie potenzielle Risiken und führen Sie bei Bedarf Ihren Notfallplan aus
- Projektstatus kommunizieren
- Änderungen sollten entsprechend genehmigt werden
- Die Konvertierungsstrategie muss die Datenanforderungen sorgfältig prüfen
- Neue und geänderte Daten sollten anhand von Validierungsregeln getestet werden
- Erstellen Sie einen gründlichen Rollback-Plan
- Wenn möglich, verhandeln Sie eine Pilotkonvertierung
Es gibt auch mindestens zwei Schwierigkeiten bei der parallelen Konvertierung, die ihre Verwendung im 21. Jahrhundert unpraktisch machen könnten, obwohl dies ein Grundnahrungsmittel der Industriepraxis war, wenn Eingaben aus Lochkartenstapeln oder Bandspulen bestanden. Diese sind:
1. Es ist unpraktisch zu erwarten, dass Endbenutzer, seien es Kunden, Produktionsmitarbeiter oder fast alle anderen, jede Transaktion zweimal über verschiedene Schnittstellen eingeben.
2. Zeitliche Unterschiede zwischen zwei interaktiven Mehrbenutzersystemen können zu unterschiedlichen Ergebnissen führen, selbst wenn beide Systeme ordnungsgemäß funktionieren, intern konsistent sind und von sich aus erfolgreich verwendet werden können.
Infolgedessen ist die parallele Konvertierung heutzutage auf einige bestimmte Situationen beschränkt, z. B. Buchhaltungssysteme, in denen eine absolute Überprüfbarkeit der Ergebnisse erforderlich ist, in denen alle Benutzer unternehmensintern sind und diese Anforderung verstehen und in denen die Reihenfolge der Aktivitäten nicht zulässig ist Auswirkungen auf die Ausgabe. In der Praxis sind die Pilot- und Phasenumwandlungsmethoden heute relevanter.
Siehe auch
- Produkt-Software-Annahme: Urknall-Annahme
- Stufenweise Annahme
- Annahme (Software-Implementierung)
- Regatta: Adoptionsmethode
- Änderungsmanagement
- Zuverlässigkeitstechnik
- Rollback (Datenverwaltung)
- Risikomanagement
- Softwareentwicklung
- Implementierung
Verweise
Artikel
- Andersson I. Hanson, K. (2003). Technologiediffusion in einer Softwareorganisation, Diplomarbeit in angewandter Informationstechnologie , Universität Göteborg
- Brown, CV & Vessey, I. (1999). ERP-Implementierungsansätze: Auf dem Weg zu einem Notfallrahmen, Tagungsband der 20. Internationalen Konferenz über Informationssysteme , Charlotte, NC, 13.-15. Dezember, 411-416.
- Chng, S. & Vathanophas V. (2002). Auf dem Weg zu einem organisationsübergreifenden Unternehmenssystem: Eine Fokusgruppenstudie. Die 6. pazifische Asien-Konferenz über Informationssysteme (PACIS 2002). Tokyo, Japan. 2. bis 4. September 2002.
- Lee, O. (2004). Eine Fallstudie zum DMV-System in Nevada, Journal der Academy of Business and Economics , Band 3
- Ribbers, P. & Schoo, KC (2002). Entwerfen komplexer Software-Implementierungsprogramme, 35. Hawaii International Conference on System Sciences (HICSS'02) , Band 8
- Yusuf, Y. & Gunasekaran, A. & Abthorpe MS (2004). Projektimplementierung für Unternehmenssysteme: Eine Fallstudie zu ERP in Rolls Royce. International Journal of Production Economics , 87, 251 & ndash; 266.
Bücher
- Daft, RL (1998). Organisationstheorie und Design. Westen: International Thomson
- Eason, K. (1988). "Kapitel 9, Implementierung und Support" in: Informationstechnologie und organisatorischer Wandel. London: Taylor und Francis
- Turban, E. & Mclean, E. & Wetherbe J. (2002) „Kapitel 14, Aufbau von Informationssystemen“, in: Informationstechnologie für das Management. New York: John Wiley & Sons, Inc.
- R. Rooimans, M. de Theye & R. Koop (2003). Regatta: IKT-Implementierungen als auch für vier-met-stuurman. Den Haag: Zehn Hagen en Stam Uitgevers.