El vacío entre el dashboard y la plataforma de datos
En LATAM existen dos categorías legibles de "trabajo con datos": BI barato sobre el ERP a USD 200/mes y una enterprise data platform desde USD 300k. Entre ambas pasa la frontera del mercado donde vive el 95% de las empresas en crecimiento. Este artículo es sobre cómo cruzar esa frontera sin comprar Snowflake donde alcanzaba ClickHouse y sin contratar un senior data engineer cuando bastaba un contractor a cuatro meses.
Un escenario. El CFO de una distribuidora de 80 personas en Bogotá abre un Excel-deck que dos analistas armaron en cinco días hábiles. Los datos son del mes pasado, ya tienen 27 días de atraso. La decisión presupuestaria del Q3 es hoy. La margen por SKU está en disputa: ventas dice una cosa, bodega otra, finanzas una tercera. Googlea data warehouse PYME LATAM y aparece o bien oferta enterprise desde USD 150k, o tutoriales DIY para startups "en un servidor a USD 20/mes". En el medio: nada.
Ese vacío es el mercado Tier B para PYME LATAM. No Big 4 enterprise. No Excel-calca. Mid-market: 50-500 empleados, USD 5-100M de facturación anual, que crecen sobre Odoo, SAP Business One o NetSuite y al mismo tiempo pierden 3-8% del margen operacional por decisiones tomadas sobre datos viejos. Para una empresa con USD 30M de facturación, eso son USD 0.9-2.4M al año. Un impuesto silencioso, no articulado, por la falta de data engineering.
De aquí en adelante: qué entra técnicamente en Tier B, cómo elegir el stack para la realidad LATAM, en qué difieren los países y dónde queda la frontera entre "ya es momento" y "todavía es temprano".
Resumen en un minuto
- Tier B ≠ dashboard sobre el ERP. Es un data warehouse aparte, pipelines ELT, capa de modelado (típicamente dbt) y catálogo de métricas. Tier A es Metabase o Superset sobre una réplica Postgres del Odoo.
- El sweet spot para PYME LATAM: 50-500 empleados, facturación USD 5-100M, 3+ fuentes de datos aisladas, divergencias recurrentes entre reportes.
- Rango realista: primera implementación USD 25-80k, run rate mensual USD 300-5 000 según el stack. Por abajo: ClickHouse self-hosted. Por arriba: Snowflake con nodo regional en São Paulo.
- Sensibilidad por país: AR (el cepo cambiario encarece el SaaS en USD un 40-60%), MX (los volúmenes de CFDI obligan a DW completo desde el día uno), PE/CL/CO (las facturas electrónicas son fuente de ingesta lista para usar).
- Error principal: construir DW antes de arreglar la calidad de datos en las fuentes. Garbage in, dashboards out.
- La mayoría necesita un stack simple: dbt + ClickHouse o BigQuery + Metabase o Superset, sin Snowflake ni Databricks hasta que ML entre al roadmap.
Qué significa "Tier B" en el contexto LATAM
En la región la palabra data engineering se usa como paraguas que cubre desde "BI para un solo departamento" hasta "Lakehouse Databricks de 200 TB". Esa ambigüedad es la fuente principal de cheques de USD 50k por trabajo que debió costar USD 5k. Conviene separar dos niveles con dureza.
Tier A — BI sobre el ERP. Metabase o Superset conectado a una réplica de solo lectura del Postgres de Odoo (o al OData de NetSuite, o a una HANA-view de SAP B1). Las consultas corren sobre la misma base donde opera el ERP, o sobre su copia. Despliegue: 1-3 semanas. Run rate mensual: USD 50-250. Sirve mientras (a) la fuente sea una sola, (b) los volúmenes estén por debajo del millón de filas en las tablas principales, (c) los usuarios con consultas pesadas no pasen de diez.
Tier B — data warehouse separado más ELT. Datos de 3+ fuentes (ERP, CRM, marketing, bodega, billing, e-commerce) cargados a una base analítica aparte. Encima: modelos dbt (staging → intermediate → marts), catálogo de métricas, BI con acceso vía capa semántica y no SQL crudo. Despliegue: 3-5 meses hasta un primer release usable. Run rate: USD 300-5 000/mes. Acá viven análisis de retención y cohortes, proyección de caja, margen por SKU casi en tiempo real.
El disparador para pasar de Tier A a Tier B no suele ser "nos faltan funciones de Metabase". Son cuatro síntomas concretos:
- Los reportes de una misma métrica difieren entre áreas, porque cada quien construye desde su fuente.
- La precisión histórica se pierde — Odoo sobrescribe filas con los cambios y el negocio necesita lógica de snapshot para auditoría.
- Las consultas pesadas bloquean el ERP — el reporte financiero trimestral tumba el POS.
- Los analistas pasan el 70% del tiempo limpiando datos en lugar de analizar.
Si aparecen tres de los cuatro síntomas, es momento. Si aparecen menos, Tier B termina siendo una solución cara a un problema que todavía no existe. Para la lectura larga del problema base ver la guía pillar de Data Engineering y el complemento sobre cuándo BI deja de alcanzar.
Stack para PYME LATAM: opciones reales y precios reales
A diferencia del mercado US, donde el "modern data stack" arranca en Snowflake + Fivetran + dbt + Looker desde USD 5 000/mes mínimo, el mid-market LATAM vive en otra realidad de precios. Este es el corte por configuración real, validado en una muestra de 30 proyectos en producción.
#1. Almacenamiento
ClickHouse self-hosted (Hetzner, DigitalOcean, proveedor local en Santiago, Lima o Bogotá). Costo: USD 250-800/mes por instancia de 8-32 vCPU, 32-128 GB de RAM, discos NVMe. La velocidad en consultas analíticas supera a BigQuery y Snowflake en cargas comparables hasta 5 TB. Contra: requiere un ingeniero que sepa administrar ReplacingMergeTree, ReplicatedMergeTree, vistas materializadas y proyecciones. Ideal para AR y para PYMEs sensibles al gasto en USD. Documentación en clickhouse.com/docs.
BigQuery es la mejor opción para startups y PYMEs LATAM que ya tienen Google Workspace y Looker Studio (gratuito). Tarifa: USD 6.25 por TB escaneado más USD 0.02 por GB de storage (modelo on-demand). En una PYME típica (50-500 GB de hot data, 200-500 consultas/día) son USD 200-800/mes. En MX y AR se accede vía reseller local con facturación en pesos.
Snowflake es el default corporativo. Nodo en São Paulo desde 2022. Presupuesto mínimo realista: USD 1 500/mes para una PYME, fácilmente sube a USD 3-5k con warehouses indisciplinados. Tiene sentido cuando (a) ya hay equipo BI de 3+ personas, (b) los datos son multi-tenant con RBAC complejo, (c) se requiere integración con catálogos enterprise.
Databricks se justifica solo si hay cargas ML en el roadmap de los próximos doce meses. Si no, es overkill a USD 2k+/mes.
#2. Ingesta
Airbyte OSS self-hosted — gratuito, 350+ conectores. Contra: complejidad operacional, inestabilidad en algunos conectores, requiere monitoreo. Funciona si hay DevOps en el equipo.
Fivetran — USD 500-3 000/mes para PYME. Estable, pero caro. En LATAM se considera lujo.
Meltano — orquestación open-source de targets Singer. Más barato que Fivetran, más flexible, UI menos maduro.
Pipelines Python custom — para fuentes LATAM específicas (API de Mercado Libre, Rappi B2B, formatos bancarios locales, exportaciones del SAT, SUNAT, SII, DIAN). En esta muestra, el 30-50% de los pipelines reales en LATAM-PYME es custom, porque los conectores listos o no existen o no cubren la especificidad local.
#3. Transformación
dbt es el estándar de facto. dbt-core es gratis. dbt Cloud arranca en USD 100/dev/mes; para una PYME con 1-3 analistas equivale a USD 300-600/mes. La alternativa es orquestador + dbt-core. No hay otra opción seria en 2026. Documentación en docs.getdbt.com.
#4. Orquestación
Airflow es el estándar, pero es overkill para una PYME. Dagster es más moderno y tiene mejor DX, pero pesa más en el arranque. Prefect es el de menor fricción inicial, ecosistema menos maduro. El scheduler de dbt Cloud alcanza para el primer año si todo lo que corre es dbt.
#5. BI y visualización
Metabase (OSS o Cloud desde USD 85/mes) y Apache Superset son las elecciones más frecuentes. Looker Studio es gratuito, pero limitado en modelado. Power BI tiene sentido si el stack ya es Microsoft. Tableau es overkill para PYME (USD 840/usuario/año).
#6. Stack realista para una PYME de 80 personas
dbt-core + ClickHouse (Hetzner CCX23, USD 200/mes) + Airbyte OSS en VM aparte + Metabase OSS. Run rate total: USD 400-600/mes más el tiempo de un data engineer part-time (contractor externo USD 2-4k/mes o un junior interno). Primera implementación llave en mano: USD 25-45k y 3-4 meses.
La alternativa "todo en la nube de Google": dbt Cloud Developer + BigQuery + Airbyte Cloud + Looker Studio. Run rate: USD 1 200-2 500/mes y cero infraestructura propia.
Diferencias por país: por qué un solo stack no funciona para todo LATAM
Ignorar la diferencia por país es el error típico del consultor US que aterriza en la región con la plantilla "Snowflake + Fivetran + dbt". En LATAM eso se rompe en tres de cada diez países.
Argentina. El régimen FX (cepo cambiario, dólar MEP, dólar oficial) encarece cualquier facturación en USD entre un 40% y 60% sobre el equivalente real en dólares. Un stack SaaS de USD 2 000/mes termina costando USD 2 800-3 200/mes al tipo de cambio efectivo. A eso se suman las demoras en las transferencias internacionales. Bloomberg Línea registra el crecimiento del número de empresas formales en 2026 tras el programa de desregulación, pero el macrocontexto con las proyecciones del FMI sigue siendo frágil. La elección lógica para PYME: ClickHouse self-hosted en infraestructura local y facturación en pesos. El acceso a la API de ARCA (ex AFIP) para extraer comprobantes es un pipeline aparte. Detalles en la guía Odoo Argentina.
Chile. El SII construyó en quince años el formato de documentación electrónica más maduro de la región: DTE (Documento Tributario Electrónico) en XML con estructura predecible. Para data engineering es la fuente ideal — un único punto de ingesta cubre el 80% de la operación del small business. La adopción cloud es la más alta de LATAM. Snowflake y BigQuery operan sin fricción, no hay problema cambiario. Más en Odoo Chile.
Colombia. La DIAN desplegó desde 2022 la nómina electrónica — los datos estructurados de salarios, aportes y retenciones entran al sistema automáticamente. Para una PYME con 30+ empleados eso convierte los datos de RH de dolor en fuente lista para usar. La adopción cloud de Bogotá y Medellín está en segundo lugar de LATAM, detrás de Chile. Marco en Odoo Colombia.
México. El SAT (CFDI 4.0) genera volúmenes con los que un Postgres + Metabase naïf se rompe al tercer mes: una PYME mediana emite 50-500k CFDI al año, más los CFDI recibidos de proveedores, más los CFDI de nómina. Para análisis serio se necesita DW desde el día uno. Carta Porte 3.1 agrega la capa logística. Es el único país de la región donde Snowflake o Databricks se justifican en una PYME media desde el principio. Ver Odoo México.
Perú. La SUNAT impulsa desde 2024 el SIRE (Sistema Integrado de Registros Electrónicos), que reemplaza parcialmente al PLE. Los registros estructurados son input directo para el DW. Volúmenes menores que en MX — ClickHouse o BigQuery son óptimos. Detalles operativos en Odoo Perú.
Brasil (fuera del foco de este artículo, pero el contexto importa) es un mercado 2.5 veces mayor que toda LATAM hispanohablante, con su formato Nota Fiscal Eletrônica, ecosistema propio de proveedores y dinámica distinta. Entrar a BR con la plantilla del resto de LATAM no funciona.
Cuándo Tier B tiene sentido — y cuándo es dinero al vacío
Disparadores donde la decisión debe ser "sí":
Escenario 1. PYME de 80 personas en e-commerce, facturación USD 12M, fuentes: Odoo + Shopify + Mercado Libre + Meta Ads + Google Ads + 1C local para gerencial. El management decide marketing mix con exports manuales de cada sistema. El delay decision-to-action es de nueve días. Tier B amortiza en 4-6 meses vía un ciclo decisión-acción más corto: se identifican problemas de mix de producto y campañas perdedoras más rápido.
Escenario 2. Manufactura de 220 personas sobre SAP Business One, facturación USD 40M. Quiere costo-por-SKU real con costos indirectos, proyección de demanda, optimización del production scheduling. Acá Tier B no es alternativa, es condición necesaria — SAP B1 no lo calcula nativamente. Presupuesto para la primera fase: USD 60-120k.
Escenario 3. Cadena de restaurantes de 14 puntos, Odoo + iiko + Rappi + Uber Eats + app local de delivery. El CFO no puede saber en tiempo real si un local concreto es rentable. A los tres meses de Tier B sí puede, y cierra dos locales que sangran.
Casos donde Tier B es prematuro o francamente dañino:
Contra-escenario 1. Agencia de 22 personas, facturación USD 1.8M. Una sola fuente (CRM), un solo analista. La acción real es mejorar los reportes dentro del CRM o hacer Tier A. Tier B es overkill que succiona presupuesto sin retorno equivalente.
Contra-escenario 2. Distribuidora donde los datos llegan a Odoo con cinco días de atraso, la bodega corre en Excel paralelo al sistema y la divergencia de stocks es del 15%+. Primero hay que arreglar la calidad en las fuentes. Un DW sobre datos sucios no los limpia: solo fija el desorden y lo vuelve visible y caro. Ver el ángulo de auditoría Odoo antes de pensar en DW.
Contra-escenario 3. Empresa que "quiere AI" antes de tener un DW funcionando y al menos un año de historia limpia. ML sobre datos de ERP en crudo sin capa de modelado es estrategia venture con presupuesto corporativo. Para entender por qué, ver Machine Learning para PYME LATAM.
Cinco errores recurrentes en LATAM mid-market
#1. Comprar Snowflake porque "lo hacen las Fortune 500"
El uso real es 200 GB de hot data y 50 consultas al día. La cuenta mensual: USD 1 800. La carga equivalente en ClickHouse self-hosted: USD 250. La diferencia son USD 18 600 al año sin gano de velocidad ni de funcionalidad.
#2. Construir DW antes de arreglar las fuentes
Un Odoo con contactos duplicados, cuentas analíticas sin configurar y correcciones manuales cada mes es la primera tarea. Mientras el origen sea caos, el DW solo lo multiplica. Un mes de auditoría y limpieza del Odoo paga mejor a distancia que tres meses construyendo DW sobre desorden. Detalles operativos en la guía de auditoría Odoo.
#3. No hay capa de modelado
Los analistas escriben SQL crudo directo contra las tablas raw, repitiendo la misma lógica de negocio en diez dashboards con micro-diferencias. A los seis meses aparece el conflicto: dos top managers discuten la definición de revenue sobre la misma plataforma. La solución son modelos dbt con tests y documentación desde el día uno.
#4. Sin lineage ni documentación
A los seis meses nadie del equipo recuerda de dónde sale la métrica active customer. Se va el analista, se va el conocimiento. dbt-doc + dbt tests + catálogo ligero (Notion o Confluence) lo resuelven si se arrancan en la primera iteración, no en el "lo agregamos después" (que nunca llega).
#5. Contratar senior in-house data engineer demasiado pronto
El senior DE en LATAM gana USD 40-80k/año. Cargarlo con trabajo real en una PYME de 80 personas durante los primeros seis meses no se puede. La secuencia lógica: contractor externo para el setup (3-5 meses), luego middle DE o analytics engineer para soporte y evolución, y solo al llegar a 100+ pipelines un senior.
Caso: distribuidor textil en Lima, 84 personas, USD 18M de facturación
Situación (anonimizada, generalización de tres casos similares). Empresa que operaba sobre Odoo Community + generador PLE local + Shopify + Mercado Libre Perú + Excel para compras a fábricas de Gamarra. Cierre financiero mensual: 14 días hábiles. Margen por SKU en disputa: control interno daba un número, el ERP otro, bodega un tercero. El CEO decidía surtido "por intuición".
Qué se hizo. Cuatro meses con equipo externo: un data engineer al 0.5 FTE y un BI-analista al 0.3 FTE. Stack: ClickHouse self-hosted (una instancia CCX33 en Hetzner Falkenstein, USD 410/mes), Airbyte OSS en el mismo proveedor, dbt-core con GitHub Actions para CI/CD, Metabase OSS como front. Fuentes: Odoo vía replicación Postgres, Shopify vía Airbyte, Mercado Libre vía pipeline Python custom (no hay conector Airbyte estable), compras desde Excel vía importador simple.
Capa de modelado: tres niveles. Staging (copia exacta de fuentes con tipado), intermediate (joins, deduplicación), marts (tres: sales, inventory, finance). Total: 47 modelos dbt, 89 tests. Documentación con dbt-doc + Notion para definiciones de negocio.
Resultados al cuarto mes después de go-live: cierre mensual en cuatro días hábiles (desde 14). Divergencia entre "bodega / ERP / finanzas": menos del 0.8% (desde 6-11%). Se encontraron USD 340k/año de fuga de margen: 14 SKU se vendían bajo costo por landed cost mal cargado desde proveedor. Acción: revisión de surtido, USD 180k de margen recuperado en el primer trimestre.
Costo total del proyecto: USD 38k de pago único más USD 1.1k/mes de ongoing (hosting + dbt-cloud dev). Repago: 2.7 meses después de go-live.
"El ROI no fue el dashboard. Fue el día que vimos el SKU que vendíamos a USD 12 cuando el landed cost real era USD 14. Ese mes paga el año del proyecto."
Qué hacer ahora
Si el lector es CFO o CEO de una PYME en LATAM dentro del rango 50-500 personas y reconoce al menos tres de los síntomas de la sección "cuándo Tier B tiene sentido", el próximo paso no es "contratar un data engineer". Es auditar las fuentes de datos. Cuántos sistemas, qué calidad, qué ciclo de decisión está doliendo en este momento. Esa auditoría toma dos semanas y cuesta del orden de USD 3-5k.
Para arrancar la auditoría sin pedir presupuesto a un consultor: checklist de auditoría de fuentes de datos para PYME LATAM — 32 puntos sobre Odoo, SAP B1, NetSuite, e-commerce, CRM y marketing, organizados en "calidad", "acceso" y "competencias del equipo". El email se entrega en la página.
Si prefieres conversar el caso concreto: agenda diagnóstica, 30 minutos, sin compromiso. Sin pitch de "modern data stack".
Preguntas frecuentes
¿Cuánto cuesta de verdad la primera implementación Tier B para una PYME LATAM?
El rango realista es USD 25-80k. El piso es ClickHouse self-hosted + dbt + Metabase, una fuente y dos dashboards objetivo, tres meses. El techo es BigQuery o Snowflake + cinco fuentes + capa semántica completa + entrenamiento del equipo, cinco a seis meses. Cotizaciones por debajo de USD 20k suelen significar que algo se recortó — típicamente tests, documentación o la capa de modelado.
¿Se puede vivir en producción sobre ClickHouse self-hosted?
Sí, con dos condiciones: (a) volúmenes en hot zone hasta 5-10 TB, (b) alguien en el equipo que sepa configurar ReplicatedMergeTree y vistas materializadas. En ese rango ClickHouse es más rápido que BigQuery y Snowflake. Por encima de 10 TB o si se requiere zero-admin, conviene mirar opciones administradas.
¿Cuándo Snowflake se justifica frente a BigQuery o ClickHouse?
Tres condiciones simultáneas: (a) equipo BI de tres personas o más con disciplina en warehouse hygiene, (b) modelo RBAC complejo con decenas de roles, (c) integración con catálogo enterprise tipo Collibra o Alation. Sin las tres, Snowflake es overpay entre cinco y diez veces.
¿Qué stack elegir en Argentina con cepo cambiario?
ClickHouse o PostgreSQL self-hosted sobre proveedor local con facturación en pesos, dbt-core (gratuito), Metabase OSS. Las variantes managed facturadas en USD encarecen el run rate entre un 40 y 60% al tipo de cambio efectivo.
¿Es necesario un data engineer in-house desde el día uno?
No. Los primeros 3-5 meses conviene contractor externo o agencia para el setup. Después, middle DE o analytics engineer para soporte y evolución. El senior DE solo se justifica cuando hay 80+ pipelines activos o carga de streaming compleja.
¿En cuánto tiempo aparecen los primeros dashboards usables?
Cronograma realista: modelos en la semana 4-6, primeros dashboards validados en la 8-10, confianza del equipo y uso recurrente entre la 12 y 16. Quien promete "production-ready en cuatro semanas" vende presentación, no solución.
¿En qué se diferencia Tier B de Power BI + Excel?
Power BI y Excel son presentation layer, no almacenamiento. Power BI sobre Tier B es una arquitectura perfectamente válida. El problema aparece cuando se intenta usar Power BI como "data warehouse" vía Power Query: en volúmenes PYME se rompe a los dos años de retención y al aparecer una segunda fuente.
¿Tiene sentido empezar por Tier B si todavía no resolvimos Tier A?
Casi nunca. Tier B requiere disciplina de fuente que Tier A obliga a desarrollar primero. Saltarse Tier A suele dejar al equipo de DW limpiando datos durante el primer año, en lugar de modelando. Si los datos del ERP ya están en condiciones, sí se puede saltar — pero esa condición se valida con auditoría, no por intuición.
¿Y si el equipo todavía no tiene un analista que sepa SQL?
Entonces Tier B no devuelve nada el primer año. Antes de invertir en infraestructura conviene contratar a un analytics engineer o BI-analista que pueda usar los modelos. Sin ese rol, el DW queda como museo: estructura impecable que nadie consulta.
Materiales relacionados
Este artículo es parte del pillar Data Engineering en la línea Sergéi Filatov / Hacker Sergio. Si necesitas el ángulo país: Odoo en Perú, Odoo en Chile, Odoo en México, Odoo en Colombia, Odoo en Argentina. Para el puente entre Odoo y analítica, Odoo + Analytics. Para stacks concretos, ClickHouse, BigQuery, Databricks. Para casos de uso vecinos, Business Intelligence, Machine Learning, Computer Vision.
Autor: Sergéi Filatov (Hacker Sergio), Forbes 30 Under 30 LATAM, Lima. Arquitecto de data engineering e implementaciones Odoo para PYMEs y enterprise en diez países de la región. Perfil y portafolio.
Última actualización: 27 de mayo de 2026.