Приёмка строительных этапов в Битрикс24: акты, замечания и разрешение следующих работ
Перемещение карточки в канбане ещё не подтверждает готовность объекта. Разбираем, как связать этап строительства с объёмом работ, проверкой, замечаниями и принятой редакцией акта.
Прораб прикрепил фотографии и отметил этап выполненным. Технический специалист обнаружил замечания, но следующая бригада уже вышла на объект. В чате спорят, кто разрешил продолжение работ, а в CRM зелёная стадия выглядит как окончательная приёмка.
Чтобы избежать такой ситуации, нужно разделить заявление исполнителя, проверку и решение уполномоченного сотрудника. Предлагаемая схема помогает организовать этот маршрут в Битрикс24; она не заменяет строительный контроль и установленный компанией порядок оформления документов.
У объекта есть адрес, заказчик, договор и участники. У этапа — конкретный состав работ, версия задания, сроки и зависимости. Проверка фиксирует, кто и что осмотрел, какие отклонения обнаружил и какое решение принял. Один объект может иметь несколько параллельных этапов и повторные проверки после исправлений.
Поэтому одной сделкой со стадиями «демонтаж — черновые — отделка» удобно пользоваться только в простом последовательном процессе. Если на разных этажах работы идут независимо, нужна более подробная модель. Задачи подходят для исполнения поручений; связанные карточки этапов — для реестра состояния и приёмки. Возможность связать смарт-процессы с CRM и задачами описана в руководстве Битрикс24 .
Зафиксируйте предмет сдачи до загрузки фотографий #
Этап должен отвечать на вопрос «что именно принимаем». Полезны зона объекта, перечень работ, согласованная редакция задания и критерии проверки. Фотографии без привязки к помещению, дате и проверяемому пункту плохо подтверждают результат: позднее нельзя понять, к какой версии работ они относятся.
Изменение объёма оформляют отдельно. Если заказчик добавил работы, это должно отражаться в новой редакции задания и согласовании условий. Переписывание исходного описания задним числом лишает историю смысла: старый акт начинает выглядеть как подтверждение того, чего в момент подписания не было.
В CRM можно требовать заполнения полей на стадии; для смарт-процессов следует использовать их настройки пользовательских полей . Но наличие вложения ещё не говорит, что загружен нужный акт, что он относится к этому этапу и что решение принял нужный человек.
Для перехода к следующей работе проектируют проверку условий: принята актуальная редакция, нет блокирующих замечаний, решение принято сотрудником с соответствующими полномочиями. Если используется электронное подписание, его подтверждённое состояние получает отдельный источник. Имя файла «подписано.pdf» не является таким подтверждением.
Нужно проверить все пути изменения: интерфейс, мобильное приложение, массовую операцию, роботов и интеграцию. Настройка, которая останавливает только ручное перемещение карточки, не доказывает, что сторонний обработчик не сможет поставить готовую стадию. Способ обеспечения правила выбирают после проверки возможностей конкретной версии портала.
Замечание должно быть самостоятельным поручением #
Общий комментарий «исправить недостатки» не позволяет понять, что осталось сделать. Для каждого замечания нужны место, описание, связь с проверяемым пунктом, ответственный и срок. Фото до и после исправления привязывают к одному замечанию, сохраняя исходные материалы.
Не каждое замечание обязательно блокирует все работы. Компания заранее определяет, какие отклонения останавливают конкретный следующий этап, а какие можно устранить параллельно. Система реализует утверждённые правила и показывает основание исключения. Она не должна сама выводить допустимость продолжения из текста комментария.
После исправления исполнитель сообщает о готовности, а проверяющий подтверждает результат. Закрытие задачи исполнителем и приёмка замечания — разные действия. Если проверка не пройдена, сохраняют новую попытку и причину возврата, а не стирают предыдущий результат.
Связи между работами полезнее одной общей кнопки «объект принят». Если завершена проверка одной зоны, это может открыть работы именно в ней, сохранив блокировку в другой. Для каждого зависимого этапа указывают, какие результаты должны быть получены раньше.
При отмене или пересмотре приёмки нужно определить последствия. Уже начатую работу нельзя незаметно вернуть в исходное состояние автоматическим роботом. Вместо этого фиксируют событие, помечают затронутые этапы как требующие решения и назначают ответственного. История должна показывать, что было разрешено на момент начала работ.
Внешнему участнику может требоваться передать фото, ответить на замечание и увидеть свой срок. Это не означает доступ ко всем договорам и объектам. Можно выбрать согласованное рабочее пространство или отдельную форму с серверной проверкой прав; способ зависит от состава участников и версии Битрикс24.
Проверяют также доступ к самим файлам. Скрытая карточка бесполезна как защита, если материалы другого объекта доступны по прямой ссылке без требуемого ограничения. Руководитель проекта должен видеть состояние своих объектов, а проверяющий — достаточный контекст для решения.
Отправьте этап на проверку с устаревшим актом и незакрытым блокирующим замечанием. Убедитесь, что следующий этап не открывается. Затем исправьте замечание и проведите повторную проверку под уполномоченным сотрудником. Попробуйте тот же переход через интеграцию и проверьте результат отдельно.
После успешной приёмки измените редакцию задания. Система должна сохранить старое решение и показать необходимость оценить затронутые работы. Именно эти сценарии подтверждают контроль процесса; количество фотографий и задач этого не доказывает.
Можно ли использовать только задачи и чек-листы? #
Да, если проект небольшой, этапы простые и решения о приёмке можно однозначно проследить в задачах. При повторных проверках, нескольких подрядчиках и связях между зонами отдельный реестр этапов и замечаний обычно понятнее. Выбор определяется сложностью процесса, а не обязательностью смарт-процессов.
Следует сохранять версии, на основании которых принимались решения, и различать черновик и действующий документ. Порядок хранения и подписания определяет компания. В CRM важно обеспечить связь документа с этапом, редакцией задания и принявшим решение сотрудником.
Свяжите отчёт о готовности с решением о продолжении #
NetLabCS поможет спроектировать этапы, замечания, роли приёмки и проверки переходов. Разработка бизнес-процессов в Битрикс24 подходит для настройки маршрута сдачи и повторной проверки; дополнительные ограничения переходов оцениваются отдельно. Для обсуждения проекта подготовьте один реальный маршрут сдачи работ — с возвратом на исправление и повторным актом. По нему определим, какие действия можно автоматизировать и где требуется решение специалиста.
