Fallgrop 12(12): Vi är inte klara att börja än

Post date: Feb 28, 2017 7:54:13 PM

Förändring och förbättring bör vara en del av vardagen. Det finns en del fallgropar som man bör undvika. Jag har samlat 12 vanliga fallgropar som jag beskriver och föreslår hur man undviker dem samt förslag på hantering om det redan inträffat:

Fallgrop 1(12): Tro att systemlösningar och metoder räcker!

Fallgrop 2(12): Det räcker med utbildning!

Fallgrop 3(12): Försöka förändra genom ombud!

Fallgrop 4(12): Att inte se själv för att börja förstå! Att förstå är nyckeln till positiv förändring!

Fallgrop 5(12): Ständiga förbättringar fixar allt!

Fallgrop 6(12): Inte lita på värdet av “misslyckade” försök!

Fallgrop 7(12): Att inte ha en plan!

Fallgrop 8(12): Att tro att du har speciella problem bara för att du är unik!

Fallgrop 9(12): Förändring kan vi klara själva!

Fallgrop 10(12): Fokusera på bästa möjliga kvalitet.

Fallgrop 11(12): Förändring utan ledningens engagemang.

Fallgrop 12(12): Vi är inte klara att börja än

Tillhör du dem som vill vara helt klar innan du tar nästa steg, vara på säkra sidan, kolla en extra gång. Risken är att man skjuter upp starten, för att säkerställa några detaljer till. Det är mänskligt att tveka, och att skjuta upp saker, vare sig det gäller att börja banta, sluta röka, börja träna eller initiera ett program för förbättringar. Alla resor börjar med ett steg, väntar man kan resultatet bli att resan blir längre eller svårare. Så ta det första steget så blir de efterföljande lättare, kanske bara för att man då är i rörelse. Mitt tips är att våga experimentera, att börja i mindre skala, med små inkrementella mål på vägen. Acceptera att vägen är något man hittar under tiden och inte försöka förutsäga allting från början.

Agil programutveckling: Inom programutvecklingen har detta lett till agila (ibland översatt till lättrörliga) sätt att arbeta. En del av behovet är känt och vi kanske har en ide om hur vi kan lösa det, men vägen fram mot lösningen kan leda till att vi får bättre idéer, synpunkter från användare som vi inte tänkt på, information om andra/nya/gamla lösningar som kan bidra till kundens resultat. Om man arbetar agilt kan man dra nytta av den kunskap man skaffar sig efterhand och arbeta in den i nästa steg.

Utnyttja ett agilt sätt att arbeta i all förändring: Ett agilt förhållningssätt hjälper även vid många andra tillfällen, en del personer arbetar efter detta sätt utan att tänka på det. Men många kan ta hjälp av ett agilt tankesätt för att inte fastna i “vi är inte klara att börja än”. Låt mig ta några konkreta exempel hur ett agilt tankesätt kan hjälpa i en del situationer:

Granskning: Att vänta tills dokumentet är “färdigt” innan det lämnas till andra för granskning av “hela” dokumentet, kanske av hänsyn till granskarna för att inte tvinga dem att läsa dokumentet flera gånger. Om vi istället arbetar agilt så delar vi upp granskningen till exempel i 3 st delgranskningar:

Granska kapitelrubriker för att se om det saknas något kapitel, då vet vi att vi har täckt in behovet.

Granska första kapitlet för att stämma av förväntning på detaljer, språk m.m.

Granska det kompletta dokumentet baserat på erfarenheter från granskning 1 och 2.

Implementation: Att vänta med utrullning till användare tills man har ett komplett system med komplett rapportering, kräver att kraven är kompletta och att det går att förutsäga alla behov.

Förändringar av system innebär ofta en förändring av arbete, organisation och flöden. Att specificera allt innan implementationen börjar är omöjligt eftersom den organisation som skall använda resultatet ännu inte existerar. Om vi istället arbetar agilt så delar vi upp implementationen i delmoment, nedan följer ett exempel på hur jag genomfört förändringen för att automatisera begäran om ändringar av kunddata. Begäran ringdes in till en arbetsgrupp eller fylldes in i ett dokument som sedan skickades till gruppens mailbox. Slutmålet var att användaren skulle kunna göra så många ändringar som möjligt själva men säkerheten ställer krav på kontroll, vissa funktioner krävde ökade rättigheter. Så här gjordes en agil implementation:

Formulär skapades och introducerades till användarna. Formulärets enda funktion i detta steg var att skicka informationen vidare till gruppens mailbox. Nu vänjer sig användarna vid att använda formulär, samt att information till användarna kan ges i formuläret. Fortsatt manuell hantering av data samt mätningar av ärenden, komplexitet och kontroll av funktion för att förbereda automatiserad hantering av data.

I andra steget byts vissa fält i formuläret mot funktionalitet, det vill säga att vissa fält går direkt in i verktyget och andra skickas i mail, användarna behöver i detta läget inte veta vilka. Anpassningar av flödet i gruppens organisation för att hantera delat inflöde av information. Användarna erhåller svar när alla begärda ändringar är gjorda, både de automatiserade och de manuella.

Tredje steget innebär en successiv ökning av antalet fält som automatiseras, och införande av kontrollfunktioner för mer komplexa behov, där data fortfarande skickas till gruppen för kontroll. Utvärdering av datakvalitet och bedömning om automatisering kan ske. Svar efter genomförd förändring till användarna.

Fjärde steget innebär automatisering av vissa fält men bibehållande av andra, nu med information till användarna om vilka fält som är direkta och vilka som för närvarande hanteras via stödfunktioner.

Fortsatt utveckling och vissa fält ändras från manuell begäran till automatiserade.

För gruppen som hanterar data innebar detta att efter steg 1 så sker kommunikationen med användarna genom formuläret och de följande förändringarna kunde genomföras stegvis kontrollerat, vilket väsentligt minskade behovet att svara på frågor från användarna. För utvecklarna innebar detta att gruppen hade full kontroll på behov och vilka fält som var prioriterade att automatisera först för att minska det manuella arbetet. Om denna förändring hade skett på traditionellt sätt var bedömningen att:

Funktionen hade blivit lanserad minst 6 månader senare och blivit väsentligt dyrare att utveckla.

Flera fält hade inte blivit automatiserade på grund av bristande kunskap om kontrollbehov.

Kommunikation med användarna hade blivit mer komplex och inneburit belastning både på gruppen och utvecklingsteamet.

Gruppens arbetsbelastning hade varit dubbel, både att stödja användare och stödja utveckling.

Erfarenheter från manuell hantering var en fördel när flöde för informationshantering skapades.

Summering:

Det hjälper inte att sikta på att vara världsbäst “imorgon”, det är bättre att göra en liten förbättring idag, då frigörs tid och energi som kan ge oss möjlighet att sträva mot att bli världsbäst på ett kontrollerat sätt. Vilket påminner mig om en sång om att vara ofelbar med The Ones nämligen Flawless

Hans Prag, hans.prag@pdla.se