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

Документ об архитектурных и технологических стандартах для разработки новых информационных решений включает следующие аспекты: определение допустимых языков программирования и сред разработки, утверждённых платформ и систем управления базами данных (СУБД), стандарты и протоколы взаимодействия компонентов системы, механизмы развёртывания и настройки локаторов прикладных серверов и middleware, требования к интерфейсу пользователя и администратора системы, стандарты по резервному копированию и восстановлению данных, требования к системам мониторинга и журналирования событий, правила форматирования и хранения логов, возможные ограничения на периоды стабильности системы (freeze периоды), требования к безопасности и аудиту. Такой документ обеспечивает техническую согласованность разрабатываемых решений с существующей инфраструктурой и позволяет избежать использования подходов и технологий, которые создают сложности при эксплуатации или сопровождении системы.

Основные ошибки при применении COBIT 5 PAM заключаются в излишней формализации и концентрации на создании документов, а не на реальном управлении процессами. Многие стремятся просто «заполнить требуемые шаблоны», не задумываясь о смысле и практической пользе. Другая распространенная ошибка — ожидание быстрого результата без учета того, что построение стабильной управленческой надстройки требует времени и постепенных улучшений. Также часто недооценивается роль профессионального суждения оценщика, из-за чего попытки механического следования формальным требованиям приводят к искажению результатов оценки. Важно помнить, что модель предназначена для поддержки управления, а не для создания бумажной волокиты.

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

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

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

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

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

Относительные приоритеты бизнеса учитываются при расчете общего показателя качества через использование весовых коэффициентов. Например, при объединении показателей из различных групп услуг (mission-critical, business-critical и обычные) каждой группе присваивается вес, отражающий ее степень важности для бизнеса. При расчете общего интегрального показателя эти веса учитываются в формуле, например, при вычислении взвешенного среднего арифметического. Если mission-critical услуги имеют вес 0.5, business-critical — 0.3, а обычные — 0.2, то их показатели будут пропорционально учитываться в общем результате. Это позволяет управлять акцентами в оценке и более точно отражать стратегические приоритеты бизнеса.

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