Переход с Atlassian и других зарубежных инструментов управления заявками нельзя рассматривать как обычную замену интерфейса. Для бизнеса ITSM-система — это не только доска задач и реестр обращений. В ней живут процессы поддержки, эскалации, согласования изменений, база знаний, регламенты, отчеты, SLA, история инцидентов, интеграции с почтой, мониторингом, корпоративными каталогами и другими сервисами. Если перенести только карточки, но потерять правила работы, компания получит новую систему и старые проблемы.
Правильный переход начинается не с выбора платформы, а с инвентаризации процессов. Нужно понять, какие типы заявок существуют, как они маршрутизируются, кто принимает обращения, где фиксируются SLA, какие роли участвуют в согласовании, какие интеграции критичны, какие отчеты нужны руководству и что пользователи ожидают от сервиса. Только после этого можно сравнивать решения, оценивать трудоемкость миграции и планировать запуск.
Для Лаборатории ИТ-сервисов IBS тема связана не только с ITSM, но и с сопровождением корпоративных систем. Чем сложнее ERP, 1С, SAP, CRM и инфраструктурный контур, тем важнее единая система управления обращениями и изменениями. На сайте Лаборатории ИТ-сервисов IBS представлены партнерские решения SimpleOne и Первая Форма, которые могут рассматриваться в контексте импортонезависимого развития сервисных процессов.
Многие компании формулируют задачу слишком узко: «нужно заменить Jira». Но в реальности Jira часто использовалась не только как трекер задач. В ней могли быть процессы Service Desk, управление инцидентами, бэклог изменений, согласование релизов, внутренние запросы, задачи поддержки, база знаний через Confluence, интеграции с почтой и системами разработки. Поэтому вопрос не в том, какой продукт похож по интерфейсу, а в том, какие процессы нужно сохранить и какие пора пересобрать.
Если начать с выбора аналога, есть риск перенести неэффективность в новую платформу. Старые статусы, лишние поля, хаотичные очереди, дублирующиеся типы задач и неактуальные SLA останутся, только в другом инструменте. В результате пользователи получат новую систему, но качество сервиса не улучшится.
Более зрелый подход начинается с описания текущей модели. Что работает хорошо? Где пользователи теряют заявки? На каких этапах обращения зависают? Какие отчеты руководители собирают вручную? Какие статусы никто не использует? Какие категории нужны только исторически? Какие интеграции давно не поддерживаются? Ответы на эти вопросы позволяют выбрать систему под реальную операционную модель, а не под привычный экран.
Перед выбором ITSM-платформы нужно провести аудит текущего процесса управления заявками. Важно собрать не только настройки старой системы, но и фактическую практику работы. Часто регламент описывает одно, система показывает другое, а пользователи делают третье.
Что нужно описать:
Отдельно нужно понять, какие процессы связаны с поддержкой ERP, 1С и других бизнес-критичных систем. Если сервисный контур обслуживает корпоративные приложения, полезно связать ITSM-подход с общей услугой сопровождения ERP-систем.
После аудита нужно не просто перенести существующую схему, а определить целевую модель. Она отвечает на вопрос: как должна работать поддержка после перехода на новую платформу?
В целевой модели важно разделить несколько уровней. Первый — пользовательский сервис: как сотрудник создает обращение, где видит статус, как получает уведомления, как находит инструкцию. Второй — операционный контур: как заявки распределяются, как работает первая линия, когда подключаются эксперты, какие очереди используются. Третий — управленческий контур: какие метрики собираются, кто смотрит отчеты, как контролируется нагрузка и качество. Четвертый — развитие: как фиксируются изменения, как формируется бэклог, как согласуются релизы.
Если не описать целевую модель, внедрение сведется к настройке экранов. Это создает видимость проекта, но не решает вопрос качества сервиса. Пользователи по-прежнему будут писать в мессенджеры, операторы будут вручную пересылать задачи, руководители не будут видеть картину, а эксперты будут работать в перегрузке.
Требования лучше делить на несколько блоков. Это помогает не сравнивать продукты по общему впечатлению, а оценивать их применимость к конкретным процессам.
Функциональные требования:
Интеграционные требования:
Требования к эксплуатации:
Требования к внедрению:
Миграция данных — один из самых рискованных этапов. Кажется, что нужно перенести все. Но полная миграция истории может оказаться дорогой, долгой и не всегда полезной. Часть старых задач нужна только для архива, часть — для анализа SLA, часть — для расследования повторяющихся инцидентов, часть — для базы знаний.
Перед миграцией стоит разделить данные на категории:
Нужно отдельно проверить качество данных. В старой системе могут быть дубли пользователей, устаревшие категории, закрытые сервисы, некорректные статусы, задачи без владельцев, вложения без связи с обращением. Если перенести это без очистки, новая система начнет работу с мусорными данными.
Одна из типовых ошибок — копировать все статусы из старой системы. В результате в новой платформе появляются длинные маршруты, в которых пользователи и операторы путаются. Статус должен помогать понять, что происходит с обращением, а не описывать каждый внутренний шаг команды.
Для Service Desk обычно достаточно понятной логики: новое обращение, принято в работу, требуется уточнение, передано экспертам, ожидает внешнего действия, решено, закрыто. Для изменений может быть другой контур: инициировано, оценка, согласование, планирование, реализация, тестирование, выпуск, закрытие. Для запросов на доступ — свой маршрут. Главное — не смешивать разные процессы в одну универсальную схему.
Также важно настроить правила переходов. Кто может изменить статус? Когда нужно уведомление? Какие поля обязательны? В каких случаях заявка должна эскалироваться? Когда нарушается SLA? Какие причины приостановки допустимы? Именно эти детали определяют качество сервиса.
Перед промышленным запуском нужна проверка на реальных сценариях. Пилот не должен ограничиваться демонстрацией интерфейса. Нужно пройти типовые и сложные случаи.
Примеры сценариев:
По результатам пилота нужно фиксировать не только ошибки системы, но и нестыковки процесса. Возможно, пользователям не понятны категории. Возможно, операторы не видят важные поля. Возможно, экспертам не хватает шаблонов. Возможно, руководителям нужны другие отчеты. Пилот нужен именно для того, чтобы не переносить эти проблемы в промышленный запуск.
Даже хорошая система не заработает, если пользователи не понимают, зачем она нужна. При переходе после Atlassian часть сотрудников может воспринимать новый инструмент как ухудшение: другой интерфейс, другие статусы, новые правила создания заявок. Поэтому обучение должно объяснять не только «куда нажать», но и что меняется в сервисной модели.
Для пользователей нужны короткие инструкции: как создать заявку, как выбрать услугу, как приложить файл, где смотреть статус, как ответить на уточнение, когда обращение считается закрытым. Для операторов нужны регламенты: как классифицировать заявки, как эскалировать, как работать с SLA, как оформлять решение, как использовать базу знаний. Для руководителей нужны отчеты: нагрузка, просрочки, качество, повторные инциденты, динамика обращений.
После запуска важно оставить окно стабилизации. В этот период команда собирает обратную связь, правит формы, уточняет маршруты, дорабатывает уведомления и помогает пользователям перейти на новую привычку.
Выбор зависит от целевой модели. Если компания строит зрелую сервисную модель с каталогом услуг, SLA, маршрутизацией, автоматизацией и отчетностью, нужно смотреть на глубину ITSM-функций, гибкость настройки и возможности интеграции. Если задача шире и включает согласование бизнес-процессов, внутренние заявки, проектные сценарии и работу подразделений, требования могут отличаться.
SimpleOne на сайте Лаборатории ИТ-сервисов IBS представлен как партнерское решение. Первая Форма также представлена в партнерском разделе. Сравнивать такие решения нужно не по одному признаку, а по набору критериев: поддерживаемые процессы, настройка ролей, интеграции, масштабирование, удобство для пользователей, стоимость владения, скорость внедрения, доступность экспертизы и соответствие требованиям ИБ.
Для некоторых компаний оптимален поэтапный подход: сначала перенести Service Desk и базовые обращения, затем добавить управление изменениями, потом развивать каталог услуг, базу знаний, отчеты и интеграции. Такой путь снижает риск большого одномоментного проекта.
Переход на новую ITSM-систему требует сочетания продуктовой экспертизы, процессного анализа и опыта сопровождения корпоративных систем. Подход должен включать аудит текущей модели, описание целевых процессов, выбор платформы, проектирование маршрутов, миграцию данных, настройку интеграций, пилот, обучение и сопровождение после запуска.
Если в компании ITSM связана с поддержкой ERP, 1С, SAP, CRM или инфраструктуры, важно учитывать не только обращения пользователей, но и процессы изменений, релизы, инциденты, бизнес-критичность сервисов и интеграции. Для обсуждения перехода можно использовать форму связи Лаборатории ИТ-сервисов IBS.
Чем ITSM-система отличается от обычного трекера задач?
Трекер помогает вести задачи. ITSM-система управляет сервисом: принимает обращения, назначает исполнителей, контролирует SLA, поддерживает каталог услуг, хранит историю инцидентов, помогает строить отчеты и управлять качеством поддержки.
Можно ли просто перенести все задачи из Jira в новую систему?
Технически можно перенести многое, но это не всегда правильно. Перед миграцией нужно очистить данные, отделить активные обращения от архива, проверить статусы, категории, пользователей, вложения и отчеты. Иначе новая система начнет работу с накопленными ошибками старой.
Сколько времени занимает переход на новую ITSM-платформу?
Срок зависит от масштаба: количества процессов, интеграций, исторических данных, ролей и требований к отчетности. Небольшой пилот можно запустить быстрее, но полноценный переход с миграцией, обучением и стабилизацией требует отдельного проекта.
Что важнее: выбрать платформу или описать процессы?
Сначала нужно описать процессы. Платформа должна поддерживать целевую модель сервиса. Если выбрать систему без анализа процессов, можно получить инструмент, который не подходит под реальные сценарии поддержки.
Переход с Atlassian — это шанс не только заменить зарубежный инструмент, но и привести в порядок сервисную модель. Важно не потерять процессы, данные, роли и отчетность, но также не копировать старый хаос в новую платформу. Правильная последовательность выглядит так: аудит текущих процессов, целевая модель, требования, выбор решения, миграция, настройка, пилот, обучение и стабилизация. Тогда новая ITSM-система становится не вынужденной заменой, а инструментом управляемой поддержки и развития корпоративных сервисов.