Бизнес-процессы Service Desk

Основа: исходники и просмотр под ролью системного администратора 19.10.2026. Метка [код] означает реализованную ветку, [UI] — увиденный экран, [уточнить] — правило не подтверждено владельцем процесса. Работа под клиентом, менеджером и инженером не проводилась.

Сущности и роли

Компания (инфоблок 29) связана с соглашением/договором (30), договор — с объектом обслуживания (31), обращение (32) ссылается на договор, объект, автора, статус, инженера и сроки; отдельная история (33) фиксирует действия. Инженеры (34), настройки уведомлений (54), праздничный календарь highload-блока 1 дополняют процесс. В объектах есть идентификаторы 1С; в /call/ есть CRM REST и форма Битрикс24. Реальная схема обмена требует уточнения.

userInit() создаёт настройки уведомлений при входе, если не найдено записей. Это важно для описания побочных эффектов авторизации.

1. Создание обращения

As-is [код/UI]: клиент выбирает договор и объект, тип и описание в /create/. Код рассчитывает номер как MAX+1, получает сроки из договора и календаря, добавляет элемент инфоблока 32 и запись истории 33. В UI после входа форма доступна; отправка не выполнялась. Если клиенту не найден договор, доступные варианты зависят от ветки кода; точное бизнес-правило согласовать.

Разрывы: договор из запроса не сравнивается явно с разрешённым набором непосредственно перед сохранением; номер без атомарной выдачи; описание сохраняется с nl2br и затем выводится через разные ветки; нет очевидной транзакции заявки с историей.

To-be: мастер из 3 шагов с предварительным показом договора и оборудования; серверная проверка объекта/договора/права и типа; атомарные номер, заявка, история; подтверждение с номером и сроками. Клиент видит понятную ошибку, если объект не привязан к договору.

flowchart LR
 A[Клиент выбирает договор] --> B[Выбирает объект или обращение по договору]
 B --> C[Описывает проблему]
 C --> D{Сервер проверил право и данные?}
 D -- нет --> E[Понятная ошибка без записи]
 D -- да --> F[Номер + заявка + история в транзакции]
 F --> G[Подтверждение и уведомление]

2. Разбор и исполнение

As-is [код/UI]: /admin/ показывает широкую таблицу с номером, статусом, договором, оборудованием, адресом, инженером и несколькими датами. /admin/control/ позволяет менять свойства, статус, сроки, инженера и текст; writeLogRequest пишет историю, sendSDNotice вызывается для ряда изменений. Администратор видит карточку и таблицу; работу менеджера не проверяли. Значения SLA видны в списке, но смысл цветов/порядок приоритетов не очевиден.

To-be: очередь по роли с колонками «номер/тема», «клиент и объект», «статус», «следующий шаг», «реакция/решение», «ответственный»; фильтры и сохранённые представления. В карточке — явная шкала: регистрация → реакция → назначение → решение → закрытие. Каждая команда валидирует переход, роль, договор, входные значения и создаёт одну запись аудита. Просрочка имеет текст и время, а не только цвет.

Неопределённости [уточнить]: кто назначает инженера, различие «решено» и «закрыто», можно ли менять плановые сроки и задним числом фиксировать факт, какие поля доступны менеджеру, как приостанавливается SLA во время согласования.

3. Общение и закрытие

As-is [код]: клиентская карточка /tickets/info/ выводит описание/ответ и даёт дописывать текст через отдельные update.php/update2.php. Код также допускает закрытие по GET-параметру close=yes. Административная карточка меняет поля через большую форму и отдельный update endpoint. История и почтовые события формируются в разных местах; не все операции выглядят атомарными.

To-be: лента событий с датой/автором/типом; отдельное поле публичного ответа и внутренняя заметка с пометкой аудитории; закрытие через подтверждённую POST-команду с кодом и причиной; повтор команды безопасен. Пользователь видит, кому ушло сообщение и что будет дальше. Повторное открытие — только если правило утверждено.

4. SLA, статистика и уведомления

As-is [код]: время реакции и решения рассчитывается из договора с учётом графика/праздников; /admin/stat.php строит сводку, /stat.php предназначен для рассылки, но его DOCUMENT_ROOT указывает на отсутствующий каталог. sendSDNotice активен, sendMailToUsers немедленно выходит. Настройки уведомлений привязаны к пользователю/договору. Работа cron и фактическая доставка в этом срезе не проверены.

To-be: владелец процесса утверждает матрицу событий и сроки доставки; сервис SLA хранит основание расчёта/версию графика и объясняет пользователю дату; очередь уведомлений фиксирует успех/ошибку; статистика показывает дату обновления и базу расчёта. Отчётные показатели сверяются с заявками.

5. QR-вызов и внешние обмены

As-is [код]: /call/index.php использует REST на corp.artron.group, данные объекта обслуживания и CRM-форму; /call/dourl.php, /call/qrcode.php работают с URL/QR. /engineer/ принимает специальный код и GET setTime=yes для фиксации времени. Наличие идентификаторов 1С в свойствах подтверждает связность данных, но направление, расписание и гарантия обмена не установлены. /call/ без параметра отвечает 200; консольная ошибка Bitrix Pull относится к push-config, работа реального QR-сценария не проверялась.

To-be: документированный контракт QR (срок, разрешённые операции, отзыв, аудит); отдельная команда инженера на POST; REST через секретное хранилище с проверкой TLS; журнал корреляции с CRM/1С и идемпотентный повтор. Изменения обменов выпускать только с владельцами обеих сторон.

Бизнес-метрики для базовой линии

Собрать за 4 недели до изменения: число созданных/закрытых заявок по роли/договору; медиану и p95 времени до реакции/решения; долю нарушений SLA; ошибку входа/создания/экспорта; долю доставленных уведомлений; задачи пользователей в тестах UX. Текущий пакет не содержит выдуманных значений этих метрик.