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

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

Основные рекомендации для повышения эффективности деловой переписки по email включают: писать краткие письма, умещающиеся в одну экранную форму, с изложением сути проблемы в 2-3 абзацах; формулировать мысли максимально ясно и просто, избегая специфических терминов и витиеватых конструкций; избегать эмоционально окрашенного текста, который может повысить конфликтность; использовать структуру приветствие-благодарность-основание-суть-запрос-подпись; указывать в теме письма ключевые слова и ожидаемое действие; не злоупотреблять статусом «Срочно», чтобы сохранить его значимость; и при необходимости повторно отправлять письма с пометкой «ПОВТОРНО», если ответ не пришел в ожидаемые сроки.

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

Предложенная метрика увеличивается при регистрации новых проблем, что противоположно эффекту традиционных метрик, которые ухудшаются при росте числа новых проблем. Поскольку метрика учитывает количество новых проблем (N) в числителе формулы (N + C), увеличение N при прочих равных условиях ведет к увеличению значения метрики. Это создает положительный стимул для менеджеров процесса активнее выявлять и регистрировать проблемы, что особенно важно для процесса управления проблемами, где триггеры выявления проблем являются внутренними по отношению к оцениваемому субъекту (ДИТ).

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

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

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

В DevOps важно учитывать не только плановую, но и неплановую работу при распределении ресурсов, потому что операционная часть (тот самый 'Ops') требует постоянного внимания к текущим системам и их поддержке. Неплановые задачи, такие как инциденты, исправление дефектов и срочные запросы, являются неотъемлемой частью операционной деятельности и могут возникать в любой момент. Если выделить все ресурсы только на плановую работу, команда не сможет оперативно реагировать на проблемы в эксплуатации, что приведет к снижению надежности системы и удовлетворенности пользователей. Разделение ресурсов позволяет поддерживать баланс между внедрением новых функций и поддержанием стабильности текущих систем.

Нормировать в процессе управления проблемами можно фазу диагностики (problem control - PC), но не всю обработку проблемы целиком. Нормирование проводится на основании уровня влияния проблемы на бизнес-процессы. Например, для проблемы с высоким уровнем влияния срок диагностики может быть установлен в 1 неделю, для среднего уровня - 2 недели, и так далее. Это обосновано тем, что диагностика проблемы, определение корневой причины и вариантов решения имеет более предсказуемый временной контур по сравнению с последующей реализацией решения.