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

№ 3 май 2007

Критерии выбора WMS: не все так просто

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

Часто поставщики используют другой способ показать модернизацию: пишут «версия 6.0», «версия 7.0» и т. д. Однако редкая фирма может позволить себе глобально переработать концепцию продукта «с нуля». Чаще всего речь идет о «косметическом ремонте». Да и многие системы имеют врожденные дефекты, которые были заложены еще на этапе системного анализа. Автоматизируя свой склад, вычислить это заранее невозможно. Таким образом, возраст решения с его качеством связан слабо.

Количество внедрений

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

Размер компании – поставщика решения

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

Распространено мнение, что крупные компании обладают бóльшим опытом. Как правило, это так. Но обладает им компания, а не вы. Вы же будете работать с несколькими конкретными людьми, и не обязательно лучшими. Стоит ли за ними опыт всей компании?

Положительные отзывы клиентов

Задумайтесь, каковы могут быть мотивы положительных отзывов. Я даже не имею в виду прямую материальную заинтересованность. Возможно, директор по логистике или IT-директор просто занимается личным пиаром. Да и вообще, задумайтесь над тем, будет ли человек, по инициативе или под ответственность которого были потрачены колоссальные деньги, расценивать свой проект как неудачный? Даже если система не принесла ожидаемых результатов, скажет ли он об этом?

Имиджевые клиенты

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

Best Practices

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

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

Наличие у покупателя персонала, уже работавшего с аналогичными cистемами или конкретно с этой

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

«Самописные» или «промышленные» системы

Считается, что профессиональная специализация дает преимущество в качестве. Но это подмена понятий. Специализация на разработке определенных продуктов дает преимущества (разработчику) в эффективности процесса разработки, а вовсе не в качестве самого продукта. Уничижительное «самописка» обычно относится к конкурентам, как будто на самом деле существует некий способ написания программ, недоступный другим. «Штамповка» снижает себестоимость, но не всем она подходит, а качество больше зависит от персоналий, чем от тиража.

Западное или отечественное ПО

Здесь каждый отстаивает свое мнение. Позиций соответственно две: 1) все западное лучше нашего; 2) Запад не может отражать нашей специфики. Ни одна из них не верна. С одной стороны, уровень наших специалистов сплошь и рядом оказывается выше, чем у иностранцев. Наши специалисты дешевле, и если российский разработчик инвестирует в разработку соизмеримые с западными средства, то он будет иметь преимущество. Однако говорить о какой-то сугубо российской специфике еще менее верно. Специфично только то, что связано с фискальными интересами нашего государства (бухгалтерия, акцизы, таможня). В области технологий обработки товарных потоков никакой «российской специфики» нет и быть не может.

Присутствие и место в мировых рейтингах

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

Целевые группы и отрасли

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

Стоимость решения

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

Поставщик согласен работать на условиях FixPrice

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

Срок возврата инвестиций и экономический эффект от внедрения

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

Например, один поставщик заявляет, что товар не потеряется в 99,9% случаев, а другой – что в 99,99% случаев. Допустим, цена потери – 1000 рублей, и в день осуществляется 100 отгрузок. Тогда мы насчитаем в одной системе 36 500 потерь в год, а другой 3 650. Разница – 32 850 руб. Откуда она взялась? Из-за разницы выражения абсолютной точности двумя разными аналитиками (разработчиками), которые на самом деле имели в виду одно и то же. Если же сделать совершенно одинаковые предположения для разных систем, то можно с удивлением обнаружить, что чем система дешевле, тем больше эффект.

Последовательное математическое и логическое развитие системы

Почему развитие должно быть последовательным или параллельным, а не скачкообразным или возвратно-поступательным? Клиента в первую очередь интересует, до какой точки дошли в процессе развития, а не траектория. Может быть, конечно, это просто неудачная формулировка. Я бы сформулировал это как непротиворечивость концепции, архитектуры или реализации, но здесь другая проблема – как это проверить? Этого может не знать даже автор системы.

Коробочный или адаптируемый софт

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

Большой изначальный набор настраиваемых функций

Многие считают, что чем больше набор, тем больше выбор. На деле более затратным может оказаться изучение большого набора по сравнению с созданием необходимого «с нуля». Никто не тестирует «галочные» системы во всех возможных комбинациях, ведь если у вас 1000 настроек, то количество вариантов равно двойке в тысячной степени – не хватит жизни перебрать все варианты. Это значит, что на тестирование (если говорить о качестве) «попадаешь» в любом случае. Адаптивные системы в этом отношении исповедуют другую концепцию: не система должна иметь большой набор, а ее объекты должны позволять строить любой (в идеале) необходимый набор.

Функциональные различия

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

Полнота функционала

