Una incidencia ciudadana parece un dato: una categoría, una fotografía y unas coordenadas. En realidad es la primera huella de un proceso que debe validar, asignar, resolver y dejar rastro. Antes de abrir un dashboard hay que decidir qué se guarda, cómo se representa cada transición y qué historia podrá reconstruirse. Si el dato nace sin contexto, el gráfico no descubre la ciudad: maquilla el fallo del sistema.
Un vecino encuentra un contenedor desbordado. Hace una fotografía, permite que el móvil obtenga su ubicación y pulsa «Enviar».
Para él, el trabajo ha terminado.
Para el Ayuntamiento, la incidencia acaba de empezar.
Al otro lado hay que validar la posición, interpretar el problema, comprobar si ya existe otro aviso, decidir quién debe atenderlo, asignarlo, comunicar su evolución y dejar constancia de lo realizado.
La aplicación captura el aviso. El servicio público gestiona la incidencia.
Y, cuando se acumulan miles de registros, aparece otra tentación.
Exportamos los registros, agrupamos por categoría y dibujamos un gráfico. «Contenedores» aparece en primer lugar. «Parques y jardines», después. La categoría «Otros» ocupa una porción incómodamente grande.
Entonces pronunciamos una frase peligrosa: «los datos hablan».
No hablan.
Todavía no sabemos si existen más problemas con los contenedores, si son más visibles, si resultan más fáciles de fotografiar o si la ciudadanía ha aprendido que ese tipo de aviso sí obtiene respuesta.
Un análisis exploratorio de datos —un EDA— no consiste en llenar un notebook de gráficos.
Consiste en separar lo que sabemos, lo que suponemos y lo que los datos todavía no permiten responder.
TL;DR
Una incidencia útil permite reconstruir qué ocurrió, dónde, cuándo, quién debía actuar, qué se hizo y cuánto tiempo consumió cada etapa. Un conjunto de incidencias permite estudiar volumen, tiempos, recurrencias y calidad, pero también refleja adopción digital, decisiones administrativas y sesgos. Por eso el análisis no empieza evaluando la ciudad: empieza evaluando el sistema que produce sus datos.
El botón «Enviar» no cierra nada
Desarrollo y mantengo aplicaciones municipales desde 2014. Durante años hablamos de apps móviles, notificaciones, mapas y backoffices. Hoy agrupamos todo aquello bajo la etiqueta GovTech, pero el problema de fondo no ha cambiado: conectar una necesidad que aparece en la calle con una organización capaz de responder.
Pocos sistemas muestran esa conexión con tanta claridad como la gestión de incidencias ciudadanas.
Desde el móvil, el flujo debe ser deliberadamente corto: describir el problema, elegir una categoría comprensible, adjuntar una imagen y confirmar la ubicación.
Corto de verdad.
Si obligamos a una persona a conocer el organigrama municipal para comunicar que una farola no funciona, hemos trasladado la complejidad administrativa al lugar equivocado.
El ciudadano no debería decidir si el aviso corresponde a servicios urbanos, mantenimiento, una brigada municipal o una empresa concesionaria. El sistema sí debe saberlo o, como mínimo, facilitar esa decisión al equipo de triaje.
Por eso pulsar «Enviar» no debería crear solamente una fila en una base de datos. Debería abrir un expediente operativo:
- Entrada y validación inicial.
- Clasificación o corrección de la categoría.
- Detección de duplicados e incidencias relacionadas.
- Asignación a un departamento o proveedor.
- Actuación sobre el terreno.
- Comunicación con el ciudadano.
- Resolución, validación y cierre.
- Conservación del histórico para auditoría y análisis.
En aplicaciones del ecosistema Vicopo, como La Pobla Info, la pantalla del ciudadano era solo una pieza. Detrás convivían las aplicaciones móviles, la API, la base de datos, la geolocalización, el almacenamiento de imágenes, las notificaciones y un backoffice encargado de organizar el trabajo.
Guardar una fotografía nunca fue la parte difícil.
Lo difícil era convertirla en una actuación: que llegase a la persona adecuada, en el momento adecuado, y que no desapareciese dentro de otra bandeja de entrada.
La anatomía de una incidencia
Una incidencia reúne tres capas distintas: información aportada por el ciudadano, datos capturados automáticamente y decisiones incorporadas durante la tramitación.
Volcarlo todo en una descripción de texto hace que el sistema sea rápido de construir y casi imposible de explotar con rigor.
| Dimensión | Datos habituales | Pregunta que permite responder |
|---|---|---|
| Identificación | ID, fecha y canal | ¿Cuál es el aviso y cuándo llegó? |
| Problema | Categoría, tipo y descripción | ¿Qué está ocurriendo? |
| Evidencia | Fotografías y documentos | ¿Qué prueba existe antes y después? |
| Localización | Coordenadas, dirección y zona | ¿Dónde sucede y quién tiene competencia? |
| Prioridad | Urgencia, impacto o riesgo | ¿En qué orden debe revisarse? |
| Responsabilidad | Departamento, proveedor o brigada | ¿Quién debe actuar? |
| Ciclo de vida | Estado actual y transiciones | ¿En qué punto está y cuánto lleva ahí? |
| Comunicación | Respuestas y notificaciones | ¿Qué se ha comunicado? |
| Contexto interno | Notas y conversación operativa | ¿Qué decisiones se han tomado? |
| Relaciones | Duplicados y casos vinculados | ¿Es un aviso aislado? |
| Histórico | Autor, fecha y motivo de cada cambio | ¿Podemos reconstruir lo ocurrido? |
Cada dato cumple una función. Una fotografía aporta evidencia, pero no sustituye a la categoría. Una dirección facilita la lectura humana, pero no sustituye a unas coordenadas válidas. El estado actual permite ordenar una lista, pero no reconstruye el histórico.
El estándar Open311 GeoReport v2 trabaja con conceptos reconocibles: identificador, tipo de servicio, descripción, organismo responsable, estado, fechas, dirección, latitud, longitud y contenido multimedia.
Nuestro sistema no nació como una implementación de Open311. Aun así, es revelador comprobar cómo el propio dominio acaba empujando hacia estructuras parecidas.
No es casualidad.
Son los datos mínimos para convertir una observación localizada en una solicitud de servicio trazable.
Clasificar es dirigir el trabajo
Categorizar una incidencia no consiste en guardarla dentro de una carpeta ordenada para elaborar un informe a final de mes.
La clasificación decide quién recibe el trabajo, con qué prioridad y bajo qué plazo.
Una combinación como «Contenedores / lleno», «Parques y jardines / riego» o «Vía pública / señalización» puede determinar mucho más que una etiqueta:
- el departamento receptor;
- el proveedor responsable;
- la zona operativa;
- el plazo esperado;
- la prioridad inicial;
- los campos adicionales;
- las respuestas predefinidas;
- las métricas aplicables.
Cuantas más categorías añadimos, más preciso parece el sistema desde el backoffice. En el móvil ocurre lo contrario: aumentan las dudas, los errores de selección y el coste de mantener la taxonomía.
Yo no empezaría diseñando un árbol de cien opciones en una sala de reuniones.
Empezaría observando los problemas reales, agruparía las categorías según su utilidad operativa y permitiría corregir la clasificación sin borrar la elección original.
Criterio de diseño
La taxonomía correcta no es la que reproduce mejor el organigrama municipal. Es la que permite al ciudadano reconocer el problema y al sistema conducirlo hasta quien puede resolverlo.
La categoría «Otros» merece una vigilancia especial. Es necesaria porque la calle siempre encuentra situaciones que el catálogo no había previsto. Pero si concentra demasiados avisos, deja de ser una válvula de escape y se convierte en una alarma: la clasificación ya no representa la realidad.
Conservar la categoría inicial y la validada permite medir:
- cuánto se reclasifica;
- qué categorías se confunden;
- qué tipos terminan dentro de «Otros»;
- dónde necesita ayuda el formulario;
- cómo evoluciona el vocabulario ciudadano.
La distancia entre ambas categorías es, al mismo tiempo, una métrica de calidad del dato y una señal de UX.
Los estados no son etiquetas de colores
Una lista con «Pendiente», «En proceso» y «Resuelta» parece suficiente hasta que alguien pregunta cuánto ha tardado realmente una incidencia.
Si solo almacenamos el estado actual y la fecha de última modificación, hemos sobrescrito la historia que necesitábamos analizar.
El recorrido principal puede ser sencillo:
Pendiente → En proceso → Resuelta → Cerrada
Pero la realidad necesita salidas alternativas:
- rechazada porque no corresponde o carece de información;
- tramitada hacia otra administración o procedimiento;
- vinculada a otra incidencia por duplicidad;
- reabierta porque la solución no fue efectiva.
Cada transición debería registrar:
- estado anterior y nuevo;
- fecha y hora;
- persona o sistema que realiza el cambio;
- departamento o proveedor responsable;
- motivo;
- comentario visible para el ciudadano;
- evidencia;
- notificación generada y resultado del envío.
Desde el punto de vista técnico, separaría la incidencia de sus eventos. La incidencia representa la fotografía actual y facilita las consultas operativas. Los eventos conservan la secuencia que explica cómo se llegó hasta ella.
| Entidad | Responsabilidad |
|---|---|
| Incidencia | Datos actuales, clasificación, ubicación y asignación |
| Evento | Cambios de estado, asignación, reclasificación y reapertura |
| Evidencia | Fotografías y documentos con autor, fecha y finalidad |
| Conversación | Mensajes ciudadanos, operativos o internos |
| Relación | Duplicidad, recurrencia o dependencia |
El histórico es el dato
Guardar que una incidencia está resuelta permite pintarla de verde. Guardar cómo llegó a resolverse permite auditar el proceso y mejorar el servicio.
Esta decisión de modelado condiciona casi todo el análisis posterior. Sin eventos no podemos medir el tiempo por estado, detectar reasignaciones, explicar reaperturas ni distinguir el tiempo de espera del tiempo de actuación.
Antes del EDA: auditar el dato
La primera exploración no debería empezar preguntando qué categoría acumula más avisos.
Debería comprobar si el conjunto de datos merece confianza.
Revisaría, como mínimo:
| Control | Qué buscar |
|---|---|
| Identificadores | Nulos, duplicados o cambios de ID |
| Fechas | Registros futuros, orden imposible o zonas horarias distintas |
| Estados | Valores obsoletos, transiciones inválidas o cierres sin evento |
| Categorías | Nulos, códigos eliminados y exceso de «Otros» |
| Ubicación | Coordenadas fuera del municipio, puntos idénticos o direcciones vacías |
| Asignación | Proveedores sin departamento, zona o fecha |
| Evidencia | Fotografías ausentes, duplicadas o sin metadatos mínimos |
| Conversación | Mensajes fuera del histórico o canales mezclados |
| Relaciones | Duplicados eliminados en vez de vinculados |
| Privacidad | Campos personales innecesarios en exportaciones |
Superar una validación técnica no garantiza que un dato sea correcto. Una fecha puede tener un formato válido y pertenecer al futuro. Una coordenada puede caer dentro del municipio y apuntar al centroide usado por defecto. Una categoría puede seguir en la base de datos aunque lleve años fuera del formulario.
Por eso el EDA debe incorporar también la línea temporal del sistema:
- versiones de la aplicación;
- cambios de taxonomía;
- campañas de adopción;
- altas y bajas de proveedores;
- modificaciones del proceso;
- periodos sin notificaciones;
- migraciones de datos;
- incidencias creadas manualmente desde el backoffice.
Sin esa cronología podemos confundir una nueva versión de la app, una campaña de difusión o una migración con un cambio real en la ciudad.
Las variables que no vienen en la exportación
Los campos originales rara vez bastan para responder preguntas operativas. Necesitamos derivar variables que representen el proceso, no solo el registro.
| Variable derivada | Cálculo o criterio |
|---|---|
| Hora y día de registro | Extraídos de la fecha con zona horaria consistente |
| Tiempo de primera revisión | Primera revisión menos registro |
| Tiempo de asignación | Primera asignación menos registro |
| Tiempo de resolución | Resolución menos registro |
| Tiempo por estado | Salida menos entrada en cada estado |
| Antigüedad abierta | Fecha de análisis menos registro |
| Reclasificada | Categoría inicial distinta de la validada |
| Número de reasignaciones | Cambios de responsable |
| Número de reaperturas | Transiciones de resuelta a en proceso |
| Tiene evidencia | Existencia de fotografía o documento válido |
| Ubicación válida | Geometría presente, coherente y dentro del ámbito |
| Grupo de duplicidad | Identificador de incidencias vinculadas |
| Cierre comunicado | Notificación de cierre registrada sin error |
| Recurrencia | Nuevo aviso compatible próximo en espacio y tiempo |
Crear estas columnas no es «limpiar el CSV». Es construir el modelo analítico del servicio.
Cada definición debe quedar documentada. Dos equipos pueden calcular el tiempo de resolución de forma distinta: desde el registro, desde la asignación o descontando los periodos bloqueados.
Si cambia la fórmula, cambia la métrica. Y, con ella, la historia que contamos.
Cuándo reporta la ciudad
Un mapa de calor por día de la semana y hora permite localizar concentraciones de registros.
Pero la hora de registro no es necesariamente la hora en que apareció el problema.
El ciudadano puede avisar al volver a casa, durante un paseo o después de soportar varios días de molestia. Algunas incidencias son inmediatas; otras solo se hacen visibles cuando una rutina vuelve a cruzarse con el problema.
Analizaría:
- distribución por hora y día;
- diferencias entre categorías;
- estacionalidad mensual;
- festivos y eventos locales;
- episodios meteorológicos;
- cambios después de campañas o actualizaciones;
- tiempo entre captura de la evidencia y registro, si existe y es legítimo utilizarlo.
No presentaría una concentración horaria como una causa. La utilizaría para formular mejores preguntas:
- ¿debemos reforzar el triaje en determinadas franjas?
- ¿las incidencias urgentes esperan hasta el siguiente día laborable?
- ¿el canal se utiliza de forma diferente entre semana y fin de semana?
- ¿algunas categorías dependen especialmente de la luz diurna?
El patrón temporal deja una pista. El conocimiento del proceso debe aportar la explicación.
Qué se reporta y cuánto pesa «Otros»
Un análisis de Pareto de categorías y tipos muestra si unas pocas familias concentran la mayoría de los registros.
También permite revisar:
- evolución de la categoría «Otros»;
- categorías que desaparecen o crecen bruscamente;
- tipos con muy poco uso;
- diferencias entre clasificación inicial y final;
- combinaciones imposibles de categoría y tipo;
- categorías con muchos rechazos o tramitaciones.
No utilizaría una nube de palabras para resumir las observaciones. Es vistosa, pero sacrifica el contexto, la negación y la frecuencia relativa.
Preferiría:
- términos distintivos por categoría;
- agrupaciones temáticas de textos anonimizados;
- ejemplos representativos revisados manualmente;
- evolución de expresiones;
- palabras asociadas a reclasificaciones;
- descripción de casos que terminan como duplicados.
El texto libre puede revelar necesidades que el catálogo todavía no cubre. También contiene erratas, datos personales, ironía, urgencia subjetiva y referencias que solo comprende quien conoce el lugar.
Por eso la revisión humana no es una corrección posterior: forma parte del análisis.
Medir el flujo sin engañarnos
El total de incidencias es la cifra más fácil de obtener y, precisamente por eso, una de las más fáciles de malinterpretar.
Un aumento puede significar más problemas. También puede indicar mayor adopción, más confianza ciudadana o el efecto de una campaña reciente.
Un descenso puede reflejar una mejora del servicio o el abandono silencioso del canal.
El volumen, por sí solo, no distingue entre esos escenarios. Para hacerlo necesitamos métricas de flujo:
| Indicador | Qué revela | Precaución |
|---|---|---|
| Primera revisión | Capacidad de entrada y triaje | Una respuesta automática no es revisión humana |
| Asignación | Fricción antes del responsable | Algunos casos necesitan validación |
| Resolución | Duración completa | Comparar por categoría y complejidad |
| Tiempo por estado | Dónde se acumula la espera | Requiere histórico de eventos |
| Backlog | Trabajo abierto en una fecha | Mostrar también antigüedad |
| P50 y P90 | Comportamiento habitual y cola larga | La media oculta extremos |
| Reapertura | Calidad o validación del cierre | Definir una ventana temporal |
| Duplicidad | Recurrencia y capacidad de relacionar | Muchos avisos también indican impacto |
| Reclasificación | Calidad de la taxonomía | Analizar qué pares se confunden |
| Comunicación | Transparencia del cierre | Enviar no significa recibir |
Mostraría la mediana y el percentil 90 antes que una media aislada. Un equipo puede resolver la mayoría de los casos en dos días y mantener unos pocos bloqueados durante meses.
La media mezcla ambos comportamientos hasta volverlos irreconocibles.
Una métrica sin contexto puede castigar a quien recibe los casos difíciles y premiar a quien cierra deprisa los fáciles.
Antes de convertir un indicador en objetivo, preguntaría qué comportamiento incentiva. Si premiamos cierres, aparecerán cierres prematuros. Si premiamos rapidez, se priorizará lo sencillo. Si premiamos volumen, confundiremos actividad con impacto.
El backlog tiene edad
«Tenemos 120 incidencias pendientes» parece una cifra concreta, pero es una frase incompleta.
Necesitamos saber cuánto tiempo llevan abiertas, en qué estado están y quién puede desbloquearlas.
Una segmentación útil podría separar:
- menos de 24 horas;
- de 1 a 3 días;
- de 4 a 7;
- de 8 a 30;
- más de 30 días.
Los umbrales deben adaptarse a cada servicio. Una poda programada no puede compartir el mismo tiempo esperado que una señal peligrosa.
Además del aging, observaría cohortes por mes de registro. Así podemos comprobar qué proporción se cierra durante la primera semana, qué parte continúa abierta al superar el primer mes y qué cohortes arrastran trabajo antiguo.
Las incidencias antiguas merecen una revisión cualitativa. A menudo revelan:
- dependencia de otra administración;
- falta de proveedor;
- clasificación incorrecta;
- ausencia de presupuesto;
- duplicidad mal gestionada;
- cierre pendiente de confirmación;
- pérdida de responsabilidad durante una reasignación.
El backlog no es solo una cola de trabajo.
Es la memoria acumulada de todo lo que la organización todavía no ha conseguido terminar.
Reaperturas, duplicados y problemas que vuelven
Dos ciudadanos pueden fotografiar el mismo contenedor desde posiciones ligeramente distintas. Para una comparación literal son dos registros. Para la operación municipal representan un único problema con varias evidencias.
Eliminar uno de los avisos simplifica la base de datos, pero destruye información.
Relacionarlos permite conservar:
- participación de ambos ciudadanos;
- evidencia desde diferentes ángulos;
- magnitud percibida;
- secuencia temporal;
- notificaciones a cada remitente;
- un único caso operativo.
La reapertura cuenta otra historia. Puede indicar:
- cierre prematuro;
- solución temporal;
- evidencia insuficiente;
- problema que reaparece;
- comunicación mal interpretada;
- error de estado.
No toda repetición es un duplicado. Para distinguir entre el mismo aviso, una recurrencia y un problema distinto necesitamos combinar categoría, distancia, tiempo, texto, activo relacionado y revisión humana.
El análisis espacial profundo merece la siguiente pieza de esta serie. Aquí basta con una advertencia:
Un mapa de puntos muestra dónde se ha avisado. No demuestra dónde están todos los problemas.
La ciudad que reporta
La distribución de las incidencias es también un mapa de adopción, confianza y acceso al canal.
Algunas zonas pueden generar más avisos porque tienen:
- más población;
- más usuarios activos;
- mejor cobertura;
- mayor conocimiento de la app;
- asociaciones vecinales más movilizadas;
- más activos municipales;
- problemas más visibles;
- experiencias previas de respuesta.
Una zona sin incidencias puede estar perfectamente mantenida.
O puede ser un silencio digital: nadie conoce el canal, nadie confía en él o nadie puede utilizarlo.
Compararía, cuando los datos lo permitan:
- incidencias por zona;
- usuarios activos;
- población;
- superficie;
- número de activos;
- recurrencia de usuarios;
- porcentaje de registros con ubicación válida;
- distribución por canal de entrada.
No hace falta convertir al ciudadano en objeto de análisis individual. Para estudiar la adopción suelen bastar identificadores seudonimizados, cohortes y agregaciones.
Los datos de incidencias no describen la ciudad completa.
Describen la ciudad que reporta, el canal que la escucha y la organización que responde.
Tres niveles de información
Una sola incidencia puede contener nombre, correo, teléfono, dirección, coordenadas, conversaciones y fotografías de la vía pública.
Que esos datos sean necesarios para gestionar el caso no significa que deban aparecer en una exportación analítica o en un mapa público.
| Nivel | Información | Acceso |
|---|---|---|
| Operativo | Contacto, localización precisa, evidencias y conversación completa | Personal autorizado y proveedores responsables |
| Analítico | Categoría, zona agregada, tiempos, estados y relaciones seudonimizadas | Gestión y análisis |
| Público | Totales, ubicación generalizada y resultados no identificables | Transparencia y datos abiertos |
La AEPD explica la protección de datos por defecto como la aplicación práctica de la minimización: limitar la cantidad, la extensión, la conservación y la accesibilidad de los datos a lo compatible con su finalidad.
En un sistema de incidencias, ese principio se traduce en decisiones de arquitectura muy concretas:
- quién descarga fotografías;
- si un proveedor ve datos de contacto;
- cuánto se conserva la posición exacta;
- qué campos aparecen al exportar;
- cómo se difuminan personas o matrículas;
- qué precisión se publica;
- cómo se auditan accesos;
- cómo se separan mensajes internos y públicos.
Privacidad desde el modelo
Anonimizar una captura al final es una medida editorial. Separar desde el diseño los datos operativos, analíticos y públicos es una decisión de arquitectura que reduce el riesgo desde el origen.
No publicaría capturas del backoffice sin una anonimización completa. Borrar el nombre no basta si permanecen el correo, el identificador, la dirección, las coordenadas, la fecha exacta o una fotografía reconocible.
Lo que la demo no enseña
En una demostración todo encaja: el móvil obtiene la posición, la fotografía sube, la incidencia aparece en el panel y alguien la marca como resuelta.
En producción, el guion deja de obedecer.
El GPS sitúa al ciudadano al otro lado de la calle. La geocodificación devuelve una dirección que no reconoce. La imagen pierde cobertura durante la subida. El texto dice «esto lleva semanas así» sin dejar claro a qué se refiere.
Después entra en escena la organización:
- departamentos con criterios distintos;
- proveedores que documentan de forma desigual;
- asignaciones a personas ausentes;
- avisos urgentes que pierden prioridad;
- conversaciones copiadas por correo;
- cierres sin evidencia posterior;
- notificaciones enviadas a direcciones inválidas;
- casos cerrados administrativamente pero visibles en la calle.
Nada de esto se arregla añadiendo otro gráfico al dashboard.
Hace falta diseñar reglas, permisos, validaciones, observabilidad y procedimientos que el software pueda sostener, sin fingir que la tecnología sustituye a la organización.
Checklist para un EDA responsable
Si varias respuestas son negativas, la prioridad no debería ser incorporar IA ni construir un modelo predictivo.
La prioridad es recuperar la trazabilidad del proceso.
Conclusión: antes de medir la ciudad, mide el sistema
Capturar una incidencia es relativamente fácil. Bastan un formulario, una fotografía y unas coordenadas.
El trabajo difícil empieza después de pulsar «Enviar».
Hay que validarla, clasificarla, relacionarla, asignarla, actuar sobre el terreno, comunicar el resultado y conservar un histórico fiable de cada decisión.
Solo entonces obtenemos un conjunto de datos capaz de responder algo más útil que cuántos registros existen.
Un EDA bien planteado permite descubrir categorías que han dejado de funcionar, estados donde se acumula la espera, cierres que vuelven a abrirse, zonas con distinta adopción y campos que nunca estuvieron tan completos como creíamos.
También obliga a reconocer los límites del propio análisis.
Más avisos no significan necesariamente peor mantenimiento. Menos avisos no demuestran que los problemas hayan desaparecido. Un punto caliente puede representar más participación. Una resolución rápida puede esconder un cierre precipitado.
Por eso mi punto de partida es sencillo: el análisis no debe comenzar evaluando la ciudad.
Debe comenzar evaluando el sistema que captura, transforma y conserva la información.
Tomaría veinte incidencias recientes e intentaría reconstruir su historia completa. Después haría lo mismo con veinte antiguas. Los huecos encontrados serían mi primer backlog de calidad. Solo entonces abriría el notebook.
Porque los datos no hablan por sí solos.
Dejan huellas.
El análisis empieza cuando somos capaces de reconstruir de dónde vienen y decidir, con criterio, qué significan.
Una prueba antes del dashboard
Selecciona veinte incidencias recientes y veinte antiguas. Reconstruye su clasificación, asignaciones, tiempos, conversaciones y cierre. Cada hueco que encuentres debería convertirse en una tarea concreta del primer backlog de calidad de datos.
Preguntas frecuentes
¿Qué es un EDA de incidencias ciudadanas?
Es el análisis inicial del volumen, las categorías, los tiempos, la calidad, las relaciones y los sesgos del conjunto. Su objetivo es comprender cómo se producen los datos y qué limitaciones tienen antes de construir indicadores, dashboards o modelos.
¿Qué datos mínimos necesita el análisis?
Como mínimo: identificador, fecha de registro, categoría, ubicación, estado, responsable e histórico de eventos. Sin transiciones solo podremos analizar la fotografía actual, no el funcionamiento del proceso.
¿Qué métricas son más útiles?
Tiempo hasta la primera revisión, asignación y resolución; tiempo por estado; backlog por antigüedad; P50 y P90; reaperturas; duplicados; reclasificaciones y cierres comunicados.
¿Por qué no basta con contar incidencias?
Porque el volumen mezcla problemas reales, adopción de la aplicación, visibilidad, confianza ciudadana y cambios del proceso. Para interpretarlo necesita contexto temporal, territorial y operativo.
¿Se pueden analizar las observaciones de texto?
Sí, después de aplicar controles de privacidad y revisión. Es preferible identificar temas, términos distintivos y motivos de reclasificación antes que recurrir a una nube de palabras sin contexto.
¿Cuándo tiene sentido utilizar IA?
Cuando existen categorías consistentes, eventos completos y criterios de validación. La IA puede sugerir clasificaciones, detectar similitudes o priorizar revisiones, pero no sustituye un buen modelo de datos ni la supervisión humana.
Deja una respuesta