1

1

Bilag Bilag 1 ”Verifikation af opdrag” ....................................................................................................................... 2

Bilag 2 ”D-IMM undersøgelsen” ...................................................................................................................... 3

Bilag 3 ”Den tykke beskrivelse” ....................................................................................................................... 9

Teknik og infrastruktur (T&I) ................................................................................................................... 9

Kerneprocesser ........................................................................................................................................ 10

Støtteprocesser ......................................................................................................................................... 13

Bilag 4 ”ITIL projektet, som blev lagt på is” .................................................................................................. 16

Bilag 5 ”Continual Service Improvement” ...................................................................................................... 18

Bilag 6 ”Interviews” ........................................................................................................................................ 20

Bilag 7 ”ITIL Terminologi” ............................................................................................................................ 46

Bilag 8 ”RFC Flow” ........................................................................................................................................ 55

Bilag 9 ”Proceslog” ......................................................................................................................................... 56

Bilag 10 ”Parlør” ............................................................................................................................................. 66

Bilag 11 ”Change Management” ..................................................................................................................... 70

2

2

Bilag 1 ”Verifikation af opdrag” Dette bilag indeholder en mailudveksling mellem mig og projektlederen af It-effektiviseringsprojektet.

Mailen er en verifikation af det opdrag som jeg er blevet stillet af Energinet.

Min mail til birger:

(Note: ”software suiten” er Birgers eneste rettelse til opdraget, hvilket er markeret med rødt nedenfor.)

Hej Birger,

Vil du ikke læse følgende igennem og sige mig om jeg har forstået dit opdrag korrekt?

Min kontakt til Energinet er skabt via en skriftlig ansøgning, om at skrive masteropgave hos Energinet.

Birger, som er projektleder på It-effektiviseringsprojektet, har givet mig den opgave, at undersøge og komme

med anbefalinger til en serviceorientering af deres fremtidige Change Management arbejdspraksis.

Rammerne for mit arbejde er, at jeg skal tage udgangspunkt i ITILv3 frameworket (APM Group, 2011) og at

It-systemet (Microsoft Service Manager) allerede er købt. Årsagen til at jeg skal tage udgangspunkt i ITIL er,

at det er den terminologi man bruger i branchen og at det er i ITIL frameworket inspiration til de fælles

retningslinjer skal hentes. Microsoft Service Manager har Energinet valgt, da de i forvejen har flere

Microsoft standardprodukter, heriblandt software suiten ”Microsoft System Center” (Microsoft, 2011),

hvortil ”Service Manager” er en relativ billig tilføjelse.

Mvh,

Thomas

Svar fra birger:

Hej Thomas,

Se minimaltilføjelse med rødt. Ellers perfekt.

Mange hilsner

Birger

3

3

Bilag 2 ”D-IMM undersøgelsen” Devoteam er et af Danmarks større konsulenthuse og har en meget stor kundeportefølje. Deres resultater må

derfor, som udgangspunkt, antages for at være gyldige som empirisk grundlag, når de udtaler sig om

Energinet. Rapporten er et potentielt nyttigt redskab i min opgave, da den giver mig mulighed for, på kyndig

og nutidig baggrund, at konkludere visse ting uden selv at skulle ud og undersøge. Nedenfor er de noter jeg

har gjort mig i forbindelse med gennemgang af rapporten. Det er tydeligt at jeg ikke er helt tilfreds med

undersøgelsen, men her er det vigtigt at huske på at rapporten primært handler om It-infrastrukturen og kun

løseligt om It-organisationen. Derfor kan nogle af konklusionerne, der omhandler ”Service Processer”, virke

tvivlsomme. Ser man på de ting der omhandler It-infrastrukturen på teknisk niveau, så mener jeg at

Devoteam har givet en nuanceret modenhedsanalyse. I afsnit ??? ”D-IMM rapporten” forklarer jeg hvorfor

jeg ikke bruger denne rapport som empirisk grundlag.

Nota Bene: Alt der herunder er skrevet med kursiv er citater fra rapporten, som jeg kommenterer.

Selve undersøgelsen må, i henhold til Devoteams intellektuelle rettigheder, ikke offentliggøres og er

derfor ikke vedlagt som bilag.

Hvad har Energinet bedt om?:

En “it-infrastrukturmodenhed ud fra en It-teknisk og driftsmæssig vinkel og i begrænset omfang også et

organisatorisk perspektiv”.

Formålet med undersøgelsen?:

“...at opnå en mere effektiv it-drift gen-nem processer, standardisering og automatisering. It-effektiviserings-

projektet er en del af Energinet.dk’s it-strategi.”.

Hvordan vil de gøre det?:

“Devoteams it-Infrastruktur ModenhedsModel (kaldet D-IMM) suppleret med interview af nøglepersoner i

forretningen og it-organisationen og Devoteams erfaringer med vurdering af it-organisationer.”

Note: Lige før den samlede vurdering står der at, “Ud fra det indsamlede materiale danner der sig et billede

af, hvor Energinet.dk med fordel kan tilpasse virksomhedens it-organisation.”. Dette understreger at der

alene er blevet skelenet til It-organisationen og It-infrastruktur. Ikke til en decideret serviceorientering It-

organisationen.

Devoteams overordnede vurdering:

1. Energinet.dk har investeret i en moderne it-infrastruktur, der understøtter et højt niveau af

driftsstabilitet.

2. Procedurer og processer er ikke prioriteret på tilsvarende høje niveau.

3. Processer og procedurer afspejler retninger og valg, der i flere tilfælde ikke harmonerer med it-

strategien (f.eks. forventning om SLA eller fokus på dekommissionering og konsolidering).

4. Et meget højt fokus på it-udvikling har reduceret den forebyggende (pro-aktive) it-drift.

4

4

Undersøgelsens hovedkonklusion er, at, “Energinet.dk’s it-organisation grundlæggende er bygget op

omkring en meget moderne it-infrastruktur, der lever op til god markedspraksis.”

Devoteam mener at Energinet skal have fokus på følgende grundlæggende principper indenfor it-området:

Forenkling og ensretning

Dokumentering og opfølgning

Proaktive processer

”Alignment problemer” (D-IMM s.4)

“På mange områder har Energinet.dk stærke individuelle kompetencer og gode processer, men det virker

som om, at formidling til og afstemning med forretningen er mangelfuld. Derfor fremstår det i nogle

sammenhænge, som om it-organisationen ikke lever op til forventningerne.”.

Indsatsområderne (D-IMM s.4 og frem):

Generelt:

Jeg ved ikke hvordan de er kommet frem til prioriteringen, men i teksten oven over fremgår det at fokus er

på effektivisering. Altså, må der være prioriteret i henhold til Devoteams vurdering af hvad der vil føre til

effektivisering.

I vurderingerne af indsatsområderne er det ikke gennemskueligt om det er interviews eller

spørgeskemaresultaterne, som har været afgørende. Dette gør at man ikke ved om der er tale om beslutninger

baseret på et enkelt udsagn eller på en generel holdning. I sidste ende må man stole på Devoteams

vurderinger.

Helpdesk:

Der skal forenkles og skabes overblik.

Det sidste punkt ang. automatisering er et enkeltstående tilfælde af ineffektivitet, der falder uden for det

generelle niveau der ellers vurderes ud fra.

Serviceprocesser:

Standardisering og kategorisering af arbejdsprocesserne.

Manglende kommunikation/forståelse mellem forretning og It.

It-infrastruktur skal systematiseres.

Igen er et enkeltstående tilfælde nævnt (incident mgm.), hvor de andre kommentarer er mere generelle.

Dokumentation:

Mere dokumentation og standardisering af dokumentation er påkrævet.

“Dokumentere processer, roller og ansvar”

Kompetencer:

Devoteam mener at vidensdeling halter lidt (Ikke særlig højt prioriteret).

5

5

Brugere:

Generelt er fundamentet for It ikke automatiseret.

“Politik og retningslinjer for anvendelse af udstyr og data” og “Ingen eller begrænset antal

lokaladministratorer på pc”. (aftaler om hvem der må hvad på operationelt niveau).

Infrastruktur:

Ingen kommentarer. Dette handler om risiko for nedbrud = teknisk optimering.

Sikkerhed:

Ingen kommentarer. Dette handler om risiko for nedbrud = teknisk optimering.

Afsnit “Hvad skal der så til for at gennemføre ovennævnte punkter?” (D-IMM s.5):

“Hvad skal der så til for at gennemføre ovennævnte punkter? Først og fremmest fremgår det, at tid er en

knap ressource i Energinet.dk. Ethvert projekt kræver uanset størrelse og vigtighed, at der kan afsættes den

fornødne tid og prioritet, og at prioriteringen respekteres. Der bør derfor indledningsvist fokuseres på de

indsatsområder, der kunne medvirke til at skabe luft i it-organisationen.”

Spørgsmålet “Hvad skal der så til for at gennemføre ovennævnte punkter?” går på hvad Energinet skal gøre

for at implementere anbefalingerne. Dog vendes fokus til at handle om at Energinet skal implementere de

anbefalinger, der giver mere tid til egne forretningsprojekter. Har Devoteam misforstået egen ‘template’?

Eller mener Devoteam at tidsbesparende initiativer har størst prioritet fordi Energinet har brug for mere tid til

deres projekter?

Alt andet lige, så er jeg enig med Devoteam i at, “Alle nye tiltag bør sikres forankring i forretningen,

primært gennem kommunikation, men også ved behovsafstemning og klare aftaler.”. Dertil vil jeg gerne

tilføje at ledelsen skal involveres, som værende øverste ansvarlige for forankring og opfølgning.

Nuværende It-situation:

Tre gamle firmaer = Energinet.

To distribuerede ‘datacentre’.

Udfordringer:

- Bindes mange ressourcer i manuelt rutinearbejde

- System-ø’er, men arbejder på standardisering og integrering.

- Drift og udvikling af it “ressourcer” bliver ledelsesmæssigt blandet sammen

Svaghed ved analysen:

“I enkelte tilfælde opnår It-afdelingen en bedre score på et højere niveau end på det

underliggende niveau – f.eks. for området Data Management i ovenstående tabel,

hvor It-afdelingen scorer 60% på Rationalized-niveau, men kun 50% på Standardized-

niveau. Dette kan være begrundet i flere ting, men skyldes oftest, at:

Scoren på det højere niveau baserer sig på ”ønsketænkning”, dvs. at besvarelsen

afspejler den situation, som man har planlagt, men endnu ikke nået”.

Dette er netop årsagen til at jeg, som nævnt i afsnittet “???Undersøgelsesdesign” har planlagt at observere og

ikke kun gøre brug af spørgeskemaer og interviews. Fremtidige ønskværdige tilstande og ‘usandheder’ er

6

6

noget af det der kan forplumre billedet.

Dette understøttes også af følgende forklaring:

“Blanketter og systemer findes og bruges i it-organisationen, men at den understøttende proces ikke er

defineret eller kommunikeret til forretningen. Hvis processen rent faktisk efterleves, er det ofte forbundet

med en stor manuel indsats”.

Her ses at It-arbejdsprocesserne ikke er ordentligt forankret/brugt i den øvrige virksomhed, hvilket sår tvivl

om validiteten af alle tallene omhandlende “Data Management”. Man kan kun håbe på at undersøgelsens

øvrige svar er mere troværdige

Update: det skal senere vise sig at ”Support Processer” heller ikke er korrekte/troværdige.

Konsekvens: Der er et delta mellem resultatet og den faktiske situation hos Energinet.

Samlet vurdering: (D-IMM s.12)

“Modenhedsvurderingen afspejler dog en noget fragmenteret og ufokuseret indsats, hvor der arbejdes på

rigtigt mange ting med minimal prioritering, hvilket kunne skyldes en meget bred it-strategi.”

Det er en god diplomatisk udlægning. Jeg savner dog nogle mere konkrete bud på hvad der kunne være galt.

Set i lyset af, at rapporten fokuserer på It-infrastrukturen, så er det uden for scope, men alligevel korrekt at

udfordringerne er af strategisk karakter.

I vurderingen afsluttes der med at kommentere “It-infrastruktur” resultaterne:

“Det er Devoteams vurdering, at Energinet.dk bør fokusere på at fuldende opfyldelsen af Standardized-

niveauet og udbygge den høje score på Rationalized-niveauet i det tempo, det passer ind i organisationens

udvikling. Energinet.dk bør dog ikke på nuværende tidspunkt fokusere på opfyldelse af kravene på

Dynamics-niveau. Meget høje scorer under ”Dynamic” uden at have de to underliggende niveauer på plads

kan være meget omkostningstungt og i hvert fald trække vigtige ressourcer væk fra opfyldelsen af de

underliggende niveauer.”

Det er korrekt. Man skal have sit “Foundation for execution” på plads. Skal man tro tallene på side 11, så vil

jeg mene at Energinet (Infrastrukturmæssigt) er på et fint niveau og vil gavne af at følge Devoteams

prioritering af indsatsområder.

I rapporten kan Devoteam ikke lade være med at nævne alle de administrative udfordringer der er associeret

med It-infrastruktur domænet. Rundt om i rapporten nævnes symptomer som:

- ”Fragmenteret og en ikke fokuseret indsats”.

- ”Alle nye tiltag bør sikres forankring i forretningen, primært gennem kommunikation, men også ved

behovsafstemning og klare aftaler”.

- ”Anbefaling: Politik og retningslinjer for anvendelse af udstyr og data”.

- ”Dokumentere processer, roller og ansvar”.

- ”Det virker som om, at formidling til og afstemning med forretningen er mangelfuld”.

- ”Processer og procedurer afspejler retninger og valg, der i flere tilfælde ikke harmonerer med it-

strategien.”

Dette tyder helt klart på, at et behov for at få styr på den adfærd, der eksisterer i forbindelse med brugen

af It. Denne adfærd skal styres af dokumenterede retningslinjer og fastlagt ansvar for virksomhedens It-

beslutninger.

D-IMM: “Support Process”:

Dette afsnit omhandler bl.a. Change Management, som er den proces Energinet har bedt mig analysere

7

7

og komme med ITSM anbefalinger til.

Uden at nævne hvilken, så omtaler Devoteam en kompleks It-organisering, der er gearet til store

virksomheder. Dette ser de ikke umiddelbart nogle problemer med, hvis ikke det var fordi at, “ansvar og

grænsesnit ikke er veldefinerede og forankrede”. Uden uddybning, konkluderer Devoteam at

Energinet.dk generelt mangler, at foretage ensretning og forenkling af processer indenfor Change- og

Incident Management. Dette er på trods af, at D-IMM undersøgelsen viser en høj modenhed for disse to

punkter, som de eneste to blandt de målte processer?! Undersøgelsen viser derimod, at der generelt

mangler serviceaftaler mellem It og forretningen. Service Level Management er et område der score 0%

i “Standardized”, hvilket ellers ville tale for et fokus på denne proces.

Ikke mindre end 5 af processerne har utroværdige data, hvor “Rationalized” har en højere score end

“Standardized” eller hvor “Dynamic” er højere end “Rationalized”. Der er inkonsistens i tallene, når man

sammenligner oversigtstabellen s.11 med detailtabellen (talt sammen) s.26. “S” burde kun være rundet

op til 40% (og ikke 50%), “R” burde være rundet op til 50% (og ikke ned til 40%). Altså, er

procentsatsen for “S” mindre end “R” og dermed inkonsistent, som i tilfældet med “Data Management”.

Dette kommenteres dog ikke i rapporten, men det kan selvfølgelig være at “S” og “R”, efter afrunding, er

byttet om ved en fejl.

Support Processes B S R D

Oversigtstabel: 100 50 40 20

Detailtabel: 100 36,6 45 23,3

Korrekt afrundet Detailtabel: 100 40 50 20

I D-IMM rapportens ”Bilag1”, kan man se spørgsmålene der er besvaret overvejende negativt og dermed

trækker ned. Man kan se at der kun er ét ’issue’ der skal til for at “S” kommer op på 100% for “Change

Management”, men man kan ikke præcist se hvilket spørgsmål/issue der er tale om. Måske kan man gætte

sig til det ved at se på prioriteringstabellen (Bilag 2) på side 60. Her er “Serviceprocessen “Strukturere

change management (systemer og proces)” nævnt som den første af Serviceprocesserne i “Prioritet 1”

kolonnen.

Change Management:

“I D-IMM undersøgelsen peger tallene på, at Energinet.dk har implementeret mange tiltag for ”Change

Management”. Interviewene viser dog, at implementeringen i praksis er for kompleks, og at ”Change

Management ikke fungerer optimalt. Eksempelvis findes der flere forskellige systemer til ”Change

Management” relaterede opgaver, hvilket gør, at ændringsforslag eller requests oprettes og gennemføres på

vidt forskellige måder indenfor virksomheden.

Der bør anvendes ét change-system, én proces, og én klar oversigt over roller og ansvar. Alt andet bidrager

udelukkende til at skabe forvirring samt en dårlig udnyttelse af de involverede ressourcer.”.

Denne vurdering er jeg enig i. Jeg kommer selv til at undersøge dette felt i mine observationer og regner med

8

8

at støtte op om denne holdning, omend i en noget mere nuanceret udgave.

Devoteams vurdering er primært fokuseret på ”It-infrastructure”, så her nævner de at en fælles database til

Asset Management bør vedtages. Den løsning, som Energinet anvender i dag, opfatter Devoteam som

værende rodet og med data af svingende kvalitet.

Generelt ser det ud som om Devoteam her forslår at tage ITSM mere aktivt i brug (de nævner at Energinet

skeler til ITIL).

Forretningens syn på It-organisationen:

Helpdesk:

“I Helpdesk-systemet registreres fejl og requests på samme måde, hvilket i nogle sammenhænge har ført til

forvirring. Desuden har kompleksiteten medført, at der er opstået parallelle løsninger baseret på Sharepoint.

Disse side-løsninger håndterer måske de daglige problemer for brugerne, men de formindsker muligheden

for et samlet billede af it-requests og -ændringer.”

Utilpassede It-systemer gør at Change Management og alm. Support bliver rodet sammen. Parallelløsninger

bliver foretaget i Sharepoint.

Serviceprocesser:

“På flere områder kan man se delvis anvendelse af ideerne i ITIL, men anvendelsen er sporadisk og fremstår

uden en konkret strategi og plan.”

Her fremgår det tydeligt at Devoteam fremhæver at ITSM er noget der skal planlægges og forankres på

strategisk niveau. Det er ikke noget man opnår de tiltænkte fordele ved, hvis man bruger det sporadisk. De

siger dog ikke lige ud at Energinet skal indarbejde ITIL frameworket i organisationen.

“Der findes mange måder at gøre tingene på i Energinet.dk, og de fleste er meget personafhængige og

udspringer ikke af nogen fast defineret proces. Dette har til dels begrundelse i, at virksomheden har behov

for en høj grad af fleksibilitet og enkelhed, som understøtter en meget travl og omskiftelig hverdag.”.

Min kommentar: Men findes der en “mere optimal” måde at gøre det på? Eller er det mest optimalt at alle

gør det på deres egen måde?

Devoteam foreslår Change Management som en god proces at starte med. Anbefalingen er at, “Her bør der

fokuseres på, at anvende én proces, ét system, og ikke mindst klare ansvarsroller og grænse-snit (som

fastholdes).”.

Rent processuelt fremhæver Devoteam et ønske fra brugerne om at, “...man i denne proces er konsekvent

med, hvem der gør hvad, og hvordan man overdrager til hinanden, så ting ikke falder mellem to stole. Den

samme opfattelse gør sig generelt gældende for alt der vedrører ”requests”.”

Bilag 3 “Interviewguide”:

Idenholder en række spørgsmål, som enten er generelle eller har fokus på support fra It-afdelingen. Det ser

ud til at pointen er at få så mange problemer på bordet som muligt. Det generelle i interviewguiden gør at

den kan bruges til hvilken som helst brug.

9

9

Bilag 3 ”Den tykke beskrivelse” Dette bilag indeholder en redigeret udgave af ”den første meningskondensering”. Der er ting fra

undersøgelserne jeg vælger ikke at offentliggøre, da jeg har lovet at behandle al information ud fra en

konstruktiv tilgangsvinkel. Altså er dette bilag en letlæselig beskrivelse af det meningskondenserede

lydmateriale1 fra mine samtaler med Energinet.

Teknik og infrastruktur (T&I)

”Teknik og Infrastruktur” (T&I) varetager It-afdelingens basale ydelser. De håndterer alt omhandlende

netværk og servere, inklusiv servernes operativsystemer. De har dertil også noget applikationsansvar i

forretningen. Teknik og infrastruktur er delt logisk op i 4 områder:

- Helpdesk (Peter Madsen + 4 folk)

- WAN (Bruger Change Management meget lidt.)

- LAN (Bruger Change Management meget lidt.)

- Kontor-It/Platform (I de 8 lokale Energinet centre). Erritsø og Egtved er de to primære sites. Alt It på

transformatorstationer m.m. er ikke inden for scope, men ansvaret er alligevel Teknik og

Infrastrukturs.

Der bruges Change Management i T&I i forbindelse med Helpdesk og når hhv. ”Kerneprocesser” og

”Støtteprocesser” skal bruge T&Is ydelser.

I T&I kommer Change Management opgaverne ind på fire måder:

1) En ”Change” (RFC) proces.

2) En ”Request” proces.

3) ”HP Servicecenter”, hvor Helpdesk får deres opgaver ind. Her kan en RFC også oprettes af en

”tildeler” eksempelvis fra gruppen Støtteprocesser (se nedenfor).

4) Diverse uformelle kommunikationsveje, som f.eks. telefonopkald direkte til Steen i T&I.

RFC processen foregår kort sagt ved at en RFC udfyldes vha. et blanketsystem i applikationen ”MS

InfoPath” (XML baseret). Derefter er der en revideringsfase, som, hvis den bliver godkendt, går videre til en

implementeringsfase, for til sidst at gennemgå en testfase. Når en ændring er ’deployet’, så revideres

processen og der sker en evaluering af RFC’en med en ’score’ udregnet efter forskellige parametre.

På baggrund af scoren bliver der lavet en månedlig rapportering til ledelsen over Change Management

processen. Rapporteringen bruges af ledelsen til at få indsigt i Change Management indsatsen. Dog bliver

Change Management arbejdet ikke brugt til at være proaktive2 og derfor udføres rigtig meget arbejde på

’bagkant’. Dette har medført, at Change Management bliver set på som ekstraarbejde, der kun udføres for at

lederne skal have noget at træffe beslutninger ud fra. Det er med andre ord ikke noget der gavner

arbejdspraksis hos dem der udfører dette administrative stykke arbejde. Blanketsystemet er ikke

automatiseret eller integreret med andre systemer på nogen måde, hvilket vil sige at det heller ikke er

integreret med andre systemer. Steen betegner systemet som ”Ikke godt, men OK”. Problemerne

omhandlende disse ’effektivitetsproblemer’ er en del af ”de skjulte accountabilityproblemer” (se afsnit ???

Metabeskrivelsen). Steen nævner dog at fordele begynder at vise sig, da Kerneprocesser og Støtteprocesser

1 Lydmaterialet har jeg ved hver samtale lovet er til mit eget personlige brug og vil således heller ikke blive

offentliggjort. 2 Viden om f.eks. opgraderinger der ofte fejler, kan proaktivt bruges til at være ekstra påpasselig.

10

10

bruger RFC listen som huskeseddel til opfølgning. Rapporteringen hjælper derudover T&I med synliggørelse

udført arbejde (se ”Det manglende overblik - Informationsøer” i afsnit ???).

Både ”Kerneprocesser” og ”Støtteprocesser” bruger dette system, når de ved at en ændring skal udføres af

T&I. Når ændringer er indgivet til T&I, så er der ingen porteføljestyring eller prioritering. Systemet giver

således ikke mulighed for at se status, således at man ved i hvilken fase RFC’en er eller hvornår man kan

forvente ’der sker noget’. Denne manglende status er en delmængde af RFC’ens samlede

accountabilityproblem (se afsnit ???).

T&I foretager en graduering af RFC’ernes vigtighed, så de kan prioritere arbejdet, men denne graduering er

ikke eksplicit nok til at folk forstår den. Forklaring følger i afsnit ???, hvor Willem udtrykker sin, til tider,

manglende forståelse for gradueringen.

Forskellige folk udfylder ydemere felterne i RFC blanketten forskelligt, da den opfattes flertydigt. Dette

problem er relateret til en generel begrebsforvirring, som jeg kommer nærmere ind på i de to følgende afsnit.

Når der skal ”deployes”, så eksisterer der ingen servicevinduer, men det er en velkendt uformel aftale i hele

It-afdelingen at der ikke må ske ændringer om fredagen eller op til ferier. Engang blev en ændring deployet

lige før en julefrokost, hvilket gik galt, og af skade bliver man klog. Så vidt muligt tilstræbes det derfor, at

lave ændringerne tirsdag og torsdag, men undtagelser sker, når det er nødvendigt. Altså er der en vis

accountability i aftalen, der sikrer rationel adfærd (se afsnit ???).

I T&I skelnes der mellem en ”Request for Change” (RFC) og en ”Request”. Der er en MS InfoPath (se bilag

??? Parlør) blanket til hver ’kategori’. Internt i T&I hersker nogen forvirring om forskellen på ”Change”,

”Incident” og ”Request”. Selv staben ”Relation Management” har svært ved at se forskel på, hvad der er en

Request og hvad er en Change. Dette problem går igen i de følgende afsnit og er relateret til den generelle

begrebsforvirring (se evt. afsnit ???).

Kerneprocesser

Gruppen ”Kerneprocesser” udgør én af tre grupperinger i It-afdelingen. Kerneprocesser er ”It-systemejer”

(også kendt som ”Applikationsansvarlig” eller ”Applikationsejer) for de 3 systemansvarlige: NOIS, DPS og

SCADA. Kerneprocesser arbejder sammen med forretningen i styringen af ændringer til systemerne (NOIS,

DPS og SCADA). Gruppen har ”1’st level support” overfor kunder (primært kontrolcenter) på systemerne.

Helpdesk har supporten på andre mere trivielle ting. Der er med andre ord ikke ”Single Point of Contact” til

It-afdelingen, set fra brugernes synspunkt.

Folk hos Kerneprocesser udfylder en Request for Change (RFC), hvortil de bruger T&Is RFC

(InfoPath) blanket, da ændringer deployes af T&I. Systemet SCADA er specielt, da et trediepartsselskab

(Alstom) har ansvaret for udvikling, test og deploys af ændringer. T&I står dog stadig for drift af

infrastrukturen. Når T&I skal lave en ændring på SCADAs infrastruktur, så informerer de selv SCADA

kunderne. NOIS udvikles også af Alstom, men her er Energinet selv ansvarlig for test og deployment af

ændringer. Der er ingen Change Management procedure i samarbejdet med Alstom, hvilket er generelt for

samarbejdsvilkårene med trediepartsleverandørerne og repræsenterer et af de større accountabilityproblemer

(se ”Det manglende overblik - Informationsøer” i afsnit ???Error! Reference source not found.). DPS

udvikles og testes internt i DPS gruppen, men deployes af T&I. DPS er et vigtigt system, der kræver

fleksibilitet og hurtige deployments. Nedetid på DPS gør at kontrolcenteret ikke kan arbejde, hvilket kan

medføre at de mister overblikket og i sidste ende kan dette påvirke elpriserne.

11

11

Når kontrolcenteret opdager en fejl, så ringer de til ”Kerneproces-vagten”, som kan oprette en

”Incident” i deres SharePoint system. Denne Incident vil i tilfælde af at der er tale om ’noget eksisterende’

føre til en ”Change”, hvilket vil sige oprettelse af en RFC. RFC’ere bruges også ’stand-alone’ ned til T&I i

forbindelse med deployments, hvilket vil sige at Helpdesk (Interaction->Incident) proceduren i nogle tilfælde

kan undlades. Når en sådan undvigelse af Helpdesk sker, så spares der tid og det letter arbejdsbyrden på

Helpdesk, men det betyder også, at ændringen ikke registreres hos Helpdesk. De har således ikke et samlet

overblik over alle udførte ændringer. I afsnittet ???.Error! Reference source not found. ”Det manglende

overblik - Informationsøer” har jeg listet flere eksempler på at forsøg på at få overblikket over ændringer.

Resultatet er at forskellige grupperinger har hvert deres ’overblik’ og at de skal bruge flere It-systemer til at

få det komplette overblik. Disse informationsøer skader Accountability hos Energinet, da information om

ændringer ikke er tilgængelig et samlet sted, hvilket ville være mere rationelt. Jeg vil i afsnit??? vende

tilbage til dette, da det har betydning for Change Managementprocessens effektivitet.

Der eksisterer et separat ”Requestsystem”, som også er baseret på InfoPath blanketter (i realiteten er

det en modificeret RFC blanket). En ”Request” er ikke en ”Request for Change” (RFC), da definitionen på

en ”Request er at der er tale om ’noget nyt’. Denne definition af en Request, som værende ’noget nyt’ går

igen i hele It-afdelingen. Ligeledes er en ”Change” defineret som værende ’noget eksisterende’. Denne

kategorisering er, ligesom de uformelle regler om ”deploys”, en etnometode, da der skabes en ’Accountable

adfærd’, som gør at man skelner mellem en ”Request” og en ”Change”. Men den tiltænkte Accountability

udvaskes, da begreberne ”Request” og ”Change” er til stor forvirring. Er oprettelse af en Database en

Reqest, da Databasen ikke eksisterede før, eller er det en ændring af en eksisterende server, gør det til en

Change? Sådanne uklarheder bliver ofte løst over e-mail og telefon og skaber behov for yderligere

koordinering.

Når en RFC skal udfyldes, så snakkes der frem og tilbage, indtil alle detaljer om en ændring er på plads.

Derefter skal man til at lave RFC’en, hvilket opleves som dobbeltarbejde, da man allerede har aftalt

ændringsarbejdet. Hermed bliver en RFC, som arbejdsredskab, reduceret til administrativt

registreringsarbejde (Se ”Administrativt registreringsarbejde” i afsnit???). Når RFC’en er registreret hos

T&I, så opleves der en manglende viden om, hvad der sker med den. De ved ikke hvor lang tid der går inden

den bliver behandlet og de får ingen notifikation om den prioritet den får hos T&I. De kan derfor heller ikke

regne med at en bestemt fejl er rettet til en bestemt dato. For at imødekomme dette, har Kerneprocesser ofte

telefonsamtaler med T&I, for at få formalia på plads og for at blive informeret om status.

På den ene side er der hos Kerneprocesser nogen utilfredshed med, at der skal laves en RFC på selv de

mindste ændringer (eksempelvis en lille indstilling på en Switch). Arbejdet med RFC’en overskygger langt

den arbejdsbyrde det er at udføre ændringen, hvilket virker omsonst. På den anden side er der opbakning til

at Energinet (og specielt It-afdelingen) som ’halvoffentlig virksomhed’ skal registrere arbejdet, således at

man kan dokumentere arbejdet og ikke bliver anskuet som et ’Costcenter’. Willem udtrykker det således,

”Den information RFC’erne tilvejebringer, er nødvendig og det dur ikke, at alle bare ’ændrer løs’ i

systemerne uden at dokumentere det.”.

Der er brug for en ’nødprocedure’, for at kunne rette en fejl, inden der laves papirarbejde, hvis fejlen er

skadelig for forretningen. I dag sker dette som en uformel arbejdsgang3 i forbindelse med ’brandslukning’,

da meget af arbejdet sker på ’bagkant’, dels på grund af den store arbejdsbyrde og dels fordi at fejlene

sjældent er til at forudse.

3 I næste afsnit fremgår det at Støtteprocesser også håndterer dette ’uformelt’.

12

12

Kerneprocesser har en ’Deploymentkalender’ hvor alle ændringer bliver indskrevet. Grunden til at

Kerneprocesser har deres egen kalender er, at SCADA, i samarbejde med Alstom, selv udfører ændringer

(konfiguration/applikationsændringer) til SCADA systemet og behøver derfor et overblik. Kalenderen kan

bruges af system-vagterne i Kerneprocesser, da de heri kan se hvilke ændringer der er sket og dermed hvad

de skal holde ekstra øje med. Kalenderen bruges også reaktivt når en fejl opstår, da den (sammen med

’Steens’ RFC liste) giver information om mulige årsager til problemer. SCADA gruppen er de eneste i

Kerneprocesser, der bidrager med information til denne kalender, på trods af at kunderne efterspørger et

samlet overblik for alle tre systemer (NOIS, DPS og SCADA). De tre systemer er højt integreret og ligeledes

er behovet for klare retningslinjer og information om drift status. DPS (BizTalk) bruger SCADA data til

afregning. DPS sender driftsplaner til SCADA, som så kobler rundt og forsyner i hvenhold til planerne.

SCADA stiller også data til rådighed for DPS og NOIS. Behovet for tilregnelig adfærd i arbejdspraksis gør

sig ikke bare gældende internt i Kerneprocesser, men også mod T&I. I SCADA er der en database, som

stiller data til rådighed for BizTalk. BizTalk sender information ud til flere systemer, bl.a. internettet, når

befolkningen skal have indsigt i forsyningstallene. Når T&I laver ændringer i databasen hos SCADA,

genererer det nedetid. Der er ofte uklarhed om hvordan informationsprocessen skal forløbe til Kontrolcenter

og andre kunder. Grupperne BizTalk, SCADA og T&I snakker på tværs for at finde ud af hvad der skal ske

hvornår. Til tider vil dette scenarie medføre, at ikke alle kunder får besked om en given ændring og at de

først opdager ændringen når de står og mangler data i et system som ’er nede’. Dette udgør et

accountabilityproblem.

I SCADA er der udnævnt en Change Manager (Jørgen). Her er der også beskrevet et procesflow. Processen

er ikke værktøjsunderstøttet, men den følges tilnærmelsesvis. Jeg fik fremvist disse, men de var beskrevet på

et for højt niveau, til at vi kunne diskutere hans opgaver ud fra dem.

Jørgen vurderer henvendelser i Helpdesks Incidentliste og finder ud af hvornår ting skal deployes og hvem

der skal arbejde med dem. Når der en sjælden gang skal laves ændringer på en server, så får Jørgen T&I til at

lave en RFC, som godkendes af Jørgen. Årsagen til at Jørgen ikke selv laver den er, at Alstom har en meget

kompliceret ’struktur’ på serveren, som kun T&I forstår qua deres tekniske infrastruktur viden.

Hvis der er fejl på SCADA systemet, så har de en ”Incident-liste” i SharePoint (denne bruger DPS også).

Kontrolcenteret ringer fejlen ind til Kerneproces-vagten, som laver en Incident-instans. Incidenten bliver

ikke logget i Helpdesk systemet. Derefter bliver problemet løst og i nogle tilfælde skal der en RFC.

En ”Opgaveliste” vedligeholdes, som tjener det formål, at visualisere alt hvad SCADA gruppen går og laver.

Den dækker alle opgaver der laves. Projekter, Requests og forskellige ændringer. Info kommer ind via e-

mails. Nogle Requests kommer fejlagtigt ind (fra ’vagter’) til Helpdesk. Jørgen må her manuelt hente disse

henvendelser ind i Opgavelisten. Incidents som i Systemteamet nedprioriteres, lægges i Opgavelisten og

udføres når der er tid til det. Nogle gange opleves Opgavelisten som værende for simpel. Der mangler flere

værktøjer til at holde styr på tid og andre ting til at visualisere ressourceforbruget.

Jørgen pointerer at koordineringen med ”Drift og Vedligehold” (D&V) ikke fungerer så godt. Når D&V har

fået overdraget en opgave af SCADA afdelingen, så ved SCADA ikke hvad der mere sker, da de ingen status

får. Der mangler et visuelt spor, så man kan se hvad de enkelte ’sager’ er endt med og hvad status er.

Problemet ligger hos D&V, som er SAP orienteret, hvilket ikke spiller sammen med SCADAs systemer.

SCADA har også prøvet T&I’s ”HP Servicedesk”, men det var for rodet. De kan kun bruge noget enkelt og

er derfor endt op med ’Opgavelisten’ og ’Incidentlisten’, hvori DPS også opdaterer deres information.

Kontrolrummet bruger SCADAs lister til at skabe sig et overblik over hvad der sker.

13

13

Jørgen mener ikke at roller og ansvar er fordelt på fornuftig vis. I og med at Kontrolcenteret opdager fejlene

og rapporterer dem ned til SCADA, DPS og NOIS, så burde de (ifølge Jørgen) også være ansvarlige for at

oprette Incidents (altså være incident manager). Kontrolrummet har også mulighed for at ringe Incidents ind

direkte til D&V, som registrerer deres opgaver i deres eget SAP system. Hermed figurerer der ingen

information om disse ændringer i Energinets systemer.

NOIS gruppens måde at håndtere Change Management på, er vellidt blandt medarbejderne i

Energinet. Steen kunne lide den og Willem kalder den ”den rigtige model”, underforstået at det er den han

mener kører godt. Én af årsagerne er at det er regelfast og at det er trediepartsleverandøren Alstom, som står

for NOIS applikationen. Her er der via SLA’ere faste procedurer for hvordan deployments foregår.

Deployments aftales med Alstom cirka et år i forvejen, da man tidligere oplevede man mange deployment

problemer, grundet kompleks koordination mellem diverse interessenter. Alstom skal give besked 24 timer i

forvejen ellers kan der ikke ske ændringer. De faste procedurer er nødvendige da der sker et større

koordineringsarbejde (med interessenter) når der skal ske ændringer.

Eksempel på en RFC proces i NOIS:

Stamdata skulle ændres i NOIS systemet, som ikke kunne ændres fra brugergrænsefladen. Derfor

skulle der bruges et SQL script, som Alstom lavede og uploadede til en FTP server. For at få SQL’en udført,

så oprettede Poul en RFC mod T&I, som lægger den i ”pre-prod”. RFC’en udfyldes med det mål at T&I

”med hovedet under armen” skal kunne teste SQL scriptet på pre-prod. RFC’en ligger så i systemet med

RFC’ere og venter (ingen indikation af hvornår der sker noget). Poul vil gerne have udført den hurtigt, så han

mailer til Steen fra T&I. Steen siger OK og overtaler Lasse til at udføre den hurtigt. Poul laver sideløbende

en RFC til at få SQL’en deployet i produktion, men noterer at det kun skal ske, hvis pre-prod testen gik OK.

Lasse ser denne RFC og ringer og spørger om den skal lægges på ”produktions” systemet og om testen er

overstået og alt er OK. Det siger Poul, som har testet på ’PreProd’ i et par dage, OK til. Lasse sender en mail

ud til diverse interessenter om ændringen og beder dem henvende sig, hvis der er indvendinger. 15 minutter

senere udfører han ændringen og sender derefter endnu en mail ud om at ændringen er udført. Denne korte

indvendingstid er ikke risikabel, da ændringen tidligere er blevet diskuteret i ”NOIS Steering Group” (NSG),

som er et forum bestående af NOIS interessenterne(Fodnote: DSP og SCADA har lignende systemteams).

De har ikke noget med selve RFC’erne at gøre. Poul er leddet mellem NSG (forretningen, 2 fra hver TSO) og

den tekniske side af systemet. NSG diskuterer ændringer og fungerer dels som ’modpart’ til Alstom, så de

ikke bare kan gøre hvad de vil (teknisk og til dels økonomisk). NSG sikrer at man ikke går i gang med noget

som ikke kan lade sig gøre i alle TSO’er og rent teknisk set i Energinet regi.

Støtteprocesser

Gruppen ”Støtteprocesser” udgør, ligesom Kerneprocesser og T&I, én af de tre grupperinger i It-afdelingen.

Støtteprocesser er ”It-systemejer” for en række administrative systemer, hvor jeg blev kort præsenteret for

disse: SAP, Acadre (ESDH), Sharepoint, GIS, Meridian, AutoCAD, Mega, Panda, Selvbetjeningsportal og

DataHub. Støtteprocesser arbejder sammen med forretningen i håndtering af ændringer til disse systemer.

Der bliver gjort brug af en ny tredjepartsleverandør/konsulent for hvert system.

Støtteprocesser har ”1’st level support” overfor forretningen. Alle henvendelser fra forretningen (brugerne)

skal, officielt set, gå gennem Helpdesk eller, i tilfælde af Requests, Relation Managers.

14

14

Som i de to andre grupperinger (Kerneprocesser og T&I) er regelen, at Requests kategoriseres som værende

”noget nyt” og Incidents kategoriseres som værende ”noget eksisterende”. For at undersøge Støtteprocessers

evne til at identificere hhv. Requests og Changes, så spurgte jeg, ”Er en ny server noget nyt, eller er det en

ændring til den eksisterende It-infrastruktur?”. Dette gav straks anledning til modstridende synspunkter,

hvilket er genkendeligt fra It-afdelingens to andre grupperinger.

En anden ting som er genkendelig er interfacet mellem Støtteprocesser og T&I, hvor der bruges RFC-

blanketter til ”Changes” og Request-blanketter til ”Requests”. Problematikkerne omkring denne procedure er

meget lig dem der ovenfor er beskrevet for Kerneprocesser.

Der er forskel på ”Konfigurationsændringer” og ”Applikationsændringer”, da konfigurationsændringer

foregår i applikationsgrupperne (f.eks. Acadre) og applikationsændringerne foregår hos

trediepartsleverandørerne. Denne opsplitning giver, ifølge Støtteprocesser, god mening i brugen af

outsourcing, men der er en del Change Management data som går tabt hos Støtteprocesser. Alle

applikationsændringer registreres i trediepartleverandørenes systemer og figurerer således ikke hos

Energinet. Konfigurationsændringerne falder uden for Helpdesk processen. Der bliver lavet hurtige

ændringer, uden at de bliver registreret hos Energinet som Incident/RFC. Tilbage er kun ændringer som

foretages, som følge af fejl der er opstået i forretningen og anmeldt til Helpdesk.

I Støtteprocesser er der ikke udnævnt nogen Change Manager. Dog er der bl.a. Britta, som er ”tildeler” på

”Assignment-grupperne” Sharepoint, Meredian og Acadre/ESDH, hvilket betyder at hun ’screener’

”Interactions” i Helpdesksystemet og tildeler Incidents til relevante It-medarbejdere i Støtteprocesser. I

Helpdesk (Selfservice) systemet er der vha. en checkboks mulighed for at angive om en ”Interaction” drejer

sig om en ”forretningsapplikation” (Støtteprocesdomænet) og man skal samtidig angive hvilken applikation

der er tale om. Dette resulterer i at en ”Interaction” vil blive sendt til en såkaldt ”Assignment-gruppe”.

Checkboksen og den underliggende funktionalitet er en etnometode, der er opstået, da T&I (Helpdesk)

generelt ikke er i stand til at afgøre, hvad der specifikt er galt og hvad der skal ske når vi snakker

administrationsapplikationerne hos Støtteprocesser. Checkboksen er blevet til ud fra et rationale om at skabe

effektiv orden i ”Interactions” ved at sende dem direkte til de berørte systemansvarlige. Denne funktionalitet

vil jeg betragte som værende refleksiv, da ”tildelerne” på denne måde ved hvilket system (Assignment-

gruppe) der er berørt, hvilket er formålstjeneligt set i forhold til at sende Interactions til T&I, som ikke har

stor viden om forretningsapplikationer. Etnometoden styrker på denne måde accountability i forbindelse med

Change Management.

Britta gav følgende beskrivelser på tre repræsentative ’Change Management’ processer:

1. Fejlscenariet: En bruger sidder og arbejder med et dokument i Acadre og ser at der er ’koks’ i

versionsstyringen. Det melder brugeren ind til Helpdesk. Helpdesk laver en ”Interaction” og ’eskalerer’ den

til en ”Incident”, hvis de ikke selv kan løse problemet. Kun Incidents til SharePoint bliver markeret med

’severity’, da de bruger det til at prioritere udviklingen af SharePoint rettelserne. Resten er ’standard’. Britta

håndterer Incidents for Acadre, hvilket vil sige at hun tildeler Incidents til de rigtige folk. Ligeledes er der er

”Tildelere” i de andre grupperinger (SAP, Sharepoint, AutoCad). Der er dog flere systemer end der er folk i

Støtteprocesser, så nogle folk håndterer Incidents for flere systemer ad gangen.

Incidents til systemet Acadre rapporterer hun til trediepartsleverandøren Traen i deres system. De arbejder på

sagen og laver en patch, på hvilken Britta så laver en RFC mod T&I, da det er dem der har

”Applikationsansvaret” på Acadre.

15

15

2. Undtagelse til standardproceduren: Er et problem alvorligt, så ringer brugeren direkte til Britta, som

forsøger at løse problemet selv. Kan hun ikke det (”lige nu”) eller er problemet meget alvorligt (der skal

yderligere tiltag til, så som en permanent løsning), så opretter hun en Incident og laver en ”sag” i Traens

systemer. Kan hun derimod godt løse problemet (måske i telefonisk samarbejde med Traen), så gør hun det

og laver en RFC (i samarbejde med Traen) mod T&I. T&I og Traen sørger i samarbejde for at få løsningen

implementeret på Acadre systemet. Her samarbedes der, da Traen ikke vil udlevere scripts til T&I.

3. Nyudvikling: Proceduren er den samme som oven over, men her er det trediepartsleverandøren,

eksempelvis PeopleNet (for SharePoint), som kommer med en opdatering. PeopleNet bruger Energinets

Helpdesk system og opretter selv en Incident. I Sharepoint gruppen bliver Incidentlisten fra Helpdesk brugt

som opgaveliste. På baggrund af Incidenten bliver der oprettet en RFC (mod T&I).

SAP gruppen fungerer på en anden måde end resten af systemgrupperne i Støtteprocesser. De har

ligesom SCADA selv applikationsansvaret, hvilket giver dem en ’ren’ grænseflade til T&I. SAP gruppen har

godt styr på ”udvikling, test og produktion” og derfor er det accepteret, at de har deres eget aflukkede miljø,

hvor de kan agere. SAP gruppen mener også at dette lukkede univers er på sin plads, da de har med kritiske

systemer (løn m.m.) at gøre. SAP bruger dog ikke systemets indbyggede Change Management modul, da de

selv mener at det skal håndteres på tværs af It-afdelingen og ikke i siloer.

Integrationen med Helpdesk er ikke velfungerende, på det tidspunkt en Incident er tildelt SAP

gruppen. Herefter forsvinder den i SAP systemet og det er op til den enkelte medarbejder, at undersøge om

Incidenten lukkes hos Helpdesk.

SAP bruger et noget andet begrebsapparat end resten af It-afdelingen, da de er meget ’farvet’ af SAP

verdenen. Det der hedder et ”Deploy” i resten af It-afdelingen, hedder en ”Transport” i SAP. De ser

udelukkende på Change Requests (læs: Incidents) som ændringer til den eksisterende forretningsproces, som

den er defineret i SAP. Altså, afføder en Change Request (læs: Incident) en omkonfigurering af SAP. En

”Change” er, hos SAP, både en ændring til noget eksisterende, men kan også være noget nyt der skal

oprettes. Ordet ”Request” bruges således ikke.

Lige som andre grupperinger, så bruger SAP også RFC mod T&I, når det kommer til It-infrastruktur.

Hermed tvinges de til at bruge den øvrige terminologi, som eksisterer hos Energinet.

16

16

Bilag 4 ”ITIL projektet, som blev lagt på is” Dette bilag er der ikke blevet refereret til fra opgaven, da jeg ikke finder det relevant. Dog er oplysningerne

en del af det empiriske data og der refereres derfor til dette bilag fra afsnittet ”Møde med Birger” i bilag 6.

Det er under mine undersøgelser kommet frem, at der tidligere har kørt et ITIL projekt. Dette projekt

er i dag ’lagt på is’, da det var ude af proportioner i forhold til de øvrige opgaver. Birger mener ikke at det

gamle ITIL projekt er årsagen til, at man ikke vil eksplicitere ITIL brugen mere i It-effektiviseringsprojektet.

Han mener heller ikke at det vil have nogen anden betydning for det nuværende projekt. Jeg har ikke

grundlag for at hævde andet og vil derfor acceptere denne holdning, med det forbehold at man holder dette i

mente, når It-effektiviseringsprojektet ’skal sælges’ til interessenterne.

Da Energinet blev dannet ud fra de tre tidligere nævnte selskaber, var ambitionsniveauet ekstremt højt. Der

blev lavet en undersøgelse af IBM (It-platform undersøgelse)), som viste at It-systemerne skulle

konsolideres. Man ville have sammenlagt IT og gøre alle systemer standardiserede. Man lavede en SOA

baseret Energinet platform/portal, hvor der var indgang til alle Energinets systemer/It-øer.

Der kørte et ITIL-projekt, hvor en masse ITIL processer skulle implementeres og alle skulle på kursus. Dette

fejlede fordi det ikke blev prioriteret højt nok. Kun få kom på kursus og dermed udeblev forståelsen for ITIL

begrebsverdenen. Udledt af dette kunne mange ikke forstå hvorfor man skulle arbejde som ITIL foreskrev,

når man nu også skulle håndtere den stigende arbejdsbyrde med konsolidering af It-platformen.

Man har i ”It-effektiviseringsprojektet” valgt ikke at kalde projektet et ITIL projekt. Birger, som er

projektleder på It-effektiviseringsprojektet, mener ikke at ”det gamle ITIL projekt” har noget at gøre med

nedtoningen. Han mener heller ikke at det tidligere projekt vil påvirke folks imødekommenhed overfor nye

tiltag. Jeg har valgt at acceptere denne holdning, da jeg ikke har tydelig begrundelse for det modsatte.

Da Energinet blev dannet ud fra de tre tidligere nævnte selskaber, var ambitionsniveauet ekstremt højt. Der

blev lavet en undersøgelse af IBM, som viste at It-systemerne skulle konsolideres. Man ville have

sammenlagt IT og gøre alle systemer standardiserede. Man lavede en SOA baseret Energinet platform/portal,

hvor der var indgang til alle Energinets systemer/It-øer. (Fransk leverandør, ny opgave for denne) (De tre It-

øer/platforme eksisterer stadig i dag, hvilket gør det svært at koordinere mange ting.)

Eksempel på konsolidering af økonomisystem: Der er ca. 500 applikationer hos Energinet.

Økonomisystemerne Admission, Axapta og SAP skulle konsolideres til én fælles SAP platform, men disse

tre systemer kører parallelt sammen med denne nye SAP platform den dag i dag. Ligeledes er mange andre

It-systemer kommet til, som en del af en konsolideringsproces. Til alle disse systemer skal der bruges mere

hardware, hvilket Steen giver udtryk for er steget for meget.

Steen om ITIL projektet

På spørgsmålet om forretningsledelsen støtter op om projektet siger Steen, at det ikke er hans opfattelse, at

projektet er andet end et It-projekt. Der er opbakning fra Claus og Gerts side.

Udfordring: Dette skal ”køres igennem” samtidig med at alt det andet skal håndteres. Der bliver et problem

her, da der skal bruges masser af dedikeret tid til at få ITSM til at køre.

17

17

Der skal sættes tid af til at alle kommer på kursus i ITIL, således at alle kan få fælles begrebsverden. Her bør

ledelsen træde til at sætte tid og penge af til dette.

Man vil i det nuværende ”It-effektiviseringsprojekt” køre et ITSM projekt uden at tage ITIL aktivt i brug.

Man har valgt kun at skele til ITIL/MOF. På mit spørgsmål om hvordan, projektet skal blive en succes under

disse vilkår, er der intet svar. Når ikke ITIL bliver en aktiv del af projektet, så er der tool’et ”MS Service

Manager” ’tilbage’. Kommentaren (fra Steen) på dette er at det bunder i for lav prioritering. Steen har fået

den opfattelse at Birger ikke har tilstrækkelig tid til projektet, hvilket er et tegn på lav prioritet. Dog er der

ansat en ekstern konsulent (John Christensen) til at hjælpe (som med det samme har fået Data-Hub

projektarbejde smidt oven i sin arbejdsbyrde).

Hvis effektivisering skal opnås gennem standardisering og automatisering, så skal man have ’tingene’ til at

snakke sammen. Der skal bl.a. udarbejdes Change ManagementS, dvs. en Change ManagementDB med CI.

Den for længe siden planlagte konsolidering af It-platformen skal eksekveres til fulde. Der skal ryddes op i

den store mængde af standalone applikationer og den tilbageværende It-platform skal integreres vha. et

system, således at arbejdsopgaver kan automatiseres. Et eksempel: En server fejler, HP-Openview sender en

alarm, som fanges af Applikation-X, der fører til en (incident)rapport. Rapporten igangsætter en række ITSM

rutiner, som fører til løsning af problemet.

Dette arbejde er en forudsætning for at ITSM arbejde kan blive en succes.

DataHub projektet skaber et pres for at få Service Management processen ”Incident Management” og

Microsoft Service Manager ’implementeret’. Men teknisk set bør man (ifølge Steen) ikke starte med

Microsoft Service Manager før SM2012 udkommer. Faren er at man forsøger at gøre noget hurtigere end

man kan.

Willem om ITIL projektet

5 år siden.

Kærneprocesser var ikke rigtigt involveret i projektet.

Projektet blev dræbt da folk sagde at det var et stort arbejde. En tung proces, som kræver meget

administration.

For højt ambitionsniveau.

Ikke pragmatisk nok.

Tilbagebleven aversion mod ITIL.

Kærneprocesser vil ikke have bureaukrati. En ændring der kan laves på 5 min. Skal ikke have en

administrativ byrde over 5 min.

18

18

Bilag 5 ”Continual Service Improvement” Denne figur viser de elementer der indgår i ”Continual Service Improvement” (CSI). Formålet med at have

den med i bilagene er, at læseren vil kunne se, at alle delene af frameworket er ’involveret’ i denne service

forbedring.

Kilde: (OGC, 2007, s. 125)

19

19

20

20

Bilag 6 ”Interviews” I dette bilag har jeg listet interviews med Energinets medarbejdere, som har betydning for opgavens empiri.

De er listet i kronologisk rækkefølge. Alle interviewguides er fyldt ud med meningskondenserede svar fra

respondenterne. Meningskondensering er foregået ved, at jeg har lyttet interviewene igennem4 og skrevet

min forståelse af svarene ned i kort form. Dette bilags dele skal kunne læses af en udenforstående, men vil

være skrevet i delvis noteform, da det er sådan svarene repræsenteres uden at fortolke dem. Således er

udarbejdelsen af informationen i dette bilag5 en del af 1. transformation (se Figur 1).

Interviews er listet i denne rækkefølge:

1. Møde med Steen (T&I).

2. Møde med Willem (Kærneprocesser).

3. Møde med Michael (Støtteprocesser)

4. Møde med Birger.

5. Møde med It-ledelsen.

1. Møde med Steen (T&I)

Forklaring af Energinet It-Struktur: (Steen møde1, del1, 6:26)

Historien om de 3 selskaber der blev til ’1’:

El siden; To selskaber der tog sig af: 1) system, planlægning, transmission; I Vest hed det Eltra og i øst

Elkraft. Det tredje selskab (Gassiden) var Gastra (fra Dong).

Gastra: Outsourset It-platform til Ematra/TLA.

Elkraft: ’Traditionel’ It-afdeling (4 mand, 2 grupper, 1.Kontor-It 2.Kontrolrums-It).

Eltra: ’Traditionel’ It-afdeling (Flere folk end i Elkraft).

Tre meget forskellige It-platforme.

Teknisk set er alle systemer blevet konsolideret, men der er flere gamle systemer der kører separat og

parallelt.

Organisatorisk set er Energinets 70 It-medarbejdere delt op i to logiske divisioner (El og Gas), men al It

håndteres af én stor It-afdeling. It-afdelingen er delt logisk op i tre afdelinger, som hedder ”Støtteprocesser”,

”Kærneprocesser” og ”Teknik og infrastruktur”.

Teknik og infrastruktur er delt logisk op i 4 områder:

- Helpdesk (Peter Madsen + 4 folk)

- WAN (Hele det danske El-net; Bruger Change Management meget lidt)

- LAN (Bruger Change Management meget lidt)

4 Lysfiler er fortrolige, da jeg ved hvert interview har lovet, at disse kun var til eget brug. De kan rekvireres, hvis der

skulle opstå tvivl om det empiriske grundlag. 5 Der har været et par mindre møder og nogle mobilsamtaler, som også har bidraget til opgaven, men på et metaplan,

der mest har omhandlet opgaven.

21

21

- Kontor-It/Platform (I de 8 lokale Energinet centre). Erritsø og Egtved er de to primære sites. Alt IT

på transformatorstationer m.m. er ikke inden for scope, men ansvaret er alligevel Teknik og

Infrastrukturs.

Sagens kerne ifgl. Steen:

På fællesmødet blev det nævnt (af Willem, ”Kærneprocesser”) at han hellere gik til ”Helpdesk” end at skrive

en RFC, når man skulle bruge en Server, da det var den hurtigste måde at opnå et ønsket resultat.

Steens svar: ”Det er i dag ret diffust, hvordan gør man når man ønsker ny funktionalitet, en rettelse eller bare

en eller anden form for henvendelse til It.”

Steen ønsker soleklare retningslinjer, så alle ved hvordan man skal gøre. Han mener at formålet med ”It-

effektiviseringsprojektet” er at få lavet et ITSM miljø der er virksomhedsdækkende, således at processer

holdes på plads og således at automatisering og standardisering (=effektivisering) ’i ave’.

Forskellighed og forskellige opfattelser skal afskaffes.

Steen mener at ”Relation Management” skal håndtere (stå for) ITSM. Han mener at ansvaret, for at

henvendelser kommer de rigtige steder hen, skal ligge her.

Roller og ansvar skal fordeles, så der eksisterer accountability og responsibility.

konsolidering af It-systemer:

Der er ca. 500 applikationer hos Energinet. Økonomisystemerne Admission, Axapta og SAP skulle

konsolideres til én fælles SAP platform, men disse tre systemer kører parallelt sammen med denne nye SAP

platform den dag i dag. Ligeledes er mange andre It-systemer kommet til, som en del af en

konsolideringsproces. Til alle disse systemer skal der bruges mere hardware, hvilket Steen synes er

eksploderet.

Eksempel på en It-ø: Teknik og infrastruktur har ansvaret for Gas-kontrolrumssystemernes (DTMS og

GSMS) servere, men Rambøll har ansvaret for al overliggende IT. (Her er der ingen Change Management

dækning på trods af at ’Gas’ er en kærneproces.).

Change Management, som det, ifølge Steen, fungerer hos ”Teknik og Infrastruktur”:

- Blanketsystem i ”MS InfoPath” (WML baseret).

- Ingen automatisering.

- Ikke godt, men OK.

- ”Kærneprocesser” bruger dette system, når de ved at en ændring vedrører ”Teknik og infrastruktur”.

- Se ”Change Management” blanket for detaljer om specifikke felter.

- Månedlig rapportering til ledelsen over Change Management.

- Ingen porteføljestyring eller prioritering. Alt styres via ”ad-hoc” fornuft.

22

22

- Ingen servicevinduer (don ingen ændringer fredag eftermiddag)! Der er guld, sølv, bronze systemer,

men det siger kun noget om hvordan oppetiderne bør være.

- Rapporteringen bruges af ledelsen til at forstå Change Management indsatsen. Dog bliver data fra

Change Management systemet ikke aktivt brugt til at udføre Change Management arbejdet proaktivt

(f.eks. viden om opgraderinger der ofte fejler kan bruges til at være ekstra påpasselig). Denne form

for vidensdeling sker ikke. (Change Management vil derfor blive set på som ekstraarbejde, der kun

udføres for at lederne skal have noget at træffe beslutninger ud fra.)

- Ændringer laves tirsdag og torsdag.

- Folk forstår ikke graduering af RFC’erne.

- Folk forstår ikke hvorfor Change Management er nødvendigt.

- Selv Relation Managers har svært ved at se forskel på hvad der er en Request og hvad er en Change.

- Nogle gange laver Relation Manager RFC, men ofte hjælper de med at finde frem til at der skal laves

en RFC.

- Relation Manager rollen skal fastlægges (opgaver og ansvar)

- I starten var det den generelle opfattelse at Change Management var et registreringsarbejde. Man

kunne ikke se de umiddelbare udnytte af arbejdet. Nu begynder fordelene at vise sig i form af:

Opfølgning/huskeseddel og ”Kærneprocesser” bruger månedsrapporten til at se vurderingen af deres

arbejde med Change Management (Rapporteringen tjener formål: rapport til ledelse og synliggørelse

af udført arbejde). Dog bliver Change Management arbejdet ikke brugt til at være proaktive; alt sker

stadigvæk på bagkant.

- Forskellige folk udfylder RFC forskelligt (opfattelser bliver tvetydige).

Udfyldelse af RFC – Review fase – Godkendelsesfase – Implementeringsfase – testfase (ikke beskrevet) –

review af processen / Evaluering m. score for hvor godt det er gået.

I RFC’en er der også krav om både ”fallforward” og ”fallback” procedure.

Problem: Hvis Willem (Kærneprocesser) laver Change Management, så ved Teknik og infrastruktur ikke

noget om det. Problemet opstår når Willem laver en ændring til hans domæne (applikationsniveauet på

kærnesystemet) og det har ’uforudsete’ konsekvenser for de systemer de kører på (Steens ”teknik’ domæne).

Update: Willem laver ikke Change Management (ud over at udfylde Steens RFC’ere). Det paradoksale er at

Steen ved ikke at Wille ikke laver Change Management. Dermed er der manglende accountability, idet man

ikke kan regne med (ved noget om) hvor der udføres Change Management-lignende arbejde.

Indkomne opgaver i It-afdelingen:

I ”Teknik og infrastruktur” kommer opgaverne ind på tre måder:

1) Den ovenfor omtalte Change Management proces.

2) En ”Request” process:

En Request: Er ikke det samme som en ”Change”, da det er noget der omhandler noget der ikke er

der i forvejen. Nyanskaffelse af en server er et eksempel. Her er der oprettet en proces lignende

”Change” processen med InfoPath skemaer m.m. Her bruges et begreb ”mindre interne opgaver”.

Relation Managers bruger meget dette system.

23

23

3) Servicecenteret, hvor helpdesk får deres opgaver ind.

4) Diverse andre uforklarige måder (mobil, mail, ved kaffemaskinen).

Forankring og ledelsens opbakning:

På spørgsmålet om forretningsledelsen støtter op om projektet siger Steen, at det ikke er hans opfattelse at

projektet ikke er andet end et It-projekt. Der er dog fuld opbakning fra It-ledelsen (Claus og Gerts side).

Udfordring: Dette skal ”køres igennem” samtidig med at alt det andet skal håndteres. Der bliver et problem

her, da der skal bruges masser af dedikeret tid til at få ITSM til at køre.

Der skal sættes tid af til at alle kommer på kursus i ITIL, således at alle kan få fælles begrebsverden. Her bør

ledelsen træde til at sætte tid og penge af til dette.

Man vil køre et ITSM projekt uden at tage ITIL aktivt i brug. Man har valgt kun at skele til ITIL/MOF. På

mit spørgsmål om hvordan, projektet skal blive en succes under disse vilkår, er der intet svar. Når ikke ITIL

bliver en aktiv del af projektet, så er der tool’et ”MS Service Manager” ’tilbage’. Kommentaren (fra Steen)

på dette er at det bunder i for lav prioritering. Steen har fået den opfattelse at Birger ikke har tilstrækkelig tid

til projektet, hvilket er et tegn på lav prioritet. Dog er der ansat en ekstern konsulent (John Christensen) til at

hjælpe (som med det samme har fået Data-Hub projektarbejde smidt oven i sin arbejdsbyrde).

Projektet er startet ’svagt’ i gang, da der i oplægsmaterialet til Effektiviseringsprojektet ikke er beskrevet

noget om sammenhængen mellem ITSM processerne. Kim (fra Teknik og infrastruktur) har på baggrund af

oplægsmaterialet til Effektiviseringsprojektet, som han finder mangelfuldt, sat sig ned og lavet et oplæg til

ting der skal på plads for at projektet bliver en succes (Set fra Teknik og infrastrukturs side). Dette oplæg er

under udarbejdelse og ikke til at få fat i, men Steen kunne afsløre at det handler om ”Implementeringsplaner”

og ikke det konkrete tool.

Hvis effektivisering skal opnås gennem standardisering og automatisering, så skal man have ’tingene’ til at

snakke sammen. Der skal bl.a. udarbejdes Change ManagementS, dvs. en Change ManagementDB med CI.

Den for længe siden planlagte konsolidering af It-platformen skal eksekveres til fulde. Der skal ryddes op i

den store mængde af standalone applikationer og den tilbageværende It-platform skal integreres vha. et

system (hvilket?), således at arbejdsopgaver kan automatiseres. Et eksempel: En server fejler, HP-Openview

sender en alarm, som fanges af Applikation-X, der fører til en (incident)rapport. Rapporten igangsætter en

række ITSM rutiner, som fører til løsning af problemet.

Dette arbejde er en forudsætning for at ITSM arbejde kan blive en succes.

DataHub projektet skaber et pres for at få Service Management processen ”Incident Management” og

Microsoft Service Manager ’implementeret’. Men 2 ting taler imod:

1) Teknisk set bør man (ifølge Steen) ikke starte med Microsoft Service Manager før SM2012

udkommer.

2) Kims oplæg omhandlende sammenhæng mellem ITSM processerne og integration af It-platformen.

Faren er at man forsøger at gøre noget hurtigere end man kan.

24

24

Steens ønsker:

- Når et netværkselement eksempelvis fejler, så skal der sendes en besked til et overvågningssystem

der får Service Management møllen til at køre og får de rigtige mennesker sat i gang med at gøre det

aftalte arbejde på den aftalte måde. Der skal automatiseres, således at man kan handle proaktivt. Det

handler ikke om hvilket tool vi bruger, men om den måde arbejdet planlægges og udføres på ret

organisatorisk. At det nye system (Service Manager) er et Microsoft system er bare fint, da

Energinets systemer i forvejen er baseret på MS-systemer.

- Der skal være folk fra Rambøll som får ansvaret for deres del af ITSM processerne. Alle skal

involveres på det rette niveau.

- Et gennemtænkt Change Manager hierarki. I det hele taget en rollefordeling, der bliver

håndhævet/ansvarsført fra ledelsen.

- Et system hvor man bliver adviseret, når man skal foretage sig noget/melde tilbage… m.m.

- Et bredt overblik, således at man kan se alle ændringer og på den måde identificere mulige årsager til

nye opståede problemer.

- Vidensdeling.

- SLA’er, UC’ere og OLA’er eksisterer ikke på skrift. De eksisterer kun i form af ”måden vi arbejder

på”. Sådanne skal laves ifm. services. (Der er dog et dokument der beskriver serverkategorier (guld,

sølv, bronze), som bruges overfor kunder til at aftale et specifikt serviceniveau.)

- Asset management (Plugin/add-on: Provance) i MS Service Manager.

2. Møde med Willem (Kærneprocesser)

”Kærneprocesser” er ”It-systemejer” (også bedre kendt som ” Applikationsansvarlig”) for de nedenstående 3

systemer/grupper (NOIS, DPS, SCADA). Et It-system som ”MS Exchange” er en administrativ applikation,

som bruges af alle hos Energinet, så er her T&I It-systemejer, da de sørger for at dette system kører

transparent for brugerne.

”Kærneprocesser” arbejder sammen med forretningen i styringen af ændringer til systemerne (NOIS, DPS og

SCADA). Folk hos Kærneprocesser udfylder oftest Request for Change (RFC).

T&I står for ”deployment” af ændringer til systemerne (DPS og NOIS?) i ”Kærneprocesser”.

Brugerne af systemerne (Systembrugerne) får mail (mailgrupper) med relativ kort varsel (24 timer, 1 time,

15 min.) om at der sker ændringer.

NOIS er den ’perfekte’ model.

Kærneprocesser bruger T&Is RFC (Infopath) blanket, da alle ændringer sker mod T&I.

Kærneprocesser har en deployment-kalender hvor alle ændringer bliver indskrevet. Grunden til at

Kærneprocesser har deres egen kalender er at SCADA selv udfører ændringer

(konfiguration/Applikationsændringer) til Applikationerne og behøver derfor et overblik. SCADA er de

eneste der bruger denne kalender. Kalenderen kan bruges af system-vagterne i Kærneprocesser, da de heri

25

25

kan se hvilken ændringer der er sket og dermed hvad de skal holde ekstra øje med. Kalenderen bruges også

reaktivt når en fejl opstår, da den (sammen med ’Steens’ RFC liste) giver en mulige årsager til problemer.

