Pensá en una reunión comercial de un lunes. Alguien pregunta qué clientes compraron menos que el mes anterior y a cuáles conviene llamar primero. Las facturas están en el sistema de gestión. Los responsables de cada cuenta están en el CRM. Para cruzar ambas cosas hay que pedir un reporte. La solicitud entra en la cola de TI y la respuesta llega el viernes, cuando el equipo ya organizó sus visitas con la información que tenía.
Esa espera aparece una y otra vez en nuestros diagnósticos. La empresa registra lo que pasa, pero tarda demasiado en convertirlo en una respuesta que alguien pueda usar. El costo aparece en el trabajo de preparar el reporte y en las decisiones que se toman mientras se lo espera.
La cola de reportes termina decidiendo las prioridades
Quien pide el dato suele ver una pregunta sencilla. Quien lo prepara tiene que identificar las tablas correctas, revisar cómo se relacionan, aplicar filtros y comprobar que el resultado tenga sentido. Si además mantiene integraciones y resuelve incidentes, cada pedido compite con el resto de su trabajo. Una pregunta comercial termina convertida en un ticket técnico.
Cuando la espera se vuelve habitual, cada área arma su propia planilla. Comercial cuenta pedidos; Finanzas, facturas; Operaciones, entregas. Los tres pueden llamar “ventas” a su número y obtener resultados distintos. Parte de la reunión siguiente se consume en discutir cuál es el correcto.
Esa dependencia también concentra conocimiento. Una persona sabe qué tabla está actualizada, qué clientes están duplicados y qué ajuste hace falta para que el total coincida con el cierre. Su criterio es valioso. Convertirlo en un requisito para cada consulta rutinaria limita la capacidad de toda la organización.
Cuánto cuesta esperar una respuesta
Para dimensionar el problema conviene registrar qué se está esperando: qué pregunta originó cada solicitud, cuánto lleva abierta y qué decisión depende de ella. Después se puede separar el tiempo de preparación del reporte del impacto de recibirlo tarde.
En uno de nuestros assessments documentamos 47 tickets de reportes pendientes, con una valoración estimada de USD 300 a 600 por ticket: aproximadamente USD 14.000 a 28.000 acumulados en el backlog.
En una empresa de energía encontramos USD 128.000 de capital avanzado inmovilizado por demoras en reportes. Dinero que la empresa ya había comprometido y no podía volver a utilizar mientras esperaba la información.
La cuenta empieza con las solicitudes que se acumulan en tu equipo: cuánto trabajo demanda resolverlas, qué decisión quedó pendiente y desde cuándo. Revisar esa lista con quien pidió cada reporte permite ver qué conviene resolver primero.
Una respuesta útil muestra de dónde salió
Con AskYourData, el equipo consulta los datos en lenguaje natural. La persona de Comercial puede preguntar “¿qué clientes bajaron sus compras respecto del mes anterior?” y explorar la respuesta por zona, vendedor o período, sin escribir SQL ni abrir un ticket para cada consulta habitual.
Para responder bien hay que precisar qué significa “compras”: pedidos confirmados, facturación neta o entregas. También hay que definir si se comparan meses completos o períodos equivalentes. Si la pregunta deja eso abierto, el asistente debe pedir una aclaración o mostrar la definición acordada que está usando.
Una respuesta útil incluye el período consultado, los filtros aplicados y una forma de revisar los datos de origen. Así, quien recibe una lista de clientes puede comprobar qué se contó antes de decidir a quién llamar.
La fecha de actualización también forma parte de la respuesta. Permite decidir si el dato alcanza para la decisión de hoy o hace falta consultar la fuente de nuevo.
El trabajo empieza por acordar qué significa cada número
La primera tarea consiste en elegir preguntas concretas y acordar con el negocio cómo se calculan sus respuestas. Qué se considera un cliente activo, cómo se descuentan las devoluciones, qué moneda se utiliza y quién mantiene cada definición. Ese trabajo permite que una misma pregunta conserve el mismo significado para distintas personas.
Después se preparan los accesos a las fuentes necesarias: se revisa la calidad de los registros, se configuran los conectores y se acuerda cómo mantener los datos actualizados. Ese trabajo deja listas las fuentes que va a consultar el equipo.
TI y el equipo de datos siguen siendo responsables de las fuentes, las reglas y los permisos. El cambio buscado es que puedan dedicar más tiempo a mantener esa base y menos a repetir consultas. El acceso del asistente debe limitarse a los datos autorizados para cada usuario. Para un caso de consulta, el punto de partida son accesos de solo lectura, con registro de las operaciones.
Si la empresa ya tiene tableros que resuelven bien una pregunta recurrente, conviene aprovecharlos. La consulta conversacional puede complementar ese trabajo cuando aparecen preguntas o desgloses que el tablero todavía no cubre. La decisión depende de la necesidad concreta y de las herramientas que ya funcionan.
Una primera versión con preguntas que se puedan comprobar
En ZirconTech organizamos este trabajo con ZirconTrace. El diagnóstico selecciona las fuentes y preguntas prioritarias y registra cómo se resuelven hoy. El diseño acuerda definiciones, accesos y criterios de aceptación. Durante la construcción se comparan las respuestas con resultados revisados por el equipo de datos. La puesta en producción incluye capacitación; la operación posterior revisa errores, consultas sin respuesta y cambios en las fuentes.
Planificamos una primera versión en producción en 4 a 6 semanas, con las fuentes, accesos y preguntas priorizados en el diagnóstico. Empezamos por las consultas que más trabajo generan y ampliamos la cobertura a partir del uso del equipo.
Para saber si sirve, medimos el tiempo desde la pregunta hasta una respuesta utilizable, las consultas que el equipo puede resolver sin un ticket y las correcciones necesarias. También comprobamos que cada respuesta respete los permisos y permita revisar el cálculo.
Lo que muestran nuestros assessments
En las empresas que evaluamos, el 68% reportó la lentitud de los reportes como un problema activo. En el 65% de los casos relevados de este problema, la demora afectaba decisiones comerciales semanales. Y el 91% de las propuestas de AskYourData fue seleccionado como prioridad de implementación, la tasa más alta de nuestro portfolio.
Cuando las empresas ponen en números el costo de esperar información, el acceso a los datos gana peso en la decisión de qué resolver primero.
El diagnóstico permite elegir por dónde empezar: mejorar un reporte existente, ordenar una fuente de datos o dar acceso directo a las consultas que hoy dependen de TI. La prioridad sale de las decisiones que el negocio necesita tomar.
Qué tecnología lo habilita
La arquitectura de referencia de AskYourData utiliza modelos disponibles en Amazon Bedrock para interpretar las preguntas y elaborar respuestas a partir de resultados consultados. Para acceder a los datos se elige el motor adecuado a las fuentes; por ejemplo, Amazon Athena permite consultar datos en S3 y acceder a otras fuentes mediante conectores compatibles.
La combinación se define en el diseño. Los cálculos deben ejecutarse sobre las fuentes aprobadas, con permisos, límites de consulta y validación del resultado. La redacción del modelo se apoya en ese resultado; la aplicación debe conservar la información necesaria para revisarlo.
El siguiente paso
Elegí una pregunta que tu equipo haya necesitado responder esta semana. Anotá quién la pidió, qué decisión dependía de ella y cuánto tardó en llegar una respuesta utilizable. Ese recorrido ofrece un punto de partida concreto para evaluar el problema.
En una reunión de diagnóstico de 60 a 90 minutos revisamos esas preguntas, las fuentes disponibles y las opciones para resolverlas. El objetivo es acordar un primer alcance y cómo comprobar su valor. En esa misma conversación podemos evaluar si aplica financiamiento del assessment a través de AWS.
