Casos
Cinco proyectos. Las mismas dos personas en todos.
Warehouses de SAP, streaming edge, atribución de marketing y calidad del dato automatizada — en industria, finanzas, telco y educación. Cada uno de ellos necesitó al menos dos de nuestras tres capacidades, que es todo el argumento para tenerlas en el mismo equipo.
- Proyectos entregados
- Cinco, en cuatro sectores
- Punto de partida más común
- Datos de SAP reconstruidos a mano cada mes
- Capacidades por proyecto
- Dos de tres, siempre
- Personas en tu proyecto
- Las dos que definieron el alcance
Proyectos seleccionados
Nombres de cliente omitidos donde todavía no tenemos permiso por escrito.
Ingresos reconocidos automatizados y P&L analítico
Los informes financieros y de contratación vivían dentro de SAP y se reconstruían a mano cada mes — días de trabajo antes de que nadie se fiara de los números. Modelamos las tablas en bruto de SAP en un warehouse de Databricks que alimenta dashboards de Power BI en vivo que el equipo financiero lee directamente.
- Arquitectura de datos
- Business Intelligence
Contabilidad de SAP en Power BI
Los datos contables llegaban como volcados manuales de SAP a Excel, subidos a un servidor local y cruzados a mano con el CRM. Automatizamos la exportación a Databricks, la modelamos contra el CRM, y convertimos una cifra de coste mensual en una diaria.
- Ingeniería de datos
- Business Intelligence
Explotando datos edge
Las métricas de salud de red y OSS estaban dispersas por los dispositivos edge sin una vista unificada, así que los problemas salían a la luz solo después de haber golpeado ya la red. Construimos un camino en tiempo real desde Node-RED en el edge, pasando por Kafka y PySpark, hasta dashboards de Grafana en vivo, sobre una configuración híbrida on-premise y cloud.
- Arquitectura de datos
- Ingeniería de datos
Modelando el ROI y el embudo de ventas desde marketing digital
Los datos de marketing estaban en ficheros parquet sin claves foráneas para cruzarlos con los datos financieros, así que nadie podía decir qué campañas se pagaban solas. Construimos el ETL desde landing hasta gold y las relaciones entre ambas verticales, y sacamos los KPI objetivo en Power BI.
- Ingeniería de datos
- Business Intelligence
Reporting de calidad de datos impulsado por IA
Los problemas de calidad pasaban desapercibidos hasta que el dato corrupto ya había llegado a la capa de BI. Centralizamos las señales de los jobs de Azure Data Factory, los jobs de Databricks y los esquemas de tabla detrás del framework DQX, y usamos un LLM para convertir la salida en bruto de las reglas en informes que el equipo del cliente lee de verdad.
- Arquitectura de datos
- Ingeniería de datos
Capacidades por proyecto
Ningún proyecto usó solo una de las tres.
Este es el argumento para mantener arquitectura, ingeniería y BI en el mismo equipo, mostrado en vez de solo afirmado. Cada traspaso entre estas tres es un punto donde un proyecto normalmente pierde dos semanas.
| Proyecto | Arquitectura de datos | Ingeniería de datos | Business Intelligence |
|---|---|---|---|
| Industrial Ingresos reconocidos y P&L | Sí | No | Sí |
| Finanzas Contabilidad de SAP en Power BI | No | Sí | Sí |
| Telco Datos edge en tiempo real | Sí | Sí | No |
| Educación Modelado de ROI de marketing | No | Sí | Sí |
| Plataforma de datos Reporting de calidad con IA | Sí | Sí | No |
Lee las tres capacidades en detalle: arquitectura de datos, ingeniería de datos, business intelligence.
El stack detrás de estos cinco
Lo que usamos de verdad, no lo que podríamos listar.
Fuentes
- SAP ECC
- CRM local
- Dispositivos edge Node-RED
- Ficheros landing en parquet
- Jobs de Azure Data Factory
Procesamiento
- Databricks
- Spark / PySpark
- Kafka
- Airflow
- DQX quality rules
Plataforma
- Azure
- Arquitectura medallion
- Tablas Delta
- Híbrido on-prem / cloud
- CI/CD dev · test · prod
Entrega
- Power BI
- Grafana
- Modelos semánticos
- Reporting generado con LLM
Preguntas
Lo que pregunta la gente después de leer esto.
¿Conectar con nuestro SAP ralentizará el ERP?
No. Extraemos según un calendario de las tablas que necesitamos, fuera del horario laboral donde el sistema lo permite, y toda la transformación ocurre después en Databricks — nunca dentro de SAP. Tres de estos cinco proyectos corren sobre datos de SAP ECC. En ninguno de ellos la capa de reporting añade carga al ERP, porque del ERP solo se lee.
Nuestros datos son un desastre. ¿Hay que limpiarlos antes de que empecéis?
No — eso es el trabajo, no un requisito previo. Ficheros de marketing sin claves para cruzar, contabilidad que llega como volcados manuales de Excel, problemas de calidad que nadie detectó hasta que llegaron al dashboard: esas son las condiciones de partida de tres de estos casos, no obstáculos que le pedimos al cliente que resolviera antes. Si tus datos ya estuvieran limpios no nos necesitarías.
¿Cuándo vemos algo funcionando?
El primer artefacto útil es el mapa del estado actual, y eso llega en las primeras dos o tres semanas. Un primer pipeline entregando datos de principio a fin suele llegar entre seis y diez semanas después de conseguir el acceso. La variable que más mueve esas fechas casi nunca es técnica — es cuánto se tarda en conseguir las credenciales de los sistemas origen.
¿Tenemos que migrar a Databricks?
No. Databricks aparece en cuatro de estos cinco porque encajaba con lo que esos clientes ya tenían — sobre todo entornos Microsoft con equipos que dominan SQL. El proyecto de telco corre sobre Node-RED, Kafka y Grafana en una configuración híbrida on-premise, sin Databricks en absoluto. Estamos certificados en Google Cloud y Azure y construimos en AWS. La arquitectura sigue a tu entorno, no a nuestra preferencia.
¿Qué pasa con la plataforma cuando os vais?
Es tuya, y la lleva tu equipo. Cada proyecto termina con las transformaciones documentadas, CI/CD entre dev, test y producción, y una sesión de entrega técnica. Escribimos las reglas de gobierno — nomenclatura, aprobación de esquema, enrutado de alertas — precisamente para que la plataforma nos sobreviva. Depender de nosotros sería un fallo de diseño, no un modelo de negocio.
¿Podéis trabajar junto a nuestro equipo interno de TI o de datos?
Es lo habitual. En el proyecto industrial los patrones de gobierno existían específicamente para que el propio equipo del cliente pudiera trabajar en paralelo sin romper producción. Podemos asumir un alcance definido de principio a fin, o integrarnos junto a tu gente en tu roadmap y con tus herramientas. Lo que no haremos es construir algo de lo que luego tu equipo quede excluido.
Empieza aquí
Si alguno de estos te ha sonado familiar, probablemente lo sea.
Cierres manuales, datos que solo coinciden entre sí por accidente, dashboards en los que nadie confía. Treinta minutos, sin diapositivas. Te diremos qué haríamos, aproximadamente cuánto cuesta, y si de verdad nos necesitas.
Empieza una conversaciónO mira las tres capacidades de las que vienen estos proyectos.