Vi bygger bare selv...

Hvad er det, der får virksomheder til at prioritere at bruge interne ressourcer til at bygge et internt IT-system i stedet for at være innovative inden for deres kernekompetencer?

Her er, hvad vi oftest hører som de væsentligste begrundelser:

1. Vi får dækket vores præcise behov - hverken mere eller mindre
2. Vi kan altid udvide, hvis vores behov skulle ændre sig
3. Det er billigere end at købe/leje et system
4. Vi har et specifikt workflow, som vi ikke vil tilpasse et standardsystem
5. Vi kender en udvikler/studerende, som kan bygge det til os til en billig pris, og så er det bare en engangsudgift

I TimeLog har vi også prøvet at bygge flere systemer, der kan understøtte vores interne behov. Dét vi har lært, af egne erfaringer samt af de kunder, som indrømmer, at det var en fejl at begynde på et sådan projekt, er:

1. Det er en kortsigtet gevinst.  Ofte har man lavet en simpel kravspecifikation, og når systemet tages i brug, så finder man ud af, at der er flere behov, som ikke er blevet understøttet. Det kræver enten ekstra udviklingstid eller at man går på kompromis med funktionalitet. Ergo, ofte vokser et simpelt projekt sig større, end man lige havde regnet med og ender med at blive skrottet, når man har indset, at man har brug for mere og noget som udvikles på kontinuerligt.
   
   
2. Det koster i indtjening eller innovation. Hvis man tager en udvikler og sætter denne til at arbejde på et internt projekt, skal man regne på, hvad det egentlig har kostet virksomheden at bruge personen til dette projekt i stedet for på et fakturerbart projekt. Har det taget 100 timer at kode et simpelt system, som kun lige klarer de behov, man har, og har man en timepris på 1000,-, så kunne et kundeprojekt i stedet have inkasseret 100.000,-. Så bliver det pludselig et dyrt system. Der er selvfølgelig stille perioder, hvor der måske ikke er fuldt booket med kundeprojekter. Men kunne det ikke tænkes, at det i stedet gav meget større værdi på lang sigt at være innovativ inden for virksomhedens kernekompetencer i stedet for at sætte et side-projekt i gang? 
   
   
3. Man kender ikke best practises inden for forretningsområdet. Hvis en leverandør har brugt 10 år på at udvikle et standardsystem, så har de også en masse erfaring fra både gode og dårlige løsninger/implementeringer. Derudover har de også udviklet i dybden og understøtter behov, man måske ikke troede, man havde i første omgang. 
   
   
4. Man kan ikke vokse med løsningen. En virksomhed er en organisk enhed, som udvikler sig over tid. Det gør et internt udviklet system ikke. Har man et system fra en leverandør, som stadig udvikler på produktet, får man også glæde af alle de nye muligheder, som ens virksomhed kan udnytte. 
   
   
5. Vedligeholdelse er en pine. Alle som udvikler software ved, at der vil opstå fejl på et eller andet tidspunkt. Det betyder, at personen som har bygget systemet skal bruge ekstra tid på at vedligeholde det løbende. Det er dermed ikke længere en engangsudgift. Stopper denne person tilmed, så er der en anden, som skal sætte sig ind i koden - og det tager tid. 

Vi har i TimeLog besluttet, at hvis der findes et standardsystem på markedet, som understøtter mere eller mindre alle vores behov, skal vi hellere købe os til en løsning end at kaste os over det som et lille sommerprojekt. Vi har med tiden fået de knubs, der i bagklogskabens klare lys, har givet os noget at regne på i forhold til, hvor mange timer vores "små" projekter har taget. Når vi så regner på, hvad vi ellers kunne have udviklet inden for vores kernekompetencer, så er der ikke mange succeshistorier. Vi vil derfor hellere bruge vores kræfter på at udvikle inden for vores kernekompetencer, som øger værdien af vores produkt, end at sætte os ind i et nyt forretningsområde og begynde på et projekt, som aldrig bliver en 100% succes.  

Så spørgsmålet er, bygger I selv næste gang?