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

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

Еще в 2002 году я, работая инженером внедрения WMS, услышал на семинаре выступление одного из первопроходцев рынка складских систем Александра Максимовского. Уважаемый мной и поныне мэтр заявил, как бы невзначай, что у него более пятидесяти неудачных проектов. Никто из слушателей, как мне показалось, даже не задумался, а сколько же тогда удачных. Молодости свойственен оптимизм, и тогда мне казалось, что у меня провальных проектов не будет. Теперь и я могу сказать, что у меня есть неудачные проекты. В последнее время я работаю со всем многообразием складских систем, представленных на рынке, и пришло понимание, что проблема эта – всеобщая. Более того, она общеизвестная, но о ней принято молчать. Однако нельзя сказать, что молчание в этом случае – лучший вариант.

Дело в том, что оно в некотором роде дискредитирует сам рынок систем управления складами. Сегодня уже немало компаний, которые в свое время внедрили WMS, но потом из-за возникших проблем отказались от нее и перешли к более «понятной» схеме работы с 1С: бухгалтерии удобнее, самим логистам меньше хлопот. Такой подход не только не оправдан – он вреден, причем как для заказчиков, так и для рынка WMS в целом, потому что на самом деле сегодня в России немало действительно эффективных WMS-решений и профессиональных поставщиков и внедренцев. Но «болезнь» рынка, которая касается и клиентов, и поставщиков, существует. О ней я и хочу поговорить.

Типичные ошибки при внедрении WMS

Типовой сценарий неудачного проекта внедрения WMS выглядит так. Компания решает купить одну из систем и выделяет на это бюджет. Под него подыскивается несколько поставщиков, и объявляется формальный или неформальный тендер. Основной критерий – насколько компания-поставщик «втиснет» в запланированный бюджет свое решение. Продавцы системы соглашаются решить любую задачу, выдвигаемую заказчиком, убеждая его, что только в их системе и можно решать подобные задачи. При этом клиент не проводит детальный анализ того, какие существуют альтернативы у системы, насколько подходит каждая из систем для решения именно его задач и т.д. Довольно быстро из нескольких поставщиков один получает контракт. Счастливый менеджер компании-поставщика, продавший систему, передает документацию о предстоящем проекте инженерам. Те хватаются за голову: «Как вообще можно было продать подобное? Некоторые задачи даже математически не решаются…». Но отступать уже некуда, и исполнитель, надеясь в процессе внедрения снять эти проблемы путем убеждения, уговоров и некоторой позиционной игры, приступает к анализу процессов. Заказчик выделяет на этот проект со своей стороны несколько человек, но «без отрыва от производства». Понимая, что судьба дала шанс отличиться, эти люди начинают прорабатывать процессы своего склада во множестве нюансов каждой операции. Как правило, количество деталей просто зашкаливает в некоторых процессах, в других же – пустота: не так актуально, или времени не хватило (ведь текущую работу никто не снял), или сфера интересов сосредоточена на одном из участков процесса. Особенно трепетно члены команды со стороны заказчика относятся к своим «изобретениям» и «открытиям», то есть каким-то хитрым процессам, которые они выдумали сами, и которые, по их мнению, должна выполнять система. Доводы инженеров поставщика о том, что куплена не заказная разработка, а стандартное решение, и что все настройки имеют свой предел, заложенный разработчиком, а всякие «анализы» сильно сажают быстродействие, на заказчика не действуют. Может быть, ему и нужна была другая система, но в свое время ему менеджер по продажам компании-поставщика обещал, что «все будет», так что теперь пусть инженеры поставщика отвечают. Отдельно следует сказать о проектном менеджменте. Как правило, заказчик требует предоставления плана проекта. По степени детализации, которую он потребует, уже можно судить о судьбе проекта. Проектные планы с большим количеством деталей и жестким слежением по срокам обречены. Именно они будут иметь максимальное сползание, так как лишают внедренцев возможности маневра. Детали предстоящего внедрения обсуждаются регулярно и обрастают все большим и большим количеством подробностей. Это будет продолжаться до тех пор, пока не подожмут сроки запуска. Приближается дата, когда переносить запуск уже нельзя. В этой точке проект получает шанс выхода из кризиса, причем практически последний шанс. Если находится (неважно с чьей стороны) человек, который берет на себя риски и ответственность, то проект срочно пересматривается с точки зрения здравого смысла, стороны идут на взаимные уступки, за короткие сроки делается рабочее решение и проект переходит в категорию успешных. С сопровождением такого проекта, как правило, проблем не возникает. Если шанс не использован, то срочно переходят к обучению персонала по стандартной схеме, так как адаптированного решения еще не родилось. Обучают только узкий круг специалистов, считая, что остальных обучать будут уже эти люди. Устанавливают недоделанное решение и запускают его. В процессе запуска продолжается позиционная игра. Заказчик не подписывает актов, выдвигая все новые и новые требования. Исполнитель спускает эти требования на тормозах. Исполнитель заявляет, что персонал заказчика и стандартных-то процедур освоить не может, куда ему «навороты»? Проект начинает приостанавливаться и возобновляться попеременно по инициативе то той, то другой стороны. Ситуация продолжается до тех пор, пока на самом высшем уровне руководства не приходит понимание, что эта ситуация затратна для обеих сторон. Проект внедряется так, «как может»… Почему бывают такие случаи и как их избежать?

Неоправданные надежды

 

Рынок WMS решений чрезвычайно конкурентен. На данный момент на нем присутствует примерно полсотни решений и столько же поставщиков. Уже сама эта цифра говорит о том, что выбор будет трудоемким, особенно если учесть, что критериев выбора очень много и что они слабо структурированы. Нет никаких классов систем с четко выраженными границами, позволяющими сузить выбор на ранних стадиях. Любой поставщик с радостью откликнется на предложение рассмотреть его в качестве потенциального автоматизатора. У каждого поставщика есть своя классификация, где его системе, естественно, отведено самое почетное место. Опыт эксплуатации подобных систем у заказчика отсутствует. Для анализа любой системы надо попробовать в ней хоть что-то, а для этого ее надо изучить. Даже сейчас на рынке работают в основном специалисты, которые имели опыт работы только с одной, максимум с двумя системами. А если учесть, что стоимость систем класса WMS высока, становится очевидно, что риски заказчика просто колоссальны. Между тем большинство заказчиков не уделяют этапу анализа и выбору WMS решений должного внимания. На вопросы о том, на основании чего делался выбор в пользу того или иного решения, заказчики почти всегда отвечают коротко и довольно расплывчато. Они ждут, что поставщик скажет им: «Мы все сделаем». Порой так и оно бывает.

Но кто бы, например, рискнул суммой в несколько сотен тысяч долларов, положившись только на русский «авось»? А заказчики WMS нередко делают это, причем часто просто из желания сэкономить время. На рынке WMS уже сейчас есть отличные решения, которые позволяют получить реальный экономический эффект. Только не стоит забывать, что любая система – это всего лишь инструмент, а не волшебная палочка. Поэтому, наряду со всеми своими преимуществами, система имеет и ограничения. Успешный сценарий предполагает, что инструмент будет использоваться так и для того, как и для чего предполагал его разработчик. Кроме того, очень важна и сама технология ввода инструмента в эксплуатацию. Очень часто нарушается именно она. Допустим, бюджет заказчика не позволяет купить дорогую систему, а очень хочется. Поставщик же всегда очень хочет продать как можно больше. В результате нередко возникает ситуация, когда стороны, вроде как, приходят к взаимному соглашению: лицензии продаются как положено, а консалтинг становится опциональным, его можно покупать, а можно и не покупать.

Если учесть, что его стоимость соизмерима и со стоимостью лицензий, и со стоимостью оборудования, то кажется, что это экономия трети средств. При этом продавец считает, что раз у него услуга не куплена, то никаких доработок он делать не должен, а заказчик считает, что раз он купил программу, то ему ее поставят и наладят как надо. Вот уже и заложен будущий конфликт. Это мина замедленного действия. Заказчик в тот момент о ней не думает, он радуется экономии. Завышенные ожидания – это тоже системная проблема рынка WMS. И их формирует общий вектор маркетинговой политики. Не успевает кто-то «изобрести» (в кавычках, потому что чаще всего это маркетинговый ход, а не разработка) новую функцию, как она тут же «появляется» в других системах. Если учесть, что в предыдущую пятилетку никто не горел желанием предоставлять рабочие описания системы всем желающим, то объективной информации по этому поводу никто не знает. На этом фоне и возникают завышенные ожидания у клиентов. Вполне естественно, что чем выше эти ожидания, тем больше потом разочарование. Иными словами, прежде чем делать выбор в пользу системы, нужно как следует изучить полный ее функционал и сравнить с функционалом других систем.

 

Бизнес-процессы

Отдельно нужно сказать о разработке отчетов. Иногда это становится камнем преткновения в проекте. Проблема распадается на несколько, а именно: возможность (реализуемость), необходимость и трудоемкость. Все они тесно связаны между собой. Большинство систем имеют как уже встроенные разработчиком отчеты, так и возможность создания новых, по требованию заказчика. «Любой» в понимании продавца – это извлечение существующей в системе информации в необходимом разрезе и представление ее в нужном дизайне. В понимании же заказчика часто «любой» – это любой вообще. Иногда аргументация просто убийственная: «а в бухгалтерской системе я это могу, значит и вы должны». Можете – так и делайте. Системы концептуально различны, и информация в них хранится по-разному. Это частая проблема для предприятий, где бухгалтерская или финансовая службы имеют больший вес, чем логистика. В них порой выводы о том, что система плоха, делают те, для кого она и не предназначалась. Например, по словам менеджера склада ООО «РСК-Северо-Запад» Михаила Марковичева, у самих складских логистов в их компании мало кто спрашивал, устраивает их внедренная на их складе WMS, или нет. Причем так было и при первом внедрении, после которого установленное решение пришлось сильно дорабатывать, так и потом, когда было принято решение перейти с этой системы на 1С. Ни в том, ни в другом случае сами логисты практически не принимали никаких решений. Естественно, спрашивать у них после этого, насколько эффективно работает внедренная система, не стоит. Следующий важный пункт – обучение. Когда и чему учить – вопрос отнюдь не риторический. В начале проекта никто не знает, как будут выглядеть процессы, и научить можно только стандартным вещам. Но время еще есть, поэтому можно подождать, пока процессы будут сформулированы, преподаватели внесут специфику в методику обучения, и сразу учить тому, как это будет работать. Вот тут и возникает проблема.

До проведения анализа никто из персонала заказчика системы не знает. Как же они построят процессы? Исполнитель знает систему, а заказчик нет. Вот они и спорят до хрипоты, как надо сделать. Некоторые внедренцы этим злоупотребляют, а мотивируют красиво: «Зачем учить, а потом переучивать». Еще один парадокс с обучением происходит уже в предзапусковом цейтноте. Потеряв время на анализе бизнес-процессов, исполнитель ведет процессы настройки и обучения параллельно. Чему же учат в этом случае преподаватели? Правильно – стандартному функционалу, потому что реальный еще не подготовлен. Потом, на запуске, переучивают на то, что уже готово. Возможно, это одной итерацией не обойдется. Так зачем же откладывать обучение, если все равно придется учить, как минимум, дважды? Разное понимание

 

Внедрение WMS – это не просто продажа системы. Это прежде всего ее адаптация под конкретного заказчика. Проблемы могут возникать не только по причине того, что заказчик, например, захотел сэкономить. Поставщик системы не всегда является владельцем кода. Разработчики систем не всегда идут на изменение кода для конкретного заказчика. Их можно понять: разные версии для разных клиентов – это затраты на поддержку этих разных версий, поэтому они предпочитают выносить всю разницу в настройки, если это возможно, а если нет – то отказывают. Многие западные вендоры не хотят даже рассматривать единичные проблемы на складах третьего мира, к которому они относят Россию. В этой ситуации многие компании-внедренцы берут на себя риски и делают «заплатки», которые позволяют частично изменить функционал. Еще на этапе переговоров с поставщиками нужно обсуждать все вопросы, касающиеся бизнес-процессов: насколько процессы, заложенные в систему, могут адаптироваться под конкретные условия…

 

Любые проекты, завершившиеся запуском системы, плавно переходят в режим сопровождения. Естественно, что интерес поставщика по вполне понятным причинам к этому проекту снижается: не может же компания бесконечно заниматься одним и тем же проектом. В некоторых случаях такой подход приводит к конфликтам. Это случается, если ошибки были на этапе подготовки и самого внедрения. В то же время заказчику в любом случае нужно понимать, что сопровождение не предполагает решения проблем двух видов: устранения пробелов в образовании пользователя и серьезной переработки настроек. Обычная для службы поддержки работа – это устранение ошибок разработки и внедрения, поддержка целостности, помощь в критических ситуациях. Это аналог «скорой помощи». Рынок WMS развивается и подвержен некоторым болезням роста. Это нужно понимать и относиться к вопросу внедрения системы управления складом очень серьезно. Прежде всего заказчику нужно быть готовым изучать, сравнивать, анализировать системы, прорабатывать требования. Он должен быть требователен к поставщикам, но требователен как профессионал, изучивший рынок WMS и знающий свои потребности. Сегодня российский рынок WMS предлагает эффективные решения, но чтобы использовать их без проблем, нужно знать об описанной «болезни роста».

Автор: Дмитрий Перов Источник: «Складские технологии»,http://wms-explorer.ru