Технические и поведенческие сложности внедрения изменений в управлении запасами и кейсы их решения на опыте внедрения ТОС

StockM — это решение для производственников, дистрибьюторов и ритейлеров. Мы внедряем систему управления запасами, которая позволяет заказывать так, чтобы не было ни излишков, ни упущенных продаж. Слово «позволяет» здесь выделено не напрасно — чтобы добиться такого эффекта, систему нужно правильно использовать, а это не всегда происходит.

В идеале, механизм внедрения системы автозаказа выглядит так:

• Запускаем IT-соединение для обмена данными.
• Организуем внедрение на рабочем месте. Настраиваем систему и обучаем людей — и начинает работать автозаказ по теории ограничений.
• Начинается управление запасами по показателям — когда решения принимаются на основе данных об излишках и упущенных продажах.

В реальности все не так просто. Дело в том, что обычно речь идет о внедрении нового алгоритма автозаказа и вообще правил работы в цепи поставки. Это значит, что в компании клиента уже есть система, которая работает по своим правилам. И чтобы внедрить другой алгоритм, нам нужно:

• Переделать программное обеспечение. Должен использоваться новый инструмент.
• Поменять процессы. Важно создать правила и объяснить, как надо работать по новому алгоритму.
• Обучить людей. Мало передать опыт — нужно убедиться, что сотрудники компании работают правильно.
• Помочь клиенту достичь очевидных положительных изменений. Это очень важный шаг — без него все остальное бесполезно. Нет смысла менять процессы и программное обеспечение, тратить время на обучение, если это не помогает улучшить ситуацию в компании.

При этом процесс важно не затягивать — мы должны понимать, что работаем в условиях ограниченного времени.

Давайте рассмотрим механизм внедрения подробнее, а также расскажем, какие диалоги бывают во время внедрения.

Стоит ли менять программное обеспечение клиента? Нашим первым проектом было внедрение решений теории ограничений для одной из сетей магазинов. У клиента уже было программное обеспечение, позволяющее автоматизировать заказы поставщикам, и нашей задачей было его перепрограммировать с учетом алгоритмов теории ограничений. Что мы и сделали.

Поначалу такая схема работы казалась оптимальной. Но мы быстро поняли — на самом деле так действовать нельзя. На тот момент широко использовалось 6 разных систем — и перепрограммировать каждую из них для каждого клиента не представлялось возможным, ведь затраты сил и времени были бы колоссальными. И не только наших, но и клиента.

И тогда мы приняли решение создать собственную систему управления запасами, которая будет реализована по алгоритмам теории ограничений ТОС, будет работать отдельно и не взаимодействовать с программным обеспечением клиента напрямую, но только обмениваться данными. Так проблема была решена.

Вдобавок мы получили серьезное преимущество: собственный продукт гораздо проще развивать и обслуживать, чем чужой перепрограммированный. Клиенту также легче получать обновления всех продуктов — они не конфликтуют друг с другом и обновления одного программного продукта не парализует работу другого. Позднее мы и вовсе поместили систему в облако — с этого момента уже не нужно было ехать на рабочее место сотрудника клиента, чтобы провести обновление.

Конечно, мы хотели, чтобы StockM была самой эффективной, современной — лучшей системой. Но мы поняли, что лидирующая система должна быть одновременно:

• Гибкой, способной подстраиваться под потребности конкретной компании. Это значит, что каждый наш клиент должен найти в системе именно те функции, которые ему нужны.
• Простой в управлении и освоении. А это значит, что нельзя внедрять в систему огромное число функций, чтобы угодить каждому клиенту — выбирать нужно только то, что подходит большинству.

Здесь есть явное противоречие, которое трудно обойти.

Наш путь — реагировать на все запросы пользователей и при необходимости расширять функционал. Мы собираем запросы, обсуждаем их и, если нужно, обновляем систему. Но есть основное правило: это изменение не должно противоречить логике продукта. Мы и здесь действуем по здравой логике ТОС и понимаем, что это должно быть решение не следствия, а причины. Поэтому, когда клиенты обращаются с запросом для изменений системы, мы выясняем, какую именно проблему они решают. Возможно, за 12 лет существования и развития программного продукта она уже была решена, а может, это просто устранение последствий и нужно решение для более глубокой причины. Каждое обновление системы доступно всем нашим клиентам.

При внедрении автозаказа важно обойтись без революций. Революции — это долго и трудоемко, они вызывают сопротивление со стороны клиента и при этом не всегда приводят к нужным результатам. Даже если консультанту кажется, что после революции в компании все стало идеально — показатели управления запасами могут говорить об обратном.

Для скорости и успешности улучшений нужен фокус внимания. Поэтому менять нужно только те процессы, без которых улучшение будет невозможно:

• Наличие данных в учетной системе. Важно, чтобы в системе клиента были данные о продажах, закупках, остатках.
• Своевременность внесения данных. Есть клиенты, которые предпочитают вводить все данные «задним числом» — такую практику нужно менять.
• Процесс ввода и вывода SKU. Важно, чтобы не было ситуаций, когда появился новый товар или отказались от старого, а в системе это не отражено.

Это не значит, что не нужно начинать внедрение новой системы управления запасами, пока не решили все проблемы в учетной системе. Внедрение позволит их увидеть и промотивирует быстро устранить, даже если до этого годами не могли сесть за решение проблем.

Те процессы, которые уже достаточно хороши, мы стараемся не трогать вообще или менять по возможности минимально — так легче внедрять систему.

Самая большая сложность, с которой сталкиваемся при внедрении новой системы — это люди.

Во время первой встречи с клиентом короткой беседы достаточно, чтобы понять, как обстоят дела с техникой, с IT, с наличием данных — и уже можно предположить, как будет идти работа. Но с людьми все не так. Никогда не знаешь, что тебя ждет.

Есть еще один момент, о котором нельзя забывать. Обычно в процессе продажи менеджер общается с руководителями, а если бизнес маленький — с собственниками. Собственники и руководители часто слишком хорошо думают о порядке в IT, а также о гибкости своих сотрудников, об их склонности к изменениям. Не стоит всецело опираться на их оценки.

Когда начинается сотрудничество с новым клиентом, часто кажется, что все идет отлично. Контракт подписан, заказчика все устраивает, он доволен предложением и готов работать.

Но тут мы сталкиваемся с первой проблемой.

Принимают решение и подписывают контракт руководители. Но те, с кем нам придется работать — совсем другие люди. И с этими людьми на стадии продажи мы ни разу не общались.

Сложность в том, что у нас, у руководителей и у сотрудников компании, с которыми нам предстоит работать, совершенно разные ожидания.

Руководители думают:

• Система выглядит просто и понятно. Значит, ее быстро внедрят и все будет работать как часы.
• Мы получим даже больше, чем планировали. Эффект для бизнеса превзойдет ожидания.

Мы надеемся:

• Будет стандартное внедрение, никаких форс-мажорных ситуаций, нестандартных проблем. Свою работу мы делали десятки раз, уже знаем все подводные камни, и никаких новых сложностей не возникнет.
• Мы поработаем над проектом 9 месяцев, проследим, чтобы все этапы прошли гладко, убедимся, что компания успешно перешла на новую систему. А потом спокойно оставим клиента работать дальше самостоятельно.

У сотрудников компании, с которыми нам предстоит работать, надежды самые простые. Они хотят, чтобы руководство перестало выдумывать новые методы и не мешало действовать по привычным схемам.

Почему ожидания от сотрудничества с нами именно такие? Потому что, хотя мы и консультанты, но предлагаем IT-решение, и нас принимают за IT-компанию. А IT-компании (те, кто делает) часто отличаются от консалтинговых (те, кто думает):

Речь вовсе не о том, что IT-компании плохи — совсем нет. Но многие из них работают по принципу «вы заказали, мы сделали — если что-то не работает, то это проблема в вашем техническом задании». Консалтинговые компании обычно действуют иначе. Хороший консультант берет ответственность за результат на себя, но при этом задает очень много вопросов, анализирует ситуацию и часто не соглашается с первыми решениями клиентов.

Мы — в первую очередь консалтинговая компания. Когда к нам обращаются, мы стараемся найти проблему, а не убрать симптомы. Для этого приходится задавать множество вопросов. Один из самых простых и быстрых способов докопаться до проблемы — это метод пяти «почему». Им мы часто пользуемся. Строится примерно такой диалог:

Вот так проблему выявили, теперь можно думать над решением.

Но это тоже относится к разряду наших ожиданий. В реальности все иначе:

Как это происходит на практике. Внедрили систему. Звонит клиент с претензией:

Взгляните на голубую линию — линию запасов — и увидите классическую «пилу» запасов. Линия запасов резко идет вверх, когда мы получаем заказ, затем уходит вниз — по мере того, как продаются товары. В определенный момент продажи начинают идти хуже, чем раньше — линия запасов опускается до желтой зоны, а за этим следует еще один заказ. Клиент недоволен: «Почему был заказ, если очевидно, что спроса нет?»

Мы пытались объяснить, что поставки не ежедневные, а еженедельные, что есть определенное время выполнения заказа и пр. — ничего не помогало.

Клиент понял, что произошло, только когда мы сделали так:

Мы закрыли часть графика на мониторе листом бумаги и сказали: «Вот тут должен быть заказ. Вы видите, что спроса нет?» Клиент ответил: «Нет, не вижу». «Так кто тогда может предугадать, что спрос упадет?» Таким образом мы добились взаимопонимания.

Рассмотрим еще несколько распространенных трудностей, которые возникают при внедрении системы. Все примеры — из нашей практики.

С такой претензией к нам пришел клиент. Спрашиваем:

— Почему вы так думаете?

— У нас 2000 SKU на РЦ (распределительный центр), три работника целый день делают заказ.

Мы удивляемся — у нас есть проекты, где один человек без особых проблем справляется с 70 000 SKU за день.

— Расскажите, как вы работаете.

— Мы ставим рядом два компьютера. На одном изучаем остатки каждого SKU в наших 50 магазинах, на втором указываем, сколько единиц товара заказать. Далее переходим к следующему SKU. Смотрим, какое количество нам предложила система, думаем, меняем цифру и идем дальше.

— Почему вы так делаете? Кто вас так научил?

— Мы сами решили, что так будет лучше.

В этом случае нужно объяснять: есть инструмент, есть правила его использования и надо работать именно по этим правилам. Хорошо работает такая аналогия: можно приготовить яичницу на лопате, но тогда не нужно говорить, что это сложно, неудобно и негигиенично.

Клиент недоволен: пришлось списать яйца (срок годности — 30 дней). Уточняем:

— Как часто поставщик привозит яйца?

— 2 раза в неделю.

Получается, за срок годности продукта проходит 9 заказов — этого более чем достаточно, чтобы товар не приходилось списывать. В чем же дело?

Мы просим показать график (точка — это один день). И видим:

Крестики внизу — это списания. Да, они присутствуют. Но также очевидно, что буфер слишком большой. Кроме того, поставки не дважды в неделю, как говорил клиент, а раз в две недели.

Синие треугольники внизу показывают: тут был сформирован заказ. Если в программе посмотреть детали, можно увидеть такую картину: сформирован заказ на 1000 единиц товара, отправлено поставщику 0. Мы задали вопрос — почему сформированные системой заказы удалялись вручную? Клиент ответил: «На центральном складе решили, что яйца везти не надо».

Когда мы разъяснили, что заказы должны быть более частыми, поскольку величина запасов тогда станет меньше и списаний не будет — ситуация изменилась, и это видно на графике:

При этом можно видеть, что даже после разъяснений заказы стали делать не дважды, а раз в неделю. Если бы они оформлялись чаще, ситуация была бы еще лучше.

