- Los "self-serve dashboards" en realidad no funcionan bien, porque hacen que ingenieros o científicos de datos dediquen mucho tiempo a escribir consultas y preparar dashboards para usuarios de negocio.
Por qué no funciona el "self-serve BI"
- SQL es la única herramienta real de "self-serve BI". Pero la mayoría de los proveedores de "self-serve BI" intentan disfrazar SQL como otra cosa.
- Escribir consultas SQL no es la única barrera para que los stakeholders de negocio consulten datos. No entienden el significado de los datos, su origen ni cómo se calculan, y tampoco saben cómo interpretar y validar los resultados.
Intento 1: el enfoque tradicional de "menús desplegables y casillas de verificación"
- Esta interfaz no es más que un intento de hacer "SQL-by-mouse". No ofrece nada mejor que SQL; de hecho, es más lenta, menos confiable, más limitada y no se puede generalizar a otras herramientas.
- Personas como un CFO no van a usar esta interfaz para consultar datos, porque no tienen el contexto para entenderlos ni pueden tener confianza en los resultados.
Intento 2: el enfoque text-to-SQL
- Los LLM son casi demasiado eficaces para traducir lenguaje natural a SQL. Intentarán generar una consulta incluso cuando la pregunta no esté bien planteada.
- Un perfil técnico notaría que la pregunta no encaja y pediría más contexto. Explicaría los tipos de datos disponibles y colaboraría con el área de negocio para formular una pregunta precisa y útil.
- Los LLM podrían convertirse en la solución real para el "self-serve BI", pero no en su forma actual. Necesitan más contexto y deben ser más capaces de expresar incertidumbre y pedir más información.
Lo que sí funciona en la práctica
- El problema del "self-serve BI" no es SQL, sino el contexto y el significado de los datos. La solución, sin importar la interfaz, es enseñar a las personas sobre los datos que están consultando.
- Pedirle al equipo técnico que documente todo ese conocimiento genera una sobrecarga considerable y además se vuelve obsoleto rápidamente.
- La verdadera solución para el "self-serve BI" no es volver el BI de "autoservicio" para personas no técnicas, sino permitir que las personas técnicas usen mejores herramientas para apoyar a los stakeholders de negocio de forma más eficiente.
Propuestas para mejores herramientas:
- Dar LLM a perfiles técnicos, no a los stakeholders de negocio.
- Permitir que manipulen libremente los datos con herramientas cómodas como Python, R, etc.
- Facilitar que el personal técnico comparta fácilmente su trabajo. Los notebooks y las aplicaciones internas de datos son difíciles de compartir porque requieren manejar contenedores, dependencias e infraestructura.
1 comentarios
Comentarios de Hacker News
En una empresa donde hacían dashboards con una herramienta de BI, vieron que los números se veían raros y revisaron el generador de consultas, pero no había forma de saber si parte de la consulta era un inner join o un left join
Ni siquiera la analista de negocio que había creado ese dashboard lo sabía, y aunque en realidad se pretendía un inner join, se ejecutó un left join, así que los datos mostrados salían un orden de magnitud por encima de los reales
Desde entonces dejé de confiar en este tipo de capas de abstracción montadas sobre SQL para gente que no sabe SQL
Hay demasiada gente que puede acceder a los datos, pero no entiende los datos en sí, sus relaciones ni lo que significan los resultados que produce
En los últimos 25 años han aparecido como supuesta solución los ingenieros y científicos distribuidos/embebidos, los dashboards de autoservicio, las herramientas BI/de datos low-code, y ahora incluso texto→SQL/visualización con LLM, pero al final no han resuelto la falta de entendimiento de los datos ni el problema de confianza en los resultados
Aun así, SQL tampoco es la solución. Hay mucha gente que sabe suficiente SQL como para extraer datos, pero muy poca que además entienda la estructura y el esquema de los datos, así como su uso correcto
Aún no existe una herramienta que resuelva este problema fuera de la experiencia, y aunque quizá algún día los LLM puedan hacerlo, honestamente no parece muy probable
Los dashboards sirven para ver KPI rápido y profundizar, pero al final lo importante son las prácticas de gestión de datos y la capacidad de entender bien los datos/relaciones/métricas para convertir eso en insights de negocio
El futuro suena prometedor, pero como hasta ahora ninguna herramienta de próxima generación ha cumplido lo que prometía, ya no me resulta fácil creerles
Los valores predeterminados razonables y los mecanismos que te disparan en el pie son solo cuestión de perspectiva
He visto casos en grandes empresas donde, si un bug sutil o un diseño hace que los ingresos se vean más altos, nadie quiere tocarlo y cargar con la responsabilidad de una caída en ingresos
Por ejemplo, el botón del plan gratuito queda debajo del pliegue en una resolución promedio, o el cálculo del estado (
state) está mal y no se aplica un descuento, o a alguien se le olvidó unfalsey se exige registro aunque técnicamente no sea necesarioMe pregunto si aquí se sintió algo parecido, como miedo a que les echaran la culpa por la bajada de los números
Al implementar flujos lógicos complejos, lo difícil no es teclear código en un IDE, sino modelar el problema y diseñar algoritmos efectivos
Estas herramientas apuntan a usuarios no técnicos con la promesa de que no hace falta escribir código, pero esos usuarios siguen sin entender la parte compleja de diseñar la solución desde una perspectiva de ingeniería, así que se pierden o producen resultados incorrectos
Los intentos de escalar procesos de negocio complejos con herramientas no-code terminan chocando contra una pared tras mucho ensayo y error, y al final se le pasan a un ingeniero de verdad
Pero ese ingeniero tiene que trabajar habiendo perdido el soporte que se da por hecho al escribir código en un lenguaje de programación real
Una vez que quedas atrapado en un constructor visual de flujos, tener un repositorio compartido, control de versiones decente, revisión de código, pruebas automatizadas y CI/CD se vuelve casi imposible
Los usuarios por defecto solo ven las cosas desde su propia perspectiva, así que hay que ofrecer formas alternativas de verlas que también encajen con su manera de pensar
Conozco un producto que maneja la asistencia escolar de forma basada en tiempo, porque debe ser flexible para distintas combinaciones de horarios según escuela, campus y fecha, además de eventos deportivos, turnos sustitutos, actividades conjuntas y horarios rotativos de 14 días
Pero eso no significa que no se puedan crear vistas que compongan esa complejidad de horarios en asistencia por clase o asistencia por mañana/tarde
Es absurdo asumir que los usuarios de negocio no pueden aprender, o son demasiado impacientes para aprender, la relación entre sus preguntas, el modelo de datos y los menús desplegables
De hecho, por mi experiencia sí quieren aprender, pero muchas veces quienes modelan los datos no entienden suficientemente el dominio como para capturar los matices de las preguntas
Como resultado, con el pretexto de simplificar el autoservicio esconden esos matices, alargando el tiempo para obtener respuestas, o directamente los eliminan y terminan produciendo respuestas inexactas y engañosas
Tampoco me gusta el eufemismo no técnico. Entre los LLM, las herramientas BI de generación de consultas y SQL hay bastante espacio intermedio, así que no hace falta declarar que la barrera de capacidad es absoluta
Está bien volverse experto en computación, programación o análisis de datos, pero si es posible les digo que pongan en el centro el dominio en el que estudian o trabajan, y que desarrollen esas habilidades como algo secundario
La solución al problema de que el experto en dominio no entiende de datos y el experto en datos no entiende el dominio es que ambas cosas sean la misma persona
Parece que la incompetencia organizacional ha llegado a un nuevo nivel
Había una tira de Dilbert que criticaba las hojas de cálculo, y aplica igual para las herramientas BI y de IA
Era algo como: “Claro que la hoja de cálculo de esta presentación está llena de errores e información incorrecta. De todos modos, nadie volverá a verla a menos que refuerce una decisión que la dirección ya tomó”
En la realidad también abundan los reportes y dashboards rotos
A veces pasan meses, o incluso años, sin actualizarse en absoluto, y nadie se da cuenta mientras se siguen usando en procesos, decisiones y flujos de trabajo
También hay casos en que los datos no se actualizan, pero como se reordenan cada vez según la fecha/hora al ejecutar un pivote, no se nota que todo está gravemente roto
Y muchas veces todo tipo de fórmulas y “matemáticas” están completamente mal y producen números de fantasía
A medida que el mundo se alejó de los EDW y sistemas ERP centralizados, los problemas de datos se volvieron exponencialmente más difíciles, y el nivel de inversión simplemente no ha seguido ese ritmo
Durante los últimos 24 años se ha estado entregando datos a usuarios de negocio, ya fuera con una herramienta de consultas, MS Access, Power BI o cubos de datos de Excel, pero en la práctica solo los usa una minoría
Probablemente sean las mismas personas que ya hace 40 años sacaban datos de terminales y reportes impresos para analizarlos
Aun así, a los ejecutivos les encantan los tableros de indicadores clave, y las nuevas herramientas de BI hacen mucho más fácil crear y mantener dashboards de KPI
Puede tener un puesto como “asistente personal”, pero se las ingenia de maravilla con SharePoint Forms, Access y Excel para crear cosas impresionantes
Reconocer su talento e inteligencia y darles herramientas más potentes es excelente. A veces luego se van a un trabajo mejor, y eso también está bien
Las computadoras eran tan caras que el “departamento de cómputo” era un área separada dentro de la empresa; por ejemplo, si la división oeste necesitaba recursos de cómputo, hacía algo así como un contrato con el departamento que tenía el mainframe instalado en sitio
Nuestro grupo era un pequeño y ágil equipo interno de análisis que usaba nuevas y “baratas” minicomputadoras
Gracias a su estructura de financiamiento, la ventaja era que podíamos responder mucho más rápido a las necesidades de los usuarios
Un día, mientras caminaba por la planta, vi a un usuario recortar líneas de uno de esos reportes verdes con franjas que habíamos hecho, pegarlas en otra hoja y luego fotocopiarlas
Estaba reordenando el reporte con otro criterio, así que le dije: “¡Eso se lo podemos hacer nosotros!”, y la respuesta fue: “¿En serio?”
La gente que necesita terminar el trabajo lo termina como sea. El objetivo de un grupo de sistemas que da servicio a clientes internos es hacer ese proceso lo más eficiente posible
Otra persona estaba usando una PC, una tableta digitalizadora y AutoCAD para registrar puntos de siluetas de aeronaves y crear perfiles de radar
No era tanto el uso original de CAD, sino una forma ingeniosa de capturar datos de diagramas de Jane's Combat Aircraft
No pueden creer que esos datos ya estaban ahí
La integración es una operación de negocio necesaria, pero los datos fáciles de entender encantan de verdad a los interesados. Es un valor agregado muy sencillo
La interfaz de BI tradicional que aparece en el artículo es Metabase, y actualmente está entre las mejores interfaces para BI
Metabase permite ver el SQL generado por la GUI y también convertir esa consulta en SQL puro, así que es muy bueno para pasar del autoservicio a la gobernanza
Es fácil modificar y validar la lógica, y también les da a personas con menos habilidad técnica un camino para desarrollar capacidades
Aun así, el punto central del artículo es correcto. Incluso desde la perspectiva de alguien que trabaja profesionalmente con datos, rara vez las herramientas de BI logran dar a más personas una comprensión correcta de los datos o las habilidades necesarias para usarlos bien
Si los datos están bien gestionados, las herramientas son fáciles y la gente puede resolver cosas por su cuenta, pero el mundo es complejo y por eso los datos también lo son
El costo de gestión de datos se ve muy claramente, mientras que los beneficios no tanto
Llegué a una conclusión parecida sobre el “BI de autoservicio”, pero con una solución algo distinta
Creo que es mejor subir aún más el nivel de abstracción: crear dashboards muy personalizables, pero sin exponer SQL a los usuarios de negocio
Por ejemplo, un dashboard con 20 filtros, dimensiones de desglose y otros 20 parámetros para controlar los “supuestos utilizados”
Una pregunta como “quiero ver el rendimiento de los anuncios de Google del mes pasado por grupo de edad” se convierte en cambiar 3 o 4 listas desplegables predefinidas
Aquí los parámetros son clave, porque solo se exponen controles validados y no se permite SQL arbitrario
Claro, este tipo de dashboard es difícil de construir y requiere bastante experiencia en visualización con herramientas como Looker, Tableau o Excel, pero al final el 70% de las preguntas sí se vuelve autoservicio
Con el otro 30% es mejor no forzarlo, y se necesita a alguien que traduzca una pregunta de negocio en una pregunta de datos. Ese es un problema de personas
Entonces, cuando el CFO o quien sea necesite una respuesta para un periodo específico, solo abre ese dashboard y ajusta un poco los parámetros base
Usamos Metabase, el que aparece en la imagen, y en general los usuarios no técnicos sí lo usan de verdad
Algo que ayudó con la adopción fue abrir “horas de oficina” para mostrar en vivo ejemplos como “cómo sacar las ventas de cierta sucursal o estado”
No resolvió todos los problemas, consultas ni exportaciones, pero una parte considerable de las solicitudes que antes llegaban a ingeniería ahora ya no llega hasta esa instancia
Otra razón por la que Metabase es bueno es que puede hospedarse por cuenta propia y usar SSO de GSuite
La métrica clave no es “hay menos solicitudes de ayuda, así que los usuarios son más independientes”
Es muy probable que esos usuarios estén sacando e interpretando métricas completamente equivocadas
He visto repetidamente que, cuando usuarios con poca experiencia técnica acceden a los datos, creen que “no es tan difícil como parecía” y empiezan a construir una pirámide de análisis incorrectos
Un análisis correcto siempre necesita contexto
Por ejemplo, en ingresos recurrentes no se debe usar la fecha de envío para calcular los ingresos mensuales, porque el equipo de finanzas vuelve a completar las fechas de envío
El precio de catálogo se guarda en USD, pero en la práctica el tipo de cambio se ajusta cada mes según la tabla
monthly_discountPor la convención de mostrar inventario no vendido del año anterior, los ítems con fecha de compra null deben excluirse del reporte de ventas
Como el precio está en moneda local, no se deben sumar ventas sin unir antes la tabla de tipos de cambio
Lo configuré para las personas no programadoras de la empresa y, siendo honesto, casi no lo usan para algo más que ver los dashboards que yo ya dejé hechos, pero la respuesta fue buena
De verdad es una herramienta útil
Siempre me causa gracia que altos directivos ganen fortunas y aun así no sepan correr consultas SQL en BI
Se supone que SQL se hizo originalmente para que los directivos pudieran consultar datos más fácilmente
Como exvendedor/exgerente, no siento mucha simpatía por ese tipo de gente
Pero no lo hace él mismo. Porque entiende principios económicos básicos
Aunque pueda hacer en medio día algo que a otra persona le tomaría 3 días, ese medio día es tiempo en el que no está haciendo algo que solo el CEO puede hacer
Un CxO competente también sabe que la parte que de verdad consume tiempo está en dejar los detalles perfectamente ajustados
Rarezas en el manejo de
null, tratamiento de fechas y uniones que no encajan: aunque SQL sea de “alto nivel”, obtener una respuesta confiable requiere tiempo y concentraciónSi hay alguien que se dedica a eso, lo correcto es encargárselo
Creo que los dashboards de BI pueden funcionar bien para consultas muy simples
Si ya estás en el punto de pedirle a un usuario no técnico que haga joins de datos, ya te fuiste demasiado al fondo, y en ese momento mejor usar SQL
Los joins pueden parecer algo básico para algunas personas, pero a mí también a veces me cuesta entenderlos, y en una UI de dashboard menos expresiva que SQL son una combinación que genera confusión
Al final es un compromiso. Se puede hacer algo más accesible que SQL para usuarios no técnicos, pero inevitablemente será menos potente que SQL
Aun así, hay mucha utilidad en ese espacio intermedio. De hecho, una buena parte del “BI” real es del tipo “aquí hay doce columnas de datos, grafícame una contra otra”
El autor dice que SQL es la única herramienta de BI “self-service”, pero sinceramente yo diría que es Excel
Muchas herramientas de BI se parecen más a rehacer Excel con una interfaz nueva y por eso menos familiar
Creo que el meme de odiar Excel viene de experiencias pasadas intentando hacer cosas complejas en Excel
Si la manipulación compleja de datos se hace en SQL y el “muéstrame esto como un gráfico circular” se hace en Excel, puede que de verdad no haga falta una herramienta de BI
Si la fuente de datos base está bien depurada, transformada y con buen control de acceso, se puede llegar sorprendentemente lejos solo con VLOOKUP y tablas dinámicas
Darle opciones de autoservicio a usuarios no técnicos cuando hay más de una fuente de datos siempre termina en mezclar datos offline
Y luego llega la pregunta de “equipo de datos, ¿por qué los datos de ‘ustedes’ no cuadran con ‘mis’ datos?”, siempre partiendo de que los suyos son los correctos
El problema central es que las herramientas modernas son distintas de los escritorios clásicos como las estaciones de trabajo Smalltalk o Emacs
Esos entornos eran un solo entorno completamente integrado, donde todo estaba en manos del usuario y el concepto de programación para usuario final venía incorporado
En org-mode puedes hacer diapositivas presentables en un instante, escribir y ejecutar fragmentos de código rápidamente y obtener resultados
Pero desde la perspectiva de dashboards tiene limitaciones grandes. Puedes graficar datos rápido, pero el resultado se parece más a una imagen estática y tosca; y si quieres algo elegante con PGF/TikZ, toma demasiado tiempo como para ser una opción realista, y además sigue siendo estático
Emacs en sí es la herramienta correcta, pero es una herramienta de otra época
Las herramientas modernas ofrecen interfaces más vistosas y operaciones más rápidas, pero están encerradas en UIs muy limitadas, poco flexibles y que tampoco se integran con otras cosas
Puede que R, junto con RStudio/quarto, sea la forma más rápida de crear contenido rápido, medio desordenado pero visualmente agradable, aunque sigue estando muy lejos de la flexibilidad de Emacs
En última instancia, no parece haber solución salvo reescribir todo el stack de software moderno sobre la base del paradigma clásico y el rendimiento del hardware moderno