Во время деловой игры команды часто сталкиваются с выбором между стремлением выполнить KPI (достичь высокого количественного результата) и желанием учиться, экспериментировать и получать новый опыт. Некоторые группы предпочитают следовать привычным методам, чтобы добиться показателей, подобно рабочей практике, тогда как другие выбирают путь обучения, даже если это может привести к временному ухудшению результатов. Однако в ряде случаев команды, сделавшие ставку на обучение, достигают лучших результатов благодаря освоению новых подходов, как, например, в игре «Проект Феникс», где команда, выбравшая обучение, поставила рекорд.

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

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

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

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

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

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

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

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

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