Управление уровнем услуг (Service Level Management, SLM)Цель процесса — управление уровнем сервиса (Service Level Management, SLM), поддерживать и улучшать качество ИТ-услуг с помощью непрерывного цикла согласования, мониторинга и подготовки отчетности о достижениях служб, а также путем стимулирования действий по улучшению качества обслуживания, в соответствии с политикой бизнеса и обоснованием затрат. ОПРЕДЕЛЕНИЯ Требование к уровню услуг (Service level requirements, SLR) детальное описание потребностей заказчика. Может использоваться для разработки SLA Каталог услуг (Service catalog) подробное описание действующих услуг на понятном заказчику языке, а также описание уровней сервисов, которые организация может предложить своим заказчикам Соглашение об уровне услуг (Service level agreement, SLA) соглашение между заказчиком и поставщиком ИТ-услуг, содержащее описание услуг и их метрик, составленное в простых (понятных заказчику, не узко-технических) терминах Программа улучшения сервиса (Service improvement program, SIP) проект, в рамках которого определяются виды деятельности по улучшению качества ИТ-сервисов и их этапы. План обеспечения качества услуг (Service quality plan, SQP) документ в котором установлены параметры обслуживания (например время для разрешения инцидентов), а также определены цели улучшения для каждого процесса. Если SLA определяет «что» мы будем предоставлять, то SQP определяет «как» конкретно мы будем это предоставлять. Операционное соглашение об уровне услуг (Operational level agreement, OLA) - соглашение с внутренним ИТ- подразделением, в котором конкретизируется предоставление определенных элементов сервисов. Внешний договор (Underpinning contract, UC) договор с внешним поставщиком, который определяет предоставление услуг. Качество - совокупность характеристик сервиса, определяющих его возможность удовлетворять оговоренным и ожидаемым требованиям. ИТ сервис - комплекс ИТ решений и деятельности, обеспечивающий реализацию определенных бизнес –процессов. ВИДЫ ДЕЯТЕЛЬНОСТИ Составление каталога услуг Сбор требований к уровню услуг Подготовка и согласование соглашения об уровне услуг Составление и согласование соглашения об уровне услуг Составление программы улучшения сервиса Подготовка программы обеспечения качества услуг Аудит и отчетность ВХОДЫ · Требования к уровню услуг (Service Level Requirements — SLR) ВЫХОДЫ · Каталог услуг (Service Catalog) · Соглашение об уровне услуг(Service Level Agreement — SLA) · Программа улучшения сервиса (Service Improvement Program — SIP) · План обеспечения качества услуг (Service Quality Plan — SQP) · Операционное соглашение об уровне услуг (Operational Level Agreement — OLA) · Внешний договор (Underpinning contract — UC) РОЛИ Менеджер уровня обслуживания организует исполнение процесса и достижение заданных результатов; разрабатывает и обновляет каталог услуг, определяет структуру SLA, заключает OLA, UC, осуществляет ведение переговоров с заказчиком, анализирует качество работы ИТ-организации. 88. Сценарии отношений между информационной системой и бизнесом. Сценарий 1: ИТ-служба — «пожарная команда». К этому сценарию ИТ-служба приходит в условиях, когда бизнес не хочет договариваться с ней. Часто он ее просто не замечает как субъект. Она для него ресурс, который он использует. Если такое использование ИТ-службы бизнесу кажется неэффективным, то виновата в этом, как правило, сама ИТ-служба. Попытка еще больше «закрутить гайки» загоняет всю КИС в более «шоковые условия». Сценарий 2: ИТ-служба — «серый кардинал». Такой сценарий часто возникает при масштабном внедрении ERP-системы в компании, где реально появились лишь фрагментарные бизнес-процессы и вся основная деятельность так и осталась построена на личных отношениях и прецедентах. Удачный запуск системы в эксплуатацию заслуженно приближает руководителя ИТ-службы к первым лицам бизнеса. При этом все руководители бизнес-подразделений обнаруживают новый центр влияния в отношениях, который базируется на «тайном знании» айтшников и «близости» к первым лицам. Иногда это становится сюрпризом и для самих первых лиц. «Серый кардинал», как правило, имеет короткую жизнь и быстро эволюционирует в «пожарную команду». Если бизнес не хочет видеть в ИТ-службе партнера, то ИТ-сервисы в лучшем случае могут завестись в технической поддержке элементов ИТ-инфраструктуры, куда бизнес редко заглядывает. Сценарий 3: ИТ-служба — «центр компетенции». К такому сценарию ИТ-служба часто приходит с масштабным внедрением ERP-системы в компании, в которой бизнес сознательно регламентирует свою основную деятельность зафиксированными бизнес-процессами. В этом случае бизнес получает высокоэффективную КИС, но в то же время и сильную зависимость от высококвалифицированной команды. В сильной интеграции эффективность оплачивается высокой сложностью КИС. Ценой высокой сложности всегда является высокая квалификация тех, кто с этой сложностью умеет работать. Такую команду надо неплохо оплачивать, да еще и удержать. Они на ИТ-рынке нарасхват. Это одна из «скользких» сторон крупных и даже успешных проектов по созданию сильно интегрированных КИС. «Центр компетенции» всегда балансирует на грани с «серым кардиналом». Для того чтобы не сорваться в сценарий № 2, бизнес должен отчетливо понимать те выгоды, которые он получает от внедрения архитектуры сильной интеграции, и те границы, из которых она не должна выйти. Сценарий 4: ИТ-служба — «сервисный центр». Именно этот сценарий идеально ложится на ITIL. Он имеет свои небольшие модификации. В архитектуре слабой интеграции каталог сервисов может четко соответствовать прикладным сервисам (почта, групповая работа, поиск, регистрация документов, согласование, хранение). В «лоскутном одеяле» каталог сервисов выстраивается вокруг бизнес-приложений («лоскутов»). В любом каталоге сервисы должны быть независимы друг от друга. Это принципиально отличает данный сценарий от сценария № 3, где попытка построения каталога сервиса, например, по модулям сильно интегрированной системы приводит к тому, что весь каталог сворачивается в один сервис — доступ к интегрированному приложению. В третьем сценарии 80% инцидентов, связанных с КИС, являются уникальными, такими, которые может понять только небольшая группа специалистов. В то время как ITIL предполагает, что 60 — 70% инцидентов должно разрешаться на уровне Service Desk. Это также цена сложности. Именно в сценарии 4 — сервисного центра — ИТ-сервисы хорошо выносятся на аутсорсинг. 89. Internet-технологии в бизнесе.
|
