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

Основные причины отказа от измерения удовлетворённости ИТ-подразделениями заключаются в восприятии удовлетворённости как эмоциональной составляющей которой нельзя доверять и в её субъективной природе. Многие ИТ-специалисты считают что поскольку удовлетворённость является субъективной оценкой она не может служить надёжным инструментом измерения качества услуг.

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

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

В методике с динамическими весами при фиксированном MS = 50% (при N=10), интегральная оценка изменяется следующим образом: при провале одного направления (один KPI=0%) интегральная оценка равна 50%; если провалено два направления, интегральная оценка становится равной 31%; при трех проваленных направлениях оценка снижается до 21%. Это демонстрирует, что даже после первого провала продолжение работы в оставшихся областях остается экономически обоснованным, поскольку каждый последующий провал приводит к дальнейшему снижению общей оценки, но не делает ее полностью бессмысленной, как в случае с произведением KPI.

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

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

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

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

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