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

Выбор WMS - это сегодня в России вопрос творческий. На рынке уже представлено довольно много предложений, но они во многом похожи, а для детального анализа (то есть предпроектного обследования) нужно потратить много времени и сил, а часто и денег. В то же время все говорят, что клиенту при выборе нужно ориентироваться на конкретные критерии, которые дадут ему полную картину и помогут сделать правильный выбор. Не претендуя на истину в последней инстанции, я просто представлю свое мнение относительно главных таких критериев

Сразу отмечу, что я не предлагаю отказаться от использования распространенных критериев оценки WMS-продуктов. Это было бы неверно. Разумеется, их нужно рассматривать. Но я хочу подчеркнуть, что определяющим при выборе должно стать вовсе не максимальное соответствие «набору» расхожих критериев, а максимальное соответствие вашим собственным потребностям. Проблема заключается в том, что клиенты часто сами не готовы анализировать свои потребности. Чтобы оправдать свой выбор и снять с себя ответственность, они находят тот продукт, который отвечает тем или иным критериям, и совершенно не задумываются над тем, насколько тот или иной пункт реально важен для них.

Возраст решения

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

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

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

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

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

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

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

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

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

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

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

Best Practices

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

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

Предполагается, что каждый, кто уже соприкоснулся с 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 000 на несколько модулей, например на три по цене $40 000, и распределить функционал между частями таким образом, что в большинстве случаев придется покупать все три. Можно сделать следующий маркетинговый ход: сказать, что вы внедряете модули последовательно и, соответственно, платите частями. Далеко не всегда подключение модуля N не требует пересмотра настроек N-1 уже подключенных модулей. Я не утверждаю, что модульность - это плохо или хорошо. Просто это не критерий для выбора.

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

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

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

Вас будут убеждать, что оптимально только два сервера - приложения и базы данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://www.lobanov-logist.ru/library/all_articles/55566/

дата: 00.00.0000 00:00:00 просмотров: 6692

рейтинг:

(Голосов: 3, Рейтинг: 5)