Bokens helhetssyn Perspektiv Prosjekt Prosess Penger Figur 0 Prosesser TEKNISK UTSTYR A: ORGANISASJON B: PROSESSER D: SYSTEMER C: DATA Prosesser Data Organisering Kompetanse Motivasjon Informasjon Installasjon Integrasjon Konvertering Prosjekt- ledelse eierskap Implemen- terings- fasen Valgfasen Anvendelses- Strategi- & modnings- Varekostnader Tjenester Forvaltning Gevinster ÅR 1 ÅR 2 ÅR 3 ÅR 4 Figur 0

Bokas fokus Bokas fokus Figur 1 Pilotfasen Spredningsfasen Valg og implementering i spredningsbedriftene Implementering i pilotbedriftene Pilotfasen Utvikling av bransjeløsninger Boka skal være til nytte for både pilotbedriftene og spredningsbedriftene. Den skal gi bedriftene økt kunnskap om hvilke prosesser som fører frem til en effektiv anvendelse av moderne IKT-baserte styringssystemer. På denne måten skal deltakerne i BIT-programmet stå bedre rustet til å være en profesjonell, og ansvarlig aktør i valg- og implementeringsfasen. Figur 1

Forholdet mellom kunde og leverandør Valg Implementering Anvendelse Krav/evaluering/kontrakt Mottaksaktiviteter Leveranseaktiviteter Læring Effektiv anvendelse Støtte og vedlikehold Belastning Innsalg Støtte og tuning Forholdet mellom kunden og leverandørens belastning i perioden fra valg til effektiv anvendelse varierer. Kundens belastning når et toppunkt ved oppstart, men belastningen holder seg et godt stykke inn i anvendelsesfasen. Leverandøren har sin største belastning i den første del av implementeringsfasen når løsningen skal designes. Figur 2

Bransjeløsningens arkitektur Virksomhets- prosesser Bransjens ”beste praksis” Standard- applikasjoner Bransjefunksjonalitet Bransjens begrepsapparat Implemen- terings- prosess Leveran- dørens metode, dvs. Konsulentressurser med IKT-faglig og bransjespesifikk kompetanse En bransjeløsning består av ett eller flere standard- produkter. Disse integreres og tilføres ny funksjonalitet for å dekke de krav bransjen har. Særlig viktig er det at bransjens begreper og terminologi gjenspeiles i løsningen, for eksempel i skjermbildene. Figur 3

erfaringer/Best practice Aktørmønsteret Bedriften SND Programansvarlig Programvare- leverandør Leverandør av bransjeløsning Konsulenter data- og/eller bransje- kunnskap Pilotbedrifter Sprednings- bedrifter Bransje- forening erfaringer/Best practice ASP Infrastruktur- infrastruktur driftstjenester En aktør kan inneha flere roller. En aktør kan for eksempel være både ASP og programvare- leverandør/utvikler. En aktør kan også være både programvareleverandør, infrastrukturleverandør og konsulentpartner. Figur 4

IKT-begrepet + = Teknologi Informasjon Kommunikasjon Informasjons- og kommunikasjons- teknologi = + IKT-begrepet er egentlig en forvansking av IT-begrepet. Begrepet ”IT” inkluderer naturligvis også kommunikasjonsaspektet. Figur 4B

ERP-løsningen Sammensatt løsning ”Alt-i-ett” løsning Figur 5 Økonomi OLFI MPS MPS + Økonomi + OLFI ERP-løsning Sammensatt løsning ”Alt-i-ett” løsning En ERP-løsning kjennetegnes ved at den er tett integrert, og fremstår som en homogen (ensartet) programvare for brukeren. Figur 5

Fire løsningsarkitekturer ERP-løsning; Økonomi & OLFI Nisjeprodukt; HRM & Lønn + Økonomi, OLFI & HRM Nisjepr. Lønn Økonomi, OLFI, HRM & Lønn ERP-løsning; Økonomi, OLFI & Lønn HRM Integrasjon: Posteringer fra lønn til økonomi Personaldata fra HRM til lønn Integrasjon: Personaldata fra HRM til lønn Integrasjon: Ingen Arkitekturvalg handler bl.a. om valg av oppgavedeling mellom systemene. Det vil si å skape effektive grensesnitt (integrasjoner). Det vil være bedriftens behov som er bestemmende for hvilken av de fire løsningsvariantene som er best. MPS + Økonomi + OLFI lønn og HRM Bred ERP-løsning Fag- system En ERP-løsning dekker ikke alt. Det vil alltid være et behov for å supplere med spesialsystemer. Det er jo nettopp hva som gjøres i bransjeløsningene. Figur 6 Figur 7

To varianter av ERP II Figur 8 ERP Kunde Leverandør Leverandør Hovedbok Reskontro Lagerstyring Produksjon Ordre Fakturering Distribusjon Lønn Personal Kunde CRM Markedsføring Salg Reklamasjoner Service SRM Varesøk Bestilling Produktegenskaper Priser Lagerstatus Leveransekvalitet Ordrestatistikk Kundedata Behov Leverandørdata Database Leverandør To varianter av ERP II Leverandør Her ser vi to løsningsvarianter der den ene må sies å være særdeles homogen, dvs at den kjennetegnes ved at både kjernefunksjonene (ERP)og handelsfunksjonene er bygget over samme lest (database) Figur 8

E-collaboration Transformasjon E-business Integrasjon E-commerce Begrepsnivåene ERP SRM CRM E-collaboration E-business E-commerce EDI Transformasjon Integrasjon Datautveksling Internett Elektronisk handel Elektronisk forretningsdrift samarbeid ERP II Det er snakk om modningsnivåer. Det betyr at kravene til både intern og ekstern integrasjon øker når man beveger seg mot E-collaboration Figur 9

Fra monolitter til komponenter 9 4 Leverandør- reskontro 6 2 Hovedbok 11 Budsjett 3 Kunde- 7 8 Analyse 12 Egenutviklet 5 Kredittsjekk 1 Anleggsverdi- regnskap 10 En god komponentarkitektur er bra for kunden, både mht forvaltning og skalerbarhet. I tillegg skal en slik arkitektur lettere åpne for introduksjon av så vel egenutviklede komponenter som 3. Parts komponenter. Figur 10

Fra portal til database via EAI WEB-tjenester Informasjonstjenester Funksjonstjenester Integrasjonskomponent Motta meldinger fra applikasjoner Sende meldinger til applikasjoner Portal Spesial- system EAI Bransjeløsningen Applikasjonskomponenter Forretningslogikk Presentasjonslogikk Databasekomponenter Data Dokumenter Database Ekstern integrasjon Data- base En spennende måte å integrere komponenter på er via et felles knutepunkt (node). Det gir en effektiv integrasjon med færre grensesnitt enn om alle skulle realiseres direkte mellom komponentene. Figur 11

