От центра затрат к конвертеру ценности: конвертация антиценности в технической поддержке

Полный текст

1 Введение

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

Аргументация опирается на словарь Теории управления ценностью (VMT) и методологии Æilus. Ценность, антиценность, поток ценности, система ценности, преобразователь ценности, а также плановая, реализованная и ретроспективная ценность используются в значениях, определённых в первой работе серии. Формальное описание Æ, валюты ценности, дано в работе Большаков (2026) и здесь не повторяется.

Основной источник - статья Æilus "Technical Support Service - Anti-Value Conversion" (Большаков, 2025). В ней поддержка описана как цепочка преобразователей ценности, которые получают от клиента антиценность и конвертируют её в ценность, причём коэффициент растёт на каждой линии. Статья предлагает измерять на каждом этапе два коэффициента. Эта работа излагает модель заново, делает коэффициенты измеримыми, фиксирует, чью ценность они измеряют, и предлагает протокол измерения. Полевых данных здесь нет: все числа в разобранном примере условны.

Работа опирается на аксиомы VMT A1 (контекстность), A2 (множественность интерпретаций), A4 (асимметрия плана и факта), A5 (независимость антиценности), A6 (реализация при потреблении), A7 (преобразование), A12 (несохранение ценности) и A13 (частичная соизмеримость), а также на теоремы T2 (инверсия потока), T4 (накопление сопротивления), T5 (локальная оптимизация), T9 (скрытые потоки), T14 (непроинтерпретированная ценность теряется), T15 (зависимость от границы) и T16 (масштабирование интерпретацией без реализации).

2 Почему поддержку считают центром затрат и что при этом скрыто

2.1 Затратный взгляд - это выбор границы

Взгляд на поддержку как на центр затрат возникает, когда граница системы ценности проводится вокруг финансовых потоков компании. Внутри этой границы поддержка потребляет зарплаты и инструменты и не даёт строки выручки. По A1 ценность существует только внутри системы ценности, а по T15 смена границы меняет вывод, не меняя реальности. Затратный взгляд - верное прочтение одной системы ценности, а не описание того, что делает поддержка.

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

2.2 Что скрывает затратный взгляд

• Ценность на стороне клиента. Поддержка восстанавливает поток ценности клиента. Если она перестаёт это делать, под угрозой оказывается условие участия клиента (A8), и по T7 клиент уходит или меняет форму участия.
• Внутренняя ценность. Источник называет три внутренних потока: информацию об инцидентах, запросы на функции, которые есть у конкурентов, и собственные предложения клиентов. По T9 структура, которую поддерживают потоки, не отражённые в модели, смоделирована неверно или неудачно ограничена. Затратная модель поддержки - именно такая модель.
• Конвертация. Источник утверждает, что поддержка конвертирует антиценность в ценность и что результат может на порядки превышать исходную антиценность, когда проблема доходит до глубоких линий и до продукта. A12 это допускает: одна устранённая первопричина снимает антиценность для всех клиентов, а не только для того, кто сообщил о проблеме.

3 Поддержка как точка входа потока антиценности

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

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

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

Точка входа важна из-за T4: сопротивление накапливается. Антиценность, оставленная в очереди, нарастает и превращается в потерю доверия, а по T6 - в снижение способности реализовать будущую ценность. Динамика очередей в разработке продуктов хорошо описана (Рейнертсен, 2009); прочтение VMT добавляет, что в очереди поддержки ждёт накапливающаяся антиценность в системе ценности клиента.

4 Цепочка конвертации

По A7 преобразование означает, что участник реализует входящую ценность, а в нашем случае поглощает входящую антиценность, и производит новую плановую ценность. Источник рассматривает каждую линию поддержки как такой преобразователь со своим владельцем преобразователя ценности (VTO).

4.1 Первая линия

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

4.2 Вторая линия

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

4.3 Третья линия

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

4.4 Владелец продукта

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

5 Коэффициенты, предложенные в источнике

5.1 Номинальные коэффициенты по линиям

В итоговом описании замкнутого цикла источник утверждает, что антиценность, принятая первой линией, может быть преобразована в ценность с коэффициентом от x1 до x1.5, на второй линии - x10, на третьей - x100. Предложения клиентов переходят на вторую и третью линии в объёме, который назван неограниченным, а ценность, которую владелец продукта возвращает клиенту, названа потенциально практически безграничной. Закономерность такова: чем крупнее проблема, тем выше линия, до которой она доходит, и чем выше линия, тем выше коэффициент. Источник предлагает эти значения как порядки величин, а не как измерения. В этой работе они рассматриваются как гипотезы.

5.2 VAM и ACM

Источник приходит к выводу, что на каждом этапе нужно измерять два параметра:

• Мультипликатор усиления ценности (VAM), коэффициент передачи ценности: "сколько ценности получено и доставлено клиенту".
• Мультипликатор конвертации антиценности (ACM), коэффициент конвертации антиценности в ценность: сколько антиценности получено и сколько из неё преобразовано в ценность для клиента.

Источник формулирует их словами и не даёт формул. Минимальное прочтение в виде отношений, предлагаемое здесь, для этапа s (первая линия, вторая линия, третья линия, владелец продукта) за отчётный период выглядит так:

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s - ценность, поступающая на этап (предложения или частично преобразованная потенциальная ценность); V_delivered,s - реализованная ценность для клиента, относимая на результат этапа; AV_received,s - антиценность, поступающая на этап; V_converted,s - реализованная ценность для клиента, полученная из неё. Все величины выражены в Æ.

Из формулировок источника следуют два вывода. Числители - это ценность для клиента, поэтому планы, тикеты и элементы бэклога учитываются только после того, как клиент их реализовал (A6). И у двух коэффициентов разные знаменатели: один отслеживает усиление ценности, другой - конвертацию антиценности. Коэффициент для всей цепочки - ACM_chain = sum of V_converted,s / AV_received,1: в знаменателе антиценность на входе, а каждая единица реализованной ценности относится только на один этап.

6 Чью ценность измеряем

По A1 и A2 коэффициент без названной системы ценности не имеет смысла. Цепочка затрагивает четыре системы ценности:

Эта работа фиксирует измерение так. Числители VAM и ACM измеряются в системе ценности клиента, потому что реализованная ценность - это интерпретация получателя. Знаменатели измеряются на границе между клиентом и поддержкой: это антиценность в том виде, в каком клиент её переживает и о ней сообщает, а фиксирует её первая линия. Системы поддержки и продукта используют коэффициенты; система компании соотносит их с затратами. VSO отвечает за политику агрегирования, по которой сопоставляются эти показатели, соизмеримые лишь частично (A13). Если бы поддержка измеряла себя из собственной системы ценности, она отчитывалась бы об усилиях и плановой ценности. Определения источника направлены вовне, и протокол сохраняет эту направленность.

7 Протокол измерения

Протокол ниже - предложение, не проверенное на практике и рассчитанное на работу с существующими системами тикетов и бэклога.

7.1 Какие данные фиксировать

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

7.2 Кто подтверждает реализованную ценность

Преобразователь, который претендует на результат, не подтверждает собственную реализованную ценность. Её интерпретирует клиент - явным подтверждением или через заранее согласованные косвенные показатели (инцидент не повторяется, функцией пользуются). VTO каждой линии предлагает оценки и отвечает за качество журнала. VTO продукта подтверждает, какие поставленные изменения восходят к каким входам поддержки. VSO разрешает споры об атрибуции. Плановая ценность фиксируется, но никогда не попадает в числитель, в соответствии с A4 и T16: масштабирование заявленной ценности одной лишь интерпретацией структурно неустойчиво. Значение x100 для третьей линии в источнике остаётся именно такой заявкой, пока изменение не дошло до клиентов.

7.3 Ритм пересмотра

• По каждому тикету, при закрытии: оценка на входе, тип решения, реализованная ценность на первой линии.
• По каждой линии, в коротком регулярном цикле: ACM и VAM по завершённым элементам, возраст открытой антиценности в очередях (T4), причины эскалации.
• По системе в целом, в более длинном цикле: VSO и VTO продукта рассматривают поставленные изменения, ретроспективные переоценки, общий приток антиценности и то, соблюдают ли коэффициенты по линиям порядок, предсказанный источником.

Поскольку реализация запаздывает, коэффициенты стоит публиковать по когортам, то есть по периодам, в которые была получена антиценность.

7.4 Подводные камни

Гудхарт (1975) заметил, что статистическая закономерность, как правило, разрушается, как только её начинают использовать для управления. В терминах VMT это T5: локальная оптимизация не гарантирует глобального улучшения.

• Накрутка числа тикетов. Если разбить одну проблему на несколько тикетов, пропускная способность выглядит выше. VAM и ACM - отношения в Æ, а не счётчики, но число тикетов не стоит ставить целью рядом с ними.
• Занижение входа. Недооценка антиценности повышает ACM. Оценкам на входе нужны общая шкала и выборочное подтверждение клиентом.
• Избыточная эскалация. Если у старших линий коэффициенты выше, возникает соблазн эскалировать. Эскалацию нужно оценивать по правилам, которые задаёт третья линия.
• Двойной учёт. На одну и ту же реализованную ценность могут претендовать несколько этапов. Каждая единица относится только на один этап.
• Сокрытие притока. Лучший результат - когда до поддержки доходит меньше антиценности, а этого ACM не видит. Общий приток нужно показывать рядом с коэффициентами, а его снижение считать результатом.
• Потеря сигналов. По T14 ценность без интерпретации теряется. Журнал должен показывать, сколько предложений и закономерностей дошло до продуктового решения.

8 Связь с доменами сервиса

Методология Æilus определяет домен как контекст интерпретации ценности, который предъявляет требования к допустимым практикам и результатам. Домены не создают ценность; они не пропускают недопустимую антиценность. Поддержка затрагивает несколько типовых доменов:

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

Отсюда два следствия. Реализованная ценность, учитываемая в ACM, должна быть допустимой во всех затронутых доменах. И ACM агрегирует ценность по частично соизмеримым доменам (A13), поэтому ему нужна явная политика агрегирования, которую методология поручает VSO, а политики доменов при этом ведут владельцы доменов. Без неё, предупреждает методология, оптимизация вырождается в локальные предпочтения или игру с метриками.

9 Условный разобранный пример

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

В продукте регулярно сбоит интеграция импорта данных. За один период об этом сообщают десять клиентов.

• Приём. Антиценность у каждого клиента оценена в 10 Æ, поэтому AV_received,1 = 100 Æ.
• Первая линия. Известное обходное решение и обновления статуса восстанавливают работу; клиенты подтверждают 120 Æ реализованной ценности. ACM_1 = 120 / 100 = 1.2, в пределах номинального диапазона источника.
• Вторая линия. Найдена первопричина в конфигурации; исправленное значение по умолчанию и статья в базе знаний доходят до сообщивших клиентов и до других. Подтверждённая реализованная ценность: 400 Æ. ACM_2 = 400 / 100 = 4, ниже номинального x10. В протоколе это результат, который нужно изучить, а не ошибка, которую нужно исправить.
• Третья линия и продукт. Выясняется, что протокол импорта хрупок; переработка и автоматическая проверка попадают в дорожную карту с плановой ценностью 5 000 Æ. Ничего ещё не выпущено, поэтому для этой когорты ACM_3 = 0. Эти 5 000 Æ фиксируются и исключаются.
• Предложения. Два клиента просят импорт по расписанию. Это потенциальная ценность на треке VAM, в ACM она не входит.

На этом пересмотре ACM_chain = (120 + 400 + 0) / 100 = 5.2. Если переработку позже выпустят и клиенты подтвердят ценность, когорта третьей линии обновляется ретроспективно; если она вызовет регрессию, эта антиценность записывается на третью линию. Пример показывает, что должен наблюдать пилот: разрыв плана и факта на самом глубоком этапе (A4, A6), запаздывание реализации и возможное расхождение с номинальными коэффициентами.

10 Ограничения

Полевых данных нет ни здесь, ни в источнике. Коэффициенты от x1 до x1.5, x10 и x100 - предложенные порядки величин, правдоподобные с учётом описанного механизма (одно исправление масштабируется на многих клиентов, создаются новые преобразователи), но не измеренные. Формулы - прочтение словесных определений в этой работе; возможны и другие прочтения. Оценки Æ зависят от интерпретации, а по A2 это свойство самой ценности, но для сравнения между командами всё равно нужна откалиброванная общая шкала, которую эта работа не даёт. Атрибуция между этапами поручена VSO без правила.

Пилот, способный подтвердить или ослабить модель, должен показать:

• что разные люди дают согласованные оценки Æ для одних и тех же тикетов;
• что ACM по когортам за несколько циклов пересмотра следует предсказанному порядку по линиям, каковы бы ни были абсолютные значения;
• что реализованную ценность подтвердили клиенты или согласованные косвенные показатели, а не сами претендующие линии;
• что использование коэффициентов сопровождалось снижением общего притока антиценности без манипуляций, перечисленных в разделе 7.4;
• что коэффициенты дают информацию сверх привычных показателей, таких как время восстановления сервиса (Форсгрен, Хамбл и Ким, 2018).

11 Заключение

Видеть в поддержке только центр затрат - это выбор границы. В финансовой системе компании поддержка - затраты; в системе клиента - устранение антиценности; в системе продукта - самая прямая информация о том, где продукт даёт сбой. Модель источника описывает цепочку преобразователей, рычаг которых растёт от первой линии к третьей и далее к команде владельца продукта, замыкая цикл PDCA обратно на клиента, и предлагает измерять её с помощью VAM и ACM. В этой работе коэффициентам даны минимальные формулы, их числители закреплены в системе ценности клиента, учитывается только реализованная и допустимая в доменах ценность, а также предложен протокол фиксации, подтверждения, пересмотра и защиты от манипуляций. Выдерживаются ли порядки величин из источника, может показать только пилот.

Источники

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.