Repetisjon om evaluering av It-systemer. Hvordan vurdere og verdsette?

Transkript

1 Repetisjon om evaluering av It-systemer Hvordan vurdere og verdsette?

2 Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme om Verdsette Vurdere, taksere, sette pris på Foreta en vurdering av systemet og nytten det har for brukerne. En systematisk innsamling av data som gir informasjon om nytteverdien systemet har for en spesiell bruker eller brukergrupper for å løse en arbeidsoppgave i en gitt situasjon.

3 Forutsetninger Brukerne vil ha systemer som er Lette å lære og å bruke Effektive til å løse arbeidsoppgavene Sikre slik at data ikke forsvinner eller stjeles systemet ikke feilfungerer eller stopper Nyttige for bruker og virksomhet Tilfredsstiller behovene i arbeidsdagen Ansvarlig for systemet setter opp kriterier eller forutsetninger som skal være oppfylt

4 Hvorfor evaluere? Foreta beslutning om kjøp eller integrasjon av programvare Overtar ansvar for utvikling, markedsføring og vedlikehold et produkt Utarbeide spesifikke krav i en utviklingskontrakt Foreta beslutning om ytterligere investeringer i programvare Programvaren holder ikke lenger definerte kvalitetsmål For å sikre produktkvalitet, kontrollere kostnader For å minimalisere forretningsrisiko Andre grunner

5 Hvorfor formelt evaluere IT systemer? Hvorfor ikke ta et system eller løsning man kjenner/kan? Det koster tid og penger la oss ta en leverandør vi allerede kjenner godt Vi vet allerede hva vi vil ha, eller har behov for det er ingen grunn til å kjøre noen omfattende prosess Ofte så avdekker prosessen: Oppfatninger av leverandører og deres løsninger endres Endring i oppfatninger av hva man egentlig skal ha

6 Hvorfor formelt evaluere innkjøp av IT systemer? Sikre en løsning som tilfredstiller virksomhetens spesifikke krav og behov Sikre en løsning i overensbestemmelse med virksomhetens ITstrategi i overensbestemmelse med virksomhetens system arkitektur Som kan fungere sammen med resten av bedriftens system portefølje Sikre fri konkurranse mellom leverandører(spesielt i offentlig sektor) Sikre kvalitet både av løsning og leverandør Sikre best mulig pris for hva du får

7 Hva skal vi evaluere? IT-systemer som brukes i virksomheter Grensesnitt Funksjonalitet Brukervennlighet Kost/Nytteverdi Personsikkerhet Informasjonssikkerhet Psykososialt miljø Brukskvalitet Andre egenskaper. Delene eller helheten

8 Evalueringstabell Lage en liste med kriterier Velg kriteriene på grunnlag av bruk og produkt Prioriter mellom kriteriene Verdsett vekt hvert kriterium Estimer en verdi for hvert kriterium Velge produktet med størst poengsum? Listen blir ofte subjektiv Kriterium Produkt 1 Produkt 2 Produkt 3 Produkt 4 Brukergrensesnitt Troverdig leverandør Pris Går også på UNIX

9 En generell metode Start arbeidet Forberedelse, planlegging og kontroll Analyse og utarbeide krav, kriterier Gjennomføre evalueringen Vurder resultatene Rapportere, presentere og kompetanseoverføring Avslutt arbeidet

10 Evaluering av brukergrensesnitt Dørhåndtak - elektronisk kodelås Reflektere hvem som gjør hva Programvare som gjør det mulig for en bruker å kommunisere med en datamaskin Bestemmer hva brukeren skal se og gjøre Både maskin og bruker påvirker hverandre Optimalisere brukerens mulighet for kontroll Programmet skal nå sitt mål som er å påvirke brukeren

11 Et godt grensesnitt gjør at Feil ikke oppstår og feilfrekvens reduseres Opplæringen kan forenkles Produktivitet og effektivitet øker Brukerne blir fornøyde Systemet kan bli lettere å selge

12 Brukervennlighet Systemet er brukervennlig når: Brukeren kan ta systemet i bruk straks for å utføre oppgaven tilfredsstillende uten undervisning eller bruk av dokumentasjon Det er lett å lære og huske, er forståelig og både effektivt og tilfredsstillende å bruke Brukeren ikke hindres eller sinkes i å utføre oppgaven tilfredsstillende ved å bruke systemet. Hindringene er en subjektiv opplevelse hos den enkelte bruker

