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

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

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

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

В области разработки программного обеспечения из-за искажения восприятия нормы часто наблюдаются следующие неэффективные процессы: заявленный конвейер CI/CD на практике представляет собой раз в неделю сборку кода с последующими ручными операциями, что приводит к развертыванию раз в две-три недели; высокий процент дефектов в продукте (от 50% до 70% бэклога) считается нормальным явлением; полное отсутствие метрик и данных об эффективности разработки, из-за чего никто не может точно ответить на вопрос о скорости выполнения задач. При этом команда уверена, что следует современным стандартам и технологиям.

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

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

Наличие этапа 'Отложено' в потоке создания ценности приводит к следующим дисфункциям: размытой ответственности, так как команда перекладывает вину на внешние факторы; повышенным требованиям к контролю, поскольку процесс становится менее предсказуемым; управлению через жесткие дедлайны, что создает стресс и искусственно ускоряет работу; управлению дефектами как отдельной активностью, так как отложенные задачи теряют контекст и качество; смещению фокуса с создания ценности на простое выполнение работы без результативности. Все это приводит к тому, что команда может быть постоянно занята делами, но конечные результаты будут неудовлетворительными.

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

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