Когда точечные интеграции перестают работать: как выбрать ESB и собрать команду
Интеграции редко проектируют сразу как отдельный слой. Обычно сначала появляется несколько обменов между системами, потом еще несколько — и постепенно всё превращается в сложный контур, который трудно развивать и поддерживать.
29 сентября вместе с EvApps проведем вебинар о двух связанных задачах:
когда компании уже нужна ESB, а когда точечных интеграций достаточно;
как собрать команду, которая сможет внедрить и дальше сопровождать интеграционный слой.
Разберем:
место ESB в корпоративной архитектуре и связь с MDM и КХД;
российский рынок интеграционных платформ;
подрядчика, аутстафф, внутреннюю и смешанную команду;
типовые точки, где проект начинает буксовать по ресурсам;
что делать с поддержкой после запуска.
Спикеры — Сергей Скирдин, технический директор «Белого Кода», и Альфред Столяров, директор EvApps.
Участники получат обзор российских шин, опросный лист для выбора ESB и чек-лист проверки подрядчика.
17 бесплатных вебинаров для аналитиков: ИИ, требования, бизнес-процессы и микросервисы
Привет, Хабр. Хороший анализ начинается не с документа и не с диаграммы. Сначала нужно понять, какую задачу решает бизнес, затем — разобраться с требованиями, договориться со стейкхолдерами, описать процессы и превратить всё это в понятное техническое решение.
Чем сложнее становятся продукты и системы, тем важнее для аналитика видеть картину целиком: от бизнес-целей и клиентского опыта до требований, бизнес-логики, данных и архитектуры. А ещё — уметь работать с изменениями и использовать ИИ там, где он действительно помогает ускорить рутинную работу.
В этом посте собрали 17 открытых вебинаров для тех, кто хочет развивать навыки системного и бизнес-анализа.
Когда обращений становится больше, кажется логичным расширить команду. Но вместе с новыми людьми растет и другая нагрузка: нужно помогать и передавать контекст новичкам, отвечать на одни и те же вопросы. При этом один сотрудник может заново искать решение, которое другой уже нашел.
С этим столкнулась команда клиентского сервиса ITSM 365. Кира, бизнес-аналитик клиентского сервиса и куратор командной базы знаний, рассказала, как команда постепенно выстроила систему работы со знаниями.
1️⃣ База знаний сама по себе проблему не решает
Можно написать сотни инструкций, но если их сложно найти, они дублируются или быстро устаревают, коллеги продолжат спрашивать друг друга. Поэтому работу с базой мы строим вокруг четырех принципов:
Актуальность — обновляем материалы и следим, чтобы они не дублировались.
Доступность — встраиваем статьи в рабочий процесс.
Признание — публично отмечаем всех, кто участвовал в подготовке материалов.
Ответственность — поддерживаем базу всей командой.
Как куратор, я проверяю, нет ли уже статьи на нужную тему, и помогаю авторам. Если коллеги замечают неточности, сообщают мне — я вношу правки сама или передаю материал автору.
При этом новые статьи пишем не ради количества, а когда видим повторяющийся вопрос или решение, которое пригодится другим.
2️⃣ Нужные инструкции должны быть под рукой
Важно, чтобы сотруднику не приходилось отдельно вспоминать, где искать нужную информацию. Поэтому стараемся сделать знания частью самого рабочего процесса.
Например, при выборе категории заявки портал сразу предлагает коллегам подходящие материалы. Клиентам он тоже подсказывает статьи: например, перед регистрацией обращения с высоким приоритетом предлагает инструкции, которые могут помочь восстановить работу приложения самостоятельно.
3️⃣ Иногда достаточно простого решения
Не все задачи требуют ИИ или большой автоматизации. Чтобы не подключать инженеров к вопросам, с которыми можем справиться сами, мы используем шаблоны комментариев. С их помощью проверяем базовые сценарии, собираем информацию и понимаем, нужна ли дополнительная экспертиза.
Еще один инструмент вообще выглядит максимально просто — обычное текстовое поле с комментариями по клиенту. Туда записываем договоренности: кому обещали рассказать о новой функции, к кому нужно вернуться после релиза, кого предупредить об изменениях. Это решение появилось как временное еще семь лет назад, но ничего удобнее мы пока не нашли.
4️⃣ ИИ там, где он действительно экономит время
Для работы с длинными обсуждениями мы используем ИИ-ассистента. Прямо в заявке можем получить краткое содержание переписки, собрать контекст для другой команды или выделить основные требования.
Раньше на такую работу могло уйти около получаса, сейчас — в среднем 3–5 минут.
Еще с помощью ИИ ищем похожие обращения по смыслу, а не только по ключевым словам. Это выручает, когда не знаем, как такую проблему описывали раньше.
5️⃣ Что изменилось в работе
Раньше на вопрос «Как добавить новую колонку в список заявок?» специалист в среднем тратил около 25 минут, а стажер — почти час. Сейчас открываем готовую статью и обычно закрываем такой вопрос примерно за минуту.
При этом часть типовых обращений вообще перестала доходить до нас: клиенты находят ответы самостоятельно. Новичков стараемся раньше подключать к реальным задачам и учим искать нужные статьи по ходу работы. В итоге тратим меньше времени на повторяющиеся вопросы, а знания становятся менее зависимыми от конкретных людей.
Культура обмена знаниями начинает работать тогда, когда найти нужную информацию самостоятельно проще, чем ждать ответа коллеги.
→ Подробнее своим опытом Кира поделилась в статье.
Luma: объединяем Data Governance, Business Intelligence и Искусственный интеллект
Вместе с Arenadata на вебинаре представили совместное решение Luma и рассказали, как интеграция каталога данных, BI-платформы и искусственного интеллекта помогает выстроить единое пространство для управления корпоративными данными и аналитики.
На мой взгляд ключевой вызов системе образования сегодня в том что мы умеем выпускать джунов, а они уже в работе растут дальше до мидлов и синьоров. А в мире победившего ИИ джуны не нужны работодателям. Да и мидлы не факт. А вот сеньоры нужны, хоть и в меньших количествах.
Если мы внимательно посмотри на анализы рынка труда, в которых фиксируется недостаток работы для джунов, например тут — «Forbes: „джуны“ сейчас не нужны или почему выпускникам IT‑курсов стало сложнее найти работу» https://habr.com/ru/news/681468/, то видим, что проблема не в ИИ, который заменил джунов, а в целом в сокращении потребности отрасли в специалистах и большом количестве переученных выпускников курсов. На самом деле джуны также нужны и сейчас и в будущем пригодятся по тем же самым причинам, что и раньше:
Им можно меньше платить.
Они больше мотивированы и готовы расти.
Они меньше спорят и больше делают.
Но конечно меня спросят, а что насчет того, что всю работу джунов может заменить ИИ? На этот счет у меня есть история из моей лабораторной практики. Когда я поступил в аспирантуру, общей практикой было то, что все новички: студенты и аспиранты, сначала в лаборатории моют посуду. Многие студенты на практике и аспиранты в первые пару месяцев только этим и занимались. Такой же подход был показан в сериале Теория Большого взрыва. Когда Шелдон приходит к Эми в лабораторию и предлагает помощь, она отправляет его мыть посуду.
Но в скором времени, наша лаборатория стала переходить на одноразовую пластиковую посуду, и потребность в мытье посуды просто отпала. По аналогии с ИИ, лаборатория должна была отказаться от студенческих практик и молодых аспирантов. Ведь теперь посуду мыть не надо, значит эти люди не будут приносить пользу. Но это не так. Просто студентам на практике стали давать больше заданий в рамках реальной экспериментальной работы.
Эта история мне всегда напоминает о том, что в реальном производственном или исследовательском процессе всегда остается много того, что пока может сделать только человек. И если у вас есть потребность в разработке, аналитике и так далее, то с помощью ИИ джун может сделать много того, что раньше мог делать только опытный разработчик.
Изначально предприятия берут MES, чтобы автоматизировать что-то, а потом сталкиваются с тем, что автоматизации минимум, и не так всё это просто запустить. В основном сейчас внедряют цифровизацию, которая собирает данные контроля и выводит красивые мнемосхемы. Никакой автоматизации в принятии решений, а зачастую нет даже подсказок, в какую сторону надо принимать решение. Все красивые технологии, о которых говорят, пока больше в презентациях. Есть и другие проблемы.
Ключевые проблемы внедрения MES:
Устаревшее оборудование, линии связи, отсутствие автоматизированных средств контроля;
Отсутствие производственных регламентов, нет проработки процессов;
Неватка компетентного персонала;
Сложности в интеграции существующих системы;
Несогласованность нормативно-справочной информации (НСИ)
Разрывы в данных, которые нужны и которые могут быть собраны;
Ограничения бюджета, невнятные KPI при высоких затратах.
Но тут ещё другая проблема выстреливает, вот позавчера наткнулся Ирония автоматизации (ссылка).
В 1970х годах когнитивный психолог Лизанна Бейнбридж проводила дни, наблюдая за операторами больших индустриальных печей. Она просила их проговаривать вслух, что именно они делают и почему, и разбирала, как устроено их знание о производственном процессе, управляемом автоматикой.
Из этой серии интервью в 1983 родилась статья "Ironies of Automation".
Ирония автоматизации состоит в том, что человеку достаются задачи, которые не удалось автоматизировать, то есть по определению самые трудные и плохо формализуемые. Плюс к ним – надзор за автоматикой, которую внедрили как раз потому, что она работает лучше человека. И эта система концептуально сломана:
Человек физиологически неспособен удерживать внимание на источнике, где почти ничего не происходит.
Умения оператора деградируют без практики. Если ты годами только наблюдаешь за системой, то в момент аварии, когда нужно перехватить управление и проявить мастерство, его уже не осталось.
Знания в долгосрочной памяти остаются доступными, только когда к ним регулярно обращаются. Оператор, не пользующийся этими знаниями, теряет способность быстро их извлечь. Кроме этого, протухает ментальная модель того, как работает система, и в каком состоянии прямо сейчас она находится.
Все эти проблемы стали ярко видны в произошедшей примерно в то время аварии на АЭС в Пенсильвании (ссылка). Скакнуло давление, один из клапанов не закрылся, и пошло-поехало. При этом все части автоматики сработали как надо, но итоговый сценарий был не знаком операторам, а из-за показаний приборов их ментальная модель разошлась с реальностью. В итоге они совершили кучу ошибок, произошел выброс радиации, а блок теперь законсервирован навсегда.
В общем история о том, что теряется субъектность персонала, люди перестают думать и доверяют машине, а когда машина подводит, не могут сами принять решение и выполнить правильные действия.
Сравните с тем, как много сейчас говорят об ИИ. Мол ИИ заберет простые задачи, но мы будет за ним проверять и думать о сложном. Не будем мы проверять, и возможно не будем думать. Это конечно плохо.
Аналитик между бизнесом и разработкой: что нужно знать сегодня
Задача поставлена, но никто не может точно объяснить, что именно нужно сделать. Бизнес ждёт результат, разработчики задают десятки уточняющих вопросов, а изменения продолжают появляться по ходу проекта.
Работа аналитика — превратить этот хаос в понятную систему: выявить потребности, зафиксировать требования, найти слабые места и помочь команде прийти к правильному решению.
Подобрали бесплатные уроки, которые помогут усилить практические навыки системного и бизнес‑анализа.
Системный анализ и работа с требованиями
8 сентября, 20:00. «Системный аналитик и его ценность глазами компании». Записаться
23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться
🤖 Типовые задачи, на которые уходит время: сбор требований, user stories, документирование as-is / to-be, ТЗ и спецификации 🤖 Инструменты: ChatGPT, GigaChat, YandexGPT с промптами для аналитика; RAG-ассистенты на корпоративной базе; ИИ для диаграмм и моделирования 🤖 Оркестрация нейросетей: одна модель (Claude) распределяет задачи между специализированными моделями и собирает результат 🤖 Кейс из практики: задача, цепочка ИИ-агентов, результат, что дорабатывалось вручную 🤖 Границы применимости ИИ: контекст, стейкхолдеры, внутрикорпоративные процессы. Критическое мышление.
📆 Когда: 8 сентября в 18:00 (Мск) 👨🎓 ️Спикер: Новичков Александр, L&D-стратег, руководитель образовательных проектов
Собрали подборку из пяти материалов о разных задачах аналитика: от работы с требованиями и взаимодействия с командой до поиска решений и использования ИИ.
Как подготовить задачу так, чтобы сократить количество уточнений и переделок, расставить приоритеты и иногда найти решение без дополнительной разработки.
Кодекс — это скорее рекомендации, чем настоящие правила
Как говаривал капитан Барбосса, «Кодекс — это скорее рекомендации, чем настоящие правила».
Все агенты по натуре тоже пираты. Все ваши промты, правила и скиллы — для них не более чем рекомендации, как и пиратский кодекс. Нет такой инструкции, которую агент не мог бы нарушить.
Причем агент не идет на нарушение сознательно. Взломщик, проникший в ювелирный магазин, знает, что он совершает ограбление. Агенты, ломавшие Hugging Face, не думали о том, что это незаконно. Они просто наилучшим образом пытались выполнить данное им задание.
Так и пираты — они нарушают свой кодекс не потому, что они беспринципные подонки. Просто они хотят наилучшим образом выкрутиться из ситуации, в которую они попали, и если соблюдение правил сулит им неприятности, то к черту такие правила!
— И как же быть?
Принять тот факт, что любые писанные правила не являются гарантией корректной работы агента.
— Но почему?
Потому что они записаны на естественном языке. А язык многозначен, допускает множество интерпретаций. Причем таких, о которых вы и не думали, составляя свои правила.
Изворотливый ум всегда найдет лазейку, удобную для себя интерпретацию, когда он формально ничего не нарушает, но все же выходит за рамки, которые вы хотели обозначить.
Ключевое слово здесь «хотели». Ибо вам и в голову не придет описать все исключительные ситуации, все возможные двусмысленности, которые найдет в ваших словах другой ум — не важно, человеческий или искусственный.
Вот, например, известная шутка:
— Учитель, можно ли курить во время медитации? — Ни в коем случае! — А можно ли медитировать во время курения? — Да пожалуйста!
— Так что делать‑то?
Строить контролирующий контур вне ИИ. Как вариант, можно взять BPM‑систему и поместить агента в жесткие рамки бизнес‑процесса. Об этом регулярно рассказывает Бернд Рюкер, со‑основатель и главный технолог Camunda. Мне его позиция кажется вполне здравой и этот подход реализуемым.
Но там есть свои нюансы — если слишком закрутить гайки, и не учесть краевые сценарии, то агент просто уходит в ступор.
Например, вы дали правило ни в коем случае не выдумывать данные, если их нет. Разумно, не правда ли? — Но вы не учли, что при определенном раскладе, сервис, который эти данные должен предоставить, тупо завис. А у агента нет такой опции сказать, что продолжить работу невозможно, потому что система не отвечает. И он падает. Человек на его месте начала бы возмущаться или просто забил бы и ушел на обед, но агент так не может.
Соответственно, вам придется учесть больше вариантов, когда будете строить BPMN‑модель для процесса с участием агентов.
Если вам не нравится BPM, можно найти и другие решения.
Главное — не полагаться только на ИИ, чтобы управлять ИИ.
Инфостарт завершает прием заявок в программу INFOSTART A&PM EVENT 2026. До 28 августа аналитики, архитекторы, руководители проектов и специалисты по автоматизации могут предложить доклад или практическую активность.
В программе предусмотрены не только классические выступления, но и мастер-классы, воркшопы, круглые столы, тренинги и деловые игры. Около 70% расписания планируется отвести практическим форматам, остальные 30% — докладам с кейсами, рабочими инструментами и разбором ошибок.
Основные направления конференции:
управление проектами и продуктами;
инструментарий и прикладные компетенции аналитика;
архитектура и автоматизация решений на 1С;
управление командами и soft skills.
Полностью готовая концепция на этапе подачи не обязательна: модераторы рассматривают идеи, дают обратную связь и помогают авторам доработать формат.
INFOSTART A&PM EVENT 2026 пройдет 12–14 ноября в Санкт-Петербурге. Прием заявок завершится 28 августа.
Как евангелист не только ЛИМС, но и ноу-код конструкторов приложений, нашел OneBase — Open-source платформа для бизнес-приложений https://onebase.ivantitov.tech/index.html
Open-source платформа для создания бизнес-приложений. Слоган Пишем как в 1С — без 1С. Знакомые концепции 1С (настройка и программирование на русском языке).
Приложение полностью в одном файле (как и DataExpress), метаданные (формы, скрипты) хранятся отдельно в YAML. Доступно использование в качестве хранилища локального файла базы SQLite, а для совместной работы можно развернуть PostgreSQL.
Вобщем будут следить за новостями и попробую собрать какое-нибудь приложение.
В целом точно будет полезно для различных MVP и проверки гипотез.
Новый выпуск «Сколько стоит WMS» — про CAPEX склада
В новом выпуске подкаста «Сначала Процессы» разбираем затраты, которые возникают, когда склад расширяют за счёт дополнительной техники и площадей.
Сколько склад переплачивает за технику и квадратные метры
Говорим о том:
— сколько стоит простой и холостые пробеги ричтраков и как оптимизация маршрутов может сократить расстояние перемещений на 25–37%; — когда вместо покупки ещё одного ричтрака за 2,2–5,7 млн ₽ можно эффективнее использовать существующий парк; — сколько стоит низкая плотность хранения при аренде склада класса А; — как уплотнение хранения с 0,35 до 0,50 позволяет получить эквивалент 1 050 м²; — в каких случаях WMS может отложить расширение склада на 12–24 месяца; — что меняется при переходе на узкопроходное хранение (VNA).
И главное — считаем три сценария в рублях: дополнительная техника, новые площади и инвестиции в WMS + оборудование.
Выпуск: «Сколько склад переплачивает за технику и квадратные метры. Считаем окупаемость WMS через CAPEX»
Шесть профилей, три локальные модели: как родился Hermes-хаб
Модели отвечали на всё. Проблема была в другом: отвечал кто угодно, только не директор, не разработчик и не аналитик.
Девятого июля я собрал первую версию хаба на Mac mini M4. Шесть профилей: директор (он же оркестратор), разработчик, аналитик, аудитор, Wiki-куратор, писатель. Три локальные модели через Ollama, общий адрес http://127.0.0.1:11434/v1, дефолт на всех профилях gemma4:12b. Звучало как готовый штаб.
А штаба не было. Я задавал вопрос директору и получал ответ без единого признака директора. Роли и принципы лежали в SOUL.md каждого профиля, но написаны по-английски и по шаблону: «You are a chief of staff for a systems architect». Формально всё работало. По сути я разговаривал с одним безликим болванчиком в шести шляпах.
Десятого июля я переписал все SOUL.md на русский. Директор стал «chief of staff для системного архитектора», его задача защищать долгосрочный горизонт пользователя от краткосрочного шума.
На следующий день добавил gpt-oss:20b и llama3.2:3b. Вот тут характеры вроде бы ожили. Модель держала роль, отвечала по-русски и применяла правила, а не пересказывала их.
Личность живёт не в модели, а в тексте, который модель читает перед каждым ответом. На русском она работает лучше.
В офисе ИнфоТеКС мы открыли Летний ТехФест и провели воркшоп по Event Storming — это 90 аналитиков, техлидов и ни одной скучной лекции. Всех участников ждали полное погружение в практику и нетворкинг.
P.S. В нашем TG-канал рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.
Исследователи Dreadnode проверили, насколько честно LLM-агенты проходят задания по наступательной ИБ. В эксперимент вошли 22 передовые модели семи провайдеров, 23 CTF-задания средней сложности из Cybench и три системных промпта: без запрета на обход правил, с обычным запретом и с жёстким перечнем запрещённых действий. Все 1518 траекторий прошли многоступенчатый аудит.
Результат ставит под сомнение pass rate как меру реальных возможностей. Без запрета 37,1% успешных прохождений были получены с нарушением правил, а жульничала 21 из 22 моделей. Средний pass rate составлял 41,5%, но доля честно решённых заданий — лишь 26,1%. У отдельных моделей оценка завышалась до пяти раз. Агенты искали готовые write-up, клонировали репозитории с решениями, читали файлы с флагами и исследовали служебную инфраструктуру.
Инструкции помогли, но проблему не закрыли. Доля заданий, в которых модель хотя бы пыталась жульничать, снизилась с 33% до 17,8% с обычным запретом и до 8,5% с жёстким. Доля честных решений при этом выросла с 26,1% до 34,4%: модели чаще продолжали самостоятельный поиск. Но даже при максимальных ограничениях восемь моделей получили хотя бы один результат с нарушением правил, а у четырёх возник обратный эффект. Обман также сместился от веб-поиска к исследованию инфраструктуры.
Авторы предлагают отдельно считать solve rate — долю только честных решений. Одного промпта для достоверной оценки мало: нужны изоляция служебных данных, ограничение интернета, аудит траекторий и свежие задания без опубликованных решений.
Снаружи ИИ-ассистент выглядит как окно чата. Но внутри — инференс, векторный поиск, база знаний, RAG-пайплайн, мониторинг и контроль доступа. От того, как всё это собрано, зависит, за сколько секунд приходит ответ, во что обходится каждый запрос и переживет ли сервис наплыв пользователей.
В статье разобрали инфраструктуру по слоям: где держать данные и контекст, каким задачам нужен GPU, а каким хватит CPU, и зачем связке из модели, хранилища и интерфейса контейнеры и Kubernetes. Плюс разница между MVP и production-архитектурой и типичные ошибки при проектировании.
Почему современные интерфейсы иногда усложняют жизнь
Интерфейсы с каждым годом становятся только удобнее: часть задач, например, сейчас можно решить с голосовым помощником. Но новые технологии не всегда делают взаимодействие с системой проще. Пользователи по-прежнему теряются в меню, тратят время на поиск нужных функций и устают от необходимости постоянно принимать лишние решения.
Поговорили об этом с Динарой — она помогает настраивать интерфейсы корпоративных систем для крупных компаний и каждый день ищет баланс между задачами бизнеса, возможностями системы и опытом пользователя.
1️⃣ Как изменилось взаимодействие человека с интерфейсами?
Они стали ближе к человеку. Если раньше компьютер требовал знать команды и мыслить как машина, то сегодня технологии все больше подстраиваются под нас: появились графические интерфейсы, сенсорное управление, голосовые помощники, искусственный интеллект.
Но сама эволюция не гарантирует удобство. Каждое новое решение нужно оценивать не по тому, насколько оно современное, а по тому, помогает ли оно человеку быстрее решать свою задачу.
2️⃣ Почему даже современный интерфейс может утомлять пользователя?
Потому что любая система требует внимания. Если человеку приходится искать нужную функцию, осваивать непривычные сценарии или постоянно принимать лишние решения, растет когнитивная нагрузка. А когда пользователь работает в системе по восемь часов в день, даже небольшие неудобства накапливаются и заметно влияют на его состояние и эффективность.
3️⃣ Получается, «проще» не всегда означает «лучше»?
Именно. Иногда в погоне за минимализмом или новыми трендами мы убираем то, что было интуитивно понятно.
Хороший пример — автомобили. Многие производители перенесли управление важными функциями на сенсорные экраны. В результате даже простое действие требует отвлечься от дороги. Поэтому сегодня часть компаний возвращает физические кнопки для критически важных функций.
4️⃣ Можно ли создать интерфейс, который будет удобен для всех?
Универсального решения не существует. Есть контекст, задачи пользователя и его привычки. Один и тот же подход может отлично работать в мобильном приложении и совершенно не подойти для сложной корпоративной системы.
Поэтому важнее искать не идеальный, а уместный интерфейс — тот, который соответствует конкретной задаче и условиям, в которых человек будет им пользоваться.
5️⃣ Как понять, что новое решение действительно улучшает интерфейс?
Я бы каждый раз спрашивала себя: станет ли пользователю действительно проще после этого изменения? Если решение выглядит современно, но увеличивает количество действий, заставляет переучиваться или сильнее отвлекает, возможно, это не улучшение, а шаг назад.
→ Подробнее своим опытом Динара поделилась в статье.
Считаем окупаемость WMS через бизнес-процессы: новый выпуск подкаста «Сначала процессы»
В управленческом отчёте маржа и операционные расходы выглядят предсказуемо. На складе часть убытков проходит по статьям, которые в эту отчётность не попадают.
Это шестой выпуск подкаста INTEKEY «Сначала процессы» и второй в тематической серии про окупаемость WMS. Предыдущий выпуск серии считал окупаемость через персонал: зарплаты, текучку, стоимость найма. Этот рассматривает только механику складской рутины, без учёта людей.
Новый выпуск подкаста "Сначала Процессы". Окупаемость WMS через изолированный критерий "бизнес-процессы".
Сравнение «12 млн за WMS — дорого» строится относительно нуля. На практике склад уже платит эту сумму каждый день: транспортные компании получают деньги за повторные рейсы из-за ошибок, банки — проценты по кредитам на закупку товара, который физически есть на складе, но его не могут найти.
Брак комплектации 1,5–2% на первый взгляд означает высокую точность. Полная стоимость одной ошибки складывается из нескольких шагов: повторная поездка, приёмка возврата, пересборка заказа, время менеджера на разговор с клиентом, корректировочные документы в бухгалтерии. Для российского B2B это около 4 000 ₽ за случай. При 500 отгрузках в день и 2% брака — больше 200 ошибок в месяц, около 800 000 ₽.
Товар физически лежит на складе, но недоступен для продажи, пока не отражён в системе. Приёмка на 150–250 строк силами трёх человек занимает около 4 часов: разгрузка, подсчёт, разбор накладных, звонки поставщику при расхождениях. Всё это время товар не виден отделу продаж. WMS с ASN (предварительным уведомлением об отгрузке) делает товар доступным к продаже в момент сканирования на воротах и сокращает процесс до 1,5 часов — около 460 000 ₽ в месяц освобождённого ресурса.
Инвентаризация с остановкой склада повторяется четыре раза в год. Прямые расходы на одну такую операцию — около 250 000 ₽ (переработки, доплаты, простои), то есть миллион в год. Цикличный фоновый пересчёт через ТСД убирает необходимость останавливать склад: расхождения фиксируются по мере появления, а не раз в квартал.
Точность остатков около 91% на ручном складе создаёт разрыв между системой и реальностью: закупщик видит в ERP отсутствие товара и заказывает новую партию, хотя старая лежит в другом углу склада. При запасе 90 млн ₽ разрыв 8,5% замораживает около 7,5 млн ₽. При стоимости капитала для бизнеса около 25% годовых это около 160 000 ₽ в месяц дополнительных расходов.
