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

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

DevOps-метрики, которые можно соотнести с элементами Causal Loop Diagram, включают: Lead Time (Time to Market), Process Time (Process Time), Deploys per day (Release Rate), процент успешно реализованных изменений (% changes successfully implemented), процент полных и точных изменений (%C/A – percent complete and accurate), PIR Coverage Index, Mean time between release implementation, Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases, Number of defects per release, Average number of release units per release, Emergency Change Rate, Percentage of Changes Registered.

В управлении доступностью (AVA) основными показателями выступают: - MTRS (среднее время восстановления услуги) - MTBF (среднее время между сбоями) - MTBSI (среднее время между инцидентами) Эти показатели связаны со статистикой и тенденциями сбоев в работе ИТ-систем. В управлении непрерывностью (CONT) используются: - RTO (recovery time objective) — целевое время восстановления - RPO (recovery point objective) — целевая точка восстановления RTO показывает, за какое время после сбоя должно быть возобновлено предоставление услуги, а RPO указывает, какой период данных может быть потерян без критического ущерба для бизнеса.

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

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

Существует два основных подхода к определению соотношения этих процессов. 1) Модель №1: CSI рассматривается как общий подход к совершенствованию, который встраивается во все области деятельности, в том числе в процесс управления проблемами. В этом случае CSI является мета-практикой или инструментом, который используется на всех этапах жизненного цикла услуги и опоясывает стратегию, проектирование, преобразование и эксплуатацию. Процесс управления проблемами, в свою очередь, использует подходы CSI для решения конкретных проблем. 2) Модель №2: Граница между CSI и PRB проходит не между различными видами деятельности, а между различными уровнями организации. В этом случае CSI представляет собой общекорпоративную практику, которая охватывает всю организацию (например, весь ИТ-департамент), в то время как процесс управления проблемами фокусируется на решении конкретных технических ошибок. При этом в большинстве организаций эти практики появляются не одновременно и имеют разный охват, что делает вопрос границы между ними актуальным только после установления жизнеспособности обеих практик. Если рассматривать CSI как мета-практику, обеспечивающую единые подходы к управлению качеством (аналогично практике риск-анализа), то эти процессы находятся в разных плоскостях, но взаимодействуют друг с другом.

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

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

В COBIT 5 проводится чёткое разграничение между процессами руководства и управления. Руководство (Evaluate, Direct, Monitor — домен EDM) осуществляется извне, как взаимодействие с управляемым объектом в режиме «черного ящика»: на вход подаются политики и требования, на выходе формируются отчеты. Управление же предполагает вмешательство во внутренние процессы, координацию деятельности и ресурсов для достижения целей. Таким образом, руководство задаёт направление, а управление непосредственно обеспечивает достижение результатов в рамках установленных требований.