Cистемы управления складом
Выбор, внедрение и эксплуатация

№ 1 февраль 2008

Проблема адаптации WMS

◄... к началу статьи

Типичные ошибки

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

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

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

Отдельно следует сказать о проектном менеджменте. Как правило, заказчик требует предоставления плана проекта. По степени детализации, которую он потребует, уже можно судить о судьбе проекта. Проектные планы с большим количеством деталей и жестким слежением по срокам обречены. Именно они наиболее рискованны, так как лишают внедренцев возможности маневра. Детали предстоящего внедрения обсуждаются регулярно и обрастают все большим и большим количеством подробностей. Это будет продолжаться до тех пор, пока не подожмут сроки запуска. Приближается дата, когда переносить запуск уже нельзя. В этой точке проект получает шанс выйти из кризиса, причем практически последний. Если находится (неважно с чьей стороны) человек, который берет на себя риски и ответственность, то проект срочно пересматривается с точки зрения здравого смысла, стороны идут на взаимные уступки, за короткие сроки делается рабочее решение и проект переходит в категорию успешных. С сопровождением такого проекта, как правило, проблем не возникает.

Если шанс не использован, то срочно переходят к обучению персонала по стандартной схеме, так как адаптированного решения еще не родилось. Обучают только узкий круг специалистов, считая, что остальных научат уже эти люди. Устанавливают недоделанное решение и запускают его. В процессе запуска продолжается позиционная игра. Заказчик не подписывает актов, выдвигая все новые и новые требования. Исполнитель эти требования «спускает на тормозах». Исполнитель заявляет, что персонал заказчика и стандартных-то процедур освоить не может, куда ему «навороты»? Проект начинает приостанавливаться и возобновляться попеременно по инициативе то той, то другой стороны. Ситуация продолжается до тех пор, пока на самом высшем уровне руководства не приходит понимание, что эта ситуация затратна для обеих сторон. Проект внедряется так, «как может»…

Почему бывают такие случаи и как их избежать?

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

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

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

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

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

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

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

В итоге «Дистрибутивный центр» поменял систему на другую – Logistic Vision. Но при новом внедрении он уже подходил к проблеме совсем по-другому. Было составлено детальное и предельно четкое техзадание. На всех этапах внедрения взаимодействие между заказчиком и поставщиком было самым тесным. «Мы формулировали, что нам нужно, как должна работать система, а специалисты поставщика предлагали варианты решений, и мы вместе выбирали наиболее технологичный вариант. В результате еще до внедрения нам была предоставлена полностью работающая система для тестирования. Само внедрение происходило совместно со специалистами поставщика без какой-либо остановки склада. Задача была осложнена тем, что мы работаем круглосуточно. В выходной день были импортированы остатки из старой системы в новую, и с утра следующего дня мы начали работу в новой системе. Первые дни у нас находилась команда внедрения. В течение 2–3 дней были решены оперативные проблемы, и мы перешли в обычный режим эксплуатации системы с поддержкой по электронной почте и телефону»,– говорит Брылкин. Таким образом, неудачный опыт все-таки сыграл и положительную роль, мотивируя заказчика очень серьезно подойти ко всем процессам, связанным с внедрением. Хотя, конечно, такой опыт слишком дорог, чтобы учиться на нем.

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

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

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

у самих складских логистов в их компании мало кто спрашивал, устраивает ли их внедренная на складе WMS или нет. Причем так было и при первом внедрении, после которого установленное решение пришлось сильно дорабатывать, так и потом, когда было решено перейти с этой системы на «1С». Ни в том, ни в другом случае сами логисты практически не принимали никаких решений. Естественно, спрашивать у них после этого, насколько эффективно работает внедренная система, не стоит.

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

Вот тут и возникает проблема. До проведения анализа никто из персонала заказчика системы не знает. Как же они построят процессы? Исполнитель знает систему, а заказчик нет. Вот они и спорят до хрипоты, как надо сделать. Некоторые внедренцы этим злоупотребляют, а мотивируют красиво: «Зачем учить, а потом переучивать?».

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

Разное понимание

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

Компания «Лента», внедрившая в прошлом году систему Manhattan, в ходе эксплуатации столкнулась с определенными нюансами. Как говорит Владимир Горичев, директор по логистике компании, вследствие внесенных в базовую логику системы изменений возникали проблемы с отправкой уже скомплектованного и подготовленного к отгрузке товара в торговые комплексы. Эти обстоятельства в период максимальной нагрузки на склад в предновогодний период сказались на выполнении планов отгрузки. Фактически при увеличении оборотов склада необходимо было менять организацию бизнес-процессов, которая была изначально предусмотрена проектом. Однако вследствие «коммуникационных» проблем, связанных в том числе со сменой ключевых участников проекта, это не было сделано вовремя. Часть функций, измененных под текущую организацию бизнес-процессов, привела к сбоям в работе WMS-системы при изменении условий. 90% выявленных ошибок системы связано именно с индивидуальными изменениями базового продукта. Естественно, исправить ситуацию на «живом организме»гораздо сложнее, хотя это возможно и такая работа проводится совместно с поставщиком решения. По словам Александра Рахманова, директора направления «Логистика» компании «КОРУС Консалтинг», эффективнее и правильнее использовать отработанные практики. Из 17 реализованных в России проектов по внедрению Manhattan, 15 обошлись вообще без модификаций. Прежде всего это объясняется тем, что как ни странно, российские бизнес-процессы строятся по примеру западных, и у нас, и за рубежом используются одни и те же складские технологии. В этом смысле сложно говорить об «особом пути» для России. Функционал WMS формировался, аккумулируя опыт тысяч внедрений, поэтому «КОРУС Консалтинг» как компания-интегратор с осторожностью относится к изменениям в базовой модели. Далеко не всегда изменение, на первый взгляд отличное и необходимое при первом рассмотрении, оказывается таковым в процессе реальной эксплуатации системы, и часто происходит возврат к базовой версии.

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

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

Обсудить на Форуме

На этом сайте нет форума. Автор является активным участником Клуба Логистов http://logist.ru, на форуме которого можно пообщаться со специалистами.