masterafhandling bilag thomas michelsen
TRANSCRIPT
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)
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.
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.).