Service Desk Archives – Страница 14 из 26

Все на портал самообслуживания!

Недавно один из клиентов поделился достижением: "теперь у нас около 90% обращений регистрируется пользователями на портале самообслуживания, почта и телефон почти не используются". За счет этого разгрузилась первая линия, сократилось время обработки обращений, т.к. они маршрутизируются на вторую линию или во внешние компании автоматически, а данные, которые поступают от пользователя, содержат достаточно деталей из-за применения специализированных форм для разных типов обращений. Пример действительно интересный, многие к этому стремятся, но вот вопрос: везде ли достижимо такое состояние, какие условия должны быть выполнены и что нужно предпринять для того чтобы это случилось и принесло пользу, а не добавило работы? Начнем с условий, которые…

Евгений Шилов, 13 апреля 2015, последний комментарий 19 мая 2015

ServiceDesk: 10 вещей, которых надо избегать

Йотсна Харихаран (Jyotsna Hariharan), аналитик компании FreshDesk, предупреждает о вреде определённых вещей, которых стоит избегать при организации и работе ServiceDesk. У неё получился список из 10 пунктов. Слепо следовать ITIL. ITIL – не набор строгих правил и норм, обязательных к исполнению. То, что важно для одной организации, может быть не востребовано в другой. Слепое копирование рекомендаций и их бездумное применение заведёт вас, скорее всего, в тупик. Ищите и подкрепляйте материалами из ITIL решаемые вами задачи. Принимать все метрики как важные. Перефразируя Оруэлла, можно сказать, что все метрики важны, но некоторые метрики важнее других. Каждая организация уникальна, перед каждой стоят свои задачи. Подбирайте релевантные метрики, определив требования…

Новостной поток, 7 апреля 2015, последний комментарий 8 апреля 2015

Кто последний, тот и…

В редакцию портала поступил вопрос. Альберт, постоянный читатель и комментатор RealITSM, спрашивает: Коллеги, добрый день! Есть вопрос по определению ответственности по просрочкам в обращениях. Суть проблемы в следующем, в Service Desk настроено, что кто последний выполнил обращение, того и заявка в отчёте, но в случае же, если данное обращение просрочено, то просрочка также назначается на последнего исполнителя. На мой взгляд, это несправедливо, поскольку те сотрудники, по чьей вине обращение просрочено, избегают ответственности, передавая её на других исполнителей. Поделитесь, пожалуйста, своими идеями по данному вопросу: кто как решает данный вопрос, какие есть алгоритмы определения ответственности по просроченным обращениям? Редакция портала знает, как…

Вопрос из зала, 31 марта 2015, последний комментарий 11 апреля 2015

Checklist: хороший сотрудник поддержки пользователей

Какими качествами должен обладать хороший специалист поддержки? Давайте сначала определим о ком пойдет речь. В данном случае имеется ввиду сотрудник, непосредственно взаимодействующий с пользователями и решающий определенный круг задач в части поддержки (при этом предметная область может быть любая, в зависимости от специфики организации и структуры службы поддержки). Мы составили короткий список, включив в него, на наш взгляд, самое главное, чем должен обладать такой специалист. Если есть пункты, вызывающие у Вас вопросы, либо Вы с ними категорически не согласны, либо считаете необходимым внести уточнения или добавить что-то важное, пишите. Обсудим вместе. Обладает необходимыми знаниями и навыками в своей области ответственности…

Новостной поток, 26 марта 2015, последний комментарий 2 апреля 2015

Вопрос из зала: что делать с взаимосвязанными инцидентами?

Эльдар спрашивает у авторов и читателей нашего портала: Если пользователи начинают плодить заявки относящиеся к одной общей проблеме, будет ли правильным объединять их в одну? Или же правильнее создание отдельной "главной" заявки и работать по ней, а по результатам закрывать заявки полученные от пользователей? Поделитесь опытом, коллеги?

Вопрос из зала, 18 марта 2015, последний комментарий 30 марта 2015

Вопрос из зала: как классифицировать инциденты по ИТ-услугам?

Посетитель нашего портала Дмитрий задаёт следующий вопрос: Коллеги, добрый день. Интересует как правильно связывать инциденты с затронутыми ими бизнес-сервисами. Пример 1: клиент не смог перевести средства на счет телефона через интернет-банк и обратился в поддержку -> зарегестрировали инцидент с привязкой к бизнес сервису "Платежи и переводы в ИБ". Тут всё понятно. Пример 2: Ответсвенный специалист обнаружил сбой в процессинговой системе (либо пришел алерт от системы мониторинга). Этот сбой влияет / может влиять не только на проведение платежей в ИБ, но на операции в банкоматах / ТСП / интернете и т.п. – В данном случае, первая линия должна связять инцидент со всеми затронутыми / потенциально затронутыми бизнес-сервисами или каким-то…

