Big bang adoption

Big bang adoption eller direkt övergång är när ett nytt system antas omedelbart, utan någon övergångsperiod mellan det gamla och det nya systemet.

När ett nytt system behöver implementeras i en organisation finns det tre olika sätt att adoptera detta nya system: big bang-adoption, etappadoption och parallell adoption . Vid parallell adoption körs det gamla och det nya systemet parallellt, så att alla användare kan vänja sig vid det nya systemet och under tiden göra sitt arbete med det gamla systemet. Fasad adoption innebär att adoptionen kommer att ske i flera faser, så efter varje fas är systemet lite närmare att bli fullt adopterat. Med big bang-antagandet sker växlingen mellan att använda det gamla systemet och att använda det nya systemet vid ett enda datum, den så kallade omedelbara övergången av systemet. Alla börjar använda det nya systemet vid samma datum och det gamla systemet kommer inte att användas längre från det ögonblicket.

Fördelen med ett big bang-antagande är att det nya systemet inte behöver vara kompatibelt eller kopplat till några gamla system som det ersätter. Detta förenklar designen av det nya systemet avsevärt, särskilt i en organisation som körs på flera inkompatibla system. Big bang-adoptionstypen är dock mer riskfylld än andra adoptionstyper eftersom det finns färre inlärningsmöjligheter som ingår i tillvägagångssättet, så det krävs mer förberedelser för att komma till big bang. Denna förberedelse kommer att beskrivas nedan, illustrerad av processdatamodellen för big bang-antagandet.

Genomförande

När ledningen har bestämt sig för att använda big bang-metoden, och stödjer de förändringar som behövs för detta, kan den verkliga förändringsprocessen starta. Denna process består av flera steg: konvertera systemet, släppa delar av systemet och utbilda framtida användare .

Aktiviteterna i processen förklaras i tabellen nedan, för att klargöra dem. Begreppen som används för att utföra aktiviteterna är i versaler.

Aktivitet	Subaktivitet	Beskrivning
Förbered förvaltningen (se Adoption)	Bestäm organisatoriska förändringar	Processen att fastställa vilka förändringar som måste ske för att möjliggöra big bang som resulterar i en rapport om organisatoriska förändringar
	Kom överens om organisationsförändringar	För att kunna införa big bang måste det finnas enighet om förändringsplanen som resulterar i ett avtalskontrakt. Om det inte finns någon överenskommelse krävs nya avtalsmöten eller så måste ändringarna bestämmas olika gång på gång, tills ett avtalskontrakt skapas.
Konvertera systemet	Gör planering för framtida användare	Skapa en plan för de personer som kommer att behöva hantera det nya systemet, så att de har en överblick över de händelser som kommer att hända
	Konvertera data från gamla system	Konvertera data från det gamla systemet så att det kan användas i det nya systemet (Koop, Rooimans och de Theye, 2003)
	Ladda data till nytt system	Ladda data de konverterade data till det nya systemet
	Testa data i nytt system	Testa data så att det blir känt om data kommer att kunna användas i det nya systemet
	Utför testversioner offline	Utför en testversion med systemet och med användarna av systemet för att kontrollera om systemet kommer att fungera korrekt
	Markera för att verifiera giltigheten	Kontrollerar giltigheten så att systemet kan göras redo att släppas (Koop, Rooimans och de Theye, 2003)
Lossa delar	Släpp konverterad databas	Släpp den nya databasen som konverteras från den gamla databasen
	Släpp framställd applikation	Släpp applikationen som är framtagen för personalen
	Släpp infrastruktur	Släpp den nya infrastrukturen
Förbered användare	Upprätthåll buffert av erfaren personal	Skapa en buffert av personal som kan ta över arbetsuppgifterna för de personer som ska utbildas i att använda det nya systemet, så att det dagliga arbetet kan fortsätta
	Utbilda användare	Utbilda användare inför den stora releasen av systemet för att skapa en lista över utbildade användare

