Transitering och upphandling – del 3

Du är här: / Transitering och upphandling – del 3

Experttips inför transitering och upphandling i det offentliga

Erik Sandell, som har genomfört många transiteringar, delar med sig av sina experttips. Från att undersöka potentiella leverantörer till att utvärdera deras kapacitet.

Transitering har många namn och kan innebära många olika saker. Transitering, migrering, etablering, exit eller helt enkelt flytt av data från punkt a till punkt b så kallad ”lift and shift” från ett datacenter till ett annat eller varför inte sikta mot stjärnorna och kliva in i molntjänster? 

Föregående delar i denna serie om transitering hittar du här:

Del 1:

Inför transitering

Läs del 1 här

Del 2:

Om upphandling

Läs del 2 här

Transiteringsprojekt efter påskrivet avtal

Efter att avtalen äntligen är tecknade så kommer vi till godbitarna med transitering. Data skall ofta flyttas från en leverantör till en annan eller migreras till nyare fräschare plattformar. 

Viktigaste tipset, om det är så att en ny IT-driftpartner vunnit anbudet, är att få den gamla leverantören ofta kallad ”exit-leverantören” att prata ihop sig med den nya leverantören ofta kallad ”boarding-leverantören” om vilka förutsättningar som finns för att göra en lyckad transitering.  

Det är lätt att falla i fällan när man skriver avtalet att den mottagande ”boarding-leverantören” har förutsatt en mängd faktorer för att kunna klara ett tajt införande/etableringsprojekt. Flyttlasset skall gå genom att den nya leverantören får öppna dörrar till den avlämnande leverantörens datacenter. Ofta så vill man ha vad man brukar kalla Layer2-access eller bara L2 vilket skulle göra näten helt transparenta för varandra.  

Men så går det inte till i verkligheten. Det finns ingen leverantör som släpper in en konkurrent att härja fritt i miljöerna som ofta delas med flera kunder och därmed brukar första brasklappen från avtalet falla ut. Nya leverantören förutsätter full tillgång och access till allt data och kringutrustning från den gamla leverantören annars kommer man inte kunna hålla tidsplanen. Dessutom måste man kanske sätta upp vissa tjänster som MECM (tidigare SCCM) eller liknande på nytt eftersom paketering av applikationer eller annat går under IPR som i 99% av fallen faller in.  

Tips:

  • Ta gisslan! Under inventeringsfasen med nuvarande leverantör ställ frågor om relevanta tjänster som används och se till att få det dokumenterat av leverantören om något går under IPR.

  • Se till att det i upphandlingsunderlaget framgår att mottagande part inte kan förutsätta att de får fri tillgång till eventuell exitleverantörs driftmiljöer.

  • Nya leverantören är den drivande parten och det skall framgå i upphandlingsunderlaget att den nya leverantören tar fram transiteringsmetod och skall kunna anpassa sig till exit-leverantörens metoder och möjligheter.

  • Efter avtalet tecknats så bjud in relevanta tekniska resurser från bägge parter till inledande startupmöten med tydlig agenda där teknikerna får förklara vad som är tekniskt möjligt att göra.

Navelsträngen 

Den första och den kanske mest signifikanta delen, i början av transiteringen, är att få till koppling mellan datacentrumen. En svartfiber som oftast kopplar ihop de två leverantörerna fysiskt, en navelsträng. Här brukar nätverksteknikerna brottas med varandra tills de kommer fram till en metod som båda parterna kan enas om. Det kan ta två till tre möten beroende på hur mycket IPR och obstruktion man vill lägga in i det hela. Det tar ofta upp till 4-6 veckor från beställning innan man får leverans beroende på var datacentrumen ligger. Tipset är beställa förbindelsen i samråd och samverkan med leverantörerna så fort tiden för avtalsspärr har gått. Oftast är det kunden som får bära kostnaden för förbindelsen eftersom man inte vet på förhand om eller vilken leverantör det blir och var och hur förbindelsen skall se ut. 

Några ord om IPR 

IPR gör det ofta extra besvärligt för projektledarna i transiteringen. IPR (Intellectual Property Rights), på svenska immateriella rättigheter, är juridiska rättigheter som skyddar skapelser och/eller uppfinningar som är resultatet av intellektuell verksamhet inom industriella, vetenskapliga, litterära eller konstnärliga områden. De vanligaste immateriella rättigheterna omfattar patent, upphovsrätt, varumärken och företagshemligheter.  

Exit-leverantören menar ofta att deras miljö är att betrakta som företagshemlighet och det är ytterst små möjligheter som finns för att få till en effektiv dataflytt. Eftersom det sällan finns klausuler i det befintliga avtalet med exit-leverantören brukar detta behöva stötas och blötas tills man till sist kommer fram till, att man gör som man i princip ville göra i början, fast med smärre förändringar. Att de flesta redan vet att man gör på likartat sätt hos i princip varje leverantör för att leva upp till branschstandard och ISO-krav gör att det kan kännas som en helt onödig och trög process för att få projektet att gå framåt. Men detta kan vara material för en annan artikel. 

Planering av flytt  

Det brukar oftast vara en dålig idé att flytta ekonomi– och HR-system på löningsdag, nära bokslut, slutet och början på månad och så vidare. En tät dialog med förvaltningen gör att data kan flyttas med minsta besvär för verksamheten. Se alltid till att systemförvaltarna eller motsvarande är med i skapandet av förfrågningsunderlaget men också i flyttplaneringen. Saknas någon systemägare så tar man med fördel in någon från verksamheten som är s k ”Poweruser” och kan systemet lite bättre.

Arbetsplats och slutanvändare  

