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

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

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

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

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

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

Автоматическое персональное назначение задач может быть эффективным только в простых сценариях работы с одинаковыми сотрудниками и потоком однотипных задач. Хороший пример – маршрутизация звонков в колл-центре, где сотрудники обладают практически одинаковой квалификацией, а задачи (звонки) имеют схожую сложность. Во всех других случаях, особенно когда задачи разнообразны по сложности или сотрудники имеют различную специализацию и компетенции, автоматизация может привести к обратному эффекту – увеличению времени обработки за счет неправильного распределения.

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

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

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