Respuesta a las dos preguntas del portal:

1. UBICACIÓN DE LA MATRIZ
   Está en el archivo XLSX ya adjunto a este ticket: hoja «2. Checklist Inicio», columna «Aplica (A/B/C)». Debe contrastarse con «1. Clasificación Proyecto», «MATRIZ RACI» y la nueva hoja «Criterios inicio 09Nov». No falta un segundo adjunto con esa matriz.
   La conciliación solicitada consiste en identificar los 25 ítems existentes, su aplicabilidad original, la aplicabilidad propuesta según la herencia A→B→C, la condición que permite «No aplica» y el rol responsable de validarla. Todavía no afirmamos que esa matriz detallada esté corregida o configurada en el ERP: pedimos presentarla para validación CONSOF antes de migrar. La aclaración aprobada resuelve el criterio general y evita interpretar una marca A/B como exclusión automática de C.

2. EJEMPLO ILUSTRATIVO DE «NO APLICA» (no corresponde a un contrato real ni modifica datos actuales)
   Ítem: «Solicitud y pago de anticipo (si aplica)».
   Motivo: «El contrato vigente establece pago contra actas de avance y no pacta anticipo del cliente».
   Soporte: vínculo al contrato aprobado y su versión/cláusula de pagos.
   Registro: persona que propone el no aplica y fecha/hora; Ximena/Planeación consolida, con revisión de la condición por Administración/Finanzas cuando corresponda, y Diego/Operaciones valida la preparación conforme a la RACI y delegaciones vigentes. Deben quedar identificados el validador, fecha y decisión.
   Resultado: una vez validado, el ítem se excluye del denominador y conserva motivo y evidencia. Si sí hay anticipo pactado pero no se ha recibido, sigue pendiente; no se marca «No aplica». Una excepción autorizada tampoco suma como completado.

Este ejemplo concreta los criterios 3, 5 y 17 de la aclaración; no otorga nuevos permisos ni exige una segunda carga del contrato.

Aclaración solicitada por David: acta de inicio con el cliente y conexión con el indicador.

El acta de aprobación interna del plan (2.6) y el acta de inicio con el cliente (3.1) son documentos distintos. En los 25 ítems de la tabla publicada aquí no aparece el 3.1 como requisito independiente. Necesitamos que no quede por fuera del control de arranque ni de su medición.

Confirmen cómo cuenta actualmente el acta del cliente en el checklist y en «Proyectos con inicio completo». Si solo alimenta «Inicio formalizado», propongan el ajuste mínimo para vincular su estado al control de inicio y al resultado del indicador cuando sea exigible. Reutilizar el acta y sus firmas existentes, sin otra carga, sin confundirla con 2.6 y sin contar dos veces la misma obligación. Firmar el acta tampoco debe completar automáticamente los demás requisitos.

No afirmamos haber probado una falla de cálculo en el ERP: señalamos una brecha en la tabla y en la conexión descrita. Mostrar un caso con checklist preparado y acta pendiente, otro con acta formalizada y requisitos pendientes, y otro con ambos cumplidos. Conservar fechas reales e históricos; firmar después no vuelve completo el inicio anterior.

Antes de modificar la fórmula, conciliar también la diferencia documental: el Sistema de Gestión del Área de Proyectos v1.1 habla de controles críticos resueltos y al menos 90% del total, mientras la aclaración posterior del 09Nov y este ticket describen checklist aplicable completo. Presentar la regla vigente y el tratamiento del acta para confirmación de CONSOF, sin escoger silenciosamente un criterio ni cambiar resultados históricos. Este comentario no autoriza ampliar permisos ni cambiar las demás reglas pendientes de validació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.

Aclaración específica del #348: esta decisión actualiza el punto que proponía a Diego como validador de “No aplica” (respuesta del 09/11 y ejemplo anterior). Diego conserva su función técnica de validar la preparación real conforme al proceso; esa función NO le concede autorización para exceptuar requisitos ni aprobar su propia solicitud. Las revisiones técnicas, financieras o de SST necesarias siguen aportando soporte, pero la decisión de excepción corresponde a los usuarios y condiciones definidos arriba. En el checklist, “No aplica” autorizado excluye; una excepción para proceder con un requisito aún aplicable no suma cumplimiento ni lo elimina. No modificamos aquí la aplicabilidad A/B/C de los ítems pendientes ni autorizamos una migración automática de datos.

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.

