Для оценки вероятности конечных событий через FTA необходимо следовать следующему алгоритму: собрать статистику по частоте возникновения базовых событий (на листьях дерева) – это могут быть данные об отказах оборудования, ошибок программного обеспечения или действий персонала; определить для каждого логического оператора формулу расчета вероятности: для оператора «И» вероятность события равна произведению вероятностей входящих событий, для оператора «ИЛИ» (при независимых событиях) – 1 минус произведение дополнений вероятностей; последовательно рассчитать вероятности по всем уровням дерева, начиная с базовых событий и поднимаясь к топ-событию. В случае сложных деревьев могут применяться программные инструменты для автоматизации расчетов. Полученная вероятность топ-события дает количественную оценку риска, которая может быть использована для сравнения с допустимыми уровнями риска и принятия решений об улучшении системы.

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

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

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

Путешествие заказчика в контексте ITIL - это последовательность шагов и взаимодействий, которые проходит потребитель услуги при взаимодействии с провайдером. Оно состоит из этапов, таких как Offer, Agree, Co-create и другие. В рамках этого путешествия потребитель взаимодействует с провайдером на различных уровнях и может запускать определенные потоки создания ценности. Путешествие заказчика помогает понять точки контакта с потребителем и те аспекты его взаимодействия с услугой, которые формируют общий пользовательский и клиентский опыт (CX/UX).

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

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

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

Оригинальный пятый принцип Agile Manifesto гласит: «Стройте проект вокруг мотивированных личностей. Создайте им необходимые условия, поддерживайте и доверьтесь им, чтобы работа была сделана». Официальный русский перевод формулирует этот принцип так: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им». Основное различие заключается в том, что в оригинале акцент сделан на мотивацию конкретных личностей, тогда как в русском переводе смещение акцента происходит на профессионализм команды в целом. Автор текста считает, что создатели манифеста (сверхпрофессионалы) воспринимали профессионализм как данность, поэтому в оригинале они фокусировались именно на мотивации, тогда как русский перевод добавил акцент на профессионализм, возможно, учитывая реалии, где настоящих профессионалов не хватает.

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