Application Management sparer tid på drift og vedligeholdelse

Mange virksomheder arbejder i dag med ældre it-systemer eller applikationer, som vedligeholdes internt af virksomhedens egne medarbejdere. Vedligeholdelse af sådanne systemer er ofte besværligt og tidskrævende, og det forhindrer de interne udviklere i at skabe nye løsninger, der får virksomheden tættere på sine strategiske mål. Commentor tilbyder professionel Application Management.  Vi har mere end 20 års erfaring i systemopdateringer og systemvedligehold.

Få styr på vedligeholdelse af gamle systemer – benyt Application Management

En udfordring med ældre it-systemer er, at ofte er der kun én eller meget få personer i virksomheden, som kan vedligeholde systemerne. En sådan afhængighed af enkeltpersoner kan være kritisk for virksomhedens fremtidige drift. Hos Commentor hjælper vi mange virksomheder med Application Management af deres systemer og applikationer. Vi har mange års erfaring med drift, servicering og udvikling til langt de fleste systemer.

Commentor leverer Application Management

Vi vedligeholder over 40 systemer med mere end 8.000 brugere. Vi tilbyder Application Management til både backend-systemer, integrations- og portalløsninger samt mobile løsninger. Commentor er et stort udviklingshus, og vores mange udviklere sikrer, at vi har kendskab til og forståelse for mange forskellige teknologier og måder at løse komplicerede problemstillinger på.

Med Commentor Application Management er jeres virksomhed blandt andet sikret:

  • Vedligeholdelse og udvikling af jeres applikation hele dens levetid
  • Mere tid til udvikling af nye løsninger og mindre tid brugt internt på vedligeholdelse af gamle systemer
  • God performance
  • Lave omkostninger til vedligehold og service gennem fastprisaftaler
  • Mulighed for tæt integration mellem IT og forretning
  • Ekstra kapacitet eller ekspertise kan simpelthen bestilles på efterspørgsel
  • Underliggende teknologi er altid up-to-date og derfor generelt på sit mest effektive niveau
  • Ekstra kapacitet eller ekspertise kan bestilles på efterspørgsel

Application Management Service – sådan leverer vi

Application Management Service – hvornår er det hensigtsmæssigt at etablere dette? De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation, der skulle håndtere et konkret problem udstukket fra forretningen. Løsningen blev lavet, det gik godt, og som tiden er gået, er der blevet flere opgaver oven i applikationen. Løsningen er gået fra at være en mindre løsning til at være et kritisk element for forretningen.

Hvordan håndterer du vedligehold af den applikation? Samtidig med, at du ikke sætter noget over styr i resten af dit it-setup? Det får du et par bud på her.

Hvorfor står du med en udfordring i forhold til Application Management Service?

De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation, der skulle håndtere et konkret problem udstukket fra forretningen. Løsningen blev lavet, det gik godt, og som tiden er gået, er der blevet flere opgaver lagt oven i applikationen. Løsningen er gået fra at være en mindre løsning til at være et kritisk element for forretningen.
Sådanne løsninger kan der være lavet flere af, inden for forskellige forretningsområder – og på den måde står man ”pludselig” med multiple kritiske løsninger.
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. Ofte er det nemlig godt for forretningen, at det sker.

Vær glad for din applikation

Som udgangspunkt er et problem jo blevet løst, og der er lavet en løsning, der understøtter forretningen. Det konkrete problem er afdækket og successen er vist igennem den videreudvikling, som løsningen har haft – på en agil, konkret og kosteffektiv måde.
Løsninger som disse er en nødvendighed for udviklingen i alle virksomheder. Man ser et konkret problem og løser det, i den skala som forretningen har på det givne tidspunkt. Når der så kommer vækst, følger løsningen med.
Men på et tidspunkt skal man tage et valg om den videre strategi. Det skyldes primært tre forhold:

1. Forretningen stiller højere krav
2. Omkostninger
3. Kompetence

Ad 1: Forretningen stiller højere krav
Forretningens krav ændrer sig hurtig. Derfor skal change requests løses hurtigt. Det kan give store udfordringer til Udvikling, da det kræver kvalificerede ressourcer, der er klar, når udviklingen skal forgå.
Det forventes, at løsningen kører professionelt med tilsvarende oppetid. Kravene til driftssikkerhed gør det derfor ofte nødvendigt med en dedikeret hotlineservice med SLA for at sikre servicen af løsningen over for forretningen.
Forretningen baserer fremtidig indtjening på baggrund af løsningen, og det giver forpligtelser – derfor skal der kunne gives garantier for levetiden i et større antal år.

