Preguntas de entrevista para Analista de Business Intelligence

Respuesta modelo

Diseñé el modelo de siniestros y pólizas de una aseguradora. Empecé por la granularidad, que es la decisión que condiciona todo lo demás: elegí el movimiento de siniestro, no el siniestro cerrado, porque el negocio necesitaba ver la evolución de la provisión mes a mes y con el grano agregado esa historia se perdía. Sobre esa base monté tres tablas de hechos, siniestros, recibos y reservas, y dieciocho dimensiones conformadas, con cliente, póliza y mediador historificados en SCD tipo 2 y claves subrogadas, de manera que un cambio de mediador no reescribiera el pasado. La carga la construí en dbt sobre Snowflake, con modelos incrementales por fecha de efecto y tests de unicidad y de integridad referencial en cada capa. Por encima expuse un modelo semántico en Power BI con las medidas oficiales de prima devengada, siniestralidad y ratio combinado, más seguridad a nivel de fila por dirección territorial. Descarté un modelo en copo de nieve, que era más elegante en el papel, porque obligaba a la gente de negocio a entender seis saltos de relación para hacer un filtro sencillo.

Respuesta modelo

Parto de que ese conflicto casi nunca es técnico, sino de definición no escrita. Lo primero que hago es documentar las versiones existentes sin juzgarlas: recojo las fórmulas reales que usa cada área, las ejecuto sobre el mismo periodo y llevo a la reunión la tabla con las diferencias y su origen, que suele estar en el criterio de fecha, en las anulaciones o en el perímetro de sociedades. Después propongo una definición única y, sobre todo, un propietario de negocio que responda por ella; el equipo de datos no puede ser el dueño de una métrica que no gestiona. Lo que se acuerda entra en el diccionario corporativo con fórmula, origen, propietario y fecha de revisión, se implementa una sola vez como medida en la capa semántica y se marca el informe como certificado. Si un área necesita una variante legítima, la creo con nombre distinto y explícito, por ejemplo prima devengada sin cartera cedida, en lugar de dejar dos cosas distintas llamándose igual. En mi último puesto ese proceso dejó 120 métricas documentadas, 34 informes certificados y 61 retirados.

Respuesta modelo

Porque me interesa más el sistema que la respuesta puntual. He trabajado en ambos lados y disfruto explicando una desviación al comité, pero lo que me engancha es lo anterior: que la pregunta se pueda responder sin discusión previa sobre qué significa cada cifra. Un análisis excelente sobre un dato sin gobernar se discute media hora y no se aplica. Cuando el modelo está bien construido, la conversación empieza en la decisión, no en la conciliación. Mi trabajo es que la persona de negocio abra un informe certificado a las siete y media de la mañana, se fíe de él y no necesite llamarme. Dicho de otro modo, el analista responde preguntas y yo construyo el sistema en el que esas preguntas se pueden responder; ambas cosas hacen falta, pero yo aporto más valor en la segunda.

Respuesta modelo

Aplico tres criterios. Primero, la reutilización: si una regla de negocio es transversal, como la homogeneización del perímetro de sociedades o la clasificación de un producto, la resuelvo en el almacén con dbt para que cualquier consumidor la herede, incluida una consulta directa por SQL. Segundo, la dependencia del contexto: todo lo que cambia según lo que el usuario filtre, como acumulados del ejercicio, comparativas interanuales o participaciones sobre el total, tiene que ser una medida DAX, porque materializarlo obliga a precalcular combinaciones que nunca se cierran. Tercero, el coste y el volumen: si una agregación se recalcula continuamente sobre cientos de millones de filas, la precalculo aunque sea contextual y la expongo mediante agregaciones. Como regla de oro, prefiero un almacén con lógica de negocio explícita y versionada, y una capa semántica delgada, legible y con nombres que el negocio reconozca.

Respuesta modelo

Asumiendo que si alguien se monta un Excel paralelo es porque mi modelo no le sirve, y averiguando por qué. En la práctica suele ser una de tres razones: falta un campo, el informe va lento o nadie le enseñó a usarlo. Las tres se arreglan. Yo trabajo con un ciclo corto: reúno las peticiones recurrentes, incorporo al modelo lo que se repite, publico el cambio documentado y aviso. Después está la habilitación, que es tan importante como el modelo: sesiones cortas por área con sus propios datos, una guía de estilo de informes de dos páginas y un canal donde respondo dudas en el día. Y por último la señal de confianza, que es la certificación visible en la herramienta, junto con la retirada de los informes antiguos, porque mientras el duplicado siga publicado alguien lo seguirá usando. Con ese método pasé de tres informes creados por negocio a cuarenta y siete en un año, y las peticiones ad hoc bajaron un 45 %.

