Границы здравого смысла при заключении OLA

В редакцию портала поступил вопрос:

Пожалуйста, подскажите по ситуации:

одно из подразделений ИТ-службы крупного банка (процессинг) решило заключить с частью других ИТ-служб OLA соглашение с параметрами качества и сроков предоставляемых услуг.

Насколько это соответствует практикам ITIL и здравому смыслу? Ведь сами параметры сервиса уже описаны в каталогах услуг и других документах ITSM, и, в принципе, процессинг — это части ИТ.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Service Offerings and Agreements

Учебный курс: проектирование и предоставление ИТ-услуг, SLA и SLM, экономика и финансы ИТ, управление поставщиками и подрядчиками — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Артем Мукосеев

    Добрый день!

    Описанная Вами ситуация здравому смыслу и практикам ITIL не противоречит. В данном случае речь идёт о внутренних (поддерживающих) сервисах, предоставляемых одним ИТ-подразделением другому. Подразделению поддержки процессинга важно чётко зафиксировать нормативы на работу подрядчика (другого ИТ-подразделения), чтобы его сотрудники могли более эффективно планировать свою работу с точки зрения качества услуг, которые они предоставляют уже своему заказчику. И при обсуждении параметров SLA с бизнесом, когда им важно обрисовать заказчику имеющиеся у них возможности, и при обработке конкретных заявок, когда им важно понимать, сколько времени у них есть на попытку закрытия таких заявок своими силами.

    Если нормативы на предоставление внутренних услуг для Вашего подразделения уже и так установлены в отдельном документе, то в данном случае речь, видимо, идёт о специальном режиме обслуживания по определённым типам запросов, поступающих от подразделения поддержки процессинга.

  2. Денис Денисов

    На мой взгляд, количество OLA в масштабе всей ИТ-службы должно быть минимальным, а сами Соглашения при этом — действительно уникальными (здесь под ИТ-службой я понимаю организацию с централизованной моделью управления ИТ).

    Просто представьте себе дальнейшее развитие ситуации. На текущий момент одно подразделение ИТ-службы заключило OLA с другими, возможно, наступит момент, когда все подразделения будут связаны OLA друг с другом. Соглашений станет много. Много — это значит, что ими будет трудно управлять: следить за тем, чтобы они не противоречили друг другу, были бы реалистичными с точки зрения технологических возможностей, содержали критерии для измерения и оценки. Добавьте к этому регулярную подготовку и анализ отчётности по каждому OLA.

    А теперь давайте поднимемся на уровень руководителя ИТ-службы. Что он увидит с высоты своего положения? Сможет ли он из многочисленных отчётов по выполнению OLA сделать верные выводы о том, насколько хорошо работает возглавляемое им подразделение? Я думаю, это будет для него непросто из-за большого их количества.

    Что предлагается. Вместо отдельных OLA создавать единые документы — операционные или технологические стандарты по различным областям: серверное оборудование, базы данных, системы хранения данных, каналы и сети передачи данных и т.д. В них описываются различные уровни предоставления технологических возможностей и уровни поддержки / доступности / безопасности / ... Фактически, данные стандарты — это описание текущих возможностей ИТ-службы. Всё, что выходит за их рамки требует детального анализа. И лишь после него, если это действительно требуется, заключение "уникального" OLA.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28