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

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

ABAC не подходит для аудита, потому что в нём отсутствует явное понятие «права», как в RBAC. В ABAC доступ определяется динамически через набор условий на основе атрибутов, что делает невозможным однозначное определение привилегий пользователя без анализа всех текущих контекстных данных (время, место, свойства объекта). Это усложняет проверку и документирование прав, необходимые для аудита.

"Технические услуги для технических услуг" — это базовые инфраструктурные компоненты и услуги, которые обеспечивают работоспособность ИТ-систем (технических услуг). Примерами являются поддержка сетей и каналов передачи данных, систем управления базами данных (СУБД), систем хранения данных (СХД). Эти услуги являются фундаментальными и повторяются для поддержки различных ИТ-систем в организации.

Использование множества уровней сервиса (например, 25 уровней) и десятков условий выбора часто оказывается неоправданным, так как можно достичь эффективного баланса с меньшим количеством уровней и правил. Это снижает сложность поддержания SLA и минимизирует потери в качестве обслуживания.

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

Времени на мастер-классе оказалось недостаточно, потому что объём материала требовал более глубокого погружения. Участникам потребовалось бы минимум три-четыре часа, чтобы подробно обсудить суть и идеи канбана, решать задачи с постепенным повышением сложности и потренироваться не только в проектировании канбан-доски, но и в её практическом использовании в повседневной работе. Ограничение в 45 минут не позволило детально рассмотреть все аспекты метода, что привело к необходимости интенсивно подгонять участников и упрощать некоторые моменты.

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

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

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