2005, внедрение ERP, часть 2

Про внедрение ERP можно написать отдельный труд, тем более, что на момент моего ухода из компании работы по "улучшению и уточнению" все еще продолжались. Но даже сам "Deloitte", готовясь к очередной задаче по внедрению следующей трехбуквенной аббревиатуры SCM, признавал, что при первом внедрении были допущены практически все ошибки, которые можно было сделать.
При этом началось все вроде как обычно. Вначале происходили интервью (хотя от многочисленных интервью за последний год народ начал уже слегка беситься) на тему того, каким образом происходит процедура заказа, какие показатели принимаются во внимание и каким именно образом, а также наши пожелания к интерфейсу и функционалу будущей системы.
А после чего нам было сообщено, как именно все это будет реализовано в системе, и мы увидели, что нам предлагают прямо противоположное тому, о чем мы говорили.
Крупнейшей ошибкой, которая была допущена, заключалась в том, что руководители проекта внедрения со стороны Топ-книги абсолютно полно и совершенно откровенно заявили, что проект будет происходить именно так, как они решили, что, видите ли, в других проектах обычно сменяется до 90% персонала фирмы (типа которые не приемлют изменений). При этом все прекрасно понимали, что никакой смены персонала не будет, просто все будут сидеть и материться.
Приведу пример, о каких пожеланиях и интерфейсах шла речь.
Пополнение ассортимента склада производилось ассортиментными менеджерами в файле формата xls, напичканном макросами. По каждой номенклатуре в файле были доступны остатки, статистика продаж за несколько последних недель, с начала года и за прошлые годы, а также информация о товаре в пути, о сделанных, но еще не отгруженных заказах, о предзаказах клиентов и о неудовлетворенном спросе за вчерашний день, а также поля описания товара и разная дополнительная информация, которую каждый ассортименщик мог сам формировать и использовать. Потом с помощью протягивания формул и статистики продаж формировался прогноз продаж по каждой позиции и заказ на закупку. Это могло быть число или просто метка, что данную позицию необходимо проверить. После чего ассортименщик пробегал по всему файлу (по "своим" позициям) и мог скорректировать число или заменить метку на число. Например, он мог решить, что именно данную позицию необходимо заказать с бОльшим или меньшим запасом относительно стандартного, или увидеть, что статистика продаж содержит сильные всплески, и ее необходимо сгладить, или мог просто округлить требуемый заказ до стандарта упаковки. Важно, что при этом ассортименщик ежеминутно чувствовал и ощущал ассортимент. Ничто не являлось более кайфовым, чем заказывать книжки, особенно одной серии, которые стабильно хорошо продаются - от этого возникала какая-то сопричастность к продажам. Да, и еще мы при этом ловили "блох" - например, некорректные предзаказы или статистику продаж. Так как эти файлы делали люди, то иногда они допускали ошибки, а хороший ассортименщик сразу видел, что "здесь что-то не то!"
Конечно, весь этот процесс требовал автоматизации. Необходимо было наличие нескольких разных прогнозов, очень нужна была статистика по большому интервалу, автоматизация отклонений статистики, профили продаж новинок разных жанров, автокоррекция прогноза под маркетинговые акции и т.д. Кроме того, необходим был тщательный процесс тестирования процедуры заказа. Мне кажется совершенно очевидным, что, заложив в систему набор алгоритмов, надо было в течение минимум нескольких недель смотреть, что за числа выдает система, откуда эти числа берутся, какие параметры учитываются, и что необходимо "подкрутить" в системе. Кроме того, в процессе работы мы бы узнавали все новые и новые нюансы, которые до этого находились в головах ассортименщиков, и происходила бы постоянная оцифровка опыта. Возможно, что ERP вообще не годилась для подобного, это скорее уже SCM, но тогда мы этого не знали, а то, что предстоит заказывать товар через "новую хорошую программу", нам было твердо сказано.
И, что самое отвратное, нам было сказано следующее. Так как процесс прогнозирования - это одно, а процесс пополнения - это другое, то нам не предусмотрено интерфейса, в котором мы бы видели одновременно статистику продаж и число, рекомендуемое к заказу. Например, если мы хотим сделать заказ в АСТ (более 25 000 наименований в ассортименте), надо было сначала попросить статистику, потом, если хочется, всю ее просмотреть и указать, где подправить, получить прогноз продаж на выбранный интервал, просмотреть его (еще один прогон), после чего нажать кнопочку и получить некий набор номенклатура/число. Предполагалось, что система сама внутри себя учитывает остатки, товар в пути и т.д. и "правильно" формирует заказ, а мы этому должны поверить. Или, если хотим, проверить: зайти ПО ОЧЕРЕДИ В КАЖДУЮ номенклатуру, нажав несколько кнопок и посмотрев, отчего же такое получилось. И так 25 000 раз.
Я в жизни не поверю, что система якобы не может технически выдавать статистику и формируемое на ее основе предложение к закупке в одной таблице (неважно, в каком эта таблице формате). В ответ же я получал истерические обвинения, что мы хотим микроскопом забивать гвозди и делать из многомиллионной программы "ваш любимый Excel".
В результате первая же попытка сделать заказ после запуска новой системы привела к такой ахинее на выходе, что всякие разговоры о заказах через "новую хорошую программу" затихли просто моментательно. Это без учета того, что статистика по поставщику из сотни наименований грузилась по часу.
Но что самое скверное, после внедрения ERP качество статистики (в первую очередь, остатков и продаж) обрушилось просто одномоментно. Информационный отдел, который раньше за это достаточно хорошо отвечал, весь перешел в отдел по усовершенствованию этой самой ERP. Выгрузки данных происходили через раз и с совершенно дурацкими ошибками (причем далеко не всегда эти ошибки сразу распознавались). Масса полезных данных просто пропала или перестала обновляться - стало уже некому и некогда. Существует стандартная процедура проверки качества данных, когда, скажем, остаток на начало недели должен быть равен остатку на начало предыдущей недели плюс приходы и возвраты минус перемещения, продажи и списания. Эти данные не бились на десятки тысяч товарных единиц в интервале недели, эти расхождения пытались выяснить, в это время появлялись новые и т.д. Потери были колоссальные, причем никто не мог даже посчитать, какие же они в итоге.
Отступление. В 2007 году была проведена выборочная проверка наличия случайно выбранного ассортиментного списка в нескольких торговых объектах. Результат - несовпадение данных более чем в 50% номенклатуры. Вывод - инициирован новый проект по "повышению качества остатков".
Вообще-то любой издатель, получающий отчеты о продажах, если не поленится, может прийти в магазин Топ-книги в Москве и проверить теоретические и фактические остатки. Сюрпризы гарантированы. А ведь по этим отчетам идут оплаты..
Или еще маленькая добавочка на десерт: на начало 2005 года у нас на центральном складе было 100 000 наименований книг, через Топ-книгу тогда проходило около 2/3 наименований книг, выпускаемых в стране. Это было тотальное преимущество перед любым конкурентом. При этом срок оборачиваемости товарных запасов на складе был 6 недель, в рознице - от 3 до 4 месяцев. Именно в 2004 году (а не в 2008, имея в 5 раз больше магазинов) Топ-книга продавала больше всего книг издательств "Медицина", "Машиностроение" и других - специализированных. А что произошло потом? А потом сменилось руководство в управлении логистики и нам было сообщено, что склад "в новой хорошей программе" "не в состоянии качественно хранить и обрабатывать более 60 000 наименований". Но это уже совсем другая история...