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

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

Основной базовый набор ключевых метрик DevOps включает: время нахождения идеи в бэклоге (пока не взяли на реализацию), время прохождения задачи от начала работы до выпуска в продуктивную среду, долю выполненных задач, которые принесли ожидаемую пользу, и предсказуемость выполнения взятых на себя задач за определенные временные периоды. К этому базовому набору можно добавить дополнительные метрики, такие как velocity, MTTR (среднее время восстановления), MTBF (среднее время наработки на отказ) и расход ресурсов на устранение дефектов и инцидентов. Однако важно не количество метрик, а то, что они дают объективную картину ситуации и помогают в принятии решений для уменьшения времени выпуска продукта (lead time).

Заказчики не понимают такой компромисс, потому что ожидают от ITSM гарантии времени разработки новых функций и улучшений. Для них SLA (соглашение об уровне услуг) кажется бессмысленным, если поставщик ИТ-услуг не может обеспечить улучшение существующих возможностей или гарантировать сроки новых разработок. Они задают вопросы вроде: «Зачем мне SLA, если текущая функциональность уже работает, а вы не можете гарантировать её улучшения?»

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

ISO 31010 представляет собой полное собрание методов идентификации, анализа и оценки рисков. Стандарт охватывает широкий спектр подходов – от организации работы экспертных групп до количественной оценки вероятности негативных событий. Среди описанных методов присутствуют FTA (анализ дерева отказов), ETA (анализ дерева событий), BIA (анализ бизнес-воздействия), метод Дельфи, SWIFT (Структурированный Что-Если Анализ Технологии) и диаграмма Ишикавы. Все эти методы собраны в едином документе, что делает стандарт ценным практическим руководством.

В ITIL4 произошел переход к более гибкой модели классификации услуг через призму парадигмы ресурсы-продукты-услуги. Вместо жесткого разделения на бизнес-услуги и поддерживающие услуги (как в ITIL V3), ITIL4 рассматривает видимость ресурсов для потребителя. Услуги могут иметь разную степень видимости в зависимости от контекста их использования. ITIL4 уделяет меньше внимания терминам 'бизнес-услуга' и 'информационная технологическая услуга', упоминая их лишь раз в описании практики Service Design в контексте SIAM (Service Integration and Management).

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

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

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