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

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

Методическое обеспечение ИТ-бюджетирования может быть 100-процентным, поскольку ITIL предоставляет четкие, структурированные процессы и руководства для каждого этапа бюджетирования. Это включает в себя последовательные шаги от получения бизнес-планов через BRM/SLM до расчета стоимости услуг и формирования бюджета, где каждый этап имеет специфические методики, алгоритмы и формулы. Это делает процесс предсказуемым и документируемым, позволяя достичь полной методической проработки без пробелов.

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

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

Для управления задачами разной природы можно использовать вертикальное или горизонтальное разделение ресурсов. Вертикальное разделение предполагает чередование периодов: например, две недели на разработку, неделю на R&D, неделю на технический долг. Горизонтальное разделение заключается в выделении долей трудозатрат (например, 70% на развитие, 20% на эксплуатацию, 10% на исследования), с контролем результатов по каждому направлению. Однако такой подход требует четкого баланса, чтобы избежать формирования силосов и потери общей целостности команды.

Для оптимизации ИТ-затрат проводится план-фактный анализ, сравнение однотипных подразделений между собой (например, на разных территориях), изучение косвенных неотнесенных затрат, сравнение с рыночными данными для формирования инициатив по оптимизации расходов.

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

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

Для обеспечения надежности данных при использовании сложных критериев выбора SLА необходимо использовать точные и своевременно обновляемые источники информации. Это может включать интеграцию с несколькими системами, ручную проверку данных или разработку дополнительных правил обработки для исправления типичных ошибок, таких как опечатки или неполнота информации.