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

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

Согласно COBIT, уровни зрелости процессов имеют исключительно иллюстративный смысл. Они используются для наглядного представления текущего состояния процесса или разницы между текущим и целевым состояниями, но не предназначены для точной количественной оценки. Уровень зрелости является побочным продуктом обследования, а не основной метрикой. Его не следует воспринимать чересчур серьезно, поскольку один и тот же процесс может проявлять признаки нескольких уровней зрелости одновременно, и разные аудиторы могут давать разные оценки одному процессу, даже используя одни и те же контрольные показатели.

Культурные барьеры включают сопротивление сотрудникам из-за недоверия к целям учёта (например, восприятие его как инструмента контроля), нежелание тратить время на фиксацию, традиции завышения данных для создания видимости загруженности и установки 'все заняты на 100%'. Например, практика округления времени до 15 минут или игнорирование параллельных задач искажает данные, что делает систему неэффективной. Преодоление требует объяснения пользы учёта для оптимизации процессов, а не наказания.

При проектировании CMDB (базы данных управления конфигурациями) важно фокусироваться не на технических атрибутах конфигурационных единиц, а на том, как информация из CMDB будет использоваться для достижения бизнесовых результатов. Например, менеджерам инцидентов может быть критично видеть связи между серверами, а менеджерам финансов — сортировать конфигурационные единицы по местоположению. Формулировка требований в терминах результатов (например, «мне нужно видеть связи между серверами, чтобы быстрее устранять инциденты») позволяет создать более эффективную структуру CMDB, которая учитывает потребности всех заинтересованных сторон и работает в рамках имеющихся ограничений, а не требует постоянных доработок.

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

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

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

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

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