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

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

Иерархия ролей (цепочки 'родительская-дочерняя') позволяет упростить управление доступом за счёт наследования прав. Например, родительская роль 'Менеджер отдела' может включать права 'Создание отчётов' и 'Утверждение заявок', а дочерняя 'Старший менеджер' добавляет к ним право 'Контроль бюджета'. При этом дочерняя роль автоматически получает все права родительской. Это избавляет от дублирования настроек, ускоряет назначение сложных ролей и обеспечивает консистентность прав. Иерархия также поддерживает градацию полномочий (например, junior/senior) без необходимости перенастройки базовых прав.

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

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

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

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

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

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

В организациях с географическим распределением матрица функций и процессов может быть использована для эффективного управления ресурсами на разных территориях. Матрица позволяет определить, какие функции участвуют в реализации каких процессов на каждой территории, и соответственно распределять ответственность. Например, начальник определенной функции на каждой из территорий будет отвечать за предоставление ресурсов, необходимых для реализации процессов на своей территории. Его оценка будет строиться на основе процессных метрик подчиненных. В то же время начальник соответствующей функции в HQ будет оцениваться по агрегированным метрикам региональных начальников. Такой подход обеспечивает единообразие управления процессами на всех территориях, позволяет сравнивать эффективность работы по регионам и своевременно выявлять проблемы. При этом все метрики должны быть приведены к сопоставимому виду (шкала от 0 до 1), что позволяет объективно сравнивать результаты различных регионов.