Processmanual för applikationsförvaltning

Processmanual för applikationsförvaltning

Innehåll PROCESSMANUAL FÖR APPLIKATIONSFÖRVALTNING 1. Samverkansformer... 3 1.1 Strategiskt forum... 3 1.1.1 Arbetsformer... 3 1.1.2 Förslag till agenda... 3 1.2 Förvaltningsforum... 3 1.2.1 Arbetsformer... 3 1.2.2 Förslag till agenda... 4 1.3 Applikationsforum... 4 1.3.1 Arbetsformer... 4 1.3.2 Förslag till agenda... 4 1.4 Samverkan med applikationsleverantören... 4 1.4.1 Arbetsformer... 4 1.4.2 Ärendemottagning... 5 1.4.3 Servicetid... 5 2. Samverkansprocesser Applikationsförvaltning... 6 2.1 Tjänsteförfrågan (service request)... 6 2.1.1 Processbeskrivning för tjänsteförfrågan... 6 2.2 Incidenthantering... 6 2.2.1 Klassificering av incidenter... 6 2.2.2 Processbeskrivning för incidenthantering... 7 2.3 Problemhantering... 8 2.3.1 Klassificering av problem... 8 2.3.2 Processbeskrivning för problemhantering... 8 2.4 Ändringshantering... 10 2.4.1 Klassificering av ändringar... 10 2.4.2 Processbeskrivning för ändringshantering... 11 2.4.3 Ändringsråd... 11 2.4.4 Ändringsstyrgrupp... 12 2.4.5 Service råd... 12 2.5 Test och godkännande... 12 2.5.1 Processbeskrivning för testprocess... 13 3. Samverkansprocesser Applikationsdrift... 14 3.1 Releasehantering... 14 Sid 1/19

3.1.1 Processbeskrivning för releasehantering... 14 3.2 Driftsättning... 15 3.2.1 Processbeskrivning för driftsättning... 15 3.3 Övervakning... 15 3.3.1 Processbeskrivning för övervakning... 16 4. Samverkansprocesser Applikationsutveckling... 16 4.1 Applikationsutveckling... 16 4.1.1 Processbeskrivning för applikationsutveckling... 17 4.2 Applikationsövertagande... 18 4.2.1 Processbeskrivning för applikationsövertagande... 18 Revisionshistorik Version* Författare Kommentar 1.0 Styrgrupp för upphandling av applikationsleverantörer 2.0 Komplettering av samverkansprocess för tjänsteförfrågan Godkännande av Inera Godkännande av Inera *Revidering av processmanualen för applikationsförvaltning sker av Inera i periodvis uppföljning och anpassning av ingående samverkansprocesser. Aktuell version av processmanualen ligger till grund för avrop av applikationsförvaltning för Sid 2/19

1. SAMVERKANSFORMER I syfte att uppnå ett för alla parter framgångsrikt resultat funktionellt, tekniskt och ekonomiskt krävs att Ineras och alla parters resurser används effektivt. Förutsättningen för att uppnå detta är en väl utvecklad samverkan mellan parterna där parternas olika uppgifter är definierade. Samverkansformerna baseras på följande forum. 1.1 Strategiskt forum 1.1.1 Arbetsformer I Strategisk forum hanteras det övergripande samarbetet mellan parterna. Dessa möten äger rum 1-3 gånger per år. Här ska applikationsleverantören bl.a. föreslå förbättringar och informera Inera om den allmänna kunskaps- och teknikutvecklingen inom Tjänsteobjektet. Inera avser att informera applikationsleverantören om bl.a. förändringar i verksamhetens behov och framtida planer avseende berörda Tjänsteobjekt. Inera är sammankallande och mötet protokollförs av applikationsleverantören 1.1.2 Förslag till agenda 1. Samarbete applikationsförvaltning Inera - applikationsdrift 2. Förändring, förbättring och tillägg i Tjänsteobjektet 3. Planerad utveckling kommande period 1.2 Förvaltningsforum 1.2.1 Arbetsformer I Förvaltningsforum avhandlas frågor som rör applikationsutvecklingen av Tjänsteobjektet. Dessa möten äger rum 1 gång per månad. I Förvaltningsforum fastställs också gällande standarder avseende applikationsförvaltning och fattas beslut om förändringar i avropat Tjänsteobjekt såsom uppgraderingar och produktval. I Förvaltningsforum medverkar Inera med tjänsteansvarig, applikationsleverantören med förvaltningsansvarig samt vid behov specialister. Inera är sammankallande och mötet protokollförs av applikationsleverantör. Sid 3/19

1.2.2 Förslag till agenda 1. Månads rapportering 2. Servicenivåer 3. Betalningar 4. Faktureringar 5. Måluppfyllnad 6. Genomförda aktiviteter 7. Planerade aktiviteter 1.3 Applikationsforum 1.3.1 Arbetsformer I Applikationsforum genomförs uppföljning och avstämning mot pågående åtaganden 1 till 4 gånger per månad mellan applikationsleverantören, Inera och andra intressenter enligt en i förväg överenskommen dagordning. Inera är sammankallande och möten protokollförs av applikationsleverantören. 1.3.2 Förslag till agenda 1. Avrapportering av tjänsteförfrågan (service request) och incidenter 2. Uppföljning av utlovad leverans 3. Planerade förändringar i leveransen 4. Nästa periods leverans 1.4 Samverkan med applikationsleverantören 1.4.1 Arbetsformer I det dagliga arbetet med applikationsleverantören utgör deras servicedesk tillsammans med Ineras Nationella kundservice och driftleverantörens servicedesk en viktig länk i den totala supportkedjan för Tjänsteobjektet i syfte att skapa spårbarhet avseende ärendehanteringen. Inera svarar för 1:a linjens support och applikationsleverantören 2:a och 3:e linjens support. Genom servicedesk bistår applikationsleverantören Inera med support som omfattar frågor om exempelvis installation, funktionalitet och användning av tjänsteobjektet samt däri ingående komponenter. Sid 4/19

Servicedeskfunktion tar emot via telefon och e-post, registrerar, klassificerar och behandlar inkomna ärenden. Ärendehanteringen sker i Ineras ärendehanteringssystem för att säkerställa samordning i ärendehanteringen. Servicedesk omfattar, men begränsas inte, till följande delar: Tjänsteförfrågan Hantering av incidenter och problem Applikationsleverantören bemannar sin servicedesk med resurser som har erforderlig kompetens för uppgiften och svarar upp mot krav på spårbarhet i arbetet med inkomna ärenden. Applikationsleverantörens servicedesk har en teknisk kontaktperson med kontaktansvar med övriga delar i supportkedjan och Ineras förvaltningsorganisation. 1.4.2 Ärendemottagning Om applikationsleverantören anser att tilldelat ärende inte är applikationsleverantörens ansvar, ska detta rapporteras till Ineras Nationella kundservice inom gällande Servicetid tillsammans med en tydlig motivering. För det fall att så inte sker ska applikationsleverantören anses vara ansvarig för att hantera ärendet. Telefonsamtal anses ha nått applikationsleverantören när ärendet nått applikationsleverantörens växel. 1.4.3 Servicetid För samtliga tjänsteobjekt ska applikationsleverantören vara tillgänglig under vardagar 08.00 17.00. Övrig tid tas ärenden emot via epost och webb. Servicetid och servicenivåer för Tjänsteobjektet fastställs i Servicenivåer för Tjänsteobjektet. Sid 5/19

2. SAMVERKANSPROCESSER APPLIKATIONSFÖRVALTNING 2.1 Tjänsteförfrågan (service request) En tjänsteförfrågan (service request) är en begäran från en användare om information eller råd, eller för en standardförändring eller att ge tillgång till ett Tjänsteobjekt. Till exempel för att återställa ett lösenord, eller att ge support till en ny användare. 2.1.1 Processbeskrivning för tjänsteförfrågan Processflöde för tjänsteförfrågan genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: 1. Nationell kundservice tar emot och registrerar tjänsteförfrågan Inera Applikationsförvaltning Applikationsdrift K H K 2. Hantera tjänsteförfrågan U H U 3. Genomföra lösning eller initiera ändringsbegäran U H U 4. Verifiera om tjänsteförfrågan har utförts H 5. Stänga ärende för tjänsteförfrågan I H I 2.2 Incidenthantering H: Huvudansvarig - Den Part som innehar det operativa ansvaret för genomförandet En incident är en händelse som hindrar användaren i sitt normala arbete. Det kan t.ex. vara ett fel som härleds till en applikation eller ett systemsamband, en driftstörning eller ett fel i en tredjepartsprodukt. Syftet med processen Incidenthantering är att åter göra Tjänsteobjektet tillgängligt så snabbt som möjligt även om det är med hjälp av en tillfällig lösning. 2.2.1 Klassificering av incidenter Incidenter klassificeras enligt nedanstående modell: Kategori Prio 1 Kritisk Påverkan Allvarliga incidenter som har stor verksamhetskritisk Sid 6/19

