Artikel top billede

(Foto: Dan Jensen)

Kør standard så meget som muligt, det er risikabelt og rigtigt dyrt at lade være

Klumme: Fordelene ved standardsystem er utallige, men du høster først gevinsterne, hvis du anerkender præmissen, at I nogle gange skal tilpasse jer værktøjskassen og altid kunne argumentere for, hvornår værktøjskassen og it-understøttelsen skal tilpasse sig jeres behov.

Denne klumme er et debatindlæg og er alene udtryk for skribenternes synspunkter.

Standish Group, der er et uafhængigt firma dedikeret til forskning i softwarekvalitet og porteføljestyring af softwareprojekter, offentliggjorde tilbage i 2010 et studie, hvor de analyserede en lang række it-systemer og værktøjer i forskellige store virksomheder og derefter afholdt workshops og interviews for at afdække, hvilke features, der blev brugt i den software, firmaerne driftede.

Undersøgelsen viste, at syv procent af alle features blev brugt hele tiden, 13 procent blev ofte brugt, 16 procent blev brugt nogen gange, mens henholdsvis 19 procent og 45 procent blev sjældent eller aldrig brugt.

I al sin enkelthed konkluderer undersøgelsen, at to ud af tre features i de softwaresystemer, virksomheder i undersøgelsen havde tilgængelige, kun sjældent eller aldrig blev brugt.

Skræmmende læsning

Det er skræmmende læsning når man forholder sig til et standardsystem versus specialprogrammering som for eksempel ERP, CRM eller lignende.

Tallene fra Stanford-undersøgelsen er i høj grad et argument for at bruge standardsystemet, som det er, fremfor at tilpasse eksisterende features til specifikke behov i virksomheden.

Grunden er ganske enkelt, at hvis over 64 procent af alle features sjældent eller aldrig bliver brugt, så er de resterende features pludselig blevet over dobbelt så dyre at bygge.

Havde du haft en krystalkugle, så du kunne nøjes med kun at bygge de features, du vidste, I ville få brug for, så ville scopet af projektet blive tilsvarenede mindre og væsentligt hurtigere at gennemføre.

Ved at købe et standardsystem og køre med standardfunktionalitet så meget som overhovedet muligt, så mitigerer du risikoen for, at du i dit hjemmebyggede system ender med at bygge de forkerte features, som ingen reelt havde brug for - en erfaring, du kun sjældent kan analysere dig frem til, men som først kommer for en dag, når systemet er blevet implementeret i forretningen efter lancering.

Agile udviklingsteknikker med hyppige releases af prototyper til at afprøve ideer ude i forretningen kan være vejen frem, men det kræver erfaring med agil projektledelse og processer at gennemføre strategiske initiativer.

Standardløsningerne uden for mange tilpasninger giver en bedre risikostyring for projektet her og nu, da du i projektet ikke risikerer at bygge dyre features, du ikke får brug for. Desuden, så har du efter implementering af et standardsystemet en lang række features tilgængelige, som du kan tage i brug, når forretningen har behovet. For eksempel i CRM ligger der en marketingsmotor, men er din organisation klar til det?

Agiliteten i jeres forretning afhænger af, at I som virksomhed er i stand til at tilpasse jer markedet og andre, ydre omstændigheder somfor eksempel corona. Hvis I ikke har en ordentlig it-understøttelse af jeres processer i dagligdagen, så er I allerede bagud på points i forhold til jeres konkurrenter.

Altid tilpasninger

Hvis I pludselig får behov for at tilpasse jeres virksomhed til udefrakommende trusler som for eksempel corona, så er I meget bedre stillet med et standardsystem, hvor ny funktionalitet kan tages i brug og hvor dataudveksling mellem systemer er bygget i åbne standarder, så man forholdsvist smertefrit kan afprøve ideer og værktøjer, der opererer på baggrund af en fælles sandhed i dit standard CRM eller ERP-system.

Der vil altid være tilpasninger til et standardsystem i en eller anden grad, en tilpasning er i sig selv ikke et onde, sådan fungerer virkeligheden jo ikke.

Det, virksomheder oftest slås med i et strategisk forandringsprojekt, er dog, at man undervurderer Total Cost of Ownership på de tilpasninger, der bliver lavet, og at man ikke prioriterer tilpasninger udfra en økonomisk vurdering af, om en tilpasning er rentabel over tid.

Det gælder også eventuelle tilpasninger, der i sig selv sagtens kan anskues som selvstændige, egenudviklede features, bare i rammerne af et standardsystem og ikke i rammerne af et system, som I selv har bygget skelettet og infrastrukturen til.

Det kan være en meget bedre og billigere løsning at ændre interne processer, der i høj grad handler om aftaler og forventningsafstemning imellem mennesker og afdelinger, end det er at købe et standardsystem og så efterfølgende programmere alle mulige undtagelser og særregler ind i systemet, der ikke understøtter et reelt behov.

Fordelene ved standardsystem er utallige, men du høster først gevinsterne, hvis du anerkender præmissen, at I nogle gange skal tilpasse jer værktøjskassen og altid kunne argumentere for, hvornår værktøjskassen og it-understøttelsen skal tilpasse sig jeres behov.

Gode råd

- Undersøg, om tallene fra Standish Group også holder i din virksomhed.

- Husk, at hvis din asfalt ikke er stabil med dine it-systemer, så bliver det svært at køre hurtigt.

- Tilpas jeres proces til standardsystemer – da I ikke er specielle.

- Betragt TOC især når man ved at systemer skal opgraderes løbende, så du ikke ender på en ø platform, hvor ingen kan hjælpe dig.

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.