13 Brukervennlighet - Fravær av brukervansker Brukeren kan ikke fortsette arbeidet uten hjelp fra en annen person Brukeren føler at systemet oppfører seg sterkt irriterende eller irrasjonelt Der er forsjkell på hva brukeren tror systemet gør og det systemet virkelig gjør Flere brukere opplever samme kritiske hendelse/stopp uavhengig av hverandre

14 Feil i arbeidet medfører kostnader Irritasjon Tidstap Tap av data Mister flyt i operasjonene Lavere effektivitet Reduserte muligheter for ansatte til å gjøre en god jobb Misfornøyde kunder Kunder og ansatte velger mindre effektive, men sikrere prosesser Feil i produkter og tjenester

15 Med og uten feil Når alt virker slik det skal uten feil Arbeidsoperasjoner går fort Grensesnittet blir en del av arbeidet Flyten i arbeidet kan optimaliseres Vi blir tilfredse med systemet I feilsituasjoner: Arbeidsoperasjoner går langsomt Grensesnittet blir et irritasjonsmoment Vi kan miste flyten i arbeidet og gjøre nye feil Vi kan bli misfornøyde med systemet og er på jakt etter andre løsninger

16 Tilfredse brukere får vi når systemet: Gjør det brukeren forventer Er effektivt Hjelper brukeren til å gjøre en god jobb Det medfører: God reklame for systemet Brukere som er lite villige til å gå over til et nytt system

17 Evaluering av brukervennlighet Hensikt: Å vurdere brukervennligheten i et system Metode: Løse arbeidsoppgaver systemet er laget for og evaluere utførelsen Resultat: En liste over funksjoner og graden av brukervennlighet i funksjonen

18 Evalueringsspørsmål Hvor lang tid tar det før en bruker Har god oversikt over systemets funksjonalitet? Kommer med forslag om hvordan systemet kan brukes? Ser hvilken effekt og nytte han har av systemet? Hvor lang tid tror du brukeren er villig til å bruke på dette?

19 Flere eksempler Informativ tilbakemelding Umiddelbar effekt av kommando (for eksempel et timeglass) Bekreftelse på at operasjon er utført med melding Glider som viser at operasjonen er initiert Manglende tilbakemelding I mange Web systemer kan brukerne bli usikre på om bestillingen er utført (bestiller gjerne på nytt for sikkerhets skyld) Evalueres grensesnittet basert på gode kunnskaper om brukernes krav og bakgrunn, eller bare på vår egen faglig dyktighet eller begge deler?

20 Noen evalueringsspørsmål Er grensesnittet standardisert og konsistent? Finnes det snarveier for eksperten? Gir grensesnittet informative tilbakemeldinger? Kan vi reversere handlinger (undo)? Er det gode feilmeldinger og god feilhåndtering? Er det brukeren eller grensesnittet som har kontrollen? Er neste hendelse selvinnlysende? Er grensesnittet selvforklarende/intuitivt? Slipper du å huske brukssekvenser?

21 Hva når jeg må lete etter informasjon på nettet Hvordan kan jeg vite om informasjonen er: Sann Pålitelig Troverdig Kvalitetssikret Ikke påvirkningsinformasjon Ikke desinformasjon Ikke manipulert Ikke unyansert Ikke ufullstendig Ikke feilinformasjon eller usann

22 Om forfatteren Hvem er han? Hvorfor skrev han det? Hva vil han at jeg skal mene eller tro? Hvorfor skal jeg tro på dette? Hvem er målgruppen? Inneholder informasjonen fakta som kan kontrolleres? Ikke stol på informasjonen før det motsatte er bevist

23 Hva kan jeg gjøre? Vær alltid kritisk til informasjonen Følg spor Hva leter du etter? Sjekk flere og andre kilder Hvem er avsenderen? Hva er motivet for presentasjonen? Hvem er målgruppen?

24 Hva slags nettsted er det? Reklame Avis eller tidsskrift Generell informasjon Informasjon om en bedrift Debattside for påvirkning En stats offisielle nettsted Bedriftsside Interesseorganisasjon Personlig hjemmeside

