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

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

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

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

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

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

Примерами компаний, иллюстрирующих трансформацию отраслей под влиянием информационных технологий, являются: Uber, который изменил таксомоторную отрасль, создав цифровую платформу для соединения пассажиров и водителей; Netflix, который трансформировал индустрию развлечений от физических носителей к потоковому видео по подписке; Amazon, который превратил розничную торговлю через онлайн-платформу и логистические инновации; Airbnb, который изменил гостиничный бизнес, используя платформу для обмена жильем; Booking.com, который трансформировал туристическую отрасль через цифровую бронирующую систему.

Точное определение уровня зрелости процесса в COBIT невозможно, так как один процесс может демонстрировать признаки сразу нескольких уровней зрелости одновременно. Эта особенность схожа с принципом суперпозиции в квантовой физике, когда система может находиться в нескольких состояниях сразу. Поэтому однозначно определить, на каком уровне зрелости находится процесс, который проявляет черты уровней 2, 3 и 4, невозможно. Существующие методы расчета уровня зрелости, такие как использование весовых коэффициентов, остаются субъективными и зависят от подхода конкретного аудитора.

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

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