1. Innføring av system

Transkript

1 Greta Hjertø Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314D Prosjektrettet systemarbeid 1. Resymé: : I denne leksjonen skal vi ta for oss den siste av fasene i prosjektet vårt innføring av systemet. Vi ser nærmere på hva som skal gjøres i denne fasen og diskuterer viktige forutsetninger for å lykkes. Dette er en meget viktig fase for å sikre at systemet blir vellykket for brukerne. Den må derfor planlegges godt, og ikke avglemmes som noe som faller utenfor det egentlige prosjektarbeidet Innledning I dette faget følger vi tidligere et systemutviklingsprosjekt gjennom fire hovedfaser, se figur: Forstudium Analyse Innføre Utform og realiser I denne leksjonen har vi kommet til den siste fasen Innføring. Denne leksjonen handler både om de aktivitetene som foregår i den siste fasen, og det vi gjør tidligere for å få et godt grunnlag for en vellykket innføring. Det vil si de aktivitetene som er knyttet til innføringen, men som må gjennomføres i de tre tidligere fasene. For å forstå bedre hvorfor alle disse aktivitetene er viktige, starter vi leksjonen med å beskrive forutsetninger for å lykkes med innføring. Vi ser deretter på de hovedaktivitetene som vi må planlegge med og gjennomføre for å sikre at forutsetningene oppfylles Referanser Innholdet i denne leksjonen bygger på et internkurs i prosjektledelse holdt for Statoils ITavdeling gjennom en årrekke og hvor forfatter av leksjonen har vært en av kursholderne Forutsetninger for å lykkes med innføring Hensikten med systeminnføring er å sette det nye systemet i daglig drift på en slik måte at: 1. Brukerne kan systemet 2. Brukerne stoler på systemet 3. Brukerne har nytte av systemet.

2 Hvis vi oppnår det, kan vi regne med at våre brukere opplever at de har fått et kvalitetssystem det systemet de har behov for og som de har stilt krav til. Forberedelsene til dette har foregått gjennom hele prosjektløpet. Først og fremst ved at vi systematisk har sørget for å utvikle et system som er i samsvar med brukerkravene. Men i tillegg ved å ivareta en rekke andre viktige forhold som: informasjon, opplæring, tilrettelegging av organisasjonen etc. Med dette utgangspunktet går vi nå inn i prosjektets siste fase som vi kaller Innføring. I denne fasen, som er svært hektisk skal vi sørge for at alt det nye som: arbeidsrutiner og roller i organisasjonen, programmer, utstyr osv. som skal innføres, begynne å virke sammen og kan erstatte det gamle Liste over forutsetninger For at brukerne skal oppleve en situasjon som vi har beskrevet over, er det en rekke forutsetninger som må være oppfylt. Nedenfor følger en liste over de viktigste: 1. Selve overgangen fra gammelt til nytt system må foregå på en kontrollert og strukturert måte slik at ting skjer som annonsert og brukerne ikke opplever uforutsette problemer og rot og kaos. 2. Systemet må være fritt for alvorlige feil og frekvensen av mindre alvorlig feil må være så lav at brukerne opplever at systemet er stabilt. 3. Prosjektet må ha utviklet rett system, dvs. at de funksjoner, de data og de egenskaper som er bygd inn i systemet må være i samsvar med brukernes virkelige behov og krav til systemet. 4. Det må være samsvar mellom de arbeidsprosessene som systemet skal støtte og systemet. Det betyr at eventuelle endringer i arbeidsprosessene må være spesifisert og innført sammen med systemet. 5. Roller og ansvar i organisasjonen i tilknytning til arbeidsprosesser og system må være definert og gjort kjent for alle som kommer i berøring med systemet. 6. Brukerne må være motiverte for å ta i bruk et nytt system. 7. Brukerne må beherske systemet og forstå virkemåten til systemets funksjoner. Det er grunnlaget for at systemet kan bli brukt på riktig måte. 8. Forvaltningsapparatet må være på plass. Det betyr at det må være utpekt en systemansvarlig som har ansvar for å rette feil i systemet og en driftsansvarlig som har ansvar for alle driftsrutiner. Disse må ha tilstrekkelig kompetanse og i den første hektiske perioden må de normalt være tilgjengelige på kort varsel og ut over normal arbeidstid. 9. Støtteapparatet må være på plass. Det kan for eksempel bety at det er utpekt superbrukere i organisasjonen som sitter nær brukerne og kan bistå hver enkelt. Hvis organisasjonen har en sk. help-desk må de som sitter der vite at systemet er innført og ha kompetanse til å svare på spørsmål knyttet til systemet eller vite hvem som er rette vedkommende for å svare på slike spørsmål. 10. Data som er overført fra gamle systemer må være kontrollert og renset slik at de er korrekte, komplette og konsistente. side 2 av 16

3 11. Systemet må introduseres i organisasjonen til rett tid, dvs. at systeminnføring ikke kommer samtidig med spesielt hektiske perioder i organisasjonen, f.eks. bør vi unngå å innføre et nytt system samtidig med årsoppgjør eller månedsavslutninger. 12. Det må være utarbeidet og lagt på plass tilstrekkelige back-up rutiner, f.eks. i form av parallellkjøring mellom gammelt og nytt system slik at det ikke oppstår alvorlige problemer om det på grunn av feil i det nye systemet er nødvendig å trekke det tilbake for en periode. 13. Alt nødvendig nytt utstyr og all nødvendig programvare i forbindelse med nytt system må være anskaffet og på plass i organisasjonen, det gjelder f.eks. nye PC-er, printere, servere etc. og det gjelder programvare som skal fungere sammen med det nye systemet. 14. Kostnadsbildet for det nye systemet må være kjent slik at brukerne kan planlegge fornuftig bruk av systemet (f.eks. i forhold til uttak av rapporter) og ikke opplever ubehagelige overraskelser når de første regningene kommer Systemutviklerens rolle Mange systemutviklere som ser denne lista vil sikkert protestere på en del av punktene: Dette er da forhold som gjelder interne ting hos oppdragsgiveren. Vi kan da ikke blande oss borti oppdragsgiverens organisasjon!? Det er en naturlig tanke. Problemet er imidlertid at med mindre noen sørger for å ivareta disse forholdene vil det sterkt gå ut over den måten brukerne opplever systemet på. Sannheten er at vi kan utvikle verdens beste system, men hvis ikke noen samtidig sørger for at forutsetningene over er oppfylte, vi brukerne oppleve at det er systemet det er noe galt med. Som systemutviklere og prosjektledere for systemutviklingsprosjekter må vi derfor sørge for at alt som står på denne lista blir ivaretatt. Hvis noe av dette svikter, blir det vårt system som får skylda, for å si det enkelt. Det er rimelig å tro at vi vet mye mer om hva det vil si å gjennomføre et systemutviklingsprosjekt enn oppdragsgiveren. Selv om prosjektet ikke skal gjøre alle oppgavene i forbindelse med innføring selv, mi vi derfor allikevel være rådgiver for oppdragsgvier. Dette innebærer å: - Utrede alternativer - Informere - Påpeke konsekvenser. Det er vanlig at systemutviklingsprosjekter organiseres med flere representanter for brukerne i prosjektgruppen og at en av disse har en rolle som brukernes prosjektleder. Hvis det er slik er det naturlig at vedkommende får ansvar for å sørge at alle nødvendige forberedelser til å ta systemet i bruk blir gjennomført. Han må nå fungere som et nødvendig bindeledd mellom prosjektet og organisasjonen i denne viktige fasen før systemet skal bli tatt i bruk. Det er imidlertid helt nødvendig at prosjektet: - i sine planer tar med nødvendige aktiviteter i oppdragsgiverens organisasjon, tidfester dem i forhold til prosjektet, påpeker ressursbehov og er pådriver for å få utpekt ansvarlige - i sin oppfølging sjekker at også disse aktivitetene gjennomføres som planlagt og at resultatet holder mål - om nødvendig støtter i gjennomføringen. side 3 av 16

4 1.3. Hovedoppgavene i forbindelse med systeminnføring Innføringsaktivitetene kan vi som tidligere nevnt dele i to kategorier. Noen få gjennomføres i sin helhet i prosjektets siste og hektiske fase innføringsfasen, men de fleste av dem starter arbeidet allerede tidlig i prosjektløpet. I figuren under har vi vist en prosjektløp med de fire hovedfasene som vi har behandlet i dette faget. Parallelt med hovedfasene har vi tegnet inn de hovedaktivitetene som er knyttet til systeminnføring. 1. Informasjonsvirksomhet 2. Planlegging av innføringsfasen 3. Brukeropplæring 4. Tilpasning av arbeidsrutiner og organisasjon 5. Veien til produksjon overføring til driftsmiljø 6. Utvikling av permanent dokumentasjon 7. Etablering av forvaltningsapparat og støtteapparat 8. Datakonvertering og installasjon 9. Akseptanse av system Utform Forstudium Analyse Innføre og realiser 1. Innformasjonsvirksomhet 2. Planlegging av innføringsfasen 4. Arbeidsrutiner og org. endringer 5. Veien til produksjon 3. Brukeropplæring 6. Utvikling av permanent dokumentasjon 7. Etablering av støtteapparat 8. Datakonvertering og installasjon 9. Akseptanse Nedenfor følger en nærmere beskrivelse av hovedaktivitetene Informasjonsvirksomhet Prosjektet må legge vekt på å gi regelmessig informasjon, målrettet informasjon og tjenelig informasjon gjennom hele prosjektløpet. Dette kan ikke sies ofte nok! I Leksjon Prinsipper for prosjektarbeid har vi gitt en generell introduksjon til hvordan informasjonsvirksomheten kan planlegges og gjennomføres. Les dette en gang til! I et systemutviklingsprosjekt må vi minimum planlegge med følgende tiltak: - Informasjon til hele brukerorganisasjonen når et prosjekt starter. Må dekke hvorfor prosjektet er startet, hva en venter å oppnå og hva som skal skje. side 4 av 16

