Искусственный интеллект, Интернет вещей, СУБД с обработкой в памяти и другие технологии уже сегодня оказывают значительное влияние на бизнес [1, 2], однако они же стали серьезным вызовом как для бизнес-подразделений, так и для ИТ-службы. С одной стороны, современный рынок требует крайне жестких сроков внедрения новаций, а с другой стороны, бизнес в большинстве случаев лишь приблизительно представляет себе возможности новых технологий. Следствием становятся отсутствие четкого технического задания для ИТ-служб и внешних разработчиков, а также постоянная корректировка требований. Все это происходит на фоне сугубо технических проблем, связанных с внедрением новых технологий, — усложнением технической инфраструктуры, трудностями обеспечения информационной безопасности и др.

Новые технологии несут также огромный потенциал для повышения результативности и экономичности процессов модели ITIL, давая возможность заменять традиционные контакт-центры роботами и чат-ботами, осуществлять интеллектуальную маршрутизацию событий и инцидентов, прогнозную аналитику критически важных объектов инфраструктуры на основе показаний датчиков Интернета вещей, автоматическое заполнение конфигурационной базы данных при помощи радиометок и т. п.

Наконец, эти же технологии непосредственно влияют на масштабы и структуру занятости в ИТ-сфере, приводя к сокращению количества сотрудников низкой квалификации (по крайней мере на 5% в год) при росте спроса на специалистов высокой квалификации; в частности, будет сокращаться число сотрудников контакт-центров.

Таким образом, налицо ситуация, существенно противоречащая стандартам процессов ITIL, построенных в основном по каскадной модели, позволяющей наиболее экономичным способом создать надежный продукт, платя за это необходимостью точного знания требований к создаваемому продукту. В условиях цифровой экономики это практически невыполнимо, что и подтверждает рост популярности таких подходов, как Agile и DevOps, построенных на основе спиральной модели, и интерес к их противопоставлению с ITIL.

Принципы ITIL и их реализация

Основные принципы модели ITIL таковы: ИТ-служба — партнер бизнеса; инструментом, посредством которого ИТ-служба поддерживает потребности бизнеса, является ИТ-услуга; объектом моделирования и стандартизации модели ITIL выступают в первую очередь процессы ИТ-службы; модель ITIL придает особую значимость упреждающему (proactive) управлению. Можно показать, что цифровая трансформация не подвергает эти принципы какому-либо сомнению. Партнерство с бизнесом заметно укрепляется, все чаще ИТ оказывается частью цепи создания новой стоимости, а нередко и ее ключевым звеном. Повысилась роль ИТ-услуг — бизнес уже осознал, что на результаты его деятельности непосредственно влияют именно сервисы, а ИТ-активы важны в той мере, в какой они поддерживают параметры сервисов, необходимые бизнесу. Растет и значимость процессного подхода: процессы ITIL по сути представляют перечень задач, решаемых ИТ-службой в интересах заказчиков, и эти задачи сохраняют свою актуальность. Мало того, структура и функции ИТ-службы могут меняться как за счет внедрения новых технологий, так и за счет перевода тех или иных ИТ-услуг на аутсорсинг, в том числе путем получения их из облака. Наконец, важность упреждающего управления также возрастает. Во-первых, Интернет вещей, искусственный интеллект и другие технологии ведут к усложнению инфраструктуры ИТ, а также предоставлению ее значительной части внешними поставщиками. Во-вторых, выполнение современных требований к времени предоставления услуг, скорости обслуживания, доступности и безопасности практически невозможно без упреждающего анализа и управления. В-третьих, сегодня технологии предлагают качественно новые возможности анализа данных благодаря радиометкам, сенсорам и средствам анализа на основе тех или иных технологий искусственного интеллекта.

Если принципы ITIL остаются вполне актуальными, то почему обсуждается вопрос о кончине этой библиотеки? Тому есть три причины: каскадная модель реализации многих процессов ITIL, чрезмерное внимание процессу стратегического и тактического планирования, высокие требования к стандартизации процессов. Следует подчеркнуть, что все эти причины относятся не к фундаментальным принципам ITIL, а к их практической реализации в версиях 2.0 и 3.0 библиотеки.

