Понять, где вы находитесь, — первый шаг к тому, чтобы понять, куда двигаться. В этом руководстве показано, как оценить уровень зрелости ITSM вашей службы по объективным сигналам из самого GLPI — не полагаясь на ощущения — и как расставить приоритеты для следующих шагов развития.
Зрелость не измеряется мнением
На вопрос «на каком мы уровне?» почти всегда отвечают эмоционально: тот, кто каждый день тушит пожары, клянётся, что это уровень 1, а руководитель, одобривший покупку инструмента, клянётся, что уровень 4. Оба ошибаются, потому что измеряют ощущение, а не процесс. Зрелость ITSM — это степень формализации, автоматизации и оптимизации управления услугами, и она оставляет измеримые следы в базе данных инструмента. Прежде чем нанимать консультантов или покупать новые модули, стоит извлечь эти следы.
Объективная диагностика: спросите сам GLPI
Три сигнала хорошо отличают зрелую службу от незрелой: сколько заявок действительно категоризировано, у скольких привязан SLA и сколько времени уходит на решение. Выполните запрос ниже прямо в базе (только чтение) за последние 90 дней:
-- Maturity signals over the last 90 days (GLPI 10/11)
SELECT
COUNT(*) AS total_tickets,
ROUND(100 * SUM(itilcategories_id > 0) / COUNT(*), 1) AS pct_categorized,
ROUND(100 * SUM(slas_id_ttr > 0) / COUNT(*), 1) AS pct_with_resolution_sla,
ROUND(AVG(TIMESTAMPDIFF(HOUR, date, solvedate)), 1) AS avg_hours_to_resolve
FROM glpi_tickets
WHERE date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
AND is_deleted = 0
AND solvedate IS NOT NULL;Практическая интерпретация: если категоризировано меньше 70% заявок, забудьте об управлении проблемами — вам не на чем группировать повторяющиеся случаи. Если SLA привязан меньше чем к 50%, ваши отчёты о выполнении измеряют только ту часть, у которой есть срок, а не всю работу службы. А если среднее время решения сильно колеблется от месяца к месяцу, процесс всё ещё ad-hoc, даже если инструмент есть.
Матрица: уровень × сигнал в GLPI × действие
Используйте матрицу, чтобы определить свой уровень по тому, что GLPI показывает сегодня, а не по тому, что вам хотелось бы видеть:
| Уровень | Наблюдаемый сигнал в GLPI | Следующее техническое действие | Целевая метрика |
|---|---|---|---|
| 1 — Ad-hoc | Нет инструмента или заявки без категории/SLA | Внедрить GLPI, создать организацию и профили | 100% заявок в инструменте |
| 2 — Повторяемый | Заявки создаются, но преобладает категория «Прочее» | Компактное дерево категорий + начальный SLA | >70% категоризировано |
| 3 — Определённый | Категории и SLA используются; распределение вручную | Бизнес-правила (назначение), база знаний | SLA привязан >90% |
| 4 — Управляемый | Метрики собираются; cron в CLI | Управление проблемами и изменениями, дашборды | SLA выполнен >90% |
| 5 — Оптимизированный | Решения на основе данных; зрелая автоматизация | Анализ повторяемости, интеграция с бизнесом | Ежегодное снижение повторных обращений |
Деталь сопровождения, которая искажает любую метрику
В сопровождении клиентских сред больше всего вводит в заблуждение показатель «SLA выполнен», когда автоматические действия GLPI работают в режиме GLPI (запуск из браузера), а не CLI. В этом режиме пересчёт сроков, эскалации и уведомления происходят, только когда кто-то открывает страницу системы. Итог: в 3 часа ночи, когда никто не залогинен, ни одна заявка не эскалируется, а отчёт на следующий день показывает зелёный SLA, не соответствующий действительности. Частая ошибка — доверять дашборду, не проверив в Настройки > Автоматические действия, какой задан режим выполнения. Исправление — перевести всё на CLI и запланировать системный cron:
# /etc/cron.d/glpi - runs the automatic actions every minute
# Works for GLPI 10 and 11 (front/cron.php is portable; on 11 avoid depending on the console)
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php &>/dev/nullПосле перехода на CLI в разделе Автоматические действия смените поле «Режим выполнения» каждой критичной задачи (queuednotification, slaticket, closeticket) на CLI. Без этого вы можете быть на уровне 4 на бумаге и на уровне 2 на практике.
Ловушка унаследованного дерева категорий
Ещё одна частая ошибка — повышать уровень, считая, что «много категорий» — признак зрелости. Всё наоборот. Мы принимали на сопровождение среду, в которой было около 400 категорий, импортированных из унаследованной системы и вложенных на пять уровней. На практике сотрудники не находили нужную категорию, выбирали первую попавшуюся, и поле превращалось в шум. Мы перекатегоризировали историю за последние месяцы, сократили дерево до чуть более двух десятков категорий, отражающих то, с чем команда реально работает, и только после этого отчёты по причинам обрели смысл. Практическое правило, которым мы пользуемся: если в категорию не поступало заявок 90 дней, она кандидат на удаление. Избыток категорий не говорит о зрелости; он мешает сортировке и искажает любой анализ повторяемости.
Чек-лист быстрой оценки
- Есть ли ITSM-инструмент, в котором находятся все заявки? (да = уровень 2+)
- Более 70% заявок имеют конкретную категорию, а не «Прочее»? (да = уровень 3+)
- SLA привязан, а cron работает в проверенном режиме CLI? (да = уровень 3+)
- Метрики собираются и разбираются на регулярной встрече? (да = уровень 4+)
- Решения принимаются на основе данных, а не ощущений? (да = уровень 4+)
- Есть ли активное управление проблемами, снижающее повторяемость? (да = уровень 5)
План развития: один уровень за раз
Не пытайтесь перескакивать этапы — каждый уровень опирается на предыдущий. Если диагностика показала низкую категоризацию, следующий шаг — не покупать ИИ, а сократить дерево категорий до того, чем команда реально пользуется (на практике 15–25 категорий покрывают большинство служб среднего размера), и обучить сортировке. Только когда категоризация стабилизируется, управление проблемами обретает смысл, потому что вы наконец можете группировать инциденты по причинам. Если вы на уровне 1–2, начните с внедрения GLPI и базовой настройки, прежде чем браться за какую-либо автоматизацию.
По нашему опыту сопровождения, самый быстрый рост зрелости даёт не новая функциональность, а наведение порядка в том, что уже есть: cron в CLI, компактные категории и SLA, привязанный к 100% типов заявок. Эти три настройки переводят службу с уровня 2 на уровень 3 за несколько недель без дополнительных затрат на лицензии.
Если вам нужна диагностика зрелости с этими показателями, извлечёнными из вашей собственной среды, NexTool проводит оценку и сопровождение GLPI для B2B-служб — от базовой настройки до оптимизированного уровня.
Проверено командой NexTool Solutions.