5 - Målrettet informasjon til alle som vil bli direkte berørt av prosjektet, hva prosjektet forventer av dem, og når de vil bli involvert, og når de vil få vite mer. - Et innledende kapittel i dokumentasjonen etter hver fase i prosjektet som forteller om systemet (etterhvert som det utvikler seg) på en lettfattelig måte og gir en oversikt over prosjektet og resultatet så langt. - Informasjon til brukerorganisasjonen om status i prosjektet. Dette må skje med jevne mellomrom, og minst hver gang en har tatt en overordnet beslutning i prosjektet. - Informasjon i god tid før systemet skal innføres i organisasjonen om hva som kommer til å skje og hvordan den enkelte vil bli berørt Planlegging av innføringsfasen Selve innføringsfasen er meget hektisk. Mye skal gjøres og det er viktig at det skjer over kortest mulig tid fordi innføringsaktivitetene virker inn på arbeidssituasjonen til mange mennesker som ikke er en del av selve prosjektgruppen og fordi de kan ha konsekvenser for andre systemer som er i drift. Det er derfor viktig at vi planlegger denne fasen nøye. En vanlig måte å gjøre det på er: Det utarbeides en innføringsstrategi tidlig i analysefasen(e). Strategien skal godkjennes i brukerorganisasjonen og tar stilling til overordnede spørsmål som: - Rekkefølgen på delsystemer som skal innføres - Rekkefølgen på innføring i forskjellige deler av organisasjonen - Nødvendig samordning med andre hendelser, som f.eks. omorganisering, innflytting i nye lokaler, spesielt hektiske perioder som må unngås, etc. - Mulighet for å ha systemet på prøve - Opplæringsbehov - Behov for spesiell assistanse - Parallelkjøring og andre overgangsordninger Det utarbeides en plan for innføring tidlig i utformings- og realiseringsfasen. Planen bygger på den strategien som ble utarbeidet tidligere, men nå legges det vekt på å få en detaljert og realistisk plan for alle aktiviteter. Denne planen vil bli revidert etterhvert som fasen for innføring nærmer seg, men den må likevel få en grundig behandling nå. Planen omfatter: - Akseptansetest. Denne planen inneholder: Strategi, hvordan skal testen foregå, ansvarsforhold, viktige/overordnede godkjenningskriterier, prosedyrer for hva som skal skje i tilfelle testen ikke blir godkjent - Innstallasjonsplan. Legg vekt på at planen skal være tilstrekkelig spesifik i forhold til systemets arkitektur: definisjon av alle installasjonsaktiviteter, rekkefølgen på aktivitetene, synkronisering av installasjonaktiviteter med andre hendelser - Brukeropplæring og informasjon. Planen skal inneholde: ansvarsforhold som gjelder brukeropplæring, oversikt over opplæringsmateriell og brukerdokumentasjon som skal lages, oversikt over personell, roller eller arbeidsoppgaver i brukerorganisasjonen som vil trenge varierende nivå av opplæring, spesifikasjon av alle nødvendige kurs eller informasjonsopplegg, med antatte kostander, tidsplaner, avhengigheter til andre hendelser side 5 av 16

6 - Databasekonvertering og initialisering. Hvis systemet har behov for nye databaser eller nye dataelementer i eksisterende databaser må det spesifiseres hvordan disse skal initialiseres. I noen tilfeller kan initialisering (lasting) skje automatisk ved normal bruk av systemets inndatatransaksjoner, vanligvis må data konverteres og overføres fra eksterne kilder til det nye systemet. Planen må inneholde en definisjon av alle slike aktiviteter med ansvarlig, tidspunkt etc. Det utarbeides en endelig plan for innføring ved slutten av fase Utforming og realisering. Denne planen bygger på tidligere planer og endres etter behov. I tillegg skal nå alle reelle datoer og navn på alle som skal delta på en eller annen måte føres inn i planen. Planen gjøres deretter kjent og må godkjennes av alle som er involvert Bukeropplæring Opplæring av brukere skal gjennomføres i henhold til innføringsplanene. Se foran. For å lykkes med brukeropplæring er følgende forhold svært viktige: - Det må være gjort en analyse av de forskjellige brukergruppene og hvilket opplæringsbehov de har, dette er grunnlaget for alle videre forberedelser av opplæring. Det er som oftest fornuftig å planlegge med at noen superbrukere kan få grundig opplæring slik at de kan støtte de andre i den første tiden. Da kan andre brukere klare seg med en introduksjon. - Det utarbeides opplæringsmateriell og annen dokumentasjon som er tilpasset målgruppen. Vurder bruk av eksperter i dette arbeidet. - Kursopplegget må være realistisk i forhold til brukernes arbeidssituasjon og den enkelte må gis mulighet til å delta uten at dette går for mye ut over arbeidet. Se forøvrig kommentar om superbrukere over. Dette er en god ide, da er lite realistisk å satse på at alle brukerne vil bli gitt anledning til å delta på langvarige kurs. Det er og fornuftig med å planlegge med opplæring i flere trinn. - Opplæringen må et ha tilstrekkelig element av egen prøving under veiledning. Kursholderne må også beherske den pedagogiske siden av opplæringen, dette er nesten viktigere enn at de er eksperter på innholdet. Brukeropplæring starter så snart det er mulig, men må i hovedsak vente til systemet er på plass i akseptansemiljøet, se kapitlet om veien til produksjon. I praksis betyr det at det meste av opplæringen må skje i selve innføringsfasen eller i etterkant av denne Tilpasning av arbeidsrutiner og organisasjon Det nye systemet vil aldri være en isolert enhet. For at det skal fungere må det integreres med arbeidsrutinene i den organisasjonen som skal ta det i bruk. Dette kan bety at det også må gjøres endringer i eksisterende arbeidsrutiner, i den måten bedriften er organisert på og i brukernes arbeidsoppgaver. Når bedriften har bestemt seg for at det er behov for ny programvare så har vi i prinsippet to mulige utgangspunkt: - Vi kan ha som mål å utvikle programvare som best mulig støtter dagens organisasjon og dagens arbeidsrutiner, for eksempel for behandling og kontroll av reiseregninger i personalavdelingen. - Vi kan ha som mål å utvikle programvaresystemer som best mulig effektiviserer organisasjonen gjennom å muliggjøre endring i organisasjon og arbeidsrutiner, for side 6 av 16

