> ## Content Index
> Fetch the complete content index at: https://economist.kg/llms.txt
> Use this file to discover other available public pages before exploring further.

# Фундамент для SuperApp: почему выбор находится не в технической плоскости
- URL: https://economist.kg/novosti-kompanii/2026/10/08/fundament-dlia-superapp-pochemu-vybor-nakhoditsia-ne-v-tekhnicheskoi-ploskosti/
- Published: 2026-10-08T05:30:43.000Z
- Updated: 2026-10-08T05:30:42.000Z
- Author: Economist.KG
- Tags: Новости компаний, PR

**Продолжаем серию экспертных статей о супераппах. В предыдущих статьях (**[**часть 1**](https://noventiq.kg/about/blog/superapp-lihoradka-kak-fintehu-v-kyirgyizstane-ne-szhech-byudzhetyi-i-nachat-zarabatyivat--chast-1?ref=economist.kg) **и** [**часть 2**](https://noventiq.kg/about/blog/superapp-lihoradka-kak-fintehu-v-kyirgyizstane-ne-szhech-byudzhetyi-i-nachat-zarabatyivat--chast-2?ref=economist.kg)**) мы разобрали, зачем банкам Кыргызстана SuperApp и как технический долг может замедлить развитие экосистемы. Теперь разбираем следующий важный вопрос: как оценить технологический фундамент, чтобы он не стал ограничением для роста?**

Диалог о выборе платформы для запуска приложений и сервисов зачастую начинается одинаково. 

> Какой у нее запас по мощности, какую нагрузку выдержит и на сколько лет этого хватит?

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

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

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

#### **Знакомая картина**

Логика запаса мощности не заканчивается на выборе платформы. Согласно нашим наблюдениям, сформировалась устойчивая последовательность. Как только какая-либо система перестает справляться — организация закупает дополнительный ресурс. Через некоторое время ситуация повторяется. Вновь и вновь…

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

> Сомнения в подходе появляются, когда последовательность повторяется в третий и более раз. Но почему тогда организация продолжает действовать так же?

#### **Почему быстрое решение выигрывает**

Схожую динамику описывали исследователи из MIT Sloan в начале двухтысячных. Они назвали это ловушкой возможностей (capability trap) \[1\].

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

В первом случае мы получаем видимый результат сразу. Во втором для внесения изменений требуется дополнительное время, и на коротком отрезке показатели становятся хуже: ресурс уходит на улучшения, а не на закрытие срочных задач. Авторы называют эту динамику «сначала хуже, потом лучше».

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

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

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

#### **Локальный масштаб**

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

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

#### **Что накапливается, пока выбирают быстрое решение**

У отложенного разбора проблем есть цена, и она измерима.

McKinsey провела исследование, охватившее ИТ-директоров финансового и технологического секторов. Около 30% опрошенных считает, что более пятой части бюджета на новые продукты уходит на разбор последствий прошлых технологических решений. Накопленный технический долг в целом они оценивают в 20–40% стоимости всего технологического парка компании (до амортизации) \[2\].

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

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

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

> Уровень технического долга ожидаемо связан и с финансовыми результатами. McKinsey измерила его в 220 компаниях из пяти регионов и семи отраслей: те, кто управляет долгом лучше остальных, растут по выручке на 20% быстрее отстающих. Авторы делают оговорку, что связь может работать и в обратную сторону — компании с хорошими результатами способны и охотнее гасят долг. Но показательно и другое наблюдение. Почти половина компаний, завершивших программы модернизации, снизить долг не смогла. То есть сама по себе замена систем результатов не гарантирует \[2\].

#### **Почему для суперприложения это критично**

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

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

#### **Что из этого следует при выборе**

Высокая стоимость изменения не появляется самостоятельно. Во многом она закладывается при выборе, когда о ней не думают.

Если ограничение — цена изменения, то оценивать фундамент необходимо по ней. Вопрос «сколько выдержит» отвечает про нагрузку. А вопрос «во сколько обойдутся изменения» отвечает про то, что для суперприложения важнее.

> У этой цены есть составляющие, и каждую можно выяснить до покупки.

**Цена роста.** Все решения масштабируются. Но какой минимальный шаг? Где-то он поштучный, а где-то исключительно целыми блоками. Прирост спроса на несколько процентов оборачивается многократно большей закупкой. И каждая подобная закупка — это отдельный срок поставки, отдельное обоснование, отдельный разговор с финансовым блоком.

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

**Цена нового.** Сколько времени занимает запуск сервиса, которого не было в плане? Считать здесь надо в сроках: сколько времени проходит от принятия решения до работающей среды.

**Цена ошибки.** Насколько решение обратимо? Если развернуться назад нельзя, то выбор направления обязан быть верным с первого раза. А точности здесь взяться неоткуда.

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

**Цена выхода.** Чаще спрашивают: сколько стоит внедрение? Реже — сколько будет стоить уйти?

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

**Цена в людях.** Сколько человек и какой квалификации вам потребуется, чтобы обслуживать систему и вносить в нее изменения? На первый взгляд вопрос выглядит техническим. Но когда на рынке труда существует дефицит специалистов, он превращается в кадровый. Наличие специалистов начинает значить больше, чем стоимость оборудования. Решение или сервис, требующие выделенной команды, создают зависимость не только от вендора, но и от рынка труда. И если разбираться с архитектурой некому, любой ответ на предыдущие четыре вопроса останется теоретическим.

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

#### **Где проходит граница**

Здесь стоит быть честным до конца.

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

К тому же выводу пришла и Deloitte по итогам опроса: технологические руководители ограничены не технологическими возможностями. Часто их ограничивает трение, которое возникает, когда организационные структуры, модели финансирования и способы работы не согласованы с целями организации \[3\].

> Фундамент задает потолок возможной скорости. Остальное зависит от процессов.

#### **Что дальше**

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

Разговор умышленно ведется без упоминания конкретных технологий: смысл в выборе инструмента появляется после того, как бизнес сформулировал требование. О самих инструментах мы расскажем в будущих материалах.

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

> Не «сколько оно выдержит» и «на сколько лет хватит», а «во сколько мне обойдутся изменения».

##### **Источники**

\[1\] Repenning N. P., Sterman J. D. Nobody Ever Gets Credit for Fixing Problems That Never Happened: Creating and Sustaining Process Improvement. California Management Review, 2001, vol. 43, no. 4\. MIT Sloan School of Management

\[2\] McKinsey Digital. Demystifying digital dark matter: A new standard to tame technical debt, 2022

\[3\] Deloitte. 2026 Global Technology Leadership Study

Первоисточник [здесь](https://noventiq.kg/about/blog/fundament-dlya-superapp-pochemu-vyibor-nahoditsya-ne-v-tehnicheskoy-ploskosti?ref=economist.kg).