Implementeringsmetode Maler i MS Word/Excel Rapportering Løsningsbeskrivelser Hhjhjjhjh Rretsavf hgfrffefg Prosedyrer i MS Word Hvordan oppgaven bør løses Plan i MS Project WEB-portal for alle prosjektdeltakere Prosjekt Dokumentlagring Notes database Filserver En god implementeringsmetode må støttes av IKT-verktøy, både for å kunne planlegge, dokumentere og kalkulere Figur 12

Det utvidede produktbegrep Hovedproduktet Bransje- løsningen Implementerings- metode Prosess- design Opplæring Support Vedlike- hold Drift Støtteprodukter separate tjenester Utviklingsretning Det utvidede produktbegrep innebærer at selve bransjeløsningen blir utvidet til å omfatte er rekke interessante tjenester som selv støttes av programvare, og som i stor grad er integrert med bransjeløsningen. Figur 13

En moderne løsningsarkitektur Merkantile dokumenter Fagsystemer Tradisjonell ERP Økonomistyring, Produksjonsstyring, Lagerstyring Innkjøp/ leverandørstyring Salg/ markedsføring Analyse Arbeidsflytstyring Dokumenthåndtering Kontorstøtte WEB-portal PDA-portal ICA-klient/Windows Salgstransaksjoner Design/utvikling E- commerce business collaboration Mail integrasjonstjenester Leveransestyring ERP- data Produktdata- historikk dokumenter Fag- Data om bransje- løsningens virkemåte En moderne løsningsarkitektur for elektronisk forretningsdrift omfatter en rekke nye funksjonsområder som kommer i tillegg til de tradisjonelle ERP-funksjoner. I tillegg til det vi har valgt å kalle ”integrasjonstjenester” Figur 14

Databasen i sin fulle bredde Produktdatahistorikk Fagdokumenter Produktdokumenter Saksdokumenter Avtaler etc. Product lifecycle Management Enterprise Management Styredata Behandlingsregler Autorisasjoner Rapportoppsett ERP-data Transaksjonsdata Sumdata Grunndata ERP-dokumenter Fakturaer Fraktbrev Reiseregninger Bestillinger Elektronisk forretningsdrift forutsetter en langt større opp-merksomhet mot den del av data-basen som omfatter digitale dokumenter, både de merkantile (fakturaer etc,) og de mer faglige (tegninger, saksdokumenter etc.) Figur 15

Elektronisk støttet leveransestyring ERP Supply Chain Management innkjøp salg Bransje- løsning Leverandører Kunder SRM CRM Elektronisk forretningsdrift (e-business) Elektronisk salg (e-sale) Elektronisk innkjøp (e-purchase) ERP II Elektronisk støttet leveransestyring Datasystemene utgjør i stadig sterkere grad selve limet i forsyningskjeden. Ved å knytte systemene sammen over Internett, utvikles nettverk av bedrifter som kan samhandle mer effektivt enn tidligere (Business-to-Business) Handelsdokumenter overføres for eksempel i elektronisk format basert på XML. Figur 16

Komponenter knyttet til dokument-håndtering Arkiv Skanning OCR Formatering Distribusjon Dokumentmottak Arkivering Versjonshåndtering Gjenfinning Dokumentforsendelse ERP Dokumentproduksjon MS Office Lotus Notes Dokument- produksjon Arbeids- flyt Fagsystemer Dokumentmottak/forsendelse Intranett/ Ekstranett/ Internett (WEB-sider) Dokumentpresentasjon Content Management Output Management Workflow Management Enterprise Resource Management Moderne dokumentbehandling medfører at en lang rekke systemkomponenter bidrar (integreres). I sentrum står det digitale arkiv, dvs dokument-databasen. Dette konseptet er en forutsetning for eksempel ved introduksjon av Knowledge Management. Figur 17