7 eksempel ved flytte behandling av reiseregninger fra personalavdelingen til de enkelte ansatte og fjerne kontrollene. Flere større bedrifter har gjort dette. Hvis utgangspunktet er å effektivisere organisasjonen kan det vi kan kalle organisasjonsutvikling, dvs. utforming av nye arbeidsrutiner, nye roller, nye måter å organisere bedriften på, komme til å bli en hovedsak i prosjektet. Hvis utgangspunktet er å støtte kan vi regne med at endringene i organisasjonen blir mindre omfattende. Uansett utgangspunkt må en som et minimum regne med at arbeidsrutinene må endres. Uansett omfanget på endringene er det viktig at vi hele tiden har aktiviteter knyttet til de organisasjonsmessige endringene med i planene og gjør arbeidet med dem til en integrert del av prosjektet. En vanlig utvikling er at vi i forstudiet klargjør omfanget på de organisasjonsmessige endringene, dvs. vi klargjør vår strategi for eventuell effektivisering av organisasjonen eller for best mulig støtte av dagens organisasjon og arbeidsrutiner. I analysefasen(e) arbeider vi først med system og arbeidsrutiner som en enhet. Dvs. at vi analyserer krav til det totale systemet. Deretter utvikler vi en modell som viser hvilke deler av totalsystemet som skal automatiseres og hvilke deler som vil være manuelt. Vi definerer og nødvendige endringer i roller og arbeidsoppgaver. Videre utvikler vi i denne fasen detaljerte spesifikasjoner av det systemet som skal utvikles, disse spesifikasjonene MÅ også omfatte spesifikasjoner av arbeidsrutinene, av roller og ansvar og av og andre organisasjonsendringer. I realiseringsfasen sørger vi for at alle endringer i ansvarsforhold blir realisert, dvs at vi sørger for å utpeke personer til de forskjellige (nye) rollen og gjøre disse kjent med de oppgavene de vil få tillagt. De nye arbeidsrutinene utformes nå i detalj og eventuelle nye organisasjonsenheter beskrives med oppgaver og bemanning. I innføringsfasen iverksettes alt det nye, dvs. det blir gjort gjeldende samtidig som systemet innføres. Opplæring i system og arbeidsrutiner går da hånd i hånd slik at dette fremstår som en enhet Veien til produksjon overføring til driftsmiljøet Når vi utvikler et nytt system må vi arbeide på en slik måte at vi ikke ødelegger for de systemene som allerede er i drift (i produksjon). Det fordrer at vi har et sk. Utviklingsmiljø som er isolert fra det sk. Driftsmiljøet. Etter at systemet er satt i drift (i produksjon) må vi på samme måte sørge for at vi kan rette feil i systemet uten at dette arbeidet påvirker driftsmiljøet. Vi må i tillegg bevare forskjellige versjoner av programvaren slik at vi kan gå tilbake til en tidligere (komplett og konsistent) versjon hvis det skjer noe galt med siste versjon, det kan for eksempel være at vi oppdager alvorlige feil ved de endringene og rettelsene vi har gjort. Dette krever at vi har et opplegg hvor vi: - har et fysisk skille mellom systemer som er i produksjon og systemer som er under utvikling - kan bevare og identifisere forskjellige versjoner av alle programmodulene - kan sette sammen riktige versjon av alle modulene til riktig versjon av systemet - kan styre overføring av en versjon av systemet fra det miljøet hvor det utvikles (utviklingsmiljøet) til det miljøet hvor systemet er i produksjon (driftsmiljøet) side 7 av 16

