Принцип «точно вовремя» (Just-in-Time, JIT) часто пересказывают как простой рецепт: убрать склад, и деньги вернутся. Исследование Садао Сакакибары, Барбары Флинн и Роджера Шредера в журнале Management Science (1997) этот рецепт опровергает. Авторы проверили пять гипотез методом канонической корреляции. Значимой связи между JIT-практиками, взятыми отдельно, и результатами производства не нашлось. Связь появлялась только там, где JIT-практики работали вместе с «инфраструктурой», то есть с практиками, которые создают для JIT подходящую среду. При этом инфраструктура сама по себе тоже объясняла результаты производства.
Отсюда главный вывод для руководителя: JIT нельзя свести к логистике склада, это свойство всей организации. В 1977 году инженеры Toyota Ё. Сугимори, К. Кусуноки и Ф. Тё сформулировали принцип так: производить только нужные изделия, в нужное время и в нужном количестве, а запасы держать на минимуме. Если не менять качество, переналадку, график и отношения с поставщиками, выполнить эту формулу не получится.
Ниже разобраны источники метода, его элементы и критика. Отдельно описаны ошибки, которые повторяются при внедрении, и пошаговый план пилота, который ведёт от карты запасов к постепенному снижению буфера.
Происхождение и исследовательская база метода «точно вовремя»
Линия Toyota: Тайити Оно и статья 1977 года
Главный ранний текст о JIT на английском написали сами сотрудники Toyota. В 1977 году Ё. Сугимори, Каноёси Кусуноки и Ф. Тё опубликовали в International Journal of Production Research статью «Toyota production system and Kanban system: Materialization of just-in-time and respect-for-human system». У неё 1332 цитирования. Авторы пишут, что производственную систему Toyota и систему канбан разработал вице-президент компании Тайити Оно (Taiichi Ohno) и что под его руководством эти системы укоренялись в компании около двадцати лет.
Статья выделяет две отличительные черты системы. Первая — производство «точно вовремя». Авторы называют его особенно важным для сборочных отраслей вроде автомобилестроения: выпускаются только нужные изделия, в нужное время и в нужном количестве, а запасы на руках минимальны. Вторая черта — система «уважения к человеку» (respect-for-human system), которая опирается на способности рабочих. В подзаголовке канбан назван «материализацией» обеих идей. Карточка здесь служит физическим носителем принципа, а сам принцип шире её. Механику карточек мы разбираем отдельно в методике «Канбан: вытягивающая система».
С популярными пересказами здесь есть расхождение. Обычно пишут, что TPS держится на двух столпах: JIT и дзидока, то есть автономизации и остановке при отклонении. В аннотации статьи 1977 года вторым ключевым признаком названо «уважение к человеку», а не дзидока. Мы опираемся на первоисточник: в его формулировке JIT стоит рядом с ролью людей, которые решают проблемы. Дзидока тоже входит в практику TPS, но схему «JIT + дзидока» не стоит выдавать за единственно верную.
Канбан — инструмент, через который JIT воплощён в цехе. Если повесить карточки и оставить прежнюю логику планирования, получится канбан без JIT.
Линия эффективности: JIT и инфраструктура (Сакакибара, Флинн, Шредер, 1997)
Работа «The Impact of Just-in-Time Manufacturing and Its Infrastructure on Manufacturing Performance» начинается с тезиса: JIT — явление всей организации, а не отдельной функции. Авторы построили модель из двух групп практик. В первую вошли собственно JIT-практики. Во вторую — инфраструктурные практики, которые, по гипотезе, делают JIT результативнее. Пять гипотез проверялись канонической корреляцией.
Результаты:
JIT-практики, взятые отдельно, значимо не связаны с результатами производства;
JIT-практики очень сильно связаны с инфраструктурными;
сочетание JIT-управления и инфраструктуры с результатами связано;
инфраструктура сама по себе достаточна, чтобы объяснить результаты производства.
Это самый неудобный для энтузиастов вывод в литературе о JIT. Сокращение партий и запасов без перестройки окружающей системы управления не даёт измеримого выигрыша. В материалах брифа нет размера выборки и состава инфраструктурных практик, поэтому мы их не приводим.
Линия планирования: выровненный график Милтенбурга (1989)
Джон Милтенбург в статье «Level Schedules for Mixed-Model Assembly Lines in Just-In-Time Production Systems» (Management Science, 1989) решал задачу, без которой JIT на сборке не работает. Как выпускать на одной линии много разных моделей и не держать больших запасов? Автор показал, что при требовании JIT производить только нужное, в нужном количестве и в нужное время цель расписания — постоянный темп потребления всех деталей, которые использует линия. Такое расписание называют выравниванием или балансировкой графика. Милтенбург дал этому теоретическое обоснование и предложил алгоритмы и эвристики построения расписаний.
Вывод работы: JIT на входе линии невозможен, если сама линия потребляет детали рывками. Практическое продолжение этой идеи — хейдзунка.
Линия цепочки поставок: JIT-отношения обмена (1988)
Гэри Фрейзер, Роберт Спекман и Чарльз О'Нил в статье «Just-In-Time Exchange Relationships in Industrial Markets» (1988) описали JIT как новую форму отношенческого обмена между производителями комплектного оборудования (OEM) и поставщиками комплектующих и материалов. По словам авторов, к тому моменту такие отношения уже приняли многие OEM и поставщики, а маркетинговая наука почти не обращала на них внимания. Статья отвечает на три вопроса. Чем JIT-обмен отличается от других форм обмена между поставщиком и OEM? Какие условия благоприятны для его запуска? Какие ключевые факторы влияют на успех или провал уже начатых JIT-отношений? Для практики отсюда следует, что JIT на стыке компаний — это особый тип отношений, а не просто график отгрузок.
Учебная линия: как JIT раскладывают курсы операционного менеджмента
В учебных материалах Говинда Бхарвани (Wright State University, 2006) JIT определён как метод управления материалами: нужная деталь, в нужном месте, в нужном количестве, в нужное время. Метод назван основным принципом бережливого производства и подходом, который упорядочивает поток материалов и информации. В результате снижается изменчивость, сокращается время цикла и уменьшаются запасы. У Бхарвани есть важная формулировка: JIT — это философия управления, построенная на непрерывном и вынужденном решении проблем, причём вынуждает к нему вывод запасов из производственной системы.
Курс операционного менеджмента AIU приводит метафору, которую сегодня связывают с JIT: вода в ручье и камни на дне. Запасы, по этой логике, держат, чтобы прикрыть плохое качество, медленные поставки, неэффективность, несогласованность и неопределённость спроса. Запасы стоят денег, ценности не добавляют и не дают увидеть проблемы.
Перенос термина за пределы цеха
Логика «доставить в момент потребности, а не заранее» вышла далеко за пределы производства. Томас Дэвенпорт и Джон Глейзер (2006) применили её к управлению знаниями. Их пример — врач первичного звена Боб Голдшер. Ему нужно ориентироваться в тысячах заболеваний и синдромов, препаратов и лабораторных тестов, а биомедицинская литература каждый год прирастает сотнями тысяч статей. Решение авторы видят в том, чтобы подавать знание в момент принятия решения, а не просить специалиста держать всё в голове.
В страховании компания Vertafore описывает политику JIT-назначения агентов. Агента назначают в момент, когда поступает первая заявка, а не «всех агентов во всех штатах» заранее. Окно для подачи назначения обычно составляет 15 дней, в некоторых штатах 30 или 45. В клинических исследованиях аналогичный подход JITM означает поставку препаратов на площадки под точную текущую потребность. Перенос метода в офисные процессы мы разбираем в методике «Точно вовремя» для непроизводственных процессов.
Термин распространился и в такие области, где с TPS его роднит только идея своевременности. Это адаптивные мобильные вмешательства в здравоохранении JITAI (Класня, Хеклер, Шиффман, 2015; Нахум-Шани и соавторы, 2015; систематический обзор Хардеман и соавторов, 2019), JIT-контроль качества кода (Камеи и соавторы, 2012) и JIT-прогнозирование дефектов (Ян, Ло, Ся, 2015), «точно вовремя» в преподавании (Новак, Гаврин, Кристиан, 1999), JIT-сигнализация в оптических сетях (Вэй, Макфарланд, 2000). В компьютерной безопасности JIT означает компиляцию на лету, и с производством её связывает только слово. Поэтому, когда ищете материалы о методе, уточняйте контекст: англоязычная выдача по запросу «just in time» сегодня вообще занята бродвейским мюзиклом 2025 года.
Ключевые идеи и принципы метода «точно вовремя»
Принцип: три «нужных» — изделие, время, количество
Ядро метода — формула статьи 1977 года: только нужные изделия, в нужное время, в нужном количестве. Учебные курсы добавляют четвёртое измерение — нужное место. Каждое слово формулы что-то запрещает. «Нужное изделие» запрещает делать ходовое впрок вместо заказанного. «Нужное время» запрещает выпускать раньше, даже если оборудование простаивает. «Нужное количество» запрещает добивать партию до удобного размера. Запасы при этом не являются целью, которую надо обнулить. Они остаются минимальными как следствие трёх ограничений.
Принцип: вытягивание вместо выталкивания
В толкающей логике (push) каждый участок работает по своему плану или на полную мощность и отправляет результат дальше, нужен он там или нет. Учебные материалы описывают JIT как обратную схему: материалы и комплектующие «вытягиваются» через систему и приходят туда и тогда, где и когда они нужны. Сигнал к производству подаёт следующий этап, когда фактически расходует изделия. На практике это реализуется через канбан: карточка или иной сигнал от потребителя разрешает изготовить или поставить ровно израсходованное.
Мощность станка показывает, сколько участок может сделать. Сколько он должен сделать, показывает расход следующего этапа.
Принцип: запасы — потери, которые прячут проблемы
В логике JIT запас — это потеря, которую надо устранять, а не страховка. Курс AIU перечисляет, что именно прикрывает запас: плохое качество, медленные поставки, неэффективность, несогласованность, неопределённость спроса. Вода в ручье — это запасы, камни — проблемы. Пока уровень воды высок, камней не видно. Если его снижать, камни проступают. Курс сразу оговаривает: увидеть проблему недостаточно, её нужно решить. Как видно из названия, эта идея связана с методикой о семи видах потерь, где перепроизводство и запасы считаются потерями.
Принцип: вынужденное решение проблем
У Бхарвани JIT назван философией непрерывного и вынужденного решения проблем. Отсюда понятно, почему запасы снижают постепенно. Каждое снижение уровня — это контролируемый эксперимент. Он вскрывает следующую проблему, и её надо закрыть раньше, чем уровень опустится ещё ниже. Если снизить запасы одним рывком, проблемы вскроются все сразу и остановят поток.
Принцип: выровненный смешанный график
Среди ключевых элементов JIT в учебных материалах первым стоит выровненное смешанное производство (level, mixed production). Милтенбург сформулировал его цель математически: постоянный темп потребления каждой детали на линии со смешанными моделями. Если выпускать модели большими блоками («неделю делаем А, неделю Б»), спрос на детали у поставщиков и предыдущих участков скачет. Тогда JIT придётся страховать запасами, и метод теряет смысл.
Принцип: ровный производственный темп
Второй элемент из того же перечня — поддержание производственного темпа (production tempo). Поток работает, когда изделия выходят с постоянным ритмом, привязанным к спросу. Рывки создают локальные очереди и простои, а их снова приходится закрывать запасами. Ритм делает отклонения заметными: если операция не уложилась в такт, это видно сразу, а не в конце смены.
Принцип: поток единичных изделий и ячеистая планировка
Курс Бхарвани раскрывает «создание потока» через конкретные требования:
поток единичных изделий (one-piece flow) вместо передачи партиями;
оборудование расставлено в порядке операций;
небольшое и недорогое оборудование;
U-образная ячейка, движение против часовой стрелки;
рабочие, владеющие несколькими операциями;
удобные перемещения и работа стоя;
определённые стандартные операции.
К ключевым элементам там же отнесены ячеистая планировка (cellular manufacturing) и бережливая балансировка линии (line balancing). Смысл всех этих требований один: убрать места, где между операциями копятся партии.
Принцип: малые партии требуют быстрой переналадки
Малые партии экономичны, только когда переналадка короткая. Если перестройка оборудования занимает часы, участок будет набирать большие партии, и JIT разобьётся о расчёт себестоимости. Поэтому сокращение времени переналадки входит в предпосылки метода, и подсказка фрейма OrgDevTools прямо об этом напоминает. Технику сокращения переналадки описывает SMED.
Принцип: поставщики — часть системы
Шестой ключевой элемент в перечне Бхарвани — вовлечение поставщиков в JIT-поставки. Фрейзер, Спекман и О'Нил показали, что JIT-обмен между OEM и поставщиком представляет собой отдельный тип отношений. У него есть условия запуска и факторы успеха или провала. Если компания перешла на малые частые партии, а поставщик работает по-старому, запас просто перемещается к нему или в грузовик.
Принцип: инфраструктура важнее отдельных приёмов
Из работы Сакакибары и коллег следует принцип, который удобно держать в голове при любом внедрении: эффект приносят не JIT-практики сами по себе, а их сочетание с окружающей системой управления. Набор карточек, ячеек и малых партий без этой среды результатов не меняет.
Принцип: люди как второй столп
Согласно статье 1977 года, JIT в Toyota шёл в паре с системой уважения к человеку. Это логически связано с вынужденным решением проблем: если запасы снижены и проблемы вскрываются ежедневно, решать их должны те, кто стоит на линии. Без вовлечения рабочих сниженный буфер превращается просто в череду остановок.
JIT убирает запас, который прятал проблемы. Дальше результат определяет одно: кто и как быстро эти проблемы решает.
Ограничения, слепые зоны и критика метода «точно вовремя»
Уязвимость к внешним сбоям. Обзорные материалы о JIT-запасах перечисляют типовые риски: задержки поставщиков, ошибка в прогнозе, которая оставляет компанию с нулевым запасом, стихийные бедствия и транспортные сбои. Там же сказано, что нужно: планы на случай непредвиденных обстоятельств (contingency plans) и стабильные партнёры-поставщики. Чем ниже буфер, тем быстрее сбой у поставщика доходит до остановки собственной линии. Если компания доводит JIT до предела и не держит резервных механизмов, она обменивает экономию на запасах на хрупкость цепочки.
Приёмы без инфраструктуры не работают. Сакакибара, Флинн и Шредер не нашли значимой связи между отдельными JIT-практиками и результатами производства. Для практики это ограничение: внедрение, сведённое к канбан-доскам и сокращению партий, скорее всего не окупится. Критика здесь направлена не против метода, а против его упрощённой версии, а именно её чаще всего и продают.
Контроль и дисциплина как побочный продукт. Грэм Сьюэлл и Барри Уилкинсон в статье «Someone to Watch Over Me» (1992) анализируют режимы JIT/TQC через понятие власти-знания Мишеля Фуко из книги «Надзирать и наказывать». Их вывод: такие режимы создают и требуют систем надзора, которые совершеннее надзора прежних фабричных режимов. Они прививают дисциплину и усиливают центральный контроль. Тактическая ответственность делегируется вниз, а стратегический контроль одновременно централизуется. Руководителю стоит это учитывать: визуальные сигналы и прозрачность потока одновременно служат инструментом самоорганизации и инструментом наблюдения, и сотрудники это замечают.
Перекладывание риска на поставщиков. Экономия на запасах часто означает, что буферная функция переходит к поставщику: он держит склад у себя, чтобы выдержать частые малые отгрузки. Если отношения не партнёрские, издержки в цепочке не исчезают, а перемещаются, иногда с наценкой. Фрейзер, Спекман и О'Нил не случайно описывают JIT-обмен как особую форму отношений с собственными условиями успеха. Требовать JIT в одностороннем порядке и называть это бережливостью нельзя.
Спор об экономии масштаба. В обзоре о применении JIT в снабжении клинических исследований разобрано типовое возражение. Малые операции приходится выполнять чаще, и критики считают, что это съедает экономию масштаба и делает JIT самым дорогим способом снабжения. Автор признаёт, что начальные накладные расходы JITM бывают выше, чем при крупносерийном выпуске. Однако с учётом сокращения отходов, возвратов и избыточных объёмов, а также экономии на курьерах, администрировании и уничтожении неиспользованной продукции метод становится выгоднее. Вывод для руководителя: экономика JIT зависит от контекста, и её надо считать по полной стоимости, а не по цене одной партии.
Расхождение в исторических пересказах. Популярные тексты почти всегда называют двумя столпами TPS JIT и дзидока. В аннотации статьи 1977 года, написанной сотрудниками Toyota, вторая отличительная черта — система уважения к человеку. Опасна не терминологическая неточность, а то, что из схемы выпадают люди: JIT начинают внедрять как техническую систему без вовлечения работников.
Размытость термина. «Just-in-time» сегодня обозначает и производственный принцип, и адаптивные медицинские вмешательства, и прогнозирование дефектов в коде, и компиляцию на лету. Когда в проекте говорят «у нас JIT», полезно уточнить, о чём речь: о вытягивании по фактическому расходу или просто о «быстро и по требованию».
Чем «точно вовремя» не является. Это не полный отказ от запасов: минимальный запас — следствие точной синхронизации, а не самоцель. Это не перенос склада к поставщику. Это не программный модуль и не складская политика, которую можно купить. Это не синоним канбана: канбан — один из механизмов реализации. И это не техника, которую можно внедрить на одном участке, не трогая планирование, качество и переналадку.
Типовые ошибки при внедрении метода «точно вовремя»
Ошибка 1: снижают запасы до стабилизации процесса.
Компания читает про «воду и камни» и спускает воду разом: режет межоперационные запасы на пилотной линии вдвое за месяц. Процесс при этом нестабилен: брак плавает, переналадка непредсказуема, оборудование отказывает. Каждый скрытый дефект теперь останавливает поток. Через несколько недель руководство делает вывод, что «JIT у нас не работает», и возвращает склад, а следующую попытку команда встречает с недоверием.
Как избежать
до снижения буфера измерьте стабильность каждого этапа: долю брака, разброс времени операций, время переналадки, отказы. Снижайте запас маленькими шагами. Следующий шаг делайте только после того, как проблема, вскрытая предыдущим, решена.
Ошибка 2: понимают JIT как ноль запасов везде.
Принцип читают буквально: запасов не должно быть нигде. Под нож одинаково попадают дешёвый крепёж и уникальный компонент от единственного поставщика с долгим сроком поставки. В результате самые рискованные позиции остаются без страховки, а экономия на них несоразмерна потерям от одной остановки.
Как избежать
разделите позиции по критичности и надёжности снабжения. Устраняйте избыточный запас, который прячет внутренние проблемы. Обоснованный буфер оставляйте там, где риск внешний и быстро его не устранить. Пересматривайте это решение по мере того, как цепочка становится надёжнее.
Ошибка 3: требуют JIT от поставщиков, не меняя отношений.
Закупки рассылают поставщикам требование возить малыми партиями точно к сроку и грозят штрафами. Поставщики продолжают выпускать крупными партиями, а разницу держат на складе и закладывают в цену. Координационные издержки растут, гибкость не появляется, буфер просто переехал за забор.
Как избежать
относитесь к JIT-поставкам как к отдельному типу отношений. Определите условия запуска, обменивайтесь прогнозами и графиком, начинайте с поставщиков, готовых синхронизироваться. Работа Фрейзера, Спекмана и О'Нила полезна как напоминание, что у таких отношений есть факторы успеха и провала.
Ошибка 4: внедряют приёмы без инфраструктуры.
Появляются канбан-карточки и супермаркеты, но планирование продолжает толкать заказы по месячному плану. Качество по-прежнему проверяют в конце, а люди не участвуют в решении проблем. Формально JIT-практики есть, результатов нет. Это ровно то, что показали Сакакибара, Флинн и Шредер: практики сами по себе значимо не связаны с результатами.
Как избежать
планируйте внедрение как изменение системы управления. Вместе с сигналом пополнения меняйте правила планирования, контроль качества на месте и порядок реакции на проблемы. Метрики оценивайте по всему потоку, а не по факту появления карточек.
Ошибка 5: вскрывают проблемы, но не решают их.
Буфер снизили, проблемы проступили, и их записывают в журнал, который никто не разбирает. Линия живёт в режиме постоянных остановок, люди устают и начинают тайком держать «свои» запасы под верстаком. Формально запасы низкие, фактически они ушли в тень.
Как избежать
за каждой вскрытой проблемой закрепляйте владельца и срок. Не снижайте буфер дальше, пока открытые проблемы предыдущего шага не закрыты. Регулярно сверяйте фактические запасы на участке с учётными, в том числе неофициальные.
Ошибка 6: забывают о выравнивании графика.
Сборка выпускает модели большими блоками, и потребление деталей скачет от нуля до пика. Предыдущие участки и поставщики видят этот «хлыст» и страхуются запасами. Сколько бы карточек ни висело, вытягивание не работает, потому что сигнал потребления рваный.
Как избежать
выровняйте график выпуска до запуска вытягивания. Цель, по Милтенбургу, — постоянный темп потребления каждой детали. Смешивайте модели в коротком цикле и держите ровный производственный ритм.
План внедрения метода «точно вовремя»
Месяц 1: карта запасов и стабильности. Выберите пилотный поток с понятным потребителем. Пройдите его на месте и нанесите на карту все места, где лежит незавершёнка и материалы, с количеством и возрастом запаса. Удобная основа — картирование потока создания ценности (VSM). Для каждого этапа зафиксируйте долю брака, разброс времени операции, время переналадки и частоту отказов. Результат месяца — карта и список этапов, где запас прикрывает конкретную нестабильность.
Месяц 2: предпосылки и риски цепочки. Займитесь узкими местами стабильности: самыми долгими переналадками, самыми частыми видами брака, самыми ненадёжными единицами оборудования. Выровняйте график выпуска на пилотном потоке, чтобы детали потреблялись ровно. Параллельно разделите закупаемые позиции на три группы: можно переводить на JIT сразу; можно после работы с поставщиком; нужен обоснованный буфер из-за внешнего риска. Для третьей группы запишите, что именно должно измениться, чтобы буфер можно было снизить.
Месяц 3: сигнальный механизм пополнения. Спроектируйте сигнал, по которому этап-поставщик начинает выпуск: карточку, пустую тару, отметку на доске. Определите стартовое количество сигналов с запасом относительно текущей стабильности. Начинать с минимума не нужно. Пропишите правила: без сигнала не производить; сигнал не задерживать; при отклонении останавливаться и звать ответственного. Запустите вытягивание на пилоте и проверьте, что планирование больше не толкает заказы на этот участок в обход сигнала.
Месяц 4: постепенное снижение буфера с журналом проблем. Снижайте число сигналов или размер буфера маленькими шагами. После каждого шага выжидайте, пока поток не покажет, что вскрылось. Каждую вскрытую проблему заносите в журнал с владельцем и сроком. Следующий шаг делайте только после закрытия проблем предыдущего. Контролируйте время протекания, запасы по потоку, число остановок и неофициальные запасы.
Месяц 5: поставщики и закрепление. Пригласите одного-двух поставщиков из первой и второй групп к синхронизации. Договоритесь о частоте, размере партии, обмене графиком и порядке действий при сбое. Опишите в стандарте, как пилот работает сейчас, и подведите итоги: что изменилось в запасах, времени протекания и качестве, какие проблемы закрыты, какие остаются.
Далее: поддержание и обновление. Тиражируйте метод на соседние потоки только при достигнутой стабильности. Раз в квартал пересматривайте список позиций с обоснованным буфером: часть из них можно переводить на вытягивание по мере роста надёжности. Держите на виду план на случай сбоя внешней цепочки и проверяйте его хотя бы на бумаге.
Хороший признак внедрения — уровень запаса снижается, а число открытых проблем в журнале не растёт.
Как реализовать этот план с помощью фрейма «Точно вовремя (JIT)» в OrgDevTools
Фрейм «Точно вовремя (JIT)» — бесплатный тренажёр. Он ведёт пилот от карты запасов к пошаговому снижению буфера. Фрейм сам считает покрытие запаса в днях, число канбан-сигналов и запас сверх расчётного уровня, а журнал снижений проверяет на главное правило JIT: не опускать уровень воды, пока не убран вскрывшийся камень. Отдельного Инструмента OrgDevTools с этим фреймом пока нет, методика использует его в режиме тренажёра.
Вкладка «1. Карта запасов» — месяц 1: карта запасов и стабильности
Это таблица, которая изначально пуста. Позиции добавляются кнопкой «+ добавить позицию». Для каждой позиции заполняются поля:
этап или позиция;
количество;
фактический расход в день;
возраст самой старой партии в днях;
проблема, которую прикрывает запас;
критичность: «Критичная (остановка клиента)», «Средняя» (стоит по умолчанию) или «Некритичная».
Покрытие в днях фрейм считает сам: количество делится на расход. Покрытие больше 3 дней подсвечивается красным, это рабочая настройка фрейма. Строки без названия в расчёты не попадают.
Вкладка «2. Канбан-сигналы» — месяц 3: сигнальный механизм пополнения
Для каждой позиции из карты вводятся время пополнения в днях, вместимость контейнера и страховка в процентах. По умолчанию страховка равна 10%, это рабочая настройка фрейма. Число карточек считается по формуле: расход × пополнение × (1 + страховка) ÷ контейнер, с округлением вверх. Расчётный уровень равен произведению карточек на контейнер. Всё, что лежит сверх него, фрейм показывает как лишний запас: красным, если он больше нуля, и зелёным, если его нет.
Вкладка «3. Снижение буфера» — месяц 4: постепенное снижение с журналом проблем
Журнал состоит из шагов. В каждом шаге есть дата (по умолчанию сегодняшняя), позиция из карты, значения «было → стало», вскрытая проблема и флажок «закрыта». Шаги сортируются по дате. Если по позиции сделан следующий шаг, а проблема предыдущего ещё открыта, этот шаг подсвечивается красным.
Вкладка «4. Предпосылки и план» — месяцы 2 и 5: предпосылки, поставщики, закрепление
На вкладке четыре свободных списка:
какой сигнал фактического расхода запускает производство на каждом этапе;
какие «камни» уже обнажились;
что должно быть стабильно до снижения буфера (качество, переналадка, поставщики);
план пилота: петля, ответственные, сроки.
Записи из прежней версии фрейма сохранены.
Вкладка «Визуализация» — контроль месяцев 4–5
По каждой позиции рисуется полоса фактического запаса с чёрной меткой расчётного уровня. Полоса красная, если запас выше расчётного, и зелёная, если нет. Цвет названия позиции соответствует её критичности. Внизу выводятся итоги: всего в запасах, сверх расчёта и снижено по журналу (сумма «было − стало»).
Вкладка «Итоги»
Вердикт строится по первой сработавшей проверке:
Карта пуста: фрейм предлагает начать с картирования.
У какой-то позиции не указан расход в день.
Покрытие больше 1 дня, но не названа прикрываемая проблема. Проверка идёт с позиции с наибольшим покрытием, порог в 1 день — рабочая настройка фрейма.
Не хватает данных для расчёта карточек.
Буфер снижен дальше при незакрытой проблеме: красный сигнал.
Снижается критичная позиция, хотя у некритичных ещё есть запас сверх расчёта.
Шагов снижения ещё нет: фрейм называет общий излишек и предлагает первую позицию. Это некритичная позиция с наибольшим излишком.
Есть открытые проблемы: следующий шаг только после их закрытия.
Всё закрыто: фрейм подводит итог снижения и показывает остаток сверх расчёта.
Под вердиктом выводится список открытых проблем. Если фрейм привязан к документу, кнопка «Создать задачу» ставит задачу «JIT: закрыть проблемы, вскрытые снижением запаса», когда есть открытые проблемы, и «JIT: следующий шаг снижения буфера», когда их нет. В описание задачи попадают вердикт и список проблем.
Чего фрейм не делает
Не собирает показатели стабильности этапов: брак, разброс времени операций, переналадку, отказы. Вердикт может предложить первый шаг снижения, не зная, стабилен ли процесс.
Возраст запаса только записывается и в расчётах не участвует.
Не обновляет количество в карте по журналу и не сверяет «было» с фактическим запасом.
Не делит закупаемые позиции на три группы из месяца 2. У него есть только шкала критичности.
Не считает такт и время протекания, не строит карту потока и график динамики во времени.
Не проверяет, действительно ли закрыта проблема, отмеченная флажком.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги по теме метода «точно вовремя»
Тайити Оно — «Производственная система Тойоты: уходя от массового производства» (1978). Описание системы её архитектором: JIT как основа TPS и канбан как механизм вытягивания, на которые опираются раздел о происхождении и принципы вытягивания и минимизации запасов.
Грегор Новак, Эндрю Гаврин, Вольфганг Кристиан — «Just-In-Time Teaching: Blending Active Learning with Web Technology» (1999). Пример переноса логики «точно вовремя» в преподавание: подготовка занятия опирается на предварительные задания (WarmUps), то есть на фактическую потребность аудитории. Использована в разделе о переносе метода за пределы цеха.