Добрый день, коллеги.
Опыта использования Service Desk в организации не имею, я только начинаю этот путь на базе iTop.
Прочитал книгу по ITIL, несколько статей, блогов в интернете и теперь я в замешательстве.
На данный момент не могу понять для себя следующий момент:
В ITIL сказано:
Запрос на обслуживание - (Эксплуатация услуг) Запрос пользователя на информацию или совет, или на стандартное изменение, или для доступа к ИТ-услуге. Например, чтобы сбросить пароль, или предоставить стандартные ИТ-услуги для нового пользователя. Запросы на обслуживание как правило, обрабатываются в Service Desk и не требуют RFC (request for change), которые будут представлены.
Стандартное изменение – предавторизованное изменение, с низким риском, относительно обычное и следующее какой-либо процедуре или рабочей инструкции. Например, сброс пароля или обеспечение нового сотрудника стандартным оборудованием. Для внедрения стандартных изменений RFC не требуется, они записываются и отслеживаются с использованием другого механизма, такого как запросы на обслуживание.
Так вот, следуя логике ITIL запрос на сброс пароля я должен оформлять в iTop, как запрос на обслуживание:
Я вижу здесь 3 варианта, как мне кажется. Правильных или неправильных я уж не знаю.
Запрос на сброс пароля я всегда оформляю как запрос на обслуживание, т.к. внутри нас эта процедура определена и стандартизирована. А стандартное изменение в iTop в модуле управления изменениями я не трогаю. Вопрос, зачем тогда оно?
Запрос на сброс пароля я оформляю как запрос на обслуживание, т.к. создано стандартное изменение в модуле управления изменениями, где описана процедура, изменение утверждено и одобрено. Я мог бы привязать запрос к изменению, но это можно сделать только тогда, когда изменение не закрыто…
Или, как я встречал в статьях в интернете к запросу на обслуживание стоит относить только консультации, подключение услуги и т.д., а все, что касается стандартных изменений, все-таки создавать запрос на изменение.
Поделитесь, как вы регистрируете стандартные изменения у себя в организации?
Приветствую!
Скажем так, Запрос на обслуживание (ЗНО - Request for …) и Стандартное изменение (Normal Change) - это термины из двух разных дисциплин.
ЗНО - Request for … - это из области Тип Обращения пользователя:
(ITIL Service Operation) Категория, которая
используется для различения поступающих в
службу поддержки пользователей запросов.
Обычные типы обращений – инцидент (Inciendent), запрос на обслуживание (Request) и жалоба (Claim) .
И вот уже после того, как вы категоризировали Обращение пользователя, вы выбираете способ решения, толи через Стандартное изменение, толи через Экстренное
… копнул еще в процесс управления Запросами на обслуживание (Request Fulfilment):
Запрос на обслуживание (service request) –общее обозначение для разнообразных запросов к ИТ департаменту со стороны пользователей
Незначительные (обычно стандартные) изменения
Запросы на информацию
Запросы на консультацию
Запрос на подключение услуги
…
Запросы на обслуживание обычно первоначально обрабатываются службой Service Desk в рамках процесса управления инцидентами
в общем ITIL такой ITIL
т.е. определяющий момент - что ЗНО выполняется Service Desk. Т.е. по хорошему первой линией поддержки (хотя в ITIL опять же нет 100% из чего, каких линий состоит Service Desk)
Если додумывать, то ЗНО решаемый через Незначительные (обычно стандартные) изменения это Change, который регламентирован настолько, что его можно доверить Первой линии.
Что касается нашей организации:
у нас нет отдельного процесс управления запросами. Но есть понятие Запрос от пользователя. Если мы его можем решить - закрываем. Если понимаем, что нужны серьезные согласования/затраты - есть отдельный процесс Change (но без разделения на стандартные и не стандартные)
Спасибо за ответ, стандартное изменение и нормальное изменение - разные вещи, тут именно разговор про стандартное.
Как вариант, да, можно сконфигурировать iTop под simple change и не делить их на нормальные, стандартные, экстренные. Как раз пока склоняюсь к такому упрощенному варианту.
Так вот, если я решаю обращение пользователя через стандартное изменение, значит я создаю запрос на стандартное изменение, а в itil написано:
Возникает какое-то противоречие)
PS: Кстати формулировка понятий взята из книги ITIL 04: Service Operation, ITIL v.3, 2011 edition
Да, с ним нужно быть осторожным)
Нужно помнить, что ITIL не сборник готовых рецептов, а лишь рекомендации. Кроме того, в проф сообществе есть мнение, что он не только бесполезен, но даже вреден, особенно для небольших организаций. Так что во главу угла нужно ставить ваши цели, которых вы хотите достичь с помощью ITIL. У вас же нет цели “внедрить ITIL”. Но наверняка есть что-то типа “снизить кол-во изменений, которые закончились инцидентами” или т.п.
По поводу разницы между запросами и изменениями я придерживаюсь следующей точки зрения:
Запрос на обслуживание инициирует пользователь.
Запрос на изменение инициирует инженер.
Запрос на обслуживание может закончиться изменением с соответствующим запросом.
Запрос на изменение должен заканчиваться
внесением изменений в CMDB.
Отсюда вывод: запрос на обслуживание, это то, что не приводит к изменению конфигурации вашей инфраструктуры и каcается только пользователя. Например, сброс его пароля для какого-то приложения (если, конечно, эти пароли вы не храните в CMDB ))). Если то, что просит пользователь, можно сделать только поменяв конфигурацию, то это изменение.
На счет стандартности изменений:
Думаю, тут имеется ввиду сброс пароля на некой КЕ, который может оказать негативное влияние на услуги. Например, пароль доступа приложения к БД. В этом случает в Стандартном изменении есть описанная и согласованная процедура, при соблюдении которой пароль гарантированно будет изменен не только в сервере БД, но и в приложениях-клиентах.
Запрос на Изменение (RFC) - (ITIL ServiceTransition) Формальное предложение на выполнение изменения. Запрос на изменение включает в себя детали предложенного изменения и может быть записан в бумажном или электронном виде. Термин «запрос на изменение» часто неверно употребляется в значениях «запись об изменении» или «изменение» само по себе.
Думаю, тут дело в этом. В iTop нет разделения на Запрос на изменение и Запись об изменении. Есть просто тикет Изменение, который на начальном этапе может трактоваться как Запрос (детали изменения, лист согласования и т.п.), а после утверждения переходит в Запись об изменении (список затронутых КЕ, услуг).
В случае со Стандартным изменением в iTop этап согласования пропускается.
Запись об изменении - (ITIL ServiceTransition) Запись, содержащая детальную информацию об изменении. Каждая запись об изменении документирует жизненный цикл одного изменения. Запись об изменении создается для каждого полученного запроса на изменение, даже если он впоследствии будет отклонён. Запись об изменении должна ссылаться на конфигурационные единицы, которые затрагивает данное изменение. Записи об изменениях хранятся в системе управления конфигурациями или где-либо ещё в системе управления знаниями по услугам.
Сразу видно, что коллега применяет ITIL на практике и понимает, что все нужно адаптировать и додумывать самому
Я бы еще сюда добавил:
Запрос на обслуживание может заканчиваться внесением изменений в CMDB
Например установка Рабочего места. Если АРМ ведется в CMDB как КЕ, тогда нужно внести изменения.
Я понял, что я не знаю особенностей iTop. И теперь из ваших слов понял, что в нем немного не по ITIL’овски реализованы Запросы на обслуживание и Изменения.
У меня в голове ITIl’овский вариант выглядит следующим образом:
Физически Инцинденты и Запросы на Обслуживание ведутся одинаково в Service Desk и специалистами Service Desk. RFC - отдельный документ (т.е. это не Запись о… а прям отдельный документ)
Для специалистов Service Desk Стандартное Изменение - это Инструкция, набор Чек Боксов - что нужно сделать, чтобы решить Запрос пользователя:
от Пароля до установки АРМ (если оно стандартизировано и передано в Управление Запросами на обслуживание)
Да, на PinkVERIFY они не особенно претендуют))
Вот, попытался изобразить, как работает iTop. Каждый процесс - отдельный модуль iTop, который предоставляет свои типы тикетов.
Добрый день! Подскажите пожалуйста по картинке. Разве можно реализовать данную картинку в itop, я имею ввиду, уже созданный запрос сделать либо инцидентом или запросом на обслуживание? Сам процесс категоризации вроде жестко привязан к запросу или инцеденту. У нас сейчас стоит задача, мы не хотим грузить пользователя, запрос это или инцидент, хотим чтобы для него это был просто запрос. А сервис деск уже сам в зависимости от критериев изменит его на инцидент если нужно, сейчас мы видим только один выход, создать инцидент ручками и привязать к нему запрос.
На картинке может быть не очень понятно, но речи об изменении типа тикета там не идет. Как раз наоборот:[quote=“vladimir, post:9, topic:194”]
Каждый процесс - отдельный модуль iTop, который предоставляет свои типы тикетов.
[/quote]
То есть для пользователя существует только Запрос, дальше которого он не видит. Инциденты и Изменения - отдельные тикеты, которые связаны с первоначальным Запросом, и ход их решения отражается в Запросе пользователя.
Конечно, если в компании пять человек, то им может и не потребоваться несколько типов изменений и разделение на запросы и инциденты. Для таких случаев есть упрощенные версии модулей.