8 - kan rulle tilbake en versjon av systemet fra driftsmiljøet til utviklingsmiljøet ved alvorlige feil og rulle inn forrige versjon Utgangspunktet for å styre dette er de sk. TAP-prinsippene i kombinasjon med prosedyrer for versjonskontroll. Disse prinsippene krever at vi for alle systemer oppretter tre fysiske miljø, se figur: et utviklings- og testmiljø, et akseptansemiljø og et driftsmiljø. Utform Forstudium Analyse Innføre og realiser Forvaltning Spesifikasjon og utvikling Bruker opplæring Innstallasjon, Akseptanse Overføring, Systemtest. Utviklingsmiljø Akseptansemiljø Driftsmiljø drift Feilretting Vanlig fremgangsmåte i et prosjekt er da: I god tid før utviklingen starter (begynnelsen av analysen) etableres et utviklingsmiljø Utviklingsmiljøet inneholder all nødvendig basisprogramvare og utviklingsverktøy som prosjektet trenger. I dette miljøet: - utvikles alle modeller og spesifikasjoner av programvaren (analysefasen(e)) - utvikles programvarearkitekturen - utvikles alle databasespesifikasjoner - utvikles alle programmoduler - testes alle programmoduler - integreres programmodulene til et komplett system - rettes feil i systemer som er i drift I slutten av analysen bestilles et akseptansemiljø. Aksseptansemiljøet skal være mest mulig likt Driftsmiljøet, dvs. med samme basisprogramvare og infrastruktur ellers, satt opp på samme måte som i driftsmiljøet. Akseptansemiljøet er likevel skjermet fra daglig drift av andre systemer. Det vil være satt opp kriterier, dvs. kvalitetskrav til programvaren(driftsstabilitet etc.) for å kunne overføres til dette miljøet. Her foregår: - Systemtest, dvs. den samlede testen av hele systemet. Denne testen kalles av og til FAT (factory acceptanse test), dvs. systemutviklernes egen akseptansetest av det produktet de har utviklet - Stresstest, dvs. test av ytelse under ekstreme belastninger. - Test av programvaren mot de kriterier som gjelder for å kunne overføres til driftsmiljøet. Gjelder driftsstabilitet og forhold som kan påvirke andre systemer i drift. side 8 av 16

9 - Opplæring av brukerne I god tid før produksjonssetting etableres et driftsmiljø. Dvs. det miljøet hvor den daglige drift skal foregå. Miljøet må etableres med all nødvendig basisprogramvare og infrastruktur ellers, og med en kapasitet som spesifisert i prosjektet. For dette miljøet må det utarbeides detaljerte driftsprosedyrer og utpekes driftsansvarlige. Når systemet har bestått testene i akseptansemiljøet overføres det til driftsmiljøet. Overføringen til driftsmiljøet er det vi kaller installasjon. I driftsmiljøet foregår oppdragsgivers akseptansetest og daglig drift Utvikling av permanent dokumentasjon Sammen med det ferdige systemet må prosjektet levere dokumentasjon som gjør det mulig å bruke systemet og å holde systemet operativt. Vi kaller ofte denne dokumentasjonen den permanente dokumentasjonen (for å skille den fra annen dokumentasjon som vi utvikler for å dokumentere arbeidet underveis i prosjektet). Den deles i tre typer: - Brukerdokumentasjon, beregnet på å gi brukerne veiledning i bruk av systemet. - Forvaltningsdokumentasjon (av og til kalt systemdokumentasjon), beregnet på å gi støtte til forvaltning av systemet, dvs. feilretting og annet vedlikeholdsarbeid med systemet. - Driftsdokumentasjon, beregnet på å støtte til drift av systemet, dvs. til backup, overvåking, initiering av spesielle kjøringer etc. Arbeidet med dokumentasjonen skjer vanligvis på den måten at grunnlaget etableres parallelt med spesifikasjon og utvikling av systemet, selve ferdigstillelsen og godkjenningen av dokumentasjonen skjer parallelt med at systemet ferdigstilles og innføring av dokumentasjonen skjer parallelt med innføring av systemet. Dokumentasjonen er viktig i opplæring, både av brukerne og av de som skal ha ansvar for forvaltning og drift, og dokumentasjonen er avgjørende viktig for hvordan systemet fungerer i den kommende forvaltningsfasen. Det er bred enighet om hva som ideelt sett er god dokumentasjon. Likevel ser vi at dokumentasjonen av IT-systemene ofte er svært mangelfull. I en del tilfeller skyldes det tidspress i utviklingen og i andre at det ikke er avsatt tilstrekkelig ressurser til denne viktige oppgaven. Ofte klarer vi lenge å leve med dårlig dokumentasjon, men etterhvert som de folkene som deltok i utviklingen av programmene ikke lengere kan tre støttende til, vil problemene knyttet til mangelfull dokumentasjon bare bli større og større. Kostnadene ved dette er vanskelig å beregne, men viser seg som svært høye opplærings- og vedlikeholdskostnader og kostander ved driftsavbrudd. Systemer med dårlig dokumentasjon blir svært personavhengige. Vi skal her kort nevne det viktigste innholdet i dokumentasjonen. Brukerdokumentasjon Brukerdokumentasjonen bidrar til korrekt og konsistent bruk av systemet og sikrer den nødvendige datadisiplin. Dette krever at brukeren, i tillegg til å få veiledning i bruken, også kan forstå systemets virkemåte. Brukerdokumentasjonen må derfor inneholde en beskrivelse av systemet, behandlingsregler og sammenhengen med andre systemer. Brukerdokumentasjonen er i tillegg grunnlag for opplæring i bruk av systemet. Forslag til hovedkapitler: 1. Formål, bruksområde, ansvarlige side 9 av 16

10 2. Oppstilling over aktuelle lover, forskrifter, regler og retningslinjer for det området systemet omfatter. 3. Overordnet beskrivelse av systemet, herunder hensikten med systemet, dialogstrukturen, skjermbilde og rapportstruktur, på og avloggingsprosedyrer 4. Brukerrettet beskrivelse av systemet, eksempelvis: bruksområde, grensesnitt til andre systemer, skjermbilder med forklaring av datafelter og regler for utfylling, menyer og kommandoer, funksjoner og behandlingsregler, regler for retting av feilregistrerte data, feilmeldinger, manuelle kontroller og avstemmingsrutiner, manuelle rutiner, driftsmessige forhold av betydning for bruker, 5. Lagringsprosedyrer 6. Oversikt over rapporter 7. Rutiner for forvaltning (behandling av endringsønsker, feilrapporter, reklamasjoner) 8. Retningslinjer vedrørende sikkerhet 9. Ordliste Forvaltningsdokumentasjon En tilfredsstillende forvaltningsdokumentasjon er en forutsetning for å sikre de verdier som er lagt ned i utviklingen av systemet. Kvalitetsmessig, effektivt og risikofritt vedlikehold er avhengig av denne dokumentasjonen. Forslag til hovedkapitler: 1. Formål, bruksområde og ansvarlige 2. Oppstilling over aktuelle lover, forskrifter, regler og retningslinjer for det området systemet omfatter 3. Systembeskrivelse: grensesnitt mot andre systemer som angir hvilke data som mottas/leveres og på hvilket format, systemarkitektur, databasebeskrivelse, logisk og fysisk, datafeltbeskrivelse, referanse til data-dictionary, systemets funksjoner med angivelse av hensikt/bruksområde, inndata, behandlingsregler etc., adgangskontroller og autorisasjon 4. Sikkerhetskrav 5. Driftsmessige krav og ressurser 6. Systembenyttede standarder 7. Rutiner for systemforvaltning: rutiner for forvaltning, plan for testing, testdata, forventede testresultater, rutiner for oppdatering av dokumentasjon, rutiner for å informere, bibliotekrutiner 8. Begreper 9. Programdokumentasjon 10. Ordliste Driftsdokumentasjon Driftsdokumentasjonen er grunnlag for korrekt, kontinuerlig og tidsriktig drift av systemet. Operatørene får gjennom denne dokumentasjonen den nødvendige veiledning i å handle riktig side 10 av 16

11 ved meldinger fra systemet. Videre skal hensyn i forbindelse med sikkerhetskopiering ivaretas. Handlinger som bør utføres i forbindelse med katastrofer for å redusere skadevirkningene bør beskrives separat. Forslag til hovedkapitler: 1. Formål, bruksområde og ansvarlige 2. Ressurser, maskinvare, programvare, utstyr, kommunikasjon 3. Driftsrettet beskrivelser av systemet: avhengighet til andre systemer, oversikt over driftsoppdrag med tilhørende rapporter og avhengigheter mellom oppdrag, beskrivelse av driftsoppdrag med tilhørende rapporter og parametre, bestillingsrutiner for oppdrag, beskrivelse av driftsplanleggingssystem 4. Driftsrutiner: kjøreplan, prioritet ved driftsforstyrrelser, ressursforbruk, manuelle kontroller, konsollmeldinger og hvordan disse behandles, oversikt over driftsfeilmeldinger, rutiner i forbindelse med feilmeldinger, loggføring og behandling av logger, rutiner for sikkerhetskopiering, restart og recoveryrutiner, avbruddsrutiner 5. Rapporter 6. Oppfølging og driftsvedlikehold av systemet 7. Rutiner for forvaltning, behandling av endringsønsker, feilmeldinger og reklamasjoner 8. Begreper 9. Retningslinjer vedrørende sikkerhet 10. Ordliste Oppretting av forvaltnings- og støtteapparat, avtaler for drift og forvaltning Som forberedelse til innføring og daglig drift av systemet er det helt nødvendig at prosjektet sørger for at det utpekes ansvarlige personer til de oppgavene som skal holde systemet i problemfri daglig drift. Disse personene må utpekes så tidlig som mulig og senest før avslutning av analysefasene. Dette gjelder oppgaver i forbindelse med brukerstøtte, forvaltning, dvs. feilretting og andre oppgaver som er nødvendig for sikre at programvaren er uten feil og mangler og har avtalte brukeregenskaper og drift, dvs. alle oppgaver knyttet til drift av systemet, herunder sikkerhetskopiering, overvåking etc. Disse personene må få den nødvendige opplæring. Opplæring må være avsluttet i god tid før systemet settes i drift. Det ideelle er at de blir tatt med i prosjektgruppa og deltar i arbeidet. Videre må det utarbeides avtaler for brukerstøtte, drift og forvaltning og det må utarbeides rutiner for brukerstøtte, drift og forvaltning. Organisering av brukerstøtte, drift og forvaltning. En mulig måte å organisere dette på er å utpeke følgende ansvarlige. Legg merke til at det er ansvar som plasseres og ikke utførelse, ansvaret innebærer å sikre at nødvendig aktiviteter blir utført, mens selve utførelsen gjøres slik det er mest hensiktsmessig: Brukerfaglig ansvarlig. Her ligger det overordnede ansvar for den ytre, dvs. funksjonelle delen av systemet og arbeidsrutinene knyttet til systemet: - Påse at systemet har funksjoner som er i samsvar med brukerbehov - Definere kvalitetskrav til systemet og påse at disse oppfylles side 11 av 16

12 - Dokumentere kvalitetskrav og funksjonelle egenskaper - Påse at system, arbeidsrutiner og organisasjon passer sammen - Identifisere endringsbehov - Sørge for utprøving av og godkjenning av alle funksjonelle endringer - Planlegge med og sørge for finansiering til forvaltning og drift og påse at nødvendige avtaler tegnes - Sørge for nødvendig informasjon om og opplæring i systemet i brukerorganisasjonen - Påse at systemet inneholder nødvendige rutiner for å sikre data mot uautorisert tilgang Systemansvarlig. Her ligger det overordnede ansvaret for systemets indre, dvs. systemtekniske egenskaper. Ansvaret omfatter: - Påse at systemet realiserer de funksjoner og kvalitetskrav som er beskrevet - Lede videreutvikling på oppdrag fra brukerfaglig ansvarlig - Sørge for at systemet til en hver tid er godt testet og dokumentert. Sørge for at brukerfaglig ansvarlig får informasjon og opplæring i systemets mulige og eksisterende anvendelser - Ved anskaffelser ivareta bedriftens interesser overfor leverandører - Bistå brukerfaglig ansvarlig ved løsning av funksjonelle problemer - Beskrive konsekvenser ved endringer - Utarbeide driftsrutiner - Utarbeide leveranseavtaler med brukerne Driftsansvarlig. Dette er knyttet til daglig drift og omfatter daglig drift og overvåking i henhold til driftsavtale og å følge opp driftskvalitet slik at den samsvarer med avtalene Avtaler om forvaltning og drift Det er uhyre viktig at det i god tid før innføringsfasen er utarbeidet og godkjent avtaler om forvaltning og drift. Disse avtalene må som et minimum inneholde: Servicenivå. Mange bedrifter har spesifisert standard servicenivå i flere trinn. Brukerne må tidlig ta stilling til hvilket nivå som er tilstrekkelig for dette systemet. Hvis det ikke finnes slike standarder eller de ikke passer må systemutviklerne i samarbeid med brukerne komme frem til et passende servicenivå. Servicenivå omfatter forhold som: - Systemets prioritet og viktighet i brukerorganisasjonen - Oppetid for systemet - Systemvakt (tilgjengelig personale f.eks. i helger og kvelder eller i spesielt kritiske faser for brukerorganisasjonen) - Prosedyrer for kategorisering av feil - Max utrykningstid for forskjellige kategorier feil (hvor lang tid fra feil er varslet til ansvarlig starter arbeidet med å rette feil) - Max feilrettingstid for forskjellige kategorier feil. - Krav til sikkerhetskopiering og reetablering ved alvorlige feil side 12 av 16

13 - Krav til oppbevaring av data Videre må avtalen innheolde krav til opprettholdt kompetanse og bemanning med navngitte personer, kostander og belastning av kostnader og spesifikasjon av rutiner som skal følges Datakonvertering Datakonvertering vil si å overføre data fra gammelt system eller fra andre kilder inn i det nye systemet. For selve konverteringen kan vi ha utviklet egne innlesningsprosedyrer som kan overføre store mengde data fra fil, eller vi kan velge å bruke systemets egne inn-funksjoner for å legge inn data. Det første er nok mest vanlig. Datakonverteringen skjer i selve innføringsfasen, men forarbeidet har startet lenge før. Det starter allerede i diskusjon med brukerne om brukerkrav, da må eksisterende data som ønskes inn i nytt system være med i diskusjonen. Vi må deretter identifisere hvilke data dette gjelder og hvor de finnes Så følger en meget viktig jobb med å kontrollere kvaliteten på data og sette iverk prosedyrer for å rense data slik at de data vi overfører er korrekte, konsistente og komplette. Dette kan være en meget krevende oppgave. Mange gamle systemer har elendig datakvalitet! Som eksempel kan vi tenke oss at et leverandørregister som er dårlig vedlikeholdt kan ha mange leverandører som ikke lengere er aktuelle, kan ha feil informasjon om leverandørene, f.eks. feil adresse hvis de har flyttet, feil navn på kontaktperson etc., kan ha registrert samme leverandør flere ganger fordi noen har skrevet navnet feil osv. Hvis det skal være et poeng å ta med leverandørregistret inn i et nytt bestillingssystem, så bør altså slike feil fjernes, slik at vi bare tar med de leverandørene vi faktisk bruker, og da med korrekte opplysninger og selvfølgelig med bare en post pr. leverandør. Selve datakonverteringen i innføringsfasen blir sammenlignet med dette forarbeidet en enkel og lite arbeidskrevende jobb. Hvis vi støter på data med svært dårlig kvalitet må vi diskutere med brukerne om hvor viktig de er å få data med inn i nytt system og om det kan være et alternativ at data legges manuelt inn i systemet på nytt ved bruk av systemets skjermbilder Oppsummert - Selve innføringsfasen I selve innføringsfasen gjennomføres følgende aktiviteter: - Konvertering og installasjon (se kapittel og 1.3.5) - Brukeropplæring (se kapittel 1.3.3) - Brukers akseptansetest, se nedenfor Brukers akseptansetest Denne testen er grunnlaget for brukers godkjenning av systemet. Hvis testen viser at systemet oppfyller de kriteriene som er satt, så overtar brukerorganisasjonen systemet, altså leveransen fra prosjektet, og aksepterer at de har fått den varen som kontrakten spesifiserte. Denne testen kjøres vanligvis i driftsmiljøet, men kan også kjøres i akseptansemiljøet, dette må avtales på forhånd med både brukerorganisasjonen og med ansvarlig driftspersonell. Se kapittel 3.5 side 13 av 16

