Подрядчик сообщает о завершении работ и отправляет фотографии в мессенджер. Представитель заказчика находит замечания, пересылает их по почте и уезжает на другой объект. Через неделю приходит акт на весь объём, а бухгалтерия не понимает, что действительно проверено и принято.
Портал подрядчиков помогает собрать в одной цепочке задание, предъявленный результат, замечания и подтверждённый объём. Его задача — сделать основания для дальнейшего оформления понятными. Загрузка отчёта и нажатие кнопки не должны автоматически означать завершение всей процедуры приёмки.
Разделите четыре состояния работы
Назначено означает, что подрядчик получил согласованное задание. Предъявлено — сообщил о выполнении определённого объёма. Проверено — заказчик сопоставил результат с установленными критериями. Принято — уполномоченный участник подтвердил объём по принятому порядку.
Внутри проверки возможны замечания и повторное предъявление. Статус должен относиться к конкретной позиции или этапу, а не только ко всему договору. Иначе одно незавершённое действие либо блокирует всё, либо теряется за общей отметкой.
Документальное оформление и полномочия участников определяют отдельно. Портал может подготовить данные для акта, но его внутренний статус сам по себе не заменяет согласованную процедуру и необходимые документы.
Опишите предмет работы до отчёта
Для каждой позиции нужны объект, место, содержание, единица измерения, согласованный объём и проверяемый результат. Прикрепите актуальную версию задания и необходимые материалы.
Фраза «Выполнить обслуживание помещения» слишком неопределённа для последующей проверки. Полезнее назвать зоны, операции и признаки завершения. Если часть результата нельзя подтвердить фотографией, заранее укажите другой способ проверки.
Изменение задания должно иметь версию и основание. Подрядчик, выполнивший работу по согласованной редакции, не должен внезапно получить замечание по новой, о которой не был уведомлён. При этом фактическая необходимость изменить требования остаётся видимой и рассматривается отдельно.
Учебный пример обслуживания двадцати узлов
Представим условную компанию, которая поручила подрядчику плановое обслуживание двадцати вентиляционных узлов на одном объекте. Это пример организации данных, не кейс ExtentLab и не инструкция по техническому обслуживанию.
Каждый узел имеет внутренний номер и отдельную позицию задания. Подрядчик предъявляет пятнадцать выполненных позиций. Заказчик принимает двенадцать, по трём фиксирует замечания, ещё пять пока не предъявлены.
Общая картина: назначено двадцать, предъявлено пятнадцать, принято двенадцать. Нельзя сказать, что выполнено 75% и столько же принято: 15 из 20 — доля предъявленных позиций, а 12 из 20 — доля принятых, то есть 60%.
Через два дня подрядчик повторно предъявляет три позиции. Две принимают, одну возвращают с уточнением. Принятый итог становится четырнадцать, а не семнадцать: повторное предъявление не добавляет новые работы к исходному объёму. Остаются одна позиция с замечанием и пять непредъявленных.
Отчёт должен ссылаться на позицию
Подрядчик выбирает конкретную работу и указывает предъявляемый объём, дату, исполнителя и необходимые подтверждения. Фотографии и файлы связываются с этой позицией, а не просто складываются в общую папку.
Минимальный состав отчёта:
- номер задания и версия;
- объект и позиция;
- заявленный результат;
- количество в согласованной единице;
- дата выполнения;
- требуемые материалы;
- отклонения от задания;
- контакт для уточнения.
Повторная загрузка того же файла не доказывает новую работу. Если подрядчик исправляет ошибку в отчёте, сохраняйте причину и предыдущий вариант. Для больших объёмов можно поддержать пакетную отправку, но проверяемые связи с позициями должны оставаться.
Замечание должно вести к действию
У замечания нужны конкретный предмет, основание, ожидаемое исправление, ответственный и способ повторной проверки. Формулировка «Не соответствует» без пояснения создаёт новую переписку.
Например, по позиции У-07 отсутствует предусмотренное подтверждение результата. Проверяющий указывает, какой материал требуется и почему. Это отличается от замечания к качеству самой работы: устранение может заключаться в дополнении отчёта, а не повторном выполнении операции.
Подрядчик отвечает в той же карточке, чтобы история не распадалась на разные каналы. После исправления замечание переходит на проверку. Закрыть его вправе назначенная роль, а не тот, кто сообщил об устранении.
При несогласии предусмотрите отдельный разбор. Повторная отправка того же текста не должна бесконечно увеличивать число замечаний и искажать отчёт.
Частичная приёмка требует устойчивых связей
Если позицию можно принимать частями, задайте единицу и способ идентификации принятого объёма. Для обслуживания отдельных узлов это номера объектов. Для других работ могут потребоваться участки, этапы или иные границы.
В системе должны различаться согласованный, предъявленный, принятый и оставшийся объём. Принятое нельзя повторно включать как новое основание при следующем отчёте. Если прежнее решение корректируют, сохраняют отдельное изменение с причиной.
Перед подготовкой данных для акта покажите, какие принятые позиции уже вошли в предыдущие документы, какие предлагаются сейчас и какие остаются на разборе. Точный порядок оформления устанавливается в рабочем процессе компании; программа должна поддерживать его без скрытого двойного включения.
Права внешнего участника
Подрядчик видит только свои задания, относящиеся к ним замечания и разрешённые материалы. Ему не требуется доступ ко всем объектам компании или условиям конкурентов.
Разделите исполнителя, руководителя подрядчика, проверяющего и участника, подтверждающего принятие. В небольшой компании роли могут совмещаться, но полномочия должны оставаться понятными. Возможность загрузить файл не должна автоматически давать возможность принять объём.
Проверьте замену сотрудника, временное отсутствие проверяющего и закрытие доступа подрядной организации. Незавершённые действия должны переходить назначенному человеку, сохраняя авторство предыдущих решений. Общая учётная запись на всю организацию затрудняет восстановление фактов.
Когда достаточно готового портала
Готовая система задач или документооборота может подойти, если работы имеют простую структуру, а требуемые роли и подтверждения поддерживаются настройкой. Начните с проверки частичной приёмки и повторного предъявления.
Заказной модуль стоит обсуждать, когда принятый объём нужно связывать с конкретными объектами, несколькими действующими программами и особым порядком оформления. Сложность часто находится в этих связях, а не в форме загрузки фотографий.
Первая версия может охватывать один вид работ и одного типичного подрядчика. Нужны задания, отчёты по позициям, замечания, повторная проверка, подтверждённый объём и выгрузка согласованного набора для дальнейшего оформления. Автоматическую оценку изображений и управление всеми договорами можно оставить за рамками.
Как проверить портал на реальной процедуре
Подготовьте обезличенное задание с частичным выполнением и двумя видами замечаний. Пройдите пример с двадцатью позициями и убедитесь, что после повторного предъявления итог остаётся четырнадцать.
Добавьте ошибочную позицию, повтор отправки, изменение задания и замену проверяющего. Проверьте, что другой подрядчик не получает доступ к материалам, а каждая принятая работа имеет понятное основание. Выгрузка должна совпадать с выбранным подтверждённым объёмом.
Организовать такую проверку поможет статья о пользовательской приёмке. Для обсуждения с ExtentLab достаточно одной процедуры и набора её документов. Это позволит определить границы портала, оценить готовые средства и выделить функции, без которых первый запуск не решит проблему разрозненных отчётов.