Kategori Prio 2 - Hög/Allvarlig Prio 3 - Medel Prio 4 - Låg Påverkan påverkan och där Tjänsteobjektet inte kan nyttjas alls, alternativt endast nyttjas med för verksamheten oacceptabel prestanda. Allvarliga incidenter med viss verksamhetskritisk påverkan. Incidenter med liten verksamhetspåverkan och där verksamheten kan fortgå som vanligt. Påverkar en eller ett fåtal användare. Mindre avvikelser eller skönhetsfel utan direkt verksamhetspåverkan, låg grad av fel som endast kräver aktivering av problemsökning efter överenskommelse. 2.2.2 Processbeskrivning för incidenthantering Processflöde för incidenthantering genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: 6. Nationell kundservice registrerar och prioriterar incident Inera Applikationsförvaltning Applikationsdrift K H K 7. Verifiera prio och klassificera incident. U H U 8. Hantera incidenten U H U 9. Felsöka och analysera incident U H U 10. Besluta om lösning ska genomföras I H I 11. Genomföra lösning eller initiera problemhantering K H U 12. Verifiera om incidenten är löst I H I 13. Följa upp och analysera I H I 14. Stänga incidentärende I H H: Huvudansvarig - Den Part som innehar det operativa ansvaret för genomförandet Sid 7/19

2.3 Problemhantering Problem är orsaken till en eller flera incidenter. Problemhantering syftar till att minimera omfattningen av antalet incidenter genom att hitta och åtgärda grundorsaken till att de uppstår. Fokus ligger på att skapa en permanent lösning på ett problem. I problemhantering ingår att åtgärda upphovet till återkommande incidenter. Applikationsleverantören utför arbete med att hitta orsaken till återkommande incidenter och ta fram ett permanent åtgärdsförslag för att korrigera dessa. När applikationsleverantören identifierat källan till en återkommande incident görs en djupare analys och beslut om åtgärdsförslag fattas. I åtgärdsförslaget ingår en uppskattning över tidsåtgången för genomförandet och eventuell påverkan på ingående applikationer. 2.3.1 Klassificering av problem Prioritering sker enligt nedanstående modell och harmonierar med incidentklassificering: Kategori Påverkan 1. Kritisk Mycket allvarlig nedgång av systemfunktionalitet, saknade funktioner eller andra komponenter i leveransen jämfört med vad som överenskommits i specifikationer och avtal. Tjänsteobjektet kan inte användas. 2. Hög Markant degradering av funktionalitet och/eller prestanda i hela eller delar av Tjänsteobjektet jämfört med vad som överenskommits i specifikationer och avtal. Tjänsteobjektet kan användas med hjälp av workarounds eller under vissa begränsningar. 3. Medium Mindre degradering eller begränsning av funktionalitet och/eller prestanda i hela eller delar av Tjänsteobjektet jämfört med vad som överenskommits i specifikationer och avtal. Mindre fel som ej kräver omedelbart ingrepp, d.v.s. Tjänsteobjektet fungerar tillfredsställande trots felet. Tjänsteobjektet kan användas. 4. Låg Fel som inte påverkar Tjänsteobjektets prestanda, stabilitet, funktionalitet eller orsakar missförstånd. Exempel kan vara felstavningar, mindre fel i användargränssnitt etc. 2.3.2 Processbeskrivning för problemhantering Processflöde för problemhantering genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: Sid 8/19

Applikationsförvaltning Inera Applikationsdrift 1. Ta emot ärende från incidenthantering K H K 2. Kontrollera om fel i Tjänsteobjektet är känt sedan tidigare U H K 3. Klassificera problem och analysera orsaker U H K 4. Design av lösning på problemet U H K 5. Besluta om åtgärd med eventuell omprioritering och skapa ändringsbegäran K H K 6. Skicka ändringsbegäran K H K 7. Rapportera enligt överenskomna rutiner U H I 8. Stäng problemärendet I H I H: Huvudansvarig - Den Part som innehar det operativa ansvaret för genomförandet Sid 9/19

2.4 Ändringshantering En ändring är ett tillägg, en modifiering eller borttagande av något som kan påverka applikationen. Det kan t.ex. vara en lösning av ett problem, en uppgradering eller driftsättning av ett nytt Tjänsteobjekt. Ändringshantering säkerställer att standardiserade metoder och verktyg används för hantering av allt förändringsarbete. Processen startar med en ändringsbegäran. 2.4.1 Klassificering av ändringar Ändringar klassificeras enligt nedanstående modell: Kategori C1 C2 C3 C4 C5 Påverkan Akut ändring som påverkar mer än en av Ineras tjänster Här gäller samma villkor som gäller för C2-ändringar, med den skillnaden att här berörs mer än en tjänst. Akut ändring som påverkar en av Ineras tjänster I vissa fall måste avsteg från normala rutiner göras i syfte att vinna tid och fokusera på situationen. Behov av akuta ändringar är en sådan situation. Andelen akuta ändringar bör hållas så lågt som möjligt. Ändringar som påverkar mer än en av Ineras tjänster När ändringen är kategoriserad som normaländring samt påverkar flera tjänster så behandlas ändringen via Driftcontroller och tas upp i Ineras centrala Ändringsråd, CAB. Driftsättning av nya system räknas som C3-ändring. Ändringar som påverkar en av Ineras tjänster När ändringen är kategoriserad som en normaländring som endast påverkar en tjänst behandlas ändringen enligt ändringsprocessen samt inom respektive tjänst och ansvaras av tjänsteansvarig eller av denne utsedda person(er). Ändringar som kategoriseras som standardändring En standardändring är en i förväg godkänd ändring. Standardändringen är väl känd, har relativt låg risk och har en tillhörande rutin. En standardändring innebär att en ändringsbegäran av rutinkaraktär kan utföras. Sid 10/19

2.4.2 Processbeskrivning för ändringshantering Processflöde för ändringshantering genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: 1. Ta emot och skicka ändringsbegäran för beredning Inera Applikationsförvaltning Applikationsdrift I H K 2. Besvara ändringsbegäran U H K 3. Skicka underlag till CAB för beslut I H I 4. Besluta om ändring ska genomföras I H 5. Utforma ändringsplan U I K 6. Tillverka och testa ändring U H I 7. Acceptanstesta I H I 8. Ta fram underlag för releasehantering U H I 9. Beställ uppdatering och driftsättning I H I 10. Skicka underlag till CCB för beslut I H I 11. Driftsätt ändring I H U 12. Uppföljning av ändring U H I 2.4.3 Ändringsråd H: Huvudansvarig - Den Part som innehar det operativa ansvaret för genomförandet Ineras ändringsråd ( CAB ) har till uppgift att granska tjänsteövergripande systemändringar för de kommande tolv (12) månaderna och granska ändringsbegäran inför driftsättningsbeslut hos ändringsstyrgruppen enligt nedan. Lokalt ändringsråd L- CAB bedömer och godkänner inkomna ändringsbegäran ( RFC ) när ändringen bedöms vara normal samt tjänsteintern dvs. C4. Ett L-CAB etableras med en delegering från Ineras Ändringsansvarig. Ordförande för CAB har mandat att besluta att gå vidare till nästa steg, alternativt avslag, av tjänsteövergripande systemändringar. Sid 11/19

