Artikel top billede

Tre gode råd: Få styr på de små applikationer - som nu er blevet forretningskritiske

Klumme: Mange virksomheder har små applikationer, som med tiden er blevet forretningskritiske. Men hvordan håndterer man drift og vedligehold af disse applikationer, så man ikke sætter noget over styr?

De fleste virksomheder har på et tidspunkt fået udviklet en lille simpel applikation, der skulle håndtere et konkret problem udstukket fra forretningen.

Løsningen blev kodet, det gik godt, og som tiden er gået, er der blevet flere opgaver oven i applikationen. Løsningen er ikke længere en simpel lille løsning, men et kritisk element for forretningen.

Sådanne løsninger kan der være en hel del af - og på den måde står man "pludselig" med mange kritiske løsninger.

Hvordan håndterer du drift og vedligehold af disse applikationer? Og hvordan gør du det, samtidig med at du ikke sætter noget over styr for forretningen?

Det får du et par bud på her.

Problemet går ikke væk

Forløbet med, at hurtigt skiftende krav fra forretningen løses efterhånden som de fremsættes, kan de fleste nok genkende.

Det er ikke noget, der bare går væk, og det skal det nødvendigvis heller ikke. Som udgangspunkt bliver et problem jo løst, og der er lavet en løsning, der understøtter forretningen.

Men forretningens krav ændrer sig hurtigt. Derfor skal change requests løses hurtigt.

Har du de nødvendige kompetencer i huset? Det kræver en stor stab at leve op til kravene om kompetence og serviceniveau in-house. Og en stor stab rimer ikke på disse "mindre løsninger", hvor det kan være en udfordring at nå kritisk masse på den givne teknologi.

Så på et tidspunkt skal du træffe et valg om den videre strategi.

Hvordan skal udfordringen gribes an?

Lad os forestille os, at det handler om en applikation, som salgsteamet har benyttet igennem længere tid, er glade for og har opnået gode resultater med.

Som jeg ser det, er der i virkeligheden kun tre alternativer at vælge imellem:

  • Gør ingenting: En aktiv beslutning om "ingenting at gøre" kan sagtens være den rigtige. Det vil betyde, at du benytter de samme ressourcer og det samme supportberedskab, som i dag. Men selvfølgelig er der både fordele og ulemper. For eksempel risikerer IT/Udviklingsafdelingen at lide imagetab ved funktionsstop. "Det var jo deres valg".
  • Genimplementere løsningen: Teknisk vil det være muligt at tilpasse standardsystemet til applikationen.
  • Etablér et Application Management setup (AMS): Det tredje alternativ er at etablere det setup, som applikationen har behov for, for at leve op til de krav forretningen stiller. Med andre ord, på en sådan måde, at der er udviklingsressourcer, og at svartider, båndbredde og kompetencer opretholdes i nødvendig grad. Det vil i de fleste tilfælde kræve et samarbejde med en ekstern partner.

Hvordan beslutter du den rigtige løsning?

Hvor gerne jeg end ville pege på en patentløsning, er der ingen. Der er fordele og ulemper ved alle tre tilgange, og du er nødt til at bruge lidt tid og kræfter på at finde ud af, hvilken vej der er bedst i lige netop din situation.

Et godt råd er altid at starte med at sætte tal på.

Her er derfor tre hovedområder, du som minimum skal gennemgå for at skaffe et solidt beslutningsgrundlag.

1. Hvor meget værdi skaber applikationerne for forretningen?

Hvad sker der hvis applikationen ikke kan bruges i 1 time, 1 dag, 1 uge - 2 måneder?
Få forretningen til at sætte tal på. Er det ikke muligt for forretningen at komme med disse tal, så forsøg selv at estimere det og præsenter resultatet for forretningen for at få en respons.

2. Hvad er omkostningen i dag?

Hvor mange timer har I brugt på vedligehold og udvikling de sidste par år?
Kan du se nogle omkostninger i fremtiden - de næste 1-3 år, opgraderingskrav, funktionalitetskrav etc?

3. Hvilken service har du i dag?

Hvis der forekommer en kritisk fejl, hvor hurtigt kan du så få den rettet?
Har du nogen, der proaktivt overvåger, om din løsning risikerer versions-udfordringer i den kommende tid?

Hvad er den rigtige løsning?

Når du har tallene kan du foretage en (relativ) simpel cost/benefit-beregning af de tre alternativer.

Giver applikationen ikke tilstrækkelig forretningsmæssig værdi til at bære yderligere investeringer, giver det heller ikke mening at tænke på vedligehold eller andet. Vælg "Gør ingenting".

Er applikationen funktionsmæssigt meget tæt på et 1-1 match i forhold til forretningens krav? Så er omkostningen ved at flytte over i et standardsystem minimal. Vælg "Genimplementér løsningen".

Er ingen af de to alternativer optimale for dig? Vælg "Etablér et Application Management setup (AMS)".

Overvej om du kan klare det selv, eller om det giver mening at kigge på et eksternt samarbejde.

Husk, at uanset hvad, så er din væsentligste opgave at fjerne den usikkerhed fra både it-afdelingen og forretningen, som uvisheden om en kritisk applikations fremtid og ydeevne indebærer.

Og dét er ikke en opgave, der forsvinder, hvis man kigger væk.