Forretningsutvikling og systemutvikling, to sider av samme sak?

For å realisere en forretningsutvikling i virksomheten er det nesten alltid nødvendig med noe systemutvikling. Det kan være du ønsker å oppnå en ny og mer rasjonell verdikjede i virksomheten, gjøre det enklere for kundene dine å nyttiggjøre seg tjenestene dere tilbyr, el.l. Du involverer da gjerne en IT-leverandør for å bistå med systemutviklingen. I tillegg vil det være en rekke endringer i arbeidsprosesser, opplæring, markedskommunikasjon, osv. som skal til for å oppnå den forretningsmessige endringen du ønsker. Investeringskostnadene dette representerer avveies mot mulighetene for økt inntjening eller besparelse, og du har et såkalt business case.

I denne bloggartikkelen snakker jeg for enkelhets skyld om "forretning" også om verdiskaping som gjøres i offentlige virksomheter. Oppgaven er å oppnå endringer som oppleves som positive forbedringer både for virksomheten, de ansatte og for kundene eller brukerne. Over tid skal disse endringene gi en langsiktig effekt for virksomheten og gjerne også for miljøet og folk flest om mulig.

Det er gjerne linjeledere og forretningsutviklere i virksomheten som jobber med slike forbedringsprosesser. Både i små skritt og i større omfattende endringer, ja noen ganger som en fullstendig omveltning av måten virksomheten skaper og omsetter sine varer og tjenester på. For å se muligheter for, og senere beslutte slike endringer, kreves mye kompetanse, spesielt om egen forretning i det aktuelle markedet og om muligheter og begrensninger i aktuell digital teknologi.

Tradisjonell kunde-leverandør-modell

Jeg bruker Kantega som eksempel i følgende beskrivelse av to ulike modeller. Tradisjonelt har det gått et skille mellom forretningskompetansen, som kunden har, og systemutviklingskompetansen, som leverandøren har. Dette skillet har vist seg tydelig ved at kunden har spesifisert sine krav uttrykt i en bestilling, og at leverandøren etter å ha utviklet løsningen, overleverer denne til kunden. Se illustrasjon, hvor det er to svømmebaner fra idé oppstår og til gevinst er realisert, og bestilling og overlevering er to markante milepeler underveis.

Tradisjonell modell: Kunden spesifiserer løsning og bestiller systemutvikling fra Kantega

Tradisjonell modell: Kunden spesifiserer løsning og bestiller systemutvikling fra Kantega

Selv i prosjekt der vi i Kantega jobber etter denne modellen søker vi å ha tett samarbeid med kunde innenfor rammene av utviklingsprosjektet, og har god erfaring med å jobbe tett med kunden og prøve ut funksjonalitet og konkludere skrittvis underveis. Og vi erfarer i flere prosjekt at underveis i utviklingsløpet vinner man erfaring og innsikt som påvirker kundens opprinnelige hypotese om hva det forretningsmessige behovet egentlig er. Det skjer en påvirkning på kundens forretningsutviklingsprosess, og noen ganger må kunden ta et skritt tilbake og justere kravene til utviklingsløpet. For Kantegas utviklere er dette veldig spennende å være med på, og det oppleves svært meningsfylt å få utvikle kundens forretning og ikke «bare» utvikle et system.

«Vi utvikler kundens forretning, - ikke systemer»

Kantega har imidlertid tro på at en tettere samarbeidsmodell mellom forretningsutviklingsprosessen og systemutviklingsprosessen er langt gunstigere enn den tradisjonelle modellen. Sammen kommer vi raskere i mål og med riktigere løsninger. Jeg skisserer en alternativ modell nedenfor.

Drøftingsmodell: Kunden utvikler sitt forretningskonsept i samarbeid med Kantega

Drøftingsmodell: Kunden utvikler sitt forretningskonsept i samarbeid med Kantega

I denne modellen jobber kundens forretningsutviklere sammen med Kantegas utviklingsteam om å utvikle og prøve ut forretningskonseptet man har idé om, og man jobber i ett felles team fra første stund. Viktige virkninger av dette er:

• Tid til å utarbeide tilbudsforespørsel inkl. å spesifisere krav til ønsket løsning bortfaller, og tilsvarende for leverandørens tid til å estimere kostnader på spesifiserte krav
• All nødvendig kompetanse og beslutningskraft er umiddelbart tilgjengelig i teamet. Det betyr at risiko for mistolkninger om hva behovene er og hvilke muligheter til løsning som finnes reduseres dramatisk
• Hypoteser om hvilke forretningsmessige endringer man tror vil gi effekt kan raskt prøves ut, og tilsvarende for hypoteser om hvilken løsning/funksjonalitet som vil fungere og gi ønsket endring
• Arbeid som ikke skaper verdi avsluttes raskt
• Kunden har fra dag til dag stor innsikt i og innflytelse på det som utvikles og utprøves, og utviklerne vet fra dag til dag at det de utvikler er ønsket av og har nytte for kunden
• Kunden utvikler sin forretning gjennom løpende systemutvikling i en og samme prosess

Noen kunder jobber sammen med oss på denne måten allerede, og jeg tror at dette er en samarbeidsmåte vi vil se mer av fremover. Det er spennende å få erfaring med hvilke kompetanser som er påkrevd og hvilke samarbeidsmønstre som er egnet for å få et slikt felles «forretningskonsept-team» til å fungere godt.

Forretningsutvikling og systemutvikling hånd i hånd

Tilbake til deg som har behov for å gjennomføre forretningsutvikling med systemutvikling som virkemiddel. Du bør forvente at din leverandør bidrar inn i teamet med kompetanse på metoder for forretningsutvikling; som tjenestedesign, Design Sprint, Business Model Canvas, osv., og kanskje også på organisasjonsutvikling og hvordan lede endringsprosesser. Videre også kompetanse på teknologier og relevante mekanismer som kan muliggjøre transformasjon. Og til sist, forståelse for den bransjen som din virksomhet opererer i og hva som skjer av digital transformasjon hos aktører i denne bransjen.

Systemutviklingsselskaper i dag må kunne være innovasjonsdrivere, og jeg tror nye forretningskonsept best utvikles innenfor rammene av felles team, og hvor man sammen kan være dristig utforskende på nye muligheter. Et eksempel fra et slikt samarbeid er Fixrate, se hva vi gjorde sammen med dem.

Ta gjerne kontakt hvis du ønsker å ta å en prat om dette eller annet.