25 Sjekkliste Om forfatteren Virker informasjonen pålitelig? Sjekk forfatterens kompetanse og arbeidssted Er forfatteren en ekspert på området? Tilhører nettstedet en anerkjent organisasjon eller ikke? Er kildene for informasjonen publisert? Kan du bekrefte informasjonen? Kan forfatteren kontaktes om du vil? Er forfatteren nøytral eller tilhører han en interesseorganisasjon.

26 Sjekkliste Om innholdet Er innholdet nyttig, originalt, nøyaktig annenhånds, hentet fra andre steder eller tvilsomt? Finnes informasjonen på andre kildeformater? Er hensikten med presentasjonen klart beskrevet? Er presentasjonen i tråd med hensikten What items are included in the resource? What subject area, time period, formats or types of material are covered? Er informasjonen fakta eller meningsytring Hvor ofte blir informasjonen oppdatert? Finnes det pekere til andre steder med tilsvarende innhold?

27 Sjekkliste Om presentasjonen Er det lett å finne informasjonen? Hvor mange klikk må du gjøre for å finne noe nyttig Hvordan er kvaliteten på grafikken? Er grafikken med på å heve kvalliteten eller er den distraherende? Er målgruppen definert eller opplagt? intended users clearly indicated? Er linkene systematisk presentert? Har nettstedet egne søkemuligheter? Er det lett å finne fram på nettstedet?

28 Sjekkliste Om betaling og tilgang Er nettstedet tidsbegrenset eller ikke? Er responstiden akseptabel? Har nettstedet mulighet for bare tekstlesing? Hvor mange pekere mangler informasjon? Krever nettstedet betaling for bruk? Kan ikke-medlemmer hente informasjon fra nettstedet Må du registrere navn og passord for å få tilgang?

29 Sjekkliste Annet Undersøk om du kan finne forfatter eller organisasjon på nettstedet En tilde ~ indikerer som oftest at informasjonen er personlig fremfor virksomhetens offisielle. For å finne utgiverens faglige status kan du måtte lete i annet skriftelig materiale som f.eks. Hvem er hvem i Norge, FN, norsk idrett.... Sjekk og kontroller innholdet med innholdet på andre tilsvarende eller lignende presentasjoner.

30 Konsekvenser av feil valgt informasjonssystem Systemet støtter ikke viktige forretningsprosesser eller støtten er dårlig Misfornøyde kunder, brukere Tap av markedsandeler Systemet blir ikke brukt eller det utvikler seg nye arbeidsmåter som ikke er optimale

31 Et utgangspunkt for evaluering Forstå rammebetingelsene og forutsetningene Hva vi ønsker/forventer at systemet skal gjøre Hva vi opplever at systemet gjør Kvaliteten Forskjellen mellom forventning og det i fikk Hvordan støttes arbeidet i virksomheten? Drift og vedlikehold av systemet Dokumentasjon av systemet Holde systemet oppe Hjelp når noe går feil Feilretting, endring og nyutvikling

32 En modell for evaluering og valg Løse dagens behov ITsystemet løser dagens arbeidsoppgaver Løse fremtidige behov ITsystemet løser fremtidige arbeidsoppgaver Implementering Tilpasning til maskiner, infrastruktur og installasjon av systemet Support Hvordan systemet videreutvikles og tilpasses nye behov i program og virksomhet Kostnader Alle kostnader ved å bruke systemet. Drift, vedlikehold, lisenser, reduksjon/økning av personalkostnader og estimering av alle ikke målbare størrelser som goodwill, personaltrivsel.

33 Struktur i en evaluering Kost/nytteanalyse Hvilke redusert kostnader fører systemet til? Hvilken økt nytte fører systemet til? Kravspesifikasjonen til systemet Hvordan er hvert krav oppfylt? Innføring av systemet Drift, vedlikehold og videreutviklling

34 Evaluering av kravene Beskriv systemets hovedfunksjoner fra forskjellige perspektiver i virksomheten: brukerens perspektiv ledelsens og ansattes perspektiv driftspersonalets perspektiv og vurder hvordan hver funksjon er løst. Vurder hvert delsystem som systemet består av på tilsvarende måte

