1 Projektstyrning
•
Har projektledaren agerat ”professionellt” i olika situationer som inträffat i projektet?•
Har projektets mål infriats?•
Hur har tidsplanen hållits? För lång tid? Förseningar? Realistisk tidsplan?•
Hur har kalkylerna utfallit?•
För hög kostnad? Fördyringar? Realistisk kalkyl?•
Var ansvars- och arbetsfördelningen i projektet riktig?2 Metodik
•
Har utvecklingsmodellen (VFS-modellen) styrt arbetet på effektivt sätt?•
Har rekommenderade arbetssteg i VFS-metoden underlättat utvecklings-jobbet?•
Har utnyttjade checklistor/dokument fungerat bra som kommunikations-hjälpmedel?•
Har använda checklistor/dokument gett ett gott underlag för val, anpass-ning, införande och efterstudie?•
Kunde vi ha situationsanpassat VFS-metoden bättre för projektarbetet?•
………3 Arbetsformer
•
Fungerade ISA-modellen som ett bra underlag för ansvars- och arbetsför-delning under utvecklingsarbetet?•
Hade användarna reella möjligheter att påverka och styra utvecklingsar-betet?•
Hade vi rätt användare med i projektet?•
Hade användarna tillräckligt med tid och hög motivation för att delta i projektet?•
Agerade ADB-avdelningen på ett riktigt sätt?•
Fick ledningen fatta de rätta besluten under projektets gång?•
………4 Leverantörsrollen
•
Förberedde vi oss på ett aktivt sätt inför kontakterna med systemleveran-törerna?•
Var systemleverantörerna lyhörda för våra behov?•
Hade leverantörerna tillräckliga kunskaper och erfarenheter om vårt verk-samhetsområde?•
Hur agerade leverantörerna vid demo/test, förhandling, avtalsskrivande och under införandet?•
Hur villig var leverantören att göra anpassningar i sitt standardsystem?Var dessa professionellt genomförda?
•
………5.8 Avveckling
Syfte
Ett standardsystem behöver avvecklas om det hämmar verksamheten, blivit föråld-rat eller är olönsamt. Avveckling innebär att vi tar systemet ur drift och därmed slu-tar att använda systemet i verksamheten. En avveckling brukar ofta kombineras med en ny utvecklingsomgång. Cirkeln är därmed sluten och vi startar ånyo med en förstudie.
Underlag
En efterstudie ger en första indikation på att ett standardsystem behöver avvecklas.
Som underlag för avvecklingen behöver vi befintlig dokumentation t.ex. användar-handböcker och driftsdokumentation för att kunna fasa ur systemet på ett korrekt sätt.
Genomförande
Avveckling av ett system måste göras både i användarnas verksamhet och i ADB-avdelningens driftsfunktion. Vi ska här behandla avveckling ur användarperspek-tiv. Avveckling ur ett driftstekniskt perspektiv behandlas i kapitel 6, se avsnitt 6.13.
Vi delar in arbetet med avveckling i följande arbetssteg:
1 Planering
Vi planerar här omfattning, tid och kostnad för en avveckling av standardsystemet.
Det är viktigt att noggrant tidsplanera en avveckling och eventuellt ”matcha” det med ett nytt system. Tänk på att ej helt avveckla det gamla systemet innan det nya systemet fungerar tillfredsställande. Vi kan behöva lägga upp ett speciellt avveck-lingssystem eller använda oss av reservrutiner under ett övergångsskede. Om vi är bundna av leverantörens avtal kanske vi måste vänta med att avveckla systemet tills gällande avtal löper ut.
2 Konsekvensanalys
Här studerar vi vilka konsekvenser en avveckling av standardsystemet får för verk-samheten. Vilka användare utnyttjar systemet och hur kommer deras behov av informationsstöd att påverkas? En systemavveckling kan också få konkurrens-, lönsamhets- och personalmässiga konsekvenser för företaget. Det är viktigt att ana-lysera vilka effekter ett borttaget standardsystem får på andra samverkande system.
Vad kommer istället: Ett nytt system eller återgång till manuella rutiner? Slutligen behöver vi studera hårdvarumässiga konsekvenser av en avveckling.
3 Skrotning
Ett beslut om avveckling leder till att vi måste ”skrota” det gamla systemet. Om vi har tur kan vi få intäkter via försäljning av standardsystemet. Eventuellt kan leve-rantören ha synpunkter på detta. Skrotning av systemet kan ske på olika sätt t.ex.
direkt avveckling, successiv avveckling eller parallellkörning med nytt system.
Befintlig dokumentation om systemet måste plockas bort från verksamheten.
Resultat
Resultatet blir ett avvecklat standardsystem som plockats bort från verksamheten.
Ett nytt utvecklingsarbete kan leda fram till att vi inför ett nytt system i verksamhe-ten (egenutvecklat eller standardsystem).
5.9 Att tänka på
Att utveckla en framtida verksamhet med nya standardsystem kräver både kreativi-tet hos projektdeltagarna och ett systematiskt arbetssätt. Vi vill här ge dig som står i begrepp att skaffa ett standardsystem till din organisation några råd:
•
Ta alltid utgångspunkt i en väl avvägd kravspecifikation som belyser verksam-hetens alla krav på ett nytt standardsystem.•
Leta efter utslagsgivande (”knock-out”) faktorer för att underlätta arbetet under valprocessen.•
Försök att ganska snabbt reducera antalet standardsystem till 2–4 finalister för en mer detaljerad bedömning.•
Satsa på standardsystem som har stora ”träffytor” mot verksamheten för att minska behovet av anpassningar.•
Jämför noggrant hur väl valt standardsystem uppfyller verksamhetens krav på funktioner, termer mm.•
Det är viktigt att du förbereder kontakterna med leverantörerna noga. Låt dig ej övertygas av säljsnack!•
Teckna alltid preliminäravtal efter valet och ett definitivt slutavtal i samband med anpassning.•
Glöm ej att satsa mycket resurser på förankring av det nya standardsystemet hos personalen.•
Gör regelbundna efterstudier för att kontrollera att standardsystemet ger ett effektivt stöd åt verksamheten.5.10 Checklistor och dokument
Vid arbete med standardsystem ur ett utvecklingsperspektiv behöver vi tillgång till olika former av dokumentation. Som utgångspunkt har vi vår verksamhet och ett antal standardsystem. Det är viktigt att studera hur dessa standardsystem stödjer verksamheten. Vi har då behov av följande dokumentation (se bilden nedan):
•
Verksamhetsbeskrivningarsom preciserar användarnas behov och krav.
•
Standardsystembeskrivningarsom preciserar möjligheter i leverantörernas standardsystem.
•
Jämförande beskrivningarsom ställer verksamhetens krav mot aktuella möjligheter i studerade standard-system.
Vi skall nedan ge förslag på konkreta checklistor och dokument för dessa tre beskrivningsformer. Främst koncentreras intresset på jämförande beskrivningar. Vi har tidigare omnämnt föreslagna checklistor/dokument under arbetsetapperna vid utveckling.
I Verksamhetsbeskrivning
En beskrivning av vårt verksamhetsområde för standardsystem äger rum under för-studien (se kapitel 4). En verksamhetsbeskrivning behövs som underlag för främst val, anpassning och efterstudie. Detta för att säkerställa att standardsystem ger ett fullgott stöd och bidrag till verksamheten. Ur ett utvecklingsperspektiv är vi intres-serade av följande checklistor/dokument: