Всем привет! Меня зовут Алексей Волков. Bместе с моим коллегой, разработчиком Александром Соловьевым (alsov), мы делаем внутренние веб-сервисы в DataLine. Этой осенью мы запустили свой сервисдеск на замену BMC Remedy. В посте расскажу, почему мы отказались от готового решения и сделали все сами.
В среднем в сутки через сервисдеск проходит 450 заявок.
Remedy я начал заниматься практически сразу, как попал в DataLine. После неоднократных попыток допилить его под наши задачи мы решили сделать свой сервисдеск. Вот не очень короткий список причин, по которым мы решили отказаться от Remedy Action Request System от BMC:
Неудобный интерфейс. Чтобы зарегистрировать заявку, взять ее в работу и отметить ее разрешение, приходилось сделать 100500 кликов.
Страница с инцидентом. Взять хотя бы поля для содержания сообщения, которое нужно было открывать в специальном окне.
Целый каскад вкладок нужно открыть, чтобы написать решение или перенаправить инцидент другому исполнителю.
Интеграция с другими клиентскими интерфейсами и какие-либо доработки предполагали еще те танцы с бубном. ПО проприетарное, места для маневров почти не было. Единственной лазейкой были веб-сервисы, которые умели общаться с Remedy, но они были очень капризными и нестабильными. Какие-то вещи мы делали совсем вручную и топорно: помню, как настроили выгрузку отчетов по инцидентам с помощью селектов из базы.
Конечно, был и другой путь: нанять подрядчика и исполнить любой свой каприз. На рынке на тот момент был всего один подрядчик по этому ПО, и он об этом знал. Производственные процессы корректируются, и постоянно нужны были бы доработки. С учетом этого ценник получался негуманным и начинался от 5 млн.
Не хватало лицензий. Когда-то на заре DataLine мы купили 100 лицензий. С тех пор компания сильно выросла. Лицензии были конкурирующими. Все чаще возникали ситуации, когда инженеру приходилось ждать освобождения лицензии, чтобы начать делать свою работу. Собственно, это и стало последней каплей.
Фиксация всех действий по инциденту. Мы хотели, чтобы все, что касается технической поддержки наших клиентов, было отражено в сервисдеске. Remedy же фактически только регистрировал запросы. Вся настоящая работа по инциденту велась в почтовой переписке, по телефону, в курилке – где угодно, но не в Remedy. Особенно, если это была комплексная заявка и задействовала специалистов из нескольких отделов. Вопрос то решали, но следов этого в Remedy не оставалось. В результате инцидент был задокументирован фрагментами, а иногда и вовсе не отображался в Remedy. Контролировать, разбираться и анализировать что-либо было очень сложно.
Функции Remedy заменить было просто. Сверхзадача нового сервисдеска – затащить всю активность по технической поддержке в «одно окно»: контакты, рабочую переписку, документы. Мы хотели получить своего рода логирование всего, что происходит после того, как клиент отправляет заявку к нам на саппорт. Попутно мы хотели автоматизировать многие вещи, чтобы снизить нагрузку на первую линию поддержки и исключить по максимуму человеческий фактор.
Вот самые важные из тех функций, что мы реализовали в новом сервисдеске:
Передача инцидента. К нам часто приходят комплексные заявки, которые по цепочке выполняют специалисты разных отделов. Из самого простого – заявка на физический доступ к оборудованию в дата-центре. Сначала диспетчер выписывает пропуск, потом передает данные клиента и номер пропуска дежурному инженеру, который встречает и сопровождает клиента в дата-центре. Есть запросы, которые последовательно отрабатывают 5 отделов.
Для всех таких случаев в интерфейсе появилась отдельная кнопка «Передать».
Переписка с клиентом и коллегами. Эта функция как раз для того, чтобы переписка по инциденту не «утекала» в почту и вся история общения сохранялась у нас.
Пока тут все очень минималистично. В планах – сделать полнотекстовый редактор с возможностью загрузки файлов, таблиц и пр.
История назначений и история всех действий по инциденту. Эти вкладки помогут разобраться в спорных вопросах и внутренних расследованиях. В данный момент я выгружаю отчеты из истории, чтобы отслеживать, как часто диспетчеры допускают ошибки при назначении инцидента на профильную группу.
Так выглядит история назначений по внутреннему инциденту «Увольнение сотрудника».
История инцидента. Тут еще будем наводить красоту, но главная задача уже решена – все логируется.
Наблюдатель. Бывает, что в письме-заявке клиент пристегивает в копию заинтересованных лиц. Все эти товарищи будут появляться во вкладке «Наблюдатели» и следить за исполнением данной заявки. Им будут приходить отбивки о статусе запроса, при желании они смогут переписываться с нашей техподдержкой. Внутри компании эта функция тоже востребована: сервис-менеджеры могут вписаться в любой запрос своего клиента и следить за его исполнением.
Список наблюдателей можно редактировать: удалять и добавлять новых.
Шаблоны инцидентов. Типовых запросов достаточно много. Чтобы не заполнять десятки раз на дню заявку на пропуск или уборку мусора, мы добавили возможность создавать шаблоны инцидентов. Нужно только нажать кнопку «Создать инцидент», и откроется предзаполненный шаблон с прописанным исполнителем, типом, приоритетом и статусом.
В работе дата-центров много регулярно повторяющихся заявок: обходы, тестирования, проверки инженерного оборудования по чек-листам и пр. Для всего этого настраиваются автоинциденты, которые автоматически попадают в трекер с заданной периодичностью.
Аналитика. В Remedy не было встроенных средств аналитики, ничего нельзя было выгрузить штатными средствами. Здесь мы предусмотрели выгрузку всего и вся для последующего анализа. Например:
Чуть позже хотим сделать дашборды с диаграммами и графиками, чтобы без всяких выгрузок и колдовства в Excel получать картину о происходящем в техподдержке.
Отчеты можно сформировать прямо в сервисдеске с помощью фильтров.
Выгрузка данных в различных форматах.
Можно выбрать поля, которые будут отображаться в выгрузке.
API для интеграции с другими внутренними сервисами. Из простого: сервисдеск подтягивает информацию из справочников с перечнем компаний-клиентов, договоров, списком заказанных услуг и ответственных лиц, которые могут направлять запросы. Раньше приходилось сначала сверяться с отдельным файлом, чтобы определить, является ли написавший клиентом и может ли он писать запросы от компании.
«Обход дежурной смены» – еще один наш внутренний сервис, с которым теперь умеет взаимодействовать сервисдеск. Это электронный чек-лист, по которому дежурные и инженеры эксплуатации несколько раз в день осматривают дата-центры на предмет поломок и непорядка. Ситуация для примера: во время обхода дежурный наткнулся на клиентскую стойку с неправильно установленным оборудованием. Он просто делает соответствующую пометку в программе «Обход», и в сервисдеск автоматически прилетает инцидент по проблеме. Дежурный идет дальше по маршруту обхода, а проблему со стойкой уже начинают решать.
По любому из пунктов чек-листа можно создать инцидент.
Форма для инцидента внутри ПО «Обход». Сверху висят инциденты в работе по этому же объекту.
По мелочи. Все самые частые типы запросов мы вывели на страницу интерфейса. После выбора приоритета пользователь видит дедлайн и прогресс-бар, показывающий сколько времени у него осталось на исполнение инцидента.
Во время опытной эксплуатации мы тестировали работу сервисдеска на внутренних заявках. Около месяца тренировались на отделах АХО, капитального строительства, производства и управления сервисом. Внешние заявки и заявки других отделов по-прежнему ходили через Remedy.
Потом мы договорились с тремя клиентами, чтобы обкатать обработку внешних заявок. Вот тут и случились первые проблемы.
Когда только начали делать новый сервисдеск, я лелеял надежду, что наш умный почтовый парсер сможет регистрировать запросы, раскидывать их по профильным отделам, подшивать сообщения по одному и тому же вопросу в один инцидент. В перспективе это означало отказ от диспетчеров на обработке письменных запросов. В Remedy люди очень привыкли полагаться на почтовую переписку, ее было больше, чем мы предполагали. На тестовых испытаниях парсер не справился: он мог перепутать отделы при назначении запроса, новые сообщения по уже открытому инциденту он регистрировал как новые инциденты. Были и более тривиальные сложности: парсер не мог прочитать письмо, пришедшее от почты с сертификатом; не понимал нестандартную кодировку и присылал текст из вопросов.
Пришлось добавить ручной труд – появилась Диспетчерская. Это чистилище для всех заявок, пришедших на support@dtln.ru. Оттуда диспетчеры вручную распределяют заявки по отделам.
На стороне клиента логика взаимодействия с техподдержкой осталась прежней, изменился только вид отбивок. В первые дни с ними было несколько накладок, во основном из-за некорректных контактных данных в справочниках. Так у одного из клиентов было 23 ответственных лица и на всех один общий email, типа info@. Сервисдеск послушно всех оповестил, выполнив за час дневную норму по входящим на этом почтовом ящике.
В ближайших планах – интеграция с Личным кабинетом. Вся переписка и история обращений будет отображаться в профиле клиента. Теоретически это шанс исключить почту из общения с техподдержкой и окончательно затащить клиента в наш веб-интерфейс. Посмотрим, как оно приживется в жизни.
Внедрение параметризованной заявки. Есть запросы, которые содержат много параметров и значений, и важно ничего в них не перепутать. Например, когда клиент просит добавить виртуальных ресурсов в пул или создать виртуальные машины определенных размеров. Для таких случаях мы планируем сделать конструктор с параметрами. Он будет автоматически парсить подобные клиентские запросы, пришедшие по почте. Его же будут использовать диспетчеры, когда принимать заявку по телефону.
Вот так выглядит параметризованная заявка.
Оценка работы техподдержки. Пресловутое «оцените наш сервис по пятибалльной шкале» с возможностью написать в свободной форме, все, что клиент думает о нашем сервисе.
Ту самую Диспетчерскую, которая возникла как костыль в помощь почтовому парсеру, хотим развить в полноценное автоматизированное рабочее место диспетчера (АРМ). Сейчас диспетчеру приходится заглядывать в различные интерфейсы (учет оборудования, список ответственных лиц, услуги по клиенту), чтобы собрать нужную информацию по клиенту. В АРМ же будет все в одном окне: инциденты клиента, контакты, договора, заказанные услуги и их параметры и пр. данные.
Ну и не теряем надежду на автоматическое распределение заявок по отделам. Сейчас думаем в сторону системы хэштегов для почтового парсера.
***
В боевом режиме сервисдеск работает с ноября, и все это время я наблюдаю стабильное увеличение количества инцидентов (+40%), в первую очередь за счет внутренних запросов. Смею надеяться, что это из-за того, что новый сервисдеск более дружелюбный во всех отношениях и запросы перестали проскакивать мимо него.
Еще один профит нового сервисдеска – это гибкость. Мы уже сделали несколько кастомных решений для отдельных клиентов, чтобы проинтегрироваться с их внутренними сервисдесками или просто подстроиться под их производственные процессы. Раньше на это ушли бы месяцы и миллионы, а теперь все, что нужно, – это письмо своему разработчику и 1-2 недели в зависимости от сложности задачи.
В среднем в сутки через сервисдеск проходит 450 заявок.
Чем нам не угодил Remedy?
Remedy я начал заниматься практически сразу, как попал в DataLine. После неоднократных попыток допилить его под наши задачи мы решили сделать свой сервисдеск. Вот не очень короткий список причин, по которым мы решили отказаться от Remedy Action Request System от BMC:
Неудобный интерфейс. Чтобы зарегистрировать заявку, взять ее в работу и отметить ее разрешение, приходилось сделать 100500 кликов.
Страница с инцидентом. Взять хотя бы поля для содержания сообщения, которое нужно было открывать в специальном окне.
Целый каскад вкладок нужно открыть, чтобы написать решение или перенаправить инцидент другому исполнителю.
Интеграция с другими клиентскими интерфейсами и какие-либо доработки предполагали еще те танцы с бубном. ПО проприетарное, места для маневров почти не было. Единственной лазейкой были веб-сервисы, которые умели общаться с Remedy, но они были очень капризными и нестабильными. Какие-то вещи мы делали совсем вручную и топорно: помню, как настроили выгрузку отчетов по инцидентам с помощью селектов из базы.
Конечно, был и другой путь: нанять подрядчика и исполнить любой свой каприз. На рынке на тот момент был всего один подрядчик по этому ПО, и он об этом знал. Производственные процессы корректируются, и постоянно нужны были бы доработки. С учетом этого ценник получался негуманным и начинался от 5 млн.
Не хватало лицензий. Когда-то на заре DataLine мы купили 100 лицензий. С тех пор компания сильно выросла. Лицензии были конкурирующими. Все чаще возникали ситуации, когда инженеру приходилось ждать освобождения лицензии, чтобы начать делать свою работу. Собственно, это и стало последней каплей.
Фиксация всех действий по инциденту. Мы хотели, чтобы все, что касается технической поддержки наших клиентов, было отражено в сервисдеске. Remedy же фактически только регистрировал запросы. Вся настоящая работа по инциденту велась в почтовой переписке, по телефону, в курилке – где угодно, но не в Remedy. Особенно, если это была комплексная заявка и задействовала специалистов из нескольких отделов. Вопрос то решали, но следов этого в Remedy не оставалось. В результате инцидент был задокументирован фрагментами, а иногда и вовсе не отображался в Remedy. Контролировать, разбираться и анализировать что-либо было очень сложно.
Сервисдеск 2.0
Функции Remedy заменить было просто. Сверхзадача нового сервисдеска – затащить всю активность по технической поддержке в «одно окно»: контакты, рабочую переписку, документы. Мы хотели получить своего рода логирование всего, что происходит после того, как клиент отправляет заявку к нам на саппорт. Попутно мы хотели автоматизировать многие вещи, чтобы снизить нагрузку на первую линию поддержки и исключить по максимуму человеческий фактор.
Вот самые важные из тех функций, что мы реализовали в новом сервисдеске:
Передача инцидента. К нам часто приходят комплексные заявки, которые по цепочке выполняют специалисты разных отделов. Из самого простого – заявка на физический доступ к оборудованию в дата-центре. Сначала диспетчер выписывает пропуск, потом передает данные клиента и номер пропуска дежурному инженеру, который встречает и сопровождает клиента в дата-центре. Есть запросы, которые последовательно отрабатывают 5 отделов.
Для всех таких случаев в интерфейсе появилась отдельная кнопка «Передать».
Переписка с клиентом и коллегами. Эта функция как раз для того, чтобы переписка по инциденту не «утекала» в почту и вся история общения сохранялась у нас.
Пока тут все очень минималистично. В планах – сделать полнотекстовый редактор с возможностью загрузки файлов, таблиц и пр.
История назначений и история всех действий по инциденту. Эти вкладки помогут разобраться в спорных вопросах и внутренних расследованиях. В данный момент я выгружаю отчеты из истории, чтобы отслеживать, как часто диспетчеры допускают ошибки при назначении инцидента на профильную группу.
Так выглядит история назначений по внутреннему инциденту «Увольнение сотрудника».
История инцидента. Тут еще будем наводить красоту, но главная задача уже решена – все логируется.
Наблюдатель. Бывает, что в письме-заявке клиент пристегивает в копию заинтересованных лиц. Все эти товарищи будут появляться во вкладке «Наблюдатели» и следить за исполнением данной заявки. Им будут приходить отбивки о статусе запроса, при желании они смогут переписываться с нашей техподдержкой. Внутри компании эта функция тоже востребована: сервис-менеджеры могут вписаться в любой запрос своего клиента и следить за его исполнением.
Список наблюдателей можно редактировать: удалять и добавлять новых.
Шаблоны инцидентов. Типовых запросов достаточно много. Чтобы не заполнять десятки раз на дню заявку на пропуск или уборку мусора, мы добавили возможность создавать шаблоны инцидентов. Нужно только нажать кнопку «Создать инцидент», и откроется предзаполненный шаблон с прописанным исполнителем, типом, приоритетом и статусом.
В работе дата-центров много регулярно повторяющихся заявок: обходы, тестирования, проверки инженерного оборудования по чек-листам и пр. Для всего этого настраиваются автоинциденты, которые автоматически попадают в трекер с заданной периодичностью.
Аналитика. В Remedy не было встроенных средств аналитики, ничего нельзя было выгрузить штатными средствами. Здесь мы предусмотрели выгрузку всего и вся для последующего анализа. Например:
- количество запросов в сутки;
- скорость реагирования;
- просрочка запросов;
- типы запросов;
- загрузка по отделам;
- работа диспетчеров;
- частота и качество возникающих проблем в разрезе клиентов;
- разнообразные зависимости, например, скорости исполнения от типа запроса.
Чуть позже хотим сделать дашборды с диаграммами и графиками, чтобы без всяких выгрузок и колдовства в Excel получать картину о происходящем в техподдержке.
Отчеты можно сформировать прямо в сервисдеске с помощью фильтров.
Выгрузка данных в различных форматах.
Можно выбрать поля, которые будут отображаться в выгрузке.
API для интеграции с другими внутренними сервисами. Из простого: сервисдеск подтягивает информацию из справочников с перечнем компаний-клиентов, договоров, списком заказанных услуг и ответственных лиц, которые могут направлять запросы. Раньше приходилось сначала сверяться с отдельным файлом, чтобы определить, является ли написавший клиентом и может ли он писать запросы от компании.
«Обход дежурной смены» – еще один наш внутренний сервис, с которым теперь умеет взаимодействовать сервисдеск. Это электронный чек-лист, по которому дежурные и инженеры эксплуатации несколько раз в день осматривают дата-центры на предмет поломок и непорядка. Ситуация для примера: во время обхода дежурный наткнулся на клиентскую стойку с неправильно установленным оборудованием. Он просто делает соответствующую пометку в программе «Обход», и в сервисдеск автоматически прилетает инцидент по проблеме. Дежурный идет дальше по маршруту обхода, а проблему со стойкой уже начинают решать.
По любому из пунктов чек-листа можно создать инцидент.
Форма для инцидента внутри ПО «Обход». Сверху висят инциденты в работе по этому же объекту.
По мелочи. Все самые частые типы запросов мы вывели на страницу интерфейса. После выбора приоритета пользователь видит дедлайн и прогресс-бар, показывающий сколько времени у него осталось на исполнение инцидента.
Внедрение
Во время опытной эксплуатации мы тестировали работу сервисдеска на внутренних заявках. Около месяца тренировались на отделах АХО, капитального строительства, производства и управления сервисом. Внешние заявки и заявки других отделов по-прежнему ходили через Remedy.
Потом мы договорились с тремя клиентами, чтобы обкатать обработку внешних заявок. Вот тут и случились первые проблемы.
Когда только начали делать новый сервисдеск, я лелеял надежду, что наш умный почтовый парсер сможет регистрировать запросы, раскидывать их по профильным отделам, подшивать сообщения по одному и тому же вопросу в один инцидент. В перспективе это означало отказ от диспетчеров на обработке письменных запросов. В Remedy люди очень привыкли полагаться на почтовую переписку, ее было больше, чем мы предполагали. На тестовых испытаниях парсер не справился: он мог перепутать отделы при назначении запроса, новые сообщения по уже открытому инциденту он регистрировал как новые инциденты. Были и более тривиальные сложности: парсер не мог прочитать письмо, пришедшее от почты с сертификатом; не понимал нестандартную кодировку и присылал текст из вопросов.
Пришлось добавить ручной труд – появилась Диспетчерская. Это чистилище для всех заявок, пришедших на support@dtln.ru. Оттуда диспетчеры вручную распределяют заявки по отделам.
На стороне клиента логика взаимодействия с техподдержкой осталась прежней, изменился только вид отбивок. В первые дни с ними было несколько накладок, во основном из-за некорректных контактных данных в справочниках. Так у одного из клиентов было 23 ответственных лица и на всех один общий email, типа info@. Сервисдеск послушно всех оповестил, выполнив за час дневную норму по входящим на этом почтовом ящике.
Что дальше?
В ближайших планах – интеграция с Личным кабинетом. Вся переписка и история обращений будет отображаться в профиле клиента. Теоретически это шанс исключить почту из общения с техподдержкой и окончательно затащить клиента в наш веб-интерфейс. Посмотрим, как оно приживется в жизни.
Внедрение параметризованной заявки. Есть запросы, которые содержат много параметров и значений, и важно ничего в них не перепутать. Например, когда клиент просит добавить виртуальных ресурсов в пул или создать виртуальные машины определенных размеров. Для таких случаях мы планируем сделать конструктор с параметрами. Он будет автоматически парсить подобные клиентские запросы, пришедшие по почте. Его же будут использовать диспетчеры, когда принимать заявку по телефону.
Вот так выглядит параметризованная заявка.
Оценка работы техподдержки. Пресловутое «оцените наш сервис по пятибалльной шкале» с возможностью написать в свободной форме, все, что клиент думает о нашем сервисе.
Ту самую Диспетчерскую, которая возникла как костыль в помощь почтовому парсеру, хотим развить в полноценное автоматизированное рабочее место диспетчера (АРМ). Сейчас диспетчеру приходится заглядывать в различные интерфейсы (учет оборудования, список ответственных лиц, услуги по клиенту), чтобы собрать нужную информацию по клиенту. В АРМ же будет все в одном окне: инциденты клиента, контакты, договора, заказанные услуги и их параметры и пр. данные.
Ну и не теряем надежду на автоматическое распределение заявок по отделам. Сейчас думаем в сторону системы хэштегов для почтового парсера.
***
В боевом режиме сервисдеск работает с ноября, и все это время я наблюдаю стабильное увеличение количества инцидентов (+40%), в первую очередь за счет внутренних запросов. Смею надеяться, что это из-за того, что новый сервисдеск более дружелюбный во всех отношениях и запросы перестали проскакивать мимо него.
Еще один профит нового сервисдеска – это гибкость. Мы уже сделали несколько кастомных решений для отдельных клиентов, чтобы проинтегрироваться с их внутренними сервисдесками или просто подстроиться под их производственные процессы. Раньше на это ушли бы месяцы и миллионы, а теперь все, что нужно, – это письмо своему разработчику и 1-2 недели в зависимости от сложности задачи.
