Здоровье команды оценивается через итоговый финансовый результат и сбалансированную карту показателей, которые отражают, что общая донесенная ценность не равна нулю. Отдельные процессы (конвейеры развития, исследования) оцениваются своими метриками: lead time, availability, скорость принятия решений. Ключевым является баланс между показателями, чтобы ни одна область (например, «гарантия») не обнулила результат всей команды.

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

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

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

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

Service Backbone в IT4IT представляет собой основную структуру архитектуры, вокруг которой организованы все элементы модели. Это сервисная модель (Service Model), которая охватывает полный жизненный цикл ИТ-услуги - от концепции до предоставления услуги клиенту. Service Backbone состоит из четырех основных потоков (Value Streams): Strategy to Portfolio (S2P), Requirement to Deployment (R2D), Request to Fulfill (R2F) и Detect to Correct (D2C). В терминах ITIL v3 этот Service Backbone соответствует жизненному циклу услуги (Service Lifecycle), который включает фазы стратегия, дизайн, переход, эксплуатация и улучшение. Таким образом, можно сказать, что Service Backbone в IT4IT - это эквивалент концепции жизненного цикла услуги в ITIL, но представленный в более структурированной и потоковой форме, как цепочка создания ценности.

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

В DevOps важно учитывать не только плановую, но и неплановую работу при распределении ресурсов, потому что операционная часть (тот самый 'Ops') требует постоянного внимания к текущим системам и их поддержке. Неплановые задачи, такие как инциденты, исправление дефектов и срочные запросы, являются неотъемлемой частью операционной деятельности и могут возникать в любой момент. Если выделить все ресурсы только на плановую работу, команда не сможет оперативно реагировать на проблемы в эксплуатации, что приведет к снижению надежности системы и удовлетворенности пользователей. Разделение ресурсов позволяет поддерживать баланс между внедрением новых функций и поддержанием стабильности текущих систем.

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

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