Здравствуйте!
Есть вопрос по Service Desk. Об отношении сервис - инцидент. От чего нужно отталкиваться?
Вариант 1:
Есть сервисы, которые предоставляет компания (услуги колл-центра, предоставление хостинга и т.д) и инциденты (пропал интернет, что-то не работает и т.д.), которые возникают в контексте этих сервисов. При этом способов разрешения этих инцидентов может быть множество и поэтому классифицировать их не важно.
Вариант 2:
Есть сервисы первого уровня (те же услуги колл-центра, предоставление хостинга и т.д) и те же инциденты, но отталкиваемся уже от сервисов - инструментов разрешения инцидентов (переустановка системы, наладка ПО, что-то ещё).
Как правильно организовать работу СД относительно этих вопросов? Возможно есть другая модель, или может быть различные модели используются в разных случаях?
Проясните пожалуйста ситуацию!
Заранее спасибо.
Нравится
Если я верно поняла Ваш вопрос, обратите внимание на группировку сервисов. Сервисы делятся на два типа: «Бизнес-сервисы» и «Технические сервисы».
Бизнес-сервис обобщенно группирует подчиненные или связанные с ним технические сервисы, которые представляют собой определенные операции, выполняемые в рамках сервисного обслуживания.
Таким образом Вы можете создать бизнес сервисы «Предоставление хостинга», «Услуги колл-центра», в которые включить технические сервисы «пропал интернет», «настройка учетных записей» и др.
Затем при создании инцидента указать тот сервис в рамках сервисного договора, по которому возник и решается инцидент.
Привела в качестве примера. Можете назвать сервис "Восстановление доступа к Интернет", а инцидент будет звучать "пропал интернет".
Акмаль,
Конечно же можно классифицировать постпродажную техподдержку как услугу. К примеру : сервис будет иметь название "гарантийное обслуживание", в него будут включаться оговоренные время реакции и время разрешения. Соответственно, все сбои будут фиксироваться как инциденты.
Что касательно второй части вопроса - то тут Вы можете самостоятельно выбрать, по какой схеме работать. Классический ITIL называет инцидентом любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги.
Запрос на Обслуживание — это Запрос от пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.
Исходя из этого, можно сделать Вывод что предложенная Вами схема работы (сбой в ПО - инцидент, не сбой - запрос на обслуживание) является рекомендуемой.
Игорь, большое спасибо!
Честно говоря не хочется вызывать желание у посетителей треда отправить меня "учить матчасть" и "курить мануалы" (я этим занимаюсь каждую свободную минуту), однако сроки, в которые мне нужны ответы поджимают.
Так что позволю себе ещё пару вопросов, чтобы прояснить ситуацию.
По поводу технических сервисов. Я так понимаю, они определяются, как действия по устранению инцидентов и выполнению запросов на обслуживание? Если да, то как определить минимальное количество технических сервисов, которое должно быть определено? По количеству типовых инцидентов и запросов? Обязательно ли при каждом появлении нетипичного инцидента добавлять новый тс в каталог?
И по поводу процессов и бизнес-процессов. Какую роль они играют во внедрении SD? Понятно, что для обработки входящих событий, которые мы можем составить только после определения перечня услуг, должен быть процесс. Существуют ли ещё какие-то обязательные процессы? И как (и нужно ли) это всё соотнести с процессами, происходящими в бизнесе, которые зависят от предоставляемых услуг?
Буду крайне признателен за ответы.
Акмаль, Вы не вызываете таких желаний и Ваши вопросы вполне обоснованы.
По поводу технических сервисов Вы абсолютно правы. У каждого бизнес сервиса (Печать, Телефония, Интернет итд.) Могут быть неограниченное количество технических сервисов. Количество определяется для каждой компании самостоятельно исходя из состава наиболее частых запросов на обслуживание или инцидентов. При появлении нетипичного инцидента 2 варианта опять же : либо добавить ( потребуется примерная оценка планируемого времени реакции/разрешения и оценка трудозатрат) , либо категоризировать инцидент по существующему сервису (в любом случае некоторые сервисы будут иметь схожее происхождение) . Принимать решение необходимо взвешенно, опять же, исходя из индивидуальной схемы работы каждого клиента.
Касательно бизнес процессов. Безусловно, процессы имеют главенствующую роль, ведь одна из целей внедрение системы - автоматизация работы и прозрачность каждого действия.
Кроме процесса обработки инцидентов, о котором Вы писали, есть целый перечень других процессов : Управление изменениями, релизами, проблемами и многое другое. Безусловно, процессы напрямую связаны с сервисами.
Связать же можно, только изучив задачи клиента и поняв, какие задачи конкретно предстоит решать.Приношу извинения, но более подробно под этого клиента я не смогу описать Вам.
Всё, вышеизложенное - теория, на практике необходимо смотреть специфику для каждого клиента.
Буду рад ответить на любые вопросы возможные.
Предыдущий вопрос в силе. Есть ещё один.
Интересно мнение специалистов, корректно ли будет с точки зрения ITIL, SD, чего угодно, заполнять раздел "Сервисы", отталкиваясь от возможных инцидентов с оборудованием/услугами? Например так:
Бизнес-сервис: Маршрутизаторы (Поддержка работы маршрутизаторов)
Технический сервис: Устранение зависание маршрутизаторов
Технический сервис: Устранение аппаратных сбоев маршрутизаторов
Технический сервис: Устранение системных сбоев маршрутизаторов
или
Бизнес-сервис: Хостинг (Предоставление хостинга)
Технический сервис: Устранение ошибок доступа к сайту из мира
Технический сервис: Устранение ошибок доступа к сайту из другой сети
Технический сервис: Устранение ошибок доступа к сайту по FTP
Заранее спасибо.
"Салихов А" написал:Скажите, а имеет ли смысл добавлять в раздел "Сервисы" певоначальные работы по внедрению? Например бизнес-услуга "Инсталляция ПО" и сервисы, входящие в неё - "Установка ОС", "Установка MSSQL Server" и т.д.?
Спасибо.
Акмаль, если идет проект по внедрению, выполняемые работы группируются в виде стадий конкретного проекта без привязки к сервисам. Если же услуги оказываются после внедрения проекта - тогда имеет смысл формировать бизнес услугу с входящим в нее набором технических сервисов.
"Салихов А" написал:Интересно мнение специалистов, корректно ли будет с точки зрения ITIL, SD, чего угодно, заполнять раздел "Сервисы", отталкиваясь от возможных инцидентов с оборудованием/услугами? ......
Подобная структура корректна.