Логист показывает норматив: сборка заказа — 40 минут, держим стабильно, отклонений нет.
Клиент в это же время говорит: заказал в понедельник, получил в следующий понедельник.
Между этими двумя фактами лежат шесть дней, которых как будто не существует. Их никто не измерял, потому что каждый участок отвечает за свою операцию и по своей операции укладывается в норму.
Заказ редко опаздывает вообще. Он задерживается в конкретном месте: ждёт подтверждения, передачи между функциями, готовности товара, комплектации или следующего окна отгрузки. Разберём, как найти это место и почему разговор о том, кто работает медленно, ведёт не туда.
Где теряются дни между заявкой и получением
Клиент видит один срок — от обещания до получения. Внутри компании этот срок разбит на несколько операций и паузы между ними, причём операции измеряются, а паузы нет.
Время работы и время ожидания — разные величины
Когда заказ комплектуют, проверяют или оформляют, с ним происходит работа. Когда он лежит между этапами и ждёт подтверждения, передачи или следующего события, календарь идёт, а операция не выполняется.
- Время работы — комплектация, проверка, оформление. Измеряется: по каждой операции есть норматив.
- Время ожидания — заказ лежит между этапами и ждёт подтверждения, передачи или следующего события. Не измеряется: паузы не принадлежат ни одному участку.
Вместо того чтобы измерять длительность операций, мы раскладываем весь путь заказа на работу и ожидание — и получаем картину полного клиентского срока.
Разложение меняет направление анализа. Допустим, сборка уже быстрая. Ускорить её технически можно, но клиент этого не почувствует, если до сборки заказ сутки ждёт решения, а после — двое суток отправки.
На большинстве складов, где такой замер делается впервые, доля собственно работы в сквозном сроке оказывается заметно меньше, чем ожидают участники процесса. Точное соотношение у каждого своё, но порядок величин обычно удивляет всех, включая руководителя склада.
Почему норматив на сборку ничего не говорит о сроке для клиента
Норматив измеряет отрезок, а клиент оценивает весь маршрут заказа
Время сборки заказа как норматив — полезная вещь для планирования смены. Как показатель качества обслуживания клиента он не работает вообще.
Причина простая: норматив измеряет отрезок, а клиент оценивает маршрут. Можно улучшить норматив на треть и не сдвинуть срок доставки ни на день, если основное время заказ проводит не в работе.
Это как оценивать поездку по времени, проведённому в движении, игнорируя стояние на светофорах. Скорость на свободных участках можно наращивать долго и с гордостью — приедете вы всё равно поздно.
Как пройти с одной накладной весь путь
Средний лидтайм полезен для наблюдения за результатом, но механику отдельной задержки не объясняет. Чтобы понять, где заказ потерял время, восстановите фактическую последовательность событий по одной накладной.
Точки, которые нужно зафиксировать:
- заявка получена;
- заказ подтверждён;
- заказ передан на склад или поставщику;
- товар готов;
- комплектация завершена;
- готовность подтверждена;
- заказ отгружен;
- заказ получен клиентом.
По каждому переходу интересуют четыре величины: вход на этап, выход с этапа, выполненная работа, ожидание.
Вместо того чтобы обсуждать процесс по схеме «как у нас должно происходить», мы восстанавливаем один фактический маршрут — и получаем последовательность реальных событий.
Регламент описывает проект процесса, накладная показывает процесс в эксплуатации
Регламент описывает проект процесса. Накладная показывает процесс в эксплуатации. Между ними обычно есть зазор, и он растёт со временем — как между чертежом и зданием после нескольких лет перепланировок.
Одна накладная не доказывает системность. Но она превращает абстрактное «у нас долго» в проверяемую временную линию. Пять-шесть разборов уже показывают, повторяется ли один и тот же участок ожидания.
Поставщик срывает сроки — что делать, если непонятно, он ли это
Когда товар приходит позже нужной даты, самое удобное объяснение звучит просто: поставщик задержал. Иногда так и есть.
Но прежде чем давить на поставщика, стоит проверить одну дату.
Когда заказ ушёл поставщику с опозданием
Сравните плановую дату передачи заказа поставщику с фактической. Если вы передали заказ позже собственного плана, часть общей задержки возникла до того, как у поставщика вообще появилось обязательство.
Вместо того чтобы относить весь срыв к поставщику, мы сравниваем плановую и фактическую дату передачи — и получаем границу внутренней и внешней ответственности.
Ситуация типовая. По внутреннему плану заказ должен был уйти во вторник, ушёл в четверг. Поставка пришла позже клиентской даты. Два дня до передачи записывать поставщику нельзя — но в большинстве отчётов они туда попадают автоматически, потому что считаются от факта размещения, а не от плана.
Метрика показывает цифру и искажает причину — как зеркало с кривой геометрией
Метрика в такой конфигурации работает как зеркало с кривой геометрией: цифру показывает, причину искажает.
Как отделить внешнюю причину от внутренней
Вопрос перестаёт звучать как «кто сорвал поставку» и превращается в последовательность проверок: когда заказ должны были передать, когда передали фактически, что происходило после.
Это не снимает ответственность с поставщика и не переносит её внутрь заранее. Наоборот — разделение не даёт смешивать две разные причины в одну удобную категорию.
В процессном анализе ошибочная причина опаснее ошибочной цифры.
Неверную цифру рано или поздно замечают. Неверная причина годами направляет улучшения не туда: компания шлифует работу с поставщиками, а теряет дни на собственном согласовании.
OTIF: как считать и что показатель скрывает
OTIF работает только тогда, когда компания заранее договорилась, что именно и по каким правилам считает. Здесь опасна иллюзия очевидности: кажется, что «вовремя» и «полностью» понятны без определений.
On time и in full — почему обе части нужны
Итоговый OTIF складывает нарушение срока и нарушение полноты в одну цифру
Один заказ выполнен в срок, но не полностью. Другой — полностью, но с опозданием. Отклонение есть в обоих случаях, а управленческие причины разные.
- Нарушена полнота (in full) — заказ пришёл в срок, но не полностью. Это обычно про наличие.
- Нарушен срок (on time) — заказ пришёл полностью, но с опозданием. Это обычно про процесс.
Вместо того чтобы использовать итоговый OTIF как диагноз, мы разделяем нарушения срока и полноты — и получаем две разные ветки анализа.
Если сложить их в одну цифру и остановиться, диагностика закончится там, где должна была начаться.
От какой даты считать
Ключевой вопрос, на котором расчёты расходятся чаще всего: своевременность оценивается от даты, которую запросил клиент, или от даты, которую вы подтвердили?
- От подтверждённой даты — вы измеряете исполнение собственных обязательств.
- От запрошенной клиентом даты — вы измеряете способность отвечать на потребность рынка.
Разница принципиальная. Обе метрики законны, но это разные метрики, и смешивать их в одном отчёте нельзя.
Почему низкий OTIF не означает плохого поставщика
Точность поставок как измеряемая величина зависит от того, где вы поставили точку отсчёта и что признаёте полным выполнением. Строка с недовозом одной позиции из двадцати может считаться невыполненной целиком — и тогда показатель обвалится, хотя сервис фактически неплохой.
Универсальных целевых значений OTIF мы не приводим сознательно: они бессмысленны без указания единицы анализа и базовой даты. Чужая цифра «95%» может быть посчитана по правилам, при которых ваши 78% превратились бы в 96%. Сравнивать имеет смысл себя с собой в динамике при неизменной методике.
Как повысить производительность склада: где узкие места внутри
Фраза «товар есть на складе» создаёт ощущение, что заказ почти выполнен. Но наличие товара и готовность заказа к отправке — разные события, и между ними помещается больше времени, чем кажется.
Для анализа разделите три момента: завершение комплектации, подтверждение отгрузочной готовности, фактическая отправка.
Ошибки при комплектации заказов и их цена
Ошибка в комплектации стоит не времени на исправление, а полного цикла заново.
Одна ошибка сборки превращается в неделю задержки — и в отчёте по срокам она выглядит как срыв, хотя причина в качестве.
Поэтому доля заказов с ошибками комплектации — это показатель сроков, а не только показатель качества. Их стоит смотреть вместе.
Адресное хранение на складе: что даёт и когда не помогает
Адресное хранение сокращает время поиска позиции и снижает зависимость от памяти конкретного кладовщика. Это реальный эффект, особенно на широком ассортименте.
Чего оно не делает — не ускоряет то, что происходит после сборки. Если заказ собран за сорок минут, а потом сутки ждёт подтверждения готовности, внедрение адресного хранения улучшит те сорок минут и не тронет сутки.
Это к вопросу о том, какие проекты запускать первыми: адресное хранение окупается там, где узкое место действительно внутри комплектации, и почти не даёт эффекта там, где оно после неё.
Окно отгрузки и отгрузочная готовность
Причинная цепочка на этом участке обычно выглядит так:
- Комплектация завершилась позже — готовность подтверждена позже.
- Доступное окно отгрузки пропущено — заказ ждёт следующего окна.
- Следующее окно на следующий день — плюс сутки минимум.
Заметьте, где здесь потеря. Не в комплектации, которая опоздала на час, а в дискретности отгрузки: окно либо застали, либо нет.
Час опоздания превращается в сутки ожидания.
Ускорять комплектацию бессмысленно, если пропущено окно отгрузки
Ускорять в такой ситуации комплектовщика — всё равно что менять двигатель, когда машина стоит перед закрытым шлагбаумом. Технически улучшение произошло. Время прибытия не изменилось.
Как сократить лидтайм заказа
Когда временная линия собрана, возникает соблазн составить список из пятнадцати проблем и запустить улучшения везде. Это надёжный способ получить много активности и мало результата.
Убирать ожидание, а не ускорять работу
Приоритет определяется по месту максимального или повторяющегося ожидания, которое удерживает переход к следующему этапу. Важно не только то, что пауза велика сама по себе, но и то, блокирует ли она движение дальше.
Вместо того чтобы ранжировать проблемы по громкости жалоб, мы ищем ожидание, которое держит следующий переход — и получаем кандидата на первое изменение.
В одном из наших проектов в e-commerce набор проблем был именно таким: логистика, доставка, клиентский сервис и стоимость обработки заказов росли одновременно с ростом спроса. Работа шла не с расширением мощностей, а с перестройкой цепочки — результатом стал рост дохода на 15% без вложений. Разбор проекта — в кейсе на сайте.
Что менять первым при ограниченных ресурсах
Это самая частая ошибка в проектах по срокам: локальный участок ускорили, отчитались, а сквозной срок остался прежним, потому что очередь переехала на шаг вперёд.
С чего начать разбор сроков
Практический первый шаг занимает несколько часов и не требует ни системы, ни бюджета.
Возьмите пять заказов, по которым были жалобы на срок, и восстановите по каждому полную временную линию: когда пришла заявка, когда подтвердили, когда передали, когда собрали, когда подтвердили готовность, когда отгрузили, когда получил клиент. Выпишите паузы между событиями.
Дальше смотрите не на самую длинную операцию, а на самую длинную паузу — и проверяйте, повторяется ли она во всех пяти случаях. Если да, вы нашли не частный сбой, а свойство процесса.
Поток не интересуется оргструктурой. Заказ просто идёт — или ждёт.
Если сроки срываются, а причина неочевидна — опишите ситуацию, разберём.
Расскажите своими словами: какой срок обещаете клиенту, какой получается фактически, где по вашим ощущениям заказ стоит дольше всего. Ответит партнёр CI Consult лично — не рассылкой и не типовой презентацией.
