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

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

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

1. Сначала надо написать собственное ТЗ, безотносительно системы управления. В ТЗ должна быть полная, подробная и обоснованная технология работы вашего склада. Никакие вопросы и проблемы не должны быть оставлены на «после выбора».

2. Надо провести первичный отсев кандидатов по нефункциональным признакам. Ну, не нравятся вам рыжие, высокие, помешанные на тряпках, дочери офицеров, с татуировками и без дачи в пределах 50 км от центра… Цель – сократить выбор до разумного предела в 5+-2 объекта. Систем у нас около 60, поэтому смело генерируете критерии отсева и безжалостно вычеркиваете по ним тех, кто не подходит.

3.  Оставшимся поставщикам систем посылаете свое ТЗ, чтобы они его прокомментировали. Пусть пишут, что могут, что не могут, сколько времени займет каждая доработка, сколько будет стоить. Все – честно. Вы говорите: «Я не буду мыть посуду», в ответ получаете требование нанять домработницу, или купить посудомоечную машину, или «мама будет жить у нас».

4. Вместе с комментариями по ТЗ вы получаете Коммерческие Предложения со всеми требуемыми доработками.

5. Если кто-то присылает КП, но саботирует проработку вашего ТЗ – этот вариант называется «только после свадьбы». Вам нужны сюрпризы? Сразу – вон из тендера!

6. Оставшихся ранжируете любым доступным вам способом, например, можете использовать Метод Анализа Иерархий (МАИ), можете изобрести собственную методику. Главное понять, кто быстрее/лучше/дешевле согласен решать ваши проблемы.

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

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

9. Делаете следующую итерацию ранжирования и повторяете пп. 6…8. В конце концов, у вас получится набор предложений с разной стоимостью и не абстрактной, а требуемой вами функциональностью.

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

11. Проговариваете с поставщиком договорные нюансы, предлагает в договор включить обязательным приложением ваше ТЗ (с учетом того, что вы могли его изменить в процессе итераций).

12. Если поставщик отказывается – вон из тендера!

13. С согласившимися оговариваете, что ваше ТЗ имеет превалирующее значение над их проектными документами (пусть пишут в них что угодно, они обязались реализовать ваше ТЗ).

14. В договор обязательно включаете кабинетное тестирование (приемку системы) перед запуском. Описываете требования к тестированию, его правила, сроки, что  считать успешным результатом, сроки исправлений, повторных тестов.

15. На запуск идете, только когда система успешно прошла тесты, не раньше (условие в договоре).

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

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

В таких условиях, все равно, какую систему запускать. Все будет работать. Я делаю это по нескольку раз в год уже долгое время.

#WMS #выбор_системы #автоматизация_склада #Логист_ру_2015 #Антикризисное_управление_цепями_поставок

Комментарии (1)

Все написано почти верно. Кроме одного. Если Вы присылаете ТЗ на 200 листов, то на его изучение требуется время. Интегратору нужно держать одного или нескольких человек, которые должны оценивать, не всегда адекватные «хотелки» клиента, как правило, навязанные консалтерами, которые не запускают WMS, а просто пишут муть (поверьте, у меня уже не один десяток запущенных WMS систем и приходится сталкиваться с таким бредом в ТЗ, например, у каждого кладовщика должен быть переносной принтер этикеток баснословной цены…). Никакой гарантии, что ты серьёзно будешь учувствовать в тендере у интегратора нет. Зачастую, справедливых тендеров не бывает, кто-то всегда получает откат, а типа 5-7 участников тендера, как Вы пишете, чисто для проформы. Так зачем, тратить время специалистов на оценку абстрактного проекта, который ты выиграешь в 0,1% случаев?

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

Важно начать со следующего WMS:

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

2. Определить платформу, на которой вы хотите получить систему (потому как, если система открыта, например, 1С, то Вы в ней можете делать сами доработки, не прибегая к услугам интегратора). Типов работы ТСД — RDP или установка клиента на терминал сбора данных (это все тоже стоит денег).

3. Когда определена платформа, оцените стоимость специалистов на рынке, которые будут поддерживать будущую систему. Если их стоимость неприемлема — возвращаемся к пункту 2.

4. Дополняем требования, определенные в пункте 1, и только потом объявляем тендер и рассылаем «хотелки».

P.S. Как показала практика, из «хотелок», которые клиент присылает в 200 страничном талмуде (после чего их оплачивает), после запуска системы он пользуется только 50-60% от заявленного функционала. А если, там участвовали консалтеры, то и вообще 30-40% и еще и платит за переписывание алгоритмов, которые у них не сработали по вине консультантов. Поэтому, проще, дешевле и безопаснее запускаться на основных требованиях. А после некоторого времени эксплуатации (2-3 месяца) уже делать дополнительное внедрение необязательных «хотелок» (поверьте, их список у вас кардинально измениться, процентов на 70%) WMS. Поверьте — это значительно дешевле. В любом случае, интегратор будет проводить обследование вашего предприятия и описывать подробно работу системы во всех ситуациях. Никто по составленному вами ТЗ настраивать систему не будет. Поэтому, если вы прибегаете к услугам консалтеров — Вам это выгодно только с точки зрения капитализации бизнеса, потому как у интеграторов зачастую свой штат опытных внедренцев (они могут быть и консультантами) WMS которые действительно знают, что будет работать, а что нет, опираясь на опыты внедрения, а не на книжные материалы. Они на моменте обследования и посоветуют, как должна отработать система в тех или иных ситуациях, ссылаясь на работающие склады.


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