Desarrollo e Implementación de un Nuevo Sistema de Administración de Cartera

1. Resumen ejecutivo

El MBN compra el reemplazo completo de su sistema de cartera (contratos de arriendo, venta y concesión onerosa de bienes fiscales): 8 módulos, 7 integraciones (SISTRED, SIGFE, TGR, BancoEstado, ClaveÚnica, Catastro, DW/Data Lake + FirmaGob), migración ETL de Oracle 10g → PostgreSQL desde el año 2000 (~1,7 GB) con saneamiento de saldos, marcha blanca y entrega de código fuente. Plazo 200 días corridos, presupuesto máximo $60.000.000 IVA incl. (≈$50,4 MM neto).

El dominio (software a medida + integraciones + migración) calza con R9, pero las bases fijan un stack obligatorio (TypeScript/Next.js + FastAPI o NestJS + PostgreSQL) y exigen, como condición de admisibilidad, un Senior con ≥4 años y un Mid con ≥2 años certificados por mandantes en ese stack y en “sistemas similares” (cartera, cobranza, cuenta corriente, recaudación, gestión financiera, etc.). El stack conocido de R9 es Laravel/.NET/Vue. Además, la adjudicación exige mínimo 70 puntos: sin ≥4 proyectos similares facturados, R9 no llega a 70 ni siendo la oferta más barata (ver §7.4). El cierre es el 20-10-2026 15:05 (5 días hábiles) y las consultas vencen mañana 14-10 a las 11:00, lo que impide armar una UTP bien hecha.

2. Ficha y calendario

2.1 Ficha de la licitación

2.2 Fechas y horas relevantes (BA 35)

3. Alcance funcional

Necesidad: el sistema actual (Java 1.6 + .NET, Windows Server 2003/IIS, Oracle 10g) tiene inconsistencias de cálculo, documentación incompleta, mantención evolutiva difícil y limitaciones de cobranza e integraciones. El MBN entrega al adjudicado la especificación funcional, reglas de negocio, historias de usuario y diagnóstico de brechas → el foco es diseño técnico, construcción y puesta en producción (BT 2.1).

Hecho documental: las historias de usuario y reglas de negocio solo se entregan al adjudicado (BT 4). El oferente cotiza sin ver el detalle → riesgo de dimensionamiento.

3.1 Matriz de requerimientos funcionales (BT 3 y 4)

3.2 Integraciones (BT 3.4 y BT 5)

SISTRED · SIGFE · TGR · BancoEstado · ClaveÚnica · Sistema de Catastro · DW/Data Lake institucional · FirmaGob. Todas con auditoría, monitoreo y manejo de errores. Las gestiones con organismos externos las hace el MBN (hecho documental), pero el plazo sigue corriendo para el proveedor.

4. Servicio y requerimientos no funcionales

5. Implementación y entregables

Plazos contados desde la entrada en vigencia del contrato. Informes con Firma Electrónica Avanzada del responsable, a equipo_desarrollo@mbienes.cl. MBN revisa en ≤10 días; proveedor subsana en ≤10 días.

Línea temporal

OC (aprox. 23-11-2026) → Inf.1 23-12 → Inf.2 22-01-2027 → Inf.3 21-02 → Inf.4 23-03 → Inf.5 22-04 → Inf.6 22-05 → fin contrato ~11-06-2027 (fechas estimadas sobre calendario probable).

6. Oferta y documentos

6.1 Documentos para presentar la oferta

6.2 Post adjudicación (3 días hábiles)

Antecedentes legales de persona jurídica (RUT, escrituras, vigencia ≤60 días, poderes), certificado F30 Dirección del Trabajo, nómina de socios, declaraciones juradas art. 4 Ley 19.886 / Ley 20.393 / Ley 21.595, garantía de fiel cumplimiento, inscripción hábil en Registro de Proveedores.

7. Evaluación y precio

7.1 Tabla de evaluación (BA 13.1)

7.2 Experiencia requerida

Empresa (no habilitante, 25%): proyectos similares 01-01-2021 → publicación, declarados en Anexo 3 con factura válida SII que indique el servicio. Lo no declarado no cuenta.

Equipo (habilitante + 30%):

Requisitos simultáneos (título + años + stack + similaridad + certificado por proyecto). Un certificado de empleador propio (R9) no calza con “certificado emitido por el mandante” Interpretación.

7.3 Precio y umbrales de acción

7.4 Simulación de puntaje (umbral 70)

*Precio supone que R9 es la oferta más barata (15 pts). Cualquier competidor más barato baja el total. Sin sello energético el máximo alcanzable es 95.

8. Contrato y pagos

IP: las bases no distinguen componentes preexistentes del proveedor. Si R9 reutiliza librerías o módulos propios, quedarían potencialmente cedidos. Preguntar.

9. Multas y términos

10. Riesgos y brechas

11. Encaje para R9

Oportunidades / diferenciación

• Trabajo remoto: no exige presencia en Santiago.
• Reportería, dashboards y alertas son terreno R9 y tienen requerimientos propios (DW/Data Lake).
• Garantía de 12 meses = 20% del puntaje sin requisitos de experiencia.
• Relación con el sector público central para futuros trámites recaudatorios (BT 3.8 anticipa ampliaciones, hasta +30%).

Partners / subcontrato

Desarrollador senior Next.js/NestJS → profesional externo contratado por R9 → cumple admisibilidad del equipo (debe ser personal propio, no subcontrato) · Especialista ETL Oracle → consultor BD → migración y cuadratura · Pentest → empresa de ciberseguridad → Informe de seguridad. UTP con empresa fintech/ERP → resolvería experiencia del oferente, pero no cabe en 5 días hábiles, y si el socio aporta casi todo lo evaluado, se repite el problema ya visto internamente.

12. Preguntas al mandante (foro, hasta 14-10 11:00)

1. ¿El stack del punto 6.2 es obligatorio o referencial, considerando que 6.1 pide “arquitectura agnóstica”? ¿Se acepta experiencia de equipo en stacks equivalentes (p. ej., Laravel/PHP, .NET, Vue) para el cumplimiento de admisibilidad?
2. ¿Cuántas historias de usuario y reglas de negocio componen la especificación funcional? ¿Pueden publicar un índice o volumetría para dimensionar el esfuerzo?
3. ¿Cuáles son las integraciones obligatorias? BT 3.4 incluye FirmaGob y BT 5 incluye SISTRED, Catastro y DW/Data Lake. ¿Existen APIs disponibles hoy para cada una?
4. Si un organismo externo (SIGFE, TGR, BancoEstado, ClaveÚnica) no entrega acceso a tiempo, ¿se ajustan los plazos de los informes sin aplicar multas?
5. ¿Se acepta como certificado de experiencia del profesional uno emitido por el empleador (empresa proveedora) cuando el mandante final es una institución pública?
6. Propiedad intelectual: ¿se excluyen de la cesión los componentes, librerías o herramientas preexistentes del proveedor?
7. ¿El MBN entrega los ambientes (desarrollo, QA, producción) desde el inicio del contrato? ¿Tecnología de servidores (on-premise/cloud, SO)?
8. Pruebas de seguridad: ¿qué alcance se espera (OWASP, pentest externo, escaneo de vulnerabilidades)?

13. Plan de postulación

13.1 Actividades comerciales

13.2 Control de calidad final

• Revisados todos los documentos (bases 46 págs. + Anexos 1–5)
• Requisitos excluyentes identificados (Anexo 1, oferta técnica, equipo mínimo, tope $60 MM, ≥70 pts)
• Experiencia de oferente separada de equipo
• Perfiles profesionales y títulos identificados
• Certificaciones revisadas (Sello Energético / ISO 50001 evaluables; ninguna habilitante)
• Subcontratación y UTP revisadas
• Presupuesto, duración, multas, garantías, propiedad intelectual revisados
• SLA: no aplica (solo garantía post servicio ofertable)
• Criterios de evaluación (suman 100%) y simulación de puntaje
• Preguntas al comprador listas
• Recomendación emitida

Requisitos excluyentes (🔴)

• 🔴 Anexo N°1 completo, en CLP, ≤ $60.000.000 IVA incl.
• 🔴 Oferta técnica que cubra todas las Bases Técnicas.
• 🔴 Senior ≥4 años en sistemas similares con stack 6.2 + Mid ≥2 años con stack 6.2, con certificados de mandantes y CV.
• 🔴 Títulos del área informática (≥4 semestres).
• 🔴 Puntaje final ≥70.
• 🔴 No ofertar como UTP y en paralelo de forma individual.

Conclusión

Razones del NO-GO: (1) brecha de stack con efecto habilitante; (2) experiencia del oferente en dominio financiero-contable no acreditada → bajo umbral de 70; (3) 5 días hábiles impiden UTP o reclutamiento con certificados; (4) alcance amplio para $50,4 MM neto en 180 días; (5) régimen de multas con término anticipado desde la 2ª multa.