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

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

Критичность отклонения оценивается через влияние сбоя на бизнес-процессы. Например, недоступность CRM-системы на час может привести к потере 100 заявок, а простой внутреннего почтового сервера — только к временному неудобству. Рекомендуется создать матрицу, где каждая услуга оценивается по шкале: 1) финансовые потери в час простоя, 2) число затронутых сотрудников, 3) регуляторные риски. Услуги с высокой оценкой по этим параметрам должны получать больший вес в обобщённом отчёте.

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

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

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

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

Для демонстрации недостатка показателя SPI в методике EVM используется пример проекта рытья канавы длиной 20 метров. Изначально с двумя рабочими проект должен был быть выполнен за пять дней (при производительности 2 метра в день на человека). Когда один рабочий заболел и производительность упала вдвое, SPI корректно показывал 50% отставания в начале проекта. Однако по мере завершения работ, даже с задержкой, SPI постепенно приближался к 100%, и на момент окончания проекта становился равным 1, несмотря на то, что проект был завершён с двукратным превышением сроков, что иллюстрирует неспособность SPI адекватно оценивать соблюдение сроков завершённых проектов.

Автор оценивает свою ошибку при проведении SWOT-анализа как существенную, поскольку он поместил риски непосредственно в квадрант «Слабые стороны», не проанализировав их корневые причины. По его мнению, вместо этого он должен был задать уточняющие вопросы, чтобы выявить внутренние слабости организации, которые делают эти риски возможными. Автор считает, что это упущение привело к недостаточно глубокому анализу, и в будущем он намерен избегать подобных ошибок, уделяя больше внимания анализу причин рисков.

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