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

Tmax — это максимальное допустимое время устранения инцидента, после которого нарушение считается просроченным. Tmin — нижняя граница времени, в течение которого простои не оказывают значимого влияния на бизнес. Например, при Tmax = 4 часа и Tmin = 30 минут инцидент, устраненный за 25 минут, не влияет на бизнес, а решение ровно за 4 часа дает минимальный рейтинг, так как близко к критическому пределу.

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

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

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

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

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

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

Термин Service Capacity Management предлагается заменить на System Capacity Management, поскольку понятие «услуга» может быть связано с разными уровнями: бизнес-процессом, ИТ-системой или ресурсом. Если ИТ-услуга определена как обеспечение бизнес-процессов, то управление мощностью должно относиться к бизнесу, а не к услуге как таковой. Аналогично, если услуга ассоциируется с ИТ-системой, то правильнее говорить об управлении мощностью системы, а не услуги.

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