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

Поддержка пользователей и удаленное управление ПК

Есть такая тема – использование удаленного управления рабочими столами для поддержки пользователей (опять недавно всплыла). С одной стороны вещь полезная, поскольку позволяет и проблемы устранять в территориально распределенной сети без квалифицированного локального персонала, и FLR поднимать (поскольку первая линия ногами, как правило, не пользуется), и скриншоты для профильных специалистов снимать при регистрации обращения. Но да – есть и вопросы безопасности. По мне так это именно вопросы, а не проблемы, которые не преодолеть. Работал с многими компаниями, где безопасники давали разрешение на применение таких средств после того, как проводили экспертизу и получали гарантию, что подключение к ПК пользователя можно выполнить только…

Дмитрий Исайченко, 17 декабря 2012, последний комментарий 22 декабря 2012

ServiceDesk для маленьких

Много раз сталкивался с ситуацией, когда в относительно небольшой компании, в которой трудится 5-10 ИТ-специалистов, организуется ServiceDesk. При этом всегда встает вопрос: "Каким он должен быть с учетом ограниченности ресурсов?". Во-первых, давайте поймем, есть ли вообще смысл выделять службу поддержки в небольшой компании. С одной стороны, ИТ-специалистов немного, скорее всего, у каждого своя специализация, пользователи знают всех поименно, и вводить дополнительное звено между ними и пользователями – значит усложнять простые процедуры. С другой стороны, недостаток ресурсов приводит к реализации рисков, например: обращения пользователей забываются/теряются в общем потоке пользователям сложно найти ИТ-специалистов для того чтобы сообщить о своих проблемах не всегда…

Для тех, кто не любит ждать

Есть такая практика – включать в число статусов обрабатываемых объектов (инциденты, обращения, задания/наряды на работы и т.д.) статус "Ожидание". Задача, которую решает этот статус, простая: обеспечить участникам процессов возможность отложить в сторону обрабатываемый объект в ситуации, когда по каким-то причинам его обработка пока невозможна. Например, ждем, пока пользователь вернется из отпуска или ждем, пока будет поставлена техника и т.д. В общем, найти разумное объяснение существованию этого статуса можно. Однако понятна и обратная сторона такой возможности: появляется способ отлынивать от работы. Традиционный способ сокращения халтуры – обязать переводящего в статус "Ожидание" указывать причину перевода. Однако при наличии богатой фантазии отдельные…

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

ROI: 7148%, срок окупаемости: 1 неделя

В известную фразу про ложь, наглую ложь и статистику, похоже, пора добавить четвёртую составляющую: заявления вендоров программного обеспечения. Рецепт изготовления красивого отчёта прост: немного текста, пара-тройка диаграмм, большая таблица с расчётами. При этом таблицу важно красиво оформить, а заполнять можно и нулями. Доказательство гигантского возврата инвестиций при минимальном сроке можно уложить в четыре страницы, отведя примерно 40% ширины страницы под красивые белые поля. Так и поступила недавно некая компания. Хорошо, что с 2008 года в ITSM-индустрии работает специальный сервис, называемый Crap Factoid. Его представитель уже выполнил небольшой анализ упомянутого выше отчёта и присвоил ему высшую категорию: "Extreme Crap Factoid Alert"….

Новостной поток, 9 октября 2012, последний комментарий 12 октября 2012

Вопрос из зала: выбор системы автоматизации

Альберт задаёт вопрос: Компания, занимается продажами. Разветвленная сеть филиалов (40 шт). На данный момент установлен service desk OTRS, пользуется для регистрации заявок через единое окно (что очень тяжело дается) и для автоматического расчета уровня SLA. Количество ИТ сотрудников работающих с этой системой около 25 человек (10 в офисе, 15 по филиалам). В эту же систему подключили техническую службу (+ 20 человек). Система не гибкая (бесплатная). В ближайший год планируется развитие компании, и понимаю, что текущая система будет не удовлетворять потребностям (количество пользователей 100, заявок 1000-2000 ежедневно). Необходимо чтобы с ServiceDeskи SLA работали не только ИТ, а все сервисные службы компании,…

Вопрос из зала, 8 октября 2012, последний комментарий 18 марта 2013

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

Говорят, для того, чтобы разгрузить перегруженных операторов поддержки, можно перехватывать часть обращений разными средствами автоматизации – порталами, IVR и тому подобными. Но мало кто знает, что эти же средства прекрасно подходят для тестирования интеллектуальных способностей (и, вероятно, других особенностей личности), чтобы потом на основе результатов тестов… делать что-нибудь. Чем больше процедура обращения в службу поддержки похожа на квест, тем больше поставщик услуг узнает о пользователях. А они – о поставщике, кстати. Позвонил я недавно в службу поддержки клиентов одного банка. Там, конечно, ответила механическая женщина, которая предложила мне зайти в систему автоматизации. Я согласился, и она попросила меня ввести номер карты….

Роман Журавлёв, 1 октября 2012, последний комментарий 13 октября 2012

Мини-кейс: выбираем приоритеты

Подискутировал тут со слушателями спец-курса «Управление инцидентами» про выбор приоритета инцидентов. Общие слова про то, что правила назначения приоритета призваны помочь исполнителям скорее выбрать, какую задачку делать первой, и про то, что приоритет – это всего лишь алгоритмически определяемый признак, который всё равно нужно дополнять живой головой, принимающей решения, были сказаны. Дело в том, что в этой организации есть регламент процесса, где, во-первых, приоритет однозначно определяет целевой срок устранения инцидента, а еще заданы признаки выбора приоритета. Примерно такие: Приоритет «Высокий» – сбой затронул работу всех пользователей Приоритет «Средний» – сбой затронул значительное число пользователей (более 80% по оценке ИТ-специалиста»). Приоритет…

Константин Нарыжный, 28 сентября 2012, последний комментарий 21 октября 2012

Роботизированная поддержка

На днях был в командировке в Краснодаре. Тамошние коллеги рассказали удивительную историю о том, как на одной из выставок им был продемонстрирован бот, который умеет самостоятельно общаться с пользователями по MS Lync, выполняя функции … первой линии поддержки. В частности, со слов очевидцев, он умеет требовать от пользователей более конкретные формулировки, чем «помогите» или «у меня всё не работает», в том числе посредством уточняющих вопросов по диагностическому дереву. По итогам диалога, если пользователю не удалось помочь, но собрана достаточная диагностическая информация, бот самостоятельно регистрирует от пользователя заявку в MS SCSM. То есть я уточню: пользователь обращается в службу поддержки по…

Дмитрий Исайченко, 27 сентября 2012, последний комментарий 4 октября 2012

Безвыходные инциденты

Думаю ни для кого не секрет, что инциденты рано или поздно закрываются. Обычно это происходит после того, как найдено и применено решение, в некоторых случаях требуется подтверждение пользователя, в некоторых нет. Иногда это делает участник одной из ролей (например, менеджер процесса), иногда – система автоматизации, после получения подтверждения или по прошествии определенного времени после решения. При этом обычно указывается так называемый "Код закрытия", указывающий, на каком основании был закрыт инцидент. Справочник кодов закрытия – отдельная история. Обычно в нем присутствуют коды: "Решен", "Не удалось воспроизвести", "Отказ пользователя" и так далее. На днях обсуждали с одним из клиентов возможность ситуации, при…

Евгений Шилов, 26 сентября 2012, последний комментарий 4 октября 2012

Вопрос из зала: есть ли плюсы в портале самообслуживания?

Анна Лобова, IT Manager и постоянный читатель нашего портала, а также регулярный участник ITSM-вебинаров, задаёт вопрос в виде развёрнутого кейса. Анна просит наше сообщество помочь ей и раскритиковать кейс в пух и прах. Давайте поможем. Не секрет, что без каталога услуг, SLA, базы знаний, системы регистрации и учета запросов сотрудникам ИТ живется нелегко: пользователи просят все что хотят и прямо сейчас. Очевидность необходимости всех этих и других «айтиловских примочек» объяснять в очередной раз не стану. Но как предоставить пользователям эти данные в удобном формате и более того: как собрать их вместе и залинковать между собой таким образом, чтобы не…

Вопрос из зала, 17 сентября 2012, последний комментарий 19 сентября 2012

Функциональная эскалация

Недавно в свете выпуска нового релиза CleverENGINE обсуждали внутри тему функциональной эскалации в управлении инцидентами. Этот, на первый взгляд, несложный вопрос на практике имеет очень важное значение, а принятые по нему решения определяют не только принципы разграничения ответственности за поддержку пользователей, но сказываются и на структуре каталога ИТ-услуг, и на содержании SLA. Так вот можно выделить два принципиально различных способа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом. В случае произвольного маршрута специалист, отвечающий за обработку инцидента, выбирает следующий шаг эскалации самостоятельно, в зависимости от результатов диагностики. Например, инцидент, связанный с отказом информационной системы по результатам диагностики может быть…

Дмитрий Исайченко, 11 сентября 2012, последний комментарий 22 сентября 2012

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

Service Desk

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