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

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

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

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

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

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

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

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

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

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