Привет, я Денис Сумелев, генеральный директор компании ООО «ИНТЕКЕЙ», ИТ интегратора и разработчика системы управления складом - INTEKEY WMS. Последние 15 лет занимаюсь консалтингом и автоматизацией складов — от небольших распределительных центров до крупных логистических комплексов.
Хочу поговорить с вами об автоматизации склада с архитектурной точки зрения. Почему одни решения работают годами без сбоев, а другие превращаются в бесконечную доработку? Почему ERP часто не справляется с задачами WMS, даже если её «прокачали»? И как выбрать систему, которая не устареет через пару лет? Постараюсь развеять Мифы о WMS функционале в ERP системах.
Я буду говорить со своей колокольни интегратора. Про причины разрабатывать WMS на основе ERP я расскажу в следующей статье, мы это тоже умеем и иногда делаем. Уверен, у вас есть свои аргументы и опыт — мне тоже интересно их услышать.
Постараюсь писать без отсылок к нашей системе, я мог бы долго хвалить её, ведь свои дети всегда кажутся самыми умными и красивыми. Но сделаю это только в начале и в конце. За годы мы не только разработали одно из лучших решений в соотношении цена/качество/сроки внедрения, с полноценной интеграцией с 1С, гибким API для любых учётных систем и современными технологиями и архитектурой, но и внедрили её на огромном количестве складов различных размеров — от Uniliver до небольших региональных складов. Но сегодня не про нас, а про принципиальные различия систем.
Введение. Два пути: WMS и функционал WMS в ERP
Давайте сразу расставим всё по полочкам. Когда мы говорим про выбор между доработанной 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: «Своими силами сделаем быстрее! У нас же база готова»
Ожидания: «Зачем покупать 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 недель. Время — это деньги. Очень большие деньги, когда склад простаивает или работает неэффективно.
Миф №3: «Это дешевле! Наши программисты уже в штате»
Логика заблуждения: «Зачем платить вендору за 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 с аналогичным функционалом! «Дешевле»? Скорее, «гораздо дороже и мучительнее».
Миф №4: "Мы – хозяева системы! Весь код наш, мы независимы"
Мнимая выгода: "У нас открытый код! Мы можем что угодно поменять, когда угодно. Никаких зависимостей от вендоров, никаких плат за обновления или техподдержку. Полная свобода!"
Суровая правда жизни: Давайте разберём эту «независимость» по косточкам:
Зависимость от конкретных людей: Кто писал этот кастомный код? Ваш программист Вася? А если Вася уволился, уехал в Таиланд или просто заболел надолго? Кто будет разбираться в его «творчестве»? Система превращается в «чёрный ящик». Любая доработка или исправление ошибки становятся русской рулеткой. «Мы владеем кодом»? Скорее, код владеет вами через ушедшего Васю.
Апгрейд ERP = Ад: Вы используете 1С 7.7? Поздравляю! Пора переходить на 1С:ERP или «1С:Управление холдингом». Что происходит с вашим «самопальным» WMS-модулем? В 99% случаев – полное перевнедрение с нуля! Потому что архитектура новой версии ERP изменилась, старые доработки не работают или работают криво. Вы снова тратите месяцы и ресурсы. С профессиональным WMS ситуация иная: нормальные вендоры имеют готовые, отлаженные коннекторы (стыковочные модули) под все популярные ERP, включая новые версии. Переезд на новую ERP займет несколько недель, а не месяцев или лет.
Отсутствие SLA и гарантий: Система упала ночью перед большой отгрузкой? С вашей «самопальной» разработкой вы остаетесь с проблемой один на один. Ваши IT-спецы будут разбираться в авральном режиме без какой-либо гарантии на скорость и результат. С вендором WMS у вас есть контракт с SLA (Service Level Agreement) – чёткими обязательствами по времени реакции и восстановления. Это не «может быть», это гарантия.
Развитие = Боль: Мир логистики не стоит на месте. Появились дроны для инвентаризации? Хотите внедрить голосовой отбор (Voice Picking)? Интегрировать робота-паллетизатора? С вашей «самопальной» системой каждая такая инновация – это новый сложный и дорогой проект доработки. Профессиональные WMS часто уже имеют готовые модули или стандартные интерфейсы для интеграции с таким оборудованием.
Вывод: «Независимость» от вендора часто оборачивается рабской зависимостью от внутренних ресурсов, устаревших технологий и невозможности легко развиваться.
Миф №5: "Сделали один раз – и забыли. Система будет работать вечно!"
Наивные ожидания: "Ну вот, вложили силы, доработали модуль под наши нужды, запустили. Теперь можно спокойно работать годами. Система же стабильна!"
Почему это иллюзия: "Любая информационная система, особенно такая сложная и критичная, как управление складом, – это не «раз и готово». Это живой организм. Почему «забыть» не получится:
Изменение бизнес-процессов: Появился новый тип товара (например, заморозка)? Нужны новые правила хранения и отбора. Изменилась схема логистики (добавили кросс-докинг)? Нужны доработки. Масштабируетесь? Нагрузка растёт, система должна её выдерживать.
Техническое устаревание и баги: «Лоскутная» система, созданная доработками поверх базовой ERP, особенно уязвима. Каждое обновление ядра ERP (а их нельзя избегать из-за поддержки и безопасности) – это риск, что ваши «костыли» перестанут работать. Баги в кастомном коде имеют свойство накапливаться, как снежный ком. Через 2-3 года система может превратиться в «дрыхлого монстра», который тормозит, глючит и требует постоянного внимания IT.
Отсутствие «нормального» обновления: Профессиональные WMS-вендоры постоянно развивают свои продукты: исправляют баги, добавляют новый функционал, улучшают алгоритмы, адаптируются под новые технологии. Вы получаете эти обновления. Ваша «самопальная» система застыла в моменте своей последней доработки. Чтобы получить что-то новое – снова заказывайте проект у своих программистов.
Итог по мифам: «Плюсы» доработки ERP под WMS оказываются мыльными пузырями. На практике этот путь чаще ведёт к перерасходу времени, денег, нервов и получению неэффективного, негибкого и ненадёжного решения.
Технические проблемы. почему ERP ≠ WMS
Мы прошлись по коммерческим и организационным мифам. Позвольте мне, как техническому специалисту, копнуть глубже и показать, почему попытка сделать из ERP WMS — это архитектурно порочная идея в большинстве случаев.
Проблема №1: разные миры данных и скорости
Сравнительная таблица:
Критерий |
ERP (Мир учета) |
WMS (Мир реального времени) |
Чем это грозит при "скрещивании" |
Основной объект учета |
Документ (Накладная, Счет) |
Физическая единица (Ячейка, Паллета, Коробка, Штука товара) |
ERP не "видит" ячейку В-12-3, ей важна накладная. WMS же управляет каждой единицей в конкретном месте. |
Гранулярность данных |
Уровень документа/позиции |
Уровень единицы товара/местоположения |
Попытка ERP отследить каждую коробку убивает производительность и создает чудовищные таблицы. |
Временная шкала |
Дни, недели, месяцы, кварталы |
Секунды, минуты, часы |
ERP не рассчитана на обработку сотен транзакций в секунду от десятков ТСД. |
Ключевые метрики |
Стоимость, Прибыль, Объемы в $/шт |
Точность, Скорость обработки (линии/час), Пробег техники (км), % ошибок |
ERP не оптимизирована для расчета оптимального маршрута сборщика или моментального бронирования ближайшей свободной ячейки. |
Пользователи" системы |
Бухгалтеры, Менеджеры, Директора |
Кладовщики, Водители погрузчиков, Упаковщики (через ТСД/голос) |
Интерфейс ERP для работы с ТСД на складе – это мучение для оператора. WMS заточена под мобильную работу в шумной среде. |
Аналогия: представьте, что вы пытаетесь управлять движением на оживленной городской развязке (это WMS) с помощью учета автомобилей в городском автопарке (это ERP). Данные вроде есть (машины те же), но инструменты и скорость реакции — небо и земля.
Проблема №2: Кто проектирует? «Кабинетные» vs «полевые»
Почему подход ERP-разработчиков губителен для склада:
ERP создают «кабинетные» специалисты: Финансисты, IT-архитекторы, системные аналитики. Часто — люди, которые: Никогда не стояли 8 часов с ТСД в руках на бетонном полу склада при -10 °C зимой или +35 °C летом. Не понимают, что такое «замылился глаз» после 500-го одинакового штрихкода за смену и почему кладовщик вместо 50 коробок может ошибочно отсканировать 52. Не знают феномен «зеркальной болезни» — когда ячейки 123 и 132 (расположенные зеркально) путаются в спешке. Не чувствуют, насколько критична экономия каждого шага для сборщика заказов. Лишние 50 метров на заказ — это километры усталости за смену. Их фокус: Правильность проводок, закрытие периода, отчётность для руководства.
WMS проектируют «полевые» технологи и инженеры: Люди, которые: Знают складскую «кухню» изнутри. Понимают физику движения товара и людей. Внедряют защиту от «дурака» и усталости: система не даст отсканировать товар не в той ячейке («Ты сейчас в А-15, а должен быть в Б-15! Подтверди действие!»). Проверит количество («Ты отсканировал 5 из 5?»). Подскажет кратчайший маршрут. Оптимизируют физические процессы: минимизация пробега техники, сокращение «холостого» хода сборщиков, оптимальное размещение товаров (часто спрашиваемые — ближе к зоне отгрузки). Их фокус: Скорость, точность, эргономика, безопасность операций на конкретном месте.
Пример непонимания: Главный бухгалтер слышит от кладовщика: «Я устал, замылился глаз, прочитал не ту ячейку». Реакция бухгалтера: «Да как так? Читать надо внимательнее! Это же элементарно!». Реакция WMS-технолога: «Значит, нужна дополнительная проверка системы при сканировании ячейки в этом ряду, возможно, звуковая или цветовая индикация на ТСД для снижения ошибок при усталости».
Итог: Доработка ERP под WMS силами «кабинетных» разработчиков без глубокого вовлечения «полевых» технологов обречена на создание теоретически правильной, но практически неудобной и неэффективной системы.
Проблема №3: Производительность и надёжность
Чем опасно «скрещивание»: серверная перегрузка – «тормоза» и «падения»:
WMS-нагрузка: Десятки, сотни ТСД отправляют запросы каждую секунду: «Забронируй ячейку!», «Зафиксируй отбор товара X из ячейки Y!», «Рассчитай маршрут для погрузчика №3!», «Обнови статус заказа!». Это огромный поток коротких транзакций.
ERP-нагрузка: В это же время бухгалтерия запускает сложный квартальный отчёт, который читает миллионы записей. Отдел продаж строит аналитику по клиентам. Закупки формируют объёмный план.
Итог: сервер ERP, не рассчитанный на такой микс нагрузок, захлёбывается. ТСД начинают «тормозить», операции выполняются с задержкой, кладовщики стоят и ждут. В худшем случае — сервер «падает», парализуя весь бизнес: и склад, и офис.
Риски безопасности и отказоустойчивости:
Единая точка отказа: Поломка сервера ERP или сбой в её ПО? Катастрофа! Останавливается ВСЁ: и приёмка, и отгрузка, и бухгалтерия, и продажи.
География: Часто сервер ERP стоит в красивом офисе в центре города, а склады — на окраине или в области. Проблемы с каналом связи между офисом и складом? Склад парализован.
WMS отдельно = страховка: Сервер WMS может (и должен!) стоять локально на складе или в надёжном ЦОД. Падение ERP? Склад продолжает работать в автономном режиме WMS: принимать, размещать, отбирать, отгружать. Данные синхронизируются, когда ERP восстановится. Падение WMS? ERP продолжает работать с базовыми данными о наличии (хотя операционная эффективность склада падает).Проблемы связи? Склад на WMS автономно работает со своими локальными данными.
Безопасность данных: Разделение систем снижает риски. Взлом или ошибка в ERP не обязательно затронет складские операции, и наоборот.
Потребляемые мощности: Раздельные серверы под ERP и WMS обычно требуют меньше совокупных мощностей и лицензий СУБД, чем один монстр-сервер, пытающийся тянуть все вместе. Потому что каждая система использует ресурсы, оптимальные для своей задачи.
Проблема №4: "Лоскутное одеяло" архитектуры
Что происходит при доработках: Представьте старую добрую 1С 7.7. Её ядро не заточено под WMS. Программисты начинают "прикручивать" WMS-функционал:
Данные о ячейках хранения лезут в таблицы, предназначенные для чего-то другого (например, для аналитики счетов).
Алгоритм волнового отбора ("Wave-picking") цепляется за механизм проведения документов.
Расчёт оптимального маршрута для сборщика втискивается туда, где есть хоть какая-то свободная логика.
Результат такого "творчества":
"Лоскутная" система: Модули плохо стыкуются, данные дублируются или теряются.
Хрупкость: Любое обновление ядра ERP, любая попытка добавить новую функцию – высокий риск "сломать" что-то старое.
Неподдерживаемый код: Через год-два разобраться в этой мешанине сможет только автор (если он ещё в компании).
Падение производительности: Постоянные "костыли" и неоптимальные запросы к базе данных приводят к тому, что система с ростом данных начинает дико тормозить. Особенно под нагрузкой.
Ограничение развития: Добавить что-то принципиально новое (голосовой отбор, интеграцию с роботом) становится невероятно сложно и дорого.
Вывод технаря: ERP и WMS – принципиально разные системы по своей архитектурной ДНК. Попытка "вшить" WMS в ERP без переписывания ядра последней – это путь к созданию неэффективного, ненадежного и дорогого в поддержке "Франкенштейна".
Когда доработка ERP всё же может быть оправдана?
Я не демон и не фанатик WMS. Есть ситуации, где путь доработки ERP под склад может иметь смысл. Но их очень мало! Это исключения, подтверждающие правило:
1. Очень крупные компании с огромным IT-бюджетом и штатом:
Кто: Глобальные холдинги, гиганты розницы (типа X5, Магнита), крупнейшие промышленные концерны.
Условия: Наличие собственной мощной IT-команды (10+ человек), включая выделенных логистических технологов, бизнес-аналитиков и программистов, которые только и занимаются развитием корпоративной ERP и её складских модулей. Часто есть свой R&D центр.
Почему им это может быть нужно: Экстремальная кастомизация: Их процессы настолько уникальны и масштабны, что даже топовые коробочные WMS требуют дорогой доработки. Им проще и иногда быстрее сделать самим под свою ERP. Контроль и скорость изменений: Они хотят мгновенно вносить изменения в систему без согласований с вендором. Готовы платить за эту «гибкость» огромными бюджетами на IT. Политика: Стратегическое решение о максимальной унификации на одной платформе.
Осторожно! Даже им нужно трезво оценивать реальные затраты (прямые и косвенные) и сравнивать с TCO (Total Cost of Ownership) профессионального WMS. Часто «своя разработка» всё равно дороже.
2. Компании с уникальными/экзотическими процессами, для которых нет готовых WMS-решений:
Примеры: Хранение опасных веществ, требующее сверхсложного контроля параметров (температура, влажность, давление) в реальном времени. Сборка уникальных промышленных изделий (космические компоненты, уникальное медоборудование) со сложнейшим трекингом каждой детали и операции. Склады с экстремальными условиями (глубокий минус, высокое давление), где стандартное «железо» (ТСД) не работает.
Условия: Готовых адекватных WMS-решений на рынке действительно нет, или они невероятно дорогие. Компания готова инвестировать в глубокую кастомизацию своей ERP как в долгосрочный стратегический актив.
3. Очень маленькие и простые склады с нулевыми планами роста:
Кто: Микробизнес, маленький производственный цех со складом сырья на 50 позиций, крошечный офлайн-магазин с задним складиком.
Условия: Обороты мизерные (десятки заказов в день).Ассортимент простой и стабильный. Процессы элементарные (приёмка → поставить на полку → взять с полки → отгрузить). Нет планов роста или автоматизации (никаких ТСД, голоса, роботов). В штате есть IT-специалист (или приходящий), который может «допилить» базовый функционал в недорогой ERP (типа 1С Бухгалтерия или УТ).
Почему: Затраты на внедрение WMS не окупятся из-за отсутствия масштаба и сложности. Базового функционала ERP хватит «с головой».
Важное уточнение: По нашим оценкам и опыту рынка, компании, попадающие в пункты 1 и 2 – это максимум 1–2% всех предприятий, которым нужна автоматизация склада. Пункт 3 – еще, может быть, 5–7%. Остальные 90–95% компаний – это средний и даже малый бизнес с растущими оборотами, стандартными (хоть и непростыми) процессами, планами по развитию и ограниченными IT-ресурсами. Для них выбор в пользу доработки ERP – это верный путь к неэффективности, переплатам и технологическому отставанию.»
Рекомендации: что выбирать?
Исходя из горького опыта многих компаний, вот наш четкий алгоритм для принятия решения:
Считайте не только лицензии! Считайте все затраты на доработку ERP: зарплаты своей команды (технологи, аналитики, программисты, внедренцы), стоимость инфраструктуры (сервера, Wi-Fi, ТСД, сетевое оборудование, оклейка), стоимость простоя и ошибок во время разработки и запуска, упущенную выгоду от неэффективной работы. Сравните с TCO (Total Cost of Ownership) профессионального WMS за 3-5 лет (лицензии/аренда, внедрение, поддержка, обновления). В 9 случаях из 10 WMS выгоднее.
Честно оцените свои IT-ресурсы:
У вас есть выделенная, опытная команда из 5+ человек (технолог + аналитик + 2-3 программиста + тестировщик), которая может полностью посвятить себя проекту на 1-2 года? Или ваши 1-2 сисадмина и так зашиваются с поддержкой текучки?
Есть ли у вас в штате именно логистический технолог, который глубоко понимает WMS-процессы и сможет грамотно поставить задачу? Или это будет «хотелка» начальника склада, пересказанная IT-директором?
Спросите себя о будущем:
Планируете рост оборота, площади, ассортимента?
Хотите внедрять автоматизацию (конвейеры, роботы)?
Нужна высокая точность (>99,9%) и скорость?
Если «да» хотя бы на один вопрос – профессиональное WMS ваш выбор.
Итоговый чек-лист
Дорабатывать ERP можно, если:
Ваш IT-бюджет превышает $500 000 в год.
У вас есть выделенная, сильная команда разработки (10+ человек) с логистическим технологом.
Ваш склад менее 3000–5000 кв. м. с очень простыми, статичными процессами.
У вас нулевые планы по росту и автоматизации в ближайшие 5 лет.
Вы готовы мириться с погрешностью инвентаризации 5–7% и периодическими простоями.
Если НЕТ на большинство пунктов — забудьте про доработку ERP, смотрите в сторону WMS.
С технической стороны, профессиональное WMS — must-have, если:
Ваш склад обрабатывает более 100 заказов в день или более 1000 строк отбора в день.
У вас более 5000 SKU (артикулов) на складе.
Точность инвентаризации критична (ошибки более 1% вызывают финансовые потери или проблемы с клиентами).
Вы используете или планируете использовать ТСД, мобильную печать, голосовой отбор, автоматизацию.
Ваш склад более 3000 кв. м. или имеет сложную конфигурацию (многоярусное стеллажирование, разные зоны).
Вы видите склад не как «неизбежное зло», а как стратегическое преимущество для конкурентной борьбы (скорость доставки, точность сборки).
Комментарии (22)
Yozh-lyudoyed
27.08.2025 17:12Напишите ещё статьи "Молоток vs Пассатижи" , "Чемодан vs Телефон", "Зелёнка vs Пенициллин" и т.д.
Lexiff
27.08.2025 17:121C тащем-то это как раз очень даже про склад - насколько я помню, их решение с регистрами со времен семёрки оченно даже котируется.
IvanSTV
27.08.2025 17:12вообще, подтверждаю, что при сшивании разномастных систем ERP и WMS, часто получается бардак с постоянным прокидыванием туда-сюда обмена и вечными доработками. Объем доработок небольшой только на первом этапе интеграции двух (и более) систем, а потом начинается - любые изменения в процессах требуют допиливать сразу две системы, постоянно выясняется, что тут не учли, там надо доработать, и так далее. Не видел ни одного случая, когда хватало коробочных решений как для ERP, так и для WMS, в результате представление, что за полтора месяца интеграция и доработка будет сделана на WMS-ной коробке - это просто рекламный обман клиента, не более.
Только в стране розовых пони бывают такие сроки, которые указаны в табличках. Такой безудержный оптимизм излучают только менеджеры по холодным продажам, и то если их начальство перед выходом к клиенту зарядило коньяком. Реальность суровей.
Своим опытом практика клянусь- не надо верить этим красивым таблицам, там все сроки занижены в 2-3 раза минимум, затраты преуменьшены кратно. Я участвовал в проектах, где интеграция шла более года. Да, перекинули технически за полтора месяца, а перед этим 4 месяца согласовывали и пилили доработки, потом после этих полутора месяцев, когда вылезли критические недоработки, еще 7 месяцев вжикали напильником. Казалось - сшили вместе коробку с готовым решением, и все, а в реальности решение не готово.
Относительно невозможности собрать требования для доработки ERP - это миф. Как раз работники, вовлеченные в процессы, гораздо лучше знают, что конкретно им требуется, и великолепно смогут описать это IT, потому что проблемы все выстраданные, а не надуманные внешним аналитиком, который берется интегрировать системы. Вот, например, у меня документ обследования лежит - там аналитическая часть WMS вообще отсутствует как класс. То есть, аналитик даже не поинтересовался, какими аналитическими инструментами пользуются люди, какими не пользуются, какие существуют, какие требуются. А на практике - выгружай голые списки из регистров, и своди в эксельке, если хочешь банально узнать, сколько в среднем хранится та или иная номенклатура по месяцам. Начальник склада годовую загруженность считает по точкам (в смысле, выгружает количество паллет на момент - например, на начало месяца), а на уточнение, что у него 30% паллет приходят и уходят одними сутками - он татарин, выразился лаконично: "кысмет"... В одной WMSной коробке вообще не было аналитики объемов движений товара - только выработка сотрудников. А там, где выработка не регистрируется - считай опять из регистров :)
В случае с доработкой также возможно пропустить часть операций и этапов, которые в коробку WMS заложены - например, у меня на предыдущей работы процесс размещения в коробке принятого выглядел так: кладовщик брал товар из ячейки приемки на себя, а потом прибивал к ячейкам перемещениями. Но в ситуации, когда он раскладывает 500-600 позиций за раз, "взять на себя" занимало до 1-2 часов непрерывного сканирования. "Взять на себя" хорошо работает, когда монопаллет несешь или 20-30 номенклатур. А когда их 500, и все умещаются в коробочку 50х50, то выполнить все, что в WMS ПРЕДПОЛАГАЕТСЯ ПО ДЕФОЛТУ, жрет время. В результате потребовали упростить процесс - я глянул, что можно поменять, а там в WMS все прибито гвоздями, документ перемещения на кладовщика никак не обойдешь - он пишет в регистр, а при перемещении оттуда списывает, в результате изгалялись, делали автоматическое формирование и выполнение перемещений на кладовщика по событию и размножили кратно ячейки приемки, чтобы 1 ячейка=1 коробка. Этот вариант был самый экономный, а неэкономный - это переписывать вообще весь процесс перемещений и размещений товаров.
И вообще, по практике, от 30 до 50% функционала WMS не используются, так как не подходят под бизнес-процессы. А процентов 20 функционала дописывается даже при достаточно простых внедрениях. Коробка готового продукта используется, когда нет ресурса дописывать или если не хотят слететь с поддержки. А когда ресурс есть, и поддерживают самостоятельно - то возможны варианты, и дописать имеет смысл, так как позволяет внедрять изменения постепенно, исправляя и подпиливая под требования процессов. Я видел весьма успешные и рабочие дописки WMS-модуля в ERP. Относительно рисков типа "бухгалтер повесит работу склада" - обмен между системами рисков несет как бы не больше. Я на одной работе чуть ли не по раз 10 в день "толкал" обмен, потому что в журнале обмена постоянно то ошибки, то подвисало, то просто пока обмен по расписанию отработает, объект на мастере удаляют (например, документ откатили для изменений), и пошли расхождения. Риск при доработке ERP есть только когда команда поддержки системы очень маленькая, а изменения отвратительно документированы - тогда разработчик становится уникальным специалистом, и держит компанию за горло. Но, с другой стороны, встречал таких уникальных специалистов, сидевших и тупо на самописных сервисах обмена, в которых, кроме них, не разбирался никто.
Итоговый чек-лист - это просто обман клиента. Программно обработка 500 SKU ничем не отличается от обработки 5000 SKU, и даже 600000 SKU - тупо справочник раздувается, а склад в 2000 метров по структуре ничем не отличается от 15000. Я видел склады с 6000 ячеек на 600 метрах и на 12000. И видел сложную вложенность ячеек для склада из нескольких ячеек напольного хранения и одного стеллажа для фурнитуры, вот там я поломал голову, как воткнуть такую топологию в WMS. И на погрешность инвентаризации вопрос, внешняя ли WMS или ERP не влияет НИКАК. Я делал на 99,6% сходящуюся инвентаризацию на складах под управлением ERP с 15000 SKU и было, что для склада с 300 SKU выходило 76% (потому что в коробке WMS процесс канбана упаковки на производства вообще работать не мог, так как не был заложен, и даже архитектура не давала написать, и все отгрузки шли по распечаткам из экселя). И работал с самописными модулями инвентаризации, гораздо более продвинутыми, чем в любой коробке (например, циклическая инвентаризация в коробке ни у одной 1С-ной WMS не присутствует, или например, принцип DIY-инвентаризации, когда результат не влияет на остатки без отдельной человеческой проводки - можно сделать просто просчет для технических нужд склада).
Либо тот, кто писал эту статью, на складах никогда не работал, либо сознательный обман.
intekey_ceo Автор
27.08.2025 17:12Очень интересное мнение, оно одновременно имеет под собой логическое обоснование со стороны ИТ и подтверждает мое мнение, что логистикой в первую очередь должны заниматься эксперты в логистике и бизнесе, а не ИТ-специалисты или экономисты. Действительно, для 500 и 5000 SKU разных требований с точки зрения хранения данных о них нет, но склад с 500 SKU и склад с 5000 SKU — это два разных склада. В первом, возможно, вообще автоматизация не окупится, если не планируется рост, во втором, скорее всего, окупится за счет повышения эффективности, снижения % ошибок и т. д. Склад в 2000 метров и в 15000 метров зачастую отличается размером бизнеса и количеством сотрудников. Что говорит, например, о наличии необходимых ресурсов на автоматизацию и точек роста эффективности. Да, будут исключения из правил, например, небольшие фармакологические склады с дорогостоящей продукцией и сложными процессами, где необходима WMS, но их можно свести в погрешность. Как и склады 15000+ метров с 2 SKU, например, цемента, лежащего в мешках на паллетах, и продажей прям паллетами — не нуждаются в WMS. Но это все исключения.
По поводу сроков и розовых пони. Это реальные и проверенные не на одном проекте сроки и стоимости. С момента согласования ТЗ и с учетом грамотного изначального аудита склада, это более чем реальные сроки внедрения, которые приведут к улучшению показателей. Конечно, после первоначального внедрения будет проводиться качественная продуманная доработка проектной командой под изменяющиеся потребности бизнеса. Процессы и технологии меняются, и автоматизация должна быть процессом постоянным. Но эффективное первоначальное внедрение укладывается в эти сроки. Вы клянетесь своим опытом, но сколько внедрений в год вы делаете? Судя по тексту, вы штатный специалист. А значит, это одно внедрение раз в несколько лет (если работу меняете). Мы делаем 15+ внедрений в год. Да, бывают долгие, но бывают и быстрые.Цифры средние.
zVlad909
27.08.2025 17:12... подтверждает мое мнение, что логистикой в первую очередь должны заниматься эксперты в логистике и бизнесе, а не ИТ-специалисты или экономисты.
Странное утверждение. Во-первых не понятно объединение ИТ-специалистов и экономистов.
А во-вторых, приведу пример из моей небогатой практики бизнес программирования.
Случилось мне работать в начале 90-х в одном большом металлургическом заводе с примерно 30 000 работников. Был я тогда зам. нач. отдела АСУП (кто не знает это Автоматизированные Системы Управления Предприятием) по разработке. Охват автоматизацией тогда был не велик и я был озабочен расширением этого охвата. Сначала взгляд упал на Отдел Кадров, потом на Отдел Научной Организации Труда, который по факту занимался штатным расписанием.
Взял я программистку из отдела и пошли мы к "экспертам". Встретили нас две сотрудницы заранее предупрежденные о нашем посещении. Радушно нас встретили, разложили образцы их документации, и рассказали как работает штатное расписание в их бумажном исполнении.
По ходу их рассказа я задавал вопросы и рассказывал как это могло бы быть воплощено на компьютере (не ПК, а настоящем компьютере, который у нас тогда был. Даже два, двухпроцессорных, 32 МБ, 20 ГБ дисков (second hand из Европы на самом деле. Конец 70-х начало 80-х в США), с Системой Виртуальных Машин - IBM VM/SP, настоящая реляционная БД IBM SQL/DS, QMF, REXX, ISPF и куча другого софта от IBM, включая OS/2. 1994 год!).
К концу рзговора одна из двух сотрудниц ОНОТ говорит другой: "Слушай, Маша, а ведь у нас бардак и нам надо сначала навести порядок и лишь потом "автоматизироваться". Я оттуда вскоре ушел, но та программистка еще много лет работала с ОНОТ и ОК и писала для них программы и они внедрялись.
Знал я и другого программиста, который писал программы для бухгалтерии "конфетной фабрики" (так он называл своих заказчиков). Он знал бухгалтерию лучше тамошних бухгалтеров и много им помогал в собственно бухгалтерии.
Так что не знаю про экономистов, но ИТ-специалисты, в виду их уникальных способностях в области обработки информации (а именно этим занимается ИТ), очень даже могут помочь и в логистике и в управлении бизнесом. Не все конечно, но уникальность в этом есть точно. И ей не надо принебрегать.
IvanSTV
27.08.2025 17:12просто вот мой послужной список:
2001-2003 - сотрудник склада (FEDEX)2003-2007 - менеджер склада (склад один, но 2 перешивания склада на разные ИС, 2 внедрения с разными клиентами)
2007-2016- менеджер по логистике (свои склады, разные организации, но ничего не внедрял, по счастью)
2018-2022- инженер по стоку и складским операциям (4 склада, внедрения)
2023-2024 - администратор WMS (две работы, 9 и 1 склад, внедрение)
2024-2025 - технолог СУС (1 склад, доработки после внедрения)
Вы кичитесь своим опытом в логистике вообще не подозревая, что опыта в логистике у меня побольше вашего. Относительно "количества внедрений" - с 2018 года я ежегодно что-то крупное внедрял, но между мной и вами есть небольшая разница - "внедренцы" со стороны поставщика ПО пару месяцев поскачут по складу туристом и убегают, А Я ОСТАЮСЬ, и гребу лопатой все то, что вы просто не видите, не знаете, или на что вам сугубо наплевать, так как вы деньги получили :)
Да, будут исключения из правил, например, небольшие фармакологические склады с дорогостоящей продукцией и сложными процессами, где необходима WMS, но их можно свести в погрешность.
вообще, с развитием маркетплейсов мелкие склады с большим количеством номенклатур - это скорее правило, потому что маркетплейсы на схеме FBO/FBS перекладывают на поставщиков большую часть складской обработки, и как раз основная масса заказчиков именно такие склады и внедряет. Производственники обычно работают с несколькими сотнями SKU, но, как правило, у них все внедрено до вас. Вы свели в погрешность почти полрынка внедрения WMS :) специалист, нечего сказать. Или просто у вас выборка такова, потому что ценник на ваш продукт конский, и большинство его просто не тянут.
С момента согласования ТЗ и с учетом грамотного изначального аудита склада, это более чем реальные сроки внедрения, которые приведут к улучшению показателей. Конечно, после первоначального внедрения будет проводиться качественная продуманная доработка проектной командой под изменяющиеся потребности бизнеса.
рекламное бла-бла-бла общими фразами. А на практике - аудит всегда поверхностен (потому что в такие сроки практически невозможно его сделать подробный - люди банально не вспомнят целый ряд операций и возможных ситуаций - например, вопрос об отрицательных остатках на обмене впервые всплыл через полгода, обнаруженный случайно - просто обращений к этим номенклатурам не было, а там весь обмен криво работал), постоянно всплывают вещи, пропущенные аудитом, за время внедрения выплывает необходимость доработок и переработок, даже хорошо отлаженные на тестах процессы на проде оказываются не тем, что предполагалось, даже без изменения бизнес-процессов, я примеров могу накидать массу. Время на отслеживание качества и поддержку прода дается минимальное - Акселот дал 2 недели работы сотрудника после переливания на прод, Ситек - месяц (и это для крупного предприятия с 14 складами и 8 заводами, я был удивлен, что они согласились - видимо, тоже в уши надули, что все будет быстро, но даже через год после того, как я уволился, они фактически проект не закончили), Бит поддерживал две недели, и плюс месяц по допсоглашению, и все равно на складе в 600 метров налажал - я через год с лишним разгребал все, что там не было донастроено и доработано, в последнем случае даже ABC-анализ из коробки не работал корректно, они его просто откатили "до лучших времен", так и осталось на два года. После того, как сотрудник "внедренца" со склада убегает, достучаться до техподдержки бывает достаточно нетривиальным делом, я отдельно у себя документировал все общение с ТП Акселота, потому что иначе я просто не мог доказать начальству, что я не игнорирую проблемы, а ежедневно трачу на ТП по часу в день и более.
Т.е. количество внедрений ваше ничего не говорит о КАЧЕСТВЕ. И не надо опять рекламной болтовни, что ваши клиенты довольны - все понимают, что отрицательные отзывы о вашем продукте и работе вы никогда и никому не покажете. 15+ внедрений в год - получается. что на специалиста приходится менее одного месяца разобраться во всем и все сделать. За это время нельзя даже въехать в суть бизнес-процессов. Я как-то с топологией разбирался месяца два (правда, по 8 складам, но все под единой системой) - но качественно нарисовать топологию занимало на склад не меньше недели, у меня каждый день начинался с проверки схем со складскими работниками, и каждый раз находились какие-то дополнения, изменения и прочее. А ведь я на этом предприятии со складами уже 8 месяцев проработал, аналитику делал, обследования. И все равно постоянно вылезало то, что не было учтено. Доходило до того, что как в фильме ДМБ " Пока противник рисует карты наступления, мы меняем ландшафты, причём вручную. " Реально - вчера я согласовал вылизанную схему, вечером залил, а ночью начальник смены добавил балок, с утра началась работа, и на проде физически груз не лез в ячейки.
15 внедрений в год - это типичное ТЯП-ЛЯП И В ПРОДАКШН.Но эффективное первоначальное внедрение укладывается в эти сроки.
вранье - в эти сроки укладывается только техническое внедрение перерисовать топологию, залить НСИ, сделать основные настройки, прокинуть обмен, настроить периферию и залить конфигурацию. Но это только верхушка айсберга. А в реальности все гораздо дольше и сложней, но это "дольше и сложней" продается плохо - вы рисуете заказчику потемкинскую деревню и убегаете к следующему.
Да, бывают долгие, но бывают и быстрые.Цифры средние.
средняя цифра в 1,5 месяцев означает, что если для одного из 15 затягивается на год (что по практике не редкость), то у остальных должно быть по месяцу, а если еще хоть у одного полгода, то остальные должны внедряться за три недели :) Ага, внедряете за миллисекунду, все верят.
PS.Почитал про WMS, которую вы рекламируете - в лайт версии вообще вырезана половина стандартного функционала, без которого будет работать разве что ремонт обуви дяди Васи на рынке в Урюпинске (например, маршруты подбора, FIFO,LIFO etc). У вас там вообще какой-то треш. Вы позиционируете продукт Lite как продукт для мелких складов и вырезаете из него погрузку навалом, которым на мелких складах в значительной степени и отгружают (например, на одном складе использовали виртуальные паллеты, чтобы отгрузить, а список физических мест и количества сводили в эксельке - ну не лезет паллет в ларгусы. которыми развозили по клиентам). Аналогично вырезано пополнение и работа с партиями С головой у вас в компании точно все дружат? Мелкий склад не значит, что не работает с партиями и характеристиками. Впрочем, судя по опыту моих собеседований в компании-интеграторы за последние три месяца, у меня сложилось впечатление, что к вам берут только сильно контуженных, а специалистов с опытом "на земле" вам не требуется, ваш бизнес - не решить проблемы клиента, а продать продукт, соответственно, проблемы эти для вас - лишь досадное препятствие к вожделенной оплате счета, и вы их просто обходите. Поэтому вряд ли вы мою т.з. вообще поймете.P.P.S. в списке проектов половина - "поставка терминалов", то есть, купи на али терминал и продай заказчику. Суперпроект года. Таких "проектов" любой продажник может по десятку в день запилить :)))
intekey_ceo Автор
27.08.2025 17:12Иван, вы пытаетесь судить всех по одной гребенке и отрицательному опыту внедрений и работы с несколькими интеграторами. Очень жаль, что у вас сложилось такое мнение об интеграторах в общем. От того же «Акселота» мы отличаемся как раз персонализацией подхода, гибкостью продукта, более адекватным ценником и скоростью внедрения. Странно судить о компании, её подходах и качестве работы без опыта сотрудничества с ней. Если будете внедрять на текущем или новом объекте — обратитесь к нам, посмотрите на подход, пообщайтесь с экспертами, сделаете объективные выводы и мы их с удовольствием обсудим и учтем. Пока же вы субъективно нам приписываете грехи других компаний и собственного неудачного опыта с ними. Не хочется в полемику уходить. Отвечу на основные тезисы:
Мы не бросаем клиента через неделю, а стараемся выстраивать долгосрочное сотрудничество.
У нас не один специалист, а несколько проектных команд, не понимаю, откуда вы взяли такую информацию в своих расчетах.
Это высококонкурентный рынок с высокими требованиями к поставщику услуг. Большая часть клиентов — это рекомендации и сарафанное радио. Поэтому основа подхода — именно решить проблему клиента, если мы её не решим, он нас не порекомендует.
Вы изначально неверно истолковали чек-листы и продолжаете к ним делать отсылки. Чек-лист, это перечень признаков по которым можно оценить склад поверхностно и с определенной точностью выявить необходимость в профессиональном отдельном решении. Чем больше попаданий, тем больше вероятность, что нужно отдельное профессиональное решение. Окончательное решение, естественно, в каждом отдельном случае должно приниматься на основе полноценного профессионального внешнего или внутреннего аудита.
В любом случае, спасибо за обратную связь. Нам важно мнение штатных сотрудников на местах и мы его всегда стараемся учитывать.
Zmey2007
27.08.2025 17:12Хорошее сравнение в комментариях....
У меня здесь есть УНИВЕРСАЛЬНЫЙ КОМБАЙН за 1 млн.рублей (ERP), которая может всё. Правда я НАВЕСНОГО ОБОРУДОВАНИЯ купил массу, ДВИЖОК расточил, ТУРБОНАДДУВ поставил - я комбайн тюнинговал 4 года и настраивал.
В штате этим занималось 4 айтишника (а как вы хотели, ведь это же ERP), потому что угодить надо было всем: закупки, финансы, бухгалтерия, продажи и где то там логистика.
Архитектор БД - неприкасаемый человек, только он владеет "как тут всё устроено". Миллион доработок за 4 года, изменение учётных сущностей, "задвигание" склада в зад и доработка по остаточному принципу.
В итоге имеем махину, с косилкой, бороной, фрезой, дополнительным баком, освещением и культиватором...НО - ей не разрешён выезд на дороги общего пользования. Комбайн отлично работает в поле, под управлением механика, комбайнёра и семи техников.
Но тут приходит молодой прогрессивный директор по продажам и говорит, нам бы в соседнем регионе поле (маркетплейсы) окучить. Посадить ячмень, а осенью сварить пиво. Но разворот этой махины требует доработки: разобрать, снять навесное, погрузить на трал, довезти, собрать, снять жильё для специалистов и пр.
Zmey2007
27.08.2025 17:12Я продолжу.
Пока разворачиваем эту операцию - поле уже засеяли на десяти местных тракторах (пусть Беларусь).
Вот ERP он по факту такой.
Мне как нач.складу, директору по логистике в прошлом виделось в нескольких компаниях именно так. И компании, кстати, не мелкие, а стабильно входящие в пятёрку крупнейших в отрасли. Мне что бы изменить порядки обхода, добавить ЧЗ, разработать интеграцию с маркетплейсами, протестировать идеи, внедрить роботизацию - ты просто идёшь через АД объяснений о "сущностях" в ERP и функциональных разрывах где то.
Адовая хреновина ERP на интеграцию с простыми системами требовала миллионы рублей и месяцы разработок. Можно конечно сказать - программисты и разработчики плохие. Да, но мне то что делать как заказчику?
Дальше следующая ступень - Исполнительный директор. Т.е. теперь я выбираю и IT Директора и систему (конечно же советуясь с IT директором). Но кому работать в WMS, исходя из моего 15-ти летнего опыта Директором по логистике? Точно не IT директору. И все отсылы к универсальной системе говорят мне только о рисках и будущей неповоротливости этой махины. Простота интеграций? Нет. Я видел как и легко интегрирующиеся c системами ERP, так и ... "Стоимость интеграции составит 200 миллионов рублей и полтора года! У нас сильно модернизированный ERP! И это не шутка!!!
А видеонаблюдение кто то пробовал интегрировать с WMS в ERP 1C??? Получилось?
Мне как человеку опытному в логистике, как человеку отвечающему сейчас в целом за бизнес - интересней иметь несколько систем, которые ОЧЕНЬ гибкие и готовы к вызовам современного бизнеса в мире. Так же важно иметь внешнюю команду на обслуживании системы или систем, т.к. с точки зрения бизнеса - я перераспределяю риски. Хакнули одно - работает второе, отключили свет - работаем на листах с фонарём, лёг ERP - работаем в WMS, легла WMS - берём заказы из ERP.
В логистике зачастую всё решается на коленке, а потом заворачивается в доработку и доработка должна быть быстрая и чёткая. Она не должна затрагивать иные сущности, финансовые контуры и прочую несусветицу в ERP.
Я не АйТишник, я логист, я с низов понимаю что такое "шапка, которая сканируется как носки, а на самом деле это куртка" и что такое "два ведра с краской без партий на складе, но с партиями у финансистов, т.к. закупались по разному курсу".
И да, кто бы что ни говорил, развертывание и запуск WMS ГОРАЗДО быстрее реализации WMS в ERP - это я тоже проходил. ERP поддерживают свои Айтишники и они ОЧЕНЬ далеки от склада, а Директор по Логистике не хочет на год становиться Айтишником. Те кто массово запускают WMS, всё таки, имеют хороший опыт на складах - даже могут поделиться знаниями и примерами.
SmileyK
27.08.2025 17:12Любя информационная система , любой комплекс систем , архитектур зависит от людей и способности выстраивать диалоги и видеть цель - такого 5% остальное в компаниях это борьба подразделений, перетягиваний одеяло и прыгания перед забором что бы шеф увидел какого-то молодца который показывает работу… если в копании есть понимание, кто чем занимается можно строить как монолитные системы ERP и с минимум персонала либо сегментированное системы обвязанные между собой . За то и за это нужно будет платить , остальное просто как считать - это уже философия, рассуждения, взгляды с разных мировоззрений.
Я очень пониманию автора статьи, когда в компании есть экспертиза в виде сотрудников и когда она пропадает - это боль для компании и боль когда приглашают интегратора что бы разобраться - а не каждая компания, генеральный директор, собственник готов менять свои бизнес процесс которые работают (худо, бедно)…
fafafafafsg2
27.08.2025 17:12Почти все в статье работает из коробки в SAP...
SmileyK
27.08.2025 17:12Главное осознать как работает программа, а не заставить работать программу как она должна работать по мнению человека …
zVlad909
Давным давно, в прошлом веке, автоматизация (по современному наверное правильнее говорить цифровизация) бизнесов велась по методу "островков автоматизации". Это когда отдел кадров имел полностью свою автоматизацию, бухгалтерия свою, склад свою, и т.д..
Такой подход был осужден и заклеймен на Западе уже в 80-е годы (тогда автоматизация/цифровизация бизнесов велась не на ПК, а на мэйнфрэймах). И тогда появился термин ERP и появилось множество продуктов под эту парадигму.
Идея их, да, была построение в единой программной архитектуре многомодульного продуктоа с охватом стольких функционалов на сколько хватало сил, средств и потребности заказчика.
Но уже с самого начала разные ERP стали позиционироваться с уклоном в какой-нибудь конкретный вид бизнеса. Например, SAP ориентировалась на баизнесы с так называемым "непрерывным" производством. Это химия, металлургия и т.п. ERP (нынешнее ее название Asset Suite, а изначально называлась Passport), с которой я как DBA проработал 20 лет, позиционировалась в ядерную энергетику.
Кроме такой ориентации также была различная ориентация в смысле системной и программной платформености. SAP изначально использовали IBM mainframe и их OS - MVS (SAP была основана пятью сотрудниками, работавшими в ИБМ). Вскоре их продукт был перепозиционирован на платформу Unix.
Кроме того SAP программируется на основе собстенного языка и собственной базе данных.
По другому пути пошли создатели Asset Suite. Язык был взят стандартный - Кобол, база данных DB2, сервер приложений - CICS.
Довольно длинное получилось введение. Перехожу к сути моего комментария.
ERP, это не про "документы и деньги" как Вы пишите. Это про все что может быть нужно бизнесам. Главное в ERP это стандартный подход к построению комплексной системы управления (вот правильный термин) бизнесов во всех его проявлениях.
Единство базы данных, программной среды и интефейса это сильнейший аргумент в пользу ERP. Доработки модулей из коробки абсолютно возможны практически с любой из известных ERP (немного напрягает SAP из-за уникальности их языка и БД, но и они уже давно позволяют по крайней мере использовать разные стандартные базы данных).
Качество доработок, конечно, может быть разным, от непригодного до идеального. Принципы ERP нисколько этому не противоречат, поскольку вне зависимости от функционала это всегда было, есть и будет информационная задача с общими для всех их подходами и результатами. Складское хозяйства исключением не является.
Да, конечно, за много лет работы именно со складским хозяйством в Вашей компании накопился огромный опыт и Вы его воплотили в Вашем продукте. Но тоже самое можно было бы сделать в рамках любой ERP системы.
Пусть у Вашего продукта есть API к нему. Ну и кто и как должен их использовать чтобы интегрировать Ваше Складское Хозяйство в имеющуюся у бизнеса ERP XYZ? Смогут ли они сделать это так же красиво как Вы сделали Ваш продукт? А Вы сможете им помочь в этом?
У меня есть пример той компании где я работаю. Их ERP системой в плане доработок стандартных модулей под потребности бизнеса занимается внешняя компания. И он это делает не только для нас, но и других похожих по бизнесу. У них конечно есть наработки, но они в рамках общей архитектуры ERP.
Так что основая идея статьи очень даже располагает для критики. Не надо ходить по кругу и водить пользователей за сабой.
Сказав это я чисто по человечески желаю Вам и Вашей компании успехов и багополучия.
NightBlade74
Для начала, хочу заметить, что это явно рекламная статья, а на Хабре их пишут не для того, чтобы читать под ними комментарии и уж, тем более, на них отвечать.
Думаю, что не стоит путать производственный склад и, к примеру, склад маркетплейса. Это две большие разницы. Ну и если ERP содержит в себе модуль MES, то его тоже зачастую выносят отдельно, подцепляя к WMS. Все по той же причине: куча мелких онлайновых операций/транзакций, которые ERP не нужны. Если все свалить в кучу, то зачастую получается гибрид онлайн и офлайн обработки, который ни к чему хорошему не приводит. А ERP от WMS нужны складские остатки, причем зачастую не онлайн, а срез на дату/период.
Вопросы по API не понял. Если уж там есть разработчики, которые теоретически могут WMS запилить, то уж интегрироваться с внешней системой они точно смогут. А вот разработку WMS с нуля я бы не рекомендовал делать, тут я с автором согласен.
Если что, я больше 15 лет проработал с разными WMS, в основном дистанционной торговли, но сталкивался и с производственными. И даже как-то написал свою, правда очень маленькую и примитивную времянку.
zVlad909
В ERP (если это ERP) может быть и на самом деле есть масса других модулей с "кучей мелких онлайновых операций/транзакций, которые ERP нужны".
Какие вообще могут быть ограничения на ERP если по определению это то что предназначено для полного покрытия нужд бизнеса по управлению им. И финансовые функции и управление персоналом и складским хозяйством и много чего еще.
В ERP, которое я как DBA и системщик поддерживал 20 лет как раз не использовался финансовый модуль (хотя он там есть), но были использованые разные другие модули с самыми разными характеристиками, включая складское хозяйство, наряды на работы, учет опасных материалов и еще с чем я за 20 лет даже и не сталкивался, и включая пакетные заданиями генерирующими отчеты.
В России видимо другие представления об ERP системах, ну и еще это то что в моем случае ERP выполнялась на ИБМ мэйнфрэйм. Сейчас это же ERP выполняется в облаке кучей серверов в то время как рашьше на небольшом, можно даже сказать весьма маленьком МФ. На серверах х86-64 это делать проблематично, но кучей серверов тоже можно.
Что касаемо API. А Вы уверены что интегрирование "с внешней системой" не своей WMS будет проще чем написать свою WMS в своей "внешней системе", в которой есть какой ни какой зародыш WMS? В нашем случае так и было сделано. Внешней компанией сделано, хреново сделано. Но было в итоге отрихтовано и проработало много лет. Модули из SAP тоже переносились в ERP Asset Suite.
Тут важно понимать теорию. А согласно теории чем больше включается в единый комплекс тем меньше издержек на интеграцию новых функционалов (модулей), тем меньше раноплановых специалистов и легче поддерживать компетенцию разработчиков или эксплуатантов.
А если сшивать ИТ бизнеса из кучи раномастных функционалов сделаных совершенно по разному с разными заморочками разных вендоров (а их может быть в нынешней ситуации в ИТ бесконечное множество, и оно постоянно растет) то это еще тот челендж и бардак. Тоже имел опыт таких подходов. Несмотря на то что, как могло показаться из вышесказаного, у нас вроде как есть ERP, но все таки есть куча разномастные, внешних к этой ERP, модулей с интерфейсами к ней. И это настоящее горе. Но мы как те ёжики. Не я лично конечно. Я это со стороны наблюдаю.
Ivan22
опять споры по микросервисы vs монолит
NightBlade74
Вы же сами пишете "выполняется в облаке кучей серверов". Т.е. действительно разносится система на разные сервера не зря, верно? Допускаю, что существуют процессы, которые в ERP будут именно с мелкими отдельными транзакциями, но вряд ли это будет ERP, которой WMS нужна, если это не ERP муравейника.
Если система (в данном случае WMS) изначально заточена под интеграцию, то проблем именно с интеграцией не вижу. В принципе, все серьезные системы под интеграцию заточены. Кстати, если уже есть хороший API со стороны одной системы, то разработчикам отвечающим за другую в разы меньше головной боли, чем если бы пришлось с нуля интеграцию разрабатывать, хоть бы они и обе системы контролировали. Те люди, которые написали WMS уже хорошо знают, что надо и как надо, говорю из собственного опыта. Работал в одной довольно крупной фулфилмент-компании, когда приходил, порядковый номер клиента (ID-шка в БД) ,была порядка 400, когда уходил - была более 800. Не всем, конечно, была нужна интеграция по API и, наверное, каждый 10-й только хотел что-то такое, что у нас не было (больше по процессам, чем по API), но опыт позволяет мне говорить, что не будет проблем с интеграцией.
zVlad909
В нашем случае, однако, несмотря на то что в облаках только кучей серверов можно выполнять сколько нибудь нагруженные системы (а очень нагруженные системы кучасми куч), БД ERP системы стоит на одном сервере.
Это изначально была централизованная БД на мэйнфрэйме и изменять это вендор не стал или не смог. Куча серверов в нашем случае это сервера приложений выполняющих бизнес логику (до перехода в облако это все размещалось на том же и единственном МФ вместе с БД) ERP системы и дополнительные примочки к этой ERP навроде обсуждаемой здесь WMS, которая до перехода в облако тоже выполнялась на МФ c ERP модулем подкудрявленным для специфики нашей компании.
Любая компания если это не ларек имеет некий набор функционалов общих для всех. Отдел кадров, бухгалтерия, снабжение/сбыт, тот же склад, охрана, и конечно же управление собственно процессом бизнеса, каким бы он ни был. Причем коль скоро это единый организм, то есть связь между всеми службами. Т.е. по сути ИТ должна быть централизованной, а не распределенной чтобы точнее отражать сущность цифровизируемого объекта.
Проблема коротких и длинных транзакций это проблема выбранной платформы. Да на х86 (даже с -64) решение этой проблемы (как впрочем и любой другой проблемы) состоит в разнесении ИТ на много серверов. По сути это давно уже стало навязчивой идей архитектеров ИТ. Они не умеют мыслить в терминах централизованых решений. И это идет не из реальности, а из мэйнстримовского понимая ИТ что оно должно быть обязательно распределенным. Это прет из всех щелей. Особенно это драматично происходит в России, где возможности использовать иные чем х86-64 платформы просто нет. И не потому что санкции, это родовая травма российского ИТ, которое перерождалось в 90-е годы в условиях экономического колапса. Другие страны этого не проходили и в тамошных ИТ есть больше гибкости и вариативности.
API это не про интеграцию. Это про затыкание дыр. Интеграция это когда вся система ERP (или любая другая ИТ-шная система, например пенсионная система, система ГАИ, здравоохранения и т.д и т.п.) строится на унифицированных подходах и средствах. По факту так сложилось что в ИТ во-первых, есть множество аналогов одной и той же функционфльности, и как результат во-вторых, множество прикладных поделок (возможно идеальных каждая по отдельности как обсуждаемая здесь), но, скажем так, проблематично объединяемых (интегрируемых) во что-то целое.
Вы можете представить "ERP" систему созданную с нуля "интеграцией" модулей от разных вендоров, использовавших разные подходы к программированию, системам, БД и т.д.? Пристегнуть эту WMS к 1С, используя API может быть и можно, но это еще не все. Наверняка что-то еще может понадобится кроме склада и что не ахти как реализованно в 1С. Да и этом WMS, несмотря на большой опыт ее разработчиков в складском учете, для какого-нибудь пользователя найдется изъян. А в большенстве случаев пользователям будет не нужно многое что есть в этом WMS.
Это жизнь.
intekey_ceo Автор
Вы правы, статья по определению рекламная, поскольку выложена в корпоративном блоге компании. Но это не делает информацию из неё бесполезной или меня безучастным. Я читаю комментарии и отвечаю на них, пока на все комментарии времени не хватило даже вычитать. Мое основное утверждение в статье — имеют место оба подхода, но в 90% случаев из тех, кому реально нужен функционал WMS, лучше внедрить отдельным решением. Соглашусь по поводу MES, там, где это необходимо, тоже часто выносят в отдельное решение.
intekey_ceo Автор
Спасибо за пожелания. Вы правы, весь функционал можно реализовать в рамках ERP. И мы этим, как интеграторы, тоже занимаемся, и это тоже наш хлеб. Но всегда ли это оправдано с технической, финансовой и бизнес точек зрения? Статья как раз об этом, что прежде чем выбрать путь, нужно очень хорошо оценить риски, ресурсы, сложность, внутренние компетенции, в идеале — провести профессиональный аудит внешний и т. д.
С API и интеграциями, естественно, мы помогаем, как и любой серьезный интегратор. Для 1С, например, у нас вообще есть полноценная официальная интеграция готовая.
Говоря про «ERP — это про деньги и документы», мы не говорим об общей концепции, больше о реалиях российского бизнеса. С вашим опытом вы должны согласиться, в 90% случаев в России это про документы, деньги и ресурсы. Это практически весь малый, средний и часть крупного бизнеса.
zVlad909
Мой опыт в СССР/Россия это 80-е и начало 90-х. Он закончился в конце 90-х. На тот момент, кстати, я поддерживал 1С в торговом доме челябинского трубопрокатного завода. Устанавливал, изменял под запросы бухгалтерии. Тогда 1С был еще про деньги.
Мой опыт последих 25 лет это канадское энергитическое предприятие с 10 000+ работников и миллирдными оборотами, которое с середины 90-х уходит с МФ (до этого у них все было на МФ, а теперь почти все в облаке), и буквально вчера я передал последнюю БД в облако.
ИТ этого предприятия имеет две ERР класса системы и кучу разномасный модулей худо-бедно интегророванных между собой и с ERP. Плюс много бла-бла-бла про контейнерные приложения и AI. Только что отказался от трэйнинга в Микрософт навязываемого нашим ьенеджером. Пугает что те кто откажется "отстанут". Мне в мои 70 и не надо никого обгонять уже. Я и так в некотором смысле впереди многих.
Тем не менее я продолжу утверждать что ERP, последнее врямя также говорят про Assets Management, это изначально интегрированная система, включающая в себя по возможности все потребности в управлении бизнесом и которая состоит из модулей созданных на унифицированных подходах и средствах. А интегрировать то что сделано на разных подходах и средствах это иммитация интеграции. API не палочка выручалочка, а отмазка.