Parallell adoption
Parallell adoption är en metod för att överföra mellan ett tidigare ( IT ) system till ett mål (IT) system i en organisation. För att minska risken körs det gamla och det nya systemet samtidigt under en viss tid varefter, om kriterierna för det nya systemet uppfylls, det gamla systemet avaktiveras. Processen kräver noggrann planering och kontroll och en betydande investering i arbetstimmar.
Översikt
Detta inlägg fokuserar på den generiska processen för parallell adoption; (verkliga) exempel används för en mer meningsfull tolkning av processen vid behov. Dessutom används en processdatamodell för att visualisera processen som är avsedd att ge en fullständig översikt över alla steg som är involverade i den parallella adoptionen, men tonvikten kommer att läggas på de unika egenskaperna hos parallell adoption. Några vanliga egenskaper, särskilt att definiera en implementeringsstrategi, som gäller för alla fyra generiska typerna av adoption beskrivs i Adoption (programvaruimplementering) .
Andra typer av adoption
Förutom parallell adoption kan tre andra generiska adoptioner identifieras. Valet av en specifik adoptionsmetod beror på de organisatoriska egenskaperna; mer insikt om detta ämne kommer att ges nedan. De tre andra adoptionsmetoderna är: Adoption av produktprogramvara: Big Bang Adoption (även känd som Direct Conversion, slam dunk eller cold-turkey-strategi), Fasad adoption och Pilotadoption.
- Adoption av produktprogramvara: Big Bang Adoption/Plunge Adoption: En big-bang-adoption innebär att hela organisationen överförs från det gamla systemet till det nya systemet i en omedelbar övergång. Detta är det billigaste alternativet men om det nya systemet misslyckas är organisationen i stora problem. Det öppnar också risker för att systemet inte accepteras av dess användare. Detta kan dock vara det enda tillvägagångssättet när de två systemen inte kan samexistera eller aktivering av det nya systemet är en nödsituation.
- Fasad adoption (även känd som gradvis konvertering): I fasad adoptionsimplementering går organisationen gradvis över till ett nytt system i olika faser, per modul eller delsystem. Vissa system är oförmögna att introduceras i bitar eftersom det är alltför beroende av hela systemet. Att använda den stegvisa adoptionen har mindre risker, men orsakar flest störningar på grund av att det tar mest tid att överföra från det gamla systemet till det nya.
- Pilotantagande: Pilotantagandemetoden används för stora organisationer som har flera platser eller till stor del oberoende avdelningar. Det nya systemet införs på någon av orterna eller avdelningarna och utökas med tiden till andra orter eller avdelningar. (begränsad gräns om ett nytt system är ett fel) (Turban, 2002)
Det finns flera tillfällen då parallell konvertering inte kan anses vara en hållbar konverteringsstrategi. Fundera först på om det nya systemet innehåller betydande schemaändringar. Dataelement som krävs av ett system och som inte fylls i av det andra kan i bästa fall leda till felaktigheter i data och i värsta fall datakorruption. En annan oro är om systemet förlitar sig på konsumenten från hyllan teknik (COTS). Om en COTS-leverantörs dokumentation anger att mer än en applikation inte kan dela samma databas, är parallellkonvertering inte ett alternativ. Ett exempel skulle vara Oracles Siebel-produkter. Andra COTS-produkter kan också lägga restriktioner när patchar eller större uppgraderingar kräver unika licensnycklar. När de väl har applicerats kan de göra databasändringar som kan orsaka att programmet felaktigt upptäcker ett parallellt system som körs mot samma databas som ett försök att komma runt licenskontroller och därigenom inaktivera systemet.
Plats i implementeringsprocessen
Det verkar finnas få konventioner om processen för parallell adoption. Flera källor (t.ex.: Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999), använder inte ett enda processbeskrivningsnamn. Termen parallell adoption betecknas i dessa källor, även om den är konsekvent per källa som: parallell konvertering, parallell körning, skuggkörning, parallell cutover och parallell implementering. Detta verkar vara fallet eftersom en generisk beskrivning av processen inte behöver en distinkt klassificering. Det finns en hel del standardimplementeringsmetoder, där olika adoptionstekniker beskrivs men ofta i ett praktiskt sammanhang; verkliga fallscenario eller en mer omfattande uppsättning implementeringstekniker som Regatta: adoptionsmetod, SIM och PRINCE2 . Generellt sett kan parallell adoption bäst ses som en systemteknisk metod för implementering av ett nytt system.
Metoden för parallell adoption skiljer sig i princip från beslutet att ändra ett system i en organisation och kan ses som ett möjligt medel för att uppnå det målet. Det finns dock en hel del faktorer som tas med i beräkningen för att fastställa den bästa implementeringsstrategin . Dessutom kan en framgångsrik implementering i stor utsträckning bero på adoptionsmetoden. (Lee, 2004)
Processen
Den parallella adoptionsprocessen kan inte representeras utan att vara uppmärksam på stegen före den faktiska konverteringen, nämligen konstruktionen av ett konverteringsscenario och identifiering och testning av alla krav . Därför förklaras processen genom att gå igenom alla identifierade processer i figur 1, samtidigt som de gemensamma aktiviteter som är nödvändiga för någon av de identifierade konverteringsstrategierna kortfattat tas upp.
Figur 1 ger en översikt över den parallella adoptionsprocessen. Den vänstra sidan visar flödet av aktiviteter som bidrar till processen. Aktiviteter som löper samtidigt föregås av en tjock svart linje. När den parallella driften av aktiviteter är över, sammanfogas aktiviteterna igen i en liknande svart linje. När det inte finns någon pil från en aktivitet till en annan, indikerar detta att de är aggregat av en större aktivitet ovan. Verksamheten är uppdelad i fyra huvudfaser:
- Definiera implementeringsstrategi , som handlar om vilken typ av implementeringsstrategi som ska utföras.
- Pre-implementation , som har att göra med att konstruera en planering av alla aspekter och krav som är involverade i implementeringen.
- Förbered organisationen Organisationen bör förberedas ordentligt enligt föregående fas.
- Konvertering handlar om själva konverteringsprocessen och avslutar konverteringsprocessen; fortsätter med det nya systemet.
Huvudfaserna är uppdelade i andra aktiviteter som kommer att beskrivas kortfattat i tabellerna 1-1 till 1-4.
Den högra sidan av modellen beskriver de data som ingår i processerna. Vissa av dessa begrepp, avbildade som ett par överlappande öppna rektanglar, kan delas upp i mer än ett begrepp. Ett par överlappande slutna rektanglar indikerar ett slutet koncept vilket innebär att det kan delas upp i fler koncept, men det är inte av ytterligare intresse för den parallella adoptionsprocessen. Diamantformsfiguren indikerar att begreppet kopplat till det fungerar som ett aggregerat begrepp och att detta begrepp består av de andra begreppen. Slutligen representerar den öppna pilen en superklass-underklassrelation. Konceptet kopplat till pilen är superklassen av de begrepp som är kopplade till det. Denna syntax i figur 1 är enligt Unified Modeling Language ( UML ) standarder. Begreppen i figur 1 definieras i tabell 2. Mer sammanhang för dessa delaktiviteter i processen kommer att ges under tabellerna.
| Aktivitet | Beskrivning |
|---|---|
| Definiera implementeringsstrategi | Implementeringsstrategin fastställs i detta tidiga skede. (Brown, Vessey, 1999) |
| Skapa masterimplementeringsskript | Den första inledande kravanalysen görs, bestående av kraven nedan. (Venture, 2004) |
| Bygg Tidsplanering | En första tidsplanering av implementeringsprocessen håller på att konstrueras. (Rooijmans, 2003) |
| Definiera organisatoriska krav | De organisatoriska kraven definieras här (Rooijmans, 2003). |
| Definiera IT-krav | IT-kraven bestäms (Rooijmans, 2003) |
| Aktivitet | Beskrivning |
|---|---|
| Installationskrav | För att förbereda organisationen installeras de definierade kraven. Organisationen förbereds och IT installeras på testmaskiner. (Rooijmans, 2003, Eason, 1988, Microsoft, 2004) |
| Testkrav | Kraven testas för att se om organisationen är redo för implementering (Rooijmans, 2003) |
| Omdefiniera masterimplementeringsskript | Masterimplementeringsskriptet förfinas med den nya informationen som samlas in i processen med aktiviteterna nedan. (Rooijmans, 2003) |
| Definiera kriterieindikatorer | För att testa det nya systemet skapas kriterieindikatorer. (Rooijmans, 2003, Microsoft, 2004) |
| Formulera lösning/återställningsplan | Dessutom görs en lösningsplan med ett återställningsscenario. Med dessa planer kan organisationen försöka rätta till de misstag som görs respektive falla tillbaka om implementeringen i ett visst skede av processen misslyckas. (Microsoft, 2004, Rooijmans, 2003) |
| Utför (segmentell) testkonvertering | I mycket komplexa organisationer kan det vara fördelaktigt att utföra en testkonvertering, innan man går "live". (Microsoft, 2004, Rooijmans, 2003) |
| Aktivitet | Beskrivning |
|---|---|
| Gör ikapp | Konverteringsprocessen startas, ett antal aktiviteter löper parallellt. Under detta skede görs ikapp med det gamla systemet. Det gamla systemet leder, men det nya löper parallellt. Alla ändringar i systemet måste läggas i det nya systemet. (Microsoft, 2004, Rooijmans, 2003) |
| Kontrollsystem | Systemet styrs hela tiden av styrsystemet. Med de definierade indikatorerna och systemkörningsegenskaperna spåras fel och misstag. (Microsoft, 2004, Rooijmans, 2003) |
| Kör ledande gamla system | Det gamla systemet leder; bearbeta de faktiska uppgifterna. |
| Kör nytt system | Det nya systemet går parallellt med det gamla systemet och övervakas noga. (Microsoft, 2004, Rooijmans, 2003) |
| Översätt catch ups i nytt system | Om kriterierna är uppfyllda översätts och överförs inhämtningen i det nya systemet och konverteringsprocessen kommer i nästa steg. (Microsoft, 2004, Rooijmans, 2003) |
| Utför strategi för lösning/återställning | Om kriterierna inte uppfylls utförs lösningsstrategin eller återställningsstrategin, beroende på typen av fel. (Microsoft, 2004, Rooijmans, 2003) |
| Gör ikapp | Ikapp görs av säkerhetsskäl, även när det nya systemet leder. (Microsoft, 2004, Rooijmans, 2003) |
| Kör gammalt system | Det gamla systemet körs som backup, av säkerhetsskäl |
| Kör ledande nytt system(1) | Det nya systemet är ledande och i full drift. Här hanteras alla transaktioner och förändringar i systemet. (Microsoft, 2004, Rooijmans, 2003) |
| Aktivitet | Beskrivning |
|---|---|
| Kör ledande nytt system(2) | Alla catch ups och kontroller är stängda. Det nya systemet är det enda systemet i drift. (Microsoft, 2004, Rooijmans, 2003) |
| Inaktivera det gamla systemet | Det gamla systemet är inte längre nödvändigt och är inaktiverat. (Microsoft, 2004, Rooijmans, 2003) |
Begreppen från figur 1 definieras i tabell 2-1 nedan.
| Begrepp | Definition |
|---|---|
| Implementeringsstrategi | Strategin som kommer att väljas för att implementera det nya systemet. Alternativen är big bang, fasad, parallell adoption, pilotkonvertering eller en kombination av dessa fyra. (Turban, 2002, Rooijmans, 2003) |
| Implementeringsskript | Råversion av själva konverteringsscenariot, bestående av organisationskrav, IT-krav och en initial tidsplanering. (Venture, 2004, Eason, 1988) |
| Organisatoriska krav | Krav inifrån organisationen som ska finnas för en framgångsrik implementering. De sysslar med att optimera (förändra) organisationen för det nya systemet. Inblandade frågor kan vara: Personalhantering, förändrade organogram och nya affärsstrukturer. (Rooijmans, 2003) |
| IT-krav | Informationsteknologikraven är kraven på mjukvara och hårdvara, plattformsval, med hänsyn till budget och befintliga system. (Rooijmans, 2003) |
| Tidsplanering | En planering där aktiviteter tilldelas en tidsperiod då de ska slutföras, vilket ger en helhetsbild av genomförandeprojektet med hänsyn till tillgänglig tid. (Eason, 1988) |
| Krav | |
| Överensstämmelse | Konformitet handlar om att uppfylla kraven. (ISO 9000) |
| Omvandlingsscenario | Det omdefinierade implementeringsskriptet, med hänsyn till överensstämmelsen med kraven. Dessutom består konverteringsscenariot av en lösning och återställningsplan. Konverteringsscenariot är ritningen av implementeringsprojektet. (Rooijmans, 2003) |
| Lösningsstrategi | En reservplan; strategi som antagits i konverteringsscenariot för att förhindra fel i konverteringsprocessen och försöka kringgå dem, så att implementeringen fortfarande kan bli framgångsrik. (Rooijmans, 2003) |
| Kriterieindikatorer | Kvantifierbara och mätbara kriterier med avseende på kraven, för att avgöra om implementeringsprocessen var framgångsrik. (Rooijmans, 2003) |
| Återställningsplan | Plan som underlättar att vända replikeringens riktning för att gå tillbaka till det gamla systemet utan förlust av data eller information. (Microsoft, 2004) |
| Testkonvertering | Segmentell testkonvertering, innan själva konverteringen sker med målsättning att vara bättre förberedd mot osäkerheter eller problem i själva konverteringsprocessen. (Microsoft, 2004) |
| Gammalt system | Det gamla systemet: när ledande = sant; det gamla systemet hanterar systemtransaktionerna live: De huvudsakliga fungerande enheterna som utgör produkten, t.ex. hårdvara, mjukvara. Också ett organiserat och disciplinerat tillvägagångssätt för att utföra en uppgift, t.ex. ett felrapporteringssystem ( ISO 9000) |
| Nytt system | Det nya systemet (mål): Det nya systemet, när ledande = sant; det nya systemet hanterar systemtransaktionerna live. De huvudsakliga fungerande enheterna som utgör produkten, t.ex. hårdvara, mjukvara. Också ett organiserat och disciplinerat tillvägagångssätt för att utföra en uppgift, t.ex. ett felrapporteringssystem ( ISO 9000) |
| Kontrollera | Det övergripande kontrollsystemet som består av resultatindikatorer samt en tillförlitlighetsbedömning och ikapp. Styrsystemet är mycket brett och är det centrala kommandosystemet för att konvertera det gamla systemet och hantera det nya under den parallella adoptionsprocessen. (Rooijmans, 2003, Microsoft, 2004) |
| Prestanda | Kvantifierbar bedömning av prestanda hos det gamla och nya systemet fungerar som input för styrsystemet. (Rooijmans, 2003) |
| Tillförlitlighetsbedömning | En kvantitativ bedömning av tillförlitligheten hos en produkt, ett system eller en del därav. Sådana bedömningar använder vanligtvis matematisk modellering, direkt tillämpbara resultat av tester på produkten, feldata, uppskattade tillförlitlighetssiffror och icke-statistiska tekniska uppskattningar. (ISO 9000) |
| Ikapp | Catch ups består av automatiskt eller icke-automatiskt skapade säkerhetskopior av systemet med det gamla systemet, som ska översättas till det nya systemet. (Rooijmans, 2003) |
| Automatiska ikappningar | Automatiskt skapade catch ups (Rooijmans, 2003) |
| Kom ikapp för hand | Ikappningar skapade av manuell inmatning (Rooijmans, 2003) |
Fastställande av den parallella implementeringsstrategin
Den parallella adoptionen föregås av att fastställa implementeringsstrategin, vilket inte är unikt för parallell adoption, utan kan ses som en del av den förändringsledningsprocess som en organisation går in i. (Lee, 2004). Vissa faktorer som är involverade i att fastställa en implementeringsstrategi för adoptionsmetoder beskrivs mer ingående i Adoption (programvaruimplementering) .
Risk kontra kostnader
Anledningen till att en organisation väljer parallell adoption till förmån för en pilotkonvertering, big bang eller etappadoption är ofta en avvägning mellan kostnader och risk (Andersson, Hanson, 2003). Parallell adoption den dyraste adoptionsmetoden (Chng, Vathanopas, 2002, Microsoft, 2004, Anderson et al., 2003), eftersom den kräver av organisationen att två system ska köras parallellt under en viss period. Att köra två system samtidigt innebär att en investering i Human Resources måste göras. Förutom en bra förberedelse av (extra) personalen måste det gå igenom en stressig period av parallellkörning där rutiner korsar varandra. (Rooijmans, 2003, Eason, 1988) Ansträngningar bör läggas på datakonsistens och förhindra datakorruption mellan de två systemen. (Chng et al. 2002, Yusuf, 2004) Inte bara för själva konverteringsprocessen, utan också för att träna dem för att hantera det nya systemet. När det är nödvändigt att det nya systemet implementeras efter en big bang-strategi är risken för misslyckande stor (Lee, 2004). När organisationen kräver stora krav på att det gamla (legacy) systemet ska ändras, bör avvägningen mellan extra involverade kostnader för ett mindre riskabelt parallellt tillvägagångssätt vara till förmån för dessa extra kostnader (Lee, 2004), trots detta ser vi att ERP-antagande följer på en big bang-adoption i de flesta fall (Microsoft, 2004, Yusuf, 2004). Detta innebär att en organisation bör tänka klart över sin implementeringsstrategi och integrera detta beslut i sin riskhanterings- eller förändringshanteringsanalys .
Utveckla ett implementeringsskript
IT-krav
För att förbereda organisationen på rätt sätt krävs en kravanalys av såväl IT-krav som organisationskrav. Mer information om kravanalys och förändringshantering finns på annat håll. För parallell användning är det viktigaste IT-kravet (om tillämpligt) uppmärksamhet för att köra de två systemen samtidigt. I konverteringsfasen finns en tidslucka, där det gamla systemet är det ledande systemet. För att kunna överföra data från det gamla systemet under inhämtningsperioden till det nya systemet måste det finnas en övergångsmodul tillgänglig (Microsoft, 2004). Andra implementeringsmetoder har inte direkt detta krav. Mer information om IT-krav finns i Software Engineering .
Organisatoriska krav
Förutom IT-kraven kräver de organisatoriska kraven Human Resource Management frågor som utbildning av personal , hantering av en kanske förändrad organisationsstruktur , organisk organisation eller Mekanistiska organisationsegenskaper hos organisationen (Daft, 1998) och viktigast av allt: Toppledningsstöd (Brown, Vessey, 1999). Brown et al. (1999) identifierar två distinkta roller som högsta ledningen kan initiera: de så kallade sponsor- och mästarrollerna:
- "En projektsponsor är ansvarig för budgetstöd och för att se till att viktiga företagsrepresentanter spelar en roll i projektteamet."
- "Projektförkämpen kan vara en formell medlem i projektteamet, men kan spela en nyckelroll i förändringsarbete"
En parallell adoptionsprocess är mycket påfrestande och kräver väl förberedda medarbetare som kan hantera misstag som görs, utan att vara konservativt ivriga till det gamla systemet. (Eason, 1988)
Tidsplanering
Det är mycket viktigt att ha en detaljerad plan för hur det nya systemet ska genomföras i en organisation (Lee, 2004, Eason, 1988). Det viktigaste med tidsplanering för en parallell konvertering är att inte skynda på och inte vara rädd för eventuella förseningar i själva konverteringsfasen. (Lee, 2004). Det kan också vara mycket fördelaktigt att arbeta med tydligt definierade milstolpar (Rooijmans, 2003), liknande PRINCE2 -metoden. Mer information om tidsplanering finns i Planering och strategisk planering .
Förbereder organisationen
Kravutvärdering
Kravutvärderingen innebär omdefiniering av implementeringsskriptet. De IT- och (om möjligt) organisatoriska krav som ställdes bör testas. Vissa tester kan köras där det organisatoriska ansvaret kan utvärderas (Rooijmans, 2003) samt IT-kraven. Här är det också återigen viktigt att ha toppledningsstöd och engagemang (Eason, 1988). Om de inte ställer resurser till förfogande för att utvärdera kan implementeringen misslyckas som en direkt följd. Efter denna utvärdering omdefinieras implementeringsskriptet till ett mer explicit konverteringsscenario.
Omvandlingsscenario
Omställningsscenariot består alltså av en plan för organisationsförändringen i alla aspekter. Det finns dock två ämnen som ännu inte fått den uppmärksamhet de förtjänar i det parallella adoptionsområdet.
- Lösningsstrategi/återställningsplan: Eftersom den skiljer sig från de andra användningsscenarierna, är lösningen eller beredskapsstrategin också integrerad i konverteringsscenariot med en återställningsplan . Lösningsstrategin definieras i ett bredare omfång i en annan post, men i detta sammanhang indikerar den enligt definitionen i tabellen ovan: En reservplan; strategi som antagits i konverteringsscenariot för att förhindra fel i konverteringsprocessen och försöka kringgå dem, så att implementeringen fortfarande kan bli framgångsrik. (Microsoft, 2004). Återställningsplanen, som en möjlig lösningsstrategi, initieras om något går fel i konverteringsfasen. Eftersom de två systemen körs samtidigt, i en parallell adoption, indikerar återställningsplanen att databasen eller annat system som hanterar transaktionerna bör vara fullt spårbart i det äldre systemet (Microsoft, 2004). I själva verket ger den parallella antagandet per definition denna återställningsplan på grund av dess karaktär av ett ledande system och ett (icke-ledande) backupsystem .
- Kriterieindikatorer: Eftersom omvandlingsscenariot är en plan för att genomföra överföringen av de två systemen, innebär det också kvantifierbara kriterier. De omdefinierade IT- och organisationskraven överförs till mätbara komponenter. När kriterierna inte uppfylls i testkonverteringen bör lösningsstrategin implementeras.
Omvandling
Själva konverteringsfasen är nu på plats. Under denna process befinner sig organisationen i en stressig period (Eason, 1988, Rooijmans, 2003). De två systemen går parallellt enligt konverteringsscenariot och det nya systemet övervakas noggrant. När kriterierna för det nya systemet är uppfyllda kommer det gamla systemet att upphöra att vara det ledande systemet och det nya systemet tar över. Uppsvingarna som är en del av lösningsstrategin är säkerhetskopieringarna av det gamla systemet och tillhandahåller medel för tillförlitlighetsteknik och dataåterställning . Det finns två typer av sätt att göra catch-ups: automatisk catch ups och catch ups för hand. (Rooijmans, 2003). Om tillämpligt kan en fjärrsäkerhetskopieringstjänst också distribueras.
Kontrollsystem
- Automatiska catch ups: Catch ups som överförs av ett automatiserat system, skapat i förberedelse av organisationsfasen. Detta system överför automatiskt data eller information till det nya systemet när konverteringen går från det gamla ledande systemet till det nya ledande systemet. Fördelen med ett automatiserat system är att det är snabbt och exakt. Nackdelen är att det tar tid att ta fram ett överföringssystem i ett tidigare skede.
- Hämta ikapp för hand: När själva konverteringen bara tar en kort tid, eller komplexiteten i informationen som ska överföras till det nya systemet är liten, kan en organisation välja att överföra träffen manuellt. Fördelen med denna procedur är att det inte finns något behov av ett system (mjukvara) för att överföra informationen och de eventuella problem som kommer med en sådan typ av överföringsprogram. Avvägningen är noggrannhet och tid. Det tar avsevärt mycket extra tid att överföra upphämtningarna manuellt och det är mer sårbart för små mänskliga fel (Rooijmans, 2003). Dessutom är den extra investeringen i arbetstimmar redan hög; ett manuellt upphämtningssystem sätter ännu mer press på personalen.
Utvärdering / Praktisk relevans
Det finns flera lärdomar som kan dras från fallstudier: Nevada DMV-systemfallet, beskrivet av Lee (2004), lär sig att en implementering av en ny process också kan ha en politisk implikation. När det system som ska förändras påverkar allmänheten och det inte bara är ett internt system som förändras, finns det ytterligare några påtryckningar som påverkar organisationen. I det här fallet kan begrepp som företagsimage och rykte förändras drastiskt om kunderna utsätts för fler förseningar i exempelvis kommunikation eller beställning av varor. Det föreslås att om systemet är politiskt känsligt bör man ägna mer uppmärksamhet åt konverteringsmetoden och helst välja parallell adoption, eftersom risken är mindre. En serie lärdomar från ett antal faktiska fallscenarier som implementerar ett nytt portföljsystem, utförda av ett företagskonsultföretag (Venture, 2004) visar några intressanta lärdomar från fältet. de verkar passa perfekt med de frågor som nämns för en generisk parallell adoptionsprocess, baserad på en kombination av vetenskapligt arbete. För att sammanfatta:
- Riskbedömning och beredskapsplanering (lösningar) är mycket viktigt
- Tilldela roller i projektgruppen
- Konstruera specifika milstolpar (som PRINCE2 ) som inkluderar utbildnings- och testplaner
- Identifiera potentiella risker och verkställ din beredskapsplan vid behov
- Kommunicera projektstatus
- Ändringar bör godkännas på lämpligt sätt
- Konverteringsstrategin måste noggrant undersöka datakraven
- Nya och ändrade data bör testas mot valideringsregler
- Skapa en grundlig återställningsplan
- När det är möjligt, förhandla fram en pilotkonvertering
Det finns också minst två svårigheter med parallell konvertering som kan göra användningen opraktisk på 2000-talet, även om det var en häftklammer i branschpraxis när indata bestod av kortlekar med hålkort eller rullar med tejp. Dessa är:
1. Det är opraktiskt att förvänta sig att slutanvändare, oavsett om det är kunder, produktionslinjearbetare eller nästan vem som helst, ska gå in i varje transaktion två gånger via olika gränssnitt.
2. Tidsskillnader mellan två interaktiva fleranvändarsystem kan ge olika resultat även när båda systemen fungerar korrekt, är internt konsekventa och kan användas framgångsrikt av sig själva.
Som ett resultat är parallellkonvertering begränsad till ett fåtal specifika situationer idag, såsom redovisningssystem där absolut verifierbarhet av resultat är obligatoriskt, där användarna alla är interna i organisationen och förstår detta krav, och där aktivitetsordningen inte kan tillåtas påverka utgången. I praktiken är pilot- och stegvis omvandlingsmetoder mer relevanta idag.
Se även
- Adoption av produktprogramvara: Big Bang Adoption
- Etappadoption
- Adoption (programvaruimplementering)
- Regatta: adoptionsmetod
- Förändringsledning
- Tillförlitlighetsteknik
- Återställning (datahantering)
- Riskhantering
- Mjukvaruutveckling
- Genomförande
Artiklar
- Andersson I. Hanson, K. (2003). Teknikspridning i en mjukvaruorganisation, Licentiatuppsats i tillämpad informationsteknologi, Göteborgs universitet
- Brown, CV & Vessey, I. (1999). ERP Implementation Approaches: Toward a Contingency Framework, Proceedings of the 20th International Conference on Information Systems , Charlotte, NC, 13–15 december, 411-416.
- Chng, S., & Vathanophas V. (2002). Mot ett interorganisatoriskt företagssystem: en fokusgruppsstudie. Den sjätte Pacific Asia-konferensen om informationssystem (PACIS 2002). Tokyo, Japan. 2–4 september 2002.
- Lee, O. (2004). En fallstudie av Nevada DMV-system, Journal of the Academy of Business and Economics, volym 3
- Ribbers, P. & Schoo, KC (2002). Designing Complex Software Implementation Programs, 35:e årliga Hawaii International Conference on System Sciences (HICSS'02), volym 8
- Yusuf, Y. & Gunasekaran, A. & Abthorpe MS (2004). Implementering av projekt för företagssystem: En fallstudie av ERP i Rolls-Royce. International Journal of Production Economics , 87, 251-266.
Böcker
- Daft, RL (1998). Organisationsteori och design. Väst: International Thomson
- Eason, K. (1988). "Kapitel 9, Implementering och stöd," i: Informationsteknologi och organisationsförändring. London: Taylor & Francis
- Turban, E. & Mclean, E. & Wetherbe J. (2002) "Kapitel 14, Att bygga informationssystem", i: Informationsteknologi för ledning. New York: John Wiley & Sons, inc
- Rooimans, R., Theye, M. de, & Koop, R. (2003). Regatta: ICT-implementations är en utmaning för en fyra-met-stuurman. Haag: Ten Hagen en Stam Uitgevers.
externa länkar
- Replatforming Branschapplikationer från UNIX till Windows. (2004), version 1.0 Microsoft , Hämtad 5 mars 2006 [1]
- Implementering av ett portföljredovisningssystem: Lessons from the trenches (2004), Venture Financial Systems Group Ltd , Hämtad 6 mars 2006 [2]