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

10 самых спорных утверждений ITIL

IT-скептик отвечает на вопрос своей читательницы: "Какие из принципов ITIL Вы считаете самыми спорными?".

Роб привел список из 10 "сомнительных" утверждений, логически вытекающих из написанного в пяти книгах ITIL:

  1. Управление рисками не является отдельной дисциплиной ("процессом") в управлении ИТ-услугами.
  2. Управление проектами не является частью управления услугами
  3. Цель аккумулиривания информации в SKMS и CMS оправдывает средства
  4. Одна из целей управления услугами – это стабильность среды эксплуатации, а изменение является исключением
  5. Предоставление услуг управляет отношениями с заказчиками, а этап приобретения и сборки является поставщиком услуг для Предоставления услуг
  6. Что нельзя измерить, тем нельзя управлять
  7. Удовлетворенность заказчика нельзя точно измерить
  8. Продуктивную среду можно обезопасить
  9. Продуктивную среду можно контролировать
  10. У инцидента есть корневая причина

Скептик предлагает продолжить список, и комментарии к посту тоже представляют интерес.

А все ли пункты кажутся вам дискуссионными?

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

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

  • Леонид

    Таки подискутируем:
    1. «Управление рисками не является отдельной дисциплиной (“процессом”) в управлении ИТ-услугами.» – Управление рисками в том или ином виде присутствует в других процессах, но ведь никто не мешает при желании выделить это в отдельный процесс, некоторые же, например, выделяют в отдельный процесс управление работами.
    2. «Управление проектами не является частью управления услугами» – Вполне себе нормальный подход, как один из возможных.
    3.
    4. «Одна из целей управления услугами — это стабильность среды эксплуатации, а изменение является исключением» – Утверждение действительно сомнительное, но я такого в ITIL не встречал, может что-то и упустил.
    5. «Предоставление услуг управляет отношениями с заказчиками, а этап приобретения и сборки является поставщиком услуг для Предоставления услуг» – Я не очень знаком с ITIL v.3, но если речь идет о связи OLA и UC с SLA, то данное утверждение вполне логично.
    6. «Что нельзя измерить, тем нельзя управлять» – Еще древние греки говорили: «Если человек не знает, куда он плывет, для него не существует попутных ветров». Так что с данным утверждением я согласен.
    7. «Удовлетворенность заказчика нельзя точно измерить» – Есть сомнение в корректности вывода Скептика. Точность может быть достаточной, и таковая возможна, а может быть точность абсолютная, и такую действительно трудно представить по отношению к психологическому состоянию.
    8. «Продуктивную среду можно обезопасить» – Также как и с п.7., достаточная защита возможна и должна быть обеспечена.
    9. «Продуктивную среду можно контролировать» – Аналогично п. 6,7,8.
    10. «У инцидента есть корневая причина» – А разве нет?

  • В данном случае полностью согласен с “сомнительностью” следующих утверждений:

    «Что нельзя измерить, тем нельзя управлять»

    Чувства людей (Любовь, ненависть и т.д.) не подаются измерению, однако эксплуатация этих чувств, позволяет управлять людьми, как бы подло это не звучало.

    «Удовлетворенность заказчика нельзя точно измерить»

    Продолжение предыдущего утверждения, заказчик это прежде всего люди.

    В целом в зависимости от специфики заказчика практически любое утверждение ITIL можно подвергнуть сомнению.

    Есть примеры, когда наличие корневой причины инцидента автоматически переводит инцидент в плоскость управления проблемами. Что подтверждает “сомнительность” 10 пункта, но ведь так бывает не всегда.

  • К пункту 10: около двух лет назад Скептику попалась на глаза статья Ричарда Кука “How complex system fail” (http://www.cleverics.ru/ru/subject-field/hot-issues/how-complex-systems-fail). В своем комментарии Роб написал тогда, что эта статья “заставила [его] полностью пересмотреть свой взгляд на ITSM, в особенности – на анализ корневых причин (Root Cause Analysis), оценку крупных инцидентов (Major Incident Reviews), и управление изменениями (Change Management).”
    Думаю, тезис об отсутствии корневой причины инцидента – оттуда.

    IMHO мы пока что управляем вполне несовершенными системами, и у большинства инцидентов есть корневая причина, причем одна. Однако по мере совершенствования ИТ все большая доля инцидентов будет являться результатом маловероятного стечения маловероятных обстоятельств, а не какой-то одной ошибки. И тогда 10 пункт списка действительно будет все более и более спорным.

  • Странный список. Почему именно эти 10 пунктов, для меня непонятно. В моём хит-параде, например, первой строчкой надолго останется классификация RFC по источнику возникновения “RFC can arise via internet, keyboard or any other source”.

    Представленные 10 пунктов разумеется спорны, в том смысле, что о них надо подумать / поспорить при реализации у конкретного заказчика. В целом:

    а) с утверждениями 1, 8, 9, 10 я скорее согласен (и точно не занёс бы их в TOP 10 спорных утверждений);

    б) утверждения 2-5 целиком зависят от реализации (их бы я в TOP 10 тоже не стал писать, или хотя бы не с такими формулировками);

    в) утверждения 6-7 действительно легко могут быть оспорены. Пункт 6 – потому что измерение только одна из составляющих управления, не единственная и не самая главная (например, дирижер прекрасно управляет своим оркестром, но вряд ли благодаря измерению). Пункт 7 – потому что на практике задачи точного измерения удовлетворённости заказчика я не встречал ни разу. (т.е. странной является сама постановка вопроса). А провести опрос, результаты которого помогут принять правильное решение того или иного вопроса, вполне посильная задача.

    • в) Надо отметить, что дирижер всё-таки измеряет свой объект управления – только инструментом мониторинга у него выступает слух, инструментом бизнес-анализа, прошу прощения – мозг, а бейслайном – ноты на пюпитре. Если что-то пойдет не в соответствии с нотами, он обязательно примет корректирующее воздействие, поверьте музыканту 😉
      Что касается пункта 7 – то, боюсь, имеет место неточный перевод Скептика: он имел в виду, что ITIL где-то пишет, что “нужно и можно точно измерять удовлетворенность заказчика”, но не уточняет как, и какие методы сбора (слух, зрение, обоняние) использовать, и как обрабатывать эти данные.

      • “Надо отметить, что дирижер всё-таки измеряет свой объект управления”

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

        Так вот на практике многие руководители “мечтают” получать отчет с метриками, по которому сразу будет понятно сколько и кого наказывать и поощрять. Т.е., как правило, под измерением понимают не просто возможность выполнять оперативный контроль, а возможность получать объективные данные и даже готовые выводы без личного вовлечения (или с минимальным вовлечением). А многие специалисты вообще считают, что если метрика не считается по данным системы автоматизации, то она субъективна и не пригодна для работы. Поверьте консультанту 😉

        И в этом, более узком, смысле утверждение 6 мне кажется весьма спорным. И оно действительно настолько базовое, что достойно попадания в TOP 10. Может быть единственное из всех приведённых Скептиком.

  • Я бы вот занёс в десятку самых спорных утверждений предложение отделять процесс управления инцидентами от обработки запросов пользователей. Мне кажется, это не только не очень полезно, но и вредно.


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM