Рассмотрим ситуацию – существует компания, в которой есть несколько отделов: отдел продаж, отдел закупок, бухгалтерия и IT-отдел, совмещенный со службой Helpdesk, который оказывает услуги технической поддержки другим отделам. Для формализации бизнес-процесса с учетом рекомендаций ITSM нужно определить:
В нашей компании есть несколько отделов-потребителей IT сервисов и отдел-поставщик IT сервисов. Это типичная ситуация для IT-поддержки внутри организации.

Типичный бизнес-процесс ИТ-поддержки выглядит следующим образом:
Бизнес-процесс может быть более сложным—он может включать в себя согласование заявки различными ролями, несколько начальных и конечных статусов, параллельные процессы и т.д.
Сервисы служат для логического объединения заявок в независимые группы. Сервисная модель в системе может быть любой: например, сервис может соответствовать контракту («Поддержка по договору №21-04»), клиенту («Поддержка филиала в Сочи») или предоставляемой услуге («Заказ канцелярии»). Ту или иную сервисную модель нужно выбирать в зависимости от того, сколько пулов исполнителей в нашей компании, какое ожидаемое количество заявок, каковы настройки прав для пользователей и т.д. В нашей компании один общий пул исполнителей, пользователи должны видеть заявки своего отдела, ожидаемое число заявок невелико, разумно выбрать группировку заявок по отделам. Более подробные рекомендации по созданию сервисной модели находятся в библиотеке ITIL, в части ITSM.
В один прекрасный день у бухгалтера не запустилась программа «1C». Чтобы решить эту проблему, бухгалтер создает заявку в системе IntraService, допустим, с помощью веб-интерфейса. (Он мог бы написать письмо, или позвонить в службу helpdesk, и диспетчер создал бы заявку вместо него, в зависимости от правил Вашей компании).
Диспетчер службы поддержки получает письмо от системы о том, что создана заявка.
В письме диспетчер видит, кто и когда создал заявку, какой у нее приоритет, есть ли вложенные файлы и т.д. Формат письма настраивается, Вы сами можете определить, какие поля заявки включать в письмо, а какие нет.
Диспетчер кликает на ссылку в письме и переходит на карточку заявки. Он проставляет срок исполнения (1), назначает исполнителей (2) из числа доступных.
Какие поля заявки диспетчер сможет изменять определяется настройками его роли. В данном примере диспетчер может менять все поля, кроме полей "Описание", "Выполнено", "Файлы" и "Активы".
Исполнители также могут быть назначены автоматически. Мы можем сопоставить исполнителей категориям заявок, и, при создании заявки с категорией «1С», на нее автоматически будет назначен соответствующий этой категории исполнитель.
Исполнитель получает письмо о том, что на него назначена новая заявка. Он решает проблему, переходит по ссылке из письма в helpdesk систему, изменяет статус заявки на «Выполнена» (1), списывает затраченное на решение заявки время (2) и сохраняет карточку.

Диспетчер получает письмо о том, что заявка выполнена, и звонит заказчику в бухгалтерию. Убедившись, что все прошло успешно, он переводит заявку в статус закрыта. (В зависимости от бизнес-процессов в Вашей компании, заявку мог бы закрывать сам клиент, или исполнитель, или сотрудник службы контроля качества.) Клиент получает уведомление о том, что его завка выполнена.
В конце отчетного периода руководитель службы helpdesk формирует отчет о выполненных заявках и трудозатратах. С помощью гибкого механизма фильтров он может формировать счета на оплату услуг за период, на оплату определенного вида услуг, на оплату услуг определенного исполнителя и так далее.

По каждой заявке ведется подробная история изменений, в которой отмечаются все произошедшие по заявке изменения. Изменившиеся поля выделены цветом.

Мы настроили этот бизнес-процесс на демо-площадке, попробуйте адаптировать его для Вашей компании!