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

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

Ограничения метода 5-Why's включают зависимость от субъективности анализирующего, возможное возникновение ложных причинно-следственных связей и необходимость экспертных знаний для правильного построения цепочки. Метод не всегда учитывает сложные взаимовлияния множественных факторов и требует чёткого определения границ анализа, чтобы не уйти в сферу нерелевантных или нерешаемых проблем. Для повышения точности рекомендуется комбинировать его с количественными методами анализа.

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

Услуга становится ресурсом для другой услуги, когда она не предоставляется конечному потребителю напрямую, а используется как компонент для обеспечения более комплексной услуги. Определить это можно по следующим признакам: услуга не имеет прямого SLA с конечным клиентом, потребитель не взаимодействует с ней напрямую, она является частью внутренней архитектуры предоставления основной услуги. Например, услуга хостинга серверов может быть ресурсом для услуги предоставления веб-приложения конечному пользователю.

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

В практике управления инцидентами термины 'Critical Incident' и 'Major Incident' часто используются как синонимы, но имеют некоторые различия в трактовке. 'Major Incident' (Значительный инцидент) в ITIL определяется как инцидент с наивысшей категорией влияния, вызывающий существенные потери для бизнеса. Основной акцент делается на необходимости применения специальной процедуры управления, выходящей за рамки обычных процедур. Термин 'Critical Incident' может относиться к инцидентам, критическим для функционирования отдельных систем или компонентов, но не обязательно имеющим широкое влияние на весь бизнес. Таким образом, все Critical Incidents не обязательно являются Major Incidents, но Major Incidents всегда имеют критическое влияние на бизнес в целом.

Автор полагает, что в книгах ITIL разделение назначения (purpose), целей (goals) и задач (objectives) сформулировано небрежно, потому что: - Отсутствует чёткая и однозначная терминология, что приводит к путанице между этими концепциями. - Не раскрыты практические аспекты применения: например, где и как документировать назначение, цели и задачи процесса. - Нет явного указания на различную стабильность этих элементов (назначение стабильно, цели часто меняются), что влияет на способы их фиксации в документации. - Не указана ответственность по уровням: кто именно (дизайнер, владелец или менеджер процесса) должен работать с каждым элементом. Это заставляет практиков "долго доходить" до понимания этих различий, несмотря на их относительную простоту и важность для практического внедрения ITIL.

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

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