Портал №1 по управлению цифровыми
и информационными технологиями

Value network и сервисный подход

Опубликовано 13 августа 2012
Рубрики: ITSM, SLA, SLM, BRM
Комментарии

Классическое понятие 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, метрик качества, расчёт доступности

Комментариев: 24

  • Юрий Ерин

    Иными словами, модель value chain является слишком упрощённой для того чтобы использовать ее в реальной жизни для решения задач связанных с определением содержания и условий предоставления ИТ-услуг ?

    • Думаю, немного менее категорично:
      1) сценариев реальной жизни, когда value chain не является адекватной моделью взаимодействия, всё больше;
      2) эти сценарии характерны не только для современных рыночных отношений, но и для внутрикорпоративных (некоммерческих) сервисных отношений, в первую очередь в крупных компаниях и группах.

    • Собственно, это не новость, об этом давно пишут. Смотри, например, ITIL 2011, Service Strategy, раздел 3.8.1 “From value chains to value networks”. Просто прочувствовав на себе, понимаешь это лучше, чем прочитав книжку. Кроме того, важным акцентом, на мой взгляд, является то, что модель value network во внутренних сервисных отношениях в крупных компаниях проявляется даже чаще и сложнее, чем на рынке ИТ-услуг. По факту построить каталог услуг коммерческого ИТ-провайдера проще, чем внутреннего ИТ-подразделения (или аутсорсинговой дочки).

      • Если мы строим Систему управления, обладающую своей уникальной процессной, ролевой и сервисной архитектурой основанной на управлении сервисными цепочками, то “value networks” это просто усложненная “value chain” (см комментарий ниже)

  • Именно для решения таких сложных задач и вводятся такие инструменты как “Служба заказчика” и “управление сервисными цепочками”.
    Именно для этого создаются разные каталоги услуг и определяются разные владельцы этих каталогов: “Бизнес-каталог” для Службы заказчика и “Операционный” – для Поставщика услуг.
    При этом первый, в основном, строится на технологиях Ресурсно-сервисных моделей(РСМ), а второй – на технологиях Расчётно-технологических карт (РТК). И соответственно, первый – решает вопросы совокупной стоимости поддержки бизнес-процессов или как частный случай, отдельных информационных систем, а второй – трудоемкости операционной услуги, а также требуемой численности и компетентности Поставщика услуг.
    Такой подход – создание Службы заказчика, как интерфейса между Бизнесом и Поставщиком услуг – позволяет решить озвученные вопросы:
    – Бизнес-подразделения приобретают бизнес-услуги у Службы заказчика и даже если они напрямую за них не платят, то в отчетности видна доля потребленных услуг и их стоимость. А вопрос продажи одной и той же услуги разным потребителям или заворачивание одной и той же услуги в разные «фантики», выводится из зоны компетенции Поставщика услуг. Служба заказчика доводит до Поставщика услуг консолидированную информацию о требуемом объеме операционных услуг.
    – Создание бюджета на предоставление бизнес-услуг ведется Службой заказчика централизовано. При этом Поставщикам услуг, по большому счету без разницы, как и с кем они будут заключать SLA. Т.к. это становится вторичным вопросом – все вопросы, связанные с объемами, стимулированием взаимоотношений и эффективности решаются на уровне взаимодействия со Службой заказчика.
    – Требования Бизнес-подразделений и их правомочность (эффективность) контролируются Службой заказчика на основе имеющихся данных, как о бизнес-процессах Заказчика, так и стоимости операционных услуг Поставщика (ов).
    Как заключение
    Система управления услугами компании строится по одному принципу. Процессный, ролевой и сервисный состав такой системы в целом постоянен и не зависит не от сорсинговой модели, не от вида деятельности компании. Она (система) может и должна масштабироваться и формализовываться в той степени, в которой нужно в данный момент Бизнесу.

    • “Именно для решения таких сложных задач и вводятся такие инструменты как «Служба заказчика» и «управление сервисными цепочками»…”

      В крупном холдинге – согласен. В крупной компании (но без холдинговых связей) служба заказчика может быть избыточна да и не прижиться.

      “Процессный, ролевой и сервисный состав такой системы в целом постоянен и не зависит не от сорсинговой модели, не от вида деятельности компании.”

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

      • В такой трактовке – согласен.
        Но я намеренно говорил о масштабировании. Представьте, как Служба заказчика превращается в одного человека, исполняющего роль CIO.
        Т.е. я не пытаюсь сказать, что количество ролей и количество процессов с уровнем зрелости 5 для Холдинговой структурой и ИТ-службы из 20 человек – одинаковы. Но замысел системы управления не меняется – меняется только масштаб и степень детализации/формализации процессов, ролей, сервисов.
        Т.е. я могу сделать модель “идеальной” системы управления сервисами, определить состав треугольника: процессы, роли, сервисы, а потом что-то реализовывать как полноценный процесс, а что-то реализовывать как процедуру или отдельную политику. Соответственно так же будут масштабироваться, укрупнятся или детализироваться роли и сервисы этой системы.

  • Pavel Solopov

    Проблема, как мне видится, в попытке натянуть новую парадигму взаимодействия, на старую парадигму управления.
    Это миф, придуманный сейлами: “ITSM можно внедрять ничего не меняя в организационной структуре”.

    • Странно. В приведённых мной примерах для упрощения взаимодействия надо менять оргструктуру не ДИТ, а профильных подразделений. В связи с этим вопрос: а Вы когда организуете SLM меняете оргструктуру всей компании?

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

      Короче, требуется пояснение. Павел, Вы о каких изменениях говорите?

      • Pavel Solopov

        “Вы когда организуете SLM меняете оргструктуру всей компании”.

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

        По этому поводу анекдот, кстати тоже про ноги:

        -Сосед, что это у тебя кабан на трёх ногах скачет?
        -А что мне ради кастрюли борща целую свинью зарезать?

        • Pavel Solopov

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

          Пока такого понимания нет ITSM будет как тот кабанчик на трёх ногах…

        • “надо менять оргструктуру…”

          Мне действительно стало интересно, какие именно изменения оргструктуры Вы предлагаете за рамками ДИТ? Ну хотя бы пример?

          • Pavel Solopov

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

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

            • “переход от функциональной структуры к процессной”

              В масштабах компании для организации сервисных отношений? Странно…

              “Вообще, изменение в оргструктуру это конечно вторично. Начинать нужно с изменения принципов взаимодействия внутри компании вообще. Внедрение сервисного принципа взаимодействия между всеми подразделениями”

              Да, это хороший момент. Только тогда вопрос, кто является заказчиком SLM-проекта? Если генеральный директор – возможно, если ИТ-директор – это скорее становится пререквизитом проекта, чем его содержанием. Такие компании, кстати, есть, это не фантастика.

              • Pavel Solopov

                Так я Вам о том и говорю, что SLM по инициативе ИТ-директора, а если он даже не ИТ-директор даже, а начальник ИТ-отдела, это кабанчик на трёх ногах. 🙂

                Нельзя построить коммунизм в отдельно взятом городе, и даже в отдельно взятой стране сложно.
                Хотя сервисный подход он ближе к идеям анархизма (как саморегулируемая система).

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

                • Однажды Скептик в твиттере написал, что ITIL – это подход для тех, у кого неограниченное количество ресурсов, то есть для некоторого идеального мира. Мне кажется, Вы тоже здесь говорите о некотором идеальном мире.

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

                  Хотя про коммунизм – это очень верно.

                  • Pavel Solopov

                    Так спору нет. Я когда начинаю кому-либо рассказывать про ITSM и иже с ним, сразу предупреждаю, что это “картина идеального мира”.

                    А реальность она сложнее и многогранней, и действительно ещё не факт, что вообще сервисная модель эффективна в экономике.
                    просто не стоит в условиях этих ограничений тогда пытаться построить идеальный мирок в неидеальном мире.
                    Может стоит ограничить SLM управлением по KPI, не пытаясь выстроить квазирыночные отношения?

                    • “Может стоит ограничить SLM управлением по KPI”

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

                  • Pavel Solopov

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

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

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

                    Вот, как Вы, Дмитрий и просили, переходим к обсуждению определения. 🙂

                    • “Вот, как Вы, Дмитрий и просили, переходим к обсуждению определения”

                      Свят-свят! (побрызгал святой водой и убежал).

    • Другое дело, что есть важные оргизменения в ДИТ, поддерживающие сервисный подход (я подробно обсуждал это на вебинаре “Управление изменениями и релизами: один или два процесса?”, смотри http://www.cleverics.ru/ru/subject-field/webinars/46-core/webinars-and-video/380), но это немного другая история, не к теме этого поста.

      • Георгий

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

  • Вадим

    Т.е. выходит, что несмотря на “цепочечность” или “сетевость” этого самого value, стимулом для …э… адаптации состава и содержания услуг под нужды потребителя все равно является стоимость.

    И в случае, когда потребление и оплата разнесены по разным подразделениям (неважно на сколько частей), как раз обеспечение связи между потребностями и платой за них является наиболее сложной задачей в современных условиях сложившихся (ранее отстроенных) компаний. Может быть поэтому имеется тенденция на разукрупнение по направлениям/видам деятельности (специализация)? Тогда ведь при адекватном содержании услуг потребителю услуг становится все равно кому платить: внешнему подрядчику или корпоративному.

    Правда, в этом случае корпоративный подрядчик выродится как класс и его функцией останется поддержание корпоративного единства… которое вроде как никому и не нужно (?)


Добавить комментарий для Дмитрий ИсайченкоОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM