Создание перечня критических бизнес-функций (VBF) может столкнуться с несколькими препятствиями: 1) низкая зрелость бизнеса в области управления процессами, что затрудняет чёткое определение и описание бизнес-процессов; 2) отсутствие готовности бизнеса к открытой коммуникации о своих процессах и их критичности; 3) сложность согласования разных точек зрения на критичность функций между различными стейкхолдерами; 4) отсутствие чётких методик по определению VBF, так как существующие методики оценки зрелости процессов не дают прямых инструкций по этому вопросу. Эти препятствия требуют времени и ресурсов для преодоления.

Относительные приоритеты бизнеса учитываются при расчете общего показателя качества через использование весовых коэффициентов. Например, при объединении показателей из различных групп услуг (mission-critical, business-critical и обычные) каждой группе присваивается вес, отражающий ее степень важности для бизнеса. При расчете общего интегрального показателя эти веса учитываются в формуле, например, при вычислении взвешенного среднего арифметического. Если mission-critical услуги имеют вес 0.5, business-critical — 0.3, а обычные — 0.2, то их показатели будут пропорционально учитываться в общем результате. Это позволяет управлять акцентами в оценке и более точно отражать стратегические приоритеты бизнеса.

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

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

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

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

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

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

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

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