Как выбрать ITSM-систему: 15 критериев оценки

Предварительные шаги

Перед оценкой систем нужно разобраться с собственными требованиями. Без этого любая оценка превращается в "какая система выглядит лучше на презентации".

1. Опишите свои процессы — хотя бы на уровне схемы обработки инцидента и сервисного запроса
2. Определите ключевые интеграции — что обязательно, что желательно
3. Посчитайте количество пользователей и операторов — для оценки лицензирования
4. Сформулируйте требования ИБ — что требует регуляторика, что диктует ИБ-политика
5. Определите бюджет и горизонт окупаемости

Подробнее о подготовке — в статье о внедрении ITSM.

15 критериев оценки

1. Покрытие ITIL-процессов (вес: высокий)

Что должно быть из коробки:

• Incident Management с жизненным циклом заявки
• Service Request Management с шаблонами
• SLA с расчётом в рабочем календаре и паузами
• Каталог услуг с параметрами
• Knowledge Management (база знаний)
• Change и Problem Management — желательно

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

2. Модель лицензирования и TCO (вес: высокий)

Основные модели:

• По пользователям — оплата за каждого оператора и/или конечного пользователя
• По заявкам — оплата за объём обращений (редко)
• Фиксированная — единая стоимость независимо от масштаба
• Подписка / perpetual — ежегодная подписка или бессрочная лицензия с платной поддержкой

Как проверить: посчитайте TCO на 5 лет с учётом роста команды на 30–50%. Подробно — в статье On-premise vs SaaS. Обратите внимание на скрытые расходы: доп. модули, интеграции, кастомизация.

3. Модель развёртывания (вес: высокий)

• On-premise — контроль данных, соответствие 152-ФЗ и 187-ФЗ
• SaaS — быстрый старт, меньше операций, но есть санкционные риски
• Hybrid / Private Cloud — промежуточные варианты

Как проверить: узнайте, поддерживает ли вендор выбранный вами режим развёртывания. Для on-premise запросите Docker/k8s-манифесты и минимальные системные требования.

4. Производительность и масштабирование (вес: средний)

Что проверить:

• Время отклика страниц при 100 параллельных пользователях
• Размер инсталляций у реальных клиентов (есть ли аналоги вашего масштаба)
• Архитектура — монолит или микросервисы, возможность горизонтального масштабирования
• Размер БД через 3–5 лет при вашем потоке заявок

Как проверить: нагрузочное тестирование на демо-стенде перед покупкой. Для больших внедрений — референс-визиты к клиентам аналогичного масштаба.

5. Интеграции (вес: высокий)

Минимальный набор из коробки:

• AD / LDAP
• IMAP / SMTP (с threading)
• SSO (SAML / OIDC)
• REST API с OpenAPI
• Webhooks
• Готовые коннекторы к Jira, мониторингу, мессенджерам

Как проверить: список встроенных интеграций в документации + попробуйте самую критичную для вас на демо. Подробнее — в статье об интеграциях.

6. Кастомизация (вес: средний)

• Настраиваемые поля на заявках
• Конфигурируемые workflow и статусы
• Редактор шаблонов форм для сервисных запросов
• Собственные правила автоматизации через UI
• Кастомные отчёты и дашборды

Как проверить: попробуйте настроить один нестандартный сценарий самостоятельно на демо. Если нужна помощь вендора для добавления поля — это не кастомизация, а платные доработки.

7. Безопасность (вес: высокий для регулируемых отраслей)

• RBAC с гранулярным разграничением
• Полный аудит действий
• Шифрование в передаче и в хранилище
• Интеграция с корпоративным SIEM
• Реестр отечественного ПО (для КИИ)
• Сертификация ФСТЭК (для отдельных отраслей)

Подробнее — в статье о безопасности ServiceDesk.

8. Аналитика и отчёты (вес: средний)

• Встроенные дашборды с типовыми KPI
• Конструктор кастомных отчётов
• Экспорт в Excel / CSV / PDF
• Drill-down в данные (клик по метрике → список заявок)
• API для подтягивания данных во внешние BI-системы

Как проверить: какие метрики есть "из коробки". Если для базового SLA-отчёта нужен внешний BI-инструмент — это проблема.

9. Мобильные приложения (вес: средний)

Для пользователей: создание и отслеживание заявок со смартфона. Для операторов: мобильный доступ к очереди, ответы на ходу.

Как проверить: приложения для iOS и Android из App Store / Google Play. Качество UI. Работа в офлайн.

10. Локализация (вес: высокий для РФ)

• Русский UI оператора и администратора
• Русский UI портала пользователей
• Поддержка кириллицы в поиске с учётом морфологии
• Локализованная документация
• Российский календарь праздников из коробки

11. Поддержка и сопровождение (вес: высокий)

• Каналы: email, телефон, портал
• SLA на ответ (например, 4 часа в рабочее время)
• Уровни поддержки: базовая vs премиум
• Russian-speaking support (не все зарубежные вендоры дают)
• Комьюнити, форумы, база знаний для самопомощи

Как проверить: референс-звонок с 2–3 клиентами вендора. Спросите прямо: как быстро отвечают, как решают сложные кейсы.

12. Скорость внедрения (вес: средний)

Типовые сроки развёртывания:

• Базовая настройка — часы (on-prem через Docker) или минуты (SaaS регистрация)
• Пилот — 2–4 недели
• Полноценный запуск — 3–6 месяцев

Как проверить: у вендора — кейсы внедрения с указанием сроков. Реалистичный план, не "внедрим за неделю".

13. Экосистема и маркетплейс (вес: низкий)

Наличие дополнений, интеграций от третьих лиц. В российских системах маркетплейс обычно слабее, чем у международных вендоров, но и потребность в нём ниже — базовые интеграции встроены.

14. Дорожная карта развития (вес: средний)

Как проверить:

• Частота релизов (раз в месяц / квартал)
• Публичный roadmap с планами на 6–12 месяцев
• Каналы сбора обратной связи от клиентов
• Примеры реализованных запросов клиентов

Если вендор не показывает roadmap — возможно, продукт в режиме поддержки, развития нет.

15. Юридические и финансовые аспекты вендора (вес: средний)

• Российское юрлицо
• Реестр отечественного ПО — если вы госсектор / КИИ
• Финансовая устойчивость вендора (возраст компании, количество клиентов)
• Возможность экспорта данных при отказе от продукта
• Условия миграции на другую систему при расторжении

Процесс выбора: 6 шагов

1. Long-list — 10–15 систем по первичному фильтру (модель развёртывания, язык интерфейса, регистрация в реестре).
2. Short-list — 3–5 систем после анализа документации и отзывов.
3. Demo с реальным сценарием — не типовая презентация вендора, а проверка именно ваших workflow.
4. Proof of Concept — 2–4 недели тестирования с 2–3 финалистами в реальных условиях.
5. Референс-визиты — общение с 2–3 клиентами каждого финалиста.
6. Финансовая и юридическая проверка — TCO, условия договора, SLA поставщика.

Scorecard: как сравнивать

Типовой подход — оценка каждого критерия по шкале 1–10 с учётом веса. Пример заполненной scorecard:

В этом примере Система A лидирует за счёт on-prem, безопасности и локализации. Важно: если по must-have критерию (например, on-premise для вашей отрасли) у системы 0, она автоматически выбывает, независимо от остальных оценок.

Красные флаги

Сигналы, что с системой или вендором что-то не так:

• Нет демо на реальном сценарии — только типовая презентация. Значит, "глубже" продукт может не работать.
• Отказ дать контакты референс-клиентов. Если у вендора нет довольных клиентов вашего масштаба — это показательно.
• Ответ "это мы сделаем в следующем релизе" на базовые вопросы. Планируемая функциональность не равна реальной.
• Сложный экспорт данных. Если нет механизма выгрузки всех данных в читаемом формате — готовьтесь к проблемам при миграции.
• Нестабильная поддержка. Если тестовые обращения в поддержку в период оценки игнорируются — после покупки лучше не будет.
• Очень низкая цена. Часто скрывает доп. платежи за модули, ограничения или планы монетизации через "будущие обязательные обновления".

Российский контекст 2026 года

Несколько особенностей, важных для выбора в РФ:

• Реестр отечественного ПО — критически важно для госсектора и КИИ, желательно для коммерческих компаний (поддерживает отечественного разработчика)
• On-premise и локализация данных — почти обязательны из-за 152-ФЗ и рисков блокировки зарубежных SaaS
• Интеграция с 1С — актуальна для большинства российских компаний
• Уход международных вендоров сократил выбор, но освободил рынок для российских разработчиков
• Миграционные сценарии — многие компании в активной фазе перехода с западных продуктов

Типовые ошибки выбора

1. Выбор по презентации. Красивая demo-версия часто не соответствует поведению в реальной работе. Всегда делайте PoC.
2. Игнорирование TCO. Фокус на стоимости лицензии, забывая про внедрение, интеграции, поддержку.
3. Слишком много критериев. 50+ пунктов scorecard — невозможно качественно оценить. Оптимум — 12–15 взвешенных.
4. Слепое копирование чужого выбора. Что подошло крупному банку, необязательно подойдёт небольшой компании.
5. Отсутствие участия IT-команды. Решение принимают финдиректор и HR, а работать будут операторы. Получаются неиспользуемые системы.

Вывод

Выбор ITSM-системы — это структурированный процесс, а не эмоциональное решение. 15 критериев выше — не догма, адаптируйте под свой контекст. Но принципы остаются: прежде чем выбирать — разберитесь с собственными требованиями, используйте scorecard для объективной оценки, обязательно делайте PoC и общайтесь с реальными клиентами.

Помните: идеальной системы не существует. Есть система, которая лучше других подходит именно вам — под ваши процессы, бюджет, регуляторику и команду. В демо TIQQET мы специально показываем продукт на реалистичных сценариях, а не абстрактных возможностях — оставляйте заявку.