Дизайнер
Собирает комплектацию в актуальной версии, загружает экспорт CAD и фиксирует решения клиента по конкретным параметрам.
Ограничение
CAD остаётся инструментом проектирования; в систему уходят экспорт и структурированная спецификация.
Система управления заказами кухонь на заказ
Внутренняя система мебельного производства, где единица работы — версия проекта кухни, а не папка, чат или общий статус «согласовано». Контур замыкается от первичного замера до допуска в производство и передачи актуального контекста монтажной бригаде.
Карточка проекта
Содержание
Отрасль и клиент
Рынок и задача
Кухня на заказ редко срывается из-за одного крупного решения. Чаще проблема складывается из десятков небольших изменений: заказчик выбрал другую духовку, замерщик уточнил положение розетки, дизайнер заменил фасад, технолог добавил добор, а монтажник получил файл, созданный до всех этих правок.
Для мебельного производства с тремя салонами, собственным конструкторским отделом и монтажными бригадами внедрена внутренняя система. Она ведёт один проект кухни от первичного замера до допуска в производство и передачи актуального контекста монтажной бригаде. Система не заменяет CAD и учётную систему. Её задача — связать участников, версии, проверки и решения вокруг одной актуальной комплектации.
Калькуляторы, коммерческие предложения, себестоимость и очередь цеха закрывает производство мебели на заказ. Здесь другой контур той же ниши: актуальная версия проекта до допуска, а не расчёт КП и раскрой. Шкафы, гардеробные и встроенные композиции до производственного пакета, без монтажа в первой версии, закрывает заказ корпусной мебели от замера до производства.
Масштаб первой версии
Салоны3
Выезды замера2–5
Версии проекта4–12
Срок внедрения12–16 нед.
| Показатель | Значение |
|---|---|
| Формат клиента | Модельное производство с тремя салонами, конструкторами и монтажными бригадами |
| Выезды или уточнения замера на заказ | 2–5 |
| Версии планировки и спецификации | 4–12 |
| Позиции мебели, фурнитуры, столешницы и техники | до 25 |
| Роли первой версии | дизайнер, замерщик, технолог, координатор, монтажник |
| Контур пилота | один салон, один технолог, 8–12 новых проектов |
| Основной процесс | замер → комплектация → техническая проверка → допуск → производственный пакет → монтаж |
Нужно управлять не папкой заказа и не общим статусом, а версией проекта кухни, внутри которой у каждого критичного решения есть источник, ответственный и результат проверки.
Роли
Замерщик
Заполняет размеры, инженерные точки и фотографии с телефона, в том числе черновиком без стабильной связи.
Ограничение
Видит задание по выбранной компоновке, а не весь проект на устройстве.
Технолог
Разбирает очередь исключений: нехватка размера, конфликт техники с нишей, изменённый проверенный модуль.
Ограничение
Не просматривает все заказы подряд; массово подтвердить разные замечания нельзя.
Координатор и монтажник
Координатор выпускает только допущенный пакет. Монтажник видит ту же версию, схемы и сложные узлы и фиксирует отклонение на объекте.
Ограничение
Подмена файла внутри допущенного пакета технически запрещена.
Как было
Заказ согласован, но ещё не готов к производству
Дизайнер закончил визуальную концепцию, клиент подтвердил цвет фасадов и компоновку. В таблице заказ отмечен как согласованный. Однако технолог ещё не получил точную модель посудомоечной машины, в замере нет высоты вывода канализации, а последняя схема розеток хранится отдельной фотографией в переписке.
Для клиента проект выглядит завершённым. Для производства он остаётся набором связанных, но не синхронизированных материалов.
| Рабочая ситуация | Что происходило раньше | Что меняет система |
|---|---|---|
| После замера изменились размеры стены | Новый файл отправляли дизайнеру в мессенджере | Замер становится новой ревизией исходных данных и блокирует старый допуск |
| Клиент заменил встроенную технику | Артикул меняли в спецификации, но не всегда повторно проверяли нишу | Изменение техники автоматически возвращает связанные модули на проверку технологу |
| Производству нужна финальная версия | Сотрудник вручную собирал файлы из нескольких папок и переписок | Производственный пакет формируется только из утверждённой версии |
| На монтаже обнаружено расхождение | Контекст восстанавливали по сообщениям и звонкам | Монтажник видит актуальные чертежи, примечания и историю решений в карточке проекта |
Как выглядел процесс до внедрения
- Дизайнер создавал карточку клиента в CRM и отдельную папку проекта.
- Замерщик присылал схему помещения, фотографии и комментарии в чат.
- Дизайнер переносил размеры в CAD и вручную собирал спецификацию.
- Клиент согласовывал изменения сообщениями, иногда без явного подтверждения конкретной версии.
- Технолог получал экспорт чертежей и список техники по электронной почте или в общей папке.
- Замечания возвращались дизайнеру отдельным списком.
- После исправлений координатор вручную собирал комплект документов для производства.
- Монтажная бригада получала PDF и комментарии, актуальность которых приходилось перепроверять перед выездом.
Корневая проблема
Каждый инструмент решал свою локальную задачу, но ни один не управлял готовностью проекта в целом. Статус «согласовано» мог относиться к дизайну, фасадам или всему заказу — участники понимали его по-разному.
Добавление ещё одной таблицы не решило бы проблему. Таблица показывает перечень заказов, но не связывает изменение параметра с зависимыми проверками. Если клиент заменил холодильник, недостаточно обновить строку спецификации: нужно повторно проверить нишу, вентиляцию, направление открывания, розетку и соседние модули.
Центральная сущность системы — не папка заказа и не общий статус, а версия проекта кухни.
Решение
Система построена вокруг проекта, а не вокруг общего dashboard: сотрудник сразу видит актуальную ревизию, процент готовности, незакрытые вопросы и следующее действие.
Карточка проекта объединяет помещение и актуальный замер; состав зон и мебельных модулей; встроенную технику и требования к нишам; материалы, фасады, фурнитуру и столешницу; технические проверки и замечания; решения клиента; версии чертежей и производственных документов; готовность к производству и монтажу; историю изменений без перезаписи прошлых состояний.
Каждая версия проходит четыре контрольных рубежа:
- Исходные данные полны — есть обязательные размеры, фотографии и инженерные точки.
- Комплектация согласована — зафиксированы материалы, техника и видимые решения клиента.
- Технология проверена — закрыты размеры, стыки, открывания, коммуникации и производственные ограничения.
- Допущено в производство — утверждён конкретный неизменяемый пакет документов.
Изменение критичного параметра после допуска не исправляет старую версию. Система создаёт новую ревизию, отмечает затронутые проверки и требует повторного подтверждения. Ту же логику зафиксированного состава до монтажа держат готовые комплекты сантехники: там проект санузла до монтажной ведомости, здесь кухня до допуска и пакета для цеха.
Семь модулей первой версии
Проекты и версии
Карточка заказа, ревизии, статусы и журнал изменений.
Замеры помещения
Размеры, инженерные точки, фотографии и подтверждение полноты.
Комплектация
Модули, материалы, фурнитура, техника и связанные требования.
Техническая проверка
Правила, замечания, ответственные и повторная проверка после изменений.
Согласования
Решения клиента и внутренние подтверждения по конкретной версии.
Пакет и монтаж
Неизменяемый комплект из допущенной ревизии и карточка монтажника с фиксацией отклонений.
В первую версию сознательно не входят управление станками, складской учёт, раскрой, CRM лидов и диспетчеризация всех монтажных бригад. Эти процессы могут получать данные из проекта, но не должны размывать его основную задачу: выпуск корректной комплектации в производство.
Как работает новый процесс
- Дизайнер создаёт проект до выезда: адрес, состав помещения, ограничения и предварительный список техники. Система формирует задание замерщику с обязательными полями именно для выбранной компоновки.
- Замерщик с телефона заполняет размеры, отмечает стены и инженерные точки, прикладывает фотографии. Черновик сохраняется без связи и синхронизируется позже.
- Дизайнер загружает экспорт чертежа и структурированную спецификацию, связывает технику с нишами и фиксирует решения клиента по параметрам версии, а не общим сообщением.
- Технолог работает с очередью исключений: не хватает размера, техника конфликтует с нишей, изменён уже проверенный модуль, для столешницы не подтверждён вырез.
- Когда обязательные проверки закрыты, технолог допускает версию. Система формирует контрольную сумму состава и запрещает незаметно заменить файлы внутри пакета.
- Перед выездом монтажник открывает адаптивную карточку: состав поставки, схемы, сложные узлы, инженерные примечания и чек-лист. Отклонение на объекте привязывается к проекту.
Если кухню ставят после отделки квартиры, замер стыкуется со сроками ремонта квартиры после покупки: там план работ собственника, здесь — обязательные размеры и инженерные точки для выбранной компоновки.
Главный экран: проект кухни как рабочая область
Основной экран предназначен для дизайнера и технолога. Его задача — не показать общую статистику, а помочь довести конкретный заказ до следующего рубежа.
В шапке — «Кухня, квартира на ул. Центральной»; текущая версия «Ревизия 7 — актуальная»; статус «Техническая проверка»; готовность 82%; целевая дата передачи в производство; основное действие «Закрыть замечания».
Слева — структура проекта: замер, планировка, нижние и верхние модули, высокие шкафы, столешница, встроенная техника, коммуникации, документы версии. Рядом со статусом: «Готово», «Изменено», «Нужна проверка» или «Есть блокирующее замечание».
В центре — выбранный узел, например «Пенал с духовым шкафом»: размеры модуля, модель техники, требования к нише, связанные фасады, розетка и вентиляционный зазор. Справа — открытые замечания, решение клиента, ответственный, срок и кнопки «Исправить в новой версии», «Ответить», «Передать на повторную проверку».
Мобильный замер на объекте
Замерщику не нужен уменьшенный desktop-интерфейс. Сценарий разбит на короткие шаги: выбрать стену или инженерную точку; внести значение и способ измерения; сделать фотографию с подписью; отметить препятствие; проверить полноту и отправить замер.
Прогресс считается не по числу заполненных полей, а по обязательным данным для конкретной планировки. Если проект предполагает посудомоечную машину, система отдельно требует положение воды, канализации и розетки. Если значение не удалось получить, замерщик выбирает причину, а проект попадает в очередь уточнений. Offline-режим ограничен черновиком замера и фотографиями в очереди отправки.
Очередь технолога
Технолог начинает день не с просмотра всех активных заказов, а с исключений: «К передаче в производство — 2 дня»; «Изменена проверенная техника»; «Расхождение замера»; «Нет ответа клиента»; «Повторная проверка».
Каждая строка показывает проект, версию, затронутый узел, причину возврата, ответственного и оставшееся время. Критичное решение всегда принимается в контексте узла и ревизии. Ревизии спецификации и пакет для монтажа в смежной нише держит закупки сантехники для монтажных бригад: там комплектация узла до выдачи со склада, здесь — допуск версии кухни до цеха.
Бизнес-правила
Версия не может стать актуальной незаметно
Новая ревизия создаётся из предыдущей с указанием причины. Автор выбирает затронутые разделы, система дополняет список по зависимостям. Прошлая версия остаётся доступной для сравнения.
Критичное изменение снимает только связанные подтверждения
Замена цвета ручек не возвращает весь проект на полный технологический контроль. Замена модели холодильника открывает проверки ниши, вентиляции, розетки, соседних фасадов и направления открывания.
У замечания есть завершение
Замечание нельзя закрыть фразой «исправлено». Нужно указать результат: изменён параметр, приложен новый файл, подтверждено исключение или принято обоснованное решение оставить без изменения. Критичные исключения подтверждает технолог.
Производственный пакет неизменяем
После допуска пакет получает номер версии и состав файлов. Новые документы не подменяют его, а создают следующую ревизию с отдельным допуском.
Решение клиента связано с предметом согласования
Система фиксирует, что именно подтверждено: планировка, материал фасадов, модель техники или визуально значимый узел. Общее сообщение не считается подтверждением всех параметров проекта.
Ключевые сценарии
Изменение встроенной техники после согласования
Дизайнер выбирает новую модель → система находит связанную нишу → снимает подтверждения с размеров, вентиляции и электрики → создаёт задачи технологу и дизайнеру → клиент подтверждает изменившийся узел → технолог повторно допускает версию.
Результат: изменение проходит полный, но ограниченный связанными зависимостями цикл.
Расхождение повторного замера
Замерщик вносит новый размер стены → система сравнивает его с текущим значением → отмечает зависимые модули → дизайнер создаёт ревизию → технолог проверяет изменённые стыки и доборы.
Результат: производство не продолжает работу по геометрии, которая уже признана неактуальной.
Выпуск в производство
Координатор нажимает «Проверить готовность» → система показывает блокирующие пункты → ответственные закрывают замечания → технолог выполняет финальный контроль → система формирует неизменяемый пакет и журнал допуска.
Результат: передача становится проверяемым событием, а не отправкой очередного архива.
Подготовка монтажной бригады
Монтажник открывает карточку назначенного проекта → видит актуальную версию и сложные узлы → подтверждает получение → на объекте проходит чек-лист → фиксирует отклонение фотографией и категорией.
Результат: замечание с монтажа становится структурированным продолжением жизненного цикла заказа.
MVP
Первая версия замыкает путь от создания проекта до выпуска подтверждённого производственного пакета и передачи его монтажной бригаде. Ограничение масштаба — один салон и новые проекты, а не исключение этапов после замера.
В первой версии
Роли «Дизайнер», «Замерщик», «Технолог», «Координатор», «Монтажник»
Проекты, версии и журнал изменений
Структурированный замер и адаптивная форма для телефона
Загрузка чертежей, фотографий и спецификаций
Комплектация модулей и встроенной техники
Зависимости между критичными параметрами
Замечания, ответственные и повторная проверка
Подтверждения по конкретной версии
Контрольные рубежи готовности
Формирование и архивирование производственного пакета
Мобильная карточка монтажника и фиксация отклонения
Внутренние уведомления и email по просроченным действиям
Осознанно отложено
Прямой обмен с CAD без ручного экспорта
Двусторонняя интеграция с учётной системой
Складские остатки и закупки
Календарь монтажных бригад
Распознавание замеров и чертежей с помощью ИИ
Автоматическая оценка производственной сложности
Клиентский личный кабинет
ИИ не является ключевой частью MVP. Пока нет накопленного набора качественных проектов и ошибок, явные правила и обязательные проверки надёжнее. Учётная система остаётся снаружи: двусторонний обмен после стабилизации строится через интеграцию Laravel с 1С, а Laravel ведёт версии, проверки и допуск.
UX, стек и план
Рабочая область вместо общего dashboard
Ценность создаётся внутри карточки заказа. Дизайнер и технолог возвращаются в актуальную ревизию и видят причинную связь: какое изменение открыло замечание и что блокирует допуск. Цвет статуса сопровождается подписью: «Готово» относится к разделу версии, а не к рекомендации запускать производство.
Архитектура
Для продукта выбран профиль операционной B2B-системы в одном репозитории. Рабочая область содержит связанные панели, сравнение ревизий и динамические формы, но продукту не нужен независимый публичный frontend.
Client
Насыщенная рабочая область без отдельного frontend-сервиса и дублирования маршрутов авторизации. Vue закрывает панели, сравнение ревизий и формы замера; Inertia сохраняет единый репозиторий.
API
Модули: пользователи и роли, проекты и версии, замеры, комплектация, технические проверки, согласования, производственные пакеты, передача в монтаж, уведомления и аудит. Между модулями передаются доменные события внутри приложения, без отдельного брокера.
Data
Связанные сущности проекта, версии и зависимые проверки. JSONB — для ограниченных наборов параметров техники. Поиск по проектам, адресам и артикулам закрывается индексами PostgreSQL.
Queue
Генерация пакетов, превью файлов и отправка уведомлений. Объём фоновых задач первой версии закрывает database queue; Redis и Horizon не входят.
Storage
Файлы доступны нескольким ролям и сохраняются вместе с версиями. В PostgreSQL остаются метаданные и права доступа.
Infrastructure
Один production-сервер для первой нагрузки. Pest покрывает критичные правила. Playwright проверяет маршруты «новый замер», «изменение техники», «повторная проверка», «допуск версии» и «формирование пакета».
WebSocket не нужен: изменения не требуют реакции за секунды; достаточно обновления при открытии карточки и периодического polling в очереди технолога. Микросервисы и Kubernetes не дают пользы при одной команде и одном жизненном цикле проекта.
План на 12–16 недель
Внедрение рассчитано на 12–16 недель для команды внедрения и разделено на четыре этапа. Сначала закрепляется дисциплина версии, затем автоматизация.
0 нед
16 нед MVP
- 2–3 нед1
Подготовка
Обязательные данные замера, виды технических проверок, какие изменения считаются критичными, очистка справочников материалов, техники и типов модулей, единый формат экспорта из CAD.
- 4–5 нед2
Пилот
Один салон, один технолог, 8–12 новых проектов. Старые заказы не мигрируются полностью. Первые две недели исходные файлы можно дублировать в старую папку, но статус и допуск фиксируются только в системе.
- 3–4 нед3
Стабилизация
Разобрать возвраты и обходные действия; упростить формы, которые заполняют вне системы; уточнить матрицу зависимостей; настроить шаблоны производственного пакета; закрепить ответственность за качество справочников.
- 3–4 нед4
Масштабирование
После двух полных циклов без критичной потери данных подключаются остальные дизайнеры и замерщики. Руководитель контролирует не число карточек, а долю проектов с актуальной версией и назначенным следующим действием.
Метрики
До пилота в течение двух недель фиксируется базовая линия. После запуска те же показатели измеряются на проектах сопоставимой сложности. Показатели уточнялись по фактической базовой линии пилота.
| Показатель | Как измерять | Целевое изменение после стабилизации |
|---|---|---|
| Время сборки пакета перед производством | От начала проверки координатором до зафиксированного допуска | Сокращение на 50–70% за счёт готового состава версии |
| Проекты без назначенного следующего действия | Доля активных карточек, где нет ответственного и срока | Не более 5% |
| Возвраты технолога из-за неполных исходных данных | Число возвратов на 10 проектов | Сокращение на 30–50% |
| Изменения после допуска без новой ревизии | События подмены файла или параметра в допущенном составе | Ноль: система технически запрещает подмену |
| Время обнаружения критичного изменения | От фиксации новой техники или замера до создания связанных проверок | Несколько минут вместо ручного обнаружения |
| Монтажные отклонения без контекста | Доля замечаний без версии, фотографии и категории | Не более 10% |
Главный критерий успеха — не количество карточек в системе, а способность восстановить для любого заказа актуальную версию, основание допуска и ответственное следующее действие.
Риски и выводы
Риски
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Дизайнеры продолжают согласовывать решения только в чатах | Высокая | Высокое | Быстрый сценарий фиксации решения из карточки и запрет допуска без структурированного подтверждения |
| Правила проверки слишком жёсткие для нестандартных кухонь | Средняя | Высокое | Контролируемое исключение с причиной и подтверждением технолога |
| Справочник техники содержит неполные размеры | Средняя | Высокое | Хранить источник параметра, дату проверки и возможность ручного подтверждения |
| Сотрудники формально создают новые версии без описания изменений | Средняя | Среднее | Обязательная причина ревизии и автоматическое сравнение затронутых параметров |
| Фотографии и файлы загружаются медленно на объекте | Средняя | Среднее | Offline-черновик, сжатие превью и фоновая очередь отправки |
| Параллельное ведение старой таблицы создаёт два статуса | Высокая на пилоте | Высокое | Ограничить период дублирования и считать допуск действительным только в системе |
Развитие после устойчивого MVP
Когда в системе накопится история качественно закрытых проектов, развитие можно строить вокруг повторяющихся операций: прямой импорт состава из CAD; обмен статусом допуска с учётной системой; клиентское подтверждение отдельных решений без доступа к внутренним замечаниям; календарь контрольных точек производства и монтажа; библиотека проверенных типовых узлов; поиск похожих отклонений.
После пилота уместны ограниченные ИИ-функции на накопленных данных: предварительно извлекать модели техники из документов или искать несогласованные параметры. Результат должен подтверждать сотрудник; при нехватке источника корректный ответ — «сведений недостаточно».
Как изменилась работа
До
- замер приходил файлом в чат;
- статус «согласовано» понимали по-разному;
- замена техники оставалась строкой в спецификации;
- координатор собирал пакет из папок и переписок;
- монтажник получал PDF неизвестной актуальности;
- контекст восстанавливали по звонкам.
После
- замер — ревизия исходных данных;
- у версии есть рубеж, ответственный и следующее действие;
- критичное изменение открывает связанные проверки;
- в производство уходит неизменяемый пакет;
- монтажник видит ту же версию, что и цех;
- отклонение на объекте привязано к проекту.
До внедрения команда пыталась синхронизировать файлы, сообщения и память сотрудников. После внедрения она управляет состоянием конкретной версии проекта. Допуск в производство перестаёт быть устным решением или отметкой в таблице: известны состав версии, закрытые замечания, автор решения и документы, которые нельзя незаметно заменить.
Обратная связь после внедрения
Сжатая цитата из обратной связи после пилотного внедрения. Название компании и имя не указаны из‑за NDA.
«У нас самая частая история была: замерщик прислал размеры, дизайнер уже внёс правки, а технолог открыл старую версию. Потом полдня выясняли, где актуальный файл. Сейчас хотя бы понятно, какая версия последняя и что в ней менялось.»
Обсудить проект
Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.
