Editar #349 — Portal de tickets CONSOF

Editar reporte #349

Editado 3 veces por David Villa — CONSOF — última: 1 día,19 horas atrás

Tu nombre (para registrar quién editó)

Asunto

Descripción

## Alcance vigente aclarado por CONSOF — 12/11/2026
Este indicador corresponde a ENTREGABLES AL CLIENTE según el alcance del proyecto: por ejemplo, bono o manual de garantía y planos eléctricos/hidrosanitarios que debamos entregarle. No mide todos los documentos internos ni la preparación para iniciar la obra. Esta aclaración prevalece sobre cualquier interpretación más amplia de los comentarios anteriores.

Separar tres cosas: (1) requisitos de inicio, tratados en checklist/#348; (2) documentos y actividades de gestión durante el ciclo; (3) entregables comprometidos al cliente, objeto del #349. Un plano usado para ejecutar no entra automáticamente aquí: solo si también es una entrega comprometida al cliente. Puede reutilizarse su archivo sin confundir ambas obligaciones.

La matriz es una referencia para construir la base, NO prueba que sus 25 productos del ciclo constituyan la lista al cliente ni que A/B/C determine por sí sola esa lista. Identificar cuáles corresponden al cliente y completar según contrato/alcance. Se conservan adiciones por alcance y exclusiones autorizadas con motivo e historial, sin borrado definitivo. Los permisos exactos siguen pendientes.

En #348, la tabla publicada por Indunnova contempla planos/especificaciones/memoria recibidos (6), presupuesto aprobado (11), cronograma (12) y validación interna (16). No crear otro indicador para esos documentos con este ticket. La revisión de esa tabla no valida todas sus propuestas de aplicabilidad.

Distinguir preparado/aprobado internamente, entregado al cliente y aceptado por el cliente cuando corresponda. No contar aprobación interna como prueba de entrega. Falta acordar qué hito cierra cada entregable y alimenta el indicador; no imponer firma del cliente para todo documento. También queda pendiente elegir total del alcance o exigibles al corte. El ejemplo conversacional de planos para ejecutar no es un criterio aprobado y no debe implementarse.

Mantener prioridad MEDIA, no bloquea salida del ERP. No se declara implementado ni validado. Las verificaciones descritas abajo son históricas; hoy el acceso directo al checklist solicitó inicio de sesión.

## Aclaración tras contrastar matriz y ERP — 10/11/2026
La base de productos del ciclo de gestión está descrita en «Gestion de proyectos Consof final V2.xlsx»: la hoja «1. Clasificación Proyecto» indica diligenciar en la primera reunión de inicio y que define los entregables obligatorios por nivel A/B/C; «FLUJO DEL PROYECTO» relaciona actividades y productos, y «MATRIZ RACI» asigna responsables y autorizadores. No corresponde diseñar un origen paralelo del listado sin reconciliar esta base.

Verificación de solo lectura: el proyecto de prueba 48 tiene clasificación B en /projects/48/clasificacion/ y muestra entregables y asignaciones RACI en /projects/48/raci/. La RACI visible incluye una fila 5.6 «Validación de Lecciones Aprendidas», adicional a las 25 actividades de la matriz fuente. Mostrar una fila y asignarle R/A/C/I no acredita aprobación ni inclusión automática en el indicador. Fase 4 sigue mostrando «Pendiente: sin modulo de calidad».

Respuesta técnica recibida de Indunnova el 09/11 a las 21:21: existe una lista de entregables del ciclo generada al clasificar, con estados y soporte; no existe un registro general de aprobación con condición, autoridad y evidencia. El repositorio y las aprobaciones de actas son reutilizables. Se reconoce atendida la consulta inicial sobre componentes existentes; la propuesta de integración aún no es implementación ni aprobación de sus reglas.

Siguiente definición concreta: contrastar la lista generada y su aplicabilidad A/B/C con la matriz y señalar cómo se vinculan o desglosan allí los entregables específicos del alcance (por ejemplo, planos eléctricos finales y manual de garantías). Indunnova debe mostrar la pantalla o recorrido para consultar esa lista y un caso de proyecto, y explicar qué parte de la aprobación debe añadirse. CONSOF debe confirmar sobre ese ejemplo cuáles elementos integran el KPI. No asumir que todos los 25 ítems, todos los archivos ni exclusivamente los documentos de cierre constituyen por sí solos el total definitivo.

La intención expresada por CONSOF de medir entregables exigidos para entrega/cierre y los ejemplos siguientes se conservan. Se corrige haber presentado su relación con el catálogo empresarial como totalmente resuelta: esa correspondencia está pendiente de validación, junto con las reglas de cálculo. No se aprueba crear otro listado independiente, modificar la RACI, ni cerrar este ticket o el #62. Esta aclaración actualiza las afirmaciones anteriores de «universo conceptual resuelto».

## Resultado de la revisión funcional
El indicador de Calidad «Entregables aprobados / totales» todavía no tiene una fuente operativa verificable en la Fase 4. Se abre seguimiento específico del #62 y de la pregunta 7 del #104. No se solicita reabrir el comité ni rehacer su alcance, ni se declara terminada la Fase 4.

## Evidencia actual
Revisión de solo lectura del 10/11/2026 (UTC), proyecto de prueba AOP-0726-001, id 48.
1. Abrir la ficha del proyecto y seleccionar Fase 4: https://consof-rvfp6uj2va-uc.a.run.app/projects/48/?tab=fase4
2. En «KPIs de gestión — Fase 4.2», Calidad muestra «Cumplimiento de calidad», valor «—», meta >=95% y «Pendiente: sin modulo de calidad». Se adjunta captura.
3. El repositorio del proyecto contiene dos documentos; su existencia no demuestra que sean los entregables computables ni que haya aprobación válida para este KPI.
4. El #104 ya declaró que Calidad no tenía dónde calcularse y preguntó si debía separarse su fuente. Su cierre del 21/09 fue para continuar modificaciones en nuevos tickets. El #109 cubre la organización de las pantallas, no acredita la validación funcional de este cálculo.
No se crearon ni aprobaron entregables, ni se modificaron datos del proyecto. La prueba numérica de extremo a extremo queda bloqueada por la falta de fuente identificada; no está aprobada.

## Base empresarial contrastada
Documento «Gestion de proyectos Consof final V2.xlsx»:
- «4. Seguimiento Semanal»: Calidad = Entregables aprobados / totales, meta >=95%.
- «7. Tablero KPIs»: «Entregables aprobados»; verde >=95%, amarillo 85%–94%, rojo <85%.
- «5. Informe Mensual»: mismo indicador y meta.
- «MATRIZ RACI» y «FLUJO DEL PROYECTO»: responsables y aprobadores dependen del entregable. La aprobación interna y la aceptación del cliente no deben confundirse.
La fórmula porcentual es aprobados / total computable x 100. El documento revisado no permite fijar sin aclaración qué integra ese total en cada corte. Tampoco habilita a contar todos los archivos cargados como aprobaciones.

## Qué debe responder Indunnova para desbloquearlo
1. Confirmar si existe actualmente una fuente estructurada reutilizable de entregables y aprobaciones. Si existe, indicar pantalla, campos y un caso de prueba. Si no existe, señalar el componente mínimo faltante.
2. Proponer la integración mínima con ficha, dashboard, informe mensual y snapshot del comité; evitar cálculos diferentes para el mismo corte y fuente.
3. Indicar qué puede reutilizarse del repositorio y de los flujos actuales de aprobación, sin crear un módulo de calidad completo por inferencia de este ticket.

## Intención funcional confirmada por CONSOF — correspondencia con matriz pendiente
«Entregables aprobados» se refiere a los resultados y documentos comprometidos AL CLIENTE según el alcance del proyecto; su hito de cumplimiento y cálculo se concretarán conforme a la aclaración vigente.

Esta precisión fue confirmada por David Villa en la revisión del indicador. Actualiza la pregunta sobre qué tipos de entregables contar y el criterio general de aceptación; no significa que el indicador ya esté implementado o validado.

### Entregables que pueden aplicar
- Planos eléctricos e hidrosanitarios finales, y otros planos exigidos dentro del alcance del proyecto.
- Manual de garantías, cuando corresponda entregarlo.
- Manuales de operación y mantenimiento de los equipos o instalaciones que los requieran.
- Acta de entrega, como entregable de formalización: completa y con las aprobaciones o firmas exigidas.
- Soporte del trámite de pólizas que corresponda, cuando sea exigible para ese proyecto. La tarea de gestionar el cierre, por sí sola, no constituye el entregable; se requiere el resultado o soporte definido. No se establece que todas las pólizas deban cerrarse en la fecha de entrega de la obra.
Estos son ejemplos de aplicabilidad, no una lista universal obligatoria para todos los proyectos.

### Cómo debe soportarlo el ERP
Cada proyecto debe tener su propia lista de entregables aplicables, definida desde la planeación según alcance y requisitos. Por cada entregable se debe identificar como mínimo: qué debe entregarse, responsable, fecha prevista y condición/autoridad de aprobación, con evidencia del resultado.
La RACI orienta quién prepara y quién aprueba. No convertir automáticamente todas las actividades de la RACI ni todos los archivos del repositorio en entregables de este indicador.
Los informes semanales y las actas de comité interno no se incluyen automáticamente: su finalidad ordinaria es el seguimiento de gestión. Un documento expresamente exigido como resultado de entrega/cierre se evalúa por su función y aplicabilidad, no por ser un PDF o por quién lo elaboró.

### Cuándo se considera aprobado
Existir, estar cargado o haberse generado en el ERP no equivale a estar aprobado. Cuenta como aprobado al satisfacer la condición de aceptación definida para ese entregable y proyecto, por la autoridad que corresponda, conservando evidencia y trazabilidad.
- Plano final cargado pero pendiente de revisión: aún no aprobado.
- Manual cargado con observaciones pendientes: aún no aprobado.
- Acta generada con firmas exigidas pendientes: aún no aprobada.
- Documento o resultado revisado y aceptado conforme a su condición aplicable: aprobado.
No se exige aceptación del cliente para todos los tipos por defecto: debe aplicarse cuando sea requisito de ese entregable. Tampoco una aprobación interna sustituye una aceptación externa exigida.

## Reglas de cálculo todavía pendientes de confirmación
La intención y la regla general de aprobación requieren concretar la correspondencia entre catálogo empresarial y entregables específicos. Antes de implementar el cálculo, CONSOF debe cerrar:
- Si el denominador incluye todos los entregables aplicables del alcance o solo los exigibles a la fecha de corte. La alternativa de contar únicamente los exigibles fue propuesta, pero aún no se da por aprobada.
- Tratamiento de «No aplica», cancelados y cambios de alcance, sin perder la trazabilidad del listado original.
- Fechas efectiva y de registro de aprobación; versiones, reaperturas y efectos sobre el corte e históricos.
- Tratamiento de decimales del semáforo. Propuesta pendiente para evitar huecos: amarillo desde 85% hasta menos de 95%, verde desde 95%.
La parametrización de responsables y aprobaciones de cada entregable deberá ajustarse a la RACI/autoridades aplicables del proyecto, sin ampliar permisos por este ticket.

## Historia de usuario y validación
Como responsable de Planeación y Control, necesito conocer cuántos entregables computables están aprobados, de cuáles se trata y a qué corte corresponde el dato, para reportar calidad con evidencia.
Una vez aprobadas las definiciones anteriores, la entrega debe permitir comprobar:
- Numerador, denominador, porcentaje, meta, estado, fecha de corte y acceso al detalle que soporta el cálculo.
- 19 aprobados de 20 computables = 95% verde; 18/20 = 90% amarillo; 16/20 = 80% rojo. Son casos de aceptación propuestos, no pruebas ya ejecutadas.
- Sin fuente o sin base computable: explicación visible de «Sin datos»/«No evaluable», sin verde automático ni división por cero.
- Un documento cargado o un entregable pendiente/rechazado no pasa a aprobado solo por existir; aprobación por la autoridad aplicable y trazabilidad de quién/cuándo/evidencia.
- Versiones no duplican el mismo entregable; las reglas de corte e historial se verifican con el escenario acordado, incluyendo registro tardío y reapertura.
- Ficha, dashboard, informe y comité coinciden para el mismo corte. Los snapshots cerrados conservan lo aprobado históricamente.
La validación debe incluir usuario autorizado y caso negativo con usuario sin atribución para aprobar, mediante usuarios de prueba existentes o prueba del equipo; no se pide ampliar permisos de usuarios reales.

## Responsables, dependencias y cierre
Indunnova: confirmar fuente, propuesta técnica y pruebas tomando la definición funcional aprobada; CONSOF: confirmar las reglas de cálculo pendientes y la aplicabilidad/autoridad de cada entregable conforme al sistema de gestión/RACI; validación funcional conjunta sobre proyecto de prueba.
No incluye compras, costos, recepción de facturas, reabrir #104/#109, cambiar la RACI ni un módulo integral de calidad. «Inicio completo» se trata en #348.
Cierre únicamente con reglas confirmadas, fuente implementada o vinculada y evidencia de pruebas positivas/negativas. Estado actual: intención funcional confirmada; correspondencia con catálogo A/B/C y RACI y reglas de cálculo pendientes de validación; componentes reutilizables identificados por Indunnova, aprobación general e integración aún no implementadas ni probadas; no resuelto.

Adjuntos existentes (1) — no se modifican

🖼

calidad-erp-pendiente-20261110.jpg

image/jpeg · 79,2 KB

Agregar nuevos adjuntos (opcional)

🎤 Grabar desde tu navegador

Arrastra archivos aquí o haz clic

Cancelar

Procesando los cambios

Estamos guardando lo que editaste y analizando los archivos nuevos con IA.
No cierres esta ventana.