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

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

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

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

Автор занимает сбалансированную позицию по этому вопросу, считая, что истина находится где-то посередине. С одной стороны, он соглашается, что полное отсутствие смысла в работе ведёт к демотивации сотрудников, о чём свидетельствует эксперимент Дэна Ариели. С другой стороны, автор отмечает, что чрезмерное идеализирование задач и постоянное напоминание о грандиозных целях может вызвать у работников цинизм и усталость, особенно если компания не подкрепляет декларируемые миссии реальными достижениями. Важно, чтобы сотрудник понимал ценность своей работы, но эта ценность не обязательно должна быть связана с глобальными миссиями компании.

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

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

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

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

Руководителям проще понять ценность ITIL, поскольку материалы библиотеки часто изложены в общих и стратегических терминах, которые ближе к управленческому уровню. В то время как простым специалистам может быть сложно понять, что ITIL написан и для них, руководители видят ценность в помощи формированию общей стратегии, организации системы учета затрат и управлении изменениями. Для руководителей сервисных организаций любой отрасли ITIL предоставляет структурированный подход к управлению услугами, что соответствует их управленческим потребностям и задачам.