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

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

В типичных командах разработки для отдельной задачи из всего времени, которое она находится в системе, в среднем 90% составляет время ожидания. Для большого количества команд эта цифра еще выше - 95-97%. Это означает, что отношение реального времени работы над задачей (Touch Time) ко времени в системе (System Lead Time), называемое эффективностью потока, находится в диапазоне от 3% до 10% для обычных команд.

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

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

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

Проблема заключается в том, что процессы EDM01 и EDM05, описывающие управление системой руководства ИТ, используют ту же структуру практик (оценка, направление, мониторинг), что и процессы руководства системы управления ИТ (EDM02–EDM04). Это противоречит основному принципу COBIT 5, разделяющему руководство и управление. Если EDM01 и EDM05 — процессы управления, то их структура должна соответствовать управленческому циклу (например, PDCA). Если же они относятся к руководству, тогда возникает вопрос о том, кем и для кого осуществляется руководство над системой руководства, что представляется логически противоречивым и избыточным.

Для изучения процесса управления релизами рекомендуются следующие источники: ITIL (Information Technology Infrastructure Library), BMC Service Management Process Model (SMPM), IBM Tivoli Unified Process (ITUP). ITIL и IBM Tivoli Unified Process описывают процесс управления релизами как часть процесса управления изменениями в подразделении эксплуатации, тогда как BMC SMPM описывает управление релизами как отдельный процесс в подразделении разработки/сопровождения.

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

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