Detalle Estructural
Módulos del Sistema SEPO
Conoce cómo cada componente individual engrana para crear el motor financiero determinístico de la industria.
Conoce cómo cada componente individual engrana para crear el motor financiero determinístico de la industria.
Este módulo no es una pantalla estética.
Es la puerta de control de capital .
Define:
En un sistema que protege decisiones antes de comprometer capital, el acceso no es
operativo: es control de responsabilidad.
Pertenece al Nivel 9 — UI / UX (Presentación) , pero con impacto en:
No contiene:
Debe delegar autenticación a backend seguro.
Indirectas pero críticas:
Esto es clave para trazabilidad institucional.
Lo que sí hace:
Lo que NO puede hacer:
Si el login tuviera lógica financiera, se rompería el contrato de capas.
1. SDK IA en frontend → exposición de API key.
2. Autenticación débil → decisiones sin trazabilidad.
3. Sesiones no versionadas → certificado sin identidad responsable.
4. Token sin expiración → riesgo legal en emisión de decisión.
En un sistema certificable, identidad ≠ detalle técnico.
Es responsabilidad jurídica.
En sotiware tradicional:
Login = acceso operativo.
En SEPO:
Login = habilitación para comprometer análisis de capital.
Diferencia clave:
El sistema no solo autentica usuario.
Autentica autoridad para decidir .
Este módulo no es una lista.
Es el orquestador institucional del sistema .
Sin proyecto activo, SEPO no existe.
Resolver:
Cada tarjeta representa un universo financiero aislado .
No hay contaminación cruzada.
Ubicación funcional:
Cada proyecto genera:
𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 ℎ𝑜𝑜𝑆𝑆𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃
Single Source of Truth por proyecto.
Cada estudio tiene:
Ese ID conecta:
Presupuesto
Romper el ID = romper trazabilidad.
Cada proyecto mantiene:
Nunca se comparten KPIs entre proyectos.
Eso evita:
Errores de estado global
Variables residuales
Snapshots contaminados
Implica:
Estado "Cerrado":
Este módulo controla la transición.
Lo que hace:
Lo que NO hace:
Es contenedor de contexto.
1. Reutilizar snapshot entre proyectos.
2. No regenerar ID al clonar.
3. Permitir modificar proyecto cerrado.
4. No separar estado UI del estado financiero.
5. Mezclar versiones de engine sin trazabilidad.
Este módulo es crítico para gobernanza.
En sotiware tradicional:
Proyectos = carpetas.
En SEPO:
Proyecto = contenedor determinístico de decisión financiera certificable.
Cada tarjeta es:
Un Digital Twin financiero independiente.
Mis Proyectos
Nunca al revés.
1titi Conclusión Técnica
Este módulo responde:
¿Dónde vive la decisión y bajo qué identidad matemática?
Sin este núcleo:
No hay aislamiento.
No hay trazabilidad.
No hay certificación.
Este módulo define la identidad contractual del flujo de capital .
No gestiona contactos.
Gestiona:
Es la base sobre la cual se:
Sin cliente validado → no existe cierre institucional.
Ubicación lógica:
No contiene:
Es una entidad inmutable de identidad comercial.
Interacciones indirectas pero críticas:
Si se altera el cliente después de emitir cotización → el hash cambia → se invalida
integridad.
Lo que sí impacta:
Lo que NO impacta:
Separación clara: identidad ≠ cálculo.
1. Duplicidad de clientes → contaminación documental.
2. Edición retroactiva sin versionado → ruptura de trazabilidad.
3. Cliente sin validación formal → riesgo legal.
4. Asociación débil usuario –cliente → responsabilidad ambigua.
En un sistema certificable, cliente es entidad jurídica , no dato editable casual.
En sotiware tradicional:
Clientes = base CRM.
En SEPO:
Cliente = nodo legal dentro del grafo financiero –decisional.
El módulo está diseñado para:
No es administrativo.
Es estructural.
Este módulo es la fuente primaria de costos unitarios del sistema .
Define:
No es un catálogo.
Es el origen estructural del costo directo.
Si aquí hay un error → se propaga a:
APU → Presupuesto → Flujo → RAM → Stress → Decisión.
Ubicación lógica:
No contiene:
Es input puro.
Flujo estructural:
Biblioteca
El Snapshot congela:
Si la biblioteca cambia después de generar Snapshot, no afecta decisiones pasadas.
Impacta directamente:
No impacta directamente:
Este módulo es multiplicador sistémico.
1. Duplicación de recursos → distorsión de costo real.
2. Precios sin moneda normalizada → incoherencia en FinancialModel.
3. Edición sin versionado → auditoría imposible.
4. Recurso mal tipificado (material como MO) → RAM falsamente inflado.
En SEPO, la “pala de $2.000” nace aquí.
En sotiware tradicional:
Biblioteca = lista editable.
En SEPO:
Biblioteca = base propagativa con impacto matemático obligatorio.
Características clave:
No es almacenamiento.
Es el primer eslabón del determinismo financiero.
Este módulo modela el costo laboral real estructural, no el sueldo nominal.
Responde:
No es una planilla salarial.
Es un motor de costo laboral con impacto financiero sistémico .
Ubicación estructural:
No depende del dominio principal.
No ejecuta decisiones.
No calcula KPIs globales.
Produce:
Es un sub -sistema determinístico integrado.
Flujo estructural:
LCSE
El Snapshot almacena:
Cambio en salario → cambia RAM → puede cambiar decisión.
Impacta directamente:
No impacta:
Es multiplicador financiero real.
1. Modelar sueldo líquido sin considerar costo empresa → RAM artificial.
2. Mezclar políticas salariales sin versionado → auditoría rota.
3. Usar supuestos legales incorrectos → exposición jurídica.
4. Duplicar Money VO entre engines → incoherencia matemática.
Este módulo toca capital real mensual.
No admite aproximaciones.
En sotiware tradicional:
Costo laboral = % sobre sueldo bruto.
En SEPO:
Costo laboral = motor matemático inverso y completo:
Además:
Modelo “Optimizado” vs “Tradicional” permite simular estructura sin alterar contrato
laboral real.
No es RRHH.
Es ingeniería financiera laboral.
Este no es un panel informativo.
Es la frontera formal entre cálculo y decisión .
Output del DecisionEngine.
Se activa cuando se viola al menos una regla jerárquica:
No es opinión.
Es convergencia sistémica.
Qué es:
Indicador de viabilidad ajustado por riesgo.
BSI base → ajustado por:
Interpretación:
Aquí: 0.67x → destruye valor esperado.
Sirve para detectar si el precio compite sacrificando capital.
Salida del Optimal Bid Engine.
Integra:
Importante:
Alta probabilidad ≠ buena decisión.
Se cruza con EV y RAM.
Peak real de capital comprometido.
Derivado de:
No es promedio.
Es el punto máximo de exposición.
Sirve para responder:
¿Sobrevivo si todo sale mal?
Conteo real de KPIs críticos activados.
Sin semántica decorativa.
Si ≥1 → la decisión puede quedar bloqueada.
Fórmula conceptual:
Margen base
– erosión esperada por stress
– impacto probabilístico
– exposición de capital
Si RAM < 0 → margen contable ilusorio.
Sirve para diferenciar:
Rentabilidad facturada vs rentabilidad sobreviviente.
Simulación temporal real:
Representa el déficit máximo de caja.
Sirve para detectar:
Si estás financiando la obra.
🛡🛡 Hard Floor Price ($11.829.030)
Precio mínimo defendible.
Incluye:
Si precio < Hard Floor → suicidio estructural.
Velocidad a la que el proyecto erosiona margen bajo stress.
Derivado de:
Sirve para medir fragilidad dinámica.
Responde:
¿Tengo colchón o estoy al borde?
Resultado de maximización de EV:
EV = WinProb × Margen
Sujeto a:
No busca ganar.
Busca maximizar valor esperado sostenible.
Mide ventaja estructural frente al mercado.
No es estética.
Es posición relativa real.
Pipeline:
IA Forense (sellada)
No depende de IA creativa.
Lista de drivers activados:
Esto evita decisiones contradictorias.
Indicador institucional.
Si se bloquea la licitación, este es el capital que no se expone.
Es la métrica de supervivencia.
RESUMEN FUNCIONAL DEL DASHBOARD
Este módulo responde las 12 preguntas estructurales:
1. ¿Existe margen real?
2. ¿Sobrevive al stress?
3. ¿Cuál es el peak de capital?
4. ¿Mi caja lo soporta?
5. ¿Hay riesgos bloqueantes?
6. ¿Cuál variable es más sensible?
7. ¿Estoy bajo Hard Floor?
8. ¿EV es positivo?
9. ¿WinProb compensa riesgo?
10. ¿Financio al cliente?
11. ¿Entro por presión?
12. ¿La decisión es consistente?
DIFERENCIA CLAVE
El mercado muestra números.
SEPO muestra si sobrevives.
A. RAM — Risk Adjusted Margin
Definición formal:
𝑅𝑅𝑅𝑅𝑅𝑅 =𝑅𝑅𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆 𝐵𝐵𝑆𝑆𝑆𝑆𝑆𝑆−𝐸𝐸𝑀𝑀𝑜𝑜𝑆𝑆𝐸𝐸𝑜𝑜ˊ𝑆𝑆𝑆𝑆𝑃𝑃𝑃𝑃𝑃𝑃𝑆𝑆𝑆𝑆−𝐼𝐼𝑆𝑆𝑆𝑆𝑆𝑆𝐼𝐼𝑆𝑆𝑜𝑜𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 ıˊ𝑆𝑆𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃
Donde:
Si RAM < 0 → el margen no sobrevive a incertidumbre.
No es contable.
Es margen sobreviviente.
B. Estrés de Caja
Modelo diario:
𝐶𝐶𝑆𝑆𝐶𝐶𝑆𝑆𝑃𝑃=𝐼𝐼𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃−𝐸𝐸𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃
Se calcula:
Capital at Risk:
max (∣𝐶𝐶𝑆𝑆𝐶𝐶𝑆𝑆𝑃𝑃∣ cuando 𝐶𝐶𝑆𝑆𝐶𝐶𝑆𝑆𝑃𝑃<0)
No promedio.
Peak real.
C. Hard Floor Price
𝐻𝐻𝑆𝑆𝑀𝑀𝐻𝐻𝐻𝐻𝐻𝐻𝑜𝑜𝑜𝑜𝑀𝑀 =𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆 𝑅𝑅𝑆𝑆𝑆𝑆𝐻𝐻𝑆𝑆𝑆𝑆 +𝐺𝐺𝐺𝐺+𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜 𝐻𝐻𝐸𝐸𝑆𝑆𝑆𝑆𝑆𝑆𝐼𝐼𝐸𝐸𝑆𝑆𝑀𝑀𝑜𝑜 +𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝑆𝑆𝑀𝑀 𝑅𝑅ıˊ𝑆𝑆𝐸𝐸𝑆𝑆𝑜𝑜
Incluye:
Precio < HardFloor → bloquea.
D. Value Destruction Velocity
𝑉𝑉𝑉𝑉𝑉𝑉 =Δ𝑅𝑅𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆
Δ𝑇𝑇𝐸𝐸𝑆𝑆𝑆𝑆𝑆𝑆𝑜𝑜
Deriva de:
Indica velocidad de colapso.
E. EV — Expected Value
𝐸𝐸𝑉𝑉=𝑊𝑊𝐸𝐸𝑆𝑆𝑊𝑊𝑀𝑀𝑜𝑜𝑊𝑊×𝑅𝑅𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆 𝑅𝑅𝑜𝑜𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑀𝑀𝐸𝐸𝑜𝑜
Pero condicionado a:
Orden jerárquico (bloqueante):
1. Riesgo contractual crítico
2. RAM < 0 severo
3. Capital at Risk > Capacidad empresa
4. Hard Floor violado
5. Burn crítico + Colapso rápido
6. EV negativo
7. Competitive weakness extrema
Si uno de los primeros se activa → se bloquea sin mirar los inferiores.
El sistema prioriza supervivencia > oportunidad.
Caso tipico:
Precio bajo → aumenta WinProb
Pero:
Entonces:
WinProb ↑
EV puede ↑
Pero DecisionEngine bloquea por RAM + Capital.
Esto evita entrar por ambición competitiva.
En la imagen:
¿Contradicción?
No.
Porque:
Alta probabilidad + EV positivo
NO compensan:
RAM negativo + colapso en 2 días + burn elevado
La decisión NO LICITAR es coherente.
El sistema está priorizando estabilidad.
Diagnóstico estructural del caso mostrado
El proyecto:
Pero:
Conclusión técnica:
Es rentable en Excel.
Es frágil en la realidad.
El motor decidió correctamente.
Condiciones mínimas necesarias
Para que el DecisionEngine desbloquee:
1. RAM ≥ umbral interno (ej. > 3 –5%)
2. Capital at Risk ≤ capacidad tolerable
3. Margin Collapse Date > ventana mínima (ej. > 30 días)
4. Hard Floor no violado
5. Burn Rate no crítico
En el caso mostrado:
Palancas reales posibles:
A. Subir precio
B. Reducir costos directos
C. Mejorar anticipo
D. Reducir plazo / curva S
E. Negociar condiciones de pago
Sin al menos dos mejoras estructurales → no pasa.
RAM depende fuertemente del precio.
Sea:
𝑅𝑅𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆=𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜−𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜
𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜
Si subes precio 3 –5%:
Pero:
Hay punto óptimo donde:
RAM positivo
EV máximo
WinProb aceptable
Eso es lo que busca el Optimal Bid Engine.
Capital at Risk no depende solo del margen.
Depende de:
Sensibilidad crítica:
Si el Estado de Pago se retrasa 15 días:
𝐶𝐶𝑆𝑆𝑆𝑆𝐸𝐸𝑆𝑆𝑆𝑆𝐻𝐻𝑛𝑛𝑛𝑛𝑃𝑃𝑛𝑛𝑃𝑃=𝐶𝐶𝑆𝑆𝑆𝑆𝐸𝐸𝑆𝑆𝑆𝑆𝐻𝐻𝑃𝑃𝑃𝑃𝑆𝑆𝑃𝑃 +𝐵𝐵𝐵𝐵𝑀𝑀𝑆𝑆_𝐻𝐻𝐸𝐸𝑆𝑆𝑀𝑀𝐸𝐸𝑜𝑜 ×15
Si Burn diario ≈ $985.271
15 días ≈ +$14.7M adicionales
Ese número puede duplicar la exposición.
Capital at Risk es el KPI más peligroso porque:
No se recupera con probabilidad de ganar.
El motor optimiza:
𝐸𝐸𝑉𝑉=𝑊𝑊(𝑤𝑤𝐸𝐸𝑆𝑆)×(𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜−𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜 )
Pero sujeto a restricciones:
Si el precio óptimo cae bajo HardFloor → se etiqueta "Fuera de Mercado".
En la imagen:
Precio óptimo ≈ $13.013.704
Hard Floor ≈ $11.829.030 Hay margen de maniobra.
Pero el problema no es precio óptimo.
Es fragilidad estructural.
Diagnóstico Final Integrado
El proyecto falla no por mercado.
Falla por estructura interna:
Aunque:
El sistema está actuando como debe:
Bloquea rentabilidad ilusoria.
(IA Forense Sellada v1.0)
Este módulo no interpreta.
No opina.
No decide.
Produce inteligencia estructural previa al compromiso de capital.
Responder una pregunta crítica:
¿Dónde me están transfiriendo riesgo sin que sea evidente en el precio?
Opera antes del presupuesto.
Identifica:
Su función es detectar fragilidad antes de que el FinancialModel la absorba .
Nivel de gobernanza:
Pipeline real:
Documento
Es productor de conocimiento, no de sentencia.
Contenedor seguro de:
No permite alteración posterior sin rastro.
Características:
Extrae:
⚠ Trampas Contractuales
Ejemplo visible en imagen:
Multa 0,5% diario.
Análisis estructural:
0.5%×20 𝐻𝐻ıˊ𝑆𝑆𝑆𝑆=10% 𝐻𝐻𝑆𝑆𝐻𝐻 𝐼𝐼𝑜𝑜𝑆𝑆𝑆𝑆𝑀𝑀𝑆𝑆𝑆𝑆𝑜𝑜
Eso puede destruir RAM en semanas.
Este módulo detecta antes de modelar.
Identifica:
🛡🛡 Contramedidas
No decide.
Propone:
Luego el Core modela el impacto.
Flujo estructural:
Bases
Si el riesgo es bloqueante → KPI Riesgos = 1+
No afecta directamente:
Pero afecta indirectamente:
Es generador de shocks estructurales.
1. Automatizar extracción sin filtro determinista.
2. Permitir que IA interprete financieramente.
3. No vincular hallazgos al Risk Map.
4. Ignorar hallazgo crítico por presión comercial.
Este módulo no es decorativo.
Si detecta multa desproporcionada y no se modela, el Dashboard será optimista
artificialmente.
Mercado:
Checklist legal manual.
SEPO:
Motor forense estructurado + integración causal.
Aquí no se detectan “riesgos”.
Se detectan variables que pueden destruir margen.
Este módulo responde:
¿Dónde me están trasladando riesgo antes de que yo lo vea en números?
Es el radar.
El Dashboard es el veredicto.
(Corazón Matemático del Sistema)
Este módulo define la arquitectura financiera del proyecto.
Todo KPI del Dashboard nace aquí.
Si aquí hay error → el sistema completo se contamina.
Definir:
Es el punto donde se fija la estructura económica completa.
Suma de:
Es la base matemática del Hard Floor.
𝑅𝑅𝑅𝑅𝐼𝐼=𝑈𝑈𝑆𝑆𝐸𝐸𝐻𝐻𝐸𝐸𝐻𝐻𝑆𝑆𝐻𝐻
𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝐸𝐸𝑆𝑆𝑆𝑆𝑀𝑀𝑆𝑆𝑆𝑆𝑆𝑆
No es decorativa.
Ese porcentaje luego será erosionado por:
UF / Dólar
Impactan:
Cambio aquí → afecta todos los APUs.
Propagación obligatoria.
Estos no son "inputs Excel".
Son multiplicadores estructurales.
Modificar utilidad %:
Cada capítulo:
No es solo organización.
Es base temporal del Stress Engine.
Aquí se construye el costo real de cada partida.
Estructura:
Materiales
Mano de obra
Maquinaria
EPP
Fletes
Subcontratos
Varios
Cada elemento tiene:
Ejemplo visible: Suministro Epóxicos
Precio unitario final: $5.647.744
Deriva de:
Costo Directo
No es suma manual.
Es fórmula estructural.
𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜𝐻𝐻𝐸𝐸𝑆𝑆𝑆𝑆𝐻𝐻 =𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝑉𝑉𝐸𝐸𝑀𝑀𝑆𝑆𝐼𝐼𝑆𝑆𝑜𝑜 ×(1+𝐿𝐿𝑆𝑆+𝑉𝑉𝐻𝐻 +𝐺𝐺𝐺𝐺+𝑈𝑈𝑆𝑆𝐸𝐸𝐻𝐻𝐸𝐸𝐻𝐻𝑆𝑆𝐻𝐻 +𝐼𝐼𝑆𝑆𝑆𝑆𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆 )
Donde:
LS = Leyes sociales
DH = Desgaste herramientas
Pero cuidado:
GG y Utilidad no son simples porcentajes aditivos.
Se aplican sobre bases definidas por política.
Cambio en:
Impacta:
APU
Este módulo es el origen de la "pala de $2.000".
Leyes Sociales (42%)
Impacta costo laboral real.
No modificar sin coherencia con LCSE.
Desgaste Herramientas (2%)
Impacta costo indirecto real.
GG (11,2%)
Si sube:
Utilidad (20%)
Si sube demasiado:
Si baja demasiado:
Imprevistos (10%)
Buffer contra incertidumbre.
Reducirlo artificialmente mejora precio…
pero destruye resiliencia.
Cada ítem tiene:
Rendimiento (m2, jornada, etc.)
𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝑈𝑈𝑆𝑆𝐸𝐸𝑆𝑆𝑆𝑆𝑀𝑀𝐸𝐸𝑜𝑜 =𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜𝐼𝐼𝑆𝑆𝑆𝑆𝐵𝐵𝑆𝑆𝑜𝑜
𝑅𝑅𝑆𝑆𝑆𝑆𝐻𝐻𝐸𝐸𝑆𝑆𝐸𝐸𝑆𝑆𝑆𝑆𝑆𝑆𝑜𝑜
Si rendimiento es optimista:
Margen se infla artificialmente.
Este es un punto crítico de fraude involuntario.
1. Rendimientos irreales.
2. Duplicar recurso en biblioteca.
3. Modificar GG para “ganar” licitación.
4. Bajar imprevistos artificialmente.
5. No considerar desfase financiero.
Este módulo puede crear rentabilidad ilusoria.
Sotiware tradicional:
APU aislado.
SEPO:
APU → Flujo → Stress → RAM → Decisión.
Aquí no se calcula precio.
Se construye viabilidad estructural.
1titi Conclusión Técnica
Este módulo responde:
¿El número que estoy ofreciendo tiene coherencia económica real?
Si el Dashboard bloquea, casi siempre el origen está aquí.
Este módulo no es administrativo.
Es el control de costos no productivos que pueden destruir el margen sin tocar el APU .
Si no se modela correctamente, el Dashboard será optimista artificialmente.
Separar:
Porque mezclar ambos:
Este módulo responde:
¿Cuánto cuesta mantener la estructura que permite ejecutar la obra?
Ejemplo visible:
Cada ítem incluye:
Este costo no produce avance tisico,
pero sí consume caja.
Muestra:
Ejemplo visible:
Incidencia CD: 10.85%
Total G.G.: $1.008.750
Eso impacta precio final.
Ubicación estructural:
Data Layer → FinancialModel
No es APU.
No se reparte automáticamente.
Se integra explícitamente al modelo económico.
Puede aplicarse como:
El método cambia el Capital at Risk.
Gastos Generales afectan:
Si GG sube 2 –3 puntos:
Es multiplicador silencioso.
GG mensual fijo implica:
𝐵𝐵𝐵𝐵𝑀𝑀𝑆𝑆𝑑𝑑𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 =𝐺𝐺𝐺𝐺 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝐵𝐵𝑆𝑆𝐻𝐻
30
Ese burn:
Si el proyecto se retrasa,
GG sigue corriendo.
APU puede estar bien,
pero GG puede destruir la viabilidad.
Sotiware tradicional:
GG = porcentaje fijo decorativo.
SEPO:
GG = componente modelado con:
Aquí se ve la fragilidad operativa.
1. Subestimar estructura real.
2. Aplicar GG como % sin modelar temporalidad.
3. No incluir staff crítico.
4. No considerar retrasos.
GG mal modelado es la principal fuente de colapso oculto.
Si GG está inflado:
Si GG está subestimado:
Este módulo es equilibrio estructural.
Responde:
¿La estructura que sostiene la obra es financieramente sostenible?
Si el proyecto colapsa rápido, muchas veces el origen está aquí.
(Cronograma + Flujo de Caja + Financiamiento)
Este módulo conecta tiempo con dinero .
Aquí se revela si la obra te financia… o tú la financias.
No es un Gant visual.
Es un motor de exposición de capital.
Responder:
Aquí se calcula el Capital at Risk real.
Cada partida tiene:
Esto alimenta:
Curva S
Si el cronograma es irrealista,
todo el flujo se distorsiona.
Gráfico mostrado:
Modelo diario:
𝑆𝑆𝑆𝑆𝐻𝐻𝐻𝐻𝑜𝑜𝑃𝑃=𝐼𝐼𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃−𝐸𝐸𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆𝑜𝑜𝑆𝑆𝑃𝑃
Capital at Risk:
𝑊𝑊𝑆𝑆𝑆𝑆𝑃𝑃=min (𝑆𝑆𝑆𝑆𝐻𝐻𝐻𝐻𝑜𝑜𝑃𝑃)
En la imagen:
Máxima inversión (peak):
-$8.448.387
Día crítico: 36
Eso es dinero real que debe existir.
Panel izquierdo:
Anticipo (%)
Retención (%)
Pago proveedores (días)
Estado de pago (días)
Estos cuatro parámetros controlan:
Cambiar Estado de Pago de 30 → 45 días
puede duplicar el peak.
Cuando hay déficit:
Se modela crédito puente:
Con tasa estimada (ej: 1,5% mensual)
Costo financiero calculado:
𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜 =𝐶𝐶𝑆𝑆𝑆𝑆𝐸𝐸𝑆𝑆𝑆𝑆𝐻𝐻 ×𝑇𝑇𝑆𝑆𝑆𝑆𝑆𝑆 ×𝑇𝑇𝐸𝐸𝑆𝑆𝑆𝑆𝑆𝑆𝑜𝑜
Ese costo puede:
Este módulo conecta flujo con precio final.
Planificación
Si el peak supera capacidad de la empresa:
Bloquea.
Si el día crítico es temprano:
Riesgo estructural alto.
Ejemplo:
Burn diario ≈ $985.271
Si el proyecto se retrasa 10 días:
𝐼𝐼𝑆𝑆𝑆𝑆𝑆𝑆𝐼𝐼𝑆𝑆𝑜𝑜≈985 .271 ×10=9.852. 710
Eso puede borrar utilidad completa.
Por eso Planificación es crítico.
Sotiware tradicional:
Gant aislado.
SEPO:
Gant → Flujo → Financiamiento → RAM → Decisión.
Aquí se modela supervivencia, no avance.
1. Cronograma optimista.
2. Ignorar dependencia real.
3. No modelar retenciones.
4. No considerar pago real proveedor.
5. No integrar costo financiero al modelo.
Este módulo expone la fragilidad temporal.
Este módulo responde:
¿Puedo sobrevivir hasta cobrar?
Si el Dashboard marca “Colapso en 2 días”,
el origen está aquí.
(Single Source of Truth de Recursos)
Este módulo no calcula precios.
Consolida la verdad del costo directo del proyecto.
Si aquí hay duplicidad o error, el APU hereda distorsión.
Responder:
Es la vista transversal de todos los APUs.
Origen de datos:
APUs
Regla crítica:
Cada recurso debe tener ID único global.
No por partida.
No por capítulo.
Evita:
Agrupa por tipo:
Vista visible:
Items únicos: 34
Costo directo total: $9.299.471
Ese número debe coincidir con:
∑𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝑉𝑉𝐸𝐸𝑀𝑀𝑆𝑆𝐼𝐼𝑆𝑆𝑜𝑜 (𝑅𝑅𝑊𝑊𝑈𝑈 )
Si no coincide → hay fuga estructural.
Para cada recurso:
𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝑇𝑇𝑜𝑜𝑆𝑆𝑆𝑆𝐻𝐻 =𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝐸𝐸𝐻𝐻𝑆𝑆𝐻𝐻𝑇𝑇𝑜𝑜𝑆𝑆𝑆𝑆𝐻𝐻 ×𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜𝑈𝑈𝑆𝑆𝐸𝐸𝑆𝑆𝑆𝑆𝑀𝑀𝐸𝐸𝑜𝑜
CantidadTotal proviene de:
∑(𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝐸𝐸𝐻𝐻𝑆𝑆𝐻𝐻𝑅𝑅𝑊𝑊𝑈𝑈 ×𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝐸𝐸𝐻𝐻𝑆𝑆𝐻𝐻𝑊𝑊𝑆𝑆𝑀𝑀𝑆𝑆𝐸𝐸𝐻𝐻𝑆𝑆 )
Aquí se ve coherencia matemática del modelo.
Insumos impacta:
Este módulo es la base del 80% del riesgo económico.
Inflación materiales +10%:
𝐼𝐼𝑆𝑆𝑆𝑆𝑆𝑆𝐼𝐼𝑆𝑆𝑜𝑜=9.299 .471 ×0.10≈929 .947
Ese monto:
Por eso está conectado al módulo de Riesgos.
1. Recurso duplicado con nombre distinto.
2. Precio actualizado en APU pero no sincronizado.
3. Cambio manual fuera del flujo oficial.
4. No recalcular consolidado tras edición.
Este módulo debe ser derivado, no editable libremente.
Mercado:
Insumos = tabla auxiliar.
SEPO:
Insumos = mapa de concentración económica.
Permite:
CantidadTotal impacta:
Si Insumos está mal consolidado,
Planificación proyecta flujo falso.
Este módulo responde:
¿Dónde está realmente mi dinero invertido?
Es el espejo del costo directo.
Sin coherencia aquí,
el Decision Engine opera sobre arena.
(Optimización post -presupuesto, sin romper el modelo)
Este módulo no crea rentabilidad.
La captura.
Opera después del Presupuesto.
Antes de la ejecución.
Responder:
No es cotizador simple.
Es módulo de optimización controlada.
Flujo correcto:
Insumos (Costo Base)
Si el descuento no propaga al modelo, es maquillaje.
Visible:
Insumos críticos (A): 8
Representan ~80% del costo directo.
Esto define prioridad de negociación.
Optimizar un ítem C no mueve la aguja.
Optimizar un A sí.
Cada fila contiene:
Fórmula estructural:
𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝐶𝐶𝐵𝐵𝑆𝑆𝐼𝐼𝑜𝑜 =𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝐵𝐵𝑆𝑆𝑆𝑆𝑆𝑆 ×(1−𝑉𝑉𝑆𝑆𝑆𝑆𝐼𝐼𝐵𝐵𝑆𝑆𝑆𝑆𝑆𝑆𝑜𝑜 )
𝑅𝑅ℎ𝑜𝑜𝑀𝑀𝑀𝑀𝑜𝑜 =𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝐵𝐵𝑆𝑆𝑆𝑆𝑆𝑆 −𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝐶𝐶𝐵𝐵𝑆𝑆𝐼𝐼𝑜𝑜
Ese ahorro debe:
Si no mejora RAM, no es ahorro estratégico.
Ejemplo:
KIT Pintura Epóxica
Costo base: $2.925.000
Si se negocia -8%:
𝑅𝑅ℎ𝑜𝑜𝑀𝑀𝑀𝑀𝑜𝑜≈234 .000
Ese monto:
Pero solo si el modelo recalcula todo.
1. Aplicar descuento sin recalcular Hard Floor.
2. Permitir edición manual sin trazabilidad.
3. No bloquear descuentos irreales (> mercado).
4. No registrar proveedor y contrato real.
Este módulo debe estar auditado.
Descuento agresivo puede generar:
Optimizar precio no debe aumentar riesgo.
Compras debe integrarse con:
Planificación
Mercado:
Compras = ahorro puntual.
SEPO:
Compras = ajuste estructural del modelo financiero.
Aquí el ahorro se mide por:
ΔRAM
ΔCapital at Risk
ΔHard Floor
ΔEV
No por % aislado.
No es:
“Ahorro proyectado $X”
Es:
Δ𝑅𝑅𝑅𝑅𝑅𝑅 >0yΔ𝐶𝐶𝑆𝑆𝑆𝑆𝐸𝐸𝑆𝑆𝑆𝑆𝐻𝐻𝑅𝑅𝑆𝑆𝑅𝑅𝐸𝐸𝑆𝑆𝑃𝑃 <0
Si no mejora resiliencia, no es mejora real.
Este módulo responde:
¿Puedo mejorar la estructura financiera sin alterar el alcance?
Es optimización táctica dentro de gobernanza matemática.
(Laboratorio Probabilístico + Motor Estratégico de Precio)
Este no es un módulo de “simulación bonita”.
Es el núcleo que determina si el proyecto sobrevive bajo incertidumbre real y presión
competitiva.
Integra:
Todo converge en una sola pregunta:
¿Vale la pena competir y a qué precio?
Escenarios:
Cada uno recalcula:
𝑅𝑅𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆=𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜−𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜𝑅𝑅𝐶𝐶𝐵𝐵𝑆𝑆𝑆𝑆𝑆𝑆𝐻𝐻𝑜𝑜
𝑊𝑊𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜
Impacta:
Si el escenario realista ya es negativo,
el proyecto es estructuralmente frágil.
No se necesita Monte Carlo para saberlo.
Simulación:
1.000 iteraciones
Distribución triangular basada en:
Resultado:
Distribución de utilidad.
Se obtienen:
Si:
𝑊𝑊50 <0
El proyecto tiene más probabilidad de perder que ganar.
Este módulo cuantifica incertidumbre real.
Modelo clásico:
𝐸𝐸𝑅𝑅𝑉𝑉 =∑(𝑊𝑊𝑀𝑀𝑜𝑜𝑊𝑊𝑆𝑆𝑊𝑊𝐸𝐸𝐻𝐻𝐸𝐸𝐻𝐻𝑆𝑆 𝐻𝐻𝑃𝑃×𝑅𝑅𝑆𝑆𝑆𝑆𝐵𝐵𝐻𝐻𝑆𝑆𝑆𝑆𝐻𝐻𝑜𝑜𝑃𝑃)
Ejemplo visible:
Comprar equipo vs arrendar.
Aunque comprar tenga mayor upside,
si la probabilidad no compensa el riesgo,
EMV será menor.
El sistema recomienda la rama con mayor valor esperado ajustado.
Pero:
EMV alto no invalida riesgo de liquidez.
Por eso no decide solo.
Modelo Beta para duración:
𝑉𝑉𝐵𝐵𝑀𝑀𝑆𝑆𝐼𝐼𝐸𝐸𝑜𝑜ˊ𝑆𝑆𝑃𝑃𝑆𝑆𝑒𝑒𝑃𝑃𝑃𝑃𝑃𝑃𝑑𝑑𝑃𝑃 =𝑅𝑅+4𝑅𝑅+𝑊𝑊
6
Desviación estándar:
𝜎𝜎=𝑊𝑊−𝑅𝑅
6
Se calcula probabilidad de cumplir plazo.
Si:
Probabilidad < 50%
La multa contractual se vuelve estructural.
Esto alimenta el módulo de Planificación y Stress.
Busca:
𝐸𝐸𝑉𝑉=𝑊𝑊(𝑆𝑆𝐻𝐻𝐶𝐶𝐵𝐵𝐻𝐻𝐸𝐸𝐼𝐼𝑆𝑆𝐼𝐼𝐸𝐸 𝑜𝑜ˊ𝑆𝑆)×𝑅𝑅𝑆𝑆𝑀𝑀𝑀𝑀𝑆𝑆𝑆𝑆𝑅𝑅𝑜𝑜𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝑀𝑀𝐸𝐸𝑜𝑜
Con:
Se obtiene:
Margen óptimo sugerido.
Pero sujeto a restricciones:
Si el óptimo viola estabilidad → se bloquea.
Compara:
$/m² proyecto vs mercado:
Si el precio está bajo mercado:
↑ probabilidad
pero ↓ margen
Si está sobre mercado:
↑ margen
pero ↓ probabilidad
El equilibrio se resuelve en el optimizador.
Presupuesto
Nunca al revés.
IA no decide.
Motor determinista decide.
1. Ajustar escenarios para justificar decisión previa.
2. No integrar resultados al Hard Floor.
3. Usar EMV sin validar liquidez.
4. Ignorar P80 y quedarse con mejor caso.
5. Optimizar margen ignorando RAM.
Este módulo puede justificar casi cualquier cosa si no hay gobernanza.
Mercado tradicional:
Análisis financiero estático.
SEPO:
Modelo dinámico probabilístico con restricciones de supervivencia.
Aquí no se busca “ser competitivo”.
Se busca:
Competir sin destruir capital.
Este módulo responde:
Sin este módulo,
el precio es intuición.
Con este módulo,
el precio es estrategia matemática.
(Impacto Ambiental Integrado al Modelo Económico)
Este módulo no es marketing verde.
Es cuantificación técnica del impacto ambiental derivado directamente del presupuesto.
Opera sobre datos reales de Insumos.
No sobre estimaciones externas.
Responder:
Integra sostenibilidad con decisión económica.
Para cada recurso:
𝐸𝐸𝑆𝑆𝐸𝐸𝑆𝑆𝐸𝐸𝑜𝑜ˊ𝑆𝑆=𝐶𝐶𝑆𝑆𝑆𝑆𝑆𝑆𝐸𝐸𝐻𝐻𝑆𝑆𝐻𝐻 ×𝐻𝐻𝑆𝑆𝐼𝐼𝑆𝑆𝑜𝑜𝑀𝑀𝐶𝐶𝐶𝐶2
Donde:
Emisión total:
𝐶𝐶𝑅𝑅2𝑇𝑇𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 =∑𝐸𝐸𝑆𝑆𝐸𝐸𝑆𝑆𝐸𝐸𝑜𝑜𝑆𝑆𝑆𝑆𝑆𝑆𝑃𝑃𝑃𝑃𝑃𝑃𝑛𝑛𝑃𝑃𝑆𝑆𝑃𝑃
En la imagen:
Emisiones totales: 695 kg CO₂e.
Distribución:
Esto permite identificar foco de reducción.
Si el 60% viene de un solo insumo,
optimizar ese recurso tiene impacto real.
Intensidad por m²:
𝐶𝐶𝑅𝑅2𝑇𝑇𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃
𝑆𝑆2
Intensidad por $:
𝐶𝐶𝑅𝑅2𝑇𝑇𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃
𝐶𝐶𝑜𝑜𝑆𝑆𝑆𝑆𝑜𝑜
Esto permite comparar proyectos distintos.
No es absoluto.
Es relativo.
Ejemplo visible:
KIT Pintura Epóxica
150 m² × 2.5 kg = 375 kg
Representa más del 50% del total.
Aquí está el punto de optimización.
No en un insumo marginal.
Sostenibilidad se conecta a:
Insumos
No altera automáticamente:
Pero puede hacerlo si:
Alternativa sostenible tiene distinto costo.
Reducir huella puede:
A) Aumentar costo → bajar competitividad
B) Reducir costo → mejorar RAM
C) Aumentar probabilidad de adjudicación (licitaciones ESG)
Este módulo debe integrarse con el Optimizer.
Si empresa desea neutralidad:
𝑅𝑅ˊ𝑀𝑀𝑊𝑊𝑜𝑜𝐻𝐻𝑆𝑆𝑆𝑆 =𝐶𝐶𝑅𝑅2𝑇𝑇𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃
𝐻𝐻𝑆𝑆𝐼𝐼𝑆𝑆𝑜𝑜𝑀𝑀𝑅𝑅𝑊𝑊𝑆𝑆𝑜𝑜𝑀𝑀𝐼𝐼𝐸𝐸 𝑜𝑜ˊ𝑆𝑆
Pero compensar no reemplaza reducción estructural.
1. Factores de emisión no auditados.
2. No actualizar biblioteca.
3. Usar factores promedio inadecuados.
4. No recalcular al cambiar insumos.
5. Desacoplar de Insumos.
Debe ser derivado, no editable manualmente.
Mercado:
Reporte ESG externo.
SEPO:
Huella integrada al presupuesto y conectable al motor de decisión.
Permite:
Optimizar costo + impacto simultáneamente.
Conclusión Técnica
Este módulo responde:
¿Cuál es el costo ambiental real de mi estructura financiera?
Y permite decidir:
¿Compito solo en precio o también en impacto?
(Capa de Salida Certificable del Motor Financiero)
Este módulo no calcula.
Congela.
Convierte el estado matemático del proyecto en un documento contractual.
Si aquí hay manipulación manual, se rompe la gobernanza.
Responder:
Es la interfaz entre motor interno y cliente externo.
Flujo correcto:
ProjectID
Regla crítica:
El documento NO recalcula nada.
Solo renderiza el snapshot activo.
Contiene:
Todos esos valores deben provenir del FinancialModel congelado.
No de inputs editables.
“Folio compuesto”:
PRJ-XXXX / COT -XXXX
El correlativo global debe:
Romper esto rompe trazabilidad contable.
Al presionar:
“Guardar Cotización Oficial”
Debe generarse:
Sin eso, no hay certificación real.
Si el usuario:
El documento histórico no debe alterarse.
Debe quedar congelado.
El nuevo cálculo debe generar nuevo correlativo.
El QR debería:
Sin validación externa, el QR es decorativo.
Presupuesto
Nunca al revés.
Mercado:
Cotización = documento Word.
SEPO:
Cotización = resultado verificable de motor determinista.
No es solo oferta.
Es decisión certificada.
Este módulo responde:
¿El número que entrego al cliente está matemáticamente respaldado?
Es la frontera entre:
Simulación interna
y
Compromiso contractual real.
(Capa de Parametrización y Gobernanza Financiera)
Este módulo no ejecuta cálculos.
Define las reglas bajo las cuales el motor opera.
Centraliza los parámetros estructurales que impactan todo el sistema:
Es la base normativa del proyecto.
Flujo correcto:
Configuración
Si se altera aquí, todo el modelo cambia.
Por eso debe estar controlado.
Estos valores son:
Son variables maestras del motor.
Riesgo crítico:
Si se permiten cambios sin versionado, se rompe trazabilidad histórica.
Debe existir:
Impactan directamente:
Estos campos no son decorativos.
Son identidad contractual.
La generación de llaves sugiere:
Si esto se implementa correctamente, SEPO deja de ser sotiware operativo y pasa a ser
plataforma certificable.
Si no, es solo un botón.
Funcionalidad clave.
Debe incluir:
Sin backup estructural real, el riesgo operacional es alto.
1. Parámetros editables sin control de versiones
2. Firma digital no vinculada al hash del documento
3. Restauración parcial que no incluya motor de cálculo
4. Cambios en UF o dólar sin recalcular coherentemente el modelo
Este módulo es:
Gobernanza estructural.
No es UI administrativa.
Es el núcleo normativo del sistema.
En herramientas tradicionales:
Configuración = formulario.
En SEPO:
Configuración = marco regulatorio del modelo matemático.
Este módulo define:
Bajo qué reglas se calcula todo.
Si está bien diseñado:
El sistema es consistente.
Si no:
Toda la arquitectura pierde coherencia.