Здравствуйте!

Меня зовут Алексей, я инженер технической поддержки. Сегодня расскажу о том, как у нас в «ДоксВижн» выстроена служба Helpdesk, с учётом специфики платформенного ПО. Возможно, эта информация поможет компаниям, которые уже плотно работают в Helpdesk, а также тем, кто только планирует выстроить канал общения с заказчиками. К слову, ряд партнёров Docsvision уже воспользовались нашим опытом и внедрили Helpdesk с нашей помощью.

Все компании, бизнес которых складывается на предоставлении тех или иных IT-услуг, стремятся быть клиентоориентированными, и «ДоксВижн» не исключение. Как и многие другие вендоры, мы не только сами производим программное обеспечение, но и предоставляем услуги по его технической поддержке, стремимся оказывать их качественно и своевременно.

Я много раз сталкивался с тем, что в компаниях по-разному оказывают услугу поддержки пользователей с технической точки зрения. На Хабре есть несколько статей на эту тему, и вот ещё одна, из которой вы узнаете, как это происходит у нас.

Начало

Процесс разработки ПО (и крупного ПО в частности) может проходить по различным схемам, но в итоге всё сводится к нескольким ключевым пунктам и инструментам, которые могут быть использованы:
• Среда разработки;
• Система контроля версий;
• Трекер задач;
• Системы автоматизированного и ручного тестирования;
• Bug tracker;
• Helpdesk.

Конечно, пункты можно дополнять, объединять или убрать лишнее, затронув только несколько аспектов, можно начать небольшой холивар :)
Но цель у меня сегодня другая.

Одновременная поддержка нескольких версий

Программное обеспечение необходимо придумать, разработать, протестировать, выпустить в большое плаванье (как мы говорим “отгрузить”) и начать его поддержку. Так как история компании и СЭД Docsvision началась достаточно давно, то на 2014 год мы имеем в поддержке несколько версий нашей платформы:

• Docsvision 4.5
• Docsvision 5.0
• Docsvision 5.1
• Docsvision 5.2
• Docsvision 5.3
• Docsvision 5.Х

У каждой версии платформы есть, как минимум, 2 релизные версии с полным названием, например, Docsvision 5.3.2529, т.е. получается примерно 10 версий одновременно. К этому стоит добавить ещё около 40 модулей платформы. Всё это многообразие продуктов и релизных версий Docsvision мы поддерживаем в работе параллельно и каждый день.
Часть наших клиентов сотрудничает с нами с ранних версий. Система электронного документооборота на предприятии подразумевает долгосрочное партнёрство с вендором ПО, и техподдержка для организаций, в которых поток входящих и исходящих документов не прекращается ни на день, играет существенную роль.

Ранние годы

С первых версий Docsvision и по сей день техническую поддержку оказывали мы сами, и начальной точкой входа была обычная почта. Пользователи в письмах сообщали о возникших затруднениях, прикрепляя скриншоты и логи. В ходе переписки решались насущные вопросы, накапливалась база знаний, и постепенно с расширением нашей компании и ростом количества клиентов росло и количество обращений от них. Для их обработки нужно было решение (или комплекс решений), которое помогло бы структурировать все полученные данные.
У истоков процесса helpdesk в компании и по сей день стоит могучий «камень», имя которому DVManagement™. И сейчас самое время плавно перейти к тому, что мы используем внутри компании.

Внутренние инструменты

DVManagement — это сервер с установленной платформой Docsvision, расположенный в недрах нашей компании, с которым со своих рабочих мест работают инженеры технической поддержки (и не только они). Сейчас на сервере установлена последняя релизная версия нашей платформы и добавлены специальные «карточки», которые мы называем issue. DVManagement является, по сути, нашей платформой с добавленным функционалом багтрекер и helpdesk для обработки внутренних и внешних обращений, к которым можно отнести:
• Запись новых требований по реализации функционала;
• Запись ошибок;
• Запись исправлений (база знаний);
• Тестовые кейсы (в небольшом количестве);
• To-do планы (в небольшом количестве).

Так как «платформа» достаточно большая, не все подразделения в компании используют только «наш» багтреккер, часть работы ведётся в репозитории Team Foundation Server (а ранее Source Save).

Сотрудники ТП ежедневно работают с карточками Issue, которые выглядят примерно так:

Issue является связующим звеном между двумя нашими инструментами поддержки, а также служит для взаимодействия вида «Инженер ТП-Разработчик ПО».

У карточки есть необходимые поля, которые должны быть заполнены (версия продукта, название фирмы-заказчика и т.д.)
Есть несколько вкладок, в которых содержится дополнительная информация о статусе решения вопроса и присутствуют такие стандартные опции, как:

• Прикрепление файлов и комментариев (с версиями);
• История общения инженер -> разработчик (в этот процесс также может быть включен тестировщик или аналитик);
• Установка статуса «ошибки»;
• Запрос оперативного исправления этой ошибки;
• Возможность связать несколько карточек.

