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

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

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

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

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

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

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

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

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

    Добрый день!

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Самое свежее

    • Работать меньше, чтобы сделать больше
      Все, а больше всех инвесторы и спонсоры, хотят, чтобы вся команда работала над новыми задачами, фичами, эпиками не останавливаясь. Тем не менее, несмотря на столь жгучее желание, …
    • Это же не наш профиль…
      Не смотр на то, что на нашем портале мы обсуждаем вопросы ITSM, я хотел бы затронуть тему “котиков”. Многие наверняка скажут: “Причем здесь котики? Это же не ваш профиль”. А какой …
    • Кто такие агенты изменений в продуктовой команде?
      Компании, которым жизненно необходимы частые выпуски изменений программного обеспечения, предпочитают переводить управление ИТ-разработкой в продуктовый подход. В этой статье я не …
    • Обновление Scrum Guide
      18 ноября 2020 года отцы-основатели Scrum Кен Швабер (Ken Schwaber) и Джеф Сазерлэнд (Jeff Sutherland) опубликовали новую версию руководства Scrum (Scrum Guide). Это особенно …
    • Где в ITIL можно почитать про управление техническим долгом?
      Во время вебинара нам поступил вопрос: Есть ли в практиках ITIL разделы\главы, в которых уделяется внимание управлению техдолга? (чтобы почитать)…
    • Технический долг: как бороться с невидимым врагом
      Зачастую о техническом долге говорят, как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и …
    • Он и тебя посчитал
      В своей недавней заметке Олег Скрынник начал диалог на тему диагностики продуктовых команд, как потока. Думая о теме со своей стороны, больше с ракурса уютной внутрикомандной …
    • «DevOps Handboek» — «DevOps для ИТ-менеджеров» на голландском
      Книга Олега Скрынника «DevOps для ИТ-менеджеров» — лучший выбор для тех, кто хочет разобраться в том, что такое DevOps, — вышла на голландском …
    • Диагностика продуктовых команд как поток
      Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали — не суть. Предположим, что …
    • Учёт доступности? А можно как-то попроще?
      На днях, когда я в очередной раз рассказывал про управление доступностью на курсе ITIL PPO, мне задали такой вопрос: «а можно как-то попроще?». Вопрос, в общем-то, …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT