OTRS-workflow против «всё P1»: как мы защищаем IT-команду через автоматику

К нам в феврале 2026-го пришла торговая компания 42 РМ из САО Москва с типовой проблемой: коммерческий директор и его три менеджера накачивали штатную IT-команду «срочными P1-задачами» так, что инженеры работали по 11 часов, выгорели за полгода и стали увольняться один за другим. Владелец потерял главного админа в декабре, в январе — ещё двух из четырёх, в феврале понял, что надо что-то делать кардинально. В этой статье — как мы внедрили у них workflow в OTRS с автоматической переклассификацией приоритетов, что стало с поведением коммерческого, какие метрики мы теперь показываем CTO раз в месяц, и почему такие системы окупаются за 4-6 месяцев именно на людях, а не на тикетах.

Откуда берётся системная манипуляция в IT-обращениях

Я считаю манипуляцию приоритетами одной из главных причин выгорания IT-команд в МСБ. И это не личная злая воля коммерческого директора — это структурная проблема. У коммерческого есть KPI по выручке, его задача — двигать сделки. Любая задержка от IT воспринимается как препятствие. Поэтому он естественно склонен ставить «P1, срочно» на всё, что хочет получить быстрее.

Параллельно у него обычно нет картинки про то, что вообще происходит в IT-очереди. Он не знает, что одновременно с его «срочной задачей» в работе — реальный P1 от бухгалтерии (упала 1С перед выплатой ЗП), сложная диагностика сервера, который вот-вот ляжет, и три текущих helpdesk-запроса. Для него его задача — единственная.

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

Результат: IT-команда работает в режиме постоянной встряски, у инженеров ломается планирование, проекты буксуют, лучшие сотрудники уходят. По моему опыту — компания теряет 2-3 миллиона ₽ в год только на ротации IT-команды, не считая нереализованных проектов.

Почему мы выбрали OTRS, а не Jira

Гибкость скриптовых правил

OTRS — open-source ITSM-система с богатой историей (с 2001 года), написанная на Perl. Главное её преимущество для наших задач — это GenericAgent: механизм, который позволяет писать скрипты, реагирующие на события в тикетах. На Perl можно сделать практически любую логику: проверить автора, посмотреть историю, обновить поля, отправить уведомление, эскалировать.

В Jira аналог есть, но это либо встроенный workflow-редактор (мало гибкости), либо ScriptRunner-плагин (платный, $1000+ в год), либо самописные webhook-обработчики (надо разворачивать отдельно).

Стоимость

OTRS Community Edition — бесплатный, под лицензией GNU GPL v3. Платная Enterprise-версия даёт расширенный функционал по комплаенсу и поддержке вендора, но для МСБ Community вполне хватает.

Jira Service Management для 30-50 пользователей стоит 7-12 долларов за пользователя в месяц, то есть 210-600 долларов в месяц или 18-54 тысячи ₽/месяц только на лицензии. За год — 200-650 тысяч ₽. OTRS даёт ту же функциональность за 0 ₽ лицензий плюс серверная мощность (виртуальная машина за 6-9 тысяч ₽/мес у нас на гипервизоре).

Опыт нашей команды

Мы держим OTRS у своих клиентов с 2018 года, у нас в инфраструктуре сейчас 11 инсталляций OTRS для разных клиентов. Все скрипты, шаблоны, дашборды у нас уже отлажены — внедрение под нового клиента занимает 2-3 недели вместо 2-3 месяцев на пустом месте.

Матрица приоритетов «цена × срок × охват»

В OTRS-конфигурации мы используем не плоскую матрицу P1-P4 с одним признаком, а трёхмерную: цена ошибки × срок выполнения × охват затронутых. Каждый тикет автоматически попадает в одну из четырёх ячеек на основе этих признаков.

Признак 1: цена ошибки в рублях за час

Стоимость задержки решения задачи. Считается по очень простой формуле: «если задачу не решить ближайший час, сколько денег компания потеряет / недополучит / заплатит сверху?». P1 — больше 100 тыс ₽/час; P2 — 20-100 тыс; P3 — меньше 20 тыс; P4 — деньги напрямую не теряются.

Признак 2: срок выполнения

За какое время задача должна быть закрыта. P1 — меньше часа; P2 — меньше 4 часов; P3 — меньше рабочего дня; P4 — по плану проекта.

Признак 3: охват затронутых

Сколько пользователей или процессов сейчас не работает. P1 — все или ключевой процесс; P2 — отдел или 5+ человек; P3 — 1-3 человека; P4 — никто пока не страдает (это запрос на изменение).

Логика автоклассификации

В OTRS при создании тикета пользователь должен заполнить все три поля. Если хотя бы одно не заполнено — система не позволяет сохранить тикет с приоритетом P1, автоматически опуская до P2. Это первый барьер.

Дальше работает алгоритм: если все три поля попадают в P1-класс, тикет идёт как P1. Если хотя бы два — P1, тикет тоже P1. Если только одно — система переводит в P2 и пишет в комментарий причину. Если ни одно — P3 или P4 по охвату.

Скриптовые правила: что и когда автоматически срабатывает

Правило 1: auto-downgrade для частых ставщиков ложных P1

В OTRS у нас есть динамическое поле «частые ставщики ложных P1». В него попадает пользователь, у которого за последние 60 дней было >5 P1, и >50% из них переквалифицированы вниз после диагностики. Когда такой пользователь создаёт новый P1, скрипт срабатывает:

# /opt/otrs/var/cron/script-frequent-p1-downgrade.pl
# ITfresh, версия 2026.05
# GenericAgent правило: запускается при создании тикета

use strict;
use warnings;
use Kernel::System::Ticket;
use Kernel::System::CustomerUser;

sub Run {
    my ($Self, %Param) = @_;

    return unless $Param{Priority} eq 'P1';

    # Список «частых ставщиков ложных P1»
    my @frequentSenders = $Self->{DB}->Get(
        SQL => "SELECT customer_id FROM frequent_false_p1
                WHERE updated > NOW() - INTERVAL '60 days'"
    );

    my $isFrequent = grep { $_ eq $Param{CustomerID} } @frequentSenders;
    return unless $isFrequent;

    # Проверяем триггерные слова в теме/теле
    my @triggers = ('упало все', 'остановка', 'не работает у всех',
                    'критич', 'аварийн', 'ransom', 'паника');
    my $hasRealTrigger = grep { $Param{Subject} =~ /$_/i ||
                                $Param{Body}    =~ /$_/i } @triggers;

    if (!$hasRealTrigger) {
        # Auto-downgrade с уведомлением
        $Self->{TicketObject}->PrioritySet(
            TicketID => $Param{TicketID},
            Priority => 'P2',
            UserID   => 1
        );
        $Self->{TicketObject}->HistoryAdd(
            TicketID  => $Param{TicketID},
            HistoryType => 'AutoPriorityChange',
            Name => "Auto-downgrade: автор в списке частых ложных P1, "
                   . "триггерные слова не найдены"
        );
        # Отправляем письмо автору
        $Self->{SendNotification}(
            TicketID => $Param{TicketID},
            Template => 'AutoDowngradeP2',
            To => $Param{CustomerEmail}
        );
        # Отправляем алерт в Telegram дежурному
        $Self->{TgNotify}(
            Channel => 'itfresh-dispatcher',
            Text    => "P1 → P2 auto-downgrade · автор $Param{CustomerEmail}"
        );
    }
}

Что критически важно: auto-downgrade всегда сопровождается письмом пользователю с объяснением причины и возможностью «обжаловать» — нажать кнопку, открыть дополнительный диалог, описать почему он считает это P1. На 85% случаев пользователь принимает решение, на 15% нажимает «обжаловать», и из них только 20% после диагностики действительно остаются P1.

Правило 2: обязательное заполнение бизнес-импакта

Для P1 без полностью заполненных трёх полей (цена/срок/охват) система блокирует создание тикета и предлагает анкету: «Напишите конкретные суммы потерь в час и список затронутых сотрудников/процессов». 60% «P1-обращений» отваливаются на этом шаге — пользователь либо не может сформулировать, либо понимает сам, что P1 неуместен, и понижает.

Правило 3: эскалация неавторизованных P1 после 17:00

P1 в OTRS могут ставить только из «авторизованного списка» (обычно — гендиректор, главбух, IT-руководитель, начальники отделов). Если P1 поступает от обычного сотрудника после 17:00 — скрипт автоматически вызывает дежурного диспетчера, который перезванивает за 5 минут и проводит верификацию.

Правило 4: антинакрутка триггерных слов

Если в теме тикета есть слова «ВСЁ ГОРИТ», «АВАРИЯ», «КАТАСТРОФА», скрипт проверяет — в последние 30 минут было ли ещё 5+ обращений с похожими словами от разных людей? Если да — значит, реально что-то сломалось (P1 подтверждён). Если нет — флаг «требует ручной верификации диспетчером».

Метрики для CTO: пять цифр, которые показывают всю картину

Раз в месяц мы готовим CTO клиента отчёт с пятью основными метриками. Этого достаточно, чтобы видеть здоровье IT-команды и эффективность процессов.

Метрика 1: SLA-комплаенс по приоритетам

Процент тикетов каждого приоритета, закрытых в SLA. У хорошей команды P1 закрывается на 95%+ в SLA, P2 — 90%+, P3 — 85%+, P4 — 80%+. Если есть просадка — конкретный приоритет недогружен ресурсами.

Метрика 2: процент ложных P1 по авторам

Сколько P1-обращений от каждого человека переквалифицированы вниз после диагностики. Если у человека больше 50% ложных P1 — это сигнал. У одного нашего клиента коммерческий директор за 60 дней поставил 47 P1, реальных оказалось 4 (8%). Этот отчёт показали владельцу — через две недели поведение коммерческого изменилось без всяких разговоров.

Метрика 3: среднее время реакции и закрытия

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

Метрика 4: CSAT после закрытия

После закрытия тикета пользователю автоматически отправляется короткая анкета на 3 вопроса:

1. «Проблема решена полностью / частично / не решена?»
2. «Оцените скорость решения от 1 до 5».
3. «Оцените вежливость и компетентность инженера от 1 до 5».

Среднее по компании — обычно 4.4-4.7 из 5 у нас на проектах. Если падает ниже 4.0 — внутренний разбор причин.

Метрика 5: нагрузка на инженера

Тикетов в месяц на одного инженера, средняя длительность работы по тикетам, переработки. У нас лимит — 65-80 тикетов в месяц на одного инженера в среднем (зависит от состава: helpdesk до 150, инфраструктурный 40-60, senior 25-40). Если переваливает — пора брать человека или сокращать клиента.

Что произошло у клиента-торговли 42 РМ за 4 месяца

Мы развернули OTRS-workflow в начале марта 2026. Базовая установка — 6 дней, скрипты и шаблоны — 10 дней, тюнинг порогов — 4 недели. Полный запуск с метриками в живой режим — 13 апреля.

Что произошло с цифрами:

• Количество P1 за месяц: с 47 в марте упало до 11 в апреле (минус 77%).
• Процент ложных P1 (от коммерческого директора): был 87%, через месяц упал до 22%.
• Среднее время закрытия P2: с 6.8 часов до 3.4 часов (стало плавнее, меньше «пожаров»).
• CSAT: вырос с 3.2 (катастрофа) до 4.3 (норма).
• Переработки IT-команды: упали с 38 часов на человека в месяц до 8 часов.

Что произошло с людьми. Двое из оставшихся четырёх инженеров клиента отозвали заявления об увольнении. Один новый инженер прошёл испытательный срок (раньше — все увольнялись через 2-3 месяца). Коммерческий директор после двух персональных отчётов от меня (где было видно его 47 ложных P1) кардинально поменял поведение — теперь ставит максимум 1-2 настоящих P1 в месяц, остальное идёт как P2-P3.

Владелец клиента сказал мне на встрече в апреле: «Семёнов, я думал, что у меня проблема в IT-команде. Оказалось, проблема в том, как мы все вместе работаем с IT. Спасибо, что это вытянули».

Как мы интегрировали OTRS с Telegram и AD

Интеграция с Active Directory

OTRS поддерживает аутентификацию через LDAP/AD из коробки. Мы настроили синхронизацию пользователей раз в час: новые сотрудники клиента автоматически появляются в OTRS, уволенные — деактивируются. Каждому пользователю прописываются роли на основе AD-групп: «admins» → Agent, «department-heads» → CustomerUser с правом P1, «employees» → CustomerUser без права P1.

Интеграция с Telegram

Алерты от OTRS приходят в три Telegram-канала: «itfresh-tickets-all» (все тикеты для дежурного), «itfresh-dispatcher» (только P1-P2 для диспетчера), «client-monitoring-{name}» (только метрики для CTO клиента, дайджест раз в день).

# /opt/otrs/Kernel/Config/Files/TelegramNotify.pm
# ITfresh, 2026.03

package Kernel::Config::Files::TelegramNotify;

use strict;
use warnings;
use LWP::UserAgent;
use JSON;

sub NotifyChannel {
    my ($Channel, $Text) = @_;

    my %ChannelMap = (
        'itfresh-tickets-all'   => '-1001234567890',
        'itfresh-dispatcher'    => '-1001234567891',
        'client-mon-trade42'    => '-1001234567892',
    );

    my $chatId = $ChannelMap{$Channel} || return;

    my $ua = LWP::UserAgent->new(timeout => 10);
    my $resp = $ua->post(
        "https://api.telegram.org/bot$ENV{TG_BOT_TOKEN}/sendMessage",
        {
            chat_id => $chatId,
            text    => $Text,
            parse_mode => 'HTML'
        }
    );

    return $resp->is_success;
}

1;

Сколько стоит внедрение и эксплуатация

Бюджеты на типовое внедрение у нас в 2026 году:

• Минимальный пакет. Установка OTRS Community, базовая матрица P1-P4, простые правила, базовые шаблоны email. 8-10 рабочих дней инженера. Цена: 90-110 тысяч ₽.
• Стандартный пакет. Минимальный + скриптовые правила auto-downgrade, интеграция с AD, базовые метрики. 12-15 дней. Цена: 140-180 тысяч ₽. Подходит большинству клиентов.
• Расширенный пакет. Стандартный + Telegram-интеграция, CSAT-анкеты, продвинутые метрики, дашборды Grafana, обучение CTO клиента. 16-20 дней. Цена: 220-260 тысяч ₽.

Ежемесячная эксплуатация — 6-9 тысяч ₽ за серверную мощность (наш гипервизор) плюс OTRS-администрирование входит в стандартный аутсорс-договор (без дополнительной оплаты). Доработки workflow по запросу клиента — почасовая ставка 4500 ₽/час.

FAQ: что чаще всего спрашивают клиенты

Чем OTRS лучше Jira Service Management или Битрикс24 для МСБ?

Три причины. Первая — гибкость workflow: в OTRS правила пишутся на Perl и могут делать что угодно с тикетом, в Jira это сильно ограничено. Вторая — стоимость: OTRS Community Edition бесплатна, Jira стоит 7-12 долларов за пользователя в месяц. Третья — мы знаем, как держать OTRS на собственном сервере без проблем 5+ лет. Но это вкусовщина — Jira тоже хороший инструмент, если у вас бюджет.

Можно ли реально автоматически переклассифицировать приоритет, не обидев пользователя?

Можно — если делать это правильно. У нас в OTRS при auto-downgrade пользователю автоматически отправляется письмо с объяснением: «приоритет изменён с P1 на P2, потому что признаки P1 (полная остановка процесса) не выявлены. Если считаете, что я ошибаюсь — нажмите кнопку «обжаловать» и опишите ситуацию». 85% пользователей принимают изменение, 15% нажимают «обжаловать», из них 80% — после уточнения тоже соглашаются. Реальных ошибок системы — около 2%.

Какие метрики действительно полезны для управления IT-командой?

У нас в ITfresh пять метрик, которые мы показываем CTO клиента: SLA-комплаенс по приоритетам (P1/P2/P3/P4 отдельно), процент ложных P1 от каждого пользователя, среднее время реакции и закрытия, индекс удовлетворённости CSAT (короткая анкета после закрытия тикета), нагрузка на инженеров (тикетов в месяц на человека). Этих пяти достаточно для управления командой 5-30 инженеров.

Что делать, если штатный сотрудник клиента саботирует workflow и обходит правила?

Реальная ситуация, она бывает. Признаки: пользователь намеренно пишет в теме тикета триггерные слова («ВСЕ ОСТАНОВИЛОСЬ»), хотя ничего не остановилось; обращается в обход системы — напрямую инженеру в Telegram; пытается уговорить сотрудника поднять приоритет «по дружбе». Мы это видим в OTRS-логах за 2-3 эпизода. Решение — личная встреча Семёнов + владелец компании + этот сотрудник, разговор без обвинений по фактам. Обычно после такого разговора всё нормализуется.

Сколько времени занимает внедрение полного workflow в OTRS?

Базовая установка OTRS Community с настройкой матрицы P1-P4 и базовых очередей — 4-6 рабочих дней. Полный workflow со скриптами auto-downgrade, интеграцией с email/Telegram/AD, шаблонами уведомлений, метриками и дашбордами — 12-18 рабочих дней. Стоимость в нашей практике 2026 — 140-240 тысяч ₽ за внедрение под ключ. Дальше OTRS работает на нашем гипервизоре и стоит 6-9 тысяч ₽/мес в составе аутсорс-договора.

Итог

OTRS-workflow с автоматической классификацией приоритетов — это не игрушка для крупных компаний. Это рабочий инструмент для МСБ 30-100 РМ, который окупается за 4-6 месяцев на сохранении IT-команды и нормальной рабочей атмосфере. Ключевые элементы: матрица «цена × срок × охват» вместо плоского P1-P4, скриптовые правила auto-downgrade для частых ставщиков ложных P1, обязательное заполнение бизнес-импакта, метрики для CTO с упором на ложные приоритеты. У клиента-торговли 42 РМ за 4 месяца количество P1 упало на 77%, переработки команды — в 4.75 раза, CSAT вырос с 3.2 до 4.3.