Ранее, до внедрения внешних инструментов взаимодействия, вся переписка с клиентами переносилась из почты в DVManagement. Сейчас это всё сохранено и используется как большая база знаний. С приходом внешних сервисов процесс немного видоизменился: к карточке issue были добавлены дополнительные поля и опции. При каждом изменении статуса issue, а также при изменении каких-либо полей, автор этого issue получает почтовые уведомления о сделанных изменениях. Другими словами, ничто не останется незамеченным.

На текущий момент в системе уже около 7000 созданных issue, используемых сотрудниками техподдержки, а всего в системе около 60000 объектов, созданных за период с 2006 по 2014 года. Не утверждаю, что «чем больше, тем лучше», но ежедневно база знаний пополняется. Это очень помогает, например, при обучении новых сотрудников поддержки.

Внешние инструменты (Полный Дзен)

Наряду с DVManagement нам нужен был инструмент, позволяющий более удобно фиксировать приходящие заявки — и был выбран Zendesk, работать в котором мы начали в 2011 году.

Zendesk поставляется как сервис (SaaS), в виде сайта, доступного как нам, так и нашим заказчикам. Это система с высокой доступностью (хостится на Amazon), направленная именно на работу с обращениями, заявками или «тикетами», как именуются вопросы внутри Zendesk.
У «ДоксВижн» есть собственный портал технической поддержки, который доступен для ознакомления даже без регистрации. А зарегистрированные пользователи могут написать нам на форум, и, при оплаченном пакете обновлений, создавать заявки в течение всего этого срока (например, в течение года).

Некоторые ключевые моменты:
• Для работы необходимо создать учётные записи инженеров поддержки, именуемые «агентами». Всего в «ДоксВижн» около трех десятков таких агентов.
• Имеется развёрнутая система форумов, в которых клиенты могут задавать вопросы и получать ответы от инженеров поддержки, а также общаться между собой — типичный пример форума по разработке (необходима регистрация). Всего у наc таких разделов больше десятка.
• Расширенная система почтовых уведомлений по событиям.
• Поддержка настраиваемого SLA.
• Система контроля доступа (имеются разные категории учётных записей — агент, конечный пользователь, администратор форума, глобальный администратор).
• Удобная привязка конечных пользователей к своим компаниям.
• При желании, несколько пользователей из одной компании могут участвовать в переписке параллельно.
• Расширенные статусы заявок (кроме «открыт», «закрыт», «решен»), ожидающие неких событий извне.
• Система макросов и триггеров (пример: распределение заявки на более «свободного инженера»).
• Расширенные отчёты по многим событиям.
• Мобильные приложения для всех платформ (теперь мы можем отвечать на запросы, находясь в любом месте).
• Интеграция с социальными сетями.

пример мобильного приложения для Windows Phone 8

Ниже представлен скриншот интерфейса агента поддержки:

Пользователи, зарегистрированные на портале, могут создавать заявки, которые автоматически будут взяты в работу. Точкой входа в этом случае является сам портал поддержки (доступный по адресу) и электронная почта: письмо, отправленное на специальный адрес, сразу преобразуется в заявку — это ещё одна особенность Zendesk.

При создании заявки в helpdesk, пользователь должен заполнить определённые поля, описать суть проблемы, и при желании прикрепить дополнительную информацию (этот может быть скриншот или какой-то лог), вот как это выглядит

Zendesk позволяет иметь абсолютно настраиваемые поля в создаваемом тикете: это может быть выпадающий список, радио кнопка, или, например, выбор из списка предустановленных администратором значений.
Все заявки, созданные в этой системе, обрабатываются в рамках указанного SLA и в зависимости от приобретённого пакета услуг. Кстати, уровень критичности пользователь имеет возможность выбрать сам.

Если говорить о динамике количества запросов, то её можно наблюдать на картинках ниже (напоминаю, 2011 — год внедрения Zendesk). Для примера взят 2013 год, который по количеству заявок пока «лидирует».

Более интересно наблюдать количество решённых заявок по месяцам. На графике выше можно увидеть, сколько было создано в месяц, и какая их часть в этом же месяце решена.

Также по каждому инженеру ведётся статистика, позволяющая собрать KPI в течение недели. Стоит отметить, что количество не всегда говорит о том, хорошо или плохо трудился в течение недели инженер, ведь, как правило, более сложные вопросы решаются более длительное время.

Особенности Helpdesk в разрезе СЭД

Zendesk помогает нам строить канал общения с заказчиками и клиентами на новом уровне. Заявка, созданная пользователем, будет обработана с учётом имеющегося SLA (Service Level Agreement — определяет взаимные ответственности провайдера ИТ-сервиса и пользователей этого сервиса). И, коль скоро мы заговорили об ответственности, упомяну и NDA (Non-Disclosure Agreement): перед заказчиками, которых заботит конфиденциальность передаваемых нам данных, мы обязуемся не передавать их третьим лицам. Также в Docsvision есть инструменты, позволяющие «обезличить» данные пользователей, переданные нам в процессе работы: инженер ТП не сможет увидеть личных данных пользователей или прочитать конфиденциальную информацию в справочниках клиента.

