Kaizen Event в строительстве: как провести сессию улучшения процесса
Как провести Kaizen Event на стройке: подготовка команды, разбор процесса, тест и проверка результата. Отдельно — как вести кайдзен-предложения в реестре.
На стройке можно провести несколько совещаний, согласовать новый порядок и всё равно вернуться к прежним задержкам через неделю. Чаще всего проблема не в отсутствии идей. Команда не зафиксировала исходное состояние процесса, не проверила изменение на реальной работе или не договорилась, кто поддерживает новый порядок после встречи.
Kaizen Event помогает пройти этот путь вместе: выбрать один повторяющийся процесс, увидеть его фактическое состояние, испытать изменение и решить по измеренному результату, стоит ли закреплять его. В статье я разбираю строительный пример согласования изменения узла и порядок проведения Kaizen Event. Опубликованный инструмент «Кайдзен» служит для учёта отдельных предложений и проверки их эффекта; само мероприятие он не проводит. Пример учебный: даты и числа ниже показывают способ проверки, а не результат реального объекта.
Кайдзен-предложение и Kaizen Event — разные формы работы. Предложение фиксирует конкретную идею улучшения, её автора, ответственное лицо, решение и результат. Kaizen Event — организованное командное событие, во время которого участники вместе исследуют проблему процесса, испытывают изменение и договариваются, как закрепить проверенное решение. По итогам события может появиться несколько предложений, но запись в реестре не заменяет само событие.
Реестр кайдзен-предложений
Здесь можно записать идеи, возникшие во время Kaizen Event, и проследить выполнение. Это инструмент учёта предложений, а не проведения самого события.
Под Kaizen Event я понимаю организованную работу команды над ограниченной проблемой процесса. Это не конкурс предложений и не собрание с общим призывом «ускориться». Участники сначала договариваются, какую проблему наблюдают, затем проверяют причины на месте работы и предлагают изменения, которые можно испытать без подмены обязательных требований к безопасности, качеству и оформлению результата.
Lean Construction Institute описывает такой формат как совместную работу затронутых участников над изменениями процесса; в зависимости от масштаба она может занимать несколько дней. Для отдельной строительной задачи разумно начать с короткого тестового прохода и заранее назначенной повторной проверки. Длительность встречи сама по себе не показатель пользы.
В производстве работ полезность такого разбора особенно видна на передачах между участниками. Каждое подразделение может выполнять свою часть добросовестно, но общий результат всё равно запаздывает: следующему исполнителю не хватает чертежа, решения, подтверждения качества или свободного фронта. Совместный разбор переносит внимание с поиска виновного на устройство процесса и делает видимыми условия, без которых работа не может двигаться дальше.
Когда сессия действительно нужна
Если вопрос единичный и у него уже есть известный ответственный, обычно достаточно действия в журнале ограничений. Kaizen Event полезен там, где одна и та же потеря повторяется в разных сменах, бригадах или комплектностях и устранение требует совместного изменения порядка работы. Например, исполнительная документация систематически возвращается из проверки; разные подразделения применяют разные правила именования, а замечание переходит из проекта в проект.
Выберите узкую границу процесса: от возникновения вопроса по конкретному узлу до передачи утверждённого решения исполнителю. Не пытайтесь одновременно изменить снабжение, проектирование и всю систему переписки компании. Слишком широкий охват не даёт проверить, какое действие помогло. Граница должна включать вход, выход и получателя результата: кому именно нужен ответ, в какой форме и к какому моменту.
Перед встречей сформулируйте наблюдаемую проблему без диагноза. «Согласование идёт долго» оставляет много толкований. Полезнее записать: «По десяти последним запросам по узлам фасада у шести отсутствовал комплект исходных данных; возвращение на доработку обнаруживалось после передачи проектировщику». Это учебный пример записи, а не статистика объекта. Реальные десять запросов и причины нужно проверить по журналу.
Как договориться о результате
Вопрос
Что фиксируем
Где возникает потеря?
Участок, вид запроса, момент возвращения и следующий исполнитель.
Что считается успехом?
Доля комплектных запросов с первого раза и время до принятого решения.
Что нельзя ухудшить?
Полноту проверки, безопасность, качество решения и обязательные согласования.
Кто принимает изменение?
Владелец процесса и принимающая сторона, а не только ведущий сессии.
Не назначайте цель вроде «сократить срок вдвое» без исходных замеров и проверки необходимых выдержек. Лучше определить способ измерения заранее и после теста обсудить, изменился ли процесс, а не только среднее число в красивом отчёте.
Есть ещё один полезный критерий выбора. Если предлагаемый порядок можно вернуть назад после короткой проверки, его легче испытать без лишнего риска. Если изменение влияет на проектные решения, договорные обязанности или обязательный контроль, понадобится отдельное согласование с уполномоченными сторонами. Kaizen Event не заменяет ни проектную документацию, ни установленный порядок её изменения.
Подготовка команды и исходных данных
Нужны люди, через чьи руки проходит работа: инициатор запроса, производитель работ, проектировщик или технический специалист, тот, кто проверяет комплектность и принимает решение. Если причина связана с поставкой или полномочиями заказчика, пригласите соответствующего участника. Нельзя принять устойчивое правило за отсутствующую сторону и потом назвать его общей договорённостью.
Соберите несколько реальных случаев за сопоставимый период. Для каждого восстановите дату и комплект входных данных, момент первого просмотра, возвраты, уточнения и дату принятого решения. Отделите рабочее время от ожидания ответа. Если в журнале нет этих отметок, не подставляйте усреднённые значения: отметьте пробел и договоритесь о кратком периоде наблюдения.
Осмотрите фактический путь одного запроса вместе с участниками. Официальный регламент может требовать одно, а рабочая переписка показывать другое. Важно услышать исполнителя, который каждый день отправляет пакет, и специалиста, который его принимает: они чаще других знают, в каком поле или документе запрос становится неполным.
Участник
Что должен подтвердить
Руководитель процесса
Границы задачи, допустимость теста, решение по новому порядку.
Исполнитель
Как собирается пакет сегодня и какой шаг создаёт ожидание.
Принимающая сторона
Какие данные нужны для первого содержательного решения.
Ведущий
Один общий вариант карты процесса, список гипотез и срок проверки.
Ответственный за замер
Единый способ считать время и возвраты до и после изменения.
Заранее назначьте не только ведущего, но и владельца последующего действия. Иначе полезная идея останется на фотографии доски. Для строительного участка важно также определить, кто подтверждает, что новый порядок применим к другим типам работ: успешный тест одного узла не делает правило универсальным.
Для встречи подготовьте одно место, где участники одновременно видят путь работы и спорные участки: доску, экран или лист с общей картой. Если данные лежат в разных переписках, попросите ответственных принести исходные записи, а не пересказ по памяти. Уточните, какие материалы можно показывать участникам с учётом договорных ограничений, и не включайте в учебные примеры сведения реального заказчика без разрешения.
Как провести разбор и выбрать изменение
Начните с построения простой карты фактического пути: кто создаёт запрос, кто проверяет вход, где ожидание, кому возвращается неполный пакет и кто принимает решение. Укажите не только формальные этапы, но и передачу результата между людьми. На схеме ниже показан ход самой сессии; карта конкретного процесса в каждом проекте будет иной.
Рисунок 1. Авторская схема Kaizen Event: от наблюдаемого факта до проверенного нового порядка.
После карты спросите, почему возникает повторяющийся возврат. Возможные причины различаются: в форме запроса нет обязательного поля, срок ответа не согласован, проектировщик получает устаревшую редакцию или проверяющий не видит приложенный чертёж. Не принимайте первую удобную версию как установленный факт. Сверьте её с несколькими случаями и с человеком, выполняющим работу.
Выберите изменение, которое устраняет проверенную причину и не переносит проблему на соседний участок. В учебном примере команда могла бы согласовать единый состав пакета: номер и редакция чертежа, место на объекте, фотография, суть расхождения, желаемая дата решения и ответственный за передачу. Такой перечень остаётся гипотезой, пока принимающая сторона не подтвердит, что он достаточен именно для этого вида запроса.
В конце сессии нужен не перечень идей, а одно проверяемое решение: какой пакет попробуем, на каких запросах, кто вносит данные, кто проверяет комплектность до отправки, какую метрику и когда сравним. Остальные идеи можно сохранить в реестре, но их статус должен быть понятен.
Ведущий должен оставлять место для несогласия. Если прораб считает, что новый шаблон добавит ему работу, а инженер ПТО ожидает уменьшения возвратов, проверьте обе стороны на одном реальном запросе. Возможно, часть данных уже существует в журнале и её нужно передавать автоматически, а не вводить повторно. Такое испытание полезнее голосования за наиболее привлекательную схему.
Учебный пример согласования изменения узла
Давайте предположим, что при монтаже фасада подрядчик регулярно направляет вопросы по примыканию кронштейна к проёму. Ответственные тратят время на уточнение места, версии чертежа и фотографии. Смена получает решение поздно и переносит выход на участок. Нам важно не «ускорить проектировщика» приказом, а понять, почему он не может сразу принять запрос к работе.
Команда берёт десять завершённых запросов одного типа, а не смешивает фасад, инженерные сети и отделку. В учебных данных шесть запросов возвращались за недостающими исходными материалами. Время от первой отправки до пригодного для решения пакета составляло от одного до трёх рабочих дней; это вымышленные значения для иллюстрации метода, не результат наблюдения на конкретной стройке.
Шаг
До теста
Тестовый порядок
Подготовка
Запрос в свободной форме, приложения разрознены.
Одна карточка с местом, редакцией чертежа, фото и вопросом.
Первичная проверка
Неполнота выясняется после передачи.
Инженер ПТО проверяет состав до отправки.
Решение
Возвраты и уточнения в разных каналах.
Один ответственный фиксирует решение и версию.
Передача фронта
Прораб видит письмо, но не критерий готовности.
Прораб подтверждает применимость решения к конкретной зоне.
Для теста выберем следующие десять запросов того же типа. Считаем долю принятых с первого раза, число возвратов, рабочие дни до принятого решения и случаи, когда вопрос всё равно задержал фронт работ. Если состав запросов или загрузка проектировщика резко изменились, укажем это при сравнении. По десяти случаям нельзя делать вывод о гарантированной экономии для всего проекта.
Владелец процесса согласует шаблон и условия теста, инженер ПТО проверяет комплектность, проектировщик сообщает, хватает ли данных, прораб подтверждает, получил ли применимое решение. После теста команда решает, закрепить ли шаблон, изменить его или отказаться. Само создание формы не является результатом Kaizen Event.
Для каждого нового запроса сохраните одинаковые отметки: время создания, первой проверки, возврата при неполноте, окончательного решения и передачи исполнителю. Тогда можно увидеть, что именно изменилось. Если срок сократился только потому, что запросы стали проще, вывод о пользе шаблона будет преждевременным. Такая оговорка защищает команду от ложной уверенности и помогает выбрать следующий тест.
Проверка результата и закрепление нового порядка
Отделяйте намерение от факта. «Ожидаем сократить время поиска» — гипотеза. «На десяти новых запросах доля возвратов изменилась с 6 из 10 до 2 из 10 при том же критерии комплектности» — возможная проверяемая запись, если данные действительно получены. В этой статье числа условные; на реальном объекте их можно писать только после повторного замера.
Одного показателя недостаточно. Быстро отправленный неполный ответ может ухудшить качество и создать переделку. Поэтому вместе со сроком проверяйте, приняла ли следующая сторона решение, не выросли ли замечания и не был ли обязательный контроль просто исключён из процесса. Экономический эффект рассчитывайте только при согласованной формуле, исходной базе и единице измерения. Не умножайте условные минуты на ставку и весь объём проекта без подтверждения.
Что делать после тестового прохода
Если порядок помог, обновите рабочую инструкцию, объясните её участникам и назначьте того, кто проверит применение через согласованный интервал. Сохраните пример правильно оформленного запроса и старую редакцию формы, чтобы изменение можно было проследить. Если результата нет, не объявляйте мероприятие неудачей: разберите, была ли причина выбрана верно, применялся ли новый порядок и достаточно ли одинаковы сравниваемые случаи.
Здесь полезен цикл PDCA: сформулировать план и способ проверки, выполнить изменение в ограниченном объёме, сравнить факты с целью, затем закрепить рабочий вариант или изменить гипотезу. Lean Enterprise Institute отдельно предупреждает, что число проведённых мероприятий не должно подменять значимые результаты; устойчивость зависит от ежедневной работы команды, а не только от специальной сессии.
Когда обнаружен отдельный барьер ближайшей работе — например, не согласована версия чертежа, — его стоит вынести в журнал ограничений с владельцем, сроком снятия и проверкой. Когда после изменения нужен новый порядок недельных обещаний, переходите к Lookahead и Weekly. Так сессия не существует отдельно от управления объектом.
При внедрении в нескольких подразделениях начните с одного согласованного процесса и проследите, как новый порядок живёт без постоянного присутствия ведущего. Если он держится только на личных напоминаниях, стандарт ещё не закрепился. Вернитесь к вопросу, понятны ли исполнителям входные данные, полномочия, срок реакции и способ сообщить о сбое. Следующий Kaizen Event тогда может работать уже с новой, точнее описанной проблемой.
Опубликованный инструмент «Кайдзен» — это реестр кайдзен-предложений. В нём можно вести каждую идею от наблюдаемой проблемы до решения, выполнения и подтверждённого эффекта. Предложение может возникнуть до Kaizen Event, во время него или в обычной работе команды. Реестр помогает сохранить решения и действия, но не является инструментом проведения события, не определяет причину вместо команды и не подтверждает экономию без замеров.
Рисунок 2. Реестр кайдзен-предложений в опубликованном инструменте «Кайдзен» и учебный пример, снимок 18.10.2026.
Откройте инструмент по ссылке ниже. В «Паспорте реестра» назовите объект, процесс и дату. Нажмите «Добавить предложение» и опишите наблюдаемый факт, место, предлагаемое изменение и автора. После решения назначьте ответственное лицо, конкретное действие и срок. Не смешивайте решение «одобрено» со статусом «внедрено»: между ними должна состояться работа на объекте.
Для учебного знакомства можно нажать «Показать пример». Он добавит демонстрационную запись о наименовании файлов исполнительных схем; не выдавайте её за свой результат. Если уже ведёте реальные данные в том же браузере, сначала сохраните копию через JSON. В опубликованной версии есть также печать, импорт JSON и кнопка PDF в Telegram. Наличие кнопки само по себе не подтверждает доставку PDF в чат.
Как заполнить эффект и что проверить перед внедрением
В карточке инструмента исходное значение, цель и факт внесены раздельно. Для примера со временем проверки комплекта можно указать «мин/комплект», исходное значение по сопоставимому замеру, целевое значение и способ измерения. После теста внесите фактическое значение, дату проверки и доказательство. Отметку «Эффект подтверждён измерением» ставьте после проверки, а не при принятии идеи. Данные инструмента хранятся на этом устройстве; перед сменой браузера или очисткой его данных сохраните JSON-копию.
Рисунок 3. Карточка предложения в опубликованном Mini App: исходное, целевое и фактическое значения, способ измерения и подтверждение результата.
Перед запуском на своём объекте проверьте пять вещей: выбран один процесс и его получатель; есть факты до изменения; участвовали исполнители и принимающая сторона; тест не отменяет обязательных проверок; назначены дата повторного замера и человек, который решит, закреплять ли новый порядок. Тогда даже небольшой тест даст команде основание для следующего решения.
Если процесс повторяется, но участники по-разному видят его границы и обязанности, начинать полезно с короткой диагностики. В работе с заказчиком я бы сначала уточнил, где теряется время и какой результат должен получить следующий исполнитель, а затем согласовал объём изменения, состав команды и способ проверки. Для обсуждения конкретной задачи есть форма краткого брифа и описание услуг.
Источники методики: Lean Construction Institute — Kaizen & Continuous Improvement; Lean Enterprise Institute — Kaizen и PDCA. Даты, значения и ситуация с фасадным узлом в статье учебные.
Зафиксируйте отдельные идеи, ответственных, сроки и подтверждённый эффект в реестре кайдзен-предложений. Сам Kaizen Event проводится командой на объекте.