’Kunderne’ efterspørger også et samlet overblik for alle tre systemer (NOIS, DPS, SCADA). (Kalenderen er

ikke en del af Energinet-portalen (omtalt af Steen). Willem ved ikke hvad dette er for en protal, men han ved

at alle i Energinet har adgang til kalenderen).

Kærneprocesser bruger Helpdesk til Incidents og RFC’ere. RFC’ere bruges også ’stand-alone’ ned til T&I til

deployments.

Incident: Kan være ’noget’ hos en medarbejder, som Helpdesk kan løse (en manglende PC-problemer eller

emailadresser til BizTalk eksempelvis) .

RFC: Bruges til ”deployments” og ”konfigurationsændringer”.

Request: RFC’ere kan også bruges til ”Requests” (der eksisterer et separat ”Requestsystem”, som også er en

Infocast blanket (modificeret RFC blanket)). En Request er ikke en Request for Change(RFC), selvom

Request’en alligevel godt kan føre til en ændring, da definitionen på en Request hos nogle i Energinet er at

det er noget nyt.

Disse tre (request/change/incident) begreber er til stor forvirring (ikke entydige). Fx: Er oprettelse af en ny

DB en Incident, som bliver til en Reqest eller er det en RFC? Dette dilemma bliver løst over email/telefon.

Noget kan starte son en Incident, som bliver til en Request, som bliver til en Change: Eksempel: En bruger

laver en Incident, da en funktionalitet ikke fungerer, men burde fungere. It (Helpdesk) mener at det er en

Request, da funktionaliteten aldrig har fungeret.

Willem ønsker sig:

- ét system med én liste hvor hver ’entry’ kan skifte status mellem incident, request og change alt efter

situationen.

- Ikke nødvendigvis stringente procesbeskrivelser, men mere vidensdeling i selve processen.

Vidensdeling i from af fordelt roller og ansvar der medfører at folk giver besked til hinanden, så man

ved hvad man har at regne med.

- At Change Management arbejdet ikke bliver omtalt som ”et kæmpe arbejde”. Han ser det som et

tegn på at det ikke bliver til noget og man burde slet ikke starte projektet. Han mener at man skal

finde et niveau som Energinet kan få nytte af Change Management og så gå i gang med at bruge det.

- At kunne bruge arbejde med Change Management til at forbedre Kærneprocesser.

- At vide hvornår man får svar på en RFC.

- At kunne oprette en RFC i et system uden at skulle ringe og aftale alt muligt først. Ofte opleves det

at man snakker frem og tilbage og aftaler en masse indtil alle detaljer om en ændring er på plads.

Derefter skal man til at lave RFC’en, hvilket opleves som dobbeltarbejde, da man allerede har aftalt

ændringsarbejdet (altså er det kun en registrering og ikke et arbejdsredskab).

- Forventningsafstemning i RFC.

Process:

26

26

Når kontrolcenteret opdager en fejl, så ringer de til Kærneproces-vagten, som opretter en ”Incident”.

Kærneprocesser har 1’st level support (overfor kunder, primært kontrolcenter) på NOIS, DPS og SCADA.

Helpdesk har på andre (trivielle) ting. Altså, er der ikke ”Single Point of Contact”, som er én af ITIL

dyderne.

3 Systemer = 3 Grupperinger i Kærneprocesser:

NOIS:

Nordisk system, der styrer planlægning af Elforsyning.

- RFC : Preproduktion : Produktion

(deployment)

Incident Request Changes ; Status (change, request, incident)

Min observation: Det er ret tydeligt at den måde Change Management sker på I NOIS er vellidt blandt

medarbejderne i Energinet. Steen kunne lide den og Willem kalder den ”den rigtige model”, underforstået at

det er den han mener kører godt. Én af årsagerne er at det er en 3’die parts leverandør der står for NOIS

applikationen. Her er der via SLA’ere faste procedurer for hvordan deployments foregår. De skal give

besked 24 timer i forvejen ellers kan der ikke ske ændringer. De faste procedurer er nødvendige da der sker

et større koordineringsarbejde (med interessenter) når der skal ske ændringer.

Deployments aftales med trediepartsleverandør ca. et år i forvejen. Årsag: Tidligere oplevede man mange

problemer ifm. ændringer. Kompleks koordination mellem interessenter ifm. deployment. Ændringerne er

måske gode at have/vigtige, men de kan godt vente.

En deployment er ikke en ret til at forstyrre systemet, man skal stadig give besked.

Snak med Poul (NOIS):

NOIS bliver brugt af de 4 (TSO) i Norden (No, Fi, Sv, Dk). Samler tal sammen.

4 releases pr. år.

Der kommer en release fra Alstom på FTP site. Den skal i test. T&I udfører RFC’erne.

Testmiljø (preprod.) der simulerer det live system der hedder ”produktion”.

Der bliver lavet en RFC til både test og når ændringen skal i produktion.

Nogle gang kan NOIS ikke altid forstå den score (evaluering) T&I kommer med efter evaluering af

RFC/Change Management forløbet. De kan til tider føle at T&I får højere score end NOIS på samme RFC.

27

27

Ting der kan gå galt (i RFC):

- NOIS har ikke fortalt godt nok hvad de vil have udført.

- Der kan være noget T&I ikke har helt styr på i deres miljø.

”Så er det godt at T&I er ”inhouse”, så de har ’domænekendskab’ og problemerne nemmere kan løses (man

kan snakke sammen)”.

At RFC ere bliver ”deployed” tirsdag og Torsdag på NOIS, hvilket ifølge Poul er med til at strukturere

’deres’ (T&I’s) hverdag. Dette er til tider dog lidt for rigidt for NOIS folkene.

Ingen ændringer om fredagen (helst heller ikke mandag). Engang lavede de en ændring lige før

julefrokosten, hvilket gik galt.. og af skade bliver man klog.

Lidt utilfredshed med at RFC’ere skal laves på selv de mindste ændringer.. f.eks. en enkelt indstilling på en

Switch.

Opfattelsen af arbejdet med RFC’erne er at man som halvoffentlig virksomhed skal registrere, således at man

kan dokumentere hvad man laver. Det er med til ikke at blive anskuet som et ’costcenter’ (avisoversigt

”Energinet sløser med elforbrugernes penge”). Synligheden er rigtig god. Det er godt at man har en proces i

stedet for at man bare ændrer løs i systemerne.

Der er nogle pre-udfyldte ting i RFC’en, så man ikke skal udfylde en blank RFC hver gang.

Et eksempel på en RFC: Stamdata skulle ændres i NOIS systemet, som ikke kunne ændres fra

brugergrænsefladen. Derfor skulle der bruges et SQL script, som Alstom lavede og uploadede til en FTP

server. For at få SQL’en udført, så oprettede Poul en RFC mod T&I, som lægger den i ”pre-prod”. RFC’en

udfyldes med det mål at T&I ”med hovedet under armen” skal kunne teste SQL scriptet på pre-prod. RFC’en

ligger så i systemet med RFC’ere og venter (ingen indikation af hvornår der sker noget). Poul vil gerne have

udført den i dag/imorgen, så han mailer til Steen fra T&I. Han siger så.. hmm.. ok og trækker i trådene og

får Lasse til at udføre den hurtigt. Poul laver sideløbende en RFC til at få SQL’en i produktion, men noterer

at det kun skal ske, hvis pre-prod testen gik OK. Lasse ser denne RFC og ringer og spørger om den skal

lægges på ”produktions” systemet og om testen er overstået og alt er OK. Det siger Poul, som har testet på

pre-prod i et par dage, OK til. Lasse sender en mail ud til diverse interessenter om ændringen og beder dem

henvende sig, hvis der er indvendinger. 15 minutter senere udfører han ændringen og sender derefter endnu

en mail ud om at ændringen er udført. Dette er ikke farligt, da ændringen i første omgang er blevet diskuteret

i ”NOIS system gruppen” (NSG), som er et forum bestående af interessenterne. De har ikke noget med

RFC’erne at gøre. Poul er leddet mellem NSG (forretningen, 2 fra hver TSO) og den tekniske side af

systemet. NSG diskuterer ændringer og fungerer dels som ’modpart’ til Alstom, så de ikke bare kan gøre

hvad de vil (teknisk og til dels økonomisk). NSG sikrer at man ikke går i gang med noget som ikke kan lade

sig gøre i alle TSO’er og rent teknisk set i Energinet regi.

DPS / BizTalk:

Drift Planlægning System (DPS) der styrer planlægning af Elforsyning i Danmark. (BizTalk er deres

kommunikationssystem mellem interessenter).

DPS udvikles internt i Kærneprocesser.

28

28

4 miljøer: Udvikling -> test (tre niveauer af ’test’) -> preproduktion -> produktion. Der ud over er der

lokaltest på udviklernes PC’ere og der er sourcedatabase. Det bliver i alt til ca. 10 miljøer/systemer.

Ting (deployments) skal ske hurtigt. Der er brug for fleksibilitet, da DPS er meget vigtigere end NOIS. Uden

DPS så kan kontrolcenteret ikke arbejde, hvilket kan gøre at de mister overblikket og i sidste ende kan dette

påvirke elpriserne.

Scrum bliver brugt som udviklingsmodel. Derfor skal der ’deployes’ når et Scrum-rul er overstået.

RFC er en process men i realiteten er det bare en formular. Der er plads til fortolkning til indholdet i RFC’en,

hvem der skal informere hvem og hvem der har ansvaret for hvad. Især mht. information er der et problem.

Eksempel: Hvis en deployment går i stå, så skal der ske en håndtering af situationen. Her er der forskellige

opfattelser af om T&I skal gå direkte til kunden eller om T&I skal kommunikere med Kærneprocesser, som

kommunikerer med kunden, hvilket har været deres ansvar hele tiden. (Min obs: Dette er et produkt af

uformelle OLSA/SLA’ere). Der er forskellige opfattelser både inden for de enkelte afdelinger og mellem

dem (det kommer an på hvem man spørger).

Willem: Information er klart det vigtigste i forbindelse med Change Management.

Der er brug for at rette en fejl inden der laves papirarbejde, hvis fejlen er skadelig for forretningen. Der må

herefter laves RFC’ere og hvad der ellers hører til.

I DPS er der et systemteam (ækvivalent til NSG i NOIS (der er ikke den store forskel på de to fora)).

Systemteamet er repræsenteret af Kontrolcenteret, Markedet (kunder) og af afregning (’Billing’). Her

prioriteres opgaverne i DPS, således at der er en rimelig fordeling (forhandling) af ressourcerne der sørger

for at tilgodese hele markedet (TSO). Dette skaber også forståelse for at de opgaver der udføres er af rigtig

prioritet.

RFC procedure:

Bruger RFC/Change Management procedure fra ”Teknik & Infrastruktur” (T&I)

Deploy 4 gange om året

SCADA:

Materialestyring overvågning- og konfiguration af forsyningskabelstationer. Styring af

transformatorstationer.

En tredjepartsleverandør (Alstom) sørger for applikationen.

I SCADA gruppen bruges ikke RFC’ere (særlig ofte). Her er tætte skodder mellem T&I og SCADA. T&I

passer infrastrukturen. Når de skal lave en ændring på SCADA infrastruktur, så informerer de selv SCADA

kunderne.

Change Manager i SCADA (4 processer) (Beskrevet i dokumenter, sendt via mail fra Willem)

29

29

1. Scada (Konfiguration af f.eks. skærmbilleder, database)

2. Scada (ditto)

3. Leverandør (Kommer med ændringer til SCADA.)

4. Infrastruktur (T&I kommer med ændringer)

Change Manager styrer alle ændringer ved brug af eksempelvis SourceSafe. Ændringer lægges i kalenderen

på intranet. Der ’deployes’ på T-dagene (Tirsdag og Torsdag).

Man har valgt at arbejde på denne måde i SCADA, da det er et forretningsmæssigt kritisk system og da man

har mange ændringer/konfigurationer.

Interface mellem SCADA og T&I er meget vigtigt

De tre systemer er integreret. BizTalk bruger SCADA data til afregning. DPS sender driftsplaner til SCADA,

som så kobler rundt og forsyner i hvenhold til planerne. SCADA stiller også data til rådighed for DPS og

NOIS.

Et komplekst eksempel på integrationen, som skal kunne håndteres:

I SCADA er der en DB som stiller data til rådighed for BizTalk som sender information ud til flere systemer,

bl.a. internettet, når befolkningen skal have indsigt i forsyningstallene. T&I laver ændring i DB hos SCADA

som genererer nedetid. Der er tre grupper der er involveret. Hvordan skal informationsprocessen forløbe til

Kontrolcenter og andre kunder?

I dag: T&I mener SCADA skal lave RFC, selvom det er T&I der har taget initiativet til DB ændringen.

Grupperne BizTalk, SCADA og T&I snakker på tværs for at finde ud af hvad der skal ske hvornår. Grunden

til at T&I mener at SCADA skal lave RFC’en er at denne proces er relativ kompleks og derfor ønsker T&I

ikke kontakt til de eksterne kunder (Dette strider mod andre tilfælde hvor T&I gerne tager kontakt til

eksterne kunder). Til tider vil dette scenarie medføre at ikke alle kunder får besked om en given ændring og

at de opdager ændringen ved at de f.eks. står og mangler noget data fra systemet.

I SCADA er der en Change Manager. Her er der beskrevet et procesflow (se mail). Processen er ikke

værktøjsunderstøttet, men den følges tilnærmelsesvis.

NOIS (Poul) skal bruge målinger fra SCADA.

Snak med Change Manager fra SCADA (Jørgen):

Jørgen var i gang med at lave en ’deploy’ på SCADA. Dette gjorde at jeg ikke kunne spørge frit, da et sådant

deploy er tidskritisk.

Der er ikke noget der hedder ”pre-prod” i SACDA. Dog er der internet i SCADA et testsystem.

30

30

Der laves opdateringer på stand-by systemet, så hvis der er fejl, så kobles der tilbage på det andet system.

Der sker ikke udvikling (det er Alstom der står for dette), men Energinet/SCADA laver konfigurationer.

Alstom smider deres ændringer (notifikation til Change Management) på stand-by system og venter på at

SCADA afd. Laver et ’failover’ mellem stand-by og primært system i forbindelse med konfiguration.

SCADA har en kalender (Deploymentkalenderen). Alle ændringer bliver skrevet i kalenderen.

Versionsstyring af konfigurationsfilerne bliver lagret i ”MS Visual Source Safe”.

OAG = Open Access Gateway svarer til (er proxy for) Frontends, som er transformatorstationerne, til hvilke

opdateringerne/konfigurationerne skal skubbes ud.

RFC’ere bliver lavet hvis der er noget med serverne. F.eks. Alstom kan sige til SCADA at serveren skal have

en bestemt update for at den næste SCADA update kan fungere.

Når der skal lave ændringer (noget nyt) på en server, så skal der laves en RFC. Den får Jørgen T&I til at lave,

så godkender Jørgen den. Årsagen er at Alstom har en meget kompliceret ’struktur’ på serveren, som kun

T&I forstår qua deres tekniske infrastruktur viden.

Hvis der er fejl på SCADA systemet, så har de en incident-liste (denne bruger DPS også). Kontrolcenteret

ringer til vagten, som laver en incident-instans. Derefter bliver problemet løst og måske skal der laves en

RFC.

En ”opgaveliste” vedligeholdes, som tjener det formål, at visualisere hvad SCADA gruppen går og laver.

Den dækker alle opgaver der laves. Projekter og forskellige ændringer. Info kommer ind via e-mails.

Incidenter kommer ind til vagten og bliver skrevet i incidentlisten. Disse går forud for alt andet i prioritet.

Nogle requests kommer fejlagtigt ind (fra ’vagter’) til Helpdesk. Jørgen må her manuelt hente disse

henvendelser ind i opgavelisten.

Jørgen vurderer henvendelser i Helpdesks Incidentliste og finder ud af hvornår ting skal deployes og hvem

der skal arbejde med dem.

Nogle opgaver tager dage at udføre, andre tager år.

Systemteam: SCADA sidder sammen med forretningen (kontrolrum), Automation (laver det i marken

(målestationer)) og T&I. De kigger opgaverne igennem og prioriterer dem (minder om porteføljestyring).

Der er nogle opgaver der er ”pre-incident”, som er meget vigtige. Nogle incidenter bliver lavet om til

opgaver og bliver lagt i opgavelisten.

Det der mangler i huset er når vagten får et opkald, så ringer han til SCADA. De undersøger og finder ud af

at det hører til i ”Drift og Vedligehold” (D&V). Du fiser ud i felten og håndterer den. Herefter hører SCADA

ikke mere til den. Der mangler et visuelt spor, så man kan se hvad de enkelte ’sager’ er endt med og hvad

status er. Problemet er D&V, som er SAP orienteret og det spiller ikke sammen med SCADAs systemer.

SCADA har også prøvet T&I’s ”HP Servicedesk”, men det var for rodet. De kan kun bruge noget enkelt og

er derfor endt op med ’Opgavelisten’ og ’Incidentlisten’.

31

31

Kontrolrummet bruger SCADAs liste(r) til at skabe sig et overblik over hvad der sker (hvem har ’faklen’ nu

og hvad sker der). DPS opdaterer informationen i SCADA. Derfor er Kontrolrummets infokilde SCADA.

I og med at Kontrolcenteret er dem der opdager fejlene og rapporterer dem ned til SCADA, DPS og NOIS,

så burde de (ifølge Jørgen) også være ansvarlige for at oprette incidenter (altså være incident manager). Så

de (og andre) kan se hvor er fejlen henne nu og hvad er status. I dag er det SCADAs vagt der oprettet

incidenten (og RFC’ere) for Kontrolrummet. Kontrolrummet kan også ringe direkte til D&V, som registrerer

deres opgaver i SAP.

Vagten vurderer hvad er det for en fejl der er snak om og hvor er fejlen.

Nogle gange er opgavelisten for simpel. Der mangler flere værktøjer til at holde styr på tid og andre ting til at

visualisere ressourceforbruget.

SLA:

Energinet tilbyder kunderne produkter der overholder de OLA’er der er med T&I. Hvis kunderne vil noget

mere, så arrangeres det med T&I. Herefter udfyldes SLA, som fungerer som et forslag på ydelse til kunden.

Ledelsens støtte til projektet:

- Forretningen forventer færre fejl. ITSM er med til at forbedre. Dermed har projektet støtte.

3. Møde med Michael (Støtteprocesser)

Jeg startede med i et mødelokale sammen med Michael, Britta og Claus. Efter mødet gik jeg sammen med

Claus ned og så på ”SAP folkenes” måde at håndtere Changes på, hvilket skulle være ret unikt.

Kort fortalt, så har de lige som SCADA og andre grupperinger selv applikationsansvaret, hvilket giver dem

en ren grænseflade til T&I. SAP gruppen har godt styr på ”udvikling, test og produktion”, men der er ikke så

god integration med Helpdesk efter at en incident er overdraget til SAP… herefter forsvinder den i SAP

systemet (det er op til den enkelte medarbejder om han/hun vil lukke ’sagen’ hos Helpdesk).

Note: Det fænomen med at der (ikke entydigt og med begrebsforvirring) skelnes mellem requests (noget nyt)

og incidents (noget eksisterende) bunder i økonomi. Det er nemlig to forskellige konti. Om man foretrækker

at bruge én konto frem for en anden ved Michael dog ikke.

SAP: (Claus (En del af SAP gruppen))

Brugere / Helpdesk ringer/skriver til gruppelederen Willemose er ”tildeler” i SAP. Alle i SAP kan dog

tildele. Kun i Helpdesk systemet kan andre i firmaet få et overblik over hvilke ”sager” der har verseret i SAP.

Her i SAP er ’verdenssynet’ anderledes end i resten af huset. Det er med et glimt i øjet og samtidig med

stolthed at man hævder at være ’rigtig gode’ til det der med ændringer til SAP. SAP ser deres måde at udføre

32

32

tingene på som den eneste rigtige måde og alle andre bør gøre ligeledes. Dette ved de godt ikke er realistisk.

Derfor er det accepteret at de har deres eget aflukkede miljø, hvor de kan agere.

SAP ser en Change Request som ændringer til den eksisterende forretningsproces, som den er defineret i

SAP. Altså, afføder en Change Request en omkonfigurering af SAP. En ”Change” er både en ændring til

noget eksisterende, men kan også være noget nyt der skal oprettes. Hvis noget er lavet i SAP, men fejler og

der laves en ’sag’ i Helpdesk, så er det ikke en change. I SAP er der funktionspodelte arbejdsopgaver (ERP,

CRM, BusinessWarehouse, BusinessObjects, Portal, m.m.). Der er også et modul der hedder ”SAP

Solutions”, som styrer/dokumenterer hvordan alle de andre dele er sat op (meta-modul).

Trestrengsmiljø: Udvikling, Test, Produktion (Kræver et IM nummer i Helpdesksystemet)

Transport = Deploy

OSS = Indrapportering til SAP applikation Helpdesk system.

SAP bruger ikke deres Change Management modul, da de ved at det skal håndteres på tværs af It.

Lige som andre grupperinger, så bruger SAP også RFC mod T&I, når det kommer til net/server.

Acadre (ESDH): Britta (administrer Acadre og opretter brugere i SAP, m.m.)

Eksempel på Change Management:

En bruger sidder og arbejder med et dokument i Acadre og ser at der er ’koks’ i versionsstyringen. Det

melder brugeren ind til Helpdesk. Helpdesk laver en ”Interaction”og ’eskalerer’ den til en ”Incident”, hvis de

ikke selv kan løse problemet (Kun incidents til SharePoint bliver markert med ’severity’, da de bruger det til

at prioritere udviklingen. Resten er standard). Britta i Acadre sidder og håndterer Incidents for Acadre,

hvilket vil sige at hun ”tildeler” Incidents til de rigtige folk. Ligeledes er der er ”tildelere” i de andre

grupperinger (SAP, Sharepoint, AutoCad). Der er dog flere systemer end der er folk, så nogle folk håndterer

Incidents for flere systemer ad gangen.

Incidents til Acadre rapporterer hun til Trean i deres systemer. De arbejder på sagen og laver en patch, som

Britta så laver en RFC på mod T&I, da det er dem der har ”applikationsansvaret” på Acadre.

En undtagelse til standardproceduren: Er et problem alvorligt, så ringer brugeren direkte til Britta, som

forsøger at løse problemet selv. Kan hun ikke det (”lige nu”) eller er problemet meget alvorligt (der skal

yderligere tiltag til, så som en permanent løsning) , så opretter hun en Incident og laver en ”sag” i Treans

systemer. Kan hun derimod godt løse problemet (måske i telefonisk samarbejde med Trean), så gør hun det

og laver en RFC (i samarbejde med Trean) mod T&I. T&I og Trean sørger i samarbejde for at få løsningen

implementeret på Acadre systemet. Her samarbedes der, da Trean ikke vil udlevere scripts til T&I.

