Llegamos al final de nuestro viaje por la cocina de los datos.
En la Semana 2, Negocio (el chef) escribió la Receta. En la Semana 3, la Plataforma guardó los ingredientes crudos en la Despensa. En la Semana 4, preparamos esos ingredientes en la mise en place, creando funciones independientes en lugar de cadenas frágiles.
Tenemos la cocina perfecta. Los ingredientes están listos, limpios y calculados.
Pero Negocio no entra en la cocina a comer de los boles de preparación. Negocio quiere un plato terminado. Un dashboard, un reporte regulatorio, un modelo predictivo. Algo que pueda consumir directamente.
Y aquí es donde la mayoría de las empresas cometen su último gran error.
El antipatrón del “Plato Combinado Obligatorio”
Como Negocio no suele tener herramientas para montarse su propio plato, le pide a IT que se lo haga.
“Necesito una tabla con los clientes, sus saldos medios, sus campañas activas y su scoring de riesgo”, dice Marketing. “Yo necesito lo mismo, pero con la provisión técnica y la morosidad”, dice Riesgos.
IT mira la cola de peticiones (¿recordáis el cuello de botella de la Semana 1?) y toma una decisión que parece lógica pero es letal: “En vez de hacer 15 tablas distintas, voy a hacer una sola tabla gigante que tenga TODO. Así todos comen de ahí y me dejan en paz.”
Nace la tabla CLIENTES_FINAL_V3_DEF. Tiene 500 columnas. Un plato para gobernarlos a todos.
Es el equivalente culinario a hacer un plato combinado gigantesco que lleva paella, sushi, hamburguesa y tarta de chocolate, todo mezclado, y obligar a todos los clientes del restaurante a pedir exactamente eso.
¿Qué pasa en la práctica?
- Marketing solo usa 12 de las 500 columnas. Pero cuando pide añadir una nueva (la número 501), IT tiene que recalcular la tabla entera.
- Finanzas encuentra un bug en la columna de “provisión técnica.” IT para la carga de la tabla para arreglarlo. El dashboard de Marketing (que no usa esa columna para nada) amanece vacío.
- La tabla tarda 6 horas en calcularse cada noche porque cruza datos de 14 sistemas distintos en una sola query monstruosa.
Intentar hacer un plato único para contentar a todos es la forma más rápida de acoplar a toda la compañía. Si uno cae, caen todos.
Pero el problema del plato único no es solo que se rompa. Es que no puedes evolucionar.
Os cuento un caso real. Una empresa tiene 130 fuentes de datos, una por cada aplicación de negocio. Todas alimentan un motor de procesamiento común que tiene 5 o 6 pasos encadenados antes de llegar a la tabla final. Un día, alguien necesita añadir un campo nuevo.
¿Qué opciones tienes?
Opción A: hacerlo bien. Modificas las 130 definiciones de fuente para contemplar el nuevo campo, y adaptas los 5 o 6 pasos del motor para propagarlo. Coste: semanas de trabajo, riesgo de regresión en cada paso, y una coordinación que implica a medio departamento de IT. Para un campo.
Opción B: hacerlo “rápido.” Reutilizas un campo que ya existe pero que “ya no se usa.” Le cambias el significado. Donde antes decía “código de campaña” ahora pones “segmento de cliente.” El campo viaja por los 6 pasos sin problema porque la estructura no cambia. Funciona. Sale rápido.
Pero ahora tienes una columna que se llama “COD_CAMPANA” y contiene segmentos de cliente.
Seis meses después, un analista nuevo mira la tabla. Ve COD_CAMPANA. Asume que es un código de campaña. Cruza con la tabla de campañas. Los números no cuadran. Pierde dos días investigando. Nadie le dijo que ese campo ya no significa lo que dice su nombre.
Y lo peor: esto no pasa una vez. Pasa con cada campo que se reutiliza. Con el tiempo, la tabla se convierte en un palimpsesto donde los nombres de las columnas son fósiles de lo que un día significaron, y el significado real solo lo conocen los tres ingenieros que llevan años en el proyecto. Si uno se va, el conocimiento se va con él.
¿Os suena? Dos opciones: o te cuesta un ojo de la cara, o pierdes toda la coherencia de la tabla. Ese es el precio del acoplamiento monolítico.
Y hay un tercer problema que es aún peor, porque es silencioso.
En un proyecto anterior me encontré con la tabla monolítica definitiva. Cientos de columnas. Todo el mundo comía de ella. Pero tenía una trampa que nadie te contaba: mezclaba granularidades.
Algunas columnas iban a nivel de contrato. Otras iban a nivel de persona. En la misma fila. Sin ninguna marca que te dijera cuál era cuál.
¿Por qué esto es un problema? Porque si una persona tiene 2 contratos, esa persona aparece en 2 filas. Si sumas una columna que va a nivel de contrato, el resultado es correcto. Pero si sumas una columna que va a nivel de persona, estás duplicando el saldo. Y nadie te avisa.
Esas eran las columnas que conocíamos. Las que sabíamos interpretar. Para las demás, tuve que sentarme con Negocio a lanzar queries hasta que averiguábamos la granularidad de cada campo que necesitábamos. “¿Este campo, es por contrato o por persona?” “No estoy seguro, déjame mirar…” Horas de investigación para una tabla que supuestamente lo tenía “todo.”
Tenía todo, sí. Pero sin un manual de 50 páginas, no podías usarla sin riesgo de dar números incorrectos.
Y ese manual, por supuesto, no existía. El conocimiento de qué columnas podías sumar y cuáles no estaba en la cabeza de dos personas. Si una de ellas se iba, el siguiente iba a duplicar saldos sin saberlo. Y el informe iba a parecer correcto. Hasta que alguien cruzara con otra fuente y los números no cuadraran.
La solución: El Buffet Libre de Datos
Si tienes una buena mise en place (Semana 4), no necesitas hacer un plato combinado obligatorio. Lo que haces es montar un Buffet Libre.
La plataforma expone todos los ingredientes ya preparados: la bandeja del saldo medio, la bandeja del scoring de riesgo, la bandeja de las campañas. Cada bandeja es un componente independiente de la mise en place.
Y ahora, el Chef (Negocio) entra al buffet y se monta su propio plato.
- Marketing coge saldo medio, segmento y canal. Y se hace su Data Mart (su producto de datos).
- Riesgos coge saldo medio, scoring y morosidad. Y se hace el suyo.
- Finanzas coge provisión técnica, saldo medio y tipo de cambio. Y se hace el suyo.
Nadie le pide a IT que le monte el plato. Negocio se sirve a sí mismo.
Y como los platos son independientes, el desacoplamiento es total. Si Marketing decide añadir una columna a su Data Mart, el Data Mart de Riesgos ni se entera. Si el cálculo de Marketing falla, el reporte de Riesgos sigue saliendo perfecto. Aquí no hay una tabla monolítica que los ate a todos. Cada equipo tiene su plato. Cada plato es autónomo.
Pero para que Negocio pueda servirse a sí mismo en el buffet, hay un problema que resolver.
La Fachada: los cartelitos del buffet
Si Negocio entra a la cocina técnica (el modelo de datos que construimos en las semanas 3 y 4), no va a entender nada.
Va a ver tablas con nombres crípticos, claves hash y columnas de versionado. Es como ir a un buffet y que en vez de poner “Salsa Boloñesa”, el cartel ponga “Emulsión de Solanum lycopersicum con proteína bovina picada al 20% de grasa, cocinada a 90°C durante 120 minutos.”
Técnicamente preciso. Incomible para el usuario normal.
Aquí entra la Fachada.
IT construye una vista por encima de toda esa complejidad técnica. Una vista que reconstruye la tabla original, pero limpia. Para Negocio, la Fachada es un cartelito que dice “Cliente.” Cuando hace una consulta, ve el NIF, el nombre, la dirección y el saldo. Exactamente igual que si fuera una tabla plana tradicional. No ve la complejidad interna.
En ingeniería de software esto tiene nombre: el patrón Fachada. La idea es simple: pones una interfaz limpia y sencilla delante de un sistema complejo. El usuario interactúa con la interfaz. La complejidad queda detrás. Si mañana reorganizas todo lo que hay detrás de la fachada, el usuario ni se entera. Solo ve el cartelito.
Para que se entienda: sin fachada, Negocio abre su herramienta de consulta y ve tablas con nombres como TBL_ENT_CLI_CORE, TBL_REL_CLI_CTR_001, TBL_ATR_CTR_FIN_V2. Columnas como SK_HASH_CLI, DT_VALID_FROM, COD_HASH_DIFF. Para hacer una consulta simple (“dame los clientes con saldo mayor de 100.000€”) necesita saber qué tabla contiene la identidad, cuál los atributos, cómo se cruzan, y qué columna de versionado usar para quedarse con el registro vigente.
Con fachada, abre su herramienta y ve una tabla que se llama “Clientes.” Con columnas que se llaman NIF, Nombre, Dirección, Saldo, Segmento. Hace su consulta directamente.
La fachada traduce entre lo que Negocio ve y lo que la cocina tiene detrás. Y si mañana IT reorganiza la cocina (cambia una partición, añade un índice, migra de tecnología), la fachada sigue igual. Negocio ni se entera.
La complejidad técnica está ahí — garantizando la trazabilidad, el reproceso y el versionado — pero es invisible para el consumidor. Es el escudo que protege a Negocio de la complejidad de IT. Es lo que permite que el actuario, el controller o el analista puedan cruzar datos con un simple JOIN, sin tener que saber cómo está organizada la cocina por dentro.
Y hay un detalle que no es evidente: la Fachada no solo simplifica. También protege. Si mañana IT necesita reorganizar la cocina internamente (añadir un índice, cambiar una partición, migrar de tecnología), la Fachada sigue igual. Negocio no se entera. Exactamente como en un restaurante: puedes reformar la cocina entera sin que el comedor cambie.
El Pase: ningún chef saca un plato sin probarlo
Vale. Negocio ha entrado al buffet. Ha visto los carteles claros (Fachadas). Se ha montado su propio plato (Data Mart).
¿Se lo come ya? ¿Lo publica en el dashboard para que lo vea el CEO?
No.
En una cocina profesional, antes de que el camarero se lleve el plato al comedor, pasa por “El Pase.” El chef mira el plato, comprueba que la salsa no está cortada, limpia el borde, lo prueba y dice: “Sale.”
Ningún chef que se precie saca un plato de la cocina sin probarlo.
En datos, esto es el Control de Calidad. Pero ojo: un control de calidad distinto al que vimos en la Semana 3.
En la Semana 3, el inspector de la despensa verificaba los ingredientes al llegar: ¿han cambiado de formato? ¿Faltan registros? ¿El envío es coherente con los anteriores? Era un control de recepción. Equivale a que el jefe de cocina compruebe los albaranes del proveedor antes de meter nada en la nevera.
El Pase es otra cosa. No mira los ingredientes. Mira el plato terminado.
No es lo mismo comprobar que el pollo llegó en buen estado (control de despensa) que comprobar que el plato final sabe bien (control de emplatado). El pollo puede estar perfecto y el plato salir salado. El ingrediente pasa su control y el resultado no pasa el suyo. Son dos momentos distintos, dos responsables distintos, y dos tipos de reglas distintas.
El inspector de la despensa sabe de logística: ¿llegó todo? ¿El formato es correcto? ¿El envío es coherente con los anteriores? Pero no sabe a qué debería saber el plato. Eso solo lo sabe el Chef.
¿Tiene sentido lo que sale de esta cocina? ¿Un contrato cancelado puede tener saldo de medio millón de euros? ¿Las comisiones de gestión, que son un acumulado mensual, pueden bajar de un día para otro? ¿Un porcentaje puede valer 1.500.000?
Estas preguntas no las puede responder IT. IT no sabe que las comisiones de gestión son un acumulado. IT no sabe que un contrato cancelado no debería tener saldo. IT sabe de pipelines, de Spark, de dbt. Pero no sabe a qué sabe el plato.
La calidad del plato la tiene que definir el Chef.
La Pregunta Mágica
En nuestros proyectos, cuando nos sentamos con Negocio para definir la calidad de un Data Mart, no les pedimos que escriban código SQL. No les pedimos que aprendan una herramienta. Les hacemos una sola pregunta:
¿Qué te haría desconfiar de este dato?
Y Negocio responde en su idioma: * “Si veo que las comisiones bajan dentro del mes, algo va mal. Las comisiones de gestión se acumulan: solo pueden subir.” * “Si un contrato cancelado tiene saldo de 500.000€, no me lo creo.” * “Si un porcentaje vale 1.500.000, eso no es un porcentaje. Es un importe disfrazado.” * “Si desaparece el 30% de los contratos de un día para otro, es imposible.”
Cada una de esas frases ya es una regla de calidad. Solo le falta estructura.
Les damos una ficha sencilla. Sin jerga. Sin SQL. Solo su conocimiento: * ¿Qué indicador vigilas? * ¿Qué debería pasar normalmente? * Dame un ejemplo correcto. * Dame un ejemplo sospechoso. * ¿Cuánta tolerancia aceptas? * ¿Quién investiga cuando salta?
Negocio rellena la ficha en cinco minutos. El equipo técnico convierte esa ficha en un test ejecutable que se lanza cada noche antes de publicar el dato.
Si el plato está “salado” (si el contrato cancelado tiene saldo), el test salta. El sistema levanta una alerta dirigida directamente al dueño de ese plato. Y el plato no sale al comedor hasta que el Chef lo revisa.
Imaginad que tuvierais a alguien que probara cada plato antes de sacarlo al comedor. Que supiera exactamente a qué debería saber cada uno. Que nunca se cansara, que nunca se le olvidara una regla, y que cada noche revisara todos los platos sin excepción. Alguien — o algo — que garantizara que nada sale de la cocina sin pasar el control.
Y lo más importante: no pedimos que definan todas las reglas de golpe. Esto es iterativo. Se empieza por los indicadores que más duelen. Y cada vez que una incidencia llega (“¿por qué este número no cuadra?”), se convierte en una regla nueva para que no vuelva a pasar. Con el tiempo, el escudo de calidad crece solo, alimentado por la experiencia real.
El primer día, el chef tiene unas recetas básicas. Pero cada plato que sale mal, cada queja de un comensal, se convierte en una lección que se incorpora al sistema. “Desde aquel día, siempre comprobamos X antes de servir.”
Documentación Viva: el menú que nunca miente
Y aquí ocurre algo que no es evidente pero que a largo plazo es lo más valioso de todo.
Cuando las reglas de calidad de Negocio se convierten en tests que se ejecutan cada noche, la documentación cobra vida.
En el modelo tradicional, Negocio escribe un PDF que dice “Los contratos cancelados deben tener saldo cero.” Seis meses después, la política de la empresa cambia y se permite un saldo residual de hasta 5€ por temas de redondeo. El dato cambia. El PDF nadie lo actualiza. La documentación y la realidad se desincronizan para siempre.
En nuestro modelo, si el dato cambia, el test falla. El plato se para.
El Chef (Negocio) recibe la alerta, investiga y dice: “Ah, es verdad, cambiamos la política. Ahora se permiten hasta 5€.” Y actualiza la regla en su ficha. El equipo técnico actualiza el test con la nueva regla, y el plato sale.
¿Veis lo que ha pasado? El sistema te obliga a mantener la documentación actualizada. Si el negocio cambia y no actualizas la regla, el pipeline se queja. La regla (la documentación) y el dato (la realidad) están atados de forma indisoluble.
Nunca más un PDF obsoleto. Nunca más un “Paco sabe cómo se hace.”
Os cuento un ejemplo real (anonimizado). En un proyecto, la documentación decía que todos los registros de un determinado tipo de operación debían cumplir una regla concreta sobre uno de sus campos. La regla se llevó al sistema como un test automático. El primer día que se ejecutó, encontró más de 20.000 registros que no la cumplían.
¿Qué había pasado? El sistema origen había cambiado su lógica meses atrás. Nadie actualizó la documentación. Nadie lo sabía. Los datos llevaban meses sin cumplir una regla que todo el mundo daba por buena.
Con un test manual, esto habría pasado desapercibido indefinidamente. Con documentación viva, saltó el primer día.
Esa es la diferencia entre un gobierno del dato que es un PDF en SharePoint y un gobierno que es software ejecutable. El PDF dice cómo deberían ser las cosas. La documentación viva te dice cómo SON las cosas, cada día, y grita cuando dejan de coincidir.
Imaginad a alguien — o algo — que custodiara cada regla de negocio. Que cada noche comparara lo que dice la documentación con lo que dicen los datos. Y que si alguna vez dejaran de coincidir, no mirara hacia otro lado. Alguien que nunca olvida, nunca se cansa y nunca deja pasar un desfase sin reportarlo.
El círculo se cierra: “El que sabe, por fin puede”
Empezamos esta serie hace cinco semanas hablando de la Paradoja Centralista: “El que sabe (Negocio), no puede. El que puede (IT), no sabe.”
Mirad dónde estamos ahora. * Negocio (el Chef) escribe la Receta en su idioma (Semana 2). * IT (la Plataforma) construye la Despensa para almacenar el dato crudo y trazarlo (Semana 3). * La Plataforma ejecuta la mise en place para preparar los ingredientes sin acoplamiento (Semana 4). * Negocio entra al Buffet Libre, ve las Fachadas claras, y se monta su propio Data Mart (hoy). * Negocio define las reglas de calidad (“¿qué me haría desconfiar?”), y la Plataforma las ejecuta antes de servir (hoy).
El cuello de botella ha desaparecido.
IT ya no pica SQL a mano traduciendo Words ambiguos. IT construye y mantiene la mejor cocina del mundo. Y Negocio, por fin, cocina.
Los números
Para los que necesitan justificarlo ante un comité:
Sin Buffet Libre (tabla monolítica, todos acoplados): * Tiempo para añadir una columna al producto de datos: días a semanas (recalcular la tabla entera, validar que no rompe nada, coordinar con los 15 equipos que dependen de ella). * Impacto de un bug: global (si falla la tabla, fallan todos los dashboards de todos los departamentos). * Dependencia de IT: total (cada cambio pasa por la cola del equipo central).
Con Buffet Libre (Data Marts independientes, Fachadas, calidad de Negocio): * Tiempo para añadir una columna: horas (solo afecta al Data Mart del equipo que lo pide). * Impacto de un bug: localizado (solo afecta al plato que tiene el problema, los demás siguen funcionando). * Dependencia de IT: mínima (Negocio se monta su plato, define sus reglas, y el sistema ejecuta).
Y el número que importa más: la confianza. Cuando cada dato que sale de la cocina ha pasado por un control de calidad definido por el propio Negocio, la conversación cambia. Ya no es “no me fío de los datos.” Es “los datos han pasado mis propias reglas.” Y si algo falla, no es un misterio: es una alerta concreta, dirigida a la persona concreta, con el contexto concreto para investigar.
El emplatado no es un detalle estético. Es la diferencia entre una cocina que sirve y una cocina en la que nadie confía.
Lo que viene: del restaurante a la franquicia
Hasta ahora hemos recorrido la cocina de arriba a abajo: la Receta, la Despensa, la Mise en Place y el Emplatado. Hemos visto el qué y el por qué de cada capa. Si lo has seguido hasta aquí, tienes en la cabeza el restaurante completo: una receta firmada por Negocio, una despensa permanente y trazable, una mise en place desacoplada y un emplatado con sus reglas de calidad ejecutables. Tres mesas llenas cada noche, una pizza que se reconoce a dos calles, y una cocina que funciona como un reloj.
Pero siguen siendo tres mesas. Esa es la frontera.
Por mucho que el restaurante esté bien montado, un restaurante de tres estrellas no escala. La pizza la sigue haciendo el mismo chef. La receta vive en su cabeza. La despensa la conoce con los ojos cerrados. Si mañana la dirección decide abrir 38 sedes en seis países, ninguna de las cuatro piezas — tal como están — se replica directamente. Funcionan dentro del restaurante. Fuera, no escalan.
A partir de la semana que viene entramos en el siguiente bloque de la serie: cómo se convierte ese restaurante en franquicia. La misma Receta, la misma Despensa, la misma Mise en Place, el mismo Emplatado — pero industrializados, con las dependencias invertidas, con una central que distribuye lo común y unas sedes que componen lo local. Lo mismo que has visto estas cinco semanas, pero diseñado para que la pizza salga igual en Zúrich, en Tokio o en Lagos sin que el chef de Roma tenga que viajar.
La cocina está montada. La semana que viene abrimos la franquicia.
Pero antes de abrir la franquicia: