Reaktionshastighet är en dold kostnad.

I de flesta produkt- och retailbolag vi arbetar med ser rapportcykeln ungefär likadan ut. Under veckan samlas data in och kontrolleras, och sedan blir den en rapport, antingen automatiskt eller för att en analytiker hämtar ihop underlaget för hand. Rapporten gås igenom på ett möte där besluten fattas och åtgärderna sätts igång.

Rapporten i sig brukar fungera, men beslutet fattas alltid med en inbyggd fördröjning. Ett stopp som inträffar på onsdagen syns i rapporten på fredagen, diskuteras på måndagen och åtgärdas kanske på torsdagen. Då har det gått en vecka och ett par dagar.

Under tiden går produktionen vidare, och kundorder styrs mot ett lager som kanske inte längre ser ut som man trodde. Avvikelserna hanteras av den som råkar märka dem, eller inte alls förrän rapporten bekräftar det alla egentligen redan anade.

Den här sortens fördröjning är svår att ta tag i, eftersom den aldrig dyker upp som en egen post i bokslutet. Någon rad som heter "kostnad för sen information" finns inte. I stället försvinner kostnaden i övertidstimmar och i produktion som kördes på fel underlag. Den syns också hos kunder som fick fel leveransbesked och i lager som byggdes upp eller tömdes av fel anledning.

De flesta chefer vi pratar med kan räkna upp sådana situationer utan att fundera länge. Produktionsledaren visste att ett stopp var på väg men fick inte bekräftelsen förrän det redan hade hänt. Inköpschefen beställde mer av en komponent samma dag som en kassation gjorde beställningen onödig, och säljchefen lovade leveranstider utifrån ett lager som hunnit ändras sedan söndagen. Var för sig går händelserna att hantera, men de kommer tillbaka varje vecka, och det är där kostnaden ligger.

Det vore lätt att se det här som ett problem med rutiner eller organisation, som om det skulle lösa sig om folk bara kommunicerade bättre eller analytikern hade mer tid. Oftast sitter problemet i tekniken. Det saknas ett sätt att se vad som händer nu, i stället för vad som hände för fem dagar sedan.

Informationen finns ju redan i affärssystemet, produktionssystemet och lagersystemet. Den går bara inte att komma åt i en form där någon kan agera utan att vänta på nästa rapportcykel.

Där gör operativ analys en konkret skillnad. Om produktionsledaren ser avvikelsen på en vy som uppdateras löpande, krymper reaktionstiden från dagar till timmar eller minuter. Då speglar underlaget det som händer nu och inte en ögonblicksbild av förra veckan.

En förutsättning brukar underskattas, nämligen att data från de olika systemen faktiskt hänger ihop och att begreppen betyder samma sak överallt. Räknar lagersystemet och affärssystemet tillgängligt lager på olika sätt hjälper det inte att båda uppdateras i realtid, för då reagerar ni bara snabbare på en motsägelse.

Samma sak gäller om "produktionsstopp" betyder en sak i kvalitetssystemet och en annan i underhållssystemet. Då blir en realtidsvy över stoppen mer förvirrande än vägledande.

Själva tekniken är mogen. Med Real-Time Intelligence och liknande plattformar går det att bygga vyer som uppdateras med sekunders eller minuters fördröjning. Men om ni ska kunna lita på besluten behöver ni först enas om definitionerna och rensa upp i integrationerna mellan systemen, och det arbetet behöver komma före vyerna.

Vi brukar föreslå att man börjar i ett avgränsat område där fördröjningen kostar mest, i stället för i hela verksamheten. Det kan vara lagernivåer i nära realtid eller produktionsstatus per linje. För andra är det orderläget med uppdaterade leveransdata.

Ett sådant område går att genomföra snabbt, och nyttan syns direkt i hur besluten fattas långt innan den märks i ett nyckeltal.

Fördröjningskostnaden syns aldrig i budgeten, men de som jobbar med den varje dag vet var den sitter. Fråga dem vilket beslut de oftast får vänta på underlag för, så har ni ert första område.