Konvertera systemet

Till en början behövs en plan för hela adoptionsprocessen. Planen låter framtida användare veta vad som kommer att hända och när de bör förvänta sig vissa förändringar, vilket undviker onödiga osäkerheter och skapar därför en bättre arbetsmiljö. Planen klargör också när den verkliga adoptionen sker och ger de framtida användarna möjlighet att förbereda sig för denna förändring. Modellen nedan visar att aktiviteterna (i den grå rutan) leder till utfall (i rutorna bredvid den grå rutan) för att kunna få ett delutfall: det konverterade systemet

När planen är gjord och alla vet vad som förväntas av dem kan den tekniska omställningen börja. Först måste den gamla datan konverteras till en form som kan arbeta med datan i det nya systemet (Koop, Rooimans och de Theye, 2003). Sedan behöver denna data laddas in i det nya systemet, vilket resulterar i den så kallade laddade datan. Denna laddade data måste testas för att kontrollera effektiviteten hos datan och för att testa förståelsen för framtida användare. Off-line försök måste utföras för att kontrollera om systemet och användarna kan arbeta tillsammans. Inte bara effektiviteten och förståelsen måste testas, utan validiteten måste testas för att göra datavalideringsnivån tydlig . Om uppgifterna inte är giltiga måste ledningen fastställa förändringarna igen och organisationen måste förbereda ett annat sätt att genomföra Big bang-antagandet.

Släpp delar av systemet

Om all data är giltig kan separata delar av systemet släppas . Databasen som konverteras från den gamla databasen måste släppas, så den nya informationen är tillgänglig . Därefter måste den producerade applikationen släppas, så den nya applikationen kan också användas. Infrastrukturen för hela det nya systemet behöver också släppas, så att det är tydligt hur systemet kommer att se ut och hur allt hänger ihop (Koop, Rooimans och de Theye, 2003) . I denna fas släpps endast separata delar, som inte utgör det nya systemet ännu, utan bara delar av det. Allt detta händer offline: bara systemutvecklarna ser detta, medan användarna fortfarande arbetar med det gamla systemet. Modellen ovan visar vilka aktiviteter som behöver utföras (i den grå rutan) av systemkontrollern, för att få de utfall som leder till de släppta delarna. Om frisläppandet av delarna misslyckades måste ledningen fastställa nya ändringar igen (Se Adoption ; Förbered en organisation för antagande).

Träna organisationen i att använda systemet

Om frisläppandet av de separata delarna lyckades blir nästa steg att förbereda användarna. För att kunna introducera hela det nya systemet, dvs att adoptera det, behöver alla användare utbildas i att arbeta med det nya systemet. Utan stora konsekvenser för produktionsnivån i en organisation är det bara att utbilda alla om det finns en buffert av erfaren personal som kan ta över det dagliga arbetet för de användare som behöver tränas. Det innebär att för alla som behöver utbildas kommer det att finnas personal tillgänglig som kan ta över arbetet, så att det inte blir några enorma förseningar i arbetet. Personalavdelningen kommer att skapa bufferten av erfaren personal (aktivitet i den grå rutan) genom att bjuda in sökande till bufferten. Sedan kan användarna utbildas och de utbildade användarna kan listas, så att en användarförberedande rapport kan skrivas.

Dålig träning kan få dåliga resultat för en organisation, vilket FoxMeyer-fallet illustrerar (Scott, Vessey, 2000). Detta företag använde big bang-metoden för att implementera ett ERP-system ( Enterprise Resource Planning) . Fel utbildning gavs, antagandet gjordes att användarna redan visste tillräckligt om det och att fel färdigheter lärdes ut. Dow Corning hade också stora problem med att skaffa de nödvändiga färdigheterna under deras big bang ERP-implementering (Scott, Vessey, 2000). Att använda ett nytt system kräver olika färdigheter och kunskaper, som i flera fall tycks underskattas av dem som sköter omställningen.

