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

№ 5 сентябрь 2008

Эта статья победила в абсолютном зачете и в номинации «Автоматизация складской логистики (WMS)» в конкурсе «Звезда рунета» журнала GoodLancer.com.

Классовая борьба 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. Обычно они умеют программировать, но программировать в данном случае как раз и не приходится. Однако можно посмотреть, какой код получается в результате использования инструмента. Они понимают, насколько он не оптимален, но ничего изменить не могут.

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

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

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

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

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

Обсудить на Форуме

На этом сайте нет форума. Автор является активным участником Клуба Логистов http://logist.ru, на форуме которого можно пообщаться со специалистами.