Applikasjonsforvaltning: support og vedlikehold
Å holde programvare som allerede er i drift i gang, innenfor deres SLA og i deres ticketkø: triage, rettelser ved årsaken, patchversjoner, oppgradering av avhengigheter og plattformer, sikkerhetsrespons og håndtering av hendelser. Andre og tredje linje, av utviklere som også bygger, slik at en tilbakevendende feil blir rettet i stedet for startet på nytt.
Hvorfor dette er et problem for partnere
Support er den delen av en managed service som er lett å selge og vanskelig å bemanne. Den kommer ujevnt, den krever folk som kan lese ukjent kode under tidspress, og i det øyeblikket dere setter de beste utviklerne på den, er de ikke lenger tilgjengelige for arbeidet som lønner seg bedre. Det vanlige svaret er et eget, billigere nivå som lukker saker uten noen gang å rette noe, og kunden merker det innen et kvartal.
Vårt svar er at menneskene på support er utviklere. De kan endre systemet, ikke bare beskrive det, og det er den eneste måten en tilbakevendende hendelse noen gang slutter å komme tilbake.
Det vi tar på oss
Triage og diagnose
Å ta over det første linje ikke kan svare på, gjenskape det og si hva som faktisk er galt i stedet for å lukke saken som ikke reproduserbar.
Rettelser som holder
Feil rettet ved årsaken, med en regresjonstest skrevet mot hele feilklassen og ikke bare den ene saken, slik at den samme hendelsen ikke kommer tilbake neste kvartal.
Utgivelser og patching
Patchversjoner levert gjennom pipelinen deres og endringsprosessen deres, med avhengigheter, rammeverksversjoner og plattformruntimes holdt oppdatert i stedet for å drive inn i en oppgraderingskrise.
Sikkerhetsrespons
En publisert sikkerhetsmelding om noe dere er avhengige av, er en ubetinget grunn til å oppgradere, ikke et punkt i en backlog. Vi følger med, patcher og forteller dere hvor stor eksponeringen var.
Overvåking og hendelser
Å følge med på varslene som allerede finnes, legge til dem som bør finnes, og håndtere hendelser med en skriftlig redegjørelse etterpå om hva som skjedde og hva som hindrer at det skjer igjen.
Små endringer
Den jevne strømmen av små forbedringer som holder en kunde fornøyd og aldri rettferdiggjør et prosjekt: håndtert innenfor samme kapasitet, på samme vilkår.
Deres SLA, ærlig vurdert
Vi publiserer ikke mål for responstid og løsningstid, fordi et tall funnet på før noen har sett systemet deres, er verdiløst for dere og for kunden deres. I stedet leser vi SLA-en dere allerede skylder, forteller hvilke deler vi virkelig kan ta på oss og hvilken dekning det krever, og forplikter oss deretter til det skriftlig.
Det samme gjelder dekning utenfor arbeidstid. Der et oppdrag trenger det og vi har avtalt det på forhånd, bemannes det av folk som er rekruttert eller tildelt for de timene, i stedet for å vekke noen og håpe på det beste. Vi går allerede etter europeisk, australsk og amerikansk Pacific-tid i andre oppdrag, så spørsmålet er hvilket tidsvindu dere trenger, ikke om det er mulig.
Å overta et system vi ikke har bygget
Som er det normale. Ni overtakelser så langt, den eldste skrevet i 2008.
Skrivebeskyttet gjennomgang først
Vi får tilgang til koden, infrastrukturen og tickethistorikken før vi har ansvar for noe av det, og vi ser på det i stedet for å endre det.
En skriftlig liste over risikoer
Hva som er skjørt, hva som mangler patcher, hva som mangler dokumentasjon og hva som vil vekke noen om natten, sortert etter betydning for produksjon. Dere beholder den uansett om vi går videre eller ikke.
Samtalen om dekning
Vi leser SLA-en dere skylder kunden og forteller ærlig hvilke deler vi kan ta på oss, hvilke timer det krever og hva det koster, før noen av partene signerer noe.
Overlevering, så i drift
En definert periode med shadowing hos den som har kunnskapen nå, så overtar vi køen. Hvis ingen lenger har kunnskapen, er det risikogjennomgangen vi starter med i stedet.
Under deres navn, hvis det er avtalen
Support er som regel den mest synlige delen av en managed service, så det er også her white-label betyr mest. Utviklerne våre kan jobbe fra e-postkontoer og kontoer dere utsteder, svare i ticketsystemet deres og skrive hendelsesrapporter dere videresender uendret, mens kunden deres forholder seg til dere hele veien. White-label-utvikling forklarer hvordan det ordnes, og det gjelder support på nøyaktig samme måte.
Hvordan support prises
Per person, per måned, slik at deres egen kostnad er forutsigbar og dere kan prise en supportavtale til kunden mot den. Alle fører timer i vår egen portal, dere ser timene gjennom hele måneden, og de samme tallene danner fakturaen, så det finnes én oversikt begge sider avstemmer mot.
Der support ligger ved siden av ny utvikling, er de to som regel én leveransepod i stedet for to kontrakter, slik at rolige uker på den ene siden betaler for travle uker på den andre.
Spørsmål om supportavtaler
Hva dekker applikasjonsforvaltning?
Å holde programvare som allerede er i produksjon i gang: sortere det som kommer inn i køen, gjenskape og rette feil, svare på tekniske spørsmål som førstelinjen ikke kan svare på, levere oppdateringer, holde avhengigheter og plattformversjoner à jour, følge med på varsler og håndtere hendelser når noe går galt. Dette er arbeid på andre og tredje linje, mens førstelinjen deres blir der den er.
Jobber dere etter vår SLA?
Ja. Vi publiserer ikke mål for responstid og løsningstid, fordi et tall som er funnet på før vi kjenner systemet deres, er verdiløst. Vi leser SLA-en dere allerede har overfor kunden deres, forteller ærlig hvilke deler vi kan ta på oss og hvilken dekning det krever, og forplikter oss deretter skriftlig.
Kan dere tilby støtte utenfor arbeidstid eller vakt?
Ja. Støtte utenfor arbeidstid og vakt avtales på forhånd, skrives inn i støttevilkårene og bemannes av folk hvis arbeidstid samsvarer med den, slik at en hendelse om natten når noen som er på vakt og ikke noen som må vekkes.
Kan dere støtte et system dere ikke har bygget?
Det er det vanlige. Ni overtakelser så langt, den eldste skrevet i 2008. Støtte for et overtatt system begynner med en skrivebeskyttet gjennomgang og en skriftlig liste over risikoer, sortert etter betydning for produksjonen, slik at de første ukene går til å forstå hva dere faktisk er ansvarlige for i stedet for å gjette under press.
Er det de samme folkene som støtter systemet som også endrer det?
Ja, og det er poenget. Utviklerne som tar støtten er utviklere, ikke et eget nivå som bare lukker saker, så en tilbakevendende hendelse kan rettes ved årsaken i stedet for å startes på nytt hver mandag. Der dere har både en byggstrøm og en støttestrøm hos oss, deler de to kodegjennomgang og arkitekturbeslutninger.
Hvordan prises støtten?
Per person, per måned, slik at kostnaden deres er forutsigbar og dere kan prise en støtteavtale til kunden deres ut fra den. Timer loggføres i portalen vår og er synlige for dere gjennom hele måneden, og de samme tallene danner fakturaen, så det finnes én kilde for begge parter.
Har dere systemer som må holdes i gang?
Fortell oss hvilke systemer det gjelder, hva SLA-en deres lover og hvor support gjør vondt i dag. Vi leser det og forteller hvilke deler vi kan ta på oss, også de vi ikke kan.