Как да разследвате липса в наличностите, преди да обвините системата

Преди повече от двадесет години приех обаждане, за което още мисля. Около 10 000 долара липса при инвентаризация, потребители, които съобщават за грешки, и собственик, който вече беше стигнал до заключението си: системата, която току-що бяхме внедрили, не работи.

По това време ръководех регионален клон по внедряване и бяхме спечелили търг за автоматизация на седемнадесет бензиностанции. Оплакванията започнаха след пускането в експлоатация, а голяма сума беше изчезнала. Прочитът му не беше неразумен. Последователността на събитията сочеше право към нас.

Беше и лично по начин, по който договорите рядко са. Бях договорил проекта лично, а собствениците го бяха обвързали с мен, не с компанията зад мен. На заключителната среща ми стиснаха ръката и казаха направо, че очакват да отговарям за всички пари, които проектът им струва. Там, където работех, такова ръкостискане тежеше горе-долу колкото подписана клауза.

Първата ни грешка беше, че не погледнахме формата на оплакванията

Поддръжката записваше инциденти от седмици. Никой не беше задал очевидния въпрос към този дневник: това един повтарящ се дефект ли е, няколко несвързани, локален оперативен проблем или едно и също събитие, докладвано отново и отново от различни хора?

Това е стандартен капан при всяко внедряване. Системата отказва надеждно, докато хората работят, и се държи безупречно в мига, в който специалист застане до тях. Оставена така, тази разлика се превръща във взаимно подозрение: потребителите решават, че софтуерът е счупен, екипът по внедряване решава, че потребителите са небрежни, и никой не гледа доказателствата.

Питайте каква форма има проблемът, не колко е голям

Преди срещата със собственика поисках от екипа нещо различно от общата сума. Пет въпроса, нито един от тях хитър:

• Къде: в кой от седемнадесетте обекта стои разликата и как всеки се сравнява с останалите?
• Кога: за какъв период се е натрупала и започна ли преди или след пускането в експлоатация?
• Кой: в кои смени и кои хора работеха в тях?
• Какво: в кои продуктови категории и какво е общото между тези продукти, физически и търговски?
• Другаде: появява ли се същият модел в друг обект със същата версия?

Какво показа разбивката

Всички сигнали за грешки идваха от един обект, в една смяна. И липсата, около 10 000 долара, натрупани за месец, не беше разпределена равномерно по асортимента. Стоеше в три категории: цигари, премиум спиртни напитки и шоколад. Малки, скъпи, лесни за изнасяне от сграда, без някой да забележи.

Занесох разпечатките на срещата, защото това беше много преди някой да отвори разбивка на телефона си. Дотогава собственикът и аз гледахме една и съща обща сума и четяхме от нея две различни ситуации. Той виждаше провалено внедряване в цялата мрежа. Разпределението показваше, че каквото и да е това, то живее в един обект, в една смяна, в ясно определена група продукти.

Числото не се промени на онази среща. Промени се каква част от бизнеса засяга и съответно къде си струва да се търси през следващата седмица.

По-късна проверка потвърди, че загубите идват от умишлена злоупотреба, а не от грешка в изчисленията. Искам да съм точен какво направиха и какво не направиха данните там. Те не доказаха нищо. Доказателството дойде от документи, инвентаризации и разговори, което е и мястото му. Разбивката насочи проверката към място, където тя наистина можеше да намери нещо.

Ако обяснението беше вярно, как биха изглеждали данните?

Този въпрос е частта от историята, която оттогава използвам най-често, и не само за липси. Вземете обяснението, което е на масата, приемете за момент, че е вярно, и попитайте какъв модел би трябвало да остави след себе си:

• Системна грешка в изчисленията би трябвало да се появи във всички обекти, смени, потребители и категории, защото една и съща логика работи навсякъде. Рядко се ограничава в един ъгъл на мрежата.
• Проблем с обучението или употребата обикновено следва конкретни хора или смени и изчезва в обектите, където същата версия работи с опитен екип.
• Грешка в конфигурацията обикновено започва на датата, на която нещо е било променено, и спира в обектите, където не е било.
• Загубата от злоупотреба се концентрира в компактни, ценни и лесни за преместване артикули, често в тесен времеви прозорец.

Днешните данни от търговията сочат в същата посока. В американското проучване National Retail Security Survey търговците отдават 36% от липсите на външни кражби, 29% на собствените си служители и 27% на грешки и пропуски в процесите и контрола¹. А преброяване, което не съвпада със системата, не винаги означава загуба: когато изследователи сравняват складовите записи на британска верига за хранителни стоки с физическо преброяване, 64,7% от тях не съвпадат².

Нито едно от тези неща не е присъда. Те са начин да се реши откъде да започне проверката, което е съвсем различно от това да се реши какво се е случило. Стойността е в отпадането на обясненията, чиито отпечатъци просто ги няма в данните.

Десет оплаквания не са десет дефекта

Същата дисциплина важи за всичко, което системата сигнализира. Десет оплаквания може да са един дефект, докладван десет пъти. Автоматично генерирана аномалия може да е статистически необичайна и оперативно без значение, докато малко отклонение в чувствителна категория заслужава внимание още тази седмица. Обемът не е тежест, а стандартното отклонение — още по-малко.

Тук станах предпазлив към системи, които вдигат аларми, без да помагат някой да ги прецени. Аларма, която казва, че едно число се е помръднало, оставя четящия точно там, където бяхме собственикът и аз, преди да се появят разпечатките. Отделният аргумент защо отчитането трябва да премине от записване на случилото се към насочване на следващата стъпка, направих в От счетоводство към навигация; този текст е за по-тесния и по-практичен въпрос как се чете една аномалия, след като вече се е появила.

Какво означава това за алармите на вашата система

Затова marql е построен да отговаря на разбивката, а не само на общата сума. Когато се появи разлика в наличности, марж или пари в брой, полезният следващ екран е разпределението: кои обекти, кои периоди, кои смени, кои категории и доставчици. Чете POS, счетоводните и складовите системи, които веригата вече използва, хостван в ЕС, а следващият въпрос е следващото съобщение в същия разговор, а не нова заявка към някого във финансите — триенето, за което писах в скритата цена на ръчното отчитане.

Ограниченията заслужават да бъдат казани също толкова ясно, колкото и възможностите. Системата не установява умисъл, не заменя инвентаризация и не води разследване. Това, което прави, е да доведе оперативния ръководител или финансовия ръководител до същите разпечатки, които носех на онази среща, за минути вместо след седмица настояване, с цени от 200 EUR на месец.