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

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

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

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

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

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

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

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

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

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