2.4.4 Ändringsstyrgrupp Ineras ändringsstyrgrupp ( CCB ) har till uppgift att besluta om driftsättning av nya releaser. Lokal ändringsstyrgrupp L-CCB hanterar vissa tjänstespecifika ändringsbegäran, som är kompletterad enligt beslut på ett lokalt ändringsråd, och beslutar om driftsättning alternativt avslag av driftsättning. Ordförande för Ineras ändringsstyrgrupp ( CCB ) beslutar om ändringsprocessen och driftsättning alternativt avslag av driftsättning av release utifrån ändringsbegäran som beslutats av CAB om att gå vidare med ändring. 2.4.5 Service råd Ineras service råd ( SRB ) har till uppgift att löpande följa upp IT-relaterade händelser. SRB har veckovisa möten som hanterar uppföljning av leverans och förändringar samt avrapportering av incidenter av kategori 1 och 2. 2.5 Test och godkännande Applikationsleverantören ansvarar för att ha verifierat den egna leveransen med ett komplett och godkänt systemtest vilket inkluderar enhetstester, integrationstest, systemintegrationstest samt regressionstest. Inera kan dock vid särskilda tillfällen begära att specifika tester utförs av applikationsleverantören. Applikationsleverantörens tester genomförs i tid enligt vad som avtalats med Inera och i god tid innan Inera genomför acceptanstest. Applikationsleverantören dokumenterar testerna i en testrapport. Vid begäran redogör applikationsleverantören för testfall och utfall av test för Inera. Syftet med applikationsleverantörens tester är att kvalitetssäkra att den egna leveransen uppfyller kraven vad gäller säkerhet, juridik, funktion, informationsinnehåll och teknik samt att tidigare levererad funktionalitet bibehållits. Test Enhetstest Integrationstest Systemtest Regressionstest Beskrivning Funktionella och tekniska krav testas på lägsta nivå. Test av integration av de olika modulerna i systemet samt test av förändringar inom en release för att säkerställa att förändringen inte har negativ påverkan på existerande funktionalitet. Kompletta flödestester av hel leverans av systemet. Utförs av applikationsleverantören som en del av systemtest och integrationstest för att säkerställa att förändringen inte har negativ påverkan på existerande funktionalitet. Sid 12/19

Test Systemintegrationstest Acceptanstest Prestandatest Kontinuitetstest Beskrivning Kompletta flödestester av hel leverans av systemet inklusive integration med omkringliggande system samt regressionstest. Utförs av Inera för acceptansgodkännande. Endast vid behov och särskild beställning av Inera. Endast vid behov och särskild beställning av Inera. 2.5.1 Processbeskrivning för testprocess Processflöde för test genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: 1. Fastställ övergripande testplan och testprocess. 2. Genomför enhetstest, integrationstest flödestest och regressionstest Inera Applikationsförvaltning Applikationsdrift U H I U H K 3. Granska och utvärdera testfall. I H I 4. Initiera kompletterande tester i nationella miljöer 5. Acceptanstest. Inera godkänner leveransen om systemintegrationstest mot alla relevanta integrerade tjänster ha genomförts och godkänts. U H K I H I H: Huvudansvarig - Den Part som innehar det operativa ansvaret för genomförandet Sid 13/19

3. SAMVERKANSPROCESSER APPLIKATIONSDRIFT 3.1 Releasehantering Releasehantering är den process som innefattar planering, schemaläggning och kontroll av att bygga, testa och driftsätta releaser, och för att leverera ny funktionalitet. En release omfattar ett leveranspaket och innehåller inte bara källkoden utan även till exempel uppdaterad dokumentation och installationspaket. Arbetet görs i samverkan med driftleverantör. En viktig aktivitet är att tillgodose olika intressenters informationsbehov, t.ex. förvaltare av integrerade system, service desks, andra driftleverantörer och övriga grupper av användare. 3.1.1 Processbeskrivning för releasehantering Processflöde för releasehantering genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: Applikationsförvaltning Inera Applikationsdrift 1. Prognos applikationsutveckling K H K 2. Övergripande releasesamordning, innehåll och plan. 3. Fastställa releasens innehåll samt tidpunkt, per objekt. 4. Informera intressenter om kommande ändringar. 5. Detaljplanering och koordinering av release. K H K U H K H U H U 6. Godkänn release för driftsättning. I H I H: Huvudansvarig - Den Part som innehar det operativa ansvaret för genomförandet Sid 14/19

3.2 Driftsättning Tillsammans med applikationsdrift ansvarar Inera för driften av Tjänsteobjekten. Förutom produktionsmiljön finns även en miljö som används för att kvalitetssäkra leveransen innan den driftsätts i produktionsmiljön. Applikationsleverantören ska enligt nedanstående processbeskrivning medverka och samarbeta tillsammans med Inera och Ineras driftleverantör. 3.2.1 Processbeskrivning för driftsättning Processflöde för driftsättning genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: 1. Ta fram installationspaket (script, dokumentation, källkod, installationsdokumentation etc.) Inera Applikationsförvaltning Applikationsdrift U H K 2. Verifiering av installation i QA-miljö K H U 3. Planera och installera applikationsuppgraderingar efter installationsanvisningar K H U 4. Ta fram driftsdokumentation K I H 5. Installation K H U 6. Produktionssättning och optimering K I H 3.3 Övervakning H: Huvudansvarig - Den Part som innehar det överordnade operativa ansvaret för genomförandet Övervakning innefattar alla handgrepp avseende ingående programvaror i respektive Tjänsteobjekt för att hålla dessa i drift och tillgängliga i enlighet med avtalad drifttid och tillgänglighet samt kunna presentera status i realtid för Tjänsteobjektet. Övervakning sker i driftplattform, som tillhandahålls inom ramen för drifttjänsten. Sid 15/19

