Qlik Sense e QlikView

Quien tiene Qlik rara vez quiere dejarlo.

Qlik suele llegar hasta nosotros por uno de dos caminos. O la empresa invirtió en él años atrás, el consultor que lo montó todo se fue, y ahora nadie entiende el script de carga que sostiene la operación. O el modelo asociativo es exactamente lo que el negocio necesita, y la discusión es cómo sacarle más.

En ambos casos el trabajo es el mismo: entender lo que ya existe antes de proponer nada. Un Qlik mal documentado es un activo caro que nadie puede evolucionar y reescribir desde cero rara vez es la respuesta más barata.

De la extracción a la app publicada

El camino es el mismo de cualquier proyecto serio de BI. Lo que cambia es la herramienta en cada etapa.

• Script de carga. La capa de ETL de Qlik, escrita para que otra persona la lea después: secciones nombradas, variables arriba, conexiones parametrizadas en lugar de rutas fijas repartidas por el código.
• Capa de QVD. Extracción y transformación separadas en etapas, con los datos intermedios persistidos. Es lo que hace que la recarga baje de horas a minutos y deja de golpear el sistema de origen cada vez.
• Modelo de datos. Modelo en estrella, claves sintéticas eliminadas y referencias circulares resueltas. El motor asociativo es rápido, pero no perdona un modelo mal montado.
• Expresiones y set analysis. Cada indicador definido una vez, con la regla de negocio registrada al lado. Comparativos de periodo y desgloses que no se rompen cuando el usuario filtra otra cosa.
• Construcción de la app. Una vista por perfil y una navegación que aprovecha lo mejor de Qlik: seguir el razonamiento de quien investiga, en lugar de obligarlo a volver al principio en cada pregunta.
• Publicación gobernada. Streams organizados, Section Access por perfil de acceso, recarga programada y traza conforme a la normativa de protección de datos.

QlikView y Qlik Sense no son lo mismo

QlikView entrega análisis guiado: el documento lo diseña quien lo construye, y el usuario navega dentro de lo previsto. Qlik Sense es self-service: el usuario monta sus propias visualizaciones sobre el modelo publicado.

Son filosofías distintas, y la elección no va de cuál es más nuevo. Operaciones con proceso cerrado y usuarios que necesitan respuesta rápida suelen funcionar mejor en el formato guiado. Equipos analíticos que exploran el dato por su cuenta rinden más en self-service. Atendemos los dos, y cuando tiene sentido migrar lo decimos y cuando no, también.

Qué te queda al final

La entrega termina cuando tu equipo puede evolucionar lo que construimos sin depender de nosotros.

• El script documentado. Comentado sección por sección, con el origen de cada tabla y el motivo de cada transformación.
• El diccionario de métricas. La regla de negocio de cada indicador escrita en lenguaje claro, no solo en set analysis.
• Formación del equipo. Para crear nuevas visualizaciones sobre el modelo existente sin romper lo que ya funciona.
• Plan de mantenimiento. Qué hacer cuando una fuente cambia de formato o la recarga empieza a tardar demasiado.

Cómo lo conducimos

Empezamos por un diagnóstico de lo que ya está en el aire: script, modelo, tiempo de recarga y qué apps abre la gente de verdad. En un entorno Qlik antiguo ese levantamiento suele revelar la mitad del trabajo de entrada y conviene saberlo antes de firmar. Después diseñamos la arquitectura y presentamos el alcance para su aprobación. La implementación ocurre en ciclos cortos, con la primera app en producción rápido.

Cómo medimos el resultado

Los indicadores de éxito se acuerdan al inicio, y son de negocio, no de herramienta. En nuestros proyectos los más frecuentes son horas de trabajo manual devueltas al equipo, reducción de pérdida operativa y ganancia de margen por segmento de cartera.

Hoy tenemos un seguimiento mucho más robusto, rápido y visual de los resultados de cada gerencia.

Dirección comercial distribuidora nacional de combustibles