Как критерий выбора конкретной системы полнота функционала не подходит потому, что вас интересует полнота только необходимого конкретно вам функционала, а не всего возможного. Большинство компаний используют лишь 10–20% от общего функционала. Более сложные системы потенциально менее устойчивы и содержат больше ошибок, поэтому лучше лишнего не брать. Допустим, вы выберете из общего списка необходимое вам количество функций, но разве функции имеют одинаковый для вас вес? А не может ли возникнуть ситуация, что аналитик решения, в котором какой-либо функции, по вашему мнению, не достает, исповедует другую концепцию и знает, как решить проблему другими путями, которые вы просто не смогли увидеть?

Система отчетов и аналитики

Считается, что развитая система отчетов снижает стоимость владения системой. Под развитой системой отчетов понимается некоторый набор предустановленных отчетов и подключение к стандартным конструкторам дополнительных отчетов, например Crystal Reports. Сами по себе стандартные средства обычно более удобны, чем самостоятельно разработанные производителями систем. Но не следует забывать, что отчеты делаются по базе данных, а у сложных систем редко бывают простые базы данных. Далее по цепочке – у сложных баз данных редко бывают хорошие описания. Поэтому, как правило, построение сложных отчетов все равно остается прерогативой разработчика (соответственно, это скажется на затратах заказчика).

Модульность

Существует идея о том, что модульные системы позволяют экономить средства пользователя, которому не нужен весь функционал, заложенный в систему. Во всех ли случаях это верно? Можно разделить моносистему ценой $100 тыс. на несколько модулей, например на три по цене $40 тыс. каждый, и распределить функционал между частями таким образом, что в большинстве случаев придется покупать все три. Можно сделать следующий маркетинговый ход: сказать, что вы внедряете модули последовательно и, соответственно, платите частями. Далеко не всегда подключение модуля N не требует пересмотра настроек N-1 уже подключенных модулей. Я не утверждаю, что модульность – это плохо или хорошо. Просто это не критерий для выбора.

Масштабируемость решения: поддерживаемыe складские площади, единицы номенклатуры, количество рабочих мест

Создается иллюзия, что разработчики оптимизируют что-либо для разных площадей либо один продукт написан лучше по быстродействию и т.п. На самом деле продавец заявляет ту площадь, на которую ему позволяют претендовать конкуренты.

Практически никто из производителей не проводит нагрузочного тестирования. Быстродействие закладывается на этапе концептуальной проработки, дальнейшее развитие продукта может только ухудшать быстродействие. Пропускная способность системы определяется самым слабым звеном. Им редко бывает СУБД (обычно они нагружены всего на 10-20%). Чаще это сервер приложения или telnet/web сервер. Негативный опыт никогда не афишируется, ибо он появляется позже этапа внедрения, когда внедряющая фирма закончила проект, заказчик вышел на проектную мощность и накопил объемную базу.

Количество серверного оборудования

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

База данных /платформа

Обычно противопоставляется более мощная Oracle и более дешевая (в том числе и по стоимости владения) MicrosoftSQL. Вопрос этот абсолютно творческий. На обеих можно построить как хорошие, так и плохие решения.

Мультиплатформенность

Обычно возможность работы на разных платформах преподносится как преимущество. Давайте посмотрим более пристально. Разные базы данных поддерживают разные языки запросов, которые пересекаются в области стандарта SQL-92. Вчитайтесь! Девяносто два. То есть все, что появилось за последние 15 лет, нельзя использовать в угоду совместимости. Либо в системе поддерживается две версии запросов, которые должен кто-то создать и сопровождать (в этом случае налицо растрата ресурсов). Вместо этого можно было бы совершенствовать решение на одной платформе.

Автономное использование системы

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

Наличие интерфейсов с ERP

Считается, что наличие стандартного интерфейса с другими системами снижает стоимость проекта. Это не всегда так. Стандартный интерфейс может плохо работать в конкретных условиях, иметь недостаточное количество полей или событий, не отвечать требованиям безопасности и т.п. Чтобы учесть всю специфику конкретного склада и конкретного учета на предприятии, межпрограммный интерфейс придется серьезно дорабатывать. Написать его заново иногда бывает проще (и дешевле).

Отработанная методика внедрения, соответствующая стандартам ISO9000

Использовать ли этот пункт как критерий оценки? Во-первых, наличие формализованной методики не равно наличию отработанной методики. Во-вторых, отработанная методика – это опыт внедрения. В-третьих, как вы проверите, что методика отработанная? В-четвертых, отработанная методика – это просто меньшие риски (хотя и не всегда). А экспериментальная методика, которая ни разу не применялась, может дать лучший результат.

Плановые сроки внедрения

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

Рекомендации

То, что нельзя использовать ни один из приведенных в списке критериев как основание для выбора, совсем не означает, что не надо их рассматривать. Рассматривайте обязательно. Чем больше информации по системам будет у пользователя, осуществляющего выбор, тем лучше. Смотрите сами системы, сравнивайте их между собой, лучше попарно. Формулируйте собственные требования и технические задания. Самое главное – не поручайте сделать выбор за вас. ■