Mitt team's hverdag består i problemløsning. Vi får inn henvendelser på telefon eller mail , og kunden forventer raske svar slik at AutoStore raskt fungere optimalt igjen. Når jeg blir inn blandet er det ofte viktig at jeg tar raske avgjørelser, fordi det er allerede brukt tid i mitt team. Min svakhet i slike situasjoner, er at jeg leter umiddelbart etter løsninger. Men etter å ha studert precision modell i kommunikasjon, har jeg funnet ut at svarene ofte kan ligge i å forstå "present state" og "desired state"
"Present state" er å skjønne hva som skjer i dag. "Desired state" er å skjønne hvor vi vil. Dersom man definerer disse godt, så kan man allerede få svaret i disse statene. Jeg hadde ett slikt eksempel for en tid tilbake, det kom inn en sak til oss, hvor Autostore ikke kom frem med kasse til port. Vi fikk opplysninger om hva som hadde skjedd fra distributør, og mitt team gikk i gang for å løse problemet. Vi hadde fått oppgitt hvilken kasse, hvilket tidspunkt og hvilke robot som var involvert. Så det ble satt i gang å studere logger fra systemet. Men det var en opplysning som manglet, og det var at denne roboten hadde manuelt blitt kjørt. For ikke å gå for dypt i detaljer, så kan vi si at selve manuell kjøringen var grunnen til at kasse ikke kom til port.
Dette resulterte i at vi satt å studerte logger i 3 dager, og fokuserte på at feilen lå i at kassen ikke kom til port. Vi skal si at siden manuell kjøring var gjort 20min før hendelsen, så var det ikke rett frem å se denne linken. Men det illustrerer det faktum, at om man bruker litt tid på å skjønne sin "present state", så kan man allerede løse problemet der.
Dette resulterte i at vi satt å studerte logger i 3 dager, og fokuserte på at feilen lå i at kassen ikke kom til port. Vi skal si at siden manuell kjøring var gjort 20min før hendelsen, så var det ikke rett frem å se denne linken. Men det illustrerer det faktum, at om man bruker litt tid på å skjønne sin "present state", så kan man allerede løse problemet der.
Bruker man tid på å definere sin "desired state", kan man også i noen tilfeller se løsningen. Ett eksempel vi for en stund siden hadde, var at en kunde meldte i fra om at kasser i Autostore fikk feil posisjon. Igjen vil jeg ikke gå for teknisk inn, men vi fant ut at det skyldtes at kunden trykket på en knapp på feil tidspunkt. Dette var vi alle enige om at vi måtte ta høyde for i software, utvikling startet med å endre software, men utvikling fant ut at dette var mer komplisert enn antatt. Siden det var viktig å forhindre situasjonen var mange involvert, og da kom det plutselig fra en medarbeider "vil vi ikke bare forhindre at de trykker på knappen, kan vi ikke bare disable den?". Der var "desired state" definert og løsningen lå foran oss.
Jeg prøver å bruke tid på de 2 statene, for jeg vet verdien av det. Men jeg skal ærlig innrømme, at jeg må jobbe med det, for det er lett å hoppe rett i løsnings fasen.