Хотя по регламенту у службы ТП 8-часовой рабочий день, работа инженеров построена таким образом, чтобы часы всех инженеров были распределены и охватывали максимально возможное время: например, с 8:00 до 20:00. Это обусловлено тем, что помощь техподдержки может понадобиться клиентам в другом часовом поясе.

В зависимости от времени суток активность также меняется:

Как видно, пик приходится на середину рабочего дня. Работа кипит.

Из-за большого количества одновременно работающих у наших заказчиков версий Docsvision, инженеры должны иметь «под рукой" все возможные версии Docsvision и комбинации установленных модулей. Для таких случаев мы используем порядка 40 виртуальных машин. Гипервизор используем на технологии VmWare.

Но часто даже большого «зоопарка» всех версий ОС Windows, всех Net Фреймворков и сканеров штрих-кодов (это мы тоже используем) в какой-то момент может не хватить.

Например, может случиться, что будет найдено неожидаемое поведение, которое стабильно воспроизводится только на физических машинах (а на виртуальных — нет) или на устройствах с тачскрином (моноблоки).

Гибкость оперативных исправлений

В случае нахождения критичных ошибок в работе системы, в ряде случаев у наших партнёров (и пользователей) нет возможности ждать выхода новой версии продукта или обновлять всю систему – зачастую это трудоёмко, да и ждать не все готовы.
Многие ошибки, устранение которых не требует большой трудоёмкости, мы решаем с помощью оперативных исправлений. Если речь идёт о сервере, то достаточно изменить одну-две библиотеки, и заплатка будет установлена. С клиентскими рабочими местами всё ещё проще. Исправления могут быть получены как по запросу, так и размещены в свободном доступе в виде кумулятивных патчей.

Экстренная техническая поддержка

Для минимизации простоя критически важных систем (документооборот на предприятии — не исключение) в “ДоксВижн” существует услуга поддержки в экстренном режиме. Мы начинаем взаимодействие с заказчиком в рамках более быстрого SLA – время реакции в таких случаях не превышает 1 часа, а по большей части инженеры работают онлайн. В этом случае, мы используем все возможные способы связи с заказчиком (Skype, Lync, удалённые подключения) для оперативного решения проблем. При необходимости работа будет проведена во внерабочее время. Таким образом, значительно сокращается время локализации проблемы и выпуска (при необходимости) исправления.

Technical Account Manager

Под таким названием работает выделенный специалист со стороны службы технической поддержки. В этом случае повышается управляемость процессом взаимодействия между заказчиком и технической поддержкой. Инженер является координатором заявки (заявок) от одного заказчика, он наблюдает за поступающими заявками и, по необходимости, принимает меры для более эффективного решения. Возникает т.н. «единое окно», в которое можно задавать как стандартные, так и смежные вопросы. Инженер в этом случае представляется в виде «универсального солдата» и берёт на себя как технические, так и организационные вопросы (организовать конференц-звонок, предоставить отчёт по недельной проделанной работе и т.д.)

Планы на будущее

В ближайшее время сама схема процесса техподдержки, скорее всего, не претерпит каких-либо изменений, но мы всегда стремимся сделать всё немного лучше, правильно выстраивая работу внутри компании и внутри отдела.

После каждого выполненного тикета пользователю, создавшему его, предлагается оценить работу инженера, нажав «мне нравится» или «мне не нравится». Сформированный таким образом рейтинг держится в районе 96%-99% — он доступен для всех на отдельной странице (данные динамически меняются).

Согласно внутренним регламентам, каждый квартал мы опрашиваем пользователей (с помощью Polldaddy) и просим оценить работу по таким пунктам как скорость ответа, вежливость, полнота информации, время первой реакции и т.д. Собирая эти данные, мы получаем отклик, на основе которого делаются определённые выводы. Одно из интересных требований — это возможность общаться в режиме реального времени с агентами (Чат или Skype прямо внутри Zendesk), возможность эскалировать проблему на более высокий уровень, возможность интегрироваться с другими системами helpdesk или строить отчёты (со стороны заказчиков).

Но, кроме технологических инструментов, на работу сотрудников helpdesk можно повлиять и по-другому: я думаю, что отличным визуальным инструментом был бы некий Dashboard, позволяющий инженерам (и руководителям) отслеживать «горящие» заявки в режиме реального времени, например, на экране телевизора в виде наглядных графиков.

Также в планах на будущее — проводить ежедневные встречи (по аналогии со SCRUM), в которых можно обсуждать текущую работу, к слову, у наших коллег из отделов QA и Development такие встречи уже давно проходят.

Модель helpdesk, выстроенная в нашей компании, удобна для клиентов и, к слову, находит отклик у наших партнёров, ведь каждый из них на определённом этапе сталкивается с вопросом организации внутренней поддержки. Несколько компаний-партнёров уже внедрили у себя подобную helpdesk с помощью нашего опыта и знаний.

Если вы готовы поделиться своим опытом, прошу в комментарии — подискутируем.

Автор:

Источник