Комплекс по управлению запасами.
Внедрение, обучение, консультации.

Статья

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

На Международной конференции ассоциации практиков теории ограничений TOCPA выступил Бальнис Гедрюс, разработчик системы StockM. Он рассказал о технических и поведенческих проблемах внедрения ТОС, а также о способах их решения. Вы можете посмотреть выступление на видео, ознакомиться с презентацией или прочитать эту статью, написанную на основе доклада.

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

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

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

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

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

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

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

Изменение программного обеспечения автозаказа

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

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

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

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

Дилемма развития системы

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

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

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

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

Изменение процессов управления запасами

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

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

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

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

Обучение сотрудников компании

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

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

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

Ожидания и реальность внедрения

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

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

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

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

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

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

Мы надеемся:

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

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

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

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

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

— У нас плохо идет бизнес.

— Почему?

— Мы мало продаем товаров.

— Почему?

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

— Почему не хватает?

— Не успевают привозить товары, которые хорошо продаются.

— Почему?

— Поставки раз в 2 недели в магазины, раз в 1,5 месяца на центральный склад, заказ формируем по прогнозам продаж. Ходовые товары быстро расходятся по торговым точкам, а больше заказать уже не можем.

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

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

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

В ходе дальнейшей беседы выясняется, что прежде клиент не считал упущенные продажи. Они были, но заказчик этого не видел, поэтому и «проблемы не было». Теперь же система показывает, что есть упущенные продажи — и «проблема появилась». Даже если удалось сделать показатели почти идеальными — сложности все равно есть, в отчетах это отражено, и какими бы ни были цифры, клиенту они не нравятся.

Но возникает еще один вопрос: почему система медленно реагирует на изменения спроса? Ведь теория ограничений систем дает очень эффективные решения. И выясняется, что клиент вынес свой вердикт «задним числом». Посмотрите на график:

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

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

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

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

Типичные сложности и причины их появления

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

«Система очень трудоемкая»

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

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

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

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

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

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

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

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

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

«Нам приходится списывать продукцию»

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

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

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

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

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

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

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

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

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

«У нас есть упущенные продажи»

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

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

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

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

Чаще — не значит лучше

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

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

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

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

Вопрос доверия

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

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

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

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

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

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

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

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

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

  • «Система показывает товары, которые были заказаны, когда я еще не работал. Я тут не при чем».
  • «Поставщик привез слишком много. Я заказал 100, он привез 200, так что это не излишки».
  • «Товары нашлись на складе после инвентаризации. Уберите их из отчетов, я не отвечаю за эти остатки».
  • «А это вообще не излишки, их скоро продадут».

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

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

Процедуры: понимание или зубрежка?

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

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

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

Контроль работы персонала

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

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

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

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

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

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

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

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

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

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

Подведем итоги: чему мы научились за время работы с клиентами

  • С техникой все просто. Основная сложность заключается в обучении людей и работе с ними.
  • Инструкции в большинстве случаев не помогают. Люди предпочитают работать по ими же выдуманным правилам.
  • Даже самые простые вещи люди могут воспринимать и оценивать по-разному. То, что очевидно для одного, может быть неясно для другого — а третий может понять это совершенно иначе, по-своему.
  • Большинство людей заражены синдромом студента, и это нужно учитывать.
  • Следует легко давить на людей и контролировать их работу, иначе дисциплины не будет.
  • Начальники, как правило, слишком хорошо думают о подчиненных, а также о порядке в компании — на их мнение не стоит всецело полагаться, планируя работу с персоналом.
  • Люди склонны говорить одно, а делать другое.
  • Люди ищут сложных решений и избегают простых. Они скептически относятся к простым методам и не верят, что такие методы могут сработать. Если вы хотите, чтобы простое решение было принято — подайте его как сложное.
  • И главное — все люди хорошие!

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

Спросите эксперта

Вам ответят сертифицированные TOC-специалисты компании Stock-M Consulting

Задать вопрос
Закажите
обратный звонок
Запланируйте персональную
презентацию Stock-M

Контактная информация