По мере роста компании работа технического подразделения становится заметно сложнее. Обращения сотрудников поступают через почту и мессенджеры, задачи распределяются между несколькими специалистами, оборудование приходится учитывать отдельно, а руководителю нужно контролировать сроки и качество обслуживания.

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

В этот момент компании начинают рассматривать специализированные системы управления ИТ-услугами. При выборе полезно изучить сравнение локальных систем управления ИТ-услугами, но ориентироваться стоит не только на место продукта в рейтинге, а прежде всего на соответствие собственным процессам.

Зачем компании нужна система управления ИТ-услугами

Главная задача такой системы — собрать техническое обслуживание в единый управляемый процесс.

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

Через систему можно организовать:

• прием и обработку обращений;

• распределение задач;

• контроль сроков;

• учет технических активов;

• обработку инцидентов;

• работу с изменениями;

• базу знаний;

• формирование отчетности;

• контроль качества обслуживания.

В результате техническое подразделение постепенно перестает работать исключительно в режиме реагирования на проблемы и получает возможность управлять услугами системно.

Когда почты и таблиц становится недостаточно

Первые признаки обычно заметны задолго до внедрения отдельной платформы.

Например, сотрудник сообщает о проблеме одному специалисту, тот пересылает сообщение другому, а спустя несколько дней никто уже точно не помнит, кто должен был решить вопрос.

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

С ростом компании такие ситуации возникают все чаще.

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

Чем локальное размещение отличается от облачного

Один из ключевых вопросов при выборе — где будет работать система.

При локальном варианте программное обеспечение размещается внутри собственной инфраструктуры компании.

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

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

Кроме того, локальная система может продолжать выполнять основные функции внутри корпоративной сети даже при ограничениях внешнего подключения.

Почему локальный вариант выбирают не все

Собственная инфраструктура дает больше контроля, но требует дополнительных ресурсов.

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

В результате первоначальные расходы могут быть выше, чем при использовании облачной модели.

Также необходимо самостоятельно контролировать состояние инфраструктуры и своевременно устанавливать обновления.

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

Сначала нужно определить свои процессы

Ошибка — начинать выбор с длинного списка функций.

Сначала стоит понять, какие задачи должна решать система именно в конкретной компании.

Одной организации достаточно централизованного приема заявок и контроля сроков. Другой требуется управление изменениями, учет оборудования и сложная маршрутизация обращений.

Третьей необходимо объединить через одну платформу обслуживание сразу нескольких подразделений.

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

Размер компании тоже имеет значение

Системы управления ИТ-услугами могут быть рассчитаны на совершенно разный масштаб.

Для небольшой команды критичны простота внедрения и понятный интерфейс.

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

Поэтому при сравнении полезно смотреть на опыт крупных внедрений и фактическую нагрузку, с которой система уже работала.

Количество функций само по себе не показывает, насколько хорошо решение будет работать при росте числа пользователей.

Обращения должны поступать через удобные каналы

Пользователи не всегда готовы самостоятельно разбираться в сложной форме заявки.

Поэтому важно оценить, через какие каналы система принимает обращения.

Это могут быть внутренний портал, электронная почта и другие предусмотренные способы.

Чем проще сотруднику сообщить о проблеме, тем меньше вероятность, что он снова напишет знакомому специалисту напрямую и обращение останется за пределами общей системы.

При этом все запросы независимо от канала желательно собирать в одном пространстве.

Настройка процессов не должна зависеть от каждой мелкой доработки

После внедрения процессы продолжают меняться.

Появляются новые категории обращений, меняются ответственные сотрудники, добавляются этапы согласования.

Поэтому важно заранее понять, насколько легко администратор может изменять формы, маршруты и правила обработки заявок.

Если для любого изменения приходится привлекать разработчиков, стоимость эксплуатации со временем увеличивается.

С другой стороны, гибкая самостоятельная настройка тоже требует сотрудников, которые понимают логику системы и способны поддерживать ее в порядке.

Интеграции могут оказаться важнее отдельных функций

Система управления ИТ-услугами редко работает полностью изолированно.

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

Поэтому еще до выбора стоит составить список необходимых интеграций.

Если нужные подключения уже предусмотрены, запуск будет проще.

Если каждую связь придется разрабатывать отдельно, стоимость и продолжительность внедрения могут заметно вырасти.

Нужно считать не только стоимость лицензии

Сравнивать решения исключительно по цене лицензии неправильно.

Для локального варианта дополнительно возникают расходы на:

• серверное оборудование;

• хранение данных;

• резервное копирование;

• внедрение;

• настройку;

• интеграции;

• техническое сопровождение;

• обновления;

• работу внутренних специалистов.

Поэтому правильнее оценивать общую стоимость владения за несколько лет.

Система с более низкой первоначальной ценой иногда оказывается дороже из-за сложной поддержки и большого объема индивидуальных доработок.

Рейтинг лучше использовать как первый фильтр

Сводная таблица или рейтинг помогают быстро сократить количество вариантов, но не должны автоматически определять победителя.

Высокая позиция означает, что решение хорошо показывает себя по совокупности выбранных критериев. Однако эти критерии не обязательно совпадают с приоритетами конкретной компании.

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

Поэтому рейтинг удобнее использовать для формирования первоначального списка, а затем сравнивать несколько подходящих вариантов более подробно.

Практический сценарий выбора начинается с требований

Работу можно разделить на несколько этапов.

Сначала определить основные процессы и количество пользователей.

Затем сформировать обязательные требования к безопасности, хранению данных и интеграциям.

После этого выбрать несколько решений, соответствующих этим условиям.

На следующем этапе полезно проверить их на реальных сценариях.

Например: создать обращение, передать его между сотрудниками, изменить приоритет, построить отчет или найти историю предыдущего инцидента.

Так быстрее становится понятно, насколько система удобна именно в ежедневной работе.

Пилот помогает обнаружить проблемы до полноценного внедрения

Описание функций и демонстрация продукта не всегда показывают реальные сложности эксплуатации.

Поэтому перед масштабным запуском полезно протестировать систему на ограниченной группе пользователей.

Во время пилота можно проверить:

• скорость работы;

• удобство интерфейса;

• маршрутизацию заявок;

• настройку ролей;

• отчеты;

• интеграции;

• работу администраторов.

После этого легче понять, какие процессы нужно изменить до полноценного внедрения.

Главное — выбирать систему под процессы, а не наоборот

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

При выборе важно искать баланс между возможностями системы и реальными потребностями.

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

Поэтому лучший вариант определяется не количеством функций и не местом в рейтинге. Он определяется тем, насколько система помогает сделать работу технического подразделения прозрачной, измеримой и управляемой без неоправданного усложнения.