Уж сколько раз твердили миру…

Ежегодно по нескольку раз на различных мероприятиях, а также в прессе я рассказываю, как выбрать систему управления складом. Тем не менее, зайдя после длительного отсутствия на форум, первое, на что я наткнулся - «сравнение 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. За лицензии платите только после удачной сдачи системы в эксплуатацию. До этого времени с системой играется сам поставщик,  поэтому платить не за что. Для того и существует Брачный контракт. Он страхует ваш брак от  того, что потратившись уже на ее шубу, вам будет жаль расстаться из-за ее любимого кота, который гадит в ваши галоши. При этом шубу уже не вернуть в магазин.

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

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