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

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

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

FTA можно интегрировать в процессы ITIL следующим образом: в рамках Service Design метод помогает выявить потенциальные отказы при проектировании системы, определять требования к компонентам на основе показателей гарантии и отсеивать заведомо ненадежные архитектурные решения; для управления непрерывностью ИТ-услуг (ITSCM) FTA позволяет понять, какие комбинации событий приведут к нарушению доступности критичной функциональности, и подготовиться к ним, определив меры предотвращения или пути быстрого восстановления. При этом анализ помогает установить точные зависимости между сбоями конфигурационных единиц (КЕ) и отказом функциональности, что упрощает расчет целевых показателей восстановления (RTO, RPO) для конкретных КЕ.

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

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

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

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

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

Примером несовместимых разрешений в RBAC может служить ситуация с платежами в банковской системе. Например, разрешение на проведение платежа в сторону контрагента и разрешение на одобрение такого платежа не могут быть назначены одному и тому же сотруднику, так как это нарушает принцип разделения обязанностей. В этом случае создается отдельная роль "Операционист", которая имеет право проводить платежи, и роль "Контролёр", которая может одобрять платежи. Эти роли не могут быть назначены одному и тому же сотруднику одновременно. Аналогичные примеры могут быть в других областях, например, в системе бухгалтерского учета не может быть одного лица, которое одновременно создает документы и утверждает их к оплате.