Ad 2: Omkostninger
Kravene, til at sikre kompetence og serviceniveau in-house, kræver en stor stab og er derfor en høj fast omkostning.
Udnyttelsen af de interne ressourcer er sjældent økonomisk optimale. Enten er der for få opgaver til de kompetencer, man råder over, eller også ligger der for mange opgaver, således at forretningen ikke serviceres ordenligt.
Interne udviklingsressourcer vil i stedet kunne omfordeles til implementering af mere innovative projekter, der bidrager til en større forretningsmæssig værdi.

Ad 3: Kompetence
Teknologisk kan det være svært at vedligeholde alle sine ”mindre løsninger”, fordi det kan være en udfordring at nå kritisk masse på den givne teknologi.
Kompetencerne på teknologi og viden ligger som oftest på meget få medarbejdere.

Hvordan skal udfordringen så gribes an?

Der er overordnet set tre alternative veje at gå:

1. Genimplementere løsningen
2. Gøre ingenting
3. Etablere professionelt Application Management

Ad 1: Genimplementere løsningen
Man kunne forestille sig, at det f.eks. handler om en applikation, som salgsteamet har benyttet igennem længere tid, er glade for og har opnået gode resultater med.
Teknisk vil det være muligt at tilpasse standardsystemet med denne funktionalitet, så det kunne umiddelbart lyde som den oplagte mulighed, men lad os se på fordele og ulemper:

Fordele
a. Hvis det er muligt lægges udviklingen i en ressourcedel, hvor virksomheden har kritisk masse.
b. Der kan måske være usabilityforbedringer ved at inkludere funktionaliteten i et – for brugerne – velkendt standardsystem.
c. Vedligeholdelsen af løsningen sikres, idet den kommer ind under den paraply som standardsystemet giver.

Ulemper
Det, der engang var en standardløsning – CRM, ERP mm – bliver tynget med mere custom funktionalitet, hvilket gør det markant dyrere at vedligeholde hele ”standardløsningen”.

Der kan kun vanskeligt beskrives en holdbar businesscase, når der konverteres. Der bidrages nemlig ikke til yderligere effektivitet eller funktionalitet ved operationen, og en businesscase vil derfor være tæt på umulig at opnå.

Ad 2: Gør ingenting
En aktiv beslutning om ”ingenting at gøre” kan, i nogle tilfælde, være den rigtige. I relation til en applikation vil det betyde, at man benytter de samme ressourcer og det samme supportberedskab, som man gør i dag.
Ved intern udvikling vil det, som oftest, betyde at man har udviklingsressourcer, der vil kunne udvikle på den enkelte løsning, men at der ikke er konkrete aftaler omkring support.
Ved eksterne leverandører fungerer udviklingen oftest på adhoc basis, og hvis der kommer et ændringsønske, kan det kun gennemføres under forudsætning af, at den/de udviklingsressourcer der kender til løsningen, stadig er i virksomheden og i øvrigt er tilgængelige for opgaven.
Derudover er der ofte ingen formaliseret ramme omkring support ved funktionsstop eller andet.

Fordele
a. Omkostningsneutralt.
b. Der kan måske være usability forbedringer ved at inkludere funktionaliteten i et – for brugerne – velkendt standardsystem.
c. Vedligeholdelsen af løsningen sikres, idet den kommer ind under den paraply som standardsystemet giver.
d. Giver en umiddelbar (men dog ikke langsigtet) løsning i forhold til forretningen.

Ulemper
a. Der vil opstå store problemer ved et funktionsstop, med mulige store økonomiske konsekvenser.
b. Når først problemet er der, kan det tage meget lang tid at genetablere systemet, bare til en simpel ”nødløsning”.
c. Risikoen for omkostninger ved funktionsstop omfatter funktionsetablering, tabt arbejdsfortjeneste, potentielt tabt indtjening, image- og omdømmetab.
d. Internt risikerer IT/Udviklingsafdeling at lide imagetab ved funktionsstop.

