Классификация заявки и управление проблемами

[JohniGo]

Вопросов в общем-то 2, но решил не плодить темы. Прошу поделиться опытом по решению таких вот вопросов:

1. Как уважаемые коллеги решают проблему классификации заявок?
Поясню, что я имею в виду. В настоящий момент ITSM еще в боевой режим не вывел и используется функционал "голого" OTRS. Для простоты работы клиентов (сотрудники компании) в заявке заполняются только 2 поля - "Тема" и "Содержание" заявки. Дальше заявка попадает в очередь техподдержки. Собственно спец техподдержки либо решает заявку сам, либо перекидывает ее в очереди второй линии поддержки. Собственно прав на редактирование заявки у этого сотрудника нет и все лишние поля для заполнения в заявке отключены.
И суть вопроса. Для дальнейшего анализа заявку необходимо классифицировать по куче признаков (ну как минимум проставить сервис к которому относился сбой, дальше, при использовании ITSM определить тип заявки Инцидент, проблема RFC и т.д.) Каким образом можно организовать схему работы, чтобы с одной стороны, клиент по прежнему заполнял только свои 2 поля, а вот специалист техподдержки был обязан заполнить все классификационные поля, но при этом не редактировал данные, введенные клиентом.

2. Каким образом организовать процесс управления проблемами?
На сколько я понимаю, проблема с точки зрения ITIL тот же самый инцидент, только более высокого уровня. И по идее, к нему должны подвязываться инциденты вытекающие из наличия данной проблемы.
Собственно вопрос: как заводить проблемы в систему. Понятно, что права на создание такого типа заявки должны иметь только агенты, например через "Телефонный звонок". Каким образом связывать инциденты с известными проблемами? Каким образом выявлять на основании имеющихся инцидентов неизвестные?

В общем расскажите, кто как это делает.

[JohniGo]

Это секретное ноу-хау, или никто не использует? Ведь самый что ни на есть ITIL...

[alexus]

Добрый день!
Вы слили два очень мощных вопроса в один топик. Может поэтому народ и пугается писать сразу обо всем. Начну с первого.

Классификация по типу запроса в принципе довольна проста. Это обычно Инцидент, RFC, Стандартный запрос, Запрос на обслуживание. Всё это согласно ITIL. И ITSM модуль тут совершенно не причём. Желательно, чтобы уже клиент (он же пользователь) сам классифицировал запрос. Ну или на первой линии чтобы уже четко было определено, что это за запрос. Ведь от этого зависит алгоритм и скорость дальнейшей обработки.

[JohniGo]

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

Хотел бы Ваши комментарии по второму вопросу услышать.

[ykolesnikov]

Интересные вопросы. По первому, не видел конфигурационных возможностей, без программирования (что не приветствую без острой необходимости) добавить штатные поля к уже созданной заявки, кроме свободных полей. Но, там тогда придется прописывать, повторяясистемные таблицы, перечни сервисов и SLA, да и если сервисы имеют несколько уровней это будет трудно сделать красиво.

[JohniGo]

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

[ykolesnikov]

Здесь есть еще косяк, который без программирования, видимо, не решить - заставить при выборе, если список сервисов иерархический, не давать его(сервис) ввести, пока не выбран самый младший уровень. Иначе потом, при анализе, все будет некорректно.

[JohniGo]

Да уже сталкивался с этой проблемой, когда разбирался с сервисами. Пока, как вариант, записывать сервисы как "Сервис: Подсервис". Но это меня пока в меньшей степени волнует.
Жаль, что мы так и не услышали начальника транспортно цеха
В смысле, что никто не ответил на второй мой вопрос.
Да и на первый в общем-то тоже. Видимо никто не использует...

[JohniGo]

Что-то я вообще не нахожу возможности редактировать тикет или даже уже существующую заметку. Мне казалось, что возможность есть, но при детальном рассмотрении оказалось, что вообще нет нигде возможности редактирования...

[alexus]

Что написано пером....

[JohniGo]

Ну в общем-то логично конечно, но тем не менее...
ИМХО не должен пользователь заниматься классификацией заявки. По всем канонам это задача ServiceDesk. А тут такая засада...

[alexus]

Можно менять Тип заявки, Сервис и SLA

[JohniGo]

Кстати да, Вы правы, Алексей.
Посмотрел на тестовой системе.Тип, сервис, SLA и приоритет в заметке у агента присутсвуют. На типе даже стоит признак обязательного заполнения. Правда так и не нашел, где отключить Тип в интерфейсе клиента.. но самое главное, что механизм есть. (странно что сам не нашел, вроди прозрачно все...)
Правда вместе с приоритетом вылезает "Impact" и ни отключить его, ни дефолтное значение не выставить..

Остался вопрос, как обязать агента привязывать инциденты к проблемам или к обходным решениям (статьям FAQ).

[alexus]

Посмотрите здесь и сделайте от обратного. Это, что касается про Тип.
А агента обязать можно только либо волшебным пендалем, либо пряником. Хотя бы по рублику за вист .

[JohniGo]

Посмотрите здесь и сделайте от обратного. Это, что касается про Тип.
А агента обязать можно только либо волшебным пендалем, либо пряником. Хотя бы по рублику за вист .

Видимо "здесь" подразумевало ссылку?

[ykolesnikov]

JohniGo!
Я думаю, он имел ввиду: viewtopic.php?f=4&t=271 и сделать наоборот

[JohniGo]

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