Tekniker

Det finns flera tekniker för att implementera ett nytt system. Antagandefasen är bara en fas av hela genomförandet. Regatta (Koop, Rooimans och de Theye, 2003) är till exempel en metod som är utvecklad för att implementera system. Denna metod, utvecklad av Sogeti, behandlar en omställning som ett projekt och fokuserar flera stadier av detta projekt, till exempel förberedelsefasen av en adoption och på acceptansen av en implementeringsmetod. SAP Implementation är en annan teknik specialiserad på att implementera och anta SAP AG -mjukvara, som är uppdelad i flera tekniker.

Risker

På grund av den omedelbara omställningen måste allt ske i ett fast tidsschema. Detta är en riskabel operation. Organisationen kanske inte är redo för detta ännu, en felaktig datauppsättning kan användas eller informationssystemet kan fastna på grund av bristande erfarenhet och startproblem. Också en oförmögen reservmetod kan vara en risk vid implementering av ett system som använder Big Bang (Koop, Rooimans och de Theye, 2003).

Storbritanniens aktiemarknad, 1980-talet

Londonbörsen 1986 stängde på fredagskvällen och alla datorer slogs på följande måndagsmorgon. Det har påståtts att detta orsakade stora förluster. ^{[ citat behövs ]}

Dow Corning

Dow Corning använde tidigare system som var fokuserade på specifika avdelningar. Ledningen beslutade att de ville bli ett verkligt globalt företag, som bara skulle använda ett informationssystem: ett Enterprise Resource Planning (ERP)-system. För att införa detta nya affärssystem använde de sig av typen big bang adoption och de lade ner mycket tid och ansträngning på att ompröva dess affärsprocesser. Företaget var förberett för antagandet och genomförde först tre pilotimplementeringar innan det nya systemet användes i hela den globala organisationen.(Scott, Vessy, 2000)

Dow Corning övervakade hela tiden framstegen och tog beslut för att säkerställa att deadlines skulle hållas. Detta var endast möjligt med feedback och bra kommunikation.(Scott, Vessey, 2000)

En annan riskabel strategi är att bara fokusera på resultatet, inte på hur man uppnår detta resultat och att underskatta inlärningsprocessen för användarna. Det är mycket svårt att planera inlärning eller kunskap, även om dessa är nödvändiga för att kunna genomföra big bang-omställningen.

FoxMeyer

FoxMeyer antog ett affärssystem med ambitiös mjukvara för lagerautomation och använde big bang-antagandet för att få konkurrensfördelar. Men FoxMeyer verkade ha en överoptimistisk ledning med orealistiska förväntningar: förändringen var för stor och för drastisk. Detta resulterade i ett mycket högt arbetstryck för att klara deadlines för alla anställda. Så orealistiska förväntningar på ledningen är också en risk (Scott, Vessy, 2000).

FoxMeyer misslyckades med att ha kommunikation och uppmärksamhet som var nödvändig för att kunna ge snabb och effektiv feedback. De försökte istället minimera problemen genom att ignorera dem, och gav avskräckande kritik, vilket resulterade i tvetydig feedback. Detta hindrade organisatoriskt lärande , något som är mycket viktigt under en organisationsförändring. Så dålig kommunikation och tvetydig feedback är också risker när man tar i bruk ett system med big bang (Scott, Vessey, 2000).

Se även

Eason, K. (1988) Informationsteknologi och organisatorisk förändring , Taylor & Francis.
Koop, R., Rooimans R. och de Theye, M. (2003) Regatta: ICT-implementaties als utmaning för een vier-met-stuurman , SDU Uitgeverij. ISBN 90-440-0575-8 .
Scott, JE, Vessey, I. (2000) "Implementing enterprise resource planning systems: the role of learning from failure", Information systems frontiers , vol.2(2), s. 213–232.