Processutveckling

Om du någon gång tänker jobba med processer? Ställ dig då först frågan varför du vill göra det, och vad du vill få ut av det. Är det bara för att få ett ISO certifikat, eller ska du använda detta i ditt förbättringsarbete.

Börja alltid med att definiera ditt flödesobjekt, den enhet som passerar genom din process. Sen definierar du de olika mognadsgraderna detta flödesobjekt innehar. Till och med den sista. Identifiera var en process tar slut och en börjar, samt välja rätt abstraktionsnivå och hur många nivåer som krävs för att beskriva det arbete som ska utföras.

Se till att processen är logisk och att den stämmer överens med verkligheten, gör den inte det, får man välja ändra på verkligheten eller ändra på processen. Jag tycker att utgångspunkten måste vara verkligheten, och däri identifiera förbättringar som sen kan beskrivas i en process.

Om du skulle råka få ihop en process som stöder ditt önskade arbetssätt och att det faktiskt går att arbeta på det sättet i verkligheten, då har du det perfekta underlaget för att mäta verksamheten, utbilda de som ska arbete i verksamheten samt en grund för fortsatt utveckling av verksamheten.

 

 

Hur bör man jobba med risk?

Om man accepterar kopplingen mellan kvalitet och risk, blir nästa fråga hur vi ska arbeta för att identifiera, värdera, hantera och kommunicera risker i projekt.

Om risk osäkerheten i om vi klarar av att hantera transitionen mellan A och B inom de givna begränsningarna, blir det ett naturligt första steg att identifiera och konkretisera exakt vad som ingår i transitionen. Identifiering och värdering av risk är väldigt nära sammanflätade.

Nästa steg är att föreslå hypotetiska fall hur transitionen kan misslyckas. Transitionen kan misslyckas genom att det inte går att genomföra alls, att transitionen inte genomförs fullständigt eller att tillstånd B inte är på den mognadsnivå som projektets beställare / kunder förväntar samt att man inte kan uppfylla transitionen inom begränsningar (Tid, Pengar och Människor)

Sen får man bedöma vad som skulle bli effekten av hur varje specifik misslyckande beskrivet tidigare. Och framförallt att bedöma, helst i pengar, hur allvarligt det skulle bli.

Utifrån det, framförallt för de misslyckanden med oacceptable effekter bedöma vad som skulle kunna orsaka dessa misslyckanden. Samt bedöma dess sannolikhet.

Vad gör vi för att förhindra att risken slår in, det som brukar kallas riskhantering? Vi måste välja ut de mest lämpliga aktiviteter vi kan tänka oss, när denna åtgärd är implementerad bedömer man effekt (kostnad) samt sannolikhet igen, om nivån är acceptabel eller om mer måste göras.

Det går att summera ihop medelvärdet för all kostnader multiplicerat med sannolikheter för att få ett projektriskmedelvärde.

Det är lämpligt att använda denna summa för att kommunicera ut ett projekts risknivå tillsammans med de faktorer som främst bidrar till denna risknivå.

Förändring och Risk

Förändring brukar delas in i två kategorier: De stora kliven och de små stegen. Inom kvalitet brukar vi prata on ständiga förbättringar och project, där de ständiga förbättringarna är de små stegen och projekt de stora kliven.

De ständiga förbättringarna pågår hela tiden, och är normalt hanterbara inom det löpande verksamheten och enkel uppföljning räcker för att se att det fungerar, annars kan man återgå till det tidigare arbetssättet. I projekt däremot, tas större omtag och kan ibland vara ireversibla, dessutom brukar det vara en fördröjning mellan beslut och implementering av förändring tills dess att återkoppling på att det fungerar fås. Det innebär att det är främst i projekt som man måste tänka i termer av risk.

Om vi definierar ett projekt som en transition mellan Tillstånd A och Tillstånd B, innebär det ju självfallet att ju större steg därimellan destor större risk.

Tillstånd A -> Tillstånd B

När man bryter ner Transitionen mellan tillstånd A och tillstånd B, räcker det ju inte att titta på transitionen för att förstå riskerna, man måste även ta hänsyn till projektets begränsningar, de är normalt tid (när projektet ska vara klart), pengar (hur mycket projektet får kosta) samt människor (Både vilka människor och hur de ska arbeta). Risken är ju inte bara att kunna genomföra transitionen utan att kunna genomföra den med de givna begränsningarna.

Project Risk Triangle

Därmed kan vi definiera projekt risk som osäkerheten om transitionen mellan tillstånd A och tillstånd B kan genomföras inom de ställda begränsningarna. Transitionen brukar kallas projektskop. Det kan vi visualisera, för att förtydliga:

Antingen kan Scope ej levereras över huvudtaget, men oftast är utmaningen att leverera skopet inom begränsningarna. Och risken är osäkerheten i om det går eller inte går.

Denna modell skiljer sig från den traditionella projekttriangeln där begränsningarna är Tid, Pengar och Skop och där innehållet är kvalitet. I vissa fall har Skop och kvalitet bytt plats. Den traditionella modellen har flera problem. Den saknar det faktum att människor (Vilka de är och hur de arbetar) är kritiskt för om ett projekt kommer lyckas eller inte. Dessutom är ju skopet inte en begränsning utan syftet med projektet. Men inte heller är kvalitet en begränsning utan en indikation på hur väl skopet levererats.

Hur kommer kvalitet in i den modell som jag föreslår? Som jag tidigare berättat finns det en tydlig koppling mellan risk och kvalitet. Det är realiserade risker som blir kvalitetsproblem eller andra sorters problem.

Vad innebär denna föreslagna modell i praktiken? Det kommer jag att återkomma till, men det jag kan säga nu är att det ger en möjlighet att arbeta mycket mera medvetet med risker, vilket den andra modellen inte medger.

Koppling mellan kvalitet och risk

Det finns en direkt koppling mellan kvalitet och risk. Med den tidigare definitionen på kvalitet, samt att risk är en osäker (negativ) påverkan, kan man därför säga att alla kvalitetsproblem var risker innan de realiserades.

Därför är det preventiva kvalitetsarbetet, direkt kopplat till arbete med risker. Medan det reaktiva kvalitetsarbetet hanterar uppkomna kvalitetsproblem.
Den vanliga frågan i det preventiva riskarbetet blir då: Hur identifierar vi risker som kan leda till Kvalitetsproblem?
Det finns mängder av metoder för att göra detta, den mest kända är nog FMEA, vi kommer att återkomma till FMEA metoden senare. Men innan vi tittar på hur vi identifierar risker måste vi ställa oss frågan: Hur uppstår risker som leder till kvalitetsproblem?

Här måste vi återkomma till riskdefinitionen och betona osäkerheten. När är något osäkert (sannolikhet)? När det ännu inte inträffat, det vill säga att tilltståndet där problemet uppstår ej inträffat. Vilket leder oss till order förändring, då det är direkt kopplat till transitionen av tillstånd. Risken uppstår i samband med förändring. Ju större förändring, desto större osäkerhet, desto större risk.

Om ovan samband accepteras innebär det att risk uppstår i förändring och utan förändring ingen risk. I vår värld har vi ständingt variation och därmed alltid en viss grad av förändring och därmed risk. Men betydande risker och de som leder till betydande kvalitetsproblem uppstår huvudsakligen i förändring. Det kan vara både interna och externa förändringar, externt både mot kund och mot leverantör. Samtidigt så behöver vi förändring, det är i förändring vi kan uppnå förbättring, men ändå är det här som vi skapar våra kvalitetsproblem. Det är ingen lätt ekvation, men vet man om att den finns, och arbetar med den medvetet finns det alla möjligheter att identifiera riskerna och hantera dem, och därmed arbeta preventivt med kvalitetsproblem.

när behöver vi inte kvalitet?

Inser att jag inte haft tid att skriva om kvalitet. Men jag har haft tid att tänka. En fråga som kan vara relevant är när behöver vi inte kvalitet? Eller snarare, när behöver vi inte formellt arbeta med kvalitet metodiskt?

I en liten organisation, som tillhandahåller en tjänst, där man kan få en direkt återkoppling, och historiken antyder att i princip alla kunder är nöjda. Kanske det enda som behövs är att snabbt reagera om en kund uttrycker missnöje med tjänsten. Men om något av ovan kriterier ej är uppfyllt kan det vara värdefullt att bedriva ett medvetet kvalitetsarbete, omfattningen måste så klart styras av verksamhetens behov.

Hur sätter vi mål för kvalitet?

När vi bestämt oss för vad kvalitet är och hur vi mäter kvalitet, går det också att sätta ett mål för kvalitet. Vilka principer ska gälla här?

Det är lika viktigt att bestämma vem som är ansvarig för att målet nås som att sätta målet. Den del av organisationen som har störst påverkan på om målet nås bör äga målet. Det kan vara allt från de som beslutar om produkter/tjänsteutbud, de som säljer produkter/tjänster, de som utvecklar produkter/tjänster, de som tillverkar produkter / utför tjänster, de som hanterar reklamationer. Ibland kan man dela upp målet mot flera parter, man måste då dock se till att det ej är möjligt att suboptimera eller skapa onödiga målkonflikter.

Mål ska ju alltid vara SMART så klart. Det vill säga Specifikt, Mätbart, lämpligt (Appropriate), Realistiskt och Tidsbegränsat. När vi bestämde vad kvalitet är och hur vi mäter har vi ju redan täckt in Specifikt och Mätbart. Nu måste vi också se till att det är lämpligt, realistiskt och tidsbegränsat. Lämpligheten beror ju till stor del på din verksamhet och var du befinner dig. Det måste vara möjligt men gärna en rejäl utmaning att nå ditt kvalitetsmål, det vill säga realistiskt.. Slutligen så ska det finnas en tidpunkt då ni ska vara framme. Och vid det laget är det nog dags för att sätta ett nytt kvalitetsmål.

Slutligen vill jag framhäva förankringen. Hela organisationen måste stå bakom kvalitetsmålet och vara villiga att prioritera för att nå målet. Är detta inte uppnått är målet meningslöst och organisationen måste i så fall se över vem som ska äga målet och processen för hur målet tas fram måste revideras.

Hur mäter vi kvalitet?

 

När vi nu bestämt vad Kvalitet är, hur vet vi då om det vi gör är bra? Det vill säga uppfyller vi det vi lovat mot våra kunder?

Vi kan fråga våra kunder om vi ger dem det vi lovat, men det är en metod som har ett antal inbyggda problem i sig, det kostar dessutom tid och pengar att genomföra. Problemen handlar om sample size, bias, mm.

Det enkla och mest grundläggande metoden är att systematisk insamla och analysera informationen som uppstår då våra kunder reklamerar till oss, det vill säga att de formellt rapporterar till oss att den vara eller tjänst eller aktivitet de fått ej uppfyllde det som de förstått att vi lovat ej var uppfyllt. En reklamation godkänns inte alltid, det kan ju faktiskt vara så att de missförrstått vad vi lovat dem, detta kan som vi tidigare diskuterat skapa en customer satisfaction ärende.

I den insamlade informationen om reklamationer kan det finnas en guldgruva av saker att förbättra! Därför vore det ju ett fullständigt slöseri med resurser att inte utnyttja detta i kvalitetsarbetet. Det är därför av största vikt att det system som hanterar reklamationer inte bara byggs upp av de som ska hantera den finansiella aspekten utan att även kvalitetsdelen. Behoven av vilken information som ska insamlas är inte densamma, det är därför väldigt svårt att i efterhanda pussla ihop all information om den inte insamlades rätt från början.

Vad är bra information från ett kvalitetsperspektiv: Information om kunden, information och varan och tjänsten. Information om felet, vad som ej uppfyllde kraven (löftet). Information om vilken åtgärds som togs för att åtgärda problemet. Andra parametrar som ofta är värdefulla är datum , kostnader och referensnummer, Det är väldigt bra om man har en systematik i rapportering av varan/tjänsten och framförallt att vilken del av den som gick fel, samt på vilket sätt felet åtgärdades.

Sen kan du över tid komplettera och komplicera hur du mäter kvalitet.

Min rekommendation är att det första steget i ett kvalitetsarbete är att bestämma hur vi mäter kvalitet, för att alla steg därefter kommer att vara beroende på hur du mäter.

Vem är din kund?

Alla aktiviteters leveranser har minst en kund, ibland flera.

Kundbegreppet sträcker sig ifrån det ”enkla”, det vi normalt benämner slutkund. Det inbegriper också relationer där du själv, dina medarbetare eller din chef mottar resultatet av ditt arbete. Till komplicerade miljöer med många intressenter. Där olika intressenter har en eller flera av typiska kundegenskaper: Beslutsfattning, brukare, utförare, betalare bedömare mm.

Om man inte vet vem eller vilka som är sin kund, det vill säga vilket kundbegrepp som man bör använda, är det svårt att veta hur man ska gå till väga för att uppfylla det ställda löftet. Det gör det också svårt att veta den fulla omfattningen av sitt löfte då.

Att uppfylla det ställda löftet

Quality is when an individual or organisation fulfils the promise it gave to its customers and/or stakeholders about the product and/or service and/or activity .

Hur uppfyller man sitt löfte, och vem bestämmer när löftet är uppfyllt?

Här finns det ibland väldigt enkla svar och ibland komplicerade gränsdragningar. Så länge alla är överens om löftet är uppfyllt eller inte, är det enkelt. Det blir dock komplicerat i det läget när parterna är oense.

Vissa delar av löftet är reglerat och kan i extrema fall lösas av lagar, regler och praxis. Det kommer dock alltid att också finnas delar av löftet som är tolkningsbara.

Dessa delar har faktiskt leverantören alltid beslutsrätt, men så klart inte sista ordet. En missnöjd kund kan ju klaga ganska högljutt. Är det tillräckligt allvarligt är det nog den sista gången kunden använder just den leverantören. Som leverantör som vill behålla en kund är det därför viktigt att komma ihåg att det ibland inte räcket att leverera det man själv tycker att man har lovat. Ibland måste man leverera det som ens kund tror sig ha blivit lovad. Det har dock i det läget ingenting med sitt eget ställda löfte att göra, utan det handlar om Customer Satisfaction: Att behålla sina kunder nöjda.

Efter varje fall där det gått så långt att man varit tvungen att gå utöver sitt löfte för att bibehålla en kund nöjd, måste man ställa sig frågan: Ska jag förändra mitt löfte eller förtydliga det mot mina kunder?

Min kvalitetsdefinition – en utläggning om löftet.

Quality is when an individual or organisation fulfils the promise it gave to its customers and/or stakeholders about the product and/or service and/or activity .

Kvalitet är en bekräftelse på att det som lovades (promise) uppfylldes (fulfil). Vi börjar därför direkt med kanske det viktigaste: Löftet. Här uppstår direkt flera frågor som måste besvaras i varje enskilt fall, det finns så klart principer och riktlinjer man kan följa, men löftet måste anpassas till den situation man befinner sig i.

Vem utställer löftet? Vad ingår i löftet, finns det outtalade komponenter? Hur begränsas löftet? Hur gör man för att inte lova för mycket? Hur gör man sitt löfte relevant till sin kund? Det finns många fler frågor för att ringa in sitt eget löfte…

Men det är något man ofta kan se, att företag skriver ”Our Promise”, vårt löfte. Jag tror att det löftet som beskrivs i ”Our Promise”, är ofta väldigt mycket mer begränsat än vad som ingår i det löfte jag pratar om.

Men att tänka över vilket löfte det är vi ger till våra kunder och stakeholders är steg 1 i att formulera sin egen kvalitetsstrategi.