Комментарии 14
Внедрение ITSM в компании нужно начинать не с определения каталога услуг, а с ответа на вопрос: «для чего нашей компании ITSM?». После честного ответа на этот вопрос все остальные вещи структурируются сами-собой.
Лично я использую ITSM для контроля двух аспектов работы ИТ-отдела:
1) Какой уровень сервиса получает компания от ИТ.
2) Сколько компания тратит на ИТ и куда уходят эти деньги.
По теме статьи:
1) ИТ-сервисы разделяются на пользовательские и на инфраструктурные. Естественно, пользовательские сервисы опираются на инфраструктурные и эта связь должна быть определена — она помогает при локализации инцидентов, а также нужна для расчета итоговой доступности пользовательских сервисов.
2) В случае сбоя инфраструктурного сервиса, достаточно завести заявку по инфраструктурному сервису. К этой заявке уже можно привязать все обращения пользователей. Нет никакого смысла насиловать свой хелпдеск необходимостью заводить 40 тикетов по каждому пользовательскому сервису из-за того, что в серверной отключили электроснабжение.
3) Стоимость владения нужно считать отдельно по инфраструктурным и пользовательским сервисам.
4) Доступность сервиса для пользователей не составляет труда вычислить зная доступности инфраструктурных сервисов и количество изолированных сбоев пользовательских сервисов, не связанных с инфраструктурными.
Лично я использую ITSM для контроля двух аспектов работы ИТ-отдела:
1) Какой уровень сервиса получает компания от ИТ.
2) Сколько компания тратит на ИТ и куда уходят эти деньги.
По теме статьи:
1) ИТ-сервисы разделяются на пользовательские и на инфраструктурные. Естественно, пользовательские сервисы опираются на инфраструктурные и эта связь должна быть определена — она помогает при локализации инцидентов, а также нужна для расчета итоговой доступности пользовательских сервисов.
2) В случае сбоя инфраструктурного сервиса, достаточно завести заявку по инфраструктурному сервису. К этой заявке уже можно привязать все обращения пользователей. Нет никакого смысла насиловать свой хелпдеск необходимостью заводить 40 тикетов по каждому пользовательскому сервису из-за того, что в серверной отключили электроснабжение.
3) Стоимость владения нужно считать отдельно по инфраструктурным и пользовательским сервисам.
4) Доступность сервиса для пользователей не составляет труда вычислить зная доступности инфраструктурных сервисов и количество изолированных сбоев пользовательских сервисов, не связанных с инфраструктурными.
Поддерживаю.
Но всё же информацию какие именно пользовательские сервисы пострадали и насколько сильно, все равно хорошо бы иметь в системе управления инцидентами, чтобы потом проще было получать отчет о доступности пользовательских сервисов.
Не всегда есть жесткая связь между инфр. и пользовательскими сервисами.
В случае сбоя инфраструктурного сервиса, достаточно завести заявку по инфраструктурному сервису. К этой заявке уже можно привязать все обращения пользователей.
Пользователь ничего не знает про инфраструктуру, у него просто 1С перестала работать. И он хочет знать, когда 1С заработает. Поэтому он позвонить и спросит на счёт своего тикета на 1С, у Вас же его нет, потому как у Вас есть тикет на «отключение электроэнергии».
Другими словами, когда звонит юзер и сообщает о том, что у него не работает 1С, ещё никто не знает, что в серверной отключили электричество. И регистрировать надо именно этот тикет «1С не работает», после чего необходимо начать расследование причин того, почему не работает 1С. Если расследование приводит к выводу о том, что в серверной нет электричества, то дальнейшие действия зависят от построения процесса обработки и регистрации заявок на инфраструктурные услуги — завести внутреннюю заявку отдельно или привязать к исходной некую подзаявку или сделать что-то еще.
При этом продолжать регистрировать все поступающие заявки по не работающей 1С, не отправленной почте, не загруженных котиках. Потому что не зарегистрированные заявки плохо сказываются на ощущениях пользователей об уровне оказываемого сервиса.
когда звонит юзер и сообщает о том, что у него не работает 1С, ещё никто не знает, что в серверной отключили электричество
А вот это не хорошо. Мониторинг нужно подтягивать на уровень повыше, чтобы о таких вещах дежурной смене становилось известно ещё до звонков юзеров.
Это уже другой вопрос и подтягивать нужно не только мониторинг, но Service delivery, вкупе с планированием — в правильной серверной стоит, как минимум, ИБП и как максимум — дизель в дизельной. :)
И на отключение основного питания автоматически создаётся внутренний тикет, который сразу назначается нужному человеку или группе.
И на отключение основного питания автоматически создаётся внутренний тикет, который сразу назначается нужному человеку или группе.
Внедрение ITSM в компании нужно начинать не с определения каталога услуг, а с ответа на вопрос: «для чего нашей компании ITSM?». После честного ответа на этот вопрос все остальные вещи структурируются сами-собо
Это достаточно философское высказывание, с которым сложно спорить. Можно, например, сказать, что нужно начинать не с ответа на вопрос «для чего нашей компании ITSM?», а с ответа на вопрос: «Какие проблемы с обслуживанием есть у нас в ИТ-отделе?»
Ряд книг рекомендует начинать именно с каталога услуг, я солидарен с авторами этих книг.
2) В случае сбоя инфраструктурного сервиса, достаточно завести заявку по инфраструктурному сервису. К этой заявке уже можно привязать все обращения пользователей. Нет никакого смысла насиловать свой хелпдеск необходимостью заводить 40 тикетов по каждому пользовательскому сервису из-за того, что в серверной отключили электроснабжение.
Не совсем понятно, что тут понимается под обращением пользователя с технической точки зрения. Будет допустим тикет на инцидент один. Service Desk тогда будет насиловаться заведение обращений пользователей, они же (обращения) сами по себе в системе не появятся!?
Фиксировать обращения пользователей в виде обращений или инцидентов надо! Это явно рекомендует ITIL.
Фиксировать обращения пользователей в виде обращений или инцидентов надо! Это явно рекомендует ITIL.
Все правильно, но 1 обращение = 1 заявка, а не 1 обращение = 30 заявок по всем затронутым сервисам.
Все правильно, но 1 обращение = 1 заявка, а не 1 обращение = 30 заявок по всем затронутым сервисам.
Так я нигде вроде такого в статье и не писал. Какую услугу в текущий момент не может потребить пользователей, по той и надо заводить инцидент.
Собственно, это и отражено на картинке в статье
Так я нигде вроде такого в статье и не писал. Какую услугу в текущий момент не может потребить пользователей, по той и надо заводить инцидент.
Давайте конкретный пример разберем:
Звонок пользователя: «у меня ничего не работает».
По какой услуге будете заводить заявку?
На мой взгляд, нужно выяснить что конкретно не работает и потом заводить инцидент. Если комп не включается, то услуга «Рабочая станция», если какая-то прога, то выяснить какая вот прям сейчас не запускается и по ней заводить.
Какую услугу в текущий момент не может потребить, по той и заводить.
Какую услугу в текущий момент не может потребить, по той и заводить.
«Почта не получается, из базы выбило, документы не открываются, не могу на принтере распечатать — я же говорю: ничего не работает!» — по какой услуге будете заводить заявку?
В таком случае заводится неклассифицируемая первоначально заявка, если она такая первая вообще, если уже были такие случаи, тогда классифицируется так, как фирме ранее определила класс таких заявок. Если-же это в первый раз, то в дальнейшем, следуя внутренним правилам заводится новый класс — «форс-мажорный». При этом, все, что не работает у юзера включается в эту заявку. Это если выпедндриваться, а обычно в таких случаях тикет заводится на услугу «рабочая станция». Потому как даже услуга «почта» зависит от услуги «рабочая станция», не говоря об услуге «хранилище файлов». :)
На самом деле, коректно выставить затронутый сервис мы можем только после того, как устраним инцидент. Процедура устранения инцидента выглядит следующим образом:
1) Регистрируем заявку со слов пользователя («В 1С ничего не работает!!!111ОдинОдинОдин111!!!!»)
2) Разбираемся что могло случиться у пользователя и локализуем причину инцидента.
3) Устраняем предполагаемую причину.
4) Связываемся с пользователем и уточняем, что теперь все работает.
5) Закрываем заявку, проставляем фактически затронутый сервис и в решении указываем причину инцидента и ее решение. В данном случае затронутым сервисом может быть сервис печати (при том что пользователь жаловался на 1С), а решение будет — «из-за зависания сервера печати пользователь не мог распечатать документ из 1С. Перезапустили сервер печати».
Точно также при закрытии заявки она может быть отнесена к инфраструктурным сервисам (рабочая станция, локальная сеть, сервера), если причиной послужили они.
Далее не только легко считать стоимость владения сервисом и его доступность, но и аргументированно вести диалог с руководством об общей адекватности пользователей и/или их технической подкованности и необходимости обучения.
1) Регистрируем заявку со слов пользователя («В 1С ничего не работает!!!111ОдинОдинОдин111!!!!»)
2) Разбираемся что могло случиться у пользователя и локализуем причину инцидента.
3) Устраняем предполагаемую причину.
4) Связываемся с пользователем и уточняем, что теперь все работает.
5) Закрываем заявку, проставляем фактически затронутый сервис и в решении указываем причину инцидента и ее решение. В данном случае затронутым сервисом может быть сервис печати (при том что пользователь жаловался на 1С), а решение будет — «из-за зависания сервера печати пользователь не мог распечатать документ из 1С. Перезапустили сервер печати».
Точно также при закрытии заявки она может быть отнесена к инфраструктурным сервисам (рабочая станция, локальная сеть, сервера), если причиной послужили они.
Далее не только легко считать стоимость владения сервисом и его доступность, но и аргументированно вести диалог с руководством об общей адекватности пользователей и/или их технической подкованности и необходимости обучения.
Опять же, все логично. Если услуга не поддерживает бизнес-процесс, то она бизнесу не нужна. И в каталоге услуг ей не место.
немного поспорил бы.
Как известно, каталог услуг состоит из двух ключевых элементов — Каталог Услуг для Бизнеса и Технический Каталог Услуг. Так вот, в каталог услуг нужно вносить и то, и другое, а Бизнесу показывать только интересующую его часть(разграничение прав доступа, отличный от общего каталога интерфейс и т.д.).
В такой каталог вносятся как основные услуги(которые видны Бизнесу), так и вспомогательные(без чего услугане сможет функционировать). Помимо этого в каталог услуг так же вносятся дополняющие услуги(делающая услугу более привлекательной для Заказчика).
Поэтому если речь идёт конкретно о Каталоге Услуг для Бизнеса, то не совсем корректно называть его Каталогом Услуг.
По той, которую прямо сейчас хочет, но не может потребить клиент и по внутренней, про которую клиент ничего не знает. В данном случае по услугам: “Услуга 3” и внутренней услуге “Сеть передачи данных”.
Опять поспорю. Изначально инцидент действительно должен заводиться на услугу, видную Бизнес-Пользователям. Однако на первой линии поддержки в рамках диагностики инцидента он должен быть переназначен на конкретную услугу, в которой произошёл сбой. зачастую квалификации ПЛП не достаточно и это происходит на Второй Линии, но это мало меняет дело.
Пойду перечитаю ваши предыдущие статьи, но сложилось ощущение, что начать стоило с построения CMS(или хотя бы CMDB), тогда бы не возникало вопросов, приведённых в заголовке статьи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ITSM. Что мы поняли об услугах