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

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

Для организации взаимодействия между внутренними ИТ-подразделениями без использования OLA рекомендуется сосредоточиться на построении четких SLA и UC (Underpinning Contracts). Это позволит регулировать внутренние процессы с теми же принципами, что и внешние отношения с заказчиками. Важно определить ответственные области, уровни обязательств и механизмы контроля, но без введения дополнительного слоя терминов и документов (таких как OLA). Такой подход снижает риски излишней бюрократизации и избежит путаницы. Также необходимо пересмотреть организационную структуру для обеспечения эффективной коммуникации и контролю за выполнением обязательств, возможно, через создание централизованного арбитра, но без усложнения терминологии.

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

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

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

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

Искажение восприятия нормы проявляется через ряд характерных признаков: регулярные задержки в релизах программного обеспечения (раз в две-три недели вместо непрерывного развертывания), наличие множества ручных операций там, где должны быть автоматизированные процессы, сложные и неудобные рабочие процедуры (например, вход в корпоративные системы требует множества шагов и специальных настроек), привыкание к высокому проценту дефектов в продукте (от 50% до 70% бэклога), отсутствие реакции на запросы пользователей ИТ-услуг. В таких компаниях часто можно услышать фразы вроде «Мы так привыкли, оно работает, кто сказал, что нужно лучше?».

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

SLA определяет конкретные параметры и условия, при которых услуга считается предоставленной в должном виде. Если в SLA не указаны сроки устранения неполадок или перечень технических средств, которые должны работать, то потребитель может столкнуться с проблемой при попытке требовать ремонта. Наличие детального SLA помогает избежать недоразумений и четко устанавливает, какие ситуации будут считаться инцидентами и каким образом они должны быть устранены