Планирование ТО и ремонтов автопарка: от графика до заявки

Грузовик вернулся из рейса, до следующей загрузки есть свободное время. Механик собирается отправить его на обслуживание, но сначала приходится искать историю работ, запрашивать СТС у водителя, уточнять реквизиты для счёта и выяснять, готов ли сервис принять машину. Свободное время уходит на подготовку, хотя само ТО ещё не началось.

В GruzHub уже заложена основа для такой подготовки: данные парка и документы техники, реквизиты и контакты компании сохраняются в личном кабинете и подставляются в заявку. Сотрудник дополняет обстоятельства конкретного обращения вместо повторного ввода сведений о машине и компании. Это позволяет избежать повторного сбора сохранённых сведений ещё до начала обслуживания.

Планирование обслуживания стоит начинать до возвращения техники. Сначала определить, какие работы нужны и на каком основании, затем согласовать доступность машины и СТО, подготовить данные и закрыть вопросы по комплектующим. Ниже — порядок для механика, диспетчера и руководителя автопарка. График обслуживания можно вести в принятой у компании системе учёта, а уже предусмотренные возможности GruzHub использовать для подготовки заявок, взаимодействия с исполнителями и сохранения согласований.

Начните с карточки техники и истории работ

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

Для подготовки плана соберите в карточке:

• марку, модель, год выпуска и VIN;
• СТС и другие документы, которые понадобятся при обращении в сервис;
• текущий пробег, а для соответствующего учёта — моточасы и дату снятия показаний;
• дату, пробег и состав последнего обслуживания;
• незавершённые рекомендации сервиса и замечания водителя;
• контакт ответственного механика и водителя;
• документ, по которому определяется следующее обслуживание.

Не заменяйте историю одной записью «ТО сделано». По ней трудно понять, какие операции выполнили, что только осмотрели, а что перенесли. Запись должна отсылать к заказ-наряду и содержать фактический результат. Если документов о предыдущем обслуживании нет, отмечайте это как неизвестность: отсутствие записи не доказывает ни выполнение, ни невыполнение работ.

В личном кабинете GruzHub сохраняются данные парка — марка, модель, год, VIN — и документы техники. Отдельно сохраняются реквизиты компании и контакты сотрудников. Эти сведения подставляются в заявку, поэтому при следующем обращении не нужно заново собирать весь комплект. Для механика это меньше запросов водителю «пришли СТС ещё раз», для диспетчера — меньше поиска нужного контакта. При подготовке графика используйте такую карточку как источник идентификационных данных, а сведения о регламенте и фактических работах проверяйте по своим документам.

Возьмите основание для ТО, а не универсальную цифру

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

У производителей есть подходы, учитывающие особенности конкретной машины. Scania в описании Flexible Maintenance указывает, что индивидуальный план учитывает текущую эксплуатацию и её историю, включая нагрузку и условия работы. Это пример принципа планирования, а не основание назначить одинаковый интервал всему парку. Scania.

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

Если точное основание пока не найдено, задача механика — восстановить его до назначения интервала. Не заполняйте пустое поле значением «как у остальных». Особенно внимательно разбирайте машины с неизвестной историей и сменившимися условиями работы.

Соедините технический план с планом рейсов

Дата следующего обслуживания и дата, когда машина реально сможет приехать в СТО, — разные записи. Первую определяют требования к обслуживанию. Вторую согласуют механик и диспетчер с учётом рейсов, расположения техники и возможностей исполнителя. Задача — подобрать подходящее окно внутри допустимых условий, а не подвинуть требование под удобную загрузку.

Для начала достаточно рабочей таблицы. Она не обязана быть сложной, но каждая строка должна отвечать на вопрос: кто и что делает дальше.

Поле плана	Что записать	Кто уточняет
Техника	Идентификатор машины, ссылка на карточку	Механик
Основание	Регламентная операция или конкретное замечание	Механик
Срок или критерий	Значение из применимой документации	Механик
Доступность	Когда и в каком регионе техника освободится	Диспетчер
Исполнитель	Кто подтвердил профиль работ и приём	Ответственный за заявку
Комплектующие	Что согласовано, что ещё требуется уточнить	СТО и заказчик
Следующее действие	Задача, ответственный и контрольная дата	Владелец задачи

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

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

Подготовьте заявку, пока техника ещё в рейсе

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

