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

Микросервисная архитектура по-разному влияет на развитие и эксплуатацию программного обеспечения. В части развития она обеспечивает гибкость, возможность раннего прототипирования, тестирования и повышения отказоустойчивости системы. Команды могут быстро внедрять изменения в отдельные сервисы без перезапуска всей системы. Однако в части эксплуатации микросервисы создают дополнительную сложность из-за множества взаимодействующих компонентов, что требует тщательного управления конфигурациями, зависимостями и мониторингом. Без правильных процессов поддержки система может стать неуправляемой, переходя в сложный домен, где диагностика и исправление проблем значительно усложняются и становятся дорогостоящими.

Международные организации, занимающиеся развитием и обменом знаниями в области управления ИТ-услугами и аутсорсингом, включают IAOP (Международную ассоциацию профессионалов в области аутсорсинга, www.iaop.org). Эта организация разрабатывает такие своды знаний как «Outsourcing Professional Body of Knowledge (OPBOK)» — трехсотстраничное руководство по внедрению профессиональных стандартов аутсорсинга, содержащее подробную информацию о разработке, реализации и управлении аутсорсингом, а также многочисленные шаблоны для практического применения. Кроме того, существуют другие своды знаний и стандарты, такие как SIAM Foundation Body of Knowledge и стандарты серии ISO 37500, покрывающие основные этапы и процессы управления аутсорсингом.

Взаимный обмен знаниями между консультантами и заказчиками существенно улучшает результат проекта. Консультанты приносят в проект общий опыт и лучшие практики из своей практики, а заказчики делятся уникальными знаниями о своей организации, её структуре, процессах и особенностях. Это создает полную картину для разработки решения, которое одновременно соответствует отраслевым стандартам и учитывает специфику конкретной организации. В процессе такого обмена обе стороны учатся друг у друга: консультанты получают знания о новых контекстах применения методик, а заказчики углубляют своё понимание подходов к управлению ИТ. В итоге проект приносит не только конкретный результат внедрения, но и повышает общую квалификацию участников с обеих сторон.

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

Помимо оценки загруженности сотрудников, измерение трудозатрат может преследовать цели: понять распределение времени между различными видами деятельности (инциденты, запросы, развитие); выявить узкие места в процессах; оценить эффективность внедрения изменений в процессы; подготовить данные для планирования ресурсов; улучшить качество предоставляемых услуг через анализ времени, затрачиваемого на различные задачи. Главное - четко определить цель измерения перед началом сбора данных.

Для улучшения процесса управления инцидентами с помощью цикла Деминга сначала нужно определить проблему (например, долгие сроки решения инцидентов). На этапе Планируй (Plan) анализируется процесс с использованием инструментов вроде Expanded Incident Lifecycle, выявляются узкие места и разрабатывается гипотеза решения (например, немедленное решение простых инцидентов). На этапе Выполняй (Do) реализуется гипотеза в течение определенного периода. На этапе Проверяй (Check) оценивается эффективность изменений через опросы пользователей и анализ метрик. На этапе Корректируй (Act) принимается решение о дальнейших действиях: если результаты неудовлетворительны, цикл запускается заново с новыми корректировками (разделение персонала на группы для простых и сложных инцидентов), а при успехе улучшения внедряются в постоянную практику.

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

Для измерения результативности процесса управления инцидентами традиционно применяются две основные метрики: доля своевременно решенных инцидентов и среднее время устранения инцидентов. Вторая метрика может анализироваться в разбивке по уровням влияния на бизнес или по приоритету инцидентов, в зависимости от методологии, принятой в организации для определения сроков устранения.

Одного лидера недостаточно для успешного проведения масштабных изменений, особенно в крупных компаниях (от 500 сотрудников), так как преобразования требуют всесторонней и системной поддержки по многим направлениям. Для этого необходима команда или специальный штаб, который будет заниматься координацией изменений, поддерживать флаг лидерства на протяжении всей инициативы, обеспечивать связь между различными стадиями преобразований и отвечать за интеграцию новых практик в организационную культуру. Масштабные изменения затрагивают множество аспектов организации, и управление ими требует распределения ответственности и компетенций.