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.

Svømmebaner og hvordan de kan hindre romersk byråkrati

Svømmebasseng er ikke bare et problem for norske distrikspolitikere som ikke har råd til å fylle de med vann. Svømmebasseng, eller rettere sagt svømmebaner (swim lanes), er for tiden tema for debatt innen prosessfaget. Bloggeren Mike Gammage har i en serie innlegg satt fokus på bruken av svømmebaner, og mener at man kan kvitte seg med svømmebanene i prosesskart (se og så her og her).

Hva er så disse svømmebanene? I notasjonsstandarden BPMN vises den utførende rollen som en svømmebane, slik det er vist i modellen under.

Denne måten å vise hvem som gjør hva gir en grei oversikt, og er, gitt at man utviser litt moderasjon i modelleringen, noenlunde lettfattelig. Gammage på sin side, bruker en analogi, og viser til at i et orkester, så har hver musiker kun sine noter, og ikke alle andre sine. Det henvises til at dette er det mest effektive, og han mener blant annet dette er en god grunn til at man bør kvitte seg med svømmebaner. Et vanlig argument mot BPMN som notasjonsform er at det er for vanskelig for vanlige forretningsbrukere å forstå notasjonsformen (se blant annet Jim Sinnurs brannfakkel – se også dette innlegget som en oppfølger) . Og det er her jeg begynner å bli uenig, både i analogien og at BPMN skal være så vanskelig å forstå.

For å ta det siste først. Dersom man bruker alle symbolene i BPMN 2.0, og modellerer med utgangspunkt i at modellene skal være i henhold til f.eks. Process Execution Conformance, så er det klart at det er for mange symboler, og for mange regler å ta hensyn til at det blir praktisk for “vanlige” brukere. Det er imidlertid et fåtall av bedrifter som ser hensikten med å velge en så streng tolkning av BPMN (standarden åpner for langt mildere tolkninger). Hovedpoenget med å dokumentere prosesser i Karabins prosjekter pleier å være et ønske om å A) kunne dokumentere prosessene som et ledd i f.eks. en ISO-sertifisering, B) dokumentere prosesser for å forbedre dem, eller C) dokumentere og harmonisere prosesser (f.eks. ved oppkjøp, eller der det er ulik praksis på tvers av ulike produktområder). Og det er her analogien om orkesteret til Gammage begynner å låte surt i mine ører.

Litt av poenget med en prosessorientert virksomhet, er nettopp å unngå silotenkning. Denne silotenkningen oppstår i mange tradisjonelle, hierarkiske organisasjoner, og kjennetegnes best ved at man tenker at “dette er ikke vår avdeling, eller vårt team sitt ansvar”. NAV er et godt eksempel; der man på lokalkontorene unnskylder seg med at “ja, nei, nå har de som sitter på forvaltning gjort en feil”, eller når man ringer til kompetansetelefonen til forvaltning så får man beskjed om at lokalkontoret ikke har samlet inn tilstrekkelig med dokumentasjon. En god illustrasjon på hvor lett det er å bli en kasteball i et slikt system kjenner sikkert de fleste fra Asterix. Hva er poenget mitt? Jo; poenget er såre enkelt. For prosessens kunde (enten det nå er en utålmodig far som venter på foreldrepenger eller en stadig mer frustrert galler) så er det irrelevant hvem sin feil det er. Hovedpoenget overfor kunden er å gi kunden det han eller hun ønsker, ikke om det er din eller de andre i den og den avdelingen sin feil. Eller for å bruke orkesteranalogien; som tilhører så er ikke jeg opptatt av om det er solisten eller fjerdefiolinen som spiller surt. Denne prosessorienteringen får man ikke til ved å fokusere på hva hver enkelt skal gjøre, men ved å fokusere på hva de ulike rollene gjør i sin samhandling for å tilfredsstille kundens behov.

Min erfaring fra prosessarbeid i Karabin, er at prosessarbeid med fokus på roller og overleveringer mellom roller, hjelper på problemene som er nevnt over. Ved å sette sammen en arbeidsgruppe bestående av mennesker som faktisk utfører oppgavene som skal kartlegges, og diskutere seg gjennom prosessen, oppnår man resultater. Små, enkle grep, som det å kartlegge en prosess både fra den overleverende enheten sin side, og fra den mottakene enheten (f.eks. en utviklingsavdeling og en innkjøpsavdeling), løser man kanskje småproblemer som begge har følt har vært et irritasjonsmoment.  Et viktig verktøy i denne sammenhengen er nettopp muligheten til å visualisere hvem det er som gjør hva; og jeg har fremdeles til gode å se et alternativ som er bedre enn svømmebanene.

På samme måte som norske skolebarn har nytte av basseng med vann for å lære seg å svømme, har norske (og utenlandske) bedrifter behov for svømmebaner for å forbedre sine prosesser. I alle fall så lenge man ikke har litt styrkedrikk på lur.

Hvordan velge riktig modelleringsstandard og metode

Noen valg er enkle, andre er verken enkle å foreta eller å leve med i etterkant, men er likevel nødvendige. Valg av modelleringsstandard og i forlengelsen av dette, valg av overordnet filosofi og metode for prosessarbeid, kan ved første øyekast virke relativt enkelt. “BPMN er en bransjestandard, la oss gå for den” – tenker man kanskje. Fullt så enkelt er det likevel ikke, og velger man feil, kan det vise seg å være både kostbart og vanskelig å leve med i etterkant. Jeg delte tidligere i sommer en link på Karabins twitterfeed til en artikkel på Aris Community, kalt “Don’t leap into modelling – think about your customers first!!”. Artikkelen tar for seg en del sentrale spørsmål som man ofte glemmer i iveren etter å starte modelleringen. Disse er:

1. Hvorfor modellerer du?
2. Hvem er kundene til prosessmodellene?
3. Hva er det du modellerer?
4. “Når” er det du modellerer?
5. Hvor skal modellene brukes?
6. Hvordan skal du modellere?

Dette er gode spørsmål som fortjener mer oppmerksomhet enn de får i de fleste prosjekter. Grunnen til dette er at svarene på hvert av spørsmålene vil legge føringer for både hvilken modelleringsstandard du bør velge, og for metoden du bør bruke i modelleringsarbeidet. I tillegg vil omfanget og typen modellering kunne bestemmes ut fra det du kommer frem til. Dersom du f.eks. på spørsmål 1 svarer at din virksomhet skal modellere fordi man ønsker å få oversikt over prosesser i virksomheten med tanke på strategiarbeid eller lignende, er det ikke nødvendig å dokumentere prosessene med samme detaljeringsnivå som f.eks. dersom du ønsker å dokumentere en arbeidsprosess som en del av en kravspesifisering av et nytt system.

Et annet moment som ofte oversees er også hvem kundene til modellene er. Hvem skal bruke modellene, og til hva? Skal modellene primært brukes i et kvalitetssystem på overordnet nivå, og vises på store skjermer på et kontor? Eller skal de brukes operativt i felten, og vises på små håndholdte PDA ‘er? Og ikke minst, hvilket detaljnivå og hvilke tilleggsopplysninger trenger den som skal bruke kartene? Er det interessant for brukeren at det er linket opp maldokumenter til aktiviteten “Fyll ut reiseregning i henhold til mal” slik at malen kan åpnes rett fra kartet?

Spørsmål fire er også et viktig valg. Med “når” menes det her hvorvidt man tar sikte på å modellere situasjonen slik den er i dag (såkalt “as is”) eller om det kun er den ønskede, fremtidige, situasjonen som skal modelleres (“to be”). Eventuelt begge to? Vi anbefaler ofte våre kunder å begynne med “as is” for å identifisere mulige forbedringsmuligheter, men dette vil avhenge av hva virksomheten har av prosesskart og dokumentasjon, og ikke minst kvaliteten på denne dokumentasjonen. Et annet spørsmål er hvorvidt kartene skal vedlikeholdes, og med hvilket tidsintervall? Prosessforvaltning er et omfattende tema, og noe jeg skal komme tilbake til i et annet innlegg, men kvaliteten på dokumenterte prosesser vil sannsynligvis forringes dersom kartene ikke vedlikeholdes. Kontinuerlig forbedring betyr nettopp at et forbedringsarbeid ikke stopper opp, men går i en syklus.

Sist men ikke minst temaet jeg tok opp innledningsvis. Hvordan skal du modellere, og med hvilken standard? Det finnes mange forskjellige modelleringsstandarder, og valget er kanskje ikke alltid like enkelt. Spørsmålene over kan imidlertid være til god hjelp. Temaet er også tatt opp i diverse forskning, blant annet anbefales Ila Biders “Choosing Approach to Business Process Modeling - Practical Perspective”. Karabin holder for tiden på med flere spennende prosjekter knyttet til valg av modelleringsstandard og utvikling av virksomhetsmodellering. I den grad det er mulig vil vi prøve å dele noen erfaringer her på bloggen på sikt.

Microsoft entrer BPM-markedet med Visio 2010 og SharePoint 2010

Noen ganger blir jeg i overkant entusiastisk, noe som vanligvis blir godt mottatt blant venner og bekjente. Denne gangen ble jeg imidlertid møtt med en blanding av lett skepsis og morsomheter på min bekostning da jeg midt under heftig krigføring på Østfronten, ca 1940 (vi var en gjeng samlet for å spille Axis &Allies, et meget fornøyelig strategispill) kommenterte at Microsoft nå hadde sluppet Visio 2010. Det ble kommentert at “jaha?” og jeg tok selvsagt dette som en oppfordring til å utbrodere om de funksjonene som jeg fant fornøyelige i den nye utgaven av Visio. Jeg lærte, om ikke annet, at ikke alle er like entusiastiske når det gjelder Visio, som det vi som bruker det daglig er..

Men til saken. Visio 2010 er sluppet, og for mange vil dette være en god nyhet. En av funksjonene jeg har blitt mest glad for, er at tegneområdet nå utvider seg automatisk (!). I tidligere versjoner har man vært begrenset til et område på størrelse med et A4-ark, som man riktignok har kunnet tegnet utover, men arket har ikke utvidet seg.



Som det fremkommer av bildene over, så utvider nå tegneområdet seg dynamisk etter hvert som du trenger mer plass. Dette høres kanskje banalt ut, men jeg vil tro at de fleste som har sittet i et kartleggingsmøte og gått “tom” for tegneplass vil føle som meg og flere andre kolleger har gjort, en barnslig glede over at Microsoft endelig har hørt på oss.

Av andre nyttige funksjoner kan det nevnes at Visio nå støtter modellering med BPMN, selv om det er litt skuffende at de bare støtter versjon 1.2, og ikke 2.0. Funksjonaliteten er imidlertid på plass, så det er vel muligheter for at støtte for 2.0 kommer i en senere oppdatering. Skulle man være så heldig å ha Premium-utgaven av Visio så har man mulighet til å sjekke at logikken i modellene er riktig i henhold til standarden. Foreløpig finnes det ikke noen innebygget simulator (mulighet for å simulere og evaluere prosessene for å vise kostnader, flaksehalser eller lignende), men det er allerede ute tredjepartsløsninger som lar deg gjøre dette, så det er håp. Koblet med SharePoint 2010 og funksjonen “Visio Process Repository” (et bibliotek for å lagre prosesskart) så ser det ut til at spådommene om at Microsoft er på vei til å ta steget mot å bli en BPM-aktør er godt på vei til å bli oppfylt. En oversikt over noen av bruksområdene finnes her – jeg ser i alle fall at det vil gjøre det relativt enkelt å tilgjengeliggjøre prosesskart og drive med prosessforvaltning på en plattform mange bruker som intranett . Selv kjenner jeg at jeg gleder meg til å få satt opp et testmiljø med SharePoint 2010 for å sjekke ut denne funksjonaliteten, men jeg har etter hvert skjønt at jeg er litt yrkesskadet i så måte.

Mulighetene er i alle fall til stede med verktøy som finnes i mange bedrifter, eller som sannsynligvis kommer til å finnes i mange bedrifter. Så er spørsmålet, vil dette være med på å senke terskelen for å få på plass kartlagte og optimaliserte prosesser og prosessforvaltning? Om noen har planer om eller erfaringer med (kanskje litt tidlig for erfaringer ennå) dette så vil vi gjerne høre fra dere.

5 spådommer om Business Process Management

Analyseselskapet Gartner har i en nylig utgitt rapport beskrevet 5 spådommer om Business Process Management (BPM). I rapporten skriver Gartner blant annet at

”i løpet av 2014 vil 40 % av ledere og kunnskapsarbeidere i verdens 2000 største selskaper bruke prosessmodeller (business process models) for å kunne utføre sin jobb. Dette er opp fra 6 % i 2009”