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

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

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

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

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

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

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

Для решения проблем требуются координаторы, отвечающие за конкретную проблему и взаимодействие со смежными группами (разработчики, архитекторы, администраторы). Координатор назначается при регистрации проблемы и отслеживает этапы диагностики, согласование решений и внедрение изменений. Эта роль отсутствует в стандартном управлении инцидентами, где ответственность обычно лежит на L2/L3 поддержке. Также в процессе прописывается контроль за деятельностью координаторов через регулярные отчёты и проверки.

Методология FIFO (первая партия закупается — первая списывается) позволяет точнее рассчитывать затраты на оборудование, так как стоимость расходников относится к конкретной закупке. Это обеспечивает прозрачность и точность учета, упрощает определение реальных расходов по каждому устройству. Также FIFO удобен в функциональной реализации, поскольку не требует сложных расчетов и подходит для автоматизации в ITSM-системах.

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