Unngå mange kokker og mye søl

Av Nina Rokseth, Avdelingsleder, EVRY og Trond Ivar Maanum, Seksjonsleder, EVRY

Livssyklus tenkning inn i applikasjonsutvikling, er det bare tåkeprat? En IT-applikasjon er sjelden ferdig når utvklingsprosjektet har levert. Allikevel planlegges og designes ofte applikasjoner utifra at de er ferdige når de er levert. IT-leverandørene og kundene tenker helt sikkert på at det vil kunne komme endringer men spørsmålet er om man virkelig har designet løsningen med tanke på at den skal kunne videreutvikles så enkelt og billig som mulig inn i fremtiden?

De elementene som påvirker livssyklus kostnaden for en applikasjon er :

• Initiell design og utvikling
• Drift med tilhørende server utstyr
• Support, feilretting og mindre endringer
• Behov for tilleggsfunksjonalitet og endrede bruker behov
• Endrede rammebetingelser i kundens forrettning eller virksomhet
• Endringer i tilgrensende systemer (integrasjon/grensesnitt)
• Nye versjoner av underliggende standard plattform
• Nedskalering og eventuell utfasing

Kostnadselementenesom treffer etter den initielle utviklingen kan i stor grad påvirkes nettopp i design og utviklingsfasen av applikasjonen.

Dette skulle joikke være så vanskelig men det sitter langt inne og flytte fremtidige kostnader inn i nåtid og faktisk få et engasjement fra både de som leverer og de som beslutter på de fremtidge kostnadene. Budsjetter fastsettes også som kjent for et år av gangen. Dette blir ikke mindre viktig når man idag ser at så mye som 75 % av en virksomhets IT-budsjett kan relatere seg til drift og forvaltning av eksisterende løsninger og bare 25 % på det man virkelig kan styre, det vil si videreutvikling og nye systemer.

Dette betyr at de ressursene som inngår i planlegging, design og utvikling av en ny applikasjon ikke bare bør være de spisseste og mest kreative hodene, men også personer som har forvaltning i fingrene og «mellom ørene».

Hvorfor tenke verdikjede ?

Tradisjonelt har man ved outsourcing av applikasjonstjenester stykket opp leveransene i verdikjeden, der basis drift, applikasjonsdrift, forvaltning og videreutvikling er inndelt i separate leveranser som kan komme fra flere leverandører og uansett over ulike kontrakter. Når det oppstår utfordringer, for ikke å snakke om problemer, så ligger ofte dette i grensesnittet mellom lagene i verdikjeden og knytter seg ofte til følgende forhold :

• Design og videreutvikling av løsningen tar ikke hensyn til de underliggende tjenestene
• Ved feil og videreutvikling lykkes man ikke med å få til et fruktbart samarbeid på tvers av verdikjeden
• Ved ytelses problemer meldes alle lag i verdikjeden grønne, selv om helheten er rød.

Det er vanskelig å tenke seg en problemfri leveranse av en applikasjonstjeneste over en kontraktsperiode med mindre leverandøren(e) har et godt opplegg for å samspille på tvers av verdikjeden. Mye tid kan i verste fall gå med til en pekelek der kunden blir skadelidende.

Applikasjonsforvaltning som konsulenttjeneste er «risky»

Sikkerhet for tilgjengelig kompetanse er helt sentralt for å kunne forvalte løsninger på en god måte. Dette må også avspeiles i Leverandørens leveransemetodikk. Å levere forvaltningstjenester til avtalt kvalitet gir føringer for hvordan leverandøren må styre og allokere ressurser.

Det er avgjørende for god og rask oppfølging av saker at det er etablert ett kontaktpunkt (Single point of Contact) mellom kunde og leverandør. For å sikre gode og stabile forvaltningstjenester over tid, er det avgjørende å dedikere et ressursteam som tar et langsiktig eierskap til løsningen. Utover god teknisk kompetanse må de tilegne seg god kunnskap om kundens forretning og forretningsprosesser. En forvaltningsavtale pålegger leverandøren et ansvar for å opprettholde kompetanse på løsningen over tid. Kunden slipper uforutsette opplæringskostnader knyttet til ad hoc konsulentoppdrag og i forbindelse med utskiftning av personell. Eventuelle feilsituasjoner blir ryddet opp i umiddelbart, slik at det kan fokuseres på verdiøkning av løsningen.

Erfaring tilsier en betydelig risiko for ansvarspulverisering når forvaltningstjenester leveres som konsulentbistand på løpende timer. Denne modellen åpner opp for en reell mulighet for hyppigere bytte av ressurs. En person som kun er inne og leverer noen bistandstimer, for primært å sitte på et annet oppdrag vil ofte ikke få samme grad av ansvarsfølelse og dedikasjon i forhold til kunden og løsningen. Et dedikert forvaltningsteam vil ha bedre forutsetninger for raskt og relevant svare opp kundens behov. Spesielt når fristene er korte. En dedikert pool av ressurser gir best mulige forutsetninger for å understøtte «Time to market» som er viktig med tanke på å styrke kundens leveranse- og konkurranseevne.

Smidig metodikk er godt egnet for å støtte videreutvikling og forvaltning

God og effektiv forvaltning handler mye om å realisere kontinuerlig forbedring i tråd med kundens behov. Det forutsetter at feilhåndtering og utvikling gjøres ut fra en prioritering som gir kunden størst verdi til en hver tid. Kanban er en metode som fungerer godt når en løsning skal vedlikeholdes og videreutvikles. Erfaringsmessig er det viktig å begrense «Work In Progress» og eliminere «waste». Ved hjelp av tavleverktøyet Leankit Kanban kan man måle farten og visualisere arbeidsflyten. Et ypperlig verktøy for å få en rask status på hvordan man ligger an, men like viktig; muligheten for å fange opp flaskehalser umiddelbart. Det gjennomføres to korte estimeringsmøter hver uke med fokus på nye utviklingsoppgaver. Utviklerne diskuterer oppgavene i fellesskap og beregner omfanget. Erfaringsmessig fungerer en slik elektronisk tavle godt med hensyn til fordeling av oppgaver og samhandling i teamet, enten man sitter hos kunden, eller i India (offshore) for den saks skyld.

Følgende møteplasser er vesentlige:

• Hyppige estimeringsmøter: gjør at man kan fange opp og ta tak i problemstillinger på et tidlig tidspunkt. Dette fører til redusert tidsforbruk når oppgaven til slutt skal utvikles.
• Retrospektive møter: gjennomføres for å fange opp elementer som kan forbedres. De to viktigste forbedringspunktene prioriteres, istedenfor å prøve å løse alle på en gang.
• Regelmessige demomøter: gir alle deler av kundens organisasjon en mulighet til å se hva som er utviklet. Dette fører ofte til gjenbruk av gode løsninger, og en funksjonell samhandling på tvers hos kunden.

Det hele koker ned til noe så enkelt som kontinuerlig kommunikasjon mellom de involverte partene.

Vellykket applikasjonsforvaltning handler ikke bare om å løse feil, men må fokusere på en større helhet. Fravær av livssyklus tenkning i utviklingsfasen vil lett kunne blåse opp forvaltningskostnadene fordi man ikke enten gjør de riktige prioriteringene eller står i fare for å ta suboptimale snarveier.