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

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

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

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

Для оценки риска изменений (Change Risk) можно использовать несколько видов метрик. Прямые метрики (отложенные показатели): Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases, Number of defects per release. Эти метрики отражают уже произошедшие инциденты и их последствия. Опережающие показатели: Release size (размер релиза), Emergency change rate (доля аварийных изменений), которые помогают прогнозировать потенциальные риски. Также косвенно на Change Risk влияют метрики, связанные с First-Time Implementation Rate и Standardization/Automation, так как они отражают качество подготовки и внедрения изменений.

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

Warranty (Гарантия) в управлении услугами состоит из четырех основных компонентов: 1) Доступность (Availability) - насколько часто услуга доступна для использования, без простоев и перерывов; 2) Мощность (Capacity) - достаточность ресурсов для удовлетворения потребностей пользователей, например, достаточно ли яркости света для комфортного чтения; 3) Безопасность (Security) - защита от несанкционированного доступа и угроз, например, отсутствие возможности соседа воровать электричество; 4) Непрерывность (Continuity) - способность продолжать работу после сбоев или аварий, например, быстрое восстановление электричества после отключения. Эти компоненты вместе определяют, насколько услуга пригодна для использования (fit for use).

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

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

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