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

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

Участие в деловой игре Grab@Pizza развивает множество навыков: способность быстро принимать решения в условиях неопределённости, навыки коммуникации и взаимодействия между различными департаментами (особенно бизнеса и ИТ), понимание процессов ITSM и ITIL, умение приоритезировать задачи и обосновывать бизнес-ценность ИТ-инициатив, навыки управления кризисными ситуациями, лидерские качества и способность работать в команде. Также игра развивает умение анализировать ситуации, находить ошибки в текущих процессах и предлагать решения по их улучшению.

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

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

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

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

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

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

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