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

Вопрос из зала: разыскиваются OLA!

Опубликовано 7 февраля 2012
Рубрики: SLA, SLM, BRM, Вопрос из зала, Обо всём на свете
Комментарии

Активный участник обсуждений на нашем портале задал нам вопрос, который, с его согласия, мы хотели бы переадресовать вам, для получения объективной картины мнений:

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

Написали. Согласовали между собой и отдали оформлять приказом. Приказом, чтобы сомнений ни у кого не было, ибо ПЕЧАТЬ на документе. И тут оказалось, что у юристов свой взгляд на проблематику и "в гробу они видали все ваши айтилы-шмайтилы" и что "заключать соглашение о предоставлении услуги между двумя подразделениями логически не верно, потому что есть функциональная ответственность, положения о подразделении и должностные инструкции". Короче, они не сдались даже после того, как мы залочили им интернет под предлогом вирусной атаки.

Собственно вопрос:

А какова действительность в российских и западных компаниях по этому поводу. Можно конечно просто самим договориться, подписать или руки пожать и пойти работать, соблюдая договоренности. Но по-моему это просто создание новых политик в компании. "Делаем так, а так нив коем случае". Смысл аббревиатуры OLA по-моему  не в этом. А вы как считаете?

Итак, кому удалось повидать этого диковинного зверя – OLA – вживую, в естественной среде обитания: поделитесь, пожалуйста, своим опытом в комментариях!

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление уровнем услуг и каталогом услуг
Разработка каталога, SLA, метрик качества, расчёт доступности

Также по теме:

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

  • Павел

    А может просто надо с юристами решить терминологический спор? Не называть документ “Соглашение о предоставлении услуг”, а внести просто изменения в функциональные рамки, положения и должностные инструкции?
    Или эти документы с их точки зрения тоже не подлежат изменению?

    • Вадим

      Для начала надо бы с юристами договориться (как с юридически грамотными людьми), что такое “функциональная ответственность”, какие моменты, связанные с ИТ услугами она подразумевает, какие и как должны быть определены параметры реагирования при отклонении качества услуги от заданных и согласованных параметров ее функционирования.

      P.S. а отключать интернет не следовало. нужно было руководству на стол положить сводку по трафику юристов, разумеется, в рамках ВАШИХ функциональных обязанностей, положений о подразделениях и должностных инструкциях. Можно также запросы от них отрабатывать с учетом отсутствия функциональной ответственности Вашего подразделения перед юротделом.

      А если серьезно, не надо было настолько поднимать статус OLA.

  • Vladimir Kalenov

    Соглашусь с Павлом. С точки зрения юристов название действительно странное. Практически, что бы не вызывать споров, можно назвать документ, например, “Порядок взаимодействия подразделений ИТ-блока в рамках предоставления ИТ-услуг”
    А вообще, по теме OLA в виде приказа:
    “У всех на памяти бурное законотворчество первых лет перестройки. Тогда принимались специальные нормативные акты, направленные на то, чтобы заставить действовать предыдущие законы и подзаконные акты, принятые задолго до перестройки, но так и не заработавшие. Например, и так известно, что по должностным инструкциям, по положению о предприятии заводоуправление обязано обеспечивать цехи работой, а цехи обязаны обеспечить работой бригады, что бригады обязаны выполнять планы и производственные программы. Это очевидно, раз эти люди нанялись на работу и подписали трудовой контракт.” А. Прохоров «Русская модель управления»

    • Vladimir Kalenov

      Был резковат, видимо наболело 🙂
      По теме вопроса: OLA, которое я наблюдал (между бэк-офисом и ИТ) было заключено в режиме жестокого поединка и по правилам “самим договориться, подписать и пойти работать, соблюдая договоренности”. Фактически используется в виде механизма давления на ИТ, т.к. соглашение не оговаривает “финансовой” ответственности сторон.

  • Дмитрий Исайченко

    Согласен, вопрос названия. Примеры названий из жизни: регламент взаимодействия, порядок взаимодействия, операционный регламент, регламент эксплуатации ИС.

  • Олег Скрынник

    Мне кажется, что вопрос был не в названии документа. Понятно, что в обычной компании договоры, соглашения, контракты между структурными подразделениями не подписать – исключение есть только в холдингах и аналогичных структурах, где такие договоры могут быть юридически значимыми.

    Вопрос, похоже, в другом – если OLA не называть соглашением, а называть, скажем, регламентом взаимодействия, то искажается ли смысл понятия OLA?

    На мой взгляд от такого именования документа смысл OLA нисколько не искажается. Это договорённости двух (или более) сторон на определённую тему. Очень хорошо, что они будут зафиксированы на бумаге, с подписями соответствующих руководителей структурных подразделений. Сложность возникает в другом – в определении ответственности за несоблюдение договорённостей.

    В обычном договоре в разделе ответственность можно прописать, например: “не платите – не оказываем услуги”, или “оказываете услуги плохо – будем платить меньше”. Во взаимодействии подразделений в большинстве компаний вопрос оплаты услуг не стоит (за исключением различных форм хозрасчётов, схем отнесения затрат и прочих ЦФО). Как тогда фиксировать ответственность?

    То, что я делал на практике – это использование уже имеющихся механизмов управления в компании. Таковыми могут быть орг.структура (“не соблюдаете регламент? пойдём на разборки к нашему общему шефу”), а также комитеты (“рассмотрим этот конфликт на очередном комитете по ИТ”). Вполне рабочий механизм, не хуже раздела “ответственность” в каком-нибудь договоре.

  • Peshkov Alexander

    Регламент взаимодействия ДИТ и ДИБ например – совершенно необходимая вещь, и ответственность там может быть закреплена строго только в виде схемы эскалации. Такой вполне нормальный и рабочий OLA.

  • Peshkov Alexander

    Более того, не только юристы не поймут, но и любой нормальный человек не поймет. С точки зрения пользы дела назвать документ нужно как можно привычнее и внутри него так же использовать только привычные конструкции. Кстати, утвердить приказом все же хорошая идея, если конечно нет отдельного желания потратить время на гарантированного столкновение с каким-нибудь засранцем, который через месяц сделает вид, что впервые слышит об этом OLA, что он недоработан и неудобен. Тоже накипело. Не надо испытывать судьбу, процессную документацию нужно проводить через ОРД.

  • Александр Жилинский

    Юристам просто лень работать над такой мелочью было, что тут непонятного. “логически не верно” вообще не является ответом )

  • Dmitri Kudryavtsev

    Во вы проблемы подняли, курам на смех, имхо. Это примитивная задача для предприятия с определённым уровнем развития.

    Давайте мыслить логически:
    1) Если в компании хотят разделить ответственность среди исполнителей процесса, значит, в компании понимают, что такое бизнес-процессы, то есть есть СМК. Скорее всего, минимальный сертификат на соответствие ISO 9001 тоже имеется. Это означает кроме всего прочего наличие методиста по СМК, а он уже решает подобные задачи ежедневно, т.к. это часть методики.
    2) Если есть СМК, то наш методолог 1 сделает:
    – описание процесса (и выпустит внутренний стандарт предприятия себе в актив)
    – прикрепит к описанию матрицу разделения функциональной ответственности (по сути это RACI на нашем языке; иначе никак, ибо зафиксировать процесс на бумаге, но не распределить ответственность = получить по шапке на проверочном аудите)
    – проверит в кадрах положения о подразделениях-участниках процесса и найдёт несоответствия там и в своей матрице;
    – капнет в кадры, чтобы те затребовали устранить несоответствия.

    В результате процесс – есть, задокументирован – да, бюрократия предприятия не нарушена – нет. Юристы дальше обрасопливают свои бумаги и все довольны – естественно 🙂

  • Игорь

    Как они к вам, так и вы для них.
    Необходимо напомнить юристам, что соблюдение ГОСТ не зависит от формы собственности. ГОСТ Р ИСО/МЭК 20000 введен 01.07.2011
    Стандарт ИСО/МЭК 20000, под общим наименованием Информационные технологии – Управлениеуслугами, состоит из следующих частей:
    — Часть 1: Спецификация
    — Часть 2: Свод практик
    ГОСТ Р ИСО/МЭК 20000-1 способствует принятию в повседневной практике поставщика комплексного процессного подхода к эффективному предоставлению управляемых услуг, соответствующих требованиям бизнеса и заказчика. Для эффективной работы организации необходимо определить и управлять многочисленными взаимосвязанными видами деятельности.
    Дело не в названии, а в том, что при процессном подходе за конкретные функции отвечает роль(и), которые не описаны в должностных обязанностях. Уровень качества требует выполнения функции по различным метрикам для разных услуг и разных клиентов или даже невыполнения, если не договорились об этом.
    Создание OLA – это лишь часть в одной из многих практик.
    Плодите нужные практики (политики, технические регламенты и пр.)…

    • Pavel Solopov

      Соблюдение требований стандартов не является обязательным по Российскому законодательству.
      Стандарт носит рекомендательный хаарктер, технический регламент – обязательный.

    • Дмитрий Исайченко

      “Как они к вам, так и вы для них.”

      Очень странный ответ. Мне кажется, не очень конструктивный. Но беда даже не в этом, а в том, что стандарт ISO 20000 и 2005 года (обе части) и 2011 года OLA не требует и не рекомендует. Там даже такого названия документа нет. Так что предложенный Вами текст юристов вряд ли в чём-то может убедить.

      • Игорь

        Павел и Дмитрий по своему правы.
        Но как же тогда конкретное содержание разделов 6.1 и 7.3 в 1 части и раздела 6.1.4 во 2 части вышеприведенного ГОСТа. Для решения проблемы на уровне юристов мне бы хватило. Может это тоже “странное” прочтение ГОСТа?

        • Дмитрий Исайченко

          У меня нет текста ГОСТа, но я знаю, что готовился он методом “аутентичного перевода” соответствующих частей ISO. Поэтому я смотрел ISO 20000:2005. Ни в одном разделе нет упоминания документа OLA. А юристы, судя по вопросу, против не самого факта регламентации, а против её формы – соглашения о предоставлении услуг между внутренними подразделениями. Именно поэтому я и предлагал выбрать другое название для документа, и даже предложил 3 варианта, которые встречал в жизни.

          • Игорь

            Текст ГОСТа я взял на ITSMF. Название п.6.1.4 “Соглашение о вспомогательных услугах”. Требование имеет внешнее и внутреннее хождение. Строго названия “соглашение операционного уровня” (OLA) в ГОСТе нет. Цель у нас одна: обеспечить установленный уровень качества. Не принципиально название внутреннего документа. Решение использовать административную форму (приказ) не самое результативное. Лучше создавать нормативные документы (внутренние стандарты, политики, порядки, регламенты и пр.)

            • Константин Нарыжный

              Игорь, но вторая часть – она же не требовательная, а рекомендательная? То есть “поддерживающее соглашение” за “требование” перед юристами получится выдать ммм на очень короткий срок;)

  • Игорь

    Много лет назад я более 9 лет работал в структурах, где требование ГОСТов по СВТ (средства вычислительной техники, т.е. то, что было до IT) были неоспоримы. Поэтому я сохранил веру в то, что этот подход имеет более высокий приоритет, чем юридические нормы и чиновничий беспредел. Конечно, сейчас я более убедителен (опыт и практика, аварии и катастрофы), но молодому поколению гораздо труднее. Сейчас любые ГОСТы, даже обязательные не соблюдаются. Причина в остаточном финансировании требований. Зачем? Ведь все и так работает!
    В бюджетных организациях ситуация хуже, но коммерческие с убытками борются. Нельзя позволять юристам отрабатывать их “хлеб” в ущерб основным источникам, которые повышают эффективности от использования ИТ.
    Вырабатывайте навыки убеждения.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.