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

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

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

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

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

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

Правильный подход к разработке KPI в области управления ИТ заключается в построении логической цепочки: Назначение ⇒ ключевые практики ⇒ метрики ⇒ целевые и граничные значения ⇒ KPI. Первый этап подразумевает четкое определение назначения процесса и его роли в организации. На следующем этапе формулируются ключевые практики, необходимые для достижения этого назначения. Затем определяются метрики, которые будут отслеживать выполнение этих практик. Далее устанавливаются целевые и граничные значения для каждой метрики, и только на завершающем этапе формируются KPI на основе всей этой информации. Этот подход противопоставляется попыткам найти готовые KPI в интернете или литературе (например, на kpilibrary.com с более чем 6500 примерами), которые часто не соответствуют конкретным целям и особенностям организации. Главный принцип: KPI должны разрабатываться специально для решения конкретных задач вашей организации, а не браться из общих примеров.

Классический показатель доступности, выражаемый как (AST - DT)/AST, имеет несколько существенных недостатков. Прежде всего, он не учитывает распределение простоев во времени: 9 часов непрерывного простоя в году эквивалентны 9-ти отдельным 1-часовым простоям с точки зрения процентного значения, тогда как бизнес-потери в этих случаях будут сильно различаться. Во-вторых, показатель не отражает влияние на бизнес-процессы, так как процент не показывает реальный ущерб от простоя. В-третьих, возникает неоднозначность при интерпретации: 99,9% может быть интерпретировано как 9 часов простоя в год или как 45 минут в месяц, что не всегда соответствует ожиданиям заказчика и провайдера.

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

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