Практические рекомендации по реализации процессов ITIL, как правило, следуют каскадной модели. Например, при внесении изменений это означает четкое понимание целей бизнеса, достигаемых изменениями, выявление всех сторон, вовлеченных в изменение, пошаговое планирование изменения для его максимально полного соответствия целям бизнеса, многоступенчатое тестирование и, наконец, развертывание изменения в полном соответствии с планом. Достоинства такого подхода неоспоримы: он позволяет достичь четко определенных и формализованных целей бизнеса с минимальными затратами и рисками. К сожалению, сегодня такой подход уже устарел. Во-первых, заказчик, как правило, туманно представляет цели внедрения новых ИТ. Достаточно древняя система SABRE — первая автоматизированная система бронирования авиабилетов — внедрялась для распределения пакетов авиабилетов между кассами. И уже в ходе ее эксплуатации стало ясно, что при наличии единой базы данных мест на рейсы распределение пакетов не нужно: каждая касса может просто отмечать занятые места в центральной базе. Системы штрихкодов в розничной торговле изначально внедрялись лишь для сокращения числа кассиров, а идея повышения разнообразия продуктов пришла значительно позднее. Естественно ожидать, что потенциал новых технологий и вновь создаваемых на их основе систем также будет раскрыт и осознан не сразу. Во-вторых, если цели и масштабы изменения могут со временем радикально меняться, то развитая система планирования, анализа рисков и тестирования становится препятствием для реализации изменений. В-третьих, новые технологии порождают новые бизнес-модели, с которыми на рынке побеждают молодые компании, поэтому выжидательная тактика несет более серьезный риск, чем внедрение недостаточно протестированного изменения. Все эти факторы обусловливают преимущества спиральной модели, применяемой в Agile и DevOps.

Аналогичные явления можно наблюдать и в процессах эксплуатации ИТ-услуг (IT Service Operation), где сегодня предлагается новый подход к разрешению инцидентов и проблем, основанный на методе гибких рабочих групп (swarming), который позволяет сократить время разрешения относительно простых инцидентов и упростить передачу сложных случаев наиболее квалифицированным специалистам ИТ-службы. Наконец, регулярная ротация сотрудников между различными рабочими группами упрощает распространение знаний среди персонала.

Стратегическое планирование — канонический способ разработки стратегии, и во многих школах разработки стратегии он до сих пор рассматривается как единственно возможный. Между тем многие успешные стратегии японских, американских, европейских и иных компаний создавались не «сверху», а «снизу» как возникающие или спонтанные (emergent) стратегии [3]. Особое значение возникающие стратегии имеют для выявления скрытого спроса или направлений применения новых технологий. Интернет, например, развился из сочетания ряда ситуационных решений — начиная с задачи устойчивости связи в условиях ядерной войны, породившей протокол X.25, и заканчивая задачей хранения данных сложной структуры в ЦЕРН, породившей HTML и HTTP. Можно предположить, что и в Интернете вещей, искусственном интеллекте и других технологиях с высокой вероятностью возникнут аналогичные ситуации. В этих условиях стратегическое планирование, основанное на устаревших знаниях, относящихся к технологиям прошлого поколения, уступает возникающим стратегиям. Но, как показано в [3], реальный спектр подходов к созданию стратегии гораздо шире, и в него входят:

  • предпринимательская стратегия, создаваемая одним лицом или небольшой командой на основе интуиции, понимания рынка и др.;
  • зонтичная стратегия, которая лишь ограничивает спектр возможных стратегий, но не задает жестко ни одну из них;
  • процессная стратегия, задающая лишь процесс разработки и принятия стратегий и допускающая любые стратегии в пределах этого процесса;
  • консенсусная стратегия, объединяющая стратегии участников предприятия;
  • навязанная стратегия, заданная предприятию извне.

