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

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

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

Существуют четкие аналогии между управлением значительными инцидентами в ИТ и в службах экстренного реагирования, что подтверждается тем, что многие принципы ITIL заимствованы из практики экстренных служб. Как в лондонской системе экстренного реагирования (London Emergency Services Liason Panel), так и в ИТ, значительный инцидент определяется как ситуация, требующая специальных мероприятий с участием множества служб, затрагивающая большое число людей. В обоих случаях требуется: объявление инцидента значительным любым компетентным сотрудником, немедленное информирование руководства, назначение ответственного лица, мобилизация дополнительных ресурсов, обработка большого объема обращений и проведение анализа после разрешения кризиса. Эти аналогии подчеркивают универсальность принципов управления кризисными ситуациями независимо от отрасли.

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

Для сокращения среднего времени решения инцидентов необходимо проанализировать этапы их обработки, выявить узкие места и оптимизировать процессы. Согласно ITIL методологии, стоит использовать подход Expanded incident lifecycle для детализации этапов решения инцидента и поиска возможностей для ускорения на каждом этапе. Также критически важно внедрять процесс управления проблемами, так как его влияние на сокращение количества инцидентов часто недооценивают. Даже при одинаковой производительности персонала, сокращение общего числа инцидентов благодаря управлению проблемами существенно снизит среднее время решения, так как уменьшает очередь и перегрузки, связанные с неравномерным поступлением инцидентов.

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

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

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

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