Информационные системы №5 сентябрь 2008

Дмитрий ПЕРОВ
Эксперт журналов «Складские технологии» и «Логистика и управление»

Классовая борьба WMS

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

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

Первые классификации WMS

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

Первая классификация выглядела так:
системы начального уровня;
системы среднего уровня;
комплексные системы.

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

Системами среднего уровня тогда считали системы со стоимостью лицензий до $50 000, с базовой функциональностью (которая, впрочем, тогда, как и сейчас, не была определена формально). К этим системам относили младшие версии западных продуктов, распространяемые на нашем рынке, и CoreWMS российского Аргуссофта, который сам при этом стремился уклониться от конкуренции и занять нишу в системах начального уровня с системой СoreIMS, которая позиционируется в отличие от WMS, как система учета склада. Для систем среднего уровня продвигали заранее определенные возможности настройки, то есть настройки «галочные».

Комплексными системами в 2004 го--ду считали системы со стоимостью лицензий более $50 000, с возможностью значительных модификаций под требования заказчика. К этим системам относили безусловного на тот момент лидера российского рынка «Солво» со своей Solvo.WMS и старшие версии западных продуктов. При этом замалчивалось, что все эти старшие версии тоже «галочные», а по западным меркам данные системы расположены у нижней границы среднего класса.

Можно ли пользоваться такой классификацией сейчас?

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

Эта классификация преследовала две цели.

1. «Столкнуть» вниз все отечественные разработки как не заслуживающие внимания потребителя со средним бюджетом.

2. «Подтянуть» вверх к лидеру западные «галочные» системы, декларируя, что они тоже настраиваются под требования заказчика.

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

Единственное, что просуществовало из той классификации до сегодняшнего дня, это разбиение на ценовые категории. И сейчас к системам начального уровня относятся системы со стоимостью лицензий до $15 000–20 000. Средний сегмент уже несколько расширился, хотя скорее всего это следствие инфляционных процессов: несмотря на то что системы дешевеют, верхняя граница среднего сегмента сейчас находится где-то в районе $100 000 за лицензию.

Ревизия классификации 2006 года

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

С такими размытыми границами классификация просуществовала в течение двух лет и в конце 2006 года была пересмотрена. Конечно, никто не созывал никаких конференций для пересмотра классификации.

Кто же их пересмотрел?

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

Отражала она следующее:
системы начального уровня;
стандартные коробочные системы;
конфигурируемые системы;
адаптируемые системы.

Системы начального класса никто естественно трогать не стал.

Они реселлерам не интересны.

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

К стандартным коробочным системам стали относить системы до $70 000 (в публикациях не обозначены стоимости отдельно лицензий и услуг, по-этому делим их сумму приблизительно пополам). Коробочным системам «выделили» такую нишу: полноценные WMS, даже с определенным уровнем оптимизации процессов, но схемы процессов в них заданы жестко. Стандартные системы предлагалось приобретать для тех складов, на которых есть возможность подстраиваться под стандартные бизнес-процессы, заложенные разработчиками.

К конфигурируемым системам отнесли системы до $120 000. В них якобы можно тоже выбрать только один из возможных вариантов выполнения. Однако так как есть понятие правил и стратегий, то набор этот шире, хотя тоже ограничен концепцией системы.

Наконец, на вершине классификации расположены «адаптируемые» системы со стоимостью от $120 000. К ним отнесли системы, построенные на основе SOA (сервисно-ориентированная архитектура). К безусловным преимуществам систем этого класса отнесли возможность изменения логики бизнес-процессов без программирования и изменения исходного кода.
Изменить классификацию потребовалось для того, чтобы вывести на рынок такие системы, как Red Prairie (Аgcom), HighJump (R-id). Компания «Корус-консалтинг» использовала несколько другую тактику, а именно «Manhattan cчитается номером один в мире», и апеллировала к этому, а не к возможности настроек. То есть теперь надо было ограничить сверху всех, кто уже был на рынке, с тем, чтобы позицио-нироваться в премиум-сегменте.

Коррективы реальности

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

Верна ли спустя два года эта классификация? Да, если речь идет о западных системах, перепродающихся здесь.

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

Можно ли использовать данную классификацию как основание для выбора системы для своего склада? Нет, нельзя.

Уже невозможно не считаться с российскими разработками, которые из нее исключены, например, R-suite от Aзъ-группы – это тоже адаптивная система, но по цене она гораздо ниже заграничных собратьев. Система № 1 от компании «Адалиус» уже накопила столько «стандартных» бизнес-процессов, что сложно выдумать какой-либо эксклюзив. Компания «Логистикс» тоже, обладая неплохо спроектированными бизнес-процессами и архитектурой LEAD WMS, предоставляет по запросу описания процедур, исходный код которых изначально открыт. В этом же ряду «АйТиСкан», «Солво», «Бухта» и другие отечественные разработчики, каждый из которых своеобразен, но все они имеют одну общую черту – клиенто-ориентированность.

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

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

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

Совокупность компромиссов

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

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

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

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

Разделение на стандартные, конфигурируемые и адаптируемые системы – это компромисс разработчика.

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

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

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

Компромисс разработчика

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

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

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

Компромисс покупателя

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

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

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

Александр ПЕРЕПЕЧИН
Генеральный директор компании Red Tree

Потребность российских компаний – владельцев и арендаторов скла-дов – в мощных WMS увеличивается с каждым годом. Интенсивное развитие логистической инфраструктуры предприятий приводит к росту рынка информационных систем, предназначенных для автоматизации складских бизнес-процессов, на 25–35% в год.

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

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

Не так давно наш отдел маркетинга провел опрос директоров торговых и производственных компаний, руководителей отделов логистики и IT-служб. Главной темой данного опроса стали критерии, которыми руководствуются специалисты при выборе системы управления складом для своего предприятия. Большинство (около 80%) респондентов прежде всего обращают внимание на соответствие WMS логистическим бизнес-процессам, реализованным в компании, и легкость обучения персонала работе с системой. На функциональные возможности системы обращают внимание 55% заказчиков, на адаптируемость – 40%. Стоимость WMS имеет первостепенное значение только для 25% опрошенных.

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

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

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

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

Почти всегда заказчик требует, чтобы WMS была совместима с другими информационными системами предприятия (ERP, CRM, SCM и др.). Соответственно при интеграции необходимо отладить экспорт и импорт документов из одной системы в другую, добиться актуальности данных, предотвратить возможность двойного ввода данных и т. д. В противном случае организовать совместную работу WMS и других информационных систем будет невозможно.
Универсальных WMS, оптимально удовлетворяющих потребности любого заказчика, не существует. Сотрудникам каждого крупного склада или распределительного центра приходится решать специфические задачи, вызванные особенностями реализованных на предприятии логистических процессов. Поэтому в 99% случаев системы управления приходится адаптировать к условиям работы компании: дописывать код, производить настройку оборудования и т. д.

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

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

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

рейтинг:

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