У бизнес-процесса обычно три версии: регламентная, системная и фактическая — та, которая действительно работает в промышленное среде. Последнюю иногда лучше всего видно не на схеме, а в Service Desk.

Бизнес-процесс — это модель состояний. Условный процесс: создание → проверка → согласование → выгрузка → подписание. Предположим, на схеме он линейный. Его состояния, соответственно, можно представить так: создан → проверен → согласован → выгружен → подписан. Проблема возникает, когда разные компоненты считают один объект находящимся в разных состояниях. Технически отдельные операции успешны, но для бизнеса - " у вас ничего не работает".

Поддержка ищет 🔍 не ошибку, а разрыв состояния. Пользователь пишет: «Не могу подписать документ». Ошибка проявилась в подписании, но не появилась при валидации. Поэтому диагностика должна искать точку нарушения инварианта — условия, которое обязано выполняться на конкретном этапе.

Ручная операция поддержки — это технический долг. Особенно интересны повторяющиеся заявки: «Поменяйте статус», «откатите процесс», «перезапустите», «протолкните объект». Если они возникают постоянно, поддержка фактически становится ручным 🛠️ промежуточным звеном между системами. Это означает, что процессу может не хватать механизмов повторного выполнения операции, отката, защиты от дублирования, сверки состояний, корректной валидации или пользовательского сценария восстановления. Поддержка в таком случае не устраняет дефект. Она вручную компенсирует отсутствие механизма восстановления.

Опасность ⚠️ : простой повтор операции. После превышения времени ожидания первая операция могла фактически выполниться. Повторный запрос без защиты от дублирования способен создать второй объект.

Заявки поддержки как карта сбоев процесса. Предположим, за месяц получили 📊: 42% — ручная коррекция данных 23% — повторный запуск процесса 14% — интеграционные ошибки 11% — права доступа

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

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

Это уже переход от Incident Management 💡 к Problem Management. Поэтому мое мнение, что Service Desk — не просто место, где закрывают тикеты, а огромный пласт информации о системах.

P.S. Всем ❤️ , кто работает в технической поддержке и сопровождении систем.