Чтобы контролировать передачу заявки, недостаточно добавить поле «Статус». Нужно определить, что подтверждает каждый этап, кто отвечает за переход и как обрабатывается задержка.

Для первого пилота на одном участке предлагаем маршрут: «Зарегистрирована» → при необходимости «Требует уточнения» → «Назначена» → «Принята ответственным». Это проектная гипотеза, которую следует проверить на конкретном процессе.

Зарегистрирована: обращение стало учётной записью

В карточке фиксируют номер, время поступления, инициатора, объект или участок и описание задачи. Связанные документы хранят вместе с обращением либо дают на них доступную ссылку.

До принятия исполнителем маршрут должен контролировать определённый сотрудник — например, координатор. Его задача на этом этапе — следить за полнотой карточки и передачей, а не обязательно выполнять саму работу.

Если обращение приходит через форму, почту или интеграцию, нужно проверять фактическое создание записи. Отправленное сообщение само по себе не подтверждает регистрацию заявки.

Требует уточнения: обозначен конкретный пробел

Этот этап нужен только при недостатке данных. В карточке указывают, какой информации не хватает, кто её запрашивает и когда проверит ответ.

Формулировка «ожидаем информацию» без вопроса и даты следующей проверки не помогает управлять маршрутом. Если данных достаточно, заявку сразу передают на назначение.

Назначена: исполнитель выбран

В карточке появляется конкретный ответственный, время назначения и срок подтверждения. Если заявка направляется в подразделение, необходимо определить, кто внутри него принимает её в работу.

Назначение и принятие стоит разделять: выбор исполнителя ещё не подтверждает, что он увидел обращение и согласился с передачей.

Принята ответственным: передача подтверждена

Исполнитель подтверждает получение заявки. Фиксируются следующий шаг и срок следующего обновления.

Принятие не следует автоматически считать началом работ. Например, следующим действием может быть проверка данных или подготовка согласования. Дальнейшие статусы выполнения проектируются отдельно.

Если подтверждение не получено в согласованный срок, координатор проверяет причину. Порядок напоминаний, переназначения и обращения к руководителю необходимо определить до запуска маршрута.

Правила, без которых статусы не работают

Для каждого перехода следует согласовать:

— кто вправе изменить статус; — какие сведения обязательны; — какое событие подтверждает переход; — когда нужно проверить отсутствие движения; — кто действует при задержке.

История изменений должна позволять восстановить передачу: кто, когда и на каком основании изменил статус. При возврате на уточнение важно сохранять причину и конкретный запрос.

Статус, ответственный и срок следующего действия решают разные задачи. Статус показывает этап, ответственный — участника, срок — момент контрольной проверки.

Что проверить в пилоте

Разумная граница первого этапа — один участок и один тип заявок. До оценки нужны владелец процесса, система-источник, разрешённые данные, требования к размещению и безопасности, а также проверяющий специалист.

Полезность маршрута можно оценивать по времени регистрации и поиска, полноте карточек, времени до принятия ответственным, доле исправлений и количеству обращений, оставшихся без подтверждения к согласованному сроку. Критерии и исходные показатели следует зафиксировать до запуска.

Интеграция с 1С, ERP, ТОиР или MES требует отдельного обследования доступов, API и выгрузок. Предложенная схема не является описанием выполненного внедрения и не гарантирует экономию. Её задача — проверить управляемость передачи заявок на ограниченном процессе.

Учёт обращений не заменяет утверждённые производственные инструкции, решения ответственных специалистов или системы управления и защиты оборудования.

Напишите «ЗАВОД» — разберём одну повторяющуюся операцию.