Modelo de Gobernanza de Datos

1. Propósito y Alcance

Garantizar que los datos de la Secretaría de Hacienda (SH) sean confiables, seguros, disponibles, comprensibles y valorados como activos estratégicos para la toma de decisiones, el cumplimiento normativo y la prestación de servicios "inteligentes" al ciudadano.

2. Estructura Organizacional de Gobernanza (Modelo Operativo)

Modelo federado de tres niveles (Estratégico, Táctico, Operativo) con autoridad decisoria clara y responsabilidad distribuida por dominios de negocio.

2.2 Definición de Roles y Responsabilidades (Matriz RACI)

3. Pilares del Marco de Gobernanza (Componentes Funcionales)

Seis pilares que cubren el ciclo de vida completo del dato, alineados con las 4 capas de la Arquitectura Técnica.

Pilar 1: Gobernanza de Datos Maestros (MDM Governance) Capa Master Data

Objetivo: Mantener la "Golden Record" íntegra, única y confiable para las 7 entidades maestras.

Pilar 2: Gobernanza de Datos de Referencia (Reference Data Governance) Capa Reference Data

Objetivo: Consistencia semántica universal. Regla de Oro: Ningún sistema transaccional ni analítico puede tener "listas de valores" hardcodeadas. FK obligatoria a RefData Hub vía API.

Pilar 3: Gestión de Calidad de Datos (DQ Management) Capa Transaccional / Analítica

Objetivo: Medir, monitorear y mejorar la "Salud de los Datos" mediante contratos de datos y quality gates automatizados.

Pilar 4: Metadatos, Linaje y Catálogo (Data Catalog & Lineage) Capa Metadatos (Transversal)

Objetivo: Auto-servicio, confianza, trazabilidad, cumplimiento AGN (Res 090/2018).

Pilar 5: Seguridad, Privacidad y Acceso (Data Security & Privacy) Transversal (Ley 1581, MECI, ENI)

Pilar 6: Gestión del Ciclo de Vida y Arquitectura (Data Lifecycle & Architecture)

4. Procesos Transversales Clave

4.1 Proceso de Resolución de Conflictos de Propiedad (Ownership Disputes)

Ejemplo clásico: ¿Quién dueño de "Ciudadano"? Tributario vs Talento Humano vs Catastro.

4.2 Proceso de Alta / Baja / Modificación de Catálogos (RefData)

1. Solicitud: Steward crea Ticket "RefData Change" (Jira): Justificación legal/negocio, Valores, Vigencia, Impacto (Sistemas).
2. Análisis Impacto: DMO ejecuta scripts búsqueda de uso (¿Dónde se usa este código?).
3. Aprobación:
   • Menor (Nuevo valor, sin ruptura): Steward Líder + DMO (Autorización Rápida 24h).
   • Mayor (Cambio estructura, deprecación, vMajor): Data Council.
4. Implementación: DMO aplica en RefData Hub (Versionado Semántico), actualiza APIs, notifica consumidores (Webhook/Email).
5. Validación: Pruebas automatizadas regresión en consumidores clave.

4.3 Proceso de Certificación de "Data Products" (Capa 4 - Consumo)

Antes de publicar un Dashboard, API o Dataset en Portal Abierto:

5. Métricas de Madurez y Desempeño (KPIs de Gobernanza)

6. Roadmap de Implementación de la Gobernanza (Alineado a Fases Arquitectura)

7. Matriz de Cumplimiento Normativo (Traceability Matrix)

8. Presupuesto y Recursos (Estimación Referencial 2024-2026)

Nota: Montos referenciales. Requieren validación en Plan Anual de Adquisiciones y Presupuesto Vigencia Futura.

9. Riesgos Críticos de la Gobernanza y Mitigaciones

10. Próximos Pasos Inmediatos (Action Items - Semanas 1-4)

Anexo: Plantilla Estándar "Data Contract" (Contrato de Datos) - SH Armenia

Formato YAML para definición de expectativas entre Productores (Fuentes) y Consumidores (DW/BI/IA). Versionado en Git junto al código de transformación (dbt/SQL).

# data_contract_fact_recaudo_v1.yaml
dataset: "fact_recaudo_diario"
version: "1.2.0"
owner:
  domain: "Tributario"
  steward: "Juan Perez (Steward Tributario)"
  technical_contact: "DMO Team (datos@armenia.gov.co)"
  
sla:
  freshness: "15_minutos_post_cierre_caja"
  availability: "99.5%"
  latency_p99_query: "2s"
  
schema:
  - name: "fecha_recaudo"
    type: "date"
    description: "Fecha contable del recaudo"
    constraints: { not_null: true, unique: false }
    pii: false
  - name: "id_ciudadano"
    type: "int"
    description: "FK a mdm.ciudadano (Golden Record)"
    constraints: { not_null: true, foreign_key: "mdm.ciudadano.id_ciudadano" }
    pii: false # Es clave sustituta
  - name: "valor_recaudo"
    type: "decimal(18,2)"
    description: "Valor total recaudado en la transacción"
    constraints: { not_null: true, min: 0 }
    pii: false
  - name: "id_metodo_pago"
    type: "int"
    description: "FK a ref.metodo_pago"
    constraints: { not_null: true, foreign_key: "ref.metodo_pago.id_metodo_pago" }
    pii: false
  - name: "recibo_numero"
    type: "string"
    description: "Número único de recibo oficial"
    constraints: { not_null: true, unique: true }
    pii: false

quality_rules: # Great Expectations / Soda Checks
  - rule: "expect_table_row_count_to_be_between"
    params: { min_value: 1, max_value: null } # Al menos 1 registro/día
  - rule: "expect_column_values_to_be_in_set"
    column: "id_metodo_pago"
    params: { value_set: "SELECT id_metodo_pago FROM ref.metodo_pago WHERE activo=true" }
  - rule: "expect_column_sum_to_be_between"
    column: "valor_recaudo"
    params: { min_value: 1000000, max_value: 50000000000 } # Rango razonable diario

lineage:
  upstream_sources:
    - system: "Sistema Recaudo Tesorería (SRT)"
      table: "srt.pagos_caja"
      extraction: "CDC (Debezium) -> Kafka Topic 'srt.pagos'"
  transformation_logic: "dbt model: models/gold/fact_recaudo_diario.sql (Limpieza, Join MDM Ciudadano, Join Ref Metodo_Pago)"

tags: ["recaudo", "tributario", "oficial", "pii_free", "kpi_critical"]