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

WIP-лимиты (ограничения работы в процессе) напрямую связаны с отсутствием этапа 'Отложено' в потоке. Если задача может быть отложена, она все равно занимает слот в потоке, что может привести к превышению WIP-лимитов. Чтобы сохранить производительность, команды либо будут вынуждены уменьшить количество задач в потоке (что обычно невозможно из-за сохраняющегося давления на входе), либо отказаться от идеи слотов и WIP-лимитов в целом. Соответственно, без WIP-лимитов невозможна вытягивающая система, а без вытягивающей системы нет потока, а без потока нет высокоэффективной работы.

Альтернативный метод оценки эффективности потока заключается в проведении практического упражнения: представить поток и для каждого этапа процесса прикинуть, сколько времени задача проводит на этом этапе и сколько времени на ней фактически выполняется работа. Суммируя эти показатели и разделив суммарное время работы на суммарное время всего процесса, можно получить оценку эффективности потока. Хотя это не точный расчет, такие оценки часто удивляют команды, показывая реальный уровень эффективности в 10-25%, в то время как субъективные ощущения предполагают гораздо более высокие показатели (75-80%). Такой подход помогает выявить проблемные зоны, даже не обладая точными данными.

Change proposal формируется на стратегическом уровне управления ИТ-услугами в рамках процесса управления портфелем услуг. Создают его обычно ответственные за управление портфелем ИТ-услуг, работая совместно с бизнес-заказчиками. Документ проходит авторизацию через процесс управления изменениями, где оценивается его потенциальное влияние на другие услуги и ресурсы.

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

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

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

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

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

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