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

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

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

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

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

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

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

При проектировании процессов без чёткого понимания возможностей ITSM-системы возрастает риск создания «бумажного» регламента, который так и не будет внедрён в работу. Такой подход часто приводит к тому, что процесс через короткое время оказывается забыт и не используется в реальных операциях. Также есть вероятность, что при последующей автоматизации выявятся несоответствия между запланированной логикой процесса и возможностями системы, что потребует переработки регламента и увеличит затраты времени и ресурсов.

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

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