Samverkanshandbok CSN och Leverantören Version 1.0

Relevanta dokument
5 VAD RAMVERKET BETYDER FÖR DIG SOM ANBUDSGIVARE

Arbetsplatstjänsten / SUA

Service management Samverkan och rapportering

TJÄNSTEBESKRIVNING SERVICEDESK

Allmänna villkor. för Mina meddelanden. Bilaga 4 Servicenivåer (SLA) version 1.0 (Gäller fr.o.m )

Bilaga 1. Definitioner

ÄNDRINGSPROCESS LÄNSTEKNIK

Ändringsprocess för driftsättning Länsteknik

TJÄNSTEBESKRIVNING APPLIKATIONSDRIFT

RUTIN FÖR DRIFTSÄTTNING

Processbeskrivning - Incident Management

PIMM PROFECTO INFRASTRUCTURE MANAGEMENT MODEL ETT WHITEPAPER OM PIMM

Mobilt arbetssätt inom vård och omsorg Linköping UH

Processbeskrivning - Incident Management

Samverkansmodellen. Samverkansmodellen. Version: 03.00

Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0

GRUND - SLA. Beslutsdatum Detta dokument syftar till att beskriva grund SLA vid Göteborgs universitet STYRDOKUMENT

Version beslutad Dnr: /1231 Dnr: KMY Dnr:SSC Samverkansmodell Statens servicecenter FE 15 SE Gävle

Dokument 1 till Kontrakt PROJEKTGENOMFÖRANDE

Förstudie: Övergripande granskning av ITdriften

Bastjänsterna ovan avser driftfasen. Införandet genomförs som ett projekt som drivs av Cygate i samarbete med kunden.

BILAGA 3 TJÄNSTENIVÅ SLA ÖVERENSKOMMELSE OM TJÄNSTENIVÅ

Tjänsten baseras på realtidsövervakning av era utskriftsenheter samt tydliga rutiner för problemlösning och effektivisering.

The Rational IT Model EN ENKLARE VÄG TILL IT SERVICE MANAGEMENT

Leverans och installation

Bilaga 4f Gemensamma processer Dnr: /

Aktiviteter vid avtalets upphörande

Bilaga 4h Aktiviteter vid avtalets upphörande Dnr: /

Visionen om en Tjänstekatalog

Avtal Standard dator arbetsplats (SLA)

Avtal om Transmissionsprodukter. Bilaga 2, Samverkan Sida 1 av 6 Datum ver Avtal om Transmissionsprodukter Bilaga 2 Samverkan

Upphandling 1-1 Datorer. Bilaga 4: Service Level Agreement (SLA)

Bilaga 9 Säkerhet Dnr: /2015 Förfrågningsunderlag

Bilaga 8D Tjänster för Stadens Pedagogiska Verksamheter

Examinering i ITIL Foundation

Processbeskrivning Problem Management

Service Management Tjänstebeskrivning

Bilaga 4f. Gemensamma processer. Upphandling av IT-stöd för hantering av elevdokumentation inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN

Bilaga 3 Säkerhet Dnr: /

Slutrapport. Certifiering LADOK Pontus Abrahamsson Lösningsarkitekt Säkerhet

Bilaga 4e. Samarbetsformer och fora. Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN

Bilaga 11. Mall för leveransavtal

Handbok för organisationsförändringar

Er partner inom IT service management. Utbildningar e-learning Workshops Material Coachning

KVALITETS- OCH MILJÖLEDNINGSSYSTEM ÖVERSIKT

TJÄNSTEBESKRIVNING SERVICE MANAGEMENT

Avtal om transmissionsprodukter Bilaga 6 Fel i Transmissionsprodukter

Bilaga 4 Kontinuerliga förbättringar Dnr: /2015 Förfrågningsunderlag

BILAGA 5 - Fö reskrifter fö r Sambiömbud Versiön: 1.0.1

Helhetsåtagande underhåll och drift

Systemförvaltningshandbok

Bilagan innehåller beskrivning av de åtaganden rörande IT som gäller för

ITIL Service Management

VERVA. Fujitsu Services Kenneth Landérus F

Bilaga 5 Administration och kontroll

Avvikelsehantering statistikproduktion

Tjänstebeskrivning Service Desk

Bilaga IT till förfrågningsunderlag Bil 3 Inledning

Tjänsteavtal för ehälsotjänst

Checklista för anslutningsarbete till e-arkiv Stockholm

Myndigheten för samhällsskydd och beredskaps författningssamling

Granskning av intern styrning och kontroll vid Statens servicecenter

Bilaga 17 Mall för operativt samverkansavtal med GSIT 2.0- leverantören Dnr: /2015 Förfrågningsunderlag

Sweden ICT Week. Avtala IT och möjliggör en god relation mellan verksamheten och IT. Anita Myrberg BiTA Service Management.

Bilaga 5 Administration och kontroll

Användarhandledning Standardfaktura SEB imail 1.1 Standardfaktura

Trafikkontorets krav

ATEA. Tjänstekoncept. Arbetsplats och utskrift som funktion. Ateas tjänsteleverans till Kammarkollegiet. Version

Uppdateringar nya standarden ISO/IEC 17020:2012

Remote Access Service

Systemdrift och Systemförvaltning Centrala verksamhetssystem Service Desk

Anslutningsprocess SNPAC - AM CRDB TM Capgemini

Process och rutinbeskrivning Ändring av fordon, HVK, dokumentation och underhåll

Västerås stad. IT-verksamhet i förändring. Att använda Best Practice och standards för att få ordning och reda ett verkligt case

Göteborg Energi AB. Självdeklaration 2012 Verifiering av inköpsprocessen Utförd av Deloitte. 18 december 2012

Handbok för organisationsförändringar

Bilaga 4g. Servicenivåer. Upphandling av IT-stöd för hantering av elevdokumentation UTBILDNINGSFÖRVALTNINGEN. Förfrågningsunderlag

Bilaga Från standard till komponent

Avtal om Kundens användning av

Bilaga 2 Drift och Underhåll

BILAGA 3 - SUPPORT OCH KONTAKTER

TEKNISK HANDBOK FÖR MARK- GATU- OCH VA-ARBETEN

Checklista för anslutningsarbete till e-arkiv Stockholm

BILAGA 3 - SUPPORT OCH KONTAKTER

Bilaga 7C Leveranser från GSIT 2.0- leverantören Dnr: /2015 Förfrågningsunderlag

System- och objektförvaltning - roller

Svensk Kvalitetsbas kravstandard (1:2016)

Bilaga 4b. Underhåll. Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN. Förfrågningsunderlag

Grundvattenbortledning M Bilaga 12. Arbete utanför ordinarie arbetstid

Processinriktning i ISO 9001:2015

Service Level Agreement mall för kommunalt IT-stöd

Ramverk för projekt och uppdrag

FAKTURERINGSRUTINER VID KFF-AVTAL MELLAN LANTMÄTERIET OCH KOMMUN

Sjunet standardregelverk för informationssäkerhet

FÖRVALTNINGSGUIDE FGUIDE FÖR STOCKHOLMS STAD MODELLFÖRDJUPNING

Ordning och reda förenklar styrningen,

Checklista för utvärdering av miljöledningssystem enligt ISO 14001:2004

Serviceavtal mellan XXX förvaltning och Serviceförvaltningen avseende ekonomiadministrativa tjänster

Inbjudan till dialog avseende drift och kundstöd

Sida 1 (av 12) Revision Skall-krav

Transkript:

Bilaga 8.1 Samverkanshandbok CSN och Leverantören Version 1.0 CSN december 2014, Informationsklassning

1 INLEDNING 5 1.1 Allmänt 5 1.2 Ramar 5 1.3 Definitioner av begrepp 6 2 ORGANISATION OCH SAMVERKAN 8 2.1 Organisation CSN 8 2.2 Organisation Leverantören 8 2.3 Roller och bemanning 8 2.3.1 CSN 8 2.3.2 Leverantör 9 2.4 Forum 10 2.5 Eskalering 11 3 KVALITET 11 4 GRÄNSSNITT BASERADE PÅ ITIL REFERENSRAMVERK 12 4.1 Incident management. 12 4.1.1 Registrera 12 4.1.2 Identifiera 13 4.1.3 Bereda 14 4.1.4 Analysera 15 4.1.5 Genomföra 15 4.1.6 Verifiera 15 4.1.7 Stänga ärende 16 4.2 Problem management 16 4.2.1 Förutsättningar för hantering av problem 16 4.2.2 Registrera ärende 16 4.2.3 Utredning och diagnos 17 4.2.4 Ta fram lösning 17 4.2.5 Besluta om lösning 17 4.2.6 Verifiera implementering 17 4.2.7 Stänga ärende 18 4.3 Change management 18 4.4 Service Request 19 4.4.1 Förutsättningar för hantering av Request 19 4.4.2 Registrera 19 4.4.3 Bereda 19 4.4.4 Genomföra 20 4.4.5 Stänga ärende 20 2

4.5 Release Management 20 5 FAKTURERING 20 6 SÄKERHET 21 7 BENCHMARKING 21 8 REVISION 21 9 RAPPORTERING 21 10 TOLKNINGAR OCH KONTRAKTSFÖRÄNDRINGAR 21 10.1 Tolkningar 22 10.2 Kontraktsförändringar 22 11 MILJÖ 22 12 VERKTYGSSTÖD 22 12.1 Gemensam lagringsyta 22 12.2 Webb 23 3

Bilagor Bilaga 1 xxx Ändringslogg 4

1 Inledning 1.1 Allmänt Syftet med denna samverkanshandbok är att säkerställa att önskad kvalitet uppnås i samarbetet mellan CSN och Leverantör genom att tydliggöra ansvarsgränser och beskriva de samverkansformer samt processer som ska gälla under kontraktstiden. Vid utförande av kontrakterad tjänst är det viktigt att det finns en tydlig ansvarsfördelning mellan CSN och Leverantören för styrning, genomförande och uppföljning. Det ska vara tydligt för bägge parter vilka roller som för dialog med varandra, om vad och när. Ett processorienterat arbetssätt är nödvändigt för att säkerställa ett effektivt samarbete mellan CSN och Leverantör. 1.2 Ramar Samverkanshandboken förvaltas gemensamt av CSN:s leverantörsansvarige och Leverantörens Service Delivery Manager. Den ska kontinuerligt uppdateras och förbättras i syfte att ha effektiva och smidiga samverkansformer mellan CSN och Leverantören. Alla förändringar i handboken skall godkännas i taktiska styrgruppen. Stora förändringar av samverkanshandboken beslutas av den styrgruppen. Mindre förändringar beslutas av operativ styrgrupp och presenteras för taktisk styrgrupp. Förändringarna skall dokumenteras så att det tydligt framgår vad som har ändrats och av vem. Part som identifierar förändringsbehov har ansvar för att initiera uppdatering av samverkanshandboken. Behov av ändringar som framkommer via andra möten skall skickas till operativ styrgrupp för godkännande eller eskalering. Samarbetet mellan CSN och Leverantören bör följa följande ramar och förhållningssätt: - Respektera varandras tider i samband med möten genom att komma i tid till mötet, ha en klar agenda och målsättning med mötet, respektera mötestiden. - Att vi ska vara tydliga mot varandra och informera om sådant som kan påverka samarbete och leveranser - Att i god tid informera och diskutera utbyte av nyckelpersoner. Handboken tillsammans med bilagor och mallar lagras och hanteras på en gemensam lagringsyta enligt avsnitt 12.1. 5

1.3 Definitioner av begrepp Nedan ges förklaringar till ett antal begrepp som används i detta dokument. Term Change Change Management Eskalering Funktionell eskalering Förändring Förändringsbegäran Grundorsak Hierarkisk eskalering Incident Incident Management IT-infrastruktur IT-tjänst Definition se Förändring Den process som kontrollerar livscykeln hos alla ITrelaterade förändringar. Den primära målsättningen med Change Management är att möjliggöra bra förändringar. Att på ett kontrollerat sätt genomföra förändringar så att inga oplanerade störningar uppstår En aktivitet som får ytterligare resurser vid behov för att nå överenskomna tjänstenivåer eller uppfylla kundkrav. Eskalering kan behövas inom alla IT Service Managementprocesser, men förknippas oftast med Incident Management, Problem Management eller hanteringen av kundklagomål. Det finns två typer av eskalering; funktionell eskalering och hierarkisk eskalering. Att överföra en incident, ett problem eller en förändring till ett tekniskt team med en högre expertis för att få deras hjälp att lösa ärendet. Tillägg, modifiering eller borttagande av något som kan påverka IT-infrastrukturen. Omfattningen ska inkludera alla konfigurationsobjekt, processer, dokumentation etc. Detaljerat och på ett standardiserat sätt dokumenterat förslag till förändring Den underliggande eller ursprungliga orsaken till en incident eller ett problem. Informera eller involvera högre chefer så att de besluta om fortsatt hantering av ärendet. Ett oplanerat avbrott i en IT-tjänst eller reduktion i kvalitén hos en IT-tjänst. Fel i ett konfigurationsobjekt som ännu inte påverkat tjänsten är också en incident Den process som ansvarar för att hantera incidenters livscykel. Det viktigaste målet för Incident Management är att återställa funktionen för användarna så snabbt som möjligt. All hårdvara, mjukvara, alla nätverk och faciliteter etcetera. som behövs för att utveckla, testa, leverera, övervaka, kontrollera och ge stöd till verksamhetsapplikationer. En tjänst som levereras till en eller flera kunder av en Leverantör. En IT-tjänst bygger på användandet av informationsteknik och stödjer kundens verksamhetsprocesser. En IT-tjänst består av en kombination av människor, processer och teknik och ska definieras i ett tjänstekontrakt. 6

Term Konfigurationsobjekt (CI) Problem Problem Management Processansvarig Produktionssättning Release Release Management Request Request Management Request for Change (RFC) Service Desk Tjänstekatalog Definition Alla komponenter som måste hanteras för att en IT-tjänst ska kunna levereras. Information om varje konfigurationsobjekt lagras i en konfigurationspost i en konfigurationsdatabas. och underhålls av Configuration Management under sin livscykel. Konfigurationsobjekt inkluderar i typfallet hårdvara, mjukvara, relationer mellan hårdvara och mjukvara och formell dokumentation som t.ex. processdokumentation. Bakomliggande grundorsak till en eller flera incidenter. Orsaken är vanligtvis inte känd vid tidpunkten när problemärendet skapas och Problem Management ansvarar för vidare undersökning Den process som hanterar livscykeln hos alla problem. Det primära målet med Problem Management är att förebygga att incidenter sker och att minimera påverkan från de incidenter som inte kan förhindras. En processansvarigs ansvar omfattar planering och koordinering av vad som krävs för att säkerställa att processen når uppsatta mål och därmed önskad effektivitet. Release (eller enskild förändring) tas i anspråk för produktion En samling av förändring(ar) bestående av hårdvara, mjukvara, dokumentation, processer eller andra komponenter som krävs för att implementera en eller flera godkända förändringar på ett eller flera konfigurationsobjekt. Innehållet i varje release skall vara hanterat, testat och produktionssatt som en enhet. Den process som ansvarar för planering, schemaläggning och kontroll när releaser flyttas till test- och produktionsmiljö. Det primära målet med Release Management är att skydda produktionsmiljön och dess integritet samt att se till att releasen innehåller rätt komponenter. En förändring som har godkänts på förhand, innebär låg risk, är relativt vanlig och följer en procedur eller arbetsinstruktion. Några exempel är att nollställa ett lösenord eller tillhandahålla standardutrustning till nyanställda. Vad som ska betraktas som Request dokumenteras i en Tjänstekatalog Den process som enligt CSN:s definition av Request Fulfillment Processen enligt ITIL v.3 hanterar livscykeln hos alla request. Det primära målet med Request Management är ta emot och utföra request från behöriga beställare. Se Förändringsbegäran Den Service Desk som Leverantören av Utdata tillhandahåller som kontaktväg till Leverantören. Förteckning över vad som tillhandahålls som Request och därmed kan hanteras inom Request Management processen 7

2 Organisation och samverkan Parterna skall samverka inom ramen för den samverkansorganisation som beskrivs i detta dokument. I frågor som avser resp. tjänst ska kontakter mellan CSN och Leverantör i huvudsak gå via de processgränssnitt, forum och roller som beskrivs i detta dokument. 2.1 Organisation CSN Kortfattad och översiktlig beskrivning av CSN och CSN:s verksamhet 2.2 Organisation Leverantören Kortfattad och översiktlig beskrivning av Leverantören och Leverantörens verksamhet 2.3 Roller och bemanning Parterna skall i sin leveransorganisation ha roller och personer som matchar beskriven samverkansorganisation. Leverantören skall tillse att leveransorganisation är stabil och försedd med den kompetens som erfordras för att professionellt samverka med CSN. Personer i samverkansorganisationen skall tala svenska. Dokumentation och övrig korrespondens skall vara på svenska. Samtliga roller skall ha ersättare vid sjukdom, semester etc. Operativ samverkan skall i huvudsak äga rum genom de roller som ingår i CSN:s driftsorganisation och Leverantörens leveransorganisation. Nyckelroller inom respektive organisation beskrivs nedan. Aktuell bemanning med namn i respektive nyckelroll finns beskrivet i Bilaga 2.3 1 Bemanning Nyckelroller, som lagras på den gemensamma lagringsytan enligt avsnitt 12.1. 2.3.1 CSN Roll CSN Ansvar Kontraktsägare - Värdera förslag till kontraktsförändringar - Besluta om kontraktsändringar - I samråd med Leverantör besluta om förändringar av samverkanshandboken - Ägare av samverkanshandboken - Följa upp kontraktsändringar 8

Roll CSN Ansvar Leverantörsansvarig - Övergripande följa upp tjänsteleveransen - I samråd med Leverantör besluta om mindre förändringar av tjänstekontrakt - Följa upp att levererad tjänst överensstämmer med kontrakterade servicenivåer - Kontaktperson mot Leverantör i frågor om leverans av tjänsten - I samråd med Leverantör föreslå förändringar av tjänstekontrakt till taktisk styrgrupp - I samråd med Leverantör förvalta samverkanshandboken - Föreslå förbättringar av samverkan CSN - Leverantör IT-säkerhetsansvarig - Följa upp att Leverantören hanterar ITsäkerhetsfrågor i enlighet med åtagande i kontraktet - Kontaktperson mot Leverantören i ITsäkerhetsfrågor enligt kontraktet 2.3.2 Leverantör Roll Leverantör Ansvar Kontraktsägare - Värdera förslag till kontraktsförändringar Service Delivery Manager (SDM) - Besluta om kontraktsändringar - Följa upp kontraktsändringar - Övergripande följa upp tjänsteleveransen och eskalerade avvikelser av tjänsteleveransen - I samråd med CSN föreslå förändringar av tjänstekontrakt - I samråd med CSN förvalta och besluta om förändringar av samverkanshandboken - Följa upp att levererad tjänst överensstämmer med kontrakterade servicenivåer - Planering och uppföljning av leverans mot överenskommen produktionsplan - Agera och följa upp eskalerade frågor angående löpande leverans 9

2.4 Forum CSN och Leverantören samverkar på två nivåer, löpande samverkan (Operativ Styrgrupp) och Taktisk styrgrupp. CSN är sammankallande för Taktisk styrgrupp och Leverantören för övriga forum. Samtliga möten skall dokumenteras med minnesanteckningar som lagras på gemensam lagringsplats. Mötesplats avser normalt CSN HK, Sundsvall alternativt telefon- eller videokonferens. Vid ev. kostnader i samband med dessa forum svarar respektive part för dessa. Om det under kontraktsperioden uppkommer behov av ytterligare forum ska dessa beslutas av taktisk styrgrupp. Varje forum ska ha ett tydligt uppdrag och avrapportera till taktisk styrgrupp. Nedan visas en översikt över fasta forum: Forum / frekvens Uppgift Deltagare och mötesroll Taktisk styrgrupp 2 gånger per år Operativ styrgrupp Månadsvis Följa upp, utvärdera och besluta om kontraktsförändringar CSN skall informera om eventuella förändringar i strategier, mål och nya behov med kopplingar till Kontraktet. Leverantör skall informera om hur man agerar utifrån nya möjligheter, trender och omvärld. Besluta om förändringar av samverkanshandbok (årlig revision) Eskaleringsinstans för Operativ styrgrupp Löpande följa upp åtagandet enligt tjänstekontrakt Utvärdera större genomförda körningar som körs någon gång per år i syfte att hitta förbättringar i arbetssätt. Vid behov föreslå förändringar av tjänsten Eskalerar till taktisk styrgrupp vid behov Representanter från CSN är: Kontraktsägare (ordförande) Leverantörsansvarig (Föredragande) Representanter från Leverantör är: Kontraktsägare Service Delivery Manager Representanter från CSN är: Leverantörsansvarig (Ordf.) Representanter från Leverantör är: Service Delivery Manager (Föredragande) 10

Bilagor 2.4. 1 2.4. 3 beskriver respektive forum. Dessa bilagor lagras på den gemensamma lagringsytan enligt avsnitt 12.1. Mallar 2.4 1 2.4 3 innehåller mallar för mötesanteckningar för respektive fora samt mallar för aktivitets- och beslutslogg. Dessa mallar lagras på gemensamma lagringsytan enligt avsnitt 12.1. 2.5 Eskalering När överenskommelse inte kan nås mellan ansvariga på viss nivå i en viss fråga eskaleras den till närmast överliggande nivå i resp. organisation enligt nedan. Syftet är att säkerställa att konflikter och frågor från lägre nivåer löses. Eskalering kan komma att användas vid följande situationer: - Oklarheter avseende utförande av tjänst, t ex prioriteringar - Oklarheter avseende omfattning av tjänst, t ex ägande av ärende - Oklarheter avseende utökning av tjänst, t ex införande av ny tjänst - Oklarheter vid uppföljning av leverans, t ex faktureringsärenden Följande eskaleringsgång gäller: CSN Leverantör Service Delivery Manager Kontraktsägare Kontraktsägare ägare Kontraktsförvaltare Leverantörsansvarig Operativa roller När överenskommelse inte kan nås mellan Kontraktsägare CSN Kontraktsägare Leverantör hanteras frågan enligt vad som beskrivs om tvist i huvudkontraktet. 3 Kvalitet Kortfattad beskrivning hur Leverantören arbetar med kontinuerligt kvalitetshöjning i sina leveranser. Kortfattad beskrivning hur CSN arbetar med kontinuerligt kvalitetshöjning i sin verksamhet. 11

4 Gränssnitt baserade på ITIL referensramverk För att ansluta till standarder som finns på marknaden och för att på ett enhetligt sätt kommunicera med Leverantörer har CSN valt att använda principerna enligt ITIL som ramverk. De processer enligt ITIL som ingår vid kontraktets tecknade är följande: - Change Management - Incident Management - Problem Management - Service Request Ytterligare processer kan komma att implementeras under kontraktstiden. CSN skall kunna följa Leverantörens ärendeflöden i de processer som hanterar Incident, Service Request, Problem och Change Management. CSN:s leverantörssansvarige får alltid återkoppling via e-post från Leverantör för ärenden som initierats av annan. Återkopplingen sker när ärendet registreras och när det stängs. 4.1 Incident management. 4.1.1 Registrera Leverantör får ett larm eller en felanmälan CSN - Initierar incidentärendet via felanmälan till Service Desk Leverantör - Registrerar ärendet utifrån upptäckt larm eller felanmälan från CSN. - Säkerställa att all nödvändig information finns tillgänglig i ärendet. - Manuellt upptäckt av Leverantör Från CSN kan en incident initieras på följande sätt: - När leverantörsansvarig får information om att fil inte levererats till Leverantör enligt plan gör denne en anmälan till Service Desk via webb 1 - När leverantörsansvarig upptäcker ett fel i en fil som levererats till Leverantör gör denne en anmälan till Service Desk via telefon och webb 1 - När leverantörsansvarig upptäcker fel i Leverantörs leverans gör denne en anmälan till Leverantör via webb 1 1 Vid inrapportering från CSN till Service Desk ska följande uppgifter anges: Xxx (enligt överenskommelse) Namn (förnamn, efternamn) Datum när incidenten upptäckts 12

Från <Annan Leverantör> kan en incident initieras på följande sätt: - När en fil inte kan överföras till Leverantör kontaktar <Annan Leverantörs> Applikationsdrift Leverantörens Service Desk via telefon. I samtliga fall ansvarar Service Desk för att ett incidentärende registreras i Leverantörens ärendehanteringssystem och att ansvaret för ärendets hantering övergår till berörd grupp hos Leverantören. När incidentärende registrerats sker återkoppling till initieraren från Leverantörens ärendehanteringssystem med information om ärendet (inklusive referensnummer) som verifiering att Leverantören tagit ansvar för ärendet. Vid fel i Leverantörens produktion kan en incident initieras på två sätt: - Via larm till Leverantörens övervakning. När övervakningen får ett larm i Leverantörens övervakningsverktyg skapas ett incidentärende i Leverantörens ärendehanteringssystem. Service Desk ansvarar för att ärendets hantering övergår till berörd grupp hos Leverantören. - Via annan upptäckt hos Leverantören När tekniker/annan medarbetare inom Leverantören upptäcker en incident skapar denne ett incidentärende i Leverantörens ärendehanteringssystem och ansvaret för ärendets hantering övergår till berörd grupp hos Leverantören. För daglig produktion gäller avvikelserapportering. Dvs Leverantör meddelar CSN alla avvikelser som innebär leveransförsening. För produktion av större volymer, tex månadsavisering, gäller som tidigare daglig rapportering av postinlämning. 4.1.2 Identifiera Leverantören identifierar hantering av incidenten genom avstämning mot tjänstekontrakt. Transferering av ett incidentärende kan ske under olika faser i ärendets hantering. CSN - Deltar i arbetet för incidenter där det är oklart om ansvaret ligger hos CSN eller Leverantör. - Godkänner att incidenten transfereras från Leverantören om den inte är inom ramen för Leverantörens åtagande. Transferering innebär att ansvaret för hantering och återrapportering överförs till CSN. Om CSN inte godkänner transfereringen, ska ärendet eskaleras enligt avsnitt 2.5. 13

Leverantör - Kontrollera om hanteringen av incidenten ingår enligt tjänstekontrakt - Om Leverantör anser att en incident inte omfattas av tjänstekontrakt ska transferering omedelbart ske till CSN. Incidenten stängs hos Leverantör om CSN godkänner transfereringen. Leverantör ansvarar för att informera om detta till den som initierat incidentärendet. - Om det är oklart om ansvaret ligger hos CSN eller Leverantör, ansvarar Leverantör för att driva incidentärendet tills klarhet finns om ansvaret. Om det då är Leverantörs ansvar, fortsätter denne att driva incidentärendet. Om det är CSN:s ansvar, ska Leverantör säkerställa att ärendet transfereras. Oklart ägande av ärende Om det finns oklarheter avseende om ett ärende ingår i tjänstekontrakt kontaktar Service Desk Leverantörens Service Delivery Manager (SDM) som övertar arbetet att reda ut ärendets ägande. Service Delivery Manager (DSM) kontaktar sedan Leverantörsansvarig på CSN för att bestämma ägande av ärende. Kan inte överenskommelse nås sker eskalering enligt eskaleringsprocess i avsnitt 2.5. Transferering Om det identifierats att ärendet inte ingår i Leverantörs ansvarsområde transfererar Service Delivery Manager (SDM) ärendet till leverantörsansvarig på CSN. Se bilaga 2.3 1 Bemanning Nyckelroller för information om bemanning. I första hand ska transferering ske via telefon. Information avseende ärendet samt Leverantörs ärendenummer lämnas vid transfereringen. Ärendet är dock inte transfererat från Leverantör till CSN förrän Leverantörs Service Delivery Manager (SDM) har fått en accept via e-post från leverantörsansvarig på CSN om att ansvaret för ärendet övertagits. Accepten ska även innehålla CSN:s ärendenummer. Ärendet stängs i Leverantörs ärendehanteringssystem med hänvisning att ärende är transfererat. Ytterst ansvarig för identifiering av incidentärenden är Service Delivery Manager (SDM). 4.1.3 Bereda CSN - Deltar i utredning för incidenter där det är oklart om ansvaret ligger hos CSN eller Leverantör. Leverantör - Sätter åtgärdstid på ärendet utifrån tjänstekontrakt. - Informerar CSN angående status på ärendet och beräknad tidpunkt för när incidenten kan vara löst. För incidenter som initierats av Leverantör informeras CSN endast vid påverkan på CSN:s verksamhet. Vid oklarheter avseende om ett ärende ingår i tjänstekontrakt eller ej gäller det som beskrivs i avsnitt 4.1.2, stycket Oklart ägande av ärende. 14

När leveranstidpunkten inte kommer att hållas informeras alltid CSN:s Leverantörsansvarig via telefon av berörd grupp hos Leverantören. 4.1.4 Analysera CSN - Deltar vid behov i samband framtagande av åtgärd - Godkänner genomförandet där det innebär risk för påverkan på CSN:s verksamhet. Leverantör - Analyserar om incidenten inträffat tidigare. - Analysera och ta fram åtgärd på incidenten. - Analysera konsekvens för genomförandet. Det vill säga finns det en risk för påverkan på CSN. Återkoppla till CSN för att få ett godkännande av genomförandet. När analys av incidenten kräver deltagande från CSN kontaktas Leverantörsansvarig. Om analysen visar på att incidenten ligger utanför Leverantörs ansvarsområde ska incidenten transfereras enligt beskrivningen under avsnitt 4.1.3 Bereda. Chef för berörd avdelning bevakar att ärendet löses inom stipulerad tid och eskalerar enligt eskaleringsprocess beskriven i avsnitt 2.5. När leveranstidpunkten inte kommer att hållas informeras alltid CSN:s Leverantörsansvarig via telefon av Leverantörens Service Delivery Manager. Ytterst ansvarig för analys av ärendet är Service Delivery Manager. 4.1.5 Genomföra CSN - Har inget ansvar i detta steg Leverantör - Genomför framtagen åtgärd. 4.1.6 Verifiera CSN - Har inget ansvar i detta steg Leverantör - Verifierar och säkerställer att incidenten är åtgärdad. - Informerar CSN att incidenten är åtgärdad. - Uppdaterar i ärendet med genomförd åtgärd. - Incidentrapport tas alltid fram till CSN. Incidentrapport tas fram för incidenter som på något sätt påverkar CSN:s leverans. Leverantörens Service Delivery Manager (SDM) säkerställer att incidentrapport skapas och att CSN:s Leverantörsansvarig notifieras. Incidentrapporten ska sparas på gemensam lagringsyta enligt avsnitt 12.1. 15

4.1.7 Stänga ärende CSN - Har inget ansvar i detta steg Leverantör - Stänger ärendet. - Initiera ett ärende till problemprocessen för utredning av grundorsak om analysen av incidenten påvisat ett behov av detta. När incidentärende stängs i Leverantörens ärendehanteringssystem går ett automatmail till den som initierat ärendet med information om att incidenten är löst och ärendet stängt. Leverantören ansvar för att ärendet stängs och säkerställer att ett ärende initieras till problemprocessen om analysen av incidenten påvisat ett behov av detta. 4.2 Problem management 4.2.1 Förutsättningar för hantering av problem Problemärenden som Leverantören ansvarar för att lösa skapas endera av CSN eller Leverantören som konsekvens av inträffade incidenter eller för att förebygga incidenter. Gränssnitt mellan CSN och Leverantören för hantering av sådana problem beskrivs nedan. 4.2.2 Registrera ärende Problemärende registreras av CSN eller Leverantör. CSN - Registrera problemärende Leverantör - Ta emot problemärende eller initiera registrering - Godkänna att problemet ska hanteras av Leverantören enligt tjänstekontrakt Från CSN får ett problem initieras till Leverantör av leverantörsansvarig på CSN genom en anmälan till Service Desk via webb 2. Service Desk ansvarar för att ett problemärende registreras i Leverantörens ärendehanteringssystem och att ansvaret för ärendets hantering övergår till berörd grupp hos Leverantören. Leverantörsansvarig på CSN ska även få kvittensmejl på registrerade och stängda ärenden. När problemärende registrerats sker återkoppling från Leverantörs ärendehanteringssystem till initieraren och leverantörsansvarig på CSN med information om ärendet (inklusive referensnummer) som verifiering att Leverantör tagit ansvar för ärendet. 2 Vid inrapportering från CSN till Service Desk ska följande uppgifter anges: XXX (Enligt överenskommelse) Namn (förnamn, efternamn) Buntnamn Filnamn Ev. referens till incidentärende Beskrivning av problemet (så utförlig beskrivning som möjligt) 16

När det finns oklarheter om ett problem ska hanteras enligt tjänstekontrakt kontaktar ärendeägare, t.ex. Service Delivery Manager (SDM), leverantörsansvarig på CSN för att bestämma om Leverantören ska hantera ärendet. Kan inte överenskommelse nås sker eskalering enligt eskaleringsprocess i avsnitt 2.5. Om problemet inte ska hanteras av Leverantören ska Leverantörens ärendeägare få en accept via e-post från CSN:s leverantörsansvarige. Därefter får ärendet stängas i Leverantörens ärendehanteringssystem med hänvisning till att det inte ska hanteras enligt tjänstekontrakt. 4.2.3 Utredning och diagnos Hitta grundorsaken till problemet. CSN - Har inget ansvar i denna aktivitet Leverantör - Genomföra utredning och diagnos - Informera CSN om grundorsaken När grundorsaken till problem initierade av CSN har hittats sker återkoppling från Leverantörens ärendehanteringssystem till initieraren och leverantörsansvarig på CSN med information om grundorsaken. 4.2.4 Ta fram lösning Ta fram en permanent lösning. CSN - Kan i vissa fall behöva lösa problemet Leverantör - Ta fram en permanent lösning av det kända felet 4.2.5 Besluta om lösning Besluta om föreslagen lösning av det kända felet. CSN - Besluta om lösningen ska implementeras i de fall CSN har tagit fram den Leverantör - Besluta om lösningen ska implementeras i de fall Leverantör har tagit fram den 4.2.6 Verifiera implementering Leverantören ansvarar för att verifiera att lösningen fick avsedd effekt. CSN ska godkänna detta. CSN - Godkänna resultatet av lösningen oavsett vilken av parterna som har tagit fram den. Leverantör - Verifiera efter produktionssättning att det kända felet är löst 17

