Каталог решений - WMS на базе 1С:Предприятие 8 — покупка готового решения или самостоятельная разработка?

Введение.

Давайте попробуем разобраться и попытаться ответить на два вопроса:
1. Можно ли использовать 1С на складе?
2. Что выбрать — купить готовое решение или самостоятельно разработать собственный продукт?

Многие задаются вопросом «А если вообще выбор из WMS на базе 1С?»

На текущий момент можно найти следующие коммерческие решения систем управления складом, разработанные на платформе 1С:Предприятие 8:

— 1С:Логистика 3.0 и 4.0

— Penta WMS

— TopLog WMS

— ARENA.WMS

— CargoPrime: WMS

— Кронос: WMS

— Sevco WMS

— Warehouse Management Suite от IT-Scan

— АСТОР:WMS

 Первопроходцем можно считать решение 1С:Логистика, которое является самым массовым продуктом т.к. распространяется коробочное решение через сеть 1С. В версии 3.0 были исправлены многие ошибки предыдущей версии, оптимизированы методы хранения данных и проведена работа по борьбе с блокировками при работе нескольких пользователей одновременно. Но есть ограничения — т.к. продукт коробочный и массовый, то функционал адаптации к конкретному складу не сильно развит, поэтому на многих проектах требуется доработка программного кода. Версия 4.0 уже написана под платформу 8.2 на управляемых формах и содержит больше параметрических настроек.
На основе анализа первых версий этой системы, которые не отличались какой-либо мощной функциональностью, сложилось мнение, что WMS на базе 1С – это только для маленьких складов и небольших фирм. Многие консультанты известных WMS систем составили целый список ограничений, которыми пугают клиентов о проблемах систем на 1С

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

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

Выбор 1С в качестве платформы для разработки.

Но данная статья не о выборе того, или другого решения, а о возможности реализации полноценной системы управления складом на платформе 1С.

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

Так почему 1С заслужила такую плохую «славу» в области решения задач автоматизации склада?

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

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

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

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

В итоге получилось то, что платформа 1С превратилась в инструмент манипулирования простыми таблицами, где все действия контролирует разработчик, а не платформа.

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

И эту задачу можно решить совсем простым способом – построить структуру базы данных так, чтобы все расчеты выполнялись в запросах на сервере SQL, а сама платформа занималась лишь выводом результата пользователю.

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

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

Отсюда хочется сделать вывод и ответить на первый вопрос:
Создание полноценной WMS системы на базе 1С возможно! 

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

Теперь перед нами встает другая задача:

1. Купить готовое решение вместе с услугами по доработке и внедрению
2. Купить готовое решение, но все работы провести самостоятельно
3. Разработать собственное решение

Попробуем рассмотреть все варианты.

Покупка готового решения вместе с услугами по внедрению. 

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

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

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

Покупка готового решения с самостоятельным внедрением.

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

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

Разработка собственного решения.

Данный подход можно применить только если:

1. У вас простые складские процессы и небольшие требования к функционалу.
2. Или есть планы по коммерческому продвижение полученной разработки.
3. При этом имеется штат специалистов очень высокого класса, которые не только хорошо знают платформу 1С, но имею большой опыт в оптимизации запросов SQL и также разбираются в предметной области.

На практике есть как положительный опыт, так и отрицательный.
Я был на складах где собственное решение отвечало всем запросам склада, хотя и не являлось каким-то гибким решением.
Также есть и опыт наблюдения, когда в течении 3-х лет решение постоянно модифицировалось, компания несла большие затраты на собственную команду разработчиков, а процессы на складе были далеки от того, что можно было бы получить при внедрении даже самой простой коммерческой WMS на базе 1С.

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

Так как же разработать правильную WMS на 1С?! 

Если вы все-таки решились самостоятельно разработать собственную систему автоматизации склада, то вот несколько советов:

• Запаситесь терпением — рабочий продукт выйдет не раньше чем через год начала разработки (при соблюдении всех других требований)
• Не пытайтесь найти логистов, которые поставят задачу программистам — разработчик должен понимать что он автоматизирует, иметь опыт работы на складе и хорошо знать известные WMS, чтобы не изобретать велосипед
• Отнеситесь очень ответственно к планированию архитектуры решения — от этого зависит «взлетит или не взлетит»
• Не используйте типовой подход — проведение документа с записью в регистры накопления
• Используйте управляемые блокировки
• Перенесите всю логику работы в запросы, код выполняется максимально возможно на сервере и сведите к минимуму обработку данных в циклах.
• Пользуйтесь фоновыми заданиями, но не пытайтесь решить с помощью их те вопросы, которые не получается решить с первой попытки (типа каждые 5 минут проверять не нужно ли удалить что-нибудь)
• Пытайтесь вынести все настройки из кода — это впоследствии позволит быстрее проводить модификации, а также позволит рассматривать продукт в качестве коммерческого решения.
• Не пытайтесь сделать систему гибкой за счет существенного ухудшения быстродействия — планируйте архитектуру с умом, чтобы все возможные внешние настройки не превращались в большое количество запросов к базе данных.
• Обязательно анализируйте запросы на стороне SQL сервера для поиска ошибок в архитектуре системы на ранних этапах, когда еще можно избежать больших ошибок.
• Если вы изначально заложились на разработку коммерческой системы, то подход постепенной разработки по мере необходимости той или иной функции тут не подходит — оцените потребности различных складов и заложите их на этапе проектирования системы.
• Пишите сразу же универсальный движок работы с терминалами сбора данных т.к. впоследствии писать отдельную форму под каждый процесс совсем не практично.

 Вот и все.

С уважением, Рубанов Сергей, руководитель разработки системы управления складом ARENA.WMS