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

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

Матрично-иерархическая структура в классификаторе изменений применяется следующим образом: Сначала устанавливается иерархия категорий изменений: - На верхнем уровне разделяются стандартные и нестандартные изменения - Далее по критериям риска, типа объекта (ИТ-инфраструктура, информационные системы, сети) - Иерархия продолжается до уровня конкретных типов или групп систем Затем формируется матрица параметров для каждой категории: - Для каждой группы систем или направлений определяются свои наборы параметров - Параметры включают: ответственных за координацию, уполномоченных на согласование, обязательные результаты этапов - Набор опциональных этапов для конкретной группы систем Особенность применения такой структуры: - Для ИТ-инфраструктуры может быть определен общий типовой порядок с опциональными этапами для работ в боевой среде - Для информационных систем — мастер-порядок с обязательным приёмочным тестированием - Для разных групп информационных систем (например, критически важных) — дополнительные этапы оценки влияния Как пример конкретной реализации: - Категория «Стандартные изменения для серверной инфраструктуры»: * Общие этапы: запрос, техническое согласование, выполнение, подтверждение * Параметры: ответственный координатор — администратор соответствующего направления, срок выполнения — не более 2 часов * Специфика: не требуется приёмочное тестирование, так как работы выполняются в режиме реального времени - Категория «Изменения для критически важных информационных систем»: * Общие этапы: запрос, анализ влияния, утверждение комитета, планирование, тестирование, выполнение, подтверждение * Параметры: ответственный координатор — старший сотрудник, срок планирования — минимум 5 рабочих дней * Специфика: обязательное приёмочное тестирование в выделенной среде Этот подход позволяет значительно сократить количество уникальных моделей, оставаясь при этом достаточно гибким для учета специфики различных систем и направлений.

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

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

Для приближения к идеальному сценарию рекомендуется использовать: искусственный интеллект для анализа кратких отзывов и выявления ключевых паттернов; системы персонализированного вознаграждения за обратную связь (скидки, бонусы); интеграцию обратной связи в повседневные сценарии взаимодействия (например, опросы после звонка в чат-боте); регулярные обновления клиентов о внесенных изменениях, основанных на их предложениях. Критически важно, чтобы процессы были прозрачны — клиент должен видеть, что его мнение имеет значение, что повышает доверие и вовлеченность.

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

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

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

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