Бизнес - консультант и кризис менеджер

Кейс Как простой складской проект можно превратить в проблемный или о важности IT систем.

    Проект был следующий:
    --- Склад – РЦ ритейла площадью 60 000 кв. метров
    --- 40% оборота идет паллетным Кросдокингом
    --- Сборка коробами производится по 10 000 SKU
    --- Одно температурный режим
    --- Вес паллеты от 300 кг до 3 тонн.
    --- Специальное лицензирование не требуется
    --- Объем вход – выход  250 машин объемом 65-82 куб. м. в день (250 на приход и 250 на «уход»)
    В общем ничего сложного, даже объем работ с учетом что 250 машин на 40% состоит из паллетного кросдокинга, в общем,  не велик.
    Система заказа на товар делится на четыре части
    --- Магазины делают заказ поставщикам, заказы проверяются ГО (Головной организацией заказчика), поставщики регистрируют заказы на WP (Web portal) на конкретное время и привозят на РЦ. На одной паллете товар только одного магазина. В заказе может быть несколько паллет, на магазин несколько заказов.
    --- ГО делает централизованные заказы поставщикам , создавая резервный товарный запас на РЦ, с которого магазины получают товар коробками, на которые в свою очередь делают заказы.
    --- Акции и прочее формируются в ГО и рассылаются по магазинам «в принудительном порядке» как со склада так и кросдокингом.
    --- Магазины присылают на склад  неликвиды   не сезонный товар  и потом «в сезон» забирают обратно.
    3PL провайдер продолжал работать на своей WMS системе, которая (что правильно) при  взаимодействии должна быть ведущей, те все изменения в товаре делаются в WMS, данные транслируются в IT систему заказчика, откуда и распечатываются сопроводительные документы.
    Схема склада также была сравнительно проста

    Склад открывался на новой площадке, «железо» - ричтраки,  электрические тележки, погрузчики …  были куплены в достаточном количестве.
    Люди  в рамках описанных относительно простых операций  были научены. 
    Склад «пустили», ленточку разрезали … Товар стал поступать (начальное заполнение), начался кродокинг.
    Ввиду «Объективной» простоты склад руководство компании и  менеджеры отвечающие за склады в целом, потеряли интерес к складу .
    Через некоторое время , это 3-4 недели, выяснилось

    --- 20% поступивших заказов на кросдокинг не отправлено по магазинам.
    --- Почти никакая отгрузка не «проходит» автоматом –  информация из WMS не попадала  в систему заказчика в полном объеме , а поскольку документы печатается оттуда, то отгрузки не происходят. И почти все поставки отправлялись в магазины с помощбю программистов
    --- Магазины не дополучили документы на 23% отправок
    --- И тд
    По перечисленным «проблемам», основные  причины следующие
    При пересылке информация в систему заказчика заказы не имеющие все требуемые системой заказчика не считывалось (а склад не получая обратной связи искренне считал что все хорошо – данные же отправлены). По таким характеристикам как номер накладной счет фактуры  требовалось уникальность. А при этом часть поставщиков дублировали номера (что в общем не противоречит требованиям законодательства и РПБУ, тк накладны были от разных дат). Причем программа заказчика проверяли уникальность сравнивая номер накладной  и остальных документов со всеми предыдущими,  за«предыдущей» жизни заказчика, а не только тот период что был доступен WMS для сравнения. И как следствие товары принятые в WMS не транслировались в систему заказчика и счета не выписывались. Кроме этого после приема «отклика» из WMS система заказчика не принимала вообще никаких изменений по принятомо товару, например размер паллет для негабаритного товара и никакие  другие данные товара, которые вообще то нужно иметь возможность менять.
    Поставщики оформляя на магазин несколько заказов  делали на них один пакет документов, например ТОРГ12 и тд. … Склад же оптимизируя загрузку машин (заботясь о заказчике) распределяли заказы по разным машинам, в результате часть товаров приходило «без документ», вызывая ворох претензий (в чем то обоснованных , тк товар который магазин не может пустить в продажу для магазина – бессмысленней). С точки зреняи склада магазин при этом получал весь комплект – пакет документов отправлялся с первым заказом в магазин.
    Кроме того не был решен вопрос что делать если заказчик свой заказ «расставил» на большем числе паллет, «лишние» паллеты в WMS естественно принимались, в систему заказчика не транслировался. При это товары которые должны поставляться комплектами , те содержатся на нескольких паллета рвались и в магазинах оказывался часть товара «Не комплектом».
    Как я уже упомянул, в начальные момент не обратили внимание на все эти проблемы и заказы в магазины «пропихивали» вместе с программистами  заказчика, при этом паллеты которые система заказчика не пропускала оставались на складе (например если в WMS поменялись массогабаритные характеристики), образуя с течением времени достаточно большой ком старого товара, что вызывало отдельные претензии Заказчика
    К  проблемам инициированным поставщиками (сюда нужно отнести товары размером более чем 3*2*3 метра, товары только для машин с боковой загрузкой, а часть магазинов не могли принять такой товар, товары от которых магазины отказались на этапе заказа, но поставщики прислали по первоначальной версии и тд) и интеграций (например отсутствовал инструмент оперативного контроля – попала ли поставка в систему заказчика. Сотрудники оператора – отсылали  информации, в ответ тишина, и о том что система заказчика не приняла поставку выяснялось только на этапе распечатки документов на уже загруженную машину) нужно отнести и часть  субъективных недоработок связанных с WMS и складом.
    --- Покупка  погрузочной техники без запасных  батарей.
    --- Ошибки в WEB  портале через которые поставщики формировали свои отгрузки, позволяющие менять структуры поставки после оговоренного срока, когда данные считывались в WMS и систему заказчика и в результате приходил товар формально не согласованный с Заказчиком и который сема заказчика отказывалась принять.
    --- Недооценка  бумажного документооборота – экспедиция имела три окна (физических окна для общения с водителями), что в общем на 250- машин в сутки , те 10 машин в час нормально, но в силу специфики бизнес оказалось что по каждой машине пачка бумаги 30 см высотой и данные всех этих бумажных документов нужно сверить с электронными и диспетчерская захлебнулась на 3-й неделе (персонал также быть принят и обучен исходя их 10 «обычных» машин в час. )
    --- Сбои WMS. Которые например позволял резервировать один паллет  на две машины
    --- Ошибки в наборе ТОП менеджеров склада
    --- И тд.
    После  «обнаружения» проблемы которая стала уже комом (напомним  сначала склад наполняли, топом стали грузить, те обнаружили что почти каждая поставка не может быть отправлена «Автоматически» когда склад был наполовину заполнен) была сделана и ошибок по исправлению: операционный директор и директор по направлению «складской сервис» лично стали управлять складом в ручном режиме – но существу находясь там круглосуточно. При этом «просели» остальные направления деятельности и складское направление, те ком в какой то степени распространился на всю компанию.
    Начальники смен остались операционными сотрудниками, никто не учил их как управлять складом. Тут нужно отметить, что операционный директор  и руководитель НД «Складской сервис» не были профессионалами и не понимали что начальников смен нужно учить. Нет понимали. Недооценка была реальная сложность склада (связанная с интеграцией и спецификой товаров), склад казался элементарным, легким …  (как и сейчас может показаться прочтя введение в эту заметку) и казалось «вот сейчас сами разгребем» и начальники смен будут управлять этим большим но достаточно «типичным» складом.
    Кроме того поскольку начальники были «велики», то часть мелких вопросов которые начальники смен или склада когда они отвечают за склад  замечают и решают, прошли «мимо кассы», создав дополнительный хаос.
    За склад взялись по серьезному через два месяца после пуска когда и ком проблем  рос и скандал с заказчиком  дошел до кипения.
    Было сделано
    --- Четкая инструкция и список дел для начальников сменю Проведено обучение и введен контроль их работы
    --- Четкая диспетчеризация работы
    --- Четкая система работы с производителя – от невозможности ввести в WEB портале повторно номер накладной (для чего закачали всю базу номеров которая была у заказчика), до «отправки» обратно машин без документов и излишков товаров
    --- Налажен четка диспетчеризация по времени разгрузки (каждый поставщик получал свое временное окно) и загрузки  (поставщики ТС были переведены на систему «Четко в срок»)

    --- И тд
    «Геморрой лечился медленно», финансовые потери были велики..
    Мораль сей басни (к сожалению это не басня а реальный кейс)?
    --- Любой проект, особенно большой, требует серьезного подхода. Склады как производство, двух одинаковых не бывает (как производство в России, имеется ввиду) – серьезно
    --- Важность it в тех случаях когда нужна интеграция или процессы достаточно новые (например несколько потоков сборки) нельзя недооценивать. Руководство не только лично должно проверять интеграционные тесты но и отслеживать пусковые режимы, не полагаться  не рассказы «о временных проблемах». Наоборот любая даже мелкая на первый взгляд проблема есть основания для проверки всей интеграции.
    --- На любой проект должны быть свое реперные точки проверки «все ли идет хорошо», на пусковой режим список существенно больше чем на период «плановой работы»