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.
Skrevet av
Robert Lohne den 6 Jul 2011
1 kommentar »
I vårt arbeid med prosessforbedring får vi ofte spørsmål om ;” hvordan skal vi organisere oss for å få det optimale ut av våre prosesser ?”
Dette er i seg selv et meget godt spørsmål, og ikke minst et spørsmål som kan være vanskelig å besvare, uten videre.
La oss først drøfte litt om prosesser.
Vi omtaler ofte fredsprosesser, rettsprosesser og prosessindustri men, når vi snakker om en organisasjons prosesser, snakker vi om en logisk sammensatt kjede av aktiviteter som alltid har en kunde, den anvender interne og i de fleste tilfeller eksterne ressurser, den har en definert start og slutt.
Det viktigste er at den tilfører en nytteverdi for kunden, og man kan på enkle måter måle effektivitet, kunde og medarbeidertilfredshet i prosessen.
Uansett om vi ”tror” på prosesstankegang eller ikke, så eksisterer prosessene i alle organisasjoner.
Dette betyr altså at vi kan jobbe som ”vanlig” i den hierarkisk oppbygde organisasjonen, med murer mellom avdelinger og enheter og håpe på at vår tverrfunksjonelle prosess fungerer, eller etablere prosessforståelse og forsøke å forbedre dem, til beste for kunden, medarbeidere og samfunnet.
I tradisjonell hierarkisk organisering, er avdelingsgrensene basert på kompetanseområder, man setter sammen team med medarbeidere med spisskompetanse og sørger for at avdelingen utfører en fagmessig optimal jobb.
Problemet er som oftest at avdelingene ikke klarer eller ønsker å se sitt bidrag i de overordnede målsetningene for bedriften som helhet.
Ved å synliggjøre prosessene i organisasjonen får ledelse og medarbeidere mange muligheter;
- Det skapes oversikt og man fokuserer på resultatet av prosessen, til kundens beste.
- Man får oversikt over hvor prosessen ikke fungerer, man kan umiddelbart gjøre forbedring
- Man kan måle effektivitet/ kvalitet og finne flaskehalsene i prosessen
- Entydig ansvar ved etablering av prosesseierskap
Den hierarkisk oppbygde organisasjonen har normalt sine overordnede resultat målsetninger, det finnes knapt noen uten.
Avrapportering i forhold til de finansielle målene gjøres flere ganger i året, i de fleste tilfeller er dette historiske tall som er umulige eller i beste fall vanskelig å påvirke.
I tillegg til å være historiske, er resultatene ofte et resultat av mange faktorer.
Dette medfører at man må gjennomføre tunge analyser før man får en viss anelse av hvor man skal gjøre forbedringene.
I en prosessbasert organisasjon, hvor prosessene er dokumentert bør man gjøre kontinuerlig måling, dette gjør det mulig å benytte enkle forbedringsverktøy for å forbedre prosessens ytelse.
Prosesseier skal altså sette sine mål for prosessen og ved involvering av medarbeidere sørge for en kontinuerlig forbedring som gir umiddelbare resultater.
Mange har hørt om Lean og Six Sigma, dette er verktøy som benyttes for å øke prosessenes ytelse.
Vi bruker Lean til å strømlinje prosessen, fjerne ikke verdi skapende aktiviteter og etablere best practice, six sigma benytter vi da en prosess har stor prosessvariasjon og det er ønskelig å redusere denne.
I den globaliserte verden, er det alltid områder av verden som kan produsere og levere billigere varer enn i en høykost land som Norge.
De organisasjoner som ikke utnytter den samlede kompetanse i sin bedrift, vil på et tidspunkt ikke unngå å bli utkonkurrert.
Organisasjoner som lever i såkalt ikke konkurranse utsatt område vil stadig få økte krav på andre måter, eks. kundetilfredshet eller krav om å klare seg med reduserte bevilgninger.
Mitt råd er derfor helt entydig ;
Dokumenter dine prosesser.
Forbedre dine prosesser, gi prosesseier ansvar og myndighet til å sette prosessmål.
Gjør organisasjonen forandringsvillig ved medarbeider involvert prosessforbedring.
Skrevet av
willy den 1 Mar 2011
Ingen kommentarer »
Hvem har ikke lyst til å komme på jobb, skru på pc’en, få en oppdatering rundt siste interne og eksterne utviklinger – som automatisk oppdaterer den eneste KPI’en man trenger – for å kjenne pulsen på sin egen organisasjon? KPI’en behøver ikke være perfekt, men den skal gjerne dekke de berømte 80 %. Resten kan vi flyte på med erfaring og dyktige mennesker rundt oss.
I noen bransjer eller virksomheter er det kanskje mulig å lage en perfekt KPI. Kanskje er det kombinasjonen av en råvarepris, omløpshastighet og kapitalbinding som sier oss om vi er på rett vei. For andre er det kombinasjoner av kroner/volum (eller kanskje motsatt siden vi ønsker å se en positiv utvikling) og salg siste periode som er den perfekte KPI. For de fleste andre er det derimot vanskelig å finne et enkelt måltall som vi kan styre etter. Resultatet blir at vi må forholde oss til et utvalg av forskjellige måltall, som i sum skal fortelle oss hvordan butikken går. Utfordringen da blir i første omgang å finne ut hvilke måltall som er vesentlige for oss. Har virksomheten en strategi eller virksomhetsplan som kan brytes ned til KPI’er? Det er en god start. Da kan vi videre få alle underavdelinger til å bygge sine egne målinger til noe som bidrar til den overordnede oversikten.
Dersom man får på plass en effektiv målstyring oppnår man flere fordeler. Jeg vil her nevne to eksempler:
- Du vil ha svar. Du vil alltid kunne forklare hvilke deler av prosessen som går godt og hvilke steder skoen trykker. Det grafiske bør i tillegg til dagens status inneholde historiske tall for å vise utviklingen, men også hvordan man utvikler seg i forhold til fastsatte mål
- Vi har nå lagt grunnlaget for hvordan hele organisasjonen kan se konkrete resultater av sine forbedringer. Ved at målstyringen er gjennomgående i hele organisasjonen vil alle medarbeiderne kunne se hvordan egne initiativer og prestasjoner påvirker resultatene. Erfaringen vår viser da økt eierskap blant alle, økt entusiasme, lavere sykefravær og bedre resultater. Det kan vi leve med.
Det forhindrer oss ikke fra å drømme om den perfekte KPI. Den ene. Kanskje den finnes.
Et Google-søk på ”Lean” på norske internettsider gir oss over 150 000 treff. Det er ingen tvil om at Lean er pop. Både sykehus, bilverksteder, bredbåndsleverandører og saksbehandlere i offentlig forvaltning tar i bruk ”The Toyota Way” for å løse sine særegne problemer. Oppskriften er tilsynelatende enkel (den kan sammenfattes i en bok), og den er oversiktlig (det finnes 7, alternativt 8 eller 9 typer sløsing).
Kombinasjonen av at veldig mange driver med Lean og at det ikke finnes noen beskytter av Lean som begrep, sier meg at ikke alle Lean-initiativ har like mye med Lean å gjøre.
I dette blogginnlegget fra 2007 irriterer Mark Graban seg over at mange LEAN-prosjekter egentlig er LAME-prosjekter. Med LAME refererte Graban til “Lean As Misguidedly Executed” eller eventuelt “Lean As Mistakenly Explained”.
Mer interessant for beslutningstakere er funnene til analyseselskaper som Aberdeen Group, som skiller mellom ordentlig Lean på den ene siden, og sløv Lean på den andre, når effektene av Lean-initiativer skal summeres opp.
Nå er det kanskje lettere å definere hva ekte Six Sigma er, enn hva ekte Lean er. I Aberdeen Group sin ”Lean Six Sigma Benchmark Report” fra 2006 poengteres det at virksomheter som bruker Lean og Six Sigma sammen, oppnår 40 % høyere besparelser hvis initiativene er ”ekte” enn hvis de ikke er det.
Med ekte Six Sigma mener Aberdeen Group at virksomheten (1) har et formelt etablert Six Sigma program, (2) bruker DMAIC som metode, (3) bruker Black Belts og (4) krever at alle effekter skal kunne måles finansielt.
Det er selvfølgelig umulig å si at det finnes en måte å bli Lean på, som er bedre enn alle andre. Vi vil likevel driste oss til å liste opp noen faktorer det er lett å glemme i kampens hete:
- Lean handler om å se verdikjeden fra ende til ende. Å optimalisere en og en del av verdikjeden hjelper deg ikke til å skape den såkalte ”pull”-effekten hvor kunden eller tjenestemottakeren styrer produksjonen eller saksbehandlingen.
- Det er de som gjør jobben som skal forbedre den. Den perfekte prosess kan ikke finnes opp av ledere eller faglig sterke kvalitetsmedarbeidere, for så å bli implementert i linjen.
- Lean må være målstyrt. Det er mulig å fikse alt, men fiksingen bør begrense seg til ting som er viktig for virksomheten.
- Lean tar tid. De virkelig store effektene av Lean kommer når hele virksomheten tenker og gjør Lean. Slikt tar tid.
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.
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:
- Hvorfor modellerer du?
- Hvem er kundene til prosessmodellene?
- Hva er det du modellerer?
- “Når” er det du modellerer?
- Hvor skal modellene brukes?
- 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.
Skrevet av
Robert Lohne den 13 Aug 2010
1 kommentar »
Jeg har sittet på en tue. Jeg har sittet på flere tuer. Og jeg har sittet der ganske alene. Ikke fordi ingen ville holde meg med selskap, men fordi ingen skjønte at det kunne være hyggelig å sitte sammen. Eller at det som så ut som en liten tue med dårlig plass, egentlig bare trengte å etablere en forbindelse til de andre tuene for å bli en blomstereng som alle kunne leke på. Men det er jo vanskelig å vite når man sitter alene på sin tue.
I mine år i det offentlige før jeg begynte i Karabin har jeg utført flere forbedringsprosjekter for egne arbeidsprosesser. Med ledere som hadde primærfokus på at arbeidsoppgavene ble utført, gjerne raskere og raskere, var det ofte en takknemlig oppgave å utarbeide nye prosesser og utvikle egne små systemløsninger som fikk oppgavene til å gå glattere, ga raskere svar til de som henvendte seg utenfra, og kuttet drastisk i andel feil (og dermed også feilkorrigeringer). For ikke å snakke om hvor enkelt det plutselig ble å hente ut data som viste noe om trendene i tjenestebehovene og –utførelsen. Som sagt, takknemlig å kunne levere oversikt og trygghet for at oppgavene ble ivaretatt på en bedre måte enn tidligere.
Men så snart kontrollen over de aktuelle prosessene var nådd, så åpenbarte et nytt og større bilde seg. Forbedringspotensialet begrenset seg! Kontinuerlig forbedring er jo et mantra i vår bransje, men når man sitter på sin tue kommer man til et punkt hvor forbedringen blir avhengig også av hva slags input og output prosessen har, ikke bare de aktivitetene som berører den enkelte rollen. Sagt på en annen måte – omgivelsene til tuen påvirker hvor fin den egentlig kan bli. Og da hjalp det lite at tuen min var fin og grønn og med mulighet for utvidelse. For det var jo helt bart og brunt rundt, og avstanden til de andre tuene føltes veldig lang.
Og det er her man møter et grunnleggende problem i ”uorganisert” forbedringsarbeid. Man kommer bare så langt med ildsjeler og selvstendige initiativ, og man kommer bare så langt med systemforbedring. Så lenge man ikke ser prosessen i et helhetsperspektiv og jobber med forbedring i hele flyten, så vil man komme til et punkt hvor forbedringen stopper opp. Og da kan tuen man sitter på være så grønn den bare vil.
For når man tenker på det, så er det jo ikke så fint med tuer. Jeg foretrekker i hvert fall store grønne blomsterenger. Og for å trekke metaforen helt ut – får man tuene til å henge sammen, kan man få den deilige sommerfølelsen en fargerik blomstereng kan gi. Og sånn er det med prosessforbedring også – jobb med områdene mellom rollene og aktivitetene, så vil man på sikt få til et miljø som er bedre for alle (kanskje med unntak av stakkarer med pollenallergi ;-)
Dagens lille solskinnsperspektiv på LEAN og prosessforbedring.
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.
Skrevet av
Robert Lohne den 19 May 2010
3 kommentarer »
Dårlige ordspill i tittelen til tross, aviser og andre medier har den siste tiden vært fulle av historier og artikler om ulike mennesker hvis store mål for helgen vi nettopp har lagt bak oss har vært å slite seg gjennom 54 km på ski. Hvor mange som går turen for å minne birkebeinernes ferd med den unge kongssønnen skal jeg ikke mene noe om, men det jeg imidlertid skal mene noe om et oppslag i e24 forrige fredag, forøvrig også gjengitt i Ukeavisen Ledelse. Organisasjonspsykolog Jan Christophersen er sitert på følgende utsagn:
“Lederen må legge ned masse tid på kropp, teknikk og utstyr som fremmer ham eller henne som en ensom, sterk, utholdende utøver, sier Christophersen, som synes ledere burde bruke mer tid på å utvikle seg som ledere”
Videre uttaler Christensen det at dersom norske ledere hadde lagt ned halvparten så mye innsats på å utvikle lederskap som de gjør på Birken, så ville norske ledere vært i verdenstoppen. Og at dette nok handler mer om ledernes behov for eksponering enn om å vise tydelig lederskap.
Grunnen til at man velger å gå ut med et slikt utspill vil jeg tro er den siste tids oppslag om hodejegere som anbefaler å sette deltakelse i Birken på CVen, og oppfattelsen om at deltakelse er en god metafor på lederskap. Om dette sier Christensen ”Det er jo bare tull og stemmer ikke. Lederskap handler om team og samarbeid”.
Jeg er enig med Christensen at det neppe bidrar til lederutviklingen å delta i Birken eller andre, tilsvarende styrkeprøver. Det jeg derimot mener Christensen enten misforstår eller velger å ikke legge vekt på, er at det kanskje ikke er lederutviklingen som er den viktigste effekten av å delta, og at det heller ikke er derfor lederne velger å bruke så mye tid på Birken. Jeg mener deltakelsen handler vel så mye om to andre ting. Christensen er inne på det ene, eksponering, det er vel ikke urimelig å tro at lederne mener at det å delta i en styrkeprøve, der enslige menn og kvinner på vei over fjellet kan gi assosiasjoner til Nansen og Amundsen, kan gi en positiv symboleffekt.
Og det er nettopp det jeg mener dette hovedsakelig handler om. Symboler. Ledere er mer enn bare en funksjon, de fyller noe mer enn bare det tekniske ved å lede sine ansatte og drive med teambuilding og samarbeid. Mye av det lederne gjør handler om mer enn bare rasjonelle handlinger og ting som kan knyttes til håndfaste resultater, slik blant annet Torodd Strand er inne på i sin bok, “Ledelse, organisasjon og kultur” (2007).
Når det å delta i fysiske styrkeprøver får så mye oppmerksomhet (blant annet godt hjulpet av Dagens Næringsliv og andre medier), blir det å delta i slike styrkeprøver nærmest en nødvendighet for toppledere. Grunnen er langt enklere enn de faktiske resultatene for lederskapet (og som Christensen er inne på, de er kanskje ikke så store). Det handler etter min mening hovedsakelig om å fremstå som legitim overfor sine omgivelser. I likhet med organisasjoner som adopterer nye trender innenfor organisasjonsformer og ledelse, uten nødvendigvis å implementere dem på et dypere plan - i følge sosiologene John Meyer og Brian Rowan (1977) nettopp for å fremstå som legitime i omgivelsenes øyne – så gjør lederne det som de ser at andre ledere gjør, de deltar i Birken og andre styrkeprøver. Det å delta i slike konkurranser har fått en mening ut over selve deltakelsen, det har rett og slett blitt institusjonalisert.
Også skal man vel heller ikke undervurdere effekten av det som konsernsjef i Terra, Stein Ole Larsen tar opp, “Vi er hundre fra Terra som går Birken. Jeg tipper at de fleste har hatt en mål (sic) om å slå meg, og de har de nok klart” (DN 22. mars). Hvem har vel ikke lyst til å slå sjefen?
Hva mener dere? Er det riktig å delta i Birken? Har det noen effekt? Følg og svar også på Erik Sontums twitterpoll her
Jeg har i Karabin jobbet særlig mye med anskaffelser av IKT i offentlig sektor, det jeg velger å beskrive som prosessorientert systemanskaffelse. Med min kompetanse på og interesse for forvaltningen av ressursene i det offentlige, ser jeg med spesiell interesse på utviklingen innen utnyttelse av IKT for forbedring av offentlig tjenesteyting. Opprettelsen av Difi, og satsingen innen standardisering, samordning og MinID for å nevne noe, legger til rette for store forbedringer innen offentlig tjenesteyting og utnyttelsen av ressursene i det offentlige ved hjelp av IKT. Og med ferske resultater fra innbyggerundersøkelsen fra Difi som viser at 58 % mener at det offentlige sløser med ressursene, er i hvert fall jeg motivert for å bidra i de prosjekter jeg er involvert i!
Et nytt paradigme er i ferd med å definere den moderne styringen av offentlig sektor, og kalles Digital Era Governance (DEG). Dette avløser den perioden som er blitt kalt New Public Management (NPM). Dette er en holistisk, eller helhetlig, måte å tilnærme seg offentlig styring, hvor man utnytter digitalisering til både å kutte kostnader og forbedre tjenestetilbudet. Dette er i tråd med det vi ser hos noen av våre kunder i offentlig sektor. Jeg vil hevde at å utnytte moderne teknologi og digitale medier legger til rette for å kunne oppnå stor forbedring innen offentlig tjenesteyting, men verktøy løser jo ikke oppgaven av seg selv.
Teknologi er kun en muliggjører, og gir verken endring eller revolusjon i seg selv. Endringen til det bedre vil kun skje dersom man ikke bare anskaffer teknologien, men også utnytter denne på riktig måte for å hente ut de gevinstene som var målet for anskaffelsen av teknologien. Og det er her jeg bringer prosessperspektivet på banen. ”Hvis du gjør som du alltid har gjort, får du som du alltid har fått”. Hvis du anskaffer et system på bakgrunn av din gamle måte å jobbe på og ditt gamle tankesett, kan du ende opp med i alle fall to ulike scenarioer. Enten bli tvunget til å gjøre endringer i arbeidsmåter ut fra hvordan systemet er bygget opp, eller rett og slett ikke klarer å utnytte systemet du har anskaffet da denne tilpasningen mellom eksisterende arbeidsprosess og nytt system ikke fungerer. Det er slettes ikke uvanlig å bygge nye løsninger opp basert på eksisterende skjemavelde for tjenesten… Ikke det beste utgangspunkt for forbedring slik jeg ser det.
Det blir og så et valg mellom å ha sin egen organisering i den offentlige avdeling/enhet/etat i fokus, eller å dreie mot et brukerfokus. Min påstand er at få anledninger vel passer bedre til å jobbe med endring og forbedring av dette enn ved anskaffelsen av nye systemer og webløsninger. Hva som initierer en anskaffelse er jeg ikke så opptatt av, for det kan være flere grunner. Det kan være å oppfylle statlige lover og regler (compliance), eller at virksomhetens egne målsetninger og strategier ligger til grunn. Det jeg er mest opptatt av er at prosessorientering og brukerfokus samkjøres med anskaffelser av system og webløsninger.
Budskapet mitt er derfor at skal man oppnå faktiske resultater og kunne realisere de store gevinster ved anskaffelse av nye systemer eller webløsninger for å forbedre tjenesteyting i offentlig sektor, må man bevege seg vekk fra silotankegangen og fokusere på prosessen som fører frem mot den tjenesten brukeren skal motta i andre enden. Altså har brukeren i fokus! Dette vil kreve at man tenker og samhandler på tvers av avdelinger og etater i stat og kommuner, og på tvers av organiseringen i egen organisasjon. Dette gir helt klart utfordringer, blant annet i forhold til finansiering av anskaffelser og hvordan utøve sitt formelle ansvar når en tjeneste leveres av flere avdelinger/enheter/etater i det offentlige.
Det var på NOKIOS 2009 gledelig å se hvordan Skattedirektoratet hadde prosessperspektivet til grunn for sin utvikling av eDialoger (strukturerte elektroniske arbeidsprosesser), som var så i tråd med min egen oppfatning. Jeg ser med spenning frem til å følge denne utviklingen videre!
Jeg er veldig interessert i å høre tilbakemeldinger på dette, og tenker at utfordringer med brukerfokus og prosessorientering ved anskaffelser av systemer og webløsninger nok ikke er særskilt knyttet offentlig sektor heller, men er like aktuell for private virksomheter.
