ERP vs WMS: мифы и причины не разрабатывать WMS на базе ERP (1C, Галактика, SAP)

ERP vs WMS: мифы и причины не разрабатывать WMS на базе ERP (1C, Галактика, SAP)

Привет, я Денис Сумелев — генеральный директор компании «Интекей», ИТ-интегратора и разработчика системы управления складом — INTEKEY WMS. Последние 15 лет занимаюсь консалтингом и автоматизацией складов — от небольших распределительных центров до крупных логистических комплексов. Хочу поговорить с вами об автоматизации склада с архитектурной точки зрения. Почему одни решения работают годами без сбоев, а другие превращаются в бесконечную доработку? Почему ERP часто не справляется с задачами WMS, даже если её «прокачали»? И как выбрать систему, которая не устареет через пару лет? Постараюсь развеять мифы о WMS функционале в ERP системах.

Уверен, у вас есть свои аргументы и опыт — мне тоже интересно их услышать. Постараюсь писать без отсылок к нашей системе, я мог бы долго хвалить её, ведь свои дети всегда кажутся самыми умными и красивыми. Но сделаю это только в начале и в конце. За годы мы не только разработали одно из лучших решений в соотношении цена/качество/сроки внедрения, с полноценной интеграцией с 1С, гибким API для любых учетных систем и современными технологиями и архитектурой, но и внедрили ее на огромном количестве складов различных размеров — от Unilever до небольших региональных складов. Но сегодня не про нас, а про принципиальные различия систем.

Введение

Давайте сразу расставим всё по полочкам. Когда мы говорим про выбор между доработанной ERP и профессиональным WMS — это не война «1С против SAP» или «наша Галактика против вашего 1С». Нет! Мы говорим о фундаментально разных подходах к автоматизации склада. И вот в чём суть:

Один путь — это когда вы берёте свою ERP-систему (неважно, на чём она работает: 1С, SAP, Галактика или кастомная платформа) и начинаете внутри неё «допиливать» складской модуль. Мол, «у нас же есть базовый функционал, мы его доработаем — и будет нам счастье».

Второй путь — это когда вы берете готовое профессиональное WMS-решение (наш INTEKEY WMS или EME, INSTOCK, TOPLOG или другие) и интегрируете его с вашей ERP. Две системы, каждая — профи в своём деле, работают вместе через чёткие интерфейсы.

Главное, что я хочу донести: те «плюшки», которые на первый взгляд кажутся преимуществами первого пути (доработка ERP), при ближайшем рассмотрении... ну, в 98% случаев они оказываются мифами, а то и скрытыми минными полями. Позвольте пройтись по ним подробно и без прикрас.

Разбор пяти главных мифов о доработке ERP

Миф №1: «Одна система — один флакон. Удобно же!» (Техническая несовместимость)

Что обещают: «Вам не надо прыгать между программами! Весь учёт — от бухгалтерии до позиции на стеллаже — в едином интерфейсе ERP. И данные синхронны! Никаких лишних интеграций».

Реальность под микроскопом: Давайте честно, ERP создана для учета документов и денег. Ее ядро — это накладные, счета-фактуры, финансовые результаты, бюджетирование. Она мыслит категориями дней, недель, кварталов. А склад? Склад — это физический мир! Это ячейка А-05-3 на третьем ярусе, это паллета №KLM-445, это задача водителю погрузчика: «Возьми 3 коробки с адресом хранения В-12-1 и отвези на упаковку, приоритет — срочный, заказ №12345». И это должно происходить в реальном времени, буквально за секунды! Представьте: ERP пытается контролировать, чтобы кладовщик не ошибся ячейкой при отборе — это как заставлять слона танцевать балет. Технически возможно? Может быть. Практично, эффективно, надежно? Никогда! Базовая архитектура ERP для этого не заточена. Это две разные вселенные: одна — мир бухгалтерских проводок и управленческой отчетности, другая — мир вилочных погрузчиков, сканеров штрихкодов и секундных транзакций.

Итог: «Единый контур» часто превращается в «единую точку отказа». Захотел бухгалтер сформировать сложный квартальный отчёт в час пик на складе? Пожалуйста — система «легла», терминалы сборщиков зависли, отгрузки встали. Удобно? Сомневаюсь».

Миф №2: «Мы – хозяева системы! Весь код наш, мы независимы» (Кадровые и технологические риски)

