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

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

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

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

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

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

Для обеспечения корректного взаимодействия процесса управления сервисными активами с другими ИТ-процессами необходимо описать связи и структуру взаимодействия со следующими процессами и функциями: управление основными средствами, управление проектами, управление разработкой и тестированием, управление изменениями и релизами, заказчики сервисов, внешние каналы взаимодействия (SPI), операционные функции включая Service Desk, управление взаимоотношениями с поставщиками. Ключевой момент - четко определить моменты передачи данных между процессами, например, при создании новых конфигурационных единиц, обновлении данных после изменений или аудитов, а также при закрытии жизненного цикла активов. Такое описание обеспечивает целостность информации в CMDB и поддерживает непрерывность бизнес-сервисов.

Лидерство руководителей критически важно для успеха ITSM проекта по нескольким причинам. Во-первых, без поддержки и участия руководителей сложно принимать оптимальные решения на этапе проектирования процессов с точки зрения достижения целей процесса. Во-вторых, именно благодаря влиянию руководства становится возможным обеспечение беспрекословного выполнения положений процесса на этапе его запуска. Руководители имеют авторитет и полномочия, необходимые для преодоления сопротивления изменениям и обеспечения соответствия новым правилам работы. Без активного участия руководства команды часто сталкиваются с проблемой получения согласований и ресурсов, а также с трудностями в установлении приоритетов, что может привести к провалу всего проекта.

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

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