Тикет-система для техподдержки
Чем отличается «хорошее» ИТ-подразделение от «плохого»? Естественно, очень многим. Однако основным критерием такого отличия является эффективность его работы, которая выражается в способности специалистов техподдержки оперативно реагировать на проблемы и пожелания пользователей.
Казалось бы, залог «хорошего ИТ-подразделения» — это высококвалифицированная команда специалистов технической поддержки, но, к сожалению, профессионализма может быть недостаточно.
На сегодняшний день во многих компаниях принято использовать электронную почту для регистрации заявок пользователей. Такая тенденция обусловлена рядом существенный преимуществ данного способа:
Пользователь может обратиться в тех поддержку в свободной форме и сообщить о проблеме буквально в двух словах: «не работает…»;
Почта почти всегда у всех открыта, тех поддержка видит обращение и может быстро отреагировать;
Пользователю не надо никуда идти или дозваниваться до специалиста.
В то же время, регистрация заявок по электронной почте может затруднять работу ИТ-отдела, так как, наравне с преимуществами, такой способ имеет и достаточно серьезные минусы:
При большом потоке обращений, письмо может затеряться;
Техподдержка может выполнить обращение без участия пользователя и не сообщить ему о том, что все проблемы решены — пользователь может быть уверен, что его проблема до сих пор не решена, что вряд ли будет способствовать плодотворной работе;
Руководителю ИТ будет крайне затруднительно проконтролировать работу ИТ-подразделения, ведь придется потратить уйму рабочего времени, чтобы найти историю по запросу.
Все это побудило ИТ-подразделения к поиску альтернативных способов регистрации обращений. Сейчас многие компании используют Тикет-систему для тех поддержки. Тикет-система существенно развила способность ИТ-подразделения оказывать техподдержку своевременно и качественно.
Cистема тикетов для техподдержки
Одним из главных достоинств тикет-системы является систематизация запросов. То есть, с помощью тикет-системы:
Техподдержка может отделить одно обращение от другого. Раньше в одной переписке могла идти речь о многих запросах или несколько писем могли относится к одному запросу, поэтому восстановить историю обращения было, как минимум, сложно.
Специалисты техподдержки и пользователи могут увидеть историю по каждому обращению: как переписку, так и объективные данные – когда поступило, когда было выполнено, когда был изменен статус и т.д.
Как правило, тикет-системы технической поддержки имеют свою «веб-страницу», заходя на которую пользователи могут зарегистрировать заявки в структурированном виде: выбрав категорию, приложив скриншот и т.д. Однако есть системы с помощью которых пользователи могут обратится в техническую поддержку, направив заявку на общий электронный адрес. Все обращения направленные на данный адрес регистрируются технической поддержкой, что позволяет избежать их потери.
Тикет-система оказывает значительное влияние на совершенствование возможностей ИТ-подразделения. По итогам ее внедрения ИТ-отдел получает возможность оценивать свою работу на основании объективных данных, а именно: нагрузку – сколько запросов поступило, оперативность оказания помощи — насколько быстро приступили к решению вопроса, качество — сколько запросов было выполнено и в какой срок и т.д.
Однако, несмотря на то, что тикет-система помогает ИТ-подразделению совершенствовать свои способности в части поддержки пользователей, уровня этих способностей, чтобы конкурировать с профессиональными ИТ-подразделениями, будет по прежнему недостаточно. Систематизация потока поступающих заявок — это всего лишь начальный этап на пути становления зрелой команды, хоть он и является обязательным.
Стоит отметить, что тикет-система, также как и электронная почта, не является совершенным способом регистрации обращений. Одна из самых больших проблем тикет систем — это отсутствие ориентации на ИТ-сервисы (ИТ-услуги). Дело в том, что после систематизации потока заявок, ИТ-подразделение понимает, что в зависимости от контекста, заявки могут сильно отличаться друг от друга, а некоторые из них могут затрагивать не только техническую поддержку, но и другие ИТ-подразделения. Поэтому многие пытаются найти обходной путь, например добавить возможность учета ИТ-сервисов в тикет-системах. Однако, это все равно не приводит компанию к внедрению сервисного подхода, потому что оно возможно только с использованием систем класса Service Desk, но об этом мы расскажем уже в другой статье.
Как управлять обращениями в ИТ-отдел
По мере роста числа устройств, которыми необходимо управлять, возрастает число обращений сотрудников компании в ИТ-отдел по разным вопросам. Как централизованно управлять ими, чтобы документировать их и координировать работу сотрудников ИТ-отдела? Рассмотрим на примере облачного RMM-решения Panda Systems Management.
В предыдущих наших статьях про RMM-системы мы рассказывали о том, как такие комплексные решения позволяют автоматизировать многие ИТ-задачи и повысить эффективность обслуживания ИТ-сетей за счет удаленного и централизованного мониторинга, контроля и поддержки устройств и пользователей: мониторинг работы устройств, управление мобильными устройствами (MDM), удаленная установка ПО, инвентаризация, управление патчами и многое другое.
Но все эти задачи – это непосредственная работа с ПО и «железом», и за их использованием стоят конкретные люди, сотрудники предприятия, которые в своей массе не обладают серьезными ИТ-навыками и знаниями, а потому периодически сталкиваются с теми или иными проблемами. Как им оптимальным и формальным образом взаимодействовать с ИТ-отделом? Как ИТ-отделу принимать такие запросы, не терять их и не забывать про них? Как руководству ИТ-отдела контролировать обработку всех этих запросов?
Очевидно, что грамотная, оперативная и качественная обработка обращений сотрудников в ИТ-отдел не только повышает показатели работы самого отдела в целом и его сотрудников в частности, но в глобальном смысле непосредственно влияет на производительность работы сотрудников предприятия, эффективность и конкурентоспособность всего предприятия.
Кстати, Вы можете бесплатно зарегистрировать лицензии Panda Systems Management на сайте www.cloudav.ru/enterprise/solutions/cloud-systems-management и вместе с нами настроить управление обращениями непосредственно в Вашей сети.
Задача: системное управление обращениями в ИТ-отдел
Рост числа устройств в компании, которыми необходимо управлять, и рост числа технических специалистов, которые выделены для решения ИТ-проблем, рано или поздно потребует внедрение системы, которая позволяет ИТ-отделу системно управлять каждым инцидентом, документировать его и координировать.
Тикет-система (Ticketing system или система по обработке заявок/обращений) используется для отслеживания каждого инцидента с момента его создания и до момента его закрытия, записывая все промежуточные этапы, через которые он проходит.
Таким образом, можно назначить обращение определенному ИТ-специалисту или переназначить его другому специалисту, если предыдущий занят или он не обладает специальными знаниями и навыками для решения данной проблемы. Кроме того, у данного обращения тикет-система сохраняет всю переписку, документацию и данные по выполненным работам, а потому при переназначении технического специалиста или при возникновении похожей проблемы в будущем можно не отвлекать конечных пользователей (сотрудников предприятия) для повторного уточнения и запроса требуемой информации.
Во-вторых, принудительное документирование инцидентов позволяет повторно использовать процедуру решения проблемы для будущих аналогичных инцидентов, что также сокращает время отклика ИТ-отдела.
И наконец, тикет-система позволяет руководителю ИТ-отдела определять нагрузку на сотрудников отдела, выбирая открытые обращения в требуемый период времени, чтобы можно было выделить дополнительные ресурсы при необходимости.
Вполне логично, что такая тикет-система интегрирована в комплексное RMM-решение, где взаимосвязаны все аспекты управления, контроля и обслуживания ИТ-ресурсов предприятия.
Итак, рассмотрим тикет-систему на примере комплексного облачного RMM-решения Panda Systems Management.
Описание тикета
Каждый тикет (по сути дела – это инцидент или обращение конечного пользователя, кейс) содержит набор полей, которые его описывают:
Creator: Создатель тикета. Это может быть устройство (если тикет создан пользователем из локального Агента) или системный аккаунт (если тикет автоматически создан соответствующим монитором Panda Systems Management и назначен техническому специалисту).
Site: Группа устройств, к которым принадлежит тикет.
Date Created: Дата создания тикета.
Status: Существует четыре статуса:
• New: недавно созданный тикетс описанием проблемы и назначенным техническим специалистом. Еще никакие работы по данной проблеме выполнены не были.
• In progress: Технический специалист из ИТ-отдела, кому назначен данный тикет, управляет инцидентом.
• Waiting: Решение инцидента было приостановлено какими-то внешними причинами (недостаток информации, подтверждение изменений пользователем и пр.).
• Complete: Инцидент был решен и закрыт.
Severity: Степень важности тикета. Если тикет был сгенерирован монитором, то будет скопирована степень важности, определенная для данного монитора.
Assigned to: Технический специалист, которому был назначении данный инцидент для решения.
Summary: Сводная информация по инциденту.
Content: Описание инцидента.
Comments: В этом поле технические специалисты и конечные пользователи могут добавлять записи, которые обновляют этап инцидента или завершают его.
Техническим специалистам и конечным пользователям рекомендуется чаще использовать данное поле с комментариями, документируя изменения в инциденте и выполненные действия, проведенные проверки и другие данные, которые могут представлять интерес. Это необходимо для того, чтобы эти данные можно было использовать в будущем для повышения скорости решения аналогичных инцидентов.
Создание тикета
Тикеты создаются тремя способами:
1. Вручную конечным пользователем (сотрудником предприятия) из локального агента Panda Systems Management, установленного на его компьютере
2. Автоматически монитором Panda Systems Management, который зафиксировал условие, определенное как аномалия для устройства пользователя
3. Вручную сотрудником ИТ-отдела из консоли управления Panda Systems Management
1. Вручную конечным пользователем
Если конечный пользователь заметил, что его устройство работает некорректно, он может вручную создать тикет (обращение в ИТ-отдел), чтобы сообщить о данном инциденте и описать наблюдаемые симптомы.
Чтобы зарегистрировать тикет вручную, пользователь должен открыть установленного на его компьютере Агента, нажав правой кнопкой на его иконке, в выпадающем меню выбрать Open, затем в интерфейсе локального агента выбрать закладку Tickets и нажать кнопку New Ticket.
В открывшемся диалоговом окне необходимо указать заголовок тикета и его описание и нажать кнопку ОК.
После создания тикета конечный пользователь может добавлять в него комментарии:
Или закрывать его, если инцидент, по его мнению, решен:
2. Автоматически монитором
При настройке политики монитора в разделе Ticket Details можно настроить опции автоматического создания тикета в том случае, если монитор зафиксирует какое-то аномальное условие на устройстве конечного пользователя:
В этом случае вы можете включить опцию автоматического создания тикетов, назначить соответствующего технического специалиста и поставить приоритет у создаваемых тикетов, а также отправлять оповещение о создании тикета по электронной почте.
3. Вручную сотрудником ИТ-отдела
Как правило, это напоминания или задачи, которые добавляются в список тикетов для ИТ-отдела.
Чтобы создать тикет, необходимо на уровне аккаунта или сайта перейти на закладку Support и нажать на кнопку New Ticket для создания тикета.
Тикеты, созданные на уровне всего аккаунта, не привязываются к сайтам внутри аккаунта и не показываются на уровне какого-либо сайта.
При добавлении тикета вы можете указать его заголовок, описание, приоритет, а также назначить или переназначить технического специалиста для решения инцидента (задачи) по данному тикету:
Управление тикетами
Созданные тикеты управляются на закладке Support на уровне аккаунта, сайта или конкретного устройства. При этом необходимо учесть, что тикеты, созданные на более низких уровнях, отображаются в списке тикетов на более высоких уровнях (т.е. если создали на уровне устройства, то будет отображаться на уровне сайта или всего аккаунта), но не наоборот.
Опции управления в панели Actions позволяют вам фильтровать тикеты (показывать только открытые тикеты, мои тикеты, все тикеты) или редактировать их статус с помощью иконки с изображением карандаша. Чтобы изменить приоритет, статус или назначенного технического специалиста, необходимо нажать на номере тикета в таблице.
Заключение
Комплексное облачное RMM-решение Panda Systems Management позволяет централизованно и удаленно обслуживать корпоративную ИТ-систему, автоматизируя и решая практически весь комплекс ИТ-задач, от мониторинга и инвентаризации до удаленной установки ПО и MDM.
Среди прочих задач с помощью данного решения можно также системно управлять обращениями и инцидентами в рамках тикет-системы. Такой подход позволяет упростить и ускорить выявление и решение инцидентов для обеспечения должного уровня функционирования ИТ-системы в целом. А это напрямую влияет на рост производительности труда и конкурентоспособности предприятия.
Добивайтесь большего, делая меньше!
Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
Для приватных тикетов
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
Оценка по степени влияния
Оценка по степени ущерба
Оценка по размеру
Оценка по критерию MoSCoW
Оценка по частоте
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно:
Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
Для приватных тикетов
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
Оценка по степени влияния
Оценка по степени ущерба
Оценка по размеру
Оценка по критерию MoSCoW
Оценка по частоте
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно: