Привет, Хабр! Я Дима, руковожу отделом технической поддержки ИТ-сервисов в “Петрович-Тех”. Давно не делился историями, решил рассказать о нашем проекте по работе с восьмилетним HTML-легаси, то есть порталом технической поддержки.
Обновление целой легаси-системы, которая обслуживает тысячи сотрудников — та еще задачка. С одной стороны есть устаревший код и сервисы, с другой — непрерывная работа, которую нельзя тормозить: пострадают бизнес-процессы. В этом кейсе расскажу, как мы обновили портал техподдержки, отбросили две ключевые, но ошибочные фичи, и поняли, что интеграция с AD стала главным приоритетом.
Начало пути: старый портал и растущий бизнес
СТД "Петрович" активно растет и рос еще восемь лет назад. Тогда, в середине 2010-ых, ручное распределение заявок стало съедать неприлично много времени. Решение пришло быстро: увеличивалось число предоставляемых услуг, а ручное распределение заявок стало занимать слишком много времени. Решение пришло быстро: разработали простенький портал на чистом HTML и... Благополучно о нём забыли.
Прошли годы, ассортимент услуг расширился в 5 раз. Компания росла, количество ИТ-сервисов на поддержку увеличивалось. А также и количество услуг бизнеса, которые они располагали на портале, также росло. По сути портал превратился в полноценный ServiceDesk, а не портал технической поддержк��. Пользователи всё чаще выражали недовольство: «Портал слишком сложный!».
Настала пора перемен.
Анализ проблем и сбор обратной связи
Первым делом нужно было разобраться, в чем именно заключается проблема и что именно стоит улучшать. Мы провели опрос среди наших пользователей. Ответов набралось не так много, в районе 100, но мы выяснили следующее:
43% пользователей хотят функцию поиска по формам запросов.
У нас было 230 форм без структуры. Поиск был скрыт за основной страницей, из-за чего пользователи могли плутать по порталу. Даже добавление отдельной кнопки для перехода на страницу с поиском не решило проблему.
13% ждут современный интерфейс.
Дизайн сайта явно устарел. Использование неподходящих шрифтов и цветов, сложная и перегруженная структура страниц, отсутствие четкого CTA — визуал остался в 2010-х.
Еще мешала непоследовательность элементов. Например, при нажатии Назад нельзя выйти на главную страницу, а контакты отображались не при наведении, а только при нажатии кнопки Контакты.
9% пользователей хотели единый пароль с Active Directory.
Отсутствие интеграции с Active Directory создавало неудобства, особенно учи��ывая требования информационной безопасности по периодической смене паролей. Пользователям приходилось менять пароль в AD, а на портале он оставался старым.
9% просили возможность переносить личные данные из других сервисов, а еще кастомизировать личный кабинет на портале: иметь избранные разделы и более подробные описания к формам запросов.
Без интеграции с другими сервисами компании пользователям приходилось вручную вводить личные данные. Также не было просмотра ранее созданных и выполненных заявок.
6% хотели сортировать заявки по дате создания в личном кабинете.
Это помогает видеть свежие обращения и сразу находить нужную информацию.
Остальные пользователи упоминали чат помощи по порталу, добавление данных первой линии техподдержки, возможность обращаться по почте, а также устранение обязательных для заполнения полей.
Мы решили сосредоточиться на основных проблемах из топ-5, а остальные улучшения отложили на будущее.
Выбор решения: почему выбрали плагин Refined
Наш старый портал и текущий ServiceDesk не справлялись с ростом бизнеса. Мы начали искать готовое решение, но при взгляде на очевидные решения столкнулись с ограничениями:
UseDesk отпал сразу из-за архитектурного ограничения — система не позволяла создавать новое обращение, пока предыдущее не закрыто. Каждое новое сообщение становилось комментарием к старому тикету, что полностью ломало наши процессы.
Eva по функционалу отличное решение, но стоимость внедрения оказалась нелогично высокой для решения задач одного портала.
Изучение рынка показало, что тяжелые платформы нам не подходят. Решением стал плагин Refined для Jira Service Management.
Почему он оказался удачным решением: Refined — по сути оболочка для нативных порталов JSM, который позволяет кастомизировать интерфейс под конкретные нужды. Он закрыл наши ключевые потребности:
Гибкая настройка интерфейса: возможность создать тематический сайт с брендированием, без привязки к стандартному виду Jira.
Переработанная навигация: мы смогли логически сгруппировать проекты JSM в категории и выпадающие меню, что решило проблему сложной структуры.
Интеграция с Confluence: позволила встроить базу знаний в портал для самопомощи пользователей.
Система разрешений: настраиваемая видимость разделов для разных групп пользователей.
Функционал плагина протестировали, наши задачи он решал.
Пилотный проект: что мы реализовали и как интегрировали AD
В рамках пилота мы:
Реализовали интеграцию с Active Directory
Вынесли поиск на все страницы портала
Настроили личный кабинет с отображением обращений
Создали новую структуру меню (Программы, Оборудование, Доступы, Услуги) с подменю для софта и каталога услуг
SAML SSO против Active Directory Attributes Sync
Рассматривали два подхода к интеграции:
Active Directory Attributes Sync — для синхронизации атрибутов пользователей
SAML SSO — для реализации единой учетной записи для многочисленных сервисов
Выбрали SAML SSO по критически важной причине: подход позволил привязать существующих пользователей Jira к AD по email, сохранив всю историю их обращений. Active Directory Attributes Sync потребовал бы создания новых учетных записей с потерей всех исторических данных.
Технические сложности при интеграции все равно возникли. Например:
Некорректные данные в AD: у части пользователей был указан личный или общий почтовый ящик вместо корпоративного
Проблемы с аутсорсом: пришлось создавать доменные учетные записи и организовывать доступ через VPN для части подрядчиков
Односторонняя синхронизация: изменения в AD передаются в Jira, но не наоборот
Сейчас интеграция с AD реализована, но для автоматического заполнения личных данных в ServiceDesk информации из AD недостаточно — ведем поиск альтернативных источников этих данных.
Также на этапе мы добавили функции:
добавление разных полей в личном кабинете
разбивку запросов для меню по группам: программы, оборудование, доступы и услуги.
внутри групп организовали подменю с указанием списка софта и каталога услуг
Изначально мы планировали разделить портал на зоны ответственности — нашей компании и заказчика. Это помогло бы пользователям лучше ориентироваться, кому адресовать проблему, так как иногда претензии по услугам бизнеса СТД Петрович ошибочно поступали к нам.
Однако такое разделение усложняет навигацию для большинства пользователей. После консультации с коллегами решили, что риск создать дополнительные трудности перевешивает потенциальную выгоду. От идеи разделения отказались в пользу единого портала.
Пилотный запуск
Следующим шагом стал пилотный запуск нового портала для сотрудников одного торгового центра. Чтобы не нарушать рабочие процессы, первая линия поддержки вручную переносила заявки из тестовой среды в продакшен.
Результаты пилота — преимущественно положительные отзывы. Однако мы обнаружили две проблемы:
Поиск на внутренних страницах работает только в рамках одного проекта ServiceDesk.
Пользователи ожидали глобальный поиск по всем разделам. Ошибку с поиском исправили за две недели.
Ручное разграничение прав. Пилот выявил структурную проблему: в нашей Jira отсутствовала организационная структура компании.
Без этого невозможно автоматически распределить 11 000 сотрудников по группам для настройки видимости форм. Единственный вариант — ручная настройка, что потребовало бы колоссальных трудозатрат и постоянного обновления данных.
Осознав объем рутины и риски устаревания данных, мы приняли решение отказаться от этой функциональности. Задача была отложена до тех пор, пока не будет найдено автоматизированное решение.
Также, столкнувшись с масштабом задачи (внедрение для 100+ подразделений), мы отказались от дальнейшего точечного пилотирования. Чтобы не растягивать внедрение на годы, было принято решение запускать новый портал сразу для всех.
Постепенная миграция и параллельное использование двух версий
Чтобы минимизировать неудобства для пользователей, разработали поэтапный план миграции:
Параллельная работа: 2 месяца.
Оба портала — старый и новый — работают одновременно. Пользователи могут тестировать новую версию и оставлять обратную связь, выбирая удобный для себя вариант.
Перенаправление с возможностью отката: следующие 2 месяца.
Прямой доступ к старому порталу отключается, все пользователи перенаправляются на новую версию. Сохраняется возможность вернуться на старый портал через специальную ссылку для обратной совместимости.
Затем — полное отключение легаси.
Старая версия порт��ла окончательно закрывается.
На всех этапах мы непременно информируем пользователей через email-рассылки и личные контакты.
Итоги и планы на будущее
Мы с командой провели успешный пилот и развернули портал в продуктивной среде. При этом исправив 71% проблем наших клиентов: от интерфейса и его персонализации до единого пароля для сервисов. Если у вас похожий легаси-портал, возможно, вам пригодится наш роадмап.
Сейчас идет финальный этап проверки новой версии портала. Опрос пользователей завершим в январе, информацию о нем донесу в комментарии. Буду рад услышать ваши мысли и советы по улучшению сервиса и его раскатке на всю компанию.