I den første del af min it-karriere arbejdede jeg på den tekniske side af it-udviklingsprojekter. Her så jeg ofte projekter lide under mangelfuld analyse af nytteværdien og de behov, kunden havde for det nye system, der var indgået aftale om.
Denne undren bragte mig gennem årene over på den mere forretningsorienterede del af projekterne. I dag er mit fokus som forretningsanalytiker at analysere og specificere kundens forretningsbehov og tilhørende it-krav, så de understøtter de strategiske forretningsprocesser. For der er en vigtig forskel på at bygge et stykke software og løse et forretningsproblem.
Kravspecificeringsprocessen er vigtig
Min kollega på området, John Hansen, er freelance-forretningsanalytiker gennem ChangeGroup, som han også er partner i. Han formulerer vigtigheden af kravspecificeringsprocessen i it-udviklingsprojekter sådan:
– Det, der for en virksomhed kan give en forretningsmæssig fordel, er enten at lave tingene bedre, hurtigere eller billigere end de andre. For at gøre det er man nødt til at have systemer, der understøtter forretningsgangen og de egentlige behov.
Kravspecificeringsfasen er blevet vigtigere end før, da projekterne har det med at være mere og mere forretningsvendte. Tidligere var fokus mere på de it-tunge projekter.
– Man har efterhånden fået dækket mange af it-behovene med at få it-infrastrukturen på plads og få nogle systemer, hvor man kan gemme informationerne osv. Den næste bølge er at få forretningens behov bedre afdækket, siger John Hansen.
Fejl og konsekvenser
Ifølge John Hansen er de klassiske fejl, set fra virksomhedens eller projektlederens side, at man ikke tillægger kravspecificeringsfasen tilstrækkelig værdi, og at man ikke sætter nok tid af til at få afdækket kravene ordentligt.
– Forretningskonsulenterne bliver presset eller lokket til at gå for hurtigt videre i processen, inden de kommer til bunds i behovene, siger han.
Årsagen skal ifølge John Hansen findes i, at virksomheden lynhurtigt får lavet nogle business-cases og får nogle gevinster ud af det. Og så er det gevinsterne man jagter. Men det er ikke sikkert, at virksomheden har høstet de værdier, som den burde.
– Det giver konsekvenser, når projektresultatet møder virksomheden, og den opdager, at produktet ikke understøtter forretningsprocesserne, siger John Hansen.
Han peger på, at virksomheden efterfølgende enten må leve med den dårlige løsning eller acceptere bekostelige tilbageløb i projektet, som kunne være undgået. De store konsekvenser kan dog mindskes, hvis systemerne er fleksible, så det efterfølgende er muligt, og relativt ligetil, at foretage ændringer i løsningen.
Kunsten at forstå et behov
Mange kunder har brug for at blive hjulpet til at få udfoldet deres behov samt blive guidet hen til den rette løsning. For nogle gange er det ikke muligt for kunden at vide, hvad der er rigtigt, og nogle gange ved han simpelthen ikke, hvad hans behov er.
En typisk tendens er, at kunden tænker sine behov som it-løsninger frem for i forretningsmæssig sammenhæng. Derfor er det forretningsanalytikerens opgave at tage kundens ideer og krav og udfordre dem, vende dem på hovedet og stille afdækkende spørgsmål.
En ofte set fejl i forbindelse med kravspecificeringsprocesser er, at forretningsanalytikeren ikke forstår forretningens behov til bunds. Der er ingen gylden ”how to”-manual, som kan hjælpe til at analysere sig frem til kundens egentlige behov. Metoder og værktøjer er nyttige, men vil ikke kompensere for mangelfuld gennemtænkning. Ved at fokusere på, hvilke processer der skal understøttes i forretningsgangen, kommer man imidlertid væk fra løsningsfokus og ned til behovene.
Ny indsigt undervejs
Tendensen er, at it-projekterne bliver mere forretningsvendte, og her kan den optimale løsning ikke nødvendigvis vides på forkant af projektet. Derfor er det essentielt, at forretningsbehovene bliver identificeret og analyseret til bunds.
Et bæredygtigt it-projekt er derfor i dag en proces, hvor man hele tiden undervejs bliver klogere på, hvad der giver forretningen optimal værdi. Løbende rettelser i projektet er nødvendige – og nogle gange helt oppe på business-case-niveau - i takt med at dybere forståelse for forretningens egentlige behov indvindes.
