Вопрос из зала: как поступать с заявками, требующими ответных действий пользователя?

Опубликовано 11 января 2016

Рубрики: ITSM, Service Desk, Вопрос из зала

Комментарии

Поздравляем всех посетителей портала с наступившим Новым годом! Редакция возобновляет свою работу после новогодних каникул.

В рубрике "Задать вопрос!" пока без ответа находится вопрос Дениса, который он адресует общественности портала:

Добрый день.

Существуют ли устоявшиеся практики управления "обратными заявками от исполнителя потребителю" или задачами, которые потребитель должен выполнять для получения услуги?

Первая иллюстрация

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

Вторая иллюстрация

Услугой является кадровый учет. При обработке заявки на перенос отпуска возникают ситуации, когда график отпусков находится на окончательном подписании у потребителя. Для утверждения графика можно создать заявку самому себе, но фактически исполнителем является сторона заказчика. Если проблема, то тоже не на нашей стороне.

Коллеги, давайте поделимся опытом в комментариях!

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 8

Андрей
11.01.2016

Тут как-то все перепутано. Первый пример, это не заяка, а совокупность инцидентов, указывающая на проблему. Хочется это называть проблемой или нет, но это проблема и решается она введением проверки вводимой информации на форме ввода.

Второй пример – это заявка, исполнение котрой зависит от состояния дополнительного объекта – графика отпусков. Не понятно, какие подразумеваются ответные действия пользователя. Он, пользователь, отправил заявку с просьбой изменить даты отпуска. Процесс исполнения таких заявок должен включать проверку статуса графика отпусков. Если график еще не начали согласовывать, то даты можно поменять сразу в нем. Если процесс согласования уже пошел, то исполнение заявки необходимо приостановить до утверждения графика отпуков и потом запустить её как корректировку. Но это все делается без участия пользователя. Так что не понятно про какие ответные действия идет речь.
- Ответить
Руслан
12.01.2016

В нашей практике применяется первый пример, только "сообщить где ошибка и потребитель исправит" заключается в отклонении заявки с указанием причины. В этом случае потребителем формируется новая заявка с указанием недостающей информацией.
- Ответить
Денис
18.01.2016

По первой иллюстрации

Администратор какой-то системы при анализе логов обнаруживает, что не сможет выполнить свои обязанности до тех пор, пока кто-то из пользователей системы не выполнит свои.

По второй иллюстрации

Кадровик не сможет перенести отпуска, т.к. кто-то из руководителей инициатора "заблокировал" график отпусков.

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

Мне кажется, всё проще. Практика такая.

Исполнитель работы (наряда) через интерфейс Service Desk отправляет Сообщение Заявителю, что нужно дополнительно сделать/чего не хватает, чтобы выполнить его Обращение. Работа (наряд) до получения сведений от Заявителя переходит в статус Ожидания. Заявителю отправляется письмо по электронной почте, ответ на которое автоматически встает в Обращение – Исполнитель оповещается о получении обратной связи от Заявителя. Время исполнения Обращение, по идее, можно передвинуть на величину ожидания информации от Заявителя.
- Ответить
Татьяна
18.01.2016

Из моей практики- заявка переводится в статус "Запрос информации" с соответствующим механизмом информирования Заявителя, Заявитель отслеживает такие заявки в системе учета , отвечает на запрос (в том числе – предоставляет нужную информацию, например логи, проводит рекомендованные манипуляции в ППО и фиксирует результат). Время нахождения заявки в статусе "ЗИ" не учитывается в общем времени выполнения заявки Исполнителем. И Заявитель , и исполнитель либо работают в одной системе учета заявок, либо система Заявителя интегрируется (в том числе по статусам) с системой Исполнителя.
- Ответить
Anton Lebedev
18.01.2016

Возьмем для примера запрос на обслуживание "Установка нового рабочего места". В поле заявки, указанны данные которые необходимо указать автору заявки. В случае если автор отправляет заявку с неполными данными, эти данные обязаны уточнить первая линия утверждающих – начальник техподдержки и начальник группы связи. Каждый выясняет свои кусочки недостающей информации, после этого согласовывает. Согласовали значит все данные есть. На второй линии утверждающих, заявку апрувит их начальник, который решает предоставляем оборудование и в каком объеме.

В случае low-инцидентов переводим заявки в режим "запрос от пользователя"
- Ответить
Денис
19.01.2016

Хотелось бы исключить из обсуждения контроль соблюдения SLA, натягивание средств автоматизации управления инцидентами на другие процессы и работу с недооформленными запросами.

Трудовая деятельность может случайно или по расписанию переходить в состояние, которое для провайдера услуги описывается фразой "проблема не на нашей стороне". Из лучших побуждений, действуя проактивно, надо сообщать потребителю об этом. Подходит ли для этого IT Operations Control, Event Management или что-то совсем другое?
- Ответить
Цыганов Олег
19.01.2016

Коллеги, всем привет.

Поделюсь своим опытом и задам вопрос.

В случае, если для решения заявки нужно, чтобы клиент выполнил какие-то действия или сообщил информацию, мы сообщаем об этом клиенту и переводим заявку в состяние "Ожидание ответа клиента". При этом счетчк времени обработки заявки останавливается. В договоре указано, что время ожидания ответа клиента не учитывается.

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

Но есть несколько проблем.

Факт коммуникации с клиентом не котроллируется, приходится вручную просматривать отложенные заявки и разбираться действительно ли с клиентом пытались связаться.

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

Не могу придумать показатель, чтобы как-то изменить и контроллировать качество работы с отложенными заявками.

Расскажите о вашем опыте решения выше указанных проблем.
- Ответить