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