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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Вопрос из зала

Вопросы, заданные читателями портала, на которые дают ответы авторы блогов и другие читатели.

Насколько детальным должно быть меню регистрации запросов пользователей?

В редакцию портала поступил вопрос: Добрый день. Вопрос наверное не новый и проблема общая. Поступает куча запросов, неправильно зарегистрированных пользователем: неправильная привязка сервиса, типа запроса и т.п. Вопрос в следующем, насколько глубоко меню регистрации запроса должно быть категоризировано. Грубо говоря первая крайность  – меню совсем без полей выбора привязки к сервису, к типу и т.д., пользователь просто описывает проблему своими словами, а далее все привязки делает специалист СТП при регистрации запроса. Вторая крайность –  меню содержит кучу зависимых полей выбора (Сервис – Вид обращения – Тип запроса и т.д.), в которых пользователь обычно путается и регистрирует запрос неверно. Хотелось бы…

, 20 января 2021, последний комментарий 11 февраля 2021

Оценка важности задач в Канбан-методе

В редакцию портала поступил вопрос: Есть ли у канбан инструменты для оценки бизнес-эффекта от поставленной задачи? Бывают случаи, когда заказчики начинают наращивать функционал, который команде представляется не самой нужной для конечного пользователя и Компании. Например, излишняя отчётность. После смены заказчика (переживали не раз) функционал будет не востребован.

, 16 декабря 2020, последний комментарий 16 декабря 2020

Два вопроса об управлении проблемами

В редакцию портала поступил вопрос: Здравствуйте! Процесс управления проблемами На основании обращений пользователей зарегистрирована проблема: определен способ обходного решения. Дупустимо ли в инциденте  устанавливать связь с проблемой (т.е. записью в проблем трекере) при закрытии инцидента путем обходного решения?  Предполагается, что это будет выполнять специалист 2-3 ЛТП. Для устранения корневой причины требуется доработка (например, ошибка при формировании требований, не является багом). В качестве решения регистрация RFC. В каком случае проблема может быть закрыта: реализация и проверка заказанной доработки или же достаточно согласование заказанной доработки?

, 11 декабря 2020, последний комментарий 14 декабря 2020

Учет кратности работ при расчете срока оказания услуги

В редакцию портала поступил вопрос: Добрый день! Безуспешно ищу на форуме тему учета кратности работ при расчете срока оказания услуги (SLA).   Кейс следующий: Наша организация оказывает ряд услуг, работы по которым могут быть множественными. Например, руководитель отдела делает заявку, что необходимо установить ПО на 10 ПК его сотрудников. Или от клиента поступила заявка на изготовление 5 ЭЦП. Диспетчер принимает заявки такого типа как одно обращение и указывает кратность работ 10 или 5. Инженер выполняя работы по обращению может учесть эту кратность при фиксации трудозатрат, с учетом того что норма на одну работу заранее четко определена. Исходя из описанного кейса…

, 6 ноября 2020, последний комментарий 12 ноября 2020

Какой критерий может проактивно показать, что группа перестает справляться с поступающим потоком обращений?

В редакцию портала поступил вопрос: Добрый день! Какой критерий может проактивно показать, что группа перестает справляться с поступающим потоком обращений? Как у вас налажен этот процесс? Хотелось бы выявлять перегрузку до того, как будут сорваны договорные сроки, настроить какой-то “красный сигнал”, что вот на данный момент дела начинают идти плохо. В магазине это растущая очередь в кассе до определенной величины, сигнал того, что нужно подключать еще кассы. А как на практике используете вы, какие индикаторы? (возможно размер очереди или еще какие-то параметры). Спасибо!

, 18 июня 2020, последний комментарий 23 июня 2020

Проактивное управление проблемами

В редакцию портала поступил вопрос: Добрый день! Вопрос по проактивному управлению проблемами. Поддержка, которая решает инциденты, может создавать отдельные запросы на вендора. Таким образом, инциденты от заказчиков, с одинаковой «проблемой» могут быть связаны с одним запросом, который решается вендором. При анализе инцидентов, определяется ряд инцидентов с одинаковой проблемой, которая решается в рамках запроса на вендора. Так как есть инциденты с одинаковой проблемой, регистрируется проблема, которая привязывается к запросу на вендора. Насколько это правильно, с точки зрения организации процесса? Новые обращения должны привязываться к проблеме или же к запросу, в рамках которого решается проблема? Имеет ли смысл выделять главный инцидент, к…

, 17 марта 2020, последний комментарий 31 марта 2020

Что делать со “старыми” инцидентами?

В редакцию портала поступил вопрос: Добрый день. Как следует поступать со «старыми» инцидентами? Пример 1. Инцидент не закрывается уже длительное время, например, месяц. Причина — отсутствие ресурсов/времени у специалистов. Следует ли открывать проблему и закрывать после этого инцидент? Пример 2. Внешний инцидент не закрывается уже длительное время, например, месяц. Причина — вендор не предоставляет исправление. Следует ли открывать проблему и закрывать после этого инцидент?

, 16 января 2020, последний комментарий 16 марта 2020

Вопрос приоритизации заявок

В редакцию портала поступил вопрос:   Вопрос по приоритетам. У сотрудника второй линии есть три заявки в работе, над одной он работает, по двум другим идёт время и эти заявки с приоритетами «срочный»и «средний». Заявки поступили в разное время, закончив первую, сотрудник, по идее, должен перейти к срочной. Но на практике заявка с приоритетом средний (пока сотрудник работал над заявкой номер 1), уже почти исчерпала время решения, так как поступила гораздо раньше средней и остались считанные минуты до нарушения SLA. Сотруднику, чтобы не потерять KPI, нужно быстро обработать среднюю, а срочный вопрос на потом. Получается конфликт интересов сотрудника и заказчика….

, 21 ноября 2019, последний комментарий 29 ноября 2019

Первая линия поддержки – от девочки-оператора до монстра

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

, 2 октября 2019, последний комментарий 18 октября 2019
 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.