3.3.1 Processbeskrivning för övervakning Processflöde för övervakning genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: 1. Tillhandahålla och säkerställa mätpunkter för övervakning 2. Övervakning av körningar utifrån för applikationens fastställda rutiner 3. Övervakning av integrationer utifrån för applikationens fastställda rutiner 4. Övervakning av applikation med hjälp av övervakningsverktyg utifrån fastställda mätpunkter Inera Applikationsförvaltning Applikationsdrift U H K K H U K H U I H U 5. Uppdatera driftsdokumentation K H U H: Huvudansvarig - Den Part som innehar det överordnade operativa ansvaret för genomförandet 4. SAMVERKANSPROCESSER APPLIKATIONSUTVECKLING 4.1 Applikationsutveckling Inom ramen för applikationsutvecklingen ska applikationsleverantören utföra löpande vidareutvecklingsaktiviteter och därigenom utveckla eller förbättra funktionalitet i Tjänsteobjektet. Vidareutveckling omfattar typiskt design, programmering, testning, och paketering av ny mjukvara. Applikationsleverantören ska leverera överenskommet resultat. Löpande vidareutvecklingsaktiviteter kan proaktivt initieras av applikationsleverantören men ska alltid beslutas av Inera. Sid 16/19

4.1.1 Processbeskrivning för applikationsutveckling Processflöde för applikationsutveckling genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: Applikationsförvaltnindrift Inera Applikations- 1. Initiering av applikationsutveckling I H I 2. Framtagning av funktionella och ickefunktionella krav 3. Analys av funktionella och ickefunktionella krav I H I H I K 4. Utforma arkitekturbeskrivning H I K 5. Granskning och godkännande av utvecklingsförslag 6. Upprätta projektplan, resursallokering och utvecklingsmodell I H I U H K 7. Beställ applikationsutveckling I H I 8. Programmering, test och paketering av mjukvara 9. Acceptanstest och godkännande för driftsättning 10. Uppdatering av systemdokumentation, installationsanvisningar, releasenotes och installationsscript H I K I H I H K K 11. Uppdatera driftsdokumentation K I H 12. Implementering och driftsättning K H U H: Huvudansvarig - Den Part som innehar det överordnade operativa ansvaret för genomförandet Sid 17/19

4.2 Applikationsövertagande Applikationsövertagande från annan leverantör eller från fristående utvecklingsprojekt ska ske med så liten störning som möjligt för Inera. Applikationsövertagande omfattar all information, programvara och utrustning som använts vid applikationsutvecklingen till Inera. Initiering av applikationsövertagande sker efter överenskommelse med befintlig leverantör om applikationsöverlämnande. Applikationsövertagande innebär att applikationsleverantören: Tar emot information om installation samt uppgifter om utrustningar, versioner och releaser och dokumentation. Tillsätter ytterligare resurser om detta krävs vid applikationsövertagande från leverantör. Utan tidsfördröjning underrätta Inera om tillkommande information som påverkar övertagandet. 4.2.1 Processbeskrivning för applikationsövertagande Processflöde för applikationsövertagande genomförs med samverkan mellan Inera, applikationsförvaltning och applikationsdrift enligt följande processbeskrivning: Ny Applikationsförvaltninförvaltning Inera Ursprungs- 1. Initiering av applikationsövertagande I H I 2. Upprätta projektplan, resursallokering och kunskapsinventering U H K 3. Beställ applikationsövertagande K H I 4. Kontroll av Tjänsteobjekt (kod, dokumentation m.m.) 5. Acceptans och godkännande för övertagande U H K U H I H: Huvudansvarig - Den Part som innehar det överordnade operativa ansvaret för genomförandet Sid 18/19