Клиент жалуется на упущенные продажи и объясняет это проблемами в работе системы. Открываем график и видим: буфер уменьшен человеком, и вдобавок, когда система формировала заказы, они удалялись вручную. Когда мы спросили, почему, то получили ответ: «Согласно отчетам, остатков товара должно было хватить на 99 дней».

Мы спросили — как вы это посчитали? Оказалось, что на центральном складе суммировали остатки товара во всех магазинах, делили на среднедневные продажи и получали такой результат. При этом не обращали внимание на то, что в некоторых магазинах нужного товара не было вообще — продавать было нечего. Если хотите изменить результаты управления запасами придется менять и подходы.

Приводить такие примеры можно долго.

Сложно понять, почему люди склонны создавать свои правила работы с инструментом, а не следовать простым инструкциям. Возможно, мы просто применяем новые инструменты «по принципу телевизора»: сначала нажимаем кнопки интуитивно, меняем настройки по своему усмотрению, допускаем ошибки и только потом, не добившись нужного результата, читаем инструкцию.

Классический вопрос от клиента: «Я долго изучал тему и знаю, что чем чаще оформляются заказы, тем меньше должны быть запасы. Я пересмотрел все заказы, сделал поставки в два раза чаще, прошло время, а запасы не изменились. Почему?»

Важно понять, что запасы сокращаются тогда, когда повышается частота пополнения на уровне конкретного SKU, а не на уровне транспорта. Увеличение фактов отправки грузовика от поставщика, если в каждом грузовике не идет один и тот же товар, никак не сокращает количество этого товара на руках. Если раньше мы возили какой-то продукт раз в неделю, а теперь грузовики приходят каждый день, но этот продукт все еще приезжает раз в неделю, на запасах это не скажется никак. Так бывает в двух случаях: когда поставщик устанавливает слишком высокий минимальный размер партии, либо когда мы редко формируем заказ на этот SKU. Распространенная ошибка, когда на товары группы С придумывают другие правила заказа, чем на, А и B. Если будем пополнять товары группы С реже — их запасы лишь вырастут.

Отдельная проблема — клиенты хотят возить чаще, но вместе с тем им важно заполнить каждый грузовик. Бывает так: система оформляет заказ на половину грузовика, а клиент вручную добавляет товары. В следующий раз система предлагает заказать еще меньше продукции (ведь запасы выросли), но клиент снова добавляет товары вручную, чтобы заполнить грузовик. И в результате у него возникает вопрос: почему запасы растут, ведь возим часто?

В этом случае нужно объяснить клиенту: если он продает половину грузовика за неделю, но хочет заказывать полный грузовик — нужно оформлять заказ раз в две недели. Но нужно помнить о риске упущенных продаж в этом случае. Запасы не будут уменьшаться, если постоянно заказывать гораздо больше, чем удается продавать — это противоречит логике.

Очень распространенная ситуация:

Чтобы наглядно показать, почему такой подход неуместен, мы провели сравнение работы человека и системы. Посмотрите на графики:

Тот же товар, тот же магазин, но у человека верхняя граница запасов 240 единиц, а у системы — 45. И если система будет считать так же, как человек, зачем она нужна?

Возникают и другие трудности.

Чтобы система работала правильно, после внедрения мы анализируем данные, рассчитываем буфер, составляем график поставок, исправляем ошибки, которые могли возникнуть при внедрении (особенно когда приходится работать с десятками тысяч SKU). Но важнее другое — мы обучаем сотрудников работе с программой, отвечаем на все вопросы, которые возникают по ходу знакомства с ней. Опыт показывает: если этого не делать, то скорее всего, специалист продолжит считать по старинке — особенно если он не разобрался, как работает система.

Сложность в том, что и это далеко не всегда помогает решить проблему доверия системе.

Вот классический диалог, который происходит после того, как наш консультант все объяснил сотруднику компании клиента, они вместе рассчитали буфер, отследили продажи и составили график поставок:

Еще один вариант диалога:

При внедрении ТОС мы даем клиенту руководство, в котором подробно описаны все основные моменты работы. Процедуры просты и наглядно показаны — это нужно, чтобы каждый сотрудник мог без проблем разобраться в алгоритмах. Вот пример:

Мы пробовали разные способы обучения: предлагали менеджерам выучить процедуры, распечатать схемы и пр. Не работало. И наконец мы поняли: такие процедуры нужны не менеджерам, а их руководителям. По этим схемам они видят, что должен делать менеджер и чему нужно обучать нового сотрудника. Но самим менеджерам это не надо — они разбираются во всем еще на этапе знакомства со StockM. Система проста, и они легко запоминают, что и как надо делать, поэтому им не приходится каждый раз смотреть на схемы.

Нет смысла заставлять менеджеров зубрить алгоритмы или распечатывать схемы — если порядок работы хорошо изучен, проблем не возникнет. А вот руководителям они полезны. Если возникли излишки или упущенные продажи — легко взять процедуру и проверить действия сотрудника.

Чтобы система работала правильно, необходим контроль — мы убедились в этом сами.

Чтобы контролировать работу персонала было легче, мы сделали в StockM такой первый экран (Кстати, сейчас уже вышла следующая версия StockM с более красочным интерфейсом :))

Нажимая на задание, специалист получает всю необходимую информацию — данные о состоянии задачи и рекомендации по ее выполнению.

Такой первый экран позволил упростить процесс внедрения системы. Однако наибольшего успеха мы добились благодаря таймерам — они располагаются в нижней левой части экрана. По умолчанию обратный отсчет заканчивается в 16:00 рабочего дня по местному времени (можно настроить и другое время) — после этого система автоматически отправляет руководителю по электронной почте список всех задач в управлении запасами, которые не были выполнены.

Мы только добавили счетчик в систему и даже не рассказали о нем подробно клиентам, но сразу заметили, что все задачи у большинства менеджеров стали выполняться не в конце рабочего дня, как раньше, а до 10 утра.

Такой контроль — хорошее решение проблемы «лени». Но есть другая трудность — синдром студента.

Менеджерам, которые управляют заказами, приходится выполнять два вида работы: там, где надо думать и там, где надо просто делать. И мы заметили такую тенденцию. До внедрения StockM большую часть рабочего времени менеджера отнимают рутинные действия — в частности, формирование заказа. При этом на работу, которая требует размышлений — изучение и анализ показателей — времени не хватает. Вдобавок из-за синдрома студента рутинные действия часто совершают в последний момент — например, за день или за несколько часов до отправки заказа. На показатели в результате никто не обращает внимания.

После внедрения системы отправка заказа становится секундным делом. Менеджер открывает заказ, нажимает на кнопку «отправить поставщику» — и готово. Если потребуется, можно выбрать опцию оптимизации по транспорту или по сумме. Более того, можно настроить систему так, чтобы она отправляла заказы автоматически.

Казалось бы, теперь должно появиться достаточно свободного времени для работы с показателями?

Опыт показывает, что нет. Часто после внедрения системы выясняется, что люди не тратят меньше времени на формирование заказа. Они привыкли делать такую работу в течение нескольких часов, поэтому начинают изучать систему, что-то проверять и перепроверять, выполнять огромное количество ненужных действий. В одной из компаний, с которыми мы работаем, менеджеры по требованию руководства заполняли огромные таблицы для подтверждения правильности расчетов. Из-за этого нет экономии времени, хотя она должна быть — и сотрудники компании по-прежнему не изучают показатели, не смотрят на упущенные продажи и излишки, не анализируют информацию, а тратят огромное количество времени на рутинные процессы. Такая проблема должна решаться на уровне руководства. Программному продукту должны быть переданы все рутиные операции автозаказа, а люди должны заниматься интеллектуальной аналитической работой и поиском решений для роста прибыли компании (новые поставщики, новые категории товаров, изменение схем поставок…)

Вы можете прочесть подробнее о программном продукте StockM и о процессе внедрения, а также задать вопросе в форме обратной связи. А ниже есть ссылки на другие полезные статьи.