Operational Excellence i IT-processer

Transkript

1 COPENHAGEN BUSINESS SCHOOL HD SUPPLY CHAIN MANAGEMENT Operational Excellence i IT-processer Implementering af Lean IT-processer i en servicevirksomhed i den finansielle sektor Vejleder: Kim Sundtoft Hald Forfatter: Caspar Miller, født 3. april 1983 Afleveringsdato: 15. maj 2013

2 Indholdsfortegnelse Indholdsfortegnelse... 2 Figuroversigt... 3 Tabeloversigt... 4 Executive Summary Problemformulering Problemfelt Undersøgelsesspørgsmål Afgrænsning Litteraturreview Simpel litteratursøgning Søgning på emneord Lean Systemtænkning og Lean i servicesammenhæng Lean IT Metode Forskningsparadigme Forskningstilgang Forskningsstrategi Dataindsamling Interviews Population Teori Værdi Spild Systemtænkning og Lean i servicesammenhæng Lean IT Analysemodel Analyse Formål Hvor går det galt? Drivere for målopfyldelse Indholdsfortegnelse Side 2 af 185

3 5.4 Indikatorer for forandring Redesign arbejdet Konklusion Perspektivering Anbefalinger Kildehenvisninger Referencer Litteraturliste Bilag Projektdagbog Projektplan Interviewguide Transskription af interviews Case Begrebsforklaring Resultater af litteratursøgning Artikel om strategi fra PenSams intranet Limoncellis typer af systemadministratorer Seddons årsager til suboptimering Bell & Orzens Lean Enterprise Principles Pyramid Likers 14 ledelsesprincipper Demings 14 ledelsesprincipper Cunningham & Jones 13 vejledende principper Lean IT Spildkategorier Figuroversigt Figur 2.1: Lean-huset efter Liker, Figur 3.1: Tragtmodel for dokumentets struktur Figur 4.1: The Efficiency Paradox. Kilde: Modig & Åhlström, Figur 4.2: Demings (1982) PDCA-cyklus Figur 4.3: Lean Enterprise Principles Pyramid. Kilde: Bell & Orzen, Figur 4.4: Vanguard-metodens Check-Plan-Do-cyklus. Kilde: Seddon, Figuroversigt Side 3 af 185

4 Figur 4.6: Tre niveauer af fejl. Kilde: Egen tilvirkning efter Piercy & Rich, 2009a Figur 4.5: Vanguards model for systemtænkning. Kilde: Efter Seddon: 2005; Nielsen, Figur 4.7: Model for håndtering af brugerhenvendelser. Kilde: Egen tilvirkning efter Limoncelli, Figur 4.8: Model for redesign af formål fra kundens synsvinkel. Kilde: Egen tilvirkning efter Seddon, Figur 10.1: PenSams nuværende IT-organisation Figur 10.2: Skematisk oversigt over sammenhængen mellem de anvendte ITIL-processer Tabeloversigt Tabel 3.1: Oversigt over dataindsamling Tabel 4.1: Synspunkter i systemtænkning vs. traditionel tænkning. Kilde: Efter Seddon, 2005; Nielsen, Tabel 10.1: Kort beskrivelse af hovedelementerne i ITIL-rammeværktøjet Tabel 10.2: Forklaring af de anvendte ITIL-begreber Tabel 10.3 Resultater af litteratursøgning Tabel 10.4: Typer af systemadministratorer. Kilde: Limoncelli, Tabel 10.5: Årsager til suboptimering. Kilde: Seddon, 2008a Tabel 10.6: Elementerne i Lean Enterprise Principles Pyramid. Kilde: Bell & Orzen, Tabel 10.7: Oversigt over de otte spildkategorier. Kilde: Frit efter Bell & Orzen, 2011, Cunningham & Jones, 2007; Liker, 2004; Ohno, Tabeloversigt Side 4 af 185

5 Executive Summary On the basis of a number of interviews conducted with several individuals in and around the IT function a number of areas for potential improvement have been identified. These findings are based in part on the author s own understanding of the organisation, partly based on a case study on the company, and finally input from the interviews. The basis for improvement of the current situation is present given the fact that the organisation has already implemented the ITIL processes in question. The biggest problem in this regard appears to be a lack of implementation of the processes, owing mainly to the functional nature of the IT organisation and the company in general, which is based on the achievement of functional, hierarchical targets. This functional goal orientation compromises the customer value aspect inasmuch as the achievement of the goals itself becomes a means to an end rather than focusing on delivering value to customers. Consequently, the mere implementation of the ITIL processes does not suffice per se. The processes must be rigorously applied in every possible context, constituting the basis for all thought and action. Everyone in the organisation must work towards a common goal, instituting an end-to-end flow state of mind in every activity of every process. The application of a Lean methodology, in an IT context as well as any other, is not so much a question of the clever use of tools as it is a change in the way things are done around here. The current situation resembles the notion of process villages, in which processes are implemented in every functional area in isolation, but at the expense of the integration of the whole. This lack of perspective renders impossible the focus on the creation of value based on customer demand. The application of a systems perspective in accordance with the Vanguard method to a wider extent enables the organisation to fulfil its purpose. Notions central to the Lean philosophy such as customer value, waste elimination and the application of flow becomes the locus of attention, and targets are constructed to focus operations on fulfilling customer requirements. It has been established that the level of customer inquiries with regard to incidents and requests is generally high, leading to difficulties for staff in coping with demand. To a wide extent, however, it is possible to rein in this demand by focusing on removing failure demand such as progress chasing by introducing certain changes. An increased focus on alignment of expectations and supplying customers with the required levels of information is required. Furthermore, customers must be enabled to seek and find this information independently by means of providing process descriptions and Service Level Agreements. Executive Summary Side 5 af 185

6 1 Problemformulering Danmark er blevet stærk på service (Nielsen, 2011), og Lean-tankegangen har vundet indpas også i servicesektoren (Jensen, 2012b). Samtidig er outsourcing udbredt (Arlbjørn et al., 2009; Fawcett & Magnan, 2002; Prahalad & Hamel, 1990). Lean-principperne finder i dag anvendelse på mange områder, og tankegangen har også vundet indpas inden for IT under begrebet Lean IT (Bell & Orzen, 2011; Williams & Duray, 2013). En disciplin, der ligeledes er udsprunget af Lean-tankegangens anvendelse i anden sammenhæng end produktion, er rammeværktøjet ITIL, som anvendes til styring af IT-tjenesteydelser (Williams & Duray, 2013, se Begrebsforklaring for en kort introduktion til begrebet). PenSam, der leverer finansielle tjenesteydelser inden for pension, bank, realkredit og forsikring, har for nylig gennemført en omfattende omstrukturering. To vigtige begreber i denne sammenhæng er for det første en centralisering af alle IT-funktioner under ét område, og for det andet indførelsen af begrebet Operational Excellence i virksomhedens strategi (se Artikel om strategi fra PenSams intranet i Bilag 10.8). Virksomheden har i mange år døjet med manglende fokus på IT, der af den øverste ledelse har været set som et nødvendigt onde. IT-organisationens understøttelse af forretningens kerneprocesser har således lidt under manglende funktionalitet og et fokus på brandslukning, symptombehandling af problemer, når de opstår, frem for helbredelse, hvor årsagen til problemet fjernes, så det ikke opstår igen. Mange oplever stor frustration ved denne situation, fordi den store mængde red tape 1 gør det besværligt at udføre det daglige arbejde (se Bilag 10.4; 10.5). 1.1 Problemfelt Komplekse integrationer, manglende funktionalitet og en stor portefølje af IT-systemer er årsag til mange henvendelser til IT-afdelingen fra brugere i hele virksomheden om oplevede fejl i IT-systemerne (se Bilag 10.5). Disse henvendelser registreres som sager i et centralt sagshåndteringssystem. Henvendelserne håndteres af tre processer, som er defineret i den for IT Service Management udbredte standard Information Technology Infrastructure Library. De tre processer, der er tale om i denne sammenhæng, er hændelses-, problem- og forespørgselshåndtering (se Bilag 10.6). Ophobning af sager medfører lange sagsbehandlingstider og dertilhørende utilfredshed med IT-afdelingens håndtering af fejl og forespørgsler vedrørende IT-systemerne. 1 Begrebet red tape henviser til en situation, hvor overdrevet bureaukrati og kontrol er hæmmende for udførelsen af det daglige arbejde (Greiner, 1972). Problemformulering Side 6 af 185

7 Flere faktorer bidrager til det høje antal indrapporterede fejl. Et pludseligt opstående udfald kan resultere i, at adskillige brugere oplever fejl i et eller flere systemer; manglende koordinering hos det modtagende organ (Service Desk) resulterer i hyppige (fler-)dobbelte registreringer af den samme fejl; manglende funktionalitet i systemerne og manglende kendskab hertil hos brugerne opleves og indrapporteres som fejl; der skelnes generelt ikke mellem egentlige fejl i systemerne i form af pludseligt opståede hændelser og fejl som følge af ukorrekt eller utilstrækkelig specificering, osv. Antallet af åbne sager, der er lang tid under behandling og/eller ligger længe i venteposition, inden løsning påbegyndes, har længe ligget på et utilfredsstillende niveau. Brugerne oplever meget lange svartider på de sager, de indmelder, og at sagerne ikke bliver løst. Denne situation fører til utilfredshed med IT-afdelingen, navnlig Service Desk, og lav tillid til, at IT-afdelingen prioriterer fornuftigt mellem sine opgaver i forhold til at understøtte den øvrige forretning. Grundet de mange henvendelser fungerer IT-afdelingen reaktivt og bruger alt for meget tid på brandslukning. Afdelingen har følgelig for få ressourcer til at udvikle holdbare løsninger, der kan spare ressourcer på lang sigt. Det er nødvendigt at nedbringe antallet af ventende og/eller uløste sager, og i særdeleshed at reducere gennemløbstiden for igangværende sager væsentligt. Situationen har den øverste ledelses opmærksomhed, og det er således både nærværende og relevant at adressere og udbedre problemstillingen hurtigst muligt. 1.2 Undersøgelsesspørgsmål Ovenstående problembeskrivelse leder til følgende undersøgelsesspørgsmål: Hvordan kan en Lean-tilgang hjælpe PenSams IT-afdeling med at frigive tid, der i dag går med brandslukning, til at fokusere på tilbundsgående problemløsning? o Hvordan kan håndteringen af de tre IT Service Management-processer Service Request Management, Incident Management og Problem Management i PenSams IT-afdeling forstås i et Lean-perspektiv? o I hvilken udstrækning kan anlæggelsen af Lean-perspektivet føre til en bedre håndtering af de tre processer? o o Hvilke Lean-elementer kan med fordel anvendes i håndteringen af processerne? Hvordan kan de valgte tiltag implementeres? 1.3 Afgrænsning Omend det kunne være både relevant og interessant at anskue det fulde omfang af daglige arbejde i ITafdelingen i relation til organisering efter Lean- og ITIL-principper, fokuseres i nærværende projekt på hånd- Problemformulering Side 7 af 185

8 tering af henvendelser til Service Desk, herunder behandling, kvalificering, videreformidling og ikke mindst kommunikation med sagsstiller. Omfanget begrænses således til arbejdet med IT i driftssammenhæng, nærmere betegnet de tre processer Service Request Management, Incident Management og Problem Management. Således er begreber som Lean Six Sigma og leagile udvikling inden for IT ikke omfattet. Organisatorisk begrænser arbejdet sig til de to afdelinger i Resultatcenter IT, Service Operation og Service Design & Transition, der beskæftiger sig med IT-drift. I samme sammenhæng kunne fokus udvides fra IT-området til hele virksomheden, da det i høj grad er relevante at inddrage brugere fra hele virksomheden som leverandører af input til processerne. Dog vil omfanget af dette udvidede fokus blive for stort i forhold til det problem, der anskues i denne sammenhæng, som handler om håndteringen af henvendelser i det daglige arbejde, det vil sige inden for IT-organisationen, men uden for projekt- og udviklingsregi. Problemformulering Side 8 af 185

9 2 Litteraturreview I det følgende gennemgås først arbejdet med at fremsøge ny litteratur i form af artikler, der kan være relevante for belysning af det undersøgte emne. Efterfølgende gennemgås grundlaget for den litteratur, der anvendes i teori- og analysekapitlerne, inddelt i de vigtigste, overordnede teoriområder. Som litteratur anvendes både fremsøgt litteratur, litteratur fra pensum i undervisningen på HD-SCM samt øvrig relevant litteratur inden for de områder, der berøres i metode-, teori- og analysekapitlerne. CBS-bibliotekets hjemmeside har en søgemulighed på forsiden, der giver adgang til at søge på tværs af alle artikeldatabaser og desuden blandt bøger og andre udgivelser på én gang. Relevante artikler fra litteratursøgningen i bibliotekets databaser arkiveres i værktøjet RefWorks 2 til senere brug. Først søges på relevante begreber inden for det valgte emne. For yderligere at afgrænse søgning på artikler om emnerne kombineres søgeordene efterfølgende med andre relevante begreber. Litteraturreviewet begrænses til det omfang, at fremsøgt litteratur i større udstrækning begynder at referere til kilder, der allerede er omfattet (Saunders, Lewis & Thornhill, 2009). 2.1 Simpel litteratursøgning Eftersom problemstillingen omhandler anvendelsen af Lean i sammenhæng med IT-tjenesteydelser, og Lean samtidig er bredt behandlet i litteraturen (se eksempelvis Womack, Jones & Roos, 1990; Womack & Jones, 2003; Liker, 2004; Seddon, 2005; Bicheno & Holweg, 2008; Suárez-Barraza, Smith & Dahlgaard-Park, 2012; Jensen, 2012a; b; oma.), er det nærliggende at starte litteratursøgningen med Lean som søgeord. En umiddelbar søgning på relevante søgeord giver et meget stort antal resultater (se oversigt over søgeresultater i Tabel 10.3). Et indledende forsøg på at reducere denne store mængde artikler til et mere overskueligt omfang omfatter afgrænsning til engelsksprogede peer-reviewed artikler i den seneste alderskategori (udgivet efter 1997), men omfanget af resultater er stadig uoverskueligt (se Tabel 10.3). 2.2 Søgning på emneord For at indsnævre omfanget af emner yderligere, søges nu i databasen Business Source Complete, der er bibliotekets mest anvendte artikeldatabase 3. Søgning afgrænses til artikler i peer-reviewed tidsskrifter. Der 2 RefWorks er et værktøj til at lagre og referere til artikler online. Se mere på Litteraturreview Side 9 af 185

10 søges på emneord frem for blot fritekstsøgning i alle dele af artiklerne. Dette for at frafiltrere artikler i søgningen, som blot nævner et eller flere af søgeordene, men reelt drejer sig om et andet emne. Resultaterne af søgningen på emneordene er illustreret i Tabel Idet langt størstedelen af litteraturen antages at være skrevet på engelsk, søges på engelske udtryk for teorierne, selvom det i øvrigt er de danske betegnelser, der anvendes i teksten. Ud fra begreberne i problemformuleringen søges i første omgang på en række relevante emneord, se Tabel 10.3). Antallet af artikler i resultatet af søgning på emneord er relativt lavt (se Tabel 10.3). For at underbygge relevansen af de fremsøgte artikler og fremsøge yderligere relevant litteratur, søges ligeledes på en række relaterede emneord, der ikke fremgår direkte i problemformuleringen. En del af artiklerne går igen i de forskellige søgninger. De mest relevante er taget med under de respektive områder. Resultaterne af de enkelte søgninger er opstillet i en samlet oversigt i Tabel Lean Jensen (2012b) inddeler Lean-litteraturen i tre perspektiver ud fra relationen mellem begreberne værdi og spild. I det første perspektiv er spild defineret som alt, der ikke er værdi. I det andet perspektiv er værdi defineret som alt, der ikke er spild. Det tredje perspektiv anskuer ikke værdi og spild som hinandens modsætninger (Jensen, 2012b). Hvis værdi er defineret som aktiviteter, kunden er villig til at betale for, så må alle andre aktiviteter være spild. Dette (første) perspektiv danner grundlag for Womack & Jones (2003) definition af begrebet Lean. Jensen (2012a) har senere defineret begrebet Refleksiv Lean, som bygger på Womack & Jones Leanperspektiv (Womack & Jones, 2003). Lean lider under nuancefattigdom, uklare begrebsdefinitioner og interne modsætninger, men formår alligevel at tjene som kilde til øget organisatorisk effektivitet (Jensen, 2012a). I årene efter Anden Verdenskrig udviklede Toyota Motor Corporation i Japan produktionsfilosofien Toyota Production System, der opnåede udbredt kendskab med bogen The Machine That Changed the World (Womack, Jones & Roos, 1990). Taiichi Ohno, Lean-guru, mangeårig direktør i Toyota og forfatter til (blandt andre) bogen Toyota Production System: Beyond Large-Scale Production, definerer formålet som at reducere tidsrummet mellem modtagelse af kundens ordre og modtagelse af betaling for ordren fra kunden ved at eliminere ikkeværdiskabende aktiviteter (Ohno, 1988): Litteraturreview Side 10 af 185

11 All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes. Ohno, 1988, ix En af Ohnos grundtanker i Toyota Production System var den kontinuerlige forbedringscyklus, der er kendt som Deming-hjulet eller PDCA-hjulet. Deming, grundlæggeren af PDCA-tankegangen, beskriver i bogen Out of the Crisis 14 ledelsesprincipper for forbedring af kvalitet og produktivitet og reducering af omkostninger (Deming, 1982). Deming argumenterer for, at the 14 points apply anywhere, to small organizations as well as to large ones, to the service industry as well as to manufacturing. (Deming, 1982, p. 23). Argumentet er således, at tankegangen kan anvendes i servicevirksomheder såvel som i produktionssammenhænge. PDCA-tankegangen er siden blevet udbygget til at omfatte et rapporteringselement, som er blevet kendt som A3 (Schjoldan, 2012; Sobek & Smalley, 2008). Sobek & Smalley (2008) argumenterer for, at A3 ikke blot er et rapporteringsværktøj, men en tankegang og en struktureret arbejdsmetode. Toyota Production System illustreres af Liker (2004) som et hus (Figur 2.1). Søjlerne (udgjort af just-in-time og jidoka som beskrevet ovenfor) står på et fundament af heijunka (udjævnet produktion) og stabile processer og standarder (Liker, 2004; Liker & Morgan, 2006). Husets tag udgøres af mål og vision om højeste kvalitet, laveste omkostninger og korteste lead-time. Toyota Production System baserer sig på de to kernebegreber just-in-time og jidoka (Ohno, 1988). Just-intime er produktion uden lagre, hvor alle dele til fremstillingen af et produkt leveres netop i rette tid, til de skal bruges, og således ikke venter unødigt (ibid.). Produkter trækkes gennem produktionsapparatet, idet en forudgående produktionsproces først starter, når behovet opstår i en senere proces. Besked om behovet gives ved hjælp af et bestillingskort kendt som kanban (ibid.). Litteraturreview Side 11 af 185

12 Figur 2.1: Lean-huset efter Liker, Jidoka er adskillelse af mand og maskine, og tankegangen er baseret på menneskelig respekt. Tanken er, at en maskine selv skal stoppe, hvis der sker en fejl, så menneskelige ressourcer kan anvendes til vigtigere formål end at overvåge produktionsudstyr (Ohno, 1988). Denne automatiske sikring mod fejl er kendt under begrebet baka-yoke eller poka-yoke (Shingo, 1986; Ohno, 1988). Heijunka er udjævning af produktionen, så der ikke produceres for store mængder for tidligt i forhold til behovet. Opstår en fejl, skal den rettes øjeblikkeligt, idet forebyggelse er bedre end behandling (ibid.). Hvis en fejl opdages i en produktionslinje, gives besked ved hjælp af andon, et signal, og alle hjælper med at udbedre fejlen, inden produktionen kan fortsætte (ibid.). I Toyota Production System er defineret syv spildkategorier (Ohno, 1988; Liker, 2004). Alle disse spildtyper findes i alle virksomheder, ikke kun i produktionsvirksomheder (Bell & Orzen, 2011). Formålet med at identificere spild er at fjerne det, så kun værdi står tilbage. Dette stemmer overens med Jensens (2012b) andet perspektiv om identificering af værdi ved eliminering af spild. Til dette formål er værdistrømsanalyser (Value-Stream Mapping) et værktøj, der finder udbredt anvendelse (Liker, 2004; Rother & Shook, 2003). Den form for spild, det er vigtigst at eliminere, er overproduktion, som fører til unødig lagring (Ohno, 1988; Shingo, 1989). For at undgå spild i form af unødigt lager argumenterer Rother & Shook (2003) for, at alle produkter skal fremstilles i små mængder ad gangen med hyppigere skift mellem produktionskørslerne efter princippet Every Part Every Day (Rother & Shook, 2003). Den ideelle produktionsstørrelse af en given enhed er 1, idet hvert produkt fremstilles en ad gangen, hvorefter der omstilles til fremstilling af den næste variant (Liker, Litteraturreview Side 12 af 185

13 2004; Rother & Shook, 2003; Womack, Jones & Roos, 1990). For at gøre så hyppige skift praktisk muligt, er det nødvendigt at kunne foretage skift mellem fremstilling af forskellige enheder hurtigst muligt. Til dette formål har Shingo (1985) udviklet metoden Single-Minute Exchange of Die (SMED). McIntosh et al. (2000) har foretaget en kritisk evaluering af SMED-metoden, om end der er behov for mere forskning på området (McIntosh et al., 2000). For at angive hvornår der er behov for nye enheder ved en bestemt aktivitet i produktionsprocessen, anvendes kanban med ordre om et antal nye enheder fra den forudgående aktivitet. Jensen (2012b) argumenterer i sit tredje perspektiv for, at der er et indbygget modsætningsforhold mellem kanban-systemet, der forudsætter små mængder af lager mellem aktiviteterne i produktionsprocessen, og eliminering af spild i form af nedbringelse af overproduktion (Jensen, 2012b). John Bicheno argumenterer i en række bøger om Lean-redskaber for, at værktøjskassen er midlet til at opnå målet om forbedringstiltag (Bicheno, 2008; 2012; Bicheno & Catherwood, 2005; Bicheno & Holweg, 2009). I artiklen Decoding the DNA of the Toyota Production System publiceret i Harvard Business Review beskriver Spear & Bowen (1999), hvordan hemmeligheden bag Toyotas succes ligger i den filosofi, der ligger til grund for Lean-tankegangen, snarere end de konkrete redskaber, som blot anses for at være temporary responses to specific problems that will serve until a better approach is found or conditions change (Spear & Bowen, 1999, p. 104). For at opretholde fleksibilitet og tilpasning til skiftende omstændigheder, skal alle aktiviteter, forbindelser og flow-veje have indbygget automatisk signalering af problemer (Spear & Bowen, 1999). Plant-first-princippet (Ohno, 1988) går ud på, at ledelsen ikke kan dirigere arbejdets gang fra direktionsgangen, men bør være til stede på fabriksgulvet, hvor arbejdet faktisk bliver udført. Dette synspunkt underbygges af (blandt andre) Seddon (2005; 2012): When he got back to the office the following Monday, he got there early, and he locked all the managers doors [..] The point he was making is We ll never do this if we go to our offices. We re going to do this by going to where the calls come in Seddon, 2012, 09:32 Modig & Åhlström (2012) argumenterer for, at det er vigtigt at fokusere på flow-effektivitet frem for ressourceeffektivitet. De definerer begrebet flow-enhed, som er en enhed af den vare eller information, der flyder gennem processen. Processen skal altid indrettes under hensyntagen til flow-enheden. Sammenfatning Litteraturreview Side 13 af 185

14 Jensens (2012b) tre perspektiver om værdi, spild og modsatrettede prioriteringer er alle velbegrundet i litteraturen, omend synspunktet om værdiskabelse gennem eliminering af spild i forfatterens øjne synes bredere repræsenteret. Meget af litteraturen i dette perspektiv baserer sig på Toyota Production System (Ohno, 1988; Liker, 2004). Tilsvarende synes meget af litteraturen i værdi-perspektivet at basere sig på Womack & Jones (1990; 2003). Det tredje perspektiv er ikke så veludforsket i litteraturen, men Jensen (2012b) argumenterer for nogle interne modsætningsforhold i kanban-systemet, og Spear & Bowen (1999) illustrerer ligeledes, hvordan Toyota i nogle tilfælde opbygger lagre på trods af, at overproduktion er spild. 2.4 Systemtænkning og Lean i servicesammenhæng I bogen Freedom from Command & Control beskriver John Seddon, som blandt er kendt som lederen af konsulenthuset Vanguard, hvordan virksomheder kan frigøre sig fra styring og kontrol ved hjælp af systemtænkning (Seddon, 2005). Metoden tager udgangspunkt i kundens behov og fokuserer på formålet med at udføre en bestemt aktivitet frem for målsætninger, hvis opfyldelse bliver målet i sig selv. Metoden, der også er kendt som Vanguards metode, er beskrevet som anvendelsen af Lean og Toyota Production System i servicevirksomheder (ibid.). Dog kan det ifølge Liker & Morgan (2006) være sværere at anvende Lean i servicevirksomheder end i produktionsvirksomheder. Specifikt for Lean i servicevirksomheder inddeler Suárez-Barraza, Smith & Dahlgaard-Park (2012) litteraturen i fire kategorier; eksplorativ litteratur, fremstilling af teoretiske rammeværker, specifikke anvendelsesmuligheder og nye tendenser. Flere af de forfattere, der er omfattet af litteraturstudiet, argumenterer for, at Lean kan overføres fra produktionsvirksomheder til servicevirksomheder (Levitt, 1972; 1976; Bowen & Youngdahl (1998), eller sågar at mange af Lean-principperne stammer fra servicesektoren, og at anvendelsen af Lean i servicevirksomheder er et udtryk for en hjemvending (Swank, 2003). Sprigg & Jackson (2006) undersøger indflydelsen af arbejdets organisering på medarbejderne og konkluderer, at overvågning fører til øget stressniveau hos de ansatte. Piercy & Rich (2009a; b) demonstrerer, at Lean-tankegangen finder høj grad af anvendelighed i servicesektoren, specifikt i sammenhæng med kundeservice i callcentre, men argumenterer samtidig for, at litteraturen på området er begrænset udbredt, og mere forskning er nødvendig. En nærmere gennemgang af Leans specifikke anvendelse i servicevirksomheder ville være for omfattende, og stemmer ikke fuldstændig overens med emnet i nærværende litteraturreview. Derfor behandles emnet ikke dybere, men der fokuseres i stedet på anvendelsen af Lean på IT-området. Sammenfatning Der er bred enighed i litteraturen om, at Lean-tankegangen i udstrakt grad finder anvendelse i servicesammenhæng (se eksempelvis Bowen & Youngdahl, 1998; Piercy & Rich, 2009a; b). Mens forfattere som Litteraturreview Side 14 af 185

15 Bicheno (2005; 2008a; b; 2012) fokuserer på anvendelse af en Lean-værktøjskasse, argumenterer mange (eksempelvis Liker, 2004; Modig & Åhlström, 2012; Spear & Bowen, 1999) for, at nøglen til succes med Lean ligger i tankegangen snarere end i anvendelsen af konkrete redskaber. Netop af denne grund, og fordi Leantankegangen oprinder fra servicesektoren (Ohno, 1988; Swank, 2003), er Lean fuldt ud lige så anvendeligt i servicevirksomheder som i produktionsvirksomheder, omend det kan være forbundet med større udfordringer (Liker & Morgan, 2006). 2.5 Lean IT Omend han ikke eksplicit anvender begrebet Lean, opstiller Limoncelli (1999) en nitrinsmodel for, hvordan systemadministratorer kan hjælpe brugere med IT-problemer. Modellen er inddelt i fire faser; modtagelse, problemidentificering, løsning og verificering. Cunningham & Jones (2007) definerer de syv spildkategorier overført på IT (Tabel 10.7). De fortsætter med at beskrive 13 vejledende principper for anvendelsen af Lean i IT-sammenhæng (Bilag 10.14). Det er et velkendt fænomen, at en aktivitet udført gentagne gange på samme måde ikke fører til forskellige resultater (Cunningham & Jones, 2007). Tilsvarende kan det ikke forventes at opnå ensartede resultater, hvis en aktivitet udføres forskelligt fra gang til gang. Standarder er derfor nødvendige for at udføre en aktivitet på samme måde fra gang til gang med opnåelsen af ensartede resultater, og således også være i stand til at opdage afvigelser, fejl og unormale procesbetingelser og, ideelt set, afhjælpe disse øjeblikkeligt (ibid.). Bell & Orzen (2011) beskriver de syv (plus en) spildformer i IT-sammenhæng, og opstiller modellen Lean Enterprise Principles Pyramid (Bell & Orzen, 2011). Markovitz (2012) beskriver, hvordan Lean-værktøjet 5S kan anvendes i informationssammenhæng. Nielsen (2011) beskriver anvendelsen af Vanguard-metoden til at organisere arbejdet i en IT-helpdesk. Williams & Duray (2013) viser, hvordan Lean hænger sammen med rammeværktøjet ITIL (se Begrebsforklaring). Sammenfatning Litteraturen om anvendelse af Lean i IT-sammenhæng er stadig begrænset i omfang (Piercy & Rich, 2009a; b), omend det har taget til de senere år (Bell & Orzen, 2011; Williams & Duray, 2013). Lige så vel som i servicesammenhæng (og andre sektorer, eksempelvis sundhedsvæsnet, Graban & Swartz, 2012), finder Lean også udbredt anvendelse på IT-området (Bell & Orzen, 2011; Cunningham & Jones, 2007; Williams & Duray, 2013). Både Womack & Jones (2003) fem Lean-principper og de syv spildformer kan overføres og anvendes på IT (Bell & Orzen, 2011; Cunningham & Jones, 2007; Piercy & Rich, 2009a; b; Williams & Duray, 2013): Forsin- Litteraturreview Side 15 af 185

16 kelser, ventetid og kødannelse ved forespørgsler eller information; kontrol af arbejde for fejl eller mangler; fejl i arbejde, der kræver genbehandling; dobbeltarbejde i form af dobbeltindtastning af samme data; unødig transport af data eller information, ineffektiv databehandling og ressourceeffektivitet er alle eksempler på spild, der jævnligt forekommer i IT-sammenhæng. Litteraturreview Side 16 af 185

17 3 Metode Undersøgelsesspørgsmålet i problemformuleringen er struktureret i stigende orden i Blooms taksonomi for indlæringsmål (Rienecker & Jørgensen, 2006). Således er hovedspørgsmålet rettet mod anvendelse af den opnåede viden, mens underspørgsmålene starter på de lavere trin (viden og forståelse) på Blooms trappe (Rienecker & Jørgensen, 2006) med forståelse af håndteringen af de tre processer i et Lean-perspektiv og relaterer sig gradvist til de højere trin på skalaen (ibid.). Årsagen til dette er hensigten om at producere ny viden (det øverste niveau, ibid.), jf. afsnit 3.2 nedenfor. Efter en kort introduktion gives en beskrivelse af genstandsfeltet (Borum, 1995) for undersøgelsen i form af en indføring i den fokale virksomhed og det niveau, der analyseres på. Desuden beskrives nogle af de for forståelsen af teksten og området centrale begreber, der ikke nødvendigvis er alment kendt af alle læsere i Bilag Strukturen i dokumentet kan illustreres med en tragtmodel (se Figur 3.1). Indledning og problemformulering indfører læseren i det undersøgte problemfelt. I litteraturreviewet gennemgås den eksisterende litteratur på området. På denne baggrund dannes analysens struktur i metodekapitlet. Teorikapitlet går i dybden med de dele af litteraturen, der anvendes i analysekapitlet. Endelig afrundes med en konklusion og perspektivering på resultaterne af analysen. I bilagene findes blandt andet projektdagbog og projektplan, transskription af interviews mv. Litteraturreview Metode Teori Analyse Figur 3.1: Tragtmodel for dokumentets struktur Litteraturreviewets formål er at danne overblik over den litteratur, der allerede eksisterer inden for det område, der introduceres i problemformuleringen. Litteraturreviewet danner udgangspunkt for teorikapitlet, der beskriver de teorier nærmere, som er udvalgt til brug i analysekapitlet. Hensigten med teorikapitlet er at definere et rammeværktøj og syntetisere nye modeller ud fra perspektivering af de forskellige teorier, som efterfølgende anvendes til at analysere problemstillingen om anvendelse af Lean-principper på de tre IT Service Management-processer, som den er defineret i problemformuleringen. Analysen af problemstillingen gribes an i form af et casestudieforløb (Bilag 10.5), hvor et antal interessenter bliver udpeget med henblik på dybere granskning af problemstillingen gennem interviews (se afsnit 3.4 nedenfor). Strukturen i nærværende metodekapitel tager udgangspunkt i modellen The Research Onion (Saunders, Lewis & Thornhill, 2009, p. 108). Denne struktur er i overensstemmelse med gængs metode for at struktu- Metode Side 17 af 185

18 rere denne type projekter (se eksempelvis Rienecker & Jørgensen, 2006; Saunders, Lewis & Thornhill, 2009; Voxted, 2008). Resultaterne af de nævnte interviews udmunder i en række anbefalinger til en anderledes tilgang til arbejdet med de tre IT Service Management-processer, som vil føre til bedre resultater i form af hurtigere reaktions- og løsningstid på henvendelser. Desuden vil analyser af situationen før, under og efter ændringen blive udarbejdet og/eller anvendt til perspektivering af den foreslåede løsning. 3.1 Forskningsparadigme Med udgangspunkt i Andersen (2008) er der tale om en opgave af problemløsende karakter. Lean-tankegangens fokus på kontinuerlig forbedring er orienteret mod løbende forandring i form af inkrementale ændringer (kaizen) i modsætning til radikal forandring (kaikaku). Der anvendes en subjektiv (Darmer & Nygaard, 2008; Saunders, Lewis & Thornhill, 2009) tilgang til forskningen i nærværende projekt, idet forfatteren foretager et studie af egen virksomhed, jf. afsnit 3.3 nedenfor. Dette er sådan at forstå, at oplevelsen af den situation, der behandles i dette projekt, afhænger af forfatterens eget synspunkt (Weirsøe, 2008). Gennem en række interviews søges at afdække forskellige aktører i organisationens opfattelse af situationen og de udfordringer og forbedringer, der øjnes. Observationer fra disse interviews behandles i en skraldespandsmodel (grounded theory, Darmer & Nygaard, 2008; se afsnit 3.3 nedenfor). I modsætning til det positivistiske paradigme, der forholder sig objektivt til det studerede fænomen, svarer denne fortolkende tilgang til et hermeneutisk videnskabsideal (Christiansen, 2008), idet det er nødvendigt at anlægge et aktørsyn, især i de problemstillinger omkring partnering der indeholder et menneskeperspektiv i forbindelse med, at to eller flere virksomheders kulturer skal samarbejde i forsyningskæden. (Christiansen, 2000, p. 273). Paradigmet i opgaven antager således en interpretivistisk (Saunders, Lewis & Thornhill, 2009), konstruktivistisk (Darmer & Nygaard, 2008; Johansen & Tetzschner, 2008; Weirsøe, 2008) natur. 3.2 Forskningstilgang Formålet med nærværende projekt er at opnå en øget effektivitet i arbejdet med de tre processer som nævnt i indledningen og problemformuleringen. Metoden er således som udgangspunkt induktiv (Darmer & Nygaard, 2008; Ghauri & Grønhaug, 2002; Nielsen, 2008; Nielsen, 2008; Saunders, Lewis & Thornhill, 2009). Udarbejdelse af projektrapporten sker således under gensidig, indbyrdes hensyntagen til tre målgrupper. Dels omfatter det faglige, videnskabelige aspekt produktion af ny viden på baggrund af eksisterende teori (Nielsen, 2008) inden for anvendelsen af Lean-principper i IT-sammenhæng. Dels har den fokale organisation en naturlig interesse i afdækning af viden, der kan anvendes til effektivisering af arbejdet med de tre Metode Side 18 af 185

19 processer. Endelig har forfatteren en egen interesse i emnet, både på det videnskabelige fagområde, men også i kraft af sin egen rolle i organisationen som deltagende aktør (Blichfeldt & Hansen, 2008). 3.3 Forskningsstrategi Opgaven omfatter elementer af casestudie og grounded theory, og antager karakter af aktionsforskning i form af praksisorienteret projektarbejde, som er: En systematisk kvalitativ undersøgelsesmetode, hvis formål er at udvikle teoretisk argumenterede handlinger på baggrund af observationer og refleksioner over tidligere handlinger og dokumenter fra praksis. Rod, 2008, p. 35 Praksisorienteret projektarbejde tager udgangspunkt i forskningsbegrebet grounded theory (Rod, 2008). Processen er cyklisk af natur, idet konklusionen fra første iteration udgør starten på næste iteration. Dette cykliske tankemønster er i tråd med Demings PDCA-cyklus og med Lean-tankegangens fokus på kontinuerlig forbedring (se Kapitel 2 ovenfor). Casestudiet er en anvendelig metode inden for nærværende studieområde, idet det kan anvendes til at udforske eksisterende teori (Johansen & Tetzschner, 2008; Saunders, Lewis & Thornhill, 2009). Casestudiet tjener ifølge Johansen & Tetzschner (2008) to formål; at bidrage til forskerens læringsproces og at bidrage til produktion af ny viden. Da der i nærværende opgave netop fokuseres på produktion af ny viden, nemlig omkring anlæggelsen af et Lean-perspektiv på arbejdet med udvalgte ITIL-processer, stemmer dette formål godt overens med hensigtserklæringen ovenfor (Nielsen, 2008). Der fokuseres i casestudiet på en enkelt afdeling i en enkelt virksomhed, nemlig PenSams IT-afdeling. Flere såkaldt indlejrede cases (Ghauri & Grønhaug, 2002; Saunders, Lewis & Thornhill, 2009) kunne have været valgt i form af de enkelte afdelinger, men synsvinklen i nærværende sammenhæng fokuserer på håndteringen af processerne på tværs af afdelinger, ikke på en funktionel opdeling. Derimod anvendes indlejrede cases i den forstand, at der tages udgangspunkt i en række interviews, der beskriver den nuværende situation i arbejdet med de tre ITIL-processer. Disse interviews udgør datagrundlaget for en fortolkning i analysekapitlet. Der er således tale om et enkeltcasestudie med en række indlejrede cases (Ghauri & Grønhaug, 2002; Saunders, Lewis & Thornhill, 2009). Saunders, Lewis & Thornhill (2009, pp ) beskriver fire forhold, hvorved aktionsforskning adskiller sig fra andre forskningsmetoder. For det første er der tale om forskning i handling frem for forskning om handling (ibid.); dette stemmer godt overens med nærværende projekts formål om at applicere et teoretisk rammeværktøj på en praktisk problemstilling hentet fra virkelighedens verden i PenSams IT-afdeling. For det andet involverer en praktiker sig i forskningen i et samspil mellem teori og praksis, hvor forskeren er en Metode Side 19 af 185

20 del af den organisation, hvor ændringen finder sted (ibid.); dette gør sig ligeledes gældende i nærværende sammenhæng. For det tredje understreges processens iterative natur i form af diagnosticering, planlægning, handling og evaluering (ibid.); dette er i tråd med Lean-tankegangens fokus på kontinuerlig forbedring og Demings PDCA-cyklus, der også finder anvendelse i nærværende projekt. Endelig skal forskningen række ud over rammerne for projektet og fungere som input i andre sammenhænge, såsom en studerende, der forsker i sin egen virksomhed (ibid.) med henblik på at generere ny viden, hvor samspillet mellem individ og gruppe omkring arbejdets tilrettelæggelse og udførelse i organisationen analyseres i sin virkelige kontekst (Nielsen, 2008). Dette udmønter sig i nærværende projekt i en række anbefalinger (Kapitel 7). Grounded theory anses for at være den bedste anvendelse af induktiv metode (Saunders, Lewis & Thornhill, 2009), og anvendes til opbygning af teori (ibid.). I grounded theory indsamles data uden udgangspunkt i et teoretisk rammeværktøj. På baggrund af indsamlet data formuleres en teori, som igen afprøves (be- eller afkræftes) ved yderligere dataindsamling. Metoden omfatter således elementer af både induktion og deduktion (Saunders, Lewis & Thornhill, 2009) i en iterativ proces. Således anvendes ikke en spørgeramme i de planlagte dybdeinterviews, der på forhånd er struktureret efter samme model som litteratur- og teorikapitlerne, idet hensigten netop er at uddrage respondenternes individuelle opfattelser (Nielsen, 2008). 3.4 Dataindsamling Data til brug i analysekapitlet udgøres af kvalitative data indsamlet gennem interviews. Data Sekundære data Primære data Kvalitative data Kvantitative data Litteraturreviewet ovenfor gennemgår den eksisterende litteratur inden for Lean, særligt med fokus på anvendelsen af Lean i sammenhæng med IT. På grundlag af denne gennemgang udvælges et antal teorier (Voxted, 2008, p. 20, pkt. 1), som gennemgås nærmere med henblik på anvendelse til analyseformål i teorikapitlet nedenfor. Litteraturreviewet baserer sig på sekundære data i form af bøger og artikler i videnskabelige tidsskrifter. I det nærværende gøres ikke brug af sekundære, kvantitative data. De planlagte interviews er et udtryk for primærdata, idet de indsamles specifikt til brug for nærværende analyse. Denne tilgang er valgt, idet der i den fokale organisation ikke tidligere er foretaget lignende undersøgelser, hvorfor det er nødvendigt at indsamle data til dette formål (Ghauri & Grønhaug, 2002). Data antager en kvalitativ natur, idet der er tale om interviews. I det nærværende gøres ikke brug af primære, kvantitative data. Tabel 3.1: Oversigt over dataindsamling Metode Side 20 af 185

21 3.4.1 Interviews Der er planlagt et semistruktureret fokusgruppeinterview. Det skal understreges, at der er tale om et interview af en gruppe, hvor intervieweren i modsætning til fokusgruppediskussionen spiller en aktiv rolle i at styre interviewet i en bestemt retning ved at stille specifikke spørgsmål (Baarts & Mehlsen, 2008). Fokusgruppeinterviewet modereres af en interviewer fra IT-driftsleverandøren. Nærværende forfatter deltager ikke aktivt i interviewet, men er til stede som observatør. Interviewet transskriberes ikke, men interviewguide og analyserapport vedlægges nærværende projektrapport som bilag (se Bilag 10.3). Hensigten med brugen af observationer fra dette fokusgruppeinterview er at afdække tilfredsheden med Service Desk hos slutbrugerne, der er initierende for de processer, der er omfattet i afgrænsningen af problemstillingen. Formålet med denne undersøgelse af brugertilfredsheden er at skabe et sammenligningsgrundlag at måle i forhold til, når de anbefalede ændringer er implementeret, for dermed at kunne afgøre, om ændringerne har haft (den ønskede) effekt. Denne tilgang suppleres med dybdeinterviews med enkelte udvalgte aktører. Interviewformen er eksplorativ, idet der er tale om udforskning af et emne, forfatteren har begrænset kendskab til, og semistruktureret, idet der ikke på forhånd er forberedt en række spørgsmål, som skal besvares i rækkefølge, men derimod blot en overordnet spørgeramme. Årsagen til dette er, at formålet med interviewet er at afdække respondentens syn på sagen. Derfor er det ikke tilrådeligt at styre interviewet for meget, men blot at lede samtalen på rette vej (Nielsen, 2008). Respondenten får ved interviewet udleveret et ark A3-papir til at illustrere sine budskaber (Sobek & Smalley, 2008). Spørgerammer for fokusgruppeinterviews og dybdeinterviews er vedlagt (Bilag 10.3). Samtlige dybdeinterviews transskriberes, og transskriptionerne vedlægges som bilag (se Bilag 10.4) Population Udgangspunktet for udpegning af respondenter til fokusgruppeinterviews er brugere (ansatte i den fokale virksomhed), der har svaret på en tidligere (kvantitativ) undersøgelse foretaget af Service Desk, og som således antages at være egnede emner til et fokusgruppeinterview. Der foretages desuden dybdeinterviews med en række respondenter, der antages at spille en særlig rolle i arbejdet med de tre processer. Disse omfatter; den ansvarlige for kontrakten med IT-driftsleverandøren, den overordnet ansvarlige for IT Service Management, som også er ansvarlig for Service Request Management-processen, den ene af de to ansvarlige for Incident og Problem Management-processerne (den anden er forfatteren selv), de to områders chefer samt IT-direktøren. Desuden interviewes udvalgte medarbejdere og ledere i forretningen, der har tæt tilknytning til og samarbejde med IT-området. Begrundelsen for denne udvælgelse af respondenter på forskellige organisatoriske niveauer er, at der på de samme spørgsmål gives vidt forskellige svar, afhængigt af om undersøgeren spørger direktøren, produktionschefen eller arbejderen direkte på gulvet (Nielsen, 2008, p. 169). Metode Side 21 af 185

22 4 Teori Lean-tankegangen centrerer sig om begreberne værdi og spild. 4.1 Værdi Womack & Jones (2003) definerer på baggrund af Toyota Production System (Ohno, 1988) begrebet Lean (Womack & Jones, 2003; Womack, Jones & Roos, 1990; se Bilag 10.6) som bestående af fem principper: 1. Specificér kundeværdi 2. Identificér værdistrømme 3. Skab flow 4. Skab pull 5. Tilstræb perfektion Kundeværdi Udgangspunktet for Lean-tankegangen er at identificere, hvad der er værdi for slutkunden (se evt. Jensen, 2012a; b), der i sidste ende er virksomhedens eksistensberettigelse. Det er således kunden, der definerer, hvad værdi er. Det kan være svært for virksomheden at definere, hvad der er værdi for kunden (Womack & Jones, 2003), ligesom det kan være svært at definere, hvem slutkunden er (Jensen, 2012a). Ligeledes ved kunder ikke nødvendigvis i alle tilfælde, hvad der er bedst for dem selv (ibid.). Eksisterende organisationsformer, teknologier og aktiver foreskriver den traditionelle masseproduktionstankegang. Skiftet væk fra denne kræver en fundamental ændring i tilgangen til værdiskabelse, hvor der fokuseres på værdiskabelse fra kundens synspunkt uden skelen til eksisterende aktiver (Womack & Jones, 2003). Alle aktiviteter, der ikke er værdiskabende for kunden, er muda, spild (ibid.). Ifølge Jensen (2012a) lider princippet om kundeværdi under manglende fokus på værdi for kunden, idet det ikke defineres, hvorledes kundeværdi beregnes. Definitionen bør således præciseres, så kundeværdi er forskellen på gevinst og omkostninger for kunden. Kundeværdien øges, hvis produktet tilføres egenskaber eller tjenesteydelser, der giver øget værdi uden yderligere omkostninger, produktet tilføres egenskaber eller tjenesteydelser, der medfører en stigning i værdi og en tilsvarende lavere stigning i omkostninger, Teori Side 22 af 185

23 produktets egenskaber og tjenesteydelser fastholdes og omkostningerne for kunden reduceres, eller produktets egenskaber eller tjenesteydelser reduceres, hvilket medfører en forringelse i værdi med til gengæld en tilsvarende større reduktion i omkostninger I alle fire tilfælde øges forskellen mellem kundens gevinst og omkostninger. Det er vigtigt at holde for øje, at kundens omkostninger er afgørende at anskue, idet virksomhedens profit ikke øges ved en nedbringelse af omkostninger, der gives videre til kunden i form af lavere pris. I princippet er foræring af produkter til kunderne en Lean-strategi, idet dette vil øge kundeværdien, omend den er uholdbar på lang sigt. Første og anden mulighed for at øge forskellen mellem kundegevinst og kundeomkostninger minder om Porters (1990) differentieringsstrategi, mens tredje og fjerde metode i højere grad minder om Porters (ibid.) omkostningslederstrategi (Jensen, 2012a). Jensen (2012a) argumenterer yderligere for, at slutbrugeren ikke i alle tilfælde nødvendigvis ved, hvad der er den bedste løsning, idet pågældendes vidensniveau er begrænset og subjektivt funderet. Slutbrugeren er sjældent i stand til at træffe en beslutning på et fuldstændigt informeret grundlag. Endelig er køber og slutbruger ikke nødvendigvis den samme entitet. Dette begreb kalder Jensen (2012a) den pluralistiske kunde. Som individer betragtet er brugerne af de IT-tjenesteydelser, der udbydes, ikke selv betalere af ydelserne, og der kan således forekomme interessekonflikt mellem dem og de ansvarlige for budgettet eller aftalen med leverandøren. Værdistrømme En værdistrøm er defineret som det sæt af aktiviteter, der skal til for at levere et produkt til kunden. Strømmen omfatter tre elementer og løber fra koncept og produktudvikling og -lancering (problemløsning) over ordremodtagelse, planlægning og levering (informationsstyring) til kunden har det færdige produkt (fysisk transformation, Womack & Jones, 2003). Denne kæde af aktiviteter starter ved modtagelsen af en salgsordre i den ene ende (informationsflow) og ved udvindingen af råvarer i den anden ende (vareflow) og dækker alle virksomheder undervejs i forløbet (Harland, 1996). Koordineringen mellem virksomhederne, hvilket også er kendt under begrebet Supply Chain Management (ibid.)., er grundlaget for Womack & Jones (2003) begreb Lean Enterprise, som er et samarbejde mellem virksomhederne om at skabe en kanal for værdistrømmen med henblik på at eliminere spild. Det kræver en ændret samarbejdsform virksomhederne imellem, ikke mindst hvad angår gennemsigtighed (ibid.). Flow Når værdien er specificeret, og værdistrømmen er identificeret og åbenlyst spild fjernet, er næste skridt at skabe flow. Dette medfører en opløsning af den funktionelle organisering i afdelinger, hvor aktiviteter Teori Side 23 af 185

24 grupperes efter funktion, så de kan udføres så effektivt som muligt, underforstået i så store mængder ad gangen som muligt. Baggrunden for denne tankegang er et (regnskabsteknisk funderet) ønske om at udnytte ressourcer (aktiver) bedst muligt. Modig & Åhlström (2012) kalder dette perspektiv for ressourceeffektivitet: It is important always to define the process from the perspective of the flow unit Modig & Åhlström, 2012, p. 20 I stedet for at fokusere på stordriftsfordele, bør arbejdet organiseres med fokus på det fremstillede produkt. Modig & Åhlström (2012) kalder dette perspektiv for flow-effektivitet. Det er hensigten, at arbejdet skal organiseres med fokus på flow-effektivitet frem for ressourceeffektivitet (Modig & Åhlström, 2012). Modig & Åhlström (2012) opstiller en effektivitetsmatrice, et rammeværktøj, de kalder The Efficiency Paradox (Figur 4.1), hvor formålet er at bevæge sig mod højre og opad i figuren. Målet om høj effektivitet i både flow og ressourcer (øverste højre kvadrant) kan i virkelighedens verden aldrig opnås, men på vejen mod målsætningen er det vigtigt at fokusere på flow frem for ressourcer (Modig & Åhlström, 2012). Figur 4.1: The Efficiency Paradox. Kilde: Modig & Åhlström, For at kunne foretage dette skift fra stordriftsfordele til produktfokus er det nødvendigt at kunne drastisk reducere den tid, det tager at overgå fra fremstilling af et produkt til et andet. Det er ifølge Womack & Jones (2003) ikke tilstrækkeligt at organisere arbejdet i processer, som er defineret som collections of tasks and activities that together and only together transform inputs into outputs (Garvin, 1998, p. 33). Årsagen til dette er, at omstrukturering fra en funktionsorienteret til en procesorienteret organisering ikke er tilstrækkelig, hvis virksomhedens kultur ikke følger med (Majchrzak & Wang, 1996). Som Hammer (1999) udtrykker det: The combination of integrated processes and fragmented organizations has created a form of cognitive dissonance in many businesses: the horizontal processes Teori Side 24 af 185

25 pull people in one direction; the traditional vertical management systems pull them in another. Confusion and conflict ensue, undermining performance. Hammer, 1999, pp Der er således risiko for, at procesorganisering fører til hvad Womack & Jones (2003) kalder process villages; organisering efter enkelte processer uden sammenhæng på tværs gennem hele værdikæden. For at skabe flow er det således nødvendigt at omorganisere både virksomheder, funktioner og roller (Womack & Jones, 2003). Specielt lederens rolle er det nødvendigt at redefinere (Seddon, 2007a; 2008b). Ohno (1988) udtrykker det således: The time that provides me with the most vital information about management is the time I spend in the plant, not in the vice president s office. Ohno, 1988, p. 20 Pull Når flow-organisering er indført, reduceres den forbrugte tid i alle led i værdistrømmen drastisk, både fra produktudvikling til lancering, fra ordremodtagelse til levering og fra råvare til færdigvare. Årsagen til dette er, at kundeordrer kan trækkes (pull) gennem systemet, hvor en vare først fremstilles, når den efterspørges. Det er således ikke nødvendigt at fremstille produkter på forhånd (push), så de er klar salg og levering, hvis eller når de efterspørges (Womack & Jones, 2003). Det punkt i værdistrømmen, hvor fremstillingen er baseret på faktisk efterspørgsel frem for forecast, kan således lægges tidligere: The information decoupling point is the point in the supply chain at which the order information changes from marketplace sales data to forecast driven data. It is the basis for supply chains moving towards continuous flow and away from pointto-point movements and ultimately to holistic control. Mason-Jones & Towill, 1999, pp Ohno (1988) beskriver, hvordan virksomheden bør indrette sig, så kunderne kan vælge (pull) de varer, de efterspørger, frem for at virksomheden bestemmer (push), hvad kunden kan købe. Ohno (1988) fik idéen om pull-systemet fra amerikanske supermarkeder, hvor personalet fylder varer op bagfra, efterhånden som kunderne tager de varer ned fra hylderne, de skal bruge. Rother & Shook (2003) beskriver supermarkedet som et led i en produktionsproces, der fungerer som buffer ( stødpude ). Når supermarkedet er fyldt op, stopper det forudgående led i produktionen, indtil der igen er efterspørgsel fra det senere led i processen. Teori Side 25 af 185

26 Dette element kritiserer Jensen (2012b) som et internt modsætningsforhold i Lean-filosofien, idet supermarkedet er et udtryk for opbygning af et (mindre) lager, hvilket strider imod princippet om at nedbringe spild, hvor den vigtigste spildkategori er overproduktion (Ohno, 1988; Shingo, 1989). Perfektion De fire første principper (kundeværdi, værdistrøm, flow og pull) hænger sammen i en cyklus, der til stadighed kan identificere og fjerne spild. Fokus på produktet og direkte dialog med kunden er konstant kilde til nye måder at specificere kundeværdi og forbedre flow og pull (Womack & Jones, 2003). Der skal altid tages udgangspunkt i værdi, som den er defineret af kunden (ibid.). Det er vigtigt at pointere, at arbejde kun skal automatiseres, hvis det passer ind i sammenhængen (Cunningham & Jones, 2007, Womack & Jones, 2003). Opnåelse af perfektion sker ved fjernelse af al spild, hvilket gøres ved hjælp af de første fire principper. Omvendt kan perfektion kun opnås ved eliminering af ikke-værdiskabende aktivitet, ikke ved skabelse af noget nyt. Dette er således udtryk for et iboende modsætningsforhold (Jensen, 2012a). Prisen for at finde den sidste fejl kan vise sig at blive for høj, idet omkostningen ved fejlfindingen overstiger gevinsten. Dette står i kontrast til nultolerancen over for fejl i elimineringen af spild (ibid.). Det kan være farligt at håndplukke elementer for at tilpasse Lean Thinking til lokale forhold uden samtidig at anskue hvilke elementer, der i samme moment skæres fra. Ligeledes er det risikabelt bevidstløst at indføre alle fem principper. Organisationen bør være sig sine kernekompetencer bevidst samt være klar over, hvilke kundesegmenter disse kompetencer henvender sig til. Hvis kundepræferencer ikke identificeres ordentligt, risikerer virksomheden at anskue nogle kernekompetencer som spild og at organisere sig ineffektivt i forhold til opfyldelsen af kundeværdi (Jensen, 2012a). 4.2 Spild Taiichi Ohno, der regnes for at være faderen til Toyota Production System (Liker, 2004), definerer syv kategorier af spild: Unødig transport af varer, der ikke skal bruges i produktionen Unødig lagring af enheder (både råvarer, halvfabrikata og færdigvarer) Unødig flytning af enten medarbejdere eller varer Unødig ventetid, dvs. enten produkter, der venter på næste led i produktionsprocessen, eller led i produktionsprocessen (medarbejdere eller maskinel), der venter på et produkt Overproduktion Overprocessering Fejlbehæftede enheder Teori Side 26 af 185

27 En ottende spildkategori er senere blevet tilføjet (Bell & Orzen, 2011; Cunningham & Jones, 2007; Liker, 2004), nemlig uudnyttet menneskelig kreativitet, som forårsages af ikke at involvere og lytte til medarbejderne: Underutilized human potential is the gold mine hidden within every company. Bell & Orzen, 2011, p. 91 Siden har andre forfattere føjet yderligere spildkategorier til listen (se eksempelvis Bell & Orzen, 2011; Bicheno & Holweg, 2008). Tabel 10.7 i Bilag nedenfor danner et overblik over spildkategorierne. Den form for spild, det er vigtigst at eliminere, er overproduktion, som fører til unødig lagring (Ohno, 1988; Shingo, 1989). Overproduktion forekommer i to former; at fremstille mere, end der er behov for, eller at fremstille produkter hurtigere, end de behøves (Shingo, 1989). Overproduktion elimineres ved at afskaffe lagre og i stedet producere den rette mængde til den rette tid, just-in-time (ibid.). For at undgå spild i form af unødigt lager er det nødvendigt at fremstille alle produkter i små mængder ad gangen med hyppigere skift mellem produktionskørslerne (Ohno, 1988). Rother & Shook (2003) kalder dette princip Every Part Every Day. Formålet er at undgå, at der opbygges lagre af råvarer og halvfabrikata undervejs i produktionsprocessen. Dette kræver, at tidsforbruget på at ændre opsætning på maskiner mellem forskellige produktionsløb afkortes så meget som muligt (ibid.). Til dette formål har Shingo (1985) udviklet metoden Single-Minute Exchange of Die (SMED), som fokuserer på reduktion af omstillingstiden mellem fremstilling af forskellige enheder (ibid.). Værdistrømsanalyse (Value Stream Mapping) er et redskab til analyse af en proces med henblik på at identificere og fjerne ikke-værdiskabende aktivitet (Liker, 2004; Rother & Shook, 2003). Aktiviteter, der ikke skaber øget værdi, som kunden er villig til at betale for, er spild og skal elimineres (ibid.). Spear & Bowen (1999) opstiller fire regler, der udgør essensen af Toyota Production System: 1. Alt arbejde skal være højt specificeret for så vidt angår indhold, sekvens, timing og resultat 2. Al kunde-leverandør-kontakt skal være direkte, og der skal være en utvetydig ja/nej-måde at sende forespørgsler og modtage svar 3. Alle produkters og tjenesteydelsers vej gennem systemet skal være enkle og direkte 4. Alle forbedringer skal ske i henhold til den videnskabelige metode, under vejledning af en læremester, på det lavest mulige niveau i organisationen Teori Side 27 af 185

28 Figur 4.2: Demings (1982) PDCA-cyklus Med den videnskabelige metode menes Demings Plan-Do-Check-Act-cyklus (Figur 4.2), som ifølge Liker (2004) danner grundlaget for Toyota Production System. Baseret på Demings 14 ledelsesprincipper (Bilag 10.13) og Toyota Production System beskriver Liker (2004) 14 ledelsesprincipper (Bilag 10.12), som er inddelt i fire sektioner: 1. En langsigtet filosofi om virksomhedens ansvar for at skabe værdi 2. Værdiskabende processer, der og eliminerer spild og skaber jævnt flow fra start til slut 3. En kultur, hvor lederen fremgår som et godt eksempel, med fokus på kontinuerlig forbedring og respekt for medarbejdere og netværk 4. Tilbundsgående problemløsning og organisatorisk læring Bell & Orzen (2011) samler Lean-principperne i Lean Enterprise Principles Pyramid (Figur 4.3). Figur 4.3: Lean Enterprise Principles Pyramid. Kilde: Bell & Orzen, Teori Side 28 af 185

29 Som andre teorier, der benytter sig af pyramideformen som illustrativt element (eksempelvis Maslows behovspyramide, Maslow, 1954), udgøres pyramidens nederste lag af de mest basale elementer, som i denne sammenhæng er sociale strukturer (Bell & Orzen, 2011). Det første element i Lean Enterprise Principles Pyramid er begrebet Constancy of Purpose, som er Demings første ledelsesprincip (Deming, 1982; se pkt. 1 i Bilag 10.13). Det nederste lag omfatter desuden respekt for medarbejderne, som også Liker (2004) fremhæver, og stræben efter perfektion, som også fremhæves af Deming (1982) som kontinuerlig forbedring (se Figur 4.2). Stræben efter perfektion ses ligeledes i kaizen-begrebet (Ohno, 1988; Liker, 2004), ligesom det danner grundlag for Womack & Jones femte princip om perfektion. Næste trin i pyramiden er proaktiv adfærd. Også dette princip stemmer overens med blandt andre Deming, der beskriver kvalitet som pride of workmanship (1982; se pkt. 12 i Bilag 10.13) og Lean-tankegangens fokus på konstant stræben efter forbedring. I tredje niveau illustrerer pyramiden bevidsthed om virksomhedens interaktion med sin omverden. Voice of the Customer understreger vigtigheden af at sætte kunden i fokus, hvilket hænger sammen med Womack & Jones (2003) første Lean-princip om identificering af kundeværdi. Ligeledes argumenterer Seddon (2005, 2007a; b; c; 2008a; b; c) for kundefokus som virksomhedens eksistensberettigelse. Quality at the Source betyder at gøre tingene rigtigt første gang og ikke acceptere fejl undervejs i produktionen. Hvis en fejl opdages i en komponent, sendes denne ikke videre til næste led, men produktionen stopper, indtil fejlen er rettet. Dette stemmer overens med begrebet jidoka, som er et af de to centrale temaer i Toyota Production System (Ohno, 1988; Liker, 2004; se pkt. 5 i Bilag 10.12) og med redskabet værdistrømsanalyse til identificering og fjernelse af spild (Liker, 2004; Rother & Shook; 2003). Det tredje og sidste begreb i dette lag i pyramiden er systemtænkning, som er omdrejningspunktet for Seddons (2005, 2007a; b; c; 2008a; b; c) perspektiv. Pyramidens fjerde lag omfatter flow og pull, tredje og fjerde princip ifølge Womack & Jones (2003), og justin-time, som er den anden søjle i Lean-huset (Liker, 2004; Figur 2.1). Spidsen af pyramiden udgøres af den kultur, der er nødvendig for at etablere og opretholde en Lean-tilgang med kontinuerlig forbedring (Deming, 1982; Womack, Jones & Roos, 1990 m.fl.). 4.3 Systemtænkning og Lean i servicesammenhæng John Seddon og konsulenthuset Vanguard arbejder med en metode, de beskriver som anvendelse af Toyota Production System i servicevirksomheder. Denne metode er kendt som Vanguard-metoden eller systemtænkning (Seddon, 2005). Kernen i systemtankegangen er, at virksomheden i modsætning til den traditionelle masseproduktionstankegang skal anlægge et perspektiv fra kundens synsvinkel. Forskellene mellem systemtænkning og traditionel tænkning fremgår af Tabel 4.1 nedenfor. Teori Side 29 af 185

30 Traditionel tænkning Systemtænkning Perspektiv Oppefra og ned -hierarki Udefra og ind -system Arbejdets form Funktionel specialisering Efterspørgsel, værdi og flow Beslutning Adskilt fra arbejdet Integreret i arbejdet Måling Mål, standarder, serviceniveauer, aktivitet mål relateret til budget Formåen, variation mål relateret til formål Motivation Ydre faktorer (gulerod og pisk) Indre faktorer Ledelsesfokus Budget- og medarbejderledelse Handling ud fra viden om systemet Holdning til kunder Holdning til leverandører Kontraktuel Kontraktuel Hvad giver værdi for kunden? Partnerskab og samarbejde Tabel 4.1: Synspunkter i systemtænkning vs. traditionel tænkning. Kilde: Efter Seddon, 2005; Nielsen, 2011 Forudsætningen for anlæggelse af systemperspektivet er ifølge Seddon (2005) at lære at Se (learning to See) al den spild, der forekommer i traditionelt, funktionelt organiserede virksomheder. Dette gøres ved at anlægge et udefra og ind -perspektiv (se Tabel 4.1) på virksomheden set fra kundens synsvinkel. Det er med Bell & Orzens (2011) ord nødvendigt at udvikle beginner s mind: the ability to look at a familiar process as if for the first time and really see what is happening Bell & Orzen, 2011, p. 35 Ifølge Kotter (1995) sker megen forandring på grundlag af en (potentiel) krise. Første trin i Kotters model for forandringsledelse er netop Establishing a Sense of Urgency (Kotter, 1995, p. 61). Seddons synspunkt er, at forandring snarere burde ske som et bevidst valg truffet af ledelsen. Således stemmer Seddons (2005) Urgency for Change (p. 100) overens med Kotters (1995) model for forandringsledelse. Learning to See er at forstå hvad virksomheden præsterer i sin nuværende organisering, og hvorfor den præsterer, som den gør. Dette er første fase i Check-Plan-Do-modellen (Seddon, 2005, p. 101; Figur 4.4), som tager udgangspunkt i Demings videnskabelige metode (Figur 4.2). Demings cyklus starter i planlægningsfasen med en idé om, hvad der skal gøres. Dette forudsætter, at modellen anvendes ud fra systemtankegangen (Seddon, 2005). Check-Plan-Do-modellen starter med Checkfasen, hvor lederen først skal lære at Se (jf. ovenstående). Teori Side 30 af 185

31 I Check identificeres først formålet, virksomhedens eksistensberettigelse, set fra kundens synsvinkel. Dette skyldes, at kunderne eneste oplevelse af virksomheden er de transaktioner, de har med virksomheden. Efterspørgslen identificeres med henblik på at afdække virksomheden kapabilitet, som igen er defineret ud fra formålet (eksistensberettigelsen). Næste skridt er at forstå årsagerne til efterspørgslen, som kan inddeles i to kategorier; ønsket efterspørgsel (value demand) og uønsket efterspørgsel (failure demand). Sidstnævnte, uønsket efterspørgsel, bidrager ikke med øget værdi og derfor spild, som skal elimineres. Årsagerne til dette spild skal findes i systemets begrænsninger (Seddon, 2005). Plan omfatter at fastslå hvilke ændringer, der skal til for at organisere arbejdet efter to formål; for det første at møde kundernes efterspørgsel, og for det andet hele tiden at kunne forbedre indsatsen. Dette kræver, at funktionelt orienterede mål om eksempelvis svartider på telefonopkald afskaffes (Deming, 1982; se pkt. 10 i Bilag 10.13) og erstattes af kapabilitetsmål. Det kræver også, at lederens rolle ændres fra at styre medarbejderne til at styre systemet (Seddon, 2005). Ændringen gennemføres i Do-fasen, og resultaterne af den ændrede proces overvåges og evalueres mod formålet. Herefter returneres til Check i næste iteration af cyklen (Seddon, 2005). Figur 4.4: Vanguard-metodens Check-Plan-Do-cyklus. Kilde: Seddon, Seddon (2005; 2007a; b; c; 2008a; b; c) beskriver seks trin (Figur 4.6) til forbedring af virksomhedens produktivitet, som gennemgås i det følgende. Vær forberedt på at ændre tænkemåde Mange virksomheder er organiseret som oppe-fra-og-ned-hierarkier, hvor arbejdet er inddelt efter funktionel specialisering, og beslutninger træffes af ledelsen, adskilt fra arbejdets udførelse. Det er ledelsens opgave at træffe beslutninger, hvilket gøres på grundlag af traditionelle målemetoder som omkostningsstyring, budgetter og standarder (Seddon, 2007a). Denne tankegang hidrører fra det forrige århundredes masseproduktionsfilosofi, men virkeligheden har ændret sig hurtigere, end ledelsestankegangen har fulgt med, og disse ledelsesprincipper synes nu at være Teori Side 31 af 185

32 det eneste rigtige. Metoderammen bag Toyota Production System er blevet til gennem praktisk, problemløsningsorienteret arbejde, ikke på direktionsgangen. Tankegangen repræsenterer en radikal ændring af de traditionelle ledelsesprincipper, som kan være svær at forholde sig til (Seddon, 2007a). Systemtænkning tager udgangspunkt i dette ændrede perspektiv, idet formålet med virksomhedens eksistens er at levere det produkt (varer og/eller tjenesteydelser), kunden efterspørger. Således anlægges et perspektiv set fra kundens synsvinkel, udefra og ind frem for oppefra og ned. Set udefra forekommer virksomheden ineffektiv, og årsagen hertil er den måde, virksomheden er organiseret og styret (Seddon, 2007a). Fordi mål er relateret til funktioner og afdelinger, bliver den enkelte enheds fokus at opnå egne mål på bekostning af andres: By focusing its measurement system on processes rather than functions, an enterprise helps create alignment and a common focus across disparate units; instead of each seeking to optimize its own unique metric, departments are encouraged to work together to improve the performance of the process(es) of which they are part. Hammer, 2007, p. 25 Selvom arbejdet er organiseret i afdelinger og funktioner, flyder det i virkeligheden gennem virksomheden. Den funktionelle specialisering udgør en hæmsko, som kan hindres ved at lære at styre dette flow, og første skridt på den vej er at anskue organisationen fra kundens synspunkt. God service resulterer altid i lavere omkostninger. For at kunne styre flowet er det nødvendigt at måle, hvor godt flowet virker. Disse målinger kaldes kapabilitetsmålinger. De er udledt af, hvad der skaber værdi for kunden, og de hjælper til at flytte ledelsens fokus fra omkostninger til i stedet at fokusere på årsagerne til omkostningerne (Seddon, 2007a). Omkostningerne og medarbejdernes præstation er en konsekvens af systemet, hvilket vil sige den måde, arbejdet er organiseret og styret. Standarder modvirker præstationsforbedringer, idet formålet med arbejdet bliver at opfylde målet eller standarden snarere end at servicere kunderne. Kapabilitetsmålinger, derimod, opfordrer til at stræbe efter bedre resultater. Traditionelle præstationsmål demoraliserer medarbejderne (Seddon, 2007a) og fører til øget stress (Sprigg & Jackson, 2006): Greater utilization of dialog scripting and higher levels of performance monitoring are associated with higher job-related strain Sprigg & Jackson, 2006, p. 200 Kapabilitetsmål giver derimod medarbejderne mulighed for medindflydelse (Seddon, 2007a). Tænk udefra og ind Teori Side 32 af 185

33 At tænke udefra og ind i stedet for oppefra og ned vil sige at forstå omfanget af de transaktioner, virksomheden har med sine kunder. Formålet med virksomheden er at leve op til kundernes efterspørgsel, ikke at kæmpe interne kampe om eksempelvis budgetter, hvor nogle dele af virksomheden vinder på bekostning af, at andre taber. Det er nødvendigt at få alle til at arbejde sammen om forbedrede præstationer, og det fordrer en diskussion om metoder. Udefra og ind-tankegangen medfører bedre metoder. Hvis virksomheden kan identificere de elementer i en kundetransaktion, der skaber værdi, og nøjes med kun at udføre disse, vil serviceniveau og effektivitet stige, og omkostningerne vil falde, fordi der ikke er noget spild. God service koster altid mindre. Et udefra og ind-perspektiv på en traditionelt, oppefra og ned-ledet virksomhed afslører altid store mængder spild, der igen er forbundet med ringe kundeservice (Seddon, 2007b). Kundeservicefunktioner omfatter ofte store mængder af ikke-værdiskabende efterspørgsel (failure demand), som er forårsaget af noget, virksomheden ikke har formået at gøre rigtigt for kunden. I stedet for at se dette spild som et fejlslag i systemet og arbejde på at fjerne det, sætter virksomheder ofte urealistisk høje mål for at besvare opkald og ansætter flere til at tage telefonen (Seddon, 2007b). Værdi er defineret i kundernes perspektiv. Udgangspunktet er virksomhedens transaktioner med kunderne. Procedurer kan kun anvendes, hvis det kan forudsiges, hvad der skaber værdi i kundens perspektiv. Hvis ikke, skaber procedurerne spild, idet de medfører et fokus på at følge procedurerne i sig selv frem for at skabe værdi for kunden. Den bedste måde at organisere sig efter kundeværdi er således at tage udgangspunkt i opfyldelse af kundens behov (Seddon, 2007b). Tænk kapabilitet Kapabilitet svarer til forudsigelse. For at kunne forbedre virksomheden, er det til stor hjælp at vide, hvad der er forudsigeligt omkring samspillet mellem virksomheden og dens kunder. Hvad efterspørger kunderne ved transaktionen, og hvordan reagerer virksomheden? Hvis præstationen ved hver transaktion kan forbedres, reduceres omkostningerne. Derfor; hvad er forudsigeligt ved kundernes efterspørgsel? Med udgangspunkt i virksomhedens kontakt med kunderne, opdeles kundernes henvendelser i to kategorier; værdiskabende efterspørgsel (value demand), hvor kunderne henvender sig for at efterspørge virksomhedens ydelser, og ikke-værdiskabende efterspørgsel (failure demand), som er et udtryk for, at en kundehenvendelse ikke er blevet behandlet rigtigt i første omgang. Når disse to typer af efterspørgsel er klarlagt, kan det forudsiges, at situationen vil fortsætte sådan indtil forholdene ændres (Seddon, 2007c). En anden mulighed er at foretage målinger over tid, eksempelvis antallet af forekomster af en given efterspørgsel inden for et tidsinterval (dage eller uger). Disse kan bruges til at forudsige antallet af henvendelser inden for den næste tidsperiode (ibid.). For hver type kundeefterspørgsel måles, hvor godt organisationen udfører arbejdet, eksempelvis svartid, løsningstid, andelen af problemer løst ved første opkald osv. Alle udgående transaktioner, der ikke lever op Teori Side 33 af 185

34 til forventningen, genererer spild. For sen eller forkert levering fører til kundeklager, genbehandling, dobbeltarbejde osv. (Seddon, 2007c). Traditionelle effektivitetsmål såsom svartid eller opkaldets varighed erstattes af måling af andelen af henvendelser besvaret ved første kontakt med kunden (Piercy & Rich, 2009a). Ifølge Hammer: There are two keys to useful performance measurement: an emphasis on end-toend business processes and a focus on the drivers of enterprise results. Hammer, 2007, p. 25 Disse mål kan så anvendes til en vurdering af systemets evne til at leve op til kundernes efterspørgsel, identificere nye typer af efterspørgsel fra kunderne, og identificere hvorvidt der er behov for yderligere træning af medarbejderne (Piercy & Rich, 2009b). Dette fører til en reduktion i antallet af ventende opkald, idet den ikke-værdiskabende efterspørgsel falder (Seddon, 2005; Piercy & Rich, 2009a). Desuden reduceres mængden af opgaver, der lægges videre i systemet til andre afdelinger (Piercy & Rich, 2009a). Tænk flow Det nytter ikke at tænke i processer uden at fokusere på kunden. En redefinering af funktioner som processer medfører ingen forbedring: Many organisations claim to be working on their processes or flows, but the question I always find myself asking is how have they decided their focus? In many cases I find people simply re-defining their functions as processes, resulting in improvement work that doesn't improve very much, if anything. Seddon, 2008a, p. 19 Virksomhedens kerneprocesser er defineret ved typen af transaktioner med kunderne. Alle andre processer er støtteprocesser, der understøtter kerneprocesserne. Kerneprocesserne er defineret ud fra kundens synsvinkel udefra og ind og starter ved kundens efterspørgsel og slutter, når kundens behov er fuldstændigt opfyldt (Seddon, 2008a). Arbejdet redesignes, så én samlet gruppe med de nødvendige kompetencer er i stand til at besvare alle kundehenvendelser fuldstændigt ved første kontakt (Piercy & Rich, 2009a). Dette tiltag fjerner behovet for at viderestille henvendelser til andre afdelinger, reducerer den totale mængde af opkald og øger tilfredsheden hos både kunder og medarbejdere (ibid.). Teori Side 34 af 185

35 Formålet er at ændre flowet i arbejdet til kun at omfatte værdiskabende arbejde. Funktionel opdeling medfører risiko for suboptimering. Forskellige former for suboptimering er nævnt i Seddons årsager til suboptimering (Seddon, 2008a). Årsagerne til suboptimering skal findes i systembetingelserne, eksempelvis arbejdets organisering, typer af målinger osv. (ibid.). Tænk system Mange virksomheder oplever, at deres ansatte ikke yder kunderne den service, de er trænet til. Årsagen til dette problem skal ikke findes blandt medarbejderne, men derimod i systemet, hvilket vil sige den måde, arbejdet er skruet sammen på. Spild skabes som konsekvens af systemet. Eksempelvis er genbehandling forårsaget af, at arbejdet ikke er udført rigtigt i første omgang. Årsagen hertil er, at kvalitet ikke er indbygget i arbejdet, så det er nødvendigt at kontrollere efterfølgende, hvilket er spild (Deming, 1982; se pkt. 3 i Bilag 10.13). Ligeledes er dobbeltarbejde spild, eksempelvis hvor en kunde ringer og spørger til status på en sag, der ikke er leveret rettidigt eller som lovet (Seddon, 2008b). Mange virksomheder ser ikke dette spild, fordi de arbejder efter mål, der fokuserer på omkostninger og ikke på årsagerne til disse. Traditionelle afdelingers fokus på egne mål på bekostning af andre afdelinger fører til store mængder spild, ikke mindst i menneskelig kapacitet (den ottende spildform), der går med at overleve i systemet frem for at bidrage til det (ibid.). Grundet ledelsens behov for afvejning af omkostninger og god kundeservice, fører masseproduktionstankegangen til et fokus på reduktion af omkostninger. Dette medfører, at telefonerne bliver svaret af laverelønnet personale, som ikke har så dybt kendskab, og som udfører et snævert defineret sæt af opgaver, der på forhånd er fastsat af ledelsen (Piercy & Rich, 2009a). Seddon (2008a) beskriver dette som dumbing down of work (se Tabel 10.5 nedenfor). Scenariet fører til en række fejl i modtagelsen af henvendelserne, som kan kategoriseres i tre niveauer (Piercy & Rich, 2009a): Figur 4.5: Tre niveauer af fejl. Kilde: Egen tilvirkning efter Piercy & Rich, 2009a. 1. Førstestadiefejl opstår ved modtagelse af henvendelsen, og omfatter fejlkategorisering af en henvendelse. Årsagen kan være, at kunden tager fejl i sin egen opfattelse af situationen, eller at den relevante valgmulighed ikke foreligger, hvorfor det nærmeste alternativ vælges. 2. Fejl i andet stadie omfatter udmattelse af kunden grundet (for) lang ventetid, eller omstilling mellem medarbejdere og/eller telefonkøer, fordi henvendelsen ikke kan besvares ved første kontakt. Teori Side 35 af 185

36 3. Sidste stadie omfatter henvendelser, der ikke kan besvares, fordi den nødvendige viden eller information ikke er til stede. Disse henvendelser lægges til næste led i kæden, hvor de bliver besvaret af medarbejdere med mere erfaring eller dybere kendskab. Kunder, der må vente for længe i telefonen og giver op, ringer igen senere (Piercy & Rich, 2009a). Dette skaber en ond spiral, der hele tiden øger den mængde opkald, der på et givet tidspunkt venter i kø (failure demand, Seddon, 2005). Et traditionelt vigtigt præstationsmål er svartid på et telefonopkald (Piercy & Rich, 2009b). Dette mål resulterer i to måder at omgå eller snyde systemet. For det første besvares opkald og sættes direkte på hold, hvilket direkte kan måles som et irritationsmoment hos kunderne (ibid.). For det andet besvares et nyt opkald, mens arbejdet (notater mv.) med den forrige kunde endnu ikke er helt afsluttet, hvilket fører til ringere service over for kunden og større risiko for fejludført arbejde, der skal genbehandles (ibid.). På trods af den ringe kundeservice, ser præstationsmålet glimrende ud i statistikken, idet alle opkald er besvaret inden for målsætningen (Seddon, 2005; Piercy & Rich, 2009b). Selv hvor kunden kommer i kontakt med den rigtige medarbejder, der kan løse problemet, driver præstationsmålet medarbejderen til at haste gennem opgavesættet. Kunden bliver således alligevel nødt til at tage fornyet kontakt for at få afsluttet henvendelsen, hvilket igen fører til et øget totalt antal opkald (Piercy & Rich, 2009a). Henvendelser, der grundet tidsbegrænsningen i målsætningen ikke kan nå at blive besvaret fyldestgørende, overføres til et andet team, der tager sig af avancerede sager, hvilket fører til forøget ventetid hos kunden (ibid.). Traditionel, hierarkisk organisering opdeler virksomheden i funktioner og afdelinger. Systemperspektivet anskuer virksomheden som et samlet hele, hvor alle dele samarbejder om at opfylde kundens behov (Seddon, 2008b). Næste skridt er at fjerne årsagerne til den ikke-værdiskabende efterspørgsel, nemlig de mål, der forårsager dette spild, og i stedet etablere kapabilitetsmål, som fremmer den rigtige adfærd (ibid.). Ikke kun mål, men også struktur, roller, procedurer, information og jobkompetence og viden. Forudsætningen for at overgå til kapabilitetsmål er en fundamental ændring i ledelsens rolle. Når lederen lærer at anskue organisationen som et system, forbedres præstationerne (ibid.). Det handler om mig Standarder modarbejder forbedring, idet de ansporer folk til at arbejde mod systemet snarere end med det. Hvis en standard er uden for rækkevidde, vil folk forvrænge eller snyde systemet for at overleve. Er standarden derimod inden for det opnåelige, sørger folk for at holde tempoet nede for at undgå, at kravene bliver skærpet. Kapabilitetsmål gør det muligt at forudsige præstationen i systemet, Dette er vigtigere end hvorvidt og hvor ofte, systemet opnår standarden (Seddon, 2008b). Kapabilitetsdata gør ledelsen i stand til at gennemskue variation i systemet, undersøge årsagerne til denne variation og fjerne dem, hvilket fører til forbedret præstation. Seddon udtrykker det således: Teori Side 36 af 185

37 People do what you count, not necessarily what counts. If you 'count' budget, standards, targets, activity and other 'productivity' measures, that's what you'll get, regardless of the impact on your system. If, on the other hand, you 'count' achievement of purpose, you'll get better at what you exist to do. Measures of purpose are always 'outside-in' measures, not 'top-down' measures. Seddon, 2008c, p. 31 Folk gør det, der måles på, ikke nødvendigvis det, der tæller i kundens perspektiv. Kapabilitetsmål indebærer en iboende motivation i kraft af, at medarbejderne lærer at forbedre arbejdet, simpelthen fordi målene nu er integreret i arbejdet, ikke adskilt fra det. Målsætninger reducerer præstation, fordi medarbejderne tillægger arbejdet mindre værdi (Seddon, 2008c). Figur 4.6: Vanguards model for systemtænkning. Kilde: Efter Seddon: 2005; Nielsen, Lean IT Kapitel 14 i Liker (2004, pp ) omhandler IT-understøttelse af Toyota Production System. Kapitlet omhandler det ottende ledelsesprincip (se Bilag 10.12). Hovedbudskabet er, at teknologi (herunder IT) kun skal indføres, hvis det skaber værdi (Liker, 2004; se pkt. 8 i Bilag 10.12). Dette synspunkt tilsvarer Cunningham & Jones (2007) første princip for anvendelse af Lean i IT-sammenhæng (se Bilag 10.14). Bell & Orzen argumenterer for, at The power of Lean IT includes knowing when not to use technology, because the vast majority of problems are caused by faulty processes, not people or technology. (Bell & Orzen, 2011, p. 70). Årsagen til dette er, at Over 80 percent of system downtime is self-inflicted, caused by people and process failures rather than technology failure. (Bell & Orzen, 2011, p. 156). Tilsvarende siger systemtænkningsperspektivet, at There is a better way to approach the use of IT. It goes like this: Understand and improve then ask if IT can further improve. (Seddon, 2005, p. 171). Teori Side 37 af 185

38 Som i alle andre Lean-sammenhænge (Liker, 2004; Modig & Åhlström, 2012; Ohno, 1988; Womack & Jones, 2003, m.fl.), tager Lean IT udgangspunkt i kundens perspektiv: Any Lean journey must begin with this simple question: What does the customer define as value? So from the IT organization s perspective, who is the customer? Bell & Orzen, 2011, p. 55 A company s value add always comes back to how it defines its customer Cunningham & Jones, 2007, p. 51 Limoncelli (1999) opstiller en model for systemadministratorers (IT-organisationens) håndtering af henvendelser fra brugere (kunder). Det er værd at understrege, i modsætning til Seddons (2008a) dumbing down of work beskrevet ovenfor, at der her er tale om IT-folk med mere indgående kendskab til håndtering af brugerhenvendelser (Limoncelli, 1999). Modellen omfatter fire faser, der hver er inddelt i et eller flere trin: Figur 4.7: Model for håndtering af brugerhenvendelser. Kilde: Egen tilvirkning efter Limoncelli, A. Modtagelse af kundens henvendelse B. Identificering af problemet C. Planlægning og udførsel af løsning D. Verificering af, at problemet er løst Fordelen ved en proces opdelt i trin er, at der kan indføres forbedringer ved at fokusere på hvert enkelt trin. Ligeledes kan processen anskues holistisk, idet der for hver overlevering af en procesenhed fra en person til en anden er risiko for fejl. Dette giver mulighed for at studere det samlede flow, eksempelvis hvis den samme bruger indrapporterer den samme fejl gentagne gange, eller hvis en fejl, der påvirker mange brugere, indrapporteres af mange på samme tid. Førstnævnte situation kan afhjælpes ved at instruere den Teori Side 38 af 185

39 pågældende bruger i korrekt brug af systemet, mens sidstnævnte kan afhjælpes ved en generel udmelding til samtlige brugere via eksempelvis en besked i telefonsystemet eller via en meddelelse på virksomhedens intranet (Limoncelli, 1999). Hovedsagen er, at der indføres en struktureret proces, som efterfølgende kan forbedres: The rule-of-thumb is that you first implement ITIL, and then use Lean tools to gain efficiencies. Williams & Duray, 2013, p. 170 Som Deming (1982) og Seddon (2005) dedikerer Limoncelli (1999) sig til den videnskabelige metode. Ved at følge modellen bliver arbejdet med processen mere struktureret: The process is something highly akin to the scientific process: observe, hypothesize, test, repeat. Limoncelli, 1999, p. 43 Desuden skaber processen mulighed for at foretage målinger af arbejdet, omend det kan være svært at udvikle målinger, der ikke fremelsker en forkert adfærd. Eksempelvis kan et mål om antal lukkede sager føre til fokus på at lukke sagen hurtigst muligt frem for at løse problemet (Limoncelli, 1999; se Tabel 10.4 i Bilag 10.9 nedenfor). Efterhånden som processen medvirker til en mere proaktiv adfærd med forebyggelse af problemer frem for symptombehandling, vil kompleksiteten i de indmeldte problemer stige, og tiden forbrugt på løsning af det enkelte problem vil tilsvarende stige. Et mål om hurtig løsningstid kan således være i konflikt med ønsket om øget proaktivitet (Limoncelli, 1999). Det er vigtigt at holde sig for øje, at modellen er iterativ. Hver fase består af et eller flere trin, som alle er vigtige at gennemføre. Hvis et eller flere trin springes over, fungerer processen ikke efter hensigten, hvilket kan føre til en dårlig kundeoplevelse. Limoncelli (1999) opstiller en liste over scenarier, hvor et trin springes over (se Limoncellis typer af systemadministratorer). Derimod kan det i en hvilken som helst fase vise sig nødvendigt at vende tilbage til en tidligere fase (ibid.). Henvendelse Første fase omfatter, at kunden tager kontakt til IT-organisationen. Dette kan ske på flere måder, afhængig af flere faktorer, herunder brugerens tekniske erfaring og henvendelsens kompleksitet. ITIL beskæftiger sig med begrebet Single Point of Contact, som er et fælles kontaktpunkt for alle henvendelser (Williams & Duray, 2013). Modtagelse af henvendelsen kan således ske enten af en person (via telefon eller ) eller via et selvbetjeningssystem: Teori Side 39 af 185

40 The Service Desk should be the request point except when self-service options are available. Williams & Duray, 2013, p. 155 Problemidentificering I anden fase kategoriseres problemet. Denne kategorisering kan ligeledes foretages manuelt af en person eller automatisk af et system. Her er mulighed for førstestadiefejl (Piercy & Rich, 2009a; b), hvor kundens ufuldstændige viden om årsagen til problemet kan føre til en fejlkategorisering. Hvis henvendelsen viser sig at være fejlkategoriseret, returneres til trin 1 (fase A) for en uddybende beskrivelse af fejlen, som den opleves af kunden. I denne forbindelse er det derfor vigtigt, for at forebygge fejl, at kunden altid får oplyst kategoriseringen (Limoncelli, 1999). Allerede i denne fase kan mange henvendelser afsluttes eller henvises til andre funktioner. En forespørgsel kan dreje sig om en ydelse, der ikke er omfattet, og må dermed henvises til den pågældende afdeling. Alternativt kan forespørgslen være i konflikt med en politik, og den må derfor afvises. Hvis brugeren er uenig, kan det føre til eskalering, og det er derfor vigtigt at have et klart defineret servicekatalog (Limoncelli, 1999). I trin 3 optages de nærmere detaljer omkring problemet. Dette gøres ofte af den samme person, som har modtaget og klassificeret henvendelsen, og pågældendes evne til at uddrage den nødvendige information fra brugeren er derfor afgørende. Problemrapporten skal være tilstrækkelig fyldestgørende til, at fejlen kan reproduceres og rettes, og det kan ikke forventes, at brugeren besidder den nødvendige viden til at kunne identificere al den information; vedkommende må derfor have hjælp. I tilfælde af en kompleks problemstilling, der ikke umiddelbart lader sig beskrive, kan det tit være til stor hjælp at benytte sig af telefonisk dialog frem for adskillige -meddelelser frem og tilbage. Det giver også medarbejderen mulighed for at stille uddybende tillægsspørgsmål undervejs. Uanset mediet er denne dialog vigtig, og den endelige problembeskrivelse skal meddeles brugeren. Ofte er modtageren af henvendelsen ikke den samme person, som senere løser problemet. Denne overdragelse stiller krav til, at fejlrapporten er så fyldestgørende som muligt (Limoncelli, 1999). Trin 4 er genskabelse af problemet. Hvis problemet ikke kan genskabes, kan det skyldes, at fejlbeskrivelsen ikke er tilstrækkelig. En anden årsag kan være, at fejlen kun optræder sporadisk, hvilket besværliggør (men ikke umuliggør) løsning af problemet. Det er vigtigt at dokumentere den metode, der er anvendt til at genskabe fejlen, til senere brug i trin 8 (verificering af løsningen). Testen kan med fordel indlejres i et script (Limoncelli, 1999). Afhængig af problemets kompleksitet kan det være tilstrækkeligt at konstatere fejlen i simple tilfælde, mens mere avancerede problemer kræver eksakt reproduktion af fejlen. Undervejs kan nye fejl vise sig, Teori Side 40 af 185

41 som ikke nødvendigvis relaterer sig til det aktuelle problem. Det er en afvejning, om undersøgelse af disse nye problemer kan betale sig, eller om de skal registreres med henblik på senere løsning (Limoncelli, 1999). Løsning Når problemet er identificeret, oplistes og planlægges mulige løsninger i tredje fase, og en løsning udvælges og anvendes. Dette trin udføres typisk af en systemansvarlig eller ekspert (Subject Matter Expert). I nogle tilfælde er løsningen åbenlys, mens der i andre tilfælde kan være adskillige årsager til problemet og således også flere forskellige mulige løsninger. Ofte er genskabelse af fejlen (fra forrige trin) en god metode til at identificere mulige løsninger (Limoncelli, 1999). Det er ikke altid ligegyldigt hvilken løsning, der vælges. Faktorer som omkostninger, tid og geografisk afstand spiller en rolle. Eksempelvis er en løsning, der kræver fysisk tilstedeværelse hos brugeren, typisk dyrere end en løsning, der kan udføres på afstand. Disse faktorer har indvirkning på de totale omkostninger (Total Cost of Ownership) ved ydelsen eller produktet. Hvis eksperten ikke kender nogen løsning på problemet, eskaleres fejlrapporten til en mere erfaren kollega eller til leverandøren af softwareløsningen (Limoncelli, 1999). I trin 6 udvælges en af de mulige løsninger med henblik på at fastslå, om den løser problemet. Dette udføres ligeledes af en ekspert. Som regel kan flere løsninger ikke udføres samtidigt, og skal derfor prioriteres. Dette bør ske i samråd med brugeren af hensyn til vedkommendes tid. Hvis der er tale om en kritisk, driftsstoppende fejl, er behovet for en hurtig løsning større end ved fejl, der ikke kræver en umiddelbar løsning på stedet. Hvis fejlen kan afhjælpes i øjeblikket, er det bedre at planlægge en tilbundsgående løsning af problemet på et tidspunkt, hvor det ikke vil forstyrre brugerens arbejde (Limoncelli, 1999). Det er værdifuldt at inddrage brugeren i denne fase. Hvis der er tale om en erfaren bruger, kan vedkommende give brugbar feedback. Selvom der er tale om en uerfaren bruger, kan involveringen bidrage til at nedbryde barrieren mellem brugerne og dem i IT-afdelingen (Limoncelli, 1999). Den valgte løsning appliceres i trin 7. Dette kan udføres af den systemansvarlige, men det kan også være andre, eksempelvis en tekniker eller en Service Desk-medarbejder, der forestår selve udførelsen. Den udførende rolle kan tilmed spilles af brugeren selv, hvis vedkommende har fået anvist løsningen. Dette gør sig specielt gældende, hvis brugeren fysisk befinder sig et andet sted. I dette tilfælde er dialogen mellem systemansvarlig og bruger særligt vigtig for at sikre, at løsningen udføres korrekt. Den systemansvarliges evne til at kommunikere passende med brugeren svarende til vedkommendes evner og erfaring er i denne sammenhæng afgørende (Limoncelli, 1999). Verificering Sidste fase omfatter verificering af, at den udførte løsning har afhjulpet problemet. Den person, der har udført løsningen, undersøger, om problemet er løst. Hvis genskabelsen af problemet ikke er udført korrekt, Teori Side 41 af 185

42 er der risiko for, at problemet ikke er løst. Fejlen kan stadig være uløst, omend dette ikke opdages under verificeringen. Dette understreger modellens iterative element, idet en tilbagevenden til et tidligere trin således er nødvendig (Limoncelli, 1999). I niende og sidste trin verificerer brugeren selv, om problemet er løst. Selvom dette ikke skulle synes nødvendigt, forudsat at trin 8 er udført korrekt, er det ofte i dette sidste trin, at brugeren opdager, at fejlen endnu ikke er løst. Brugerens verificering kan afsløre fejl begået i en tidligere fase. Specielt kommunikationsproblemer, hvor brugeren ikke er i stand til at beskrive problemet fyldestgørende, eller eksperten ikke forstår brugeren, kan føre til, at den fejl, der blev verificeret i fase 4, er en anden fejl end den, brugeren oplever. Løsningen kan således have afhjulpet denne anden fejl, uden at brugeren får løst sit problem. Igen kan det vise sig nødvendigt at vende tilbage til tidligere trin (Limoncelli, 1999). Forbedring af processen For at sikre, at eksperten opbygger et indgående kendskab til brugernes behov, og for at undgå, at en bruger kommer til at tale med en ny person ved hver kontakt, kan eksperter grupperes i teams, der koncentrerer sig om et forretningsområde, frem for at koncentrere sig om teknologiområder (Limoncelli, 1999). Omvendt er en bruger, der bedre forstår IT-eksperternes arbejdsform med de ni trin, potentielt en bedre kunde, idet vedkommende kan være bedre forberedt ved indrapportering af en fejl. De forstår vigtigheden af at indsamle så megen information som muligt, og arbejdet med at indsamle denne information kan endda føre til, at brugeren selv kan løse problemet (ibid.). Det er nødvendigt for en smidig gennemførsel af processen, at den person, der klassificerer et problem (i trin 3) er i besiddelse af tilstrækkelig viden om hvilke typer af problemer, der skal løses af hvilke eksperter. Desuden skal pågældende være i stand til at indsamle tilstrækkelig information fra brugeren, som denne ikke selv måtte levere i første omgang. En liste over standardspørgsmål for hver klassificering kan være behjælpelig i denne sammenhæng. Endelig kan arkitektur spille en rolle, idet den stigende kompleksitet i softwareløsninger fører til blandt andet inddeling af systemer i flere lag. Det kan være svært at afgøre, i hvilket lag årsagen til et problem skal findes, og den enkelte ekspert skal derfor have indgående kendskab til alle områder (Limoncelli, 1999). 4.5 Analysemodel Den gennemgåede litteratur har indtil nu anført vigtigheden og anvendeligheden af en række teoretiske begreber, som kort opridses i det følgende. På denne baggrund foreslås en model, som efterfølgende vil blive anvendt i analysen. Værdi Teori Side 42 af 185

43 Organisationens eksistensberettigelse og fornemste opgave er at efterleve kundernes behov. Kunden er i nærværende sammenhæng brugere, der henvender sig til IT-organisationen for at få løst et problem eller få svar på en forespørgsel. Derfor er formålet at identificere, hvor stor en andel af kundehenvendelserne der skaber værdi (value demand). Spild De kundehenvendelser, der ikke tilfører værdi (failure demand), er spild. Systemet skal derfor indrettes således, at dette spild elimineres. Her er typisk tale om opfølgning på, hvor langt en sag er nået (progress chasing), eller rykning for en løsning, der ikke er leveret rettidigt eller som lovet. Flow I modsætning til den traditionelle masseproduktionstankegang, der fokuserer på effektiv udnyttelse af ressourcer, skal arbejdet indrettes med fokus på flow-enheden. Dette medfører, at en kunde skal kunne henvende sig og i videst muligt omfang få løst sit problem i første ombæring, (fokus på flow-enheden), frem for en effektiv udnyttelse af specialistressourcer (fokus på ressourceudnyttelse), der til gengæld medfører unødig ventetid (spild) for kunden. Således skal arbejdet organiseres i flow, hvor en enhed behandles ad gangen gennem samtlige aktiviteter i processen: To the extent that business operations are dependent on repeatable, reliable IT service delivery, a process organization and culture are required. Although technical skills will always be required, the optimized process-based organization is horizontally focused on outcomes, not vertically oriented around skills. Bell & Orzen, 2011, p. 154 Mål Traditionelle, ressourcebaserede mål om eksempelvis svartider på telefoniske henvendelser medfører, at indsatsen fokuseres på opfyldelse af målet i sig selv snarere end efterlevelse af kundens efterspørgsel. I stedet skal der indføres kapabilitetsmål, der fokuserer på evnen til fuldstændigt at besvare kundernes henvendelser, skaber mulighed for løbende at forbedre indsatsen og gør medarbejderne i stand til at forbedre arbejdsprocessen for at udvide kapabiliteten. Den videnskabelige metode Alle forbedringstiltag skal ske i henhold til den videnskabelige metode. Teori Side 43 af 185

44 Formålet med arbejdet skal være klart og i henhold til en standardiseret proces: The work process itself, along with the management process, must be absolutely standardized by managers, and by manufacturing and industrial engineers as well, before a work team can have any hope of improving it. Standardization in this context means creating a precise and commonly understood way to conduct every essential step in every process. Womack, Jones & Roos, 2007, p. 290 Analysemodel På baggrund af Seddon (2005) og ovenstående opsummering opstilles nedenstående model (Figur 4.8) med følgende seks trin til anskuelse af virksomhedens formål fra kundens synsvinkel: 1. Fastslå formålet med virksomheden set fra kundens synsvinkel. Hvor godt præsterer systemet? Hvad er systemets evne til at nå sine mål? 2. Indtegn resultaterne med øvre og nedre kontrolgrænser, og undersøg årsager til forekomster, der befinder sig væsentligt uden for grænserne. Er der gode forklaringer på afvigelserne, eller er de et tegn på ustabilitet i systemet? 3. Hvad er de adfærdsmæssige drivere for opnåelsen af målene? Er disse drivere afstemt formålet om efterlevelse af kundens efterspørgsel? 4. Er der synlige tegn på pludselige ændringer i systemet? Hvad er årsagerne til disse ændringer? 5. Hvor godt præsterer systemet? Hvad er fordelingen mellem værdiskabende og ikke-værdiskabende efterspørgsel? 6. Redesign arbejdet til at skabe værdi og opfylde formålet Teori Side 44 af 185

45 Figur 4.8: Model for redesign af formål fra kundens synsvinkel. Kilde: Egen tilvirkning efter Seddon, I første trin af analysemodellen (Figur 4.8) revurderes formålet med virksomheden, dens eksistensberettigelse, fra kundens synspunkt. Dette trin omfatter en indledende vurdering af systemets præstation. Trin 2 undersøger tilfælde, hvor processen ikke forløber, som den skal, og hvad årsagerne til afvigelserne kunne være. Tredje trin beskæftiger sig med, hvad der skal til for at drive den rette adfærd for opfyldelsen af målene. Herefter identificeres ændringer og årsager til disse i trin 4. Næste skridt er endnu en vurdering i trin 5 af, hvor godt systemet præsterer, og gennemløbet af modellen afsluttes i trin 6 ved at redesigne arbejdet, så det bedre er i stand til at opfylde målene. Modellen indeholder et iterativt element, idet trin 1 afsluttes med en mellemfase, hvor præstationen vurderes. Denne vurdering gentages i trin 5. Ligeledes kan der i modellens forløb returneres til tidligere trin med henblik på yderligere forbedringstiltag. Eksempelvis kan der returneres til slutningen af trin 1 efter redesign af arbejdet i trin 6, eller dette kan ske allerede efter trin 3, afhængig af antallet af iterationer og de resultater, der er opnået undervejs. Teori Side 45 af 185

46 5 Analyse I det følgende gennemgås de enkelte trin i analysemodellen (Figur 4.8), men indledningsvis er det værd at genopfriske, at der er tale om IT-organisationen internt i virksomheden. Det vil sige, at kunderne i denne forstand ikke er virksomhedens slutkunder, men derimod interne medarbejdere, der benytter sig af ITorganisationens tjenesteydelser. Slutkunderne benævnes i denne sammenhæng forbrugere. 5.1 Formål IT-organisationen agerer i dag alt for reaktivt, og fokus burde i langt højere grad være på prævention og at få rettet tingene (Larsen, 2013). Første prioritet er at løse de akutte problemer, der er opstået i løbet af morgenen. Herefter kan vi begynde at koncentrere os om de ting, som er mindre akutte (Larsen, 2013). Arbejdet indebærer således en klar prioritering: hvad der er akut, det er akut, det skal laves først. Altså, vi skal opretholde en drift som resten af firmaet nyder godt af (Larsen, 2013). Det er nødvendigt at afveje det interne arbejde med forretningens behov. IT-systemerne er ofte lukket i weekenderne grundet vedligehold, men hvis forretningen planlægger overarbejde, er det nødvendigt, at ITorganisationen planlægger udenom. Med andre ord må IT, som en støttefunktion til virksomhedens kerneprocesser, ikke suboptimere og arbejde udelukkende efter egne mål uden at tage hensyn til, at det vigtigste for virksomheden overordnet er, at forretningen, det vil sige kerneprocesserne, kan fungere. Processen omkring idriftsættelse, det vil sige ibrugtagning, af ny teknologi eller nye IT-systemer skal således indrettes efter, hvornår det passer bedst ind i de overordnede planer, hvis arbejdet med eksempelvis opgradering af et system karambolerer med kerneprocessernes arbejde. IT-funktionen er derfor nødt til at kende de strategiske og taktiske mål, og det er nødvendigt at vide, hvad der er vigtigt for forretningen. Ligeledes er det nødvendigt at vide, hvad der er vigtigt, når der opstår problemer. Hvis forretningen planlægger udsendelse af en brevkampagne eller en udbetalingskørsel, og der opstår fejl i de understøttende systemer i samme periode, er disse fejl naturligvis vigtigere at håndtere end andre, der måtte opstå samtidig. IT-organisationen skal formidle til brugerne, hvad de kan forvente. Når brugere henvender sig til Service Desk, oplever de i vid udstrækning, at der mangler dialog (Ludvigsen & Borring, 2013; Bisbo & Nicolaisen, 2013). Efter henvendelsen bliver der som regel hurtigt sendt en bekræftelse på, at sagen er modtaget, men efterfølgende får brugeren ofte ingen anden information, før sagen lukkes. Det er således umuligt at vide, hvad der kan forventes. Der mangler information om, hvornår sagen påbegyndes og hvor længe, der kan forventes at gå, før den er løst. Analyse Side 46 af 185

47 Ofte må brugerne selv henvende sig igen, for at få oplyst status i sagen (Ludvigsen & Borring, 2013). Det er ikke nødvendigt at kende hele sagsforløbet inde bagved, men det er til stor frustration ikke at få noget at vide: Der mangler tilbagemelding om status i sagen; både løbende, men også endelig. Du får kun automatisk den her, at nu er din sag lukket, men som slutbruger står der ikke nogen begrundelse i den , og hvis ikke du har adgang til Remedysystemet, så får du ikke begrundelsen, så kan du bare se, at sagen er lukket, men du har ingen ide om hvorfor. Bisbo og Nicolaisen, 2013 Mange brugere oplever (Ludvigsen & Borring, 2013; Bisbo & Nicolaisen, 2013), at de end ikke ved, om der overhovedet bliver gjort noget ved de sager, de melder ind, eller om de blot er modtaget, og der er sendt en bekræftelse på dette: Det skal ind via de rigtige kanaler, og jeg har en idé om, at NNIT bliver målt på, at de skal have svaret et eller andet autosvar eller et eller andet inden for x-antal tid. Jeg håber ikke, det er den der autosvar, de bliver målt på. Ludvigsen & Borring, 2013 Det betyder, at det bliver nødvendigt for brugeren selv at ringe for at spørge til status (Ludvigsen & Borring, 2013). Ligeledes oplever brugerne, at der ikke bliver taget højde for, at en situation kan være kritisk eller nødvendig at få løst hurtigt (Ludvigsen & Borring, 2013; Bisbo & Nicolaisen, 2013). Der er mulighed for at indmelde sager i fire kritikalitetsniveauer, low, medium, high og emergency, men uanset hvad, brugerne skriver i fejlmeldingen, oplever de, at sagerne bliver oprettet med lav prioritet. Dette kan i hastetilfælde medføre, at der ikke er den nødvendige opmærksomhed på sagen for at få den løst hurtigt. Mange fejl indmeldes på baggrund af henvendelser fra forbrugerne. I disse tilfælde er rådgiverne afhængige af at få et svar, når et problem er løst, fordi de efterfølgende skal vende tilbage til forbrugeren med et svar (Bisbo & Nicolaisen, 2013). Systemet fungerer i dag ud fra et funktionelt perspektiv, hvor fokus er på at lukke sagen (Limoncellis Closer, se Tabel 10.4) eller ekspedere den videre inden for tidsfristen (præstationsmål, Seddon, 2005) frem for at arbejde efter, om kunden har fået løst sit problem (kapabilitetsmål, Seddon, 2005). Analyse Side 47 af 185

48 Det er det generelle, at vi har et problem med forventningsafstemningen; at man ikke har nogen som helst ide om, hvornår kan jeg forvente, at det her er løst, og er der overhovedet nogen i gang med at kigge på det. Bisbo og Nicolaisen, 2013 Der er meget stor forskel på, hvem der sidder i Service Desk den pågældende dag, når brugere melder fejl ind (Bisbo & Nicolaisen, 2013). Mange af Service Desk-medarbejderne kender ikke PenSam og er ikke vant til at hjælpe med de konkrete problemstillinger, brugerne har (ibid.).: Jeg burde ikke som bruger opleve så stor en forskel på, hvem der sidder i den anden ende. Det synes jeg, der er. Det synes jeg, har været det største og er fortsat det største problem. Bisbo og Nicolaisen, Hvor går det galt? Mange fejl opstår uventet, og det kræver mange ressourcer at håndtere dem. Det medfører, at der bruges uforholdsmæssigt meget tid på en reaktiv adfærd, hvor fejl løses, når de opstår, frem for proaktiv forebyggelse af fejl, hvor de løses en gang for alle, så de ikke opstår igen: Vi er lidt proaktive og meget reaktive i den forstand med Remedy-sager. Vi lider under, at der kommer voldsomt mange fejl, og de samme fejl kommer flere gange, og vi har ikke nogen mulighed for at få dem rettet umiddelbart. Larsen, 2013 De specialister, der besidder de nødvendige kompetencer til at kunne grave sig dybere ned i problemerne, har begrænset tid til arbejdet, fordi der hele tiden opstår så mange fejl (Ludvigsen & Borring, 2013). Desuden er der en lang række andre forhold (Larsen, 2013), der forbruger tid, eksempelvis tid forbrugt på møder (Larsen, 2013; Ludvigsen & Borring, 2013). For at kunne løse problemer tilbundsgående, er der behov for tid til at analysere nærmere på fejlen og om nødvendigt drøfte situationen med udviklere eller leverandører, men der ser jeg, det er den tid, der bliver spist (Larsen, 2013). Derfor er der heller ikke tid til at procesudvikle og dermed skabe mere tid (ibid.). Konsekvensen er, at de samme problemstillinger opstår igen og igen. En bruger har oplevet, at den samme sag har kørt 15 gange siden februar måned (Ludvigsen & Borring, 2013) og mener ikke, at det ikke burde være så kompliceret at gøre det igen, når jeg melder fejlen ind og refererer til et tidligere Remedy-nummer, for at man hurtigere kan fejlfinde og løse det her problem (ibid.). Hver gang bliver sagen betragtet som et nyt problem. Der mangler opsamling på, om de samme problemer gentager sig (Ludvigsen & Borring, 2013). Analyse Side 48 af 185

49 Det er den her, som jeg hele tiden melder ind på, og fordi den er opstået rigtig, rigtig tit, så er jeg jo sådan rimelig sur over, at jeg ikke kan se, at der sker noget på området. Ludvigsen & Borring, 2013 Det medfører, at situationen ikke bliver aflastet, fordi der hele tiden kommer nye ting til (Larsen, 2013). Hver fejl, der dukker op, som ikke bliver løst, men blot afhjulpet, gør krav på en del af den tid, der skal bruges på at løse problemerne en gang for alle. Hvis der så kommer et nyt til lad os bare sige en gang hver anden uge i seks måneder - så er der ikke meget tid tilbage efter seks måneder (Larsen, 2013). Det kan også være andre ting, som man simpelthen ikke har nået at kigge på den dag, de er kommet ind. Så har man lige pludselig en oprydning af Remedy-sager fra hele sidste uge for eksempel. De små sager, som man siger, Hvad skete der egentlig her? Var der nogen som fik undersøgt det? Larsen, 2013 Nogle processer forløber ikke optimalt, fordi de ikke er beskrevet., Dermed er brugerne ikke orienteret om, hvad de kan forvente (Damgaard, 2013). En hyppig kilde til fejl er idriftsættelse af en opgradering eller et nyt IT-system. Break-fix-tankegangen (Bell & Orzen, 2011; Seddon, 2005), hvor problemer løses, som de opstår, er forårsaget af en utilstrækkelig proces for håndtering af disse idriftsættelser (Damgaard, 2013; Larsen, 2013). Godt nok er den akutte fejl løst, men den langsigtede løsning på problemet skal også findes og implementeres, og det er mange gange her, det går galt: Det kan godt være, vi har forslag til, hvordan man kan løse tingene, men det er ikke altid, at det er noget, som nogen synes, man skal bruge penge på på nuværende tidspunkt (Larsen, 2013). Når der opstår fejl, som kræver en løsning i udviklingsregi, har udviklingsprojekterne tit ingen ledig kapacitet til at udvide omfanget. Lange projektforløb medfører således, at der går lang tid med at håndbære en omgåelse af et problem, selvom løsningen er fundet, enten fordi der ikke er tid til at udvikle løsningen, eller fordi der er lang tid, til løsningen kan idriftsættes (Larsen, 2013).. For så vidt angår Incident, Problem og Service Request er processerne beskrevet. Det vil sige at brugerne kan åbne beskrivelsen og se hvilke servicemål, der ligger der. Forespørgsler om ændringsønsker er markant anderledes, fordi det ikke er beskrevet Hele processen fra en opgave bliver født, til den bliver til en idriftsættelse, er ikke beskrevet. Det betyder, at en bruger i PenSam kan melde et ændringsønske ind til et system, men mangler en masse information: hvad kan jeg forvente, når jeg har afleveret mit ønske? Hvornår får jeg svar tilbage? Hvor lang tid går der, før det bliver løst? Bliver det måske prioriteret ikke-løst?" Det kan godt være, brugeren får besked tilbage, men vi er ikke i stand til at orientere brugeren om "hvad kan jeg forvente, når jeg har indmeldt en sag?" Det kan skabe noget frustration (Damgaard, 2013). Analyse Side 49 af 185

50 Konsekvensen kan være, at en sag ikke bliver løst, eller at kommunikationen mellem forskellige aktører ikke er tilstrækkelig, så det arbejde, den ene har brugt tid på at udføre, starter den anden forfra på, fordi fremgangsmåden ikke fremgår af beskrivelsen og løsningen af opgaven. På den måde mangler der en struktureret fejlsøgningsprocedure (Damgaard, 2013). Jeg synes, vi har en udfordring i, at alle vores processer ikke nødvendigvis er beskrevet. Det giver en stor risiko for, at opgaverne ikke bliver løst til den aftalte tid, pris eller servicemål Damgaard, 2013 Brugerne oplever (Ludvigsen & Borring, 2013), at Service Desk er hurtige til at sende en bekræftelse, når de har indmeldt en sag, men i de fleste tilfælde gør Service Desk intet andet end at oprette en sag og lægge den tilbage til PenSam (Bisbo & Nicolaisen, 2013). Problemet indfinder sig, når brugeren ikke får nogen tilbagemelding på sin sag. Konsekvensen er, at brugerne begynder at skrive direkte til specialister i PenSams IT-funktion, de tror, kender noget til problemet (Ludvigsen & Borring, 2013). Dette starter endnu en dødsspiral, fordi disse specialister så får endnu mere at se til (ibid.). Situationen forværres yderligere af, at de enkelte funktionelle områder tit er forbundne med specifik viden og derfor personafhængige (Ludvigsen & Borring, 2013). Ligeledes begynder brugerne at eskalere problemerne for at få dem løst hurtigere (ibid.). Situationen med de mange fejl bliver endnu mere frustrerende, når det skal involvere NNIT, der måske ikke helt har forstået, hvad problemet er. Medarbejdere internt i PenSam, som kendte systemerne og de problematikker, der er i huset og i systemerne, ville lette sagsgangen, fordi det ikke hver gang er nødvendigt at forklare (Ludvigsen & Borring, 2013). En sag, som opstår femten gange inden for to måneder, burde være løst på kort tid, eftersom det blot er at trykke på knappen ligesom sidste gang. Det afhjælper det akutte problem, og skal gøres øjeblikkeligt. Derudover er det nødvendigt, at der sideløbende bliver fulgt op årsagen til, at den samme fejl opstår så mange gange, med henblik på at finde roden til problemet og løse det, så fejlen ikke opstår igen. Det kan jeg slet ikke forstå, man ikke gør (Ludvigsen & Borring, 2013). Det er et problem, at den enkelte bruger selv skal prioritere de sager, de melder ind, for hvordan vurderer den enkelte person et problem i mængden, uden at have overblik over, hvad der ellers er meldt ind. Brugere melder altid sager ind, fordi de synes, det er vigtigt. Alle sager, brugerne indmelder til Service Desk, får prioriteten low, og de fleste bliver derefter sendt videre til PenSams interne IT-funktion (Ludvigsen & Borring, 2013). Implikationen er, at brugerne ikke ved, hvad de kan forvente (Ludvigsen & Borring, 2013). Hvis der er tale om en mindre fejl, der ikke er så kritisk at få løst her og nu, er det ikke afgørende, at den har været nogle dage undervejs gennem systemet, men hvis der opstår en større fejl, hvor eksempelvis et centralt system er nede, som påvirker mange brugeres arbejde, så skal der være en alarmklokke, som gør, Analyse Side 50 af 185

51 at sagen ikke går i stå, fordi de ansvarlige sidder i møde eller er optaget af andre ting, så sagen strander (Bisbo & Nicolaisen, 2013). Det giver dobbeltarbejde, at den samme fejl når at blive oprettet flere gange (Bisbo & Nicolaisen, 2013). Det er et problem, så snart der er mange led. Når sagerne skal gennem så mange led, og de risikerer at vente længe hvert sted, går der for lang tid, inden de kommer igennem fra brugeren til den, der skal løse problemet. (Bisbo & Nicolaisen, 2013). Noget andet er også, at udviklerne har svært ved, hvordan de skal prioritere, fordi de tit er allokeret til projekter. Hvordan skal og må udviklerne prioritere driftsfejl i forhold til andre opgaver? I og med, at fejlene kommer med prioriteten low, så får de lov at ligge (Bisbo & Nicolaisen, 2013). Ud over en beslutning om, at der skal ske en tilbagemelding til slutbrugeren, bør det også kunne forventes, at der som minimum skal være en udvikler, der har analyseret fejlen inden for en given tidsramme og taget stilling til, hvad skal der ske for at løse den. Mange fejl kommer videre til udviklere, som skal prioritere den tid, de bruger på driftsfejl kontra udvikling. De er typisk allokeret til nogle projekter, der har med noget helt andet at gøre (Bisbo & Nicolaisen, 2013). Ligeledes er det svært at gennemskue, hvornår der skelnes mellem på den ene side en Service Request, hvor brugeren eller afdelingen selv skal betale særskilt for ydelsen og derfor vurdere, hvad der skal prioriteres op, og på den anden side Incidents, hvor betalingen er omfattet af vederlaget. Det kan være af afgørende betydning for prioriteringen, om der skal betales for en ydelse, eller om den er inkluderet (Ludvigsen & Borring, 2013). Når en fejl opstår, er det vigtigt for brugerne, at der er information tilgængelig om fejlens årsag, konsekvens og forventede varighed (Bisbo & Nicolaisen, 2013). I den forbindelse kommer denne udmelding ofte for sent, hvilket medfører, at mange brugere parallelt når at indmelde deres oplevelse af, hvad der senere kan vise sig at være den samme fejl (ibid.). Dette skaber ekstra arbejde for de personer, der skal modtage og klassificere henvendelserne. En hurtigere og mere proaktiv udmelding, så snart en fejl er identificeret, vil således lette arbejdet for både brugere og IT-folk (Limoncelli, 1999). En yderligere udfordring i denne sammenhæng er, at brugerne ikke nødvendigvis ved, hvor de skal søge denne information, og at de skal foretage sig noget aktivt for at modtage den (Bisbo & Nicolaisen, 2013). Således ville det være en fordel, hvis informationen kunne leveres til brugerne automatisk (ibid.). Desuden bør flere fejlmeldinger på det samme problem behandles allerede i det modtagende led (Limoncelli, 1999; Piercy & Rich, 2009a; b). Hvis Service Desk kunne samle lignende henvendelser under én sag, kunne der ved gentagne henvendelser fra brugere om det samme problem henvises til denne ene sag (Bisbo & Nicolaisen, 2013). På den måde undgås ligeledes unødige dobbeltsager længere fremme i værdikæden (ibid.). Analyse Side 51 af 185

52 Mange fejl venter længe på at blive løst. Problemet er, at for rådgiverne er det en enormt dårlig oplevelse, at den hele tiden enten er meget længe om at svare eller slet ikke svarer. Så kan det godt være, den så virker igen om en halv time, men det er bare meget utilfredsstillende, når man sidder med kunder i røret, at den ikke virker. Så det kunne være rart, at der var højere attention på at finde ud af, hvad er det, der gør, at den hele tiden går ned. Bisbo & Nicolaisen, 2013 I sidste ende er risikoen, at brugerne ophører med at fejlmelde, når der opstår problemer, fordi de oplever, at der alligevel ikke er opmærksomhed på det. Det er risikabelt, idet det i så fald er svært at danne sig et reelt billede af fejlsituationen (Bisbo & Nicolaisen, 2013). Derfor bør der gøres meget ud af at opfordre brugerne til at indmelde alle fejl, og det skal være hurtigt og nemt både at fejlmelde og at søge og finde information om den nuværende situation hvad findes der i øjeblikket af kendte fejl, og hvornår forventes de løst eller afhjulpet (ibid.). Resultatet bliver, at alle stadig står med det samme problem. (Bisbo & Nicolaisen, 2013). 5.3 Drivere for målopfyldelse Målsætningen om behandling af en sag inden for et antal dage medfører opportunistisk udnyttelse af processen,i og med at en sag bliver sat i venteposition, fordi der ikke er tid til at løse den. På denne måde undgås, at sagen overskrider KPI-målet, men problemet er, at det ikke er ensbetydende med, at sagen er løst (Larsen, 2013). I systemtænkningsperspektivet er denne adfærd et typisk eksempel på, at disse KPI-mål opfordrer medarbejderne til at modarbejde systemet. Fokus burde i stedet være på at få løst sagen, så kundens behov er opfyldt (Seddon, 2005). Årsagen til denne adfærd er, at der er for lidt tid til at løse alle de problemer, der opstår (Larsen, 2013). Implikationen er, at mange sager bliver sat på hold og først løst på ubestemt tid, når der er tid til det (Larsen, 2013). Ikke alle problemer, der opstår, kan løses umiddelbart. I sådanne situationer er der to muligheder. Enten lægges sagen i venteposition, indtil der er tid til at løse den (Larsen, 2013). Alternativt bruges den tid, der er nødvendig for at få løst problemet her og nu, men det vil ske på bekostning af andre sager, der skubbes foran (Larsen, 2013). Det er altid et problem at finde ressourcer. Der er behov for at finde en ressource ud af det blå, som ikke er prioriteret, som ikke har afsat tid til den opgave, der er opstået uden for projektregi. Det er prioriteret, at projekterne har de ressourcer, de skal bruge. Derudover er der afsat noget tid til driftsfejl, men det er sjældent tilstrækkeligt (Larsen, 2013). Adfærden omkring håndteringen af processerne er for snæversynet (Damgaard, 2013). Fokus kommer til at ligge på at sende sagen videre, men det er ikke i den enkeltes interesse at videreformidle, hvad der er sket i sagen, og hvorfor den bliver videregivet, og det kan trække sagerne unødigt i langdrag (ibid.). Analyse Side 52 af 185

53 Den bedste løsning ville være at indføre et servicekatalog, hvoraf de enkelte ydelser fremgår, hvorimod det i procesbeskrivelsen er forløbet, der er beskrevet. Således ville servicekataloget være et godt supplement til procesbeskrivelsen. Procesbeskrivelsen beskriver, hvad der kan forventes af leveringstider, responstider, og hvad der sker, når en sag er løst eller ikke løst og hvis den skifter prioriteret (Damgaard, 2013). Brugerne ved ikke, om de får besked. De kan ikke læse noget sted om, hvad de kan forvente, om de får en kvittering for modtagelsen af opgaven, hvornår den vil blive estimeret, hvor meget den koster at få løst, og om den overhovedet bliver løst, eller man har valgt at nedprioritere og annullere den forespørgsel. Jeg tror, hvis man snakker brugertilfredshed med slutbrugerne, så er forventningsafstemning en hovedingrediens til tilfredshed (Damgaard, 2013). Det kan være rigtigt svært for folk at tænke i processer. Det kræver en bestemt profil, så det afhænger af, hvem der er procesansvarlig. De mennesker, som i PenSam er udpeget som procesansvarlige, er forskellige profiler - nogle er mere proces-minded end andre, og de, der er mindst proces-minded, har også svært ved med det samme at konkludere, at det er processen, der skal arbejdes med. De går mere efter at få løst den konkrete sag, så den er ude af verden. Det kommer ikke naturligt til dem at tænke, om der er noget generelt, som gør, at den pågældende type fejl opstår, eller om noget lignende procesmæssigt er set før. Det kræver en bestemt personprofil at tænke sådan (Damgaard, 2013). Hvis en fejl er for længe om at blive løst, vil den ofte blive eskaleret. De, der ikke tænker i processer, går hen på den anden side af gangen til en kollega, som er specialist, og vedkommende om at hjælpe med at få løst den konkrete sag. Så får man løst selve fejlen, men de får ikke kigget på årsagen til, det tog så lang tid, og hvor i processen kæden hoppede af: Der oplever jeg en forskel i de personer i PenSam, som er procesansvarlige, de har forskellige profiler, og nogle er bedre til at tænke procesorienteret end andre (Damgaard, 2013). Formålet med at arbejde efter en struktureret proces er at arbejde ensartet og effektivt uanset hvem, der løser opgaven. Hvis alle arbejder ensartet og dermed mere effektivt, og der alligevel sker noget, hvor proceduren ikke har været fulgt, ville det, der skulle til for at få tingene på sporet igen, være at genopfriske processen hos vedkommende. Det er det, der er problemet med, at processerne ikke er implementeret blandt aktørerne. Der er for mange episoder, hvor folk gør tingene på deres egen måde, og dermed ikke ensartet og effektivt. Hvis alle kender processen og arbejder efter den, så ville man også kunne overdrage til andre og dermed ikke være personafhængig. Nøgleordene er ensartethed og dermed effektivitet (Damgaard, 2013). De enkelte aktører kan have en procedurebeskrivelse for, hvordan hver opgave udføres, og hvilke aktiviteter den enkelte proces omfatter. På den måde kan en procesbeskrivelse suppleres med procedurebeskrivelser. Når en procedure er udført, vendes tilbage til procesbeskrivelsen, der angiver, hvad der efterfølgende skal ske i processen. På den måde kan en proces suppleres med en procedurebeskrivelse inden for det enkelte speciale (Damgaard, 2013). Analyse Side 53 af 185

54 Hvis udviklerne bare lukker den og siger "nu har jeg løst den, altså lukker jeg den", men den måske først kommer i drift om fire måneder, så er det jo også vigtigt, man får kommunikeret det til slutbrugeren, at godt nok er den løst udviklingsmæssigt, men der går altså fire måneder, før du kan se det. Bisbo og Nicolaisen, Indikatorer for forandring Det er et grundlæggende princip, at hvis de opgaver, der ligger i IT-regi, kan automatiseres, skal det gøres (Larsen, 2013), så det ikke er nødvendigt at håndholde det (jidoka, Figur 2.1; Liker, 2004). Når der opstår fejl, som gør, arbejdet ikke kører automatisk, er det nødvendigt at foretage kompenserende handlinger, hvor man håndholder det, der ikke fungerer eller ikke er blevet automatiseret (Larsen, 2013). Problemet med det er, at tiden går fra de tiltag, specialisterne burde beskæftige sig med, nemlig at videreudvikle processer og automatiserede løsninger for at frigive mere tid (Larsen, 2013). Der går meget tid med at få gennemført rettelser, fordi der ikke er nogen systemmæssig understøttelse af idriftsættelsesprocessen. Processen forløber manuelt og afhænger af, at alle led undervejs i kæden gør de rigtige ting i den rigtige rækkefølge uden at begå fejl. Processen bør understøttes af et workflow-system (Larsen, 2013). Der mangler dokumenthåndtering og procesunderstøttelse af de opgaver, der udføres i IT-regi: Der mangler simpelthen en central processtrategi og procesunderstøttelse i hele IT. Larsen, 2013 Den umiddelbare konsekvens er, at den samme fejl opstår flere gange. Nogle gange er det på forhånd til at forudsige, og andre gange kommer fejlen igen med tilfældigt mellemrum. Det medfører, at den samme fejlrettelse eller kompenserende handling er nødvendig at udføre igen og igen, indtil der er fundet tid til dels at få undersøgt årsagen til fejlen tilbundsgående, men endnu værre er det, at den samme kompenserende handling skal udføres, indtil en permanent løsning på problemet er idriftsat. Det er typisk dette led, der tager længst tid (Larsen, 2013). I samarbejdet med leverandøren, for så vidt angår Problem Management, fungerer processen tilfredsstillende, men der er det udestående, at brugerne i forretningen - når de har indmeldt noget - ikke nødvendigvis får en tilbagemelding på, hvad de kan forvente med den lidt mere langvarige fejl, de har meldt ind. Det er nødvendigt at undersøge, hvordan implementeringsaktiviteterne har været, og om der har været tilstrækkelig involvering af brugerne af Problem-processen. For at processen skal fungere, kræver det, at alle aktører, som indgår i processen, både rekvirenten og de, der skal udføre opgaverne, har en helhedsforståelse for, hvad en proces indebærer (Damgaard, 2013). Hvis et led i kæden hopper af, har det en konsekvens for alle de andre aktører. Implementeringsaktiviteterne er noget af det, der skal evalueres oftest, for at Analyse Side 54 af 185

55 vedligeholde en fungerende proces. Oftest giver det sig til udtryk i, at aktørerne ikke følger den proces, der er beskrevet, så processen ikke får en chance for at vise sit værd. Det kan enten skyldes, at aktørerne ikke husker at følge processen, eller ikke har mulighed for at følge processen (Damgaard, 2013). Det gælder for alle processer, at hvis man skal lave procesforbedringer og procesevalueringer, så skal man hele hjulet rundt. Er det designet rigtigt? Er det implementeret rigtigt? Gør folk det, der står? (Damgaard, 2013) Der er ansvarsplaceret på begge sider, både hos PenSam og hos NNIT, et procesejerskab, og den procesejer er den primære kontaktperson, som varetager processens beskrivelse, implementering, formalitet, sundhed og opfølgning. Det giver skarpe grænseflader, som gør, at det altid er den pågældende person, der kontaktes, hvis det eksempelvis er nødvendigt at afvige fra processen, så ingen behøver at spilde tiden (Damgaard, 2013). Situationen skal anskues fra et forretningsmæssigt perspektiv, hvor der foretages en vurdering af, hvad det koster i kroner og øre, hvis en antal medarbejdere ikke har mulighed for at udføre deres arbejde i en periode, fordi de er forhindret af en fejl, der endnu ikke er løst. Tilsvarende kan det analyseres, hvad den økonomiske konsekvens er af, at et antal forbrugere ikke kan få svar på deres henvendelser i en given periode (Ludvigsen & Borring, 2013). Det er uforeneligt, at fejlhåndtering er bundet op på enkeltpersoner, som også har andre ansvarsområder: Det er sårbart, der kun er én, der kan svare på det, og når så den ene person ikke er der, så går alt i stå, eller også er der nogen, der prøver at løbe rundt og finde ud af noget, og så tager det bare fire gange så lang tid, som hvis den person, der ved noget, var der. Ludvigsen & Borring, 2013 Der er behov for flere ressourcer og bedre organisering. Det er tit uklart, hvem der har ansvaret for et givent område, og der går derfor ofte tid med at finde ud af, hvem der skal løse en given problemstilling (Ludvigsen & Borring, 2013). Jeg synes også, der er behov for, at der sidder et team eller nogle mennesker, som er dedikeret til det hundrede procent, kun skal lave det, og ikke har fyrre andre opgaver. Ludvigsen & Borring, 2013 Eksempelvis det her, at Rådgiverportalen har været ustabil i en lang periode; nogle gange virker den slet ikke, og andre gange svarer den bare langsomt, og der har det vist sig, at hver gang der er en, der tager fat i den, så har problemet løst sig selv, men at det så opstår igen efter en halv time eller en halv dag. Den opgave er man ikke nået til endnu, at se på "hov, hvad skyldes det her egentlig?" Det vil sige, at vi når hver gang at få fejlen mange gange, fordi den bliver meldt ind tre gange i første omgang, og når så den igen ikke Analyse Side 55 af 185

56 virker om fire timer, så når tre andre rådgivere at melde den ind, så derfor er den lige pludselig mange gange, fordi man hver gang tænker lige nu virker den jo, så vi kan godt lade den ligge i stedet for hurtigt at få taget fat om nældens rod og se, hvad er det, der er grunden til, at den hele tiden går ned. Der må være en eller anden grund til, at den lige pludselig kører så ustabilt i forhold til, hvad den plejer (Bisbo & Nicolaisen, 2013). 5.5 Redesign arbejdet Arbejdsfordelingen omorganiseres, så modtagelsen af henvendelserne sker hos medarbejdere, der besidder et dybere kendskab til PenSams systemer og arbejdsrutiner. Dette kræver, at de pågældende personer besidder en altomfattende viden om alle de systemer, der kan opstå fejl på, og hvordan de hænger sammen. Det vil sige, at de specialister, der i dag fungerer som eksperter på de forskellige systemområder, fremover sidder i Service Desk og er frontline-medarbejdere. Det vil betyde, at mange henvendelser vedrørende oplevede fejl i systemerne vil kunne løses med det samme; fordi modtageren besidder det nødvendige kendskab til enten at rette fejlen eller til at gennemskue, at der ikke er tale om en fejl, men et forståelsesspørgsmål, og i samme ombæring hjælpe brugeren videre (Larsen, 2013). Det kræver, at den modtagende funktion er bemandet både af tekniske eksperter og af superbrugere af de pågældende systemer, som har indgående kendskab til den praktiske anvendelse af systemet (Bisbo & Nicolaisen, 2013), som de tekniske eksperter måske mangler (Larsen, 2013). Hvis flere lignende henvendelser dukker op inden for kort tid, kan modtagerne gruppere dem og iværksætte en dyberegående undersøgelse, og i kraft af deres dyberegående kendskab til både den tekniske og forretningsmæssige side af sagen med det samme rette fejlen (Larsen, 2013) eller som minimum give brugeren et kvalificeret svar på en tidshorisont (Bisbo & Nicolaisen, 2013). På denne måde er henvendelsen løst i første trin. Brugeren har måske ikke nødvendigvis fået løst fejlen i det samme, hvis der er tale om et problem, der kræver udvikling og idriftsættelse af en ændring, men pågældende har fået svar på sin henvendelse (Bisbo & Nicolaisen, 2013). Denne løsningsmodel er mulig, simpelthen ved at der er nogen, der fanger og løser problemerne frem for blot at indsamle, registrere og videresende information (Larsen, 2013). Selvfølgelig kan det være overvældende, i og med at der kan komme så mange fejl ind, at det alligevel ikke kan nås at behandle dem alle, men det vigtigste er at løse flest muligt af henvendelserne med det samme (Larsen, 2013). Der er helt klart for mange led, som det er lige nu, for den kan ligge x antal tid hos NNIT, den kan ligge x antal tid, hvis vi tager igen Rådgiverportalen, når den kommer til Portalsupport, når den kommer op til Service Operation, kan den også ligge x antal timer/dage, og igen, når den kommer til udviklerne. Så der er rigtig mange led, hvor - fordi der ikke er nogen, der har de her driftsbriller på, der hele Analyse Side 56 af 185

57 tiden sidder og overvåger, om der kommet noget nyt ind - så risikerer vi, de ligger alt for længe hvert sted. Bisbo og Nicolaisen, 2013 Det næste naturlige spørgsmål er nu, hvem der skal udføre det arbejde, som eksperterne beskæftiger sig med under den nuværende organisering. Naturligvis vil der være behov for, at nogle af opgaverne bliver varetaget af andre, men afskaffelsen af det led, Service Desk er defineret som i dag - der primært omfatter at registrere og skaffe oplysninger om, hvad fejlen er og efterfølgende sende den videre i processen - ville i sig selv skabe en synergieffekt og frigive ressourcer (Larsen, 2013). Værdiskabelsen ligger i en bedre beskrivelse af problemet i første omgang, og bedre forudsætninger i kraft af dybere indsigt hos modtageren, gør det nemmere at gennemskue, hvad der er gået galt (ibid.). Det kræver også, at disse medarbejdere har kendskab til, hvordan problemet kan undersøges. Det medfører en nødvendighed af at forlade sig på, den enkeltes viden, metodekendskab og erfaring. Der findes ingen systematiseret oplæring eller videnoverdragelse - det kræver et bredt spektrum af kendskab til dels fejlsøgningsprocesser, men også hvad der skal gøres, når der opstår et problem (Larsen, 2013). Hele denne proces er det nødvendigt at afsætte tid til at indføre (Larsen, 2013). Forudsætningen for at indføre denne proces er, at den er understøttet af procesorienteret personale, der er i stand til at følge op på processen (Damsgård, 2013). Hvis der er ting, der går undervejs, er første eskalationspunkt dem, der er bestemt til at løbe efter den slags opgaver, og som er skrappe ud i det procesmæssige. Disse profiler findes, men der er ikke fodfæste nok for opgaven (Damsgård, 2013). Der er med andre ord behov for en modning i PenSams procestankegang (ibid.). Nogle brugere har givet udtryk for et uopfyldt behov for information om, hvad de kan forvente omkring deres henvendelse. Her er det nødvendigt at arbejde med implementeringen af processerne (Damgaard, 2013). Hvis brugerne forventer at få en opgave udført fra den ene dag til den anden, er det et udtryk for, at det ikke er formidlet tilstrækkeligt klart, hvad der kan forventes. Det medfører frustration, hvis forventninger ikke efterleves, og der samtidig ikke gives en forklaring (Damgaard, 2013). Der skal indføres et service-katalog, som skal være tilgængeligt for alle brugere, der søger information om pris og ekspeditionstid på de forskellige typer af opgaver (Damgaard, 2013). Procesbeskrivelserne er udarbejdet og publiceret via PenSams intranet, og der r tidligere blevet afholdt et åbent hus-arrangement, hvor brugerne blev introduceret til processerne, men der er ikke blevet fulgt op på det arbejde i årevis. (Damgaard, 2013). Der skal indføres et egentligt implementeringskoncept, som både er programsat for nyansatte, men også bliver gennemført løbende, og hvis der sker ændringer til processerne (Damgaard, 2013). Konceptet skal følges op med en kommunikationsplan, som skal indrettes efter, hvad det er for en målgruppe, ændringerne vedrører. Det er vigtigt for sørge for, at de aktører, der skal bidrage til processen, er i besiddelse af de fornødne forudsætninger for at anvende værktøjet, så det bliver hurtigt og smidigt og fejlfrit (Damgaard, 2013). Analyse Side 57 af 185

58 For at processen kan fungere, er det nødvendigt at sørge for, at den også er implementeret ordentligt i ITorganisationen, så alle følger fælles fodslag og udfører opgaver og aktiviteter på samme måde. Nogle gange kan løsningen måske være lavet, men bare ikke implementeret. Årsagen er, at den forudgående aktør tror, at aktiviteten er afsluttet, mens den næste aktivitet afventer, at den forrige aktør afslutter sin aktivitet. Uklare roller og ansvarsfordelinger medfører, at sager kan havne mellem to stole. Derfor er det nødvendigt med en skarp afgrænsning af processer og roller, hvem der gør hvad, og at alle er loyale mod og følger processen. På den måde afhjælpes risikoen for, at opgaven mangler at blive løst og sagen lukket, og brugeren er blevet spurgt, om de er tilfredse med løsningen, og om det virker (Damgaard, 2013). Information og kommunikation er nøglen til at udbrede kendskabet til, hvordan der skal ageres i processen (ibid.). Det skal formidles, at den pågældende procesejer skal kontaktes, hvis nogen oplever noget, der ikke fungerer i processen. Vedkommende har en forpligtelse til at vedligeholde processen og finde ud af, hvad der er gået galt, og om der er anledning til en generel skal forbedre, eller der var tale om en enlig svale (Damgaard, 2013). Hvis der opstår mange driftstoppende fejl, er der risiko for, at andre forespørgsler ryger nederst i bunken. Givet det antal fejl, der løbende opstår, bør der indføres et Emergency Team, der kun beskæftiger sig med driftstoppende fejl, så der også er nogen, der beskæftiger sig med almindelige henvendelser, som også skal løses, men ikke haster. Brugerens behov er at få sit problem løst hurtigst muligt (Ludvigsen & Borring, 2013). Det skal fremgå klart, hvad brugerne kan forvente af svartider inden for de forskellige kategorier. Hvis brugerne ved, at der kan forventes svar inden for 24 timer, kan de bedre planlægge, sætte den konkrete sag til side, og fokusere på noget andet imens (Ludvigsen & Borring, 2013). Dog kan det være risikabelt at give en tilbagemelding på en tidshorisont. Det kræver, at de tidsgrænser, brugerne er blevet stillet i udsigt, kan honoreres, og at der er ressourcer til at løse opgaverne i virkeligheden (ibid.). Service Desk skal være placeret internt i PenSam (Ludvigsen & Borring, 2013) Alternativt mangler der et kontaktpunkt internt i huset. Det er rart som bruger at kunne gå et sted hen og tale med nogen: På et tidspunkt satte de et skilt op, man måtte ikke komme derned, man måtte kun ringe [..] Jeg synes faktisk, det er lidt underligt. Det er en servicefunktion, som vi betaler for. Ludvigsen & Borring, 2013 I nogle situationer er det hurtigere at kunne gå ned og tale med nogle mennesker i stedet for at skrive, fordi de måske kunne afhjælpe nogle ting. Hvis en bruger skriver en , der ikke er nogen, der forstår, skal de henvende sig tilbage til brugeren for en uddybning. Mange oplever, at der i sådan nogle situationer er meget ping-pong frem og tilbage, inden en sag både bliver tildelt en bestemt person og løst (Ludvigsen & Borring, 2013): Analyse Side 58 af 185

59 Nogle gange er en sag måske ikke en sag. Så kan det være, de kan sige "jamen du skal bare gøre sådan." Så kan jeg gå ned på min plads og være glad, og ikke frustreret over at der ikke sker en skid før om halvanden dag, når de har tid. Det bliver meget bureaukratisk, synes jeg. Det bliver meget administrativt tungt det der system. Service Desk. Ludvigsen & Borring, 2013 Der er stor værdi for brugerne i, at de mennesker, der modtager henvendelserne, sidde internt i PenSam. Årsagen til dette er, at brugernes problemer typisk er af en natur, hvor de har brug for hjælp på stedet. Der er behov for, at der er nogen internt i huset, der kan hjælpe (Ludvigsen & Borring, 2013). Du måske kan gå ned og tale med dem, eller de kan komme op og tale med dig. Der mangler noget nærhed i virkeligheden, tror jeg Ludvigsen & Borring, 2013 Adgang til det system, der anvendes til registrering og behandling af henvendelserne, ville give brugerne mulighed for selv at søge meget af den efterspurgte information, hvilket ville medføre færre opkald til Service Desk (failure demand, Seddon, 2005): Jeg kunne godt bruge adgang til det der, hvor man kan se, hvad der sker med mit sagsnummer. ligesom man kan følge sin pakke, når man har bestilt en, der bliver sendt med en eller anden pakkepost eller Post Danmark, så jeg kan se, hvad sker der, og også, at man har mulighed for at se, hvad prioriteringen er, og hvad er den forventede tid på at løse det her, så man ikke bare sidder tilbage og venter Ludvigsen & Borring, 2013 En sådan adgang skal indrettes efter det formål, den tjener. Det er ikke nødvendigt for brugeren at kende alle tekniske detaljer, blot skal den relevante information være tilgængelig. Dette ville ligeledes reducere mængden af opfølgende henvendelser til Service Desk (Ludvigsen & Borring, 2013). Tilpasning af denne brugeradgang til systemet skal ske i samarbejde mellem brugerne og IT-funktionen. Dette skyldes, at det er nødvendigt at have brugernes synspunkter med for at sikre, at deres behov bliver opfyldt, men samtidig kan nogle ting være indlysende for brugerne, der arbejder i PenSam til daglig, kender programmerne og systemerne, og bruger nogle fagudtryk om nogle bestemte ting. Det er således nødvendigt med være et samspil om at få det indrettet enkelt i form af et antal drop down-menuer, der skal udfyldes og en log, hvor brugerne kan se og følge med i, hvor deres sager befinder sig i forløbet (Ludvigsen & Borring, 2013). Analyse Side 59 af 185

60 Service Desk kunne i første omgang skrive tilbage til brugeren, at sagen er sendt videre til en given afdeling i PenSam, som vender tilbage. Set fra brugerens side, som ikke er så meget inde i, hvordan IT løser tingene, kunne det være godt, at de fik besked. Når udviklerne har løst problemet, melder de tilbage, at det er løst og kommer i drift på en given dato, men det er ikke ensbetydende med, at brugeren får besked. Der er et klart udestående med at give fejlmelderen ordentlig besked på, hvornår de kan forvente, ikke bare at fejlen er løst, men at løsningen er i drift (Bisbo & Nicolaisen, 2013). Arbejdsgangen kan strømlines ved, at der er så få led som muligt, men det kræver, at den nødvendige viden er til stede i Service Desk, fordi der ikke er nogen, der er dedikeret driftsfejl som hovedfokus (Bisbo & Nicolaisen, 2013). Der kan dæmmes op for, at den samme fejl bliver indmeldt mange gange eller af mange brugere, ved at være hurtigere til at opdatere på intranettet, så det hurtigt fremgår, at en given fejl allerede er meldt ind og har et givent sagsnummer (Bisbo & Nicolaisen, 2013). Hvis vi havde et driftsprojekt eller lignende, hvor vi hele tiden havde nogen, så ville der måske sidde de rette ressourcer klar til at løse alle vores problemer (Larsen, 2013) Hvad har vi af aftaler? Hvad kan vi forvente? Hvad skal man skrive? Hvad skal man gøre? Det er jo derfor, jeg godt kan lide ideen om den der Post Danmarkmodel. Ludvigsen & Borring, 2013 Analyse Side 60 af 185

61 6 Konklusion Gennem en række interviews med udvalgte aktører i virksomheden, der antages at have berøring med ITfunktionen og/eller spille en særlig rolle i forhold til arbejdet, er der identificeret en række områder, hvor der potentiale for forbedring. Disse erfaringer er gjort dels på baggrund af forfatterens forudgående kendskab til organisationen, dels med udgangspunkt i et casestudie i virksomheden, og dels med input fra interviews af en række aktører i og omkring IT-organisationen. Grundlaget for en forbedring af situationen er til stede i den forstand, at de berørte ITIL-processer allerede er indført i virksomheden. Det største problem i denne sammenhæng lader til at være manglende implementering af processerne. IT-funktionen er meget funktionelt organiseret, og arbejdet er bundet op på mål, der bliver til et middel i sig selv frem for at fokusere på det endegyldige formål, nemlig at opfylde kundernes - det vil sige slutbrugerne af IT-tjenesteydelserne - behov. Indførelsen af processerne i sig selv er således ikke tilstrækkeligt; de skal forankres i aktørernes tænke- og handlemåde, og alle i organisationen skal gøre sig formålet med arbejdet klart og arbejde efter et fælles mål. Den nuværende situation bærer præg af proceslandsbyer, hvor de enkelte processer i en vis udstrækning anvendes, omend hver for sig, men integrationen mellem de enkelte aktiviteter mangler. Konsekvensen af dette er, at der mangler flow i arbejdet, og processerne mangler sammenhæng og kundeperspektiv. Anlæggelsen af et Lean-perspektiv, der konkret udmønter sig i Vanguards systemtænkningsmetode, sætter i højere grad organisationen i stand til at opfylde sit formål. Centrale Lean-begreber som værdi, spild og flow kommer i fokus, og mål indrettes til at koncentrere indsatsen om at agere på kundernes efterspørgsel. Lean-tankegangen er ikke blot et spørgsmål om anvendelsen af nogle redskaber til forbedring af en given proces eller eliminering af spild. Det er i langt højere grad et spørgsmål om tankegang, og Lean giver sig til udtryk i en ledelsesfilosofi snarere end en værktøjskasse. Det er slået fast, at niveauet for henvendelser fra forretningen til IT-afdelingen vedrørende fejl og forespørgsler løbende ligger på et højt niveau, der gør det svært for det eksisterende personale at følge med. Samtidig er det konstateret, at en stor del af disse henvendelser kan reduceres eller elimineres ved at gennemføre en række konkrete tiltag, som vil skabe øget værdi for kunderne. Et øget fokus på information og forventningsafstemning omkring reaktion og løsning på henvendelserne er nødvendigt, ligesom der er værdi for kunderne i selv at kunne søge og finde disse oplysninger ved selv-service, både ved hjælp af procesog procedurebeskrivelser, Service Level-aftaler og opfølgning på henvendelser. Ligeledes er der identificeret en række kilder til ikke-værdiskabende arbejde. Disse omfatter dobbelthenvendelser i form af opfølgende spørgsmål vedrørende tidligere henvendelser, der ikke er besvaret fuldkomment og/eller rettidigt. En mere proaktiv adfærd og et skarpere fokus på målopfyldelse, der tilfredsstiller kundernes behov, vil kunne eliminere dette spild. Konklusion Side 61 af 185

62 Endelig er der identificeret en række tiltag, der forventes at bane vejen for en spild-fri håndtering af processerne. Den økonomiske konsekvens af disse tiltag er ikke behandlet nærmere, men en omorganisering af IT-funktionen vil givetvis medføre øgede omkostninger på kort sigt. Konklusion Side 62 af 185

63 7 Perspektivering Den samlede mængde litteratur, der ligger til grund for nærværende projekt, er af betragteligt omfang, særligt hvad angår litteratur om Lean og Toyota Production System. Specifikt findes der ikke én bog eller artikel i nedenstående litteraturliste, der ikke nævner Toyota som oprindelsen til Lean-tankegangen. Meget af litteraturen er således en gentagelse af beskrivelsen af Toyotas produktionsfilosofi. Tilsvarende bygger al litteratur om anvendelsen af Lean i IT-sammenhæng ligeledes på Toyotas principper. En tilgang til Lean, og særligt til Lean IT, der tager udgangspunkt i nyere litteratur og forskningsresultater, ville være kærkommen, men forudsætter et bredere grundlag end det, der eksisterer i dag. Den fokale virksomhed har udtrykt ringe interesse for projektets formål og resultater, og det har været vanskeligt at skaffe input til arbejdet med opgaven. Dette forhold har været kilde til stor frustration hos forfatteren under hele forløbet. Paradoksalt nok har den organisatoriske enhed i virksomheden - Resultatcenter IT - der tjener som genstandsfelt for projektet, været den sværeste at få til at bidrage med sparring og ikke mindst tid til afholdelse af interviews. Gentagne indkaldelser til interviews er blevet afslået med begrundelsen, at der ikke er tid, og reaktionen i IT-organisationen på projektet afspejler i det hele taget, at der ikke er tid til Lean-tiltag, fordi der er travlt nok i forvejen med at få hverdagen til at hænge sammen. IT-driftsleverandøren, der spiller en central rolle i arbejdet med ITIL-processerne, har afholdt en fokusgruppeundersøgelse med en række af PenSams brugere af Service Desk. Rapporten fra denne fokusgruppeundersøgelse, som skulle have været inddraget som empirisk data i projektet, er desværre ikke er klar fra leverandøren ved redaktionens afslutning, og det har således ikke været muligt at inkludere disse data i undersøgelsen. Denne del er derfor taget ud, på trods af at der er refereret til den i metodekapitlet. Tilsvarende har en del af de planlagte interviews måttet droppes som beskrevet ovenfor. Casestudiet kunne have dækket flere virksomheders anvendelse eller implementering af ITIL-processer, men det vurderedes at blive for omfattende i forhold til dybden af analysen. Ligeledes er analysen holdt til IT-organisationen, selvom det kunne have været relevant i højere grad at inddrage resten af virksomheden. I så fald skulle dataindsamlingen i stedet eller som supplement -have antaget en mere kvantitativ natur. Casestudiet som praksisorienteret projektarbejde kunne have været mere iterativt af natur, idet der kunne have været udarbejdet en struktur for opgaven strækkende sig over flere cykler. Således kunne sekvensen litteraturreview metode teori analyse (del-)konklusion have været gentaget ad flere omgange med henblik på en stadigt snævrere indkredsning af problemfeltet på baggrund af resultaterne af hver iteration, sådan som det er aktionsforskningens tankegang, men det har været forfatterens vurdering, at denne tilgang ville have været for omfattende og for kompleks. Derfor er der kun gennemført en enkelt iteration af forløbet. Perspektivering Side 63 af 185

64 Der er ikke taget hensyn til det økonomiske aspekt, og der er således ingen business case opstillet for anbefalingen om hjemtagning af Service Desk. En vurdering af dette aspekt ville have krævet indgående indsigt i regnskaber, forretningsplaner og aftalen med driftsleverandøren med henblik på en kvantitativ, økonomisk analyse af begge scenarier. Dette tiltag ville desuden utvivlsomt have krævet en hemmeligholdelse af projektet og dets konklusioner. Behovet for en kvalitativ analyse og forfatterens ønske om at producere en projektrapport, der efterfølgende kunne gøres offentligt tilgængelig, har opvejet dette alternativ. Der har i projektet ikke været fokus på kvantitative elementer. Eksempelvis kunne der have været gennemført en analyse af antal og alder af henvendelser inden for kategorierne af de tre processer for at konstatere, om de anbefalede initiativer havde haft den ønskede effekt. Dette havde dog krævet en større dedikation fra virksomhedens side, hvor det havde været muligt i højere grad at implementere nogle ændringstiltag undervejs i forløbet med henblik på at måle deres effekt. Analysemodellen, der er syntetiseret i teorikapitlet, kan således appliceres mere kvantitativt - under anvendelse af statistiske analyser og kapabilitetsmålinger - end det har været tilfældet i nærværende projekt. Modellen danner grundlag for en nærmere bearbejdning af mere kvantitativ karakter, og kan med fordel viderebehandles i et senere projekt; specielt trin 4, der går i dybden med analyse af ændringer i systemet som identificeret i kapabilitetsmålene. Modellen tager udgangspunkt i Vanguards systemtænkningsmetode, som er anvendelse af Lean-principperne fra Toyota Production System på servicevirksomheder. Således kan nærværende projekt opfattes som en fortolkning af sin egen model, der er kvantitativ i natur, men anvendes på kvalitativ vis på en problemstilling. Even if we help create time for employees, managers might still complain they don t have time. Well, make time! If something s important, you make time for it. Saying, I don t have time is playing the victim. A more accurate statement is, I choose to not make time. Graban, 2013 Perspektivering Side 64 af 185

65 8 Anbefalinger IT-driftsfunktionen bør omorganiseres i henhold til et systemperspektiv. Procesperspektiv Anlæg et procesperspektiv på tværs af Resultatcenter IT, så IT som funktion understøtter forretningens kerneprocesser i stedet for at være en funktionel silo. Implementér ITIL-processer på en måde, så de er ordentligt forankret i organisationen, og ikke bliver til process villages. Forbedringskultur Etablér en afdeling med ansvaret for CSI kunne være organiseret under eller sideordnet med Service Operation. Hjemtag Service Desk Hjemtag Service Desk fra driftsleverandøren og etabler en Service Desk-funktion internt kunne være organiseret sammen med eller sideordnet CSI-afdelingen. Single Point of Contact Etablér et Single Point of Contact for alle henvendelser, hvor brugere kan henvende sig uanset arten af deres forespørgsel. Adskil Service Desk og eksperter Omorganisér IT-funktionen, så eksperter er adskilt og kan koncentrere sig om deres systemområder, og Service Desk er bemandet af erfarne IT-folk, ikke blot formidlere. Definér mål for Service Desk, der understøtter arbejdet med opfyldelse af kundernes behov frem for at fokusere på målopfyldelsen per se. Afskaf funktionelle mål KPI-mål om at afslutte en sag inden for en given tidsfrist fører til et fokus på at lukke sagen, altså opfylde målet i sig selv, frem for at løse problemet. Der bør i stedet indføres mål, der sikrer, at kundens behov er opfyldt, eksempelvis måling på, i hvor høj grad kunden er tilfreds med løsningen, inden sagen lukkes. Anbefalinger Side 65 af 185

66 9 Kildehenvisninger 9.1 Referencer Til angivelse af referencer i teksten og i litteraturlisten anvendes metoden parentetisk reference (også kendt som Harvard Style Referencing), som den er beskrevet i den ofte anvendte Guide to the Harvard Style of Referencing udgivet af Anglia Ruskin University Library i Storbritannien (Anglia Ruskin University Library, 2012). 9.2 Litteraturliste Andersen, I., Den skinbarlige virkelighed. 4. udgave. Frederiksberg: Samfundslitteratur. Anglia Ruskin University Library, Guide to the Harvard System of Referencing. 4th ed. Cambridge: Anglia Ruskin University. Arlbjørn, J. S., Wæhrens, B. V., Johansen, J. & Pedersen, T., Produktion i Danmark eller offshoring/outsourcing: Ledelsesmæssige udfordringer. SMG Working Paper. No. 11/2009, December Frederiksberg: Copenhagen Business School, Center for Strategic Management and Globalization. Baarts, C. & Mehlsen, M., Fokusgruppediskussion. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 16. Bell, S. C., & Orzen, M. A., Lean IT: Enabling and Sustaining Your Lean Transformation. New York, NY: Productivity Press. Bicheno, J., The Lean Toolbox for Service Systems. Buckingham: PICSIE Books. Bicheno, J., The Service Systems Toolbox: Integrating Lean Thinking, Systems Thinking and Design Thinking. Buckingham: PICSIE Books. Bicheno, J. & Catherwood, P., Six Sigma and the Quality Toolbox for Service and Manufacturing. Buckingham: PICSIE Books. Bicheno, J. & Holweg, M., The Lean Toolbox: The Essential Guide to Lean Transformation. Buckingham: PICSIE Books. Bisbo, M.-B. & Nicolaisen, A., Interview. Interviewet af Caspar Miller, personligt interview i PenSam, Jørgen Knudsens Vej 2, 3520 Farum, mandag den 22. april 2013 kl Blichfeldt, B. & Hansen, B., Aktionsforskning at bedrive feltstudier i egen organisation. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 19. Borum, F., Strategier for organisationsændring. København: Handelshøjskolens Forlag. Kildehenvisninger Side 66 af 185

67 Bowen, D. E. & Youngdahl, W. E., Lean service: in defense of a production-line approach. International Journal of Service Industry Management. Vol. 9, No. 3, 1998, pp Cartlidge, A., Hanna, A., Rudd, C., Macfarlane, I., Windebank, J. & Rance, S., An Introductory Overview of ITIL V3. UK: itsmf. Christiansen, P. E., Logistikledelse i forsyningskæder. 2. udgave. København: Ingeniøren. Cunningham, J. & Jones, D., Easier, Simpler, Faster: Systems Strategy for Lean IT. New York, NY: Productivity Press. Darmer, P. & Nygaard, C., Paradigmer: Forståelse, anvendelse og begrænsning. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 5. Damgaard, E. N., Interview. Interviewet af Caspar Miller, personligt interview i PenSam, Jørgen Knudsens Vej 2, 3520 Farum, tirsdag den 16. april 2013 kl Damsgård, B., Interview. Interviewet af Caspar Miller, personligt interview i PenSam, Jørgen Knudsens Vej 2, 3520 Farum, tirsdag den 16. april 2013 kl Deming, W. E., Out of the Crisis. Cambridge, MA: Massachusetts Institute of Technology, Center for Advanced Educational Services. Fawcett, S. E. & Magnan, G. M., The rhetoric and reality of supply chain integration. International Journal of Physical Distribution & Logistics Management. Vol. 32, No. 5, 2002, pp Garvin, D. A., The Processes of Organization and Management. Sloan Management Review. Summer 1998, pp Ghauri, P. & Grønhaug, K., Research Methods in Business Studies. 2nd ed. Harlow: Pearson Education Limited. Graban, M., Who Coined the Term Lean? And Where is He Today? Tilgået 1. april Graban, M., No Time for Improvement? Bah! Make Time for Improvement! Tilgået 1. april Graban, M. & Swartz, J. E., Healthcare Kaizen: Engaging Front-Line Staff in Sustainable Continuous Improvements. Boca Raton, FL: Productivity Press. Greiner, L. E., Evolution and revolution as organizations grow. Harvard Business Review. July-August 1972, Vol. 50, Iss. 4, p Hammer, M How Process Enterprises Really Work. Harvard Business Review. November-December 1999, Vol. 77, Iss. 6, pp Kildehenvisninger Side 67 af 185

68 Hammer, M., Deep Change How Operational Innovation Can Transform Your Company. Harvard Business Review. April 2004, Vol. 82, Iss. 4, pp Hammer, M., The 7 Deadly Sins of Performance Measurement (and How to Avoid Them). MIT Sloan Management Review. Spring Harland, C. M., Supply Chain Management: Relationships, Chains and Networks. British Journal of Management. Vol. 7, Special Issue, March 1996, pp HM Government, Official ITIL Website. Tilgået 23. februar Jensen, K. B., Refleksiv Lean: Lean Thinkings nuancefattigdom, uklare definitioner samt interne modsætninger som kilde til øget organisatorisk effektivitet, Økonomistyring & Informatik, Vol. 27, No. 4, pp Jensen, K. B., Sorting Lean literature Value, waste and competitive priorities. Frederiksberg: Copenhagen Business School. Jepsen, A. L. & Madsen, S. O., Om at foretage kvalitative interviews. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 15. Johansen, P. H. & Tetzschner, H., Castestudiemetoden en frugtbar og relevant model i samfundsvidenskab. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 7. Jung. E., PenSam får pisk for manglende vilje og evne. Berlingske, 23. januar 2013, p. 44. Kotter, J. P., Leading Change: Why Transformation Efforts Fail. Harvard Business Review, March-April 1995, Vol. 73, Iss. 2, pp Larsen, L. B., Interview. Interviewet af Caspar Miller, personligt interview i PenSam, Jørgen Knudsens Vej 2, 3520 Farum, mandag den 15. april 2013 kl Levitt, T., Production-line approach to service. Harvard Business Review. Vol. 50, No. 5, pp Levitt, T., The industrialisation of service. Harvard Business Review. Vol. 54, No. 5, pp Liker, J. K., The Toyota Way. New York, NY: McGraw-Hill. Liker, J. K. & Morgan, J. M., The Toyota Way in Services: The Case of Lean Product Development. Academy of Management Perspectives. May 2006, Vol. 20, Iss. 2, pp Limoncelli, T. A., Deconstructing User Requests and the Nine Step Model. Proceedings of LISA '99: 13th Systems Administration Conference. Berkeley, CA: The USENIX Association. Ludvigsen, B. & Borring, C. C., Interview. Interviewet af Caspar Miller, personligt interview i PenSam, Jørgen Knudsens Vej 2, 3520 Farum, tirsdag den 16. april 2013 kl Kildehenvisninger Side 68 af 185

69 Majchrzak, A. & Wang, Q., Breaking the Functional Mind-Set in Process Organizations. Harvard Business Review. September-October 1996, Vol. 74, Iss. 5, pp Markovitz, D., Information 5S. Management Services. Spring 2012, pp Maslow, A. H., Motivation and Personality. Harper. Mason-Jones, R. & Towill, D. R., 1999, Using the Information Decoupling Point to Improve Supply Chain Performance. The International Journal of Logistics Management. Vol. 10, No. 2, 1999, pp McIntosh, R. I., Culley, S. J., Mileham, A. R. & Owen, G. W., A critical evaluation of Shingo s `SMED (Single Minute Exchange of Die) methodology. International Journal of Production Research, Vol. 38, No. 11, pp Modig, N. & Åhlström P., This is Lean: Resolving the Efficiency Paradox. Stockholm: Rheologica Publishing. Nielsen, K., Casestudier anvendt I arbejds- og organisationssociologien. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 13. Nielsen, K. S., Samspillet mellem teori og empiri anvendelse af hypotetisk/deduktiv metode i projekter. I: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 9. Nielsen, K. A., IT helpdesk - Best eller worst practice. Medlemsmagasinet effektivitet.dk, Nr. 1, 2011, pp Ohno, T., Toyota Production System. Beyond Large-Scale Production. Boca Raton, FL: CRC Press, Taylor & Francis Group. Piercy, N. & Rich, N., High quality and low cost: the lean service centre. European Journal of Marketing. Vol. 43, Iss. 11, pp Piercy, N. & Rich, N., Lean transformation in the pure service environment: the case of the call service centre. International Journal of Operations & Production Management. Vol. 29, Iss. 1, pp Prahalad, C. K. & Hamel, G., The Core Competence of the Corporation. Harvard Business Review. May-June 1990, pp Porter, M. E., The Competitive Advantage of Nations. New York, NY: Free Press. Rienecker, L. & Jørgensen, P. S., Den gode opgave håndbog i opgaveskrivning på videregående uddannelser. 3. udgave. Frederiksberg: Forlaget Samfundslitteratur. Rod, P., Praksisorienteret projektarbejde. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 4. Kildehenvisninger Side 69 af 185

70 Rother, M. & Shook, J., Learning to See: Value-Stream Mapping to Create Value and Eliminate Muda. Cambridge, MA: The Lean Enterprise Institute. Saunders, M., Lewis, P. & Thornhill, A., Research Methods for Business Students. 5th ed. Harlow: Pearson Education Limited. Schjoldan, P., A3 anvendelse hos Lundbeck. Medlemsmagasinet effektivitet.dk, Nr. 1, 2012, pp Seddon, J., Freedom from Command & Control. New York, NY: Productivity Press. Seddon, J., Six steps to improving productivity. Management Services. Summer 2007, pp Seddon, J., Think outside-in. Management Services. Autumn 2007, pp Seddon, J., Fit for the future. Management Services. Winter 2007, pp Seddon, J., Think flow. Management Services. Spring 2008, pp Seddon, J., Think system. Management Services. Summer 2008, pp Seddon, J., This means me. Management Services. Autumn 2008, pp Seddon, J., The Vanguard Method Seminal Moments leading to the creation of the Vanguard Method. Shingo, S., A Revolution in Manufacturing: The SMED System. Cambridge, MA: Productivity Press. Shingo, S., Zero Quality Control: Source Inspection and the Poka-yoke System. Portland, OR: Productivity Press. Shingo, S., A Study of the Toyota Production System: From an Industrial Engineering Viewpoint (Produce What Is Needed, When It's Needed). Oversat fra japansk af A. P. Dillon. Tokyo: Japan Management Association. Sobek, D. K. & Smalley, A., Understanding A3 Thinking: A Critical Component of Toyota s PDCA Management System. New York, NY: Productivity Press. Spear, S., & Bowen, K. H., Decoding the DNA of the Toyota Production System. Harvard Business Review, September-October 1999, Vol. 77, Iss. 5, pp Sprigg, C. A. & Jackson, P. R., Call Centers as Lean Service Environments: Job-Related Strain and the Mediating Role of Work Design. Journal of Occupational Health Psychology. Vol. 11, No. 2, pp Suárez-Barraza, M. F., Smith, T. & Dahlgaard-Park, S. M., Lean Service: A literature analysis and classification. Total Quality Management & Business Excellence. Vol. 23, Iss. 3-4, pp Swank, C.K., The lean service machine. Harvard Business Review. October 2003, Vol. 81, Iss. 10, pp Kildehenvisninger Side 70 af 185

71 The Shingo Prize, The Shingo Prize. Tilgået 30. marts Voxted, S. Det gode projekt. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 2. Weirsøe, B., Jeg iagttager, at han iagttager, at de iagttager Operativ konstruktivisme som videnskabsteoretisk udgangspunkt for produktion af empiri. In: S. Voxted, ed Valg der skaber viden om samfundsvidenskabelige metoder. København: Academica. Kapitel 6. Williams, H. & Duray, R., Making IT Lean: Applying Lean Practices to the Work of IT. Boca Raton, FL: CRC Press, Taylor & Francis Group. Womack, J. P., Jones, D. T. & Roos, D., 1990, The Machine that Changed the World. London: Simon & Schuster UK Ltd. Womack, J. P. & Jones, D. T., Lean Thinking. London: Simon & Schuster UK Ltd. Kildehenvisninger Side 71 af 185

72 10 Bilag 10.1 Projektdagbog November 2012: Første overvejelser omkring valg af muligt emne omfatter; - Etablering af en egentlig produktions-(planlægnings-)afdeling i en finansiel servicevirksomhed - Hvordan gør en leverandør sin kunde mere attraktiv, når det er kunden, der har forhandlingsstyrken? Exit-voice, magt, forhandlingsstyrke, netværk, relationer 15. november 2012: På vej hjem-møde på IT-universitetet arrangeret af Dansk IT og Implement Consulting Group om Lean og Operational Excellence. Thomas Thorsted holdt et foredrag om OpEx i NNIT, som var meget inspirerende. Emnet for hovedopgaven bliver nok OpEx i PenSams IT-afdeling. til KSH om mulighed for valg af Kim som vejleder samt opridsning af mulige emner: From: Caspar Reiff Miller Sent: 15 November :05 To: Kim Sundtoft Hald Subject: HD SCM hovedopgave Hej Kim Jeg skriver til dig, fordi jeg gerne vil have dig som vejleder på hovedopgaven på HD SCM i foråret 2013, hvis det er muligt at ønske, og hvis din kvote ikke allerede er opfyldt :) Hvad angår emnet for opgaven, har jeg gjort mig nogle overvejelser. Jeg tænker at tage udgangspunkt i enten min egen nuværende arbejdsplads, PenSam, eller Coloplast, hvor jeg tidligere har arbejdet. Nogle af de mulige emner kunne omfatte; - Hvordan kan en mindre leverandør af IT-serviceydelser forhandle en tættere samarbejds- /partnerskabsaftale på plads med en af sine største kunder? - Hvordan kan en kunde forhandle bedre (dvs. længere) betalingsfrister med sine leverandør, uden at tilbyde noget til gengæld? (Er måske ikke længere så relevant med den nye lovgivning?) - Etablering af en Lean IT-strategi i en virksomhed i den finansielle servicesektor - Etablering af en egentlig produktionsplanlægningsafdeling i en virksomhed i den finansielle servicesektor (jeg ved, at både PFA og Danske Bank har haft succes med lignende tiltag) Har du mulighed for at mødes en dag i løbet af næste uge for at tale nærmere om ovenstående? På forhånd tak Caspar 19. november 2012: Kort snak med JDR (IT-direktør, PenSam) om muligheden for at skrive om OpEx i Resultatcenter IT. 26. november 2012: Første vejleder. Valg af emne er faldet på OpEx i PenSams IT-afdeling. Bilag Side 72 af 185

73 17. december 2012: Brainstorming på underemner. Hvordan kan flest muligt af fagene fra de første tre semestre inkorporeres i en opgave, der også skal tage hensyn til det praktiske problem? Hvordan skal opgavens akademiske tilgang og den konkrete problemstillings praktiske tilgang vægtes? Centralised Prioritisation Training & Education Organisational Change Management Supplier Relationship(s) Financial Goals Conformance to IT Strategy Operational Management by Example IT Development inhouse or outsourced? Skills ITSM (Remedy) Platform People Requirements Organisational Layout Operational Excellence Single Point of Entry Certification Key Performance Indicators Management ITIL Resolution Time Processes Service Level Agreement(s) Response Time Business Partnership Criticality/Category/ Priority Service Catalogue Lean IT Services 3. januar 2013: Møde i uddannelsesudvalget i effektivitet.dk. Talte med Christian Obbekær og Thomas Thorsted om sparring på opgaven og implementeringen af OpEx i PenSam IT. 4. januar 2013: Christian Obbekær sendte en inspirerende meddelelse (uddrag): Til dit projekt kan jeg anbefale Asger Aamunds synspunkt i Berlingske i dag. Det falder ganske godt i tråd med den ene af de bøger, jeg vil anbefale dig. Det er jo imponerende, hvordan folk kan udnytte smarttelefoner, QR-koder, tavlecomputere og andet, når de har fri, mens de i arbejdstiden skal benytte "forældede" systemer. På en undergrundsbane i Sydkorea er der en hel fotovæg, der forestiller hylder med varer i et suppermarked. Hver vare har en QR-kode. Folk kan så scanne de varer, de mangler - og når de kommer hjem, står varerne ved døren. Sammenlign det med indkøbsfunktionen i et firma. Bogen hedder Far from the Factory - Lean for the Information Age, af George Gonzalez-Rivas og Linus Larsson (svensker, tidl. PA konsulent), ISBN En anden bog af (Guru) Jean Cunningham og Duane Jones hedder Easier, Simpler, Faster - Systems Strategy for Lean IT. ISBN Der findes også en 1 times video, hvor hun fortæller om Lean IT hos Kimberley-Clark. Sidste bog: Lean IT - Enabling and Sustaining Your Lean Transformation, af Steven C. Bell og Michael A. Orzen.ISBN (Den har jeg ikke læst endnu). Bilag Side 73 af 185

74 Id Opgavenavn Startdato Slut Varighed 1 Problemformulering d 2 Litteraturreview d 3 Metode d 4 Teori d 5 Analyse d 6 Konklusion d 7 Perspektivering d 8 Implementering d 9 Handlingsplan og projektstyring d 10 Projektarbejdets organisering d 11 Executive Summary d 12 Forord og indledning d jan 2013 feb 2013 mar 2013 apr 2013 maj Caspar Miller Med hensyn til John Bichenos bøger, så er Six Sigma bogen ikke blevet erstattet af en ny, og det er nok heller ikke hans kerneområde. De to andre er derimod erstattet af nye, forbedrede og helt omskrevne versioner: Grøn: The Lean Toolbox - The essential Guide to Lean Transformation, Fourth Edition (2009), den er skevet sammen med Matthias Holweg, ISBN (Gul): The Service Systems Toolbox - Integrating Lean Thinking, Systems Thinking and Design Thinking (2012), ISBN Asger Aamunds artikel: 6. januar 2013: Foreløbig problemformulering skrevet og uploadet på Learn. 9. januar 2013: Litteratursøgning på CBSs bibliotek. Litteraturreview-kapitel påbegyndt. Opstillet struktur for opgaven i et hoveddokument. Udarbejdet foreløbig projektplan: Afsnit Sideantal Indholdsfortegnelse 2 Executive Summary 1 Forord 0,5 Indledning 0,5 Problemformulering 2 Litteraturreview 10 Metode 5 Teori 20 Analyse 30 Bilag Side 74 af 185

75 Konklusion 3 Perspektivering 3 Implementeringsplan 1 Projektarbejdets organisering og styring 2 I alt januar 2013: Organisationsdiagram til indledning. Indledning skrevet, fylder under en side. Overvejelser omkring dataindsamling. Plan for hvilke personer, der skal interviewes. Spørgeramme påbegyndt. Dataindsamling - Kvalitative data o Dybdeinterviews Interne Respondenter o o o o o o o o o o JDR JO AMS THAX CPO MSD? HH? SHO? ELD? Hvad med nogen fra forretningen? ACA? RIB? Spørgeramme o Hvad er største styrker hhv. udfordringer for den nye/nuværende IT-organisation? o Hvor skal vi hen? Eksterne Respondenter o o o o Thomas Thorsted (effektivitet.dk, Implement Consulting Group) Lars Nygaard / Mikkel Lou (Visma Consulting) Peter Sant? (PFA) Alan Saul eller en anden fra Deloitte? Spørgeramme o Hvordan organiserer man arbejdet i IT-afdelingen bedst? Bilag Side 75 af 185

76 o - Kvantitative data o o Fokusgruppeinterviews? Respondenter Spørgeramme Eksisterende Nye Kundeservice? Forventninger til IT? Udfordringer? Ugentlige lister over antal åbne Remedy-sager Brugertilfredshedsundersøgelser Evt. ny brugertilfredshedsundersøgelse? medio januar 2013: Læst John Seddons bog Freedom from Command & Control. Bogen handler om Systems Thinking-metoden eller Vanguards metode, som anlægger et systemperspektiv (udefra-ind-tænkning) på den traditionelle ordre-og-kontrol-tankegang. Bogens tankemønster kan direkte overføres til dette projekt. 28. januar 2013: Litteratursøgning fortsat. Søgt på emneordene Lean og Service i Business Source Complete. Udvalgt 14 artikler ud fra overskrift til nærmere gennemlæsning. 29. januar 2013: Workshop i grundlæggende informationssøgning og referencehåndtering på CBS. Ny litteratursøgning ved brug af metoderne fra workshoppen resulterer i mere relevante søgeresultater for Lean, som anvendes i stedet. 2. februar 2013: Sammensat al skreven tekst (inkl. nærværende projektdagbog) i ét samlet dokument. Inddelt litteraturreview-kapitel i forskellige temaer (Lean, PDCA og A3, og systemtænkning), og sat litteratursøgning og øvrig litteratur sammen under hver enkelt underoverskrift. Det giver en bedre struktur i reviewet (måske skal nogle af temaerne tages ud?). Skrevet til Kim og foreslået vejledermøde i næste uge (tirsdag den 5. februar 2013). 5. februar 2013: Vejledermøde. Kim foreslog en skarpere formulering af undersøgelsesspørgsmålet, så det i sig selv i højere grad afspejler formålet med undersøgelsen. Litteraturreviewet er en gennemgang af den litteratur, der indtil videre er skrevet på området. I teoriafsnittet gås i dybden med de valgte teorier og hvordan de anvendes i analysen. Omprioriteret i sideantal efter Kims anbefaling om, at analyseafsnittet skal fylde halvdelen: Afsnit Sideantal Revideret Indholdsfortegnelse 2 Executive Summary 1 Forord 0,5 Indledning 0,5 Bilag Side 76 af 185

77 Problemformulering 2 Litteraturreview 10 5 Metode 5 Teori Analyse Konklusion 3 Perspektivering 3 Implementeringsplan 1 Projektarbejdets organisering og styring 2 I alt 80 Antal anslag inkl. mellemrum, i alt Antal anslag inkl. mellemrum, gns. pr. side 2275 Maks. antal sider 80 Antal anslag inkl. mellemrum februar februar 2013: Læst Finn Borums bog Strategier for organisationsændring, som omhandler en intervention i en IT-virksomhed anskuet i forskellige perspektiver. 17. februar 2013: Omformuleret undersøgelsesspørgsmålet: Ovenstående problembeskrivelse leder til følgende undersøgelsesspørgsmål: Hvordan kan IT-afdelingens håndtering af de fire ovennævnte processer forstås? o o I hvilken udstrækning kan de fire processer håndteres smidigere? Hvilken værdi kan det tilføre at organisere arbejdet på en anden måde? 18. februar 2013: Svar fra Kim ( ) på omformulering af undersøgelsesspørgsmålet: From: Kim Sundtoft Hald [ksh.om@cbs.dk] Sent: 18 February :27 To: Caspar Reiff Miller Subject: RE: HD-SCM hovedopgave: Problemformulering omskrevet Hej Casper, Jeg synes bestemt at den er blevet bedre godt at undgå ja/nej spørgsmålet. Overvej også om: - Virksomhedsnavnet bør indgå i problemformuleringen. - LEAN eller LEAN-perspektiv bør indgå i problemformuleringen. Forstås i et LEAN-perspektiv? - Om du i stedet for at referere til nogen ovenfor bør skrive navnene på de fore processer, så problemformuleringen kan læses mere selvstændigt. Sig endelig til når du er klar til et nyt vejledermøde. Best regards Bilag Side 77 af 185

78 Kim Sundtoft Hald, Associate Professor, Ph.D. Copenhagen Business School, Department of Operations Management Solbjerg Plads 3, 2000 Frederiksberg Denmark, Tel: Fax: From: Caspar Reiff Miller Sent: 17. februar :59 To: Kim Sundtoft Hald Subject: HD-SCM hovedopgave: Problemformulering omskrevet Hej Kim Efter vort seneste møde har jeg forsøgt at omformulere undersøgelsesspørgsmålet, så det undgår ja/nejspm. og er mere dækkende: Hvordan kan IT-afdelingens håndtering af de fire ovennævnte processer forstås? o I hvilken udstrækning kan de fire processer håndteres smidigere? o Hvilken værdi kan det tilføre at organisere arbejdet på en anden måde? Jeg synes, det giver en bedre forståelse af, hvad formålet med opgaven er. Hvad synes du? Mvh Caspar På denne baggrund er undersøgelsesspørgsmålet omformuleret til: Hvordan kan håndteringen af de fire IT Service Management-processer Service Request Management, Incident Management, Problem Management og Change Management i PenSams IT-afdeling forstås i et Lean-perspektiv? o o I hvilken udstrækning kan de fire processer håndteres smidigere? Hvilken værdi kan det tilføre at organisere arbejdet på en anden måde? 23. februar 2013: Skrevet videre på litteraturreview. Tilføjet introduktion til ITIL i indledningen. Måske skal dette afsnit flyttes til teori-kapitlet? Bilag Side 78 af 185

79 24. februar 2013: Læst bogen This is Lean og tilføjet beskrivelse til litteraturreviewet. I skrivende stund fylder dokumentet tegn inkl. mellemrum fordelt på 25 sider (uden bilag og litteraturliste), så der er plads til mange sider med ren tekst uden at overskrive kravene (nogle af siderne er pt. blanke, fordi de blot er der for at definere skelettet i dokumentet). 25. februar marts 2013: Læst bogen Toyota Production System af Taiichi Ohno. 3. marts 2013: Tilføjet Cunningham & Jones overføring af de syv spildkategorier på IT til litteraturreviewet. Afgrænsning skal skrives, så det fremgår, at der kun er tale om drift, ikke udvikling. Derfor er det heller ikke relevant at interviewe udviklingsfolk. Litteraturreviewet fylder nu 7 sider og er stadig ikke skrevet færdigt. Måske skal noget af teksten flyttes til teorikapitlet. 9. marts 2013: Påbegyndt bogen Lean IT. 11. marts 2013: Omskriv litteraturreview så Lean fremgår som hovedoverskrift med de øvrige som underpunkter + tilføj Lean IT som underpunkt. 12. marts 2013: Spørg Christian Obbekær om litteratur for TWI. 14. marts 2013: Omarrangeret litteraturreview, så Lean er overskrift med Lean IT, PDCA/A3 og systemtænkning er underoverskrifter. Omskriv problemformulering/baggrund så Change ikke er med (kun drift, som også skrevet i afgrænsning) Bilag Side 79 af 185

80 15. marts marts 2013: Læst bogen Learning to See om værdistrømsanalyser og tilføjet afsnit herom i litteraturreviewet. 18. marts 2013: Endelig lykkedes det at få taletid på afdelingschefernes ugentlige møde. En kort introduktion til opgavens emne fremkaldte udtalelser som vi har ikke tid til Lean og Lean virker ikke på services, det er jo bevist. Disse udtalelser viser, at ledelsen ikke har forstået, at Lean handler om tankegang, ikke kun om redskaber. Det medfører, at opgaven må gennemføres uden støtte fra ledelsen. Hvis dette havde været udmeldingen fra starten, havde det været muligt at tage udgangspunkt i en anden virksomhed, hvor problemstillingen ville være blevet mødt med større forståelse. 21. marts 2013: Læst bogen Lean IT. 22. marts 2013: Det er vigtigt at understrege, at fokus er på drift, ikke på udvikling. Derfor tages de to udviklingschefer i Resultatcenter IT ud af listen over respondenter til interview. Litteraturreview skal skrives færdigt, og noget skal måske flyttes til teorikapitlet. Metodekapitlet skal skrives færdigt. Teorikapitlet skal uddybes og anvendelsen af de enkelte teorier og modeller skal begrundes i deres brug i analysekapitlet. Der skal udarbejdes en plan for interviews, herunder spørgeramme, respondentliste osv., og der skal indkaldes til interviews. 23. marts 2013: Der er i skrivende stund tællende tegn i dokumentet, hvilket svarer til 21 ns. 25. marts 2013: Læst bøgerne Understanding A3 Thinking og Making IT Lean. 29. marts 2013: Skrevet Change Management-processen ud af problemformuleringen. Undersøgelsesspørgsmål omformuleret, så de i højere grad følger trinene i Blooms taksonomi som følger: Hvordan kan håndteringen af de tre IT Service Management-processer Service Request Management, Incident Management og Problem Management i PenSams IT-afdeling forstås i et Leanperspektiv? o I hvilken udstrækning kan anlæggelsen af Lean-perspektivet på de tre processer føre til en smidigere håndtering? o o o Hvilke Lean-elementer kan med fordel anvendes i håndteringen af processerne? Hvordan kan effekterne af Lean-tiltagene måles? Hvordan kan de valgte tiltag implementeres? Hovedspørgsmålet bevæger sig på de lavere trin (viden og forståelse) på Blooms trappe. De fire underspørgsmål relaterer sig gradvist til de højere trin på skalaen. Bilag Side 80 af 185

81 Det sidste spørgsmål om implementering skal måske flyttes til kapitlerne efter konklusionen og i den sammenhæng måske tages ud af undersøgelsesspørgsmålet. Skrevet til Kim og bedt om tid til vejledermøde inden for de næste to uger. 30. marts 2013: Skrevet metode. Vinklen er deltagende, aspekter af Action Learning, Participative Inquiry. Indsamling af data som casestudie med udgangspunkt i beskrivelsen i problemformuleringen. Data er både kvalitative i form af interviews og kvantitative i form af statistikker.fra Remedy. 31. marts 2013: Gennemgang af litteraturreview og teori. Der skal flyttes rundt på nogle afsnit, og teorikapitlet skal uddybes. Litteraturreviewet er nu nede på seks sider, hvilket nok passer meget godt. Måske er nogle af teorierne stadig lidt for uddybet, men fem-seks sider stemmer fint overens med planen. Metodekapitlet er inddelt i afsnit tilsvarende Saunders research onion, og fylder tre sider. Det skal stadig rettes lidt til, men formuleringen går udelukkende på indholdet i opgaven og ikke generel afskrift fra metodebøger. Sidefordelingen ser nu således ud: Afsnit Sideantal Revideret Faktisk Indholdsfortegnelse Executive Summary Forord 0,5 0,5 0 Indledning 0,5 0,5 4 Problemformulering Litteraturreview Metode Bilag Side 81 af 185

82 Teori Analyse Konklusion Perspektivering Implementeringsplan 1 1 0,5 Projektarbejdets organisering og styring 2 2 0,5 I alt Antal anslag inkl. mellemrum, i alt Antal anslag inkl. mellemrum, gns. pr. side Maks. antal sider 80 Antal anslag inkl. mellemrum, maks. i alt Spørgsmål til vejledermøde: Inddragelse af egen viden? 1. april 2013: april 2013: Udvidet metodekapitlet. Tilføjet forklaring af projektet som en kombination af casestudie, aktionsforskning og grounded theory. Kapitlet er stadig ikke renskrevet. Metodeafsnittet har vist sig at være den største udfordring indtil videre. 8. april 2013: Vejledermøde med Kim. Selvinterview eller interview af nær kollega for at få i forvejen kendte svar på spørgsmål, blot for at have dem nedfældet som data, der kan refereres til, er for tyndt. Anbefaling om i højere grad at gøre brug af Bilag Side 82 af 185

83 observationer i form af caseforløb so m datagrundlag. Anbefalingen er efterlevet og metodeafsnittet er omformuleret til at afspejle dette. Valg af paradigme er i højere grad et spørgsmål om at træffe et valg og bevidst anlægge et bestemt perspektiv, frem for at forsøge at problemløse for at finde ud af, hvad det rigtige svar er. Der skal argumenteres for valg af paradigme som netop et aktivt valg, ikke blot en analyse af situationen og deraf følgende logisk slutning omkring paradigmet. Litteratur-, metode- og teorikapitler skal lukkes, og fokus skal nu lægges på dataindsamling og analyse april 2013: Skrevet videre på metodekapitel, der stadig ikke er færdigt. Planlagt 12 dybdeinterviews til afholdelse i løbet af de næste to uger. 16. april 2013: Vejledermøde: Konstruktivistisk: Mere tydeligt at aktørerne har forskellige holdninger, virkelighedsopfattelser Dataindsamling: Skab oversigt, præsenter data, disse underoverskrifter følger måske modellen lidt for slavisk. Lidt mange afsnit, overvej at slå nogle sammen. Præsenter oversigter, hvilke elementer er der i data. I øvrigt: Flyt Dokumentets opbygning, er lidt kedeligt at starte med, start med et større perspektiv Danmark er blevet stærk på service, outsourcing er udbredt osv. Begrebsdefinitioner flyttes længere ned, evt til bilag, bryder flowet på de første, vigtige sider. Flyt ITIL til teorikapitel. Problemfelt skrives, så det bedre fremgår, at hensigten er at frigive tid til at løse problemer tilbundsgående. Kan også modereres gennem sprogbrug, fx Mange oplever, at, Det synes, Det kan skyldes... Kan referere til interview allerede i indledning/problemfelt (fortsættelse af Executive Summary). Hovedspm. være noget andet, Lean-analyse, forståelsesspm. skal være et underspm. Hvordan kan en Leananalyse hjælpe PenSam med at frigive tid i brandslukning til at løse problemer i root cause. Litttrvw: Mange tabeller bryder flowet; kan blive hvor det er, skaber nærhed til data, men bryder flowet for meget; kan flyttes til sekundære data; kan flyttes til bilag. 20. april april 2013: Flyttet dele af indledning og dele af litteratur (tabeller) er flyttet til bilag. Litteraturreview omstruktureret, så kun Lean og Lean IT figurerer som emner. Droppet interviews med cheferne i IT. De har ikke tid og bliver ved at udskyde møderne. Bilag Side 83 af 185

84 10.2 Projektplan Bilag Side 84 af 185

85 10.3 Interviewguide Fokusgruppeinterview Pensam Fokusgruppe Spørgeguide Struktur semistruktureret Moderator: Lasse Lundemark Co-moderator: Carsten Lund Larsen Observer: Agnes Brazauskyte, Andy Kruger Optages på iphone5 app Introduktion Præsentation af os og formål og baggrund. Brugertilfredshedsmålinger. Information til gruppen: Optagelse, anonymitet, alle kan tale frit osv. Kort 1 minuts præsentation af deltagere og deres sidste oplevelse med NNIT Service desk. Start spørgsmål: 1. Hvilke forventninger havde i til NNIT s Service Desk 2. Hvad er jeres oplevelse af Service Desk efter NNIT s overtagelse? 3. Hvad er den største forskel på Service Desk før og efter NNIT tog over. a. Ventetid telefon b. Ventetid på løsning af sag c. Supporterens evne til at forstå problemet d. Supporterens IT kompetencer e. Informationsniveau f. Kommunikative evner g. Servicemindedness h. Service Systemet processer, service level targets m.m. Hurtig bordet rundt øvelse: Hvad er det vigtigste for dig når du kommer igennem til Service Desk? 1 ord! Imødekommenhed Venlighed Hurtighed Faglighed Forstående Empatisk Medfølende Korrekt etc Afslutning Mange tak Kort opsummering af observationer Hvad gør vi nu? Analyse samt strategi for forbedring af service. Bilag Side 85 af 185

86 Formidler herefter til Pensam IT Tak for jeres hjælp! Dybdeinterviews Baggrunden er RCITs håndtering af henvendelser modtaget gennem Service Desk i processerne Service Request Management, Incident Management, Problem Management. Tegn og fortæl A3 Hvordan er situationen i dag? Hvad er udfordringerne? Hvordan kan disse afhjælpes? Hvor er der potentielle forbedringer? Hvordan kan disse opnås? Bilag Side 86 af 185

87 10.4 Transskription af interviews Respondent: Larsen, Incident og Problem Manager I: Det som det går ud på her, den her interview-form, det er at man.. Du har et stykke A4-papir til rådighed og så er der nogle enkelte spørgsmål som skal guide interviewet i en bestemt retning. Så går det ud på at tegne og fortælle. Derfor har jeg lige taget nogle kuglepenne med. Du må selv om, om du bruger en eller flere farver osv. Det går på den måde, vi håndterer de her processer: Incident management, problem management og service request management her i PenSam. Og anvendt på de processer eller de henvendelser der kommer via Service Desk. Og den første del handler om, hvordan situationen ser ud i dag; hvordan fungerer det, hvordan foregår det, hvad har vi af.. altså hvordan er banen kridtet op. Og sådan som jeg forestiller mig, det er at vi for eksempel kan dele det op i tre dele, men i princippet så er det dig, der vælger, og dig der som sagt tegner og fortæller. Men der er de tre overordnede temaer: Hvordan ser det ud nu, hvad har vi af udfordringer og hvor kan vi gøre noget bedre. Vi starter med sådan en overordnet generel.. Hvordan er situationen i dag? Hvordan hænger det sammen? Vores arbejde med de processer anvendt på de sager, vi får ind fra Service Desk. R: Ja I: Og som sagt du må meget gerne tegne, hvis der er noget, du gerne vil illustrere. R: Skal vi sige, as is situationen fra mig set, er en.. Jeg vil egentlig kalde den reaktionær situation stadigvæk. Vi er lidt proaktive og meget reaktive i forhold til... I den forstand med remedy-sager. Vi lider under, at der kommer voldsomt mange fejl, og de samme fejl kommer flere gange, og vi har ikke nogen mulighed for at få dem rettet umiddelbart. Så som jeg siger, as is situationen for mig at se, den er i alt for høj grad reaktiv og opryddende på de fejl der kommer ind. Og fokus burde i langt højere grad være på prævention og ja.. rettelser at få rettet tingene. Men der er flere faktorer der spiller ind der, som jeg siger. Det er ikke så nemt at sige. I: Ja, jeg skriver bare ned undervejs R: Ja, og det er selvfølgelig typisk Incidents det her, som det vedrører, når jeg taler om den situation. Når vi så har klaret de Incidents som dagen/morgenen har budt på, så kan vi begynde at koncentrere os om de ting som er mindre akutte. Og det vil sige, der er en klar prioritering fra min side: Det er, at hvad der er akut, det er akut, det skal laves først. Altså, vi skal opretholde en drift som resten af firmaet nyder godt af. Det er et problem nogle gange. I: Og hvorfor er det et problem nogle gange? R: Ja, når man har sådan nogle problemer, når man har sådan nogle fejl, der dukker op, jeg vil ikke sige ud af det blå, men de dukker op, fejl som vi ikke, vi kan ikke tage højde for dem andet end at sige, de kommer, Bilag Side 87 af 185

88 når de kommer. Vi ved ikke altid hvorfor, de dukker op, men vi har nogle fornemmelser selvfølgelig om det. Lige nu der går meget af min tid for eksempel med fokus på de fejl der opstår i Edlund-systemerne eller omkring pensionssystemerne, og batch-afvikling af dem. Og nu de fejl de har givet anledning til oprettelse af problems, og der har jeg nogle gange sådan et.. Der er vi presset, synes jeg også, og håndterer de her problems sideløbende med at vi håndterer de daglige Incidents. Altså, jeg har brug for tid til at snakke med vores leverandører både på driftsiden og på udviklingssiden. Det vil sige NNIT set på driftsiden og Edlund på udviklingsiden. Og den tid jeg egentlig gerne vil bruge på at få løst det overordnede problem, den er begrænset af, at man stadigvæk skal opretholde og gøre en masse på de andre Incidents, som dukker op i løbet af dagen. Der er ikke tid til at være dedikeret til en rolle som problem manager, når du samtidig løber efter også at holde den øvrige drift oppe at køre. Det må man bare sige. Man kan så sige også, det er jo ikke altid vi har et problem at løbe efter, og så ville det være uhensigtsmæssigt hele tiden at sidde med den opgave alene. Men når man så har nogle problems, så er det sgu svært at finde aflastning på de andre daglige opgaver, det må man sige. Og så er der så den tredje del, det er det der med proaktiv og videreudviklende. Og det handler om sådan noget med nemlig at udvikle processer og udvikle vores driftskoncept er det jo for vores vedkommende primært koncentreret til. Der ser jeg, det er den tid der bliver spist. Jeg har nogle opgaver liggende som, det havde været hensigtsmæssigt at havde været lavet for tre måneder siden. To måneder siden, så skal vi heller ikke overdrive. Eller i hvert fald jeg gerne ville have lavet mere på. Og der må jeg bare sige. De har simpelthen været syltet totalt, altså den ene der skulle jeg lave noget sammen med Sofus omkring overvågning, og vi har ikke en gang holdt et møde endnu, fordi jeg tror ikke nogen af os, har haft tid til at se hinanden i øjnene på at snakke om det. I: Og I har ikke haft tid til det fordi? R: Jamen altså der har været så mange andre opgaver. Jeg har jo simpelthen været lagt ned af nogle af de her Incidents som har været på pensionssystemerne. Der er ikke rigtig overskud til det. Og så er der selvfølgelig alle de andre der kommer, det er jo også daglige møder, tidsregistreringer, afdelingsmøder, og møder med NNIT. Ja, alt det som går fra til, som man måske kunne sige fra til, men så ved man heller ikke, hvad der foregår, hvis man ikke deltager i noget af det. I: Går der generelt meget tid med møder? R: Nogle dage ja, men jeg synes ikke, det er så slemt for mit vedkommende. I: Så det er ikke sådan at... R: Altså, det kunne være meget værre. Det kunne det. Sammenlignet med Jacob, der har sådan et tigerstribet mødekaldender, så har jeg ikke rigtig særlig mange møder. Til gengæld kan man sige, de møder jeg har, de er jo sådan set også relevante for mig at deltage i. I: Det er de? R: Ja. Bilag Side 88 af 185

89 I: Det er ikke sådan, så der er en masse møder som går til spilde? R: Jeg sidder ikke og keder.. Nej, det synes jeg ikke, det ville være forkert at sige fordi altså, afdelingsmøder skal man deltage i. Der er projektmøder, idriftsættelsesmøder, som der også er hensigtsmæssige at vi deltager i for at få koordineret hvad der foregår. Der er også andre som trækker på vores tid. For eksempel har jeg haft nogle korte møder med Governance, for at tale om, altså hvor de prøver at kortlægge processer for, hvad der foregår forskellige steder omkring systemer og så videre. Og det er også hensigtsmæssigt at de bidrager til deres arbejde, plus at vi er med til at dokumentere noget, der foregår på vores område. I: Og hvis du siger Governance, så mener du IT-sikkerhed eller hvem? R: Nej det.. Er det ikke Governance der sidder med proces? Erik og.. I: Nå dem. R: Er det ikke dem der eller? I: De sidder i ledelsessupport. R: Nå for helvede.. skide være med det. Jamen der kan du bare se.. Altså bortset fra det, så synes jeg ikke, der er så mange møder, hvor jeg ikke burde deltage. Hvor jeg bare burde rejse mig og gå. Jeg synes faktisk, de er relevante, de fleste af dem. Men der går tid med det, og der går også en del tid med det. Det kan man ikke afvise. I: Så det er situationen i dag, som du oplever den? R: Ja det vil jeg sige, det er lidt sådan jeg.. Som jeg siger, jeg ser den. Ud fra min begrænsede synsvinkel. I: Hvad har det så af implikationer for den måde, vi arbejder med de her processer: Altså Incident, service request og problem? R: Jeg tror nogle gange, vi bliver lidt opportunistiske i udnyttelsen af processerne. I: Og med det mener du? R: Nu kender vi jo lidt til systemerne og også til de systemområder vi behandler. Remedy for eksempel. Det gør selvfølgelig at vi nogle gange kan finde på at gå ind og reprioritere og pille i prioriteringen af en opgave. Fordi det er nødvendigt for, som jeg siger, jamen altså, der kommer så mange opgaver ind, Incidents ind så, og service requests, så man siger, det her det må bare vente. Og det vil sige, de bliver sat og taget og så sat i pending, og så sætter jeg måske en pending 3-4 måneder ud i fremtiden. Og når den tid kommer, så kan det være jeg flytter den igen. Og det er dybt utilfredsstillende, jeg ikke har tid til at følge op på.. Og mange gange så kan det være, det kan være en dokumentationsopgave, hvor det for eksempel, som jeg siger, de bliver bare skubbet langt ud i fremtiden, fordi der er simpelthen ikke.. Planlægningshorisonten gør ikke at jeg kan sige, at det her kan jeg lave næste uge, for i næste uge der tør jeg ikke planlægge med det, men hvis jeg har tid, så tager jeg dem. Nu har der været et stykke tid, hvor der har været mindre.. To, tre, fire uger, Bilag Side 89 af 185

90 hvor der har været lidt mindre projektbelastning, og så har jeg haft tid til at prøve at dykke ned i Remedysager. I: Og du siger, det er dokumentationsopgaver? R: For eksempel.. Det er for eksempel dokumentationsopgaver, men det kan også være andre ting som man simpelthen ikke har nået at kigge på, på den dag hvor de er kommet ind. Så har man lige pludselig en oprydning af remedy-sager fra hele sidste uge for eksempel. De små sager, som man siger, hvad skete der egentlig her? Hvad.. var der nogen som fik undersøgt det? Nå, det var der ikke, så må vi hellere kigge det igennem, gøre det, se hvad der skete. Er der noget der skal ryddes op? Og nogle gange dukker der sådan noget op.. Hold da helt op, får vi gjort noget ved det? I: Altså dukker op, det vil sige, det er noget, der har ligget, som så dukker op igen eller? R: Så dukker der sådan en som OPD-breve op. På et tidspunkt så.. Den har været oppe flere gange. Vi har behandlet den akut sådan lidt og troet, at det var nok, men der var ikke nogen, der havde tid til at dykke ned i den, så jeg kan jo kun sige, at den opgave opstod allerede.. ja, jeg vil tro i efteråret Og der er ikke nogen, der har haft tid og overskud til at kigge ind i den dybere end at sige hov, nå vi har fundet filen og så siger nå okay, så må vi få ryddet op i den og så har de fået sendt en fil, og så er der bare ikke sket mere. I: Og hvad går det så ud på, hvis du skal uddybe.. R: Jamen det er jo så, altså vi har kun reageret på det ene problem, det Incident, som jeg siger, og der er nogen, der så har fundet en løsning på at få sendt nogle breve til nogle kunder. Fint nok, så har vi glemt alt om den derfra, fordi så er det blevet sådan væltet hen over af øvrige ting, der er kommet af projekter og idriftsættelser og Incidents og så videre. I: Så det vil sige, det er nogle breve man sende ud til.. R: Kunderne? Ja. I: Og det gør man? R: Det gør man ved.. Jeg tror faktisk, det kører en gang om måneden. Og der er kommet et Incident måske hver anden måned, hver tredje måned, og så har kundeområdet oplevet at hov, de har vidst ikke fået noget brev. I: Og hvad så? Så løser man det det konkrete R: så har man fundet filerne og så har man fundet.. Så er der nogen, der har fundet ud af at tage de her filer og sende nogle breve ud til kunderne. Men det præventive ligger i, at vi har ikke været ude at finde det underliggende problem. Det er først her for nyligt hvor Mia er blevet sat på sagen og er begyndt at grave dybere i at forstå, hvad der er sket. At vi så har gravet så meget ned i den, at vi har fundet ud af, at det her var faktisk en opgave, som aldrig er blevet leveret i projektet. Aldrig lavet færdig. Bilag Side 90 af 185

91 I: Og hvad har det så af implikationer? R: Ja, lige nu der har det den implikation, at nu begynder man selvfølgelig at få lavet, det der mangler at blive lavet i det her proces-flow, sådan at det rent faktisk bliver automatiseret, og der kan ske den her print af breve en gang om måneden osv. I: Men hvorfor skulle der det? Altså, hvorfor er der en, der skal bruge tid på, at grave sig ned i og finde ud af.. Kan man ikke bare løse fejlen, når den opstår? R: Jo måske, men det har vi ikke haft brugt tid på. I: Nå nej, men jeg mener altså.. R: Enten så har vi ikke set, at der var en underliggende fejl, eller også så har vi ikke set, at der var et hul i processen der. I: Men jeg mener, når nu der opstår og man ser fejlene komme op til overfladen, så løser man dem der, så er det problem løst, og når det så kommer næste gang, så gør vi det igen. Hvad er grunden til, at man gerne vil grave så dybere ned og løse det, som du siger, der hvor problemet egentlig opstår, hvor problemet egentlig er? R: Jeg har en holdning til, at de ting vi har kørende i IT, de skal automatiseres. Det er sådan et helt grundlæggende princip, at hvis vi kan automatisere det, hvis vi kan få det til at glide automatisk igennem, så skal vi ikke side og håndholde det. Det vi så har problemet med, det er at nogle gange, så har vi så fået nogle projektleverancer, hvor der er ting, der er blevet afgrænset fra projekterne. Eller der er opstået fejl efterfølgende i det der er kommet fra leverancerne. Du ved, der er nogle fejl her som gør at det kører bare ikke på den rigtige måde. Ja, det er svært at sige andet end, at det kører bare ikke på den rigtige måde. Det kommer ikke rigtig ud af det. Eller der sker noget forkert. Og så laver man nogle håndholdte kompenserende handlinger, som det så smukt hedder, hvor man kompenserer for det, der ikke fungerer, eller det, der ikke er blevet automatiseret. I: Og hvad er så problemet med det? R: Problemet er, at vi sidder faktisk og laver driften. Og det er et stort problem, for det tager jo tid fra de fremadrettede løsninger og det som.. hvor jeg ser, vi har større værdi ved at få videreudviklet de koncepter vi har, og også de processer vi har. Vi bruger også meget tid på for eksempel at få rettelser igennem. For ikke at skyde andre ting i skoen, så har vi jo ikke nogen procesunderstøttelse i hele idriftsættelsesprocessen. Der findes et stykke, jeg var lige ved at sige A4-papir, men det er så som skabelon i Word, og den kan du så udfylde og sende til en mailbox. Og den mailbox er så en blackbox, fordi så har du sendt den til Change Management eller Service Desk, og så sker der et eller andet ved den der. Hele det her flow her, det er jo sort. Altså i en hver anden forretningsproces ville man jo kigge at procesunderstøtte et eller andet workflow-system eller lignende. Det er der bare ikke her. Vi har ikke nogen dokumenthåndtering, vi har ikke Bilag Side 91 af 185

92 nogen procesunderstøttelse IT-mæssigt, og det vi gør i IT. Men vi leverer noget til forretningen som kunne gøre det. I: Ingen dokumenthåndtering? R: Vi har ikke nogen altså.. Jo, vi har de der ad hoc oprettede Sharepoint Sites, men det er jo for dem, der ved, at de eksisterer. Der mangler simpelthen en central processtrategi og procesunderstøttelse i hele IT. Altså hvis vi havde tid, så skulle vi også kigge på at forretningen har også brug for en ny procesunderstøttelse og dokumenthåndtering. Og til erstatning for det eksisterende CUBUS-system som leverer processer og dokumenthåndtering. Og der kunne man sagtens bruge det samme sikkert bare implementeret i forskellige instanser. En til IT og en til kundeområdet primært. I: Hvis vi så skulle prøve at opridse, hvad er de største udfordringer i den måde, vi arbejder på med de ting i dag? Hvad ville det så være? R: Det er det politikerne kalder et godt spørgsmål. I: Ja? Altså set i procesperspektiv. Den måde vi behandler de opgaver, der kommer ind. R: Det synes jeg faktisk ikke, er et nemt spørgsmål fordi det.. På den ene side så er det et spørgsmål om at skaffe overblik over hvilke opgaver, der er. Og der er selvfølgelig.. Det overblik er selvfølgelig et spørgsmål om, hvad er der af akutte opgaver, hvad er der af efterfølgende, langsigtede opgaver. I: Og hvad er langsigtede opgaver? R: Det er så der hvor vi siger: Godt nok har vi løst den akutte, men den langsigtede løsning på det problem, det Incident, den skal også findes og falde på plads. Og der synes jeg mange gange vi havner i.. Specielt i det langsigtede problemløsning.. Der havner vi i det der med at, det er ikke en prioriteret opgave at få altså.. Vi får ikke vores prioriteter rigtig meget igennem. Det kan godt være, vi har forslag til, hvordan man kan løse tingene, men det er ikke altid, at det er noget som nogen synes, man skal bruge penge på på nuværende tidspunkt. Ellers også skal man se frem til, at der går et halvt til et helt år, til vi kan komme med i en projekt-release. I: Og det vil sige at så har man.. så laver vi en løsning, som man så lægger med i den projekt-release? R: Ja, det vi vil komme med et eller andet, som vi har bedt projektet om at få med i en projekt-release eller en måneds-release, hvis dem der skal udvikle det, har tid til at lave det. Og det der sker mange gange, det er for eksempel at pensionssystemerne, eller dem som vi selv har udviklet, eller dem som Edlund står for at udvikle, de har jo ikke tid til at tage nye opgaver ind. De er jo fuldt committed til at levere til projektet. Projektet har næsten brugt tiden. Og så kommer vi med en eller anden ændring, som vi siger, vi synes det ville være rigtig smart, hvis vi fik lavet den her ændring, fordi så slap vi for at sidde og lave en kompenserende handling. Eller rette et problem så vi slet ikke fik fejlen længere eller sådan noget. Men det har så også nogle konsekvenser nogle gange fordi.. Vi må også erkende, at får vi leveret noget, så skal det testes. Og det skal vi også finde tid til. Eller finde nogen der har tid til at teste for os. Og det giver så en anden problema- Bilag Side 92 af 185

93 tik, og det er at det nuværende driftsetup, det er ikke en del af FoI-testen nogensinde. Den nuværende driftsetup bliver testet i preprod, hvilket er på et tidsspunk hvor, du ikke kan få leveret en ny version, hvis det finder en fejl. I: Det vil sige at den test, den er der heller ikke afsat tid til? R: Jo jo, der er sådan set afsat tid til den, normalt finder man tid til at lave den test i preprod. I: Men FoI-testen, hvad med den? R: FoI-testen den.. Vi mangler simpelthen et test-setup hvor man tester driftsafviklingen helt inde i FoItesten og får afprøvet nogle ting der inde, og det er ikke lavet i dag. Det kan for eksempel være alle de kørsler, der ligger i Edlund-systemerne via web services, at få dem afviklet og få dem ind i autotesten, der kører. Det ville være perfekt, men det eksisterer ikke i dag. I: Og hvad betyder det så, at man ikke har det? R: Det betyder så, at når vi får en ny version af for eksempel Edlund-systemerne, og vi tester driftsafviklingen og kørslerne i preprod.. Hvis vi finder en fejl på det tidspunkt, så kan vi være et hundrede procent sikker på, at den fejl kan ikke nå at blive rettet, inden vi skal gå i drift. Det er der ikke lavet plads til. Preprodforløbet er lavet til at NNIT kan nå at installere tingene og finde ud af, hvad der er af installationsproblemer og få rettet dem og få gjort det korrekt. Men det er i realiteten det første sted, hvor vi tester driftsafviklingen, både med Ctrl-M og med alt det andet, som ligger der i. I: Hvis vi lige skal prøve at vende tilbage til.. Nu siger du, det.. Tiden til at finde det tilbundsgående problem, hvis der opstår et eller andet, der kommer op til overfladen, den er nedprioriteret? Hvad betyder det så? Hvad medfører det, at vi ikke har tid til at finde roden til problemet og løse det, når det opstår, men i stedet bliver nødt til at lægge det ud i fremtiden.. at det må vi kigge på en anden dag, når vi har tid? R: Altså, den umiddelbare konsekvens er at typisk så kommer der en Incident igen. Nogle gange så ved vi den kommer, og andre gange så kommer den så igen med lidt mere tilfældigt mellemrum. Det afhænger af selvfølgelig af fejlen. Typisk så betyder det bare, at vi kommer til at lave den samme fejlrettelse eller kompenserende handling, eller hvad du vil kalde det, igen og igen, indtil vi finder tid til dels at få undersøgt tilbundsgående, hvad der er årsagen til fejlen, men endnu værre at vi kommer til at sidde og lave den samme kompenserende handling, indtil vi kan få leveret noget. En rettelse, en patch, et eller andet som løser problemet permanent forhåbentligt. Og i sidste ende er nok det der tager længst tid.. altså mange gange så finder man hurtigere en løsning, og så sidder man lang tid og venter på, at den løsning bliver implementeret. Man kan sige, det er jo ikke kun vores ressourcer, der ikke er nok af. Der er heller ikke sat nok ressourcer af til at få leveret de fejlrettelser eller ændringer som vi synes er hensigtsmæssige for at få tingene til at køre fornuftigt. Og når jeg siger fornuftigt, så er det selvfølgelig med mindst muligt indgreb manuelt både fra driften og fra vores side for at få tingene til at køre igennem korrekt. Man skal jo heller ikke være i tvivl om, at vi er der for kundernes skyld, og vi skal sikre at de kunder, vi har, og vores rigtig kunder ude i verden, Bilag Side 93 af 185

94 at de får de ting, de har krav på, og man kan sige, det er der, vi lægger den største del af vores tid på at sikre det. I: Men hvis man så skal koble det til det, du sagde med de der breve før, som man sender ud til kunderne, hvorfor er der så ikke tid til at løse sådan nogle problemer? Altså finde årsagen og rydde op sådan så fejlen ikke opstår igen. R: Det er en prioriteringssag. Du prioriterer rettere sagt at få de akutte sager afklaret.. altså, der kommer sager ind hver dag stort set. Der er dage, hvor det ikke går galt, men det tæller vi på en hånd, tror jeg. Så er der dage, hvor det går mere galt end andre, og så har vi ikke hænder nok til at tælle alle de problemer, der vælter ind over os. Men det primære er jo egentlig, at får du ikke på dagen undersøgt den Incident, og fundet en årsag, dybere årsag, så er det ikke sikkert, du kan nå at prioritere det næste dag, eller hvis du prioriterer det til næste dag, så er der måske noget andet, hvor du siger, så må jeg lade være med at undersøge de Incidents, der kommer ind der, eller droppe et møde eller et eller andet. Det er hele tiden et spørgsmål om at prioritere tiden i forhold til, at du har brug for at bruge den ekstra tid til at grave dig ned i det. Nogen gange har du også brug for at tale med dem, der har været med i processen og udviklet systemet, og det tager også tid at få det på tale og få de informationer ud om, hvad er der egentlig meningen, der skulle ske, og hvorfor gik det så galt. I: Hvis nu vi anskuer de her to elementer som to forskellige ting, og det er jo også understøttet af to forskellige processer: Incidents og Problems. Det ene det er her og nu, afhjælpning af en fejl, og det andet er at grave sig ned i at finde roden til problemet. Hvordan kunne man så løse det, at der er så mange sager og.. du giver udtryk for, at hvis man ikke når at løse det, der kommer ind på dag et, så når man det heller ikke dagen efter fordi, der er der kommet noget nyt, man skal tage sig af. Så enten så skubber man det nye foran sig, eller også så lader man det gamle ligge, og så bliver det ikke gjort. R: Ja, eller også så lader man være med at kigge på det nye, og så kigger på det gamle. I: Men hvordan kommer man ud over det problem at der hele tiden opstår nyt samtidig med, at man ikke har tid til at kigge på det, der opstod i går? Eller at man blive nødt til at skubbe det nye frem til i morgen, hvor man så ikke har tid til at kigge på det, der kommer der. Altså hvordan kan man omgå den problematik? R: Det er et godt spørgsmål.. Tarveligt.. Noget af det man bruger tid på at undersøge.. Altså nu.. Det er jo ikke alting, der bliver til et problem. Fordi nogle gange så tager det bare tid at undersøge en Incident. Så undersøger man Incident lidt ud over bare at få løst det akutte Incident, men for at det skal blive til et problem eller.. Det kan godt være man finder en løsning og finder et problem, men det er ikke nødvendigvis noget som gør, at det bliver til et problem som man så dykker mere ned i. Det kan godt være, man er nødt til det, men det er ikke sikkert, man lige får gjort det på det tidspunkt, hvor Incidenten er løst. Gør vi det, så er det, vi måske kan oprette et Problem, eller lave noget, som gør at vi kan arbejde med det her Problem, og meget af den tid, der går med sådan et Problem, det er at finde ud af, hvad er det egentlig, der skulle Bilag Side 94 af 185

95 foregå, hvad er egentlig den forretningsmæssige og den IT-mæssige del af processen, som skal foregå, og finde dokumentationen for det. I: Altså, hvad mener du med hvad der skal foregå, hvad der burde være sket? R: Hvad burde der være sket, ja. At finde dokumentationen, det er nogle gange et spørgsmål om at kende den rigtige mand, eller finde det rigtige SharePoint-site, eller gætte sig til, at det er nok det her, der burde være foregået, fordi det er det, vi gør med alle andre af den her type ting. Meget af min tid burde faktisk gå med at læse dokumentation, hvis jeg kan finde den. I: Det du siger med at finde den rigtige mand, er det så fordi, altså, hvorfor kan man ikke gå et andet sted hen, hvorfor skal jeg spørge lige præcis Lars om noget? R: Det skal du heller ikke.. I: Du siger, at meget af det er bundet op på, at man skal finde den rigtige mand eller det rigtige sted, hvad er grunden til det? Er det fordi, det ikke står skrevet nogen steder? R: Måske står det skrevet nogle steder, men det er ikke altid at den dokumentation, der ligger til grund og er lavet, at den er fyldestgørende, eller at den indeholder de informationer som vi har brug for for at kunne vurdere, om det her det er et problem, som vi skal dykke videre ned i. Altså, der findes for eksempel på MOF-siden, findes der masser af programmer hvor vi.. Vi kan godt finde noget jobdokumentation på at sige.. hvad gør de sådan overordnet, men vi har ikke nogen ideer om, hvad de gør på designplan. Det var en af intentionerne med dem. Det kan godt være, der findes noget dokumentation, det gør der sikkert på mange af dem. Det er ikke noget som lige er pænt og velordnet som for eksempel på PSL-systemerne som trods alt har fået en del kravspecifikationer til rådighed over, da de lavede PSL-migreringen. Så nogle gange så sidder vi tilbage med at kigge på en blackbox, hvor vi ser et gråt omrids og så begynder vi at stille spørgsmål til andre mennesker: Hvad er det for nogle problemer, hvorfor opstår det her? I Incidentprocessen, der har vi ikke mulighed for at løse det, der er vi nødt til at lave en service request efterfølgende, for at finde ud af om vi har et problem, som vi så kan oprette efterfølgende. Og hvis vi mener, vi har fundet ud af, vi har et problem, så kan vi måske finde nogle ressourcer til at løse det problem. I: Og det er så også et problem? Det med at finde ressourcer? R: Det er altid et problem at finde ressourcer. De er jo.. lykkeligvis er de jo brugt, eller bliver brugt. Ellers ville folk sidde og trille tommelfingre. Det er ikke mit indtryk at folk sidder og triller tommelfingre heller. Det ville selvfølgelig være en trist situation. Men som jeg siger, det er et behov for at finde en ressource ud af det blå, som ikke er prioriteret, som egentlig ikke er sat tid af til at lave den undersøgelse som er opstået uden for projektregi. Hvis der ligger et projekt.. Hvis vi havde et driftsprojekt eller lignende, hvor vi hele tiden havde nogen, så ville der måske sidde de rette ressourcer klar til at løse alle vores problemer. Men sådan prioriterer man ikke. Det er prioriteret, at projekterne har de ressourcer, de skal bruge og så er der sat noget tid af, men det er sådan lidt ad hoc jo. Bilag Side 95 af 185

96 I: Skulle det så være en person, der sad i driften? Altså sad i vores område og kun beskæftigede sig med, hvad der opstår, efter der bliver sat nye ting i drift, eller skulle det være en del af projektet at man varetager en eller anden form for det, vi kalder en hypercare-periode, hvor man tager sig af de fejl, der måtte opstå umiddelbart efter idriftsættelsen? R: Umiddelbart tror jeg, det er bedst, hvis projektet leverer nogle ressourcer, som er med i problemløsningen, fordi det tager også noget tid at overlevere noget af den viden er noget af de beslutninger, der er taget i projektet. Det kan godt være, de har nået at skrive ned, men vi skal også nå at læse den, når de leverer den, og vi har ikke nødvendigvis nået at læse alt dokumentationen og forstået hvad, der ligger i den. Der er en periode, hvor der er brug for et tæt samarbejde mellem projektafleveringen, dem der har været med i udviklingen af det, der er leveret hvis der er problemer med det vel at mærke, hvis der ikke er nogen problemer, er det måske ikke så interessant men der er en periode, hvor det er interessant at arbejde tæt sammen med dem, som har leveret på det system eller den delleverance, eller hvad det måtte være, hvor vi bruger tid på at samle deres erfaringer få overført dem til os, og de kan hjælpe med at fejlsøge og forklare: Hvad er det, der går galt? Det er en del af vores vidensopbygning, det er at vi forsøger at bevare et eller andet holistisk billede af, hvad det her system, det foretager sig, og hvad der sker i systemerne. Det er jo sådan en del af vores speciale, det er at vide, at når der kommer noget ind, og det går galt her, hvorfor er det så vigtigt? Men også lige så meget at forstå, hvad er det der foregår, fordi det påvirker andre ting som foregår.. Eller også så mange gange sker de i en bestemt sekvens hvis man udfører det her job, så skal man også udføre det næste job og det næste og det næste.. fordi ellers så har du ikke leveret slutprodukter til de afdelinger og kunder og så videre. I: Så det er noget med et fokus på ikke kun IT men også forretningen og kunder? R: Du er nødt til at kende begge dele og have fokus på begge dele. Hvad er det forretningen skal bruge, hvorfor gør man det her? Man har brug for noget.. Overordnet set så skal vi hele tiden kende de strategiske mål, og derudover når de strategiske mål er sat, så skal vi kende de taktiske mål, og det er nogle gange på ugeplan og dagplan. Hvad er det, der er vigtigt for forretningen lige nu? Altså vi kan jo se det for eksempel med pensionsoversigter, oprydning, den sidste del af POS2012, sidste del af det der kørte ind i januar og februar og marts, der gik det op for os på et tidspunkt omkring idriftsættelse og planlægning og så videre, at forretningen de ikke havde fået kommunikeret videre, at de havde behov for at have åbent 24-7 næsten, eller i hvert fald syv dage om ugen. Og det er lidt svært, hvis man har en idriftsættelse, der lukker systemet fem dage eller sådan noget. Hvis ikke vi får de oplysninger, så kan man godt sidde og planlægge i blinde. Eller hvis de ikke får videregivet dem eller kun giver dem en dag ad gangen og siger: nu skal vi have åbent lørdag-søndag her, jamen hvad så med næste lørdag-søndag? Nå, der skal vi også have åbent. Okay, fint. Så der ligger også nogle andre hensyn at tage der rent tidsmæssigt, hvad vi kan gøre, når vi arbejder med systemerne. Bilag Side 96 af 185

97 I: Hvis vi så skulle prøve at pege på nogle forbedringstiltag. Hvor kunne vi gøre det her.. altså hvordan kunne vi gøre den situation, der er i dag, med de udfordringer vi har i dag, bedre? R: Altså ud over den der hypercare-periode, eller hvad du vil kalde det, hvor der skal være et samarbejde mellem projekt og forretning eller projektet og os, så er der en eller anden form for samarbejde med forretningen. Altså på mit område har jeg bare brug for at vide, hvad er det, der foregår både dag til dag men også på uge og månedsbasis. Brug for at kende de planer, som ligger i forretningen. Hvis vi for eksempel ikke ved at kundeområdet skal køre en kampagne, eller hvis vi ikke ved at deadline for en eller anden udsendelse er den 15. juni eller sådan noget, et eller andet som de skal have ud der, så kan vi jo ikke planlægge noget som helst efter det. I: Når du siger udsendelse, så mener du udsendelse af breve? R: For eksempel breve ja ja, det kan også være udbetaling af et eller andet beløb eller et eller andet som de har planlagt. Hvis de ikke filtrerer ned gennem, og hvis man ikke har de oplysninger, så er det svært at koordinere de handlinger, der ligger i det. Det er svært at prioritere, hvad der er vigtigt i det. Det er også derfor, det er vigtigt, at når vi har identificeret et eller andet problem, vi får fundet ud af, hvad er forretningens holdning til, hvor vigtigt det her, det er. Og det gør det ikke nemmere at rent procesforbedre. I: Hvorfor gør det ikke det? R: Det betyder, at der bare er flere spillere med i processen som bliver koordinationspunkter, fordi du skal bruge mere tid på at rende rundt og tale med folk og lave projektledelse. I: Så det er ikke løsningen at procesforbedre, men hvad er så løsningen? R: Jo, det kan godt være, det er løsningen, men jeg siger bare, det er ikke nødvendigvis noget, der gør det nemmere at inddrage flere mennesker i processen. Men jeg sidder lige og overvejer, hvad kan man gøre rent procesmæssigt. I: Ja, det er nemlig det, jeg egentlig vil frem til. Hvordan kan vi forbedre det arbejde, vi udfører i dag med de processer og håndteringen af de henvendelser, der kommer til os primært fra Service Desk? Altså hvad skal vi gøre anderledes, eller er der noget vi kan gøre anderledes for at skabe mere tid til for eksempel at løse problemer frem for kun at tage de akutte fejl? R: En ting man kan gøre.. Man kan have nogle medarbejdere som sidder, når fejlen dukker op og kan løse fejlen med det samme. Det kræver selvfølgelig at de ved, hvad det går ud på. Det kræver at de har en altomfattende viden om, alle de systemer, som vi kunne få fejl ind på, og ved hvordan de hænger sammen og hvad, der sker med dem. Det svarer til, at vi sidder i Service Desk og frontline-medarbejdere. At vi sidder i first line og siger det der, det løser vi med det samme og får det væk, og hvis det dukker op igen, så kan vi godt.. Så er vores hukommelse lang nok til at sige, at det her,det har jeg set før. Det irriterer mig, nu gider vi ikke løse den her længere, den lægger vi over og siger, det er et problem, nogen skal undersøge den. Det var det første trin. Det er simpelthen, at der er nogle, der fanger og løser problemerne frem for bare at Bilag Side 97 af 185

98 registrere og indsamle information og sende videre. Selvfølgelig kan det være overvældende, at der kan komme så mange fejl ind, så man ikke når at kigge på dem alligevel, men det vigtigste ville nok være at løse nogle af de her med det samme og håndtere dem. Hvis vi skulle sætte os derud i Service Desk, så ville vi komme til at bruge tid på at registrere, eller så skulle vi sidde tættere på nogle gange. I: Men hvis vi sad i Service Desk, hvem skulle så lave det, som vi laver i dag? R: Så tror jeg, der var andre, der ville komme til at lave det. Eller også så, og det er så problemet med den måde, man har defineret Service Desk på. Man har defineret Service Desk som et sted, hvor man registrerer og måske løser nogle af de Incidents, der kommer ind, men primært som et sted, som jeg ser det, et sted hvor man registrerer og prøver at skaffe oplysninger om, hvad fejlen er, og så sende den videre i en proces. Og værdiskabelsen ligger der i, jo bedre problemet er beskrevet, jo dybere det er beskrevet, jo større chance er der for, at det næste led i processen, det vil sige os, kan gennemskue hvad, der er gået galt. I: Hvem er så det, der skal beskrive det problem? R: Ideelt set så ville Service Desk levere den beskrivelse på baggrund af det, der er kommet ind på grund af det, som brugerne fortæller dem. Reelt set, så kan man sige, hvis Service Desk-medarbejderen ikke ved noget som helst om systemet andet end navnet, så har vedkommende måske ikke en chance for at stille nogle fornuftige spørgsmål eller forstå om de svar, der er kommet tilbage er fornuftige, og nogle gange så ved man godt, at svaret ikke er fornuftigt, men på trods af de måske har en service-instruktion, så er det ikke altid, de kan skaffe de svar, som måske var interessante for det bagvedliggende problem. I: Og det vil sige, at der kommer en sag til os, som mangler oplysninger? R: Enten mangler der oplysninger, eller også så er vi nødt til at grave videre ned i det, for at finde de oplysninger, vi har brug for. Og det kan for eksempel være, at vi skal have adgang til noget dokumentation omkring.. Hvorfor.. Det her job, hvad gør det af procesflowet her, hvor er det på vej hen ad, hvad skal det gøre, hvad er dokumentationen bagved. I: Hvad betyder det så for os, at vi får sager ind som har mindre omfangsrig dokumentation, end de kunne have? Altså du siger, hvis nu vi sad i Service Desk, så kunne vi hurtigere løse sagerne. Hvad betyder det, at vi sidder et trin længere bagud, og vi har en Service Desk i mellem? R: Vi er nødt til at forlade os på, at Service Desk kan indsamle de informationer, vi har brug for. At vi ikke selv skal gå ud og samle de rigtige informationer sammen eller selv finde dem, bruge tid på det. I: Så det vil sige, hvis Service Desk ikke gør det, så skal vi bruge mere tid på at finde de oplysninger som.. R: Vi kommer til at bruge tid på og finde flere informationer om, hvad det er for en fejl. Det kan også godt være, det er den rigtige måde at gøre det på. Service Desk har i hvert fald ikke altid mulighed for at hive de samme informationer ud af systemerne, som vi ville kigge efter. Det er også et spørgsmål om fejl hvad er det for en fejl, der er der, hvad er det for et system, der er fejl på. Hvad har vi for nogle muligheder for at undersøge det. Jeg synes nogle gange så går der.. Der skal som regel en del Incidents til for at der bliver Bilag Side 98 af 185

99 lavet et problem. Men selv når der er et problem, så er der måske noget i processen omkring, hvordan fejlsøger man sådan et problem, hvordan undersøger man problemet hvor vi, rent metodisk forlader os på, hvad den enkelte person ved og gør og har af erfaringer. Der er ikke nogen systematiseret oplæring eller videnoverdragelse om, hvordan man.. Hvordan finder man et fejl i et system. Det har jo selvfølgelig også noget at gøre med.. Det kræver et bredt spektrum af kendskab til dels fejlsøgningsprocesser - hvordan finder man ud af, om der er et problem. Men også.. Hvad gør man, når man finder et problem.. Har du et system, hvor du kan gå hen og afprøve, at det er et problem? Kan du reproducere det? Kan du vise det problem? Kan du dokumentere, hvad der skal til for at gøre det? Har du et sted, hvor du kan lægge en test ind så andre kan tage det bagefter, når de udvikler det og teste det og så videre? Og hele den proces der, det er jo noget af det, som vi forsøger at få tid til at gøre. I: Så hvis vi skulle binde det op imod det tredje punkt her, som er forbedringer, hvad kunne vi så iværksætte af tiltag for at forbedre den nuværende situation? Hvad skal der til for, at vi kan flytte tid fra brandslukning, altså at løse de akutte fejl, når de opstår, til system.. eller fra symptombehandling til helbredelse? R: Det der er.. Altså, du kommer ikke ud over symptombehandlingen, den kommer hver eneste gang, den samme fejl opstår. Der er formentlig de samme ting, man skal gøre for at få rydde op og komme videre. I: Jamen formålet med at grave sig ned, var det ikke at løse problemet, så det ikke opstår igen? R: Jo. I: Hvordan kommer vi så hen i den situation, at når vi ser et fejl, så løser vi den, sådan så den ikke sker igen, fremfor vi blot tager de akutte og så haster videre til det næste? Fordi du foreslog noget med, at vi burde sidde i Service Desk. R: Ja, det er den ene side af sagen, den kunne tage nogle af dem. Den næste, de fejl, der kommer igen jævnligt, eller ugentlig og dagligt, der vinder man utrolig meget ved at have en hurtigere idriftsættelsesproces og løsningsleveringsproces, kan man sige det på den måde? Når først vi får identificeret, at der er et problem her, får det dagligt, selvfølgelig skal det løses akut hver dag sikkert, men derfra og til at få leveret en løsning. Al den tid der går med at få leveret løsningen, der sidder man dagligt og laver akut arbejde stadigvæk, det er spildtid. Eller rettere sagt, det er tid som.. Jo kortere du kan gøre det proces fra du har identificeret, hvad problemet er til du får leveret en rettelse, jo mindre tid skal du bruge på at sidde og laver de daglige kompenserende handlinger. Så en hurtigere proces omkring pasning, få rettet fejlen, få den testet og idriftsat, jo mindre tid skal vi bruge på efterfølgende i uger eller måneder, og sidde og lave kompenserende handlinger. Det er jo bare for et problem. Hvis der så kommer et nyt til lad os bare sige en gang hver anden uge i seks måneder, så er der ikke meget tid tilbage efter seks måneder, og så er det ikke sikkert at du får alle rettelserne på de her Incidents med, så får du måske kun halvdelen leveret. Det bærer du så videre til de næste seks måneder, hvor du sidder og bygger op måske hver anden uge igen med et nyt Incident, der kræver en kompenserende handling. I: Og det seks måneder, det er så de der.. Bilag Side 99 af 185

100 R: Ja, det er jo så bare et eksempel med projekt-release. Nu er der nok kun fire måneder imellem, men det er så også I: Men det er en periode.. R: Der er en periode det, hvor efter de er identificeret fejlene, så går der bare tid med at håndholde noget som.. det kunne godt være man kunne lave noget kompenserende handling der, som kunne automatisere det. Det forsøger vi så også så vidt det kan lade sig gøre i en eller anden grad men stadigvæk. Vi står stadigvæk tilbage med det her med, at der er en periode hvor du simpelthen.. Du håndholder ting, som der egentlig er en løsning på, men du bliver ikke aflastet som sådan, for det betyder bare.. Der kommer hele tiden nye ting til, der æder den tid, du skal bruge til at problemsøge og måske forbedringstiltag og nye udviklingstiltag, som jeg siger. Det æder den tid, som du ville bruge på det i stedet for. Respondent: Damsgård, Contract Manager I: Formålet med det her interview er jo at afdække dit synspunkt på hele samarbejdet mellem PenSam og NNIT med henblik på de her processer, som vi arbejder efter i ITIL: Service Request, Incident og Problem. Det er de tre, det går på. Og grunden til at du er indkaldt, det er, at du sidder med kontrakten, så det er sådan i det perspektiv, det skal foregå i dag. Metoden er sådan noget med at man må tegne og fortælle. Man skal ikke tegne, men det må man gerne, hvis man vil, så derfor har jeg taget noget A3-papir med, og der kommer til at være tre faser. Det ene det er, hvordan ser det ud i dag, det andet er, hvad har vi af udfordringer, og hvad kan vi gøre for at afhjælpe dem, og det tredje er, hvad kunne vi se af forbedringstiltag i fremtiden. Og så går det sådan set bare på, hvad er dit synspunkt på hele det her univers, startende med hvordan er situationen i dag. Og jeg skriver lige ned undervejs, men jeg lytter til, hvad du siger, så det er bare.. Jeg tager lige nogle noter, for så er det nemmere bagefter. Og du må som sagt meget gerne tegne det, som du fortæller, for så kan det bruges til at understøtte. R: Men hvad er det, du godt vil vide eller.. Du kommer nok til at sætte nogle flere ord på, fordi sådan kontraktuelt, der kan vi jo gå ind og se hvordan vi er dækket på de tre ydelser, og der ligger der jo nogle månedsrapporter, der siger hvordan, det ser ud på de ydelser. I: Men hvordan ser du, at det ser ud? Hvordan ser den samarbejdsmodel det univers ud i dag ud fra dit synspunkt? Hvordan fungerer det i dag? R: Jamen i virkeligheden så har jeg jo ikke specielt meget fingrene i, hvordan det fungerer i dag, fordi de processer er forankret i jeres afdeling og ikke hos mig, så jeg har været med til at designe det kontraktuelt kun, og det jeg så efterfølgende laver er udelukkende mappet op mod det kontraktuelle: Får vi den ydelse, som vi har aftalt? Bliver den leveret og bliver den leveret med de KPI er, som har været sat op for ydelsen. Og hvis den ikke gør det,så er der nogle bodsbestemmelser, som træder i kraft, og hvis de bodsbestemmelser kommer for tit i kraft, så er der et issue, som vi bør diskutere også kontraktuelt. Bilag Side 100 af 185

101 I: Men du sidder også med i nogle af de her møder, transitionsgrupper og så videre. Så du har jo alligevel et indblik i eller en oplevelse af, hvordan samarbejdet fungerer, og hvordan situationen er. R: Ja, altså der har jo været lagt et stykke arbejde fra transitionens side at overføre de ting, der har været nye af Service Desk IT-teknik og brugeradministration, at de er blevet overført på en god måde, og i den udstrækning, vi har haft fantasi til at forestille os hvilke processer, der skulle bruges i den anledning, der har vi bidraget til det på hver vores side. I: Og når du siger overført, så mener du til R: Til NNIT. Vi har jo fået en anden snitflade i og med i at vores Service Desk ikke længere er i PenSams regi, men er i NNITs regi og samme gælder for brugeradministration og IT-teknik. Og jeg tror der har været, eller jeg er sikker på, der har været nogle startvanskeligheder, men det er mit indtryk lige nu, at det går bedre specielt for så vidt angår IT-teknik og Service Desk, hvor imod brugeradministration, der er stadig nogle udfordringer, der skal arbejdes med. Og de udfordringer bliver adresseret, er adresseret. I: Det vil sige, at du har ikke, du er ikke så dybt inde i, hvordan det hænger sammen til daglig? R: Nej, det er lige præcis det, jeg har ikke.. Altså, den del af leverandøropfølgningen er jo snarere Ellis, der laver det. Jeg er mere ovre på kontraktsiden, og ikke særlig meget med i det operationelle. Jeg er nede i det operationelle så vidt angår ting, der kan relateres direkte til kontrakten. I: Det vil sige at.. R: Det vil sige, at jeg for eksempel deltager i koordinationsmøderne, fordi der kan være ting, der føres tilbage til en diskussion om, er det nu den ydelse, vi kan forvente at få, er det den ydelse, vi har aftalt at skulle have, og til styregruppeforberedelsen, der er det jo typiske spørgsmål om, hvordan ser månedsrapporten ud? Er der røde tal på nogle af KPI erne, og er det bodsudløsende? Skal vi have flyttet fokus over på nogle områder, der lider nød eller går det meget godt? I: De her koordinations- og styregruppemøder, er det det, der er formålet? Er det at følge op på, hvordan går det med kontrakten eller? R: Det er ikke alene et spørgsmål om, hvordan det det går med kontrakten, jeg tænker, at kontrakten er det sekundære, det der er vigtigt, det er at følge op på, om vi får de ydelser, som vi skal have. Og det er jo selvfølgelig bestemt via kontrakten, men jeg tænker, at det andet er det primære. Får vi ydelserne og er der problemer i forhold til det at få ydelserne? Er der problemer i processerne nogen steder? Er der noget der ikke fungerer efter hensigten? Det kan være sig i og for sig både ting, som er KPI-underlagte, og ting, som ikke er det. Fordi altså KPI erne rammer jo kun, hvad skal man sige, nogle få spidser, som vi har valgt at måle på. Der ligger jo en hel masse ved siden af det, som altså.. Vi kan jo ikke måle på det hele, og der kan jo sagtens være noget af det, som vi ikke måler på, som skal fungere, og som måske ikke fungerer, og som vi skal have fokus på. I: Hvis der så er problemer med det, hvad så? Uanset om det er målt eller ikke målt. Bilag Side 101 af 185

102 R: Jeg tænker, at det er meningen, at vi så diskuterer det i koordinationsgruppen, og hvis det volder udfordringer i en grad som vi ikke kan løse det i koordinationsgruppen, så eskalerer vi det til styregruppen. Jeg tror, det der er tænkt, med det nye styregruppe- og koordinationsgruppe-setup, er at koordinationsgruppen i virkeligheden skal lave en større del af arbejdet og styregruppen skal der eskaleres til, hvis der er udfordringer, man ikke kan løse i koordinationsgruppen, og der har det været sådan lidt, at styregruppen i virkeligheden gik ind og var for operationel. Det har der været en god grund til. Der har været nye folk på banen og nye kontrakter og transitioner osv, så det er der gode forklaringer på. I: Hvad er så grunden til, at styregruppen har været meget operationel.. Det siger du jo, er fordi.. Nye folk og nye kontrakter og det ene og det andet, men hvad er grunden til, at man gerne vil have at det er koordinationsgruppen, der laver så meget af arbejdet som muligt, som du sagde. R: Fordi at helt oplagt så sidder der jo en række mennesker med i koordinationsgruppen som ved, hvad det handler om. Altså styregruppen er jo i sagens natur besat med nogle chefer, som ikke har det.. altså som ikke operationelt har fingrene i det, der foregår. Så nummer et vil da være, at dem der er impliceret i det, og dem som har fingrene i opgaven, de kunne løse det. I: Ok, så det er et spørgsmål om at så meget som muligt skal løse på så lavt et niveau som muligt? R: Enig, ja. I: Og hvis det ikke kan løses der, så hæver man det.. R: Så må man eskalere det, ja. I: Hvad sker der så, når man eskalerer noget til styregruppen? Hvad sker der så? Er der så nogen, der gør noget? Nu siger du, at dem, som sidder i koordinationsgruppen, de har fingrene nede i det, det har styregruppen ikke. Hvad kan de så gøre? R: Styregruppen har jo det budgetmæssige ansvar og dermed også mulighed for at træffe nogle aftaler af økonomisk karakter. Er man blevet uenige om et eller andet, så er det jo typisk i sidste ende noget, der kan sættes kroner og øre på, og der kan styregruppen jo så gå ind og sige: Jamen vi bestemmer os for, at vi gør det på en eller anden måde. I: Og hvad kunne det for eksempel være? R: Den måde styregruppen forvalter det på, sådan som det ser ud lige nu, er at man vil lave en liste over de issues, der ikke er blevet afklaret. Vi har en række ting, jeg kan godt give et par eksempler på det med nogle ting, hvor vi ikke er enige. Hvor NNIT har en holdning til problemstillingen, og vi har en anden holdning til problemstillingen, og der må vi gøre det at vi hjælper styregruppen med at lave en liste over ting, hvor vi er uenige om de økonomiske konsekvenser af en eller anden problemstilling, og så vil man prøve at pulje det, og se om man ikke i stedet for nede i detaljer, hver eneste gang man støder på et problem at skulle løse det, men så i stedet for sige jamen nu samler vi til bunke i et halvt år, og så har vi måske ti problemstillinger og så laver man et eller andet kompromis ud fra det. Bilag Side 102 af 185

103 I: Og et kompromis skal forstås, som at man.. R: At man så finder ud af, hvem der skyldes hvem penge i sidste ende. I: Okay, så det er et spørgsmål om at korrigere, det er ikke sådan noget med, vi forhandler en ny kontrakt hele tiden, eller vi laver om i et eller andet? R: Nej, vi forhandler ikke kontrakten, det er ikke tanken i hvert fald. Det der kunne udløse, at vi forhandlede kontrakten, var snarere at nu var der gået nogle år, og nu var der nogle ting, hvis scope for kontrakten ændrer sig, som her, hvor vi trak Service Desk med.. Altså vi lavede et andet outsourcing-snit. En anden ting der kunne udløse det i hvert fald en justering økonomisk det er at vi jo har en adgang til at få lavet Benchmark en gang i perioden, dog tidligst 1. juli Hvis det Benchmark-resultat viser, at PenSam betaler mere end 7% mere end pier-gruppen i Benchmark, så er vi berettiget til en prisreduktion, men prisreduktionen kan maks antage 10% af kontraktsummen. Så der er sådan en hel række forbehold, der er med, men i princippet kan det lade sig gøre, og det er en del af kontrakten økonomisk. I: Så det vil sige, at koordinationsgruppen den varetager noget operationelt af noget driftkarakter, og det daglige arbejde, hvor styregruppen er på overordnet niveau og har mere økonomisk fokus? R: Ja. I: Hvad sker der så, hvis styregruppen ikke evner at løse en eller anden problemstilling? Er der et eskalationspunkt, der er endnu højere? R: Altså.. I princippet kan man sige, at hvis styregruppen også var voldsomt uenige om noget, så er den eneste sidste eskalation, det er at, PenSams direktør taler med NNITs direktør og siger der er en problemstilling her. Jeg kan ikke tænke mig andre udveje, hvis ikke styregruppen kan enes. I: Det er noget der.. Altså det er et organ, som løser knuder som ikke kan.. R: Jeg synes ikke, det er et organ. Jeg synes, det er.. Jeg ville ikke kalde to direktører for et organ. I: Det er kun de to direktører? R: Ja, det ville i så fald være Charlotte Stokkebye og så.. I: Nå ja, men jeg tænker styregruppen er.. Det er lige som der hvor ting, der går i hårknude bliver løst, og det er også dem, der gør det. R: Ja, det er et organ, der vil jeg give dig helt ret. Men går tingene helt i hårknude for styregruppen, og man vil trække chefkortet, så synes jeg ikke, det er at kalde det et organ. I: Har vi nogen eksempler, og kan man forestille sig en situation, hvor styregruppen ikke ville kunne enes om at løse et problem? Altså, er det noget der forekommer eller? De ting der bliver eskaleret til styregruppen, bliver det så også løst der? Altså bliver det resolveret? Bliver man enige om et eller andet? Bilag Side 103 af 185

104 R: Jeg tror, det er for tidligt at svare på det. Vi er ikke nået der til endnu hvor.. Altså det eneste man kan sige er, at når man trækker det kort at genforhandle kontrakten, så er det jo typisk nogle chefer, der bliver hidkaldt. Altså Charlotte Stokkebye sad for bordenden fra PenSams side under kontraktforhandlingen. I: Så det vil sige, det er det perspektiv, du ser den nuværende situation i. Hvis du skulle pege på nogle udfordringer, som vi har i dag i det setup, vi har, hvor NNIT er vores driftsleverandør, hvor vi har outsourcet en stor del af IT, i hvert fald IT-driftsydelser til en ekstern samarbejdspartner senest selvfølgelig Service Desk og så videre. Hvad ser du af udfordringer i den sammenhæng? I det nuværende setup som det ser ud i dag. R: Jamen jeg tror ikke, at man kan undgå, at der vil være en række ting hele tiden, løbende i hverdagen som volder problemer. Noget hvor vi ser på tingene på en måde og NNIT på en anden måde, og noget hvor Pen- Sam vil gerne have lidt mere, og NNIT vil lave lidt mindre, hvis man kan forstå det på den måde. Det kan også være udtrykt på andre leder. Det tror jeg ikke, man kan undgå, fordi det er en del af det, vi vil gerne maksimere vores udbytte og NNIT vil selvfølgelig gerne levere kun det de skal og ikke for meget, men hvis du sådan spørger ind til nogle faresignaler, så kan det da godt bekymre mig, hvis vi igen etablerer en maskinpark hos os selv, fordi det synes jeg er et symptom på, at tingene ikke fungerer efter hensigten. Hvis det er sådan nogle ting, du spørger ind til. I: Jeg vil simpelthen bare vide, hvad dit synspunkt er. R: Det.. Der synes jeg i hvert fald vi har en problemstilling. I: Nu siger du vi har, det er jo faktisk en insourcing i virkeligheden. At vi har haft noget ude hos NNIT, som vi nu tager hjem. Hvorfor gør vi det? R: Altså, vi gør det fordi vi ikke kan enes om pris og ydelse, og når vi ikke kan enes om det, så er det et fornuftigt træk fra PenSams side at sige jamen det er i orden, så må vi selv løse de her ting. Det er bare, set i aftalens ånd, er det ikke et sundhedstegn. I: Er det en tendens, set i dit perspektiv, at der er mere og mere, der bliver trukket hjem? R: Jeg synes, der er en række ting, vi diskuterer, hvor det er ærgerligt, at vi ikke kommer til en konklusion, inden vi begynder at trække sådan nogle våben, hvis jeg må bruge det billede. Jeg synes også hele transitionen, hvor vi har haft.. Vi har lavet nogle bestemmelser om, hvad skulle være løst i løbet af transitionen, og tingene bliver ikke løst, og tingene trækker fuldstændigt i langdrag nu, og jeg synes, det er kedeligt, at der ikke er mere fokus på at komme til vejs ende med det, sådan at vi kunne overholde aftalen på begge sider af bordet, og det er ikke fordi, jeg vil placere fejlen entydigt det ene eller andet sted, fordi jeg tror, der ligger fejl på begge sider. I: Når du siger transition, så mener du overdragelsen af Service Desk og så videre til NNIT? R: Jeg mener faktisk transitionen lige nummeret bredere. Det er en af de ting, jeg har diskuteret rigtig meget med NNIT, fordi den transitionsprojektleder, de satte på den opgave, havde udelukkende fokus på at Bilag Side 104 af 185

105 flytte de tre nævnte enheder. For mig at se ligger der en hel række ting i aftalen, altså gå ind og se på det nye bilag 33, der stater hvad er det nye indhold i den nye aftale, og de skulle jo opfyldes alt sammen, og det har jeg haft svært ved at trænge igennem med, at de skulle altså gennemføres. Og det var faktisk først da Jan trak i snoren og skrev til NNIT, at så længe de ting, der stod som værende en del af det, vi skulle have leveret som nye ting, så længe de ikke var løst, så var transitionen ikke slut. I: Og det er det, vi sidder i i dag? R: Og det er den suppedas, vi sidder i i dag. Der er jo simpelthen nogle servere som står i vores kælder, som var aftalt flyttet ud til NNIT, som en del af transitionen, altså det burde jo have været færdigt i løbet af de første tre måneder, og foreløbig er vi ikke nået til, at der ligger en plan for, hvordan man gør det. Og det ender med, at de servere, det varer et år inden de er flyttet, og, jeg mener, vi har betalt for den ydelse i et år. Jeg synes, det er.. Det er et af de forhold, som skal på styregruppens liste over ting, som koordinationsgruppen ikke har kunnet løse, for vi har ikke kunnet nå til måls med det, og det skal styregruppen tage en stilling til, hvordan.. Altså en måde at.. Man kan sige, vi kan.. PenSam kan udstille vores utilfredshed ved at sige, at det beløb, de servere repræsenterer, driftet hos NNIT, det vil vi have retur. På den måde kan man ende med at måtte gøre tingene op i noget økonomi frem og tilbage, hvis man ikke har ku.. I: Men for at drage en parallel tilbage til det, du sagde tidligere: Vil det sige at sådan nogle elementer, som det du nævner nu med de her servere, der ikke er flyttet, er det det, der gør, eller er det en medvirkende årsag til, hvis man skal sige det på den måde, at vi i større udstrækning nu begynder at tænke i de baner, at der er noget, vi vil have hjem igen? Altså er det en medvirkende faktor? Eller er det noget, der.. R: Nej ikke lige netop den her situation. Sådan som jeg har forstået det, er det fordi man ikke kan blive enige om.. Der er nogle tekniske uenigheder omkring det, som man ikke kan løse, og formentlig også nogle prismæssige. Det må du spørge Jacob om, jeg tror, han er bedre til at svare på det. I: Ja, men det er heller ikke fordi, vi skal grave os ned i de enkelte.. Det her handler mere om forståelsen af, hvordan situationen ser ud, selvfølgelig set i forskellige perspektiver. Jeg tænker bare, det kunne være, der var en sammenhæng mellem de to. Altså at det var sådan nogle ting som det, at man ikke kan blive enige om at flytte de her, at der er det, der gør, at PenSam så i højere grad tænker: Nå, men så lader vi det bare stå her hos os selv. Hvis ikke vi kan blive enige, så beholder vi det bare. R: Nej fordi aktuelt er der jo talt om, at Jacob gerne vil hjemtage nogle servere, hvor de ikke kan blive enige om.. Blandt andet tror jeg noget af det, de ikke kan blive enige om, er, hvordan teknikerne fra Jacobs afdeling skal have adgang til de servere. Og hvis man ikke kan blive enige om det helt nede på det operationelle plan, så er det et issue.. I: Så det har ikke noget konkret at gøre med transitionsprojektet. R: Nej, det mener jeg ikke, det har, det er to forskellige ting, men det har samme natur på den måde, at det er nogle ting, vi ikke enes om, og hvor der så ender med at blive truffet nogle beslutninger som overordnet Bilag Side 105 af 185

106 set måske ikke er specielt hensigtsmæssige, men som ligesom bliver til den mulighed, vi har for at agere på, at vi ikke er tilfredse. I: Og når du så siger beslutninger, som ikke er hensigtsmæssige, er det så for samarbejdet eller er det for PenSam, at de ikke er hensigtsmæssige? R: Jamen, jeg tænker, at det er overordnet set. Vi har lavet en aftale medio 2012, som gik ud på, at vi gerne ville have ryddet server-rummet dernede, fordi vi gerne ville koncentrere os om et bestemt sæt af ydelser. Vi ville have vores kerneområder at befitte os rundt i, og serverdrift var ikke en del af det, så på et eller andet overordnet plan, er der nogen, der har taget stilling til en sourcing-strategi, som vi nu er ved at kompromittere, fordi vi ikke kan løse nogle operationelle issues, sådan som jeg ser det. Giver det mening? I: Ja absolut. Er det rigtigt forstået, at meget af diskussionen går på.. Altså du siger hele tiden pris kontra ydelse, og det hører jeg som den pris, PenSam betaler for det antal timer, som NNIT lægger i arbejdet, fordi hvis de kan løse deres arbejde med færre antal timer, så tjener de flere penge på kontrakten. Er det sådan at forstå? R: Det er klart, ja. I: Vil det sige at diskussionen går meget på, hvor mange timer skal vi, og hvor mange timer skal NNIT lægge i arbejdet? R: Det synes jeg ikke, jeg synes det i høj grad er et spørgsmål om, vi vil have leveret ydelsen snarere end vi vil ned.. Altså set med mine øjne skal vi ikke interessere os så voldsomt for, hvor mange timer NNIT lægger i det, vi skal mere interessere os for, om vi får ydelsen leveret. At vi så godt kan drage nogle paralleller, der siger, at når vi ikke får ydelsen leveret, så er det nok fordi bemandingen er, så de ikke kan nå at levere det.. Det kan jo selvfølgelig også være alle mulige andre ting, men jeg tror, vi alle sammen har en fornemmelse af, at de er klemt hos NNIT på tiden. På et eller anden led så har man jo lidt på fornemmelsen, om det er fordi, de har svært ved at løse deres opgaver, eller om det er fordi, de ikke har tiden til det. Jeg tror i en række tilfælde, er det oplagt fordi, de er knebet på tid. I hvert fald set fra det jeg ser på. I: Men det er også det, der er formålet. Så det er ikke et spørgsmål om.. Altså vi stiller ikke spørgsmålstegn ved deres evner til at løse den opgave, vi har stillet dem eller deres folks kompetencer? R: Nej, i virkeligheden ikke. Jeg tror.. Det er jo kun en mavefornemmelse, jeg har. I: Jamen det er også det, der er interessant. R: Men min mavefornemmelse siger mig, at de kunne godt løse de her opgaver, vi har i udestående, hvis de ville. Det er et postulat men.. I: Så det vil sige, det er heller ikke udelukkende et spørgsmål om, hvor meget tid de har til det? Fordi der er jo ingen tvivl om at både PenSam og NNIT har en interesse i at få løst det her og få lukket sagen. Så tror du inden for det her rums fire vægge, at der er tale om manglende vilje? Bilag Side 106 af 185

107 R: Jeg gætter, og jeg kan give mit bedste gæt. Mit bedste gæt er at der ikke mangler vilje, men der mangler at tiden bliver prioriteret til det hos NNIT. Det er mit bedste gæt, men som sagt så er det lidt at være ude at gætte på, hvad der foregår på den anden side af plankeværket, som jeg i virkeligheden måske ikke synes, man skal begynde at gætte på, fordi man skal forholde sig til det, der er på ens egen banehalvdel, og ikke begynde at dirigere rundt med det, der er på den anden banehalvdel. Vi skal kigge på de leverancer, som vi modtager og reflektere i forhold til dem. Og vi får ikke leverancerne, og så er det selvfølgelig nærliggende at begynde at gætte på, hvorfor vi ikke får leverancerne. Selvom jeg godt kan give mit gæt, så synes jeg på det principielle plan, vi skal holde os til at beklage os over, vi ikke får de leverancer, vi har aftalt at skulle have. I: Så det vil sige, at hvis man skal summere den her del lidt op, så er billedet, at vi.. At de ikke leverer på de ydelser.. Som du udtrykker det: Vi får ikke leverancerne. Så mener du til tiden eller i aftalt kvalitet eller til den pris vi betaler? R: Altså, prisen diskuterer vi ikke, fordi den er en del af den nye aftale, så de ting, jeg har med at gøre i transitionen, er det leverancen og kvaliteten og så tiden. Det er ikke prisen, fordi der er ingen tvivl om, at de udeståender, der er, det at få flyttet serverne, er en del af økonomien i kontrakten, eller det er underlagt kontrakten. I: Oplever du, at der er forskel på, hvordan sådan nogle ydelser bliver leveret i dag, kontra hvordan de blev leveret den gang de tre områder altså Service Desk, IT-teknik og brugeradministration sad her i PenSam? R: Jeg er ikke sikker på, at jeg mærker en stor forskel. Men det skal så også siges, at lige nu har vi jo onsitesupport alle dage i ugen, og det bliver vi ikke ved med at have. Om det så kan ændre sig på det tidspunkt, det.. I: Hvad er planen for det, hvis du bare skal sætte en eller to sætninger på? Hvad går det ud på det her med onsite-support, og at vi ikke bliver ved med at have det? R: Det går ud på, at vi nedskalerer det efter nogle tidsterminer, men det gør vi først efter, at transitionen fra begge sider er afsluttet. I: Og hvad vil det så betyde? R: Det vil betyde at vi får onsite nogle færre dage om ugen. I: Og hvad er det, onsite? Hvad er ligger der i det begreb? R: Der ligger det, at der sidder en person fra NNIT som er fysisk til stede i PenSam, som du i princippet kan gå ned og tale med, men som også i princippet kan få en telefonisk henvendelse, og som så kan gå ud og lave noget hos brugeren hvis.. Jeg var dernede i går med min telefon. Jeg har fået ny telefon, og jeg kunne ikke få mine mails og kalender i telefonen. Så var jeg nede og tale med onsite eren, og så klarede han det lige for mig. Bilag Side 107 af 185

108 I: Så det er en positiv oplevelse, at der sidder en person fysisk? R: Ja. I: Det kommer der ikke til at gøre fremover? R: Kun nogle dage om ugen. I: Og det forsvinder ikke helt? R: Nej, det gør det ikke. I: Kunne man forestille sig en situation, hvor der var mere nu stiller jeg lidt et provokerende spørgsmål men hvor der var mere, der blev insourcet, og kunne man forestille sig.. R: Der bliver trukket tilbage til PenSam? I: Ja. Kunne man forestille sig, at man på et tidspunkt revaluerede hele outsourcing-samarbejdet og hele den her, som du nævnte før, sourcing-strategi med at vi har en masse mennesker siddende rundt omkring hos forskellige leverandører, der arbejder for os i stedet for, at de sidder i huset? R: Det kunne man i princippet sagtens forestille sig ja. I: Men er det noget, du ser for dig? Er det sandsynligt? R: Altså, det du beder mig om, det er at gætte på, hvad Jes og Torsten og Helen mener om det, fordi det er i givet fald dem, der kommer til at træffe den beslutning om, at sourcing-strategien skal se anderledes ud, og jeg vil sige, jeg vil ikke udelukke at de kunne komme på den ide, hvis samarbejdet med NNIT giver for mange udfordringer. På den anden side set, så tror jeg på det.. Og det er kun et gæt på, hvad de vil mene om det. Det er dem, der kommer til at træffe afgørelsen. Så tror jeg, det nuværende sourcing-snit er meget godt i tråd med det, de har ønsket. I: Ser du niveauet af udfordringer i dag som værende for højt i forhold til det eller er det acceptabelt? Altså, du startede med at sige, at der vil altid være nogle daglige udfordringer som.. Ligger det på et niveau, der er til at leve med? R: Du beder mig om at gætte om nogle ting lige nu.. I: Nej, jeg spørger om dit synspunkt. R: Ja, men det er ikke mig, der skal beslutte om PenSam vil leve med.. I: Men hvis det nu var dig, der skulle beslutte det? R: Jeg kunne forestille mig, at de udfordringer, vi har nu, ikke er af en karakter, så vi vil ønske at lægge sourcing-snittet anderledes. Det vil være mit umiddelbare.. I: Hvad har du af forestillinger om.. Eller hvad ser du af muligheder for at forbedre situationen, som den ser ud i dag? Det var det tredje punkt, som jeg nævnte til at starte med. Givet den situation og givet de udfor- Bilag Side 108 af 185

109 dringer, vi har i dag. Hvad kunne der være af forbedringstiltag som kunne gøre i samarbejdet mellem os og NNIT for at det kom til at køre bedre, end det gør i dag? R: Det er jo todelt. Den ene ting er at få leverandøren til at levere bedre, hurtigere og så videre.. Billigere. Den anden del er jo at vende blikket indad og kigge på, hvordan vi kan forbedre vores bidrag til det. I: Og hvad mener du med.. Forbedre vores bidrag til hvad? R: Jeg mener, at der er en række projekter, hvor vi også skal levere og bidrage til det. Dokumentationsprojektet for eksempel som er en af show-stopperne for at afslutte transitionen. Der skal PenSam bidrage, og det tager også tid overhovedet at finde en person, der skal bidrage, og det tager også tid at finde ud af, hvad er det for ressourcer, der skal bidrage. De ressourcer har måske i virkeligheden ikke særlig meget tid til det. Jeg tænker, at det kunne være sundt, hvis vi husker på, at der er to til at forme samarbejdet, og hvis vi kan forbedre vores indsats, vores leverandøropfølgning og vores leverancer til de opgaver, der ligger fælles, så vil vi også være nået et stykke af vejen. Jeg tror, det er vigtigt at huske på, at det ikke ensidigt er NNIT, der skal levere. Ikke dermed være sagt at vi ikke også skal kigge på den side af det, for selvfølgelig skal vi det, og vi skal gøres umage, for at få dem til at performe bedst muligt ved aktivt at være efter deres leverancer og så videre. Men jeg tror altså også, vi skal kigge indad. I: Hvis du skulle sætte nogle enkelte ord mere på, nu starter vi med NNIT, hvad er det så.. Hvad skulle de gøre anderledes? Så kan vi tage PenSam bagefter. R: Tænker du i transitionen eller i det daglige samarbejde? I: Helt overordnet i det daglige samarbejde. Set fra din stol. Hvad kunne de forbedre? R: Altså set fra min stol så er det vigtigste jo at se at blive færdig med transitionen. Jeg synes, det er rigtig skidt, at vi ikke har fået afsluttet det så lang tid efter, og jeg synes at vi ikke alene bliver ramt på noget funktionelt, altså noget operationelt, men jeg synes også det rammer noget troværdighed. Som jeg faktisk synes, er mindst lige så vigtigt.. At vi mister troværdigheden til samarbejdet. Troværdigheden i samarbejdet lider skade af, at en opgave flyder så længe. I: Er det primært NNIT s - i gåseøjne skyld at det forholder sig sådan, som du beskriver der? R: Jeg mener ikke at PenSam er uden skyld, men jeg mener NNIT har størsteparten af skylden. I: Hvad kunne PenSam så gøre for at forbedre.. Dels det med transitionen, men også set overordnet. R: Jeg tror, at PenSam skal gøre det, at vi i højere grad fokuserer på leverandørstyringen i det. Det er faktisk Ellis funktion, der skal have bedre fodfæste. Det ville være mit bedste bud. I: Er det.. Du sagde før.. Du startede den her sidste del med at sige, at der er to dele i det, og det ene er, at vi skal have leverandøren til at.. bedre, billigere, hurtigere, og det andet er, at vi skal se indad. Hvor ligger balancen på den vægtskål? Er det NNIT eller er det PenSam, der vejer tungest? R: Det har jeg svært ved at vurdere. Bilag Side 109 af 185

110 I: Så det er ikke sådan at du uden tvivl vil sige det er.. R: Jeg vil sige, at omkring transitionen, der synes jeg, den er ubalanceret i forhold til, at det er NNIT, der mangler mest, men i det generelle samarbejde, der har jeg svært ved at komme med et godt bud på balancen, hvilket nok er ensbetydende med, at der måske ligger fejl på begge sider. I: Så hvis vi skulle opsummere, hvad skal der til for at vi kommer skridtet videre og vi kommer ud over nogle af de udfordringer, vi sidder med i dag. R: Jeg tror, det er vigtigt, at vi sætter ressourcer af til både at arbejde med samarbejdet og med opfølgning på leverandørens performance og ydelser. I: Og dermed mener du ting, man så kan se og måle og mærke i kontrakten? R: Ja. I: Og når du siger opfølgning på processer.. R: Dermed mener jeg også, at hvis der er ting, der går i hegnet i det daglige - nogle operationelle ting - at der så er den her eskalationsvej til dem, der er en bestemt, der løber efter den slags opgaver, og som er skrap ud i det procesmæssige. I: Er de en profil, der er til stede i dag? Altså, jeg går ud fra, du mener, det er her i PenSam, der skal sidde en.. R: Ja. I: Er det et punkt, som er tilstrækkeligt understøttet her på stedet, og er det profiler som findes? R: Det er profiler, der findes, men jeg mener ikke, der er fodfæste nok for den opgave. I: Så det er ikke et spørgsmål om, at de personer, der udfører opgaven, ikke evner, det er mere et spørgsmål om, hvorvidt rammerne er til stede for, at de kan udføre det arbejde. R: Ja, det er sådan jeg ser det. Måske heller ikke så firkantet sagt, så man bare.. Altså noget af det er jo også en modning, tænker jeg. Det er ikke bare et spørgsmål om at sige: nu skal skabet stå her, men det er også et spørgsmål om først at finde ud af, hvor praktisk skabet står. I: Så en modning i.. R: I hvordan kan vi gøre det her på en god måde efter vi har fået en ny IT-afdeling og en ny organisering og nye roller og ansvar og så videre. Hvordan løser vi så den opgave? I: Så en modning i PenSams procestankegang, eller? R: Ja. Respondent: Damgaard, IT Service Manager og Service Request Manager Bilag Side 110 af 185

111 I: Det, det går ud på, er, som sagt, at i første omgang se på, hvordan situationen ser ud i dag i arbejdet med de ITIL-processer, der hedder Service Request, Incident og Problem. Det er de tre, der er omdrejningspunktet, og så i samarbejde mellem NNIT og PenSam med service desk som input, fordi brugerne jo leverer input til de her processer via Service Desk. Det er delt op i tre temaer. Det første er, hvordan ser situationen ud nu, det næste er, hvad har vi af udfordringer i samarbejdet og i det daglige arbejde i det hele taget, og det tredje er, hvad der så er af forbedringstiltag, som du ser det. Hvis vi starter med det, med den daglige situation som den ser ud i dag. Hvad er så din oplevelse af, hvordan det fungerer, hvordan det hænger sammen set ud fra de tre processers perspektiv: Service Request, Incident og Problem. Hvordan ser situationen ud i dag? R: Altså, nu du siger, hvordan det fungerer, så tænker du, om det fungerer effektivt eller om servicemålene bliver overholdt? I: Simpelthen bare set fra din stol, hvordan ser situationen ud i dag? R: Og så er det min stol som.. I det job jeg bestrider her i PenSam, og ikke som slutbruger eller et eller andet andet. I: Som Service Manager og Service Request Manager R: For Service Requests tænker jeg, at vi fungerer bedre på nogle områder, end på andre. Jeg tror også, det er et rigtigt svært område at få til at fungere, fordi der er så mange forskellige varianter. Nogle er mere komplekse end andre og nogle kræver et helt andet work flow og sådan nogle ting. En af de varianter, som vi har haft svært ved at få til at fungere, det er tilbudshåndteringen. Det har både været fra vores side, men egentlig mest fra NNIT s side. De har nogle account managers, som ikke ser sig selv som en operationel aktør, og dermed ikke en bruger af Remedy for eksempel. Vi har insisteret på at få alle opgaver styret via Remedy, så der har vores leverandør en intern opgave i at få den proces til at fungere. Så kan der være nogle varianter, hvor en bestilling for eksempel skal udføres eller på en eller anden måde tilgår. Der er flere forskellige afdelinger hos leverandøren, der er flere aktører i det. Der har værktøjsunderstøttelsen heller ikke været optimal, og det betyder at planlægning af opgaven, måske ikke har været.. Bliver lidt kompliceret fordi den skal udføres af flere, og man kan ikke distribuere opgaven til flere interessenter. Lige sådan så er der ikke et eller andet pop-up, der siger i dag skal du udføre denne her opgave, så nogle opgaver kan gå i glemmebogen, og det er jo selvfølgelig en stor risiko. Opgaven bliver ofte glemt og det udgør en stor risiko for os, hvis det er kritiske kørsler for eksempel. Vi har haft eksempler på, at noget ikke er blevet kørt, eller er blevet kørt flere gange, fordi værktøjsunderstøttelsen simpelthen ikke er tilstrækkelig. Hvad kan jeg mere sige på Service Request delen..? Så er der jo et nyt område omkring brugeradministration, som også er en Service Request-type, men der har vi ikke erfaring nok, synes jeg, til, at jeg kan vurdere det. Der er en, jeg tænker, der er nogle forudsætninger omkring Access Management, som siger, hvad det er for noget input PenSam skal give, for at leverandøren er i stand til at udføre opgaven, og der synes jeg ikke, vi har Bilag Side 111 af 185

112 været helt konkrete i at få den opgave i mål endnu. Så det fungerer ikke optimalt på den, men forudsætningerne er heller ikke aftalt. På Incident-siden synes jeg, det fungerer rigtig godt på den måde at forstå, at hvis man tænker ud fra Pen- Sams forretningsperspektiv, så når der bliver oprettet et Incident, så bliver den assignet til nogle mennesker, og den bliver løst, og oftest inden for de servicemål, der er aftalt. Så ud fra et forretningsmæssigt perspektiv så fungerer Incident-processen jo godt. Så kan der være nogle arbejdsrutiner, noget adfærd omkring Incident-processen, som vil kunne gøres bedre. For eksempel det at man assigner en opgave til en kollega, hvis man analyserer en fejl og man tænker: nu kan jeg ikke komme videre med at analysere inden for mit ansvarsområde, så kan man videregive den til en anden, men så får man ikke givet besked om, hvad man har gjort, og hvorfor man videregiver den til en anden og sådan noget. Og det kan trække sagerne unødigt i langdrag. Så på den måde kan der godt være nogle arbejdsrutinemæssige ting, som vi kan forbedre, og det tror jeg, vi også kan forbedre både i PenSam og hos leverandøren. Værktøjsunderstøttelsen på Incident er heller ikke optimal, forstået på den måde at det er svært at søge tilbage og sige, hvor mange driftsforstyrrelser har der været på et konkret system, fordi man ikke i et felt angiver systemet. Vi har heller ikke været skarpe nok til at lave et work log entry, og sige forbindelsen med den her fejl var, at de og de systemer var utilgængelige. Opfølgningsmæssigt hvis du skulle lave et health check som systemansvarlig for en eller anden given applikation, så er værktøjsunderstøttelsen ikke.. Bidrager ikke særlig meget til den type opgaver. Det sidste det var Problems? I: Ja. R: Problemprocessen oplever jeg som rimelig godt velfungerende. Der er aftalt spillereglerne hvordan vi agerer. I forhold til samarbejdet med leverandøren, der tror jeg mere, at vi internt hos os har et hængeparti i forhold til at forretningen og brugerne ude i huset, når de har indmeldt noget, så får de ikke nødvendigvis en tilbagemelding på, hvad de kan forvente med den lidt mere langvarige fejl, de har meldt ind. Men i samarbejdet med leverandøren, mener jeg processen fungerer tilfredsstillende. I: Hvad kunne så årsagen være til, at der mangler fremdrift internt i PenSam på Problem-processen? R: En årsag kunne jo være.. Altså jeg tænker i hvert fald at man, hvis man skal analysere årsagen, så skal man jo kigge på, hvordan har vores.. for eksempel implementeringsaktiviteter været, og så kigge på dem, og sige: Har vi været tilstrækkelig omkring vores implementering og involvering af brugerne. I: Implementering af..? R: Af Problem-processen, fordi det kræver jo, at alle aktører, som indgår i processen, uanset om det er rekvirenten, eller det er dem, der skal udføre opgaverne, har en helhedsforståelse for, hvad en proces indebærer, for hvis mit led i kæden hopper af, så har det en konsekvens for alle de andre aktører. Så jeg tror implementeringsaktiviteterne, er noget af det man skal kigge på oftest, når en proces ikke fungerer. Selv- Bilag Side 112 af 185

113 følgelig skal man også kigge på at lave noget evaluering med de forskellige interessenter med nogle konkrete hændelser, der ikke fungerer, og sige hvad var det, der skete her. Og tage udgangspunkt måske i det aftalte, og sige hvis det var det her, der var ønskemodellen.. Hvis vi nu havde fulgt den og resultatet ikke var tilfredsstillende, så skal man selvfølgelig finde ud af.. Hvorfor fungerede det ikke, og hvor kan man gøre nogle forbedringer. Men oftest synes jeg, det viser sig at aktørerne ikke følger den proces, der er beskrevet, så processen får ofte ikke en chance for at vise sit værd. Der er for mange der gør og formentlig ikke af ond vilje men der ikke lige husker, at den er der, eller man ikke lige har mulighed for at kigge efter, at den er der. Så selvfølgelig skal man kigge på selve processen: Er den god nok? Men i høj grad også på, om aktørerne er vidende og kenskab nok til processen til at indgå i den. I: Er det et scenarie, der gør sig gældende udelukkende for Problem Management, eller går det også igen på.. Altså du nævnte ikke noget specifikt for Incident eller Service Request, at der er ting på processiden, der ikke fungerer så godt. Men er det også gældende i det processer, eller er det kun for Problem? R: Nej, det var kun fordi, jeg nævnte det eksempel med.. Hvor vi ved, at nogle af vores rekvirenter i huset har givet udtryk for frustration over, at når de har indmeldt et eller andet problem, så hører de ikke mere om det, de ved ikke, hvornår det kan forventes løst, og noget af det kan måske endda være forretningskritisk. Jeg tror, det gør sig gældende for alle processer, eksempelvis da vi talte om.. Eller da jeg nævnte Incident og det at skrive.. Nu har jeg analyseret det her og giver opgaven videre til dig. Det er jo også en adfærdsting, en som bør være beskrevet i processen. Så hvis ikke den er det, så ved folk jo ikke, de skal gøre det. Så taler man kun til den enkeltes sunde fornuft, og det kan man ikke altid forvente, at folk har kenskab til. Så det gælder for alle processer, at hvis man skal lave procesforbedringer og procesevalueringer, så skal man jo hele hjulet rundt, kan man sige. Er det designet rigtigt? Er det implementeret rigtigt? Gør folk det der står og sådan nogle ting? På Service Request-siden tror jeg også.. Jeg er ikke sikker på, det er helt så kritisk som fejlene, men jeg synes også, jeg kan huske, at nogle af vores rekvirenter i huset, har givet udtryk for, når jeg nu afleverer en Service Request, hvad kan jeg så forvente? Der kunne vi også kigge på vores implementeringsdel og sige, har vi orienteret vores brugere godt nok om, hvad de kan forvente. Hvad er det for nogle bestillingstider, der er. Man kan ikke forvente at få en opgave udført fra den ene dag til den anden. Det er klart at folk sidder og bliver frustrerede, hvis de sidder og forventer, at de kan få en opgave løst på to dage, men der er fem eller otte dages ekspeditionstid. Vi mangler et service-katalog, som skulle være tilgængeligt for vores brugere, for af det service-katalog skulle det fremgå, hvad pris og ekspeditionstid der er, på de forskellige typer opgaver. I: Og det service-katalog skulle så være tilgængeligt for en hver, der søger.. R: Ja, det skulle være tilgængeligt for en hver som har adgang til at fejlmelde eller bestille. Fordi for Service Request kunne det jo være et service-katelog, som beskriver den vare, du kan købe: Indholdet af den, prisen af den og leveringstiden. Men på Incident for eksempel kan det jo være hvilke kategorier af Incident - hvordan opdeler og prioriterer vi den ud fra de karakteristika, og hvor hurtige er løsningstiderne så ud fra Bilag Side 113 af 185

114 de karakteristika. Det ved folk heller ikke altid. Vi ved også godt, at nogle brugere de fejlmelder deres egen sag som dybt kritisk og urgent og alt muligt andet, men ud fra de definitioner, vi har lavet, er den ikke det. Så har vi jo brug for at forklare de brugere, hvad der er karakteristisk for de forskellige prioriteter. Ikke dermed sagt at man altid kan holde sig til dem, for der kan sagtens sidde en enkelt bruger, som er ved at lave et årsregnskab, som har en vigtigere urgency end et driftsproblem, som rammer flere brugere, hvis ikke det er mere forretningskritisk end at få årsresultatet ud til tiden. I: Og hvor er de definitioner så fastlagt henne? Du siger, der er nogle forskellige definitioner.. R: I dag? I: Ja R: I dag er de fastlagt dels i kontrakten med vores leverandør.. I: Altså med NNIT? R: Ja. Kontrakten er operationaliseret i driftshåndbogen hvor servicemål og sådan noget er, og definitioner er, copy-pastet over i driftshåndbogen. Driftshåndbogen er så suppleret med nogle mere operationelle ting. Derudover har vi, fordi driftshåndbogen er jo et PenSam-NNIT-samarbejdsdokument, og det er ikke nødvendigvis interessant for vores slutbrugere, så derfor har vi udarbejdet nogle interne procesbeskrivelser, hvor de samme elementer indgår, plus at det er suppleret med noget PenSam-intern oplysning, eller hvad kan man sige.. Sådan gør vi i PenSam. Det kunne være hvis nogen skal godkende noget eller et eller andet, som er helt PenSam-specifikt, og som måske skal udfyldes inden man overhovedet overvejer at oprette en bestilling eller sådan noget. I: Så en person.. En bruger kan godt se sin fejl som noget, der er ved at vælte hele verden, men vi kunne have et andet syn på den fejl, når den så kommer ind i møllen? R: Som udgangspunkt ja. I: Hvad er det så, der afgør, om vi synes, at en fejl er anderledes prioriteret, end.. R: Jamen når jeg siger som udgangspunkt ja, så er det fordi, du hvis du kigger rent på definitionerne, så kan de jo tænke: "Hmm.. Denne her fejl, hedder ud fra definitionen at vurdere kategori middel." Men hvis man kigger på hvilken konsekvens, fejlen har ud fra en forretningsmæssigt perspektiv, så kunne det jo godt, for eksempel lige som hvis vi skal lave årsregnskab: I denne her situation, i denne her tid på året i kalenderen, har denne her enkeltbrugerfejl for eksempel en højere kritikalitet og en højere betydning for PenSams forretning, og det er der, hvor man siger, at definitionerne er retningsgivende, men der kan forekomme varianter, hvor man må lave et individuelt skøn. Det skal til en hver tid være konsekvensen ved fejlen, som afgør prioriteten end definitionen. I: Og hvad er så det for.. Hvad kunne det være for elementer? Bilag Side 114 af 185

115 R: Ja, det kunne for eksempel være den der med, at hvis man.. Hvis en enkeltbruger som sidder og laver årsregnskaber, skal aflevere det klokken fire i eftermiddag, så ville du kigge på din definition og sige, at enkeltbruger-fejl det er en low eller medium, men fordi konsekvensen ved, at denne bruger ikke får løst sin sag, og får afleveret sit regnskab klokken fire, gør, at det er en stor trussel for PenSams renommé eller forpligtelser over for kunder eller bestyrelsen eller et eller andet, så ville man jo der vurdere, at konsekvensen ved, at den her fejl ville køre som medium er for grov til, at vi kan acceptere, at den kører sådan, og så vælger vi at give den en højere prioritet og beskriver konsekvensen, som argumentation for, hvorfor vi har givet den en højere prioritet end den ud fra definitionen var berettiget til. I: Så det vil sige.. Nu siger du "enkeltbrugerfejl" som medium. Vil det sige, at hvis en fejl, som kun en bruger oplever, så vil den som udgangspunkt ikke være højt prioriteret? R: Ja. I: Hvad ligger der så i de der forskellige kategorier, forskellige definitioner? R: Altså jeg kan jo ikke lige på stående fod huske dem udenad, og hvad der ligger i dem, men definitionerne tager udgangspunkt i konsekvensen, og at man som udgangspunkt for eksempel siger, at en enkeltbrugerfejl kan i langt de fleste tilfælde ikke være kritisk for PenSams forretning. Derudover skal man jo ikke glemme, at servicemål og prioriteter og sådan noget er jo også lavet ud fra et økonomisk perspektiv: Hvor hurtigt har vi råd til, eller hvor hurtigt vil vi betale en eller anden pris for at få løst vores opgaver. Så det er jo også et element, men det er jo selvfølgelig mere den kontraktuelle del, mere end procesdelen. Men prioriteterne ligger jo alt andet lige i kontrakten, og dermed har vi sagt, at der er nogle servicemål på et antal dage, og det vil sige at man fra PenSams side har vurderet, at en enkeltbrugerfejl godt kan ligge i, lad og sige, tre eller fem dage. Det kunne være, der var en kollega, som har ferie, hvor man kan gå hen og låne den PC, eller hvad det nu måtte være. Men der er jo nogle muligheder for at opprioritere og muligheder for at få vores leverandør til at løse opgaven hurtigere, og i sidste ende er det jo PenSams prioritering at sige "hvad er det for nogle opgaver, der ikke bliver løst, som for eksempel ligger med en højere prioritet, men som ikke bliver løst, fordi vi gerne vil have den her løst tidligere eller hurtigere. Så på den måde kan man sige, leverandøren tager jo opgaverne ud fra de kontraktuelle definitioner. Men hvis vi ringer og siger "den her opgave er vigtigere - læg alt andet til side" så skal de jo gøre det. I: Kunne det medføre, at der kunne opstå tvivl om prioriteringen og hvilken rækkefølge sagerne skal løses i? R: Det kunne det selvfølgelig godt, men i ren praksis opstår det sjældent, og jeg synes, det fungerer godt på den måde, at vi har fået indarbejdet nogle rutiner, hvor nogle konkrete kontaktpersoner har mulighed for at ringe til hinanden og omprioritere nogle ting. Det sker ikke ret tit, og når det sker, så er det min opfattelse, at det fungerer rimelig godt og uden de store sværdslag. I: Kan du uddybe lidt? Bare uddybe en lille smule mere, altså, når du siger "vi har fået indført nogle bestemte kontaktpersoner, man kan ringe til." Hvad ligger der i det? Bilag Side 115 af 185

116 R: Der ligger, at man har ansvarsplaceret på begge sider, både hos PenSam og hos NNIT har man ansvarsplaceret et procesejerskab, og den proces-manager er den, der er den primære kontaktperson, som varetager processens, altså beskrivelse, implementering og formalitet og sundhed, hvis man kan sige sådan - processundheden og opfølgningen. Det vil sige, at hvis man har behov for at afvige fra processen, så vil det oftest være den proces-manager, man kontakter. Det giver nogle lidt skarpe grænseflader, som gør, at man ved, hvem man skal kontakte og ikke behøver rende rundt til.. og spilde tiden på at få fat i nogen som måske ved noget, og som kunne tænkes at vide noget eller bestemme noget. I: Nu siger du, det er noget, vi har indført. Er det noget man har gjort for nylig, og hvorfor har man indført det? R: Begrebet omkring procesejerskab blev indført i forbindelse med, at vi startede vores drift hos NNIT for tre år siden. Jeg mener ikke, at det ligefrem kontraktuelt er beskrevet, at PenSam er forpligtet til at have en proces-manager, men det er det, der er aftalt. For eksempel, som jeg sagde, i kontrakten står der at NNIT har de her roller, og at vi operationelt er blevet enige om og har indført i driftshåndbogen, det har vi så også i PenSam, fordi vi vurderede på det tidspunkt, at det nok ville fungere godt, og dermed aftalte vi at prøve det af. Så vi aftalte at placere Incident Manager og Change Manager og Problem og Service Request og Capacity, Configuration og Security, og alle de der forskellige ITIL-processer er placeret hos en person i PenSam, som så varetager processundheden, og også internt i PenSam har implementeringsansvaret - og få det beskrevet i et sprog, så PenSams brugere kan forstå, hvad processen indebærer og sådan noget. I: Er det så noget, som man.. Fordi nu siger du, begrebet procesejerskab blev indført i forbindelse med, at vi overgik til NNIT. Du siger, man har indført en skarpere inddeling. Er det så noget, man også gjorde dengang, eller er det noget man har gjort efterfølgende? R: Nej, vi gjorde det dengang og fra starten af. I forbindelse med at vi fornyede kontrakten med NNIT i 2012 og outsourcede nogle funktioner, deriblandt Service Desk og Desktop Management og Brugeradministration, så overvejede man fra PenSams side at sige, kan det fungere, hvis vi i PenSam siger "vi har ikke de roller hos os. Det er kun leverandøren, der har det, fordi de har hele ydelsen." Det prøvede vi af i en periode, og det fungerede ikke særlig godt. Det var jo for eksempel.. Altså give sig udslag i, at det at implementere processen internt i PenSam, der ville leverandøren jo ikke vide, hvem er PenSams brugere, hvem er målgruppen for lige netop denne her type bestilling, og hvem i PenSam skal godkende, og hvor meget må det koste. Er der nogle prisgrænser på, eller hvad ved jeg. Så det prøvede vi af i en periode og konstaterede, det ikke fungerede optimalt. Derfor valgte vi at gå tilbage til at lave en procesansvarlig for hver proces. I: Har det så gjort det bedre? R: Det synes jeg - altså i forhold til ikke at have nogen. Det synes jeg bestemt, fordi altså vi oplevede jo at vores leverandør havde nogle.. Hvad skal mange sige.. Havde et samarbejdsbehov med PenSam, som ikke nogen i PenSam var i stand til at tage sig af, og vi kan jo ikke bede vores leverandør om at rende rundt på gangene og lede efter nogle tilfældige personer. Så leverandøren udtrykte behov for, at der blev genopta- Bilag Side 116 af 185

117 get nogle faste kontaktpersoner. Jeg ved da også, at i de seneste styregruppereferater fra sidste uge, ikke referat i styregruppen, men materialet som NNIT laver som oplæg til det fælles styregruppemøde, der roste de samarbejdet på de her forskellige processer. Det synes jeg er meget positivt, fordi alt andet lige så er det jo IT-leverandøren, som bør være mest professionel i området. Så det er dejligt at få ros for, at vi også har magtet at udføre vores del af opgaven. I: Når du siger, det er IT-leverandøren, der bør være mest professionel, er det så et udtryk for, at de ikke nødvendigvis er det? R: Nej, så er det mere et udtryk for at ITIL er en IT-driftsmodel som anvendes i IT-branchen, og PenSam er alt andet lige i pensionsbranchen. ITIL kunne være ny for mange af os, og i og med vi har outsourcet både vores drift og udvikling, så har vi ikke nødvendigvis særlig mange IT-profiler, og dem, vi har, er måske mere specialister, end de er brede profiler. Derfor er det rigtig godt, at vi alligevel har formået selv internt at have de brede profiler, som der skal til for at varetage procesarbejde. Ofte så viser det sig jo at en specialist - en udvikler for eksempel er ikke særlig procesorienteret. Han kører i sit snuden i sporet og kører efter at løse den konkrete opgave uden at tænke på helheden i en eller anden proces og sammenhænge og sådan noget. Så det betyder meget, at en virksomhed som ikke er specialist i ITIL har evnet at opbygge et ITILkoncept selv. I: Nu siger du, at vi har outsourcet både drift og udvikling, og samtidig så sidder der nogle specialister i Pen- Sam, og der nævnte du også en udvikler. Hvordan hænger det sammen, hvis vi har outsourcet udvikling og drift, hvorfor har vi så specialister, såsom udviklere? Hvad er det ellers for nogle specialister, der ved.. R: Det er fordi, man har valgt ikke at lave en hundredeprocentsoutsourcing, men at fastholde noget egenudvikling og noget egen vedligeholdelse. I: Så de specialister, der sidder, de er udviklere? R: Ja, det er udviklere, og så er det.. Vi har også nogle infrastrukturfolk, som, hvad skal man sige, matcher outsourcing-partneren, og vi har også selv noget infrastruktur stående at køre i PenSam. Så det er jo også et udtryk for, at vi har outsourcet vores drift, men vi har ikke hundrede procent outsourcet vores drift. I: Hvad er så grunden til det? Hvorfor har man ikke valgt enten at outsource alt og så sige "det håndterer.." R: Jeg kender ikke beslutningen bag ved det. I: Så du kan ikke.. Du ved ikke hvorfor, man stadigvæk har for eksempel infrastrukturfolk siddende, og man stadigvæk har noget stående her i huset i stedet for at lægge det hele ud? R: Nej.. Ja.. Både og. Jeg ved, man har infrastrukturfolk siddende her, fordi vi er nødt til at have nogle folk hos os, som kan vurdere de løsninger og leverancer, som leverandøren kommer med. Derfor kræver det også, at vi har nogle infrastrukturfolk, som har et godt kendskab til vores løsninger, på samme måde som vi også har applikationsarkitekter, selvom opgaven bliver løst ude af huset. Vi har stor kompleksitet i vores integration mellem systemerne. Derfor har vi brug for at bevare den viden hos os, men hvorfor man lige- Bilag Side 117 af 185

118 frem har valgt at have et antal servere kørende produktion i vores egen kælder, det kender jeg ikke baggrunden for. Det kunne være mange ting: Det kunne være økonomi, det kunne være servicemål. Hvis man har et behov for at tilgå eller lave ændringer eller på en eller anden måde tilpasse hurtigere eller mere smidigt end hvis man ofte har en kontraktuel aftale med leverandøren. Jeg kender ikke baggrunden for det. I: Nej men der er heller ikke nogen grund til.. R: Der er sikkert også forskellig argumentation for afhængig af hvad det er for et system, vi har valgt at inhouse. I: Der er heller ikke nogen grund til at gå så meget ned i det, det var bare for at høre, om der var en bestemt grund til det. R: Men man må sige procesmæssigt giver det jo.. Kan det give en udfordring. Jeg har ikke erfaring med, om det gør det, men det kan give en udfordring i form af, at de processer vi kører, kører vi oftest imod leverandøren og ikke nødvendigvis imod vores egen drift. Det kan jo give, for slutbrugerens vedkommende, nogle udfordringer ved, at de måske ikke ved, hvad har vi selv kørende - altså hvor skal vi bestille varen henne. Eller hvis der er et driftsproblem, bliver en Incident så sendt et forkert sted hen, fordi Service Desk ikke nødvendigvis tænker over, at det system kører hos os selv eller et eller andet. Det kan man selvfølgelig dokumentere sig ud af, men alt andet lige så jo mere spredt tingene er, jo mere tidskrævende er det at få assignet opgaverne det rigtige sted hen, og få det løst hurtigt og effektivt. I: Nu nævnte du selv udfordringer.. Det var også, som jeg startede med at sige.. Det er et andet ben i det her. Hvad har vi ellers.. Det her er én ting, men hvad har vi ellers af udfordringer i det daglige i håndteringen af de her processer? R: Internt synes jeg, vi har en udfordring i at alle vores processer ikke nødvendigvis er beskrevet. Det giver jo en stor risiko for, at opgaverne ikke bliver løst til den aftalte tid, eller pris eller servicemål eller hvad ved jeg. Jeg ved, at vi konkret har på, det vil så i ITIL-termologien være på testsiden, men helt derude på Change-forløbet, hvor en opgave bliver født og så til den bliver en idriftsættelsesting. Det forløb fra opgaven bliver født og til idriftsættelsesimplementeringen er klar, det forløb er ikke beskrevet. Det betyder også at en bruger i PenSam kan melde et ændringsønske ind til et system. Det kunne være ny funktionalitet eller et eller andet andet. Ved at det ikke er beskrevet, så kan brugeren ikke gå ind og se, "hvad kan jeg forvente, når jeg har afleveret mit ønske? Hvornår får jeg svar tilbage? Hvor lang tid går der, før det bliver løst? Bliver det måske prioriteret 'ikke-løst'?" eller et eller andet. Det kan godt være brugeren får noget besked tilbage, men vi er ikke i stand til at orientere brugeren om "hvad kan jeg forvente, når jeg har indmeldt en sag?" Det kan så skabe noget frustration. I: Er det et generelt problem at brugere ikke får besked på deres henvendelser? R: Nu talte jeg jo om den type opgaver, som er bestilling af vedligeholdelse af eksisterende applikationer og sådan noget. Bilag Side 118 af 185

119 I: Men er det så noget, der også gør sig gældende i andre.. For andre henvendelser fra brugere eller er det kun på det område? R: Altså fra andre typer opgaver? Du tænker på Incidents eller I: Altså det ved brugerne jo ikke hvad er, men en indmeldelse fra en bruger til Service Desk om noget, som vi så håndterer i de ITIL-processer, vi har taget i brug. Gør det sig gældende generelt, eller er det kun på forespørgsler om ændringsønsker? R: Jeg synes, at jeg oplever, at forespørgsler om ændringsønsker er markant anderledes, fordi det ikke er beskrevet, og dermed så har vi ikke mulighed for at orientere folk om, hvad de kan forvente. De andre processer, om det er Incident eller Problems eller Service Request eller tjenester, er processerne beskrevet. Det vil sige at vores brugere i huset kan gå ind og lukke den beskrivelse op og se hvilke servicemål, der ligger der. Det ville selvfølgelig være endnu bedre, hvis vi havde det her service-katalog, som jeg tidligere nævnte, fordi der kan du se det enkelte produkt, hvor i procesbeskrivelsen er det forløbet, der er beskrevet. Så service-kataloget ville være et rigtig godt supplement til procesbeskrivelsen. Men procesbeskrivelsen er jo den, der beskriver, hvad man kan forvente i forhold til leveringstider, og hvornår man får noget at vide, og hvad sker der, når en sag er løst eller ikke løst, og hvis den bliver prioriteret op eller ned eller sådan noget. I: Er det noget af det, som brugerne mangler at få besked på? Det med "hvornår kan jeg forvente at sagen er løst? Prioritet og sådan nogle ting?" R: Om de mangler at få besked? I: Ja, altså når du siger, at brugerne oplever, de ikke får tilbagemeldinger på, i det her tilfælde var det forespørgsler om ændringsønsker, og så siger du manglende tilbagemeldinger på.. R: Ikke at de ikke får deres.. De ved ikke, om de får det. De giver udtryk for, at når de har afleveret et ønske, så står de sådan lidt: "Og hvad sker der så?" De kan ikke læse noget sted om "hvad kan jeg forvente?" "Er det sådan, så jeg får en kvittering for min opgave, og vil den inden for en måned blive estimeret, så jeg kan få at vide, hvor meget den koster at få løst og forvente om den overhovedet bliver løst? Har man valgt at nedprioritere den og simpelthen helt annullere den forespørgsel?" Så jeg tror mere, det er fordi.. Jeg ved det ikke.. Jo jeg ved det ud fra, at jeg selv har været bruger/rekvirent på en enkelt forespørgsel. Den tilbagemelding jeg fik, var sådan en automatisk genereret mail fra et system, hvor jeg egentlig mere kunne se, at min opgave var blevet registreret i et system, men ikke en tilbagemelding på, hvad jeg kunne forvente. Når der så bliver opdateret i den sag, så får jeg igen en automatisk notifikation, hvor jeg skal bruge lidt tid på at se, hvad det er, der er opdateret i sagen. Men igen - det er jo tilfældigt, og det bliver kun gjort.. Jeg får den notifikation, når sagen er blevet opdateret, jeg er stadigvæk ikke blevet orienteret om, hvad jeg kan forvente. Jeg tror, hvis man snakker brugertilfredshed med slutbrugerne, så er forventningsafstemning en hovedingrediens til tilfredshed. Bilag Side 119 af 185

120 I: Er det så noget, der også gør sig gældende på andre typer af henvendelser? R: Forventningsafstemning? I: Ja, eller manglende forventningsafstemning i virkeligheden. Eller er det så også kun gældende for ændringsforespørgsler? R: Nej, jeg tror godt, vi kunne gøre det bedre på forventningsafstemningen. Det er lidt igen tilbage til implementeringen. Jeg tror man skal kigge lidt på, hvordan har man implementeret de her processer. Jeg tror faktisk, at det forholder sig sådan, at de er blevet beskrevet, og de er blevet publiceret på vores intranet, og så blev der holdt sådan et åbent hus-arrangement, hvor dem der havde lyst til at gå ned og høre lidt om det, de kunne gøre det. Siden har vi ikke lavet noget opfølgning eller nogle yderligere implementeringsseancer. Det betyder jo, at hvis vi implementerede de her processer for.. Lad os bare side to år siden - det er vidst endda godt og vel.. Det er faktisk to et halvt år siden - så er der jo sket mange ændringer siden. Det kan både være ændringer i vores processer, men det er også et spørgsmål om at orientere nye medarbejdere, der kommer om.. Altså så de er klædt på med, hvad de kan forvente og sådan noget. Så jeg tror, hvis man skulle gøre det optimalt, så skulle man overveje at lave et eller andet implementeringskoncept, som både er løbende for nyansatte, men også at sige "nu laver vi ændringer til noget, og så har vi en eller anden kommunikationsplaner. Og så skal man selvfølgelig afstemme den kommunikationsplan og de seancer efter, hvad det er for en målgruppe, som ændringerne vedrører. Der er forskel på, om man er slutbruger eller man er aktør. Altså om man skal ind og løse og arbejde med for at løse et problem. Det kunne lige så vel være værktøjsunderstøttelsen. Hvis man gør et system tilgængeligt og siger: "Gå ind og brug det." Det kan de fleste finde ud af at gøre, for det kan man også på internettet, hvis man skal ind i en eller anden webbutik og bestille noget, så finder man også ud af, hvordan det fungerer. Men hvis det er vigtigt for PenSam at have effektive processer og effektiv ekspedition af fejl og sådan nogle ting, så må vi også bidrage til, at de aktører, der skal bidrage til processen, er klædt ordenligt på med at anvende værktøjet, så det bliver hurtigt og smidigt og fejlfrit. I: Det oplever du, at de ikke er i dag? R: Ja. I: Hvad har det så af konsekvenser? R: Jeg oplever, at konsekvensen ofte er at.. Jamen det kan både være, at en sag ikke bliver løst, eller at kommunikationen mellem nogle forskellige, det kan være teknikprofiler ikke er tilstrækkelig, så det arbejde den ene har brugt tid på at udføre, det starter den anden forfra på, fordi man for eksempel ikke har skrevet i opgaven, hvad man har gjort, og ikke på den måde laver en struktureret fejlsøgningsprocedure eller sådan noget. Få dokumenteret nogle.. Ja det kunne være nogle hypoteser for "lad os undersøge det og det og det.. og så dokumenterer man så efterhånden som man arbejder sig frem på, hvad man har undersøgt og sådan noget. Bilag Side 120 af 185

121 I: Når du siger, at en konsekvens kan være, at en sag ikke bliver løst. Hvad ligger der i at.. Altså betyder det, at der er en bruger, der henvender sig om et eller andet problem, og så får vedkommende aldrig noget tilbagemelding og der bliver ikke gjort noget ved problemet eller situationen? R: Det kunne det godt være. Jeg tror, eller jeg vil ikke en gang sige, jeg tror, for jeg synes, jeg oplever det i ny og næ, at.. Det kan jo være en bruger som henvender sig og siger "nu er der gået tre måneder siden, jeg oprettede en eller anden sag, hvad er der sket med den?" Når vi så graver os lidt ned i det, så sker det at den opgave bare ligger, fordi den af en eller anden grund er blevet syltet. Ikke bevidst syltet men syltet fordi den måske "nå men den troede jeg, du tog dig af" eller "den troede jeg da egentlig var løst." Nogle gange så kan løsningen måske være lavet men bare ikke implementeret eller et eller andet. Vi får ikke.. Der bliver måske ikke helt bundet sløjfe på opgaven og får den helt konkret færdiggjort. Den ene tror, den anden gør. Hvis man var meget skarp på sine processer og roller, hvem gør hvad, og folk var loyale mod at følge det, så ville man også på den måde, hvad skal man sige, være mere opmærksom på, om opgaven er løst, og sagen er lukket og brugeren er blevet spurgt, om de var tilfreds med løsningen, og om det nu virker og sådan nogle ting. I: Hvis nu vi skulle fokusere.. Der er omkring ti minutter tilbage. Hvis nu vi skulle fokusere på, hvad kunne vi foretage os af forbedringstiltag. Hvad kunne vi gøre for at dæmme op for nogle af de her udfordringer, som du lige har fortalt lidt om? R: Jeg tror, vi kan nå rigtig langt ved at lave et recap på vores kommunikation og implementeringsaktiviteter. Og sige "hvordan har vi egentlig implementeret denne her proces og hvornår gjorde vi det sidst? Hvem var målgruppen og ramte vi dermed alle relevante målgrupper?" Man kunne eventuelt gå ud og spørge nogle af de modtagere/målgrupper, vi tidligere har implementeret over for, og spurgt hvilke.. Hvordan de oplevede det og om der var noget, vi kunne gøre bedre. Lave noget evaluering på den tidligere implementering, for så at lave nogle forbedringer til runde to. Jeg tror i høj grad, at information og kommunikation om de her ting er nøglen til, at folk har kendskab til, hvordan man skal agere i den proces. I: Hvad med sådan i det daglige.. Altså, du snakker meget om implementering af.. Formidling af at nu har vi de her processer, og vi gør sådan og sådan. Hvad med i det daglige? Den funktion der er, at vi modtager og i nogle tilfælde løser et antal problemer. Er der noget i det daglige samarbejde internt i PenSam og mellem PenSam og NNIT set i lyset af, at vi har valgt at bruge de her processer til at udføre arbejdet, hvor der var plads til forbedring? R: Jeg kan ikke lige sådan til højrebenet tænke, at der ligger noget, hvor vi kunne gøre det meget bedre, for jeg synes, at jeg oplever, at det samarbejde der er mellem de her procesfolk, hvor man har nogle.. En løbende dialog om processen og om sagshåndteringen og sådan noget.. Den fungerer rigtig godt, og hvis der er noget i hverdagen, så vil de blive taget op i de fora. Så man kan sige, skulle man lave nogle forbedringer, så skulle man i hvert fald være opmærksom på at sige "Hvis du oplever noget, der ikke fungerer i den her proces, så kontakt Incident Manageren" Som så har en forpligtelse til at vedligeholde processen og finde ud Bilag Side 121 af 185

122 af, hvad der gik galt, og er der noget vi generelt skal forbedre, eller var det her en enlig svale på noget, der gik galt? I: Er det din oplevelse, at der så bliver taget hånd om, at det kan være, at det er processen, der er noget galt med? R: Ikke altid. Det synes jeg, er sådan lidt forskelligt. Igen tror jeg, det er fordi, det kan godt være rigtig svært for folk at tænke i processer. Det kræver en bestemt profil, hvis man kan sige sådan, så det afhænger lidt af, hvem det er, der har den Proces Manager-opgave. I: Og når du siger, at det kan være svært for "folk" at tænke i processer, mener du så forretningen, brugerne i huset eller mener du de mennesker, der sidder i IT-funktionen? R: Nej, der tænker jeg, de mennesker som i PenSam er udpegede som procesansvarlige. Fordi det er også forskellige profiler, som er blevet udpeget som procesansvarlige. Nogle er mere proces-minded end andre, og dem der er mindst proces-minded, de har også svært ved med det samme at knipse og sige "der skal vi da lige have kigget på processen. De går mere efter at få løst den konkrete sag, og så er den ude af verden. Det kommer ikke naturligt til dem at tænke "hmm.. Er der noget generelt her som gør at den her type opgaver.." Eller "har vi set det her før rent procesmæssigt at kæden hopper af et eller andet sted?" Det kræver en personprofil at tænke sådan. I: Så det vil sige, at der er nogle, der er bedre til at tænke i.. Hvad skal man sige.. R: I processer end andre.. I: Ja, men i behandling eller i helbredelse, og nogle der tænker mere i symptombehandling, og nu opstår der en fejl, og så løser vi den, og så kommer vi videre. R: Ja, vi løser fejl, men vi tænker ikke på.. Man kan jo for eksempel sige, hvis nu en eller anden fejl er for længe om at blive løst, så vil den ofte blive eskaleret. Dem, der ikke tænker i processer, de går hen på den anden side af gangen til en kollega, som er specialist på det her og siger: "kan du ikke lige hjælpe mig med at få løst den her, for den har altså ligget og kogt, og det er vigtigt, at vi får den løst." Så får man løst selve fejlen, men de får ikke kigget på: Hvorfor tog det her lang tid? Hvor i processen hoppede kæden af? For eksempel at man blev opgaven ikke videregivet til de rigtige, der skulle have den? Eller er den ikke beskrevet ordenligt, så folk der skulle have den, kunne finde ud af at arbejde efter den? Havde vi ikke den dokumentation, der skulle til? Så på den måde procesmæssigt sige "hmm.. hvorfor hoppede kæden af i denne her situation?" Der oplever jeg en forskel i de personer i PenSam, som er procesansvarlige, de har forskellige profiler, og nogle er bedre til at tænke procesorienteret end andre. I: Hvorfor er det interessant, at man, når der opstår en situation eller en fejl, graver sig ned i at løse problemet, sådan så.. Med hensyn til om der blev gjort det, der skulle gøres og ikke bare få fejlen løst. Hvorfor er hele det her procesarbejde så interessant, hvorfor er det nødvendigt at anlægge det perspektiv, kan man Bilag Side 122 af 185

123 ikke bare løse fejlen, når den opstår? Altså, når en bruger og en kunde oplever et problem, så vil de jo gerne bare have det løst. Hvad er så meningen med alt det andet? R: Formålet med at arbejde efter en struktureret proces, det er at arbejde ensartet og effektivt uanset hvem, der løser opgaven. Og derfor så.. Lad os nu antage at folk arbejdede ensartet og dermed mere effektivt. Hvis der så alligevel sker et eller andet, hvor man ikke har fulgt proceduren, så vil det jo være den ene person, som træder uden for proceduren, og så ville det være det, der var.. Der skulle til for at få tingene på sporet igen. Det var at sige "hov, du skal ikke gøre sådan her, du skal gøre sådan her, for sådan gør alle de andre, og så fungerer det godt." Så er man på sporet igen. Det der er problemet med, at processerne ikke er implementeret blandt aktørerne, det er jo, at der er for mange episoder, hvor folk gør tingene på deres egen måde, og dermed ikke ensartet og effektivt. Det vil også komplicere det at overdrage en rolle til en anden. Det kunne være i forbindelse med ferie eller et eller andet, fordi så.. Hvis alle ved, at dokumentationen ligger her, og vi gør sådan og sådan, så ville man kunne overdrage til andre og ikke være personafhængige ved fravær og sådan nogle ting. Det kræver, at folk er bekendt med og arbejdet efter de procedurer, så jeg tænker at nøgleordene er ensartethed og dermed effektivitet. I: Så det er en mere effektiv måde at arbejde på, hvis man følger processerne og gør det samme hver gang? R: Ja, processen skulle gerne være udarbejdet med det formål at løse den her opgave så hurtigt og effektivt så muligt. Så hvis processen er ordenligt beskrevet, og gennembearbejdet, kan man sige, for man kan også lave nogle processer bare for processens skyld, og så er den ikke særlig effektiv. Det er jo derfor, man så hele tiden skal lave forbedringer og improvements på sine processer. Det er jo hele tiden fordi, den der har ansvaret for processen forhåbentlig har det mindset, der hedder "hvordan kan vi gøre det her mere effektivt og mere fejltolerant og sådan nogle ting. I: Og når du siger "gøre det her mere effektivt." er "det her" så arbejdet, som fører til at der opstår en fejl eller er det processen, der skal gøres mere effektiv? R: Det er processen, som er måden at arbejde på. Processen er jo at føre en opgave fra A til B. I: Men er det så en opgave forstået med en fejl en bruger melder ind hertil, eller er det vedkommendes måde at arbejde på, som resulterer i, at der opstår en fejl? I hvilket lag er vi? Taler vi om brugernes måde at arbejde på, eller taler vi om de mennesker, der udfører det her procesarbejde på de tre processers måde at arbejde på? R: Jeg synes, det er begge dele.. Eller det hele. En procesbeskrivelse beskriver de forskellige aktører, og hvis du starter med den bruger, der melder en sag ind, så skal procesbeskrivelsen jo også sige: "Forudsætningerne for, du kan melde en sag ind, er, at du bidrager med det og det og det.. Så skal du henvende dig der, så er der nogle andre, der tager sig af den, og de gør så det og det og det.." Man kan så selvfølgelig supplere, og det gør man jo oftest i en procesbeskrivelse, fordi processen er jo sagens håndtering fra den opstår, til den bliver løst. Så kan der jo godt inden for de enkelte aktører kan jo godt have en procedurebeskrivelse for at sige "hvordan udfører jeg så min del af opgaven? Skal jeg bruge den blå skruetrækker, eller skal jeg Bilag Side 123 af 185

124 bruge en rød skruetrækker?" Så på den måde kan man godt supplere en procesbeskrivelse med nogle procedurebeskrivelser, men en procesbeskrivelse beskriver det overordnede forløb for en sagshåndtering. Og så har man så dokumentation ved siden af, som siger: "Når du får denne her type sag, skal du arbejde med den konkret med den røde skruetrækker, og når du så er færdig med det, så går du tilbage i processen og siger: "Når jeg er færdig med min aktivitet, så videregiver jeg sagen i procesforløbet, og så er der nogle andre, der gør noget andet."" Så på den måde kan man have en proces suppleret med en procedurebeskrivelse inden for det enkelte speciale. I: Fungerer det så? Altså arbejder man sådan her i IT-området? Altså er det din oplevelse, at man arbejder efter processen, og man gør som.. R: Nej, det er det ikke. Og det er der hvor jeg siger, at vi kunne lave nogle forbedringer ved at implementere de her ting og følge op på, at det bliver fulgt, og få det ind i folks bevidsthed, så vi i højere grad arbejder ensrettet, ensartet og effektivt, end vi gør i dag. I dag er vi mere tilbøjelige til, at folk gør det, de synes er bedst og smartest og mest effektivt for dem isoleret set og ikke for helhedsperspektivet. I: Men hvis jeg så indrettede en proces, der hed "når der opstår en fejl, så går jeg hen til vedkommende, som oplever den og afhjælper den." Så er vedkommendes problem løst set fra hans heller hendes side. R: Så er det din procedure for Incident-håndtering. Fordi Incident-processen ville så være der, at en bruger henvender sig i Service Desk, Service Desk opretter en sag, den sag bliver assignet til dig. Det er ren procedure. Når du så får sagen.. Det at du går ned og hjælper brugeren, det er din procedure for at afhjælpe lige netop den her type opgave. Så kan det godt være, at det på den type opgaver er mest egnet, at du går ned og viser brugeren, hvis det nu var en fejl 40 for eksempel, det hænder jo, at man så siger: "Jamen proceduren for det, vi tror er fejl 40, det er at gå ned og hjælpe brugeren og vise, hvordan man skal gøre det rigtigt. Det kunne også være, at proceduren siger "der er ikke nok beskrivelse af, hvad det her er for en fejl, og hvor den opstår, så mit første trin, min første procedure i min analyse af den her fejl, det er at gå ned til brugeren, og få dem til at fremprovokere fejlen igen, så jeg med mine egne øjne kan se og dokumentere, tage skærmbilleder, eller hvad man nu ville. Så ville det være din procedure i processen - altså i den aktivitet, der hedder at fejlanalysere eller fejlsøge eller sådan noget. Det ville jo så være individuelt for, hvad det var for en type fejl. Det kan man ikke sige, at alle skal gøre det, fordi det ville være et individuelt behov. I: Men hvis nu det var den måde, jeg havde valgt at strukturere processen på, og jeg så fulgte den, så følger jeg jo processen. Men er det ensbetydende med, at det er en smart måde at gøre det på? R: Altså det skulle jo gerne være fordi, vi har besluttet at det.. Altså at vi har vurderet.. En proces er jo designet individuelt for den enkelte virksomhed, og hvis vi er kommet frem til, at vi siger, at alle, der modtager en fejl her skal ned til brugeren og se, hvordan den ser ud i virkeligheden, eller prøve at afhjælpe den eller et eller andet, så ville det være fordi, vi har vurderet, at det er den mest effektive måde at løse fejl på hos os. Det er jo et valg man tager ud fra den enkelte sag, og det kan være lige så forskelligt fra sag til sag og fra den ene virksomhed til den anden. Bilag Side 124 af 185

125 Respondenter: Ludvigsen & Borring I: Der er tre led i det her. Det er første er, hvordan situationen ser ud i dag, det andet er, hvad vi har af udfordringer, og nummer tre er, hvad vi kunne forestille os af forbedringstiltag, hvis vi skulle det. Omfanget, det vi skal tale om, det er situationen med, at man, når man som brugere, det vil sige jer, indmelder en eller anden sag til Service Desk, så bliver den håndteret på en eller anden måde. Og så gælder det om for mit vedkommende at få afdækket, hvad er jeres oplevelse af den proces. Og som sagt er der de tre dele af det: Hvordan ser det ud i dag, hvad er der af udfordringer, og hvordan kan vi forbedre det - hvad kunne man forestille sig, man kunne gøre, for at gøre tingene smartere, bedre og nemmere for jer. Så hvis vi starter med, hvordan I ser situationen i dag. Når I indmelder en sag eller henvender jer på en eller anden måde til Service Desk, og til I finder ud af, at nu er en eller anden sag løst - enten fordi I selv finder ud af det, eller I får svar på, at nu er det løst. Det kan også være, I får svar, og det ikke er løst. Der er en masse situationer, man kan forestille sig. Hvordan ser det ud for jer i dag? R1: Det er sjældent, man får svar, at det er løst. I: Jeg skriver lige ned undervejs, men jeg hører, hvad I siger. Det er sjældent man får svar? R1: Ja, nogle gange får man svar på, at det er løst, og så er det ikke løst. R2: Jeg synes bare, processen inden at man når der til, at det er løst.. De er hurtigere til at sende, at nu har man opstartet Remedy på den, og så er det bare der. Så ligger den bare indtil man selv mister tålmodigheden. Jeg har i hvert fald i dag indgivet en klokken ti, og så går der ikke andet end et par minutter, så siger de: "Vi har oprettet den her sag" og så hører jeg ikke mere. Så når der er gået fyrre minutter, så skriver jeg, hvad sker der, og så ringer jeg ind. Jeg har sat høj prioritet på det hele. Altså, det er en, der haster, så vi sidder dernede, vi kan ikke lave noget. Det er totalt blokket. Hvis vi ikke får det op at køre, så kan vi ikke lave noget. Så sidder vi og spilder nogle mandetimer. Jeg hører stadigvæk ikke noget. Så ringer jeg ind. "Jamen den er sat til low" Det undrer jeg mig lidt over. Vi sidder og ikke kan lave noget. Med mindre man skriver de der "high", "emergency" eller et eller andet, så er det altså, så er det altså det, man går ud fra, uanset om man har sat prioriteringsflag på eller ej. I: Det er en besked, du får? R2: Ja. I: Så der er ikke nogen som sådan forklaring på hvorfor sagen.. Hvorfor de ikke gør det, du skriver? R2: Nej, og jeg kunne som udgangspunkt også tænke mig at forstå.. Eller kunne få oplyst, hvad man bør kunne forvente. Hvad er handlingen? Hvad er der af sagsgang på det her? Altså, når jeg indgiver noget, hvad er der så af samspil? Jeg kan jo kun se, at der er ping-pong, altså NNIT de opretter en Remedy og så skal de smække den over Service Operation og så er der ligesom sådan noget ping-pong imellem der, så man ved ikke rigtig, hvor er det, den ligger henne. Og jeg har heller ikke fået at vide endnu med den her, og nu skriver vi klokken et, jeg har heller ikke fået at vide, hvem den her er blevet assigned to, heller ikke. Jeg Bilag Side 125 af 185

126 har ikke hørt noget, så jeg er sådan lidt... Jeg tror, der er et eller andet forløb bagved, som er kendt for de implicerede parter, altså NNIT kender det, og som dem, som man taler med problemet om, Service Operation eller lignende. Men jeg som bruger mangler den viden, så for mig så kan det jo.. Virker det som om, man egentligt taget er ligeglad med det her problem. I: Er det et generelt billede, eller er det noget du kun oplever på den sag, du lige nævner her. Den specifikke.. R2: Den her specifikke sag, den har kørt, været samme problemstilling.. Vi er op på 15 gange siden februar måned. Hver gang så bliver det betragtet som et nyt problem i stedet for.. Altså, jeg refererer til tidligere Remedy-numre, og siger "prøv lige at høre, det er det her problem. I skal genstarte servereren." Jeg tror den faktisk er blevet sat op nu, hvor det her er et eller andet gentagende problem, nu skal man finde ud af, hvorfor det opstår. Det er bare sjovt, hvorfor der skal gå så lang tid, for at man sætter en lille arbejdsgruppe ned, og så siger "ok, hvorfor går den her server ned hele tiden? Hvad kan det skyldes?" Så der mangler ligesom noget historikopsamling, også. I: Det vil sige, at du refererer til en fejl, som opstår gentagne gange, og hver gang, den opstår, så er det som at starte forfra, og man undersøger ikke problemet til bunds? Man ved heller ikke nødvendigvis at du og eller andre har oplevet før? R2: Som udgangspunkt nej, for det er jo et nyt Remedy. Man siger "vi er godt klar over problemstillingen osv osv." I: Men oplever du, at du får at vide, når du melder det ind "vi ved godt, at det her er et problem, og du kan i øvrigt se mere om problemet her." R2: Nej. De informationer får man ikke. Jeg tror, hvis jeg husker tilbage, tror jeg en gang, at jeg har fået at vide, at der var en eller anden Ida - der indsamler informationer, men man hører ikke noget om hvordan og hvorledes det går. Det kan også godt være, man ikke skal vide det, men man kender bare ikke den forretningsgang, der ligger bagved, synes jeg med det der samspil. Det kunne jeg godt bruge, for at jeg ikke sådan måske virkede som sådan en lille Terrier, der hele tiden ringer og siger "hvad sker der nu? hvad sker der nu?" Det må jo også være forstyrrende for dem at blive hele tiden afbrudt. I: Er det noget der gør sig gældende generelt? R1: Jeg har ikke.. I: I er udvalgt, fordi I repræsenterer to forskellige områder. Du sidder med en ting, og du sidder med noget helt andet. Men i sidder begge to i en funktion der er tættere på IT end så mange andre områder i huset. Er det en situation, du kan nikke genkendende til? R2: Jeg vil sige, det her, det er jo ikke.. Min mest generelle.. Det er den her, som jeg hele tiden melder ind på, og fordi den er opstået rigtig, rigtig tit, så er jeg jo sådan rimelig sur over, at jeg ikke kan se, at der sker noget på området. I min verden så når man har løst problemet gentagende gange - fjorten gange før ved at Bilag Side 126 af 185

127 genstarte en server - så ville jeg jo mene, at det ikke burde være så kompliceret at gøre det igen, når jeg melder fejlen ind og refererer til et tidligere Remedy-nummer, for at man hurtigere kan fejlfinde og løse det her problem. R1: Jeg savner også noget opfølgning hurtigere, for jeg.. Man får den der besked med "vi har oprettet din sag" og så har jeg faktisk flere.. Og det synes jeg måske også er.. R2: Det er sådan et autosvar.. R1: Jo, men så sker der ikke noget, når jeg tager kontakt igen. Selvfølgelig gør der det nogle gange også, men jeg synes det er tit, hvor man sidder og tænker "okay hvornår.." Altså, så kunne man få at vide, nu er den blevet tildelt til den eller.. Jeg ved ikke hvor lang svarfrist, der er på den. Jeg ved ikke, om det er sådan noget med, at I skal svare inden for 48 timer.. R2: Man kan sige, det er jo igen den der med manglende.. Man mangler den der med, hvad tidsforløb har modparten til at sige "nu skal vi.. Vi har en time her og så har næste en time til at få den her tildelt en person her i huset, og så er der igen en time indtil man kan smække den tilbage til NNIT" Jeg mangler hele det der overblik over forretningsgangen, hvad ligger der der. I: Er det en situation der.. Altså for nu nævner du lidt det samme. Er det en situation, der gør sig gældende generelt? Britt du nævnte, at du havde en specifik sag, som kom igennem mange gange, og så siger du, Camilla, at du oplever også, at du ikke får svar. R1: Jeg mangler bare noget feedback. I: Det vil sige.. Det lyder som om, det er noget generelt. Det er ikke kun på den specifikke sag, det er generelt for... R2: Altså, overordnet så er det jo fordi, man har brug for at vide, hvordan går det med min sag. Jeg sidder.. Nogle gange så er det, man sidder med en fejl man melder ind, fordi du ikke kan komme videre. Det vil sige, man sidder jo og afventer på problemet her bliver løst, før jeg kan fuldføre den arbejdsopgave eller de arbejdsopgaver, som jeg nu skal gøre. R1: Jeg har jo ikke sådan nogle, hvor det er driftstop, men jeg har nogle sager, hvor der er sket et eller andet. Vi har haft de der OPD som skulle akteres her, vi fik lavet de der breve der skulle akteres, og så lavede jeg sådan en Remedy-sag og så hører jeg ikke noget. Så viser det sig, at ham, som skulle have fået sagen, han har.. Den er forsvundet. Den er blevet overset, og det er så, hvad det er, men så bliver man jo rykket fra resten af huset. Så begynder jeg jo at rykke. Jeg tænker bare, man har behov for lige som at.. Men jeg ved ikke, hvad jeres.. Altså, jeg ved ikke hvor lang buffer, der er. Det ville også være rart at vide. Hvis man bare fik at vide fra starten "jamen du får svar inden for 24 timer eller 48 timer" så kunne jeg lige som sige "Nå men inden for 48 timer.. Hvis ikke jeg har fået svar om to dage, så kontakter jeg jer" Det tror jeg, er et godt udgangspunkt i stedet for, jeg begynder at ringe inden for 24 timer, hvis der er 48 timer. Jeg ved ikke, om det står.. Det tror jeg ikke, det gør vel? Bilag Side 127 af 185

128 R2: Nej, men jeg tror, der er jo sådan en aftale mellem nogle andre, vi bare ikke har kendskab til. R1: Nej.. I: Så det vil sige, I oplever, at I ikke ved, hvad I kan forvente, og I kan heller ikke slå den information op nogen steder. R1: Nej, eller også har vi ikke fået information om, hvor vi kan finde det. Altså, det ved jeg ikke. Det kan godt være, den er der. Det skal jeg ikke kunne sige. I: Men hvis ikke du ved, hvor du skal søge den, så er den jo ikke tilgængelig for dig. R1: Nej, det er rigtigt. I: Oplever I at.. Altså Britt, nu sagde du før, at når du ringer ind, så siger de "ja, men hvis man ikke bruger nogle bestemte ord og sådan noget.." R2: Ja, men det er jo også hvad kategori. Det vil sige, hvad.. Low hvad bliver det betragtet som. Hvad er der af svartid på det? Også fordi jeg var oppe hvor man sagde, skal det være Emergency, så kom jeg til at tænke på, åh nej, er det noget, der koster penge eller, ej, så sætter jeg den til High, for den kan nok ikke koste penge. Det.. Jeg aner jo ikke hvornår at man kan sige, at det koster noget ekstra, hvis vi skal sige, de skal smide alt, hvad de har i hænderne. Så det er jo igen, det der.. Hvad ligger i de forskellige? Vi ved, de har det der low, medium, high, emergency, har jeg fundet ud af. Det, de har, er de fire kategorier. Men man aner jo heller ikke hvor mange sager, de har liggende der inde, så det kommer jo også an på, hvordan man så vælger at prioritere den opgave, man smækker ind. I: Når du siger, du har fundet ud af, at der er de der fire kategorier. Hvordan har du fundet ud af det? R2: Det fik jeg at vide, da jeg ringede i dag. R1: Det vælger man da ikke selv. Man laver den der mail. R2: Jo jo, men hvis jeg ikke noterer i mailen, har jeg fået at vide, hvordan den her skal prioriteres, så bliver de som udgangspunkt sat til low. R1: Nå, det har jeg aldrig fået at vide. Jamen, det troede jeg var noget, I gjorde - altså IT gjorde netop for at.. R2: Jeg troede også, det skulle igennem, men det fik jeg at vide af den, der var på vagt med.. R1: Altså, jeg ved godt, at der er noget, der hedder emergency, men så skal jeg også ringe til dem. Det har jeg fået at vide. Hvis det er meget vigtigt, så skal jeg ringe samtidig med, at jeg skriver. I: Hvordan ved du.. Altså hvordan er det kommet til dit vidende.. R1: Det har jeg fået at vide fra mund til mund, jeg har ikke læst det nogen steder. Bilag Side 128 af 185

129 I: Okay. Så der er altså noget med, at hvis man skal.. Hvis noget haster, så skal man ringe, men det er ikke noget, der står nogen steder. R1: Nej. R2: Og man kan sige, egentligt taget er det jo også svært, fordi hvordan vurderer den enkelte person et problem for dem, man selv har meldt ind, det synes man jo altid er vigtigt. Så det der med at finde ud af hvor i mængden, for man har jo ikke overblik over, hvad der ellers er meldt ind. Der ville det nok være hos jer, der skulle styre den del. Det gør den jo ikke, for den bliver først sat.. Den bliver sat ud hos NNIT, de sender den til low, så smækker de den bare videre hos jer. Og så ved jeg ikke hvordan Service Operation, hvordan de tolker den vigtighed som NNIT har sat på. Jeg har jo fundet ud af, hvis jeg vil have noget trumfet igennem, så skal jeg bare sætte den på high, så håber jeg på, der sker noget. I: Sker der så noget? R2: Det er jo ikke sket noget endnu. I: Og har du fået bekræftelse på..? R2: Jeg ringede og sagde hallo. "Jamen så skal du sætte den til high, det gør jeg lige med det samme" I: Og der har de så bekræftet, at de har sat sagen på, så det bliver.. R2: Nej, det gør de jo ikke. Det er mundligt. Jeg kan jo ikke se, det der de.. Der sagde hun jo, at så sender hun den over til Service Operation med, at den her skal opprioriteres. R1: Du kan ikke gå ind i Remedy eller hvad? R2: Jo, men de smækker ikke tilbage til mig som.. R1: Men du kan jo gå ind i worklog'en og følge.. R2: Ja, det har jeg så ikke kenskab til. R1: Nej okay. R2: Men det kunne da være meget smart, hvis jeg kunne gå ind og se, fordi jeg ringer jo til.. R1: Jamen jeg har jo adgang til Remedy, men det ved jeg ikke, om det er fordi, jeg har siddet i den afdeling heroppe. Jeg ved ikke om alle har det? Det har du så tilsyneladende ikke. R2: Jeg anede ikke, det eksisterede i hvert fald. For jeg har jo altid ringet. R1: Det gør jeg jo. Jeg går ind.. Altså, hvis ikke jeg får svar så går jeg ind i Remedy og ind i worklog'en, og hvis ikke der er sket noget, så tænker jeg, så kan jeg godt rykke. Men hvis jeg kan se, der kører noget korrespondance, nogle gange kører der jo noget mellem Visma eller NNIT eller så rykker jeg dem jo ikke, for så kan jeg se, der kører noget frem og tilbage. Bilag Side 129 af 185

130 R2: Ja, der er jeg jo så bare sådan en lille pestilens, fordi jeg ikke kan finde ud af, hvad der foregår, og ikke får nogen opfølgning. Så ringer jeg jo. I: Hvordan kan det være at du siger, du kan gå ind i systemet og følge op, og du siger, du ved ikke at du kan eller om du kan. R2: Jeg aner ikke, om jeg kan, for jeg ved ikke, hvor jeg skal gå ind og kigge henne. I: Okay. Hvis du Britt.. Nu har du sagt nogle gange, at når du indmelder en sag til Service Desk, så tager de sagen og hælder den videre til nogen her i huset, her i PenSam. R2: Det er det, jeg får at vide med de her ting, ja. Det er jo dem hos NNIT. Det er jo hos NNIT, der sidder og har vagten med de her problemer, der bliver meldt ind. I: Men når du siger, med de her problemer, der bliver meldt ind, refererer du så til den specifikke sag, der er opstået femten gange, eller er det generelt alt, hvad du melder ind.. Eller alt hvad I melder ind til Service Desk, det kommer tilbage til PenSam et eller andet sted i huset? R2: Generelt synes jeg tit. Jeg havde en anden sag med.. Jeg skulle have digital signatur installeret på min PC til brug for at kunne indberette nogle oplysninger til SKAT på deres hjemmeside. Jeg har så fået det hele fra Nets, så skulle jeg installere det, og så kunne jeg ikke det, for jeg er jo ikke brugeradministrator, så det kunne jeg ikke få lov til. Og så kørte det hele frem og tilbage i en uge, hvor jeg så.. Altså ham der er kontaktperson her fra os, vores administrator på det område, sagde så jeg skulle lave sådan en Remedy og så videre, og så fik jeg tilbage med sådan en, om jeg havde en kontostreng. Så tænkte jeg på.. Fordi jeg mener, når det er brugeradministration og sådan noget lignende. Jeg kan jo ikke gøre det, uanset hvordan, så kan jeg jo ikke få lov til at installere, så hvorfor det lige pludselig skulle koste penge.. I: Var det noget, der lige pludselig dukkede op, at nu skulle man til at betale for ydelsen? R2: Det mente ham, der havde besvaret min mail. Om det så var fordi, de har misforstået det, at de tænkte på, at de skulle sørge for at skaffe den licens der eller ej, det ved jeg ikke. Jeg havde jo skrevet, at jeg havde fået det hele og licensen og fået alt fra Nets. Installationskoder og hele molevitten. Jeg kunne bare ikke få lov til at installere de hjælpeprogrammer, der skulle til for at få digital signatur installeret på min PC. Så måtte jeg jo gå tilbage til vores administrator og sige "det kan ikke være rigtigt, jeg skal betale penge for det her?" Mine to andre kollegaer, der har det, de var jo så begge sygemeldte, så jeg kunne ikke rigtig lige.. Hvad de havde gjort. Men det endte jo så med, vi ikke skulle betale, fordi det er jo altså.. Til sidst.. Men det tog altså fjorten dage. I: Endte med at I ikke skulle betale fordi..? R2: Jeg vil skyde på, at det var ikke noget, der var ud over, end hvad der ligger i aftalen med NNIT jo. Men hvis man ikke ved bedre, så tænker jeg på.. Alligevel ved jeg godt, det måske er småpenge, men fjortenhundrede kroner er da alligevel også noget for en halvtimes arbejde for at få installeret noget, som.. Jamen det var bare det, jeg tænkte på, fordi jeg kan jo ikke gøre.. Jeg kan jo ikke komme uden om på nogen Bilag Side 130 af 185

131 som helst måde her som almindelig bruger, og når man så lige pludselig skal gå til sin chef og sige "jeg skal have en kontostreng" Der er jo nogle, der har sagt "jamen så er det det, jeg må gøre" for man ved ikke bedre. Jeg tænker bare på, det kan sgu ikke være rigtigt, jeg skal betale for det her. I: Vil det sige, at I heller ikke ved hvordan.. Nu siger du det kommer an på, hvordan kontrakten er skruet sammen. Mangler I oplysninger om, hvordan kontrakten er skruet sammen? Føler I, at der er noget, I ikke er klar over og I ikke ved hvor, I skal søge den information? Er det oplysninger, I mangler i jeres hverdag? R2: Jeg tror, nogle gange, så kan det være lidt svært at se, hvornår den skelner mellem en request som man siger, der er der budget inde over, altså hvor afdelingen selv skal vurdere, hvad der skal prioriteres op, eller hvad der ligger på den anden side, som er med i vedligeholdelse, eller hvad man kan sige. I: Der er forskel på de to kategorier? R2: Ja, der synes jeg grænsen er lidt svær, for hvis jeg ikke havde vidst bedre, så havde jeg jo nok dumpet i og sagt "jeg skal have den her kontostreng" og så smækket den videre, fordi nu skal jeg altså have indberettet noget til SKAT. Det kan også godt være, man kan finde informationer, men når man sidder i nuet, så tænker man på "øøøh". I: Er det et behov, I har, som I føler, ikke er opfyldt? Mangler I den information? Ville det kunne være en fordel at kunne se det? R2: Det kan jo godt være, det ikke er for alle, men jeg synes, det ville være rart at kunne se hvornår, fordi så kan det jo også være, det er lidt med i ens prioriteringer, om det her nu er nødvendigt eller om nogle andre ting. R1: Det ville også lette jobbet på den anden side af bordet. I: Hvad er på den anden side af bordet? R1: Det er hos NNIT for eksempel. Hvis man får nogle informationer.. Man får at vide hvad man skal fylde ind eller hvad man skal oplyse om, så skal de ikke bede om det, så har de lige som givet det på forhånd i stedet for, de siger "vil du ikke være sød at sende en kontostreng eller vil du ikke være sød at oplyse, om den skal være high eller medium eller.." Altså, man skal måske hjælpe dem. Folk bruger også til at udfylde en Request bedre end vi gør. Det kan da godt være man udfylder den sådan lidt. Man aner ikke.. Altså, jeg skulle lave en eller anden her for nyligt, hvor jeg tænker "gad vide hvilke informationer, jeg skal give?" Jeg kan ikke tale med en udvikler. Så står de jo nede ved mit skrivebord på et tidspunkt og siger "hvad mener du?" Og så siger jeg "Jamen det har jeg da skrevet?" Vi taler forbi hinanden. Jeg tænkte, det ville være meget fedt, hvis man kunne.. R2: Jamen også bare at når vi fejlmelder noget. Hvad er det de har brug for? Er det styresystemet eller programmet eller hvor ligger vi henne? Hvad kan de se, det hedder og sådan noget. R1: Det er nogle gange udfordrende bare at skulle skrive sådan en mail, synes jeg. Bilag Side 131 af 185

132 I: Prøv at uddybe det lidt. R1: Der, hvor jeg har arbejdet før, der, hvis vi skulle lave sådan en request, der hed det en ticket, så gik man ind i sådan et program og så var der nogle drop-downs, hvor man kunnne gå ind og vælge, hvad omhandlede det.. Hvilket system var det, man fejlmeldte. Hvad gik det ud på. Var det noget med det ene eller.. Så var man sådan en hel menu igennem, og så til sidst så skulle man så udfylde, hvad problemet handlede om. Men det lettede lidt, fordi der var en masse ting, som havde en, var præ-udfyldt. Så tænker jeg, at IT på den anden side af bordet lige som også kan sige, i stedet for jeg sidder der med mine egne mærkelige formuleringer og prøver at forklare "jamen det handler om.. og måske har det noget at gøre med kernen og måske.." Jeg tænker, det kunne lette for begge parter. R2: Vi har sådan et skema, ved jeg, hvis man går ind gennem Intranettet, men det er sjældent man gør det. R1: Ja, men det er hvis du fejlmelder noget. Nogen gange stiller man også bare et spørgsmål. R2: Ja til Request. I: Britt du siger noget med et skema? R2: Ja på intranettet, det der gamle indgangsvinkel via intranettet, der var jo helt oppe i hjørnet et eller andet skærmbillede et eller anden.. Det er sådan en Remedy. Men nogle gange så er det jo. R1: Den er meget statisk, synes jeg. R2: Det er jo et gængs skema, og uanset hvad det er, så er det et på to en halv side, og det er jo ikke altid man lige gider alt det der igennem. R1: Det passer altså heller ikke altid lige ind i det, man skal bruge. R2: Nej. R1: Det er sådan meget med, hvordan opstår fejlen, og skærmbillede og.. R2: Man kan sige, at det, der er vigtigt for dem, det er måske at sætte sig ned og sige "hvad har vi som minimum behov for at få oplyst?" I: Så det vil sige, der findes en skabelon, som man kan udfylde til at.. Altså sådan så man i højere grad sikrer at de oplysninger, der er nødvendige, kommer med, men den bliver ikke brugt fordi den er for generisk Er det sådan at forstå? R2: Altså, jeg vil sige, det er sjældent. Hvis jeg går ind og fejlmelder noget så er det via mailen. R1: Jeg synes, det er nemmere at skrive en mail end at bruge det der skema, vil jeg sige. R2: Ja. I: Hvorfor er det nemmere? Bilag Side 132 af 185

133 R1: Jamen, det er fordi, jeg synes ikke den passer. Altså så skal man.. Nu er det et stykke tid siden jeg har været der inde. Men så er der sådan nogle spørgsmål.. R2: Der er tyve punkter, du skal tage stilling til. R1: For det første tyve punkter, man skal tage stilling til, den er meget lang. Og for det andet, så er det sådan noget, hvor man så sådan "nej, det er ikke det.. Et skærmbillede.. Nej det er det heller ikke lige.." Og hvis det er en eller anden kørsel, så kan jeg jo ikke levere et skærmbillede, og jeg har slet ikke adgang til systemerne, så jeg tænker bare, den er meget fastlåst i sin form. Jeg kan ikke bevæge mig ret meget uden for rammerne, og så er det nemmere for mig at skrive en mail. I: Camilla du nævnte før et system fra en tidligere arbejdsplads, hvor det var noget med nogle drop downmenuer og sådan noget. Har det været noget, der var mere dynamisk end den? R1: Ja, for der kunne jeg gå ind og vælge nogle forskellige scenarier, som så også passede på vores system der. I: Ville det få jer til at bruge et sådan skema mere, hvis det var mere dynamisk og mere tilpasset de forskellige scenarier? R1: Ja, hvis ikke det har tyve punkter, ja. Det skal heller ikke tage en halv time at udfylde, vel? Ja, det tror jeg. Det gjorde jeg jo, der hvor jeg kom fra. R2: Hvad skal man sige.. Jeg har jo ikke som sådan noget imod at der bliver stillet krav til, hvad de som minimum skal have at vide, men de der standardskemaer, hvor man har svært ved at passe ind, når man skal udfylde. Det er nødvendigt, og det er nødvendigt og hvor meget kan man skippe over og sådan noget lignende. Det er ikke klart. I: Hvis nu vi skulle fokusere lidt på de udfordringer, der er i den situation, som den er i dag. Hvad ser I som de største eller sådan mest umiddelbare udfordringer i hele det her setup? R1: Det er, at der er for få mennesker til at løse for mange opgaver, tror jeg. R2: Ja, og manglende kommunikation simpelthen. Man ved jo ikke rigtig, hvad man kan forvente. R1: Ja, også det. R2: Jeg synes, der mangler kommunikation. Altså det der med.. I: Og når du siger manglende kommunikation Britt, så er det.. I hvilket led taler vi om? R2: Jamen det eneste led, som Camilla siger, det eneste led vi får det, det der den der med "du har oprettet din sag" eller hvad man kan sige. Og så venter man, og så tænker man på "nå, hvornår hører jeg noget? Hvornår kan jeg tillade mig at rykke? Hvordan er den prioriteret? Skal jeg selv prioritere den? Det har jeg jo så fundet ud af efterhånden, at det skal man, hvor jeg siger, det er måske ikke helt OK, at den enkelte bruger skal lave prioriteringen. Bilag Side 133 af 185

134 R1: Men jeg har også indtryk af.. I har også mange driftstoppende ting ikke? R2: Jo. R1: Hvis der er mange driftstoppende ting, så når jeg kommer med mine Requests, så kan jeg godt forestille mig, hvor de ligger i prioriteringen. Så kommer det langt ned. Det kunne også være fedt, hvis der var nogen, der sad med alt det, som var driftstoppende kun og nogle, der sad med det, som bare var almindelig Request. Altså som også skal løses, men det er ikke noget.. Mit når jeg sender det ind, så er det ikke sådan noget bål og brand. Jeg vil bare gerne have det løst hurtigst muligt, fordi det er jo et problem, ellers havde jeg ikke lavet en Request. R2: Men det er jo det der, hvis det er low den er sat til i en eller anden kategori, jamen så hører du fra os inden for 24 timer, så ved man.. Jamen så er det også lige som om, så kan man sige "jamen så kan jeg sgu da vente ikke?" Så kan jeg sætte den til side, og så kan jeg fokusere på det næste område. R1: Men man skal også kunne opfylde det krav fra den.. Altså hvis nu man har lavet sådan en med "vi svarer inden for 48 timer." Hvis der så bare kommer 48 Emergency Requests ind, altså det er måske også lidt ekstremt, men hvis der er mange af dem, så er det svært, at nå de andre. Jeg tænker bare, der burde sidde sådan et Emergency Team. Eller Emergency og High Incident. Jeg ved ikke.. Jeg har bare indtryk af.. Jeg synes tit, jeg hører, I har noget, der er driftstoppende. R2: Ja, men altså det der vi har haft, det er jo en webservice-funktion, som går ned hele tiden, som vi primært har oplevet de der snart femten gange siden slutningen af februar, hvor vi gik i luften igen efter.. I: Det er femten gange siden slutningen af februar, det er ikke femten gange i alt? R2: Nej, det er siden februar. Men det er jo fordi, efter den der sidste idriftsættelse, vi har haft med opdatering af de forskellige ting i kernerne, der har været her efter årsafslutningen. R1: Hvad er kernerne? R2: Jamen hos os så er det jo PMF Edlund-kernen, hvor vi har haft problemer på grund af at.. Vi er jo ikke.. Man kan sige, de hændelser, som vi laver, de er jo ikke IT-understøttet i kernen, så vi har jo vores hjælpeark, som er excel, som så kører på nogle webservere, der så gør at man har mulighed for at indlæse data fra kernen. Og den service, URL-webservice der, den går ned eller ryger af eller går tabt. I: Så der mangler en eller anden funktionalitet i et system, hvilket gør at I er nødt til at foretage korrigerende foranstaltninger, og det er så dem, der er noget galt med. R2: Så man kan sige, det er ikke kernen som sådan, den kører, som den skal. Det er også derfor, man oplever i Tradition og Fleksion, de ting de kan i kernerne, de fungerer, men lige så snart, vi går over til nogle kopisystemer eller til nogle andre hjælpesystemer, så er det så sårbart, fordi så er det jo ikke lige pludselig kun en ting, så er der jo.. Altså, jo flere led, den skal kommunikere igennem, jo større chance er der for, at der er noget, der går galt. Bilag Side 134 af 185

135 R1: Jeg har faktisk lidt svært ved at vurdere, men det er jo også fordi man ikke ved.. Jeg kan ikke forstå hvad, NNITs rolle er. Man laver sådan en Request, og så ryger den ud til NNIT. R2: Som så smider den tilbage her til. R1: Men de løser den sjældent. Det er jo nogen her i huset som tit løser den problem man har. R2: Ja, visse punkter så ser det ud som om, man bare har et mellemled. R1: Jeg ved ikke om det.. Det kan godt være, det er fuldstændig forkert opfattet. Men jeg synes, det er.. Jeg tænker bare, at så er der meget få mennesker her i huset som kan løse de mange, mange problemstillinger, vi sender af sted, hvis NNIT ikke bærer den opgave. Jeg ved slet ikke, om de kan, og om det er det, der er meningen. Mit indtryk er bare, at mange af de opgaver man sender af sted, der ryger som sådan en elastik eller boomerang lige tilbage i hovedet på os. R2: Det har jeg også. R1: Det kan godt være, det er helt forkert. R2: Men der er oftest, når man ringer og spørger "hvad sker der med den her?" så siger de "jamen den er tildelt Service Operation" der kan man spørge hvorfor. I: Jeg skal bare lige holde fast, at der er ikke noget, der er forkert inde i det her rum, fordi det, det handler om, det er at afdække, hvad er jeres oplevelse af situationen. R1: Ja, men det er måske også fordi.. Jeg ved jo ikke, hvad aftalen er. Så jeg tænker bare.. min tanke er bare, at hvis alle de.. Jeg har ikke lavet så mange, mine de er ikke driftstoppende, men jeg laver alligevel en del, og jeg tænker bare, alle dem som jeg sender af sted, som alligevel nogle af dem er lidt tunge at løse. Hvis de så alligevel kommer tilbage som sådan en boomerang her til huset, så kan jeg godt forstå, der går lang tid før, at de bliver løst. I: Det er bare for at slå fast, der er ikke tale om.. Altså du kan jo ikke holdes til ansvar for et eller andet, som du ikke ved. Så det, det her handler om, det er at afdække hvor meget af den information, som IT tror er meldt ud i forretningen, kender I faktisk. Kommer det ud til jer, når vi forsøger at gøre et e eller andet. R1: Det går.. Det kan være man bare ikke har forstået det eller. I: Det handler om, hvad er jeres oplevelse af situationen. Hvordan føler I.. Hvordan oplever I at tingene foregår. Så derfor er der ikke noget, der er forkert. R1: Nej nej, jeg tænker bare.. Min tanke er bare, jeg forstår ikke.. Som Britt også siger. For mig er NNIT nogle gange bare et forstyrrende ekstra led, for det ville være nemmere, hvis jeg bare gik op til dem, som alligevel får opgaven. Det staller lige som derude mange gange. R2: Jeg kan jo blankt erkende, jeg skriver jo til.. Når jeg laver sådan en Remedy næsten nu, som jeg sender til NNIT, så sætter jeg altså cc på til Torben, fordi han plejer altid at få opgaverne. Det er måske frækt, og Bilag Side 135 af 185

136 man ikke må det, men jeg tænker på, at så er det lige som om, så ved han, at der er noget i vente. Så kan han nå at gøre noget inden der skal gå så lang tid. Men man kan sige, det er én mand igen. Det er så sårbart.. R1: Det er det tit. R2: Ja, det er én mand, der er tildelt ét område, og så kommer det så an på hvor meget møg, der er med det område. Hvor meget der bliver lagt ned. R1: Du er ikke den eneste, som skriver eller laver måske en Remedy på det område. R2: Nej lige præcis. R1: Du er bare den eneste, der sætter ham cc. R2: Ja. I: I siger det tit er kun en person, der er.. Sidder med noget. R2: Det lyder som. Nu ved jeg ikke, hvis man skiller det op.. PMF så er det Torben. Edlund-kernen så er det ofte Torben, som ender med at rende med dem, synes jeg. I: Gør det sig gældende generelt, at der er en person, der sidder med et eller andet bestemt? Altså hvis nu du meldte en sag ind på et andet område, er det så lige så personfølsomt? R1: Det er min oplevelse. R2: Det ved jeg ikke rigtig, for jeg har jo siddet med.. Fejlmelder mest noget som har med kernerne at gøre. Altså hvor der er et eller andet samspil mellem vores hjælpeprogrammer, som ikke virker. Men oftest har jeg jo.. Det er jo derfor, jeg er så fræk at sætte ham på. Det er jo egentligt taget lidt flabet, for man ved ikke, hvad hans ellers har fået af opgaver, eller om han er her eller et eller andet andet. I: Oplever I, at I får den tilbagemelding? Altså Britt når du siger, at du.. R2: Nogle gange så får jeg at vide, at den her opgave er blevet tildelt.. Altså den her vi har haft femten gange siden februar. Hver gang hvis de har meldt tilbage med hvem, den er blevet tildelt, så har det været Torben. I: Hvis de har.. Det vil sige, det gør de ikke hver gang? R2: Nej. I: Men oplever du at.. Du griner lidt af det, og du siger, det er lidt flabet. Får du den tilbagemelding? R2: Nej, men jeg tænker bare, jeg ville da blive nok sådan noget træt, hvis det var mig der sad, for at sige i den funktion og så hele tiden fik cc på alle. Det kan også være, at man til sidst har sagt "jeg gider ikke se på cc-mailen. R1: Men det virker åbenbart, siden du gør det eller hvad? Bilag Side 136 af 185

137 R2: Det ved jeg ikke. Det er et håb. R1: Men kan du konstatere, at der sker noget mere i sagen, hvis du sender en fejlmelding til NNIT med cc til Torben, end hvis du bare sender den. Altså får du noget ud af at sende den cc? R2: Lige i dag har jeg ikke.. Men nogle gange så går det altså hurtigere, vil jeg sige. I: Det gør det? R2: Ja, og jeg er jo også begyndt med de fejlmeldinger, nu så er Gitte ind over også, for nu er det simpelthen sket så mange gange, så nu bør man hos NNIT sætte sig ned og finde ud af, hvad er det, der gør, at det samme problem opstår så mange gange. I: Sender du nogensinde en fejlmelding til en eller anden person her i huset direkte uden at gå til Service Desk? R2: Nej, det vil jeg ikke gøre, for der er alligevel noget med, at det skal jo ind via de rigtige kanaler, så man kan se.. Og jeg har en eller anden ide om at NNIT bliver målt på, at de skal have sendt den her.. Svaret et eller andet autosvar eller et eller andet inden for x-antal tid. R1: Jeg håber ikke, det er den der autosvar, de bliver målt på. I: Tror I, I ville få hurtigere svar, hvis I gik direkte til en herfra end hvis sagen gik rundt om Service Desk? R1: Ja måske et mere konkret svar end bare den der "vi har modtaget din sag". Men det er ikke sikkert at opgaven bliver løst hurtigere. I: Men tror du sagsbehandlingen - altså løsningen af et problem - ville gå hurtigere? R1: Nej, det tror jeg ikke, men det kunne godt være, jeg ville få et svar hurtigere måske bare ved at sige "jamen jeg skal nok kigge på det, jeg vender tilbage om en uge" eller "jeg har ikke tid lige nu." Men det ville være svar nok i første omgang i stedet for, man bare får sådan en "vi har oprettet din sag." Så sidder man sådan lidt "jamen hvornår hører jeg så noget næste gang?" Jeg tror ikke nødvendigvis, opgaven bliver løst hurtigere, fordi den havner jo alligevel herude. B. De eneste ting som. Der når de er lidt større. Driftstop og nogle måske lidt længere processer, hvor man skal undersøge mere, at der går det nok ikke hurtigere vil jeg så sige altid. Men jeg har jo oplevet, bare det der med det lille eksempel, jeg havde med digital signatur, jeg skulle have installeret. Der kunne jeg jo bare have gået ned, den gang Service Desk lå hernede og sige "Hej. Prøv lige at hør jeg har meldt den her ind. Jeg har ikke hørt noget." Og så oftest tidligere, hvis vi manglede nogle brugerrettigheder eller et eller andet andet, så kom de jo. R1: Ja, der mangler altså lidt sådan et kontaktpunkt her i huset, synes jeg. Ikke at man skal rende ned til dem, men nogle gange er det bare rart at kunne gå et sted hen og tale med nogen. Jeg ved ikke, nu er det længe siden, jeg har.. Jeg ved ikke, om der sidder nogen stadigvæk. Bilag Side 137 af 185

138 R2: Opgaven er også nogle gange lidt mere alvorlig, når det er, at man har en direkte kontakt nogle gange. Altså man ved at kunden kan finde på at komme. R1: Og så på et tidspunkt satte de sådan et skilt op. Jeg ved ikke, om de stadig sidder hernede Service Desk. På et tidspunkt satte de sådan et skilt op, man måtte ikke komme derned, man måtte kun ringe, og der kan jeg huske, jeg havde det sådan lidt.. I: Hvad var jeres oplevelse så af det? R1: Det synes jeg bare er.. R2: Jeg synes, det er lidt flabet. R1: Ja, det synes jeg faktisk. Ikke flabet men jeg synes faktisk, det er sådan lidt underligt. Det er en servicefunktion. R2: Som vi betaler for. R1: Som er til stede i huset, og vi betaler for det, og de skal selvfølgelig lave nogle ting, som de er blevet bedt om. Nogle gange er det bare rart at kunne gå ned og tale med nogle mennesker, inden at jeg begynder at sætte mig ned og skrive, fordi de måske kunne afhjælpe nogle ting, i stedet for jeg går op og skriver en eller anden mail, som der ikke er nogen, der forstår, og så skal de alligevel henvende sig tilbage til mig og sige "hvad foregår der her?" R2: Oplevelsen er i hvert fald at i sådan nogle, der er meget ping-pong frem og tilbage, inden at en sag både bliver tildelt en bestemt person og løst. R1: Ja og nogle gange er en sag jo måske ikke en sag.. Så kan det jo være, de kan sige "jamen du skal bare gøre sådan." Så kan jeg gå ned på min plads og være glad, og ikke frustreret over at der ikke sker en skid før om halvanden dag, når de har tid. Det bliver meget bureaukratisk, synes jeg. Det bliver meget administrativt tungt det der system. I: Og når du siger det der system, så mener du? R1: Service Desk. I: Hvad kunne man forestille sig, at der ville være af muligheder for at forbedre den situation givet de udfordringer, I har nævnt her? R2: En tilbagemelding på en tidshorisont selvom.. Jeg ved selvfølgelig godt, det kan være risikabelt. R1: Ja, så skal man bare kunne leve op til de ting, man lover. Det nytter ikke noget, at man siger "vi svarer tilbage inden 24 timer, og vi løser opgaven inden en uge" hvis man så ved at der går tre uger før opgaven overhovedet bliver taget fat i. Så det kræver, der er ressourcer til at løbe med opgaverne i virkeligheden. Og så kræver det vel også, at dem, som modtager vores Service Requests, de ved.. Fordeler dem til de rigtige mennesker, for nogle gange cykler det altså lidt rundt omkring, synes jeg. Hvis man følger den der Bilag Side 138 af 185

139 worklog, så nogle gange kan man se, "det er ikke mig" "jamen det er heller ikke mig." Der er ikke rigtig nogen, der ved, hvem der har problemet. Hvem har fnatten? R2: Nej og nogle gange er den også kommet tilbage igen. Den kan jo også sådan blive tildelt os. Et problem som vi har stillet er blevet tildelt os. Hvor man bare tænker "jamen jeg har bedt om hjælp!" R1: Ja, det hvor det kom fra os. Men jeg ved ikke.. Dem, som sidder ude hos NNIT, er det tidligere PenSam folk stadig? Jeg tænker, det må også være svært for dem.. R2: Jeg tror, nogle er, og nogle er ikke. I: Du siger det er "stadig"? R1: Jamen, det har været ikke? I: Har det det? R1: Ja. Men så tænker jeg, det må være svært for NNIT også at kende.. Hvis jeg sender et eller andet problem.. R2: De kender jo ikke de programmer, de systemer vi.. R1: Det giver ikke rigtig mening, at det skal der ud, synes jeg, altid. Så kan jeg godt forstå, de vender tilbage, men hvorfor så ikke bare holde det inden for husets fire vægge? I: Hvad kunne grunden være til, at man har valgt at outsource Service Desk til NNIT? R1: Det har jeg ingen ide om. I: I stedet for at holde den inden for.. R2: Det sad jeg lige og tænkte på. Prøver at komme i tanke om, hvad man havde sagt på daværende tidspunkt. Jeg kan simpelthen ikke huske.. R1: Det var for at spare penge, var det ikke? R2: Jo, men det er jo.. R1: Det forstår jeg så stadigvæk ikke. I: Hvad mener du, når du siger Camilla, at du ikke forstår.. R1: Jamen, jeg kan ikke forstå, at det skal spare penge, hvis det alligevel, når man sender noget ind.. Altså hvis man sender en Request til nogen, som skal hjælpe en, og det så alligevel kommer tilbage her til huset, så er det nogen her i huset, som skal løbe efter.. Jeg går ud fra, det er fordi, man mangler ressourcer her i huset, at man så outsourcer det, så der er nogle andre, der kan hjælpe. Men hvis tingene så kommer tilbage, så er det jo lige meget. Så er det jo nærmest, i min verden, bare at man har et forstyrrende led. R2: Ja og så er vi endnu færre mennesker, end vi var før. Bilag Side 139 af 185

140 R1: Ja og betaler for en service, som vi alligevel selv løser i sidste ende. R2: Fordi så er de jo faktisk bare.. NNIT er jo faktisk bare administrator af de Remedies, som vi indmelder. R1: Ja, de sidder bare og fordeler dem, og hvis de ikke ved, hvem man skal fordele dem til, så er det jo nogen her i huset, der fordeler dem. Det har jeg altså lidt indtryk af, at det er det, der sker nogle gange. Det kan godt være, det er helt forkert. I: Hvordan kunne man så forbedre det? Hvad skal der til for, at I oplever, at den service, som Service Desk stiller til rådighed, i højere grad lever op til jeres behov, jeres forventninger? R1: Jamen, jeg tror helt klart, at de skal sidde internt, fordi som oftest når du har et problem, sådan nogle problemer som Britt har, så har du brug for hjælp her og nu, og så nytter det ikke, at det skal køre her fra og ud til NNIT og tilbage hertil.. Så har du behov for, at der er nogle, der her internt i huset kan hjælpe dig. Du måske kan gå ned og tale med dem, eller de kan komme op og tale med dig. Det bare.. Der mangler noget nærhed i virkeligheden, tror jeg.. Og så tror jeg, altså det er bare mig.. Jeg synes også, der er behov for at der siddet et team eller nogle mennesker, som er dedikeret til det hundrede procent. R2: Ja kun skal lave det, og ikke har fyrre andre opgaver.. R1: Så kan det godt være, det kører i turnus, men det kan ikke nytte noget, at man har en masse opgaver, og så derudover skal løse de der, som kommer ind som sådan noget emergency. Så bliver de andre opgaver bare aldrig løst, tror jeg. R2: Jeg kunne godt bruge adgang til det der, hvor man kan se, hvad der sker med mit sagsnummer. Lige som man kan følge sit.. R1: Men har du ikke adgang til Remedy? R2: Jamen jeg ved jo ikke, hvor det er henne. R1: Nej, men du kan ikke gå ind i Remedy? Du har ikke et password til det? R2: Nej. Men jeg kunne jo godt bruge, lige som man kan følge sin pakke, når man har bestilt en der bliver sendt med en eller anden pakkepost eller Post Danmark, GLS eller hvad det er, man kan følge. R1: Ja, men når du får den der autoreply, så er der jo sådan et sagsnummer. R2: Ja, men jeg skal jo ringe og høre "hvad sker der med den her?" R1: Nå, du kan ikke gå ind i systemet. Det kan jeg. R2: Det er jo der. Den kunne jeg jo godt bruge den der log, så jeg kan se, hvad det er. Så jeg kan se "okay, de har gang i.." R1: Jeg vil så sige, den er heller ikke så brugervenlig for ikke-it-kundige. Bilag Side 140 af 185

141 R2: Men det kunne jo godt være, man kunne lave lige som når man følger sin pakke fra pakkepost, at man kunne se.. At man kunne taste det der nummer ind, og så kunne man se, hvad sker der, og også at man har mulighed for at se, hvad prioriteringen er, og hvad er den forventede tid på at løse det her eller et eller andet, sådan så man ikke bare sidder tilbage og venter. Nogle gange tænker man "ej, jeg må nok hellere lige vente lidt til. Jeg må nok lige vente lidt til inden jeg lige tager fat" fordi man er alligevel menneske og tænker på, ok, hvordan ville jeg mon ha' det hvis der var nogen, der stod og åndede mig i nakken hele tiden. I: Så du udskyder at rykke for en sag, du ikke har hørt fra, fordi du tænker at der.. R2: Jamen jeg mangler jo det der, der siger, hvad er tidsfristen for at løse det her problem. Hvad skal jeg skrive, for at den bliver sat op til high? Skal jeg skrive driftstop eller hvad for nogle termer, hvad for nogle ord skal jeg bruge for, at vi taler samme sprog? Og kan jeg bare skrive et eller andet som hedder hændelsesark, ved de så, hvad jeg snakker om eller er det noget andet, jeg skal nævne for at det er med til, at den her opgave bliver løst hurtigt, sådan så de ikke først skal sidde og finde ud af "hvad er det damen mener, er det det her eller er det det her?" I: Hvordan kunne man så konkret løse det? For du nævner to ting der. Hvad skal jeg gøre, for at få opprioriteret en sag som haster, og hvad skal jeg gøre for, de forstår, hvad jeg mener. Hvordan kunne man.. Hvordan kunne vi indrette den modtagelse af din henvendelse, sådan så vi i højere grad forstår, hvad du siger, når du kommer og siger "her er et problem." R2: Det ved jeg ikke, der har jeg det jo sådan, at der må NNIT med på banen. Jeg ved jo ikke lige hvordan.. Noget der kan være indlysende for mig.. Man sidder og arbejder i firmaet, man kender programmerne, man kender systemerne, man bruger måske nogle fagudtryk om nogle bestemte ting. Der er der jo.. Der må jo være et samspil om, hvordan får vi det her enkelt. Altså måske fire drop down-menuer, man lige skal udfylde og så nogle gange, tror jeg også bare, den der log at man kan se.. Altså der er et eller andet med, hvor ligger den her henne? Jeg kan godt lide den tanke om, at man kan følge det, man har sat i værk. Hvor ligger den henne? I: Når du siger det der med forretningsspecifikke og et specielt sprog.. Altså hvad hedder de her systemer og sådan noget. Er det så et udtryk for, at du oplever at NNIT, at Service Desk, ikke forstår dit sprog, når du henvender dig? R2: Jamen, der er nogle gange, hvor jeg tænker.. For mig der.. De problemstillinger som jeg indrapporterer noget på i dag, som jeg ikke en gang ved om er løst endnu, at hvis jeg skriver PMF og hændelsesark, ved de så hvad det er, eller skal jeg bruge.. At sige det er en URL til en webservice, det er den her.. Hvad er det, jeg skal bruge? I: Men ved de det? Hvis du skriver, som du gør, forstår de så, hvad du mener? Bilag Side 141 af 185

142 R2: Jamen, jeg har jo ikke fået det modsatte. Jeg har ikke fået svar, hvor de ikke gør det. Så i min verden må de jo gøre det, men så synes jeg bare, det er utroligt, der går så lang tid, inden at tingene bliver løst, hvis man har forstået hvad opgaven går ud på, og at den her ting som jeg har nævnt med de femten episoder. Jeg meldte den ind og nu skriver vi snart klokken 14. Og som jeg også nogle gange siger, det er jo ikke kun to nede i vores afdeling, der er altså også nogle andre rundt om i huset, som også er afhængige, som sidder og regner på nogle ting og hiver nogle data ud via den her webservice-funktion. Jeg skriver endda ind, hvad den webserver hedder, så langt er jeg nået til, så jeg også skriver ind, hvad det er for en. Og så synes jeg måske, det er lidt sårbart, fordi jeg tænker på, nogle gange kan jeg godt tænke på, er Torben her i dag, når jeg har indmeldt den her? Ligger den så bare og venter på, at han kommer tilbage? Det kan jeg godt frygte lidt, når der går så lang tid, og det skal jo ikke være sådan. Det er jo utrolig sårbart. R1: Det er heller ikke fedt for Torben. R2: Nej, det er det da ikke. Men sådan er det jo lige som om, man har spændt lidt ben for sig selv synes jeg, PenSam nogle gange har gjort, med at man har lavet nogle aftaler, og så ender det med at være en person her i huset, som sidder for det. Det har vi jo oplevet også med andre projekter, hvor det er det samme. Man må kalde ind igen og igen og igen. Og der sker de samme fejl igen og igen og igen.. For eksempel med skatteindberetningen også der har vi jo også nogle udfordringer med, hvordan man kan trække ting ud af vores system og så videre også. I: Britt når du siger det med at den person, der nu skal løse en eller anden given problemstilling er til stede eller ej.. R2: Det er jo bare noget, som jeg sidder og føler. Jeg tænker på, at nu har jeg jo fundet ud af, at alle de gange, jeg har indrapporteret noget, som vedrører kernen og kommunikation fra kernen til andre systemer, så er det, i hvert fald til noget regnearksbaseret, så er det Torben. Så sidder jeg jo tænker på, når jeg kan se det der mønster igen og igen, så kan jeg jo godt sidde og tænke "når der ikke er sket noget over en længere periode, jeg har ikke hørt noget, og den er heller ikke blevet tildelt nogen endnu" så tænker jeg på "gad vide om Torben er her." I: Hvad har det af.. Altså hvis Torben ikke er her, hvad så? R2: Jamen det ved jeg jo ikke. Så kan det godt være der ikke sker noget før i morgen, tænker jeg jo på, at det måske er derfor. Jeg sidder jo og laver oppe i mit hoved nogle episoder, hvor jeg tænker på "nå, det er derfor, det tager så lang tid. Torben er her ikke i dag. Gad vide hvornår han kommer tilbage, så jeg kan få løst det her." Og det går jo bare ikke. Der er et eller andet med, at man skal tænke på det som en forretning. Der er ikke rigtig noget hvor at.. Jeg tænker på, at nogle gange hvis man kunne lave sådan en business case, hvor man kan sige, hvis det her ikke komme op inden for en time, så koster det også det. Jeg har på fornemmelsen, at der skal kroner og øre på for nogle gange, at man tager alvorlighed i de problemstillinger, man kommer med. Altså lige som at sige "nu har jeg siddet ikke og kunnet lave noget i en halv dag. Hvad koster det i kroner og øre? Er vi andre personer, der har det samme? Hvad koster det? Hvad Bilag Side 142 af 185

143 har det af betydning?" "Jamen det har betydning for, at her der er tyve kunder, der ikke får svar på deres henvendelser, for det kan være noget, jeg måske kunne have nået at lave." Sådan så man har den der.. I: Så hvis nu vi skulle opsummere her til sidst, hvor der ikke er så lang tid tilbage. Hvad kunne man konkret gøre for at gøre det nemmere for jer? R2: Altså jeg vil gerne have "Post Danmark-funktionen" R1: Den har jeg jo. R2: Jeg kunne godt tænke mig, man fik sådan en nem og overskuelig en hvor man kunne se.. Fordi så havde NNIT også.. Hvis de bare oprettede det en gang i et system, så kunne de jo også give oplysningerne om.. Jeg vil jo kunne se, sådan så det ikke er mig, der skal prioritere opgaven. Så kan jeg jo se, hvad den er blevet prioriteret som, ud fra måske at man har nogle drop drowns - hedder det driftstop, kan du ikke komme videre, hvis det her ikke blive løst. På den måde.. Og så derefter er der for NNIT, eller os eller huset eller hvor det ligger henne, nogle ekspeditionstider, så man kan sige, hvornår skal det her være løst inden, for den har driftstop eller et eller andet tilsvarende. Det kunne man jo godt lægge i sådan en funktion der, der hedder "følg sagen" eller et eller andet. Der er jo mange informationer, der kan smækkes ned der, hvis man kunne gøre det, som du siger brugervenligt, for det lyder det ikke som om, det er. Og så er det også sådan med, at jeg har ikke behov for at vide, at der er fyrre mennesker, der siger "nej, det er ikke mig, det er ikke mig.." Jeg tænker på de der overordnede ting på "den og den er blevet tildelt her, vi forventer at den kan løses inden der, ud fra at det er driftstop eller et eller andet. I: Ville det afhjælpe den situation med, at I føler, at I ikke får svar? R1: Nej, der skal flere ressourcer til. R2: Ja, der skal flere ressourcer til. R1: Og mere organiseret. Altså, jeg ved ikke, jeg har indtryk af at det tit er det der "jamen, hvem er det, der har ansvaret, hvem kan svare på det her? Det ved jeg ikke. Nå, men jeg prøver lige at spørge her. Nå, de kunne heller ikke, så prøver jeg lige.." Jeg ved ikke, om man kan gøre det.. Og så tit og ofte også fordi det er sårbart, så der kun er en, der kan svare på det, så når den ene person ikke er der, så går alt i stå. Eller også er der nogen, der prøver at løbe rundt og finde ud af noget, og så tager det bare fire gange så lang tid, som hvis den person, som ved noget om det, var der. I: Men Britt du siger, du ville gerne kunne se det, du kalder "Post Danmark-funktionen", så du vil gerne kunne følge med i, hvor er din sag henne, og hvornår kan du forvente, den er løst. Ville det kunne afhjælpe det, at I ikke får.. I siger, I ikke får noget information, andet end du sagde, den er oprettet, og så hører I ikke en lyd. R2: Jeg tænker bare på, at jeg vil jo kunne få informationerne ved den der "Post Danmark-funktion", som jeg kalder den. Der vil jeg jo kunne få en information om, nu er den blevet tildelt, nu.. Hvordan kører den igennem møllen. Bilag Side 143 af 185

144 R1: Der får du jo så også den der korrespondance frem og tilbage. R2: Ja, men jeg vil sige, der vil jeg jo så have en anden brugerflade end den, der fungerer i øjeblikket, kunne jeg godt tænke mig, i stedet for jeg kan se alle log. Som jeg sagde, jeg vil kun på de overordnede punkter. Lige som hvor man får lavet en SLA, hvad er vigtigt for mig af informationer. Hvad der så ligger bagomliggende med, at så har Jens Peter fået eller Hans Henrik eller hvem fanden, man har spurgt om "kan du løse det her", alt det der er jeg jo ikke interesseret i. R1: Men så er det mere.. Hvor skiller den. Så kan der jo godt gå lang tid, før du får et svar. R2: Ja, det kan godt være. Men så må det igen være ud fra, man kan sige igen.. Jeg tænker, det må være de der driftstop og andre ting, man kan sige, som måske går ind og prioriterer.. Så er det den der, man siger "jamen så er det inden for 24 timer, så er det inden for 48 timer, så er det inden for en uge." Et eller andet man kan forvente at høre noget eller få det løst. Som du selv siger, der mangler noget struktur. R1: Ja, det synes jeg, der gør. R2: Det er lige som om, man ikke har talt sammen om, hvad forventer vi af hinanden her. R1: Det har man helt sikkert, vi har bare ikke fået det at vide, tror jeg. R2: Ja, det vil jeg håbe, man har. R1: Ellers så er der en dårlig aftale for PenSam i gang. R1: Så synes jeg også bare, der mangler nogen her i huset, som kan.. Altså, det ved jeg ikke.. Jeg mangler en IT-IT-afdeling. I: Hvad mener du med det? R1: Det er noget, som jeg kan ringe ned til og sige "jeg har et problem." For eksempel hvis nu jeg kommer en morgen og min computer ikke vil starte. Jeg aner ikke hvor, jeg skal gå hen. Jo, så ville jeg gå op til jer, men det er jo ikke meningen, jeg skal det. Så ville jeg måske ringe til Service Desk.. R2: Jeg ville sige 3838, så ville jeg vente på, der kom en. Han møder først klokken ni.. R1: Så ved jeg ikke, om de kommer hele vejen ude fra NNIT, eller hvornår de møder hernede. I: Men hvorfor er det vigtigt, om de kommer det ene eller det andet sted fra? Du har et telefonnummer, du kan ringe til, er det så ikke mindre vigtigt, om de møder på det ene eller det andet tidspunkt? R1: Jo, men det er jo bare meget rart, hvis jeg møder klokken halv otte, og min computer ikke starter.. R2: Så er det meget rart, man ikke skal vente til klokken ni. R1: Så er det meget rart, at der ikke først kommer en kvart over ni. I: Vil det sige, at det, at du ringer til Service Desk på 3838, det er afhængigt af, at der sidder en. Bilag Side 144 af 185

145 R1: Nej, det siger jeg ikke. Jeg siger bare, at i nogle situationer ville det være rart, at der sidder nogle mennesker her i huset, som man kunne tale med eller gå ned til eller vide var her. Jeg ved ikke hvad tid, vi har service fra, om man kan ringe til dem klokken halv otte. Jeg har heldigvis ikke prøvet det, men jeg ved ikke, hvad der ville ske, hvis jeg ringende halv otte. Om der er nogen, der tager telefonen, eller om det så er ude hos NNIT, hvor de siger "jamen de møder først klokken ni." Så har jeg et problem fra halv otte til klokken ni. I: Så det vil sige, at det der ville give noget værdi, det ville være, at der sad nogle her i huset, hvor man vidste, at de var her, og hvornår de var her. R1: Ja, så man kunne gå ned.. Altså jeg.. Det ved jeg ikke, det er måske også bare mig. Jeg tænker bare, at nogle gange er det rart at tale.. Jeg kan godt lide at tale med folk, også fordi nogle gange, så synes jeg, det der mail frem og tilbage og ind i systemer, det bliver bare så administrativt tungt. R2: Så er det også det der med, at nogle gange så føler man, at det er også for det menneskelige.. Altså, den der forståelse og mindske muligheden for fejl, ved at de kender det. De kender systemerne. De ved, at når jeg siger det her, så er det det her, jeg taler om. Så man hurtigt kan snævre sig ind til "nå, det er her, den ligger." kan stille modspørgsmål. Og så finder man ud af, at det er faktisk CSL eller et eller andet i stedet for, at det drejer sig om med Edlund-kernen eller you name it. Også bare fordi, det er jo ikke alle dem, som har siddet her i huset, som er dem, der er rykket derud, der varetager vores opgaver, det er jo blevet spredt ud nu. Ikke fordi det gør noget, man er bare ikke helt sikker på, at de forstår.. Nogle gange er man også lidt uforstående for, hvorfor det skal tage så lang tid. Det kan også være fordi, vi tror jo måske, nu sidder de i hus, det er jo ikke kun os, de har som kunde selvfølgelig. Men man aner jo ikke hvor mange, der er med til at analysere vores virksomhed. Og det der igen: Hvad har vi af aftaler? Hvad kan vi forvente? Hvad skal man skrive? Hvad skal man gøre? Det er jo derfor, jeg godt kan lide ideen om den der "Post Danmark-model". R1: Så tror jeg også bare, de har så mange problemer med systemer. R2: Ja, batch-kørslerne, der ikke er kørt færdige og så lukker det for nogle ting. R1: Ja, så det bliver endnu mere frustrerende at det skal køre rundt om en virksomhed, hvor folk måske ikke føler, de helt har forstået, hvad problemet er. I: Hvad kunne man gøre ved det? R1: Jamen det tror jeg.. Hvis du havde folk her i huset, som kendte systemerne og kendte de problematikker, der rent faktisk er i huset og i systemerne. For jeg har indtryk af, at der er rigtig mange udfordringer med de der systemer. Nu har jeg jo ikke adgang til dem. Jeg hører jo bare.. I: Hvad så? R1: Så tror jeg måske, det ville lette sagsgangen, fordi man ikke hver gang skal forklare "nå, men det og det og det.." Sådan en sag som opstår femten gange inden for to måneder. Det burde jo bare være løst på to minutter, for det er jo bare at trykke på knappen, ligesom man gjorde sidste gang. Bilag Side 145 af 185

146 R2: Så kan man sige.. Så vil man jo gerne have, at de så sideløbende følger op på "hold da op nu er det sket femten gange, hvorfor.." R1: Ja, hvorfor sker det femten gange.. R2: Altså sætter sig ned og ser på historikken, og finder ud af "Okay, hvad kan vi gøre her" og så prøve at sammenligne på det tidspunkt, har vi kørt nogle bestemte kørsler, nogle forskellige batch? Eller hvad er det, der er kørt? Er det en type, der gør, at så slår den den funktion fra, eller hvad er det? I: Og dermed siger du, at man.. R2: Man bliver jo nødt til at køre noget historik op på nogle forskellige Remedies. Altså kategorisere dem og så se "hov, dem her har vi.." I: Med henblik på hvad? R2: På at løse fejlen så webserveren den ikke bare går ned. I: Så løse problemet så fejlen ikke opstår igen? R2: Ja. R1: Det kan jeg slet ikke forstå, man ikke gør egentlig. Respondenter: Bisbo & Nicolaisen I: Som sagt, i første omgang, prøv at beskriv situationen, som den ser ud fra jeres synspunkt med hensyn til, når I oplever en eller anden fejl i et system eller et andet sted, som I melder ind, og så frem til at fejlen er løst. R1: Det er bare, jeg tror, der er stor forskel på, hvordan du oplever det, og hvordan jeg.. I: Det er derfor, I begge to er indkaldt. R1: Ja. R2: Kan man sige, det der er den største udfordring, det er.. Det er den her tilvænning til, hvordan vi håndterer fejl i dag, for mig at se, at vi melder ind til en Service Desk, som håndterer sagen i NNIT, kontra vi meldte ind til nogen, der var her i huset. Og det kan både være det gode og det dårlige, at de her SLAaftaler og andet, der ligger. Du skal melde ind, og så skal du vide, der er et respit på x dage. Var der en sag, der var svær tidligere, jamen, var der en respit på mere end en dag, så fandt man ud af at få hjulpet det af sted. Og det er nok, for mig at se, den sværeste tilvænning, der er i hvert fald oppe i mit hoved at sige "jeg skal huske at sige, jamen, der inden for aftalen det her tid, der må gå." Så har vi nogle virkemidler, hvis det er nogle bål og brand-situationer, men det der med at skifte fra ikke at kunne presse sagens udvikling til at blive løst med mindre det er en eller anden direktionssag, det er nok den største tilvænning, jeg har skullet have. Du skal respektere, der er lavet en aftale, og den ser ud på den her måde, og er det helt vildt og Bilag Side 146 af 185

147 voldsomt, så er der også en aftale for, hvordan vi kan håndtere det. Men motorvejen det er den her: Du melder ind, der går x antal dage, med sådan det brede svar. Så kan man sige, så skal du også igen sige, så går det så videre til, enten til jer eller op til udvikling, og det der skifte med at have snoren på, hvornår og hvor hurtigt det går igennem, det er nok en tilvænning også, som I nok er mere i berøring med end nogen andre, tror jeg. Jeg tror ikke, alle oplever det her store skifte fra Service Desk til NNIT. R1: Jeg vil sige, jeg har ikke ret meget, hvor det sådan er.. Hvor Service Desk egentlig gør andet end at stor set bare oprette dem, og så ryger de jo tilbage til PenSam, fordi det stort set kun er Rådgiverportalen. Der kan man sige, der ligger jo ikke nogen aftaler på hvor hurtigt, de skal være besvaret. Så jeg har egentlig ikke noget på den front, jeg synes, man kan klandre Service Desk for, det er nok mere, at vi Internt her i PenSam skal have, hvad så med alle de fejl, der ryger tilbage til os, hvor hurtigt skal de være løst? Det synes jeg, man mangler at der er noget bedre styr på, og at det er meldt ud generelt, hvad man kan forvente, når der er fejl på Rådgiverportalen eksempelvis. Der er det jo næsten altid her i huset de skal løses alligevel. R2: Men også fra du melder fejlen til du.. Til den er gået igennem systemet, der er jo også en respit nogle gange. R1: Jeg vil sige, det går meget, meget hurtigt. Nu får jeg dem jo lige som selv tilbage i Portalsupport, og der går oftest ikke mere end en halv til en hel time, så det går faktisk ret hurtigt. I: Maj-Britt, hvis du oplever selv at melde en fejl ind.. Ikke så meget fejl andre melder ind til jer i den her specifikke situation, at I er med inde over som led, men hvis du nu oplevede, at der var opstået en eller anden fejl for dig.. Altså som berører dig.. R1: Jamen det har jeg gjort.. Næsten alle de fejl, vi har aktive lige nu, er faktisk nogen, jeg har meldt ind, fordi det er nogen, jeg har fundet i forbindelse med alle de her omvalgsfejl med skattereformen, og hvad ved jeg. Så det er nogen, jeg har meldt ind. Og der oplever jeg, at jeg meget hurtigt får det her HD-nummer tilbage fra Service Desk, og at der så ikke går ret lang tid, før den ligger i Portalsupport, men mindre jeg har skrevet til dem, fordi det gør jeg tit, "skal direkte til.." Altså, så den ikke kommer forbi mig igen, og det synes jeg egentlig går rigtig hurtigt. I: Hvordan ser I ellers på hele den.. Altså nu har I talt lidt om skiftet fra da Service Desk lå her i PenSam til det er flyttet over i NNIT-regi. Men hvordan ser I situationen generelt, uagtet at Service Desk er flyttet og har været et andet sted før? Hvordan oplever I det at skulle henvende sig til et bestemt sted, og så bliver sager lagt til de rette personer? R1: Det synes jeg ikke er gået super smidigt. Som jeg også sagde, da vi havde seancen med NNIT, at jeg synes, at der er meget, meget stor forskel på, hvem det er, der lige sidder der den pågældende dag, når man melder en fejl ind. Og der er, som jeg også sagde der, mange af dem der siger "hvem er PenSam?" og hvis de overhovedet ved, hvad PenSam er, så ved de i hvert fald ikke, hvad rådgiverportalen er eller.. Og det synes jeg er lidt trist, at de ikke er bedre klædt på, dem der sidder der i den anden ende. Jeg burde ikke, det er klart lige nu har sådan en som Heidi en fordel, fordi hun kender til PenSam, men jeg burde ikke som Bilag Side 147 af 185

148 bruger opleve så stor en forskel på, hvem der sidder i den anden ende. Det synes jeg, der er. Det synes jeg, har været det største og er fortsat det største problem. R2: Skinner det også.. Jeg tænker, skinner det også igennem, når vi så får de sager, man har meldt ind, der bliver sendt videre? Altså, hvem er afsender i forhold til.. Selvfølgelig kommer det fra Service Desk, men er det samme kvalitet som det i telefonsamtalerne? R1: Nej, der er jo også stor forskel.. De glemmer for eksempel tit, når man vedhæfter et skærmdump, så skal de ofte åbenbart selv ind og føje til Remedy'en. Og det bliver meget, meget ofte glemt at få den føjet ind, og det giver store problemer, for så får jeg først en mail fra en udvikler måske en uge senere, der siger "hvorfor fanden har du ikke vedhæftet det, du siger?" Og det er der også nogle derude, der er bedre til end andre. I: Et det så et konkret problem lige nu eller.. R1: Jeg havde så sent som i sidste uge flere sager, hvor jeg skulle tale med en. Jeg kan ikke huske hvem, det var derude fra, og hvor han sagde, men han ville prøve at gå tilbage og finde de sidste et eller andet, jeg havde lavet, og så ville han tjekke dem og få vedhæftet skærmdumps, fordi det sådan var generelt, at jeg blev ved med at få mails fra udviklerne, at "du skriver, du har vedhæftet noget, men hvor er det?" Og jeg kunne jo se, det var med i det, som jeg havde sendt til Service Desk, men så var det noget med, de forklarede, de skal gøre det på en eller anden manuel måde, og den glipper åbenbart tit. I: Så når du opretter en sag, som du hvad..? Sender per til Service Desk? R1: Jeg sender den via den der inde fra Intranettet. I: Og der sætter du et skærmprint ind, og det er ikke med, når sagen så kommer igennem? R1: Meget, meget ofte er det ikke med, når sagen kommer igennem. I: Okay. R1: Så jeg tænker, det måske være et eller andet med deres proces for, hvordan de gør det her. Jeg ved ikke om det.. For jeg kunne forstå på ham, at nogle gange sker det automatisk, og andre gange så sker det ikke. Jeg ved det ikke.. Det er bare noget, jeg i hvert fald godt kunne tænke mig, de var lidt mere obs på, at de fik de skærmdumps med. R2: Så man undgik tilbageløb? R1: Ja, for hvis jeg så får sagen en uge efter, så er det lige det der med "hvor fanden var det nu?" og måske er der så sket et eller andet med opgaven eller med kunden, så jeg ikke kan genskabe præcis det samme. Så skal jeg ind og lede i min sendte. Så det kunne jeg i hvert fald godt tænke mig, at de var lidt bedre til at få de der skærmdumps med. I: Det lyder på dig som om, det er et stort problem, eller at det er til stor irritation? Bilag Side 148 af 185

149 R1: Ja, men det sker bare rigtig ofte, og det synes jeg bare er lidt trist, når alle oplysninger egentlig har været der fra start af. At der så falder noget af, fordi der er de her led. I: Gør det sig gældende med andre typer information end, nu siger du, hvis du vedhæfter et skærmprint. Er der andre oplysninger, der går tabt undervejs? R1: Nej, det synes jeg ikke, der er. Alt hvad jeg udfylder i de der felter, det er med, men det er de der skærmdumps, der forsvinder. R2: Det er væsentligt. R1: Ja, ofte er det rimelig væsentligt. I: Har du adresseret det problem over for nogen, og har du fået nogen tilbagemelding på det? R1: Kun til ham jeg konkret snakkede med ude hos Service Desk i sidste uge, og hvor han selv indrømmede, at han godt vidste, at det ofte var en udfordring. I: Så I har ikke fået nogen information om at det her, det er et problem. Og vi, underforstået Service Desk, forstår godt eller kender godt problemet, og vi har tænkt os at gøre det og det ved det? R1: Nej ikke andet end at han den konkrete dag jo sagde til mig, at han ville prøve at få nogle af de seneste igennem og få det vedhæftet. Det var ligesom det. I: Hvis vi så tager det som eksempel. Oplever.. Det er jo en situation, hvor du jo oplever en fejl, for det må jo være at tolke som en fejl, at når du sender noget vedhæftet et skærmprint, så er det ikke med, når det kommer op i den anden ende. R1: Ja. I: Oplever I generelt, at man godt er opmærksom på problemer, men ikke nødvendigvis løser dem? R1: Nej, det synes jeg ikke lige. jeg har haft andre. I: Der er ikke andre sammenhænge, hvor I har en fornemmelse af, at alle godt er klar over, at det her er et problem, men der ikke er nogen der adresserer det? R1: Nej, ikke sådan noget, jeg lige har eksempler på. R2: Jeg sidder og tænker, kan vi.. Ikke i den form andet end at hvis kvaliteten af det, at de mangler skærmdumps, at det kan gøre, at man tager noget for at være en dublet, selvom det ikke var en dublet. Det er nok der, hvor jeg siger, der kan være noget der, men ikke decideret at man godt ved det, men man kan jo misse noget når informationen ikke er med. R1: Jeg har haft en anden sag, hvor jeg havde en fejl på mit Outlook, og hvor jeg så fik at vide, det ville de løse ved at opgradere mig til en I den forbindelse oplevede jeg jo, at rigtig mange af mine ting, af mine opsætninger og hvad ved jeg, der forsvandt, uden at jeg blev gjort opmærksom på det. Så det opdagede jeg jo over en rum tid. Nu har jeg for eksempel også lige opdaget, at jeg ikke længere kan Bilag Side 149 af 185

150 tilaktere, der fik jeg så at vide af en af mine egne kollegaer, at det var åbenbart en kendt fejl i 2010'eren. Men sådan nogle ting blev jeg ikke gjort opmærksom på, da de ville forsøge at afhjælpe min fejl, jeg havde i 2007'eren, ved at opgradere mig, så der kunne jeg måske godt lidt mere have tænkt.. eller have ønsket, at jeg fik at vide "vi kan godt opgradere dig, men så skal du være klar over at blablabla.." Så jeg ligesom.. Og det fik jeg ikke, og jeg måtte kontakte dem ad flere omgange med "hov det der var også røget, hov det der var også røget.." Så afhjalp de det også rimelig hurtigt, men der mener jeg, der skulle de nok lidt mere være klar over konsekvensen af at installere en ny Office-pakke. I: Så det vil sige, du melder en fejl ind, som du oplever - noget du ikke kan - og det løser de ved at gøre noget, som ikke efterfølgende har løst problemet? R1: Det har løst problemet. Jeg havde problemer med, konstant var det lige som om, min Outlook stod og sagde, den svarer ikke. Så sagde de "det vidste de godt, og det kunne løses ved, at man opgraderede til en 2010'er." Og jeg har heller ikke efterfølgende haft det problem, som jeg havde før, jeg har bare fået nogle nye. I: Okay så problemet er løst, men det har affødt nogle andre problemer, du ikke har set før. R1: Ja, specielt der i dagene efter, hvor jeg opdagede at den ene og den anden og den tredje opsætning var røget, og det har jeg så efterhånden fået løst. Men det med tilaktering for eksempel, det vidste jeg ikke for eksempel. Jeg havde brug for at tilaktere et brev, det er jo ikke så tit, jeg gør det i den funktion, jeg sidder i i dag, og der får jeg så faktisk lige at vide i dag, hvor Gosia siger "det synes hun da godt, hun havde hørt" og det var faktisk et kendt problem, og det var derfor, at de ikke bare over en kam ville give alle I: Så det vil sige, det er noget, du kunne i den tidligere version, og som du nu lige pludselig ikke kan? R1: Ja, jeg kan ikke tilaktere et brev. Og sådan nogle ting, kunne jeg godt have tænkt mig at få listet op, eller der var nogen, der sagde.. Tog stilling til og sagde, at.. Hvis de ved, at hver gang de opgradere, jamen så ryger det og det og det, at man enten får hjælp, det var jo nummer et, at man fik hjælp til at få sat det op, som det var før, eller man i hvert fald som minimum fik at vide "du skal være klar over, at det og det og det ryger. Det skal du lige sætte op bagefter." I: Og den oplysning får man ikke, når man beder om et eller andet? R1: Nej, jeg fik den ikke i hvert fald. De var meget hurtige, når jeg så ringede og sagde "hvordan gør jeg så lige?" Så fik jeg hjælp med det samme, men jeg kunne bare godt have tænkt mig, at jeg på forhånd havde fået at vide "du skal være klar over sådan og sådan.." I: Så du oplever, at de har måske ikke løst problemet hundrede procent, men de kan godt afhjælpe det efterfølgende? R1: Ja, altså jeg har endnu ikke fået afhjulpet det her med, at jeg ikke kan tilaktere, for den har jeg lige som selv lige valgt at parkere, fordi det ikke er min primære opgave, så den har jeg selv lige nu parkeret. Bilag Side 150 af 185

151 I: Asbjørn oplever du noget i stil med det, Maj-Britt fortæller? Er det noget, du kan genkende, eller er det..? R2: Jeg har ikke haft samme udfordringer systemmæssigt som Maj-Britt på det punkt. Selve fejlhåndteringen har vi jo sådan delt meget op, så Maj-Britt har kørt meget af det, der har været på det seneste. Så det er udfordringer, vi arbejder sammen om, men det er ikke mig, der har fået de ting til at starte med. I: Men du har ikke oplevet noget tilsvarende? Altså igen, som jeg sagde før, noget som er din situation, og ikke noget som du formidler videre på vegne af nogle andre? Hvis nu man skulle tage udgangspunkt i en konkret situation. Hvad har din sidste korrespondance med Service Desk været, hvad er din sidste.. R2: Det har været oprydning af dubletter og gamle sager, som man mente var løst, og som så har været løst. I: Og hvad mener du med dubletter? R2: Sager, der har en fejl, der ligger sammen med sager, der har været tidligere eller senere oprettet, som så er dem, man arbejder videre med, så, når man løser dem her, så er det dem, der bliver taget hånd om. Der har været en del i forbindelse med omvalgssager, da vi lavede skattereformen og forskellige ting. Vi sad og fejlmeldte på kryds og tværs, og der er så blevet samlet op og mandet ind på, at det er de og de fejlting, der skal håndteres. Og det er sådan set den seneste korrespondance, jeg har kørt mest med. Og der er den største udfordring, det er at få, det er de og de, og det er den henvisning til det og det, så kan vi godt gøre det. Det er sådan.. Der er det jo PenSam-medarbejdere, man kommunikerer med på det punkt, og der er det jo din egen afdeling, der er med der. Det er sådan set ikke noget issue, fordi der er det rimelig nemt at tale med.. Hvad er kvalitet, eller hvad det fejlen er konkret på. I: Vil det sige, at der bliver indmeldt.. De samme fejl bliver indmeldt flere gange eller hvordan skal det tolkes? Er det forskellige brugere, der oplever den samme fejl, fordi der opstår et eller andet i et system, som mange anvender? R2: Ja, og så har vi selv siddet i forbindelse med testsituationer og meldt nogle ting ind, hvor vi siger, det er det, vi oplever, og det har så haft sammenfald med lignende situationer eller med lignende kunder, man har indrapporteret på. Så den samme fejl kan godt være rapporteret af mig eller en i test eller en over i produktion, hvis det er det. I: Hvordan kunne man så dæmme op for, at sådan nogle fejl så dukker op mange gange set fra jeres synspunkt? Hvis nu I melder noget ind, og det er der også fem kunderådgivere, der har gjort? R1: Ved at man var mere opdateret på intranettet. At det blev hurtigere opdateret der. Og måske endda med henvisning til et Remedy-nummer, så folk hurtigt kunne se "Nå men det her, det er meldt ind, og det har det og det sagsnummer." Det.. Fordi jeg synes, den halter lidt, den her med, at der hurtigt nok kommer besked på intranettet, så derfor når rådgiverne jo hurtigt at melde den samme ting ind syv gange. R2: Problemet er nok bare fokus på informationskilde. At ikke alle vil få kigget på det. Bilag Side 151 af 185

152 R1: Det er rigtigt, og det er også problematisk, at man lige skal ind og opdatere siden, altså.. Fordi informationen kan godt være lagt på, men hvis rådgiveren ikke lige trykker F5 inden de.. R2: Lige præcis. Så om det er den enkelte rådgiver, eller om det er, at man hver anden dag eller to gange om ugen, bare lige i sektionen, siger "er I opmærkesomme på.." Det er nogle generelle ting. Jeg fornemmer nogle gange, at det der med at lægge ting på intranettet, det er godt at gøre, men det er ikke alle, der når eller går ind og kigger. Det kan både være går og når. I: Så der er et forum, eller der er en side på Intranettet, hvor man kan se, hvilke fejl der pt er kendt? R2: Ja, hvis det er driftmæssigt kendt, så ligger der jo den ude i højre side. I: Men i oplever dels at det ikke bliver opdateret hurtigt nok, og dels at folk ikke søger information det sted? R1: Ja. R2: Det kan være en god kombi. R1: Eksempelvis så synes jeg, den her vi har haft inde, med at Rådgiverportalen har været ustabil. Der er tit, hvis der så bliver ændret i den her systemmeddelelse, så bliver der ændret i teksten, men den står stadigvæk med en dato, der ligger måske halvanden uge bagud. Det tror jeg ikke, rådgiverne de kigger på. Det er vigtigt, den hele tiden får en ny dato, så hver gang, der bliver ændret i den, så skal den have en ny dato, for ellers så tror jeg ikke, de kigger i den. R2: "Nå, det var bare det, der stod sidst i den, der den anden dag kom op." R1: Ja, så der tror jeg godt, at vi kunne spare os selv lidt mere, eller vi måske blev bedre til at fortælle Service Desk, at når de bliver ved med, for eksempel i den her periode, at få en fejl ind om at Rådgiverportalen er ustabil, så ved vi det godt, så skal de i stedet henvise til den og den sag, fordi der er fokus på det eller et eller andet. Man behøvede måske ikke have oprettet 17 forskellige sager på det samme. I: Så det vil sige, at hvis Service Desk i højere grad var klar over, at der er i øjeblikket en fejl, som vi godt kender og flere indmeldinger fejlmeldinger på noget lignende, så er de i den ideelle verden i stand til at stoppe sagen allerede ved første henvendelse og svare tilbage med det samme "vi ved godt, problemet er der." Så I undgår at få så mange fejl ind i jeres led. Er det det, der er tanken? R1: Ja, det synes jeg, og også for jeres led, hvor den så ryger videre. Så kunne Service Desk måske skrive ind "nu er der kommet en henvendelse igen." Altså skrive det ind på den samme sag, i stedet for der lige pludselig ligger en masse åbne på præcis det samme problem. R2: Ja, man kan komme bredt ud til rådgiverne, så de ikke skal undgå funktioner, men er vidende om, hvad det er for nogle funktioner, de er begrænset på. Det kunne måske også gøre lidt på, at de lige holder hesten og føler, at man er opmærksom på det. Det er nogle gange følelsen, der gør, at de ikke.. også fra tidligere tider bliver irriteret over "jamen hvornår kan vi så få at vide "jamen vi er i gang, og lige nu er det uvist og Bilag Side 152 af 185

153 sådan og sådan.."" Og det er der, hvor det bliver svært at komme ud med det. Det næste er at sige "men hvad så, hvornår er vi klar igen?" Men at vide "vi er altså opmærksomme på det, og der er fuldt.." R1: Det er jo det generelle. At vi har et problem med forventningsafstemningen. R2: Ja. R1: At man ikke har nogen som helst ide om, hvornår kan jeg forvente, at det her er løst, og er der overhovedet nogen i gang med at kigge på det. I: I var også lidt inde på det til at starte med, men hvordan oplever I informationsniveauet og.. Altså skal problemet findes i, det I beskriver nu, at I ikke får noget at vide, eller er det fordi, der ikke er nogen, der har fortalt jer, hvor man kan finde sådan nogle oplysninger henne, eller er det fordi der slet ikke er aftalt nogen som helst form for mål eller forventninger? R1: Jeg tror ikke, der er aftalt noget. Hvis vi tager det fra Rådgiverportalen, hvor den ryger tilbage til PenSam, så tror jeg ikke, der er aftalt noget som helst, og det synes jeg er problematisk. Jeg har lige nu en hel del sager, der er oprettet før påsken, og hvor jeg stadigvæk intet besked har. Jeg har så muligheden for, at jeg selv kan gå i Remedy, og jeg kommer en del oppe hos udviklerne, så jeg kan selv spørge dem. Men det kunne lige så godt have været en hvilken som helst rådgiver end mig, der havde meldt den her fejl ind. For jeg har, set med mine brugerøjne, ikke fået en eneste tilbagemelding, og det synes jeg ikke er okay, når der er gået en måned. I: Er det så en situation, der er specifik for det system, Rådgiverportalen, eller gør det sig gældende generelt? R1: Nu har jeg jo ikke så meget med andre systemer. Så er det kun, hvis jeg sådan selv personligt har nogle problemer med min maskine, og der har jeg ikke haft andet end den her med Outlook, så derfor har jeg ikke rigtig noget, at holde det op imod. Men det er i hvert fald helt generelt i forhold til Rådgiverportalen, at der halter det rigtig, rigtig meget med tilbagemeldinger, og jeg tror simpelthen ikke, der er nogen, der ved.. Folk ved simpelthen ikke, hvad er prioriteten for driftsfejl og hvordan og hvorledes gør vi det. Så den synes jeg halter rigtig, rigtig meget. Men det er jo ikke noget, vi kan klandre Service Desk eller NNIT for, for det er jo når den er landet tilbage her i huset. I: I beskriver det flere gange nu her igennem, at en sag meget ofte bliver indmeldt af en bruger til Service Desk, hvor efter den kommer tilbage her til PenSam. Er det så, nu igen du var lidt inde på det, er det Service Desk, der ikke melder tilbage, eller er det når sagen kommer videre i et eller andet system, så får I ikke noget at vide om, hvor den så er havnet? R1: Ingen af delene. Man kunne sige i første omgang kunne man selvfølgelig godt.. Det kunne vi også høre, da vi sad her med nogle af rådgiverne til NNIT, de anede ikke, de rådgivere, at når det er fejl på Rådgiverportalen, at det faktisk ligger hos PenSam. Så de sad og klandrede Service Desk for, at de ikke fik nogen tilbagemelding. Så der kan man sige, der kunne Service Desk måske godt i første omgang skrive Bilag Side 153 af 185

154 tilbage til brugeren, at vi har nu sendt din sag videre til den og den afdeling i PenSam, som vil vende tilbage til dig eller whatever. Så set fra den side, hvis man ser helt ud til rådgiverne, som ikke er så meget inde i, hvordan vi løser tingene her, så kunne det være godt, at de fik besked. Jeg har set, at du gør det nogle gange, når du får fat i nogle sager, så skriver du tilbage, at nu har jeg overdraget din sag til blablabla, men det er bare meget meget sjældent, at det sker. Og det er meget meget sjældent for nærmest at sige aldrig, tror jeg. Fordi når udviklerne, eller hvem det så er, der har løst den, så melder de bare tilbage "nu er den her løst, og den kommer i drift der og der.." Det gør de eksempelvis til mig, fordi jeg har kontakt til rådgiverne, men jeg får ikke en besked fra Remedy-systemet. Det vil sige hvis jeg var en almindelig bruger, rådgiver, så ville jeg ikke få besked om "din sag er nu løst, den kommer i drift der og der." Så jeg synes helt klart, vi halter lidt der på at give fejlmelderen ordenlig besked på, hvornår de kan forvente, at den er i drift. R2: Men det signal eller viden til mig om, at der ligger et eller andet.. Viden om systemet og hvordan hele den her proces kører, der heller ikke er sådan helt meldt ud. R1: Jo. R2: At trinene er på den her måde, der er de og de overordnede rammer. Det kan godt være, de ikke skal huske på dem, men at de slet ikke kender dem, det er måske nok en.. R1: De havde ingen ide om det. De troede, det var NNIT, der skulle gøre noget, når Rådgiverportalen gik ned. I: Hvem troede det og hvornår? R1: Det var.. Var det Iversen og Gine, der var med den dag, da vi havde det med NNIT? I: Som var hvad..? R1: Som er rådgivere. Den dag vi havde med NNIT, hvor vi gennemgik, hvordan vi synes, det kørte, efter de havde overtaget det. I: Altså et interview af en art? R1: Ja. Der sad de jo og sagde til NNIT, at de synes, det var for dårligt, at de ikke fik nogen tilbagemelding på fejl på Rådgiverportalen, og jeg kunne godt se, at NNIT sad jo sådan lidt og tænkte.. Hvor jeg så sagde "nå, men det er faktisk ikke NNIT, der gør andet end at oprette sagen og sende den tilbage til PenSam. Det anede de ikke, og det.. Det kan man sige, i bund og grund skal en slutbruger jo heller ikke bekymre sig om, hvem der løser den, de skal jo egentlig være fuldstændig ligeglade om det er NNIT eller PenSam eller hvem pokker det er med.. R2: Men hvis de nu vidste det er ledet, og for at du får et produkt, så skal du igennem det her produktionsled. R1: Eller de fik bare en eller anden mail lige fra.. Altså hvis en eller anden udvikler havde modtaget den at sige "nu har jeg fået din sag, og jeg forventer.." en eller anden form for tilbagemelding. Bilag Side 154 af 185

155 I: Så det der mangler, det er altså tilbagemelding? R1: Helt sikkert, og så nogle interne aftaler i PenSam. Hvad kan forventningen være når der er fejl på Rådgiverportalen? Hvornår skal.. Altså alt efter hvad det er for en type fejl, men hvor hurtigt skal det være løst? Det er der jo ingen her i huset, der reelt ved. I: Så der mangler tilbagemelding om.. R1: Om status i sagen. Både løbende, men også endelig. Du får jo kun automatisk den her, at nu er din sag lukket, men som slutbruger står der jo ofte ikke nogen begrundelse i den mail, og hvis ikke du har adgang til Remedy-systemet, så får du ikke begrundelsen, så kan du bare se, at sagen er lukket, men du har jo ingen ide om hvorfor. Og tit sidder de jo med gule lapper og skal huske på, at når den her sag er løst, så skal jeg gøre det og det i forhold til kunden. Og det er måske problematisk, hvis man ikke får tilbagemelding om hvordan eller.. Altså for hvis udviklerne bare lukker den og siger "nu har jeg løst den, altså lukker jeg den." men den måske først kommer i drift om fire måneder, så er det jo også vigtigt, man får kommunikeret det til slutbrugeren, at godt nok er den løst udviklingsmæssigt, men der går altså fire måneder, før du kan se det. I: Så det ville give værdi, at der blev givet en løbende tilbagemelding undervejs, for eksempel når sagen skifter hænder? Det ville give værdi at, der bliver en tilbagemelding, når sagen er løst og hvordan eller hvorfor, den er løst, og det ville give værdi at vide, hvornår man kunne forvente, at der skete noget? R1: Ja, at det er i drift. Helt sikkert. I: Nu har vi været lidt inde på, men det næste punkt i den her session her, det er, hvad ser I konkret af udfordringer i den måde, det hænger sammen på i dag? R1: Altså hvordan.. Hvad hænger sammen.. Med NNIT? I: Ja, igen at I melder en fejl ind og så kommer det igennem et antal led i en proces, og så bliver fejlen måske løst i sidste ende. R1: Der er helt klart for mange led, som det er lige nu. For den kan ligge x antal tid hos NNIT, den kan ligge x antal tid, hvis vi tager igen Rådgiverportalen, når den kommer til Portalsupport. Den kan så ligge, når den kommer op til Service Operation, kan den også ligge x antal timer/dage og igen, når den kommer til udviklerne. Så der er rigtig mange led hvor, fordi der ikke er nogen, der har de her.. Lige som "driftsbriller" på, der hele tiden sidder og overvåger, om der kommet noget nyt ind, så risikerer vi, de ligger alt for længe hvert sted. Så det synes jeg, er en stor, stor udfordring. For nogle gange kan det være en lille ting, hvor det ikke gør noget, at den har været måske to dage undervejs igennem systemet, men hvis det er generelt at Rådgiverportalen er nede eller et eller andet, så skal der jo virkelig være en eller anden alarmklokke, som bimler, og som gør at fordi vi sidder i møde eller I sidder i møde, så må den altså ikke strande der. Men hvordan man lige.. Bilag Side 155 af 185

156 I: Hvis nu.. Nu siger du "fordi du lige sidder i møde eller vi lige sidder i møde." var der ikke nogle andre, der så kunne tage sig af det i stedet? R1: Jo, men sådan er det bare ikke lige ressourcemæssigt opdelt, at der er andre, der tager sig af det. I: Hvis du lige skal uddybe lidt, hvad mener du med, at det ikke er så opdelt, er det fordi, der ikke er tid til det eller..? R1: Ja, nede hos os er det primært min opgave, så er jeg på arbejde, så er det mig der tjekker den, og der er ingen af mine andre kollegaer, der bekymrer sig om den. Hvis jeg så er syg eller har ferie, så er Asbjørn nummer to til at skulle kigge i den, og ellers er der, som der er nu, ikke nogen andre, der har opgaven med at kigge i Portalsupport. I: Og Portalsupport beskæftiger sig med.. R1: Rådgiverportalen. I Fejlmeldinger på Rådgiverportalen.. R1: Ja og spørgsmål fra rådgivere, så det er ikke kun fejl, der kommer ind i den. I: Henvender rådgiverne sig så direkte til jer, eller henvender de sig til Service Desk? R1: De har efterhånden fået lært.. I starten, der henvendte de sig til os med stort set alt, men de har efterhånden fået lært at skelne imellem, er det en fejl, eller har jeg spørgsmål til brugen af et eller andet. Så hvis det er spørgsmål til brugen, så er det direkte til Portalsupport, og ellers er det direkte til Service Desk. I: Ved rådgiverne det? R1: Ja, det synes jeg faktisk, de er blevet ret skarpe på. I: Så det vil sige i det tilfælde, der er det faktisk at foretrække, at der er forskellige steder at henvende sig, afhængigt af karakteren af forespørgslen. R1: Ja, for hvis de bare har et eller andet spørgsmål "hvordan gør jeg nu lige, når jeg står der?" Det er der jo ingen grund til, at Service Desk skal blandes ind i, og der skal oprettes en sag på, fordi det er jo ikke en fejl. I princippet kan det være noget, Rådgiveren lige så godt kan have spurgt deres kollegaer om lige inde på den anden side af væggen. I: Er det sådan at forstå, at der så også er andre situationer, hvor man kan forestille sig, at det ikke var nødvendigt at henvende sig til Service Desk, men man henvendte sig til nogle andre og spurgte om et eller andet? R1: Det ved jeg ikke. Altså du tænker med andre systemer eller andre fejl? I: Måske. Andre situationer. R1: Det ved jeg ikke. Bilag Side 156 af 185

157 R2: Det er svært lige at se. I: Så det er ikke selve kanalen? Det er ikke selve det, at man skal henvende sig til Service Desk uanset, hvad henvendelsen drejer sig om, der er problemet? R1: Det er mere, at lige så snart, der er mange led, at der er problemet. Jeg ved godt, at hvis den er.. Altså tit hvis jeg har en kritisk fejl.. For eksempel hvis jeg finder ud af, at Rådgiverportalen ikke virker, så skriver jeg, opretter jeg jo en fejl til Service Desk, hvor jeg skriver "den skal være høj" og jeg ringer samtidig. Der ved jeg, at de ringer med det samme videre enten til jeres afdeling eller til udviklerne. Så der kommer den hurtigt igennem, men jeg tror desværre bare, hvis vi igen ser på rådgiverne. De ved ikke, at alt hvad de melder ind på Rådgiverportalen altid bliver meldt ind som low, med mindre de gør noget andet. Det tror jeg simpelthen ikke, de er klar over. Så en rådgiver kan sagtens melde ind, at Rådgiverportalen ikke virker, og den kan så ryge igennem møllen med low hele vejen. R2: Og der har du shortcuttet dem og kommet indenom. R1: Ja, det er ret kritisk, at sådan en bliver meldt som low hele vejen rundt. For så får den bare ikke den nødvendige attention. Så der kunne det måske også være rart, at PenSam over for NNIT havde defineret, hvilke typer fejl skal, uanset hvad rådgiveren skriver, altid have medium eller high, og hvilke kan sagtens have low. Fordi problemet er bare, når de skal igennem så mange led, og de risikerer at ligge flere timer, halve og hele dage de forskellige steder, Så går der bare for lang tid. I: Skyldes det så manglende viden hos nogen, eller skyldes det manglende fleksibilitet i den aftale, der er indgået? R1: Jamen igen synes jeg jo ikke rigtig for den del af det, at det har så meget med NNIT at gøre, fordi det jo er en sag, der ryger tilbage her til. Så det er nok mere, at vi internt skal have sat nogle aftaler op. R2: Der skal nogle aftaler for os selv.. R1: Ja, det synes jeg, det er meget mere der, den hænger. I: Hvis nu man så skulle prøve at forestille sig nogle forbedringstiltag, vi kunne gøre for at få den her situation til at glide bedre.. For I nævner meget, at der er mange led, og at der er meget ventetid i de enkelte led, før en sag kommer videre fra den ene til den anden, fordi en eller anden sidder i møde eller noget tilsvarende. Hvordan kunne man strømline sådan en arbejdsgang, så tiden fra henvendelse til løsning blev afkortet? R1: Det er jo helt klart, at der var så få led som muligt, men det er jo bare lige nu rigtig svært. For det er jo ikke meningen, at Portalsupport overhovedet skal være inde over fejl, men lige nu er det bare os, der sidder med den største viden om, hvad er det og hvordan og hvorledes, og derfor er vi stadig inde over. Men det er jo helt klart, fordi der ikke er nogen, der er dedikeret til, at driftsfejl er ligesom deres hovedfokus. Og så netop at der ikke er lavet de her aftaler om, hvor længe må det.. Altså, så kan det godt være, man skulle have sat det op til, man fik en SMS eller et eller andet, så vi fik besked, "hov, nu tikkede der noget nyt ind" Bilag Side 157 af 185

158 for lige nu finder vi ikke ud af det på anden måde end at gå ind og tjekke de her fællespostkasser. Der burde på en eller anden måde, fordi der nu, specielt i øjeblikket, er rigtig, rigtig mange fejl på Rådgiverportalen, så den kræver ret stor attention lige i øjeblikket. R2: Det er jo fase et. Forbedringerne ligger selvfølgelig i, at vi er så hurtige på den som muligt, men det er lige så meget alt det, der ligger i de interne løsninger, hvor jeg tror, at det er den her forventningsafstemning på, hvad er det for en tidsfaktor, man er oppe imod. Hvad er det, der er blevet ledelsesmæssigt sagt "jamen, vi ved sådan og sådan og sådan" At man anerkender, at der er et kendskab til, at vi gør det på den her måde som bruger, at det er det, man er oppe imod. Men det er måske der, den halter, at man ikke ved det. At man fik det defineret og fik beskrevet "jamen når den kører sådan, og den lander hos os, så har vi de og de rammer og den og den besvarelsestid inden for mail" lige som man oplever, hvis du skriver til din bank, så får du at vide "vi svarer inden i morgen klokken 16." At man havde sådan nogle respittider, viden om at når den lander her, så er det sådan, og når den lander hos udvikleren, er det så lang tid alt afhængigt af projektdeltagelse. Altså, at der var den. Det er nok lige så meget vigtigt, som at vi er hurtige på den, det er også, at vi ved hvor lang tid, hvert led har for at kunne forstå grunde "jamen, fair nok, vi ved det godt." og i ekstraordinære tider med ny idriftsættelse eller andre steder, hvor fejlmængden stiger, jamen så med rette, vil der også være et led, den lander i, der bliver påvirket i anden grad, så det vi normalt lover, det har vi lidt svært ved at overholde. R1: Men man kan sige, det er én ting i forhold til leddene igennem og slutbrugeren, men noget andet er også, tror jeg.. Jeg oplever også tit, at udviklerne har svært ved, hvordan de skal prioritere, fordi de tit er allokeret til projekter, og hvad ved jeg, og når der så pludselig kommer driftsfejl ind, hvordan skal og må de prioritere dem i forhold til alt andet, de har? Og derfor tror jeg desværre tit, og i og med de så tit kommer op med prioriteten low, så får de bare lov at ligge. R2: Altså manglende kendskab? R1: Ja, én ting er i forhold til slutbrugeren, men det er også sådan, at man netop beslutter, at de her der skal altså som minimum være en udvikler, der har kigget på dem inden x antal tid og taget stilling til, hvad skal der ske med den her. I: Det lyder som om, det er en situation, der gør sig gældende for det her specifikke system, når I taler om, at der er mange fejl lige på det lige det system, og der er mange af dem, der kommer videre til nogle udviklere, som skal prioritere deres tid brugt på driftsfejl i forhold til udvikling. R1: Ja. I: Er det så udvikling, som løser de fejl, eller er det, at de sidder med noget helt andet udvikling, og nu skal de tage tid ud til at gøre noget, for at den her fejl.. R1: Ja, de sidder jo typisk allokeret til nogle projekter, der har med noget helt andet at gøre. Bilag Side 158 af 185

159 I: Oplever I tit, at det er de samme fejl, der bliver meldt ind? I nævner, at der tit er mange, der når at melde den samme fejl ind, inden det ligesom går op for den kollektive bevidsthed, at nu er der noget galt. Oplever I så, at de fejl, der bliver meldt ind, og som kommer op til de her udviklere, at de så bliver løst, eller er der mange af de fejl, som kommer igen ugen efter? R1: Ja, de kommer desværre igen. I: Så det vil sige, udviklernes tid går ikke med at udvikle på systemet og med at løse fejlen, det går med at afhjælpe problemer? R2: Det er nok lidt en blanding. R1: Jo, men jeg synes også eksempelvis det her, vi har haft nu i en lang periode med, at den har været ustabil, Rådgiverportalen. Nogle gange virker den slet ikke, og andre gange svarer den bare langsomt og sådan noget. Og der har det så vist sig, at hver gang der er en, der tager fat i den, så har problemet løst sig selv, men at det så opstår igen efter en halv time eller en halv dag eller et eller andet. Den opgave er man ikke nået til endnu, at se på "hov, hvad skyldes det her egentlig?" Det vil sige, at vi når hver gang at få fejlen ret mange gange, fordi den bliver måske meldt ind tre gange i første omgang, og når så den igen ikke virker om fire timer, så når tre andre rådgivere at melde den ind, så derfor er den lige pludselig rigtig mange gange, fordi man hver gang tænker "jamen lige nu virker den jo, så vi kan godt lige lade den her ligge i stedet for hurtigt at få taget fat om nældens rod og se, hvad er det, der er grunden til, at den her hele tiden går ned. Der må være en eller anden grund til, at den her lige pludselig kører så ustabilt i forhold til, hvad den plejer. I: Og det er der så ikke nogen, der gør? R1: Jeg tror da bestemt, at der er nogen, der gør noget, men det er bare ikke.. Altså, der er bare ikke sket noget endnu. Der ligger flere åbne, der har ligget åbne nu i minimum to uger på en ustabil Rådgiverportal, som ikke er løst. Lige nu kører den, og den kommer op at køre hver gang, men det gør den de fleste gange af sig selv. Men problemet er bare, at for rådgiverne er det jo en enormt dårlig oplevelse, at den hele tiden enten er meget længe om at svare eller slet ikke svarer. Så kan det godt være, den så virker igen om en halv time, men det er bare meget utilfredsstillende, når man sidder med kunder i røret, at den ikke bare virker. Så der kunne det være rart, at der måske var en lidt højere attention på at finde ud af, hvad pokker er det, der gør, at den hele tiden går ned. Det giver jo dobbeltarbejde, at den når at blive oprettet, altså over de her uger er den nået at blive oprettet rigtig, rigtig mange gange, den samme sag, reelt. I: Hvad er så grunden til, at der ikke er nogen, der gør det? Som du siger "griber om nælden" og får problemet løst en gang for alle? R1: Det ved jeg ikke, det handler vel også om prioritering, ressourcer, tænker jeg. Jeg ved det ikke. Der bliver lige som kigget på den forholdsvist hurtigt hver gang, og så har det nogen gange været nogle services, Bilag Side 159 af 185

160 der skulle genstartes, og det er blevet gjort forholdsvist hurtigt. Jeg ved, at det er blevet oprettet som et problem i stedet for nu. At der skal findes ud af, hvorfor det er, at den hele tiden går ned. I: Er det så noget, du har hørt nogen tilbagemelding på? R1: Nej, ingen. I: Så det vil sige, der sker ikke noget i det.. R1: Det kan sagtens være, der sker noget, men det er ikke noget, jeg hverken kan læse, hvis jeg går ind på Remedy'en, og det er ikke noget, jeg har fået tilbagemeldinger om. Det kan sagtens være, der foregår en hel masse i kulisserne, så der bliver arbejdet på højtryk på den. Det har jeg ingen ide om. I: Men hvad er din oplevelse af den situation? R1: Min oplevelse er, at der ikke er sket noget endnu, fordi den person, der lige har fået sagen, var på ferie i sidste uge, og jeg har ikke indtryk af, at opgaven var overdraget til andre. I: Så det vil sige, det er igen et spørgsmål om personafhængighed og en skrøbelig situation, som ikke er til at.. R1: Ja, for vi har jo så i den periode, hvor personen var på ferie, har vi oplevet, at den var ustabil, og der er der andre, der har afhjulpet, at vi har fået genstartet nogle ting og sådan noget. Men det er bare.. Jeg mener, man kunne jo nok gøre sig selv en tjeneste ved, at man lidt hurtigere havde fundet ud af, hvad pokker er det. For det forstyrrer jo hver gang den går ned, så er der en masse mennesker, der bliver forstyrret, før at det så bliver afhjulpet den ene gang, frem for hvis man kunne finde ud af "hov, det er den der lille ændring, der har gjort, at den går ned hele tiden." I: Og hvad så? R1: At man så måske kunne få det løst en gang for alle kørte stabilt. Altså, det kommer jo helt an på, hvad fejlen er, det har jeg jo slet ikke forstand på, men der savner jeg jo nok lidt mere tilbagemelding. Og det er også det, jeg hører fra rådgiverne, at de er frustrerede over, at "nu virker det møg igen ikke, og vi hører ikke og.." R2: Ja, bottom line på det kan jo så blive, at vi får ikke registreret alle de fejl, som de måtte opleve, for de gider ikke at bidrage til årsagen, for vi får alligevel ikke noget ud af det, og man kan sige, så bliver det bare den der onde cirkel, at vi får måske ikke det rigtige billede af, hvad det er, der foregår ude i produktion. C: Det lyder interessant. R2: Hvis nu de har.. Bruger.. For eksempel de kunderådgivere, der sidder i KS, de har haft nogle oplevelser, hvor man siger "jamen det vi gør, der sker ikke noget. Vi får ikke oplevelsen af, at vi kommer videre hen og at redskabet bliver det bedre, eller forbedringen kommer. Så kan det også bare være lige meget." Sådan en resignationseffekt på hvor meget, man så gider at bidrage til.. Jamen alt, og det er jo der, jeg ikke forstår det, at uanset hvad så meld ind, meld ind, meld ind, for det er den eneste måde, vi kan finde ud af, hvad Bilag Side 160 af 185

161 omfanget er, hvordan vi kan ske forbedringer om prioriteterne på, når der bliver gjort noget, om det er det rigtige. Det kan blive en udfordring, tror jeg, på den lange bane, at vi får ikke det rigtige billede fra rådgiverne. Enten det, de resignerer, eller de bare vælger at benytte de bestående underliggende systemer. R1: Og det er rigtigt. Det hører man faktisk tit fra dem "nej, det gider jeg ikke lige at fejlmelde, fordi.." R2: Og det er for mig at se et endnu større problem. I: Ja, det er i hvert fald en interessant problemstilling, at folk ikke melder ind fordi.. Fordi hvad? R2: Fordi "who cares?" Det er lidt den.. De føler ikke, eller de oplever måske ikke, at der sker det, der skal, for at situationen bliver det bedre, eller at tilbagemeldingen.. "de sagde jo ikke noget." eller "den tilbagemelding jeg fik, den var mangelfuld." At distancen mellem det her.. Jamen så bliver det bare den der skolepigefornærmet "så vil jeg bare heller ikke." Og hvem er det så? Jamen så er det stadigvæk os alle sammen, der står med det samme problem. Det er nok den binding, der er den sværeste på brugersiden. Det bliver bare alt eller intet hvis.. De første par gange fordi de er så afhængige af det. Jamen hvis de ikke føler, de får det ud af det, eller de havde nogle andre forventninger. Og det er sådan set der, hvor man kan sige, det værste det er forventninger, der gør, at de ikke vil, fremfor hvad det er, de får tilbage. I: Så det er igen tilbage til det der forfærdelige ord "forventningsafstemning" i virkeligheden? R2: Ja, fordi er det det rette grundlag, de lægger det på is på, eller er det på baggrund af utålmodighed, fordi man vil have det hele løst nu og her. Jamen så var det måske hele billedet man skulle have med, inden man trak den linje. R1: Ja. Bilag Side 161 af 185

162 10.5 Case Virksomheden PenSam er en servicevirksomhed i den finansielle sektor, der varetager arbejdsmarkedspensionsordninger for en lang række af offentligt ansatte, der alle er organiseret under FOAs overenskomster. Ud over forvaltning af arbejdsmarkedspensionsmidler udbyder PenSam også en fuld pallette af bank- og realkreditprodukter samt livs- og skadesforsikring. PenSam har i de senere år døjet med store problemer specielt på IT-fronten, som blandt andet har medført, at store projekter er blevet skrottet, og at selskabet ikke har formået at sende det krævede materiale med pensionsoplysninger til en mindre andel af sine kunder. Disse forhold har bragt selskabet i mediernes søgelys (Jung, 2013). IT-funktionen I 2005 blev store dele af den daværende IT-organisation (primært de driftsrelaterede dele) outsourcet til en ekstern IT-driftsleverandør, og de elementer, der blev tilbage, blev spredt ud i virksomheden. Denne decentralisering skete efter et ønske om, at IT skulle være tættere på forretningen. De forskellige IT-funktioner var nu delt ud i forskellige divisioner under hver sin overordnede divisionsdirektør, hvor ledelsen i hver division prioriterede, hvilke opgaver de respektive IT-funktioner skulle udføre. Den tværgående koordinering i form af et udvalg var svag og uden beslutningsdygtighed eller sanktioneringsmuligheder. Der manglede således et overblik over den samlede IT-situation, hvilket gav sig til udtryk i store problemer med at få ændringer og udviklingstiltag gennemført. IT-udviklingsprojekter med omkostninger i hundredemillionerkronersklassen blev sat i søen decentralt uden tværgående styring. Der fandtes ingen central ITstrategi, og hvert område benyttede sig af egne underleverandører og arbejdede efter egen dagsorden uden hensyntagen til udviklingstiltag i de øvrige afdelinger. IT-projektlederne hørte til en afdeling for sig selv, men havde ingen ressourcer, og var således nødt til at konkurrere internt om de samme midler og medarbejdere. IT-arkitektur og egenudvikling af IT-løsninger hørte til en anden afdeling, ligesom IT-drift og samarbejde med IT-driftsleverandøren hørte til en afdeling for sig, mens ekstern IT-udvikling og kontakt til disse leverandører sorterede under kundeservicefunktionen. Ligeledes var det ikke klart, hvem der havde ansvaret for hvilke områder. Cheferne for de respektive afdelinger holdt i nogle sammenhænge møder i tværgående fora, men ansvaret for eksempelvis IT-udvikling var Bilag Side 162 af 185

163 spredt over adskillige funktionelle områder uden en klar fordeling. IT-udviklingsafdelingerne var således med i kampen om knappe ressourcer, omend det ikke var klart, hvornår en udviklingsopgave blev varetaget i drifts- og/eller forvaltningsregi og hvornår den skulle varetages af et udviklingsprojekt. Den manglende styring resulterede i, at nogle projekter gik i vasken og aldrig blev gennemført, mens andre blev taget i brug med mangelfuld eller manglende implementering. Det medførte, at forretningen ikke var klædt på til at modtage projektet, der oftest affødte et nyt IT-system og nye procedurer, som ingen efterfølgende anvendte. En yderligere konsekvens af det manglende fokus på IT har været en tendens i de enkelte områder til suboptimering og løsning af enkelte behov på bekostning af en fælles retning. Resultatet er knopskydning af små, individuelt udviklede løsninger. PenSam har i dag omkring 70 forretningsapplikationer, hvoraf de fleste er egenudviklede. Disse applikationer er meget dyre at vedligeholde, fordi de er afhængige af en meget begrænset skare, nogle gange helt ned til en eller to personer, der har det fornødne kendskab. Det repræsenterer en risiko, hvis der skulle opstå behov for hjælp, og eksperten ikke er tilgængelig. Endelig har manglende koordinering mellem forretningsenhederne og dårlig implementering af projekterne ført til udviklingen af løsninger, der ikke har været afstemt med forretningens behov. Yderligere opererer mange af disse såkaldte legacy-systemer med en ældre teknologi, hvor systemet i perioder skal lukkes for at køre batch. Dette medfører, at systemerne lukkes brugeradgang, så de indtastninger, der har fundet sted i løbet af dagen, bliver opdateret i systemernes databaser. Af hensyn til tidsforbruget bliver denne batchafvikling kørt om natten, men kørslerne tager ofte længere tid end planlagt, og der opstår mange fejl. Dette medfører, at systemerne ikke er tilgængelige, når brugerne møder på arbejde den efterfølgende morgen. Der manglede med andre ord både fælles standarder, forventningsafstemning mellem IT og forretningen og ordentlig implementering af IT-udviklingsprojekter. Resultatet af dette er et unødigt komplekst landskab af forretningsapplikationer, der mangler integration og funktionalitet. Tiltrædelse af en ny IT-direktør Efter syv år med decentral IT-styring og de udfordringer, det har medført, blev der i forbindelse med en større organisationsændring etableret resultatcentre i stedet for de tidligere divisioner, og alle ITfunktioner blev samlet i Resultatcenter IT under én IT-direktør (se organigram i Fejl! Henvisningskilde ikke fundet.). Den største udfordring for den nytiltrådte IT-direktør var fra begyndelsen at få alle dele af den fragmenterede IT-organisation i ét område, hvor alle arbejdede efter fælles fodslag. Dette blev gjort konkret ved etableringen af Resultatcenter IT (se organigram i Figur 10.1). I forbindelse med omorganiseringen blev omtrent halvdelen af de hidtidige funktionschefer på IT-området afskediget, og nye kom til, særligt fra ATP, hvor den nye IT-direktør også kom fra. Nogen tid efter blev det af en medar- Bilag Side 163 af 185

164 bejder med et humoristisk islæt foreslået, at PenSam lige så godt kunne skifte navn til ATP Sydøst (fordi PenSams hovedkontor i Farum befinder sig geografisk sydøst for ATPs hovedkontor i Hillerød). Det humoristiske indslag havde dog et mere alvorligt islæt, idet ansættelsen af en række folk med baggrund i ATP førte en kulturel ændring med sig, som af mange af PenSams hidtidige medarbejdere blev opfattet negativt. Driftsdelen af Resultatcenter IT er nu organiseret efter ITIL-principperne Service Design, Service Transition og Service Operation. Service Strategy er forankret højere i hierarkiet (IT-direktøren og chefarkitekten), mens det sidste element, Continual Service Improvement, ikke er ansvarsplaceret i organisationen. Figur 10.1: PenSams nuværende IT-organisation. Næste opgave blev at udforme en IT-strategi, hvis fornemste opgave var at opgradere hele IT-platformen og reducere afhængigheden af personbunden viden og nedbringe porteføljen af forretningsapplikationer fra 70 til omtrent 20. Horisonten for den nuværende IT-strategi strækker sig til år Inden for denne tidsramme er planlagt en udskiftning af størstedelen af applikationsporteføljen med henblik på forenkling og ensretning af applikationerne. Outsourcing Den seneste udvikling er, at de resterende dele af IT-driften nemlig Service Desk er blevet outsourcet til IT-driftsleverandøren. Dette har medført, at en stor del af den implicitte viden, som de tidligere driftsfolk i huset besad, er gået tabt, hvilket har ført til en stor ophobning af brugerhenvendelser, som leverandøren ikke kan løse, og som på trods af outsourcingen derfor alligevel videregives til løsning internt i PenSams IT-afdeling. IT-direktøren begrunder beslutningen om outsourcing af Service Desk-funktionen og medarbejderne, at der kan spares et millionbeløb på den nye kontrakt med leverandøren i sammenligning med at beholde funktionen internt i huset. Mange af Resultatcenter ITs kunder, de daglige brugere af IT-tjenesteydelserne, udtrykker frustration og uforståenhed over for outsourcingen, fordi de oplever, at ventetiden på at få en sag løst er steget samtidig med, at kvaliteten af den ydede service er faldet. Samarbejdet med Service Desk, der er første kontakt- Bilag Side 164 af 185

165 punkt for brugerne og fælles indgang til al IT i PenSam, opleves som bureaukratisk og administrativt tung. Det er besværligt at henvende sig med et problem, og det tager generelt (for) lang tid at få sit problem løst. Brugerne savner tilbagemelding og en forventning om, hvornår de kan forvente, at deres sag bliver løst (Ludvigsen & Borring, 2013; Bisbo & Nicolaisen, 2013; Glade & Brandt, 2013). Bilag Side 165 af 185

166 10.6 Begrebsforklaring I det følgende gives en kort definition af nogle af de anvendte begreber, der ikke nødvendigvis er kendt af alle læsere. Operational Excellence Begrebet Operational Excellence hidrører fra prisen The Shingo Prize for Operational Excellence, der årligt uddeles ved Utah State University, hvor Shigeo Shingo modtog sin doktorgrad i 1988 (The Shingo Prize, 2012). Operational Excellence dækker over opnåelse af høj performance under eksisterende forudsætninger ved at reducere fejl og omkostninger, men ikke fundamentalt ændre den måde, arbejdet udføres på (Hammer, 2004). Tankegangen er grundstenen i mange effektivitetsprincipper som Lean, Six Sigma, TQM og just-in-time (The Shingo Prize, 2012). Lean Begrebet Lean blev først fremsat af John Krafcik (Jensen, 2012b; Womack, Jones & Roos, 1990), der i dag er administrerende direktør for den koreanske bilfabrikant Hyundai (Graban, 2010). Begrebet blev vidt udbredt med bogen The Machine That Changed the World (Womack, Jones & Roos, 1990). For en nærmere forklaring af begrebet og dets fortolkning i nærværende sammenhæng, se kapitel 2 Litteraturreview og kapitel 4 Teori ovenfor. Information Technology Infrastructure Library (ITIL) IT Service Management er en betegnelse for et begreb, der anskuer anvendelsen af IT som et udbud af tjenesteydelser (services), der understøtter det forretningsmæssige behov. En service i denne sammenhæng er defineret som følger: A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. (Cartlidge et al., 2007, p. 6) En vidt udbredt standard på området er Information Technology Infrastructure Library, forkortet ITIL. Bilag Side 166 af 185

167 ITIL er et rammeværktøj, der samler alle IT-tjenesteydelser (IT Services) til understøttelse af forretningsprocesser i en livscyklus. ITIL er udviklet af Best Management Practice, som sorterer under Cabinet Office (tidligere Office of Government Commerce) i Storbritanniens regering (HM Government, 2013). Formålet med ITIL er at beskrive et rammeværktøj, der samler alle IT-tjenesteydelser (IT Services) til understøttelse af forretningsprocesser i en livscyklus. ITIL-livscyklen består af fem hovedelementer, som er kort beskrevet i følgende tabel: Hovedelement Service Strategy Beskrivelse Identificering af, hvem kunderne er, hvilke IT-tjenesteydelser der skal til for at opfylde kundernes behov og hvilke ressourcer der er nødvendige for at stille disse tjenesteydelser til rådighed. Service Design Sikring af, at tjenesteydelserne udformes, så de opfylder de identificerede kundebehov. Service Transition Service Operation Opbygning, test og ibrugtagning af tjenesteydelser for at sikre, at behovene opfyldes. Vedligehold af idriftsatte tjenesteydelser, håndtering af hændelser (se forklaring på Incident Management-processen i Tabel 10.2). Service Desk-funktionen håndteres i denne fase. Continual Service Improvement Fokus på løbende forbedring af de udbudte IT-tjenesteydelser gennem måling og forbedring af serviceniveau og proceseffektivitet. Tabel 10.1: Kort beskrivelse af hovedelementerne i ITIL-rammeværktøjet I nærværende sammenhæng fokuseres på tre centrale procesbeskrivelser i ITIL, som er forklaret nærmere i nedenstående tabel. Rammeværktøjet omfatter adskillige andre processer og funktioner, der dog ikke vil blive beskrevet nærmere her. Change Management-processen behandles heller ikke yderligere, men er med i denne beskrivelse for at danne et overblik over den samlede håndtering af en henvendelse fra hændelse til løsning. Begreb Single Point of Contact Service Desk Forklaring Et princip om, at en bruger altid kun skal henvende sig ét sted vedrørende ITtjenesteydelser. Det organ, der modtager alle henvendelser vedrørende IT-tjenesteydelser, jf. Single Bilag Side 167 af 185

168 Begreb Forklaring Point of Contact-princippet (se ovenfor). Service Request Management (Request Fulfilment) Processen initieres af, at en bruger af en IT-tjenesteydelse henvender sig til Service Desk-funktionen med henblik på udbedring af en fejl. Hvis fejlen umiddelbart kan afhjælpes, afsluttes henvendelsen med det samme. Hvis ikke, overdrages henvendelsen til Incident Management-processen som en Incident, dvs. en hændelse. Incident Management Undersøger årsagen til en fejls opståen. Hvis fejlen kan afhjælpes og tjenesteydelsen genetableres, lukkes hændelsen. Ved gentagne hændelser, eller hvis årsagen ikke hændelsens opståen ikke umiddelbart kan identificeres, overgår hændelsen til Problem Management-processen. Hvis der skal gennemføres ændringer for at genetablere tjenesteydelsen (User Service Restoration, se Figur 10.2), eller hvis der er tale om et ændringsønske eller indførelse af ny funktionalitet (User Service Request, se Figur 10.2), varetages dette af Change Management-processen. Problem Management Change Management Tabel 10.2: Forklaring af de anvendte ITIL-begreber Nærmere analyse af (et eller) flere tilfælde af en hændelse med henblik på identificering af den underliggende årsag til problemet. Hvis en hændelse (eller et problem) kræver en ændring i det eksisterende udbud af IT-tjenesteydelser for at kunne løses, varetages denne ændring af Change Management-processen. En brugerhenvendelse kan også dreje sig om idriftsættelse af en ændring, i hvilket tilfælde henvendelsen varetages direkte af Change Management-processen uden om Incident Management (og Problem Management). For overblikkets skyld er sammenhængen mellem de fire processer illustreret i nedenstående figur. Bilag Side 168 af 185

169 Figur 10.2: Skematisk oversigt over sammenhængen mellem de anvendte ITILprocesser Bilag Side 169 af 185

170 10.7 Resultater af litteratursøgning Søgeord Antal artikler i søgning Lean it services Lean it processes Lean it services Lean it processes Service industries 8 (i alt) Waste minimisation Lean manufacturing Process optimisation Lean 12 Customer Services Lean 15 Information Technology Lean 3 Financial Services PDCA 1 Lean PDCA 1 Information Technology PDCA 4 Customer Services Systems Thinking (titel) 4 Customer Services Systems Thinking (titel) 5 Information Technology Bilag Side 170 af 185

171 Tabel 10.3 Resultater af litteratursøgning Bilag Side 171 af 185

172 10.8 Artikel om strategi fra PenSams intranet Indsatsområder 2013: 6 fyrtårne viser vejen Resultatcenterdirektørerne har udpeget 6 fokusområder med mål og indsatser for De 6 fokusområder for 2013, også kaldet fyrtårne, er udpeget, fordi de har en central betydning for recultatcentrenes udvikling og forretning. Indsatserne skal sikre at resultatcentrene hele tiden udvikler sig i den rigtige retning. "Vi glæder os rigtig meget til at rulle indsatserne for 2013 ud. Indsatserne under hvert fyrtårn skal sikre, at vi er konkurrencedygtige og leverer de rigtige produkter og services til forretningsenhederne - også i fremtiden", fortæller Ulla Benediktson på vegne af RCD-kredsen. De 6 fyrtårne Fyrtårnene er de 6 fokusområder, vi skal arbejde med i 2013 for at kunne levere "operational excellence": Bilag Side 172 af 185