Guide för namnsättning av processer

Det är alltför vanligt att företag och organisationer slavar när det gäller namnsättning av processer.  Resultatet från dålig namnsättning är att hela processarkitekturen blir otydlig och svår att få ett bra grepp om.

I denna artikel tar jag upp några saker jag anser är viktiga för att få en bra och sammanhängande processarkitektur sett ur namnsättningssynvinkel. Tips på utformningen av processarkitekturen kommer i senare artiklar.

Först några termer

  • Huvudprocess – End till end process ur kundens synvinkel. Kallas även kärnprocess.
  • Delprocess – Återanvändbar eller specifik subprocess
  • Aktivitet – Kan vara delprocess eller task och är det enda objekt i processen där det utförs något jobb. Den dubbla betydelsen kommer från BPM och jag tycker att det fungerar bra att samla delprocesser och tasks under denna benämning.
  • Task – Lägsta nivån av en aktivitet i det aktuella scopet för en process. En task kan göras om till en delprocess om lägre nedbrytning av processen önskas

Namnsättning på nivå 1 – Huvudprocess

Jag måste erkänna att jag tidigare var fast i tanken att man även för huvudprocesser skulle använda formen <verb> <substantiv>. Numera har jag ändrat uppfattning kring det och menar att man inte behöver vara kategorisk kring detta.

Anledningen är att det är svårt att sätta ett bra namn för en end-2-end process via verb+substantiv. Som exempel på denna nivå kan man ta ”order-to-cash” som brukar vara den generella benämningen huvudprocessen för försäljning.

Order-to-cash för bilförsäljning skulle kunna heta Sälja bilar med verb+substantiv. Den tidigare ger en indikation på scopet för processen och den andra vad för typ av försäljning det handlar om.

En fördel med den tidigare är att huvudprocessen på översta nivån kan vara likadan för olika typer av försäljning vilket medför att det räcker med en huvudprocess.

Rekommendationen jag vill ge är att man kan ta sig friheten att ge processen ett tydligt namn istället för att alltid använda formen <verb><substantiv>

En viktig notering kring huvudprocesser är att det är beroende på kontexten. En process kan vara delprocess för hela processflödet men för en specifik del i verksamheten är det en huvudprocess.

Namnsättning på övriga nivåer

För alla andra nivåer från översta delprocesser till tasks bör man med fördel använda formen verb+substantiv.

Exempel på namnsättning av aktiviteter i en process
Figur: Namnsättning av aktiviteter i en process

Anledningen är att varje delprocess i en process anger något som utförs i processen och genom att använda den föreslagna formen blir processen tydligare och det är lättare att få ett konsistent flöde.

Exempel på aktiviteter som lika gärna skulle kunna vara delprocess eller task

  • Skapa order
  • Leverera vara
  • Betala faktura
  • Skicka faktura

Betala faktura kan t ex behöva brytas ner till ett flöde som täcker en kedja av godkännanden men i andra fall är det en enkel betalning.

Processkarta

För att förstå komplexiteten när det gäller namnsättningen måste man ha klart för sig hur en processarkitektur ser ut eller kan se ut eftersom det finns många olika sätt att beskriva det på.

Processarkitekturen brukar beskrivas i en processkarta där verksamhetens processer på högsta nivå finns med för att skapa en översiktsbild över verksamhetens arbetsflöden.

Patrik Halldin på xxxx har skrivit en artikel på  linkedin om de olika nivåerna i en processarkitektur. Det finns lite skillnader beroende på vilken metod man använder samt personliga eller organisatoriska preferenser. Artikeln kan du läsa här

Jag skall belysa även processkarta i senare artiklar.

 

Exempel på en ineffektiv logistikprocess

Inblandade aktörer

  • Kund = Mottagaren av paketet
  • Leverantör = Avsändaren av paketet
  • Logistikbolag = Det bolag som ansvarar för hanteringen av paketet från att det hämtats från leverantören och överlämnats till kunden

Processflöde

Brister i logistikflöde

Exempel på ett aktuellt logistikflöde som inte fungerar

Bilden visar ett pågående leveransflöde för ett paket som skickats från Sidney i Kanada och som skall levereras till Tvååker i Sverige. Flödet visar att det finns lite brister i den interna hanteringen av leveransen.

Ursprungsfelet är enligt logistikbolaget att paketet märktes med fel destinationsland vid mottagandet i Kanada. Leverantören har dock angett rätt uppgifter till logistikbolaget.

Logistikbolaget har haft kännedom om problemet åtminstone sedan det var i Litauen första gången.

”De skall göra allt de kan för att försöka få dem att leverera paketet till Sverige men kan inte lova att det lyckas”.

Alternativet är att paketet skickas tillbaka till leverantören i Kanada.

Problemet är att supportavdelningen inte har möjlighet att kontakta den del av bolaget som för tillfället hanterar paketet för att se till att paketet märks om med rätt destinationsland. Detta resulterar i att paketet åker runt mellan olika länder i Europa.

Identifierade brister i hanteringen

  • Det brister i förmågan att justera en felmärkt leverans
  • Det brister i kommunikationen mellan olika delar av verksamheten. Supportavdelningen har t ex ingen möjlighet att kontakta den avdelning som för tillfället har hand om paketet för att rätta till ett problem
  • En leverans kan skickas fram och tillbaka mellan olika platser och länder utan att någon inom organisationen åtgärdar problemet
  • Brister i informationssystemen medför att alla inte kan se den slutliga destinationen. Beroende på typ av tjänst som leverantören beställ kan t ex supportpersonal bara destinationsland men inte kundens adress

Följdverkningar som riskera att uppkomma som resultat av dessa brister

  • Logistikbolaget
    • Varje onödig transport resulterar i extra personal- och transportkostnader
    • Ökar belastning på terminaler och utrymme i fordon
    • Belastning på supportorganisationen
    • Risk för att leverantörer byter logistikbolag
    • Merarbete om samma vara behöver skickas en gång till. inge
  • Leverantören som varorna beställdes ifrån
    • Leverantören behöver lägga ner arbete för att ge support till kunden
    • Leverantören behöver ha kontakt med logistikbolaget
    • Extra arbete och kostnader om logistikbolaget returnerar varorna till leverantören som då måste göra en ny leverans till kunden
  • Kunden
    • Försenad eller utebliven leverans riskerar medföra olägenhet för kundens kund
    • Om varan är kritisk för kundens verksamhet kan det få betydande konsekvenser för verksamheten
    • Extra arbete för kunden med att kommunicera med inblandade aktörer
  •  Klimatet
    • Varje extra transport orsakar ökad miljöpåverkan vilket är dåligt för miljön och klimatet

Förslag på förbättringar som skulle kunna göras inom logistikbolaget

  • Se över hela flödet för hela leveransen från mottagande av leverantören till kunden som skall ta emot leveransen och identifiera problemområden
  • Förbättra hantering och rutiner för avvikelser. Det borde t ex finnas tydliga kommunikationsvägar genom alla led av organisationen. Idag ser det ut som att inte supportorganisationen kan få kontakt med den del av organisation som hanterar paketet vid den aktuella tidpunkten
  • Förbättrade informationssystem som gör det möjligt att justera felaktig information.
  • Se till att varje aktör har tillgång rätt information vid varje tillfälle. Exempelvis om någon matat in eller angett felaktig information skall det gå att korrigera informationen.
  • Se över hanteringen av spårningsmeddelanden. Dagens spårningsmeddelanden ger inte tillräckligt med information. Åtminstone inte till kunden. Exempel på ett spårningsmeddelande är: ”Under transport”. Det hade varit mer upplysande om det stod: ”Under transport till Stockholm”. Detta medför att man måste invänta nästa avläsning innan man får reda på vart ett paket har skickats.

Signavio Process Editor

Signavio Process Editor är en molnbaserad tjänst för processutveckling. Signavio erbjuder ytterligare två IT-stöd, Signavio Workflow samt Signavio Decision Designer.

CH Tano är Consulting partner till Signavio och vi kan demonstrera deras produkter och förmedla kontakt till Signavio.

Här kommer inom kort en sammanfattning av Process Editor som är ett riktigt bra verktyg för att utveckla och underhålla en organisations verksamhetsprocesser med.

Signavios webbplats hittar du på Signavio.com

 

Outside In – Manning/Bodine

Outside In - The power of putting custiomers at the center of your business

ISBN: 9780547913988

Fokusera på att sätta kundens totala upplevelse i fokus vid effektivisering av verksamheten. Metoden ”Outside In” sätter kundens behov i fokus. En av insikterna man kan få är att man kan hitta sätt att  utvidga sin verksamhet genom man ser verksamheten ur ett annat perspektiv.
Köp boken från Adlibris

Process improvements

This article by Steve Towers give a good insight to some differencies between Lean, Six Sigma and CEMM (Customer Expectation Management Method)

He points out this phrase:

“you may be doing things right, but are you doing the right thing?”

and it’s important to think about this when working with process improvements.

As an example you could provide the best product on the market (doing things right) but if no one is interested in that product, then you should concider if you doing the right thing.

You find the article here

 

 

Utmaningar vid mätning av en process

Det finns många utmaningar när man skall mäta effektiviteten i en process. Initialt kan det ses som en enkel sak att göra men tittar man närmare på det, inser man att det är lite mer komplicerat än vad det ser ut vid första anblicken.

Här skall jag ge ett exempel på några utmaningar man kan stöta på vid mätning av en process samt hur viktigt det är att vara medveten om vilken kunskap man vill få ut av mätningen. Som utgångspunkt  kommer jag att använda ett exempel som finns i boken Processbaserad verksamhetsutveckling.

Detta exempel anser jag belyser problematiken kring KPIer och mätning av processer på ett bra sätt.

Exemplet handlar om att man önskar servera god mat till en matgäst på en restaurang. I detta exempel är ett av kundens krav att maten skall vara varm för att smaka bra och ge en bra upplevelse. Den stora frågan är då hur man skall mäta processen för att säkerställa att maten är varm när den serveras?

Ett sätt att lösa det på är som författarna skriver i boken, att man mäter maten vid tillagningen och vet då att den har kommit upp till rätt temperatur. Problemet med denna typ av mätning som kan grupperas in i området funktionell mätning, är att man får ett mått på hur varm maten är just vid tillagningen men det betyder inte att maten är varm när kunden blir serverad. Beroende på hur resten av processen ser ut kan det finnas många steg som medför att maten hinner kallna innan serveringen, t ex bli stående på en serveringsvagn eller liknande.

Measurement example step 1

 

I ovanstående mätning kan det således finnas många saker som leder till att kundens mat hinner bli kall innan serveringen med följden att kunden blir missnöjd.

Varmhållning kan vara ett sätt att lösa problemet på, men det skapar extra arbete i köket med aktiviteter som varmhållning och temperaturmätning. Dessutom riskerar kvalitén på maten att försämras om den varmhålls under en längre tid.

Hur kan man istället lösa leveransen av varm mat till kunden och hur är det kopplat till mätning av processen?

En enkel lösning som beskrivs i boken är att helt enkelt se till att maten serveras direkt efter tillagningen. Då behövs varken mätning eller varmhållning eftersom kunden får maten utan dröjsmål efter tillagningen.

För att lösa detta behöver processen vara utformad på ett sätt som medför att maten kan serveras direkt efter tillagningen.

Measurement example step 2

Summering

Om man som i exemplet skulle utfört mätningen i samband med tillagningen av maten, hade man infört en mätning i processen som inte skapat något värde för vare sig för kunden eller för verksamheten. Dessutom hade man infört extra arbetsuppgifter utan nyttoeffekt för de som arbetar i köket.

Ett exempel på när mätning i samband med tillagningen skulle kunna vara befogad är om man av någon anledning hade behövt visa på att maten varit uppe i tillräckligt hög temperatur, t ex för att döda eventuella bakterier i maten.

 

 

Metoder inom processutveckling

Metoder inom processutveckling

Inom processutveckling finns det en stor mängd olika metoder för analys och design av verksamhetsprocesser. Förutom de mer eller mindre standardiserade varianterna finns även många anpassade och kundunika. Alla organisationer är olika och ofta behöver metodiken anpassas till verksamheten.

Denna sida kommer att utvecklas mer och i olika inlägg på processarkivet.se kommer varje metod att beskrivas separat.

  • Customer Expectation Management Method (Outside-In)
  • Kundresa
  • EPC
  • BPM – Business Process Management
  • Lean
  • Six Sigma
  • SIPOC
  • Kundunika metoder