В заявке пригодятся СТС тягача и, при необходимости, прицепа с VIN, телефон водителя или механика, местонахождение техники и направление движения. Для оформления отношений с компанией — карточка партнёра с реквизитами ООО или ИП. Документы и контакты из личного кабинета GruzHub используются при формировании заявки; текущие обстоятельства обращения сотрудник дополняет по ситуации. Такая подготовка уже предусмотрена на платформе: повторяющиеся сведения берутся из сохранённых данных, а внимание сотрудника остаётся на конкретной задаче и условиях приёма.

Точку и направление движения водитель может указать в описании обращения: принимающему СТО важно знать, где находится техника. Для планового визита уточняйте ещё и предполагаемое место после завершения рейса — текущая точка сама по себе не объясняет, куда машина сможет приехать к согласованному времени.

У профильного СТО уточните, может ли оно принять заявку с учётом своей специализации и загрузки. В описании поэтому важны сведения, которые помогают оценить конкретную работу: техника, задача, материалы, доступность машины. Ответ сервиса и условия приёма всё равно должны быть согласованы — наличие заявки не означает, что пост уже забронирован.

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

Согласуйте работы, комплектующие и границы решения

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

По комплектующим заранее уточните, кто подбирает и закупает позиции, на каких данных основан подбор, где подтверждено наличие и к какому сроку ожидается поставка. Сохраните ответ поставщика или СТО вместе с обсуждением. Для сравнения предложений запрашивайте сопоставимый состав: одна и та же позиция, количество, условия поставки и включённые работы. Иначе более низкая сумма может относиться к другому объёму заказа.

VIN уже хранится в карточке техники GruzHub и используется в данных заявки. Подбор запчастей, наличие на складах региона и условия предложений уточняйте у СТО и поставщиков. Сохранённый VIN сам по себе не подтверждает наличие конкретной детали, её применимость или стоимость для вашей машины.

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

Сохраняйте результат, а не только счёт

В GruzHub сохраняются сообщения согласований, документы контрагентов, фотографии и видео. Используйте это для связи между первоначальным обращением и результатом: какие симптомы были описаны, что обнаружили при проверке, какие работы согласовали и что выполнили. Материалы должны помогать восстановить ход конкретного заказа. Их сохранение уже предусмотрено на платформе: представителю транспортной компании и сотруднику СТО проще вернуться к условиям и документам обращения, чем заново собирать их по отдельным разговорам.

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

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

Для СТО такая последовательность тоже удобна: данные машины, условия и решения собраны в одном обращении. При уточнении заказа не нужно заново выяснять, какой автомобиль обсуждался и к какому объёму работ относилась договорённость. Качество ремонта при этом оценивают по выполнению согласованных работ и проверкам результата, а не по самому факту сохранения переписки.

Проверьте историю обращения перед разбором задержки

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

Для проверки заведите отдельный ручной лист. Его задача — связать каждое утверждение с исходной записью и определить, что уже установлено, а что нужно уточнить. Данные парка, документы, контакты и согласования можно сохранять в GruzHub. Описанный ниже лист сотрудники заполняют отдельно; он не предполагает наличия на платформе журнала событий, выгрузки или автоматического анализа.

Все шесть случаев — оригинальное учебное упражнение редакции GruzHub, 2026. Обращения, обозначения и часы вымышлены; реальные люди и машины не используются. Это не норматив сроков и не способ измерить производительность механика.

Подготовьте лист и сохраните исходные строки

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

Поле ручного листа	Что записать
Исходная запись	Источник, ссылка и исходный идентификатор события, если он есть
Обращение	Точный идентификатор ремонтного обращения
Визит	Отдельный идентификатор, если он нужен и известен
Смысл события	Что сообщает запись: отправка, ответ, получение материала или исправление
Время события	Дата, время и числовое смещение; неизвестные составляющие обозначить явно
Время регистрации	Когда запись внесли; время импорта при необходимости указать отдельно
Связь исправления	Какая исходная строка исправляется
Результат проверки	Подтверждено, повторное отражение, конфликт, исправление или недостаточно данных
Допустимое утверждение	Что можно сказать по проверенным материалам
Вопрос владельцу источника	Какое конкретное уточнение ещё требуется

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

Случай A. Две строки E11 относятся к одному событию

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

Теперь допустим вывод: в таблице две строки, но отражённое ими событие одно. Сохраните обе импортированные строки. Только в рабочем представлении пометьте вторую как повторное отражение E11, чтобы не использовать её как самостоятельное событие.

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

Вопрос владельцу источника: «Гарантирует ли ваш идентификатор уникальность события в этом источнике и относятся ли обе строки к одной исходной записи?» Пока ответ и равенство содержимого не проверены, отметка остаётся «возможный дубль».

Случай B. Один E12 содержит два разных сообщения

В следующем независимом случае обе строки имеют идентификатор E12, но одна сообщает «обращение отправлено», другая — «обращение принято». Их содержание различается, поэтому правило из случая A неприменимо.

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

В листе допустимо написать: «Под E12 обнаружены разные сведения; принятие по этому набору не установлено». Вопрос владельцу источника: «Что обозначает E12, почему содержание различается и где находятся исходные записи отправки и принятия?» До уточнения не объединяйте версии в последовательность двух подтверждённых действий.

Случай C. Событие произошло в 10:00, запись появилась в 12:00

В этом примере источник сообщает о событии в 10:00, а оператор внёс запись в 12:00. По условию обе отметки относятся к одной дате, одному смещению и сопоставимым часам. Разность составляет два часа.

Эти два часа характеризуют задержку внесения записи в рамках учебного условия. Точность исходных часов не установлена, поэтому разность отметок не подтверждает точную фактическую длительность. Она также не показывает, сколько механик отвечал, работал или бездействовал: для таких выводов здесь нет соответствующих событий начала и окончания.

В программной модели OpenTelemetry различаются время события и время его наблюдения системой сбора. Раздельные поля нашего ручного листа — редакционная аналогия; ручное внесение не тождественно такому наблюдению.

Запишите оба времени и смысл разности. Если известен только момент импорта, оставьте время события неизвестным. Вопрос источнику: «Чем подтверждается 10:00 и что именно означает отметка 12:00?» Подстановка времени импорта вместо отсутствующего времени события не восстановит длительность задержки.

Случай D. Отображаемые часы дают другой порядок

Для двух отметок явно выбрана одна учебная дата — 15 октября 2026 года. Первая запись содержит 09:30+03:00, вторая — 11:00+05:00. По показаниям часов вторая кажется более поздней.

При приведении к UTC получаем:

Исходная отметка	Та же отметка в UTC
2026-10-15 09:30+03:00	2026-10-15 06:30Z
2026-10-15 11:00+05:00	2026-10-15 06:00Z

Следовательно, вторая отметка соответствует моменту на 30 минут раньше первой. Здесь используется правило числового смещения: для получения UTC смещение вычитают из местного времени. Обозначение Z соответствует UTC.

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

Если по смыслу первая запись — запрос, а вторая — ответ, неожиданная последовательность требует уточнения. Сохраните исходные отметки рядом с пересчитанными. Спросите владельца источника: «Верны ли даты и смещения, проверены ли часы и действительно ли эти записи обозначают связанные запрос и ответ?» До ответа не называйте отрицательную разность длительностью реакции.

Случай E. Исправление вложения сохраняет открытый вопрос

В исходной строке E21 на 10:10 записано «смета получена». В 11:20 добавлено исправление C21: «прикреплено неверное вложение», со ссылкой на E21. Вид этих двух временных отметок в условии не задан, поэтому длительность между действиями не рассчитываем.

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

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

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

Случай F. Ответ оказался выше запроса

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

Проверьте ссылку и принадлежность к точному обращению. Если связь подтверждена, можно записать: «Ответ относится к этому запросу». Числовую длительность между ними установить нельзя. Перестановка строк сделает чтение удобнее, но не добавит недостающих временных отметок.

При необходимости уточните визит. По выбранным компанией определениям одно обращение может включать несколько визитов, а один визит — несколько этапов. Это не универсальная схема: для листа важно, чтобы участники одинаково понимали идентификаторы.

Вопрос источнику: «На какой запрос ссылается ответ, к какому обращению и визиту он относится и сохранились ли времена самих событий?»

Перенесите решения в рабочий лист

Ниже один учебный лист разделён на две части с общей колонкой случая. В первой сохранены исходные сведения, во второй — решения проверки. Для всех случаев точный идентификатор обращения, визита и рабочая ссылка на источник не заданы: в этих полях остаётся «не задано». Обозначения A–F помогают читать упражнение, но не заменяют реальные идентификаторы.

