Для создания системы стандартов оценки эффективности работы в гибкой команде необходимо сначала определить, что организация считает нормальной работой. Это включает установление допустимого уровня дефектов (например, не 15-50%, как часто ошибочно считают, а гораздо ниже), определение эффективного использования трудовых ресурсов (чтобы не было ситуации, когда до 80% ресурсов расходуется впустую), создание четких стандартов постановки запросов от бизнеса, чтобы все задачи в бэклоге несли бизнес-ценность. Также необходимы KPI для оценки производительности и качества работы. Эти стандарты должны быть согласованы со всеми заинтересованными сторонами и понятны всем сотрудникам. Важно регулярно пересматривать и обновлять стандарты по мере развития бизнеса и изменений в ИТ-ландшафте. Соблюдение этих стандартов должно стать частью корпоративной культуры и оцениваться в рамках системы мотивации.

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

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

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

Розабет Кантер, профессор Гарвардской школы бизнеса, определила три ключевых класса инструментов влияния: 1) Информация — данные, технические знания, экспертиза, знание политической ситуации; 2) Ресурсы — финансовые средства, материальные активы, человеческие ресурсы, время; 3) Поддержка — подтверждение, легитимность, одобрение, защита. Эффективное использование всех трех классов инструментов позволяет сформировать коалицию поддержки изменений и построить процесс внедрения так, чтобы сотрудники воспринимали изменения как свои собственные.

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

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

В ITIL за разные аспекты процесса отвечают следующие роли: 1. Дизайнер (технолог/проектировщик процессов): определяет назначение процесса – его базовую функцию в общей процессной модели. 2. Владелец процесса: формирует и актуализирует цели процесса в формате SMART, привязанные к конкретным периодам времени. 3. Менеджер процесса: определяет задачи процесса, обеспечивающие выполнение назначения и достижение целей, и отвечает за оперативное управление процессом. Каждая роль фокусируется на своём уровне детализации: дизайнер на стратегическом, владелец на тактическом, менеджер на оперативном.

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

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