Respuesta modelo

Migramos de SSIS y SQL Server local a Snowflake con dbt, en once meses y sin parar la operación. Lo que salió mal fue exactamente lo que subestimé: la equivalencia funcional. Cargamos primero en paralelo los dos entornos durante dos meses y comparamos automáticamente cifra a cifra; aparecieron 34 diferencias, y solo cuatro eran errores míos. Las demás eran reglas de negocio no documentadas que vivían en procedimientos almacenados de 2014, incluidas dos exclusiones de cartera que nadie recordaba haber pedido. Convertir esa arqueología en reglas explícitas, con propietario y test, fue el verdadero trabajo del proyecto. La segunda lección fue de coste: el primer mes en Snowflake se disparó porque dejamos almacenes encendidos y modelos recalculando completos; lo corregimos con materialización incremental, dimensionado por carga y suspensión automática, y cerramos un 38 % por debajo del entorno anterior. Y la tercera, de proceso: congelar funcionalidades durante el paralelo, porque cada cambio en el origen durante la migración cuesta el doble.

Por defecto, estrella. El motor VertiPaq de Power BI comprime muy bien columnas de baja cardinalidad y resuelve con eficacia las relaciones uno a muchos desde dimensiones pequeñas hacia un hecho grande, y sobre todo el negocio entiende el diagrama sin ayuda. El copo de nieve lo acepto cuando una dimensión es enorme y muy repetitiva, o cuando el sistema de origen ya la entrega normalizada y desnormalizarla obligaría a un mantenimiento constante; el precio es un salto de relación más y más confusión para el usuario. La tabla plana solo la defiendo en dos casos: un modelo pequeño de un único proceso, o una vista de exportación pensada para que alguien la descargue. En un modelo corporativo, la tabla plana multiplica el almacenamiento por la repetición de atributos, impide reutilizar dimensiones entre hechos y hace imposible una tabla de calendario común, que es justo lo que da coherencia a todos los informes.

La granularidad es qué representa exactamente una fila del hecho, y se declara antes de escribir una sola línea de SQL: si es el movimiento de siniestro, cada fila es un movimiento con su fecha, y no un siniestro completo. Elegir un grano demasiado agregado ahorra espacio y cierra puertas para siempre. La clave subrogada es un identificador propio del almacén, independiente del código del sistema de origen, que permite sobrevivir a fusiones de sistemas, a recodificaciones y a orígenes duplicados. El SCD tipo 2 sirve para conservar la historia de una dimensión: cuando un cliente cambia de segmento o una póliza de mediador, no se sobrescribe el atributo, se cierra la fila vigente con su fecha de fin y se abre otra nueva. Gracias a eso una venta de 2023 sigue atribuida al mediador que la hizo. Si sobrescribiera, tipo 1, la comparativa interanual cambiaría cada vez que alguien reorganiza la red comercial, y ese es un fallo que se detecta tarde y destruye la confianza en el almacén.

Organizo el proyecto en tres capas: staging con un modelo por origen, renombrado y tipado, sin lógica de negocio; intermedia con las reglas de negocio y las conciliaciones; y marts con los hechos y dimensiones que consume BI. Uso la función ref para que dbt construya solo el grafo de dependencias y el linaje, que es lo que después me permite responder en dos minutos a qué informes afecta un cambio en un origen. Los modelos incrementales los aplico a los hechos grandes, con una ventana de reproceso de varios días para recoger llegadas tardías y una estrategia de merge por clave; el reproceso completo lo dejo programado en fin de semana. En pruebas, los básicos de unicidad, no nulo, valores aceptados y relaciones entre tablas cubren la mayor parte de los incidentes, y añado pruebas propias para reglas de negocio, como que la suma de recibos cuadre con la contabilidad dentro de una tolerancia. Los snapshots los reservo para historificar dimensiones cuando el origen no guarda su propia historia, y las exposures para declarar qué informes dependen de qué modelo.

El contexto de fila existe cuando se evalúa fila a fila, por ejemplo en una columna calculada o dentro de un iterador como SUMX, y da acceso a los valores de esa fila concreta. El contexto de filtro es el conjunto de filtros activos que restringen el modelo cuando se evalúa una medida: los que vienen del gráfico, de los segmentadores y de la propia medida. CALCULATE es central porque es la única función que modifica el contexto de filtro, y además transforma el contexto de fila en contexto de filtro, que es la razón por la que funciona una relación entre tablas dentro de un iterador. En la práctica, CALCULATE es lo que permite escribir ventas del mismo periodo del año anterior o participación sobre el total de la categoría sin duplicar tablas. El error típico es crear columnas calculadas para lo que debería ser una medida: la columna se materializa, ocupa memoria y queda congelada al margen de lo que filtre el usuario, mientras que la medida se recalcula en su contexto. Y las relaciones bidireccionales las evito salvo necesidad demostrada, porque introducen ambigüedad y filtros que nadie espera.

En el ETL clásico la transformación ocurre en un servidor intermedio, con SSIS, Talend o Informatica, y solo llega al almacén el resultado final. Con los almacenes en la nube, el cómputo es elástico y barato en comparación, así que resulta más eficaz cargar el dato en bruto y transformarlo dentro, con SQL versionado. Las ventajas prácticas son tres: se conserva el dato original para poder reprocesar sin volver a pedirlo al sistema de origen, la lógica queda en Git con revisión y pruebas en lugar de dentro de una caja gráfica, y se escala el cómputo solo cuando hace falta. La repetibilidad la consigo con cargas idempotentes: cada ejecución sobre la misma ventana temporal deja el mismo resultado, mediante merge por clave o borrado e inserción de la partición completa, nunca con inserciones ciegas. Añado marcas de tiempo de carga y de origen para poder auditar cualquier fila. Dicho esto, el ELT no es siempre la respuesta: si el origen es un sistema transaccional frágil o hay que aplicar seudonimización antes de que el dato personal aterrice en la nube, mantengo esa transformación aguas arriba por diseño y por cumplimiento del RGPD.

Primero mido en lugar de suponer, con el analizador de rendimiento y con las estadísticas del modelo, para saber si el problema está en la consulta de almacenamiento, en la fórmula o en el propio informe. Las causas más frecuentes son cuatro. Cardinalidad excesiva: columnas de texto muy únicas, identificadores o marcas de tiempo al segundo que impiden comprimir; se solucionan separando fecha y hora y eliminando columnas que nadie usa, que suelen ser muchas. Modelo mal diseñado: relaciones muchos a muchos, bidireccionales o una tabla plana gigantesca. Medidas ineficientes: iteradores anidados sobre el hecho completo o cálculos que deberían estar precalculados en el almacén. Y el informe: una página con veinte objetos visuales lanza veinte consultas. A partir de ahí actúo por orden de coste: limpiar columnas, corregir el modelo, precalcular agregaciones para los niveles más consultados y activar el refresco incremental para no recargar la historia entera cada noche. En el último caso, esa combinación bajó la ventana de refresco de 3 h 40 min a 22 min y el informe de dirección pasó a estar listo a las 7:30.

La seguridad a nivel de fila la implemento con una tabla de asignación entre usuario y ámbito, por ejemplo dirección territorial u oficina, en lugar de escribir reglas fijas por rol, porque así los cambios de organización se resuelven con un dato y no con un despliegue. La regla filtra la dimensión y se propaga al hecho, y siempre la pruebo suplantando a un usuario de cada perfil antes de publicar. Cuando hay atributos que ciertos perfiles no deben ver siquiera como columna, uso seguridad a nivel de objeto. En cuanto al RGPD y la LOPDGDD, parto de la minimización: al almacén analítico no llega el dato personal que no aporta nada al análisis. Lo que sí se necesita se seudonimiza, con la tabla de correspondencia en un ámbito restringido, y los identificadores directos quedan fuera de los modelos de consumo. Añado el registro de accesos, la política de conservación por tipo de dato y la documentación del linaje, que es lo que permite responder a un derecho de supresión sabiendo en qué tablas y en qué informes aparece esa persona. En seguros y banca eso no es opcional: es lo primero que revisa la auditoría interna.

En la sala no discuto la cifra ni defiendo el modelo: pido treinta segundos para anotar de qué informe procede cada número y propongo traer la conciliación al día siguiente, porque una discusión técnica en un comité no la gana nadie y se pierde la reunión. Después reproduzco ambos cálculos sobre el mismo periodo y busco el origen de la diferencia, que casi siempre está en el criterio de actividad, en la fecha de corte o en la inclusión de bajas del mes. Preparo una única página con las dos definiciones, la diferencia en cifras y una propuesta de definición común, y la llevo primero a los dos responsables por separado para que ninguno se sienta desautorizado en público. Cuando hay acuerdo, la métrica entra en el diccionario con propietario, se implementa una sola vez en la capa semántica, se certifica el informe correcto y se retira el otro. Si ambas definiciones son legítimas, creo las dos con nombres distintos y explícitos, porque el problema no era tener dos medidas, sino que las dos se llamaran igual.

Lo primero es comunicar antes de que lo descubran: aviso en el canal correspondiente indicando qué informes están afectados, con qué fecha de dato se están viendo y cuándo daré la siguiente actualización. Mucho peor que un dato tardío es un dato antiguo que parece actual, así que marco la fecha de última actualización de forma visible en el informe. En paralelo diagnostico, y suelo ir por orden de probabilidad: origen no disponible, cambio de esquema en el sistema de origen, credencial o pasarela caída, o un test de calidad que ha bloqueado la carga a propósito. Si el fallo es de un origen secundario, relanzo solo el subgrafo afectado, que gracias al linaje de dbt está acotado, y publico con una nota sobre el ámbito incompleto. Si el bloqueo es un test que detectó datos incorrectos, no lo desactivo para salir del paso: publico el dato correcto disponible y explico qué falta. Después, la parte que evita la repetición: análisis del incidente por escrito, alerta automática de fallo, reintento programado y, si el origen es recurrente en incidencias, un acuerdo de entrega con el equipo responsable.

Lo tomo como un síntoma, no como un desafío. Le pido media hora para ver con él lo que hace en su día a día, porque en esa media hora suelen aparecer las dos causas reales: falta un atributo o un nivel de detalle, o hay un informe concreto que tarda demasiado. Si falta información, valoro incorporarla al modelo común, que casi siempre beneficia a más áreas; si es rendimiento, lo mido y lo corrijo, normalmente con agregaciones o limpiando el informe. Lo que intento evitar es el modelo paralelo, y lo explico en su idioma: en cuanto exista, sus cifras y las del resto de la casa divergirán, y será él quien tenga que justificarlas en el comité. Si aun así necesita autonomía inmediata, propongo una salida intermedia y controlada: un espacio de trabajo propio conectado al modelo certificado, de modo que pueda construir lo que quiera sin duplicar la lógica de negocio, con el compromiso de revisar en un mes si lo que ha creado debe incorporarse al modelo corporativo.

Empiezo por acotar el alcance con el auditor: qué informe, qué campos y qué periodo, porque documentar todo a la vez es la forma más segura de no entregar nada. Después reconstruyo el linaje desde el consumo hacia el origen, apoyándome en el grafo de dependencias del proyecto de transformación, que está actualizado aunque el documento de Word no lo esté, y lo contrasto con el código para cada campo crítico. Entrego una ficha por campo con origen, transformaciones aplicadas, regla de negocio, propietario y fecha de última modificación. Lo que no puedo justificar lo digo explícitamente en lugar de rellenarlo, porque una laguna reconocida se corrige y una inventada se convierte en una observación grave. Y cierro con la medida estructural: generar la documentación desde el propio proyecto en cada despliegue, para que el linaje deje de ser un documento que envejece y pase a ser una salida automática del sistema. En la práctica, ese cambio es también el argumento con el que se consigue tiempo del equipo para hacerlo bien.

No digo que no, digo qué cabe. Presento el alcance por dominios y no por porcentaje del total: en seis meses, con el equipo actual, es viable migrar los dominios comercial y financiero, que son los que más consultan las direcciones, manteniendo BW en paralelo para el resto. Acompaño la propuesta de tres condiciones explícitas: congelar funcionalidades en los dominios migrados durante el periodo de paralelo, disponer de una persona de negocio por dominio para validar cifras, y aceptar dos meses de doble carga con comparación automática antes de apagar nada. Cuantifico también lo que no se hará si todo el equipo entra en la migración, porque el mantenimiento diario no desaparece. Y propongo un criterio de éxito medible y acordado de antemano, por ejemplo cero diferencias no explicadas en los informes migrados y una ventana de refresco por debajo de la actual. Si tras esa conversación la dirección mantiene el plazo completo, dejo por escrito el riesgo y las alternativas, que es la manera profesional de discrepar.