ИмпрессАрт — управление ремонтами

Контекст и задача

Клиент / сфера: Производственное предприятие с несколькими участками и собственной технической службой: механиками и специалистами КИП

Пользователи: Операторы участков, механики, специалисты КИП, руководители участков, руководитель техслужбы, администратор

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

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

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

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

Исследование

Изученные процессы и данные

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

Выводы и влияние на решение

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

Решение

Реализованные сценарии

1. Регистрация сотрудника. Руководитель создаёт пользователя: ФИО, роль, участок. Система генерирует шестизначный код. Сотрудник вводит в боте ФИО и код, после чего его аккаунт привязывается. Администратор и руководители участка получают уведомление о запросе регистрации.
2. Рабочая смена. Сотрудник начинает и завершает смену. Руководитель участка получает уведомление об этом. Руководитель при начале и окончании своей смены получает список незакрытых заявок. Доступен просмотр сотрудников на смене.
3. Создание заявки. Оператор выбирает участок, оборудование и узел, тип ремонта, описывает проблему и прикладывает одно фото или альбом.
4. Работа техслужбы. Механик или КИП видит новые заявки и принимает одну из них. К уже принятой заявке он может присоединиться как дополнительный исполнитель. Затем отмечает «Приступил к ремонту» и «Ремонт завершён». При завершении указывает отремонтированный узел, обязательное описание работ и фото.
5. Приёмка результата. Инициатор принимает ремонт, и заявка закрывается. Если не принимает, указывает причину и прикладывает фото, а заявка переходит к руководителям для решения.
6. Управление исполнителями. Руководитель техслужбы добавляет или заменяет исполнителя из сотрудников на смене. Руководитель участка передаёт заявку другому оператору участка.
7. Контроль сроков. Если заявка остаётся в статусе «Новая» дольше заданного времени (по умолчанию 15 минут), назначенные ответственные получают уведомление.
8. Отчётность. Ежедневно в 10:00 по Москве руководители получают отчёт Excel за предыдущие сутки. Тот же отчёт можно выгрузить по кнопке.
9. Управление пользователями. Создание, поиск по ФИО, активация и деактивация сотрудников.
10. Просмотр материалов. Фото заявки, ремонта и отклонения доступны из карточки заявки.

Подход к решению

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

Технологии

Python, python-telegram-bot, PostgreSQL, SQLAlchemy, Alembic, APScheduler, openpyxl, Docker, GitLab CI/CD

Результат

Что реализовано

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

Дальнейшее развитие

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

Текущий статус

Сборка Docker-образа и развёртывание через GitLab CI настроены для ветки разработки.

Ограничения

• Интерфейс только в Telegram, веб-панели для руководителей нет.
• К заявке, ремонту и отклонению прикладываются только фотографии.
• Отчёт, в том числе выгружаемый вручную, формируется за предыдущие сутки.
• Уведомления получают только сотрудники с активной сменой.
• Длина комментариев по умолчанию ограничена 256 символами.