Вы готовы к ведению учета? Ну что, начнем?

Прежде всего, Вам необходимо ясно представить цели, которые Вы хотите получить в конце от автоматизации Service Desk и быть морально готовым к кропотливой работе по упорядочиванию задач, их систематизации, обучению пользователей новой системе и т.д.
На бумаге нарисуйте схему обработки инцидентов (в нашей терминологии и далее – заданий) у Вас в отделе, как бы Вы хотели, чтобы это работало. Есть ли у Вас менеджер по приему заданий, который распределяет задания по направлениям, или Вы будете работать без него? Составьте ПОЛНЫЙ СПИСОК всех возможных процессов в Вашей ИТ-структуре. И для каждой сделайте свою схему. Мы покажем, как настроить работу для одного вида процессов. Остальное Вы сделаете по аналогии.
Рассмотрим бизнес-процесс обращения пользователей организации (инициаторов) в ИТ-службу на примере следующей схемы (по умолчанию она присутствует в только что установленной конфигурации и называется «Обращение»).
Допустим, в нашем виртуальном примере есть человек, который отвечает на все телефонные звонки (оператор), фиксирует все данные в самом начале и распределяет эти обращения по исполнителям.
При этом он регистрирует все данные (тема, текст, приоритет, от кого и т.д.). Потом отдает на выполнение другому специалисту отдела, а тот уже выполняет все, что бы обратившийся получил решение поставленного задания.
Причем, человек регистрирующий обращение достаточно грамотен и может решить вопрос самостоятельно, не передавая другому сотруднику. Так же в процессе беседы может оказаться, что обращение было вызвано неграмотностью пользователя вследствие чего, обращение было отменено.
После того, как оператор выбрал исполнителя, исполнитель может установить другого исполнителя, т.е. передать его другому специалисту, а так же самостоятельно выполнить задание. В процессе работы может быть такая ситуация, когда конечный исполнитель указал, что он выполнил задание, но после проверки его инициатором оказалось, что задание не доведено до конца. В таком случае необходимо предусмотреть переход из состояния «Выполнено» в состояние «Выполнение», из которого потом снова можно перейти в состояние «Выполнено» и т.д.

В результате имеем этапы обращения:
• Новый (обращение еще не рассмотрено оператором);
• Регистрация (обращение рассмотрено оператором, внесены все реквизиты обращения);
• Отмена (оператор решил вопрос самостоятельно, или по какой-то причине обращение было отменено)
• Выполнение (оператор назначил конечного исполнителя)
• Выполнено (конечный исполнитель выполнил задание)

По этим этапам нарисуем схему, как в нашей мнимой организации происходит работа с обычным обращением пользователей:

r1.png


В конфигурации получим процесс ( Техническая поддержка > Процессы ) :

r2.png

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

r14.png

Видно, что перевести с этапа "Регистрация" можно на один из двух этапов: либо "Выполнение", либо "Отменено". Если мы выберем "Выполнение", то задание будет переведено на новый этап "Выполнение" с этапа "Регистрация", таким образом мы перейдем с одного этапа на другой.

Аналогично и для других этапов.

Последовательный переход с этапа на этап позволит перевести задание из начального этапа "Новый" в конечный этап "Выполнено" или "Отменено".


 Определяемся как работаем по заявкам с пользователями | Описание курса | Работы по заданиям