ИПЗ Управление программными аппаратными средствами. Л12_В10_Дина. Управление Каталогом услуг12
 Скачать 1.44 Mb.
|
|
Л12 Какие процессы входят в Проектирование услуг? " Управление Каталогом услуг12 ". Процесс порождает и поддерживает Каталог услуг, обеспечивая точность содержащейся в нем информации о действующих услугах и услугах, готовящихся к вводу в действие. " Управление уровнем услуг13 ". В этом процессе происходит согласование целей ИТ-услуг с представителями бизнеса. Затем организуется оперативный контроль за предоставляемыми услугами, чтобы гарантировать соответствие их согласованным целям. " Управление мощностями14 ". Процесс обеспечивает своевременное наличие всех мощностей, относящихся к ИТ и соответствующих текущим и будущим потребностям бизнеса. " Управление доступностью15 ". Процесс обеспечивает то, что в каждый момент времени уровень доступности всех услуг точно соответствует текущим и будущим потребностям бизнеса или превосходит их. • " Управление непрерывностью ИТ-услуг16 ". Процесс направлен на то, чтобы работоспособность всего необходимого оборудования (включая компьютерные системы, сети, приложения, репозитории данных, телекоммуникации, среду, техподдержку и службу Service Desk) всегда могла быть восстановлена в согласованные с бизнесом сроки. •Управление информационной безопасностью17 ". Процесс устанавливает уровень ИТ-безопасности, соответствующий уровню бизнес-безопасности, и гарантирует эффективное управление безопасностью во всех услугах и процессах управления услугами. • " Управление поставщиками18 ". Процесс управляет поставщиками и оказываемыми ими услугами, обеспечивая одинаковый уровень качества всех ИТ-услуг для бизнеса. 2. Что такое Каталог услуг? Какова его структура? Каталог услуг представляет собой главный источник информации об ИТ-услугах, предоставляемых организацией - провайдером услуг. Это означает, что все сферы бизнеса могут видеть точную, согласованную картину ИТ-услуг, их описания и статусы. Каталог позволяет потребителю увидеть, какие услуги используются, какие предполагается использовать, какие бизнес-процессы их используют, а также ожидаемый уровень качества услуг. Каждая организация должна разработать и поддерживать политику, относящуюся к содержанию Портфеля и Каталога услуг. Политика должна определять детальность описания и статус каждой услуги. Политика должна также определять ответственности за поддержание каждого раздела Портфеля услуг (т. е. Воронки услуг и Каталога услуг), а также границы и содержание разделов. Часто имеет смысл включать в Каталог услуг иерархию услуг, точно указывая, что за услуга располагается на каждом уровне иерархии (например, "бизнес-услуга", видимая потребителю, или "инфраструктурная услуга"). Инфраструктурные услуги, такие как услуги сети, услуги приложений, хотя и невидимы для потребителя, также должны быть включены в Каталог услуг. Таким образом, иерархии могут содержать потребительские и связанные с ними услуги: поддерживающие, разделяемые и услуги, связанные с предоставлением потребителю физических объектов.  В простейшей форме Каталог услуг может представлять собой матрицу или электронную таблицу. Часто Портфель услуг и Каталог услуг интегрируют в Систему управления конфигурацией. Определяя услуги как Элементы конфигурации и выстраивая их, если нужно, в иерархию, организация получает возможность связывать события, такие как инциденты или запросы на изменение, с услугами, которые эти события затрагивают. 3. В чем состоят назначение, цель и задача процесса "Управление Каталогом услуг? Назначение (purpose) процесса. Процесс должен предоставить единый источник согласованной информации обо всех услугах и обеспечить доступ к нему для всех, кому такой доступ разрешен. Цель (goal) процесса. Процесс должен обеспечить создание и поддержание Каталога услуг, содержащего точную информацию обо всех эксплуатируемых услугах и услугах, готовящихся к запуску в эксплуатацию. Задача (objective) процесса. Обрабатывать информацию, содержащуюся в Каталоге услуг, обеспечивать ее точность для действующих услуг и услуг, готовящихся к запуску в эксплуатацию, в реальной среде. Эта информация включает детальное описание услуги, ее статус, интерфейсы и зависимости от других услуг. 4. Каковы входы, выходы и триггеры процесса "Управление Каталогом услуг"? Источниками информации для процесса служат: • бизнес-стратегия и ИТ-стратегия организации, планы, финансовые планы, данные о текущих и будущих требованиях бизнеса из Портфеля услуг; • данные импакт-анализа, содержащие информацию о влиянии услуг на бизнес, приоритетности услуги и связанных с ней рисках или изменениях требований к услуге; • бизнес-требования: подробности о любых согласованных, новых или изменившихся бизнес-требованиях из Портфеля услуг; • портфель услуг; • система управления конфигурацией; • обратные связи от других процессов. Триггеры процесса22 - это изменения бизнес-требований и услуг. Поэтому главные источники триггеров - это запросы на изменение и процесс "Управление изменениями". Изменения могут заключаться в появлении новых услуг, модификации существующих услуг, удалении услуг. Выходами процесса являются: • документация и соглашение об "определении услуги"; • обновления Портфеля услуг: все услуги должны иметь текущий статус и связанные с ними требования; • Каталог услуг, содержащий для каждой действующей и вводимой в эксплуатацию услуги детальное описание и текущий статус, а также ее интерфейсы и зависимости. 5. Каковы основные активности процесса "Управление Каталогом услуг"? Два основных показателя эффективности процесса: • количество услуг в Каталоге в процентном отношении к общему количеству оказываемых услуг, введенных в эксплуатацию; • число зафиксированных отклонений данных Каталога от существующих в реальности. Примеры других возможных показателей: • осведомленность бизнес-пользователей об оказываемых услугах, т. е. увеличение степени завершенности Каталога бизнес-услуг по отношению к реально реализованным услугам (в процентах); • осведомленность ИТ-персонала о технологиях, поддерживающих услуги: • увеличение степени завершенности Каталога технических услуг по отношению к ИТ-компонентам, поддерживающим услуги (в процентах); • уровень доступности информации для службы Service Desk, измеряемый процентом инцидентов, обработанных без обращения к информации, связанной с услугами. Вопрос к зачету 10 Попытки регламентировать управление ИТ-услугами начались в 80-е годы прошлого века в Великобритании по инициативе правительственного Центрального Агентства по вычислительной технике. В результате была создана, вероятно, самая известная и широко распространенная эталонная модель процессов управления ИТ-услугами, получившая впоследствии название Управление ИТ-услугами (ITSM1) и изложенная в нескольких книгах, составивших так называемую библиотеку ITIL2. После ряда доработок в 2001 году была опубликована вторая версия ITIL, которая стала де-факто стандартом в области управления ИТ-услугами и послужила теоретической основой ряда программных продуктов, предназначенных для автоматизации управления ИТ-услугами. В качестве примеров можно назвать HP ITSM компании Hewlett-Packard, IT Process Model компании IBM, MOF компании Microsoft. Появление и распространение второй версии ITIL (для краткости - ITIL v.2) привело к созданию некоммерческой организации itSMF (от англ. IT Service Management Forum), которая имеет целью распространение идей ITIL, проведение конференций и форумов, организацию обучения ITIL. Книга (itSMF, 2003) стала фактически общепринятым введением в ITIL для начинающих. Дальнейшее изложение ITIL v.2 опирается на эту книгу. Процессная модель ITIL v.2 отличается конкретностью и прагматичностью. Процессы подробно описаны в едином шаблоне, включающем не только перечень активностей, но и блок-схемы, описания ролей и ответственностей, критические факторы успеха, метрики и многое другое. Все описания предельно конкретны и не допускают никаких двусмысленных толкований. Вот, например, как выглядит в (itSMF, 2003) описание задачи процесса "Управление инцидентами" (русский перевод, к сожалению, оставляет желать лучшего): "Задача Процесса Управления Инцидентами является реактивной - уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом обеспечивая наиболее быстрое восстановление работы пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Так как это требует тесного взаимодействия с пользователями, фокусной точкой Процесса Управления Инцидентами обычно является функция Service Desk, которая играет роль центра контактов пользователей с "внутренними" коллективами технических служб. Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры"  Запрос на Обслуживание - это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры. Примеры Запросов на Обслуживание: • вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации; • запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре; • запрос о замене пароля; • запросы на выполнение пакетных заданий, восстановление или авторизацию пароля; • получение информации из базы данных. Для того чтобы можно было отличить "настоящие инциденты" от "инцидентов" - Запросов на Обслуживание, рекомендуется присваивать Запросам на Обслуживание специальную категорию. Важно также отметить, что Запрос на Обслуживание - это не то же самое, что Запрос на Изменение. Запрос на Изменение (RFC4) - это экранная или бумажная форма, используемая для записи детальной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной Единицы (CI5) в ИТ-инфраструктуре или процедуры, или какого-либо иного объекта ИТ-инфраструктуры. Запрос на Изменение считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не инциденты, а изменения". Приведенные фрагменты типичны для книги (itSMF, 2003), где описаны основные процессы ITIL v.2. Они демонстрируют, что ИТ-услуги в ITIL v.2 имеют строго инфраструктурный смысл. ITIL v.3 представляет собой попытку теоретически переосмыслить и максимально обобщить как процессную модель, базирующуюся на понятии услуги, так и область ее применения. Как следствие, на первый план вышли такие вопросы, как природа услуг, связь услуг с целями и стратегией бизнеса, экономика услуг. ITIL v.3 не ограничивается услугами, связанными с управлением существующей инфраструктурой, хотя и включает процессы из ITIL v.2. С точки зрения ITIL v.3, к услугам можно отнести, например, проектирование и разработку приложений, внедрение эффективных процессов управления ИТ, закупку лицензий ПО.   |