Operasjonell intelligens: hva er det, og hvordan mestrer man det i prosjektsammenheng?

Operasjonell intelligens: hva er det, og hvordan mestrer man det i prosjektsammenheng?

La oss først se på selve begrepet. Operasjonell kan nok defineres på mange måter, litt avhengig av hvilken bransje og kontekst vi befinner oss i. For denne artikkelen velger jeg å fokusere på operasjoner utført i et gitt systemmiljø, og hvordan miljøet oppfører seg over tid. Intelligens i ordets forstand kan defineres som «evnen til å oppfatte, tenke og resonnere så vel som gjenkjenne og forstå (se sammenhenger i) nye situasjoner - praktiske eller teoretiske - på grunnlag av tidligere erfaring og kunnskap.»

Når vi kombinerer de to ordene blir uttrykket straks mer interessant. Operational Intelligence er definert på den engelske Wikipedia.org, jeg forsøker her med en komprimert, fornorsket versjon av definisjonen:

"Operasjonell intelligens omfatter forståelse av sanntidsdynamikk og forretningsanalyse gjennom synliggjøring og bevisstgjøring av nøkkeltall, sentrale hendelser og operasjoner for et gitt systemmiljø". 

Det kan kanskje være nyttig å koble litt kontekst til selve begrepet. Jeg har nylig deltatt i et ganske stort IT-prosjekt hvor vi daglig møtte utfordringer på området. Hvilke hendelser skal prioriteres, hva gjør vi for å løse en situasjon eller et problem, hvordan rapporterer vi det til prosjektledelsen? Selve hendelsene ble rapportert i Jira, på «tradisjonelt vis» for avvikshåndtering – altså med beskrivelse av situasjonen eller problemet, anbefalt prioritet og merking av relevante miljø, komponenter og versjonsnumre.

Å etterleve KPI-ene

Hvem som avdekker de aktuelle hendelsene avhenger av organisasjonen og fasen prosjektet er i. Gjennom et tradisjonelt utviklingsløp er det testerne, kanskje i samråd med produkteiere og brukere som finner forbedringspotensial i løsningen. Når prosjektet nærmer seg overlevering vil det i økende grad være driftspersonell som ser eventuelle svakheter og ekstraordinære hendelser. Utfordringen ligger ofte i å etterleve KPI-er, Key Performance Indicators, satt av prosjekt eller linjeorganisasjon.

Hvilke KPI-er er det som typisk settes i et prosjekt? Noen gjengangere kan kanskje være blant disse: Tilgjengelighet på funksjoner, antall feil over en periode, responstid på tjenester, antall påloggede brukere, antall unike brukere over en periode, antall ubrukte tjenester over en periode, hvor hurtig vokser bruken av en tjeneste. Hvordan vi måler KPI-ene kan også være en utfordring i seg selv – det viktigste er dermed å ha målbare KPI-er.

Når det kommer til verktøy for rapportering er det viktig å vite nøyaktig hvilke behov man har for presentasjon av datagrunnlaget. Er det rapportering kun internt i prosjektet, eller kanskje for ledere hos kunden også?

Et annet moment er kompleksiteten på rapportene. Uavhengig av verktøy så vil det naturlig ta lengre tid å fremstille komplekse rapporter enn enkle rapporter. Anbefalingen min er derfor å ha flere enkle rapporter, heller enn én stor superrapport. Regneark er dermed et godt utgangspunkt for rapportering, så kan man heller benytte mer avanserte verktøy utover i prosjektet.

Blant mer avanserte verktøy kan jeg anbefale Oracle’s «Business Intelligence Enterprise Edition» (versjon 10 eller 11), samt Splunk.

I prosjektet jeg deltok i benyttet vi OBIEE typisk til rapporter som angikk volum på transaksjoner og sistnevnte til å avdekke antall feil i de forskjellige miljøene. Splunk kan også fungere til monitorering av miljøet ved at man setter opp e-postvarsling for oppgitte kriterier eller at man jevnlig følger med på egendefinerte målepanel. Et målepanel består av et sett med rapporter som kan ha forskjellige presentasjonsformer. Avhengig av KPI-er man har bestemt seg for, lander man et fornuftig design på målepanelene. Det er alltid lurt å ta utgangspunkt i tidsperioden man har behov for å rapportere for - siste time, siste døgn, uke, måned eller et annet forhåndsdefinert tidsintervall før man velger presentasjonsform. Se eksempler på målepaneler under.

Figur 1: Eksempler på målepanel - blogs.splunk.com

Overleveringsfasen

Overleveringsfasen begynner naturlig nok når personer fra linjeorganisasjonen blir mer involverte i prosjektet. I denne fasen er det essensielt å finne ut hvilke personer fra linjen som har ansvar for rapportering av de forskjellige KPI-ene. Dette kan gjerne være personer som innehar en eller flere av følgende roller: Systemeier, tjenesteansvarlig, miljøansvarlig, produkteier, applikasjonsforvalter, driftsansvarlig eller lignende. Hvis det er behov for å gjøre justering av presentasjonsformatet eller hyppighet på rapporteringen, er dette et gunstig tidspunkt for det. Når KPI-ene over en gitt periode viser stabilitet, samt at nøkkelpersoner fra linjen føler de har kontroll, da nærmer vi oss driftsfase. I prosjektet jeg deltok i hadde vi til og med en egen prøvedriftsfase, innen vi gikk over i drift.

Driftsfasen

Selv om man i driftsfasen ikke forventer avvik av stor betydning, vil det nesten daglig forekomme situasjoner og problemområder man må ta stilling til. Hvis problemet tyder på feil eller svakhet i løsningen, må det vurderes hvem man skal involvere. I prosjektet jeg deltok i hadde vi tilgang til teknisk ekspertise også etter overlevering, noe som bidro til effektiv implementering av endringer, med lav risiko. Løpende bør man i driftsfasen holde oversikt på alle endringer som er planlagt, samt ha et tilgjengelig arkiv på endringer som er utført. Når kritiske situasjoner oppstår hjelper det ofte å gå tilbake i arkivet og se hvordan man løste en lignende situasjon. Dette viser også at presis dokumentasjon er svært viktig for å opprettholde stabil drift. Nærliggende vil det også være at man har omforente rutiner på hvilke verktøy som benyttes når man dokumenterer.

Oppsummering

For å oppsummere artikkelen har jeg laget en figur som illustrerer prosjektfasene vi har vært innom, med tilhørende kontrollspørsmål og nøkkelord.

comments powered by Disqus