35 Evalueringskriterier Løsningens arkitektur Skalerbarhet Ytelse Pålitelighet Utvidbarhet Programmerbarhet Åpenhet/enkel å integrere Sikkerhet Drift- og administrerbarhet Støtte for outsourcing scenarioer Tilgjengelighet på kompetanse Løsningens modenhet i markedet Funksjonalitet Kostnad både i innkjøp og drift Brukervennlighet og brukertilgjegelighet Internasjonal støtte Konfigurerbarhet Standardstøtte Produktets fremtidige veikart roadmap Leverandørens størrelse og finansielle status Analytiker rating eller vurdering Support-organisasjon

36 Total Cost of Ownership Elementer i en TCO evaluering Direkte kostnader Lisenskost Implementasjons/migreringskostnader Driftskostnader (menneskelige ressurser) Opplæringskostnader Indirekte kostnader Nedetid tap av produktivitet Manuelle operasjoner som følge av manglende funksjonalitet De ulike elementer i en TCO er forskjellig fra løsning til løsning Gir grunnlag for å sammenligne epler med epler og pærer med pærer Gjør det mulig å se kostnad i et annualisert perspektiv ikke som et øyeblikksbilde ved innkjøp

37 Så hva betyr TCO? Kostnader annualisert, og ikke i et øyeblikksbilde feks ved innkjøp og impl MERK: TCO er en komplisert eksersis og kan kreve mye tid og ressurser For Eval-prosesser: Bruk TCO tankegangen når du vurderer løsninger Hva betyr feks Brukervennlighet, Driftsfunksjoner/Administrerbarhet eller denne løsnings-arkitekturen for løsningens totalkostnad i et 5 års perspektiv

38 En sjekkliste - 1 Regner systemet riktig? Er systemet lett å lære/bruke? Gir systemet nyttige rapporter? Er det lett å lage nye rapporter? Hvordan samvirker systemet med andre systemer i virksomheten Hvordan er systemet å drifte Hvordan påvirker systemet virksomhetens organisering Er systemet forankret i ledelsen? Er brukergrensesnittet selvforklarende? Hvordan vil det gå om nøkkelpersoner slutter?

39 En sjekkliste - 2 Hvilke hovedoppgaver har systemet? Hvordan løses hovedoppgavene? Hvilke positive og negative påvirkninger har systemet på virksomheten Hvilken maskinplattform - ny eller som før? Proprietær eller åpen programvare? Har driftsavdelingen kompetanse til å drifte systemet?

40 Systemets livsløp - 1 Hvilke behov vil virksomheten løse? Hvilke behov skal systemet løse? Hvordan løses behovene? Grov beskriving av hvordan behovene løses Vurder kravspesifikasjon mot løsning Hvordan er programmene bygd opp? Utviklingsplattform, objektorientering, gjenbruk Feiltesting, svakheter, avgjørende valg

41 Systemets livsløp - 2 Innføring Undervise brukerne Lage et driftsmiljø: Maskin, personale, kontaktarbeid Forvaltning Drift Vedlikehold og videreutvikling Lage nye eller tilpasse rapporter Lage nye eller tilpasse funksjoner Rette alvorlige feil Lære opp brukere System- og brukerdokumentasjon Brukerhåndbok, hjelpfunksjonen

42 Distribusjonskjeden G D G P D F

43 Evalueringer og IT-strategi Et IT innkjøp er realiseringen av en IT strategi Evalueringskriterier skal være forankret i IT strategien Alignment med IT-strategien er i seg selv et evalueringskriterie Beslutningen må kunne forankres i IT strategi og bør ikke gå på tvers av denne Vurder strategiske vs taktiske aspekter! Det vil alltid være behov for unntak, men Legg ikke IT strategien i det øyeblikk dokumentet er ferdigstillt

44 Oppsummert - Noen råd og anbefalinger Løsningsarkitektur er like viktig som funksjonalitet fra et IT perspektiv Adopter en TCO tankeprosess når du evaluerer en løsnings kostnad pris og kostnad er ikke alltid det samme Vær oppmerksom på leverandørers taktikk og manipulering Utarbeid en bevisst strategi for best-of-breed vs totalleverandør løsninger Sørg alltid for at en IT innkjøps beslutning er forankret i IT strategi