(bemærkning: Britta nævner sikkerhed ifm. Treans adgang til systemet og siger at T&I tidl. Er set lave

småændringer uden RFC’ere (on the fly). Ligeledes ’mistænkes’ Trean for at arbejde på live-systemet i

forbindelse med et script, hvilket gør at Acadre arbejder på at T&I skal være dem der kører scripts på

serveren.

Hos stort set alle trediepartsleverandørerne er der systemer, som håndterer indkomne ændringer. Nogle

gange bliver disse systemer brugt til at skabe overblik over hvad der er blevet ændret.

33

33

Eksempel på nyudvikling:

Proceduren er den samme som oven over, men her er det trediepartsleverandøren, eksempelvis PeopleNet,

som kommer med en opdatering. PeopleNet bruger Energinets Helpdesk system og opretter selv en Incident.

I Sharepoint gruppen bliver Incidentlisten fra Servicedesk brugt som opgaveliste. På baggrund af Incident’en

bliver der oprettet en RFC (mod T&I).

Niels-Jørgen er Arkitekt, Udvikler og administrator af SharePoint. I princippet er det ham (i

SharePointgruppen) der er tættest på Helpdesk systemet, men reelt er det Britta der henter opgaver ud fra

Helpdesk og distribuerer dem ud til folkene i SharePointgruppen. Britta er ”tildeler” på ”assignment-

grupperne” Sharepoint, Meredian og Acadre/ESDH, hvilket vil sige at hun ’screener’ og tildeler Incidents til

folkene i disse grupper (Energinets egen folk eller konsulenter). (Min obs: Er hun Change Manager?)

I Helpdesk (Selfservice) systemet er der vha. en checkboks mulighed for at angive om en ”Interaction” drejer

sig om en ”forretningsapplikation” (Støtteprocess domænet) og man har mulighed for at angive hvilken

applikation der er tale om. Dette resulterer i at en ”Interaction” vil blive sendt til en såkaldt ”assignment-

gruppe”, hvilken kan være SAP, SharePoint, Acadre m.m. Årsagen er at Helpdesk hos T&I generelt set ikke

er i stand til at afgøre hvad der specifikt er galt og hvad der skal ske når vi snakker specielle applikationer.

Eksempel: En person i ”assignment-gruppen” Acadre håndterer en ”Interaction” og opretter en ”Incident”,

som herefter bliver tildelt en person i den respektive gruppe. I de tilfælde hvor T&I skal bruges til at udføre

noget arbejde (netværk/Server), så opretter dén der opretter en specifik Incident også en RFC.

Min obs: At det er noget rod i Itafdelingen er så som så, men det vigtige er at brugeren har ét sted at

henvende sig og det er Helpdesk hvor han/hun opretter en ”Interaction” (som det hedder i HP ServiceDesk

system).

Sharepoint:

Applikationsansvar ligger pt. Hos T&I, men vil med indførslen af SharePoint2010 blive flyttet til SharePoint

gruppen.

Eksempel på rutineopgave som ikke fungerer:

Oprettelse af en bruger (ny medarbejder, konsulent, m.m.) bliver ordnet gennem Helpdesk, hvor der oprettes

Incidents mod alle de systemer, som har en ’aktie’ i forbindelse med oprettelse af en ny bruger. Problemet er

at: information mangler, Incidents bliver glemt og koordinering fungerer ofte ikke.

Accountability:

Snitfladen mellem Støtteprocesser/Kærneprocesser og T&I. Hvem skal prioritere hvor vigtig en RFC er?

T&I eller ’os’? Hvem skal afgøre om den overhovedet skal udføres? Ofte kan der gå mere tid med at

diskutere om den skal udføres end det tager at udføre den. Der er en gråzone mellem administration af

platformen (net/server) og applikationen (f.eks. SharePoint).

34

34

Note: Der er forskel på ”Konfigurationsændringer” og ”Applikationsændringer”, da konfigurationsændringer

foregår i applikationsgrupperne (så det falder uden for den strømlignede proces (der bliver lavet hurtige

ændringer uden at de bliver registreret i Change Management systemet (incident/RFC))) og

applikationsændringerne foregår hos trediepartsleverandørerne. Årsag: Det er ikke noget T&I skal ind over,

så det behøves ikke… men vi mangler at visualisere dette arbejde.

Systemer I Støtteprocesser:

SAP (ERP administration)

Acadre/ESDH (Trediepartsleverandør: Trean)

Sharepoint (Trediepartsleverandør : PeopleNet)

GIS

Meridian (tegninger)

AutoCAD (Design)

Mega (Proceskortlægning)

Panda (Afregning)

Selvbetjeningsportal

DataHub

Note: Der bliver gjort brug af en ny tredjepartsleverandør for hvert system.

4. Møde med Birger

Jeg har i arbejdet med Change Management fået mange gode input og dannet mig et godt billede af hvordan

ændringer håndteres hos Energinet. Når jeg skal sætte denne kontekst sammen med nye idéer til Change

Management, så opstår der nogle tvivlsspørgsmål omhandlende It-strategien og It-effektiviseringsprojektet.

Jeg har derfor arrangeret et formelt møde med Birger.

Note: Jeg har haft i alt haft fire møder med Birger. De andre tre møder har jeg ikke inddraget som empirisk

materiale i opgaven, da møderne mest har omhandlet metasnak, dvs. snak om masteropgavens

omstændigheder hos Energinet. Det kan ikke undgås at der er diskuteret emner omhandlende Change

Management, men jeg har sørget for at få denne information dækket ind i den dokumenterede empiri.

Motivation for at effektivisere Change Management og Incident Management (ITSM):

35

35

Ligger der nogle krav i DataHub projektet om at Incident Management skal eksistere? Hvis ”ja”, hvad er

årsagerne til dette?

Svar: Der ligger en klar forventning til at Incident håndteringen er på plads. ”Den eksterne Helpdesk”

(kaldet: Frontoffice (elmarkedets Helpdesk)) skal kunne håndtere opståede problemer i forretningspraksis.

Der er således et interface udadtil og et indadtil. Service Management (It-effektiviseringsprojektet) er således

en del af DataHub projektet.

Spørgsmål: Har man i DataHubprojektet overvejet hvad der skal til for at etablere Service Management

principper i Energinet?

Svar: Nej.

Spørgsmål: Hvad var motivationen/årsagen for valg af ”Incident Management” og ”Change Management”

processerne, som de første der skulle implementeres? (Devoteams rapport?)

(Fra forretningsstrategien: ”I 2009 blev der foretaget en større europæisk TSO-benchmark, hvor

Energinet.dk blev lavt placeret. Derfor skal der fokus på dokumentering af effektivitet. Er Service

Management en del af denne strategi i IT-afdelingen?”.)

Svar : It-effektiviseringsprojektet blev igangsat uden et egentligt kommissorium, men på baggrund af den

europæiske TSO-benchmarks (en ’cost-exercise’) konklusion om at Energinet havde et

effektiviseringsproblem og dermed er blandt de 25% dyreste selskaber i Europa. Projektet hyrede Devoteam

til at analysere situationen i It-afdelingen. Der er ud fra Devoteams rapport at indsatsområderne IM og

Change Management blev udtaget.

Incident først, da det er den proces der ’gennemsyrer’ alle grupperingerne i It-afdelingen. Det er der hvor It-

afdelingen har den højeste frekvens og det er der hvor vi ser størst forskellighed i arbejdsprocesserne.

Change Management er valgt ud fra samme principper, men vigtigheden vurderes lidt lavere end ved

Incident Management.

Årsagen til at man ikke ser på projektet, som et ITIL projekt er at Devoteam, på baggrund af Energinets It-

infrastruktur modenhed (se bilag 2 ”D-IMM undersøgelsen”), har frarådet Energinet at se på andet end de to

processer. Årsagen skulle være at ca. 80% af alle ITIL projekter fejler, da man tager for meget med.

I projektet har man derfor besluttet, ”ret firkantet”, at arbejde med Change Management og Incident

Management, da disse skal være på plads, før man kan gøre andre ting, som f.eks. Service Level

Management, da denne ligger ’højere oppe’ i processtakken.

Spørgsmål: Er projektet en klart defineret del af It-Strategien? Eller er det et initiativ taget på baggrund af

forretningsstrategiens krav om 1)”dokumentation af effektivitet” og 2)”Intern måling af effektivitet”?

(Fra forretningsstrategien: ”I de seneste år er der flere gange blevet stillet spørgsmålstegn ved Energinet.dk's

effektivitet. En systematisk intern måling af virksomhedens egen effektivitet vil understøtte en løbende

opfølgning på, om de eksterne målinger er dækkende for Energinet.dk's aktiviteter.”.)

Svar: Nej, projektet udsprang af den i pkt.1 nævnte benchmark-undersøgelse.

36

36

Mantraet er: ”Standardisering + Automatisering = Effektivisering”.

Spørgsmål: Hvad hvis ITSM skaber effektivitet, men faktisk øger driftsomkostningerne? Problemet er at dét

at blive mere effektive, ikke altid fører til omkostningsreducering, hvilket var motivationen for It-

effektiviseringsprojektet.

Svar: Det er ikke sikkert at vi gør tingene billigere med dette, men den kvalitetsforbedring det er at gøre

tingene bedre, har en stor forretningsværdi. I det lange løb vil der kunne spares penge, da man i ITSM

konceptet har Continuous Service Improvement (CSI). Hermed udvikler man hele tiden Servicekonceptet i

It-afdelingen og slipper efterfølgende for større Business Process Reengirneering (BPR) runder.

Det gamle ITIL projekt: (Se Bilag 4 for yderligere oplysninger)

Spørgsmål: Kender du til et tidligere ITIL projekt? (Steen og Willem har nævnt det).

Svar: Ja. Søsat af Niels Såby.

Spørgsmål: Baggrunden for projektet var en undersøgelse lavet af IBM (hvilken type undersøgelse var det?

Svar: Vides ikke.

Spørgsmål: Hvorfor blev projektet ’lagt på is’?

Svar: Alt for omfangsrigt. Over budget. Lukket ned da det hele løb løbsk.

Spørgsmål: Er dette projekt nu ’tøet op’ igen? Eller er der snak om et nyt projekt? Er det så et ITIL projekt

eller hvad kan det kategoriseres som?

Svar: Nej.

Spørgsmål: Er dette projekt årsagen til at man ikke vil køre ”It-effektiviseringsprojektet” i henhold til ITIL

konceptet?

Svar: Nej, det er fordi Claus (CIO) og Jørgen er ikke store tilhængere af ITIL. Vi bruger ITIL terminologien,

da det er den der bruges i branchen. Det er således et It-effektiviseringsprojekt der baserer sig på (begreber

og inspiration til udførelse af arbejdsprocesser) ITIL. Vi gør dette fordi man ikke kan snakke med nogen som

helst, hvis ikke man må bruge ITIL termer. I DataHub projektet har vi lavet et ”ITIL intro kursus”, så det er

accepteret (læs: Blandt medarbejderne) at vi bruger ITIL, men det er ikke et ”ITIL projekt”.

Spørgsmål: Hvis det ikke er et ”ITIL projekt” (sidekommentar: ITIL dokumentationen siger at ITIL ikke må

køres som et projekt, det er noget der skal adopteres og man skal tilpasse sig ITIL konceptet), men et ”It-

effektiviseringsprojekt”, der har en start og en slutdato, så køres det som et It-projekt med en start og en

slutdato. Hvad så bagefter? Hvad med den Continual Service Improvement (CSI), som er én af

effektiviseringerne ved at bruge ITILv3?

Svar: Det er også noget jeg skal til at sætte fokus på. Vi skal finde ud af hvordan organisationen ser ud efter

projektet. Altså, hvordan ejerskabet for processerne ser ud? Hvem skal drive det videre? Der er dog ikke stor

37

37

entusiasme for at snakke om omorganisering. Der er allerede planlagt nye projekter f.eks. med udarbejdelse

af andre processer som eksempelvis ”Problem Management”. Dog er der ingen konkrete planer endnu.

It effektiviseringsprojektet:

Spørgsmål: Hvordan er man fundet frem til at der skal startes med ”Incident Management” og ”Change

Management” og at It-systemet skal være Microsoft Service Manager?

Svar: Vores It-platform er udgjort af Hp og Microsoft produkter. Vi så på HP og MS og et andet proprietært

system, men endte med MS Service Manager, da vi kun skal betale få licenskroner kan vi addere Service

Manager til vores MS Solution Center (MSC). Hermed kunne der bruges flere kroner på andre ting.

Spørgsmål: Hvad er målene for brugen af ITSM? Effektivitet? (services, It-systemet m.m. er midlerne)

Svar: At lave It-afdelingens ydelser om til services, så man får overblik. At få defineret forretningsansvarlige

og Systemansvarlige (fordelt/klargjort roller). Når dette er på plads, så kan infrastrukturen i It-platformen

hægtes op på disse services. Når disse ting spiller sammen, så kan vi få et overblik over Incidents og

Changes, således at vi kan skabe rapporter, der giver information.

Spørgsmål: Hvordan måles effektivitet (Hvad vil man opnå i brugen af Change Management (læs:ITSM)?

(Overblik over serviceydelser og kostprisen; Skabe værdi for kunden))?

Svar: Der er ingen Kritiske succes faktorer (KSF). Målet er at alle ydelser skal være defineret som services

(Note: men der er ikke sat tal på ”hvad alle services er”).

Spørgsmål: Hvad ligger der i projektet, som skal sikre at folk får svar på ”Whats in it for me?”

Svar: John (med sælgererfaring) ’sælger idéen’ når han er ude og snakker med interessenterne. Tilpasninger

til deres kontekst loves og feedback tages med tilbage. Hermed sikres velvilje og de kan se fordelene. I og

med at DataHub projektet er noget nyt, så er folkene ikke ”servicetrætte”, hvilket gør at de ’trækker’ andre

med (Note: sneboldeffekt?).

Spørgsmål: Hvilke Service Management initiativer er planlagt for at kunne udføre f.eks. Change

Management?

Service catalog (brugervenlig terminologi (se SCSM210 unleashed s.60))?

- SLA’ere?

- Håndtering af kvalitet, kostpris, værdi(SLA)?

- Change ManagementDB

Svar: Ikke andet end det der tidligere er nævnt (Change ManagementDB og Service katalog).

38

38

Spørgsmål: Har I i projektet kigget på ”Service Strategy” og ”Service Design”?

Svar: John kender til det, men det er ikke noget vi har brugt som udgangspunkt.

Spørgsmål: Du har før sagt at I skeler til ITIL og MOF. Hvad bruger I MOF til?

Svar: Vi bruger ikke MOF så meget, men når vi mangler konkrete retningslinjer for hvordan man udfører

noget i praksis, så lader vi os inspirere af frameworket.

Spørgsmål: Hvordan ser man på den fremtidige arbejdsgang, når ”Change Management” og ”Incident

Management” er taget i brug? (Vil man mokke de gamle arbejdsgange ind i Service Manager toolet? Vil man

beholde den gamle terminologi?

Svar: Arbejdsopgaverne vil ikke ændre sig. Dog er der endnu ikke planlagt nogen ’support struktur’ der skal

drive Service Management.

Spørgsmål: Hvornår slutter projektet? Hvad sker der efterfølgende? (Audit og vedligehold af ITSM

processerne)

Svar: Det slutter 1/6 2012. Der kommer opfølgningsprojekter og der skal gøre løsninger mere vedvarende og

løsningerne skal spredes ud til flere områder (Note: Hvilke er ikke omfattet af projektet i dag?).

Misc:

Spørgsmål: Hvor formelt er ansvaret for It-systemerne? Der er en rolle der hedder ”Applikationsejer”,

”Applikationsansvarlig”, ”It-systemejer” eller bare ”systemejer”. Er rollen og ansvaret dokumenteret.. hvor?

(Kan man kalde det for It-Governanace?)

Svar: Ikke godt. Der står lidt rundt omkring, men nej.

5. IT-Leder møde

Intro v. Thomas (5 min.)

Ericsson 10 år. Udvikler og systemtester. 200 mand fyret. Præge min fremtid ved at uddanne mig.

Masterstuderende ved It-Vest. Universiteter vest for Storebælt. Jeg har været i gang siden februar 2010 (2 år

– op til 6 år).

[Jeg optager mødet]

Jeg har fået mange gode input og dannet mig et godt billede af hvordan Change Management håndteres hos

Energinet.

Jeg har læst D-IMM rapporten (Devoteam) og er bekendt med resultater og beslutninger herfra. Bl.a. at de

har anbefalet at starte med ”IM” og ”Change Management”.

39

39

Der er opstået tvivlsspørgsmål omhandlende It-strategien og It-effektiviseringsprojektet.

ITSM principper og It-effektiviseringsprojektet (5+ 30 min.)

Spørgsmål: Hvad er It-ledelsens rolle i It-effektiviseringsprojektet?

It-ledelsen har igangsat projektet, som en del af It-strategien fra 2009-2012. Her er et af ’sporene’ It-

effektivisering. It-ledelsen er øverste ansvarlig. Det forventes at omlægge omkostningerne (hverken at forøge

eller mindske dem) fra f.eks. fra HP Service Center til Service Manager.

Spørgsmål: På hvilket plan vil I bruge IT Service Management (ITSM) principper? (Terminilogien,

værktøjerne, Continual Service Improvement, m.m.). Som det ser ud, så er I meget teknisk fokuserede.

Svar: Det (teknisk fokuseret) bliver det ikke. Der kommer til at foregå et arbejde med at finde ud af hvem der

ejer hvilke services og hvem der står på mål (min note:accountable) for serviceprocesserne.

Forklaring af ledelsens opfattelse af Service Management strukturen:

Vi vil ikke centralisere ansvaret (til en person/enhed) for hvem der har ansvaret for processer og flows. Det

vil vi ikke gøre, da det vil blive ”en stat i staten”. Vi vil decentralisere ansvaret på en måde så der er én

person i f.eks. SCADA systemet der har ansvaret for services og processer. Hun vil have ansvaret for at

registrere problemer og få dem ordnet. På den måde bliver tilgangen praktisk, da det er den daglige kontekst

i systemgruppen der definere om noget fungerer. Det skal ikke være en central gruppe, der sidder og siger at

noget strider mod ITIL principper og derfor laver det om. Der skal dog være en erfagruppe, som skal sikre at

man ikke bryder ’normerne’ i systemet, så man holder sig inden for de serviceorienterede principper.

Spørgsmål: Projektet kører med en start og en slutdato, men hvad skal der ske bagefter?

Svar: Ja der er en start og en slutdato på enkeltdelene af projektet, men der er en ’blød bagkant’ og vi ved

ikke hvor dybt og bredt denne serviceorientering bliver før vi er ude i at effektivisere marginaler.

Men jo det er et projekt og et projekt stopper.

Min kommentar: Men det gør Management Processerne ikke. Er der etableret en struktur, som sørger for

deres vedligeholdelse?

Svar: Det er netop det vi decentraliserer. De enkelte applikationsgrupper har ansvaret for at tingene fungerer

i relation til kunder m.m.

Spørgsmål: Er der et fælles forum på tværs af disse grupper, som sætter sig sammen og kigger på om Change

Management fungerer?

Svar: Der er ikke etableret eller planlagt nogen struktur til dette endnu, men da det er et af formålene at

ensarte (standardisere) vores måde at gøre det på, så er ’den forretningsmæssige implementering’ helt klart

noget vi skal have set på, når det andet er implementeret. Det er nemlig ikke noget der skal være statisk og

som skal leve sit eget liv. Det er noget der skal ’trimmes’ og holdes ved lige over tid.

40

40

Det kunne så være en leverance i projektet at få dette etableret. Til forskel fra normale It-projekter, hvor

projektet termineres ved leverance, så termineres dette først efter ibrugtagningen. Det vil sige at services skal

være dokumenterede og forretningen skal være i stand til at bruge dem.

Spørgsmål: Energinets It-afdeling vil transformere ”It-ydelser” til ”It-Services”. Skal disse håndteres efter

Service Management principper (ITSM)? (Forbedringskonceptet (CSI), Måling- og opfølgningskonceptet,

Informationshåndteringskonceptet)

Dette spørgsmål stillede jeg ikke, da jeg i det foregående spørgsmål blev klar over at man har planer om at

etablere en ansvarsstruktur for services. Der er så godt som ingen planer om ledelse af Service Management

processerne. Det eneste der peger lidt i denne retning er planerne om en ’erfagruppe’, som er et forum for

udveksling af erfaringer. Der er (indtil videre) i dette projekt ikke planlagt at gøre brug af ITSM tiltag, som

går i dybden med de serviceorienterede principper, der skal sørge for administrationen af Service

Management processerne.

Services = Daglig drift og vedl. af midlerne i et serviceorienteret system.

Processer = Administrationen af Service Management processerne, der på metaplan sørger for Service

Management af de fysiske services.

Spørgsmål: Mine undersøgelser har vist at It-effektiviseringsprojektet ikke må kaldes for et ITIL projekt.

Dog bruges bl.a. ITIL i et vist omfang.

Hvorfor vil man ikke gøre den allerede eksisterende brug af ITIL og andet ITSM materiale mere eksplicit?

Dels fordi ITIL er for stort. Der er alt for mange roller til vores lille organisation.

ITIL bliver også meldt ud, som noget vi gør brug af, men på et niveau der skal inspirere og informere.

Projektet skal være praktisk orienteret. Det skal ikke være ITIL teorien der driver projektet. Den drivende

kraft skal være sund fornuft, der er støttet af noget ITIL.

ITIL er dybt og bredt. Man kan ’gå til i det’, hvis man ikke har en pragmatisk tilgangsvinkel til det.

Der har kørt et 6 timers ITIL seminar, hvor forretningen var inviteret. Det var et smadder godt seminar, hvor

forretningen godt kunne se det smarte i at vi bruger ITIL.

Note: Der var ingen fra It-ledelsen, ud over Claus (CIO), som deltog ”i det meste”, der var med på seminaret.

Distancen er noget vi selv har påtaget os. Det har også noget med at gøre, at vi er en ingeniørtung

virksomhed, så hvis vi sagde ”det her er ITIL”, så ville det hele ende som et stort diskussionsforum.

Der blev givet et eksempel: Energinet fik hostet en applikation hos en trediepartsleverandør, som var ITIL-

ficeret til fingerspidserne. Her havde Energinet ikke ”et ingangspunkt”, som det bliver lovet i ITIL, men man

stødte hele tiden ind i hvem der nu var procesansvarlig for den enkelte ITIL proces. Det vil vi ikke ud i.

Vi vil hellere gøre det her decentralt og lade arbejdsopgaver og ansvar opstå på behovsbasis (det der er

nødvendigt) og ikke etablere et stort centralt styret system, der kun fokuserer på at gøre det rigtige i forhold

til ITIL. Dette vil måske bidrage mere til forvirring end til en løsning. Et miks af ’empowerment og

autonomi’.

41

41

Et tillægsspørgsmål:

Hvad så med standardiseringen/koordineringen, når man her satser på decentral styring. Det man forsøger på

at komme til livs er jo at tingene bliver gjort forskelligt i de forskellige grupperinger. Hvordan vil man

koordinere indsatsen?

Det kunne være en fare, men der skal ske en central implementering, med en decentral opfølgning.

Spørgsmål: Man har valgt ”Incident Management” og ”Change Management” processerne, som de første der

skulle implementeres. Hvordan planlægger man at vedligeholde dem når projektet er slut?

Dette spørgsmål valgte jeg at springe over pga. tiden og da Birger allerede havde svaret på det.

Spørgsmål: Hvordan har man tænkt sig at gøre disse serviceydelser ”serviceorienterede”, når elementer som

”Service Level Management” (SLA, OLA, UC) ikke er taget med?

Svar: Det der mangler (på nogle områder) er OLA’ere indad til egen drift.

Vil man gentænke de forskellige aftaler i forhold til de nye services?

(Lidt uklart svar.) På nogle områder ”ja”, men services vil blive lavet i henhold til de eksisterende aftaler.

Note: Man ser ikke stor værdi i at have for mange aftaler på andre områder end udad til. Indadtil er det mere

uformelt.

Forretnings/It-strategien og It-effektiviseringsprojektet (35+ 50 min.)

Intro: It-Effektiviseringsprojektet er et relativt stort projekt, som har indflydelse på arbejdsgangene i It-

afdelingen. Derfor er jeg interesseret i de strategiske overvejelser.

Spørgsmål: Er der udarbejdet en "It-strategi", der tager udgangspunkt i forretningsstrategien for 2012-2015?

(Jeg spørger fordi motivationen for "It-effektiviseringsprojektet" kommer fra TSO-Benchmarks, der har

skabt fokusområder i forretningsstrategien. Ergo må/bør den It-Strategien 2012-2015 sige noget om dette.)

Svar: Nej. Der er udarbejdet nogle ”It-spor” til at understøtte strategien med. I forbindelse med It-

effektiviseringsprojektet og ITIL, så er et af sporene ”Fælles supportprocesser”. Her er netop ITIL og hele

Service Management (ikke kun IT) noget som vi vil have implementeret dybt i organisationen. F.eks. skal et

problem med et regnskabsprogram gå gennem en service i stedet for at man kontakter applikationsgruppen

direkte. Derefter skal kontakten med trediepartsleverandøren også ske gennem systemet, således at hele

’sagen’ logges i systemet fra forretningen til service leverandøren (om så leverandøren er intern eller

ekstern).

42

42

Der er ikke flere spor i forbindelse med Service Management. Der er et overordnet spor der omhandler

’effektivisering’ der har kroner/øre m.m. som mål og her kommer ITSM ind.

Spørgsmål: På hvilke områder kan ”It-effektiviseringsprojektet” siges at være en del af It-strategien? (eller

forretningsstrategien). Kan det ledes tilbage til omkostningsminimering?

Nej, der er mere tale om effektivisering end omkostningsminimering. Der ligger nogle store

projektporteføljer for Energinet de kommende år. Allerede næste år der det den højeste invisteringsportefølje

vi har haft nogen sinde. Det kræver noget at kunne absorbere den. Man skal lave mere for det samme eller et

mindre beløb.

TSO-Benchmarken bliver hvert år målt procentmæssigt i forhold til anlægsmassen. Altså skal

omkostningerne til drift blive mindre, set i forhold til stigningen i anlægsmassen. De to må helst ikke stige

proportionalt og drift må slet ikke overstige anlægsmassen. Den ønskelige situation er at

driftsomkostningerne falder, som følge af bedre effektivitet.

(TSO benchmark = E3 grid) Teknisk og finansielt i topklasse, men procesmæssigt er der nogle områder der

kunne forbedres. Det er det It-effektiviseringsprojektet går ud på. Medarbejderne får bedre værktøjer og

mere smidige processer.

Spørgsmål: Projektet er altså ikke en afvisning af køre det serviceorienteret, som ITIL foreskriver?

Svar: Nej, vi kommer til at køre meget serviceorienteret. Det er hele grundstammen i den måde vi vil gøre

det hele på. Men vi går ikke ind og laver en ’mediekampange’ der siger at nu skal vi være serviceorienterede.

Spørgsmål: Men folk skal vel have at vide hvordan de skal bruge de nye systemer og hvordan de skal

bestride diverse roller og ansvar?!

Svar: Nej, det er kun indad til i It-afdelingen.

Svar fra mig: Det er også It-afdelingen jeg snakker om. Forretningen må gerne se på ITSM, som en

’blackbox’, hvor de har en række services og en helpdesk de henvender sig til.

Kommentar: Jamen, hele forretningen kommer til at kunne drage nytte af det nye system.

Mit svar: Kan du ikke uddybe det?

Svar: F.eks. facility kan i Service Manager tilbyde deres services på samme måde, som vi tilbyder Incident

Manager.

Note: Her snakkes der om Business Management, som bliver integreret med It-Service Management. Dette

er uden for mit scope i opgaven, men en alignment mellem It og forretning med dertil hørende IT-

Governance er et nobelt mål.

Note: Det er lidt mit indtryk at det der udgør ”Service Management” i ITSM konceptet, udelukkende bliver

set på som dét at tilbyde services. Jeg mener at der ligger mere i det end det.

43

43

En kommentar (fra Claus) der kom frem noget senere: Da du før spurgte til ITIL, så troede jeg at det var i

forhold til hele forretningen. For selvfølgelig er vi bevidste om ITIL internt i It. Men vi er også bevidste om

vores egen måde at gøre det på.

Spørgsmål: Når man ikke vil lave ”en mediekampange” for at gøre opmærksom på at man bruger ITIL,

hvordan vil man så sikre at folk kommer til at bruge et fælles begrebsapparat? Skal der ikke oplysning til?

Jeg kunne forestille mig at den ”ITIL workshop” (seminaret) kunne være en god til. For en gangs skyld

mødte jeg én som var i stand til at sælge ITIL på en ”Stating the obvious” måde. Altså på en måde så hele

logikken og tankesættet bag ITIL blev klart. Kompendiet (fra workshoppen) kunne jeg godt forestille mig at

vi skulle arbejde videre med og lave noget ’awareness’ onkring.

Spørgsmål: Ønsker man at en del af den kommende It-Strategi skal være, at køre It-afdelingen efter ”It

Service Management principper”? (Det vil sige de ’dyder’ der danner rammen om f.eks. ITIL frameworket.)

Spørgsmål: Hvis ikke, hvilke arbejdsprincipper vil man så gøre brug af?

Ja, vi bruger meget ITIL, men vi har ikke biblen fremme. Vi kommer til at lave en businesscase på at køre

det på denne måde, hvor der er nogle ’cost-drivere’ og nogle ’benefit-drivere’. Efter ibrugtagningen af

Service Management, når It-effektiviseringsprojektet er slut, så kommer der en benefitrealiseringsfase, som

økonomiafdelingen får ansvaret for. Nogle af disse benefits er finansielle og nogle er non-finansielle. Der er

så dem man skal følge op på.

Spørgsmål: Vil det sige at man først vil have de tekniske ting på plads og derefter sigte efter at få gjort

brugen mere serviceorienteret, f.eks. mht. Service Level Management og andre ting?

Svar: Nej, vi faktisk to spor. Det første er ”Processporet”, hvilket er det vi er startet i. Dette spor handler om

hvordan man kører en Incident igennem. Både i It-afdelingen, men også i forbindelse med de eksterne

leverandører. Det andet spor er ”Tekniksporet”. Vi har valgt at køre disse to spor, da det handler om to

forskellige måder at tænke på. Det er en udfordring, men vi tror på at det er den rigtige måde at tænke på.

Kommentar fra salen: Vi trænger også til at gøre noget ved processporet, ikke?

Svar: Jo… de kommer til at fungere sådan at processporet stiller krav til tekniksporet og omvendt.

Min kommentar: Så er der sporet der hedder ”People”, hvor man har det I har defineret som

”ansvarsfordeling”.

Svar: Ja, det er rigtigt. Hele den decentrale struktur skal vi have gennemtænkt hvordan vi får foretaget den

her koordinering af de decentrale dele. Governancen omkring det her er ikke mejslet i sten.

Spørgsmål/kommentar: Ok, så jeg kan forstå at det her med at måle på tingene kommer senere hen i

forbindelse med benefitrealiseringen?

Svar: Ja, det kommer til at ligge i halen på det her og der ligger KPI’erne selvfølgelig.

Spørgsmål: Kan man sige at det kommer med i næste projekt?

44

44

Nej, man kan sige at effektiviseringsdelen kommer til at køre i ’en rum tid’. Hvert projektspor afsluttes, som

i alle andre projekter´, med en benefitrealiseringsfase der udføres, når man skal ’ud af’ en businesscasen…

når man har gennemført businesscasen.

Det er projektet skal definere KPI’ere af diverse arter.

Økonomi (85+ 10 min.)

Spørgsmål: Motivationen for ”It-effektiviseringsprojektet” er TSO-Benchmarken, som pegede på for høje

omkostninger. Der er endnu ikke planlagt initiativer der kan muliggøre finansielle målinger.

Hvordan vil It-ledelsen sikre at effektivitetsforbedringer (som følge af Standardisering + Automatisering)

fører til reducerede omkostninger?

(Hint: Financial Management IT under ”Service Strategy”)

Svar: Der er endnu ikke fastlagt nogle KPI’ere, da vi ikke har noget ’baseline’. Vi har en idé om hvor meget

der bliver løst samme dag.. ca.90%... men vi skal have flere målinger som udgangspunkt.

Spørgsmål: Hvad med nogle finansielle målinger? Dem der nævnes her er systemdriftsmæssige.

Svar: Sammen med økonomi kommer vi til at lave en økonomimodel. Vi skal vide hvad de forskellige ting

koster. Mht. hardware og software, så ved vi hvad det koster.

Spørgsmål: Hvad koster det så at patche en server?

Svar: Det niveau er vi ikke nede på. Vi måler i dag på kvaliteten og ikke på økonomi.

Spørgsmål/min kommentar: Hvis man kan visualisere hvor meget det koster at drive IT, så kan man også

vide at man gør noget ved omkostningerne.

Svar: Vi kunne godt måle på andre ting også. Vi skal bare passe på at der er et formål med målingerne. Det

er også noget af det man skal finde ud af i forhold til ITIL… hvor langt vil man gå og hvad er teoretisk

korrekt at gøre? Spørgsmålet er, ”Vil vi gå så langt ned?”. Vi er kun interesserede i at vide hvad et system

koster at drive år for år.

Vi vil hellere se på ”Hvor lang tid er vi om de enkelte ting” og ”i hvilken kvalitet udfører vi arbejdet”. Det

kan vi se ud fra antal RFC’ere og tilfredshedsmålingerne.

Spørgsmål: Hvornår bliver effektiviseringen til omkostningsminimering?

Svar: Hvordan kan man værdisætte effektivisering? Det bliver noget med at fastsætte en baseline, hvor man

så kan sige, at vi nu kan tage 10% flere opgave ind, fordi vi er dét mere effektive. Man kan vende

effektiviteten om og sige at vi er blevet mere effektive fordi at vi f.eks. kan se at der kommer mange

fejlindkald ind på et bestemt område, hvor vi så kan bruge informationerne proaktivt, og gå ud og

efteruddanne folk, så der ikke kommer så mange fejlopkald.

45

45

Organisationsændringer (95+ 10 min.)

Spørgsmål: Hvordan ser man den fremtidige arbejdsgang, når ”Change Management” og ”Incident

Management” er taget i brug? Vil der være ’support struktur’ der skal drive Service Management

initiativerne og holde dem ajour med udviklingen i forretningen?

Note: Dette spørgsmål er tidligere besvaret med, at der vil være decentral styring og central implementering.

Der ud over vil der være en erfagruppe der skal diskutere om Service Management fungerer.

Diverse (105+ 15 min)

Spørgsmål: Har It-ledelsen lavet en ’assessment’ på om IT Service Management kan hjælpe Energinet med

at udføre missionen? Altså, hvorvidt ITSM kan bidrage til de tiltag der er beskrevet i forretningsstrategien.

Svar: Der er som et led i forretningsstrategien (som er en del af missionen) blevet overtaget 32 ’stationer’ på

Sjælland, som gør at T&I øger deres anlægsmasse inden for WAN-delen med 40%, uden at lave en

personaleudvidelse. Det gør de bl.a. ved at fordele arbejdsbyrden mellem hvad de selv laver og hvad

trediepartsleverandørerne laver, således at arbejdsbyrden fordeles. Det er det samme vi gør med ITSM. Vi

etablerer et system, så brugerne ikke er så afhængige af at der er systemfolk i den anden ende, der kan klare

tingene for dem.

46

46

Bilag 7 ”ITIL Terminologi” I dette bilag bliver ITILv3 termer forklaret (Hanna, 2007), som jeg har vurderet er relevante for opgaven.

Availability Management (Service Design) The Process responsible for defining, analysing,

Planning, measuring and improving all aspects of the Availability of IT

Services. Availability Management is responsible for ensuring that all IT

Infrastructure, Processes, Tools, Roles etc are appropriate for the agreed

Service Level Targets for Availability.

Baseline (Continual Service Improvement) A Benchmark used as a reference

point. For example:

• An ITSM Baseline can be used as a starting point to measure the effect

of a Service Improvement Plan

• A Performance Baseline can be used to measure changes in

Performance over the lifetime of an IT Service

• A Configuration Management Baseline can be used to enable the IT

Infrastructure to be restored to a known Configuration if a Change or

Release fails

Best Practice Proven Activities or Processes that have been successfully used by

multiple Organisations. ITIL is an example of Best Practice.

Capability (Service Strategy) The ability of an Organisation, person, Process,

Application, Configuration Item or IT Service to carry out an Activity.

Capabilities are intangible Assets of an Organisation.

Capability Maturity Model

(Change ManagementM)

(Continual Service Improvement) The Capability Maturity Model for

Software (also known as the Change ManagementM and SW-Change

ManagementM) is a model used to identify Best Practices to help

increase Process Maturity. Change ManagementM was developed at the

Software Engineering Institute (SEI) of Carnegie Mellon University. In

2000, the SW-Change ManagementM was upgraded to Change

ManagementMI® (Capability Maturity Model Integration). The SEI no

longer maintains the SW-Change ManagementM model, its associated

appraisal methods, or training materials.

Capacity Management (Service Design) The Process responsible for ensuring that the Capacity

of IT Services and the IT Infrastructure is able to deliver agreed Service

Level Targets in a Cost Effective and timely manner. Capacity

Management considers all Resources required to deliver the IT Service,

and plans for short, medium and long term Business Requirements.

47

47

Change (Service Transition) The addition, modification or removal of anything

that could have an effect on IT Services. The Scope should include all IT

Services, Configuration Items, Processes, Documentation etc.

Change Advisory Board

(CAB)

(Service Transition) A group of people that advises the Change Manager

in the Assessment, prioritisation and scheduling of Changes. This board

is usually made up of representatives from all areas within the IT Service

Provider, the Business, and Third Parties such as Suppliers.

Change Management (Service Transition) The Process responsible for controlling the

Lifecycle of all Changes. The primary objective of Change Management

is to enable beneficial Changes to be made, with minimum disruption to

IT Services.

Change Model (Service Transition) A repeatable way of dealing with a particular

Category of Change. A Change Model defines specific pre-defined steps

that will be followed for a Change of this Category. Change Models may

be very simple, with no requirement for approval (e.g. Password Reset)

or may be very complex with many steps that require approval (e.g.

major software Release).

Change Record (Service Transition) A Record containing the details of a Change. Each

Change Record documents the Lifecycle of a single Change. A Change

Record is created for every Request for Change that is received, even

those that are subsequently rejected. Change Records should reference

the Configuration Items that are affected by the Change. Change

Records are stored in the Configuration Management System.

Change Request Synonym for Request for Change.

Change Schedule (Service Transition) A Document that lists all approved Changes and

their planned implementation dates. A Change Schedule is sometimes

called a Forward Schedule of Change, even though it also contains

information about Changes that have already been implemented.

Change Window (Service Transition) A regular, agreed time when Changes or Releases

may be implemented with minimal impact on Services. Change

Windows are usually documented in SLAs.

Configuration Item (CI) (Service Transition) Any Component that needs to be managed in order

to deliver an IT Service. Information about each CI is recorded in a

Configuration Record within the Configuration Management System and

is maintained throughout its Lifecycle by Configuration Management.

CIs are under the control of Change Management. CIs typically include

IT Services, hardware, software, buildings, people, and formal

documentation such as Process documentation and SLAs.

48

48

Configuration Management (Service Transition) The Process responsible for maintaining

information about Configuration Items required to deliver an IT Service,

including their Relationships. This information is managed throughout

the Lifecycle of the CI. Configuration Management is part of an overall

Service Asset and Configuration Management Process.

Configuration Management

Database (Change

ManagementDB)

(Service Transition) A database used to store Configuration Records

throughout their Lifecycle. The Configuration Management System

maintains one or more Change ManagementDBs, and each Change

ManagementDB stores Attributes of CIs, and Relationships with other

CIs.

Configuration Management

System (Change

ManagementS)

(Service Transition) A set of tools and databases that are used to manage

an IT Service Provider's Configuration data. The Change ManagementS

also includes information about Incidents, Problems, Known Errors,

Changes and Releases; and may contain data about employees,

Suppliers, locations, Business Units, Customers and Users. The Change

ManagementS includes tools for collecting, storing, managing, updating,

and presenting data about all Configuration Items and their

Relationships. The Change ManagementS is maintained by

Configuration Management and is used by all IT Service Management

Processes.

Continual Service

Improvement (CSI)

(Continual Service Improvement) A stage in the Lifecycle of an IT

Service and the title of one of the Core ITIL publications.

Continual Service Improvement is responsible for managing

improvements to IT Service Management Processes and IT Services.

The Performance of the IT Service Provider is continually measured and

improvements are made to Processes, IT Services and IT Infrastructure

in order to increase Efficiency, Effectiveness, and Cost Effectiveness.

Control Processes The ISO/IEC 20000 Process group that includes Change Management

and Configuration Management.

Early Life Support (Service Transition) Support provided for a new or Changed IT Service

for a period of time after it is Released. During Early Life Support the IT

Service Provider may review the KPIs, Service Levels and Monitoring

Thresholds, and provide additional Resources for Incident and Problem

Management.

Emergency Change (Service Transition) A Change that must be introduced as soon as

possible. For example to resolve a Major Incident or implement a

Security patch. The Change Management Process will normally have a

specific Procedure for handling Emergency Changes.

Financial Management (Service Strategy) The Function and Processes responsible for managing

an IT Service Provider's Budgeting, Accounting and Charging

49

49

Requirements.

Governance Ensuring that Policies and Strategy are actually implemented, and that

required Processes are correctly followed. Governance includes defining

Roles and responsibilities, measuring and reporting, and taking actions

to resolve any issues identified.

Help Desk (Service Operation) A point of contact for Users to log Incidents. A Help

Desk is usually more technically focussed than a Service Desk and does

not provide a Single Point of Contact for all interaction. The term Help

Desk is often used as a synonym for Service Desk.

Incident (Service Operation) An unplanned interruption to an IT Service or a

reduction in the Quality of an IT Service. Failure of a Configuration Item

that has not yet impacted Service is also an Incident. For example

Failure of one disk from a mirror set.

Incident Management (Service Operation) The Process responsible for managing the Lifecycle

of all Incidents. The primary Objective of Incident Management is to

return the IT Service to Users as quickly as possible.

International Organization for

Standardization (ISO)

The International Organization for Standardization (ISO) is the world's

largest developer of Standards. ISO is a non-governmental organization

which is a network of the national standards institutes of 156 countries.

Further information about ISO is available from http://www.iso.org/

ISO/IEC 20000 ISO Specification and Code of Practice for IT Service Management.

ISO/IEC 20000 is aligned with ITIL Best Practice.

IT Service A Service provided to one or more Customers by an IT Service Provider.

An IT Service is based on the use of Information Technology and

supports the Customer's Business Processes. An IT Service is made up

from a combination of people, Processes and technology and should be

defined in a Service Level Agreement.

IT Service Management

(ITSM)

The implementation and management of Quality IT Services that meet

the needs of the Business. IT Service Management is performed by IT

Service Providers through an appropriate mix of people, Process and

Information Technology.

ITIL A set of Best Practice guidance for IT Service Management. ITIL is

owned by the OGC and consists of a series of publications giving

guidance on the provision of Quality IT Services, and on the Processes

and facilities needed to support them.

Lifecycle The various stages in the life of an IT Service, Configuration Item,

Incident, Problem, Change etc. The Lifecycle defines the Categories for

50

50

Status and the Status transitions that are permitted. For example:

• The Lifecycle of an Application includes Requirements, Design, Build,

Deploy, Operate, Optimise.

• The Expanded Incident Lifecycle includes Detect, Respond, Diagnose,

Repair, Recover, Restore.

• The lifecycle of a Server may include: Ordered, Received, In Test,

Live, Disposed etc.

Office of Government

Commerce (OGC)

OGC owns the ITIL brand (copyright and trademark). OGC is a UK

Government department that supports the delivery of the government's

procurement agenda through its work in collaborative procurement and

in raising levels of procurement skills and capability with departments. It

also provides support for complex public sector projects.

Operational Level Agreement

(OLA)

(Service Design) (Continual Service Improvement) An Agreement

between an IT Service Provider and another part of the same

Organisation. An OLA supports the IT Service Provider's delivery of IT

Services to Customers. The OLA defines the goods or Services to be

provided and the responsibilities of both parties. For example there could

be an OLA

• between the IT Service Provider and a procurement department to

obtain hardware in agreed times

• between the Service Desk and a Support Group to provide Incident

Resolution in agreed times.

Problem Management (Service Operation) The Process responsible for managing the Lifecycle

of all Problems. The primary Objectives of Problem Management are to

prevent Incidents from happening, and to minimise the Impact of

Incidents that cannot be prevented.

Procedure A Document containing steps that specify how to achieve an Activity.

Procedures are defined as part of Processes.

Process A structured set of Activities designed to accomplish a specific

Objective. A Process takes one or more defined inputs and turns them

into defined outputs. A Process may include any of the Roles,

responsibilities, tools and management Controls required to reliably

deliver the outputs. A Process may define Policies, Standards,

Guidelines, Activities, and Work Instructions if they are needed.

51

51

Process Manager A Role responsible for Operational management of a Process. The

Process Manager's responsibilities include Planning and co-ordination of

all Activities required to carry out, monitor and report on the Process.

There may be several Process Managers for one Process, for example

regional Change Managers or IT Service Continuity Managers for each

data centre. The Process Manager Role is often assigned to the person

who carries out the Process Owner Role, but the two Roles may be

separate in larger Organisations.

Process Owner A Role responsible for ensuring that a Process is Fit for Purpose. The

Process Owner’s responsibilities include sponsorship, Design, Change

Management and continual improvement of the Process and its Metrics.

This Role is often assigned to the same person who carries out the

Process Manager Role, but the two Roles may be separate in larger

Organisations.

Request for Change (RFC) (Service Transition) A formal proposal for a Change to be made. An

RFC includes details of the proposed Change, and may be recorded on

paper or electronically. The term RFC is often misused to mean a

Change Record, or the Change itself.

Request Fulfilment (Service Operation) The Process responsible for managing the Lifecycle

of all Service Requests.

Service A means of delivering value to Customers by facilitating Outcomes

Customers want to achieve without the ownership of specific Costs and

Risks.

Service Asset and

Configuration Management

(SAChange Management)

(Service Transition) The Process responsible for both Configuration

Management and Asset Management.

Service Capacity

Management (SChange

Management)

(Service Design) (Continual Service Improvement) The Activity

responsible for understanding the Performance and Capacity of IT

Services. The Resources used by each IT Service and the pattern of

usage over time are collected, recorded, and analysed for use in the

Capacity Plan.

Service Catalogue (Service Design) A database or structured Document with information

about all Live IT Services, including those available for Deployment.

The Service Catalogue is the only part of the Service Portfolio published

to Customers, and is used to support the sale and delivery of IT Services.

The Service Catalogue includes information about deliverables, prices,

contact points, ordering and request Processes.

Service Design (Service Design) A stage in the Lifecycle of an IT Service. Service

Design includes a number of Processes and Functions and is the title of

52

52

one of the Core ITIL publications.

Service Design Package (Service Design) Document(s) defining all aspects of an IT Service and

its Requirements through each stage of its Lifecycle. A Service Design

Package is produced for each new IT Service, major Change, or IT

Service Retirement.

Service Desk (Service Operation) The Single Point of Contact between the Service

Provider and the Users. A typical Service Desk manages Incidents and

Service Requests, and also handles communication with the Users.

Service Knowledge

Management System (SKMS)

(Service Transition) A set of tools and databases that are used to manage

knowledge and information. The SKMS includes the Configuration

Management System, as well as other tools and databases. The SKMS

stores, manages, updates, and presents all information that an IT Service

Provider needs to manage the full Lifecycle of IT Services.

Service Level Measured and reported achievement against one or more Service Level

Targets. The term Service Level is sometimes used informally to mean

Service Level Target.

Service Level Agreement

(SLA)

(Service Design) (Continual Service Improvement) An Agreement

between an IT Service Provider and a Customer. The SLA describes the

IT Service, documents Service Level Targets, and specifies the

responsibilities of the IT Service Provider and the Customer. A single

SLA may cover multiple IT Services or multiple Customers.

Service Level Management

(SLM)

(Service Design) (Continual Service Improvement) The Process

responsible for negotiating Service Level Agreements, and ensuring that

these are met. SLM is responsible for ensuring that all IT Service

Management Processes, Operational Level Agreements, and

Underpinning Contracts, are appropriate for the agreed Service Level

Targets. SLM monitors and reports on Service Levels, and holds regular

Customer reviews.

Service Management Service Management is a set of specialized organizational capabilities

for providing value to customers in the form of services.

Service Management

Lifecycle

An approach to IT Service Management that emphasizes the importance

of coordination and Control across the various Functions, Processes, and

Systems necessary to manage the full Lifecycle of IT Services. The

Service Management Lifecycle approach considers the Strategy, Design,

Transition, Operation and Continuous Improvement of IT Services.

Service Manager A manager who is responsible for managing the end-to-end Lifecycle of

one or more IT Services. The term Service Manager is also used to mean

any manager within the IT Service Provider. Most commonly used to

53

53

refer to a Business Relationship Manager, a Process Manager, an

Account Manager or a senior manager with responsibility for IT

Services overall.

Service Operation (Service Operation) A stage in the Lifecycle of an IT Service. Service

Operation includes a number of Processes and Functions and is the title

of one of the Core ITIL publications.

Service Owner (Continual Service Improvement) A Role which is accountable for the

delivery of a specific IT Service.

Service Portfolio (Service Strategy) The complete set of Services that are managed by a

Service Provider. The Service Portfolio is used to manage the entire

Lifecycle of all Services, and includes three Categories: Service Pipeline

(proposed or in Development); Service Catalogue (Live or available for

Deployment); and Retired Services.

Service Portfolio

Management (SPM)

(Service Strategy) The Process responsible for managing the Service

Portfolio. Service Portfolio Management considers Services in terms of

the Business value that they provide.

Service Request (Service Operation) A request from a User for information, or advice, or

for a Standard Change or for Access to an IT Service. For example to

reset a password, or to provide standard IT Services for a new User.

Service Requests are usually handled by a Service Desk, and do not

require an RFC to be submitted.

Service Sourcing (Service Strategy) The Strategy and approach for deciding whether to

provide a Service internally or to Outsource it to an External Service

Provider. Service Sourcing also means the execution of this Strategy.

Service Sourcing includes:

• Internal Sourcing - Internal or Shared Services using Type I or Type II

Service Providers.

• Traditional Sourcing - Full Service Outsourcing using a Type III

Service Provider.

• Multivendor Sourcing - Prime, Consortium or Selective Outsourcing

using Type III Service Providers.

Service Strategy (Service Strategy) The title of one of the Core ITIL publications. Service

Strategy establishes an overall Strategy for IT Services and for IT

Service Management.

54

54

Service Transition (Service Transition) A stage in the Lifecycle of an IT Service. Service

Transition includes a number of Processes and Functions and is the title

of one of the Core ITIL publications.

Service Validation and

Testing

(Service Transition) The Process responsible for Validation and Testing

of a new or Changed IT Service. Service Validation and Testing ensures

that the IT Service matches its Design Specification and will meet the

needs of the Business.

Type II Service Provider (Service Strategy) An Internal Service Provider that provides shared IT

Services to more than one Business Unit.

Underpinning Contract (UC) (Service Design) A Contract between an IT Service Provider and a Third

Party. The Third Party provides goods or Services that support delivery

of an IT Service to a Customer. The Underpinning Contract defines

targets and responsibilities that are required to meet agreed Service

Level Targets in an SLA.

55

55

Bilag 8 ”RFC Flow”

Figur 1 "Example process flow for a normal change” s.49

56

56

Bilag 9 ”Proceslog” Den 22. September

Påbegyndt den 22. september på opfordring af vejleder, som supplement (Bilag) til procesbeskrivelsen. Den

skal tjene to formål:

1) At vise vejleder og censor, hvilke processuelle overvejelser jeg har være igennem i opgaveforløbet.

2) At hjælpe mig til at reflektere over det processuelle i opgaven, i takt med at den skrider frem.

Ind til i dag har jeg arbejdet med følgende:

1) Påbegyndt et ”Working Document” der indeholder alt lige fra gode idéer; over nyttige links; til små

bidder af teoretisk diskussion vedrørende opgaven. Jeg vil senere pille i dette dokument og bruge dét

der er brugbart for opgaven. Dokumentet fungerer under hele opgaveforløbet, som en slags

opslagstavle.

2) Uformelt møde med Birger Rosager den 7. juli. Tema: Hvem er Energinet og hvilke It-projekter har

de gang i for tiden? Er der basis for en opgave? Hyggeligt og informativt møde. Ingen aftaler. Jeg

melder tilbage efter snak med vejleder.

3) Refleksion over møde m. Birger og oplæg til møde med Povl Erik.

4) Vejledermøde med Povl Erik den 17. August (Skype). Tema: Opgavens emne og afgrænsning. Min

fremgangsmåde i forbindelse med fastlæggelse af tema for opgaven hos Energinet. Lidt snak om

teori.

5) Finde teori og litteratur om ITSM/IT-Governance. Læse teori. Forberedelse til møde m. Birger.

6) Uformelt møde hos Energinet den 2. september. Genopfriskning af situationen hos Energinet (efter

sommerferien). Snak om undersøgelser hos Energinet. Birger orienterede om et kommende Kickoff-

møde, som jeg gerne skulle med til. ITIL-seminar afholdes hos Energinet, men desværre på samme

dag som Claus Bossens ”Masteropgave-Seminar” i Århus.

7) Masteropgave-Seminar” i Århus. Godt seminar, dog uden de store overraskelser.. hvilket jo er fint.

8) Vejledermøde med Povl Erik den 14. September i Århus (Face-2-Face). Klar afstemning af hvad der

vil være en god vinkel på opgaven. Referat og efterfølgende mailkorrespondance følger:

Referat af møde med Povl Erik Rostgaard Andersen d.14/9 2011

Inden mødet havde jeg sendt en mail til Povl Erik, som ikke kom til at fungere som dagsorden, da vi med det

samme gik i dialog om opgavens emne. I denne forbindelse kom vi rundt om adskillige emner. Disse er listet

i dette referat.

Vejledning

Povl Erik har rammerne for øje, men tæller ikke timer. Han læser ikke hele opgaver igennem. Vi blev enige

om at vi snakker løseligt sammen, efter behov. Når jeg når længere hen, så skal vi snakke mere

struktur/opbygning på opgaven.

Omfang af opgaven er 60 sider.

57

57

Opgaven kan siges at være banebrydende, hvis jeg formår at analysere mig frem til noget Energinet kan brug

i deres virksomhed.

Empiri

Det giver opgaven et akademisk løft, at jeg bruger teori og erfaring fra fagpakken ”Arbejdspraksis” til at

indsamle min empiri med. Dette har jeg styr på, så det snakkede vil ikke meget om. Dog blev det slået fast at

observation/interview i afdelingerne ”støtte”, ”kærne” og ”teknik” var repræsentativt. Uddybende interviews

kan dog sagtens blive nødvendige også.

Opgavens fokus:

Povl Erik lagde vægt på at opgavens tyngde bør ligge i arbejdet med ITSM/ITIL, da det er dét Energinet har

bedt om (hvilket måske også vil kunne føre til en jobsituation efter endt projektarbejde).

Modenhedsgrad hos Energinet skal være temaet i opgaven. Det skal dreje sig om modenhed i deres

arbejdsprocesser; om modenhed i deres stadie af ITSM; og deres modenhed af den praktiserede It-

Governance. Altså, skal man ”kravle før man kan gå”, eller vil det være fornuftigt at fokusere på It-

Governance i samme ombæring, som man arbejder med ITSM?

Energinets holdning er ”buttom-up”, hvor de vil have ’fundamentet’ på plads før man kan koncentrere sig

om de mere højtflyvende ting. Spørgsmålet er dog, om en ”Top-Down” tilgang ikke ville være fornuftig for

at Energinet ved hvad de arbejder frem mod. Det ville jo være et problem, hvis de senere finder ud af at

tingene ikke hænger sammen og at de har fokuseret på de forkerte ting. Et tredje alternativ kunne være en

”Coming-in-from-the-side” tilgangen, hvor man orienterer sig om It-Governance for at få et kendskab og

være klar over hvilke arbejdsopgaver der ligger forude. Man behøver således ikke forpligte sig til at tage et

It-Governance framework i brug.

Jeg skal finde ud af hvordan man måler modenhed. Dette skal gøres, hvilket vil være noget af opgavens

Empiri. Der vil også være modenhedsindikatorer at hente i de arbejdsprocesundersøgelser jeg laver i

Energinets It-afdeling med henblik på ITSM undersøgelsen.

Teoretiske frameworks:

Jeg vælger frameworket ITILv3, da Energinet bruger det i deres ”setup”. Jeg kan/skal også vælge andre

teorier, som f.eks. Cobit, men disse skal være relevante for opgavens pointe. Det vigtige er at jeg forholder

mig til teorien. Dette skal forstås sådan, at jeg skal vurdere hvor teorien kunne bruges og hvor det ikke var

hensigtsmæssigt at bruge den. Det er en kritisk stillingstagen til teorien, som skal underbygges med mine

informationer (observationer/interviews/spørgeskemaer) fra Energinet skal underbygge.

Mht. flere forskellige frameworks, så gælder det om at diskutere udvalget af frameworks, vælge ét og

argumentere for valget. At andre frameworks nævnes viser overblik, men samtidig viser mit valg evnen til at

vurdere Energinets behov. Der skal ikke bruges for megen tid/energi på dette. Et helikopterperspektiv er fint.

Mht. Energinet og deres ”Effektiviseringsprojekt”, så skal jeg:

- Finde ud af hvordan arbejdet med ”Change Management” faktisk foregår. Obs/int. i de 3 afdelinger.

- Finde ud af hvad de vil med det. Hvorfor er det vigtigt for Energinet?

- Hvilke udfordringer er det der har motiveret til dette tiltag.

- Hvad er strategien og målene i forbindelse med indførelsen af ITSM. (Roden i opgaven)

58

58

o Dette skal også undersøges på operativt plan. (Stemmer deres holdninger overens med

ledelsens?)

Pointe:

- At kunne underbygge mine løsningsforslag med en accept (reviews/feedback) fra Energinet. Noget

vil de være enige i og andet vil de ikke. Dette skal der reflekteres over.

- Samtidig finde ud af hvordan de arbejder med It-Governance.

- At kunne vurdere og forholde mig til om det de gør også er det rigtige for Energinet. Igen skal dette

kobles til deres modenhedsniveau. (Best practice/teori skal være lakmustesten).

Implementering af ITSM løsning:

Mht. hvorvidt jeg skal koncentrere mig om at forankre indførelsen af ITSM hos Energinet, så blev Povl Erik

og jeg enige om at det er et helt emne for sig selv og at jeg skal undgå et få det med i opgaven.

Forslag til opgavens problematiserende spørgsmål:

Hvordan ser det ud med Enerinets modenhed af It-funktionen; og vil det i forbindelse med deres “It-

effektiviseringsprojekt” være formålstjeneligt at indarbejde It-Governancemekanismer? Altså, skal man

”kravle før man kan gå”, eller vil det være fornuftigt at fokusere på It-Governance i samme ombæring, som

man arbejder med ITSM?

Note:

Alt omhandlende It-Governance skal kunne ses i relation til ITSM og Change Management ”siloen”. Jeg skal

ikke bevæge mig ud og snakke om f.eks. It-Projektporteføljestyring. Det handler om at holde ’scopet’.

Tvivlsspørgsmål:

- Skal jeg holde ”Alignment” problematikken uden fra min undersøgelse af Energinets modenhed,

selvom en dårlig alignment er et af modenshedstegnene? Vil scopet blive for bredt?

- Vil det gavne/være nødvendigt for opgaven at starte opgaven med at forklare hvem Energinet er ud

fra en ”Enterprice architecture” vinkel? Eller vil det være en dødssejler, da opgaven har et andet

fokus?

Tilbagemelding:

Kære Thomas

Tak for referatet.

Jeg har svært ved helt at greje dit referat.

Du skal lave service management for Energinet. Du skal vurdere hvad de gør og komme med forslag til

forbedringer. Det er det primære. Det kan godt ske, at du vil bruge et modenhedsbegreb til at sige hvor de er,

og hvor de skal hen. Og de skal se service management som en del af IT-governance. Men dit fokus er og

skal være service management. Og det kan godt være at du kan hente støtte/hjælp i alignmentlitteraturen.

Det andet spørgsmål – beskrivelse af Eneriginet ud fra EA - har jeg svært ved at svare på på nuværende

tidspunkt. Prøv. Det kan være at du finde ud af at det ikke er den rigtige vinkel.

59

59

Vh

Povl Erikl

Kære Povl Erik,

Jeg tror godt jeg ved hvor du får svært ved at greje referatet. Jeg har nemlig lagt megen vægt på det med

modenhed, men det skal forstås som en dimension, der skal forklare om Energinets valg er rettidige. Jeg er

med på at ITSM er det jeg skal undersøge og hovedproduktet skal være mit løsningsforslag til Energinet,

hvor ITILv3 som framework er givet på forhånd.

Dér hvor jeg er lidt uenig med dig, er hvor du siger at ITSM er en del af It-Governance. Jeg (i hvert fald

indtil videre) ser IT-Governance, som et 'evolutionstrin' højere end ITSM, hvor "Management" bliver til

"Govermance", således at det man gør, hænger sammen med forretningsstrategien. Det er også her

modenhedsbegrebet kommer på banen.

Jeg er sikker på at vi 80-90% af vejen er på samme spor og at denne opgave nok skal blive spændende. Jeg

vil nu gå i gang med at planlægge mit undersøgelsesdesign.

Mvh,

Thomas

Kære Thomas

Jeg er helt enig i din uddybning. Governance skal bringes ind for at placere service management i en

styringsmæssig ramme.

God søndag og god arbejdslyst.

Vh

Povl Erik

9) Arbejde med planlægning af undersøgelsesdesign. Denne opgave minder meget om de krav der har

været i tidligere eksamensopgaver, så her kan jeg drage nytte af mine erfaringer. Der er dog en del

ting jeg ændrer og en hel del jeg vælger at uddybe, nu hvor masteropgaven kræver nuanceret

argumentation i diskussioner og veldokumenterede analyser.

10) Start på selve opgavedokumentet, hvor ”dit og dat” fra mit ”working document” bliver sat ind de

respektive afsnit i henhold til dispositionen. Jeg vælger, som udgangspunkt, at bruge ”den klassiske

disposition”, da jeg ikke har nogen gode grunde til at gøre det anderledes.

Den 27. september

60

60

Energinets D-IMM rapport, som er udarbejdet af Devoteam har vist sig brugbar på to måder. 1) Den kan

bruges, som empirisk grundlag, der forklarer hvorfor Energinet har startet ”It-effektiviseringsprojektet”. 2)

Den danner grundlag for at jeg tager fat på Change Management processen.

Den 4. oktober

Efter et møde med Energinet har jeg nu fået mødt de andre i ’teamet’ og jeg har lavet de to første aftaler om

observationer (Hos hhv. ”teknik & Infrastruktur” og ”Kærneprocesser”). Michael fra ”Støtteprocesser” vil

jeg lave en aftale med i ugen efter efterårsferien (hvis ikke i ~).

På mødet snakkede vi om:

- Claus Kofoed (CWO) har initieret ”Effektiviserings projektet”. ”Standardisering + automatisering =

Effektivisering”. Dette ’mantra’ skulle bunde i It-Strategien. Grunden til at dette er blevet til et

ITSM projekt er at de i dag skeler lidt til ITILv3.

- John (incident management proces ejeren) bliver forsinket pga., anden opgave -> ingen inspiration

herfra.

- Intro fra Birger. John (Incident proces ansvarlig) har fået en opgave mere ved siden af ITSM og

incident proces undersøgelsen.

- Jeg præsenterer mig og fortæller om mine planer for observation, interview.

- Der blev diskuteret om hvorvidt det er interessant overhovedet at se på hvordan det foregår i dag hos

Energinet. Nogle folk mente at det ikke er nyttigt (nærmere farligt), men at man hellere skulle lave

en ny plan ud fra et tool/framework og sørge for at alle følger den.

I brugen af Etnometodologien går jeg meget tæt på arbejdsgangen som den er, men pointen er ikke at

kopiere deres arbejdsmetoder og genbruge dem i lyset af ITIL. Pointen er at se på arbejdspraksis og

finde ud af hvad der faktisk foregår eller sagt på en anden måde: Hvordan de bærer sig ad med at få

arbejdet til at give mening. Specielt ”Accountability” vil være et begreb, som jeg vil holde øje med

(se teoriafsnit om Etnometodologi). Begrebet dækker bredt, så selvom det skærper fokus, så vil jeg

være vågen for alle nye input.

På et mere praktisk plan kan man sige at: Hvis der skal indføres ITSM og Energinet skal indføre nye

processer og arbejdsfunktioner, hvad skal så nedlægges/skæres væk? Der må være nogle

arbejdsgange og nogle systemer som bliver ‘redundante’ og skal afskaffes. Denne pointe er én af

årsagerne til at undersøge hvordan Change Management foregår i dag.

Hvis jeg bare ville have data om hvordan Energinet skal gøre, så kan jeg bare læse ITIL

frameworket. Hvis jeg vil have viden om hvordan Energinet skal gøre, så må jeg have kontekst med

ind i ligningen. Se ” Transition_and_Knowledge.swf, Modul5, ITIL v3 - The Art of Service Online

Learning Video” hvor der metakommunikeres over dette emne ifm. ”Knowledge Management”

Processen. Altså er her endnu en årsag til at undersøge den kontekstuelle ”As Is” situation.

Pointer fra mødet:

1) dét jeg skal finde frem til er Energinets behov for Change Management. Det er vigtigt at alle

interessenter bliver ’hørt’, således at tidligere dækkede behov ikke bliver skåret væk uden

overvejelse.

2) Løsningen skal være fælles for de tre afdelinger.. ja, for hele Energinet.

61

61

3) Change Management processen bliver defineret, så alle ved hvor starter processen

(hvad/hvem kan initiere den) og hvor slutter den.

4) Min observation: Der hersker begrebsforvirring, som kan føre til forkert brug af processer.

Derfor er det vigtigt at forklare hvad der er hvad (F.eks. forskel på: request, change,

incident). Case eksempler kunne være en god måde at forklare det på.

5) Felterne i en RFC skal være utvetydige.

6) I dag hersker et ”systemview”, som skal laves om til et ”Serviceview”. Altså, når en RFC

laves, så skal den laves mod en service og ikke et system. I Servicen skal det fremgå

hvordan RFC skal løses.

7)

-

Eksempel: Når ”Kærneprocesser” skal bruge en ny server, så bliver det overvejet hvordan de hurtigst får fat

i den. Skal de lave en RFC eller gå til helpdesk? De bestemmer selv. Svar fra ”Teknik og infrastruktur” er at

brugerne ved ikke hvordan de skal bære sig ad, så man kan aldrig forudse hvad de kan finde på. Derfor er det

vigtigt at gøre det fuldstændig entydigt for enhver hvordan man gør.

Snakken falder hen på at løsningen er at gøre alle ydelser til services.

Overblik ”Teknik og Infrastruktur”:

Aktører (ejerskab):

Forretningsejeren: Ejer af forretningsdelen. Bruger systemet. F.eks. ”kontrolrum”.

It-systemejeren: (F.eks. kærne- og supportproces) Ejer af It-system-delen. Leverer It-ydelser. (Skala, DPS,

SAP, m.m.) Vurderer ’severity’ og planlægger inplementering m.m.

3. parts leverandør af It-ydelse (…)

Den 19. oktober

Jeg har nu været på besøg hos ”Kærneprocesser” og ”Støtteprocesser”, hvor jeg har fået god indsigt i

arbejdspraksis i forbindelse med ”Change Management”. Dog er jeg stødt ind i en procesmæssig udfordring

omhandlende observation. Det blev overvejende til interviews, da Change Management hos Energinet har

vist sig at være et svært fænomen at observere. Årsagen skulle findes i at Change Management arbejdet

forløber over længere perioder, hvilket gør det umuligt at observere f.eks. en fejl fra vugge til grav.

Observationerne blev således til uformelle konversationsinterview med Change Management som det

overordnede emne og med det formål at give mig indsigt i hvordan Change Management udspiller sig i de

enkelte grupperinger. Denne ændring af mit undersøgelsesdesign har konsekvenser, for den grad af

faktualitet der med sikkerhed er over de indsamlede data. Problemet er at interviews bærer den risiko at de

har tendens til at afbillede en ønsket situation og at de kan gemme på usandheder og skjult agenda. Hvorvidt

dette er tilfældet i dette tilfælde er mig ikke bekendt, men jeg vil forholde mig til mine data med dette i

mente. Jeg vil dog arbejde med min empiri ud fra den antagelse at informationerne er reelle og bruge

undersøgelserne som udgangspunkt for ændringsforslag til Change Management og ITSM i det hele taget.

62

62

Min snak med Birger før jeg gik (efter besøg hos ”støtteprocesser”):

Jeg er under mine undersøgelser blevet klar over at ”DataHub projektet” har Incident Management som en

del af projektscopet. Dette betyder at projektet bliver initiator for selve Service Management konceptet.

Spørgsmålet er så om ’omstændighederne’ er til at indføre ITSM hos Energinet eller om man har fokuseret

for snævert på incident som process. DataHub projektete har en tidsplan, som kan resultere i en forcering af

implementeringen af ITSM, hvilket giver udfordringer mht. forankring strategisk- og organisatorisk set.

Change Management konceptet skal bruges af alle, men f.eks. SAP og SCADA (m.m.) skal have lov til at

håndtere deres incidents internt.

Det blev aftalt at Birger og jeg afholder et midtvejsmøde, som skal give mig projektstatus og her skal jeg

også finde ud af hvordan Birger/John vil køre ITSM projektet. Hvilke ITILv3 dele vil de gøre brug af og

hvordan vil de gøre det. Midtvejsmødet skal afholdes inden jeg holder møde med It-ledelsen, hvor jeg vil

diskutere It-strategien og organisatoriske forhold i forbindelse med ”It-effektiviserings projektet”.

Den 27. oktober

Arbejdet med data fra undersøgelserne tager lang tid. Jeg har optaget alle samtaler på diktafonen og har

skrevet alt ned, som der blev snakket om. Der er ikke tale om direkte transskribering, men mere om

meningskondensering. Denne proces er svær og der må ikke gå for lang tid mellem undersøgelsen og

meningskondenseringen. Når dette arbejde er færdiggjort, så skal informationen koges yderligere ned og

analyseres ud fra den valgte teori (Etnometodologien). Dette arbejde har jeg nu påbegyndt og til min store

glæde begynder der at vise sig mønstre eller presserende emner, som vil være dét jeg vil behandle, når jeg

skal bruge teorien til at komme med forbedringsforslag til Energinets Change Management proces. Ud over

forbedringer, så vil de ting jeg har fundet også være noget af det, som skal sikre flowet i arbejdspraksis. Der

er en årsag til at de adspurgte har valgt at give udtryk for netop disse ting.

Jeg er ved at stykke en mail sammen til Birger, hvor jeg beder ham arrangere et møde med Energinets It-

ledelse. Det er gået op for mig (og Birger), at projektets succes ikke alene afhænger af om man får etableret

en fornuftig Change Management proces, men i lige så høj grad om man har ledelsens opbakning og mod på

at udføre de fornødne organisationsændringer (roller/ansvar m.m.).

Den 1. november

Jeg har nu afsendt mailen til Birger, hvor jeg beder om møder med 1) Birger 2) It-ledelsen og 3) Med

brugerrepræsentanter. Grunden til at jeg beder om tre møder er at der er behov for det. Birger har ikke oplyst

mig om alt projektindholdet (og projektplanen er ikke just detaljeret), så her har jeg behov for at få større

indblik i hvad hele projektet kommer til at favne. Der ud over, så er der også ting jeg skal have afklaret inden

mødet med It-ledelsen. Mødet med Bruger repræsentanterne (Relation Management og måske

kontrolrummet) vil jeg afholde, da jeg er nysgerrig for om der her gemmer sig andre synsvinkler ifm. Change

63

63

Management. De har sikkert en mening om hvordan de ønsker at indrapportere fejl og i det hele taget få

support.

Under analysearbejdet blev jeg klar over, at der er en hårfin grænse mellem de tilfælde af arbejdspraksis,

hvor jeg vurderede at en situation enten var et ”Accountabilityproblem”, eller de tilfælde hvor jeg vurderede

anderledes. Der opstod således en kategori af arbejdspraksissituationer, som tilhører en kategori jeg

navngiver ”Effektivitetsproblemer”. Det er altså problemer jeg har identificeret i forbindelse med brugen af

etnometodologien, men som, ved et nærmere eftersyn, ikke skader accountability under de nuværende

forhold. Ser man nærmere på ”Effektivitetsproblemerne”, så vil de dog ikke harmonere med en fremtidig

Service Management arbejdspraksis og er derfor taget med (Fodnote: Dette vender jeg tilbage til i afsnit???).

Under analysearbejdet opdagede jeg at jeg var blevet meget fokuseret på problemer, for at notere mig de ting

i arbejdspraksis, som stod i vejen for deres håndtering af ændringer. Jeg kunne ikke gøre dette samtidig med

at jeg også noterede mig alle de ting, som faktisk fungerede og som også var vigtige for flowet i

arbejdspraksis. Jeg måtte som konsekvens gå alle observationerne igennem en ekstra gang for at få denne

dimension med også.

Den 4. november

Jeg har under samtalerne med Energinets medarbejdere indgået i dialog og har derfor ikke kunnet undgå at

ytre nogle af mine synspunkter på diverse problematikker. Som opgaven skred frem blev jeg klar over at der

af Energinets medarbejdere blev erkendt et større behov for organisatorisk forankring end der oprindeligt var

lagt op til i projektet. Jeg tilskynder min påvirkning af konteksten en del af denne udvikling. Jeg har gjort ret

klart at min opgave også vil omhandle de organisatoriske forhold, som kan påvirke successen af ”It-

effektiviseringsprojektet”. Der er andre i organisationen, som deler dette synspunkt, men jeg kan ikke vide

om de har advokeret for større fokus på dette. Alt andet lige så er resultatet, at Birger (projektleder) har

indkaldt styregruppen til at møde hvor organisatorisk forankring i form af roller og ansvar bliver sat på

dagsordnen, sammen med den gængse agenda. Udviklingen er i min optik positiv og jeg har som del af min

indifferens i opgavens udvikling taget den beslutning at jeg afholder et ”midtvejsmøde” med Birger for at få

styr på hvilket arbejde han mener at der skal udføres i It-effektiviseringsprojektet. Jeg vil bruge udfaldet til to

ting: (i) At forberede mig til mit eget møde med It-ledelsen og (ii) til at holde op mod teorien og se om jeg

kan komme med forbedringsforslag til deres Service Management arbejdspraksis.

Den 11. november

Jeg er ved at komme til et klimaks i opgaveprocessen, hvor jeg skal til at gå dybere i ITSM teorien. Det

bliver MEGET spændende at finde ud af om mine ’fund’ (Metabeskrivelsen) fra undersøgelsen, kan bruges i

det analyserende arbejde med ITSM. Jeg har ingen anelse om hvorvidt tingene ”passer sammen”, eller om

jeg må ud i diskussioner om, hvorfor mine undersøgelser ikke kunne bruges til at sige noget om, hvordan

Energinet skal gebærde sig i forbindelse med ibrugtagning af Change Management. Jeg vil fortsætte i troen

på at jeg gør det rigtige.

Møder med Birger og It-ledelsen er nu på plads. Her vil jeg have mulighed for at spørge nærmere ind til

selve It-effektiviseringsprojektet, ITSM, ITIL, Strategi, It-strategi og andre forhold der bliver relevante for

64

64

opgaven. Indtil mødet skal jeg læse endnu mere op på teori om ITSM og hvad der nu ellers udspringer

herfra.

Jeg har besluttet mig for at afgrænse scopet for opgaven endnu mere end min egen interesse i opgaven ellers

tillader. Jeg kommer ikke til at gå i dybden med modenhedsanalyse eller It-Governance. Dette hænger

sammen med at det er delvist uden for scope og det vil gøre opgaven alt for omfattende. I forbindelse med

ITIL frameworket er der forskellige stadier, som forklarer noget om modenheden. Der behøves ikke en

analyse for at pinpointe Energinet, hvilket gør en større analyse overflødig.

Det var også min tanke at inddrage It-Governance (som værende en drivende kraft i Energinets virksomhed)

i opgaven. Det vil dog ikke være rettidigt at snakke It-Governance før Energinet har styr på bl.a. Change

Management (ITSM). I ITSM er der også et aspekt af It-Governance, som jeg vil komme til at behandle i

forbindelse med forholdet ”Roller og ansvar” fra Metabeskrivelsen.

Den 18. november

Kære dagbog. Det er nu en uge siden at jeg sidst skrev Jeg er nu nået til en fase hvor jeg forbereder mig til

møderne med projektlederen Birger og It-ledelsen, samtidig med at jeg læser på ITSM teorien. Det er

glædeligt at se, at de forhold jeg har identificeret i Metabeskrivelsen også peger mod ibrugtagning af Service

Management. Dog er der et ret stort problem i den måde It-effektiviseringsprojektet er stykket sammen.

Ifølge teorien, så kan man f.eks. ikke køre det som et alm. It-projekt, da det er et arbejdspraksiskoncept man

er ved at tage i brug. Der er en del andre forhold, som jeg p.t. formoder at Energinet er tilbageholdende over

for at gå i krig med, da det vil gøre projektet større end de måske ønsker det skal blive. Jeg kender endnu

ikke 100% deres motivation for at køre projektet, men for mig er ’effektivisering’ ikke fyldestgørende nok.

Jeg vil på møderne spørge ind til disse ting og med ITSM ’viden’ i bagagen vil jeg finde ud af om de har styr

på tingene eller om de har søsat endnu en dødssejler (Se bilag 4).

Den 22. november

I arbejdet med ITSM teorien har jeg fået styrket min holdning til, at man skal være mere holistisk i sin

tankegang, når man tager ITSM i brug. Jeg kunne sagtens finde flere steder hvor ITSM litteraturen nævner

dette, men jeg manglede noget der kunne understøtte pointen i netop Energinets kontekst. Skal jeg udvide

opgavens scope? …Frustration. Dette uddybes ikke mere, nu.

Den 3. december

Jeg har nu fået styr på de tanker, som jeg slet ikke nåede at berette færdigt om oven over, da jeg i min

refleksion kom nærmere en løsning på mine frustrationer.

Jeg har fået afholdt møder med både Birger og It-ledelsen, som har givet mig svar på en række

tvivlsspørgsmål.

Jeg har fået nogle erkendelser på plads, som gør, at jeg ved hvordan jeg skal beskrive Change Management i

ITSM konteksten, således at Energinet bliver klar over at de skal fokusere lige så meget på

65

65

administration/Management af deres Service Management processer og services, som de fokuserer på

services og teknik.

Dette er ikke nogen lille ting, for det er netop dét der vil skabe holisme i deres brug af Service Management.

Der er her de har mangler i deres tilgang til hele paradigmet. Det er dét som vil bringe de tre sider af ITSM

trekanten i balance og imødekomme deres accountabilityproblemer. At være serviceorienteret indebærer ikke

kun dét at pakke It-ydelser ind i et serviceobjekt i MS servicemanager. Det handler om (i) at tilgå konceptet

på den rigtige serviceorienterede måde (CSI) og (ii) at etablere en ITSM struktur der kan håndtere de Service

Management processer man vil gøre brug af.

Jeg er derfor gået videre med at skrive om Change Managements placering i ITSM konceptet og hvordan

Energinet skal gøre brug af Change Management. Dette er opgavens anbefaling til Energinet.

Jeg har aftalt et møde med Povl Erik, som bliver afholdt 14 før opgave aflevering. På mødet skulle vi

diskutere om det er ok, at ændre problemstillingen 2/3 henne i opgaven. Det var måske en lidt dårlig måde at

stille det op på fra min side, men jeg troede (for 2-4 dage siden) at det ville være nødvendigt, da jeg var af

den overbevisning at Energinet ikke ville gøre brug af de serviceorienterede principper der ligger i Service

Management konceptet (altså lave Management af Service Management processer). Jeg har siden hen (på It-

ledermødet) fundet ud af (og mærket på egen krop) at vil de gerne, men at lige netop dette princip er svært at

begribe. Jeg bebrejder ikke Energinet at de ikke har fokus på dette, men jeg sætter nu fokus på det, da jeg

mener at det har betydning for Change Management processens succes (altså, hvis de i sidste ende skal gøre

noget ved deres accountability). Derfor er opgavens udgangspunkt stadig det samme.. altså at videreudvikle

Change Management processen ud fra ITIL principper.

Jeg er til mødet blevet bedt om at lave en kommenteret disposition, hvilket jeg vil gøre. Så kan vi snakke om

jeg har en god fordeling af emnerne i opgaven og om der evt. mangler noget.

Den 15. december

Jeg har super travlt med opgaven. Der er meget der skal formuleres på den rigtige måde, således at jeg får de

vigtige pointer frem. Emnet er komplekst og omfattende, hvilket stiller store krav til min formuleringsevne.

Jeg har haft et Skypemøde med vejleder Povl Erik, hvilket har bekræftet mig i, at jeg var på rette kurs, men

der var nogle enkelte ting der skulle ekspliciteres.

Denne log har hjulpet mig til at reflektere over min opgave på en anden måde end jeg normalt gør. Det

skyldes at jeg ikke kun reflekterer over indholdet af opgaven, men mere metareflekterer over

opgaveprocessen. Jeg får på den måde styr på (eller bliver klar over) de udfordringer jeg står over for. Dette

vil være sidste indslag, da jeg står over for en travl periode med vurdering, konklusion og perspektivering,

som mest af alt handler om benarbejde og ikke mental refleksion, som jeg har brugt denne log til.

66

66

Bilag 10 ”Parlør”

Der er mange FTB’ere6 og begreber hos Energinet, hvorom læseren af denne opgave kan blive draget i tvivl.

I dette bilag finder du en kort forklaring af de ord, som jeg har fundet flertydige eller ikke almindeligt

kendte. Denne ’parlør’ kan med fordel tages ud og bruges løbende under læsning af opgaven.

Alstom: Fransk trediepartsleverandør af SCADA og NOIS systemerne.

Applikationsansvarlig: Også omtalt som ”Applikationsejer”, ”It-systemejer” eller bare ”systemejer”.

En sådan kan være en gruppe i It-afdelingen, men en person i It-afdelingen kan

også blive benævnt ”Applikationsejer”.

Applikationsejer: Se ”Applikationsansvarlig”.

Assignment-grupperne: I Helpdesk (Selfservice) systemet er der vha. en checkboks mulighed for at

angive om en ”Interaction” drejer sig om en ”forretningsapplikation”

(Støtteprocess domænet) og man har mulighed for at angive hvilken

applikation der er tale om. Dette resulterer i at en ”Interaction” vil blive sendt

til en såkaldt ”assignment-gruppe”.

BizTalk: Kommunikationssystem mellem interessenter i NOIS.

Change: Se RFC.

Costcenter: En organisatorisk enhed der koster mange penge at drive, men som ikke direkte

genererer indtjening. En sådan enhed er ofte mål for besparelser. Hos Energinet

er begrebet brugt som noget negativt, til at illustrere at en enhed bruger ’for

mange penge’.

Deploy: At lægge en ændring til et system på en server og gøre den aktiv i

produktionen, hvilket vil sige det kørende system. Ordet kan bruges som

fordansket udsagnsord: ”At deploye”, ”Jeg deployer”, ”Jeg har deployet”.

Deploymentkalenderen: Alle ændringer hos SCADA bliver skrevet i denne kalender, for at skabe

overblik.

DPS Systemteam: Ækvivalent til NSG. Systemteamet er repræsenteret af Kontrolcenteret,

Markedet (kunder) og af afregning (’Billing’). Her prioriteres opgaverne i DPS,

således at der er en rimelig fordeling (forhandling) af ressourcerne der sørger

for at tilgodese hele markedet (TSO’erne).

DPS: Drift Planlægning System (DPS) der styrer planlægning af Elforsyning i

Danmark.

6 Forkortelser på Tre Bogstaver.

67

67

Failover: Et skift fra en redundant standby server kaldet ”PreProdP til en kørende (live)

server kaldet ”Produktion” eller vise versa.

Gruppering: En Gruppering er en samling It-medarbejdere der har et fælles formål.

Eksempler kunne være NOIS, T&I, SharePoint m.m. Jeg har i opgaven også

omtalt disse grupperinger, som værende praksisfællesskaber.

Helpdesk: T&I varetager Helpdesk, som tager sig af brugernes henvendelser ang. It. Peter

Madsen og 4 medarbejdere varetager denne funktion.

Incident: I ”HP Servicedesk” systemet, som bruges i Helpdesk bliver der oprettet

Incidents. Disse kan oprettes af både Helpdeskpersonalet og af nogle folk i It-

afdelingen. Der oprettes ofte RFC’ere på baggrund af Incidents.

Incidentliste: I Helpdesk er der en liste over alle Incidents der er oprettet. Denne liste bruges

flittigt af It-afdelingen til at holde styr på ændringer. I SCADA gruppen har

man sin egen Incidentliste.

Interaction: Når en bruger henvender sig i Helpdesk, så laves der en Interaction. Denne kan

blive til en Incident, hvis Helpdesk ikke kan afhjælpe henvendelsen med det

samme.

ITIL: ITSM ’Best Practice’ framework.

ITSM: IT Service Management.

It-systemejer: Se ”Applikationsejer”.

Kærneprocesser: Udgør én af tre grupperinger i It-afdelingen. De arbejder sammen med

forretningen i styringen af systemerne (NOIS, DPS og SCADA).

Kærneproces-vagten: Kærneproces gruppen har en telefonvagt 24 timer i døgnet, som tager sig af

henvendelser på systemerne SCADA, DPS og NOIS.

MS InfoPath: It-System udviklet af Microsoft. Beregnet til styring af information i brugen af

XML formularer.

NOIS: Nordisk system, der styrer planlægning af Elforsyning.

NSG: ”NOIS Steering Group” diskuterer ændringer og fungerer dels som ’modpart’

til Alstom, så de ikke bare kan gøre hvad de vil (teknisk og til dels økonomisk).

NSG sikrer at man ikke går i gang med noget som ikke kan lade sig gøre i alle

TSO’er og rent teknisk set i Energinet regi.

Opgavelisten (SCADA): Tjener det formål, at visualisere hvad SCADA gruppen går og laver. Den

dækker alle opgaver der laves; eksempelvis projekter og forskellige ændringer.

Opgavelisten (SharePoint): Helpdesks Incidentsystem bliver af SharePoint folkene brugt som opgaveliste.

PreProd: ”PreProd” betyder ”Pre Produktion” og er et testsystem, hvorpå en ændring

skal testes inden det kan gå i ”Produktion”.

68

68

Produktion: ”Produktion” er en betegnelse for et kørende system. Det er herpå ændringer

”Deployes” vha. en ”failover”, når man ’ved’ de virker uden fejl.

Relation Management: En gruppe i It-afdelingen, som er It-afdelingens folk i forretningen (og vise

versa). Formålet er at skabe alignment mellem It og forretning.

Request For Change: Se RFC.

Request: En forespørgsel på ’noget nyt’, der kræver at T&I udfører et stykke arbejde.

RFC: En forespørgsel på ændring af ’noget eksisterende’, der kræver at T&I udfører

et stykke arbejde. Forespørgslen udføres vha. en InfoPath blanket (Request For

Change), som udfyldes med relevant information. (En RFC kaldes også for en

”ændring” eller en ”Change”).

RFClisten: Listen over RFC’ere i afdelingen T&I.

Sag: En ”Sag” er en instans i en trediepartleverandørs system. Disse oprettes, når der

ønskes ændringer til Energinets kørende system.

SCADA: En gruppe i It-afdelingen, som står for Materialestyring overvågning- og

konfiguration af forsyningskabelstationer. Styring af transformatorstationer.

Tredjepartsleverandøren Alstom sørger for udvikling, test og deployments af

ændringer i SCADA systemet.

Selfservice: En webportal i Helpdesksystemet, hvor igennem man kan oprette sager i

Helpdesk, i stedet for at maile eller ringe.

Støtteprocesser: Udgør én af tre grupperinger i It-afdelingen. De arbejder sammen med

forretningen i styringen af diverse administrative systemer (herunder

SharePoint og SAP).

System Group: Se Systemteam.

Systembruger: En ’ikke-It-medarbejder’ Energinets virksomhed.

Systemejer: Se It-systemejer.

Systemteam: Et Systemteam er et forum, hvor interessenter i forbindelse med et system

samles og diskuterer ændringer. Der eksisterer systemgrupper for systemerne

NOIS, SCADA og i Støtteprocesser.

T&I: Udgør én af tre grupperinger i It-afdelingen. De står for al It-infrastruktur fra

netværket og op til diverse operativsystemer. Gruppen har også diverse

applikationsansvar i forretningen.

Teknik & Infrastruktur: Se T&I.

Tildeler: Begreb i Støtteprocesser om en person, som tildeler Incidents fra Helpdesk

systemet til relevante It-medarbejdere.

69

69

Traen: Trediepartsleverandør for Acadre (ESDH).

Transport: SAP systemets pendant til de andre systemers ”Deploy”.

TSO: Står for Transmission System Operator. En fællesbetegnelse for firmaer der

styrer den overordnede El (og Gas) infrastruktur. 130kV netværk og opefter,

samt har ’balance ansvar’, dvs. at der produceres lige så meget el som der

forbruges. TSO’erne kaldes med en fællesbetegnelse for ‘Markedet’. I norden

er der 4 TSO’er (NO, FI, SV og DK).

XML: Programmeringssprog kaldet ”Extended Markup Language”.

70

70

Bilag 11 ”Change Management” Denne korte beskrivelse af Change Management skal fungere, som en overordnet definition af ITILv3

Change Management.

Change Management, er en ITIL kerneproces, der kan betragtes som en kontrolproces, i det den samler et

overblik over ændringer i den daglige arbejdspraksis. Processen styrer evaluering og godkendelse af

ændringer. Change Management processen bidrager til flere andre kerneprocesser i ITILv3 frameworket,

som f.eks. ”Release og Deployment” og ”Asset og Configuration Management” i det den stiller krav til

deploys og bidrager med information til Change Management systemet.

Formålet med Change Management processen er7:

- At sikre ensartede metoder og procedurer i håndteringen af ændringer, således at ændringsarbejde

kan koordineres horisontalt i virksomheden.

- At minimere risici i forbindelse med ændringsarbejdet, som f.eks. nedetid på kritiske systemer, som

følge af uautoriserede ændringer.

Ændringer er som oftest ændringer til It-infrastrukturen, hvilket udføres via en service. En ændring kan

således også være en ændring til en service. Når en ændring til It-infrastrukturen skal foretages, så vil man

gøre brug af en service, som er defineret til formålet.

7 Change Management er her defineret ud fra ITILv3 frameworkets kontekst, da dette er opgavens omdrejningspunkt

(se afsnit Error! Reference source not found.).