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

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

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

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

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

Федеральный закон 44-ФЗ определяет ответственность Поставщика за неисполнение или ненадлежащее исполнение обязательств в размере от 0,5% до 2,5% от суммы контракта, при этом точный процент зависит от суммы самого контракта. Такой размер штрафов значительно ниже, чем обычно предлагается в коммерческих контрактах, где штрафные санкции могут составлять 20–30% от суммы договора. Это указывает на более мягкий подход государственного регулирования к применению штрафов по сравнению с частным сектором и может ограничивать возможности заказчиков для установления строгих финансовых санкций в государственных закупках.

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

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

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

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