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

Ценность для всех, разную, и пусть никто не уйдет обиженным

 

 Роберт Фальковиц (Robert Falkowitz) написал статью про ценность. Интересную, необычную, помогающую выйти из плоскости обыденных размышлений. Вот что примерно он в ней пишет:

Мы привыкли к описанной в ITIL модели, согласно которой услуги — это способ причинять добро ценность заказчикам. Ценность при этом выражается в повышении производительности и/или снижении действующих на заказчика ограничений. Но сервисные отношения сложнее, и кроме описанной в ITIL бизнес-ценности есть и другие, возможно, не менее важные. Вот как их можно классифицировать (я позволю себе некоторые комментарии к идеям Роберта; тем, кому интересны идеи без комментариев, можно познакомиться с оригиналом статьи или просто игнорировать третий столбец таблицы):

Виды ценности Описание  Комментарий РЖ
Market value / рыночная ценность Деньги, которые поставщик услуги получает от потребителя услуги. Получатель ценности — поставщик услуг. Я бы называл это рыночной ценой и в список "ценностей" не включал. А если и включал бы, то не цену, а прибыль.
Business value / бизнес-ценность Позитивное влияние потребляемой услги на результаты деятельности потребителя. та ценность, про которую пишут в ITIL,то есть фактическое повышение производительности (снижение затрат, оптимизация рисков) потребителя. Получатель ценности — конечно, потребитель услуг.   Важно и правильно, что Роберт указывает на отложенный и негарантированный характер этого позитивного влияния. Одна и та же ИТ-услуга может одному заказчику принести много  пользы, а другому — мало. То есть бизнес-ценность не может быть гарантирована поставщиком услуг, она формируется в том числе в процессе их потребления.
Returned value / ответная ценность Позитивные побочные эффекты сервисных отношений, которые получает поставщик услуг благодаря взаимодействию с потребителем — лучшее понимание рынка, улучшение имиджа, развитие компетенций...  Возможны и другие, но именно побочные, получаемые помимо (а иногда и вместо) денег за оказываемые услуги. Получатель ценности — поставщик услуг. Я бы, наверное, назвал это побочной ценностью. И добавил в число получателей потребителя услуг. В ITIL похожее по смыслу понятие (именно для потребителя услуг) — enhancing services, те услуги, которые заказчик не покупает отдельно, но радуется, когда они дополняют основные (core). Разница в том, что enhancing services заявлены и продаются, а, скажем, новые контакты на рынке, полученные благодаря потреблению услуг у определенного поставщика, или подсмотренные у него идеи организации работы — именно побочные позитивные эффекты сервисного взаимодействия. 
Relationship value / ценность отношений Самый сложный вид ценности. Это позитивное влияние на деятельность потребителя услуг сложившихся отношений с поставщиком: доверие, позволяющее меньше тратить на контроль; уверенность в целостности собственной цепочки формирования ценности для клиентов; снижение ориентации поставщика на других потребителей (возможно, конкурентов данного потребителя).
Получатель ценности — потребитель услуг.
Во-первых, мне кажется, что это частный случай побочной ценности (предыдущий пункт в списке). Во-вторых, следовательно, получателем ценности могут быть все участники сервисных отношений, не только потребитель услуг. Интересно, что Роберт указывает на то, что этот тип ценности может существовать и в отсутствие как рыночной, так и бизнес-ценности. Тут в действие вступают всякие психологические и социологические эффекты — непростые и интересные. 
Replacement value / ценность замены Выгода от замены собственных ресурсов и деятельности потреблением услуг, выгода аутсорсинга. С учетом возможностей, которые может дать организации развитие собственных ресурсов, ценность замены может быть как позитивной, так и негативной. Получатель ценности — потребитель услуг. 

Мне кажется, это понятие очень близко к бизнес-ценности; бизнес-ценность должна рассматриваться с учетом альтернативных сценариев реализации бизнес-операций и дополнительных воможностей. Не уверен, что стоит выделять здесь отдельный вид ценности — и так все непросто. 

 

Вот такая получилась классификация. 

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

Оригинал статьи доступен всем желающим, а комментировать и развивать предложенную автором классификацию можно здесь, в комментариях. 

 

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Добавить комментарий

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT