Внедрение системы управления запасами - это сложный процесс, требующий опыта, знаний и вовлеченности сотрудников. К сожалению, не все подобные проекты заканчиваются удачно. В итоге страдают обе стороны - заказчик, так как не смог решить свои проблемы, и вендор, так как получил репутационный урон. В сегодняшней статье мы поделимся кейсом неудачного внедрения, разберем ошибки и расскажем как внедрить систему управления запасами.
Внедрение системы управления запасами. Предыстория
С запросом о выборе системы и дальнейшем ее внедрении к нам обратилась компания, которая является федеральным дистрибьютором. Компания имеет логистические комплексы по всей территории РФ, сотрудничает с более чем 40 000 розничных продавцов, которым поставляет около 10 000 позиций товаров.
Компания обратилась к нам с классическим запросом - необходимо было: сократить излишки продукции на складах, тем самым высвободить оборотные средства; корректно распределять товары внутри собственных логистических комплексов и складов; минимизировать потери от списания просроченной продукции.
Сделаем небольшое пояснение к тому, как происходит внедрение Forecast NOW! Оно включает в себя две составляющие. Одна из них – это интеграция с учетной системой заказчика для загрузки/выгрузки данных. Интеграция может быть проведена силами IT специалистов заказчика, либо с привлечением интегратора. Мы со своей стороны предоставляем подробную документацию и консультируем специалистов по возникающим вопросами.
Вторая составляющая - это настройка системы в соответствии с правилами, методикой и бизнес-процессами, которые приняты в компании. Эти работы могут проводиться силами специалистов заказчика, либо с привлечением сторонних консультантов по управлению товарными запасами, которые имеют опыт успешного внедрения систем управления товарными запасами, могут организовать необходимые работы, как внутри компании заказчика, так и наладить эффективное взаимодействие с разработчиком ПО. Мы также сопровождаем весь процесс настройки программы: консультируем по сопоставлению бизнес-логики клиента с нашей программой; консультируем по функциях и возможностям системы; подсказываем, как настраиваются те или иные параметры.
Выбираете систему управления товарными запасами? Скачайте подробную пошаговую инстркцию.
Дальнейшее развитие событий
После обсуждений внутри компании было решено проводить внедрение системы собственными силами. Это решение было достаточно спорным. Во-первых, из-за размеров самой компании и объемов предстоящих работ. Во-вторых, из-за отсутствия полноценной проектной команды с выделенным временем. Но заказчик настоял именно на таком решении, проигнорировав все наши предостережения.
Куратором внедрения был назначен руководитель смежного подразделения, имеющий опыт реализации подобных проектов, но с низкой квалификацией в области управления товарными запасами. Основным оператором проекта, т.е. тем, кто должен был отвечать за настройку, тестирование и отладку системы, был назначен сотрудник, отвечающий за оптимизацию бизнес-процессов в компании. Оба сотрудника хорошо зарекомендовали себя в компании, как грамотные менеджеры в своих подразделениях, но при этом не имели достаточно хорошо налаженных коммуникаций с другими подразделениями.
Ошибка № 1. Два ключевых участника проекта напрямую не были связаны с управлением товарными запасами в компании. При этом выбранные сотрудники были заинтересованы в удачном завершении проекта, но не в результативности при дальнейшем использовании систему управления запасами.
Рекомендации по выбору куратора проекта:
1. Желательно, чтобы это был сотрудник, который хорошо понимает специфику управления запасами. Он должен сформировать метрики, по которым можно отслеживать, что улучшит система управления товарными запасами.
2. Куратор проекта должен быть наделен достаточными полномочиями (в т.ч. неявными) и иметь налаженные коммуникации со всеми отделами внутри компании. Это один из ключевых моментов, который отделяет удачные внедрения от провальных.
3. При этом, чтобы внедрение scm системы прошло успешно он должен уделять 100% своего времени текущему проекту. Часто сотруднику предлагают взять внедрение сверх основных обязанностей. На как бы не был заинтересован сотрудник, работать в таком режиме продолжительное время мало кто сможет. Другой распространенный вариант - выделить 20-30% рабочего времени на внедрение системы. Но основной работы при этом не становится меньше и в итоге приходиться работать сверхурочно. Поэтому заранее стоит проработать этот вопрос внутри компании.
4. Сотрудник должен быть готов разбираться в принципах работы системы. Лучше всего, если он является активным сторонником системы и инициатором внедрения.
Кроме обозначенных выше участников в группу вошли сотрудники отдела IT, которые должны были заняться интеграцией. Однако сотрудников отделов закупок и логистики в проектной группе не было. Как будет показано дальше - это негативно сказалось на использовании системы управления запасами. Соответственно все работы по настройке и тестированию системы легли на плечи единственного участника, который для успешного внедрения проекта должен был уделять ему от 70 до 100% времени. В реальных условиях этого достичь было невозможно, так как основные обязанности с него никто не снимал.
Ошибка № 2. Объем работ оказался несоизмерим с количеством участников проекта. Рекомендация – проектная команда помимо куратора должна содержать, как минимум еще одного-двух человека, в зависимости от объемов работы. На них в дальнейшем ляжет основная часть работы по настройке и тестированию системы.
Ошибка № 3. В проектную команду не были включены сотрудники, которые в последствии должны были ежедневно работать с системой.
Рекомендация. К настройке и тестированию системы должны быть привлечены сотрудники профильных подразделений. Это поможем тщательнее адаптировать систему под нужды компании и снизит риски саботажа в дальнейшем. При выборе сотрудников следует ориентироваться на их лояльность к инновациям и изменениям, так как в дальнейшем они могут стать центром экспертизы, чтобы другие могли к ним обращаться.
По мере того, как внедрение scm системы продолжалось, оператору необходимо было заниматься настройкой и тестированием. Для этого нужно очень хорошо разбираться в собственных бизнес-процессах, тонкостях заказа товара, прогнозирования спроса и всех внутренних правилах в компании. Вообще говоря, тестовая эксплуатация - это ключевой этап, так как пользователи привыкают к самой программе и при необходимости оптимизируют настройки.
Рекомендация. Для того, чтобы еще больше повысить эффективность управления товарными запасами на этом этапе можно пригласить стороннего консультанта, имеющего большой опыт работы с разными компаниями и методиками управления товарными запасами, опыт работы внедрения подобных систем. Он сможет указать на существующие ошибки в методологии и поможет скорректировать процессы.
Возвращаясь к внедрению scm системы в компании, как уже было отмечено выше, все описанные работы должен был выполнить оператор проекта. Было понятно, что такой объем работы не под силу одному человеку. Мы, со своей стороны, старались чаще контактировать с заказчиком, предлагать свою консультации и готовы были всячески помогать с внедрением. К сожалению, в первые 2-3 месяца заказчик редко шёл на контакт, изредка задавая вопросы и отвечая, что все под контролем. Но как выяснилось позже – сложности все же были.
Причем сложности были и со стороны интеграции Forecast NOW! c учетной системой компании. Как и в случае с другими вопросами IT-подразделение заказчика не торопилось выходить с вопросами к нам, а пытались решить проблемы самостоятельно.
Ошибка № 4. Отсутствие постоянной коммуникации между заказчиком и вендором. Рекомендация – важно держать вендора в курсе внедрения проекта и своевременно оповещать о возникших сложностях. Несмотря на то, что мы не занимаемся внедрением продукта, мы напрямую заинтересованы в успешном завершении проекта. Для этого готовы проводить консультации и оказывать помощь.
Как оказалось, позднее, интеграция сильно затянулась. Вместо того, чтобы в первую очередь наладить обмен только самыми необходимыми данными своей учетной системы с программой и приступить к тестированию уже в течение первого месяца, IT-специалисты выбрали другой путь. Тщательно проштудировав всю имеющуюся документацию, программисты принялись настраивать обмен всеми возможными типами данных (размеры складов, зоны хранения, всевозможные ограничения поставщиков), не разбираясь нужно ли это на данном этапе и в целом, в дальнейшей работе. В итоге процесс сильно затянулся.
Рекомендация. Важно идти итеративно и как можно раньше начинать работать, настраивать и тестировать программу. Процесс интеграции с учетной системой при корректном подходе занимает от 2-х до 4-х недель.
Только в последнем месяце пилотного проекта участники проектной группы начали активно задавать нам вопросы и пытаться ускорить решение накопившихся проблем. С ростом количества вопросов стали появляться и претензии к нам. Вся их суть сводилась к двум вещам – ответы на вопросы были слишком «сухими», недостаточное погружение в бизнес-процессы заказчика. Часто такое происходит, когда специалисты заказчика сами недостаточно погружены в собственные бизнес-процессы и не могут или не хотят в этом разбираться. По факту они заинтересованы только галочке выполненного успешного проекта, а не в реальном изменении KPI.
Мы оказываем консультации по сопоставлению бизнес-логики клиента с нашей программой. Но основная работа ложится на клиента, который должен хорошо разбираться в своих процессах, либо на приглашенных консультантов. Мы консультируем по функциях и возможностям системы, подсказываем, как настраиваются те или иные параметры, можем давать общие рекомендации или разбирать конкретные примеры. Но за конечную настройку отвечает клиент.
К окончанию пилотного проекта началось тестовая эксплуатация системы, а с ней появилось сопротивление со стороны сотрудников отдела закупок. Никто не хотел менять привычный уклад работы. Так как в самом начале внедрения системы, сотрудники отдела закупок не были вовлечены в процесс, то они начали саботировать использование системы и не желали в ней разбирать.
Работники привыкли к конкретным цифрам заказов, к объемам продукции, которая приходит на склады. Для этого они использовали привычную методику сравнения. Методологию же, которая используется для расчетов заказов в Forecast NOW! им никто не объяснил. В результате они начали сравнивать заказы, которые делает система со средними дневными продажами. Показатели не сходились. А часто сотрудники просто интуитивно считали, что объемы заказов должны быть другими.
В результате, настройки системы стали выставлять таким образом, чтобы результат сходился с их предыдущим опытом, со старой методологией. Настроив таким образом систему на одном складе, подобную конфигурацию попытались перенести на другие. Но, так как ситуация на разных складах может сильно отличаться, такая «оптимизация» не всегда работала. В итоге – ложные выводы об эффективности программы.
Часто возникала ситуация, когда программа объективно корректно (по результатам последующего анализа) формировала заказ, но количество товара казалось для сотрудника некорректным. Так как он мог несколько лет работать с определенной товарной позицией, то любые отклонения интуитивно трактовались как дефицит или сверхзапасы. И это без какого-либо анализа и разбора сразу транслировалось руководству выше, как некорректный заказ и неправильная работа системы. По факту же, после анализа, оказывалось, что нет не избытков, не дефицитов. И более того, ретроспективно по заказам менеджера были видны излишки или дефициты
Ошибка №5. Люди используют старую методологию для сравнения с новым инструментом. Это верный путь к тому, чтобы провалить внедрение.
Рекомендация. Нужны объективные метрики того, как происходит весь процесс. Сопротивление может быть настолько велико, что по указке свыше часть работы сотрудники будут делать в Forecast NOW! и докладывать об этом руководству. Но заказы будут делать все равно по-старому. Поэтому важно доносить до сотрудников методологию работы системы с самого начала использования и объяснять, в чем различие с их старой методикой.
Момент сверки заказов должен быть хорошо проработан. Чтобы это не приводило к тому, что люди будут ожидать к заказу определенные цифры.
Как итог пилотного проекта, эффективность работы оказалась ниже предполагаемой из-за описанной выше ситуации. По результатам проекта, топ-менеджмент отказался от использования системы управления запасами в дальнейшем.
В заключении нужно сказать еще об одной, пожалуй, самой главной ошибке при внедрении системы. Это отсутствие контроля пилотного проекта со стороны топ-менеджмента. В компании после начала внедрения, пилотная группа замкнулась в себе и весь проект практически не контролировался и не проверялся руководством компании. На все вопросы по ходу проекта куратор ограничивался стандартными отчетами о том, что все и идет по плану.
Рекомендация. По статистке, от 40 до 80% оборотных активов в российских торговых компаниях содержатся в товарных запасах. И оптимизация страховых запасов – это стратегически важное направление. Поэтому, проект по внедрению системы управления товарными запасами должен в обязательном порядке курироваться ТОП-менеджментом компании.
В следующей статье мы поделимся несколькими примерами удачных внедрений и на их основе расскажем, как обеспечить положительный исход.