Ad 3: Etabler professionelt Application Management Service (AMS) på vedligehold og fuld support.
Det tredje alternativ beskriver, hvordan man med ekstern hjælp kan etablere det setup, som appikationen har behov for, for at opnå de krav forretningen stiller. Med andre ord, på en sådan måde at udviklingsressourcer etableres, således at svartider, båndbredde og kompetencer opretholdes i nødvendig grad.
Der defineres klare krav til support og hotlineservice på applikationen, som aftales med AMS-partneren.

Fordele
a. Fuld kontrol med applikationen og udviklingen.
b. Risikoproblemet er løst.
c. Mulighed for tæt integration mellem IT og forretning.
d. Ikke længere et behov for at skabe eller opretholde dedikerede ressource-tjenester. Ekstra kapacitet eller ekspertise kan simpelthen bestilles på efterspørgsel.
e. Den underliggende teknologi er altid up-to-date og derfor generelt på sit mest effektive niveau.
f. Opnå en fast og forudsigelig udgift til dit vedligehold.

Ulemper
a. Etablering af en løbende omkostning.

Hvordan beslutter du den rigtige løsning?

For at forstå den risiko og de costdrivere, der er i dine applikationer, er det altid en god ide at sætte tal på. Her er derfor fire hovedområder, du som minimum skal gennemgå for at skaffe et solidt beslutningsgrundlag.

1. Hvor meget værdi skaber applikationerne for forretningen?
2. Hvad er omkostningen i dag?
3. Hvilken service har du i dag?
4. Hvad er cost/benefit ved de tre alternativer?

Ad 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å forretning til at sætte tal på værdien af systemet, fx pris pr. dag. Hvad er ekstra indtjening eller, hvad vil omkostningen være, hvis løsningen slet ikke var til stede, eller den fandtes i en mere minimal standardløsning? Er det ikke muligt for forretningen at komme med disse tal, så forsøg at estimere selv, og præsenter dem for at få respons.

Ad 2: Hvad er omkostningen i dag?
Hvor mange timer har været brugt på vedligehold og udvikling de sidste par år?
Kan du se nogle omkostninger ud i fremtiden – de næste 1-3 år, opgraderingskrav, funktionalitets krav, etc?

Ad 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?

Ad 4: Hvad er cost/benefit ved de tre alternativer?
Hvis du har analyseret dig frem til at “gøre ingenting”, så fandt du formentlig ud af det, da du talte med forretningen om vigtigheden af applikationen. Altså; giver applikationen ikke tilstrækkelig forretningsmæssig værdi til at bære yderligere investeringer, så giver det heller ikke mening at tænke på vedligehold eller andet.
Genimplementering i et standard system betyder, at applikationen funktionsmæssigt er meget tæt på en 1-1 match i forhold til forretningens krav, og eventuelle gap’s i funktionaliteten ikke er begrænsende for forretningen. Omkostningen ved at flytte over i et standardsystem er derfor minimal og din løsning er inden for rækkevide. Aftalen med forretning om konvertering skal bare sættes i stand.

Hvis analysen viser, at ingen af de ovenstående alternativer er optimale for dig, så bør du overveje at etablere et eksternt, professionelt Application Management Service setup på vedligehold og support. I samarbejde med en professionel leverandør skal I definere de parametre, der skal gøre sig gældende for en AMS-service, og dermed fjerne den usikkerhed fra både IT og forretningen, som uvisheden om en kritisk applikations fremtid og ydeevne indebærer.

Hent vores Whitepaper – AMS i Commentor

Læs om vores øvrige ydelser: SystemintegrationMobil udviklingPortalløsningerDevOpsBackend

Daniel Schødt
Business Developer
Mobil: +45 61 45 97 14
E-mail:
dsc@commentor.dk

Morten Kryger

Morten Kryger
Business Developer
Mobil: +45 40 68 21 71
E-mail:
mkr@commentor.dk

Abier Commentor

Abir Abboud
Business Developer
Mobil: +45 23 87 03 87
E-mail: aab@commentor.dk

Susanne Edemann
Business Developer
Mobil: +45 61 73 45 14
E-mail: sed@commentor.dk

Kim_Lauritzen

Kim Lauritzen
Business Developer
Mobil : +45 61 45 76 76
E-mail : kla@commentor.dk

KONTAKT EN AF OS, HVIS DU BRUG FOR HJÆLP TIL APPLICATION MANAGEMENT

Copyright 2017 Commentor A/S - all rights reserved