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.

Når Lean blir Lame

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:

1. 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.
2. 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.
3. Lean må være målstyrt. Det er mulig å fikse alt, men fiksingen bør begrense seg til ting som er viktig for virksomheten.
4. Lean tar tid. De virkelig store effektene av Lean kommer når hele virksomheten tenker og gjør Lean. Slikt tar tid.

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.

Sosiale medier og internkultur i et prosessperspektiv

Jørgen Dalen i Halogen spør om det er noen som har kartlagt organisasjoner i forbindelse med sosiale medier, og lurer på følgende:

Det blir gitt mange motstridende råd om hvordan man skal lykkes med sosiale medier internt i organisasjoner (Enterprise 2.0). Enkelte hevder at verktøy som mikroblogging og kunnskapsnettverk bør tas i bruk uten alt for mye styring, mens andre påstår at det krever store endringer av organisasjon og ledelse for å kunne lykkes. Hvem har rett?

Vi i Karabin har riktignok ikke kartlagt noen organisasjoner spesifikt i forbindelse med sosiale medier, men vi har etter hvert kartlagt mange organisasjoner. Jeg tenkte derfor at jeg skulle forsøke å se spørsmålet i lys av det perspektivet vi mener vi kan best, og som vi bruker mest, nemlig prosessperspektivet.

Jeg skal ikke påberope meg noen ekspertise innenfor sosiale medier, så her må andre gjerne korrigere meg; men jeg mener at både sosiale medier og organisasjoner som er prosessorienterte må og bør ha samme fokus, nemlig kunden eller brukerne. I et prosessperspektiv kan kundebegrepet like gjerne brukes om personer eller enheter internt i organsiasjonen som eksterne kunder.

En av tankene med å prosessorientere en organisasjon, er “å rette fokus mot hvordan medarbeidere fra ulike enheter samarbeider om felles oppgaver” (Iden 2005: 15). Dette perspektivet, hvor man i praksis prøver å se organisasjonen fra siden, er en annerledes måte å se på organsiasjoner på. Tradisjonelt har man gjerne sett på en organisasjon som et hierarki, med ulikt antall nivåer, men ofte med et gitt antall avdelinger, enheter, og med en leder på toppen av hver av disse avdelingene. I et prosessperspektiv sees det imidlertid på hva det er man produserer, hvordan det blir produsert, hvem er kundene til prosessen, og hvordan behandler vi dem? Figuren under illustrerer hvordan denne måten å følge kunden fra et behov oppstår, til kunden har fått oppfyllt sitt ønske, gjerne tar oss innom flere av organisasjonens enheter eller avdelinger.

En av de tingene vi ofte ser når vi er ute og kartlegger organisasjoner i forbindelse med prosessprosjekter, er nettopp den tradisjonelle måten å se sin egen organisasjon. Bedriften er ofte organisert i avdelinger, og det er ofte sine egne prosesser man kjenner best. Det er selvsagt en grunn til dette, men av og til kan det være hensiktsmessig å kjenne til hvordan andre utfører sine arbeidsoppgaver, og ikke minst, hva de har behov for av informasjon og hva de forventer av deg for at de skal kunne utføre neste steg i prosessen. Når man får denne felles forståelsen, er man et godt steg på veien til å oppfylle det viktigste for bedriften, nemlig en fornøyd kunde.

Og da er jeg fremme ved skjæringspunktet til sosiale medier og bruken og oppbyggingen av interne kunnskapsnettverk. Det vi har erfart i vårt arbeid med prosesskartlegging, er ofte at en av grunnene til at det kan være vanskelig å se helheten i prosessen, i stedet for sin egen del av den, skyldes særlig to ting. Den første er at man fremdeles tenker avdelinger, og ikke prosess. Den andre er mer relevant i denne sammenheng, nemlig mangelen på et felles forum der man kan diskutere slike ting, og dele kunnskap om hva er det vi driver med, og hvorfor. Kan sosiale media fylle denne rollen, og gjøre internkommunikasjonen lettere og mer oversiktlig?

Vår erfaring med bruk av sosiale medier internt i Karabin viser i alle fall at det er utfordringer knyttet til dette. Delvis skyldes det som nevnt i Jørgen Dalens innlegg, at det må signaliseres at dette er noe det er ok å bruke tid på, men i større grad tror jeg det handler om graden av opplevd nytte. Hvorfor skal jeg bruke tid på noe jeg ikke føler er nyttig for meg i min arbeidshverdag? Jeg har noen ganger vært ute for den samme innledende tanken hos kunder vi har kartlagt. “Hvorfor skal jeg bruke tid på å gjøre meg kjent med andres arbeidsoppgaver og behov i forhold til dette?” tenker man gjerne. Jo, nettopp fordi dersom hele organisasjonen er opptatt av dette, så er det andre som er opptatt av hva du trenger av informasjon for å gjøre dine ting enklere. Og ikke minst, de får gjerne forståelsen for hvorfor dette er viktig for deg. Dersom man får til en slik delingskultur, så vil det kunne føre til bedre prosessforståelse, og kanskje kan sosiale medier være et verktøy.

Jeg tror derfor at man i kartleggingen av den interne kulturen i forbindelse med sosiale medier kan benytte mye den samme tilnærmingen som man gjøre i en prosesskartlegging. Hva er det bruken av de sosiale mediene skal føre til (hva produserer vi), hvordan skal vi gjøre dette (hvordan blir det produsert?), hvem er mottakerne av det som kommuniseres (hvem er kundene?) og hvordan kommuniserer vi med dem (hvordan behandler vi kundene våre?).

Hva tenker dere som jobber med sosiale medier om en slik tilnærming? Enig? Uenig?

Skreddersydd CRM løsning

Karabin har siden oppstarten i 2005 benyttet Microsoft Sharepoint som hovedverktøykasse. Sharepoint har vært brukt til blant annet

• Tradisjonell intranett med nyheter, kontaktinformasjon, dokumenter, interne prosjektsider, avtaler og mye mer
• Ekstranett/samhandling, hvor våre kunder har hatt tilgang til våre prosjektområder
• CRM system (system for potensielle kundeemner, salgsrapportering og kundehåndtering)

Høsten 2009 innså vi at vi trengte et bedre system til å håndtere kundedialog i forhold til salg og avtaler. Sharepoint fungerte til vårt forhold, men vi oppdaget at det også var svært sårbart. Hva skjer hvis en av våre kundeansvarlige ble syk? Har andre tilgang til all dialog (møter, telefoner, kontaktinformasjon, e-poster og viktige dokumenter) vi har hatt med kunden? Hvor god var egentlig oversikten i listene i Sharepoint? Stolte vi helt på salgsrapportering og salgsprognosene?

Vi besluttet for lenge siden at vi skal bruke Microsofts produkter så langt det lar seg gjøre (jeg er selv en Mac-fan, men det er ikke alle diskusjoner man går inn i). Vi hadde dermed kun Micosoft Dynamics CRM å forholde oss til som systemvalg. I så måte var anskaffelsesprosessen ganske enkel; hvem kan levere dette og til hvilken pris?

Er det så enkelt?

Nei, for alle bedrifter har ulike prosesser.

Nei, for et CRM (Customer Relationship Management) system er uansett hvem du kjøper av rettet mot tradisjonell varenhandel. Helt forenklet skjer det slik: bedriften markedsfører en fysisk vare, en kunde ønsker den, han ber om tilbud, han får et tilbud, han bestiller, bedriften registrerer ordren, varen blir sendt, og faktura sendes).

Nei, for MS Dynamics CRM er tilpasset amerikansk tankesett.

Løsningen?

CRM systemet er et støtteverktøy til Karabins kjerneprosesser, og derfor begynte vi riktig (vi er tross alt spesialister på dette!). Vi tegnet opp salgsprosessen fra A-Å. Vi definerte hvilke aktiviteter vi måtte gjennomføre fra første kontakt med kunden til kunden avsluttet sitt kundeforhold (noe som ikke skjer så ofte). Vi så på hvordan informasjonen ble overlevert i dag mellom ansatte, og mellom oss og kunden. Vi brukte RIS som metode og notasjonsform. Vi fikk kontroll med salgsprosessen, og så med en gang en rekke forbedringsmuligheter. Vi analyserte disse, omformet prosessene og tegnet prosesskartene på nytt. Ved hjelp av dette så vi i hvilken aktiviteter, overleveringer og rapporter som CRM systemet skulle hjelpe kjerneprosessene med. Se et utdrag av prosesskartet under:

Prosesskart for salgsprosessen i Karabin

Implementering
Vi valgte leverandør basert på at de kunne leverer Hosted CRM løsning til en svært god pris. Videre kontaktet vi ulike konsulentmiljøer som kunne bistå oss med å få CRM systemet tilpasset våre prosesser. Vi leide inn en dyktig konsulent, og i første møte brukte Karabin 2 timer på å gå gjennom prosesskartene. CRM konsulenten fikk med andre ord full informasjon, oversikt og dokumentasjon. Basert på dette estimerte han at tilpasningene var så godt beskrevet at vi kunne få ferdig løsning basert på en fast pris.

I forhold til estimatet klarte vi tilpasningen av systemet på riktig tid og til riktig kostnad. Systemet har vi nå brukt i 4 måneder, og det har fungert 100 %.

Lærdommen
Skal du kjøpe et systemt så bruk tid på å forstå prosessene. Følg gjerne denne sterkt forenklede oppskriften:

1. Finn ut hvilke prosesser som har mest forbedringspotensiale
2. Sørg for å ha full kontroll på prosessen
3. Utarbeid en optimalisert prosess
4. Tegn prosessen på nytt
5. Bruk prosessbeskrivelsen som underlag for kravspesifikasjon
6. Sørg for at utviklerne eller systemet er 100 % tilpasset den forbedrede prosessen når du overtar det