Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от соавторов ITIL 4

Комментариев: 2

  • Артем Мукосеев

    Добрый день!

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

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

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

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

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

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


Добавить комментарий для Артем МукосеевОтменить ответ

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM