При использовании разных календарей для разных типов обращений возникает риск просрочки при переклассификации обращения. Например, если обращение изначально классифицировано как 'предоставление прав' (норматив 8 часов по календарю 8х5), а затем переклассифицируется как 'устранение ошибки' (норматив 8 часов по календарю 24х5), пересчет срока по новому календарю может привести к автоматическому нарушению, так как по новому календарю уже прошло больше времени, чем отведено. Это создает несправедливую ситуацию для сотрудника, который обнаружил ошибку в классификации. Такие проблемы подчеркивают важность точной первоначальной классификации и продуманной системы учета календарей.

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

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

Для улучшения процесса управления инцидентами с помощью цикла Деминга сначала нужно определить проблему (например, долгие сроки решения инцидентов). На этапе Планируй (Plan) анализируется процесс с использованием инструментов вроде Expanded Incident Lifecycle, выявляются узкие места и разрабатывается гипотеза решения (например, немедленное решение простых инцидентов). На этапе Выполняй (Do) реализуется гипотеза в течение определенного периода. На этапе Проверяй (Check) оценивается эффективность изменений через опросы пользователей и анализ метрик. На этапе Корректируй (Act) принимается решение о дальнейших действиях: если результаты неудовлетворительны, цикл запускается заново с новыми корректировками (разделение персонала на группы для простых и сложных инцидентов), а при успехе улучшения внедряются в постоянную практику.

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

Основные особенности Value network по сравнению с Value chain включают: нелинейность взаимодействия участников, сложные кросс-отношения между субъектами (когда одни организации могут быть одновременно и потребителями, и поставщиками услуг для разных участников), возможность совместного предоставления услуг, множественность заказчиков для одной услуги и разделение функций заказчика и плательщика. В отличие от линейной последовательности Value chain, где решение о требованиях и стоимости принимает один субъект для следующего звена, в Value network решения принимаются с учетом множества взаимосвязанных факторов и интересов разных участников.

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

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

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

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