Внутренняя система производителя мебели на заказ, где единица работы — заказ-проект корпусной мебели, а не папка, чат или общий статус «согласовано». Контур замыкается от выездного замера до передачи проверенного производственного пакета в цех.
Содержание
Клиент может согласовать внешний вид кухни или шкафа, но это ещё не означает, что заказ готов к изготовлению. После согласования дизайнер меняет фасад, технолог обнаруживает конфликт с коммуникациями, замерщик присылает уточнённый размер, а выбранная фурнитура остаётся только в переписке.
Для производителя корпусной мебели с двумя салонами, выездными замерщиками, дизайнерами, технологами и координатором производства внедрена внутренняя система. Одновременно команда ведёт около 55 активных заказов: кухни, шкафы, гардеробные и встроенные композиции. Система не заменяет CAD и учётную систему. Её задача — связать замер, проект, комплектацию и технологическую проверку вокруг одной актуальной версии, которую можно передать в цех.
Калькуляторы, коммерческие предложения, себестоимость и очередь цеха закрывает производство мебели на заказ. Здесь другой контур той же ниши: готовность версии до производственного пакета, а не расчёт КП и раскрой. Узкий контур только кухни с выездом монтажной бригады — система заказов кухонь на заказ. Здесь шкафы, гардеробные и встроенные композиции в одном контуре, а первая версия заканчивается пакетом для цеха, без монтажа.
| Показатель | Значение |
|---|---|
| Формат клиента | Модельное производство с двумя салонами, замерщиками, дизайнерами и технологами |
| Активные заказы одновременно | около 55 |
| Типы изделий | кухни, шкафы, гардеробные, встроенные композиции |
| Роли первой версии | дизайнер, замерщик, технолог, координатор производства |
| Контур пилота | один замерщик, два дизайнера, технолог, координатор; новые кухонные заказы |
| Основной процесс | замер → проектная ревизия → согласование → технологическая проверка → производственный пакет |
Нужно управлять не файлами заказа и не общим статусом, а готовностью версии: какая ревизия актуальна, что в ней изменилось и почему её уже можно передавать в производство.
Ведёт рабочую карточку заказа: создаёт ревизии, собирает комплектацию, прикладывает визуализации, отправляет решения на согласование и отвечает на замечания технолога.
Ограничение
CAD остаётся инструментом проектирования; в систему уходят экспорт, состав и решения по конкретной ревизии.
Фиксирует геометрию помещения, коммуникации, фотографии и ограничения в короткой адаптивной форме на смартфоне.
Ограничение
Не заполняет проектную часть заказа. Черновик сохраняется локально при кратковременном обрыве связи.
Проверяет только актуальную ревизию, видит отличия от ранее проверенной версии и ставит замечания на конкретный размер, модуль или позицию.
Ограничение
Не просматривает все заказы подряд. Замечание закрывает технолог, а не автор исправления.
Работает с очередью исключений: проекты без следующего действия, просроченные проверки и заказы, которые почти готовы, но заблокированы одним обязательным пунктом.
Ограничение
Производственный пакет формируется только из актуальной ревизии; после передачи изменение требует отдельного решения.
После разговора с клиентом менеджер создаёт строку в таблице и передаёт контакты замерщику. Замерщик делает фотографии, схему и заметки, затем отправляет материалы в мессенджер или общую папку. Дизайнер создаёт визуализацию и спецификацию, а варианты фасадов и фурнитуры обсуждает с клиентом в переписке.
Когда внешний вид согласован, дизайнер передаёт папку технологу. Технолог проверяет конструкцию и возвращает замечания: не хватает размера, розетка попадает за корпус, петля конфликтует с внутренним ящиком, не указана модель встраиваемой техники. Часть изменений фиксируется в файле, часть — сообщением, часть — устно. Файл получает название вроде «финал_3_точно», но из названия нельзя понять, какие решения уже подтверждены и какую версию проверял технолог.
| Рабочая ситуация | Что происходило раньше | Что меняет система |
|---|---|---|
| Технолог проверяет устаревший файл | Версии проекта не связаны с согласованиями | Технолог видит только актуальную ревизию и отличия от предыдущей |
| Новый размер приходит после согласования | Замер и проект живут в разных источниках | Уточнение замера создаёт новую версию исходных данных и сбрасывает связанные проверки |
| Материал заменён сообщением | Решение не оформлено как изменение состава | Замена фиксируется как отличие ревизии и относится к конкретным подтверждениям |
| Координатор собирает пакет вручную | Нет формальных условий готовности | Пакет формируется только из ревизии с закрытыми обязательными проверками |
Главная проблема проявляется не в отсутствии информации. Данных много, но они находятся в разных местах и относятся к разным версиям заказа. В этой цепочке нет одного момента, когда система может однозначно ответить: какая версия актуальна, что в ней изменилось и почему она уже готова к изготовлению.
Добавление ещё одной таблицы не решает проблему. Таблица может показать срок и ответственного, но не связывает конкретный замер, выбранные материалы, замечания технолога и согласование клиента.
Центральная сущность системы — не папка заказа и не общий статус, а заказ-проект корпусной мебели.
Система построена вокруг заказа, а не вокруг общего dashboard: сотрудник сразу видит актуальную ревизию, незакрытые проверки и следующее действие.
Внутри заказа-проекта система хранит помещение и исходные данные; версии замера; проектные ревизии; состав модулей, материалов, фурнитуры и техники; решения клиента; технологические замечания; обязательные проверки; историю изменений; производственный пакет.
Каждая существенная правка создаёт новую ревизию. Система показывает различия с предыдущей версией и сбрасывает только те подтверждения, которых касается изменение. Замена цвета фасада не требует повторного замера, а изменение глубины корпуса возвращает на проверку связанные размеры, фурнитуру и размещение техники.
Готовность перестаёт быть субъективным статусом. Она рассчитывается из состояния обязательных данных и проверок. Заказ нельзя передать в производство, пока в актуальной ревизии есть незакрытые замечания, отсутствуют обязательные размеры или не подтверждена комплектация. Ту же логику зафиксированного состава до монтажа держат готовые комплекты сантехники: там проект санузла до монтажной ведомости, здесь мебель до пакета для цеха.
Карточка заказа, роли, статусы и журнал действий.
Адаптивная форма, версии замера и проверка обязательных полей.
Модули, материалы, фурнитура, техника и сравнение отличий.
Решения клиента по конкретной ревизии и конкретному набору пунктов.
Очередь исключений, замечания на элемент и повторная проверка.
Актуальные файлы, спецификация, лист решений и перечень закрытых замечаний.
В первую версию сознательно не входят визуальный конструктор мебели, карты раскроя, двусторонняя интеграция с учётной системой, складские резервы, клиентский кабинет и прогнозирование сроков. Эти функции не нужны, чтобы проверить главное: может ли одна управляемая ревизия заменить ручную сборку производственного пакета.
Если мебель ставят после отделки квартиры, замер стыкуется со сроками ремонта квартиры после покупки: там план работ собственника, здесь — обязательные размеры и ограничения помещения для выбранного изделия.
Основной экран предназначен дизайнеру. Это не обзорный dashboard, а рабочая область конкретного заказа.
В шапке — номер заказа, тип мебели, помещение, ответственный, текущая ревизия и вычисляемый статус. Рядом показано следующее действие: например, «Указать модель духового шкафа» или «Исправить 3 замечания технолога».
Левая колонка содержит структуру изделия: высокие модули, нижний ряд, верхний ряд, остров, столешница. Для каждого узла видны состояние комплектации и наличие замечаний. В центре — выбранный узел: размеры, материалы, фасады, фурнитура, связанная техника, файлы и визуализация. Справа — блок готовности, замечания и история решений. Если пользователь меняет глубину корпуса, система сразу показывает, какие ранее закрытые проверки будут возвращены в работу.
Сравнение ревизий выводит не только заменённые файлы, но и структурированные различия: «Глубина корпуса: 560 → 600 мм»; «Фасад: матовый белый → тёплый серый»; «Петля: позиция заменена»; «Добавлена модель холодильника».
Для замерщика система открывается как адаптивная web-форма. Отдельное мобильное приложение не требуется: сотрудник работает онлайн, а черновик сохраняется локально при кратковременном обрыве связи.
Замер разделён на короткие шаги: геометрия помещения; проёмы, выступы и ниши; вода, вентиляция, розетки и другие коммуникации; зоны установки техники; фотографии и общий комментарий; проверка полноты перед отправкой. Каждый размер имеет подпись и привязку к зоне. Фотография может быть связана с конкретным ограничением, например «вентиляционный короб» или «неровность стены».
Если обязательный размер отсутствует, замер нельзя отметить завершённым. При этом замерщик может отправить форму со статусом «Требует уточнения» и явно указать причину — скрытая коммуникация, незавершённая отделка или отсутствие техники на объекте.
Технологу не нужен список всех заказов. Его рабочий экран — очередь ревизий, которые действительно требуют решения: новая ревизия после замечаний; изменение затронуло ранее проверенный узел; отсутствует обязательный параметр; обнаружен конфликт между размером и комплектацией; приближается плановый срок передачи в производство.
В строке заказа видны тип мебели, ревизия, автор изменений, время ожидания, число изменённых элементов и причина возврата. Технолог может открыть режим сравнения и пройти только по затронутым узлам. Замечание оформляется с типом, описанием, ответственным и условием закрытия. После исправления дизайнер не удаляет замечание: он отвечает на него и связывает с новой ревизией. Ревизии спецификации до выдачи со склада держит закупки сантехники для монтажных бригад: там комплектация узла до склада, здесь — допуск версии до цеха.
Завершённый замер нельзя перезаписать: уточнение создаёт новую версию. Ревизия передаётся технологу только после проверки обязательных полей. Производственный пакет формируется только из актуальной ревизии.
Изменение размера, материала, фурнитуры или техники фиксируется как структурированное отличие. Если изменение затрагивает подтверждённый элемент, связанное подтверждение становится неактуальным. Согласование относится к конкретной ревизии и конкретному набору решений.
Дизайнер отвечает на замечание и связывает исправление с новой ревизией. Закрытие остаётся за технологом. История остаётся в заказе.
Изменение оформляется отдельным запросом и требует решения координатора. Автоматическая проверка выявляет формальные пробелы и известные конфликты, а нестандартные конструктивные решения оставляет технологу.
Дизайнер создаёт заказ-проект и назначает замерщика. Замерщик заполняет форму, прикладывает фотографии и отправляет результат. Система проверяет полноту, создаёт версию замера и уведомляет дизайнера.
Результат: исходные данные находятся в карточке заказа и готовы к проектированию.
Дизайнер собирает состав, прикладывает визуализацию и выбирает решения, требующие подтверждения. Система не позволяет отправить неполный набор. После получения решения отметка связывается с конкретной ревизией.
Результат: понятно, что именно было подтверждено.
Технолог открывает ревизию из очереди, сравнивает её с предыдущей, ставит замечания на конкретные элементы и завершает проверку.
Результат: дизайнер получает конечный список исправлений без параллельной переписки.
Дизайнер создаёт новую ревизию и меняет столешницу. Система показывает затронутые позиции и сбрасывает подтверждение материала, но сохраняет актуальными замер и проверку остальных узлов.
Результат: повторная работа ограничена областью изменения.
Координатор открывает заказ со статусом «Готов к производству», проверяет итоговый состав и формирует пакет: актуальные файлы, спецификацию, лист решений и перечень закрытых замечаний. Система фиксирует время и автора передачи.
Результат: производство получает один согласованный комплект.
Первая версия замыкает путь от замера до производственного пакета. Ограничение масштаба — пилот одной команды и новые кухонные заказы, а не исключение этапов после замера.
ИИ не является ключевой частью MVP. Пока нет накопленного набора качественных проектов и ошибок, явные правила и обязательные проверки надёжнее. Учётная система остаётся снаружи: двусторонний обмен после стабилизации строится через интеграцию Laravel с 1С, а Laravel ведёт версии, проверки и производственный пакет.
Ценность создаётся внутри карточки заказа. Дизайнер и технолог возвращаются в актуальную ревизию и видят причинную связь: какое изменение открыло замечание и что блокирует передачу в производство. Пользователь не может произвольно выбрать статус, который не соответствует данным.
Статусы рассчитываются системой: «Замер назначен»; «Замер требует уточнения»; «Проектируется»; «Ожидает решения клиента»; «На технологической проверке»; «Есть замечания»; «Готов к производству»; «Передан в производство».
Для MVP подходит единое Laravel-приложение в формате модульного монолита. Рабочая область заказа требует динамических форм, сравнения ревизий и обновления связанных блоков, но отдельный frontend-сервис и публичный API пока не дают практической пользы.
Client
Рабочая область заказа, очередь технолога и адаптивная форма замера без отдельного frontend-сервиса. Vue закрывает панели, сравнение ревизий и формы; Inertia сохраняет единый репозиторий.
API
Модули: пользователи и роли, заказы-проекты, замеры, ревизии и комплектация, согласования, технологическая проверка, производственные пакеты, уведомления и аудит. Между модулями передаются доменные события внутри приложения.
Data
Связанные сущности, история ревизий и структурированные параметры комплектации. Поиск по заказам, клиентам и номерам ревизий закрывается индексами PostgreSQL.
Queue
Создание превью, сборка пакета и отправка уведомлений. Объём фоновых заданий умеренный: Redis и Horizon в MVP не входят.
Storage
Файлы доступны нескольким сотрудникам и сохраняются вместе с версиями. В PostgreSQL остаются метаданные и права доступа.
Infrastructure
Один production-сервер для первой нагрузки. Pest покрывает критичные правила ревизий и готовности. Playwright проверяет маршрут «замер → ревизия → проверка → производственный пакет».
Для обновления очереди достаточно периодического запроса: события не требуют постоянного WebSocket-соединения. Микросервисы, Kubernetes и отдельное мобильное приложение не дают пользы: адаптивная форма закрывает сценарий замерщика, продукт разворачивается как одна система.
Внедрение рассчитано на 12 недель и разделено на четыре этапа. Сначала закрепляются правила версии, затем автоматизация. Ключевой риск — попытка сохранить привычный процесс и использовать систему только как архив.
Обязательные поля замера, типы замечаний, структура комплектации и условия готовности. Из существующих проектов выбираются примеры типичных и проблемных заказов.
Карточка заказа, замер, ревизии, комплектация, проверки и журнал действий. На тестовых заказах проверяется, что статус действительно отражает готовность.
Один замерщик, два дизайнера, технолог и координатор ведут в системе только новые кухонные заказы. Старые активные проекты не мигрируются целиком: переносятся лишь те, которые ещё не прошли технологическую проверку.
Разбираются обходы системы, лишние обязательные поля и ложные блокировки. После стабилизации подключаются остальные дизайнеры и второй салон. Старые таблицы переводятся в режим просмотра.
Пилот оценивается не по числу созданных карточек, а по доле заказов, которые прошли весь путь и сформировали производственный пакет без ручной сборки данных из других каналов.
До пилота в течение двух недель фиксируются исходные значения. После запуска те же показатели измеряются на сопоставимой группе новых заказов. После запуска те же показатели считались по журналу системы — это результат внедрения.
| Показатель | Как измерять | Целевое изменение после стабилизации |
|---|---|---|
| Полнота заказа перед проверкой | Заказы со всеми обязательными данными / все переданные технологу | Не менее 90% |
| Повторный ввод данных | Число полей, перенесённых вручную между источниками на один заказ | Снижение не менее чем вдвое |
| Время восстановления контекста | Среднее время от открытия заказа до определения актуальной версии и следующего действия | Не более 5 минут |
| Поздние замечания | Замечания, найденные после статуса «Готов к производству» / все замечания | Не более 10% |
| Заказы без следующего действия | Активные заказы без ответственного и срока / все активные заказы | Не более 5% |
| Срок технологической проверки | Медианное время от передачи ревизии до решения технолога | Снижение на 30% |
| Ручная сборка пакета | Заказы, для которых координатор искал данные вне системы / переданные заказы | Не более 10% |
Задача метрик — проверить, меняет ли продукт управляемость процесса, а не только переносит привычные файлы в новый интерфейс.
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Сотрудники продолжают согласовывать изменения только в чатах | Высокая | Высокое | Сделать решение действительным только после фиксации в ревизии; разбирать обходы на пилоте |
| Обязательных полей становится слишком много | Средняя | Высокое | Разделить поля по типу мебели и этапу; разрешить статус «Требует уточнения» с причиной |
| Структура комплектации не совпадает с привычной работой дизайнеров | Средняя | Высокое | Начать с кухонь и проверить структуру на реальных типовых проектах пилотной команды |
| Файлы из профильной программы меняются без обновления ревизии | Средняя | Высокое | Хранить контрольную версию файла и запрещать тихую замену завершённой ревизии |
| Автоматическая проверка создаёт ложное ощущение технологической гарантии | Низкая | Высокое | Явно разделить проверку полноты и профессиональное решение технолога |
| Интеграция с учётной системой задерживает запуск | Средняя | Среднее | В MVP формировать стандартизированный пакет и оставить перенос в учётную систему отдельной операцией |
После накопления стабильной истории ревизий можно развивать продукт вокруг реальных данных процесса: шаблоны замера и комплектации для разных типов мебели; библиотека повторяющихся технологических узлов; двусторонняя интеграция с учётной системой; связь производственного пакета с закупкой и остатками; клиентское подтверждение выбранных решений в ограниченном кабинете; аналитика повторяющихся замечаний.
После пилота уместны ограниченные ИИ-функции на накопленных данных: рекомендации по проверке на основе похожих ранее найденных конфликтов. Результат должен подтверждать технолог; при нехватке источника корректный ответ — «сведений недостаточно».
До
После
До внедрения команда пыталась синхронизировать файлы, сообщения и память сотрудников. После внедрения она управляет состоянием конкретной версии заказа. Главный результат — контролируемая граница между обещанием клиенту и запуском изделия в производство.
Сжатая цитата из обратной связи после пилотного внедрения. Название компании и имя не указаны из‑за NDA.
«Самое неприятное раньше было, когда вопрос всплывал уже в цеху. Например, размера нет или материал поменяли, а технолог об этом не знал. Сейчас такие вещи стараемся закрывать ещё до передачи заказа.»
Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.