Любая из этих стратегий может привести к созданию некой новой стратегии предоставления ИТ-услуг, однако даже в новых книгах ITIL ничего не говорится о применении таких подходов и о том, как вести планирование, преобразование и сопровождение ИТ-услуг при наличии подобных подходов. Характерный пример — зонтичная стратегия, в рамках которой у ИТ-службы может быть несколько стратегий оказания ИТ-услуг, осуществляемых одновременно. Это отнюдь не гипотетический пример, поскольку, владея передовыми технологиями, предприятие может создать венчурное подразделение, которое руководствуется предпринимательской стратегией, тогда как устоявшиеся центры прибыли будут придерживаться прежней стратегии, разработанной в процессе стратегического планирования. При этом в каком-либо региональном подразделении может возникнуть новая спонтанная стратегия, которая должна быть как минимум учтена.

Наконец, формализация бизнес-процессов имеет преимущество при условии, что соответствующие процессы относительно стабильны. Формализация и регламентация требуют значительных ресурсов, а частые изменения процессов ставят под вопрос соотношение затрат и результатов. Регламентация на основе передового опыта также имеет свои пределы, устанавливаемые как минимум «областью определения» самого передового опыта. Таким образом, развитая формализация и регламентация процессов ИТ-службы также могут быть препятствиями для цифровой трансформации предприятия в целом и его ИТ-службы в частности.

Из всего этого вытекает главный недостаток нынешней реализации модели ITIL — она строит процессы ИТ-службы в рамках организационного дизайна, иногда называемого «механистической бюрократией» [4]. В такой конфигурации организационного дизайна координация работников осуществляется посредством формальных правил, единых для всей организации. Такой механизм координации экономичен и обеспечивает низкие затраты при соблюдении необходимых стандартов деятельности и результатов, в том числе и самых строгих. Однако он имеет два серьезных недостатка: крайнюю чувствительность к изменениям внешней среды и стратегии предприятия (которые могут потребовать дорогостоящего и рискованного пересмотра всей системы правил); неспособность конструктивно воспринять возникающие или предпринимательские стратегии, появившиеся в тех или иных подразделениях. Баланс достоинств и недостатков механистической бюрократии для ИТ-службы был явно положителен в 1980-е годы, когда и появилась библиотека ITIL, и остался таковым в 1990-е — первой половине 2000-х, когда библиотека получила широкое распространение. Однако в эпоху цифровой трансформации, требующей быстрого приобретения новых знаний и радикальных перемен как на самом предприятии, так и в его ИТ-службе, эти недостатки ставят под угрозу конкурентоспособность предприятия.

Готовность к изменениям технического задания, спиральная модель разработки, гибкая организация рабочих команд, приоритет неформального общения в команде над формализованными процессами (иначе говоря, Agile и DevOps) позволили преодолеть бюрократизацию, характерную для «классической» реализации процессов ITIL, и обеспечить в сравнительно краткие сроки удовлетворение потребностей пользователей. Однако Agile противоречит «классическому» процессу управления изменениями как минимум в части процесса одобрения изменений и управления релизами.

От организации к технологии и обратно

Во второй половине 1980-х годов, когда создавалась библиотека ITIL, уровень автоматизации ИТ-службы был сравнительно низок. Данные инцидентов и конфигураций собирались преимущественно вручную, разрешение инцидентов осуществлялось путем непосредственного воздействия на предмет или систему, его вызвавшие. Соответственно, и в ИТ-службе было большое количество работников сравнительно низкой квалификации: операторы Service Desk, сотрудники первой линии поддержки и др. Это порождало жесткую централизованную структуру, работающую по формальным правилам, — механистическую бюрократию. Осознание этого факта и разработка рекомендаций по построению адекватной конфигурации ИТ-службы стали большим шагом вперед, обеспечившим популярность идей ITIL в 1990–2000-е годы. Однако процессы автоматизации ИТ-службы не стояли на месте: повышалась степень автоматизации самих процессов, описанных в библиотеке, появлялись средства удаленного мониторинга и управления приложениями, ИТ-инфраструктурой. Виртуализация и облака значительно упростили планирование мощностей ИТ-службы и обеспечили гибкий доступ к мощностям в зависимости от конкретных текущих потребностей предприятия. Наконец, чат-боты стали заменять сотрудников Service Desk, а искусственный интеллект — маршрутизировать значительную часть заявок и т. д.

