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

Стандарты ИТ-управления, такие как ITIL, COBIT и ISO/IEC 20000, предусматривают рекомендации о назначении ответственных за процессы, но не всегда указывают на необходимость выделения отдельной должности. Например, в ITIL говорится о роли Process Owner (Владелец процесса), который отвечает за стратегическое развитие и качество процесса. Однако во многих организациях эта роль совмещается с операционными обязанностями. Стандарты предполагают, что если масштаб процесса достаточно велик, то его управление может стать основной должностью сотрудника. Наличие выделенных менеджеров процессов чаще всего наблюдается в крупных компаниях с высоким уровнем зрелости по моделям, таким как CMMI или ITIL Capability Maturity Model.

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

Новый KPI создает стимул для минимизации количества инцидентов, поскольку решение вблизи Tmax дает низкий рейтинг. В отличие от традиционного подхода, где достаточно уложиться в Tmax для получения максимального балла, здесь даже успешное устранение инцидента за 3,9 часа из 4-часового лимита считается неоптимальным. Это поощряет не только оперативное реагирование, но и профилактические меры по повышению общей надежности ИТ-систем, так как любые инциденты, влияющие на бизнес (te > Tmin), негативно сказываются на итоговом рейтинге.

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

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

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

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

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

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