OBM i komplexa system

Jag är övertygad om att man med hjälp av OBM (Organization Behavior Manegement) kan hitta bra lösningar på organisatoriska problem. Nedan är ett av de problem som jag stött på ett flertal gånger i lite olika former.

Syftet med exemplet nedan är att försökt göra en enkel beskrivning över ett komplext problem och alla vinklar är inte med i denna korta version. Exemplet ger inte en komplett bild av OBM men använder sättet att se på beteende.

När man river eller bygger om i befintliga anläggningar är det vanligt att uppdrag inte når hela vägen (händer även vid nybyggnad). Ibland handlar det om kunskaper men det är inte alltid det som är problemet. De delarna som enlig min erfarenhet inte blir helt färdigställda är ofta delar som är mindre synliga för det stora flertalet i en organisation eller delar som man av olika anledningar valt att prioritera på en lägre nivå. Normalt är det många olika typer av kunskaper/kompetenser som krävs när man bygger, ändrar och river komplexa tekniska anläggningar. Om man bara tittar på dokumentation är det ett ganska omfattande område (funktionsbeskrivningar, riskanalyser, manualer, underhålls instruktioner, mekaniska ritningar, CE-märkning, apparatlistor, el ritningar, styrsystemsdokumentation…)

Exempel med OBM-ögon
Vi utgår från en komplex anläggning som består av delfunktionerna Y, X och Z. En projektgrupp får i uppdrag att sanera bort anläggningsdelen.

Gruppen sanerar bort delfunktion Z. Det är den delen som är synlig för de flesta, sedan är uppdraget ”klart”. I  verkligheten finns fortfarande delfunktion Y och X kvar.
Frågan man ställer sig då är om gruppen som fått uppdraget att sanera bort anläggningsdelen inte vet att funktion Y och X  finns kvar?
Det är inte helt ovanligt att gruppen är medveten om att funktion Y och X finns kvar. Frågan är då varför sanerade man inte allt?

I exemplet är det intressant att titta på konsekvenserna och de är delvis beroende av chefens kunskaper. På vilken nivå chefen har möjlighet att kontrollera uppdraget påverkar konsekvenserna. En inte helt ovanlig situation är att chefen inte är fullt insatt i alla delar och då kan det bli så att gruppen som utfört rivningen istället för en tillrättavisning får beröm. En annan bonus är att gruppen som gjort arbetet blir klara fort, uppdraget blir enklare att utföra och gruppen kan avsluta uppdraget snabbt. De kan även ha gjort arbetet lite billigare än beräknat och få lite extra beröm för det. Summerar man konsekvenserna som kommer nära i tiden blir det mycket positivt och det gör att sannolikheten är stor att man använder samma beteende i framtiden.

Hade gruppen i exemplet ovan haft samma chef och valt en annan väg där man försökt att sanera allt, är risken stor att konsekvenserna blivit mer negativa. Detta eftersom uppdraget då tar längre tid, blir mer komplext och kostar mer. Det gör att sannolikheten ökar för att man vid nästa tillfälle löser uppdraget utan att sanera allt.

Vad händer om någon vid ett senare tillfälle ska in och ändra i ett system som inte har sanerats?
Det är inte ovanligt att situationen blir synlig i samband med en annan ombyggnad och för att lösa det nya uppdraget måste man sanera det som tidigare inte sanerats. Risken är stor att det nya uppdraget tar längre tid än planerat och uppdraget blir mer komplext. Har man otur kan chefen bli mindre glad p.g.a. tidsfördröjningen. Det som är positivt är att man kan känna sig nöjd med att lämna en anläggning i bättre skick.

Beteendeanalysen ovan ger inte en klar bild utan den blir lite mer otydlig och resultatet blir med stor sannolikhet mer individuellt. Lite beroende på hur man ser på uppdragets komplexitet och hur stort värde gruppen sätter på "anläggning i bra skick". För vissa kan problemen som uppstår p.g.a. att uppdraget tar längre tid än planerat, påverka mycket mer än "anläggning i bra skick". Dvs hur gruppens beteende kommer att bli vid detta och nästa likartade uppdrag är svårare att se direkt med den förenklade OBM-metoden ovan. Risken finns att man vid nästa tillfälle undviker att åtgärda problemet eller kanske t.o.m. förvärrar problemen om det gör att arbetet går snabbare. (Man skjuter problemen framför sig och har man "tur" blir det någon annans problem).

Resultat för verksamheten
Om man inte sanerar allt i det första exemplet ovan kan konsekvensen för verksamheten ofta blir kostnader som blir mer eller mindre synliga. Att åtgärda problemen i efterhand innebära att utredningstider blir avsevärt längre eftersom man inte alltid har tillgång till information om vad som gjorts och varför. Det gör att kostnaden normalt blir högre när rester skall saneras i efterhand.
I några enstaka fall kan det bli störningar som påverkar produktion samt kunder. Om man då kan härleda problemet kan det bli tydligt för arbetsledningen och det kan få stora konsekvenser för gruppen som utfört uppdraget. Men enligt min erfarenhet är det är inte en vanlig utveckling.
Ett fall som jag själv sett var när man skulle ersätta "system Y" där "funktion Y" var en del. I detta fall var cirka 20-30% av hela systemet delar som borde varit sanerade. Gruppen som arbetade med att ersätta system Y var inte insatta i övriga delar och de gjorde då nya delfunktioner som i praktiken aldrig användes.

Tittar man på kostnaden var det cirka 20-30% av kostnaden som var helt onödig och den summan var ganska stor i exemplet.
När man en andra gång på förhållandevis kort tid skulle ersätta system Y var projektledaren mer insatt i hela anläggningen. Det gjorde att man i stället för att flytta över alla funktioner som i första försöket istället utredde vad som skulle med. Kostnaden för att utreda vad som inte skulle överföras var ca: 20-30% av budgeten men då var funktionerna enbart sanerade i system Y. System X där funktion X ingår sanerades inte (utanför uppdraget) och det fanns fler delsystem som hade samma situation.

Vad kan man då göra för att skapa en bättre situation.
Ett sätt som vissa organisationer använder är rent organisatoriskt. Man har resurser som har till uppgift att ansvara för olika system. Men för att det skall fungera måste de som är "systemansvariga" vara informerade och ha kanaler där man snabbt kan ta upp problem som uppstår. D.v.s. en grupp som inte gör hela saneringen klart, ska snabb ha feedback på att de inte är klara. Det gör att konsekvensen när man inte gör arbetet klart blir mindre positiv och på det sättet ökar sannolikheten för att man ska ändra beteende. En annan konsekvens av att utse ansvariga för system är att det för projektgruppen finns någon som man kan kontakta och kanske t.o.m. får hjälp av. Det gör att komplexiteten för projektgruppen minskar och det kan i sin tur även minska genomförande tiden. Sist men dock viktigast är att gruppen får beröm när den genomfört hela uppdraget, det får en stor påverkan framförallt om den kommer nära i tiden och alltid.

Om man utgår från samma tabell som i första exemplet och förutsätter att alla försök att "fuska" genom att inte sanera allt upptäcks, får vi den förenklade beteendeanalysen nedan.

Verkligheten är inte lika enkel som exemplet och tyvärr kan man inte alltid ha egna systemansvariga inom alla områden. Saknar man möjligheten att ha systemansvariga får man helt enkelt leta efter andra vägar att uppnå målen, men OBM kan ge förutsättningar att lyckas.

(Beteendeanalyserna i exemplen är förenklade och inte på något sätt kompletta, men de är ändå intressanta att utgå från. Den förenklade tabellmallen är hämtad från boken "OBM, Ledarskapets psykologi" men liknande mall finns i boken "Beteendeanalys i organisationer".)

https://ledarskap.webnode.se/news/beteendeanalys-i-organisationer/

https://ledarskap.webnode.se/news/obm-ledarskapets-psykologi/