Как согласовать репозиторий ITIL и гибкость для управления его инфраструктурами?
Для управления инфраструктурой мы внедрили библиотеку передовой практики ITIL * в OVH, которая является гибкой организацией, используя методы SCRUM в развитии своих услуг. Репозиторий ITIL стал международным обязательством в области управления ИТ-услугами, но его также часто считают тяжелым и, вероятно, задушить организацию, теряя гибкость. Как SCRUM может сочетаться с ITIL? Объединив оба мира, вы получите «Agile Service Management».
Метод Agile основан на трех основных элементах:
При разработке службы вы должны помнить об этих значениях, но как насчет того, когда вы предоставляете услугу? Как смешивать эти гибкие принципы с подходом ITIL?
Давайте сравним эти основные значения с ITIL. Во-первых, ITIL, похоже, уделяет большое внимание процессам и их документации. Для объяснения 26 процессов ITILv4 требуется более тысячи страниц, целью которых является получение качества обслуживания без учета качества взаимодействия между отдельными лицами.
Аналогичным образом договорные соглашения переходят на внутренние соглашения (OLA) и внешние (SLA) соглашения об уровне обслуживания, которые позволяют измерять качество услуг без учета предполагаемого предоставляемого обслуживания.
Кроме того, процессы предсказуемы; они всегда производят одинаковые эффекты в соответствии с тем, что мы вводим. Все этапы четко определены, и ответ на изменения является непреодолимым, поскольку вы не можете отклоняться от того, что написано.
Поэтому априорно существует сильный антагонизм между двумя методологиями. Но будьте осторожны с этим выводом немного поспешным, потому что оба подхода также очень взаимодополняют друг друга.
Фактически, ITIL и SCRUM — это не что иное, как эффективная практика, применяемая соответственно для ИТ-производства и развития ИТ. Действительно, SCRUM — это прежде всего рабочий метод, принципы которого помогают принимать быстрые решения, но не дают никакой системы отсчета. С другой стороны, ITIL предоставляет систему координат через определенные процессы, но не указывает, как выполнить эту работу.
Таким образом, объединение SCRUM и ITIL не является невозможным; мы тогда берем лучшее из обоих миров, полагаясь на первоначальную философию ITIL: «вдохновляйтесь этим методом и применяйте его так, чтобы он был вам лучше всего».
Например, мы реализовали процесс «управления изменениями», чтобы он был текучим и полезным для всех. Хотя мы имеем высокий уровень автоматизации процессов, некоторые операции могут по-прежнему быть ручными из-за их сложности или низкой частоты; поэтому процесс внедрения изменений рассматривается Консультативным советом по изменениям (CAB).
В OVH CAB не является административным органом, который управляет всем. Он распространяется таким образом, что вызов операций выполняется между «знанием». Мы задаем себе классические вопросы, связанные с изменениями, чтобы измерить его подготовку (укомплектование персоналом, время, откат ...) и присущий ему риск. С тех пор изменения отслеживаются, архивируются и передаются изнутри и снаружи через «рабочие» задачи.
Метод Agile основан на трех основных элементах:
- Взаимодействие между людьми
- Важность инструментов
- Непрерывная адаптация к изменениям
При разработке службы вы должны помнить об этих значениях, но как насчет того, когда вы предоставляете услугу? Как смешивать эти гибкие принципы с подходом ITIL?
Давайте сравним эти основные значения с ITIL. Во-первых, ITIL, похоже, уделяет большое внимание процессам и их документации. Для объяснения 26 процессов ITILv4 требуется более тысячи страниц, целью которых является получение качества обслуживания без учета качества взаимодействия между отдельными лицами.
Аналогичным образом договорные соглашения переходят на внутренние соглашения (OLA) и внешние (SLA) соглашения об уровне обслуживания, которые позволяют измерять качество услуг без учета предполагаемого предоставляемого обслуживания.
Кроме того, процессы предсказуемы; они всегда производят одинаковые эффекты в соответствии с тем, что мы вводим. Все этапы четко определены, и ответ на изменения является непреодолимым, поскольку вы не можете отклоняться от того, что написано.
Поэтому априорно существует сильный антагонизм между двумя методологиями. Но будьте осторожны с этим выводом немного поспешным, потому что оба подхода также очень взаимодополняют друг друга.
Фактически, ITIL и SCRUM — это не что иное, как эффективная практика, применяемая соответственно для ИТ-производства и развития ИТ. Действительно, SCRUM — это прежде всего рабочий метод, принципы которого помогают принимать быстрые решения, но не дают никакой системы отсчета. С другой стороны, ITIL предоставляет систему координат через определенные процессы, но не указывает, как выполнить эту работу.
Таким образом, объединение SCRUM и ITIL не является невозможным; мы тогда берем лучшее из обоих миров, полагаясь на первоначальную философию ITIL: «вдохновляйтесь этим методом и применяйте его так, чтобы он был вам лучше всего».
Например, мы реализовали процесс «управления изменениями», чтобы он был текучим и полезным для всех. Хотя мы имеем высокий уровень автоматизации процессов, некоторые операции могут по-прежнему быть ручными из-за их сложности или низкой частоты; поэтому процесс внедрения изменений рассматривается Консультативным советом по изменениям (CAB).
В OVH CAB не является административным органом, который управляет всем. Он распространяется таким образом, что вызов операций выполняется между «знанием». Мы задаем себе классические вопросы, связанные с изменениями, чтобы измерить его подготовку (укомплектование персоналом, время, откат ...) и присущий ему риск. С тех пор изменения отслеживаются, архивируются и передаются изнутри и снаружи через «рабочие» задачи.
