Фактические трудозатраты следует фиксировать как можно более своевременно, идеально - сразу после завершения работы. Допустимым крайним случаем является учет один раз в конце рабочего дня. Чем дольше задержка с учетом времени, тем ниже его достоверность. Например, при учете раз в неделю искажение трудозатрат может составлять около 10% (что соответствует 4 рабочим часам в неделю), причем чаще всего данные оказываются завышенными, вероятно, из-за неосознанного стремления отразить более интенсивную работу. Своевременная фиксация времени также более эффективна, так как онлайн-учет занимает меньше времени, чем попытки вспомнить и зафиксировать пройденные события в конце недели. При правильной организации учета по 20-25 работам, учитывая, что не все сотрудники участвуют во всех работах и не выполняют все свои задачи ежедневно, на учет специалист тратит около 10 минут в день (примерно 2% рабочего времени), а линейный руководитель - около 5% рабочего времени на контроль данных.

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

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

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

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

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

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

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

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

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