Эта история о том, как оптимизация одного участка может быть полностью правильной и при этом ухудшить весь процесс. Именно так произошло с автоматизацией возвратов: одну проблему решили, несколько новых создали на стыках. В компании регулярно возникали недовозы: клиент заказал товар, но часть заказа до него не доехала. Запускалось расследование — склад, транспорт, другие участки. Разбор мог занимать несколько дней или пару недель. Всё это время недовезённый товар продолжал влиять на взаиморасчёты. Клиент мог договориться зачесть эту сумму в счёт следующего платежа, но система всё равно видела просрочку и блокировала новые заявки. Нашли разумное решение: при регистрации заявки по недовозу спорный товар автоматически отражался на виртуальном складе, а взаиморасчёты корректировались. Если расследование показывало вину клиента, оформлялась повторная реализация. Локально решение было вполне рабочим. Но до автоматизации виртуальные возвраты вручную проводили внутренние операторы. И после запуска системы они продолжили это делать. Получился двойной возврат: один автоматически попадал на виртуальный склад, второй вручную — на физический склад, с которого когда-то была оформлена реализация. Остаток удваивался. Взаиморасчёты тоже искажались — уже в ущерб компании. Ситуацию усложняло активное переоборудование складов: товар постоянно перемещался. Поэтому ручной возврат мог восстановить остаток там, где физически такого товара уже не было. Ошибка не выглядела как авария. Каждый отдельный документ был допустимым. На стыке процессов цифры почти не сверяли, поэтому ошибка успевала накапливаться. Дальше она расползалась по цепочке: расхождения остатков, вычерки, ревизии, недостачи, ошибки учёта, сложности с закрытием месяца и расчётом себестоимости. А ИТ и аналитики потом разбирали последствия вручную, в том числе по ночам при закрытии месяца. Автоматизация одного участка добавила ручную работу на соседних — по устранению её же последствий. Сама автоматизация здесь была не главным источником ошибки. Не был спроектирован переход: какие действия сохраняются, какие меняются, а какие должны прекратиться. Не пересмотрели роли и контроль на стыке взаиморасчётов, складского учёта и фактического движения товара. Автоматизировали фрагмент процесса. Остальной процесс продолжил жить по старым правилам. Позже виртуальные возвраты заменили корректировкой реализации. Остаток восстанавливался на складе исходной продажи, но за 45 дней между реализацией и возвратом товар мог успеть переехать. Поэтому расхождения по местам хранения возникали снова.

Такие истории повторялись. Со временем стало трудно списывать это на отдельные недочёты: слишком часто проблема возникала не в самой идее решения, а в том, как её внедряли. Можно было и дальше героически разбирать последствия по ночам. Но дешевле научиться нормально внедрять изменения и проверять, что новый порядок действительно заменил старый, а не просто лёг поверх него.