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

Согласно ITIL, в управлении мощностями выделяются три подпроцесса: Business Capacity Management (управление бизнес-мощностями), Service Capacity Management (управление сервисной мощностью) и Resource Capacity Management (управление ресурсной мощностью). Первый подпроцесс связан с прогнозированием и управлением мощностью на уровне бизнеса, второй – на уровне предоставляемых ИТ-услуг, третий – на уровне физических и виртуальных ресурсов.

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

Ошибка восприятия канбана как простого списка задач заключается в том, что канбан – это не только визуализация задач, сложенных по статусам ("Надо сделать", "Делаем", "Сделано"), но и инструмент управления потоком работы. Настоящий канбан позволяет выявлять узкие места процесса, устанавливать ограничение на количество задач в работе одновременно (WIP limit) и организовывать вытягивающую систему производства, где следующий этап берёт задачу только после освобождения предыдущего этапа. Простое размещение задач на доске без соблюдения этих принципов не делает процесс настоящим канбаном.

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

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

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

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

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

Назначение персонального телефона для специалиста Service Desk обеспечивает четкую и постоянную точку контакта для всех пользователей, что упрощает процесс обращения с проблемами. Это снижает время, затрачиваемое пользователями на поиск нужного специалиста, и делает поддержку более доступной для сотрудников компании. Наличие dedicated номера позволяет избежать ситуаций, когда пользователи не знают, кому звонить в случае проблем, и предотвращает потерю обращений, которые могут остаться незамеченными в общих каналах коммуникации. Для организации это дает прозрачность в работе службы поддержки и возможность отслеживания всех запросов через один канал.