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

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

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

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

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

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

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

Для внедрения SMART-подхода в управление ITSM-процессами необходимо для каждого процесса сформулировать цели, соответствующие критериям Specific (конкретность), Measurable (измеримость), Achievable (достижимость), Relevant (релевантность), Time-bound (ограниченность сроками). Например, цель для процесса управления инцидентами: 'Сократить среднее время устранения инцидентов с критическим приоритетом до 2 часов к концу квартала'. Эти цели должны быть привязаны к назначению процесса и измеряться через влияние на качество ИТ-услуг.

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

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