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

Альтернативой OLA в практике управления ИТ-услугами являются SLA (Соглашения об Уровне Услуг) и UC (Underpinning Contracts). При правильной организации эти документы способны описать все необходимые обязательства и процессы без введения дополнительного термина OLA. SLA можно использовать как для взаимодействия с внешними заказчиками, так и для регулирования внутренних отношений, если определить уровни ответственности и обязательств соответствующим образом. Таким образом, вместо введения OLA, которое усложняет структуру и может привести к путанице, достаточно использовать SLA и UC, что упрощает управление сервисами и повышает прозрачность процессов.

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

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

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

Бизнес-услуга (или customer-facing service в терминах ITIL V3) - это услуга, которая непосредственно предоставляется заказчику и на которую заключается соглашение об уровне услуги (SLA). Это видимая для клиента услуга, с которой он непосредственно взаимодействует. Примером может служить комплексное ИТ-обеспечение процесса продаж или бухгалтерского учета, которое клиент заказывает и использует напрямую.

Адаптация к клиенту играет ключевую роль в бизнесе, так как именно удовлетворение потребностей клиентов обеспечивает устойчивость и рост компании. Этот принцип остается актуальным на протяжении десятилетий: от неформальных предложений на рынках 1990-х, таких как «Рассмотрю любые предложения», до современных формулировок миссии компаний, ориентированных на «качественное удовлетворение покупательского спроса».

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

Для вычисления необходимого количества сделок нужно разделить общий план продаж на средний чек. Например, если план продаж на год составляет 1440 млн рублей, а средний чек равен 10 000 рублей, то ежемесячное количество сделок будет равно 1440 млн / 12 месяцев / 10 000 рублей = 12 000 сделок в месяц. Это значение используется для дальнейших расчетов нагрузки на ИТ-системы, определения необходимого количества продавцов и прогнозирования обращений в службу поддержки.

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