Ключевая оговорка:
Оба находятся в уязвимой зоне (заказная разработка). Речь не о том, что DIAS — «buy», а DGTL — «sell». Речь о том, у кого больше времени и пространства для манёвра.

1. Бизнес-модель (сегодня)

Вывод по модели:
DIAS чуть лучше за счёт гибрида «продукт + услуги». DGTL — чистая услуга, а услуга в эпоху AI — самый уязвимый формат.

2. Что делает AI с их позициями

Угрозы для обоих:

• клиенты начинают сдвигать IT-бюджеты в AI → заказной разработки становится меньше

• AI ускоряет написание кода → падение человеко-часов на проект

• pricing power падает (клиент знает, что код стал дешевле в производстве)

Почему DIAS пострадает меньше (относительно):

1. АБС — это не просто код, это бизнес-процесс банка.
   Заменить АБС — это многомесячный проект с рисками остановки операционной деятельности.
   Клиент не заменит АБС, даже если AI позволит написать новый аналог за полцены. Слишком дорого.

2. Поддержка и развитие АБС — recurring revenue.
   Даже если новые проекты заказной разработки сожмутся, поток от сопровождения останется.

3. У DIAS есть доступ к клиентским данным (в рамках АБС).
   А это — база для встройки AI в бизнес-процесс заказчика. Именно туда, по вашим же рекомендациям, нужно двигаться.

Почему DGTL в более сложной позиции:

1. Нет «якорного» продукта.
   DGTL продаёт руки и головы. Если AI снижает спрос на руки и головы — не за что зацепиться.

2. Стоимость замены поставщика — низкая.
   Клиент, который пользуется услугами DGTL, через 1–2 месяца может переключиться на другого аутсорсера или даже собрать внутреннюю команду + AI.

3. Нет встроенности в операционку клиента.
   DIAS сидит внутри банковской системы. DGTL — снаружи, решает точечные задачи.

3. Что могут сделать (стратегически)

Ключевая асимметрия:
DIAS может использовать AI, чтобы усилить свой продукт и продать его дороже.
DGTL может использовать AI, чтобы сократить свои затраты, но это не увеличит выручку, а сожмёт её (меньше часов).

4. Инвестиционный вывод (субъективно)

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

(какие вопросы задавать CEO / владельцу)

Блок 1. Бизнес-модель и монетизация

• Какой процент выручки сегодня зависит от продажи человеко-часов (FTE / проекты без привязки к результату)?

• Есть ли recurring revenue (подписка, поддержка, usage)? Какой % от выручки?

• Как изменится pricing, если клиент скажет: «мы внедрили AI — делайте ту же работу за 50% времени»?

• Тестируете ли вы модель оплаты за результат (fixed outcome), а не за часы?

• Есть ли эксперименты с usage-based pricing (токены, запросы, транзакции)?

Блок 2. Продукт и интеграция в клиента

• Есть ли у компании свой продукт (а не только услуги)?

• Какова стоимость замены вашего продукта/услуги для клиента (в месяцах и деньгах)?

• Есть ли доступ к клиентским данным (легально и технически) для встройки AI?

• Ваш продукт решает бизнес-задачу или просто «автоматизирует процесс»?

• Может ли AI заменить ваш продукт полностью или частично?

Блок 3. AI-стратегия (конкретика)

• Есть ли утверждённая AI-стратегия не дольше чем на 6 месяцев?

• Какой бюджет на AI в 2025–2026 (в % от выручки или FCF)?

• Используете ли вы AI внутри компании для ускорения разработки (Copilot, автотесты, генерация кода)?

• Самый важный вопрос:

  Какую новую ценность для клиента вы создаёте с помощью AI, которую он не может получить сам?

• Продаёте ли вы уже AI-функции как отдельный продукт или апсейл?

• Есть ли пилоты по встройке AI в бизнес-процессы клиента (не в вашу внутреннюю кухню)?

Блок 4. Риски и конкуренция

• Кто ваш главный AI-конкурент через 2 года? Это другой аутсорсер, продуктовая компания или сам клиент с внутренней AI-командой?

• Что произойдёт с выручкой, если крупнейший заказчик сократит IT-бюджет на 20% из-за AI-оптимизации?

• Какой % ключевых клиентов уже экспериментирует с AI для автоматизации задач, которые раньше отдавали вам?

• Есть ли план на случай, если market rate на разработчика упадёт на 30–40% из-за AI (ваши сотрудники уйдут? вы снизите цены?)?

Блок 5. Финансы и метрики (AI-adjusted)

• Как изменилась средняя выручка на одного разработчика за последние 12 месяцев (выросла или упала)?

• Есть ли у вас метрика «стоимость создания единицы функциональности» (например, один бизнес-сценарий за клиента)? Снижается ли она быстрее, чем у конкурентов?

• Какая доля FCF тратится на R&D в AI vs на поддержку legacy?

• Как изменится EBITDA-маржинальность, если вы переведёте 50% разработки на AI-ассистентов?

Блок 6. Организационная готовность

• Уволил ли кто-то из топ-менеджмента за последний год «из-за AI»? Нанял ли AI Head / Chief AI Officer?

• Есть ли у сотрудников (не только у C-level) KPI, связанные с внедрением AI?

• Как часто вы обсуждаете AI на совете директоров / стратегических сессиях (раз в квартал, раз в месяц)?

• Бонусный вопрос (самый честный):

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

Как пользоваться чек-листом

Красный флаг (дальше не смотреть), если:

• ▶️ Выручка на 80%+ из FTE / человеко-часов и нет плана перехода

• ▶️ CEO говорит: «у нас специфика, AI нас не коснётся»

• ▶️ Нет ни одного пилота по AI внутри продукта или в бизнес-процессе клиента

Жёлтая зона (можно брать, но с дисконтом), если:

• ▶️ Стратегия есть, но на уровне «смотрим»

• ▶️ Продукт есть, но AI не встроен

• ▶️ Рекурринг есть, но низкая маржинальность

Зелёная зона (можно рассматривать серьёзно), если:

• ▶️ Переход от FTE к usage или fixed outcome начался

• ▶️ AI встроен в продукт и продаётся как апсейл

• ▶️ Компания зарабатывает не на часах, а на результате для клиента

Если хотите — следующим шагом могу:

• применить этот чек-лист к DIAS / DGTL / любой другой компании (что получится)

• сделать краткую версию чек-листа для инвестиционного меморандума (1 страница)

• написать шаблон «AI-transformation roadmap» для CEO софтверной компании

Говорите, что забираете в работу.

Отлично. Двигаемся по трём направлениям, как вы и просили.

Заголовок:
AI не убил софтверные компании. Он убил их мультипликаторы.

Коротко (суть для инвестора):

Акции EPAM (-51% за год), QTWO (-35%), TCS (-27%) — это не «AI пришёл и всё сломал».
Это наложение двух вещей:

1. Цикл — клиенты режут IT-бюджеты.

2. Структура — рынок перестал верить, что софтверные компании будут расти вечно.

Раньше бизнес-модель «продажа человеко-часов» стоила дорого.
Теперь AI показывает: человеко-часы больше не дефицит.
Маржинальность под вопросом. Pricing power падает.

Что это значит для российских публичных компаний?

Наиболее уязвимы:
🔴 DIAS, DGTL, FIAI (заказная разработка, модель = человеко-часы)

Менее уязвимы, но не неуязвимы:
🟡 POSI, ASTR, 1С, Касперский (продукты, высокая стоимость замены)

Серая зона:
⚪ DATA, BAZA (пока неочевидно, насколько глубок их ров)

Главный вывод для инвестора:
Не смотрите только на P/E и EV/EBITDA. Смотрите на бизнес-модель.
Если компания продаёт время программистов — её терминальная стоимость снижается.
Это не вопрос «сейчас», это вопрос горизонта 3–5 лет.

Что делать?
Искать компании, которые:
✔️ встраивают AI внутрь продукта (а не внутрь своей кухни)
✔️ переходят с FTE на usage-based pricing
✔️ продают ответственность и результат, а не код

Проблема:
Классика: продажа человеко-часов (FTE) → клиент видит AI → говорит: «вы раньше писали этот модуль за 200 часов, а теперь с AI — за 50. Почему цена не изменилась?» → давление на ставку.

Три модели будущего для российского аутсорса:

Модель А. Fixed Outcome (фиксированный результат)

Формула:
Цена за бизнес-функцию, не за часы.

Пример:
Не «разработка личного кабинета за 500 часов по 50», а«работающийличныйкабинетсNфункциямиза50», а«работающийличныйкабинетсNфункциямиза25 000».

Как считать:
P = (1 + k) × C(AI)
где C(AI) — себестоимость с AI (часы × ставку с учётом AI-ускорения),
k — доля прибыли (например, 30–50%, выше, чем в FTE-модели)

Плюс: клиенту пофиг, сколько часов. Он платит за результат.
Минус: вы берёте риск на себя (AI ошибётся — вы переделываете).

Модель Б. Usage-based (токеномика для B2B)

Формула:
Цена за использование AI-агентов внутри продукта.

Пример:
Вы встроили AI, который автоматически проверяет код на уязвимости в инфраструктуре банка.
Плата: 0.50запроверкуодногофайла,0.50запроверкуодногофайла,0.10 за автоисправление.

Логика:
Revenue = Σ (Qᵢ × Pᵢ)
где Qᵢ — количество операций/запросов, Pᵢ — цена за единицу.

Плюс: привязаны к ценности для клиента (чем больше AI используют — тем больше вы зарабатываете).
Минус: сложно внедрить в российском enterprise (заказчики любят предсказуемые бюджеты).

Модель В. Hybrid: FTE + AI-коэффициент

Формула:
Ставка = базовая ставка × (1 − α) + премия за результат

Где α — коэффициент ускорения (например, 0.3 = на 30% быстрее).

Пример:
Базовая ставка разработчика 50/час→номинально50/час→номинально35/час.
Но к этому добавляется премия за фиксацию показателей (например, 20% от экономии клиента).

Как это считать в excel модели проекта (упрощённо):

→ прибыль упала, но маржинальность выросла (50% → 63%).

Вывод:
В чистом виде FTE-модель умирает.
Hybrid — переходная стратегия.
Fixed Outcome и Usage-based — где будет рынок через 3 года.

Методика (5 критериев):

1. Модель монетизации
   🟢 = usage/результат/подписка с сетевым эффектом
   🟡 = подписка или лицензия (SaaS)
   🔴 = человеко-часы / проектная без AI-трансформации

2. Интеграция в клиента
   🟢 = глубокая (высокая стоимость замены)
   🟡 = средняя (заменят за 6–12 мес)
   🔴 = низкая (легко заменить через AI + младшие джуны)

3. Потенциал AI внутри продукта
   🟢 = прямой (AI усиливает продукт, а не просто автоматизирует внутреннюю разработку)
   🟡 = косвенный (AI помогает, но не меняет ценность для клиента)
   🔴 = нет или AI враждебен модели (автоматизирует самого клиента)

4. Pricing power перед AI
   🟢 = цену можно повышать (замены нет)
   🟡 = цену удерживаем
   🔴 = цена под давлением

5. Готовность CEO / стратегия AI
   🟢 = публичная стратегия, меняют модель
   🟡 = зондируют, но не меняют pricing
   🔴 = отрицание / «у нас своя специфика»

Результаты (субъективно, на основе публичных данных + типовой логики)

Легенда по итогам:

• 🟢 устойчива — бизнес-модель не разрушится, AI — скорее возможность

• 🟡 зона неопределённости — нужна стратегическая перестройка в ближайшие 1–2 года

• 🔴 высокий риск — текущая модель напрямую угрожается AI-революцией

Главный вывод по таблице:
Заказная разработка без собственного AI-продукта (DGTL, FIAI) — красная зона.
DIAS чуть лучше за счёт глубокой интеграции АБС, но тоже без чёткой AI-стратегии.
POSI, ASTR, Касперский, 1С — защищены лучше всего.

Если хотите — могу:

• упаковать это в pdf для внутреннего использования в инвестиционном комитете

• написать разбор конкретно по DIAS vs DGTL (почему один чуть лучше другого)

• сделать чек-лист для due diligence IT-компании в эпоху AI (какие вопросы задавать CEO)

Скажите, что забираете.

нижерасположенный текст полностью написан ИИ )) но это не точно ))

Сильная сторона: вы не повторяете мантру «AI всё сломает», а разделяете циклический спад (сжатие бюджетов) и структурный сдвиг (переоценка терминальной стоимости). Это сразу поднимает уровень анализа выше 90% публикаций.

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

Разбор сильный. Вы правильно выделяете:

• Цикл → сокращение «необязательных» IT-бюджетов.

• Структура → AI убивает не прибыль сегодня, а ожидания долгосрочного роста → снижение DCF-оценок.

Это принципиально важно. Многие путают причину и следствие.

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

Список 7 пунктов — очень плотный и честный. Ключевое, на мой взгляд:

«компании теряют pricing-power»

Это недооценённый риск в публичных дискуссиях. Клиент теперь понимает: «вы продаёте мне код, но код уже наполовину умеет генерировать ИИ — почему я плачу как раньше?»

Особенно хорошо, что вы различаете:

• заказную разработку (человеко-часы) → наиболее уязвима

• продуктовые компании (1С, Касперский, POSI) → относительно защищены

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

Пункт «Ретроградные контраргументы» — отдельное спасибо. Вы честно показываете, как выглядит typical Russian enterprise-ответ на AI.

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

Добавлю один важный нюанс:
Аргумент «в России нет своего ИИ» не означает, что AI не повлияет на рынок. Импортозамещение не отменяет тот факт, что заказчики российских софтверных компаний (те же банки, ритейл) уже активно экспериментируют с AI, в том числе через открытые модели. И их внутренний спрос на традиционную разработку может снизиться независимо от наличия у вендора своей LLM.

Как российские компании реагируют сейчас (факт, который можно было добавить):
Пока реакция в основном defensive:

• запрет внутреннего использования ChatGPT (кроме отдельных песочниц)

• единичные PoC на российских LLM

• отсутствие публичных стратегий трансформации бизнес-модели

То есть, риски вы описали хорошо, но реакция пока слабее, чем следовало бы.

Самый важный блок. Здесь вы даёте конкретику.

Лучший тезис — стратегический:

«AI должен давать вендору больший прирост производительности, чем клиенту»

Это редкий уровень честности. Если клиент научится экономить на разработке больше, чем вы — вы становитесь не нужны.

Что можно было бы развернуть:

1. Для заказной разработки (DIAS, DGTL, FIAI):

   • переход от продажи FTE к продаже бизнес-результата (не «мы напишем код», а «мы внедрим функцию за X часов по фиксу»)

   • обязательный AI-коэффициент в офферах (оценка проекта без AI vs с AI — так вы показываете ценность, а не скрываете экономию)

   • создание практик «AI для legacy-кода» (это боль больших заказчиков — переписывать старые системы под современные требования)

2. Для продуктовых компаний (DATA, BAZA, ASTR, POSI):

   • AI-агенты для автоматизации процессов заказчика внутри продукта (увеличение ценности, а не замена себя)

   • модель usage-based pricing (токены, запросы, инференс)

   • самое слабое место сейчас — никто не предлагает enterprise-безопасный AI внутри контура заказчика под ключ

Очень важный пункт, который у вас почти есть, но можно усилить:

«Ответственность как конкурентное преимущество»

В российском B2B компании платят не за код, а за чужие проблемы с которыми не надо разбираться. Если AI-инструмент снимает с клиента ответственность (безопасность, комплаенс, SLA) — это продаётся дорого. Этого почти нет на рынке.

Плюсы материала:
✅ Разделение циклического и структурного
✅ Честная постановка вопроса о pricing-power
✅ Различие бизнес-моделей (не все компании умрут)
✅ Реалистичный взгляд на «российскую специфику» без излишнего оптимизма
✅ Стратегический критерий «выигрыш вендора vs выигрыш клиента»

Минусы / зоны роста:
❌ Нет даже оценочных цифр: насколько выросла производительность в российских компаниях с AI (даже субъективно)
❌ Нет конкретных кейсов (пусть анонимных) — кто уже меняет модель
❌ Рекомендации верные, но без приоритетов («первым делом — pricing model и встройка в бизнес-процесс»)

Очень полезный материал для инвестора и для CEO софтверной компании.
Он не даёт готовых ответов (что честно), но задаёт правильные вопросы и разрывает популярные иллюзии.

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

Если хотите, могу помочь:

• превратить это в пост для Telegram/Twitter с акцентами для инвесторов

• написать вторую часть с конкретными финмоделями («как перестроить pricing в заказной разработке»)

• сделать таблицу устойчивости российских IT-активов к AI (DIAS, DATA, POSI, ASTR и др.)

Скажите — двигаем дальше?

Владимир Бубликов, ну добывать полезные ископаемые на донбассе все же веселее, чем валить лес в сибири зимой ))

Тимофей, сдай ещё и этого бандеровца куда следует, а то их трудно прореживать каждый раз заново ))

Создай телепередачу. Трейдинг навсегда или Трейдинг по пятницам

я тоже в ЧС у 115 человек, наверное, весь кадровый состав небратьев данного сайта

а у меня в ЧС всего 1 хам, емнип ))

значит облОжался? хы-х ))