- 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
Opinión de Hacker News
Problemas con las herramientas de BI: Al usar herramientas de BI, he tenido experiencias en las que la forma de hacer los joins en las consultas estaba mal configurada y los datos se mostraban incorrectamente. Eso me hizo perder la confianza en la capa de abstracción para personas que no conocen bien SQL.
Utilidad de Text-to-SQL: Sigue siendo útil para desarrolladores, pero para quienes no son desarrolladores existe la posibilidad de que se generen consultas incorrectas porque no entienden bien la estructura de la base de datos.
Incompetencia institucional: En la práctica se usan herramientas de BI y herramientas de IA con errores, así como reportes que contienen información incorrecta, algo que también fue criticado de forma similar en la caricatura de Dilbert.
Capacidad de aprendizaje de los usuarios de negocio: Es incorrecto asumir que los usuarios de negocio no pueden entender el modelo de datos y la relación con los menús desplegables. El problema surge porque el modelador de datos no entiende bien el dominio.
Experiencia entregando datos: A lo largo de 24 años entregando datos, he visto que solo una minoría de usuarios realmente usa las herramientas, y que la dirección prefiere dashboards de KPI.
Ventajas de Metabase: Metabase ofrece una buena interfaz entre las herramientas de BI, y permite convertir el SQL generado por la GUI en SQL puro, así que incluso personas con menor nivel técnico pueden usarlo con facilidad.
Límites del BI de autoservicio: Hay que reconocer los límites del BI de autoservicio, y la solución es crear dashboards personalizados que no expongan SQL a los usuarios de negocio.
Experiencia usando Metabase: Al usar Metabase y enseñarles a los usuarios no técnicos mediante "horario de oficina" cómo utilizarlo, muchas solicitudes dejaron de escalar al equipo de ingeniería.
La ironía de usar SQL: Es irónico que los altos directivos no puedan ejecutar consultas SQL. SQL originalmente se creó para que los gerentes pudieran consultar datos con facilidad.
Dificultad del ETL: Para usuarios no técnicos, tratar con datos en ETL es aún más difícil que en BI. Al desarrollar AWS Glue, quedó claro que los usuarios técnicos necesitan herramientas para poder depurar problemas.