Оставить заявку на демо
Заполните форму, и мы свяжемся с вами в течение рабочего дня
Как перейти на Service Desk с альтернативного решения без потери процессов
28.04.2026
До сих пор около 20% российских компаний не используют Service Desk и продолжают обрабатывать ИТ-запросы в ручном режиме. Процессы при этом часто «хромают», но команда привыкает и справляется. Возникает ощущение, что все работает «нормально». Поэтому сама идея перехода на полноценную систему вызывает сопротивление: есть страх потерять то, что уже хоть как-то функционирует.
Однако за этим «нормально» скрываются реальные потери: заявки теряются, сроки исполнения непредсказуемы, нагрузка распределяется неравномерно, а управляемость фактически отсутствует. В этой статье развенчиваем миф о том, что переход на Service Desk — это долго, дорого и неизбежно ломает процессы. А еще по шагам разбираем три распространенных сценария перехода: с Excel, устаревшего сервис-деска и таск-трекер — без хаоса и потерь.
Однако за этим «нормально» скрываются реальные потери: заявки теряются, сроки исполнения непредсказуемы, нагрузка распределяется неравномерно, а управляемость фактически отсутствует. В этой статье развенчиваем миф о том, что переход на Service Desk — это долго, дорого и неизбежно ломает процессы. А еще по шагам разбираем три распространенных сценария перехода: с Excel, устаревшего сервис-деска и таск-трекер — без хаоса и потерь.
Почему переход пугает
Компании часто не понимают, зачем что-то менять, если «и так все работает нормально». Нормально в том смысле, что процесс выстроен кое-как и плюс-минус работает. До автоматизации IT-поддержки еще далеко. К этому привыкают. По принципу «с милым рай и в шалаше» можно адаптироваться даже к самым неудобным решениям и интерфейсам. Отсюда типичные аргументы: «у нас вся история в Excel», «мы привыкли к Jira», «команда не хочет учить новый инструмент». За этим стоит не столько рациональный выбор, сколько сопротивление изменениям: проще оставить как есть, чем отстраивать что-то заново и перестраивать привычный ход вещей.
Новый инструмент (поставьте здесь знак равенства) переносить процессы, разбираться в настройках, переделывать интеграции, обучать персонал. У некоторых заказчиков за плечами есть опыт проектов, которые растягивались на месяцы или даже годы — особенно если речь о сложных ITSM-системах как для внутренней техподдержки, так и для внешних пользователей.
Но давайте договоримся: длительность и сложность — свойства не по умолчанию, а следствие «избранного» пути. При должной организации миграция будет быстрой и управляемой. Например, переход на TIKITRIK занимает от 10 дней: за это время можно запустить сервисы и начать работать в полноценной новой системе.
Новый инструмент (поставьте здесь знак равенства) переносить процессы, разбираться в настройках, переделывать интеграции, обучать персонал. У некоторых заказчиков за плечами есть опыт проектов, которые растягивались на месяцы или даже годы — особенно если речь о сложных ITSM-системах как для внутренней техподдержки, так и для внешних пользователей.
Но давайте договоримся: длительность и сложность — свойства не по умолчанию, а следствие «избранного» пути. При должной организации миграция будет быстрой и управляемой. Например, переход на TIKITRIK занимает от 10 дней: за это время можно запустить сервисы и начать работать в полноценной новой системе.
СЦЕНАРИЙ 1: Переход с Excel и ручного управления
Компании такого типа — это обычно 200–500 сотрудников и ИТ-отдел на 1–5 человек. Несмотря на то, что Service Desk для среднего бизнеса также подходит, здесь все держится на ручном управлении. Заявки принимают где угодно — в мессенджерах, по почте, по телефону, «поймали в коридоре», в курилке, столовой, на улице. Учет ведут в одной или нескольких таблицах, которые считаются системой. Хотя по факту это просто фиксация задним числом: что-то записали, что-то забыли, что-то потерялось. Процессы вроде есть, но они не формализованы. Каждый работает, как привык. В итоге нет ни стандартизированного SLA, ни нормальной приоритизации, ни предметной аналитики. Альтернатива — Service Desk вместо Excel.
Пошаговый план перехода
Шаг 1. Определите ожидания и цели
Как внедрить Service Desk? Зафиксируйте, что вы хотите получить от перехода: сэкономить, повысить удовлетворенность сотрудников, навести порядок в процессах, сделать их прозрачными. В идеале — прийти к модели, где есть единая система: пользователи видят свои обращения, исполнители их обрабатывают, менеджеры контролируют, а бизнес понимает, почему на ИТ уходит столько ресурсов и как эти ресурсы распределяются.
Шаг 2. Выберите вендора и решение
Под цели из первого шага подбирается инструмент. Очевидно, это должен быть вендор, который дает не только систему, но и экспертизу в сервисном подходе: помогает учесть текущий ландшафт, особенности бизнеса и на этой основе правильно настроить инструмент. Сам заказчик «изнутри» часто не может сделать это качественно, поскольку варится в собственном пузыре.
Шаг 3. Проведите аудит совместно с вендором
В случае с Excel часто выясняется, что с точки зрения сервисного подхода отсутствует почти все: нет каталога услуг и сервисов, целевых показателей и критериев качества, групп исполнителей, стандартных маршрутов согласований, временных метрик (реакция, решение), нормальной отчетности. Есть лишь базовое понимание что делает ИТ, без ролей, прав доступа, уведомлений и управляемости.
Шаг 4. Разработайте каталог услуг и все, что с ним связано
В первую очередь зафиксируйте, что делает ИТ, а что — сторонние организации. Часто часть задач закрывают другие направления, и это важно сразу отразить, чтобы не создавать ложных ожиданий.
Когда появляется четкое понимание зоны ответственности, можно формировать каталог услуг. Уже на этом этапе важно определить конкретные услуги, т. е. что именно ИТ предоставляет бизнесу, и объединить их в сервисы.
Далее задаются критерии качества сервисов. На старте они могут быть ориентировочными — «по ощущениям» или на основе опыта, — с последующей корректировкой по фактическим данным. Если даже базового понимания нет, лучше отложить этот шаг, чем фиксировать значения «с потолка».
По каждой услуге определяются целевые нормативы: за какое время она должна выполняться. Для инцидентов важно задать целевые значения по различным приоритетам, т. е. в зависимости от срочности и влияния.
Дальше нужно определить группы исполнителей: какие команды будут задействованы и какие услуги они будут выполнять — обрабатывать инциденты, сервисные запросы, консультации и т. д. Также нужно задать им графики работы. Затем — формализовать, какие услуги требуют согласования и как эти согласования проходят. Определить группы и конкретных согласующих.
В результате формируется рабочий каталог услуг — сначала базовый, но уже пригодный для управления и дальнейшего развития.
Шаг 5. Внедрите и запустите решение
Перенесите разработанные процессы и настройки в систему: задайте автоматические маршруты определения групп исполнителей, приоритизацию по умолчанию, временные параметры для реакции и выполнения, назначьте согласующих, дополнительные поля в формах обращений и т. п. Будьте готовы к тому, что часть вещей придется корректировать уже в процессе — это нормальная практика, а не ошибка планирования. На этом этапе и в первое время после запуска крайне важна оперативная приоритетная поддержка со стороны вендора. Производитель должен не просто отдать систему, а помогать оперативно вносить изменения и адаптировать решение под реальные процессы.
Перед полноценным запуском можно протестировать систему на пилотной группе, чтобы проверить логику работы и собрать первую обратную связь. Если масштаб компании позволяет, допустим и более быстрый сценарий — запуск сразу в проде с последующей донастройкой.
Отдельное внимание уделите коммуникации. Важно заранее оповестить сотрудников, но не в формате «мы внедряем новую систему», а через ценность: «мы улучшаем качество ИТ-услуг, ускоряем обработку заявок, создаем удобное согласование и делаем процессы прозрачнее».
Шаг 6. Продолжайте адаптировать
Компании меняются. Значит, каталог услуг нужно регулярно пересматривать, снимать метрики, анализировать, укладываетесь ли вы в заявленные сроки, как это влияет на простои и загрузку команд. При необходимости корректируются SLA, вводятся или уточняются пороговые значения качества.
И, конечно, важно постоянно слушать и слышать пользователей. Именно их опыт показывает, работает ли система в реальности: если появляются жалобы, значит, где-то нарушена логика процесса, не учтены ожидания или система усложняет то, что должна упрощать. В конечном счете Service Desk существует не ради отчетности, а ради того, чтобы пользователю было проще и быстрее получать результат.
Как внедрить Service Desk? Зафиксируйте, что вы хотите получить от перехода: сэкономить, повысить удовлетворенность сотрудников, навести порядок в процессах, сделать их прозрачными. В идеале — прийти к модели, где есть единая система: пользователи видят свои обращения, исполнители их обрабатывают, менеджеры контролируют, а бизнес понимает, почему на ИТ уходит столько ресурсов и как эти ресурсы распределяются.
Шаг 2. Выберите вендора и решение
Под цели из первого шага подбирается инструмент. Очевидно, это должен быть вендор, который дает не только систему, но и экспертизу в сервисном подходе: помогает учесть текущий ландшафт, особенности бизнеса и на этой основе правильно настроить инструмент. Сам заказчик «изнутри» часто не может сделать это качественно, поскольку варится в собственном пузыре.
Шаг 3. Проведите аудит совместно с вендором
В случае с Excel часто выясняется, что с точки зрения сервисного подхода отсутствует почти все: нет каталога услуг и сервисов, целевых показателей и критериев качества, групп исполнителей, стандартных маршрутов согласований, временных метрик (реакция, решение), нормальной отчетности. Есть лишь базовое понимание что делает ИТ, без ролей, прав доступа, уведомлений и управляемости.
Шаг 4. Разработайте каталог услуг и все, что с ним связано
В первую очередь зафиксируйте, что делает ИТ, а что — сторонние организации. Часто часть задач закрывают другие направления, и это важно сразу отразить, чтобы не создавать ложных ожиданий.
Когда появляется четкое понимание зоны ответственности, можно формировать каталог услуг. Уже на этом этапе важно определить конкретные услуги, т. е. что именно ИТ предоставляет бизнесу, и объединить их в сервисы.
Далее задаются критерии качества сервисов. На старте они могут быть ориентировочными — «по ощущениям» или на основе опыта, — с последующей корректировкой по фактическим данным. Если даже базового понимания нет, лучше отложить этот шаг, чем фиксировать значения «с потолка».
По каждой услуге определяются целевые нормативы: за какое время она должна выполняться. Для инцидентов важно задать целевые значения по различным приоритетам, т. е. в зависимости от срочности и влияния.
Дальше нужно определить группы исполнителей: какие команды будут задействованы и какие услуги они будут выполнять — обрабатывать инциденты, сервисные запросы, консультации и т. д. Также нужно задать им графики работы. Затем — формализовать, какие услуги требуют согласования и как эти согласования проходят. Определить группы и конкретных согласующих.
В результате формируется рабочий каталог услуг — сначала базовый, но уже пригодный для управления и дальнейшего развития.
Шаг 5. Внедрите и запустите решение
Перенесите разработанные процессы и настройки в систему: задайте автоматические маршруты определения групп исполнителей, приоритизацию по умолчанию, временные параметры для реакции и выполнения, назначьте согласующих, дополнительные поля в формах обращений и т. п. Будьте готовы к тому, что часть вещей придется корректировать уже в процессе — это нормальная практика, а не ошибка планирования. На этом этапе и в первое время после запуска крайне важна оперативная приоритетная поддержка со стороны вендора. Производитель должен не просто отдать систему, а помогать оперативно вносить изменения и адаптировать решение под реальные процессы.
Перед полноценным запуском можно протестировать систему на пилотной группе, чтобы проверить логику работы и собрать первую обратную связь. Если масштаб компании позволяет, допустим и более быстрый сценарий — запуск сразу в проде с последующей донастройкой.
Отдельное внимание уделите коммуникации. Важно заранее оповестить сотрудников, но не в формате «мы внедряем новую систему», а через ценность: «мы улучшаем качество ИТ-услуг, ускоряем обработку заявок, создаем удобное согласование и делаем процессы прозрачнее».
Шаг 6. Продолжайте адаптировать
Компании меняются. Значит, каталог услуг нужно регулярно пересматривать, снимать метрики, анализировать, укладываетесь ли вы в заявленные сроки, как это влияет на простои и загрузку команд. При необходимости корректируются SLA, вводятся или уточняются пороговые значения качества.
И, конечно, важно постоянно слушать и слышать пользователей. Именно их опыт показывает, работает ли система в реальности: если появляются жалобы, значит, где-то нарушена логика процесса, не учтены ожидания или система усложняет то, что должна упрощать. В конечном счете Service Desk существует не ради отчетности, а ради того, чтобы пользователю было проще и быстрее получать результат.
Кейс. От Excel и «черного ящика» к прозрачному Service Desk
Ситуация. Компания работала с обращениями через Excel с макросами, доступ к которому был только у ИТ. В нем фиксировались обращения и «как-то» учитывалось время. Статистика формально была, но из-за проблем в исходных данных она давала сильные искажения, и реальная загрузка оставалась непонятной. Дополнительно классическая ситуация: разрозненные точки сбора обращений и полное отсутствие прозрачности процессов. Согласования по почте, на словах и на основе сиюминутного видения. Для пользователей и бизнеса ИТ выглядел как «черный ящик».
Проблема. Низкое качество исходных данных приводило к искаженной аналитике и отсутствию понимания реальной загрузки ИТ. Не было прозрачности процессов и единого жизненного цикла обращений. Пользователи не понимали, на каком этапе находится их запрос и почему он не решается «здесь и сейчас». Это вызывало недовольство и снижало доверие к ИТ.
Действия. Компания приняла решение внедрить Service Desk. За три недели был проведен аудит, сформирован каталог услуг и внедрена единая система поддержки. Настроили сквозной процесс обработки обращений: от регистрации до исполнения и контроля. Подключили всех участников — пользователей, согласующих, исполнителей и менеджеров. Реализовали уведомления, напоминания и базовую систему метрик.
Результат. Была получена единая система, в которой все участники взаимодействуют в рамках прозрачных процессов. Все обращения, а также процессы согласования, исполнения и контроля стали отслеживаемыми. Обеспечена измеряемость: как количественная, так и качественная. Сроки согласования сократились в 3 раза, стали понятными и удобными. Пользователи быстро привыкли к решению, количество претензий существенно снизилось. В итоге «грабли убрали», при этом бизнес продолжил работать без остановки.
Таблица «До / После» — Excel vs Service Desk
Проблема. Низкое качество исходных данных приводило к искаженной аналитике и отсутствию понимания реальной загрузки ИТ. Не было прозрачности процессов и единого жизненного цикла обращений. Пользователи не понимали, на каком этапе находится их запрос и почему он не решается «здесь и сейчас». Это вызывало недовольство и снижало доверие к ИТ.
Действия. Компания приняла решение внедрить Service Desk. За три недели был проведен аудит, сформирован каталог услуг и внедрена единая система поддержки. Настроили сквозной процесс обработки обращений: от регистрации до исполнения и контроля. Подключили всех участников — пользователей, согласующих, исполнителей и менеджеров. Реализовали уведомления, напоминания и базовую систему метрик.
Результат. Была получена единая система, в которой все участники взаимодействуют в рамках прозрачных процессов. Все обращения, а также процессы согласования, исполнения и контроля стали отслеживаемыми. Обеспечена измеряемость: как количественная, так и качественная. Сроки согласования сократились в 3 раза, стали понятными и удобными. Пользователи быстро привыкли к решению, количество претензий существенно снизилось. В итоге «грабли убрали», при этом бизнес продолжил работать без остановки.
Таблица «До / После» — Excel vs Service Desk
Параметр | Excel / ручное управление | Service Desk |
Учет заявок | Частичный, вручную, часть теряется | Централизованный, фиксируются все обращения |
SLA | Отсутствует или «на словах» | Четко задан, контролируется |
Аналитика | Нет предметной аналитики | Полноценная: отчеты и метрики |
Скорость выполнения | Непредсказуемая, зависит от загрузки и «памяти» сотрудника | Управляемая, зависит от приоритетов и SLA |
История обращений | Разрозненная (Excel, почта, мессенджеры) | Полная, хранится в единой системе |
СЦЕНАРИЙ 2: Переход с существующего Service Desk
Среди основных причин миграции на Service Desk со старой системы — импортозамещение, устаревшая или слишком сложная и громоздкая система (когда до 80% функционала просто не используется), высокая стоимость владения.
При этом база готовности для внедрения новой тикет-системы у таких организаций довольно высокая. И это очевидный плюс. У компании (и ее сотрудников) уже есть опыт взаимодействия с сервисной системой, выстроенные процессы и каталог услуг, пусть даже неидеальный. Есть понимание по сервисам, целевым показателям, времени реакции и выполнения. То есть это уже не работа с нуля, а доработка и переосмысление того, что накопилось.
При этом база готовности для внедрения новой тикет-системы у таких организаций довольно высокая. И это очевидный плюс. У компании (и ее сотрудников) уже есть опыт взаимодействия с сервисной системой, выстроенные процессы и каталог услуг, пусть даже неидеальный. Есть понимание по сервисам, целевым показателям, времени реакции и выполнения. То есть это уже не работа с нуля, а доработка и переосмысление того, что накопилось.
Пошаговый план перехода
Шаг 1. Определите ожидания и цели
Сформулируйте, зачем компании мигрировать на новую платформу. Например, чтобы импортозаместить иностранного вендора, получить стабильную поддержку, удобный и быстрый интерфейс и т. д.
Шаг 2. Выберите решение
Подберите систему под ожидания и критерии успешности.
Шаг 3. Проведите аудит совместно с вендором
Если в случае с Excel была низкая сервисная база, то здесь ситуация другая: у компании уже есть работающие процессы по сервисной модели. Однако копировать все как есть не рекомендуется. Гораздо правильнее пересмотреть каталог услуг, понять что действительно нужно, а что нет, и перестроить структуру так, чтобы она стала удобнее и для пользователей, и для исполнителей. Всегда есть место для улучшения и оптимизации.
Аудит необходимо проводить совместными усилиями внутренней ИТ-команды и вендора, потому что у каждого участника есть своя критически важная экспертиза. Внутренняя команда лучше знает реальные процессы и ограничения бизнеса, а вендор — возможности системы и лучшие практики построения сервисной модели.
Шаг 4. Внедрите и запустите решение
В фоновом режиме проведите технические работы: настройку системы, доработку процессов и подготовку интеграций. Отдельное внимание уделите переключению на новую систему, которое должно пройти максимально бесшовно.
В зависимости от масштаба и зрелости процессов можно запускать новую систему поэтапно. Например, сначала переведите обращения, не требующие согласования, чтобы снизить риски и сохранить стабильность текущих процессов. Затем подключите заявки с согласованиями. И уже финальным этапом переведите внутренние сервисы и «скрытые» услуги, которые доступны не всем пользователям.
Сформулируйте, зачем компании мигрировать на новую платформу. Например, чтобы импортозаместить иностранного вендора, получить стабильную поддержку, удобный и быстрый интерфейс и т. д.
Шаг 2. Выберите решение
Подберите систему под ожидания и критерии успешности.
Шаг 3. Проведите аудит совместно с вендором
Если в случае с Excel была низкая сервисная база, то здесь ситуация другая: у компании уже есть работающие процессы по сервисной модели. Однако копировать все как есть не рекомендуется. Гораздо правильнее пересмотреть каталог услуг, понять что действительно нужно, а что нет, и перестроить структуру так, чтобы она стала удобнее и для пользователей, и для исполнителей. Всегда есть место для улучшения и оптимизации.
Аудит необходимо проводить совместными усилиями внутренней ИТ-команды и вендора, потому что у каждого участника есть своя критически важная экспертиза. Внутренняя команда лучше знает реальные процессы и ограничения бизнеса, а вендор — возможности системы и лучшие практики построения сервисной модели.
Шаг 4. Внедрите и запустите решение
В фоновом режиме проведите технические работы: настройку системы, доработку процессов и подготовку интеграций. Отдельное внимание уделите переключению на новую систему, которое должно пройти максимально бесшовно.
В зависимости от масштаба и зрелости процессов можно запускать новую систему поэтапно. Например, сначала переведите обращения, не требующие согласования, чтобы снизить риски и сохранить стабильность текущих процессов. Затем подключите заявки с согласованиями. И уже финальным этапом переведите внутренние сервисы и «скрытые» услуги, которые доступны не всем пользователям.
«Либо можно выбрать более кардинальный и, по моей практике, более эффективный подход — с конкретной даты вся работа полностью переходит в новую систему. Такой вариант не растягивает процесс переключения во времени, позволяет сотрудникам быстрее адаптироваться к изменениям и сокращает период двойной жизни двух систем».
Артем Хижний
Генеральный директор РИКИТЛАБ
Отдельно важно учесть интеграции — скорее всего, они уже есть в текущем контуре, и их нужно корректно перенести и проверить на этапе внедрения. Очень желательно наличие тестовой среды: она не всегда обязательна, но существенно снижает риски и дает пространство для безопасных изменений. Если ее нет — это не критично, но тогда подготовка к переключению должна быть еще более аккуратной.
Предусмотрите архив старой системы, поскольку миграция истории заявок скорее всего будет невозможна. Часть обращений является значимой с точки зрения доступов, решений и истории изменений. Чтобы не потерять этот контекст, необходимо сохранять архив в течение определенного времени.
Не забудьте рассказать сотрудникам о запуске новой системы, сделав упор на преимущества, удобства и новые возможности, которые она несет.
Шаги 5. Продолжайте адаптировать
И, наконец, после внедрения начинается самый важный этап — адаптация. Система начинает жить в реальной эксплуатации: появляются донастройки, корректировки процессов, обратная связь от пользователей. Здесь же критична роль вендора — не только на этапе запуска, но и дальше, в поддержке и развитии системы. Потому что внедрение на самом деле не заканчивается переключением, оно просто переходит в режим постоянного улучшения.
Предусмотрите архив старой системы, поскольку миграция истории заявок скорее всего будет невозможна. Часть обращений является значимой с точки зрения доступов, решений и истории изменений. Чтобы не потерять этот контекст, необходимо сохранять архив в течение определенного времени.
Не забудьте рассказать сотрудникам о запуске новой системы, сделав упор на преимущества, удобства и новые возможности, которые она несет.
Шаги 5. Продолжайте адаптировать
И, наконец, после внедрения начинается самый важный этап — адаптация. Система начинает жить в реальной эксплуатации: появляются донастройки, корректировки процессов, обратная связь от пользователей. Здесь же критична роль вендора — не только на этапе запуска, но и дальше, в поддержке и развитии системы. Потому что внедрение на самом деле не заканчивается переключением, оно просто переходит в режим постоянного улучшения.
Кейс. Как ITMS перешла с ServiceNow на TIKITRIK за 3 месяца
Ситуация. Группа компаний ITMS, следуя курсу на технологическую независимость, приняла решение перейти с зарубежного ITSM-решения ServiceNow на российский продукт. Требовалось обеспечить непрерывность ИТ-сервисов для более чем 2500 сотрудников в России и Белоруссии и сохранить текущий уровень сервиса при масштабной нагрузке.
Проблема. Основные вызовы — импортозамещение без потери качества, высокая нагрузка (до 10 тыс. обращений в месяц) и необходимость сохранить все ключевые процессы: инциденты, сервисные запросы, изменения и базу знаний. Дополнительно требовалось обеспечить доступ для распределенных команд и внешних подрядчиков.
Действия. ITMS провела анализ рынка и выбрала TIKITRIK Service Desk как оптимальное решение. В рамках проекта были перенесены и адаптированы все процессы ITSM, настроен доступ с мобильных устройств и подключены внешние службы поддержки (более 100 групп). Переход был реализован бесшовно и занял менее трех месяцев.
Результат. Компания сохранила уровень сервиса и обеспечила стабильную работу ИТ для всей организации. При этом система стала быстрее и удобнее для пользователей, а затраты на управление ИТ-сервисами существенно сократились, что сделало TIKITRIK эффективной альтернативой зарубежным решениям.
Проблема. Основные вызовы — импортозамещение без потери качества, высокая нагрузка (до 10 тыс. обращений в месяц) и необходимость сохранить все ключевые процессы: инциденты, сервисные запросы, изменения и базу знаний. Дополнительно требовалось обеспечить доступ для распределенных команд и внешних подрядчиков.
Действия. ITMS провела анализ рынка и выбрала TIKITRIK Service Desk как оптимальное решение. В рамках проекта были перенесены и адаптированы все процессы ITSM, настроен доступ с мобильных устройств и подключены внешние службы поддержки (более 100 групп). Переход был реализован бесшовно и занял менее трех месяцев.
Результат. Компания сохранила уровень сервиса и обеспечила стабильную работу ИТ для всей организации. При этом система стала быстрее и удобнее для пользователей, а затраты на управление ИТ-сервисами существенно сократились, что сделало TIKITRIK эффективной альтернативой зарубежным решениям.
СЦЕНАРИЙ 3: Переход с Jira Software и Яндекс Трекер
Ключевая проблема применения Jira и других таск трекеров в разрезе ИТ-услуг заключается в том, что эти инструменты — про разработку и проектную деятельность, где есть ограниченные по времени задачи и понятный финал. Service Desk — это про операционную деятельность, которая по своей природе непрерывна и требует постоянного управления, контроля качества и изменений. ИТ-команды часто «натягивают» таск-трекеры на процессы поддержки, пытаясь закрыть сервисные задачи там, где система изначально проектировалась под другое. В итоге это не всегда просто и эффективно, а где-то даже контрпродуктивно. Поэтому полноценная замена Яндекс Трекер, а также альтернатива Jira — это Service Desk.
Сравнительная таблица
Сравнительная таблица
Параметр | Jira / таск-трекер | TIKITRIK Service Desk |
Основное назначение | Трекер задач / разработка | ITSM / поддержка пользователей |
SLA из коробки | Требует настройки/плагинов/доработки | Встроенный компонент для настройки |
Каталог услуг | Не формализован | Есть |
Интерфейс для пользователей | Не заточен под сервисную поддержку | Интуитивный, User-Centric |
Сервисный подход | Частично | Полностью |
Стоимость лицензий | Высокая (особенно Jira) | Оптимальная и прозрачная без доп. расходов |
Локализация для РФ | Частичная / ограничения | Полная, российский вендор |
Пошаговый план перехода
Подробный разбор пошагового перехода на Service Desk вместо Jira см. в Сценарии 1 (переход с Excel на Service Desk), поскольку логика с таск-трекерами в целом сохраняется. Кроме одного: в отличие от Excel, ситуация уже более зрелая — у компании, скорее всего, есть базовое «меню услуг», понимание сервисов и логики работы, пусть и не до конца формализованное. Это, с одной стороны, облегчает старт перехода, но с другой — не отменяет необходимости пересборки и нормализации модели.
Отдельный важный момент — работа с таск-трекерами. Их не нужно полностью убирать или «ломать»: в командах, где они действительно эффективны (разработка, внутренние проекты и т. д.), они могут и должны остаться. Важно не пытаться заменить все одним инструментом, а разделить контуры: Service Desk — для сервисных процессов, таск-трекеры — для продуктовой и проектной работы.
Отдельный важный момент — работа с таск-трекерами. Их не нужно полностью убирать или «ломать»: в командах, где они действительно эффективны (разработка, внутренние проекты и т. д.), они могут и должны остаться. Важно не пытаться заменить все одним инструментом, а разделить контуры: Service Desk — для сервисных процессов, таск-трекеры — для продуктовой и проектной работы.
Кейс. Звук оптимизировал нагрузку на ИТ-службу при росте бизнеса с помощью российского TIKITRIK
Ситуация. HiFi-стриминг «Звук» управлял ИТ-обращениями через разрозненные каналы — мессенджеры, почту, таск-менеджер и телефон. Единой системы учета и обработки заявок IT не было, что затрудняло контроль процессов и работу ИТ-службы.
Проблема. Отсутствие централизованной системы приводило к перегрузке ИТ-команды, потере прозрачности обращений и невозможности корректно считать SLA. Также требовалось сохранить привычные каналы коммуникации и при этом выстроить управляемый процесс.
Действия. Для перехода на сервисную модель компания выбрала российское ITSM-решение TIKIRIK Service Desk. В рамках проекта были настроены ITIL-процессы и создана единая точка входа для обращений с возможностью работы через привычные каналы. Полный цикл обработки заявок — от регистрации до контроля исполнения — был запущен всего за 2 месяца.
Результат. Компания получила единую систему управления ИТ-услугами с возможностью расчета SLA. Среднее время ответа сократилось с 25 до 13 минут, SLA реакции достиг 95%, а процессы ИТ-службы стали прозрачными и управляемыми благодаря TIKITRIK.
Проблема. Отсутствие централизованной системы приводило к перегрузке ИТ-команды, потере прозрачности обращений и невозможности корректно считать SLA. Также требовалось сохранить привычные каналы коммуникации и при этом выстроить управляемый процесс.
Действия. Для перехода на сервисную модель компания выбрала российское ITSM-решение TIKIRIK Service Desk. В рамках проекта были настроены ITIL-процессы и создана единая точка входа для обращений с возможностью работы через привычные каналы. Полный цикл обработки заявок — от регистрации до контроля исполнения — был запущен всего за 2 месяца.
Результат. Компания получила единую систему управления ИТ-услугами с возможностью расчета SLA. Среднее время ответа сократилось с 25 до 13 минут, SLA реакции достиг 95%, а процессы ИТ-службы стали прозрачными и управляемыми благодаря TIKITRIK.
Типичные ошибки миграции
Переносить все подряд без аудита. Если переносить все как есть, без разбора, в новую систему просто переедет старый хаос. В результате Service Desk формально появится, но проблем в процессах это не решит.
Не информировать конечных пользователей заранее. Если пользователей не подготовить, любое изменение системы воспринимается как «сломали привычное». Это резко увеличивает сопротивление и количество негативной обратной связи на старте.
Игнорировать обучение ИТ-команды и их вовлечение. Без понимания новой модели работы команда продолжает мыслить старыми категориями. В итоге система используется не по назначению и теряет свою ценность.
Не замерять результат. Если не зафиксировать метрики до и после, невозможно понять, стало ли лучше. Любая оценка превращается в субъективное «кажется стало удобнее».
Выбор решения, где 80% функционала не будет использоваться. Часто компании выбирают «самую мощную» систему, но используют только базовые функции. Это приводит к переплате и усложнению без реальной пользы, а со временем к отказу от такой громоздкой системы.
Меньше теории — больше практики. Не стоит строить миграцию только от идеальной модели или теории ITIL. В реальности каждая компания уникальна, и важно опираться на реальные процессы, а не на усредненные шаблоны.
Не информировать конечных пользователей заранее. Если пользователей не подготовить, любое изменение системы воспринимается как «сломали привычное». Это резко увеличивает сопротивление и количество негативной обратной связи на старте.
Игнорировать обучение ИТ-команды и их вовлечение. Без понимания новой модели работы команда продолжает мыслить старыми категориями. В итоге система используется не по назначению и теряет свою ценность.
Не замерять результат. Если не зафиксировать метрики до и после, невозможно понять, стало ли лучше. Любая оценка превращается в субъективное «кажется стало удобнее».
Выбор решения, где 80% функционала не будет использоваться. Часто компании выбирают «самую мощную» систему, но используют только базовые функции. Это приводит к переплате и усложнению без реальной пользы, а со временем к отказу от такой громоздкой системы.
Меньше теории — больше практики. Не стоит строить миграцию только от идеальной модели или теории ITIL. В реальности каждая компания уникальна, и важно опираться на реальные процессы, а не на усредненные шаблоны.
FAQ
Сколько времени займет переход на TIKITRIK?
Переход на TIKITRIK занимает от 10 дней. Уже в этот срок можно запустить услуги и начать работать в системе.
Можно ли перенести историю заявок из старой системы?
Полноценный перенос, как правило, не требуется. Для значимых обращений нужно сохранить архив старой системы и при необходимости обращаться к истории.
Что будет с процессами во время миграции — придется останавливать работу?
Нет, внедрение происходит без остановки работы. Например, с определенной даты команда просто начинает работать по новой ссылке, бесшовно.
Нужно ли обучать всех сотрудников или только ИТ-команду?
Зависит от решения, но в случае с TIKITRIK и его простого интерфейса достаточно обучить ИТ-команду. Для остальных сотрудников все интуитивно понятно.
Подходит ли TIKITRIK, если у нас специфические процессы?
Да, система гибко настраивается под разные сценарии. Подходит не только для ИТ, но и для других сервисных функций — например, HR или производственных процессов.
Можно ли сначала попробовать, а потом принять решение?
Да, есть демо-доступ. Можно протестировать систему на практике и понять, насколько она подходит под ваши задачи.
Что делать, если команда сопротивляется переходу?
Работайте с коммуникацией: заранее объясните, что за новая система и зачем она внедряется. Важно подсветить конкретные выгоды — как это упростит работу, снимет текущие проблемы или ускорит решение задач.
Переход на TIKITRIK занимает от 10 дней. Уже в этот срок можно запустить услуги и начать работать в системе.
Можно ли перенести историю заявок из старой системы?
Полноценный перенос, как правило, не требуется. Для значимых обращений нужно сохранить архив старой системы и при необходимости обращаться к истории.
Что будет с процессами во время миграции — придется останавливать работу?
Нет, внедрение происходит без остановки работы. Например, с определенной даты команда просто начинает работать по новой ссылке, бесшовно.
Нужно ли обучать всех сотрудников или только ИТ-команду?
Зависит от решения, но в случае с TIKITRIK и его простого интерфейса достаточно обучить ИТ-команду. Для остальных сотрудников все интуитивно понятно.
Подходит ли TIKITRIK, если у нас специфические процессы?
Да, система гибко настраивается под разные сценарии. Подходит не только для ИТ, но и для других сервисных функций — например, HR или производственных процессов.
Можно ли сначала попробовать, а потом принять решение?
Да, есть демо-доступ. Можно протестировать систему на практике и понять, насколько она подходит под ваши задачи.
Что делать, если команда сопротивляется переходу?
Работайте с коммуникацией: заранее объясните, что за новая система и зачем она внедряется. Важно подсветить конкретные выгоды — как это упростит работу, снимет текущие проблемы или ускорит решение задач.