Decisión aprobada por CONSOF — cuatro mínimos de preparación también en proyectos tipo A

Respondemos la decisión pendiente sobre los ítems 13, 14, 15 y 16 de su matriz conciliada. SÍ aplican también en A, y se mantienen para B y C. La profundidad será proporcional al alcance y complejidad; no exigimos cuatro documentos nuevos ni una nueva reunión obligatoria.

1. Responsables/RACI: antes de iniciar debe estar claro quién coordina, ejecuta y valida. Reutilizar las asignaciones del proyecto y la RACI existente. No pedir transcribirlas en otro archivo.
2. Riesgos: revisar los riesgos relevantes del trabajo y las medidas acordadas. En un servicio pequeño puede ser un registro breve, vinculado a los controles existentes de Operaciones y Calidad y de SST cuando corresponda. Una casilla marcada sin revisión real no acredita cumplimiento.
3. Indicadores aplicables: dejar definido qué se va a seguir y de qué información del plan saldrá, usando las fechas, actividades y entregables ya registrados. No exigir un Excel adicional ni bloquear el inicio porque un indicador aprobado esté pendiente de desarrollo tecnológico. Distinguir “indicadores definidos” de “cálculo automático implementado”; no inventar datos ni dar por probado un cálculo inexistente.
4. Aprobación interna del plan: registrar la validación por el cargo autorizado sobre la versión del plan, con fecha y evidencia. Mantener las atribuciones vigentes de Planeación y Control y Operaciones y Calidad. Esta aprobación interna (2.6) NO reemplaza el acta de inicio con el cliente (3.1), ni completa automáticamente los demás requisitos.

Ejemplo ilustrativo para demostrar el recorrido: servicio pequeño de cambio de luminarias y reparación de una pared. El equipo revisa el alcance aprobado, responsables, riesgos como altura/corte de energía y acceso al local, fechas, recursos y entregables aplicables; después valida el plan. El ERP debe vincular esa información sin duplicarla. Si falta una autorización necesaria para ejecutar una actividad, debe seguir visible como pendiente: aprobar el plan no la resuelve.

Pruebas solicitadas:
- Proyecto A con los cuatro mínimos visibles y registrables de manera sencilla, reutilizando información y soportes existentes.
- Responsable o revisión de riesgos pendiente: no marcar completo ese requisito por existir el proyecto.
- Indicadores definidos pero automatización pendiente: reconocer la definición sin simular cálculos ni exigir que termine ese desarrollo para iniciar.
- Plan con versión/validador/fecha; acta del cliente aún pendiente: conservar ambos estados separados.
- Casos B y C conservan los cuatro mínimos y el detalle que les corresponda.
- Mantener históricos: completar después del arranque no convierte retroactivamente ese arranque en completo. No migrar ni reescribir proyectos iniciados automáticamente.

Usar CARGOS y usuario vigente asignado, no nombres personales en las reglas. Se conservan las autoridades y el control de excepciones publicados anteriormente. Esta decisión resuelve únicamente la aplicabilidad en A de 13, 14, 15 y 16; no aprueba de forma implícita todas las demás propuestas de la tabla, condiciones de No aplica ni cambios de responsables.

Indunnova: incorporar esta decisión a la matriz conciliada y presentar el recorrido mínimo en un proyecto de prueba, señalando lo que ya existe y el ajuste que falta. Consolidar las decisiones restantes en una lista concreta, sin volver a preguntar por estos cuatro ítems. Siguen pendientes de conciliación los condicionales 6, 10 y 19, los responsables señalados en su tabla y la regla global de inicio completo/controles críticos indicada en el comentario del acta de inicio. No confundir esos pendientes con esta decisión ya resuelta.

Estado: requerimiento aprobado, pendiente de implementación y pruebas. No declaramos validado el indicador ni cerramos #348 o #62. No creamos con este comentario un nuevo módulo ni otra carga documental.

Decisión aprobada por CONSOF — definición de “Inicio completo”

Resolvemos la diferencia que habíamos señalado entre el criterio de requisitos críticos y 90% del total, y el checklist aplicable completo. Para este requerimiento, la regla aprobada es:

1. INICIO COMPLETO: el 100% de los requisitos aplicables al arranque está cumplido y validado cuando comienza realmente la ejecución. Se refiere a la preparación para las primeras actividades del plan, no a tener comprados o preparados todos los recursos de la vida del proyecto.
2. INICIO CON EXCEPCIÓN AUTORIZADA: se permitió arrancar con algún requisito aplicable pendiente que admite excepción, mediante el circuito de autoridad por cargo ya definido. Conservar el pendiente, responsable, motivo, decisión y seguimiento. NO cuenta como inicio completo. Un requisito que no admite excepción sigue siendo obligatorio; esta decisión no autoriza omitirlo.
3. NO APLICA AUTORIZADO: el requisito no corresponde al proyecto según una condición justificada y validada. Se excluye del denominador conservando evidencia e historial. No confundirlo con un requisito que sí corresponde pero está pendiente.

Ejemplo de prueba: 10 requisitos, 2 No aplica autorizados = 8 aplicables. Con 8 cumplidos y validados al arrancar, inicio completo. Con 7 cumplidos y 1 pendiente con excepción autorizada, inicio con excepción e incompleto para este indicador. Un pendiente sin autorización no debe aparecer como inicio completo ni como excepción autorizada.

El indicador del área conserva su fórmula: proyectos iniciados en el período que estaban completos al arrancar / total de proyectos iniciados en ese período × 100. El proyecto iniciado con excepción permanece en el denominador, pero no entra en el numerador. Ejemplo: 5 proyectos iniciados, 4 completos y 1 con excepción = 80%.

No confundir dos porcentajes: el 100% define cuándo UN proyecto está completo al iniciar. Esta decisión no cambia la meta del 90% del indicador del ÁREA ya descrita en este ticket. Tampoco cambia el indicador de entregables al cliente del #349.

Conservar fecha real del inicio y del cumplimiento, fecha de registro, validaciones y evidencia. Resolver realmente un pendiente después del arranque no convierte ese arranque en completo. Conservar las reglas de registro tardío sustentado y corrección validada, sin reescribir silenciosamente históricos. Sin proyectos iniciados, mostrar ese estado y no un 100% artificial. Una lista vacía o sin validar no acredita inicio completo.

Se mantiene la separación entre acta de inicio con el cliente, aprobación interna del plan, inicio formalizado e inicio completo. La firma de un acta no completa automáticamente el resto del checklist. Los permisos se definen por cargo y el historial identifica a la persona que actuó.

Esta confirmación resuelve la pregunta de 90% frente a 100% para clasificar el inicio del proyecto y debe reflejarse en la especificación funcional vigente. No afirmamos que los documentos fuente hayan sido editados ni que el ERP ya lo implemente. No migrar retrospectivamente resultados de proyectos iniciados sin una regla validada.

Indunnova: incorporar esta definición y presentar los casos anteriores, más un requisito cumplido después del inicio, uno No aplica aún pendiente de autorización y el período sin inicios. Son pruebas requeridas, no pruebas ejecutadas. Mantener identificados los demás pendientes de aplicabilidad y responsables de la matriz, sin volver a pedir esta decisión ya aprobada. El ticket continúa pendiente de implementación y validación; no cerrar #348 ni #62 con este comentario.

Bloque aprobado por CONSOF — información técnica, subcontratistas y cargos del checklist

Respondemos las condiciones pendientes de los ítems 6, 10 y 19 de su tabla, con preparación proporcional al trabajo real y sin nuevos documentos por defecto.

Ítem 6 — planos, especificaciones o memoria:
Exigir la información técnica necesaria para ejecutar el alcance. Puede acreditarse con plano, especificación o croquis, según el trabajo y las exigencias aplicables. Reutilizar los soportes recibidos/aprobados y registrar la revisión correspondiente. No aceptar “No aplica” únicamente porque el proyecto sea pequeño o no incluya diseño: un servicio sin diseño contratado también puede necesitar planos o información técnica. No sustituir un plano exigido por un croquis insuficiente. La forma del soporte depende del trabajo; debe permitir ejecutar con claridad. Planeación y Control consolida la información con la validación técnica que corresponda de Operaciones y Calidad.

Ítems 10 y 19 — ofertas/preparación y documentación de subcontratistas:
Para el arranque, exigir lo correspondiente a quienes intervienen en las primeras actividades del plan vigente. Si esas primeras actividades se ejecutan sin subcontratistas, permitir “No aplica” justificado y autorizado por el circuito aprobado. No confundir ausencia de subcontratistas con un contratista necesario que aún no está seleccionado o preparado: en este último caso sigue pendiente. Los que entren después deben estar preparados antes de su intervención; no desaparece esa obligación por haber marcado No aplica al arranque. Mostrar y seguir esa preparación con las actividades/controles existentes, sin alterar retroactivamente el resultado del inicio ni duplicar el proceso de compras tratado en otros tickets.

Distribución por CARGO, conservando la matriz:
- Planeación y Control consolida el checklist y sus evidencias.
- Operaciones y Calidad responde por la preparación técnica, frentes de trabajo y personal. La visita y coordinación de campo corresponden a Operaciones o al coordinador asignado conforme al proyecto.
- Operaciones y Calidad trabaja con Suministros en las ofertas y preparación de subcontratistas.
- Talento Humano y SST participa en los requisitos documentales y de seguridad; se conserva la participación de Gestión y Desarrollo donde corresponde según la matriz.
- La responsabilidad de contrato/orden con el cliente se conserva en Visión y Proyectos según la matriz conciliada; no trasladarla a Abastecimiento por la etiqueta heredada.

Usar los cargos oficiales vigentes y el usuario asignado, sin nombres personales fijos ni cambios masivos de usuarios. Mantener diferenciadas la validación técnica y la autorización de No aplica/excepciones: esta última se rige por la decisión por cargos ya publicada, incluida la restricción de solicitudes propias de Planeación y Control y la decisión directa de máxima autoridad con trazabilidad.

Pruebas solicitadas:
1. Servicio pequeño sin diseño contratado que sí necesita información técnica: no queda exento automáticamente y reutiliza el soporte adecuado.
2. Trabajo que exige plano: un soporte insuficiente no acredita cumplimiento.
3. Arranque sin subcontratistas: No aplica sustentado y autorizado; su solicitud pendiente no elimina el requisito.
4. Subcontratista necesario en la primera actividad pero sin preparación/documentación: sigue pendiente.
5. Subcontratista previsto para una fase posterior: no obliga a tener toda su preparación al inicio, pero queda controlada antes de intervenir, sin reescribir el resultado histórico del arranque.
6. Cargos responsables y autorizadores coherentes con las reglas vigentes, sin que el responsable pueda quitarse una obligación por validar técnicamente el proyecto.

Con este bloque quedan contestadas las decisiones de aplicabilidad y distribución de cargos señaladas en la tabla del 09/11, junto con las aprobaciones posteriores de los cuatro mínimos en A, las autoridades por cargo y el 100% de requisitos aplicables para inicio completo. Esto cierra esas preguntas de definición, NO certifica que la implementación esté terminada ni que todos los datos actuales estén correctos.

Siguiente entrega solicitada a Indunnova: consolidar la matriz funcional con estas decisiones y presentar un proyecto de prueba sencillo que demuestre el recorrido y el indicador. Señalar por separado cualquier contradicción concreta que persista, lo ya implementado y el ajuste pendiente. Conservar evidencias e históricos; no migrar proyectos iniciados automáticamente, no tocar cuentas de prueba y no reabrir #91. #348 y #62 continúan pendientes de implementación y validación. No se añaden indicadores ni módulos con este comentario.