Forretningsprosesser og SOA – som syre og vann

Av min gamle kjemilærer lærte jeg følgende regle: «Syre i vann, det går an. Vann i syre blir uhyre.» Litt på samme måte er det med tjenesteorientert arkitektur (SOA) og forretningsprosesser.

Nesten enhver IT-avdeling med respekt for seg selv har prosjekter gående som er basert på SOA. Det er den nye hypen i IT-bransjen. SOA kan være som balsam for forretningsprosessene, men SOA kan også ende opp som et mareritt.

Man kan fylle flere bøker med diskusjonen om hva som avgjør om et SOA-prosjekt blir en suksess eller en katastrofe. Men det er én ting som er viktigere enn noe annet:

SOA må bidra til å optimalisere verdiskapingen !

(Det er et viktig poeng å bruke ordet optimalisere, ikke forbedre. Det finnes i de fleste virksomheter flere titalls forslag til tiltak som kan forbedre verdiskapingen. Utfordringen er å finne de tiltakene som gir størst forbedring. De som optimaliserer verdiskapingen.)

Hvordan kan SOA bidra til å optimalisere verdiskapingen ?

I to uavhengige undersøkelser i fjor ble over 1000 konsernsjefer spurt hva som var den viktigste utfordringen for deres bedrift. Begge undersøkelsene hadde den samme utfordringen øverst på listen: Fleksibilitet til å tilpasse seg stadige endringer.

Med kunder, marked og rammebetingelser i konstant endring er det en stor utfordring bedrifter å følge med. Når store, tunge IT-systemer først er implementert, er det ofte dyrt og krevende å gjøre endringer.

SOA kan være en løsning på denne utfordringen. Hele hensikten med SOA er å tilføre IT-systemene fleksibilitet og gjenbrukbarhet. Store, komplekse systemer deles opp i mindre, funksjonelle biter (tjenester) som kan settes sammen og endres etter behov. Med standardiserte grensesnitt kan tjenestene settes sammen til en løsning som passer bedriftens behov. Når behovet endres, kan løsningen enkelt endres tilsvarende. Akkurat som Legoklosser.

Et eksempel på en virksomhet som klarer å utnytte teknologi som en drivkraft i verdiskapingen er flyselskapet Norwegian. Riktig bruk av teknologi var en viktig bidragsyter til at selskapet gikk med overskudd mye tidligere enn markedet forventet. Hva gjør de annerledes ?

IT-direktøren i Norwegian er en del av toppledelsen i selskapet. I tillegg til IT har han også ansvaret for forretningsutvikling. Hos Norwegian er ikke fokuset med IT å følge en eller annen IT-strategi. Hos Norwegian er IT et verktøy for å oppfylle selskapets forretningsstrategi. Følgen er at hvert eneste IT-prosjekt i Norwegian tilfører verdiskapingen noe konkret og målbart, i form av reduserte kostnader, høyere inntekter og så videre. Og når markedet endrer seg, er Norwegian flinke til å endre systemene tilsvarende.

SOA kan altså gjøre IT til en drivkraft i verdiskapingen. Men da må man gjøre som Norwegian og bruke SOA som et middel for å oppfylle forretningsstrategien, ikke bare IT-strategien.

I tillegg til dette overordnede fokuset, er det noen helt konkrete områder som IT-direktører må bli flinkere til å fokusere på:

Det som ikke måles kan ikke optimaliseres.

Man må bli flinkere til å sette tall på resultatet av investeringer i SOA og andre IT-prosjekter. Med tall så mener jeg tall som forretningen er opptatt av, ikke IT-tall. Kan man for eksempel dokumentere en økning i antall ordre som behandles, en reduksjon i kostnadene per transaksjon eller en økning i antall telefoner som besvares på kundesenteret, så er det interessant. Antall transaksjoner per sekund i et system er som regel ikke interessant for andre enn IT-avdelingen.

Disse målekriteriene må bestemmes FØR man setter i gang et prosjekt. Hvis man ikke vet hvordan tilstanden var før man startet, så er det ikke mulig å vite hvor mye bedre resultatet har blitt.

Ikke glem risiko

Risiko står høyt på agendaen til de fleste toppledere. I noen bransjer er risiko helt avgjørende for hele virksomheten. Dette er noe som dessverre forsømmes i mange IT-avdelinger. I noen tilfeller har det fått katastrofale følger. Det norske netthandelselskapet Komplett.no opplevde for noen år siden redusert omsetning i et helt år og store tap som følge av et mislykket IT-prosjekt.

Når IT-prosjekter vurderer risiko, så tenker de som regel bare på risikoen for å tape pengene som investeres i prosjektet. Man glemmer risikoen for at prosjektet skaper problemer for kjernevirksomheten. Det er her den store risikoen ligger. Det kan koste mange ganger mer enn selve investeringen i prosjektet.

Et norsk selskap som for noen år siden ønsket å spare en håndfull millioner årlig på å sette ut driften av IT-systemene, opplevde at de som følge av dårlig kvalitet på driftsleveransene ikke klarte å opprettholde sine forpliktelser ovenfor kundene. I tillegg til titalls millioner i direkte tap, opplevde konsernsjefen å se bilde av seg selv på forsiden av Dagens Næringsliv i et par uker i krangel med sin største kunde. Hva dette kostet selskapet i form av tapt anseelse kan man bare gjette på.

Lever verdi ofte

Det er en kjent sak at å ta mange små skritt ofte er bedre enn å ta få lange skritt. Trår man feil en gang, så blir følgene som regel mindre. Det er også enklere å beholde fokus hos brukerne.

Et annet aspekt ved dette, er at jo tidligere man kan levere verdi, jo større blir gevinsten. De fleste økonomisjefer er opptatt av nåverdi og internrente, og nåverdien kan bli betydelig høyere hvis man leverer tidligere. Som følge av dette kan det lønne seg å dele opp prosjekter i mindre leveranser som hver gir litt verdi, fremfor å vente med å levere en komplett løsning.

Prosjekter som mislykkes

Det er uendelig mange årsaker til at SOA-prosjekter mislykkes, men noen feil har gått igjen i flere av de vi har sett eksempler på:

• Urealistisk planlegging. Å utvikle den første SOA-baserte løsningen er mer krevende enn en tilsvarende tradisjonell IT-løsning. Den store gevinsten kommer med prosjekt to, tre, fire osv. Ofte glemmer man å ta høyde for denne «overheaden» i det første prosjektet.
• Urealisteiske ambisjoner. SOA er et omfattende fagområde, og noen IT-avdelinger har overdrevent store ambisjoner om å skape «den perfekte arkitektur». Dette har i flere prosjekter drevet kostnadene til nivåer som ikke står i forhold til den forretningsmessige gevinsten. Det er bedre å lykkes med et prosjekt som er «bra nok» enn å mislykkes med et prosjekt som er «perfekt».
• Risiko ! Se avsnittet tidligere i artikkelen.

For mer informasjon om tjenesteorientert arkitektur, se denne artikkelen på Wikipedia:

http://en.wikipedia.org/wiki/Service-oriented_architecture