Приложение для автопарка: от осмотра до готовности машины

До собственной разработки

Проверьте, где уже ведутся ремонты и плановое ТО.

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

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

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

Модельный сценарий

Шесть машин. У одной замечание перед сменой.

В придуманном примере на Северной базе находятся шесть автомобилей. Три доступны, один выполняет задание, один проходит плановое ТО, а V-024 ожидает проверки. Это условные записи для демонстрации интерфейса: клиент, запуск и результаты BORNLI здесь не заявляются.

Водитель V-024 замечает, что левый задний фонарь не работает, и создаёт запись D-104. Он описывает наблюдение; причину неисправности и дальнейшие действия определяет механик. В модели до завершения проверки диспетчер не назначает эту машину. Такое правило нужно согласовать с владельцем процесса, а не выводить автоматически из свободного текста водителя.

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

Осмотр без связи

«Сохранено на телефоне» ещё не означает «механик получил».

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

Для такой работы предлагаем сохранять идентификатор операции OP-104 вместе с данными осмотра. После восстановления связи приложение отправляет ту же операцию. Если сервер уже создал D-104, но ответ потерялся, повтор должен вернуть существующую запись. Этот механизм необходимо проверить с выбранной системой учёта: одинаковый текст двух замечаний ещё не делает их одним событием.

В истории полезно отдельно хранить время наблюдения и время получения. На обзорном экране примера D-104 уже получен в 08:42; на экране ниже показан более ранний момент, когда запись ещё находилась на телефоне. Для диспетчера отсутствие нового сообщения не должно выглядеть как подтверждение исправности автомобиля.

Ремонт и возврат

Закрытый ремонт не переключает машину в «доступен» сам по себе.

Механик внёс ремонтную запись R-058 по замечанию D-104. В модельном примере восстановлен контакт фонаря. После этого V-024 остаётся на проверке: отдельно нужно зафиксировать контроль и сверить запись ремонта.

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

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

Обмен и первая версия

Для каждого состояния нужен один ответственный источник.

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

• Карточка машины: стабильный внутренний идентификатор, модель, база, назначенные сотрудники и последнее обновление.
• Осмотр: версия чек-листа, наблюдение, время, автор и очередь отправки.
• Ремонт: ссылка на замечание, запись выполненных работ и отдельный результат контроля.
• Доступность: состояние, основание, ответственный и история переходов.

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

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

Приёмка и результат

Проверьте потерю связи, повтор и право вернуть машину в работу.

1. Осмотр без сети. Запишите замечание, закройте приложение и откройте снова. В согласованном режиме автономной работы запись и очередь должны сохраниться.
2. Повтор после потери ответа. Прервите ответ после создания замечания. Повторная отправка той же операции должна вернуть один номер, не два ремонта.
3. Ремонт без контроля. Закройте запись работ. Убедитесь, что готовность не подтверждается автоматически, если в вашем процессе требуется отдельное решение.
4. Чужая роль или устаревшее состояние. Попробуйте подтвердить готовность от имени водителя и после нового замечания другого сотрудника. Система должна проверить права и актуальную версию перед изменением.
5. Ошибочное показание. Передайте пробег меньше принятого ранее. Спорная запись должна попасть на проверку, не меняя молча график ТО.

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

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