Случай	Исходная запись и связь	Время события	Время регистрации / импорта	Исправление
A	Две равные копии E11 из одного источника; уникальность проверена	Не задано	Не задано	Нет в условии
B	Две строки E12: отправлено / принято; содержание конфликтует	Не задано	Не задано	Не задано
C	Источник сообщает о событии в 10:00; оператор внёс в 12:00	10:00; общая дата и одинаковое смещение заданы без конкретных значений; часы сопоставимы по условию, точность не установлена	Внесение 12:00 при тех же условиях; импорт не задан	Нет в условии
D	Две отметки; их принадлежность и связь ещё проверяются	2026-10-15 09:30+03:00 и 2026-10-15 11:00+05:00	Не задано	Нет в условии
E	E21: «смета получена», отметка 10:10; C21: неверное вложение, отметка 11:20	Вид видимых отметок не задан	Вид видимых отметок не задан	C21 ссылается на E21
F	Ответ содержит ссылку на запрос; ссылка и принадлежность требуют проверки	Оба времени неизвестны	Известен порядок внесения: ответ внесён раньше запроса; числовых отметок нет	Нет в условии

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

Случай	Результат проверки	Допустимое утверждение	Что уточнить
A, E11	Подтверждённое повторное отражение	Две импортированные строки отражают одно событие	Основание уникальности и равенства сохранить рядом
B, E12	Конфликт содержания	Принятие не установлено	Значение ID и исходные записи
C	Разные виды времени	Разность отметок внесения и события — два часа при заданных условиях; точность фактической длительности не установлена	Основание и смысл каждой отметки, точность часов
D	Разный порядок после пересчёта	06:00Z предшествует 06:30Z	Даты, часы и связь событий
E	Связанное исправление	Неверное вложение отмечено; правильная смета неизвестна	Надлежащее вложение и получение
F	Связь без измеримой длительности	При подтверждении ссылки ответ относится к запросу	Принадлежность и времена событий

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

Как выбрать ближайшее окно, если свободная машина ещё не означает замену

Рассмотрим самостоятельный вымышленный пример редакции GruzHub. Для тягача А согласованы плановые работы и приём в СТО; обслуживание ещё не началось. Диспетчер предлагает отправить А в подтверждённый рейс. Тягач Б свободен, его текущее техническое состояние подтверждено, но соответствие требованиям задания не проверено. У тягача В остаётся открытым вопрос топливной подготовки к маршруту. Ни одна из этих записей сама по себе не определяет, кому ехать и чьё обслуживание переносить.

Разделите основания выбора

Предмет решения	Что известно	Чего не хватает
Техническая готовность	Состояние Б подтверждено; по В открыт вопрос подготовки	Применимые ограничения обслуживания А и основание оценки подготовки В
Потребность рейса	Задание подтверждено, Б свободен	Соответствует ли Б требованиям задания и будет ли доступен на весь рейс
Обязательства по обслуживанию	Для А согласованы работы и приём	Возможны ли изменения договорённости и на каких условиях

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

Сначала проверьте замену

Заполненное решение на текущий момент: проверить Б как замену, сохранив согласованное окно А. Диспетчер сопоставляет Б с требованиями задания и уточняет его доступность. Механик проверяет применимые ограничения обслуживания А. Ответственный за заявку сохраняет действующую договорённость со СТО: предложение диспетчера ещё не меняет согласованный заказ. Для отдельного разбора изменений пригодится материал о том, как учитывать изменение уже подтверждённого заказа.

Если Б подходит и его выпуск оформлен установленным порядком, А сохраняет окно обслуживания. Если замена не подтверждается, диспетчер передаёт конфликт ответственному за планирование: нужно согласовать другое решение по рейсу и обслуживанию. Перенос А можно обсуждать только в пределах применимых требований и после уточнения условий СТО. Новое окно пока не обещано.

Тягач В в этом выборе остаётся неподтверждённой заменой. Открытый вопрос топлива не доказывает неисправность, однако подготовка к данному маршруту не завершена. Механик получает задачу установить, какого основания оценки не хватает, и получить его до решения об использовании В. Ответ только о другой машине или другом маршруте этот вопрос не закрывает. Подробности — в материале «Проверка топлива для конкретного маршрута».

Зафиксируйте решение до назначения техники

В рабочем плане запишите: окно А остаётся согласованным; назначение Б требует подтверждения диспетчера и оформления выпуска; вопрос В передан механику. Контрольный момент — до окончательного назначения машины на рейс. Пересмотр запускают результат проверки Б, изменение задания или новый ответ СТО; ответственный за заявку доводит изменения договорённости до участников. В GruzHub можно сохранить данные техники, документы, контакты и согласования, на которые ссылается запись. Сам выбор окна сотрудники фиксируют в рабочем плане.

Разбирайте простой по причинам

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

Чтобы оценивать организацию обслуживания, отделяйте время самих работ от ожидания. Машина может находиться у исполнителя, пока уточняют комплектующие, ждут решения заказчика или согласуют изменившийся объём. Общая продолжительность визита не показывает, какой именно этап стоит улучшить.

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

На разборе спрашивайте конкретно: какие сведения пришлось повторно запрашивать, какое решение задержалось, какие материалы не подготовили к визиту. Выберите одно изменение для следующего заказа — например, назначить согласующего до передачи техники. Так оценка сервиса и собственной команды будет опираться на ход работы, а не только на впечатление от длительности простоя.

Не обещайте экономию «в несколько раз» до измерений. Сравнивайте сопоставимые обращения и отмечайте различия в объёме ремонта, наличии запчастей и условиях. Цель платформы в этом процессе — сократить повторный сбор данных и сделать согласования доступными участникам. Размер экономии для конкретной компании нужно проверять по её результатам.

Пример: подготовка планового визита

Рассмотрим условную ситуацию, не реальный заказ. У тягача запланировано обслуживание по его документации, а после рейса появится время для визита. Водитель также сообщил замечание, причину которого ещё предстоит установить. Механик разделяет обращение на регламентные работы и проверку этого замечания, не назначая ремонт до диагностики.

Диспетчер уточняет, где техника освободится и какие ограничения есть по следующей загрузке. Ответственный выбирает карточку машины, использует сохранённые документы, реквизиты и контакты, добавляет обстоятельства обращения. Профильное СТО оценивает задачу и согласует условия. До передачи техники стороны уточняют необходимые материалы и порядок дополнительных решений.

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

От истории обращений к обслуживанию по состоянию

Накопленная история помогает сформулировать вопросы для анализа: какие замечания повторяются, какие работы уже выполнялись, при каких условиях возникала проблема. Но набор заказ-нарядов сам по себе не позволяет достоверно предсказать дату отказа узла.

Scania связывает индивидуальное планирование с эксплуатационными данными машины. Практический вывод для автопарка — сначала наладить качество исходных записей и связь с конкретной техникой. Функции производителя не следует приписывать GruzHub. Описание Scania.

Уже сейчас в GruzHub можно использовать сохранённые данные парка и материалы заявок для более организованной работы транспортной компании и СТО. Это не подтверждает наличие предиктивных ремонтов или автоматического прогноза. Обещание автоматического прогноза требует отдельного подтверждения готовности функции и проверки её результатов.

Подключите автопарк и начните с одного обращения

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

Подключить автопарк к GruzHub — сохраните данные компании и техники для следующих заявок. Условия подключения представлены на отдельной странице.

Частые вопросы

Можно ли составить один график для всего парка?

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

Нужно ли переносить всю историю перед первой заявкой?

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

GruzHub уже рассчитывает график ТО автоматически?

В этой статье описан процесс, который организуют сотрудники компании. Возможности GruzHub здесь — сохранённые данные парка, подготовка заявок, взаимодействие с профильными СТО и хранение согласований и материалов. Автоматический расчёт графика не заявляется.

Что делать с дополнительными работами, найденными в СТО?

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

Источники

• Scania — Services 360 Core, описание Flexible Maintenance.

Источник повторно проверен 15 октября 2026 года. Он поясняет подход производителя к планированию обслуживания и не заменяет документацию на конкретную машину.

Для нового учебного раздела использованы: OpenTelemetry — Logs Data Model, поля Timestamp и ObservedTimestamp; OpenTelemetry — General logs attributes, идентификатор записи; G. Klyne, C. Newman — RFC 3339, 2002, раздел 4.2. Проверены 15 октября 2026 года. Это источники о программных журналах и записи времени. Перенос различий в ручной лист — авторская учебная модель редакции, а не отраслевой стандарт, транспортный регламент или описание функций GruzHub.