Kako istražiti manjak u zalihama pre nego što okrivite sistem

Pre više od dvadeset godina primio sam poziv o kojem i danas razmišljam. Oko 10.000 dolara manjka na popisu, korisnici koji prijavljuju greške i vlasnik koji je već doneo zaključak: sistem koji smo upravo uveli ne radi.

Tada sam vodio regionalnu filijalu za implementaciju i dobili smo tender za automatizaciju sedamnaest benzinskih stanica. Žalbe su počele posle puštanja u rad, a nestala je velika suma novca. Njegovo tumačenje nije bilo nerazumno. Redosled događaja pokazivao je pravo na nas.

Bilo je to i lično, na način na koji ugovori retko jesu. Posao sam lično dogovorio, a vlasnici su projekat vezali za mene, a ne za firmu iza mene. Na završnom sastanku rukovali su se sa mnom i otvoreno rekli da očekuju da ja odgovaram za svaki novac koji ih projekat košta. Tamo gde sam tada radio, takav stisak ruke vredeo je otprilike koliko i potpisana klauzula.

Prva greška nam je bila što nismo pogledali oblik žalbi

Podrška je nedeljama beležila incidente. Niko nije postavio očigledno pitanje o tom dnevniku: da li je to jedan isti kvar koji se ponavlja, nekoliko nepovezanih, lokalni problem u radu ili isti događaj koji različiti ljudi prijavljuju iznova i iznova?

To je uobičajena zamka svakog uvođenja sistema. Sistem pouzdano otkazuje dok ljudi rade, a besprekorno se ponaša čim specijalista stane pored njih. Ako se taj jaz prepusti sam sebi, pretvara se u međusobno nepoverenje: korisnici zaključe da softver ne valja, tim za implementaciju zaključi da su korisnici nepažljivi, a niko ne gleda dokaze.

Pitajte kakav oblik problem ima, a ne koliko je velik

Pre sastanka sa vlasnikom tražio sam od našeg tima nešto drugo umesto ukupnog iznosa. Pet pitanja, nijedno pametno:

• Gde: na kojoj od sedamnaest stanica stoji razlika i kako se svaka od njih poredi sa ostalima?
• Kada: u kom periodu se nakupila i da li je počela pre ili posle puštanja u rad?
• Ko: koje smene i koji ljudi su u njima radili?
• Šta: koje kategorije proizvoda i šta ti proizvodi imaju zajedničko, fizički i komercijalno?
• Drugde: da li se isti obrazac javlja na nekoj drugoj lokaciji koja radi na istoj verziji?

Šta je raščlanjavanje pokazalo

Svaka prijava greške došla je sa jedne stanice, iz jedne smene. Ni manjak, oko 10.000 dolara nakupljenih za mesec dana, nije bio ravnomerno raspoređen po asortimanu. Stajao je u tri kategorije: cigarete, skuplja žestoka pića i čokolada. Malo, skupo i lako se iznese iz objekta a da niko ne primeti.

Na sastanak sam doneo odštampane izveštaje, jer je to bilo davno pre nego što je iko mogao da otvori raščlanjavanje na telefonu. Do tog trenutka vlasnik i ja smo gledali isti ukupan iznos i iz njega čitali dve različite situacije. On je video propalo uvođenje na celoj svojoj mreži. Raspodela je pokazivala da, šta god da je to bilo, živi na jednoj lokaciji, u jednoj smeni, u jasno određenoj grupi proizvoda.

Broj se na tom sastanku nije promenio. Promenilo se koliki deo posla on dovodi u pitanje, a time i gde bi iko trebalo da provede narednu nedelju tražeći.

Kasnija istraga potvrdila je da gubici potiču od namerne zloupotrebe, a ne od greške u obračunu. Želim da budem precizan u tome šta su podaci tu uradili, a šta nisu. Nisu ništa dokazali. Dokaz je došao iz dokumenata, popisa i razgovora, gde mu je i mesto. Raščlanjavanje je uputilo istragu na mesto gde je zaista mogla nešto da pronađe.

Kada bi objašnjenje bilo tačno, kako bi podaci izgledali?

To pitanje je deo ove priče koji sam od tada najviše koristio, i to ne samo za manjkove. Uzmite objašnjenje koje je na stolu, pretpostavite na trenutak da je tačno i zapitajte se kakav bi obrazac moralo da ostavi za sobom:

• Sistemska greška u obračunu trebalo bi da se pojavi na svim lokacijama, u svim smenama, kod svih korisnika i u svim kategorijama, jer ista logika radi svuda. Retko se zadržava u jednom kutu mreže.
• Problem sa obukom ili načinom korišćenja obično prati određene ljude ili smene i bledi na lokacijama gde ista verzija radi sa iskusnim timom.
• Greška u podešavanju obično počinje na dan kada je nešto promenjeno i prestaje na lokacijama gde nije.
• Gubitak od zloupotrebe obično se koncentriše na artikle koji su mali, vredni i laki za iznošenje, i često u uskom vremenskom okviru.

Današnji podaci iz maloprodaje pokazuju u istom pravcu. U američkom istraživanju National Retail Security Survey trgovci su 36% svog manjka pripisali spoljnoj krađi, 29% sopstvenim zaposlenima, a 27% propustima u procesima i kontroli i greškama¹. A popis koji se ne slaže sa sistemom nije uvek gubitak: kada su istraživači uporedili evidenciju zaliha jednog britanskog lanca prehrambenih prodavnica sa fizičkim popisom, 64,7% zapisa se nije poklapalo².

Ništa od ovoga nije presuda. To je način da se odluči odakle istraga treba da počne, što je zaista nešto drugo nego odlučiti šta se dogodilo. Vrednost je u tome da odbacite objašnjenja čijih otisaka u podacima jednostavno nema.

Deset žalbi nije deset kvarova

Ista disciplina važi za sve što sistem označi. Deset žalbi može biti jedan kvar prijavljen deset puta. Automatski otkrivena anomalija može biti statistički neobična, a operativno nebitna, dok malo odstupanje u osetljivoj kategoriji zaslužuje pažnju još ove nedelje. Obim nije težina, a nije ni standardna devijacija.

Zato sam postao oprezan prema sistemima koji dižu uzbunu, a ne pomažu nikome da je proceni. Upozorenje koje kaže da se broj pomerio ostavlja čitaoca tačno tamo gde smo vlasnik i ja bili pre nego što su se pojavili odštampani izveštaji. Zaseban argument o tome zašto izveštavanje mora da pređe sa beleženja onoga što se dogodilo na usmeravanje sledećeg koraka izneo sam u tekstu Od računovodstva do navigacije; ovaj tekst se bavi užim, praktičnijim pitanjem: kako pročitati jednu anomaliju kada se pojavi.

Šta to znači za upozorenja koja šalje vaš sistem

Zato je marql napravljen da odgovori raščlanjavanjem, a ne samo ukupnim iznosom. Kada se razlika pojavi u zalihama, marži ili gotovini, koristan sledeći ekran je raspodela: koje lokacije, koji periodi, koje smene, koje kategorije i dobavljači. marql čita POS, računovodstvene i magacinske sisteme koje lanac već koristi, hostovan je u EU, a sledeće pitanje je sledeća poruka u istom razgovoru, a ne novi zahtev nekome u finansijama. O tom trenju sam pisao u tekstu o skrivenoj ceni ručnog izveštavanja.

Ograničenja vredi reći jednako otvoreno kao i mogućnosti. marql ne utvrđuje nameru, ne zamenjuje popis i ne vodi istragu. Ono što radi jeste da operativnog rukovodioca ili finansijskog rukovodioca dovede do istih odštampanih izveštaja koje sam ja nosio na taj sastanak, za nekoliko minuta umesto posle nedelju dana zapitkivanja, a cene počinju od 200 EUR mesečno.