14 Testen kan kjøres rett etter installasjonen i aktuelt miljø eller en kan velge å vente en tid. Testen kan strekke seg over flere dager og den kan kjøres i flere omganger. Selve testen kjøres altså som oftest i sin helhet i innføringsfasen. Det finnes imidlertid eksempler på at deler av den kan kjøres i forlengelsen av innføringsfasen; f.eks. kan hele første måned i drift defineres som akseptanseperiode. Men uansett er grunnlaget også for denne aktiviteten lagt gjennom hele prosjektet ved: - Spesifikasjon av akseptansekriterier tidlig i prosjektløpet - Planer for akseptansetesten som utarbeides første gang i analysefasene og senere detaljeres og utfylles etterhvert som innføringsfasen nærmer seg. For selve testen er det viktig at planene er detaljerte nok. Se kapittel hvor vi har tatt med hovedpunktene i planen. Her utdypes disse: Strategi, hvordan skal testen foregå - Tidspunkt og varighet - Metode for gjennomføring - Testomfang, f.eks. simulering av en mnd. Regnskapskjøring - Prosedyre for dokumentasjon av feil - Prosedyre for innrapportering, oppretting og tilbakerapportering av feil Ansvarsforhold, hvem gjør hva: - Anskaffelse testdata - Oppbygging testdatabaser - Beskrivelse av hva som skal testes - Gjennomføring av testen - Gjennomgang og godkjenning av testresultat Viktige/overordnede godkjenningskriterier, f.eks.: - Ikke systemstopp i perioden - 90% av transaksjonene svartid bedre enn 3 sek. - Osv. Prosedyrer for hva som skal skje i tilfelle testen ikke blir godkjent og prosedyrer for hva som skal skje hvis testen må avbrytes. Dokumentasjon og oppfølging Alle testdata og alle resultater fra akseptansetesten skal dokumenteres og oppbevares. Testresultater omfatter ikke bare utdata for systemet, men også nødvendig informasjon for å verifisere systemets ytelse og korrekthet. Slik tilleggsinformasjon kan være: - Utskrift og analyse av systeminterne data, f.eks. innhold i databasen, kontrollsummer, mellomresultater - Tidsanalyse, kostnadsanalyse og andre mål for ytelse side 14 av 16

15 - Godkjenning fra bestemte personer på at spesielle deler at systemet fungere som det skal, dette gjelder de deler av systemet som ikke produserer utskrifter, f.eks. passordkontroll, hjelp-funksjoner etc. Alle avvik fra tidligere godkjente planer for akseptansetesten må nå: - Dokumenteres med vurdering av årsak til avviket og hvilken risiko og konsekvenser avviket medfører - Godkjennes skriftlig av oppdragsgivers kontaktperson Avvik kan være: - Sykluser, kjøringer eller testtilfeller som sløyfes - Gjentatte kjøringer eller tester - Inngrep fra programmerere eller andre tekniske spesialiser i løpet av eller mellom kjøringer - Resultater eller utskrifter som er forskjellig fra det som var ventet Hvis akseptansetesten inneholder parallell drift av gammelt og nytt system må resultatet inneholde en liste over alle uforutsette avvik mellom de to systemene. For hvert avvik må vi dokumentere: - En beskrivelse av avviket - En vurdering av årsaken og nødvendig oppfølging - En indikasjon på hvilket system brukerne valgte å stole på og handle ut fra - En vurdering av konsekvenser. side 15 av 16

16 1.5. Innhold 1.1. INNLEDNING Referanser FORUTSETNINGER FOR Å LYKKES MED INNFØRING Liste over forutsetninger Systemutviklerens rolle HOVEDOPPGAVENE I FORBINDELSE MED SYSTEMINNFØRING Informasjonsvirksomhet Planlegging av innføringsfasen Bukeropplæring Tilpasning av arbeidsrutiner og organisasjon Veien til produksjon overføring til driftsmiljøet Utvikling av permanent dokumentasjon Oppretting av forvaltnings- og støtteapparat, avtaler for drift og forvaltning Datakonvertering OPPSUMMERT - SELVE INNFØRINGSFASEN INNHOLD side 16 av 16