Applikationsförvaltning och underhåll
Att hålla programvara som redan är i drift fungerande, inom ert SLA och er ärendekö: triage, rättningar vid orsaken, patchreleaser, uppgraderingar av beroenden och plattformar, säkerhetshantering och incidenthantering. Andra och tredje linjen, av utvecklare som också bygger, så att ett återkommande fel rättas i stället för att startas om.
Varför detta är ett partnerproblem
Support är den del av en managerad tjänst som är lätt att sälja och svår att bemanna. Den kommer ojämnt, den kräver personer som kan läsa främmande kod under tidspress, och i samma stund som man sätter sina bästa utvecklare på den slutar de vara tillgängliga för det arbete som betalar bättre. Det vanliga svaret är en separat, billigare nivå som stänger ärenden utan att någonsin rätta något, och kunden märker det inom ett kvartal.
Vårt svar är att personerna på supporten är utvecklare. De kan ändra systemet, inte bara beskriva det, vilket är det enda sättet ett återkommande fel någonsin slutar återkomma.
Vad vi tar på oss
Triage och diagnos
Att ta över det första linjen inte kan svara på, återskapa det och säga vad som faktiskt är fel i stället för att stänga det som icke återskapbart.
Rättningar som håller
Fel som rättas vid orsaken, med ett regressionstest skrivet mot hela felklassen i stället för det enskilda ärendet, så att samma incident inte kommer tillbaka nästa kvartal.
Releaser och patchning
Patchreleaser som levereras genom er pipeline enligt er ändringsprocess, med beroenden, ramverksversioner och plattformsruntimes som hålls aktuella i stället för att glida mot en uppgraderingskris.
Säkerhetshantering
En publicerad säkerhetsvarning i något ni är beroende av är en ovillkorlig anledning att uppgradera, inte en backlogpost. Vi bevakar den, patchar den och talar om hur stor exponeringen var.
Övervakning och incidenter
Att bevaka de larm som redan finns, lägga till dem som bör finnas och hantera incidenter med en skriftlig redogörelse efteråt av vad som hände och vad som hindrar att det upprepas.
Små ändringar
Den jämna strömmen av mindre förbättringar som håller en kund nöjd och aldrig motiverar ett projekt: hanteras inom samma kapacitet, på samma villkor.
Ert SLA, ärligt bedömt
Vi publicerar inga svars- och lösningsmål, eftersom ett tal som hittats på innan någon har sett ert system är värt noll för er och noll för er kund. I stället läser vi det SLA ni redan är skyldiga, talar om vilka delar vi genuint kan bära och vilken täckning det kräver, och förbinder oss sedan till det skriftligen.
Detsamma gäller jour utanför kontorstid. Där ett uppdrag kräver det och vi har kommit överens om det i förväg bemannas det av personer som rekryterats eller tilldelats för de timmarna, i stället för att väcka någon och hoppas. Vi arbetar redan på europeiska, australiska och amerikanska Stillahavstider i andra uppdrag, så frågan är vilket tidsfönster ni behöver, inte om det är möjligt.
Att ta över ett system vi inte byggde
Vilket är det normala fallet. Nio övertaganden hittills, det äldsta skrivet 2008.
Först en skrivskyddad genomgång
Vi får åtkomst till koden, infrastrukturen och ärendehistoriken innan vi ansvarar för något av det, och vi tittar i stället för att ändra.
En skriftlig riskförteckning
Vad som är sårbart, vad som saknar patchar, vad som saknar dokumentation och vad som kommer att väcka någon på natten, ordnat efter påverkan i produktion. Er att behålla oavsett om vi går vidare.
Samtalet om täckning
Vi läser det SLA ni är skyldiga er kund och talar ärligt om vilka delar vi kan bära, vilka timmar det kräver och vad det kostar, innan någon sida skriver under något.
Överlämning, sedan i drift
En definierad skuggningsperiod med den som har kunskapen i dag, sedan tar vi över kön. Om ingen längre har kunskapen är riskgenomgången där vi börjar i stället.
Under ert namn, om det är upplägget
Support är oftast den mest synliga delen av en managerad tjänst, så det är också där white-label spelar störst roll. Våra utvecklare kan arbeta från postlådor och konton ni utfärdar, svara i ert ärendesystem och skriva incidentrapporter som ni vidarebefordrar oförändrade; er kund har kontakt med er hela tiden. White-label-utveckling beskriver hur det ordnas, och det gäller support på exakt samma sätt.
Hur support prissätts
Per person och månad, så att er egen kostnad är förutsägbar och ni kan prissätta ett supportavtal till er kund mot den. Alla loggar tid i vår egen portal, ni ser timmarna under hela månaden, och samma siffror ligger till grund för fakturan, så att det finns en enda journal som båda sidor stämmer av mot.
Där support ligger bredvid ny utveckling är de två oftast en enda delivery pod i stället för två avtal, så att lugna veckor på ena sidan betalar för hektiska veckor på den andra.
Frågor om supportupplägg
Vad omfattar applikationsförvaltning?
Att hålla programvara som redan är i produktion igång: sortera det som kommer in i kön, återskapa och åtgärda fel, besvara de tekniska frågor som första linjen inte kan svara på, leverera korrigeringsreleaser, hålla beroenden och plattformsversioner aktuella, bevaka larm och hantera incidenter när något går sönder. Det är andra- och tredjelinjearbete; er första linje blir kvar där den är.
Arbetar ni enligt vårt SLA?
Ja. Vi publicerar inga mål för svars- och lösningstider, eftersom en siffra som hittas på innan vi känner till ert system är värdelös. Vi läser det SLA ni redan har gentemot er kund, berättar ärligt vilka delar vi kan bära och vilken bemanning det skulle kräva, och förbinder oss sedan skriftligt till det.
Kan ni erbjuda beredskap och support utanför kontorstid?
Ja. Support utanför kontorstid och beredskap avtalas i förväg, skrivs in i supportvillkoren och bemannas av personer vars arbetstider motsvarar det, så en incident på natten når någon som har pass i stället för någon som väckts.
Kan ni ge support för ett system som ni inte har byggt?
Det är det normala fallet. Nio övertaganden hittills, det äldsta skrevs 2008. Support av ett övertaget system börjar med en granskning i skrivskyddat läge och en skriftlig lista över risker ordnad efter påverkan på produktion, så de första veckorna går åt till att förstå vad ni faktiskt ansvarar för i stället för att gissa under press.
Är det samma personer som ger support till systemet som också ändrar det?
Ja, och det är poängen. Ingenjörerna i supporten är ingenjörer, inte en separat nivå som stänger ärenden, så en återkommande incident kan åtgärdas vid orsaken i stället för att startas om varje måndag. Där ni har både ett utvecklingsflöde och ett supportflöde hos oss delar de kodgranskning och arkitekturbeslut.
Hur prissätts supporten?
Per person och månad, så att er egen kostnad är förutsägbar och ni kan prissätta ett supportavtal mot er kund utifrån den. Timmar loggas i vår portal och är synliga för er under hela månaden, och samma siffror ligger till grund för fakturan, så båda sidor har en enda källa.
Har ni system som måste hållas igång?
Berätta vilka systemen är, vad ert SLA lovar och var supporten gör ont i dag. Vi läser det och talar om vilka delar vi kan bära, inklusive de delar vi inte kan.