Мнимая выгода: «У нас открытый код! Мы можем что угодно поменять, когда угодно. Никаких зависимостей от вендоров, никаких плат за обновления или техподдержку. Полная свобода!»

Суровая правда жизни: Давайте разберём эту «независимость» по косточкам:

• Зависимость от конкретных людей: Кто писал этот кастомный код? Ваш программист Вася? А если Вася уволился, уехал в Таиланд или просто заболел надолго? Кто будет разбираться в его «творчестве»? Система превращается в «чёрный ящик». Любая доработка или исправление ошибки становятся русской рулеткой. «Мы владеем кодом»? Скорее, код владеет вами через ушедшего Васю.
• Апгрейд ERP = Ад: Вы используете 1С 7.7? Поздравляю! Пора переходить на 1С:ERP или «1С:Управление холдингом». Что происходит с вашим «самопальным» WMS-модулем? В 99% случаев – полное перевнедрение с нуля! Потому что архитектура новой версии ERP изменилась, старые доработки не работают или работают криво. Вы снова тратите месяцы и ресурсы. С профессиональным WMS ситуация иная: нормальные вендоры имеют готовые, отлаженные коннекторы (стыковочные модули) под все популярные ERP, включая новые версии. Переезд на новую ERP займет несколько недель, а не месяцев или лет.
• Отсутствие SLA и гарантий: Система упала ночью перед большой отгрузкой? С вашей «самопальной» разработкой вы остаетесь с проблемой один на один. Ваши IT-спецы будут разбираться в авральном режиме без какой-либо гарантии на скорость и результат. С вендором WMS у вас есть контракт с SLA (Service Level Agreement) – чёткими обязательствами по времени реакции и восстановления. Это не «может быть», это гарантия.
• Развитие = Боль: Мир логистики не стоит на месте. Появились дроны для инвентаризации? Хотите внедрить голосовой отбор (Voice Picking)? Интегрировать робота-паллетизатора? С вашей «самопальной» системой каждая такая инновация – это новый сложный и дорогой проект доработки. Профессиональные WMS часто уже имеют готовые модули или стандартные интерфейсы для интеграции с таким оборудованием.

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

Миф №3: «Своими силами сделаем быстрее! У нас же база готова» (Заблуждение о скорости)

Ожидания: «Зачем покупать WMS и тратить время на интеграцию? У нас же в ERP уже есть модуль «Складской учёт»! Возьмём его, немного «докрутим» под наши нужды — и через пару месяцев у нас будет своя, родная система управления складом. Быстро и сердито!»

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

Что хотим получить	Доработка ERP (оптимистично)	Профессиональное WMS	Реальная разница
Адресное хранение	12-18 месяцев	1 - 1.5 месяца	В 10-15 раз быстрее!
Ротация FIFO/FEFO	6-8 месяцев	2-3 недели	В 10-12 раз быстрее!
Wave-picking (волновой отбор)	8-12 месяцев	3-4 недели	В 8-10 раз быстрее!
Полный цикл (приемка -> отгрузка)	2.5 - 3+ года	4-6 месяцев	В 6-8 раз быстрее!




Почему так? Да потому что «докрутить» — это не просто добавить пару кнопок. Это:

• Понять, ЧТО именно «докручивать»: нужны сильные технологи-постановщики, которые знают склад изнутри. Они должны выявить ВСЕ нюансы ваших процессов. Без этого любая доработка будет кривой.
• Перевести «хотелки» технологов на язык IT: нужны бизнес-аналитики, которые сядут между технологами и программистами и скажут: «Ребята, под «оптимизацией маршрута» технолог имеет в виду вот этот алгоритм, а не просто кнопку «Оптимизировать».
• Написать код, который не сломает ERP: это ювелирная работа. Одно неверное движение — и вы получаете конфликт модулей, потерю данных или «тормоза» в самый неподходящий момент.
• Протестировать в боевых условиях: и это не «а давайте попробуем на тестовом складе». Это запуск на реальном потоке с риском остановки всего.

Конкретный пример из жизни: один наш клиент, крупный дистрибьютор электроники, решил «докрутить» складской модуль в своей 1С:ERP. Хотели «всего лишь» внедрить адресное хранение и базовый волновой отбор. Команда из 5 программистов и 2 аналитиков билась над этим 1 год и 3 месяца! И это при том, что изначально планировали уложиться в полгода. Профессиональное WMS внедрило бы этот функционал за 6 недель. Время — это деньги. Очень большие деньги, когда склад простаивает или работает неэффективно.

Миф №4: «Это дешевле! Наши программисты уже в штате» (Финансовая иллюзия)

Логика заблуждения: «Зачем платить вендору за WMS? У нас же есть свои IT-специалисты, которые и так получают зарплату и поддерживают нашу ERP. Дадим им задачу — они и сделают. Экономия налицо!»

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

Прямые затраты на команду (которых вы не избежите):

• Технологи-постановщики: Это не просто кладовщики. Это люди, глубоко понимающие логистические процессы, зоны хранения, принципы ротации, особенности работы с ТСД (терминалами сбора данных). Их время стоит денег. Им нужно выделять время на постановку задач вместо их основной работы. Или нанимать таких специалистов. (15–20% стоимости проекта)
• Бизнес-аналитики: Их задача — перевести язык технологов на язык программистов и наоборот. Без них — гарантированное недопонимание и кривые ТЗ. (20–25% стоимости проекта)
• Программисты: Основная рабочая сила. Но их время, которое они тратят на «допиливание» WMS, они не тратят на поддержку основной функциональности ERP, развитие других систем компании. Это упущенная выгода! (30–40% стоимости проекта)
• Консультанты по внедрению/обучению: Кто будет готовить склад к работе? Кто настроит Wi-Fi-покрытие для 10 000 кв. м.? Кто обучит 50 кладовщиков и 10 бригадиров? Кто будет «держать руку на пульсе» при запуске? (15–20% стоимости проекта)

Скрытые затраты на инфраструктуру (которые все равно будут):

• Аппаратная часть: Промышленные точки доступа Wi-Fi, способные держать сотни подключений ТСД одновременно. Серверные мощности для обработки потока транзакций в реальном времени (а ERP-сервер может не потянуть дополнительную нагрузку). Новые ТСД (терминалы сбора данных) с хорошим сканером, батареей. Сетевое оборудование.
• «Железо» для автоматизации: Если у вас большой склад (10–15 тыс. кв. м. и больше), то речь может идти о конвейерах, сортировочных линиях, возможно, даже роботах. Их тоже надо интегрировать в вашу «самописную» систему.
• Оклейка склада: Система адресного хранения требует физической маркировки каждой ячейки! Это тысячи, десятки тысяч этикеток.

Затраты на простой и ошибки:

• Тестовые периоды: Когда система «сырая», ошибки неизбежны. Это задержки приемки, отгрузки, ошибки в инвентаризации. Клиенты недовольны, деньги теряются.
• Обучение: Пока персонал учится работать с новой, неотлаженной системой, производительность падает.
• Доработки «на лету»: Обнаружились косяки после запуска? Снова отвлекаем команду, снова риски остановки.

Итоговая арифметика: Когда один наш клиент из сектора FMCG (товары повседневного спроса) решил посчитать реальные затраты на 2-летний проект доработки складского модуля в своей ERP (с учетом зарплат, инфраструктуры, простоев, упущенной выгоды), сумма оказалась в 2,3 раза выше, чем предложение по внедрению профессионального WMS с аналогичным

Миф №5: «Сделали один раз – и забыли. Система будет работать вечно!» (Долгосрочная нежизнеспособность)

Наивные ожидания:«Ну вот, вложили силы, доработали модуль под наши нужды, запустили. Теперь можно спокойно работать годами. Система же стабильна!»

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

• Изменение бизнес-процессов: Появился новый тип товара (например, заморозка)? Нужны новые правила хранения и отбора. Изменилась схема логистики (добавили кросс-докинг)? Нужны доработки. Масштабируетесь? Нагрузка растёт, система должна её выдерживать.
• Техническое устаревание и баги: «Лоскутная» система, созданная доработками поверх базовой ERP, особенно уязвима. Каждое обновление ядра ERP (а их нельзя избегать из-за поддержки и безопасности) – это риск, что ваши «костыли» перестанут работать. Баги в кастомном коде имеют свойство накапливаться, как снежный ком. Через 2-3 года система может превратиться в «дрыхлого монстра», который тормозит, глючит и требует постоянного внимания IT.
• Отсутствие «нормального» обновления: Профессиональные WMS-вендоры постоянно развивают свои продукты: исправляют баги, добавляют новый функционал, улучшают алгоритмы, адаптируются под новые технологии. Вы получаете эти обновления. Ваша «самопальная» система застыла в моменте своей последней доработки. Чтобы получить что-то новое – снова заказывайте проект у своих программистов.

Итог по мифам

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