Denne klumme er et debatindlæg og er alene udtryk for skribenternes synspunkter.
For 20 år siden, dengang internettet var ungt, Nokia var altdominerende på mobilmarkedet, Google knap nok var kommet ud af garagen og det kun var en lille minoritet, der havde prøvet at handle med kreditkort på internettet, var systemlandskabet i de danske virksomheder naturligt nok et helt andet end det, man bliver mødt af i dag.
Dengang var standarden, at du ved ansættelse fik adgang til en Microsoft Office 2000 – men herfra, så kunne du ikke forvente, at værdikæderne i virksomheden var understøttet af standardsoftware.
Hovedreglen var, at du havde egenudviklede løsninger og derudover en række tilpasninger af proprietær software til at løfte på effektiviteten af dine HR-processer, dine ERP-behov og til salg og marketing.
Det var reglen dengang, at eksempelvis din webshop var programmeret helt fra bunden således, at it-udviklere i virksomhederne havde implementeret hver deres indkøbskurv, hver deres fortolkning af lagerstyring og hver deres måde at håndtere ordreoprettelse og økonomisystemer på. Der fandtes ingenting, så man begyndte fra bunden hver gang.
Byggeklodser
Spoler vi 20 år frem i tid, så kan du købe dig til et system, du så tilpasser efterfølgende til dine specifikke behov på basis af, hvad du ser som dine unikke value propositions. Hvis for eksempelvis SAP og Microsoft ikke er sagen for din virksomhed, så findes der heldigvis et utal af muligheder for små og mellemstore virksomheder. Fremtiden er at sætte byggeklodserne sammen med dine egne folk og eksperter indenfor det givne område.
Dog, så lever nogle virksomheder i dag stadig efter en grundlæggende præmis, der tilsiger, at it skal tilpasse sig behovene i virksomheden og ikke omvendt.
Der vil altid være mange følelser og kulturel kapital involveret, når virksomheder skal argumentere for, hvordan de skaber værdi for deres kunder.
Du opnår aldrig en skalerbar virksomhed, hvis du bygger dine it-systemer udfra en præmis om, at det altid er it-systemet, der skal tilpasse sig din virkelighed og ikke omvendt.
Nogle gange må du skære interne processer til og tilpasse dig en standardløsning for at undgå en teknisk gæld, der over tid kan diktere dine handlemuligheder og blive en hæmsko i forhold til at følge med markedet og kundernes forventninger.
Du og din bestyrelse kommer muligvis fint i mål på at indføre et standardsystem, der er tilpasset i alle ender og kanter for at understøtte de samme arbejdsgange, I har arbejdet efter i 20 år.
Dengang byggede I systemerne selv og de blev skræddersyet til jer.
Vil give udfordringer
Hvis du og din virksomhed ikke forstår at ændre strategi, så skal du og dit team være forberedt på at tackle de udfordringer, der kommer, når en opgradering af dit standardsystem tre-fire år ude i fremtiden skal implementeres.
Det er jo ikke kun standardsystemet, der skal skiftes ud i dette scenarie.
Tilpasningerne skræddersyet til version 1 skal skrives om af et nyt hold dyre konsulenter, så de passer til version 2.
Konsulenterne har sandsynligvis svært ved at estimere opgaven på grund af den øgede mængde kompleksitet, I lagde ind i standardsystemet, så det kan være svært at få en samlet pris up front på, hvad en opgradering koster.
Konsekvensen er, at at din businesscase enten forringes eller bliver så dårlig, at hele opgraderingsprojektet bliver skudt til hjørne. Så har du om fem-seks år en forældet platform, der bliver en hæmsko i forhold til sikkerhed og ikke mindst behov for kommende forretningsudvikling og det er brandærgerligt, når det netop er på længere sigt, at gevinsterne ved at indføre et standardsystem skal høstes.
Hovedreglen er, at man skal kigge grundigt på omkostningerne og konsekvenser af udvikling, drift og support på løsningen i hele softwarens levetid.
Gør man sig den tjeneste at regne i Total Cost of Ownership fremfor udelukkende at regne på prisen for en implementering af den første, store implementering, så finder man ofte, at et standardsystem er at foretrække, medmindre softwaresystemet er af strategisk betydning for virksomhedens evne til at konkurrere i markedet.
Gode råd
Lyder det bekendt, så er der her en række spørgsmål, du kan stille dig selv, hvis du har gennemført din foranalyse og skal udfordre din forretning på, hvad det rigtige valg vil være i jeres situation:
- Hvilke løsninger findes der på markedet, der indeholder 80 procent af de features, din virksomhed har brug for i kontekst?
- Vil det give dig en konkurrencefordel overfor dine konkurrenter, at du bygger softwaren selv?
- Kan du forsvare et samlet estimat på Total Cost of Ownership og kompleksiteten af en egenudviklet løsning fremfor at købe et stykke standardsoftware, hvor cost og risici er forudsigelig på nogle helt andre parametre?
- Hvordan sikrer du igennem hele softwarens levetid, at nonfunktionelle krav til sikkerhed, skalerbarhed, GDPR, dokumentation, brugergrænseflade og lignende vil blive implementeret på niveau med det, du vil få i en standardløsning?
- Er forretningen villig til at vente på, at it-afdelingen programmerer en ny feature, når behovet er erkendt - fremfor at betale for at kunne eksperimentere og tage eksisterende funktionalitet i standardsystemet i brug med det samme?
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
