Registro de incidencias de coordinación (BIM/CAD): guía operativa para gestionar cambios sin perder decisiones
- Un registro de incidencias (issue log) no es una lista de tareas personal: es un registro compartido de incidencias que necesitan una decisión, una acción y una verificación visible en el entregable.
- Su versión mínima viable cabe en una tabla sencilla, pero debe exigir siempre contexto, responsable, estado y evidencia antes de considerar una incidencia cerrada.
- Bien usado, reduce retrabajo, discusiones circulares y errores de exportación porque saca lo importante de chats, correos y recuerdos individuales.
Si trabajas con planos, modelos, PDFs, láminas o entregas coordinadas entre varias personas, un registro de incidencias puede convertirse en una pieza estructural de tu proceso. No porque haga el trabajo por ti, sino porque ordena el paso más frágil del proyecto: la transición entre detectar un problema y darlo realmente por resuelto.
Esto importa especialmente en cuatro situaciones frecuentes:
- cuando varias personas editan información relacionada, aunque no usen el mismo software;
- cuando una corrección cambia más de un entregable;
- cuando una incidencia requiere una decisión de criterio y no solo “arreglar algo”;
- cuando el equipo empieza a depender de chats, notas sueltas o memoria para seguir el estado de la coordinación.
En la práctica, un registro de incidencias bien llevado mejora tres cosas muy concretas.
La primera es la claridad de responsabilidad. Muchas incidencias no se atascan porque sean difíciles, sino porque nadie sabe con precisión quién decide, quién ejecuta y quién verifica. Poner un responsable no sirve para “culpabilizar”, sino para evitar que la tarea quede flotando entre disciplinas.
La segunda es la calidad de la revisión. Decir “ya está” no basta si el cambio no aparece en el plano, en el PDF exportado o en el archivo compartido que realmente se entrega. Un registro de incidencias obliga a separar resolución de verificación, y esa diferencia es la que evita cierres falsos.
La tercera es la conservación del criterio. En coordinación, una parte importante del valor no está solo en corregir, sino en recordar por qué se eligió una solución y no otra. Si ese razonamiento queda perdido en un mensaje, el equipo lo volverá a discutir más adelante. Si queda registrado, se convierte en una referencia útil para siguientes fases.
Acciones
- Crea hoy mismo un registro de incidencias compartido con una tabla mínima y acordad entre todos qué significa cada estado.
- Exige evidencia inicial en cada incidencia antes de asignarla: captura, referencia de plano, vista o localización inequívoca.
- Formula siempre la decisión requerida, no solo la acción técnica; así evitarás tareas ambiguas y correcciones sin criterio.
- Haz una priorización rápida (triage) antes de exportar o entregar para centrarte en lo que afecta de verdad a la coordinación y a la calidad documental.
- Cierra solo lo que esté verificado en el soporte de entrega relevante: plano, PDF, IFC o paquete compartido.
- Revisa la lista de pendientes (backlog) semanalmente para dividir megatareas, actualizar responsables y eliminar ruido.
- Mantén el sistema simple: si una herramienta complica el registro, vuelve a una tabla básica, pero no renuncies a la trazabilidad.
En muchos equipos pequeños, la coordinación no falla por falta de buena voluntad sino por falta de trazabilidad. Alguien detecta una incompatibilidad entre estructura y arquitectura, otro corrige el modelo, un tercero exporta los planos, y al final nadie tiene claro qué se decidió, qué cambió realmente y qué quedó pendiente. El resultado no suele ser un gran colapso visible, sino algo más común y costoso: revisiones repetidas, planos desalineados, PDFs que no recogen la última decisión y tiempo perdido reconstruyendo conversaciones.
Un registro de incidencias sirve precisamente para evitar eso. No hace falta una plataforma compleja ni una metodología pesada. Hace falta, sobre todo, una disciplina ligera y consistente: registrar lo que importa, asignarlo a alguien, definir cuándo se considera resuelto y comprobar que el cambio aparece donde tiene que aparecer. En BIM o en CAD, en estudio o en escuela, el problema es el mismo: una decisión no existe de verdad para el proyecto hasta que queda documentada y verificada en el soporte de entrega.
Esta guía operativa propone un sistema mínimo viable, independiente de la herramienta, para implantar un registro de incidencias útil sin convertirlo en burocracia. La idea no es registrar todo, sino registrar mejor lo que puede afectar a la coordinación, al criterio o a la entrega.
Qué es un registro de incidencias (issue log) y en qué se diferencia de una lista personal de tareas
Una lista personal de tareas (to-do) sirve para recordar acciones: “revisar cotas”, “actualizar axonometría”, “nombrar capas”. Un registro de incidencias sirve para coordinar incidencias que afectan a un entregable compartido y que exigen una decisión o una comprobación trazable.
Esa diferencia parece menor, pero cambia por completo la utilidad del registro.
Una tarea personal puede ser ambigua porque solo la entiende quien la escribió. Un issue de coordinación, en cambio, debe poder entenderlo otra persona del equipo sin contexto adicional. Por eso necesita campos, evidencia y una formulación más precisa.
Además, una lista personal admite cierres subjetivos. Si escribes “revisar puerta acceso” y la revisas, para ti puede estar hecho. En un registro de incidencias, “cerrado” debería significar algo más exigente: la incidencia está resuelta y verificada en el entregable afectado.
Por eso conviene pensar un issue como una unidad mínima de coordinación: una incidencia, una decisión, un resultado verificable. No una megatarea. No un paquete difuso de problemas mezclados.
Mal ejemplo: “Revisar núcleo de comunicaciones”. Buen ejemplo: “La puerta de sectorización del núcleo en planta tipo invade el ancho libre de paso representado en plano A-12; decidir si se desplaza el tabique o se modifica el sentido de apertura, y actualizar plano y modelo coordinados”.
La segunda formulación permite actuar, asignar y comprobar. La primera solo genera más preguntas.
Cuándo merece la pena usarlo
No hace falta implantar un registro de incidencias desde el primer boceto de un ejercicio individual muy simple. Pero hay señales claras de que ya lo necesitas.
La primera señal es la repetición de incidencias. Si el mismo problema aparece en varias revisiones, no estás ante un fallo puntual sino ante una mala trazabilidad. El equipo corrige, pero no captura bien ni la causa ni la evidencia de cierre.
La segunda es la fragmentación de la información. Cuando parte del criterio está en un chat, parte en un correo, parte en comentarios sobre un PDF y parte en la cabeza de quien modela, la coordinación se vuelve dependiente de personas concretas. Eso es frágil y escala mal.
La tercera es la existencia de entregables múltiples. En cuanto una decisión debe reflejarse en más de un soporte —modelo, plano, tabla, lámina, exportación— conviene registrar la incidencia para comprobar que el cambio no se quedó a mitad.
La cuarta es el aumento de los “casi correctos”. Este tipo de error es muy común: el modelo está actualizado, pero el plano no; el plano está bien, pero el PDF exportado es anterior; la sección cambió, pero la leyenda no; la coordinación se hizo en reunión, pero nadie dejó rastro del criterio. Un registro de incidencias no elimina estas situaciones, pero las hace visibles antes de entregar.
En equipos de escuela también es útil cuando varias personas producen una misma entrega. Aunque el proyecto no sea “profesional”, el problema de coordinación es real: quién cambia qué, con qué criterio y cómo se comprueba.
Plantilla mínima viable: los campos que no deberían faltar
La mayor parte de los registros de incidencias fracasa por dos extremos: o son tan pobres que no sirven para coordinar, o son tan complejos que nadie los mantiene. La clave está en una plantilla mínima viable.
Esta tabla puede copiarse en Excel, Google Sheets, Notion, Airtable o cualquier herramienta equivalente. Lo importante no es la plataforma, sino la lógica de los campos.
| Campo | Para qué sirve | Regla práctica |
|---|---|---|
| ID | Identificar el issue sin ambigüedad | Usa un código corto y único: ISS-001, ISS-002 |
| Fecha | Saber cuándo se detectó o registró | No confundir con fecha de cierre |
| Disciplina | Ubicar a qué ámbito afecta | Arquitectura, estructura, instalaciones, representación, coordinación |
| Ubicación | Encontrar el problema | Plano, vista, nivel, zona, lámina, detalle o archivo |
| Descripción | Explicar qué ocurre | Describe el problema observable, no solo “revisar” |
| Impacto | Valorar por qué importa | Entrega, coordinación, criterio, representación, exportación |
| Decisión requerida | Aclarar qué hay que decidir | Formula la pregunta o alternativa concreta |
| Responsable | Asignar quién coordina la resolución | Una persona, aunque intervengan varias |
| Estado | Saber en qué punto está | Usa pocos estados y defínelos bien |
| Fecha objetivo | Priorizar y ordenar revisión | Mejor realista que aspiracional |
| Evidencia inicial | Probar que el issue existe | Captura, referencia de plano, vista o comentario |
| Nota de resolución | Registrar qué se hizo o decidió | Breve y específica |
| Evidencia final | Probar que quedó resuelto | Captura, ID de plano, export o enlace verificable |
| Verificado por | Separar ejecución de comprobación | Si es posible, otra persona |
| Fecha de cierre | Trazabilidad temporal | Solo cuando esté verificado |
Si quieres una versión todavía más ligera, podrías empezar sin “verificado por”, pero no deberías prescindir de evidencia inicial, decisión requerida ni evidencia final. Son los campos que transforman una lista de tareas en una herramienta de coordinación.
Estados recomendados
No conviene multiplicar estados. Cuantos más estados, más discusión sobre etiquetas y menos avance real. Para un equipo pequeño, suele bastar con estos:
- Abierto: la incidencia está registrada con evidencia mínima.
- En triage: se está valorando prioridad, alcance o responsable.
- En curso: alguien está resolviéndola.
- Pendiente de verificación: el cambio está hecho, pero no comprobado en el entregable.
- Cerrado: verificado con evidencia final.
- Bloqueado: no puede avanzar por falta de decisión, dato o dependencia externa.
Si el equipo necesita aún menos complejidad, puede fusionar “Abierto” y “En triage”, pero conviene mantener siempre la diferencia entre “En curso”, “Pendiente de verificación” y “Cerrado”. Esa separación evita el error más común: dar por resuelta una incidencia solo porque alguien tocó el archivo.
Definición de “hecho”: cerrado significa verificado
Esta es probablemente la regla más valiosa de la guía: una incidencia no está cerrada cuando alguien dice que la ha cambiado, sino cuando ese cambio aparece comprobado en el soporte que importa.
En coordinación BIM/CAD, “hecho” puede significar varias cosas, y no son equivalentes:
- se ha corregido el modelo;
- se ha corregido el plano;
- se ha regenerado la vista;
- se ha actualizado la lámina;
- se ha exportado de nuevo el PDF o el IFC;
- se ha comprobado que la exportación refleja el cambio.
El cierre solo debería llegar al último escalón relevante para la entrega. Si el proyecto va a revisión en PDF, la verificación no puede quedarse en “está bien en el modelo”. Si el intercambio entre disciplinas se hace mediante IFC o DWG, la comprobación debe incluir ese formato.
Esta regla reduce una forma muy habitual de retrabajo: la falsa sensación de avance. Mucho trabajo se pierde entre modificaciones correctas y entregables desactualizados. El registro de incidencias ayuda a detectar justamente esa zona gris.
Flujo de trabajo mínimo: de la captura al cierre
Un registro de incidencias útil no es solo una tabla; es una secuencia clara de trabajo. La más simple y robusta puede resumirse en cinco pasos.
1. Captura
Registrar una incidencia en cuanto aparece, con evidencia suficiente para que otro la entienda. Eso significa adjuntar una captura, una referencia de plano, una vista concreta o una localización inequívoca.
La captura no debería redactarse como una orden vaga (“arreglar techo”), sino como un problema observable con contexto. Por ejemplo: “En sección S-03, el falso techo representado interfiere visualmente con el hueco de instalaciones; revisar si la cota de referencia es correcta o si falta ajuste de representación”.
Una buena captura ahorra tiempo en la reunión posterior. Una mala captura obliga a redescubrir el problema.
2. Priorización (triage)
La priorización (triage) es una revisión breve para decidir prioridad, responsable y siguiente paso. No es una reunión larga ni una discusión completa de diseño. Su objetivo es ordenar.
Aquí conviene responder tres preguntas:
- ¿Esto afecta a la entrega inmediata o puede esperar?
- ¿Hace falta una decisión de criterio o solo una corrección técnica?
- ¿Quién coordina su resolución?
En este punto también se puede detectar si una incidencia está mal formulada. Si una fila contiene tres problemas mezclados, hay que dividirla. Una incidencia = una decisión o resultado.
3. Resolución
Consiste en hacer el cambio y dejar nota de qué se decidió. Esa nota no necesita ser extensa, pero sí suficiente para no repetir la conversación en la próxima revisión.
Ejemplo de nota útil: “Se desplaza 10 cm el trasdosado del patinillo para mantener continuidad del paso en planta y sección; se actualizan planta P2 y sección S-03”.
Ejemplo poco útil: “Corregido”.
La diferencia es importante porque, si la incidencia reaparece, la segunda nota no ayuda a entender nada.
4. Verificación
Aquí se comprueba la resolución en el soporte de entrega relevante. No basta con confiar en que el cambio se propagó bien. Hay que mirarlo.
La verificación puede incluir:
- revisar el plano concreto;
- abrir el PDF exportado;
- comprobar la vista o lámina;
- revisar un intercambio de referencia;
- confirmar que el identificador o la anotación coinciden.
Este paso debería producir evidencia final: una captura, un enlace al archivo actualizado o una referencia clara al plano.
5. Cierre
Solo se cierra cuando la evidencia final existe y alguien confirma que el resultado es correcto. En equipos pequeños, puede verificar la misma persona si no hay alternativa, pero lo ideal es que otra revise al menos las incidencias de mayor impacto.
Ejemplo de plantilla copiable
Puedes usar esta estructura tal cual:
Nota: los valores de ejemplo son marcadores a rellenar y no corresponden a un proyecto real.
| ID | Fecha | Disciplina | Ubicación | Descripción | Impacto | Decisión requerida | Responsable | Estado | Fecha objetivo | Evidencia inicial | Nota de resolución | Evidencia final | Verificado por | Fecha de cierre |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ISS-001 | [aaaa-mm-dd] | Arquitectura / Estructura | [Planta X, eje Y-Z] | [Conflicto visible entre elementos / documentación] | Entrega + coordinación | [Qué decisión hace falta tomar] | [Nombre o rol] | En curso | [aaaa-mm-dd] | [Captura / ref. localizable] | ||||
| ISS-002 | [aaaa-mm-dd] | Representación | [Sección / plano / lámina] | [Incoherencia entre vistas o documentos] | Coherencia documental | [Qué hay que confirmar y actualizar] | [Nombre o rol] | Abierto | [aaaa-mm-dd] | [Captura / ref. localizable] |
Ejemplos de incidencias bien redactadas
A continuación, cinco ejemplos ficticios (genéricos) que muestran el nivel de precisión deseable.
| ID | Disciplina | Ubicación | Descripción | Decisión requerida | Estado |
|---|---|---|---|---|---|
| ISS-003 | Arquitectura / Instalaciones | Planta cubierta, zona patio | El recorrido de bajante dibujado en cubierta no coincide con el patinillo representado en plantas inferiores | Confirmar si se reposiciona la bajante o si el patinillo está mal situado en plantas tipo | En triage |
| ISS-004 | Representación | Lámina L-03, detalle acceso | El detalle muestra carpintería abatible, pero la planta general representa corredera en el mismo punto | Decidir cuál es la solución válida para mantener coherencia entre detalle y planta | Pendiente de verificación |
| ISS-005 | Arquitectura | Planta baja, acceso principal | La hoja de puerta invade el espacio de espera dibujado en mobiliario y dificulta lectura del recorrido de acceso | Definir si se cambia sentido de apertura, posición o criterio de representación | Abierto |
| ISS-006 | Coordinación | PDF entrega intermedia | La numeración de planos del índice no coincide con los códigos visibles en las láminas exportadas | Decidir nomenclatura final y regenerar índice antes de entrega | En curso |
| ISS-007 | BIM / Representación | Sección S-05 exportada a PDF | El cambio de cota de falso techo está corregido en modelo, pero no aparece en el PDF de revisión | Verificar si la vista no se actualizó o si se exportó una versión anterior | Bloqueado |
En todos los casos hay tres rasgos útiles: el problema es visible, la ubicación es clara y la decisión requerida está formulada. Eso evita que el registro se convierta en una lista de mandatos genéricos.
Rituales mínimos para que funcione
Un registro de incidencias sin rituales suele acabar abandonado. No porque la tabla sea mala, sino porque nadie reserva un momento explícito para usarla. La buena noticia es que no hace falta mucho.
Revisión rápida antes de exportar o entregar
Reserva 10–15 minutos antes de una exportación importante para revisar:
- incidencias abiertas con impacto en la entrega;
- incidencias en “pendiente de verificación”;
- incidencias bloqueadas que exigen decisión inmediata;
- evidencias finales faltantes.
Este ritual es breve, pero muy rentable. Detecta si el equipo está a punto de exportar con problemas conocidos aún no comprobados. También obliga a distinguir lo importante de lo accesorio.
Revisión semanal de pendientes (backlog) y limpieza
Una vez por semana conviene limpiar el registro:
- cerrar definitivamente lo ya verificado;
- dividir incidencias demasiado amplias;
- archivar lo irrelevante;
- reabrir incidencias mal cerradas;
- actualizar responsables o fechas objetivo irreales.
La limpieza evita que el registro se convierta en un cementerio de tareas antiguas. Cuando una herramienta acumula demasiados elementos ambiguos o desfasados, el equipo deja de confiar en ella. Y cuando deja de confiar, vuelve al chat y a la memoria.
Reglas de higiene para evitar burocracia
La intención del registro de incidencias no es añadir administración al proyecto, sino reducir pérdidas. Para conseguirlo, conviene respetar unas pocas reglas.
Una incidencia = una decisión o un resultado
Si una incidencia mezcla varias preguntas, varias ubicaciones o varios entregables no relacionados, debería dividirse. Las incidencias grandes parecen eficientes, pero dificultan asignación, verificación y cierre.
Sin evidencia, no se asigna
Si alguien detecta un problema pero no aporta una referencia mínima, el equipo tendrá que invertir tiempo en localizarlo antes siquiera de empezar. No siempre hace falta una imagen perfecta, pero sí un rastro verificable.
“Corregido” no es una nota suficiente
La nota de resolución debe explicar qué cambió o qué criterio se adoptó. No por formalidad, sino para evitar rediscutir lo mismo.
Cerrar no es desaparecer
Aunque una incidencia se cierre, su registro debe seguir consultable. La utilidad del registro no está solo en gestionar lo abierto, sino en conservar decisiones pasadas.
No registrar microtareas de producción individual
“Renombrar archivo”, “alinear texto”, “ordenar capas” o “pasar a PDF” pueden ser tareas reales, pero no siempre son incidencias de coordinación. Si se registra todo, se pierde foco. El registro debe reservarse para lo que afecta a criterio, coordinación o entregable compartido.
Cómo integrarlo sin depender de una herramienta concreta
Una de las mejores decisiones posibles es mantener el sistema independiente de la plataforma. Cambiar de Excel a Notion o a un software especializado no resuelve por sí mismo los problemas de coordinación. Lo que importa son los principios.
Un buen registro de incidencias, en cualquier herramienta, debe permitir:
- ver todas las incidencias en una misma vista;
- ordenar por estado, responsable y prioridad o fecha;
- enlazar o referenciar evidencias;
- filtrar lo pendiente antes de entregar;
- conservar historial mínimo de cambios.
Para equipos pequeños, una hoja compartida suele ser suficiente. Su ventaja es la simplicidad: cualquiera entiende una tabla. Para equipos que necesitan comentarios, adjuntos o vistas filtradas, una base de datos ligera puede ayudar. Pero el criterio de implantación debería ser este: usar la herramienta más simple que permita mantener la disciplina.
Si la herramienta exige más mantenimiento que el valor que aporta, el sistema se hunde. Si, por el contrario, la herramienta es simple pero el equipo no acuerda definiciones de estado y cierre, también fallará. El problema central no es tecnológico, sino de método.
Errores frecuentes al implantar un registro de incidencias
Hay varios fallos recurrentes que conviene anticipar.
El primero es usar el log como repositorio de todo. Cuando se vuelca cualquier detalle mínimo, la revisión se vuelve lenta y los asuntos críticos se diluyen. La solución no es registrar menos por pereza, sino registrar con criterio.
El segundo es no separar incidencia y solución. A veces se abre una incidencia ya formulada como instrucción cerrada, cuando en realidad lo que falta es decidir entre alternativas. Si la decisión requerida no está clara, la resolución será errática.
El tercero es confundir actividad con cierre. Un cambio ejecutado no siempre es un cambio entregable. Esta confusión genera muchos “ya estaba hecho” que no resisten una comprobación final.
El cuarto es no revisar la lista de pendientes (backlog). Los registros abandonados no solo estorban: erosionan la confianza del equipo. Si hay decenas de filas desactualizadas, nadie sabe qué sigue vivo y qué no.
El quinto es no vincular la incidencia al lugar exacto donde se observa. En coordinación gráfica, la localización importa tanto como la descripción. Un problema mal localizado obliga a releer planos, navegar vistas y perder tiempo.
Contexto y glosario mínimo
Registro de incidencias (issue log): registro compartido de incidencias de coordinación que requieren seguimiento, decisión y verificación.
Priorización (triage): revisión breve para ordenar incidencias según prioridad, responsable y siguiente acción.
Evidencia: prueba mínima de existencia o resolución de una incidencia. Puede ser una captura, un código de plano, una referencia a vista o un archivo exportado.
Verificación: comprobación de que la resolución aparece correctamente en el entregable relevante, no solo en el archivo de trabajo.
Pendientes (backlog): conjunto de incidencias abiertas o no cerradas, pendientes de revisión o resolución.
Cerrado: estado reservado para incidencias verificadas con evidencia final suficiente.
Un registro de incidencias no garantiza una coordinación perfecta ni promete cero errores. Su valor está en algo más sobrio y más útil: reducir la pérdida de decisiones, hacer visibles los puntos críticos y convertir la revisión en un proceso menos dependiente de memoria, urgencia o intuición. En proyectos pequeños, esa diferencia puede parecer modesta. En la práctica, suele ser la frontera entre una entrega razonablemente controlada y una cadena de correcciones que nadie consigue reconstruir del todo.