Leavitts`diamant STRUKTUR OPPGAVER MENNESKER TEKNOLOGI Figur 18 Leavitts diamant fokuserer på at man ikke kan behandle for eksempel teknologispørsmål (datasystemer og infrastruktur) uten samtidig å se på hvilke konsekvenser dette har for de ansatte, deres oppgaver og måten de er organisert på. Dette kalles en helhetlig (holistisk) tilnærmingsmåte. Figur 18

To perspektiver, fem dimensjoner Medarbeidere Organisasjonsstruktur Rollestruktur Selskapsstruktur Geografisk struktur E: TEKN. UTSTYR PC-er, Tjenermaskiner Operativsystemer Nettverk/Skrivere Teknisk infrastruktur A: ORGANISASJON B: PROSESSER Primær prosesser Støtteprosesser Prosesstruktur D: SYSTEMER Bransjeløsningen For- og ettersystemer Kontorstøtte Systemstruktur Grunndata Datastruktur C: DATA Bedriftens prosesser er plassert i sentrum. Alle øvrige strukturer (D, A, E og C) er utelukkende til for å støtte verdiskapningen. De har i seg selv ingen egenverdi !. Det er derfor prosessene som ”setter krav” til systemstøtte, datastøtte, teknisk støtte og ikke minst menneskelig ressursinnsats fra organisasjonens medlemmer. Figur 20

De 10 koplinger Medarbeidere Organisasjonsstruktur Rollestruktur Selskapsstruktur Geografisk struktur E: TEKN. UTSTYR PC-er, Tjenermaskiner Operativsystemer Nettverk/Skrivere Teknisk infrastruktur A: ORGANISASJON B: PROSESSER Primær prosesser Støtteprosesser Prosesstruktur D: SYSTEMER Bransjeløsningen For- og ettersystemer Kontorstøtte Systemstruktur 1 2 3 5 6 Grunndata Datastruktur C: DATA 7 8 4 9 10 De 10 koplingene adresserer hver for seg viktige spørsmål som det må tas stilling til i valg og implementeringsfasen. Pilenes retning er basert på ”hva-som-støtter-hva” prinsippet. Figur 21

Prosessen i et bredt perspektiv Implemen- terings- fasen Valgfasen Anvendelses- Beslutning om kjøp Strategi- & modnings- Prosjekt- idé Implementering av nye komponenter Utskifting av bransjeløsningen om å videre- føre dagens løsning Prosjektorganisering om å vurdere kjøp ta i bruk Prosessen består totalt av fire faser. Modningsfasen er en uformell tilnærming til et krevende prosjekt som består av valgfasen og implementeringsfasen. I forbindelse med at systemet settes i drift overleveres bransjeløsningen fra prosjektet til linjen. Da er vi inne i anvendelsesfasen som varer så lenge løsningen er i bruk. Det er ikke uvanlig at prosjektet opprettholdes et godt stykke inn i anvendelsesfasen. Figur 22

Plan for gjennomføring Tidsaspektet Plan for gjennomføring Strategi- & modningsfasen Valgfasen Implementerings- fasen Anvendelsesfasen JAN FEB MAR APR MAI JUN JUL AUG SEP OKT NOV DES Beslutning om å starte et prosjekt kjøpe bransjeløsning, eller terminere prosjektet Q1 Beslutning om oppstart med ny bransjeløsning Ideen fødes, formes og forankres Kritisk oppstarts-periode Planen viser et eksempel der driftsstart på ny bransjeløsning faller sammen med årsskifte. Dette må ikke sees på som et krav. For mange vil det være meget gunstig å velge et annet tidspunkt, for eksempel basert på når belastningen på organisasjonen er minst. Figur 23

Prosjektets økonomiske utvikling Valg- fasen Implementerings- Akkumulert kost/nytte Tid - Konsulenthjelp - Egen innsats - Kjøp av programvare - Lisenskostnader - Opplæring - Infrastruktur - Erstatningshjelp - Produktivitetstap i en overgangsperiode - Vedlikehold - Support - Intern forvaltning/drift - Tilleggskjøp av programvare - Flere lisenser (database m.m.) - Opplæring av nye medarbeidere + Effektivisering + Økt salg + Salg man unngår å tape + Lavere kapitalbinding + Lavere tap på fordringer + Redusert kredittid + Mindre reparasjonskostnader År 1 År 2 År 3 År 4 År 5 Økonomisk balanse = Break even Positiv ROI Negativ Anvendelses- kontantstrøm Kurven er kumulativ. Det betyr at summen av kostnader og nytteverdier fra og med valgfasens begynnelse vises. Figur 24

Økonomimodellens bruksområder Versjon 3.n; Tilbud fra leverandør n + Kostnadsbilde; Dagens løsning Økonomi- modell Versjon 1 Investerings- budsjett Versjon 2 leverandør A Versjon 3 Kost/nytte kalkyle basert på frem- forhandlede priser (kontrakt) Versjon 4 Virkelige kostnader og nytteverdier Versjon 5 Økonomimodellen skal, som figurene viser, kunne benyttes til mange formål: Versjon 1 kan utarbeides i modningsfasen Versjon2-4 kan utarbeides i valgfasen Versjon 5 kan utarbeides i implementeringsfasen og anvendelsesfasen Figur 25

Økonomimodellens prinsipp Realistisk anslag Varer & Tjenester Versjon 1: Kostnadsbilde eksisterende løsning Reelle kostnader/ Budsjett Trendfremskrivning Versjon 2: Prosjekt ÅR 1 Valg/ Implementering Normalår på gammel løsning ÅR 2 Anvendelse 1. driftsår på ny løsning ÅR 3 2. driftsår på ÅR 4 3. driftsår på Versjon 3: Tilbud fra leverandørene Tilbudspriser Vedlikehold, support, drift Versjon 4: Kost/nytte kalkyle bransjeløsning Forhandlede priser Vedlikehold, support, drift, forvaltning vs. nytteverdi Versjon 5: Reelle kostnader og nytte Reelle kostnader Reell nytteverdi Terminering av kostnader knyttet til gammel løsning Etter- kalkyle Merk at etterkalkyle på prosjektet vil si å sammenstille versjon 4 og 5. Merk også at når man fullkalkulerer eierskapskost for ny bransjeløsning må også alle kostnadene knytter til den løsningen som termineres (Versjon1) komme til fradrag. Figur 26

Når oppstår effekten? Tid Nyttekurve; alternativ 1 Figuren viser ulike nyttekurver. En nyttekurve er en fordeling av en type nytteeffekt over tid. Hver gang vi tar inn en effekt i kost/nytte kalkylen må vi gjøre oss opp en mening om hvordan effekten utvikler seg over tid. Figur 27

Nytteeffekter Figur 28 Prosess forbedring Sikre eksisterende (primærprosesser) (støtteprosesser) Sikre eksisterende forretning (unngå tap) Vinne ny forretning Kapitalforbedring (intellektuell kapital) (monetær kapital) Kroneverdi Stor effekt Liten effekt Nytteprofilen viser 3 sett med effekter, nemlig prosesseffekter, forretnings- effekter og kapitaleffekter. Effektene kan opptre i kombinasjon. Effektene langs hver av aksene må summeres over en kalkyleperiode på for eksempel 3 år. Figur 28

Applikasjonskomponentenes livsløpskurve Tid Introduksjon Spredning Høsting Avvikling Antall installasjoner MBS AXAPTA XAL Navision Man må alltid vurdere hvor bransjeløsningens komponenter er i sitt livsløp. Det er en del av den obligatoriske risikovurderingen Figur 29

Endringstyper Suksessfaktorer En helhetlig modell Forretnings- modell ORGANISASJON SYSTEMER TEKNISK UTSTYR DATA PROSESSER Endringsledelse Ledelses- forankring Prosjekt- metode Bruker- Endringstyper Suksessfaktorer Styrings- Endringsledelse må sees i sammenheng med hvilke endringer det planlegges for. Desto større endringer, desto større må oppmerksomheten være mot profesjonell endringsledelse. Figur 30

Endringsledelse og de involverte Ansatte/ vanlige sluttbrukere Ledelses- nivåer Styrings- gruppe Prosjekt- leder Gruppe- deltakere Prosjekt Organisasjonen Ressursallokering leveranser Informere, motivere Endringsledelse forutsetter tung involvering både fra prosjektledelsen og linjeledelsen. Figur 31

Den ansatte påvirkes på flere måter (sluttbruker) Prosjektleveranser Påvirkning fra ledelsen fra kolleger Endringsvilje Endringsevne De krefter som påvirker den ansatte bør være positive og synkroniserte, slik at den nødvendige endringsvilje og -evne oppnås. Figur 32

Endringsledelse i et tidsperspektiv Endringsmål oppnådd Endringsledelse Linjeledelse Prosjekt- ledelse start Endrings- forslag slutt År 0 Endringsledelse starter før prosjektet tar til og avsluttes ikke før endringsmålene er oppnådd. Figur 33

Kanalstruktur; modernisering av verdikjeden Produsent Grossist Detaljist Konsument Alt. 1 Alt. 2 Alt. 3 Kunde Alt. 4 Markeds- plass I et langsiktig perspektiv ønsker vi å oppnå en mer effektiv kanalstruktur, med færre ledd og høyere servicegrad overfor kunden. Figur 34

De fire basismodellene CRM ERP Hjemme- sider KUNDE LEVERANDØR A E-ordre registrering E-handels- program Brann- vegg E-markeds- plass Modell 1: Forsiktig tilnærming Modell 2: Lavt ambisjonsnivå Modell 3: Middels ambisjonsnivå Modell 4: Moden løsning LEVERANDØR B LEVERANDØR C Bildet viser hvordan en handelsløsning kan modnes fra en forsiktig tilnærming til deltakelse på en markedsplass. Figur 35

E-handel; et spørsmål om hva det er man selger CD-er Bøker Matvarer Møbelinnredning Datautstyr Catering Enkel Kompleks Stabil kvalitet over tid Kvalitet som forringes over tid Enkelt å håndtere i et e-handelskonsept KSF: Massedistribusjon KSF: Varetilgjengelighet Krevende å håndtere i et KSF: Leveringshastighet KSF: Routing KSF: Konfigurator KSF: Pakking Meget vanskelig å håndtere i et e-handelskonsept KSF: Logistikk Kategorisering av varer Kritiske suksessfaktorer I forbindelse med utvikling av en e-handelsstrategi må man vurdere nøye hvorvidt de produkter man selger egner seg for denne type handel, eller om produktene setter særlige krav til handelsløsningen. Figur 36

Hva opptar norske IKT-sjefer? Tvungen rangering av 24 forhåndsdefinerte problemstillinger ga følgende resultat: RANG 1: Forbedre sammenhengen mellom IKT-strategi og forretnings- strategi RANG 2: Identifisere og planlegge IKT-prosjekter som gir konkurranse- fortrinn RANG 3: Styrke IKT-planlegging på tvers av organisasjonsgrenser RANG 4: Bedre planlegging og utvikling av en helhetlig IKT-arkitektur Dette er hovedresultatene fra en spørreundersøkelse gjennomført i 1999 blant IKT-sjefer i mellomstore og store organisasjoner. Målet var å rangere hvilke utfordringer de så for seg i de kommende år, dvs. 2000-2004. Figur 37

IKT-strategirevisjon Dette er forretningsledelsens ansvar. Denne delen av strategien bør ideelt sett være inkludert i det dokumentet som beskriver bedriftens forretningsstrategi IKT-visjoner IKT-mål IKT-arkitekturer IKT-prosjekter & -tiltak Ansvar Nytteeffekter Budsjett H A N D L I N G S P L A N Retningslinjer Prosedyrer Standarder Metoder ”IKT-kjørereglene” IKT-strategi Dette er IKT-ansvarliges ansvar. Denne delen av strategien vil være beskrevet i et eget dokument som naturlig nok vil ha en teknisk vinkling Figur 38

Strategihierarkiet CRM/ SCM/ Forretningsidé Forretnings- strategi Logistikk Produksjon Salg/ markeds- føring Idégrunnlag Misjon Primærstrategi Virksomhetsstrategi Støttestrategier Funksjonsstrategier Teknisk infrastruktur Applikasjoner og data IKT-organisering og -styring Delstrategier Forretnings- og IKT-strategi CRM/ IKT SCM/ IKT-Kjøreregler Slik det ofte er Slik det bør være Applik./ data Tekn. Infrastr. IT-org./ styring Retningslinjer Prosedyrer Standarder Metoder En IKT-strategi for elektroniske forretningsdrift må være meget godt sammenkoplet med forretningsstrategien. Figur 39

Integrert strategiutvikling IKT-strategi Strategi- dokument Svak koordinering Strategi for e-forretningsdrift Før Nå Forretningsstrategi m/eventuelle funksjonsstrategier IKT Forretning IKT-strategi og forretningsstrategi bør utvikles integrert og helst samtidig Resultatet blir da en samlet strategi for elektronisk forretningsdrift Figur 40

1a 1b 2a 2b Analysemodell Eksternanalyse Internanalyse E-analyse E-handel som fenomen E-handel innen vår bransje E-handel innen våre segmenter Kundenes forhold til e-handel Systemleverandørens forhold til e-handel Infrastrukturleverandørens Salgsvolumer og resultater Leverandørenes forhold til e-handel Leveransekvalitet Kundelojalitet/kjøpsmønster E-analyse Modenhets- og mulighetsanalyse Eksternanalyse Nøkkeltallsanalyse 1a 2a 1b Internanalyse Konsekvenser for elektronisk forretningsdrift Organisasjon Prosesser Data Systemer Infrastruktur Figur 41

Servicegrad overfor sluttbruker Organisasjonsstruktur Systemstruktur Teknisk infrastruktur Prosesstruktur Brukerstøttetjenester Opplæringstjenester Service & driftstjenester Obligatoriske programvaretjenester Rollebaserte Personlige infrastrukturtjenester Felles 5 6 1 Servicegrad overfor sluttbruker Å velge riktig servicegrad overfor sluttbruker er en viktig strategisk beslutning. Servicegraden velges basert på klare mål for hvilke effekter den valgte service skal resultere i. Figur 41B

Strategi og modningsfasen Implemen- terings- fasen Anvendelses- Beslutning om kjøp om å ta i bruk vurdere kjøp Prosjekt idé Erkjennelse Sondering Strategibehandling Motivering Strategi- og modningsfasen Valgfasen Modningsfasen er både formell og uformell og har som sitt viktigste formål å sikre at: bedriften forstår hvilket arbeid som ligger foran dem. bedriften har gode grunner (dvs et erkjent behov) for å gå inn i et systemskifte. bedriften er kjent med hva markedet har å tilby bedriften har forankret prosjektet i sine strategiplaner (formelt element) Modning (uformelt) og strategiforankring går hånd i hånd. Modning skjer som følge av effektiv endringsledelse. Modning I Strategi- behandling Modning II Prosjekt- start Idé Figur 42 Figur 43

Valgfasen Figur 44 Implemen- terings- Anvendelses- fasen Valgfasen Beslutning om kjøp om å ta i bruk vurdere kjøp Prosjekt idé Erkjennelse Sondering Strategibehandling Motivering Strategi- og modningsfasen Valgfasen Prosjektetablering Situasjonsanalyse Strategisk analyse Kravspesifisering Tilbudsinnbydelse Evaluering/valg Valgfasen er første fase i prosjektet og skal resultere i at: bedriften har etablert et best mulig fundament for valg av ny løsning (strategiske og operative krav) bedriften har foretatt en tilbudsinnbydelse på en slik måte at det er etablert reell konkurranse bedriften har foretatt et valg, og det er utarbeidet en god kontrakt Figur 44

Ambisjoner og avgrensninger Moder- selskap Datter- A og B C Konsern Prosesser Økonomi OLFI Personal og lønn CRM E-salg SRM E-innkjøp Analyse/ Datavarehus Visjonen; Elektronisk forretningsdrift 1 2 3 4 5 6 7 8 Det kan ta fra 2-4 år å realisere visjonen trinn for trinn Å bygge et informasjonssystem må ofte gjøres trinn for trinn. Figuren viser at det er planlagt 8 delleveranser. Å splitte opp implementeringen på denne måten bidrar til å redusere risiko, samtidig som det gir organisasjonen en mulighet til å assimilere (ta inn over seg) endringene. Figur 45

Prosjektorganisering i valgfasen Prosjektleder Delprosjektgruppe: Teknisk infrastruktur Integrasjon Konvertering Organisasjon Kompetanse Motivasjon Prosesser/rutiner Styringsmodell Kodeplaner/grunndata Prosjekteier (Leder i styringsgruppe) (Daglig leder) Prosjektgruppe: Forenklet prosjektorganisering Fullverdig prosjektorganisering Kvalitets- revisor Styringsgruppen Ledergruppen Prosjektsekretær Figur 46

Selskapsstruktur og organisasjonskart Selskap A Selskap B Selskap C Selskap D 100 % 60 % Daglig leder Avdeling 1 Avdeling 3 Avdeling 2 Kostnadssted Oslo Bergen Bodø Fabrikkveien 3 Selger: 4 Ordremottaker: 2 Lagermedarb.: 3 Selskapsstruktur og organisasjonskart viser også enkelte viktige informasjoner (eksempler) om: Eierskapsprosent Stedsangivelse (geografisk struktur) Antall rolleinnehavere pr. avdeling Adresse Figur 47

Kompetanseområder Virksomhets- Bransje- Produktspesifikk Fag- Varianter av IKT-kompetanse Bransjeløsningen MS Office, DAK/DAP Maskinutstyr, nettverk Generell IKT-kompetanse fra universitet, høgskole eller fagskole IKT-strategi, IKT-arkitektur Hvordan IKT anvendes og forvaltes i virksomheten Bransje- IKT-leverandører IKT-løsninger IKT hos markedsaktørene Forretningsstrategi Strukturforståelse Prosesskompetanse Økonomi Materiallære Jus Markedsverdi Markedsutvikling Markedets behov Produksjonsutstyr Verktøy Produkter Kunder Leverandører Markedsaktørene Markedskreftene Markedsrelasjonene Elektronikk Sveising Erfarings- basert Formal Å bygge riktig kompetanse er en kritisk suksess- faktor for å lykkes med bransjeløsningen. Bedriften må derfor analysere hvilken kompetanse den harm hva som kreves og hvordan et eventuelt kompetansegap skal fylles. Figur 48

Verdi- konfigurasjoner Økonomiprosesser Personalprosesser Produktutviklingsprosesser Innkjøpsprosesser Støtte- prosesser Primære, verdi- skapende Inngående logistikk Markedsf./ salg Produk- sjon Utgående Service Tilbud Kalkyler Ordreoppf. Annonsering Avrop/mottak Kontroll Råvarelager Transport Montasje Materielladm. Installasjon Testing Kvalitetskontr. Pakking og emballering Varelager Distribusjon Oppfølging Informasjon Reparasjoner Klager Garantisaker Økonomiprosesser Personalprosesser Produktutviklingsprosesser Innkjøpsprosesser Støtte- prosesser Primære verdi- skapende Problem- forståelse løsning Løsnings- valg utarbeidelse evaluering Porters verdikjedemodell kan benyttes som en ramme for en første definering og kategorisering av bedriftens prosesser. Når hver enkelt prosess skal studeres nærmere kreves andre, og mer detaljerte beskrivelsesteknikker Fjeldstad og Stabells verdiverksted representerer en alternativ verdikonfigurasjon. Den er mer egnet når bedriften ikke har en tradisjonell fabrikk-produksjon, men løser kunde- spesifikke problemer. Figur 49

Datastrukturen, et eksempel KONTO PROSJEKT Timeverk Ansatt Materialkjøp Materialer Tegning Produksjon ORGANISA- SJONS- ENHET Datastrukturen (datamodellen) viser 3 sett med grunndata konto organisasjonsenhet prosjekt og 3 transaksjoner: produksjon timeverk materialkjøp En viktig egenskap ved datastrukturen er at den viser hvordan grunndata og transaksjoner er knyttet til hverandre (relasjoner) Figur 50

Systemstruktur M Figur 51 Driftsplattform Arbeidsstasjon Produksjons- Applikasjons- og databaseserver Arbeidsstasjon MPS-system Dataassistert produksjon Kontorstøtte (Excel / Word) Salgsstøtte Produksjons- utstyr M = automatisert datautveksling = manuell Database- server Database Økonomisystem Lønnssystem Ordre/fakturering Systemstrukturen skal vise alle systemkomponenter og eventuelle grensesnitt mellom disse. Figuren skal også angi hvilken integrasjonsmetode som er anvendt (manuell eller maskinell) Figur 51

Teknisk infrastruktur Driftsplattform Applikasjons- og databaseserver Arbeidsstasjon Produksjons- utstyr (DAP) Database- server PC (4) PC (6) Etasje 1 2 Servertype B Datamaskin i produksjons- utstyret Servertype A Merk at den horisontale aksen har den samme inndeling som for systemstruktur (ref. figur 51). Den vertikale aksen kan man fritt velge detaljeringsgrad for. Fra etasjer i et bestemt bygg til grovere angivelse av geografiske lokasjoner (byer) Figur 52

Strategisk analyse Figur 53 Utviklingstrekk som er av betydning for systemvalg og systemtilrettelegging Veksttakt (organisk/oppkjøp) Geografisk spredning Produkt/tjenestesammensetning Sannsynlige konsekvenser, IKT-perspektivet: Infrastruktur (Fjernnett/lokalnett) Systemer (BIT-programmet) Interne formelle strategidokumenter Forretningsstrategi IKT-strategi Eksterne markeds- og e-handels analyser Bransjeforening Analysebyråer Konsulentselskaper Interne planer Markedsplaner Investeringsplaner Produksjonsplaner Prosjektplaner Offentlige rammebetingelser Konkurransevilkår Rapportering Kundeservicemål Kvalitetsmål Produktivitetsmål Forretningsmodell Styringsmodell Prismodeller Prosesser (Handelsprosesser) Organisering (Roller/kompetanse) Data (Grunndata/kodeplaner/varekatalog) Tolkning av intern og ekstern informasjon virksomhetsperspektivet: Organisasjon Prosesser Data Systemer Infrastruktur Interne styringsdata Salg Økonomi Produksjon Logistikk Aktørenes planer innen IKT-området Kundene Leverandørene Samarbeidspartnere Konkurrentene Figur 53

Bedriftens samlede vurderinger Visjon/ mål O T D P S Strategi IKT- strategi Forretnings- Arkitektur Organisasjon Prosess Data Systemer Teknisk infrastruktur Egenskaper Risiko Nåverdi Bedriftens vurderinger i anskaffelsesfasen Hoved- produktet Støtte- produktene Overlevelse Gjennom- førbarhet Eierskaps- kost Nytteverdi Rolle- aspektet Prosess- Data- Teknologi- Implementerings- metode Referanse- prosesser Support- apparat Drifts- støtte (ASP) Opplærings- metoder Aktør (leverandør) Løsnings- konsept Mottaks- evne Forankring Ressurser Endringsvilje Prioritet Kompetanse Opptreden Leveranse- Gevinst- realisering Lisenser Infrastruktur Valg/ Implementering Anvendelse forbedring Verdiskapende pr. Støtteprosesser Omsetning Ny forretning Unngå tap Kapital- Monetær Intellektuell Trigger Figur 54

Implementeringsfasen Prosjektrevisjon Installasjon Design Realisering Klargjøring Etterarbeid Anvendelses- fasen Beslutning om kjøp om å ta i bruk vurdere kjøp Prosjekt idé Erkjennelse Sondering Strategibehandling Motivering Strategi- og modningsfasen Valgfasen Prosjektetablering Situasjonsanalyse Strategisk analyse Kravspesifisering Tilbudsinnbydelse Evaluering/valg Implementeringsfasen Implementeringsarbeidet er den mest kritiske fasen i prosjektet. Målet er å sette bransjeløsningen i drift til avtalt tid og til avtalt kostnad, basert på et vedtatt design. Dette krever profesjonell prosjektledelse. Det er særlig viktig å ikke utvide rammene og endre kravene underveis i implementeringsfasen, spesielt ikke etter at løsningsdesign er vedtatt. Figur 55

To varianter Figur 56 Figur 55 Anvendelses- Valgfasen fasen Implementeringsfasen Valgfasen Anvendelses- fasen Proto- typing Analyse Design Realiser Test Opp- start Klar- gjøring Strategi- og modnings- Beslutning om kjøp om å ta i bruk vurdere kjøp Prosjekt idé Prosjektrevisjon Installasjon Realisering Klargjøring Etterarbeid Valg- Variant 1 viser en tradisjonell såkalt ”fossefallsmodell” der utviklingen skjer sekvensielt trinn for trinn. Dette er sannsynligvis en hensiktsmessig modell når basissystemene, dvs de tunge transaksjonsintensive systemer skal på plass. Ved senere delleveranser kan det være hensiktsmessig å vurdere variant 2 som er en mer iterativ og friere måte å gå frem på. Figur 56 Figur 55

Prosjektorganisering i implementeringsfasen Prosjektleder Delprosjektgruppe: Teknisk infrastruktur Konvertering Integrasjoner Organisasjon Kompetanse Motivasjon Prosesser/rutiner Styringsmodell Kodeplaner/grunndata Prosjekteier (Leder i styringsgruppe) (Daglig leder) Prosjektgruppe: Integrasjon Forenklet prosjektorganisering Fullverdig prosjektorganisering Kvalitets- revisor Styringsgruppen Ledergruppen Prosjektsekretær Konsulenter: Konfigurering Opplæring Installasjon Leverandørens prosjektleder Et implementeringsprosjekt er krevende fordi det krever samhandling mellom leverandørens leveranse- prosjekt og kundens mottaks- prosjekt. Figur 57

Installasjon Installasjon Figur 58 9 E: TEKN. UTSTYR A: ORGANISASJON PC-er, Tjenermaskiner Operativsystemer Nettverk/Skrivere Teknisk infrastruktur A: ORGANISASJON C: DATA D: SYSTEMER Bransjeløsningen For- og ettersystemer Kontorstøtte Systemstruktur 9 Installasjon Installasjon betyr å ”montere” bransjeløsningen på bedriftens tekniske infrastruktur. Infrastrukturen dimensjoneres for å støtte (9) bransjeløsningen effektivt slik at den målsatte responstid oppnås. Figur 58

Design Design Figur 59 5 1 3 10 4 7 Design omfatter både virksomhets- E: TEKN. UTSTYR A: ORGANISASJON B: PROSESSER D: SYSTEMER 1 3 5 C: DATA 7 4 10 Konfigurasjonsplan (3) Lagringsplan (7) Autorisasjonsplan (5) Rapportplan (5) Integrasjonsplan (D) Utviklingsplan (D) Konverteringsplan (D) Kodeplaner (4) Nummerserier (4) Transaksjonsplan (4) Rolleplan (1) Styringsmodell (10) Kodeplaner (10) Design Design omfatter både virksomhets- perspektivet og systemperspektivet. Design betyr å prosjektere den samlede løsning, dvs å planlegge hvordan virksomhet og bransje- løsning skal fungere sammen. Figur 59

Prosesshierarkiet Hovedprosess Prosess ERP- data Figur 60 Aktivitet/ Nedbrytning Ned- brytning Hovedprosess Prosess Aktivitet/ oppgave Transaksjon ERP- data I dette eksempelet bryter vi ned i fire nivåer. Hovedprosessen kan være lønnsadministrasjon (nivå 1) og transaksjonen kan være betaling av feriepenger (nivå 4) Figur 60

Prosessmodellering Figur 61 Aktivitet: Motta faktura Godkjenne Remitterings- forslag Remittere Roller mot prosess (Kopling 1) Økonomisjef Innkjøpssjef Revisor Prosjektleder Avdelingsleder Regnskapsmedarb. Prosess: Faktura- håndtering Prosess- eier Grunndata mot prosess (Kopling 4) Kontostreng Signatur Leverandørnr. Utføre Fakturanr. Innkjøpsordrenr. Bokførings- transaksjon Figur 61

Datastrukturen videreutviklet i designfasen KONTO PROSJEKT Timeverk Ansatt Materialkjøp Materialer Tegning Produksjon ORGANISA- SJONS- ENHET DISIPLIN Etter designfasen viser nå datastrukturen (datamodellen) 4 sett med grunndata konto organisasjonsenhet prosjekt disiplin Dimensjonen ”disiplin” er tilført for å styrke prosjektstyringen ytterligere. Figur 62

Design av kontostreng Konto Prosjekt Disiplin 4010 11200 B20 STØ Organisa- sjonsenhet Prosjekt Disiplin 4010 11200 B20 STØ Alfanumerisk kode Numerisk Dimensjon = elementer (4) på kontostrengen Styringsobjekter Alfa- Klassifisering av inntekter, kostnader og balanseposter Kontostrengen er selve hjertet i et administrativt system. Kontostrengen setter rammer for hvilke analyser man kan foreta på data i databasen. En detaljert kontostreng (mange dimensjoner) vil medføre mer registreringsarbeid. Dette må sees opp mot den nytten mer detaljerte data har for analyseformål. Figur 63

Systemmodell Figur 64 Bransjeløsningen to grensesnitt Komponent B A C Bransjeløsningen E D to grensesnitt fire transaksjonstyper G1 G2 Systemmodellen er en videreføring av figur 51 som viser dagens systemstruktur. Systemmodellen viser hvordan bransjeløsningen skal innpasses blant to gjenværende systemer, og hvordan integrasjonen mot disse skal håndteres. Figur 64

Lagringsplan Sum tabeller Transaksjons- Figur 65 Selskap Dato Trans.- type Kontostreng Beløp Kvantum Sum tabeller Konto Org.- enhet Prosjekt Disiplin Konto (virkelige tall) Konto + Org. enhet (virkelige tall og budsjett) Konto + Prosjekt (virkelige tall og prognosetall) Bokføringstransaksjon Dimensjoner (4) Elementer (5) på kontostrengen Transaksjons- Virkelige tall Budsjetterte tall Justert budsjett I lagringsplanen bestemmer vi hvordan transaksjoner skal summeres og lagres i sum- tabeller. Det er dimensjonene på kontostrengen som er ”nøklene”når summerings-reglene skal bestemmes. Figur 65

Konverteringsprosedyre Database i gammelt system Uttrekks- fil Konverterings- program Korrigert Bransje- løsningen nytt Direkte oppdatering av tabellene (risikabelt) Konvertering kan vise seg å være en meget kostnadskrevende implementeringsaktivitet. Det kreves meget god innsikt i så vel datastruktur som datakvalitet i gammelt system. Datakvalitet, volumer og ulikheter i data formater i gammelt og nytt system danner fundamentet for valg av konverteringsmetode. Figur 66

En moderne skjermrapport basert på BSC Figur 67

Grunnlaget for realisering Designe Realisere Bedriftens forretningsmodell, mål og strategier Bygge/konfigurere bransjeløsningen Påvirker Prosess- modell Transaksjons- plan Design-grunnlag Organisasjons- Rolleplan/ styringsmodell Grunndata- Kodeplaner/Nummers. Kontostreng Konfigurasjonsplan (behandlingsregler) Systemmodell Integrasjonsplan, utviklingsplan og konverteringsplan Rapportplan Autorisasjonsplan (og brukergrensesnitt) Lagringsplan Å bygge vil si å festne bransjeløsningens virkemåte. Dette gjøres ved å legge inn data som beskriver bedriften. Det vil si å legge inn grunndata, parameterverdier og sist men ikke minst, legge inn regler for rapporter, spørre- funksjoner og brukergrensesnitt. Figur 68

Klargjøring Klargjøring Figur 69 5 1 A: ORGANISASJON D: SYSTEMER E: TEKN. UTSTYR A: ORGANISASJON B: PROSESSER D: SYSTEMER 1 5 C: DATA Skape tilgjengelighet til Bransjeløsningen (5) Konvertering (D) Cut-off prosedyrer Forvaltnings- og driftsprosedyrer Opplæring Forvaltningsroller Klargjøring Klargjøring omfatter de siste forberedelser før oppstart på nytt system. Figur 69

Anvendelsesfasen Figur 70 Anvendelsesfasen Prosjektrevisjon Installasjon Design Realisering Klargjøring Etterarbeid Beslutning om kjøp om å ta i bruk vurdere kjøp Prosjekt idé Erkjennelse Sondering Strategibehandling Motivering Strategi- og modningsfasen Valgfasen Prosjektetablering Situasjonsanalyse Strategisk analyse Kravspesifisering Tilbudsinnbydelse Evaluering/Valg Implementeringsfasen Anvendelsesfasen Planprosesser Utviklingsprosesser Forvaltningsprosesser I forbindelse med oppstart overleveres prosjektets resultater til linjen. I anvendelsesfasen er det et klart mål å realisere de gevinster (nytteverdi) som er beregnet. I tillegg er det et klart mål å videreutvikle bransjeløsningen for nye bruksformål i organisasjonen. Dette krever kontinuerlig oppmerksomhet og nytenkning. Ikke minst er det viktig at nye ideer til forbedringer i programvaren tilflyter programvareleverandør. Figur 70

Anvendelsesfasen i et bredt perspektiv Plan- prosesser Utviklingsprosess (Prosjekt) 1. driftsår 2. driftsår 3. driftsår Forvaltningsprosesser Utviklingspr. I planprosessene planlegges og budsjetteres kommende delleveranser for eksempel nye moduler og nye brukergrupper. I prosjekt/Tiltaksprosessene realiseres delleveransene I forvaltningsprosessene ivaretas den løpende drift av bransjeløsningen Figur 71A

Utvikling IKT kjøreregler Detaljer IKT-kjøreregler Retningslinjer Applikasjoner og data Obligatorisk programvare Rollebasert programvare Teknisk Infrastruktur Personlig teknisk infras. Felles teknisk infrastruktur IKT-organisering og -styring Planprosesser Utviklingsprosesser Forvaltningsprosesser Retningslinjer Prosedyrer Standarder Metoder Utvikling Detaljer For at en integrert systemløsning skal kunne fungere effektivt over tid, må den videreutvikles i takt med brukernes behov. En slik utvikling kan ikke skje uten at man følger et antall omforente regler. I dette bildet vises hvordan reglene er organisert i forhold til tre hovedtemaer. Innenfor hvert hovedtema vil det kunne formuleres retningslinjer, prosedyrer, standarder og/eller metoder. Figur s. 229

En måte å se de store sammenhenger på E: TEKN. UTSTYR A: ORGANISASJON B: PROSESSER D: SYSTEMER C: DATA IKT-kjøreregler Applikasjoner og data Teknisk infrastruktur IKT-organisering og -styring Retningslinjer Prosedyrer Standarder Metoder Visjon O P D S T Planlegge Utvikle Forvalte Langsiktig målarkitektur målarkitekturer Figur 71B

Sammenhengene OPP- ROLLE GAVER Figur 72 MED- AVDELING ARBEIDER En rolle kan tildeles en eller flere oppgaver En medarbeider kan inneha en eller flere roller En avdeling har flere medarbeidere Rollebegrepet er populært,og benyttes i mange sammenhenger. Forvaltningsroller (systemeier, systemadministrator etc.) Brukerrolle (innkjøper, selger, økonomimedarbeider etc.) Aktørrolle (programvareleverandør, ASP, infrastrukturleverandør etc.) Figur 72

Organisering av IT-funksjonen Enkel organisering Delt organisering Systemeier/ IKT-ansvarlig Brukermiljø Systemadministrator/ Driftsansvarlig Vedlikeholdsansvarlig Sluttbrukere Programvareleverandør Infrastrukturleverandør Super- brukere Utviklings- ansvar Vedlikeholds- Serviceansvar Kontrakter Funksjonell brukerstøtte/ Teknisk brukerstøtte Systemeier IKT-miljø System- administrator Drifts- ansvarlig IKT-sjef Oppdrag Teknisk brukerstøtte Funksjonell EKSTERNT INTERNT LINJE STAB/STØTTE Uansett om bedriften er stor Eller liten er det de samme typer forvaltningsoppgaver som skal utføres. Alle roller må ivaretas. I en liten bedrift vil imidlertid hver enkelt forvaltningsoppgave kreve mindre ressursinnsats. Derfor kan én og samme person påta seg flere roller. Figur 73

Anvendelsesfasen i detalj Det sies ofte at IKT-strategiarbeid krever en multimetodisk tilnærming. Det betyr at man må benytte flere metoder parallelt, ofte grovt betegnet som: Top-down tilnærming Bottom-up tilnærming Inside-out tilnærming Strategisk analyse tolkning av forretningsstrategier og mål (Top-down tilnærming) Mulighetsanalyse innovasjon og nytenkning (Inside-out tilnærming) System- & prosjektrevisjon styrker og svakheter innen IKT området (Bottom-up tilnærming) IKT- strategirevisjon IKT-visjoner & IKT-mål IKT-prosjekter IKT-tiltak ”IKT-Kjøreregler” Overlevering av prosjektresultater til drift (forvaltning) Utviklingsprosesser Plan- prosesser P1 P2 P3 Igangsetting av prosjekter og tiltak Forvaltningsprosesser Teknologiforvaltning Systemforvaltning Kunnskapsforvaltning Figur 74

Systemrevisjon Systemrevisjon Figur 21 5 3 9 7 A: ORGANISASJON Medarbeidere Organisasjonsstruktur Rollestruktur Selskapsstruktur Geografisk struktur 5 B: PROSESSER Primær prosesser Støtteprosesser Prosess-struktur D: SYSTEMER Bransjeløsningen For- og ettersystemer Kontorstøtte Systemstruktur 3 E: TEKN. UTSTYR PC-er, Tjenermaskiner Operativsystemer Nettverk/Skrivere Teknisk infrastruktur D: SYSTEMER Bransjeløsningen For- og ettersystemer Kontorstøtte Systemstruktur 9 7 C: DATA Systemrevisjon vil si å foreta en regelmessig kritisk gjennomgang av bransjeløsningen med sikte på å avklare bl.a. om: Løsningen anvendes som forutsatt. Løsningens oppetider og responstid er som planlagt Løsningens funksjonalitet er i henhold til spesifikasjonene Løsningens grunndata har den nødvendige kvalitet Brukernes kompetanse er tilstrekkelig god. Grunndata Datastruktur Figur 21

Flere tiltak og prosjekter, men én visjon VISJONEN UØNSKET SITUASJON ØNSKET Alle tiltak og prosjekter som iverksettes i anvendelsesfasen skal naturligvis være gjenstand for en kost/nytte vurdering. I tillegg er det viktig å sikre at prosjekter og tiltak fungerer som byggeklosser mot en klart uttrykt visjon. Det handler om å se tiltak og prosjekter samlet. Figur 76

Mulighetsanalyse Mulighetsanalyse Strategisk analyse Systemrevisjon system- og prosjektrevisjon Resultater fra strategisk analyse Strategisk analyse Systemrevisjon ORGANISASJON SYSTEMER Bransjeløsningen TEKNISK UTSTYR DATA PROSESSER 5 9 3 7 Tolkning av de premissgivende kilder Utviklingstrekk som er av betydning for systemvalg og systemtilrettelegging Sannsynlige IKT- konsekvenser KILDER Resultater fra samarbeidet i kompetansenettverket Mulighetsanalysen er en kreativ prosess. Det betyr at mulighets- analysen ideelt sett er ”uforpliktende” og ikke begrenset av mangel på investeringsmidler, ressurser til realisering etc. I mulighetsanalysen skal vi høste ideer, både gode og mindre gode ! Figur 77

IT-strategirevisjon; Klassisk modell IKT-visjoner IKT-mål IKT- prosjekter og tiltak Ansvar Nytteeffekter Budsjett H A N D L I N G S P L A N Retningslinjer Prosedyrer Standarder Metoder ”IKT- kjørereglene” IKT-strategi Strategisk analyse Tolkning av forretningsstrategier og mål Top-down tilnærming Mulighetsanalyse Innovasjon og nytenkning Inside-out tilnærming System- & prosjektrevisjon Styrker og svakheter innen IKT-området Bottom-up tilnærming Analyse Strategirevisjon Figur 78

IT-strategirevisjon; Modell tilpasset elektronisk forretningsdrift Forretnings-visjoner & mål IKT-visjoner & mål Retningslinjer, Prosedyrer Standarder, Metoder ”IKT-kjøreregler” Strategirevisjon Analyse E-handel som fenomen E-handel innen vår bransje E-handel innen våre segmenter Kundenes forhold til e-handel Systemleverandørens forhold til e-handel Infrastrukturleverandørens Salgsvolumer og resultater Leverandørenes forhold til e-handel Leveransekvalitet Kundelojalitet/kjøpsmønster E-analyse Mulighets- og modenhetsanalyse Eksternanalyse Nøkkeltallsanalyse Internanalyse Konsekvenser for elektronisk forretningsdrift Organisasjon Prosesser Data Systemer Infrastruktur Prosjekter & tiltak Plan År 1 – år n Hvordan realisere og forvalte Hva som skal realiseres ”Forretningskjøreregler” Figur 79

Kunnskapsforvaltning Kompetanse- mål Trigger Virkelig Kompetanse Opp- læring Bruker- møter støtte Erfarings- utveksling Systemdokumentasjon FAQ-database E-læringsverktøy Brukerdokumentasjon Konfigurasjonsstyring Egen- trening Rekrut- tering Kunnskapsdatabase IKT-kjøreregler Retningslinjer Prosedyrer Metoder Standarder Forvaltning Med kunnskapsforvaltning forstår vi alle de aktiviteter som gjennomføres for å sikre at brukerne utvikler og vedlikeholder en kompetanse som gjør dem i stand til å dra nytte av bransjeløsningen Figur 80

Teknologiforvaltning SNA Trigger Virkelig leveranse- kvalitet Sikkerhets- kopiering Infrastruktur- overvåking Oppgradering/ Installasjon Teknisk service Konfigurasjonsstyring Konfigurasjonsbeskrivelser Konfigurasjonstabeller Servicenivåavtaler Kontrakter Dokumentasjon (teknisk utstyr) Kunnskapsdatabase IKT-kjøreregler Retningslinjer Prosedyrer Metoder Standarder Forvaltning Med teknologiforvaltning forstår vi alle de aktiviteter som gjennomføres for å sikre at bransjeløsningen er tilgjengelig for den enkelte bruker via nettverket i henhold til avtalt servicegrad (servicenivåavtale, SNA) Figur 81

ASP: Application Service Provider Livsløp Hovedproduktet bransjeløsningens funksjonalitet Implemen- teringsår 1. driftsår 2. driftsår Siste driftsår Støtte- produkt: tering Opplæring/ trening Prosess- design Support Drift 3. driftsår Den tradisjonelle definisjonen av en ASP er relatert til leveranse av ”rene” driftstjenester. Utviklingen går i retning av at en ASP tilbyr et bredt spekter av tjenester knyttet til hele livsløpet. Figur 82

Konfigurasjonsstyring Systemforvaltning Konfigurasjonsbeskrivelser Systemdokumentasjon Kontrakter Feilmeldinger ”Forslagskasse” (nye behov) IKT-kjøreregler Kunnskapsdatabase Retningslinjer Prosedyrer Forvaltning Metoder Standarder Konfigurasjonsstyring Trigger Administrere grunndata og styredata Administrere bruker- profiler Administrere feil- meldinger Administrere nye behov Administrere kontrakter Virkelig leveranse- kvalitet Oppdrag Med systemforvaltning forstår vi alle de aktiviteter som bidrar til at bransjeløsningens funksjonalitet og virkemåte er i henhold til bedriftens behov. Figur 83

En lang rekke av effekter Bedre grunndata analyser prosesser Større kunde- tilfredshet Økt omsetning Mer rasjonell drift deknings- bidrag ”bunnlinje” De effekter vi oppnår ved bruk av bransjeløsningen kan ikke sees helt uavhengig av hverandre. Én positiv effekt, for eksempel bedre analyser, vil kunne gjøre bedriften i stand til å identifisere svakheter i prosessene, og dermed legge et grunnlag for å forbedre disse. Figur 84