Классическое понятие Value chain описывает «линейную» модель взаимодействия нескольких субъектов, каждый из которых в общем случае может выступать как потребителем, так и поставщиком услуг. Замечательная простота этой модели заключается в том, что некоторый субъект у одних приобретает услуги, другим – оказывает (рисунок 1, часть «а»). При этом если «увеличить» одно из звеньев цепи (рисунок 1, часть «б»), то мы увидим одно прямое следствие такой линейности: один субъект (в данном случае – организация «B») принимает решение и о требованиях к содержанию / объёму потребления услуг, и о расходах на потребляемые услуги.

Однако жизнь вокруг нас сложнее. Всё более адекватным описанием реальных взаимодействий становится другая модель – Value network. Согласно этой модели несколько субъектов вступают в сложные взаимоотношения, и могут быть потребителями услуг друг друга, вместе (например, будучи партнёрами) предоставлять услуги одним и потреблять услуги других и так далее. Организация сервисных отношений в такой схеме взаимодействий существенно усложняется.

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

• разделение заказчика и плательщика;
• несколько заказчиков у одной услуги.

Разделение заказчика и плательщика

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

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

Несколько заказчиков у одной услуги

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

В этом случае ИТ-подразделению остаётся один из трёх вариантов:

• либо заключать SLA сразу с двумя заказчиками (что может привести к серьёзному усложнению переговорного процесса и размыванием ответственности бизнес-подразделений);
• либо считать подразделение «A» заказчиком ИТ-услуги, а подразделение «B» – потребителем, заключать SLA с заказчиком, считая что договорённость с потребителем – обязанность заказчика (также вероятно усложнение переговорного процесса, да и не факт, что бизнес пойдёт на такой вариант);
• либо выделять для заказчиков «A» и «B» разные ИТ-услуги (это приводит к росту каталога ИТ-услуг, и может потребовать более сложных связей между отдельными ИТ-услугами, а сам каталог в этом случае скорее всего будет строиться от бизнес-процессов).

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

Вместо заключения

Из представленных примеров ясно, что усложнение характера взаимодействия участников сервисных отношений серьёзно сказывается на решениях, которые необходимо принимать в части определения содержания (utility) ИТ-услуг, условий предоставления (warranty) ИТ-услуг, состава заказчиков ИТ-услуг и отношений с ними. Причём, в отличие от распространённых коммерческих сценариев (например, предоставление услуг связи, IaaS, SaaS, ремонта / обслуживания ВТ и так далее), внутрикорпоративные сервисные отношения принципиально более сложны, и их описание в рамках модели value chain является слишком упрощённым, чтобы работать в реальной жизни.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление уровнем услуг и каталогом услуг

Разработка каталога, SLA, метрик качества, расчёт доступности