«Не успели» — это сигнал, но ещё не причина
Когда недельная работа не завершена, команда часто ограничивается короткой записью: «не успели», «не было материала», «не хватило людей». Такая формулировка помогает закрыть протокол, но не помогает изменить процесс. Через неделю похожий срыв повторяется, а руководитель снова узнаёт о нём постфактум.
Я предлагаю фиксировать невыполнение через RNC. В контексте Last Planner System сокращение RNC обычно расшифровывают как Reasons for Non-Completion — причины невыполнения недельных обязательств. В актуальных материалах Lean Construction Institute этот шаг также называется Reasons for Variance: команда сопоставляет обещанное и фактическое выполнение, а затем использует данные для обучения и улучшения следующего цикла планирования.
Важно не смешивать этот процесс с NCR — Non-Conformance Report, то есть отчётом о несоответствии требованиям качества. NCR фиксирует дефект или нарушение требования и запускает установленную процедуру качества. RNC в этой статье отвечает на другой вопрос: почему конкретное обязательство недельного плана не было выполнено полностью и в согласованный срок. Если причиной невыполнения стал дефект, у записи RNC может быть ссылка на NCR, но один документ не заменяет другой.
В моей системе управления я использую RNC как связку из четырёх элементов: факт отклонения, категория причины, связь с обязательством и дальнейшее действие. Цель не в поиске виновного, а в том, чтобы проект сохранил память о сбоях и перестал повторять их под разными формулировками.
Когда создавать запись RNC
Запись нужна, если обещанный результат недельного плана не достигнут полностью к согласованному времени или не соответствует заранее принятому критерию завершения. Частичное выполнение не следует задним числом превращать в выполненное обязательство: это искажает надёжность планирования и скрывает незавершённую передачу следующему участнику.
Lean Construction Institute определяет Weekly Work Plan как уровень обещаний команды, а PPC — как долю назначений, выполненных на 100% в запланированный срок. Поэтому RNC логично создавать при недельном разборе одновременно с проверкой выполнения. Сначала фиксируем «что обещали» и «что получили», затем разбираем причину. Не наоборот.
RNC не нужен для каждой мелкой пометки в течение дня. Если блокер выявлен до срыва и его ещё можно снять, его ведут как ограничение. Для этого на сайте уже опубликован разбор Constraints Log. Если же обязательство не выполнено, факт становится частью RNC, а незакрытое препятствие при необходимости переносится в журнал ограничений на следующую работу.
Факт, причина, коренная причина и действие — разные поля
Большинство слабых записей появляется из-за смешения четырёх уровней. Факт отвечает на вопрос «что произошло». Непосредственная причина объясняет, какое условие сорвало выполнение. Коренная причина показывает, почему система допустила повторение. Действие определяет, что команда сделает и как проверит результат.
| Слабая запись | Рабочая формулировка |
|---|---|
| Не успели | Обязательство не выполнено: из 120 м лотка смонтировано и принято 80 м; 40 м не переданы следующей работе к четвергу 16:00. |
| Не было материала | К началу смены не было крепежа указанного типа. Нужно установить: когда сформирована заявка, когда подтверждена комплектация, что фактически выдано и где возник разрыв. |
| Не хватило людей | Планировали 6 монтажников, фактически работали 4. Нужно подтвердить, почему изменился состав, кто знал об этом до обещания и можно ли было скорректировать объём заранее. |
| Смежники задержали | Фронт в зоне Б не передан по принятому критерию. Указать конкретную предшествующую работу, дату передачи, отсутствующий результат и владельца следующего действия. |
Не каждую причину удаётся установить на недельном совещании. В этом случае честная запись «предварительная причина, требуется подтверждение» полезнее уверенного предположения. Назначьте, кто и к какой дате проверит документы, остатки, переписку или фактическую последовательность работ.
Какие поля должна содержать карточка RNC
Минимальная карточка должна позволять вернуться к исходному обещанию и проследить, что произошло после разбора. Я рекомендую следующие поля:
- идентификатор обязательства, неделя и дата проверки;
- работа, зона, исполнитель и согласованный результат;
- критерий завершения и обещанный срок;
- фактический результат на момент проверки;
- непосредственная причина и статус её подтверждения;
- категория причины для последующей группировки;
- ссылка на доказательство: запись журнала, акт передачи, заявка, версия документа, фото или другой допустимый источник;
- следующее действие, владелец, срок и признак выполнения;
- метка повторения и ссылка на Constraints Log, NCR, A3 или другой связанный разбор, если он нужен.
Категории удобно задать заранее: документация и решения; материалы; люди; техника; фронт и предшествующие работы; качество и приёмка; координация; внешние условия; ошибка планирования. Но категория не заменяет описание. Запись «материалы» позволяет построить диаграмму, а запись «не выдан крепёж М8 для зоны Б; заявка подтверждена частично» позволяет действовать.
Порядок разбора RNC на недельной встрече
- Сверьте каждое обязательство с критерием завершения. Выполнено только то, что завершено полностью в обещанный срок и принято по согласованному правилу.
- Для каждого невыполненного обязательства зафиксируйте факт без оценки и оправдания: обещание, срок, зона, полученный результат и недостающая часть.
- Запишите непосредственную причину. Если она не подтверждена, пометьте это и определите, какие факты нужно собрать.
- Выберите категорию причины. Используйте один справочник на проекте, иначе одинаковые сбои разойдутся по названиям «поставка», «снабжение» и «нет материала».
- Назначьте дальнейшее действие. В записи должны быть владелец, срок и проверяемый результат, а не поручение «разобраться».
- Определите маршрут. Текущее препятствие внесите в Constraints Log; дефект качества свяжите с NCR; повторяющуюся системную проблему направьте в «5 почему», A3 или Kaizen Event.
- После нескольких сопоставимых недель посмотрите повторяемость категорий и формулировок. Один случай ещё не доказывает системную причину, а серия подтверждённых случаев уже задаёт вопрос к процессу.
Такой разбор не должен превращаться в длинное расследование всей стройки. На общей встрече достаточно зафиксировать факт, известную причину и владельца следующего шага. Отдельный анализ проводят с теми, кто может предоставить данные и изменить процесс.
Условный пример: вместо «не хватило крепежа»
Рассмотрим учебную ситуацию, не связанную с конкретным объектом. В недельном плане записано обязательство: «до четверга 16:00 смонтировать и предъявить 120 м кабельного лотка на третьем этаже, зона Б». Критерий завершения — весь объём смонтирован, крепления проверены, результат принят ответственным участником.
На проверке установлено: смонтировано и принято 80 м, оставшиеся 40 м не завершены. Для PPC это обязательство не выполнено, даже если физически выполнена большая часть объёма. Формулировка «не хватило крепежа» пока остаётся только первым объяснением.
| Поле RNC | Запись в учебном примере |
|---|---|
| Обязательство | 120 м кабельного лотка, 3-й этаж, зона Б; предъявить до четверга 16:00. |
| Факт | 80 м смонтировано и принято; 40 м не завершены и не переданы следующему участнику. |
| Предварительная причина | К началу второй смены отсутствовал крепёж М8. Причина дефицита не подтверждена. |
| Что проверить | Ведомость потребности, дату и состав заявки, подтверждение комплектации, фактическую выдачу со склада, расход и возможную передачу крепежа в другую зону. |
| Действие | Сопоставить потребность, заявку, выдачу и фактический расход; подтвердить разрыв документами и осмотром. |
| Владелец и срок | Прораб и представитель снабжения; согласованный срок проверки указывается в карточке. |
| Следующий маршрут | Если дефицит угрожает следующей зоне — открыть ограничение. Если повторяется ошибка комплектации — провести отдельный анализ причины и проверить контрмеру. |
После проверки может оказаться, что поставщик привёз неполный комплект, заявка была сформирована по старой ведомости, часть крепежа выдали другой бригаде или фактический расход изменился после корректировки решения. Пока доказательств нет, нельзя объявлять один из вариантов коренной причиной и тем более приписывать улучшению экономический эффект.
Сила RNC здесь не в красивой карточке. Она в том, что команда сохраняет цепочку «обещание — факт — проверяемая причина — действие» и может увидеть повторение. Если через две недели снова появляется тот же разрыв комплектации, у руководителя уже есть не набор жалоб, а сопоставимые записи для анализа процесса.
Как начать без отдельного приложения
На дату проверки отдельный публичный инструмент RNC на сайте не размещён. Начать можно с общей таблицы, связанной с недельным планом. Это лучше, чем ждать автоматизации. В опубликованном Weekly уже можно формулировать обязательства так, чтобы их однозначно проверить; в Constraints Log — вести препятствия, которые ещё можно снять до срыва.
Полезные переходы: недельный план Weekly ↗ → журнал ограничений Constraints Log ↗ → Kaizen Event для повторяющегося сбоя ↗. Каталог действующих материалов и инструментов: olegzolotukhin.ru/materialy/ ↗.
Если затем появится Mini App RNC, его нужно использовать как продолжение процесса, а не как замену разговора. Приложение должно сохранять связь с исходным обязательством, различать подтверждённую и предварительную причину, поддерживать владельца действия и позволять увидеть повторяемость. Без этих правил цифровой реестр быстро превратится в архив одинаковых записей «не успели».
Типичные ошибки
- Исправлять недельный план задним числом, чтобы невыполнение исчезло из статистики.
- Считать частично выполненную работу выполненным обязательством, хотя следующий участник не получил обещанный результат.
- Записывать виновного вместо причины: «подрядчик подвёл», «снабжение не сработало».
- Сразу называть коренную причину без проверки заявки, версии документа, фактической выдачи или передачи фронта.
- Ограничиваться категорией причины и не назначать проверяемое действие.
- Разбирать все RNC на общем совещании до мельчайших деталей и терять рабочий темп встречи.
- Смешивать RNC причин невыполнения с NCR по качеству и нарушать установленный порядок работы с несоответствиями.
Проверка запуска на одном участке
Для первого цикла достаточно одного участка и одной недели:
- Согласуйте критерии завершения для всех записей Weekly.
- Создавайте RNC только по фактически невыполненным обязательствам.
- Используйте единый список категорий и обязательное поле «что нужно подтвердить».
- Не закрывайте запись без владельца следующего действия и проверяемого результата.
- В конце нескольких недель сгруппируйте повторения, но не делайте вывод по одному случаю.
- Выберите одну повторяющуюся проблему для более глубокого анализа и отдельно проверьте действие контрмеры.
RNC полезен не количеством заполненных строк. Он полезен, когда помогает команде точнее обещать, раньше видеть условия срыва и менять процесс на основании фактов. Именно так запись о невыполнении становится инструментом обучения проекта, а не очередным отчётом о прошлом.
Восстанавливаем цепочку события
Разбор RNC начинается с зафиксированного недельного обещания. Сначала команда сверяет, что было обещано, к какой дате и по какому критерию результат должен был быть принят. Затем записывает фактический объём и состояние передачи. Только после этого имеет смысл обсуждать, почему обещание не выполнено. Иначе разговор быстро превращается в соревнование объяснений, а исходные условия остаются неясными.
В учебном примере с кабельным лотком недостаточно сказать, что отсутствовал крепёж. Нужно проверить, когда возникла потребность, кто её передал, что было в заявке, когда подтвердили комплектность и что реально пришло к месту монтажа. Если на складе крепёж был, но комплект выдачи не учитывал фактическую схему узла, причина может лежать в подготовке задания. Если заявка поступила после планирования недели, нужно вернуться к правилу проверки готовности.
Одно событие может иметь несколько связанных причин. Для RNC важен ближайший проверяемый механизм срыва и действие, которое можно испытать на следующем цикле. Не стоит присваивать «коренную причину» без данных. Пометка «гипотеза» сохраняет честность записи и задаёт вопрос для проверки на месте.
| Этап | Доказательство | Если данных нет |
|---|---|---|
| Обещание | Базовая строка Weekly и критерий передачи | Восстановить исходную запись |
| Факт | Принятый объём и время проверки | Сверить с исполнителем и принимающим |
| Событие | Что именно остановило работу | Проверить место и документы |
| Причина | Подтверждённая цепочка до события | Оставить гипотезу открытой |
| Контрмера | Владелец, срок и критерий проверки | Назначить отдельный разбор |
Классификация помогает увидеть повторение
Категория нужна для сравнения нескольких недель, но она не заменяет описание факта. Если написать только «материалы», никто не поймёт, отсутствовал ли заказ, поставка, комплект на складе или выдача на фронт. В одной и той же категории могут быть совершенно разные управленческие решения. Сначала формулируйте событие, затем выбирайте метку, которая поможет найти похожие случаи.
Категории ниже — удобная рабочая группировка, а не нормативный перечень. Команда может адаптировать её к своим видам работ, сохраняя одинаковый смысл меток на протяжении нескольких циклов. Когда записи сравнимы, становится видно, где повторяется сбой: в подготовке проекта, межподрядной передаче, поставке или завышенном обязательстве.
| Категория | Проверочный вопрос |
|---|---|
| Проектное решение | Была ли актуальная согласованная информация до включения работы? |
| Предшествующий фронт | Была ли принята работа, от которой зависит старт? |
| Материалы | Был ли фактически доступен нужный комплект у места работы? |
| Люди и техника | Были ли подтверждены бригада, оборудование и окно использования? |
| Координация | Не столкнулись ли работы и доступы разных участников? |
| Качество обещания | Можно ли было выполнить объём при известной готовности и ресурсе? |
Что можно сделать в действующей цифровой форме
Отдельный публичный инструмент RNC на сайте не подтверждён. Уже сейчас факт и ближайшую причину можно записать в действующей форме Weekly и PPC: откройте обещание, выберите статус недели и заполните поле «Факт и причина отклонения». На снимке показано именно это поле. Оно не является полноценным журналом анализа коренной причины, поэтому для сложного случая полезно вести расширенную таблицу ниже и связать её с исходной строкой недели.
Перед записью убедитесь, что базовый недельный план был зафиксирован. Поздняя, частичная или отменённая работа остаётся в знаменателе PPC; её нельзя удалять ради красивого процента. В текстовом поле укажите конкретный факт, первичную причину или гипотезу и следующее действие. Не смешивайте подтверждённый факт с предположением: если данных пока нет, напишите, что именно проверят и когда.
Сохраните изменения, проверьте сводку PPC и откройте строку снова. Для резервной копии используйте «JSON», для восстановления — «Импорт», для бумажного разбора — «Печать». Данные формы хранятся в текущем браузере. Отдельный файл с RNC нужно именовать по объекту и периоду, чтобы команда не обсуждала устаревшую версию.
| Рисунок 1. Действующая форма Weekly: статус и факт с причиной отклонения | Рисунок 2. Базовый план сохраняет знаменатель PPC при разборе причин |
|---|
Рабочая карточка для отдельного разбора
Если одна строка Weekly не вмещает всю цепочку, вынесите случай в отдельную карточку. В ней достаточно оставить связь с обещанием, фактический результат, подтверждённые данные, открытые вопросы, решение и проверку. Карточка не должна превращаться в поиск виновного: задача — изменить способ подготовки следующего обещания или снятия препятствия.
На следующей недельной встрече проверяйте не наличие заполненной формы, а действие контрмеры. Если после изменения порядка комплектования похожая остановка повторилась, ищите пропущенное условие. Если остановка исчезла в одной смене, наблюдайте ещё один сопоставимый цикл прежде, чем считать порядок устойчивым.
| Поле карточки | Как заполнить без догадки |
|---|---|
| Ссылка на обещание | Номер недели, участок, работа и обещанный срок |
| Факт | Принятый результат, остаток и время проверки |
| Подтверждённые данные | Накладная, заявка, запись приёмки или наблюдение |
| Гипотеза | Что пока предполагается и как проверить |
| Действие | Изменение порядка, владелец и срок |
| Проверка | Где и на какой следующей работе смотреть результат |
Проверяем действие на следующей неделе
Запись RNC не заканчивается выбором категории. После разбора команда назначает одно изменение порядка и заранее определяет, на какой следующей работе увидит его результат. В примере с крепежом это может быть сверка комплекта до фиксации недельного обещания и повторная проверка у места монтажа в день начала. Если условия следующей работы иные, сравнение надо делать осторожно и описывать различие.
На следующем разборе полезно вернуть исходную карточку на экран. Сначала проверить, выполнили ли согласованное действие, затем — повторилась ли остановка. Отсутствие остановки в одном эпизоде ещё не доказывает устойчивого улучшения. Но если не было даже проверки действия, новая классификация причин не даст управленческого эффекта. Поэтому владелец и дата контрольной проверки нужны в каждой рабочей карточке.
Для руководителя важен не общий рейтинг категорий, а повторяемость конкретного механизма срыва. Три записи «материалы» могут требовать трёх разных решений. Группировку используют как указатель, где читать подробности, а не как готовый диагноз.
| Шаг | Действие | Признак завершения |
|---|---|---|
| Изменить порядок | Назначить проверку комплекта до принятия обещания | Есть согласованное правило и владелец |
| Испытать | Применить правило на следующей сопоставимой работе | Результат зафиксирован на месте |
| Сверить | Сравнить причину нового отклонения с исходной | Карточка обновлена фактами |
| Закрепить | Сохранить работающий порядок или изменить гипотезу | Решение принято на данных |
Три вопроса перед закрытием причины
Первый вопрос: отделили ли мы факт от объяснения? Запись «подрядчик плохо организовал работу» не показывает, какое событие сорвало обещание. В рабочей карточке следует назвать исходную задачу, обещанный результат и срок, фактическое состояние к сроку и то, что наблюдалось на месте. Слова участника полезны как свидетельство, но сами по себе ещё не подтверждают причину. Если документы, поставка и готовность фронта влияли одновременно, не стоит насильно выбирать одну удобную категорию: сначала восстановите последовательность событий.
Второй вопрос: кто может изменить условие, из-за которого работа остановилась? Исполнитель может сообщить об отсутствии комплекта, но не всегда вправе изменить график поставки или утвердить замену. Владелец контрмеры должен иметь полномочия и срок. Если решение зависит от заказчика, проектировщика или службы снабжения, в записи указывают конкретный запрос, адресата и точку проверки ответа. Формальное назначение ответственности без права решить вопрос оставляет ограничение открытым.
Третий вопрос: как мы узнаем, что причина действительно устранена? Закрытие по отправленному письму или состоявшемуся совещанию слишком рано. Проверка должна происходить на следующей сопоставимой работе: нужный комплект поступил до выхода бригады, действующая версия документа доступна на месте, принимающая сторона подтвердила фронт. Если остановка повторилась, карточку открывают вновь и уточняют гипотезу. Так RNC становится частью подготовки следующего обещания, а не архивом оправданий.
| Проверка | Недостаточная запись | Рабочая запись |
|---|---|---|
| Факт | «Не успели из-за снабжения» | Какой комплект, где и когда отсутствовал |
| Действие | «Усилить контроль поставок» | Кто сверит комплект и к какому часу |
| Эффект | «Вопрос закрыт» | Где и когда проверена следующая работа |
Проверенные ссылки для работы
Форма Weekly и PPC с полем причины отклонения ↗
Схема применения
Схема автора. Последовательность для проверки на одном участке, без заявленного результата.
Как проверить результат применения
Результат разбора RNC проверяем на следующей сопоставимой работе. Сохраняем исходную частоту повторения причины, срок снятия ограничения и дату проверки контрмеры. На следующей недельной встрече сопоставляем не только число карточек, но и условия выполнения новых обещаний.
Если причина перестала повторяться на одной неделе, это обнадёживающий сигнал, а не доказательство устойчивого улучшения. Повторное возникновение требует пересмотра гипотезы или меры; закрывать запись по факту проведённого совещания нельзя.
Темы выступлений и связь с автором ↗
Источники и проверенные материалы
［4］ Олег Золотухин. Недельный план строительства: как составить Weekly Work Plan. ↗
［5］ Олег Золотухин. Журнал ограничений в строительстве и порядок работы с Constraints Log. ↗
Источники и состояние каталога сайта повторно проверены 22 октября 2026 года.