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

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

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

Момент объявления инцидента значительным определяется на основании заранее согласованного и задокументированного определения, утвержденного поставщиком услуг совместно с заказчиком. Любой участник процесса (сотрудник аварийной службы или подразделения поддержки) может объявить инцидент значительным, если ситуация соответствует заранее определенным критериям. После объявления значительного инцидента должна быть активирована специальная процедура, включающая уведомление топ-менеджмента, назначение ответственного лица, организацию совместной работы команд и внедрение специальных мер реагирования. Даже если некоторые службы не видят признаков значительного инцидента, они обязаны следовать установленной процедуре реагирования.

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

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

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

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

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

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