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

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

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

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

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

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

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

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

Статическое разделение обязанностей (SSD) и динамическое разделение обязанностей (DSD) в RBAC обе добавляют ограничения в систему, но по-разному. Статическое разделение обязанностей вводит ограничения на уровне назначения ролей пользователям - запрещает назначать определённые комбинации ролей конкретным пользователям. Примером может служить ограничение, при котором пользователь не может одновременно иметь роль, отвечающую за формирование заявок на платежи, и роль, отвечающую за заверение этих платежей. Динамическое разделение обязанностей вводит ограничения в процессе работы пользователя - запрещает одновременное использование определённых ролей в одной сессии, даже если обе роли назначены пользователю. Также динамические ограничения могут зависеть от внешних факторов, таких как время суток, местоположение и другие атрибуты.

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