Переход от «конвейерных» процессов к процессам, полностью автоматизированным, ведет к радикальным изменениям и в организационном дизайне. Задачи, которые ранее решали сотрудники низкой квалификации, теперь поручаются автоматизированным системам. Количество работников резко сокращается, и остаются работники высокой квалификации, способные анализировать и устранять проблемы процесса, а также вносить в него изменения. Если для «конвейерного» процесса жесткие правила исполняли работники, то в автоматизированном процессе эти правила реализуют автоматизированные системы, а работник разрешает лишь редкие нестандартные ситуации. Жестких правил для таких ситуаций быть не может, а следовательно, и квалификация этих работников должна быть на уровне нынешних архитекторов бизнес-процессов и лиц, принимающих решения.

Разнообразие возможных ситуаций требует, чтобы их разрешением занимался не один человек, а команда специалистов различной специализации, что и происходило в 1960–1970-е годы на предприятиях отраслей с непрерывным производством. Например, в нефтепереработке жестко формализованный «конвейер» заменялся небольшими многофункциональными командами квалифицированных работников. Сегодня к этому состоянию приближаются и ИТ-службы предприятий — высокий уровень автоматизации, передача рутинных задач автоматизированным системам, рост доли специалистов высокой квалификации и другие признаки отчетливо наблюдаются в современных ИТ-службах предприятий. Но в этой ситуации устаревают «конвейерные» технологии управления, а с ними и механистическая бюрократия как идеальная некогда форма организации. И снова основные положения Agile и DevOps вполне соответствуют новым реалиям. Следовательно, ITIL либо пройдет соответствующую модернизацию, либо уйдет в прошлое.

***

Итак, ITIL, с одной стороны, и Agile и DevOps, с другой, — это не альтернативные методологии. Agile и DevOps не противоречат принципам ITIL, и их внедрение не означает отказа от ITIL. Более того, DevOps позволяет повысить результативность процессов ITIL. Бережное (Lean) внедрение Agile и DevOps, соответствующее политикам изменений, принятым в ИТ-службе, сегодня является вполне естественным.

Несомненно, ИТ-стратегия необходима предприятию, однако стратегическое планирование — далеко не единственный метод создания работоспособной стратегии. В условиях технологической революции готовых оптимальных решений быть не может, а значит, и поиск единственно верной стратегии смысла не имеет. Более продуктивна «зонтичная» стратегия, описывающая желательные для компании направления развития и ресурсы, выделяемые для этого. В рамках такой стратегии руководители бизнес-подразделений, например, могут выдвигать и защищать собственные технологические инициативы, а ИТ-служба участвует в их оценке, отборе и координации. Важным дополнением такой стратегии становится процесс контроля проектов, позволяющий на возможно более ранней стадии оценить влияние проекта на бизнес. Наконец, ИТ-служба должна быть готова увидеть, оценить и распространить удачное решение, предложенное вне рамок «авторизованных» стратегий.

Литература

  1. The Official Introduction to the ITIL Service Lifecycle: London, The Stationery Office, 2007. — 174 p.
  2. Hall J. ITSM, DevOps, and why three-tier support should be replaced with Swarming [электронный ресурс]. ­URL: https://medium.com/@JonHall_/itsm-devops-and-why-the-three-tier-structure-must-be-replaced-with-swarming-91e76ba22304 (дата обращения: 26.06.2017).
  3. Mintzberg H., Waters J. On Strategies, Deliberate and Emergent [текст] // Strategic Management Journal. — 1985. Vol. 6, No. 3. (Jul. — Sep.). — P. 257–272.
  4. Mintzberg H. Structure in Fives: Designing Effective Organizations: Englewood Cliffs: Prentice Hall, 1993. — 312 p.

Кирилл Скрипкин (k.skripkin@gmail.com) — доцент кафедры экономической информатики, МГУ им. М. В. Ломоносова (Москва).