För problemärenden som har initierats av CSN ska Leverantörens ärendeägare kontakta leverantörsansvarig på CSN efter verifiering för att få ett godkännande av att lösningen fick avsedd effekt. Godkännandet inkl. vem som godkänt dokumenteras via webben. 4.2.7 Stänga ärende Ärendet stängs. CSN - Har inget ansvar i denna aktivitet Leverantör - Stänga ärendet När problemärende initierat av CSN stängs i Leverantörs ärendehanteringssystem går ett automatmail till den som initierat ärendet samt leverantörsansvarig med information om att problemet är löst och ärendet stängt. Chef på berörd grupp ansvar för att ärendet stängs. 4.3 Change management Ett change initieras från CSN:s Leverantörsansvarige via Leverantörens webb. Då changet anmälts och registrerats i webben tilldelas ärendet en ärendeägare hos Leverantören för vidare koordinering av changet. Leverantören kvalitetssäkrar Changet och returnerar det till beställaren på CSN om det är ofullständigt eller oklart. Leverantör uppskattar Changet m.a.p. tid och kostnad och meddelar beställaren på CSN. Change beställningen ska/bör innehålla uppgifter om: - CSN:s kundnummer hos Leverantör (nnn) - Produktionssättningsdatum - Datum när testfiler ska finnas framtagna - Filnamn - Forms - Distributionssätt - Simplex/Duplex Produktionssättning sker på begäran av CSN:s Leverantörsansvarige via webb till Leverantörens ärendeägare som bekräftar produktionssättningen via mail till Leverantörsansvarig på CSN. Hanteringen av change avser både akuta och planeringsbara change. Leverantören ansvarar för att uppdatera rutinbeskrivningar när changet påverkar informationen i dessa Leverantörens ärendeägare stänger ärendet. 18

4.4 Service Request 4.4.1 Förutsättningar för hantering av Request De tjänster inom kontraktet som kategoriseras som Request är: - återkommande och har kort utförande tid - utförs på ett kontrollerat sätt med hjälp av checklistor och mallar CSN-unika papper och kuvert. - Varje månad gör Leverantören en lagerinventering som skickas till CSN. Denna inventering gås igenom på det månatliga uppföljningsmötet. - Inköp av CSN-papper och -kuvert görs av Leverantör i samråd med CSN. - Avrop av CSN-papper och -kuvert görs av Leverantör utan samråd med CSN. Alla tjänster som kan beställas från Leverantören är hämtade från tjänsteavtalen och finns samlade i en Bilaga 4.4 1 Tjänstekatalog. 4.4.2 Registrera En beställning registreras och beställs av CSN. CSN - Registrera beställningen. Leverantör - Har inget ansvar i detta steg. En beställning till Leverantör initieras från CSN genom att behörig beställare registrerar en beställning via Leverantörens webb. Behöriga beställare hos CSN är leverantörsansvarig samt dess ersättare. Service Desk ansvarar för att ett requestärende registreras i Leverantörens ärendehanteringssystem och för ärendets fortsatta hantering. 4.4.3 Bereda Leverantören återkopplar till CSN att ärendet är mottaget och kontrollerar beställningen. CSN - Har inget ansvar i detta steg Leverantör - Kontrollerar hanteringen av ärendet enligt Requestkatalog. - Kontrollera om all nödvändig information erhållits. - Återkoppla till beställaren att ärendet mottagits och kan utföras enligt avtalad service nivå. Service Desk kontrollerar mot tjänstekatalogen att beställningen: - är från behörig beställare - är korrekt ifylld 19

Om beställningen inte är från behörig beställare eller på rätt beställningsmall återkopplar Service Desk till beställaren vem som har rätt att beställa tjänsten eller på vilken beställningsmall beställningen ska utföras. Service Desk stänger därefter ärendet. Service Desk kontrollerar därefter att beställningen är komplett ifylld. Om så inte är fallet kontakter Service Desk beställaren, via telefon eller e-post för att få kompletterande uppgifter. Service Desk återkopplar därefter till beställaren via e-post att ärendet är mottaget och när beställningen beräknas vara utförd. 4.4.4 Genomföra Ärendet utförs enligt gällande rutiner för Leverantören. CSN - Har inget ansvar i detta steg. Leverantör - Genomför beställning enligt fastställda rutiner hos Leverantören. Ärendet genomförs enligt gällande rutiner hos Service Desk med hjälp av berörd grupp. 4.4.5 Stänga ärende Leverantören stänger ärendet CSN - Har inget ansvar i detta steg. Leverantör - Återkoppla till CSN att beställningen är utförd. - Ärendet stängs. Service Desk stänger ärendet i Leverantörens ärendehanteringssystem och återkopplar till beställaren via e-post att beställningen är utförd. 4.5 Release Management Leverantör ska till operativ styrgrupp tillhandahålla årsplanen för releaser inkl. servicefönster så fort den är framtagen, men senast under november året innan den gäller. I samarbetet mellan CSN och Leverantör hanteras releaser i changeprocessen. 5 Fakturering Beskrivning av rutiner för fakturering Exempel (enligt överenskommelse): Leverantör fakturerar CSN månadsvis. Med fakturan följer en specifikation med uppgifter om antal och belopp på order och artikelnivå. För CSN:s del innebär order tex en bunt med printfiler som printats och kuverterats. Filer som inte buntas, tex listor och adressuttag, 20

faktureras på egna ordrar. Faktureringen körs normalt den första vardagen månaden efter produktionsmånaden. Månadsbryt på kalendermånad. På Operativ styrgrupp presenterar Leverantör en rapport med summa antal och belopp per artikel fakturerat under månaden. CSN-unikt materiel, tex kuvert med CSN-logga, som Leverantör hanterar faktureras vid leverans till Leverantör. Standardmateriel, tex vitt standardpapper, faktureras vid förbrukning/produktion. Konsulttjänster faktureras löpande efter utfall med referens till beställning. I övrigt hänvisas både till kontraktet. 6 Säkerhet Här beskrivs endast informationssäkerheten kring printat materiel. Alla anställda hos Leverantören signerar en sekretessförbindelse som säkerställer att ingen information om Leverantörens kunder eller innehållet i printat material får yppas för tredje part. Samma sekretessavtal måste också tecknas av utomstående besökare som besöker produktionslokalerna. För övriga säkerhetsfrågor hänvisas till kontraktet. 7 Benchmarking Villkor för den prisjämförelse som regelbundet ska göras under kontraktstiden regleras i kontraktet. Benchmarking sker på begäran av CSN:s kontraktsägare och val av benchmarkingmetod beslutas av CSN:s kontraktsägare i samråd med Leverantörens Kontraktansvarige. 8 Revision I kontraktet beskrivs vad som gäller i fråga om granskning och revision. Sådana aktiviteter initieras av leverantörsansvarig på CSN, som även ansvarar för planering och genomförande i samråd med Leverantörens Service Delivery Manager (SDM). Dokument om genomförd granskning och revision blir tillgängliga genom att sparas på den gemensamma lagringsytan i mappen Revision. 9 Rapportering Rapporter tas fram enligt vad som beskrivs i underlag till resp. forum. 10 Tolkningar och Kontraktsförändringar I kontraktet beskrivs vad som gäller om CSN vill förändra tjänstens karaktär eller omfattning. Som komplement till detta beskrivs nedan hur tolkning och ändringar av kontraktet ska hanteras. 21

10.1 Tolkningar Vid oklarheter i kontraktet som kräver en tolkning, ska detta löpande dokumenteras om möjligt med hjälp av exempel. Alla tolkningar ska beslutas i Taktisk styrgrupp. Alla beslutade tolkningar av kontraktet ska dokumenteras enligt mall 10.1 Tolkningslogg, som lagras på den gemensamma lagringsytan enligt avsnitt 12.1. 10.2 Kontraktsförändringar Ibland uppstår en situation där en tolkning av kontraktet inte är tillräcklig, och bägge parter istället vill göra en förändring av kontraktet. En annan typ av kontraktsförändring är en förändring av innehållet i eller omfattningen av den tjänst som ska levereras. En kontraktsförändring kan initieras av leverantörsansvarig, kontraktsförvaltare och kontraktsägare på CSN samt av Leverantörens kontraktsansvarige och Service Delivery Manager. Vanligtvis tas ett förslag om en förändring av kontraktet fram efter att parterna har diskuterat frågan i olika forum. Förslag på kontraktsförändringar ska innehålla följande: - Titel på kontraktsförändringen - Namn på samt e-mailadress och telefonnummer till den person som föreslår kontraktsförändringen - Referens till kontraktet [namn, datum, paragraf etc.] som man önskar en ändring i - Typ av ändring [förtydligande av kontraktstexten, mindre ändring som t ex formuleringar/stavfel eller ändring av villkor/omfattning] - Beskrivning och motivering av föreslagen kontraktsförändring Kontraktsförändringar beslutas i taktisk styrgrupp. Alla beslutade förändringar i kontraktet ska dokumenteras enligt mall 10.2 Kontraktsförändringslogg, som lagras på den gemensamma lagringsytan enligt avsnitt 12.1. Förändringen ska diarieföras hos CSN. 11 Miljö I kontraktet beskrivs vad som gäller i miljöfrågor. I Leverantörs åtagande ingår att redovisa utfallet i olika miljöfrågor för CSN. Dokument om detta blir tillgängliga för CSN:s miljöansvarige genom att sparas på den gemensamma lagringsytan i mappen Miljö. 12 Verktygsstöd 12.1 Gemensam lagringsyta Projektplatsen, projektet CSN-Leverantör Förvaltning, ska användas som gemensam lagringsyta för dokument som är gemensamma för CSN och Leverantör. Det omfattar alltifrån dokument från olika fora till dokument om enskilda ärenden, som t.ex. incidentrapporter. Syftet är att det ska vara tydligt för bägge parter vilken dokumentation som gäller i frågor om samverkan. Det innebär att e-post ska undvikas för distribution av denna typ av dokumentation. I samband med att en ny version av ett dokument sparas på 22

Projektplatsen ska en sammanfattning av ändringarna beskrivas som kommentarer enligt Projektplatsens funktionalitet. Ansvarig för administration av vilka personer som ska ha tillgång till Projektplatsen är Leverantörens Service Delivery Manager. Följande mappstruktur gäller för Projektplatsen och mappen Utdataproduktion: Leverans Incidentrapporter Filnamn: ÅÅÅÅ-MM-DD <Objekt alt. några ord om vad som felar> Operativ styrgrupp <År> <Mötesdatum> (Dokument med underlag och resultat) Produktion <År> (valfri mappstruktur för övrigt) Taktisk Styrgrupp <År> <Mötesdatum> (Dokument med underlag och resultat) Projekt och uppdrag (allt utöver leverans enligt kontrakt) <År> <Projektnamn> Riktlinjer för samverkan Bilagor Mallar Samverkanshandbok.doc Ansvarig för denna mappstruktur är Leverantörsansvarig på CSN och Leverantörens Service Delivery Manager. 12.2 Webb Leverantören erbjuder sina kunder en Webb. Via Webben kan kunderna lägga ärenden som beställningar, begäran om support eller felanmälan. En av fördelarna med Webben är att kunden själv kan styra över vem hos kunden som har rätt att lägga ärende till Leverantör. Andra fördelar är att all erforderlig basinformation som kundnummer, rutinnamn etc. finns med i ärendet redan från början samt att ärendet snabbare kommer in i Leverantörs ärendehanteringssystem för vidare handläggning och åtgärd. Ytterligare en fördel är att kunderna via Webben enkelt kan följa status på sina ärenden. 23