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

Модель RBAC имеет ряд преимуществ перед другими моделями управления доступом, такими как DAC (Discretionary Access Control) и MAC (Mandatory Access Control). Во-первых, RBAC обеспечивает более высокую масштабируемость, что особенно важно для организаций с большим количеством сотрудников. Во-вторых, она повышает прозрачность управления доступом, так как права привязаны к ролям, соответствующим должностям и бизнес-процессам. В-третьих, RBAC обеспечивает легкость администрирования - добавление или удаление пользователей не требует перенастройки всего механизма доступа, достаточно назначить или отозвать соответствующую роль. Также RBAC позволяет лучше соблюдать принцип разделения обязанностей, что повышает информационную безопасность организации.

Операционные затраты (OPEX) составляют 67-68% от общего объема затрат на ИТ в среднем по компаниям. В банках этот показатель выше — 76-79% (по данным за 2015 год), тогда как международная банковская статистика (Computer Economics) приводит цифру около 73%. Российские компании обычно демонстрируют более низкий уровень операционных затрат — 55-60%, но кризисные условия способствуют их росту за счет сокращения инвестиционных программ.

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

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

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

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

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

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

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