Det finns mer än bara servrar och infrastruktur. Det gäller att man inte glömmer bort den kanske viktigaste komponenten – arbetsplats! Slutanvändare bryr sig sällan om infrastruktur och om servrar står i molntjänst i Holland eller på Gärdet i Stockholm. Det skall bara fungera och sitter man på en äldre laptop/PC som luktar bränt har blåskärm två till fyra gånger om dagen, batteritid på en kvart och fläktar som surrar som ilskna bin hela tiden då längtar man till att få byta till en fräsch ny arbetsstation. Var därför noga med att sätta förväntningarna rätt från början och ta till ordentligt på estimerad leveranstid. Användare som väntat åratal på att få något nytt bättre väntar hellre en stund längre än att bli lovad något som inte kommer på utsatt tid. Ingen blir gladare än användaren när hen får sin efterlängtade PC tidigare än förväntat. Så tipset är prioritera upp arbetsplats och se till att leveranstider är uppsatta mot viten i avtalet. Standardavvikelse på 5-10% kan kanske accepteras men en leverantör som lovat leverans och raljerat om allt står på hyllan ger skam till sig själv, projektet, kunden och de viktigaste det vill säga slutanvändarna och inte minst IT-avdelningen som framstår som inkompetenta och utan kontroll. 

Tester Leveranskontroll, Leveransgodkännande, överlämning till förvaltning 

I transiteringen genomförs löpande tester vid de tidpunkter och i den omfattning som ofta anges i separata bilagor i transiteringen av tjänsterna, särskilt om man har flera upphandlingsområden.  

En del kunder väljer att ta in en testledare och det kan vara bra om man har flera viktiga verksamhetsnära system, men en testare värd sitt salt behöver god tid på sig att sätta sig in i systemen och hur de skall användas för att kunna göra fullgoda tester med protokoll. Så räkna med att lägga på tid för testledaren om ni anser att ni behöver en. I de allra flesta fall så har systemförvaltarna ganska så bra koll eftersom deras system ofta blivit uppgraderat i omgångar vilket gör att man kan använda gamla testprotokoll. 

Vad gäller acceptanstester brukar de avtalas en tid från tio upp till trettio sammanhängande kalenderdagar beroende på vilken tjänst som avses. Tänk på att flytt av servrar och system kan ha en avtalad acceptanstestperiod av tio dagar men det är som regel oftast för sent att testa efter att produktionsdata börjat gå in i det flyttade systemen.  

Som exempel så flyttas system X till nya leverantören. System X testas av systemförvaltare och tekniker och allt verkar som det skall. I detta läge fattar man ett GO/NOGO-beslut. Om man säger GO och godkänner systemflytten så går systemet praktiskt i produktion och överlämnas till förvaltningen och den nya leverantören tar över ansvaret av driften. Detta även om det är en 10 dagars acceptanstestperiod. Det är därför man flyttar test-system först för att se hur de beter sig, sedan system som används mer sällan och till slut de kritiska produktionsmiljöerna.  

Acceptanstestförfarandet är brukligt att kunden skriftligen skall godkänna leverans av tjänsterna efter det att acceptanstest slutförts med tillfredsställande resultat och det görs i princip i samband med GO/NOGO-mötet men formellt efter exempelvis 10 dagars acceptanstest. 

Tips till avtalet:

  • I avtalet så skall man ha en avtalad leveransdag för tjänsterna. Exempelvis leveransdag för flytt av servrar skall ske inom X månader i kalenderdagar räknat från avtalsdagen. Min erfarenhet säger att upp till 100 servrar ca 3 mån transiteringstid, 500 servrar ca 7 månader och 1000 servrar så åtminstone ett år. 30% av tiden brukar gå åt till planering.

  • Effektiv leveransdag finns många gånger inte med i avtalet. Se till att begreppet finns med. Man skjuter ofta på avtalad leveransdag och drar ned på acceptanstestperioden. Undvik det så mycket det går.

  • Om effektiv leveransdag är senare än avtalad leverans är leveransen att betrakta som försenad och är det leverantörens fel att dröjsmål uppstått så lägg ett vite i avtalet.

  • Det uppstår alltid förseningar i transiteringsprojekt och i 90% av fallen är det för att exit-leverantören inte har kunnat allokera resurser i tid eftersom det är mycket svårt att göra en prognos på när man behöver vilken resurs från exitleverantören när.

  • Ersättning för transiteringsprojektet faktureras när effektiv leveransdag har uppkommit.

Begrepp i avtalet

Avtalsdagen
Avtalsdagen avser den dag då båda parter blir bundna avtalet d v s bägge parter signerat avtalet.

Avtalad leveransdag
Den dag då lösningen ska vara driftsatt och ha erhållit leveransgodkännande.

Effektiv leveransdag
Dagen för kundens leveransgodkännade.
Avtalstid – den tid under vilken avtalet är i kraft.

Erik SandellErik Sandell

IT-konsult med över 25 års erfarenhet varav de sju sista har varit inriktat på upphandling och transitering. Kunderna har skiftat med allt från Regeringskansliet, Göteborgs Energi, Almi, Stockholms stad till Agria djurförsäkringar och allt däremellan. ”Varje gång jag färdigställt en transitering så lovade jag mig själv att inte ta, vad jag då tyckte vara, nya ”kamikazeuppdrag””. Men efter fem sex år så blev det i stället en adrenalinkick att se data röra på sig, från ett datacenter till ett annat, och orkestrera en full transitering.

Föregående delar i denna serie om transitering hittar du här:

Del 1:

Inför transitering

Läs del 1 här

Del 2:

Om upphandling

Läs del 2 här

Föregående delar i denna serie om transitering hittar du här: