Frågan är kanske något förenklad och tillspetsad, men jag har på sistone haft flera anledningar att börja fundera i de här banorna. Jag ska förklara vad jag menar:
De flesta organisationer anser sig nog ha tekniska problem
Här kan nog alla känna igen sig. Visst finns det en hel del av det vi i dagligt tal kallar tekniska problem, både i form av buggar och i form av andra brister.
Så om det finns problem, är det inte bra att vara lösningsorienterad då?
Självklart låter det bra att vara lösningsorienterad. Det är bra också. Men är det verkligen tillräckligt?
Om ett team eller en person mycket snabbt kan ta sig an ett tekniskt problem, sätta sig in i det och lösa det så är det förstås bra. Det är vanligt att alla inblandade blir nöjda och tycker det är skönt att vara av med problemet – men är vi verkligen av med orsaken också?
Orsakerna – på riktigt
Vad jag vill lyfta med den här artikeln är att problemet kanske inte alls är löst.
Jag anser att det som anses vara orsaken till ett problem i själva verket inte alls är orsaken utan ofta istället är ett symptom som sin tur beror på något. Det är alltså detta något som är orsaken.
Vi tar ett exempel:
Anta att vi har ett fel någonstans i företagets system eller produkter. Felet gör att en funktion eller ett delsystem som används av slutkunderna svarar för långsamt eller inte svarar alls. Det låter ju verkligen som ett tekniskt fel. Det är nog det också. Antagligen kommer en eller flera tekniker att relativt ta sig an problemet och fixa felet.
Det är förstås bra att vi avhjälper felet, men däremot anser jag att vi gör fel om vi under efterföljande diskussioner för lättvindigt säger att vi hittade orsaken till felet. Gjorde vi verkligen det – eller kan det vara så att vi bara hittade ett felsymptom som i sin tur hade triggat andra symptom?
Jag tror att den riktiga orsaken (grundorsaken) till problemet kan gömma sig i den här listan:
- En leverantör fick inte information om en ändring som vi gjort – eller tvärtom.
- Någon antog att en viss detalj var eller skulle vara på ett visst sätt, trots att den detaljen inte förekommit i någon kommunikation. Personen antog också att den detaljen trots det inte behövde dubbelkollas.
- En person glömde att agera på en information som den personen fått del av.
- En ändring genomfördes av någon, någonstans, och den personen ansåg (antog) sig inte vara den som också borde kommunicera förändringen och dess effekter till andra.
- En ändring genomfördes av någon, någonstans, och den personen antog att det inte skulle påverka någon annan eller något annat.
- Ett utvecklingsteam hade inte tillräckligt mycket eller tillräckligt bra information om vart deras produkt var på väg på längre sikt – eller ens på meddellång sikt. Detta gjorde att de tekniska beslut som för dem såg korrekta och rimliga ut ledde till lösningar som bara fungerade under en kortare period.
- Någon fattade ett beslut om hur/när/var saker skulle göras, trots att andra inblandade – kanske tom ämnesexperter – avrådde från just det beslutet.
- En stor eller komplex förändring planerades och genomfördes utan att någon riskanalys – ens av enklaste slag – gjordes.
Listan kan göras lång. Det som är gemensamt för alla punkter är att det handlar om kommunikation (eller bristen på kommunikation) människor emellan, inte på teknik.
Kort uttryckt skulle man kunna säga att:
Tekniska problem kommer oftast inte av tekniska orsaker. utan av andra tekniska fel – som i sin tur beror på brister i den mellanmänskliga kommunikationen.
Detta är inget nytt, det bara tål att upprepas
Tankarna som jag har velat lyfta här är egentligen bara en variant på – eller en tillämning av – konceptet ”5 whys”; det koncept som Sakichi Toyoda utvecklade och som länge användes på Toyota Industries.
Lycka till!
/Björn