55-70% времени сквозного цикла уходит на стыки между отделами, а не на работу. По 8 анонимизированным проектам NeoGraph медиана потерь составила 3,2 млн ₽/мес. Стыки невидимы в ERP и CRM, потому что эти системы работают внутри отделов. Покупка ещё одной системы редко закрывает то, что прячется на границе.
Это не теоретическая цифра. По 8 закрытым проектам NeoGraph (логистика, FMCG, производство, дистрибуция). Минимум 0,9 млн ₽/мес у компании на 80 человек, максимум 12 млн ₽/мес у крупного дистрибьютора.
Стык — это точка передачи данных, задачи или ответственности между двумя подразделениями компании.
В управленческом учёте есть отдел, есть процесс, есть ресурс. Между ними пустота, которую никто не считает. Отдел продаж отвечает за свою воронку. Склад отвечает за свою точность. Логистика отвечает за доставку. А переход «продажа → склад» формально не принадлежит никому. Эту пустоту мы и называем стыком.
Похожие фреймы есть в смежных дисциплинах. Системная инженерия говорит про interfaces. Lean называет это handoffs или waiting waste. BPM знает про межоперационные потери. В B2B-консалтинге для среднего бизнеса фрейм недооформлен, поэтому в проектах его пропускают. Именно поэтому 67% ERP-внедрений не достигают целевых KPI: проектная команда считает, что покупает софт, а на самом деле должна была чинить границы между отделами.
Стык работает как управленческая категория, не техническая. Технология может его обслужить, но не может создать ответственность там, где её нет.
Концепция держится на пяти тезисах. Каждый проверен на 8 проектах NeoGraph, опубликован в РБК и подтверждён практикой компаний размером от 50 до 5 000 сотрудников.
Стык появляется там, где задача, документ или ответственность переходят между двумя подразделениями. Это не отдел продаж и не процесс отгрузки, а граница между ними. В управленческом учёте граница невидима: у CRM свой владелец, у склада свой, у логистики свой. Никто не отвечает за переход. На практике это выглядит так: продавец оформил заказ в CRM, а кладовщик получает задание через час, потому что кто-то должен скачать выгрузку из 1С и отправить файл по почте. Это и есть стык.
Заказ оформлен в 14:00, задание на сборку появилось в 15:10. Час просто исчез между двумя системами и двумя людьми.
По 8 анонимизированным проектам NeoGraph медиана потерь на стыках составила 3,2 млн ₽/мес. Это не работа, а ожидание. Сотрудник внутри отдела делает свою операцию за минуты или часы, а потом задача лежит сутки или двое, пока соседний отдел её заметит и подхватит. Производительность считают по операциям, и она часто хорошая. Цикл «Заказ → Деньги» при этом растягивается на недели. Лекарство против внутренней эффективности отдела не работает. Лекарство нужно прикладывать к границе.
Отдел снабжения закрывает заявку за 4 часа. Заявка лежит у инициатора 3 дня до согласования. Эффективность снабжения — 100%, цикл закупки — 4 дня.
Управленческие системы построены вокруг отделов. ERP знает движение материалов внутри производства, CRM знает воронку продаж, WMS знает остатки на складе. Что происходит между ними, не видит никто. Время передачи задачи из CRM в WMS не записано нигде. Когда CFO смотрит отчёт, он видит работу систем, но не видит пустоты между ними. Поэтому реальная себестоимость заказа всегда выше плановой, а собственник не понимает, куда уходят деньги. Считать стыки приходится отдельно, на руках, по выгрузкам и логам.
CFO нашёл расхождение в 3% между плановой и фактической маржой. Источник нашли через месяц: 18 часов средней задержки между «Заказ принят» и «Сборка начата».
Это самая дорогая ошибка отрасли. Компания видит, что между отделами хаос, и решает, что нужна большая ERP, которая всё свяжет. Через 18 месяцев и 25 миллионов рублей она получает ту же самую границу, только теперь между двумя модулями одной системы. По данным Panorama Consulting за 2024 год, 67% ERP-проектов не достигают целевых KPI в первый год. Причина не в софте. Граница между «закупки» и «склад» остаётся, даже если оба отдела работают в SAP. Управленческая категория не лечится технической.
Дистрибьютор внедрил единую ERP на закупки и склад. Через 8 месяцев замерили: средняя задержка между «приход на склад» и «доступно к продаже» — 14 часов. Раньше было 16 часов.
Когда стык виден, починить его обычно недорого. Не нужно менять всю архитектуру. Нужно увидеть конкретный переход, измерить его в часах и рублях, поставить SLA, иногда добавить интеграцию или AI-ассистента. Бюджет на устранение одного дорогого стыка обычно 200-800 тысяч рублей. Возврат за 2-4 месяца. Сначала диагностика на 1-2 недели: где границы, что на них теряется, во что это обходится. Потом ремонт 2-4 самых дорогих стыков. Потом смотрим, нужна ли вообще большая система.
Производитель обнаружил три стыка с потерями 2,4 млн ₽/мес. Бюджет на ремонт — 540 тыс. ₽. Окупаемость — 7 недель.
Стыки бывают разные, и лечатся разными инструментами. В наших проектах мы встречаем четыре типа, иногда комбинированные. Знание типа помогает выбрать правильное решение и не покупать ERP там, где нужен RACI.
Данные есть, но не видны соседнему отделу. CRM знает планируемую отгрузку, склад не знает. Кладовщик видит заказ за 2 часа до отгрузки, и собирает в спешке. Лечится репликацией данных или общим дашбордом.
Данные передаются, но в разном формате. Бухгалтерия требует Excel, склад работает в WMS, логистика хочет 1С. Кто-то постоянно конвертирует руками. Лечится через парсер или промежуточный API. Распространён в компаниях со «зрелой» автоматизацией.
Нет SLA на передачу. Заявку пометили «отправлена снабжению», а когда снабжение её увидит, никто не знает. Лечится через сроки реакции, очередь и эскалацию. Самый частый тип в средних компаниях с регламентами уровня «развитого».
Не назначен владелец перехода. Закупки говорят «это уже склад», склад говорит «это ещё закупки». Задача висит «между двумя стульями». Лечится не интеграцией, а матрицей RACI и единым ответственным за сквозной процесс.
Стык невидим в учёте, но измерим. Базовая формула опирается на четыре переменные, которые можно собрать через выгрузки и интервью за 2-3 дня. Подробный гайд с примером по дистрибьютору и шаблоном для самостоятельного расчёта — в отдельном материале.
Пошаговый расчёт на примере дистрибьютора с 80 заказами в день, чек-лист из 7 шагов, готовый шаблон Excel. Можно посчитать самостоятельно за 1 день, без подрядчика и без ERP.
Открыть гайдКонцепция «Стыки дороже систем» прошла модерацию федеральных и отраслевых изданий. Ниже публикации, которые формируют публичный контекст идеи и подтверждают экспертизу автора.
Сигнатурный материал серии. Через 4 дня после публикации pos 2.5 в Яндексе с CTR 16,7%.
Авторская статья в разделе CIO News. Стыки между ERP, WMS и розничными магазинами на конкретном примере.
Пять типовых сценариев, где точечные доработки эффективнее внедрения большой системы. ERP не закрывает управленческую границу между отделами.
Первая публикация серии. Раскрывает причину провала автоматизации: межфункциональные разрывы и игнор сквозных процессов на этапе скоупа.
Бизнес-процесс — это последовательность операций внутри одного отдела с понятным владельцем. Стык — это переход задачи или данных между двумя процессами или двумя отделами, у которого обычно нет владельца. Процесс «оформление заказа» в CRM существует, у него есть метрика. Процесс «передача заказа на склад» формально не существует. Поэтому стыки невидимы в стандартных BPM-картах, и их надо специально искать.
Нет, и не нужно. Стыки появляются там, где есть специализация отделов, а специализация полезна. Цель не в нулевом количестве стыков, а в видимом количестве и управляемой стоимости. Дорогие стыки чиним, дешёвые оставляем. Хороший показатель: каждый стык на сквозном цикле имеет SLA, владельца и метрику задержки. По нашим проектам, при достижении этого уровня потери на стыках падают на 60-70%.
Сначала диагностику. Это 1-2 недели работы и 200-500 тысяч рублей. На выходе вы знаете, где теряете деньги и сколько. Без этого вы покупаете ERP или AI-платформу вслепую и рискуете попасть в те же 67%, что не окупаются (Panorama Consulting, 2024). После диагностики обычно становится ясно: ремонт 3-4 точечных стыков даёт 65-70% эффекта, который ожидался от большой системы, но за 10% бюджета.
Работает, но в упрощённом виде. В компании на 30 человек обычно 3-5 функциональных команд: продажи, операции, финансы, иногда производство. Между ними те же 4-6 стыков, что в крупной компании, только потери в рублях меньше. Часто маленькая компания не нуждается в формальной диагностике, достаточно интервью с собственником и анализа 2-3 ключевых сквозных циклов. Цель — поймать самые дорогие стыки до того, как компания вырастет до 100 человек, и стыки станут дороже исправления.
Прямо связана. Стыки делятся на две категории: те, что система закроет автоматически, если оба отдела на ней работают, и те, что система не закроет, потому что граница не техническая, а управленческая. Перед покупкой ERP надо составить список ваших дорогих стыков и проверить каждый: закроет ли его новая система. Часто оказывается, что 4 из 6 закроет, а 2 останутся. И вот эти 2 стоят 60% всех потерь. Тогда правильный план: ремонт двух стыков сначала, ERP потом.
Концепция стыков связана с услугами, гайдами и кейсами на сайте. Ниже маршруты для разных задач: посчитать самостоятельно, заказать диагностику, прочитать практический пример.
Услуга на основе концепции стыков. Диагностика 1-2 недели, точечные доработки, окупаемость 2-3 месяца.
Полная карта стыков по сквозному циклу. Карта с приоритетами, где чинить в первую очередь, что отложить.
Telegram-бот собирает 12-15 вопросов о ваших процессах, на выходе оценка потерь на стыках в рублях.
Формула, пример расчёта на дистрибьюторе, чек-лист из 7 шагов. Можно посчитать самостоятельно за день.
Практический пример: компания из 200 человек теряла 18 часов в неделю на ручную сверку Excel-файлов.
Связанный нарратив про причины провалов ERP/CRM. Главный фактор провала — игнор стыков на стадии скоупа.
Два пути узнать. Быстрый — через бесплатный AI-аудит в Telegram, ответы на 12-15 вопросов и оценка потерь в рублях за 10 минут. Полный — через E2E-диагностику с картой всех стыков по сквозному циклу за 1-2 недели.