Специфика работы техподдержки модульной системы

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

    Меня зовут Алексей, я инженер технической поддержки. Сегодня расскажу о том, как у нас в «ДоксВижн» выстроена служба 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 (а ранее SourceSafe).

    Сотрудники ТП ежедневно работают с карточками 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 с помощью нашего опыта и знаний.

    Если вы готовы поделиться своим опытом, прошу в комментарии — подискутируем.
    ДоксВижн 44,96
    Компания
    Поделиться публикацией
    Комментарии 7
    • 0
      Есть ряд вопросов:

      01. База знаний (БЗ) — это только запись исправлений и всё? Есть ли в ней автоматический поиск (по ключевым фразам и т.п.)?
      02. Опрос клиентов — это хорошо и правильно, но есть ли оценка ответа и статьи в БЗ сразу по получению? Ведется ли статистика, если есть, такой оценки?
      03. С чем связан рост в июле?
      04. Пробовали ли Вы внедрять методы увеличения эффективности ответов и каковы вообще показатели вторичных обращений? Я вижу рост тикетов, но каковы причины? Чисто соотношение «кол-во клиентов — кол-во запросов»? Но тогда как Вы измеряете KPI операторов тех. поддержки/инжинеров?
      05. Дисплейное отображение заявок — это хорошая идея. Надо взять на заметку
      06. Выгрузка в CRM и вообще интеграция с таковыми есть?
      07. Есть какая-то связка с email или вы полностью отделили эти инструменты?
      • 0
        1. В базу знаний, во первых попадают все обращения которые решались с привлечением разработчика т.е была найдена какая то ошибка, по ней создано и сохранено исправление.
        Да есть гибкая система поиска которая использует возможности нашей СЭД, можно искать по всем полям базы знаний(версия модуля, заказчик, модуль, комментарий, описание, была ли записана ошибка) в разных вариациях, по вхождению строки и поиск по дате, фильтрация уже найденных элементов.

        2. Опросы проводим как сразу после закрытия обращения («нравиться» / «не нравится»), так и например при пополнении статьи в БЗ можно оценить кол-во просмотров и «лайков». Как правильно больший интерес и отклик вызывают примеры программного кода.

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

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

        5. У Zendesk сейчас глабальное обновление интерфейса есть более «вебдванольный» в котором на одной странице может быть любое кол-во заявок.

        6. Есть много интеграция с разными система в том CRM — подробнее на сайте www.zendesk.com/apps#crm

        7. E-mail остаётся точкой входа и без него не обойтись — кроме переписки на портале Zendesk, все ответы дублируются по почту. Есть гибкая настройка добавления в переписку сторонних" пользователей указав их почтовые ящики. Например удобно менеджеру или руководителю следить за ходом работы по заявке даже без регистрации на портале ТП. Также, как было сказано есть вариант когда отправленное на почтовый адрес письмо, автоматически трансформируется в заявку.
        • 0
          Благодарю за обстоятельный ответ. У Вас оч. высокий показатель оценки клиентов. А дифференцированную оценку (от 0 до 10 баллов, например), не вводили?
          • 0
            Дифференцированная оценка в текущей реализации невозможна, многие пользователи Zendesk из других компаний уже много писали об этом — т.к. шкала хорошо/плохо слишком упрощённая — но из коробки такого нет. В будущем мы планируем после каждого решённого вопроса присылать «письмо-голосование» но тут нужно учитывать психологический аспект — не каждый готов потратить хотя бы 5-10 минут на участие в таком голосовании — поэтому сейчас это делаем не чаще раза в квартал.
            • 0
              Да, это хорошее начинание: по крайне мере статистически становится ясно, что и как. А можете выслать (хотя бы личным сообщением) примеры опросов? Я просто плотно занимаюсь ТП для разных проектов, оч. интересно, как реализованы разные сервисы на живых решениях.
              • 0
                Отправил личным сообщением, плюс посмотрите на polldaddy.com там можно сформировать опрос любой сложности

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое
    Интересные публикации