Sedan, stasjonsvogn eller kabriolet? Noen erfaringer fra prosessarbeid

Tidligere har jeg blogget om Hvordan velge riktig modelleringsstandard og filosofi, i dag tenkte jeg å dele noen erfaringer fra denne typen prosjekter. Tilfeldigvis har jeg av familiære årsaker også måttet ta et annet vanskelig valg; nemlig; “hjelp, skal jeg virkelig kjøpe stasjonsvogn?” og ikke minst “hvilken stasjonsvogn lar meg i det minste være (føle meg) litt sportslig?”. Derav tittelen.

I løpet av det siste året har jeg deltatt i to store prosjekter, der valg av modelleringsstandard og -praksis har vært tema. I det første prosjektet var det et åpent spørsmål om hvilken standard som skulle brukes, og i det andre prosjektet var det valgt en standard, men man var usikker på hvordan man skulle bruke den.

I begge tilfeller kom det opp noen sentrale spørsmål. Hvorfor, hvem, hva, når, hvor og hvordan? Ikke alle spørsmålene kom samtidig, og ofte måtte spørsmålene hjelpes frem. I de tilfellene der spørsmålene måtte hjelpes frem, ble praksis gjort ved at noen måtte stille de “dumme” spørsmålene (“Hvorfor gjør vi dette? Hva er det vi skal bruke dette til? Hvem er kundene til modellen?) – spørsmålene er som oftest ikke dumme, men kan gjerne føles dumme i det man stiller dem (“alle” vet jo hvorfor vi har prosesskart?). I begge prosjektene har det vekslet hvem som har stilt spørsmålene, noen ganger har det vært den eksterne konsulenten, andre ganger interne i organisasjonen eller prosjektet. Her er det min erfaring at sistnevnte ofte stiller mange bra spørsmål, gjerne uten at de egentlig tenker over at de fungerer som en slags katalysator for en 6W-analyse (Hvorfor, hvem, hva.. etc.). Et i utgangspunktet kritisk spørsmål som “Hva i all verden skal vi med dette?” ledet i det ene tilfellet til mye tenkning rundt hvem det egentlig var som var kunden til prosjektet; interne brukere/kunder, eksterne interessenter eller eksterne kunder? Svaret var Ole Brum-aktig; alle tre.

Hovedutfordringen er å lage prosesskart som tilfredsstiller alle tre gruppene, og for å gjøre det måtte prosjektet bryte ned spørsmålet ytterligere, og se på hvilke behov det var de ulike brukerne hadde. I tilfellet interne brukere, var det å synliggjøre deres oppgaver, samt å gi dem enkel tilgang til hvilke krav som gjaldt oppgavene. For eksterne interessenter var behovet å raskt kunne se hvordan eksterne krav ble ivaretatt av interne prosedyrer, og å kunne etterprøve dette. For den siste, og kanskje viktigste gruppen, nemlig de eksterne kundene, er behovet mer indirekte. De er avhengig av at virksomheten løser sine oppgaver på en god måte, slik at kundenes egentlige behov løses mest mulig effektivt. Dette ledet til slutt til at prosessmodellene ble organisert i et hierarki, der ulike interne og eksterne interessenter og brukere sine behov ble dekket med varierende grad av detaljering. For mellomledere og eksterne kravstillere ble det opprettet oversikter over hele prosessen samt delprosesser, med tilhørende prosedyrer og krav. For sluttbrukerne av prosessen, ble det opprettet mer detaljerte aktivitetskart, som viste hvem som utfører oppgaven (med RACI-matriser som alternativ), hvilke verktøy som brukes, og hvilke kravdokumenter som hører til.

Bildet under viser et eksempel på hvordan man gikk frem for å identifisere de ulike behovene som brukerne hadde til systemet.

I det andre tilfellet, der modelleringsstandarden allerede var valgt, spilte 6W-analysen en annen, men likevel lignende rolle. Her ble spørsmålene i stedet brukt utelukkende til å definere hvilket detaljnivå man skulle legge seg på, og hvordan dette skulle realiseres i praksis. Antall nivåer var i stor grad gitt av metoden og rammeverket som var valgt, men detaljeringsgraden var opp til prosjektet. Også her har spørsmålene og problemstillingene vært mye de samme som nevnt over.

Som ekstern konsulent i slike prosjekter blir man stilt overfor en av de kanskje mest sentrale problemstillingene rundt bruken av eksterne i prosjekter. Er man leid inn som rådgiver/ekspert, eller som fasilitator? Ofte forventes det at man bekler begge rollene, selv om de i utgangspunktet er nokså forskjellige. Som rådgiver eller ekspert er oppgaven ofte å besvare spørsmålene (hvorfor, hvem, hva.. etc.), eller i alle fall gi råd om hvordan de skal besvares. Som fasilitator skal man imidlertid stille spørsmålene (og da gjerne ikke bare på en direkte måte), og fremprovosere eller hjelpe frem svar fra organisasjonen. Sistnevnte tar ofte mye lengre tid, og kan oppleves som mer frustrerende (for den eksterne), enn førstnevnte. Likevel er det som oftest den metoden som er best for kunden (dvs. virksomheten du er leid inn hos). Årsaken til dette er at kunden da (forhåpentligvis) er i stand til å selv kunne gi gode svar på spørsmålene (fordi de selv har svart på spørsmålene). Hvis svaret på spørsmålet “Hvorfor har dere dokumentert prosessene på denne måten?” er “Fordi den eksterne konsulenten sa at det var lurt”, så har man i utgangspunktet ikke gjort en god jobb som konsulent.

Dette er selvsagt en forenkling, og fremstilles litt sort/hvitt – i noen tilfeller blir man gjerne bedt om å være ekspert, og komme med anbefalinger eller ta avgjørelser basert på beste praksis eller erfaring fra andre, lignende virksomheter.Poenget mitt er å bevisstgjøre seg forskjellen på rollene som ekspert, og som fasilitator. Min erfaring er at denne rollen utfordres i stor grad i den typen prosjekter som jeg har nevnt her. Noen ganger må man hoppe fra den ene rollen til den andre, noen ganger holder det å stille de riktige spørsmålene, mens andre ganger må man skjære gjennom, og si at nå mener jeg at dere er på vei i gal retning.

Hva er svaret på det innledende spørsmålet? Både for min egen del og for kunden ble det en stasjonsvogn. I begge tilfellene ble det er kompromiss mellom robusthet og arbeidskapasitet, samtidig som det presenteres som en pakke som også ser bra ut (jeg vet ikke om jeg skal gå så langt som å kalle prosesskartene for sportslig, selv om en prosessnerd som undertegnede fant dem særs behagelige), og som har stor nok motor til at det er et morsomt arbeidsverktøy.