Подход, позволяющий минимизировать складские запасы на производстве в системе Kanban, — это организация вытягивающего типа производства, основанная на принципе «точно-во-время» (just-in-time). В этой системе каждый участок производственной цепочки производит или поставляет компоненты только тогда, когда следующий участок нуждается в них, что сигнализируется с помощью карточек Kanban. Это устраняет необходимость поддержания больших складских запасов между этапами производства, так как материалы поступают к потребителю как раз в тот момент, когда они нужны для продолжения процесса, что снижает издержки на хранение, уменьшает риск устаревания запасов и ускоряет оборачиваемость средств в производстве.

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

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

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

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

Руководителям, чьи задачи обозначены как R (Responsible - непосредственный исполнитель) в RACI-матрице, рекомендуется делегировать эту работу другим сотрудникам, полностью или частично. Это обусловлено ограниченностью времени руководителя, которое нужно использовать максимально эффективно. Все задачи, которые могут быть выполнены другими членами команды, следует делегировать как можно быстрее. При делегировании важно четко определить, кому и какие именно функции передаются, сохраняя за собой контрольные функции. Это позволяет руководителю сосредоточиться на стратегических задачах, одновременно развивая компетенции подчиненных и создавая резерв исполнителей для ключевых процессов.

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

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

Метод EVM нельзя считать полноценной системой измерения успешности завершённых проектов, прежде всего из-за недостатка показателя SPI, который теряет информативность к концу проекта, автоматически становясь равным 1, что не отражает реального соблюдения сроков. Хотя EVM предоставляет ценные метрики для текущего управления проектом, особенно в части контроля бюджета через CPI, его структура не позволяет провести адекватную пост-оценку проекта по временным показателям, что критично для комплексной оценки успешности проекта, включающей качество, сроки и соответствие бюджету.

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