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

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

При расчете Flow Efficiency возникает вопрос, какое рабочее время учитывать. Если команда состоит из сотрудников с разными графиками работы (например, аналитики в Новосибирске, разработчики в Москве, тестировщик на неполную ставку), возникает сложность выбора календаря. Можно было бы использовать календарь отдельного сотрудника, но в случае совместной работы над задачей это не отражает реальную ситуацию. В результате многие команды прибегают к упрощенным оценкам или договоренностям, которые дают неточные результаты, а не строгий расчет. Это приводит к ситуации, когда формально рассчитанная Flow Efficiency может отличаться от реальной эффективности в несколько раз.

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

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

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

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

В методологии COBIT 5 for Risk влияние риска оценивается по трем составляющим: получение ценности от ИТ (IT Benefit/Value Enablement), исполнение ИТ программ и проектов (IT Programme and Project Delivery) и эксплуатация и предоставление ИТ-услуг (IT Operations and Service Delivery). Для каждого конкретного сценария риска приводится детальное описание того, как негативное событие может повлиять на эти три ключевые области. Такая структурированная оценка позволяет организациям лучше понимать последствия рисков и разрабатывать целевые стратегии их снижения.

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

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