Вопрос из зала, 4 марта 2015, последний комментарий 10 марта 2015

Пять важнейших навыков современного специалиста Service Desk

Ник Пирт, директор по маркетингу и PR компании Zendesk, делится своим видением ключевых навыков специалиста Service Desk наших дней. По мнению Ника, служба поддержки становится гораздо более восприимчивой частью бизнеса и должна технически и эмоционально реагировать на потребности обращающихся пользователей. Точка контакта – первая линия поддержки – формирует восприятие всей ИТ-организации в целом, а характер этого ежедневного взаимодействия вносит свою лепту в её оценку. Пользователи стали разборчивее: они представляют, что такое хорошее обслуживание – этому способствует получаемый опыт общения с разными поставщиками услуг. Чтобы развиваться в ногу со временем, вашей команде специалистов службы поддержки нужно будет обзавестись определёнными навыками, которые позволят…

Новостной поток, 3 марта 2015, последний комментарий 12 марта 2015

Система определения приоритетов одной известной компании

В одной компании уже много лет действует такая система определения приоритетов неприятных событий (мы бы называли их инцидентами, наверное): Код Sev-5, самый низший, используется для относительно незначительных проблем, как правило технических. Такие проблемы можно и нужно решать в обычном рабочем порядке. То есть — не очень срочно, но сделать нужно. Код Sev-1, самый высший, присваивается срочным событиям, реакция на которые должна быть безотлагательной: запускаются все возможные системы оповещения ответственных сотрудников, приступить к устранению беды следует немедленно, о проблеме, её последствиях и героическом устранении будет доложено одному из топ-менеджеров компании, который не только выслушает, но и сделает орг.выводы и примет административные…

Олег Скрынник, 11 февраля 2015, последний комментарий 30 марта 2015

Вопрос из зала: критерии формирования групп поддержки

Наш постоянный читатель и участник дискуссий на портале, Вячеслав просит совета аудитории про необходимые и достаточные критерии, которые можно было бы использовать при организации отдельных групп поддержки: Доброго времени суток. Вопрос к личному опыту по Support groups. Какие ключевые критерии вы бы посоветовали выбрать необходимыми и достаточными, для выделения отдельных Support Groups. Интересует как с точки зрения здравосмыслия Support model, так и с точки зрения реализации в ITSM приложении. Вопрос вызван тем, что при рассмотрении организации достаточно большого размера и ширины профиля, логичное желание выделить группы по матрице Операционный уровень/Сервис влечёт за собой желание пользователей системы плодить группы сотнями… Поэтому…

Новостной поток, 26 января 2015, последний комментарий 29 января 2015

Как измерить портал самообслуживания

Директор по обучению и сертификации HDI, Rick Joslin в своей заметке «What is LZS?» рассказывал о метрике LZS (Инциденты, решаемые на 0 уровне – Level Zero Solvable), которая показывает долю инцидентов, решённых службой поддержки, которые могли бы быть решены пользователями самостоятельно с использованием портала самообслуживания. Предположим, вы запускаете такой портал. Известно, что если пользователи не могут решить свой вопрос с помощью портала самообслуживания, они вряд ли обратятся к нему снова. Метрика LZS помогает спрогнозировать эффективность портала самообслуживания с точки зрения пользователя, снизить риски неприятия и повысить вероятность повторного использования. После запуска портала, анализ инцидентов входящих в LZS, помогает выявлять возможности…

Реальные примеры описаний процессов: управление инцидентами

Мы подготовили еще один список документов, находящихся в открытом доступе, и полезных для самостоятельной организации процессов. Ранее мы уже говорили о процессах управления изменениями, управления уровнем услуг. На этот раз речь о процессе управления инцидентами. Многие организации уже не первый год имеют дело с этим процессом, поэтому вдвойне интересно посмотреть "а как другие решают проблемы, с которыми столкнулись мы". Возможно, вы найдете интересные для себя решения в приведенных ниже документах. Описание процесса управления инцидентами Harvard University. Интересный экземпляр, с документе проработаны не только процедурные вопросы, но и политики, CSF, KPI. Описание процесса управления major инцидентами Harvard University. Не менее любопытный документ,…

Новостной поток, 23 ноября 2014, последний комментарий 10 февраля 2017

Портал №1 по управлению цифровымии информационными технологиями

Service Desk

Портал №1 по управлению цифровыми
и информационными технологиями