1. Resumen Ejecutivo
Cliente: ARAUCO (Celulosa Arauco y Constitución S.A.), sector forestal-celulosa. Objeto: diseñar, implementar, configurar, integrar, probar y poner en servicio la solución que reporta en línea a la SMA las 46 señales (36 temperatura de venteos + 10 temperatura de quemado de gases NCG, cada una con elemento verificador) exigidas por el DS50/2024, revisando y optimizando la arquitectura actual de integración con PI System e IP21. El alcance es exclusivamente de implementación — la operación continua, monitoreo y soporte quedan en un contrato aparte.
El documento recibido corresponde únicamente a bases técnicas: no incluye bases administrativas, por lo que faltan datos comerciales críticos (modalidad de proceso, fechas, presupuesto, criterios de evaluación, garantías de oferta, multas y reglas de subcontratación/UTP).
Alineación con capacidades R9
Media-Alta
Complejidad estimada
Alta
Stack técnico exigido
API REST · JSON · JWT · PI System/IP21 · PLC/RTU/DCS
Nivel de confianza del análisis
Media (faltan bases administrativas)
🟡 GO CONDICIONADO
Fuerte encaje de dominio (ambiental/SMA + desarrollo de software e integraciones vía API), condicionado a validar experiencia comprobable en historiadores industriales (PI System / IP21) y a obtener la información comercial faltante antes de comprometer una oferta.
Principal fortaleza: El objeto del servicio (reporte ambiental en línea a la SMA, gestión de datos, dashboards, APIs REST) coincide directamente con la experiencia de R9 en Airviro/AQMS, ANZIZA y desarrollo de software (Laravel/.NET, APIs REST, integraciones industriales OPC UA/Modbus/DNP3/MQTT).
Principal limitante: Las bases exigen acreditar experiencia comprobable en integración con historiadores industriales PI System (AVEVA/OSIsoft) e IP21 (AspenTech) — tecnologías específicas no confirmadas en el track record documentado de R9.
2. Ficha y Calendario
2.1 Ficha de la licitación / requerimiento
| Campo | Información |
|---|---|
| Mandante | ARAUCO (Celulosa Arauco y Constitución S.A.) |
| Sector | Forestal / Celulosa — cumplimiento ambiental (SMA) |
| Proyecto | Conexión en línea de instrumentos No-CEMS con la SMA — DS50/2024 |
| Documento base | "Bases técnicas licitación DS50_4" — elaborado por Mirta Gómez, aprobado por Marianne Hermanns (sin fechas registradas en el documento) |
| ID de proceso | No indicado — el documento no referencia ID de Mercado Público ni portal; por su formato parece un proceso de contratación privada/directa de ARAUCO |
| Modalidad de contratación | No indicada — se requiere confirmar con el mandante |
| Ubicación / plantas | Planta Arauco Línea 2 y Línea 3, Planta Constitución, Planta Nueva Aldea, Planta Valdivia |
| Alcance territorial | Regiones del Biobío y de Los Ríos, Chile |
| Presupuesto referencial/máximo | No indicado |
| Duración del contrato | No indicada explícitamente (solo se define garantía post-implementación de 180 días corridos desde recepción provisoria) |
2.2 Fechas y horas relevantes
🔴 El documento no contiene fecha de publicación, fecha límite de consultas, fecha de respuestas, fecha de cierre de ofertas ni fecha estimada de adjudicación. No es posible construir un calendario de postulación sin las bases administrativas o confirmación directa del mandante.
3. Alcance Funcional
Matriz de requerimientos funcionales por dominio. Prioridad "DEBE" salvo indicación distinta — todo lo listado en las bases técnicas se redacta en forma imperativa ("deberá").
| Dominio | Requerimiento | Evidencia esperada |
|---|---|---|
| Arquitectura | REQ-F001 Conexión a dispositivos concentradores provistos por ARAUCO; entrega de diagramas de red, matriz de comunicaciones, integración PI/IP21, buffer local, reenvío automático, trazabilidad, sincronización horaria oficial (GMT-4), resolución de 1 min | Diagramas de arquitectura, matriz de comunicaciones, informe de evaluación de arquitectura actual |
| Arquitectura | REQ-F002 Registro de la empresa proveedora en el formulario electrónico de la SMA | Constancia de registro SMA |
| Arquitectura | REQ-F003 Acceso de usuarios vía SSO con credenciales ARAUCO (integración EntraID) | Configuración SSO validada |
| Arquitectura | REQ-F004 Arquitectura propuesta debe ser aprobada previamente por TI y Ciberseguridad de ARAUCO | Acta/aprobación formal de ARAUCO |
| Datos | REQ-F005 Captura de datos crudos desde equipo adquisidor (PLC/RTU/DCS) sin procesamiento, con marca de tiempo GMT-4 y frecuencia continua 24h a resolución de 1 minuto | Especificación técnica de captura + pruebas |
| Datos | REQ-F006 Etiquetado de datos configurable | Módulo de etiquetado operativo |
| API REST / Registro | REQ-F007 Modelo jerárquico SMA (Unidad Fiscalizable → Procesos → Dispositivos → Parámetros) y estructura JSON según Anexo RE254/2020 (nombre, valor, unidad, estampaTiempo ISO8601, estado) | Payloads JSON validados contra diccionario oficial SMA |
| API REST / Registro | REQ-F008 Preparación de información técnica para registro de metadatos ante SMA (registro formal es responsabilidad de ARAUCO) | Ficha de metadatos por dispositivo/parámetro |
| Historizador | REQ-F009 Servicio API REST de consultas históricas: 18 meses mínimo vía servicio, 3 años totales en servidor de ARAUCO | Endpoint operativo + documentación de respaldo/recuperación |
| Historizador | REQ-F010 Autenticación inversa: endpoint propio que recibe credenciales SMA (JSON) y retorna JWT Bearer válido 24h sin refresco | Endpoint de autenticación probado |
| Historizador | REQ-F011 Endpoint GET de consulta por dispositivo/fecha, retorna JSON según estructura 4.3 | Endpoint documentado y probado |
| Historizador | REQ-F012 Almacenamiento temporal ante pérdida de enlace + envío automático al restablecer comunicación | Pruebas de contingencia |
| Seguridad | REQ-F013 Resguardos contra hackeo, DoS, cortes eléctricos, manipulación maliciosa; secretos/credenciales nunca embebidos en código o configs sin protección | Informe de arquitectura de seguridad + gestión de secretos |
| QA/QC | REQ-F014 Validación de datos PI/IP21, contraste de cantidad enviada vs. confirmada por SMA, interfaz de visualización en tiempo real, reglas de validación documentadas y parametrizables sin recompilar | Módulo de QC operativo + documentación de reglas |
| Reportes | REQ-F015 Reporte mensual formato DS50/2024, reportes de "fuera de control" y de fallas de conexión, exportables en CSV y Excel, API de consumo para ARAUCO | Módulo de reportes + API documentada |
| Diagnóstico | REQ-F016 Capacidades de diagnóstico en línea para validar integraciones, historización y servicios API en pruebas y puesta en marcha | Panel de diagnóstico |
| Cálculos | REQ-F017 Módulo de cálculos configurable (ej. tiempo acumulado con quemado <650°C) con trazabilidad de fórmula/entrada/resultado/fecha, extensible sin rediseño mayor | Módulo de cálculos + trazabilidad |
| Alarmas | REQ-F018 Alarmas por variación de temperatura, quemado bajo 650°C, fallas de instrumento, pérdida de señal/datos, falta de confirmación SMA; umbrales documentados y configurables | Motor de alarmas configurado |
4. Servicio y No Funcionales
| Área | Exigencia | Observación analítica |
|---|---|---|
| Disponibilidad de datos | Frecuencia continua 24/7, resolución 1 minuto; históricos 18 meses (servicio) / 3 años (servidor Arauco) | Requiere diseño de historización robusto; volumetría de 46 señales a 1 min es manejable, pero debe validarse capacidad del servidor Arauco |
| Sincronización horaria | GMT-4 permanente (hora oficial de Chile continental de invierno), incluso en horario de verano | Detalle técnico fino — implica no seguir el cambio de hora de verano; debe quedar explícito en el diseño para evitar desfases |
| Seguridad | Anti-hackeo, anti-DoS, gestión segura de secretos (vault/servicios ARAUCO), sin secretos embebidos en código | Requiere definir junto a ARAUCO el mecanismo de secret management corporativo a utilizar |
| Autenticación | SSO/EntraID para usuarios; JWT Bearer 24h sin refresh para SMA (autenticación inversa) | Dos esquemas de auth distintos y paralelos — usuarios internos vs. maquina-a-máquina SMA |
| Auditabilidad | La SMA puede auditar técnicamente la conexión y los datos reportados | El diseño debe soportar trazabilidad íntegra de extremo a extremo (dato crudo → cálculo → envío → confirmación) |
| Configurabilidad | Reglas de validación, cálculos y alarmas deben ser parametrizables sin recompilar | Implica motor de reglas/configuración administrable — no hardcodear lógica de negocio |
| Continuidad ante fallas | Buffer local, reenvío automático, reconstrucción de históricos ante pérdida/corrupción | ARAUCO reporta a la SMA dentro de 12 horas — la solución debe garantizar recuperación rápida para no comprometer ese plazo (dependencia crítica, aunque el reporte final es responsabilidad de ARAUCO) |
| Escalabilidad | Componentes reutilizables para incorporar nuevas variables/cálculos sin rediseño mayor; el número de señales (46) podría ajustarse | Diseño debe evitar acoplamientos rígidos por señal |
ℹ️ No se especifican SLA de soporte, mesa de ayuda ni horarios de atención — coherente con que la operación y soporte continuo quedan expresamente fuera de este alcance (contrato separado).
5. Implementación y Entregables
5.1 Hitos de entrega exigidos
| N° | Entregable | Responsable | Condición de aceptación |
|---|---|---|---|
| 1 | Registro completo del escenario de monitoreo en el Catastro electrónico SMA, con caracterización de dispositivos/parámetros | Proveedor (info) / ARAUCO (registro formal) | Catastro completo y validado |
| 2 | Arquitectura de la solución: diagramas de comunicaciones y matriz de señales | Proveedor | Documentación aprobada por TI/Ciberseguridad ARAUCO |
| 3 | Configuración completa de la solución, scripts, desarrollos y manual técnico | Proveedor | Manual técnico entregado |
| 4 | Endpoint de envío de datos íntegro y validado (pruebas en ambiente no oficial → producción) | Proveedor | Pruebas exitosas + paso a producción |
| 5 | Servicio de históricos operativo: endpoint de autenticación inversa + endpoint GET, probados con credenciales SMA | Proveedor | Pruebas con credenciales reales SMA |
| 6 | Capacitación al equipo interno + manuales de administrador | Proveedor | Capacitación realizada y documentada |
| 7 | Procedimiento de contingencia (interrupciones, almacenamiento temporal, recuperación automática) | Proveedor | Procedimiento documentado y probado |
| 8 | Plan de gestión de cambios (personas, normativa, software/hardware) | Proveedor | Plan entregado |
| 9 | Matriz detallada de integración (señal origen, fuente PI/IP21, tag, variable SMA, unidad, frecuencia, verificador) | Proveedor | Matriz completa y validada |
| 10 | Documentación técnica As-Built | Proveedor | Entrega formal previa a recepción conforme |
5.2 Criterios de aceptación (recepción conforme)
- Todas las variables definidas historizándose correctamente
- SMA valida recepción exitosa de datos
- Consulta de datos históricos operando correctamente
- Período de observación acordado completado
- Módulos de control de calidad y reportes operando correctamente
- Documentación técnica As-Built entregada
5.3 Garantía post-implementación
Mínimo 180 días corridos desde recepción provisoria — corrección sin costo de defectos de configuración, parametrización, desarrollo o integración atribuibles al proyecto. No incluye operación/monitoreo/soporte continuo (contrato aparte).
6. Oferta y Documentos
🔴 Las bases técnicas recibidas no incluyen un listado de documentos requeridos para la presentación de la oferta (oferta técnica, económica, declaraciones juradas, anexos, respaldos de experiencia, garantías de seriedad de la oferta, etc.). Esta información debe solicitarse a ARAUCO o corresponde a un documento de bases administrativas separado que no fue proporcionado.
Pendiente de completar cuando se reciban las bases administrativas.
7. Evaluación y Precio
7.1 Tabla de evaluación
🔴 No se incluyen criterios de evaluación ni ponderaciones (técnico/económico/experiencia). No es posible construir la tabla de evaluación con la información disponible.
7.2 Experiencia requerida
El documento define experiencia del equipo profesional (perfil), pero no distingue explícitamente si además se exige experiencia acreditable de la empresa oferente como requisito habilitante o evaluable:
| Ámbito | Experiencia exigida | Tipo |
|---|---|---|
| Equipo — perfil profesional | Profesionales de Informática, Electrónica, Telemática o afín (recomendación de RE252/2020 N°1 y RE254/2020 N°1) | Formación — recomendado, no explícitamente excluyente |
| Equipo — experiencia | Integración de APIs REST (JWT/Bearer) | Experiencia comprobable — DEBE |
| Equipo — experiencia | Manejo de JSON y estructuras con estampas de tiempo (ISO8601) | Experiencia comprobable — DEBE |
| Equipo — experiencia | Conectividad industrial: PLC, RTU, DCS | Experiencia comprobable — DEBE |
| Equipo — experiencia | Ciberseguridad de sistemas industriales y de comunicaciones (firewalls, cifrado, prevención de accesos no autorizados) | Experiencia comprobable — DEBE |
| Equipo — experiencia | Integración con historiadores industriales: PI System, IP21 o tecnologías equivalentes | Experiencia comprobable — DEBE |
🟡 El texto usa "deberá acreditar experiencia comprobable" pero, al tratarse solo de bases técnicas, no queda claro si este requisito opera como criterio de admisibilidad excluyente o como criterio evaluable — debe confirmarse contra bases administrativas o directamente con ARAUCO.
7.3 Precio y umbrales de acción
🔴 No se indica presupuesto referencial ni máximo, estructura de precios, moneda ni forma de pago.
8. Contrato y Pagos
🔴 No hay información sobre duración total del contrato, hitos de facturación, condiciones de pago, reajustes ni moneda. Pendiente de bases administrativas.
9. Multas y Términos
🔴 No se definen causales de multa, montos, porcentajes, límites máximos ni procedimiento de aplicación. Tampoco se menciona garantía de seriedad de la oferta ni garantía de fiel cumplimiento del contrato (solo se define la garantía técnica post-implementación de 180 días, ver sección 5.3).
10. Riesgos y Brechas
| Riesgo | Nivel | Impacto | Mitigación |
|---|---|---|---|
| Experiencia comprobable en PI System (AVEVA/OSIsoft) e IP21 (AspenTech) no confirmada en el track record de R9 | 🔴 Alto | Es un requisito "DEBE" explícito del perfil profesional; sin evidencia, compromete la credibilidad técnica de la oferta | Levantamiento interno de proyectos previos con historiadores industriales; si no existen, evaluar partner especializado en PI/IP21 o presentar equivalencia con integraciones industriales ya realizadas por R9 (OPC UA, Modbus, DNP3, MQTT) |
| Ausencia de bases administrativas (plazos, presupuesto, criterios de evaluación, documentos de oferta) | 🔴 Alto | Impide una evaluación comercial completa y una planificación de postulación con plazos ciertos | Solicitar formalmente a ARAUCO las bases administrativas o aclarar la modalidad exacta del proceso |
| Reglas de subcontratación/UTP no definidas | 🔴 Alto | Si la brecha en PI/IP21 requiere partner, no se sabe si está permitido subcontratar ni bajo qué condiciones | Consultar expresamente si se permite subcontratación o conformación de UTP para cubrir este componente |
| Acreditación de ciberseguridad industrial (firewalls, cifrado, prevención de accesos) exigida al equipo | 🟠 Medio | Requiere evidencia formal de experiencia previa del equipo asignado | Preparar CVs/evidencias del equipo con foco en ciberseguridad OT/industrial |
| Aprobación de arquitectura condicionada a TI y Ciberseguridad de ARAUCO | 🟠 Medio | Genera dependencia externa que puede extender los plazos de implementación | Incluir en cronograma un hito temprano de revisión conjunta con ARAUCO TI/Ciberseguridad |
| Registro de metadatos y catastro ante la SMA — responsabilidad compartida proveedor/ARAUCO poco delimitada en el detalle operativo | 🟠 Medio | Riesgo de ambigüedad sobre quién ejecuta cada paso del trámite ante la autoridad | Definir matriz RACI conjunta con ARAUCO para el proceso de registro SMA |
| Ventana de 12 horas de ARAUCO para reportar a la SMA en caso de falla | 🟢 Bajo (para R9) | La obligación regulatoria recae en ARAUCO, pero la solución debe soportar recuperación rápida | Diseñar mecanismos de contingencia y alertamiento temprano de fallas de conexión |
| Posible variación del número de señales (46 podría ajustarse) | 🟢 Bajo | Cambios de alcance menores durante ejecución | Diseño modular/parametrizable ya exigido por las bases mitiga este riesgo |
11. Encaje para R9
| Capacidad requerida | Alineación preliminar | Validación necesaria |
|---|---|---|
| Desarrollo de software / APIs REST (Laravel, .NET) | 🟢 Alta | Ninguna — core de R9 |
| Manejo de JSON, JWT/Bearer, ISO8601 | 🟢 Alta | Ninguna — práctica estándar de R9 |
| Experiencia ambiental / reporte a organismos regulatorios (SMA) | 🟢 Alta | Destacar casos Airviro/AQMS y ANZIZA en la propuesta |
| Dashboards, reportes, módulos de alarmas y cálculos configurables | 🟢 Alta | Ninguna — alineado con productos propios de R9 |
| SSO / integración EntraID | 🟢 Alta | Confirmar experiencia puntual con EntraID (vs. otros IdP) |
| Conectividad industrial PLC/RTU/DCS | 🟡 Media | R9 declara experiencia en OPC UA, Modbus, DNP3, MQTT — validar si cubre específicamente PLC/RTU/DCS de esta arquitectura |
| Ciberseguridad de sistemas industriales | 🟡 Media | Preparar evidencia formal de prácticas y proyectos de ciberseguridad OT |
| Integración con historiadores PI System / IP21 | 🔴 Baja | No confirmado en el perfil documentado de R9 — validar internamente o evaluar partner especializado |
💡 Oportunidad de valor agregado: R9 podría posicionar su experiencia en ANZIZA y Airviro/AQMS como diferenciador frente a integradores puramente de TI sin trayectoria ambiental, destacando el entendimiento del ecosistema regulatorio SMA (DS50, RE252, RE254) más allá del componente técnico.
12. Preguntas al Mandante
- ¿Este proceso corresponde a una licitación competitiva formal, a un trato directo o a una solicitud de propuesta (RFP) privada de ARAUCO?
- ¿Cuáles son las fechas de publicación, consultas, respuestas, cierre de ofertas y adjudicación estimada?
- ¿Existe un presupuesto referencial o máximo definido para este servicio?
- ¿Cuáles son los criterios de evaluación de la oferta y sus ponderaciones (técnico/económico/experiencia)?
- ¿Se permite subcontratación o conformación de UTP/consorcio, particularmente para cubrir la experiencia específica en PI System/IP21?
- ¿Qué documentos deben presentarse junto con la oferta técnica y económica (respaldos de experiencia, certificaciones, declaraciones juradas, garantías)?
- ¿Existen garantías de seriedad de la oferta y de fiel cumplimiento del contrato, y multas asociadas a incumplimientos durante la ejecución?
- ¿Cuál es la duración total del contrato y la estructura de pagos/hitos de facturación?
- La experiencia exigida en integración con PI System/IP21, ¿es un requisito de admisibilidad excluyente o un criterio evaluable con puntaje?
- ¿La aprobación de arquitectura por TI/Ciberseguridad de ARAUCO ocurre antes de adjudicar o durante la etapa de ejecución del contrato?
13. Plan de Postulación
13.1 Tabla de actividades comerciales
| Fecha objetivo | Actividad | Resultado esperado |
|---|---|---|
| Inmediata | Confirmar con el contacto en ARAUCO la modalidad exacta del proceso y solicitar bases administrativas | Claridad sobre plazos, presupuesto y criterios de evaluación |
| Inmediata | Levantamiento interno: ¿tiene R9 proyectos previos con PI System, AspenTech IP21 o historiadores industriales equivalentes? | Definir si se requiere partner especializado |
| Corto plazo | Si aplica, identificar y contactar posible partner/especialista en integración PI System o AspenTech IP21 | Validar disponibilidad y condiciones de colaboración |
| Corto plazo | Preparar evidencia de experiencia del equipo en APIs REST, JWT, JSON/ISO8601 e integraciones industriales (OPC UA/Modbus/DNP3/MQTT) | Carpeta de respaldos lista para anexar a la oferta |
| Antes de ofertar | Confirmar reglas de subcontratación/UTP con ARAUCO | Definir estructura de oferta (R9 solo vs. UTP/partner) |
| Antes de ofertar | Reunión interna Go/No-Go final con Bruno una vez recibidas las bases administrativas | Decisión definitiva de participación |
13.2 Control de calidad final
- Revisado el documento de bases técnicas disponible (único documento recibido)
- Identificados requisitos de experiencia del equipo (DEBE) — PI System/IP21 como brecha principal
- Separada experiencia del equipo de experiencia de la empresa (esta última no está definida en el documento)
- Revisada subcontratación/UTP — no mencionada en el documento, marcada como pregunta pendiente
- Revisado presupuesto, duración, multas y garantías de oferta — no disponibles, marcados como brecha de información
- Revisada garantía técnica post-implementación (180 días corridos) — sí definida
- Revisados criterios de evaluación — no disponibles en este documento
- Identificados documentos obligatorios de la oferta — no disponibles en este documento
- Identificados riesgos y brechas — completado (ver sección 10)
- Identificadas preguntas al comprador — completado (ver sección 12)
- Emitida recomendación GO / GO Condicionado / NO-GO — 🟡 GO CONDICIONADO
ℹ️ Este análisis se basa exclusivamente en el documento "Bases técnicas licitación DS50_4". No se inventó información comercial no presente en el documento; todas las secciones marcadas como faltantes deben completarse con las bases administrativas o mediante consulta directa a ARAUCO.