CDP: build или buy — рамка решения для оператора

Когда возникает развилка

CDP-инициатива созрела. CMO хочет быстрее. CTO хочет ownership. CFO хочет понятную TCO. Vendors (Tealium, Treasure Data, Bloomreach, Twilio Segment) presентуют 6-недельный pilot. Internal data engineering уверяет: «у нас есть фундамент — за 9 месяцев построим под себя».

Выбор не очевиден. Часто принимается на основании политических факторов, а не systematic framework.

Критерии для рамки

Time to first value. Buy: 3-6 месяцев до первого working use case. Build: 9-18 месяцев. Если бизнесу нужна demonstrable value быстро — buy выигрывает.

Уникальность требований. Если ваши требования стандартные (identity resolution, segment activation, basic personalization) — buy подходит. Если вы telecom с уникальным combination biller events / network signals / multi-line accounts — build может быть оправдан.

Размер базы и cost per profile. Buy-vendors часто charge per profile. На базе 5M клиентов это может стать материальным расходом. Считайте 5-летнюю TCO, не лицензию первого года.

Скорость собственной data engineering команды. Buy = заплатили вендору. Build = нужна команда из 8-12 человек, которая её строит и поддерживает 5+ лет. Реалистично оцените, есть ли вы такая команда.

Регуляторные особенности. Если ПДн нельзя экспортировать (data residency), некоторые buy-vendors отпадают. On-prem vs cloud — отдельный criteria.

Lock-in tolerance. Buy создаёт contractual lock-in — повышение цен через 3 года, ограниченная exit option. Build вам — экспертиза-lock-in (если ваша команда уйдёт, всё обвалится).

Где обычно ошибаются

Buy под лозунгом «у нас нет команды». Через год команда не наняла, vendor подняла цены — оператор стоит между двух стульев.

Build под лозунгом «всё уникальное». Через 18 месяцев построили generic CDP с retro design, который проигрывает baseline vendor.

Pilot vendor с одним use case, потом «расширим до всех». На pilot vendor показывает best, в полной нагрузке — другая story.

Сравнение по списку features, не по реальному business job to be done. Vendor имеет 200 features, 90% не нужны.

Игнорирование integration debt. Любой CDP — buy или build — требует integration с biller, CRM, channels. Это часто 60-70% effort, и не зависит от build/buy.

Когда buy

База <2-3M клиентов. Нет специфических требований по data residency. Команда data engineering небольшая (<5 человек). Need for speed (запуск в 3-6 месяцев).

Use cases стандартные: marketing automation, basic personalization, segment activation.

Когда build

База значимая (>5M). Telecom-специфические требования к identity resolution. Strong существующая data engineering команда. Регуляторные ограничения на cloud / data export. Long-term horizon (5+ лет).

Когда hybrid

Часто оптимально: buy для quick-win frontend (audience builder, segment activation), build для long-term backend (identity resolution, profile store) с migration path. Vendor становится UI layer, internal — data layer.

Что обсуждать в комитете

Какой 5-year TCO для каждого option (включая cost per profile, integration, run-cost, exit cost)?

Какие use cases в первые 12 месяцев? Какие — в первые 36?

Реалистичность hiring data engineering команды на build-сценарий.

Vendor financial stability — кто будет существовать через 5 лет.

Exit story — что делать через 3 года, если выбор окажется неверным.

Как SamaraliSoft помогает

CDP Decision Workshop — 3-4 недели. Sizing requirements, TCO modelling для build / buy / hybrid scenarios, vendor longlist+shortlist evaluation, risk assessment, рекомендация с justification.

Связанное

• /architecture/telecom-cdp-architecture/ — CDP architecture
• /insights/telecom-vendor-management/ — vendor management
• /decisions/telecom-build-vs-buy-decisioning/ — decisioning build vs buy
• /insights/telecom-platform-tco/ — platform TCO