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

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

Чтобы определить, является ли проблема дефектом или частью функциональности, необходимо сравнить поведение системы с документированными требованиями. Если поведение системы отклоняется от зафиксированных требований, это дефект. Если требования не специфицируют конкретное поведение, то возникает область подразумеваемого. В случае продуктового подхода команда должна понимать подразумеваемые требования из контекста и здравого смысла. В модели 'заказчик-исполнитель' важно максимально четко специфицировать требования, так как исполнитель не обязан думать за заказчика.

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

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

Чтобы процесс не остался «бумажным» и не был забыт, необходимо установить чёткие цели и временные рамки для его тестирования, определить конкретный охват (например, отдельные услуги или проекты), и систематически анализировать результаты. Ключевым является постоянное фиксирование учёта всех действий по регламенту, даже если они происходят на бумаге, для демонстрации ценности процесса руководству и участникам. Регулярные проверки прогресса и привязка результатов к измеримым показателям повышают вероятность его дальнейшего внедрения и автоматизации.

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

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

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

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