Aclaración de la revisión frente a las preguntas automáticas: 1) En la ficha /projects/48/?tab=fase4 se observa «Pendiente: sin modulo de calidad». El repositorio /documents/project/48/ contiene archivos, pero no se verificó una fuente estructurada vinculada a este indicador. Solicitamos a Indunnova confirmar técnicamente si existe un registro reutilizable y señalar su pantalla/campos, conforme a la pregunta 7 del #104. 2) El universo de entregables y el corte quedan expresamente pendientes de definición de CONSOF; no autorizamos asumir que todos los archivos o todas las actividades de la RACI son el denominador. 3) La aprobación computable debe definirse por tipo de entregable y autoridad aplicable; no autorizamos una equivalencia automática entre carga, firma, aprobación interna y aceptación del cliente. Estas dos definiciones empresariales se resolverán antes de aprobar la implementación. Mientras tanto pueden confirmar la fuente existente y proponer la integración mínima. No corresponde marcar este indicador como validado ni cerrar el ticket.

✏️ Editó el reporte: actualizó el contenido.

Definición funcional confirmada por CONSOF y ya incorporada en la descripción del ticket:

1. Qué contamos: los resultados y documentos exigidos para la entrega y el cierre de cada proyecto según su alcance. Ejemplos aplicables: planos eléctricos/hidrosanitarios finales, manual de garantías, manuales de operación/mantenimiento, acta de entrega completa y soporte del trámite de pólizas correspondiente. Cada proyecto tendrá su lista desde la planeación, con responsable, fecha y condición/autoridad de aprobación. No es una lista universal ni la copia automática de todas las actividades de la RACI.

2. Qué se considera aprobado: satisfacción de la condición de aceptación definida para ese entregable, por la autoridad correspondiente, con evidencia. Carga de archivo o generación de acta no equivalen a aprobación; revisión interna y aceptación del cliente se exigen según corresponda a cada caso. Los informes semanales/actas de comité no se incluyen automáticamente por ser registros de gestión.

Esta precisión actualiza los puntos 2 y 3 de nuestra aclaración anterior; el alcance conceptual y la regla general de aprobación ya están definidos. La fuente técnica sigue por confirmar por Indunnova (pregunta 1). Puede avanzar en identificar la fuente reutilizable y proponer su integración mínima con esta base.

Para la validación deben existir casos de plano pendiente de revisión, manual observado y acta sin firmas exigidas que NO computen como aprobados, y sus casos aceptados con evidencia que SÍ computen. No se declara que esas pruebas se hayan ejecutado.

Siguen pendientes las reglas detalladas de corte/denominador, No aplica/cancelaciones, cambios y fechas/historial, como se identifica en la descripción. El ticket continúa abierto: requerimiento funcional precisado, pendiente de completar cálculo e implementar/validar.

✏️ Editó el reporte: actualizó el contenido.

Aclaración de prioridad acordada con David: este desarrollo del indicador de entregables es de PRIORIDAD MEDIA y NO BLOQUEA LA SALIDA DEL ERP A OPERACIONES. Es importante y lo vamos a completar, pero puede trabajarse con el ERP ya en uso. No debe retrasar los pendientes que sí impiden operar, como los bloqueos de compras o los flujos indispensables de Proyectos.

Esto no significa cerrar el ticket ni dar el indicador por validado. Se mantienen las definiciones y pruebas pendientes. Mientras se completa, debe quedar identificado como pendiente/sin datos, sin mostrar un cumplimiento inventado. Tampoco elimina la obligación de entregar los documentos y resultados que correspondan a cada proyecto: lo que puede quedar para después es este desarrollo y su medición en el ERP, no los compromisos con el cliente.

Decisión de CONSOF — lista base y ajustes por alcance (12/11/2026)

Confirmamos esta dirección para trabajar: la lista debe partir de la matriz de gestión de proyectos y de la clasificación A/B/C. Durante la planeación se concreta según el alcance contratado. No queremos construir otra lista independiente ni convertir automáticamente todos los archivos o las 25 actividades en el indicador.

Se deben poder agregar entregables específicos del alcance, por ejemplo planos finales eléctricos/hidrosanitarios o manual de garantías cuando correspondan. Identificar qué se entrega, responsable, fecha prevista y condición/autoridad de aceptación, reutilizando el repositorio.

Los entregables de la base que no correspondan podrán excluirse por un usuario autorizado, con justificación obligatoria. No se borran definitivamente: conservar la lista original, el elemento excluido y quién hizo el cambio, cuándo y por qué. Lo mismo para adiciones y cambios de alcance. No debe mejorarse silenciosamente un corte histórico al excluir un pendiente después.

Permisos por concretar: David mencionó a Ximena, Juan y a sí mismo como posibles usuarios autorizados. La propuesta es que Planeación prepare la lista y que las exclusiones respeten la autoridad definida en el proceso/RACI. Todavía no está aprobado el reparto exacto ni si cada exclusión requiere segunda aprobación. No ampliar permisos reales ni cambiar la RACI con este comentario.

Sobre su respuesta del 09/11: reutilicemos la lista del ciclo que ya existe y su manejo de No aplica. Les pedimos mostrar el recorrido de esa pantalla y un ejemplo que conecte un ítem de la matriz con un entregable específico, señalando cómo evitar contar dos veces el ítem general y su detalle. Necesitamos distinguir qué ya funciona y qué ajuste mínimo falta; no solicitar un módulo nuevo por defecto.

Casos a comprobar al implementar: lista base según clasificación; adición por alcance; exclusión autorizada con motivo e historial; rechazo de exclusión sin motivo o sin permiso; conservación del resultado de cortes cerrados. Son criterios de prueba, no pruebas ya realizadas.

Esto precisa el origen y mantenimiento de la lista. Aún debemos acordar el total del indicador (todos los aplicables o solo los exigibles al corte), el detalle de las aprobaciones y fechas/versiones. No declaramos cerradas esas definiciones. Se mantiene PRIORIDAD MEDIA, NO BLOQUEA LA SALIDA DEL ERP; ticket abierto hasta implementación y validación.

✏️ Editó el reporte: actualizó el contenido.

Definición aprobada por David — estándar mínimo de entregables AL CLIENTE (12/11/2026)

Cerramos la dirección funcional de la lista: nace del estándar de calidad de CONSOF, se ajusta a las intervenciones reales y al alcance, y se contrasta con la matriz existente. A/B/C aporta el nivel de control, pero no decide por sí solo qué recibe el cliente. Esto actualiza el comentario anterior que ponía la clasificación como origen suficiente. No convertir los 25 productos internos del ciclo en entregables al cliente.

Categorías mínimas que deben revisarse en todo proyecto:
1. Acta de entrega al cliente: constancia de lo entregado y de pendientes, si existen.
2. Documento de garantías y cuidados de los trabajos ejecutados. Su contenido y formato se definirán aparte; no se dan por diseñados aquí.
3. Planos o registro final de las instalaciones intervenidas: eléctricas, hidrosanitarias, rutas de desagüe de aires u otras, según lo realizado.
4. Manuales y garantías de equipos suministrados, cuando corresponda.
5. Certificados y soportes de pruebas aplicables según la instalación y exigencias del proyecto; por ejemplo, certificación de gas cuando corresponda. No se establece que toda obra deba tenerla.
6. Otros entregables particulares comprometidos con el cliente o derivados de cambios de alcance aprobados.

El mínimo es revisar siempre estas categorías y concretar los entregables aplicables. No exigir documentos de instalaciones inexistentes ni omitir una instalación intervenida por ser obra pequeña. Una categoría puede tener varios entregables concretos: no contar categoría y documentos como dos obligaciones distintas.

Cómo se trabaja: desde la planeación se deja la lista con responsable, fecha y condición de cumplimiento. En la reunión semanal existente se revisan pendientes, próximos vencimientos y cambios que obliguen a agregar o excluir entregables. No crear otra reunión ni reconstruir la lista cada semana. Los cambios conservan quién, cuándo y por qué.

Permitir agregar entregables especiales. No aplica o exclusión requiere justificación y validación por usuario autorizado, con historial, sin borrado definitivo. Estar atrasado no es motivo para excluir. Si existe un compromiso con el cliente, la exclusión debe estar respaldada por el cambio de alcance correspondiente. El reparto exacto de permisos sigue por concretar conforme a las autoridades del proceso, sin ampliar accesos reales con este ticket.

Distinguir listo/aprobado internamente, entregado al cliente y aceptado cuando corresponda. Para acreditar entrega, vincular documento final/versión y evidencia de envío o entrega; añadir aceptación cuando sea exigida. Tener el archivo en el ERP no demuestra que el cliente lo recibió. El acta de entrega es un entregable; su firma no debe marcar automáticamente cumplidos los anexos o pendientes que falten.

Reutilizar lista y repositorio existentes, sin duplicar documentos. Indunnova debe mostrar el ajuste mínimo y qué funciones ya existen. CONSOF concreta la lista de cada proyecto; todavía no afirmamos que esta configuración esté implementada.

Pruebas previstas: obra pequeña con plano aplicable y obra mayor sin esa intervención; agregar un certificado particular; excluir con justificación y rechazar exclusión sin permiso/motivo; archivo listo pero no entregado; entrega con aceptación pendiente cuando se exige; acta con anexos pendientes; cambios revisados en comité sin perder historial. No son pruebas ya ejecutadas.

Queda pendiente la fórmula del indicador y su corte. Debemos conciliar la diferencia entre «aprobados/totales» del Excel y «aceptados sin reproceso significativo/evaluados» del documento rector; no tratarlos como equivalentes ni crear automáticamente un indicador general del área sin definición. Las categorías y la rutina sí quedan aprobadas con este comentario.

PRIORIDAD MEDIA. NO BLOQUEA SALIDA DEL ERP. Esto no elimina obligaciones de entrega al cliente. Ticket abierto hasta desarrollo y validación. El acta de inicio con cliente (3.1) y su conexión con el checklist/indicador de arranque se están tratando en #348, separadamente del acta de aprobación interna (2.6).

Mejora aprobada por CONSOF: envío y conformidad de entregables desde el ERP

Queremos que el ERP ayude a hacer la entrega y recoger la respuesta del cliente, sin obligar al responsable a reconstruir después el envío con pantallazos. PRIORIDAD MEDIA: NO BLOQUEA LA SALIDA DEL ERP. Es una ampliación funcional del #349, pendiente de desarrollo y pruebas.

Alcance: entregables documentales al cliente (planos finales, manuales, certificados y actas aplicables). No estamos solicitando aquí medir la calidad de ejecución de la obra o del servicio ni desarrollar un módulo integral de calidad. Se conserva la lista mínima y los ajustes por alcance acordados en el comentario anterior.

Recorrido solicitado:
1. Desde la lista de entregables del proyecto, el responsable selecciona uno o varios documentos completos y revisados, confirma el contacto del cliente y pulsa “Enviar para revisión”. Reutilizar los archivos del repositorio y conservar la versión enviada.
2. El ERP envía un correo con un enlace y registra destinatario, fecha, documentos y resultado del envío. El correo será el canal principal; WhatsApp o QR podrán compartir el mismo enlace, sin crear respuestas separadas.
3. El cliente consulta o descarga los documentos y responde por cada entregable: “Recibido a conformidad” o “Tengo observaciones”, dejando el detalle de lo que se debe corregir. Preferimos que no necesite crear una cuenta en el ERP. Indunnova debe proponer cómo verificar al destinatario y proteger el acceso a los documentos de ese proyecto.
4. Esa respuesta queda asociada al entregable, su versión, la persona y la fecha. Actualiza su estado y alimenta el cumplimiento sin que CONSOF vuelva a digitar la aceptación. La revisión interna sigue siendo responsabilidad de CONSOF.

Reglas:
- Cargar un archivo, enviar el correo o abrir el enlace NO equivale a aceptación. Un envío fallido tampoco acredita entrega.
- Cuando la condición del entregable exige aceptación del cliente, solo se completa con esa conformidad y la revisión interna exigida. No imponemos firma para todo documento: se respeta la condición de cumplimiento definida en la lista.
- Si se envían cinco documentos y uno recibe observaciones, los otros cuatro pueden quedar aceptados. No aprobar o rechazar todo el paquete automáticamente.
- Una nueva versión conserva la anterior y sus respuestas; requiere una nueva revisión/aceptación aplicable. No hereda silenciosamente la aprobación ni duplica el entregable. Conservar cortes históricos cerrados.
- Reutilizar el recorrido de firma de actas probado en #316 y el mecanismo de aprobación/versiones que ustedes identificaron. La firma de un acta acredita esa acta; no completa automáticamente anexos faltantes. Solo podrá acreditar documentos expresamente identificados en su aceptación y accesibles al cliente.
- Si el cliente responde por un canal externo, permitir registrar la evidencia, quién respondió, fecha real y fecha de registro, por usuario autorizado. Es alternativa, no el recorrido principal. No ampliar permisos reales con este requerimiento.

Dependencias y alcance de la implementación:
- Coordinar el envío con #320 y reutilizar lista, repositorio y aprobación de actas. Esto no reabre #316 ni da por terminada la integración del correo.
- La actualización del estado será automática; la fórmula del porcentaje, denominador y corte sigue pendiente de concretar en #349. No sustituirla por la fórmula de calidad de ejecución ni inventar un indicador general del área.
- Mantener esta mejora identificada por separado dentro del trabajo del #349 para poder programarla sin bloquear la operación del ERP. No elimina los compromisos de entrega al cliente.

Les pedimos confirmar qué componentes ya funcionan y cuáles deben desarrollar, mostrar desde qué pantalla se enviaría y cómo vería/respondería el cliente, y proponer el ajuste mínimo. Si necesitan separarlo en un ticket de desarrollo, conservar la referencia a este acuerdo, sin duplicar el alcance.

Pruebas de aceptación previstas (aún no ejecutadas): un archivo cargado sin envío no cumple; envío fallido no acredita entrega; abrir el correo no aprueba; aceptación de cuatro documentos y observación de uno; corrección y aceptación de nueva versión; firma de acta con anexo pendiente; evidencia externa trazable; cliente sin acceso a documentos de otros proyectos; aceptación registrada una sola vez y mismo resultado en las vistas que usen el indicador.

CONSOF define lista, responsables y condiciones de cada entrega. Indunnova confirma viabilidad, implementa y presenta el recorrido de prueba. El ticket permanece abierto hasta desarrollo y validación; este comentario registra el requerimiento aprobado, no una funcionalidad implementada.

Regla de cálculo semanal aprobada por CONSOF

Ya resolvimos la pregunta del denominador: se cuentan los entregables documentales al cliente que debían estar cumplidos a la fecha de corte, no todos los documentos futuros del proyecto.

Indicador = entregables cumplidos de ese conjunto / total de entregables aplicables exigibles a esa fecha × 100.

Ejemplo: el proyecto tiene 10 entregables, pero al corte solo vencían 4. Si esos 4 están cumplidos, el indicador es 100%; si hay 3 cumplidos, es 75%. Los otros 6 siguen visibles como pendientes futuros y no afectan todavía este porcentaje. Tampoco una entrega anticipada de esos 6 compensa un atraso de los 4 exigibles: numerador y denominador corresponden al mismo conjunto.

Es acumulado al corte: incluye los que ya debían estar cumplidos en semanas anteriores. Los atrasados no desaparecen al cambiar de semana. Cuando se cumplen, mejoran el resultado actual, sin borrar el atraso ni modificar silenciosamente cortes cerrados. Este indicador mide cumplimiento a la fecha; no afirma que todas las entregas se hayan hecho puntualmente.

Cumplido conserva la condición acordada para cada entregable: documento completo y revisado, entregado al cliente y con conformidad cuando se requiera. Subirlo, enviarlo o abrir el enlace no constituye por sí solo aceptación.

Si la lista está definida y aún no vence ningún entregable, mostrar “Aún no hay entregables exigibles”, sin porcentaje ni verde artificial. Si faltan la lista o las fechas necesarias, señalar datos incompletos; no confundir esa situación con ausencia de obligaciones.

Se conservan las exclusiones autorizadas con justificación e historial, sin borrar compromisos, y el control de versiones. Los cambios de fecha deben conservar trazabilidad; no mover una fecha para ocultar un atraso ni reescribir cortes cerrados. El detalle de permisos y autorización de reprogramaciones debe concretarse con las autoridades del proceso.

Pruebas a presentar: 4/4 = 100%; 3/4 = 75%; seis futuros no reducen el porcentaje; un futuro entregado anticipadamente no compensa un vencido pendiente; un atraso de la semana anterior sigue contando; aceptación posterior mejora el corte actual y conserva el histórico; ningún exigible no produce 100%; datos sin fechas no generan cumplimiento ficticio. Son criterios de aceptación, no pruebas ya realizadas.

Esta decisión reemplaza las frases anteriores que dejaban pendiente elegir entre todos los entregables del alcance o los exigibles al corte. El alcance sigue siendo entregables documentales al cliente; calidad de ejecución de obra/servicio queda fuera de este trabajo. No se crea otro indicador con este comentario.

Indunnova: por favor incorporar esta regla a la propuesta del #349 junto con el recorrido de envío y conformidad ya solicitado, e indicar de manera concreta cualquier definición restante que impida desarrollar o probar. No damos por aprobados automáticamente los permisos ni todas las propuestas anteriores por resolver esta fórmula.

PRIORIDAD MEDIA. NO BLOQUEA LA SALIDA DEL ERP. Permanece pendiente de implementación y validación; no cerrar el ticket por recibir esta definición.

Decisión aprobada por CONSOF — solicitudes y autorización de excepciones

Aplicar esta lógica tanto a entregables al cliente (#349) como a requisitos del checklist de inicio (#348), respetando las condiciones particulares de cada requisito. No es una autorización general para omitir obligaciones.

1. El responsable de elaborar o cumplir el requisito puede solicitar una excepción/No aplica o una modificación de fecha, explicando el motivo y aportando el soporte correspondiente. Ser coordinador o líder de Operaciones no permite aprobar su propia solicitud. Diego y los demás responsables podrán preparar, enviar y atender documentos según sus permisos, pero no eliminar por su cuenta una obligación.
2. Solo Ximena Suárez, Juan Esteban y David Villa podrán decidir estas solicitudes dentro de sus atribuciones. Ximena coordina Planeación y Control y puede aprobar o rechazar solicitudes de otros dentro de su autoridad. Si la solicitud corresponde a algo a cargo de Ximena y la presenta ella, la decisión corresponde a Juan o David.
3. Juan o David, como máxima autoridad en este flujo, pueden autorizar directamente una excepción dentro de su competencia, incluso sobre un requisito a su cargo. No inventar un superior ni simular una segunda aprobación. Registrar expresamente “Excepción autorizada directamente”, con autor, fecha, motivo y evidencia; distinguirla de una solicitud aprobada por otra persona.
4. Mientras la solicitud está pendiente o si se rechaza, la obligación y su fecha vigente permanecen. Una explicación, un archivo de verificación o una solicitud no bastan para retirarla del indicador. No borrar definitivamente el requisito.
5. Excepción autorizada NO significa documento elaborado, entregado ni aceptado. Mostrarla separadamente del cumplimiento. En #349, una exclusión de aplicabilidad aprobada sale del conjunto computable según las reglas acordadas, conservando el historial y sin reescribir cortes cerrados. Una prórroga cambia la fecha autorizada, no elimina el entregable ni oculta su fecha anterior. En #348 conservar la diferencia entre excepción y requisito realmente cumplido; no convertir una excepción en cumplimiento ni resolver por este comentario la discusión sobre requisitos críticos.
6. Antes de habilitar excepciones por tipo de requisito, identificar cuáles admiten decisión interna, cuáles exigen respaldo del cliente/cambio de alcance y cuáles no pueden omitirse por obligación aplicable. La máxima autoridad tampoco elimina obligaciones legales o compromisos externos desde el ERP. El ejemplo de “contrato” fue ilustrativo: NO autoriza omitir contratos ni define que ese requisito sea exceptuable.

Ejemplo: Diego solicita que el acta de inicio no aplique; sigue pendiente hasta decisión autorizada y solo puede exceptuarse si el proceso permite hacerlo. No confundir el acta de inicio con el cliente con la aprobación interna de la planeación. Igual control para un plano o certificado al cliente.

Conservar requisito original, solicitante, fecha de solicitud, motivo, soporte, decisión, decisor, fecha de decisión y valores antes/después. Al rechazar, registrar el motivo. Reutilizar el historial existente.

Pruebas que deben presentar: responsable sin autoridad no puede autorizar; solicitud pendiente no elimina obligación; aprobación/rechazo de Ximena sobre solicitud ajena; Ximena no aprueba su propia solicitud; Juan o David autorizan directamente con trazabilidad; falta de justificación impide autorizar; requisito no exceptuable no se omite; exclusión/prórroga no reescribe históricos ni aparece como documento cumplido.

Indunnova: esta decisión concreta los usuarios autorizadores antes pendientes; confirmar cómo soportarlo con los permisos y pantallas existentes, y presentar los tipos de requisito y límites de autoridad que aún necesiten definición de CONSOF. No modificar por inferencia otras responsabilidades de la RACI, usuarios de prueba ni permisos ajenos a este flujo. Es un requerimiento aprobado, pendiente de implementación y pruebas; no estamos reportando cambios ya hechos en producción.

Para #349 se mantiene prioridad MEDIA y NO BLOQUEA LA SALIDA DEL ERP. Esta nota no rebaja automáticamente la prioridad de los controles operativos de inicio del #348. No cerrar los tickets por recibir esta definición.

Corrección de CONSOF: permisos por cargo, no por nombre de persona

Esta precisión prevalece sobre las referencias personales del comentario anterior. Configurar la autoridad por cargo vigente y usuario que lo ocupa, no por nombres fijos:
- Líder de Planeación y Control: decide solicitudes de otros responsables dentro de su autoridad. No aprueba solicitudes propias sobre requisitos a su cargo.
- Líder de Visión y Proyectos y Líder de Gestión y Desarrollo: resuelven las solicitudes propias de Planeación y Control y pueden autorizar directamente dentro de su competencia, con motivo, evidencia e historial.
- Responsable asignado al requisito/entregable: prepara y solicita; no obtiene permiso de excepción por ser coordinador o Líder de Operaciones y Calidad. La validación técnica de preparación y la autorización de excepciones son funciones distintas.

Usar la denominación oficial del cargo que corresponda en el catálogo vigente y su relación con el usuario; no crear perfiles duplicados por variaciones del nombre. Mantener los límites por tipo de requisito y evitar aprobar solicitudes propias de Planeación incluso si el usuario tiene varios perfiles. No ampliar estos permisos por el solo hecho de ser administrador técnico del sistema.

La regla se vincula al cargo; el historial debe conservar además la persona que efectivamente solicitó/decidió, el cargo con el que actuó, la fecha, el motivo y los soportes. Un cambio de ocupante no reescribe decisiones anteriores.

Se mantienen las reglas aprobadas sobre obligación pendiente hasta decisión, rechazo, decisión directa de máxima autoridad, excepciones distintas de cumplimiento y conservación de históricos. Esta es una corrección al requerimiento; no indica que los permisos ya se hayan cambiado en producción.

Para terminar la definición sin ampliar el alcance, presenten las diferencias concretas que aún necesitan decisión de CONSOF y un caso de prueba del flujo. Evitar volver a preguntar por reglas ya resueltas en los comentarios vigentes.