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

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

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

Комбинирование потока создания ценности с доской канбан в DevOps-практиках дает следующие преимущества: обеспечивает наглядное представление всего процесса доставки ценности от идеи до конечного пользователя; позволяет видеть не только текущее состояние задач, но и их положение в общем потоке создания ценности; помогает команде сосредоточиться на непрерывном потоке работ вместо изолированных этапов; делает видимыми зависимости между различными частями процесса; упрощает управление ограничением задач в работе (WIP Limit) для каждого этапа; и способствует более эффективному выявлению и устранению узких мест в процессе. Такая комбинация создает целостную картину работы, которая помогает командам лучше понимать свой вклад в конечный результат и оптимизировать процессы.

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

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

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

В Lean-подходе Lead Time — это время от момента поступления запроса до его выполнения, то есть общий период, который заказчик ожидает результата. Process Time (также называемое Touch Time или Task Time) — это время, когда непосредственно осуществляется работа над запросом, без учета времени ожидания в очередях. Основная разница в том, что Lead Time учитывает все задержки и время ожидания, тогда как Process Time фокусируется только на активной работе. Поскольку именно Lead Time определяет восприятие скорости выполнения работы заказчиком, оптимизация обычно направлена на сокращение именно этого показателя, а не Process Time. Однако отношение Process Time к Lead Time служит важным индикатором общей эффективности потока.

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

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