Переход на российскую ITSM-платформу начинается не с названия продукта. Первая рабочая точка - перечень услуг, типов обращений, ролей поддержки, согласований, интеграций и отчетов, которые уже живут в старом контуре.
ITSM (IT Service Management) в документации SimpleOne описан как подход к доставке, управлению и улучшению ИТ-услуг внутри организации. Это полезная формулировка для миграции: переносится не "портал заявок", а способ управлять услугами, инцидентами, изменениями, знаниями и конфигурационными данными.
23 мая 2026 года в документации SimpleOne ITSM выбранная версия указана как 1.20.1. В навигации раздела перечислены service portfolio, configuration, user query, service request, incident, problem, monitoring and event management, change enablement, matrices, Telegram bots и release notes. Такой список нужен не для рекламы, а для проверки покрытия.
Практический аудит начинается с матрицы процессов. В одной колонке фиксируются реальные процессы старого решения: инциденты, запросы на обслуживание, изменения, база знаний, CMDB, события мониторинга, SLA-отчеты. Во второй колонке отмечается, где это описано в документации целевой платформы. В третьей остаются пробелы: кастомные поля, интеграции, отчеты, очереди и права.
CMDB нельзя переносить как обычную таблицу. Если в старом контуре конфигурационные единицы дублировались или не имели владельцев, новая платформа только покажет беспорядок быстрее. До миграции нужно определить классы объектов, обязательные поля, правила актуализации и связь с услугами. Иначе поддержка получает красивый интерфейс с теми же неточными данными.
Лицензирование проверяется до пилота. В лицензионной политике SimpleOne v.1.6.6, действующей с 25.02.2026, SimpleOne.ITSM указан среди продуктов, а модель по агентам применима к SimpleOne.Platform, SimpleOne.ITSM, SimpleOne.CRM и SimpleOne.SDLC. Активным считается пользователь со статусом Active в месячном отчетном периоде; отдельная лицензия нужна агенту для каждого приложения, где ему назначена роль или доступ к таблицам.
В той же политике указано допустимое превышение не более чем на 30% от количества лицензий, приобретенных на текущий год подписки. Это не запас "на всякий случай". Для плана перехода такая строка означает, что временные учетные записи внедренцев, замены сотрудников и встроенные записи должны попасть в расчет, а не появиться после счета.
Поддержка тоже должна быть частью требований. В политике SimpleOne On-premise поддержка включает прием и обработку обращений, доступ к обновлениям после публикации релиза, консультации контактных лиц, исправление дефектов путем выпуска новой версии и регистрацию контактных лиц на портале Service Desk. Это отделяется от проекта внедрения, обучения и миграции данных.
Правила Customer Care задают каналы обращения: веб-портал Service Desk, email servicedesk@simpleone.ru, телефон +7 (495) 181 85 20 и Telegram-бот. Там же указано, что каналы равноценны по приоритету обработки, а обращения аутентифицируются заданным способом. Для эксплуатации это превращается в runbook: кто имеет право писать в поддержку, какие данные прикладываются, кто принимает обновление.
Релизы проверяются как индикатор развития продукта. SimpleOne опубликовала новость об ITSM 1.19.0 26 декабря 2025 года: среди изменений названы матрица расчета влияния инцидентов, отмена и возобновление обращений на портале, массовое комментирование и обработка задач. Для миграции это повод сверить, какие функции уже есть в версии, а какие остаются в доработке проекта.
Юридический блок нельзя закрывать фразой "российский продукт". На сайте SimpleOne есть утверждение, что платформа включена в реестр российского ПО. Если закупка зависит от реестра, импортозамещения или внутреннего положения о закупках, нужна отдельная проверка официальной карточки реестра и договора. В статье не стоит заменять ее пересказом с сайта вендора.
Пилот должен проверять не интерфейс, а рабочий день службы поддержки. Достаточно выбрать один поток: например, инциденты первой линии с эскалацией, SLA-контролем, уведомлениями, статьей базы знаний и связью с конфигурационной единицей. Если этот поток проходит от заявки до отчета без ручных обходов, можно планировать следующую волну.
Реальный план перехода выглядит как реестр решений. Для каждого процесса указаны владелец, данные, интеграции, лицензии, права, поддержка, релизная зависимость и критерий приемки. Название продукта появляется в этом документе поздно. Сначала организация доказывает, что понимает собственный ITSM-контур.
Источник обложки: https://www.pexels.com/photo/people-having-a-meeting-at-the-office-9301256/
Читайте также: