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

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

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

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

Expanded incident lifecycle - это метод из книги ITIL Service Design (глава про управление доступностью), описывающий основные этапы решения инцидента с целью последующего анализа и оптимизации. Этот метод позволяет детализировать процесс от выявления до закрытия инцидента, выявить, на каких именно этапах теряется время, и сосредоточить усилия на их оптимизации. Например, можно ускорить диагностику, улучшить маршрутизацию инцидентов или оптимизировать передачу информации между командами. Такой структурированный подход дает возможность целенаправленно работать над сокращением времени на каждом этапе, а не пытаться улучшать процесс в целом без конкретизации.

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

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

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

В тексте упоминаются две альтернативные модели управления доступом: DAC (Discretionary Access Control, избирательное управление доступом) и MAC (Mandatory Access Control, мандатное управление доступом). RBAC во многих случаях заменяет эти модели из-за своей большей гибкости, прозрачности и соответствия бизнес-процессам. В отличие от DAC, где владелец ресурса сам определяет права доступа, RBAC обеспечивает централизованное управление, что снижает вероятность ошибок. По сравнению с MAC, который часто слишком жесткий и сложный для коммерческих организаций, RBAC предлагает более практичный и масштабируемый подход, особенно для организаций с большим количеством сотрудников и сложной структурой доступа.

Крупные организации имеют ряд характеристик, усложняющих внедрение изменений: 1) Инерция, поддерживающая текущий порядок и снижающая ощущение срочности перемен. 2) Сложные коммуникации в подразделениях, где работает более 100-200 человек, что мешает быстрому распространению информации об изменениях. 3) Среда, не поощряющая риски, особенно в компаниях, прошедших стадию стартапа, так как существует страх, что изменения могут привести к ухудшению ситуации. 4) Хроническая нехватка различных ресурсов - трудовых, финансовых, временных и волевых, что ограничивает возможности для экспериментов и корректировок. 5) Сопротивление как система, проявляющееся не через отдельных людей, а через саму структуру и культуру организации, что делает его менее очевидным и более сложным для преодоления, чем индивидуальное сопротивление сотрудников.