Несмотря на широкое распространение ITIL, есть несколько причин, почему его могут считать устаревшим или не актуальным для современных ИТ-организаций…
Медленная адаптация к современным методологиям
ITIL был разработан в эпоху традиционных подходов к управлению ИТ-услугами и бизнес-процессами. Он полагался на строгую регламентацию процессов, что подходит для стабильных сред, но может быть неэффективным в условиях быстрого развития Agile-методов и DevOps. Эти современные подходы требуют гибкости и быстрой реакции на изменения, что противоречит формализованным процессам ITIL.
Суть традиционного подхода ITIL
ITIL был разработан в 1980-х годах, когда ИТ-инфраструктура представляла собой относительно статичную среду, а процессы предоставления ИТ-услуг были централизованными и строго управляемыми. В рамках этого подхода основное внимание уделялось поддержанию стабильности, прогнозируемости и снижению рисков. Основные принципы предполагали внедрение и соблюдение строгих регламентов для минимизации сбоев в работе ИТ-систем.
Ключевые процессы ITIL, такие как управление инцидентами, изменениями и проблемами, были ориентированы на длинные циклы внедрения и жесткую иерархическую структуру. Это хорошо подходило для больших корпоративных сетей, работающих по регламентированным моделям, где каждая фаза должна была быть тщательно продумана, утверждена и реализована по четкому процессу.
Развитие гибких методологий (Agile, DevOps)
С появлением методологий Agile в начале 2000-х годов стало ясно, что традиционный подход к управлению ИТ-сервисами, основанный на строгих процессах, часто является неэффективным в условиях динамичного рынка и быстро развивающихся технологий. Agile-методологии ориентированы на адаптивность, итеративное развитие и быстрые циклы обратной связи, что позволяет лучше реагировать на изменения требований бизнеса и клиентов.
Agile методологии сосредоточены на быстрой разработке продуктов через короткие спринты, частые поставки и тесное сотрудничество между всеми участниками процесса (разработка, тестирование, эксплуатация). Этот подход прямо противоречит традиционной методологии ITIL, где внедрение изменений требует длительных согласований и утверждений.
Появление DevOps в 2010-х годах еще больше усилило этот разрыв. DevOps — это культурная и методологическая парадигма, которая объединяет разработку (Development) и эксплуатацию (Operations), делая процессы непрерывными, что позволяет реализовывать изменения и обновления более быстрыми итерациями (CI/CD — Continuous Integration and Continuous Deployment). Основная идея DevOps — минимизация времени между разработкой и доставкой продукта в эксплуатацию за счет автоматизации и совместной работы команд.
Противоречие между строгими процессами ITIL и гибкостью Agile/DevOps
Основное противоречие между ITIL и Agile/DevOps заключается в уровне гибкости и скорости реагирования на изменения:
ITIL ориентирован на строгие, предопределенные процессы с четким разделением ролей и ответственностей. Это означает, что любые изменения должны пройти через многоступенчатую систему проверки и утверждения, что замедляет процесс внедрения нововведений.
Agile и DevOps, напротив, требуют гибкости и минимизации барьеров для изменений. Здесь акцент делается на короткие циклы разработки, быструю адаптацию под изменения и тесное сотрудничество между командами.
Это различие особенно заметно в управлении изменениями. В ITIL процесс управления изменениями обычно требует обширного планирования и анализа возможных рисков. В DevOps и Agile культурах изменения могут быть внедрены автоматически и часто (в идеале, несколько раз в день) благодаря автоматизированному тестированию, мониторингу и релизным механизмам.
Медленное обновление ITIL для поддержки гибкости
Несмотря на то что ITIL прошел несколько обновлений (например, ITIL 4 был выпущен в 2019 году), изменения были медленными и недостаточно радикальными, чтобы полностью адаптироваться под современные реалии. ITIL 4 попытался интегрировать некоторые элементы Agile и DevOps, включая концепции потоков создания ценности и непрерывного улучшения, но основная философия осталась сосредоточенной на процессах, а не на людях, коллаборации и гибкости.
Кроме того, ITIL 4 по-прежнему предлагает сложные и многоэтапные процессы для управления изменениями, что не согласуется с философией «fail fast, learn fast» (быстро пробуй и учись) Agile и DevOps, где ошибки рассматриваются как важная часть процесса обучения и улучшения.
1.5. Устаревшие роли и обязанности
ITIL подразумевает наличие четко определенных ролей и обязанностей в рамках управления ИТ-услугами, таких как менеджер по инцидентам, менеджер по изменениям, менеджер по проблемам и т.д. В современных гибких командах DevOps и Agile эти роли размыты, а обязанности распределяются более равномерно между членами команды. Например, в DevOps разработчики несут ответственность не только за написание кода, но и за его развертывание и мониторинг в продакшене.
Строгое распределение ролей создает барьеры для эффективного взаимодействия между разработкой и эксплуатацией, что делает его неактуальным в условиях современной культуры DevOps, где основное внимание уделяется быстроте, коллаборации и автоматизации.
Сложность внедрения изменений в существующих компаниях
Организации, которые уже внедрили ITIL и зависят от его процессов, часто сталкиваются с трудностями при попытке перейти к гибким методологиям. Это связано с тем, что внедрение новых подходов требует полной перестройки культурных и процессных основ компании. Многие компании боятся потери стабильности и контроля при переходе на Agile или DevOps, особенно если их ИТ-инфраструктура является критически важной для бизнеса.
Однако те, кто стремится к инновациям и ускорению бизнес-процессов, часто находят ITIL слишком медленным и неэффективным, предпочитая более динамичные подходы.
1.7. Итог
В результате медленная адаптация ITIL к современным методологиям делает его менее применимым для компаний, стремящихся к гибкости, автоматизации и скорости внедрения изменений. Agile и DevOps предлагают более современные подходы, которые помогают быстрее реагировать на изменения и создавать ценность для бизнеса, что делает традиционные процессы ITIL слишком медленными и бюрократическими для современных ИТ-организаций.
Бюрократизация процессов в ITIL
Одной из наиболее часто упоминаемых причин устаревания ITIL является его склонность к излишней бюрократии и усложнению процессов. Это может замедлять работу ИТ-подразделений, что критически важно для современных компаний, работающих в условиях быстро меняющихся технологий и рынкагде важна скорость принятия решений и внедрения изменений.
Избыточная детализация процессов
ITIL содержит наборы регламентированных процессов для управления всеми аспектами ИТ-услуг, включая управление инцидентами, проблемами, изменениями, конфигурациями и так далее. Эти процессы прописаны очень подробно, с множеством шагов и правил, что создаёт высокую степень формализации и фиксированного подхода к решению задач. Например, для внедрения любого изменения ITIL требует выполнения множества процедур, таких как:
- Оценка рисков изменений.
- Формирование запроса на изменение (RFC).
- Оформление различных отчетов для утверждения изменений.
- Проведение совещаний с комитетом по изменениям (CAB) для рассмотрения и утверждения изменений.
Такие сложные процедуры могут сильно замедлять темп работы в случаях, когда изменения необходимо внести срочно или в условиях Agile-ориентированных команд, где итеративные улучшения и изменения должны происходить быстро и без лишней бюрократии.
Чрезмерное количество документов и согласований
Одним из ключевых аспектов ITIL является документирование каждого шага в процессе управления ИТ-услугами. На практике это приводит к необходимости составления большого объема документации, которая может потребовать много времени на создание и поддержку. Например:
- При регистрации инцидентов важно задокументировать все детали инцидента, его диагностику, шаги решения, а также последующий анализ.
- В случае управления изменениями требуется многократное согласование изменений на всех уровнях, включая инициатора, ответственного менеджера, CAB и другие заинтересованные стороны.
Такая форма организации работы вызывает задержки, так как каждая задача или изменение требуют выполнения строго регламентированных процедур согласования. Например, небольшое исправление ошибки в программном обеспечении может потребовать нескольких дней на формальные процедуры, в то время как его устранение на практике занимает несколько минут. Это снижает оперативность и гибкость работы команды.
Сложность внедрения и поддержания процессов
Для полного внедрения ITIL компании должны обучить персонал, разработать и внедрить процедуры, провести интеграцию процессов с существующими инструментами и системами управления. В крупных организациях это требует значительных временных и финансовых затрат. Более того, поддержание всех этих процессов требует постоянного контроля и периодической оптимизации, что увеличивает административные расходы и нагрузку на ИТ-персонал.
Снижение гибкости и скорости адаптации
Организациям, которые работают в условиях быстрых изменений (например, стартапы или компании, использующие методологии Agile и DevOps), необходимы гибкие подходы к управлению ИТ-сервисами. ITIL же ориентирован на строго регламентированные процессы, которые ограничивают скорость адаптации. Например:
- В условиях DevOps изменения в коде и его развертывание происходят непрерывно и часто в автоматическом режиме. Однако ITIL требует предварительных запросов на изменения, анализа и формальных согласований, что замедляет процесс.
- В Agile-командах решения принимаются на уровне разработки, тестирования и эксплуатации в режиме реального времени, что противоречит бюрократическому подходу ITIL с обязательными комитетами и формализованными документами.
Из-за этих формальностей в ITIL компании сталкиваются с трудностями в быстрой адаптации к изменениям, что особенно критично в условиях жесткой конкуренции и необходимости постоянно улучшать продукт и внедрять новые технологии.
Преувеличенное внимание к контролю вместо результата
Вместо того чтобы сосредотачиваться на быстром решении инцидентов или оперативной доставке изменений, ITIL накладывает чрезмерный контроль на каждый процесс. Например, управление инцидентами предполагает строгую процедуру, состоящую из множества шагов и обязательных согласований, что увеличивает время решения проблемы.
Модернизация, нацеленная на устранение бюрократических ограничений, пришла с выпуском ITIL 4, который пытается интегрировать принципы гибкости и скорости, принятые в Agile и DevOps. Однако многие компании, внедрившие ранние версии, до сих пор сталкиваются с устаревшими бюрократическими процедурами, которые сложно адаптировать к современным требованиям.
Примеры последствий бюрократизации ITIL
Долгие согласования изменений
В компаниях, которые полностью придерживаются ITIL, процесс согласования изменений может занимать значительное время, что задерживает внедрение исправлений и новых функций. Например, в финансовых организациях с высоким уровнем регулирования это может быть оправдано, но в динамично развивающихся стартапах это только снижает скорость.
Задержки при решении инцидентов
Процесс строгого документирования и согласования при решении инцидентов может привести к задержкам в восстановлении работоспособности систем, особенно в случае критических инцидентов, где важна скорость реакции, а не формализация.
Негативное влияние на мотивацию сотрудников
Разработчики и операционные команды могут сталкиваться с фрустрацией из-за необходимости выполнять многочисленные формальные процедуры, что снижает их мотивацию и вовлеченность в процесс работы. Это также может привести к увеличению текучести кадров.
Итог
Избыточная бюрократизация ITIL действительно является одной из его ключевых проблем в контексте современных ИТ-подходов, таких как Agile и DevOps, которые требуют более быстрых и гибких решений. ITIL может быть полезен в организациях с жёсткими требованиями к регулированию и контролю, однако в более динамичных и инновационных средах бюрократический подход ITIL становится препятствием для быстрого реагирования и адаптации.
Ориентация на процессы, а не на ценность
ITIL фокусируется на процессах и контроле, часто упуская из виду главное: создание ценности для бизнеса и клиентов. Современные подходы, такие как Lean и DevOps, больше сосредоточены на потоке создания ценности, минимизации потерь и быстром реагировании на потребности клиентов.
Фокус на выполнении процессов ради процессов
ITIL сосредоточен на стандартизации процессов, таких как управление инцидентами, изменениями, проблемами, уровнем обслуживания и т.д. Важность заключается в четкой последовательности выполнения действий для обеспечения контроля, прозрачности и учета всех этапов работы.
Однако в некоторых случаях организации начинают следовать процессам механически, не обращая внимания на конечный результат или ценность для бизнеса. Когда выполнение регламентов и процедур становится целью само по себе, это может привести к снижению гибкости и адаптивности организации.
Например, в условиях срочного бизнес-запроса, требующего оперативного изменения в инфраструктуре, строгие процессы управления изменениями могут замедлить внедрение обновлений, несмотря на очевидную пользу для бизнеса от их быстрого применения. Таким образом, формализм ITIL иногда идет в ущерб бизнес-целям.
Отсутствие гибкости в изменениях
ITIL требует строгого соблюдения процессов для минимизации рисков и обеспечения устойчивости работы ИТ-систем. Это особенно важно для крупных организаций с тысячами пользователей и сложными системами. Тем не менее, такая жесткость может быть обременительной в условиях быстрой рыночной динамики.
Современные подходы, такие как DevOps, предполагают итеративный подход к изменениям, где внедрение нового функционала происходит быстро и часто. Фокус на создании ценности, а не на строгом следовании процессам, позволяет быстро реагировать на потребности пользователей, адаптироваться к изменениям на рынке и быстро корректировать курс. В ITIL, напротив, каждый этап процесса требует документирования, утверждения и, в некоторых случаях, ожидания, что затрудняет быструю реализацию изменений.
Создание избыточных действий без очевидной ценности
ITIL требует развернутой документации на каждый процесс, особенно в таких областях, как управление изменениями или инцидентами. Это может привести к накоплению избыточных действий и отчетности, которые не всегда имеют непосредственную ценность для клиента или бизнеса.
Например, документирование незначительных изменений, которые не влияют на критическую инфраструктуру, может быть излишне трудозатратным и не приносить видимой выгоды. В результате команды тратят значительное время на административные задачи, которые не способствуют созданию новых продуктов, улучшению пользовательского опыта или сокращению затрат.
Затрудненное создание инноваций
Строгие процессы ITIL, направленные на минимизацию риска, могут быть препятствием для внедрения инноваций. Риски минимизируются за счет сокращения экспериментов и ограничений на внесение изменений, что может противоречить духу инноваций, необходимому для успешного выживания на конкурентных рынках.
В инновационных компаниях создание ценности часто заключается в способности быстро тестировать гипотезы и внедрять новые решения для получения обратной связи от пользователей. Если же компания придерживается ITIL в его классическом виде, это может создать культурный барьер, подавляющий новаторство и склонность к экспериментам.
Необходимость в постоянном мониторинге показателей без оценки реальной бизнес-ценности
Ключевые показатели эффективности (KPI) в ITIL зачастую основаны на выполнении процессов, например, время ответа на инциденты или количество завершенных изменений. Однако такие показатели могут не отражать реальную ценность для бизнеса или пользователей.
Например, можно быстро закрывать инциденты, но если не улучшить общий пользовательский опыт или качество предоставляемого сервиса, это не создаст реальной ценности. Фокус на процессных метриках вместо конечного результата может привести к иллюзии эффективности, тогда как реальная бизнес-ценность остается незамеченной.
ITIL в старых ИТ-архитектурах
ITIL был создан для управления ИТ-услугами в традиционных архитектурах с централизованными серверами, системами хранения и сетевой инфраструктурой. Однако с переходом на облачные технологии, микросервисные архитектуры и контейнеризацию требуется иное управление, ориентированное на автоматизацию, гибкость и скорость изменений.
В облачных средах процессы ITIL могут не всегда быть применимы или требовать значительных модификаций. Например, динамическое масштабирование облачных сервисов или автоматическое исправление ошибок часто противоречат процедурам ITIL, которые требуют предварительных запросов на изменения, утверждений и ручного вмешательства. Эти действия могут быть неэффективными и ненужными в современных инфраструктурах, которые стремятся к автоматизации и снижению человеческого фактора.
Отличие от современных подходов Lean и DevOps
В то время как ITIL фокусируется на управлении процессами, такие подходы, как Lean и DevOps, направлены на создание ценности для конечного пользователя. Lean, например, предполагает оптимизацию всего потока создания ценности, начиная от идеи и заканчивая предоставлением услуги или продукта пользователю.
DevOps стремится к объединению разработки и эксплуатации, чтобы сократить время вывода на рынок и повысить качество за счет непрерывной интеграции и доставки (CI/CD). В этих методологиях процессы не менее важны, но они вторичны по отношению к ценности для пользователя. Главная цель — быстрые результаты, тесное сотрудничество между командами и акцент на оптимизацию потока создания продукта, что часто противоречит более формализованным и раздробленным процессам ITIL.
Итог
Проблема ITIL заключается в его ориентации на процессы, а не на ценность для бизнеса или конечного пользователя. В быстро меняющемся мире технологий, где инновации, скорость и адаптивность важнее формального следования регламентам, ITIL может показаться устаревшим и менее гибким. Современные методологии, такие как Agile, DevOps и Lean, больше сосредоточены на непрерывной оптимизации и повышении ценности для клиента, что делает ITIL менее привлекательным для компаний, которые стремятся к быстрому росту и динамическим изменениям.
Неполное соответствие облачным технологиям и автоматизации
Рассмотрим как рост облачных вычислений и автоматизированных процессов ставит под сомнение эффективность традиционного подхода ITIL.
Изменение архитектуры ИТ-инфраструктуры: от традиционной к облачной
В основе ITIL лежат процессы управления традиционной ИТ-инфраструктурой, состоящей из физической серверной инфраструктуры, локальных сетей, локальных приложений и классических центров обработки данных. Облачные технологии существенно изменили эту парадигму:
Облачная инфраструктура: С переходом на облачные платформы больше не требуется сложное управление физическими серверами, системами хранения данных и сетевыми устройствами. Облачные провайдеры берут на себя управление физической инфраструктурой, предоставляя гибкие ресурсы «по запросу», что уменьшает необходимость в традиционных процессах управления конфигурациями и изменениями, описанных в ITIL.
Самовосстановление и автоскалирование: Облачные платформы имеют встроенные механизмы самовосстановления и автоскалирования. Например, если сервер выходит из строя, система автоматически заменяет его другим экземпляром, без необходимости вручную инициировать инциденты и следовать процедурам восстановления, что прописано в ITIL. Это делает многие процессы, такие как управление инцидентами и доступностью, менее актуальными, так как эти функции уже встроены в сервисы облачных провайдеров.
Автоматизация ИТ-процессов
ITIL предполагает формализованные и структурированные процессы, которые выполняются вручную либо с минимальной автоматизацией. Однако автоматизация в современных облачных средах изменила требования к управлению ИТ-сервисами:
Инфраструктура как код (Infrastructure as Code, IaC): В облачных системах инфраструктура управляется и настраивается с помощью кода (например, с использованием Terraform, AWS CloudFormation). Это полностью меняет подход к управлению изменениями и конфигурациями, делая их более автоматизированными и повторяемыми. ITIL же изначально предполагал ручное управление изменениями, что замедляло процессы и увеличивало вероятность ошибок. С IaC процессы могут быть автоматизированы на 100%, что сводит на нет многие традиционные подходы ITIL.
CI/CD-пайплайны: В рамках современных DevOps-практик используются системы непрерывной интеграции и доставки (CI/CD), которые автоматически тестируют, интегрируют и развертывают изменения в приложениях и инфраструктуре. Это делает процессы управления изменениями ITIL излишне сложными. Традиционная система согласований и ручного управления изменениями уступает место автоматизированным пайплайнам, где изменения проходят через проверенные шаги тестирования и внедрения автоматически.
Облачные SLA и модели ответственности
ITIL включает управление соглашениями об уровне обслуживания (SLA) и доступностью сервисов. В облачных средах эта ответственность во многом делегируется облачным провайдерам:
SLA облачных провайдеров: Облачные провайдеры, как правило, предлагают свои SLA с уже установленными уровнями доступности и надежности. Это значительно упрощает процессы управления доступностью, так как облачные компании предоставляют механизмы резервирования, катастрофоустойчивости и масштабирования «из коробки». В ITIL же большое внимание уделяется детализированному процессу управления доступностью, что становится менее актуальным при использовании облачных сервисов с гарантированным уровнем SLA.
Ответственность за управление инфраструктурой: Облачные провайдеры несут значительную ответственность за физическую инфраструктуру и безопасность на уровне платформы, освобождая компании от выполнения этих задач, что уменьшает значимость процессов управления инфраструктурой в рамках ITIL.
Ускорение инноваций и релизов
Один из главных факторов, по которым ITIL считается устаревшим в облачных средах, заключается в скорости релизов и инноваций, требуемых для современного бизнеса. Облачные платформы и автоматизация позволяют ИТ-командам быстро адаптироваться и внедрять новые сервисы:
Медленные циклы внедрения изменений в ITIL: ITIL ориентирован на строгие процедуры внедрения изменений, которые часто занимают много времени из-за бюрократических процессов, согласований и тестирований. В облачных средах же возможно быстрое внедрение изменений благодаря автоматизированным тестам и развертываниям. Подходы вроде DevOps и CI/CD позволяют сократить время вывода изменений на рынок, а ITIL с его формализованными процессами может стать тормозом для таких инноваций.
Облачные сервисы “как услуга” (SaaS, PaaS, IaaS)
Использование облачных сервисов, таких как программное обеспечение как услуга (SaaS), платформа как услуга (PaaS) и инфраструктура как услуга (IaaS), также снижает необходимость в сложных процессах управления ИТ-сервисами, предписанных ITIL:
Меньше управления инфраструктурой: В случае SaaS и PaaS большая часть операций по поддержке, мониторингу и обновлению выполняется сторонним поставщиком услуг, что уменьшает необходимость управления этими процессами внутри компании. ITIL предполагает более сложные модели поддержки сервисов, что уже не требуется в таких моделях.
Обеспечение безопасности и управления: В облаке безопасность и управление часто делятся между поставщиком и клиентом (shared responsibility model). В результате клиенты управляют только своей частью приложения или данных, тогда как ITIL нацелен на полный контроль за всей инфраструктурой, что не всегда применимо в современных облачных средах.
Итог
ITIL, разработанный для традиционных ИТ-сред, слабо адаптирован для полностью автоматизированных облачных сред, где управление инфраструктурой становится частью сервисов, предоставляемых облачными провайдерами. Облачные технологии и автоматизация, такие как Infrastructure as Code и CI/CD, сделали многие процессы ITIL избыточными, бюрократическими и несовместимыми с требованиями скорости и гибкости современных компаний.
Таким образом, организации, работающие в облачных средах, могут столкнуться с тем, что строгие регламенты ITIL не только замедляют работу, но и становятся препятствием для эффективного управления ИТ-услугами в условиях облачных технологий.
Конкуренция со стороны новых фреймворков
В последние годы появились новые подходы и фреймворки, которые более гибки, адаптивны и ориентированы на быстрое реагирование на изменения в ИТ-среде, чем традиционный ITIL. Эти фреймворки предлагают современные решения, которые лучше соответствуют потребностям компаний, работающих в условиях высокой скорости изменений, интеграции инноваций и облачных технологий. Рассмотрим детально, какие альтернативы конкурируют с ITIL и почему они могут быть предпочтительны.
SRE (Site Reliability Engineering)
SRE — это инженерная дисциплина, разработанная Google для обеспечения надежности, производительности и масштабируемости сервисов. Этот фреймворк существенно отличается от ITIL, и его ключевые преимущества включают:
Гибкость в подходе к изменениям
В отличие от ITIL, где управление изменениями может быть слишком бюрократическим, SRE использует практику контролируемого риска. Это позволяет быстрее внедрять изменения с применением методов автоматизации и мониторинга для минимизации потенциальных рисков.
Чёткая метрика надежности
SRE опирается на такие метрики, как SLA (Service Level Agreement), SLO (Service Level Objective) и SLI (Service Level Indicator), которые помогают более точно определять, насколько сервисы соответствуют ожиданиям по надёжности и доступности. Этот подход даёт лучшее понимание, как измерять успех и прогресс, чем традиционные ITIL-процессы.
DevOps-подход
SRE поддерживает активное взаимодействие между командами разработки и эксплуатации, что сокращает задержки и улучшает качество выпускаемых изменений. В ITIL процессы управления часто разделяют эти роли.
Автоматизация
SRE ставит акцент на автоматизации рутинных процессов, что сокращает вероятность человеческих ошибок и ускоряет выполнение задач. ITIL, хотя и признает важность автоматизации, не так интегрирован с современными DevOps и CI/CD процессами.
DevOps
DevOps — это культура и набор практик, которые объединяют разработку и эксплуатацию для ускорения выпуска программного обеспечения и повышения его качества. Этот подход является одной из самых сильных альтернатив ITIL по нескольким причинам:
Скорость выпуска
DevOps нацелен на то, чтобы сокращать цикл разработки и выпуска продуктов, что делает его более эффективным в условиях высокой конкуренции и быстрых изменений в технологиях.
Интеграция и сотрудничество
В DevOps, в отличие от ITIL, нет строгого разделения на ИТ-службу и разработку. Операционные команды и разработчики работают совместно на всех этапах жизненного цикла продукта, что уменьшает трения и ускоряет решение инцидентов.
Непрерывные улучшения
DevOps внедряет такие практики, как CI/CD (Continuous Integration/Continuous Delivery), которые позволяют постоянно внедрять изменения и новые функции, избегая долгих и сложных процессов согласования изменений, характерных для ITIL.
Акцент на автоматизации и инфраструктуре как коде
В DevOps широко используются такие подходы, как Infrastructure as Code (IaC), что позволяет быстро масштабировать инфраструктуру и вносить изменения автоматически. Это отличается от ITIL, где процессы инфраструктуры описаны в виде стандартных процедур, что может замедлить реакцию на изменения.
SAFe (Scaled Agile Framework)
SAFe — это масштабируемый Agile-фреймворк, который помогает крупным организациям применять гибкие практики, такие как Scrum и Kanban, для работы с большими проектами и программами. Этот подход имеет ряд преимуществ перед ITIL:
Масштабируемость гибких процессов
SAFe позволяет масштабировать Agile-методы на уровне больших организаций и проектов, предоставляя четкие процессы для координации нескольких команд, которые работают над одним проектом. В ITIL акцент делается на процессах и регламентах для отдельных функциональных подразделений, что может замедлить работу в условиях кросс-функционального взаимодействия.
Ориентация на создание ценности
В SAFe больше внимания уделяется созданию продуктов и услуг, которые действительно нужны пользователям, с акцентом на результат, а не на строгое следование процессам. ITIL же ориентирован на обеспечение стабильности и выполнения процессов, даже если это не всегда приводит к быстрому созданию ценности.
Непрерывное улучшение через краткие циклы
SAFe использует спринты и регулярные обратные связи с заказчиками для непрерывного улучшения продукта, что позволяет быстрее реагировать на потребности бизнеса. ITIL, напротив, имеет более длинные и фиксированные циклы процессов улучшения.
Lean IT
Lean IT — это адаптация Lean-философии к ИТ-среде, которая фокусируется на сокращении потерь, повышении эффективности и максимизации создания ценности для клиентов. Основные различия Lean IT от ITIL:
Фокус на устранении потерь
В Lean IT основная цель — устранение всех видов потерь, что может включать неэффективные процессы, задержки в управлении инцидентами и т. д. В ITIL, напротив, существует множество процессов, которые могут сами по себе добавлять дополнительную сложность и неэффективность.
Непрерывное улучшение
Lean IT активно использует циклы PDCA (Plan-Do-Check-Act) для постоянного совершенствования и оптимизации процессов. В ITIL процессы улучшения также существуют, но они менее гибки и зачастую требуют долгосрочного планирования.
Agile
Agile — это набор методов разработки программного обеспечения, которые направлены на быстрое и гибкое реагирование на изменения, что делает его привлекательной альтернативой ITIL:
Гибкость и адаптивность
Agile предлагает минимальные процессы, гибкость и постоянное взаимодействие с клиентами, что позволяет быстро вносить изменения в продукт. ITIL же ориентирован на стабильные процессы и формализованное управление изменениями, что часто затрудняет быструю адаптацию.
Самоорганизующиеся команды
В Agile команды имеют большую степень автономности, что позволяет им быстрее реагировать на проблемы и внедрять улучшения. В ITIL процессы и ответственность строго распределены, что иногда ограничивает возможности для быстрой оптимизации.
Итог
Многие компании, особенно те, которые работают в условиях быстро меняющейся среды и сильной конкуренции, предпочитают переходить на более гибкие и современные фреймворки, такие как DevOps, SRE, SAFe и Lean IT. Эти методы лучше адаптированы к динамичным условиям, автоматизации и кросс-функциональному взаимодействию, чем ITIL. Однако ITIL все еще может оставаться полезным в стабильных, консервативных организациях с медленными изменениями, где приоритетом остаются процессы, а не скорость изменений.
Ограниченная поддержка гибких и кросс-функциональных команд
Одна из ключевых проблем, которая делает ITIL менее подходящим для современных ИТ-команд, заключается в его ориентации на жёсткие структурированные роли и процессы, что слабо сочетается с гибкими и кросс-функциональными командами, популярными в рамках Agile, DevOps и других современных методологий. Рассмотрим подробнее, в чём заключаются ограничения ITIL с этой точки зрения:
Жёсткое разделение ролей
ITIL изначально был спроектирован для организаций с чётко определёнными функциональными отделами. В нём выделяются специфические роли, такие как менеджеры по инцидентам, менеджеры по изменениям, специалисты по проблемам и так далее. Каждая из этих ролей отвечает за конкретные задачи в рамках определённых процессов.
Проблема: в современном мире Agile и DevOps подходов, где роли становятся более гибкими, такое жёсткое разделение функций не всегда эффективно. Команды, ориентированные на DevOps, часто предпочитают подход, при котором один специалист или небольшая группа выполняет несколько функций. Например, разработчики могут одновременно заниматься кодированием, тестированием, и мониторингом в продакшн-среде (так называемая концепция «you build it, you run it»).
Ограничение ITIL: разделение на роли в ITIL, такие как управление изменениями, инцидентами или проблемами, требует строгого соблюдения формальных процедур и взаимодействия между разными отделами, что может замедлить процессы и создать «узкие места» в передаче ответственности между командами.
Отсутствие гибкости в распределении задач
ITIL основывается на процессе управления, где каждое изменение должно пройти через определённые стадии проверки и одобрения. Это требует взаимодействия множества участников для согласования задач, что может замедлять внедрение изменений или восстановление после инцидентов.
Проблема: в кросс-функциональных командах, которые часто работают по Agile- или DevOps-принципам, задачи распределяются в зависимости от актуальной ситуации, а не от жёстко закреплённых ролей. Такие команды стремятся минимизировать количество промежуточных согласований, чтобы быстрее принимать решения и выпускать обновления.
Ограничение ITIL: жёсткая структура процессов ITIL с многочисленными согласованиями и утверждениями может усложнять быструю реакцию на изменения и инциденты. Например, процессы управления изменениями (Change Management) требуют согласования изменений через специальный комитет (CAB), что значительно замедляет процесс в быстро меняющихся средах DevOps.
Ориентация на вертикальные структуры
ITIL традиционно ориентирован на вертикально интегрированные организации, где ИТ-сервисы управляются специализированными командами, каждая из которых занимается своей областью (например, управление серверами, сетью, базами данных и т.д.). Это создает узкие места при необходимости быстрого взаимодействия между разными командами.
Проблема: в современных методологиях (например, в DevOps или Scrum) команды создаются как кросс-функциональные, то есть в них входят специалисты с разными компетенциями (разработчики, тестировщики, операционные инженеры). Такие команды могут полностью отвечать за весь жизненный цикл продукта, включая разработку, тестирование, развертывание и мониторинг.
Ограничение ITIL: вертикальная структура и специализация затрудняют создание кросс-функциональных команд, которые могут самостоятельно принимать решения и управлять сервисами от начала до конца. В итоге это снижает гибкость и эффективность работы в среде, требующей быстрого выпуска и управления изменениями.
Длинные циклы принятия решений
В ITIL принятие решений обычно связано с прохождением через несколько уровней управления. Это особенно касается процессов, таких как управление изменениями (Change Management) или управление инцидентами (Incident Management), где каждая задача должна быть одобрена определённым набором ролей или комитетов.
Проблема: в современных кросс-функциональных командах решения должны приниматься быстро, чтобы минимизировать время на согласование и быстрее реагировать на изменения в коде или инфраструктуре. Agile и DevOps, например, активно используют подходы непрерывного развертывания (Continuous Deployment) и непрерывной интеграции (Continuous Integration), где изменения выпускаются небольшими, частыми итерациями.
Ограничение ITIL: формальные и длительные процессы согласования могут противоречить потребностям гибких команд. Это приводит к задержкам в выпуске новых версий продукта, усложняет внедрение автоматизации и требует большего административного ресурса.
Масштабируемость и управление инновациями
Кросс-функциональные команды часто работают над созданием инноваций и быстрыми итерациями по улучшению продукта. В таких командах важна возможность мгновенного внесения изменений, особенно в облачных средах, где инфраструктура и приложения могут масштабироваться практически мгновенно.
Проблема: подход ITIL, с его ориентацией на регламентированные процессы, может препятствовать внедрению новых технологий и методологий, которые требуют высокой гибкости, таких как автоматизация операций, CI/CD, контейнеризация и микросервисы.
Ограничение ITIL: отсутствие гибкости и склонность к традиционным методам управления усложняют быстрый переход к инновационным технологиям и методологиям. Это также может ограничивать внедрение принципов непрерывного улучшения и быстрых экспериментов, что в условиях современных ИТ-процессов критически важно.
Отсутствие культуры совместной ответственности
ITIL, с его строго определёнными ролями и процессами, способствует культуре, где ответственность за разные части ИТ-инфраструктуры разделена между различными командами. В итоге каждая команда отвечает только за свою часть процесса, а за конечный результат — предоставление услуги — никто не несёт полной ответственности.
Проблема: кросс-функциональные команды, особенно в DevOps, строятся на принципах совместной ответственности. Команды несут полную ответственность за всю цепочку создания ценности — от разработки до эксплуатации. Это позволяет быстрее реагировать на инциденты, внедрять изменения и обеспечивать высокий уровень качества конечного продукта.
Ограничение ITIL: фокус на разделении ответственности между отдельными командами может создавать ситуации, когда проблемы передаются от одного отдела к другому, что увеличивает время на их решение. Совместная ответственность за конечный результат — один из ключевых факторов успеха в гибких методологиях — в ITIL реализована слабо.
Итог
ITIL с его строгим разделением ролей и процессов может быть эффективен для крупных организаций, работающих по традиционным моделям управления, но в быстро меняющихся современных ИТ-средах, где важна гибкость и скорость, такие подходы становятся ограничением. Кросс-функциональные команды, работающие по Agile или DevOps, требуют минимальной бюрократии, возможности быстрой адаптации и совместной ответственности, что не всегда возможно в рамках ITIL.
Фокус на ITSM, а не на продукте
ITIL ориентирован на ITSM (управление ИТ-услугами), тогда как современные компании часто работают по принципам продуктовой разработки, где на переднем плане стоит само приложение или платформа, а не управление инфраструктурой. Это требует других практик и подходов, таких как DevOps, которые объединяют разработку и поддержку в одном цикле.
Парадигма ITSM против продуктового подхода
ITIL изначально был разработан для управления ИТ-услугами (ITSM), что подразумевает управление всей инфраструктурой, включая сети, серверы, базы данных, ПО и поддерживающие службы. В то время как ITSM концентрируется на стабильности, безопасности, доступности и предоставлении услуг в соответствии с бизнес-требованиями, современные ИТ-организации всё чаще переходят на продуктовый подход, который фокусируется на быстрой разработке, выпуске и улучшении самих приложений и сервисов.
Продуктовый подход включает в себя ориентацию на конечного пользователя и предоставление максимальной ценности через функциональные улучшения и быстрые обновления, а не только на поддержку и управление инфраструктурой. Это противоположно традиционному ITSM-подходу, где акцент ставится на предоставлении услуг с минимальными нарушениями, часто за счёт долгих циклов планирования и изменений.
Ориентация на поддержку услуг вместо разработки инноваций
ITIL в своей основе ориентирован на управление операционными аспектами ИТ — обеспечение доступности и стабильности сервисов, управление инцидентами, проблемами, изменениями и т.д. При этом разработка новых продуктов, улучшение функционала приложений и удовлетворение потребностей пользователей зачастую остаются на втором плане. В условиях же продуктового подхода ИТ-услуги — это не просто поддержка, а ядро бизнеса, где ценность создаётся через инновации и разработку.
Современные компании всё чаще рассматривают ИТ не как поддерживающую функцию, а как важнейший инструмент для создания и предложения нового продукта. Это требует ускорения разработки и более тесной интеграции между бизнес-целями и ИТ-стратегией, что традиционные ITIL-процессы могут затруднять из-за их фокуса на операционной эффективности и контроле изменений.
Разрыв между разработкой и эксплуатацией
ITIL, будучи ориентированным на ITSM, предполагает разделение ролей между различными подразделениями: служба поддержки, управление инфраструктурой, управление изменениями и т.д. Такое разделение может привести к «узким местам» в разработке, когда изменения, необходимые для развития продукта, проходят длительный цикл согласований и утверждений через множество процессов. Это сильно отличается от продуктовой разработки, где важна скорость вывода новых функций на рынок и уменьшение времени между идеей и её реализацией.
Модели, такие как DevOps, которые интегрируют разработку и эксплуатацию в одну команду, нацелены на устранение подобных разрывов. Продуктовый подход позволяет разработчикам и операционным инженерам работать вместе для достижения общих целей, что сокращает время реакции на запросы клиентов и увеличивает гибкость в изменении продукта.
Ценность продукта и пользовательский опыт на первом месте
В продуктовом подходе акцент делается на ценность для пользователя, что подразумевает фокус на функциональности, удобстве использования и скорости разработки. В то время как ITSM ориентирован на предоставление стабильно работающей инфраструктуры и устранение инцидентов, продуктовый подход требует более активного внимания к пользователю, его ожиданиям и требованиям.
ITIL предполагает разработку процессов для обеспечения согласованного уровня сервиса, но не всегда гибок в учёте требований, которые динамично меняются. Для современных пользователей важна быстрая реакция на запросы, частые обновления и новые функции, а также улучшение интерфейса и UX. Это может быть сложно реализовать в рамках процессов, которые требуют строгого контроля изменений и долгих циклов согласования.
Продуктовый подход и Agile/DevOps
Современные методологии разработки, такие как Agile и DevOps, идеально сочетаются с продуктовыми подходами. Они предполагают непрерывные улучшения и короткие итерационные циклы разработки, что позволяет быстро выводить на рынок новые функции и реагировать на изменения в требованиях пользователей.
Agile — это методология, которая подразумевает быструю адаптацию к изменениям, постоянные релизы, тесное взаимодействие с пользователями и гибкость в разработке.
DevOps — это подход, который интегрирует разработку и эксплуатацию для улучшения скорости и качества выпуска программного обеспечения, устраняя разрывы между командами и сокращая время от разработки до внедрения продукта.
Эти подходы намного лучше соответствуют современной модели продуктовой разработки, где инновации и изменения играют ключевую роль. В то время как ITIL, несмотря на эволюцию, по-прежнему остаётся более процессно-ориентированным, что затрудняет его интеграцию с Agile и DevOps.
Продукт как платформа для постоянных изменений
Современные ИТ-компании создают продукты, которые являются постоянными платформами для развития и изменений. В этих условиях фокус смещается с управления изменениями на управление продуктом, который постоянно улучшается и обновляется. Это требует постоянной интеграции новых функций, быстрого устранения проблем и постоянной обратной связи с пользователями.
ITIL может ограничивать возможности для быстрого внедрения изменений из-за своего фокуса на стабильности и минимизации рисков. В продуктовых подходах изменения — это неотъемлемая часть процесса, и продукт должен быть готов к их постоянной интеграции.
Итог
Фокус ITIL на ITSM делает его отличным инструментом для управления инфраструктурой и операционными аспектами ИТ. Однако в условиях быстрого технологического прогресса и растущих требований к скорости разработки и вывода на рынок новых функций его можно считать устаревшим для компаний, ориентированных на продукты. Современные ИТ-команды, работающие по Agile и DevOps методологиям, нуждаются в более гибких, динамичных процессах, где продукт и пользовательский опыт ставятся на первое место.
Сравнение подходов ITIL и BPM для управления процессами
Сравнение подходов к процессам ITIL с BPM (Business Process Management) позволяет выявить ключевые различия и сходства между управлением ИТ-услугами и бизнес-процессами, особенно в контексте современных требований к гибкости, эффективности и скорости адаптации изменений.
Фокус на ИТ vs. фокус на бизнес
ITIL: изначально был разработан для управления ИТ-услугами. Его основная цель — это улучшение качества ИТ-сервисов внутри организации, обеспечение их доступности, надежности и предсказуемости. Его подходы сосредоточены на конкретных процессах ИТ-службы, таких как управление инцидентами, изменениями и проблемами.
BPM: BPM, напротив, занимается управлением бизнес-процессами в более широком смысле, охватывая все аспекты деятельности организации — от маркетинга и продаж до производства и управления персоналом. BPM направлен на оптимизацию всех бизнес-процессов для достижения стратегических целей компании.
Сравнение: ITIL можно считать частным случаем BPM, но с фокусом на ИТ-услуги. BPM более гибок и может быть применен ко всем областям бизнеса, тогда как ITIL ограничен ИТ-операциями. В современном мире акцент на BPM стал более предпочтительным, так как он охватывает всю организацию, а не только ИТ-отдел.
Процессная структура
BPM: BPM ориентирован на управление бизнес-процессами с целью их оптимизации и автоматизации. Один из ключевых инструментов BPM — это использование диаграмм и моделей, таких как BPMN (Business Process Model and Notation), для описания процессов, их анализа и дальнейшей оптимизации. BPM стремится к тому, чтобы процессы были как можно более гибкими и легко модифицируемыми.
Сравнение: BPM предоставляет более гибкую структуру, поскольку процессы можно быстро адаптировать к меняющимся условиям. ITIL, напротив, часто ограничен жесткими процедурами, что затрудняет быструю реакцию на изменения. В условиях быстро меняющейся среды BPM лучше соответствует требованиям бизнеса, чем статичные процессы ITIL.
Гибкость и адаптация
ITIL: В ITIL процессы довольно формализованы и регламентированы. Например, для внедрения изменений требуется пройти через процесс управления изменениями, который часто включает несколько уровней согласований и рассмотрений. Это делает подход менее гибким в контексте современного бизнеса, где скорость изменений имеет ключевое значение.
BPM: BPM обеспечивает большую гибкость. Основная идея BPM заключается в постоянном улучшении процессов (например, через циклы PDCA — планирование, выполнение, проверка, корректировка). Процессы легко настраиваются и автоматизируются в зависимости от потребностей бизнеса, что позволяет быстро адаптироваться к изменениям.
Сравнение: В современных условиях BPM предлагает более динамичную модель управления процессами, которая быстрее реагирует на изменения и позволяет организациям оставаться конкурентоспособными. ITIL, напротив, может оказаться слишком ригидным для быстрого реагирования на внешние и внутренние изменения.
Цель управления
ITIL: Основная цель — обеспечение стабильности и надежности ИТ-услуг. Успех измеряется эффективностью выполнения процессов и минимизацией рисков для ИТ-инфраструктуры. Подход сосредоточен больше на внутренней работе ИТ, чем на конечной ценности для бизнеса.
BPM: BPM ориентирован на достижение бизнес-целей через оптимизацию и автоматизацию бизнес-процессов. Ключевой целью BPM является создание дополнительной ценности для организации и её клиентов через повышение эффективности и сокращение затрат.
Сравнение: ITIL ориентирован на процессы и их выполнение, тогда как BPM акцентирует внимание на бизнес-ценности и результатах. BPM лучше отвечает требованиям современного бизнеса, где приоритетом является скорость и максимизация ценности для клиента.
Автоматизация процессов
ITIL: В рамках ITIL автоматизация не является приоритетной. Процессы были разработаны в период, когда управление ИТ-сервисами выполнялось преимущественно вручную, что накладывает свои ограничения. Хотя ITIL может интегрироваться с инструментами автоматизации, такие решения чаще всего вторичны.
BPM: Одной из ключевых целей BPM является автоматизация процессов, что позволяет значительно улучшить их производительность и сократить время выполнения задач. Современные BPM-системы включают инструменты для автоматизации процессов с использованием таких технологий, как RPA (Robotic Process Automation), что помогает исключить ручной труд и ускорить выполнение задач.
Сравнение: BPM больше ориентирован на автоматизацию и улучшение процессов с использованием технологий, в то время как ITIL, особенно в классической своей версии, полагается на ручное управление процессами. Это делает BPM более предпочтительным выбором для компаний, стремящихся к цифровой трансформации и автоматизации своих операций.
Подход к изменению процессов
ITIL: использует процесс управления изменениями, который подразумевает формальное рассмотрение и утверждение каждого изменения в ИТ-среде. Это делается для минимизации рисков, но также может привести к замедлению внедрения изменений.
BPM: В BPM изменения рассматриваются как неотъемлемая часть процесса управления. Модели процессов создаются таким образом, чтобы их было легко изменять и улучшать по мере необходимости. Изменения можно тестировать, моделировать и внедрять с минимальными затратами и рисками.
Сравнение: BPM предлагает более гибкий подход к изменениям, где процессы могут изменяться динамически, что делает его более адаптивным и быстрым по сравнению с ITIL, где каждый шаг изменения требует тщательного рассмотрения.
Итог
Устаревшие подходы ITIL, ориентированные на стабильные и предсказуемые ИТ-процессы, постепенно уступают место более гибким и динамичным подходам, таким как BPM. В то время как ITIL сфокусирован на управлении ИТ-услугами, BPM охватывает всю организацию и ориентирован на создание ценности для бизнеса. BPM обеспечивает гибкость, быструю адаптацию, автоматизацию процессов и оптимизацию всей цепочки создания ценности, что делает его более актуальным в условиях современного бизнеса, где скорость изменений и способность к быстрой адаптации стали ключевыми факторами успеха.
Выводы
ITIL остается полезным для многих организаций, особенно в традиционных отраслях и крупных компаниях с медленными изменениями, но его недостатки в адаптации к современным требованиям могут затруднить его использование в быстро развивающихся средах.
