Главная Обратная связь

Дисциплины:






Тома Библиотеки: о чем они?



В Библиотеке рассматривается много разнообразных управленческих

процессов, правила их построения, организация их

функционирования и взаимодействия. Для иллюстрации реальной

ситуации рассмотрим жизненный цикл инцидента -

последовательность действий клиента и службы поддержки при

возникновении какой-нибудь нестандартной ситуации в ходе

пользования сервисом:

l клиент связывается с Service Desk - диспетчерской службой,

ответственной за общение с клиентами по всем возникающим

у них вопросам и проблемам и сообщает о проблеме;

l устанавливается связь инцидента с процессом "Управления

инцидентами";

l инцидент учитывается в процессе "Управления проблемами";

при дальнейшем анализе возможны обращения к процессам

"Управления возможностями" и "Управления уровнями

сервиса";

l инициируется процесс "Управления изменениями" для

координации внесения изменений;

l процесс "Управления ИТ-финансами" производит оценку

стоимостей с точки зрения бизнеса;

l процесс "Управление непрерывностью сервисов" участвует в

формировании требуемых изменений для учета возможностей

возврата к предыдущему состоянию при неудачном изменении

и для обеспечения непрерывности предоставления услуг;

l внесение изменений контролируется процессом "Управления

внедрением", несущим ответственность в том числе и за учет

всех произведенных изменений "Управлением

конфигурациями" (предоставляя всю необходимую для этого

информацию);

l процесс "Управление доступностью" обязательно должен

произвести со своей стороны оценку изменений в

оборудовании и программном обеспечении;

l процесс "Управление конфигурациями" должен зафиксировать

действующее состояние (для возможности возврата) и новую

конфигурацию в Базе данных конфигурационных единиц

(CMDB);

l процесс "Управления взаимоотношением с клиентами" должен

поддерживать связь с клиентом для его полного и

своевременного информирования о прогрессе в разрешении

его проблемы.

Как видно, все процессы находятся в тесном, порой нелинейном

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

(или несколько), эффект может не оправдать надежд и скорее

послужит основанием для отрицания идеи в целом. Для исключения

этого предлагается одновременно внедрять все процессы, но не с максимальной полнотой, а на достижимом в реальной ситуации

уровне. В любом случае, даже если нет возможности реализовать

процесс, его необходимо обязательно обозначить (и тем самым

отнести его реализацию на будущие этапы внедрения системы).



Например, можно отметить необходимость организации процессов

"Управление непрерывностью предоставления сервисов" и

"Управления ИТ-финансами" как отдельных, но на какое то время

поручить их реализацию соответственно руководителю всего бизнеса

(управление непрерывностью) и финансовому директору (управление

ИТ-финансами). Понятно, что эти менеджеры в большей степени

ориентированы на несколько иные проблемы, но при определенных

условиях их деятельности может быть вполне достаточно и для

управления ИТ-сервисами.

Нельзя не отметить еще один важный принцип ITIL - отношение к

тем, кто использует в своих целях услуги ИТ. Кто они: пользователи

или потребители? Разница между в следующем: пользователь как

правило использует то, что ему дают и не имеет возможности

попросить то, что ему реально необходимо. Потребитель сам вправе

выбирать и формулировать свои потребности, заключать соглашение

о необходимых уровнях сервисов и требовать их соблюдения. При

рассмотрении всех (и внутренних, и если есть-внешних) клиентов ИТ-

подразделения как потребителей достигается дополнительные

полезные результаты - возможность полного учета реальных

стоимостей услуг и построение универсальной, прозрачной для

контроля, системы управления (не зависящей от конкретного

клиента).

Тем не менее, в томах Библиотеки используется понятие "User" для

выделения в отдельную группу всех, кто использует услуги, и в

другую группу (Customer) - тех, кто фактически заказывает услуги и

платит за них (как правило, высшее руководство соответствующих

подразделений и организаций - клиентов). Отношение к таким

"пользователям" должно быть именно как к "потребителям".

CMDB

CMDB - это централизованное хранилище информации обо всех объектах, управляемых ITIL, и связях между ними. CMDB описывается ITIL, начиная с самой первой версии. Из ITIL 2 было непонятно, является ли CMDB единым физическим хранилищем. В ITIL 3 явно сказано, что не является, кроме тех мест в тексте, где это по-прежнему непонятно. Оценивая любые предложения по внедрению ITIL тщательно изучите планы по развитию CMDB. Скептик настаивает на том, что создать на практике CMDB, описанную в ITIL, за разумные деньги невозможно. Такая работа потребует огромных ресурсов и как следствие - огромных и неоправданных затрат. Те организации, которые стремятся поднять зрелость управления конфигурациями до четвёртого или пятого уровня, вероятно, попытаются проделать эту работу. Остальные остановятся на этапе обоснования затрат. Вот ещё пример: корпоративный самолёт при правильном подходе может, наверное, оправдать связанные с ним инвестиции. Будет ли это оптимальным способом потратить деньги с учётом других вариантов - отдельный вопрос. Надо сказать, что так рассуждает меньшинство. С CMDB связано много споров.





sdamzavas.net - 2020 год. Все права принадлежат их авторам! В случае нарушение авторского права, обращайтесь по форме обратной связи...