1.1 Proyecto Armenia

Proyecto Armenia es una iniciativa de la Alcaldía de Armenia y tiene como objetivo guiar la elaboración de los planes de desarrollo de la ciudad en el mediano y largo plazo y dar sustento tanto a la toma de decisiones por parte de la Alcaldía así como a la definición de políticas públicas del Municipio. Adicionalmente la información de Proyecto Armenia es útil al sector privado y organizaciones no gubernamentales para soportar toma de decisiones.

La presente información se divide en las siguientes secciones:

• 1. Estructura de la plataforma
• 2. Gobernanza de datos
  • 2.1 Datos Maestros (Master Data),
  • 2.2 Datos de Referencia (Reference Data),
  • 2.3 Datos Transaccionales (Transactional Data) y
  • 2.4 Metadata,
• 3. Modelo Entidad-Relación

1. Estructura de la Plataforma

Para el cumplimiento del objetivo general, se implementan bases de datos y tableros de control con la información clave de la ciudad. Con los datos de la ciudad se procede mediante analítica de datos, modelos econométricos y simulación, a la generación de notas de análisis en temas de coyuntura sobre variables relevantes de la ciudad, como precios, desempleo, crecimiento económico, desempeño fiscal, recaudo tributario, etc. Por otra parte, se realizan consultas directas de la ciudad desde las comunas y por medio de encuestas se determina la percepción de los ciudadanos sobre los problemas reales que enfrentan.

Tanto del procesamiento de datos, como de las notas de análisis y de las encuestas, se realiza un trabajo de consolidación y articulación para identificar problemas. Esta etapa permite realizar diagnósticos a profundidad y con modelos más sofisticados, proponer soluciones.

De esta manera, Proyecto Armenia tiene seis secciones: Contexto, Observatorios, Datos de Armenia, Desde la Comuna, Armenia y el Quindío y Diagnóstico y Posibles Soluciones.

La primera corresponde al contexto que explica el proyecto y da inicio presenta las perspectivas económicas de la ciudad. La segunda sección corresponde a los observatorios que maneja la Secretaría de Hacienda (Fiscal, Tributario, Económico e Inmobiliario), los cuales consignan notas y análisis de coyuntura que serán insumos para la identificación posterior de problemas. La tercera sección contiene información de la ciudad a través de bases de datos trimestrales y tableros de control interactivos que apoyan a los Observatorios, estudios y diagnósticos. La cuarta sección explora de manera directa los problemas de la ciudad, a través de encuestas y estudios sobre temáticas de sus habitantes. La quinta sección explora, de acuerdo con el perfil económico de la ciudad, cómo este se puede articular con los demás municipios del departamento, dado que la ciudad de Armenia no está aislada de su territorio. Finalmente la sexta sección contiene la propuestas de diagnóstico y posibles soluciones a los problemas de la ciudad identificados.

Los diagnósticos se hace sobre la base de un conjunto de dimensiones previamente definidas y que son estratégicas para el cumplimiento de fondo de la administración pública: la reducción de la pobreza monetaria y la pobreza multidimensional de los hogares y habitantes de la ciudad.. En la sección Datos de Armenia puede consultarse su detalle.

Sobre estas dimensiones estratégicas para la ciudad gravita tanto el trabajo de los Observatorios como la exploración de los problemas de la ciudad a través de la sección Desde la Comuna. Adicionalmente, se analiza la interacción de Armenia con otros municipios del departamento del Quindío en la sección Armenia y el Quindío, donde se analizan problemas y soluciones comunes al territorio. Por último, todo el trabajo de Proyecto Armenia se decanta en el árbol de problemas y soluciones de cada dimensión, cuyo contenido se presenta en la sección Diagnóstico y Posibles Soluciones.

De las dimensiones, se deriva los requerimientos para los Observatorios de la Secretaría de Hacienda:

2. Gobernanza de datos

La de “Estructura de Datos” para la Alcaldía Municipal de Armenia, Quindío, será dividida en cuatro capas:

• 2.1 Datos Maestros (Master Data),
• 2.2 Datos de Referencia (Reference Data),
• 2.3 Datos transaccionales (Transactional Data)
• 2.4 Metadata

A partir de la estructura de datos de cada una de las etapas se derivará el modelo conceptual de Entidad–Relación y algunos lineamientos de implementación.

2.1      Datos Maestros (Master Data)

Establece la “única fuente de la verdad” para las entidades centrales con las que opera la Alcaldía. Garantiza que los datos críticos (ciudadanos, predios, empresas, proveedores, empleados, programas, proyectos) estén limpios, consolidados y normalizados.

La estructura de datos propuesta para la Alcaldía de Armenia se condensa en el siguiente diagrama:

Para la estructura de datos propuesta, se tiene la siguiente descripción de las entidades:

Entidad	Clave PK	Atributos clave	Relación principal
Ciudadano	id_ciudadano	nombre, tipo_documento, número_documento, fecha_nacimiento, dirección, contacto	→ Predio, → Trámite, → Pago_Impuesto
Predio	id_predio	código_catastral, ubicación, área_m2, uso_suelo, id_ciudadano	← Ciudadano → Impuesto
Empleado	id_empleado	nombre, cargo, dependencia, fecha_ingreso, email, teléfono	→ Contrato
Proveedor	id_proveedor	razón_social, NIT, dirección, teléfono, categoría_suministro	← Contrato
Empresa	id_empresa	nombre, NIT, tipo_empresa (p.ej. comercial, industrial), dirección, teléfono, representante_legal	→ Proyecto, → Programa
Programa	id_programa	nombre, descripción, objetivo, fecha_inicio, fecha_fin, dependencia_responsable	← Empresa, → Proyecto
Proyecto	id_proyecto	nombre, descripción, objeto, presupuesto, fecha_inicio, fecha_fin, estado, id_programa, id_empresa	← Programa, ← Empresa

Para cada entidad se tienen las siguientes buenas prácticas:

Ciudadano

Es el eje central de la Alcaldía.

  Unicidad y validación:

• Validar tipo y número de documento contra la Registraduría.
• Evitar duplicados con reglas de Match & Merge (por ejemplo, comparar nombre y dirección).

  Seguridad y privacidad:

• Encriptar campos sensibles (número de documento, dirección).
• Controlar acceso a datos personales vía roles (p.ej. sólo Gestión Humana o Secretaría General).

  Auditoría y versionamiento:

• Mantener campos created_by, created_at, modified_by, modified_at.
• Registrar estado de vigencia (activo/inactivo) y fechas de cambio.

Predio

Corresponde a las porciones de terreno de propiedad privada o pública apropiadamente delimitada e identificada.

  Integridad espacial:

• Usar un sistema geoespacial (p.ej. PostGIS) para validar coordenadas y límites.

  Código catastral único:

• Validar unicidad del código catastral contra la base del IGAC.

  Relación con ciudadano:

• Forzar FK a ciudadano vigente y activo.

  Metadatos de uso de suelo:

• Registrar clasificación oficial (residencial, comercial, mixto) y fuente de la clasificación.

Empleado

Corresponde al funcionario público, de planta o de contrato, que labora para al Alcaldía.

  Control de claves:

• Asignar un identificador interno distinto del documento personal.

  Histórico de cargos y dependencias:

• Versionar cargo (cargo_actual vs. cargos_previos) y dependencia.

  Datos de contacto confiables:

• Validar correo y teléfono corporativo (dominio alcaldía.gov.co).

  Seguridad de acceso:

• Integrar con Active Directory o IAM para gestionar permisos según rol.

Proveedor

Son los agentes que proveen bienes y servicios a la Alcaldía.

  Validación de NIT:

• Comprobar vigencia y estado ante la DIAN (activo, inhabilitado).

  Clasificación de suministros:

• Usar catálogos estandarizados (CIIU 4.0) para tipo de bien o servicio.

  Score de desempeño:

• Mantener indicadores de cumplimiento de contratos (entregas a tiempo, calidad).

  Auditoría de relaciones:

• Registrar histórico de contratos y solicitudes de cotización.

Empresa

Agente económico natural o jurídico que genera ingresos en el territorio administrado por la Alcaldía.

  Unicidad y correspondencia:

• Evitar que una misma empresa exista como Proveedor y como Empresa sin relación; mapear NIT y RUT.

  Clasificación sectorial:

• Definir sector económico (comercial, industrial, ONG) con códigos estandarizados.

  Representante legal:

• Versionar cambios de representante y sus periodos de vigencia.

  Cumplimiento normativo:

• Registrar certificaciones o registros especiales (p.ej. Cámara de Comercio, RUT actualizado).

Programa

Corresponde a la dimensión que pretende desarrollar el plan de gobierno que salió elegido.

  Definición de alcance y KPIs:

• Documentar objetivos SMART y métricas de éxito en el diccionario de datos.

  Cronograma y versiones:

• Versionar versiones de alcance y presupuesto cuando haya ajustes.

  Dependencia responsable:

• Forzar FK a la dependencia (Secretaría, Unidad) que administra el programa.

  Riesgos y alertas:

• Asociar un plan de riesgos y registrar alertas de desviación (plazos, costos)

Proyecto

Corresponde a la programación de las actividades que permite dar alcance a lo propuesto por el programa.

  Fases y hitos:

• Modelar fases (Iniciación, Planeación, Ejecución, Cierre) con fechas de inicio y fin.

  Presupuesto y ejecuciones:

• Registrar presupuesto original vs. ejecuciones reales (forecast vs. actual).

  Estado y gobernanza:

• Definir estados estandarizados (planeado, en curso, en riesgo, cerrado).

  Responsables:

• Asociar usuarios internos (líder de proyecto, comité de seguimiento) y roles de aprobación.

2.2 Datos de Referencia (Reference Data)

Los datos de referencia se desarrollan para mantener catálogos, códigos y parámetros estandarizados que aseguren consistencia semántica y operacional en todos los sistemas de la Alcaldía.

Catálogo / Código	Descripción	Ejemplo de Tabla	Atributos clave
Ubicación Geográfica	Territorialización oficial	Departamento, Municipio, Barrio	id_ubicación, nombre, nivel, código_DANE
Tipos de Trámite	Clasificación de procesos ciudadanos	Tipo_Tramite	id_tipo_tramite, nombre, descripción, vigencia
Categorías Presupuestales	Clases y rubros de gasto según la ley	Clase_Gasto, Rubro_Presupuestal	id_clase, id_rubro, nombre, fuente_normativa
Métodos de Pago	Formas autorizadas para recaudos	Metodo_Pago	id_metodo_pago, nombre, detalle, activo
Dependencias Internas	Organismos y secretarías de la Alcaldía	Dependencia	id_dependencia, nombre, nivel (Secretaría, Unidad)
Códigos de Actividad Económica	Clasificación Económica (CIIU 4.0)	Codigo_CIIU	id_ciiu, código, descripción, nivel
Estados de Proyecto/Programa	Fases y estatus homogéneos para seguimiento	Estado_Entidad	id_estado, dominio (Proyecto/Programa), nombre
Categorías de Servicio	Tipos de servicios ofrecidos (recolección, infraestructura, etc.)	Categoria_Servicio	id_categoria, nombre, descripción
Métricas y KPIs	Indicadores estandarizados para evaluación	KPI_Definicion	id_kpi, nombre, unidad, fórmula, frecuencia

Para que la capa de Reference Data proporcione la estructura semántica y los controles necesarios para estandarizar, validar y gobernar todos los catálogos que sustentan los procesos de la Alcaldía municipal se recomienda:

Gobernanza de Catálogos

• Establecer un comité de datos (Data Council) que apruebe cambios y nuevas versiones.
• Versionar cada catálogo con fechas de vigencia y números de versión.

Distribución y Sincronización

• Publicar catálogos a través de APIs RESTful (o OData) y exports periódicos (CSV/JSON).
• Implementar mecanismos de “pull” en aplicaciones cliente para refrescar catálogos (p. ej. cada 24 hrs).

Control de Calidad y Validación

• Definir reglas de validación en origen (front‑end o API) para impedir inserción de códigos no existentes.
• Ejecutar pruebas automatizadas (unitarias) tras cada actualización de catálogo.

Documentación y Accesibilidad

• Mantener un repositorio central (por ejemplo, en un Data Catalog o wiki interno) con definiciones, ejemplos y glosario.
• Publicar guías de uso (p. ej. “Cómo referenciar el catálogo de Tipo_Tramite en solicitudes”).

Seguridad y Accesos

• Restringir cambios a usuarios o roles autorizados (Data Stewards).
• Registrar en logs quién hizo cada modificación y cuándo.

Lineaje y Trazabilidad

• Documentar el origen de cada catálogo (normativa, decreto, organismo externo).
• Asociar políticas de retención: algunos catálogos pueden requerir histórico completo (p. ej. tarifas).

Integración con Master y Transaccional

• Forzar claves foráneas en tablas transaccionales hacia los catálogos.
• Auditar periódicamente la integridad referencial (no debe haber valores huérfanos).

2.3      Datos transaccionales (Transactional Data)

Los datos transaccionales se encargan de capturar y almacenar todos los eventos operativos y de negocio que suceden de manera cotidiana en la Alcaldía, incluyendo interacciones con ciudadanos, pagos, contratos, trámites, proyectos y programas. Esta capa alimenta tanto los procesos de operación diaria como los sistemas analíticos (Data Warehouse, BI).

Categoría	Ejemplos de Entidades / Tablas	Atributos clave
Pagos y Recaudos	Pago_Impuesto, Pago_Servicio, Recaudo_Patrimonio	id_pago, id_ciudadano, id_predio, valor, fecha_pago, método_pago, recibo_número
Trámites y Solicitudes	Trámite, Solicitud, Registro_Ciudadano	id_trámite, id_ciudadano, id_tipo_trámite, fecha_solicitud, estado, observaciones
Contratación	Contrato, Adición_Presupuestal, Acta_Vinculación	id_contrato, id_empleado, id_proveedor, fecha_inicio, fecha_final, valor_contrato, objeto
Servicios Ciudadanos	Solicitud_Servicio, Atención_Servicio, Cierre_Servicio	id_solicitud, id_servicio, id_ciudadano, fecha_inicio, fecha_cierre, estado, responsable
Gestión de Proyectos	Avance_Proyecto, Hito_Proyecto, Desembolso_Proyecto	id_avance, id_proyecto, fecha_registro, porcentaje_avance, comentario; id_hito, fecha_hito
Ejecución de Programas	Desembolso_Programa, Informe_KPI_Programa, Registro_Actividad	id_desembolso, id_programa, fecha, monto; id_kpi, valor, fecha_medición; descripción_actividad
Auditoría de Transacciones	Log_Transacción	id_log, tabla_origen, operación (I/U/D), usuario, timestamp, datos_previos, datos_posteriores

La capa de Datos Transaccionales cubre de manera integral no solo los pagos y trámites, sino también la gestión de proyectos y programas, garantizando un registro completo, normalizado y auditado de todas las operaciones municipales. Para garantizar una buena práctica en el manejo de los datos transaccionales se debe tener en cuenta:

1. Modelado y Normalización
   • Diseñar cada área (pagos, trámites, contratos, proyectos, programas) en esquemas normalizados (3FN) para mantener integridad referencial.
   • Separar tablas de “detalle” (ej. Avance_Proyecto) de “cabecera” (Proyecto) para facilitar reportes y agregados.
2. Change Data Capture (CDC)
   • Implementar mecanismos de CDC (p.ej. Debezium, triggers nativos) para replicar cambios en tiempo cercano a los sistemas de BI y Data Warehouse.
   • Definir políticas de retención para los logs de CDC, equilibrando trazabilidad y espacio de almacenamiento.
3. Auditoría y Trazabilidad
   • Registrar en cada tabla transaccional campos de auditoría: created_by, created_at, modified_by, modified_at.
   • Centralizar los logs de transacciones críticas (p.ej. pagos y contratos) en tablas de auditoría especializadas (Log_Transacción).
4. SLAs de Disponibilidad
   • Establecer metas de latencia: p.ej., que toda transacción quede disponible para análisis en máximo 15 minutos.
   • Monitorizar procesos ETL/ELT y alertar automáticamente en caso de fallos o demoras.
5. Integridad Referencial y Validaciones en Origen
   • Forzar claves foráneas a Master Data y Reference Data para garantizar consistencia (p.ej. id_ciudadano siempre válido, id_programa activo).
   • Validaciones en tiempo real en la capa de captura (front-end o API) para asegurar dominios y rangos correctos.
6. Seguridad y Acceso
   • Definir roles y permisos granulares: p.ej., solo Tesorería puede insertar o anular registros de pagos; Secretaría de Planeación gestiona avances de proyectos.
   • Encriptar datos sensibles en reposo y aplicar conexión TLS para las transacciones.
7. Monitoreo y Alertas
   • Crear dashboards operativos que muestren volúmenes de transacciones por canal (portal web, atención presencial), estado de trámites, desviaciones de cronogramas de proyectos.
   • Configurar alertas automáticas ante caídas de procesos ETL, alta tasa de errores o incumplimientos de SLA.

2.4 Metadata

Los metadatos proporcionan información sobre los datos mismos —su contexto, origen, calidad, estructura y reglas de uso— para habilitar la gobernanza, trazabilidad y auto‑servicio.

Categoría	Descripción	Ejemplo de Elemento	Atributos Clave / Notas
Diccionario de Datos	Definiciones y propiedades de tablas y campos	Tabla: CIUDADANOCampo: numero_documento	tipo de dato, longitud, formato, dominio de valores
Linaje de Datos	Flujo de transformación desde origen hasta destino	Origen: formulario web → ETL → DW	origen_sistema, proceso, timestamp, destino
Políticas de Retención	Reglas de conservación y eliminación de registros	Expedientes civiles: 20 años	entidad, periodo_vigencia, responsable de eliminación
Catálogo de Calidad	Reglas y métricas para medir integridad, completitud, precisión	Completeness: % registros con email válido	métrica, umbral_aceptable, frecuencia de cálculo
Configuración ETL/ELT	Parámetros de extracción, transformación y carga	Job: ETL_PREDIOS_DIARIO	frecuencia, parámetros, notificaciones, responsable
Modelos y Esquemas	Estructuras de datos físicas y lógicas	Esquema DW: estrella de “Recaudación”	tablas_hecho, tablas_dimensión, relaciones
Versionamiento de Catálogos	Historial de cambios en Reference Data	Versión 1.2 de Tipo_Tramite	versión, fecha_publicación, autor_cambio
Glosario de Negocio	Términos y definiciones de negocio para alineación semántica	“Programa”: iniciativa estratégica	término, definición, ejemplos de uso

Fuente: Secretaría de Hacienda de Armenia (2025)

Para que la capa de metadata queda completamente alineada con las necesidades de gobernanza, trazabilidad y calidad de datos de la Alcaldía municipal, facilitando la confianza y el acceso controlado para todos los usuarios de información de la entidad, se recomienda:

  Centralización y Herramienta de Catálogo

• Utilizar una plataforma de Data Catalog (p.ej. Apache Atlas, Alation) o repositorio interno para centralizar todos los metadatos.
• Proveer interfaz de búsqueda y navegación para facilitar el descubrimiento.

  Captura Automática de Linaje

• Integrar conectores ETL y logs de base de datos que registren el flujo de datos sin intervención manual.
• Visualizar mapas de linaje que muestren dependencias entre sistemas y procesos.

  Mantenimiento de la Calidad de Metadatos

• Definir indicadores de calidad de metadatos (por ejemplo, porcentaje de tablas documentadas).
• Ejecutar revisiones periódicas para detectar metadatos obsoletos o incompletos.

  Versionado y Gobernanza de Cambios

• Gestionar cambios en metadatos mediante control de versiones, con fechas de vigencia y autores.
• Aprobar modificaciones a través de un Data Governance Board, registrando actas de decisiones.

  Integración con Seguridad y Privacidad

• Etiquetar metadatos relacionados con datos sensibles (PII) y enlazar con políticas de encriptación y acceso.
• Registrar en el catálogo los roles y permisos asociados a cada conjunto de datos.

  Documentación de Procesos ETL/ELT

• Mantener descripciones detalladas de cada job (frecuencia, transformaciones aplicadas, excepciones).
• Asociar diagramas de flujo y scripts de referencia en el repositorio de metadatos.

  Auto‑Servicio y Capacitación

• Ofrecer guías de uso y talleres de introducción al catálogo de metadatos para usuarios técnicos y de negocio.
• Incluir tutoriales sobre cómo interpretar linaje, diccionario y métricas de calidad.

  Monitoreo y Alertas de Metadatos

• Configurar notificaciones automáticas ante caducidad de catálogos o desviaciones en SLAs de actualizaciones.
• Generar reportes ejecutivos de estado del catálogo: porcentaje de campos documentados, catálogos pendientes de versión.

3.      Modelo Conceptual (entidad-relación)

El modelo conceptual de Entidad–Relación para la estructura de datos expuesta se despliega a continuación.

erDiagram
CIUDADANO ||–o{ PREDIO : posee
CIUDADANO ||–o{ TRAMITE : solicita
CIUDADANO ||–o{ PAGO_IMPUESTO : efectúa

PREDIO     }o--o{ IMPUESTO        : genera
TRAMITE    }o--|{ TIPO_TRAMITE    : clasifica
PAGO_IMPUESTO }o--|| METODO_PAGO  : usa

EMPLEADO   ||--o{ CONTRATO        : firma
CONTRATO   }o--o{ PROVEEDOR       : relaciona

SERVICIO   ||--o{ SOLICITUD       : atiende
SOLICITUD  }o--|| CIUDADANO       : inicia

EMPRESA    ||--o{ PROGRAMA        : administra
EMPRESA    ||--o{ PROYECTO        : patrocina
PROGRAMA   ||--o{ PROYECTO        : contiene

%% Definición de entidades y atributos clave
CIUDADANO {
  int id_ciudadano PK
  string nombre
  string tipo_documento
  string numero_documento
  date fecha_nacimiento
  string direccion
  string email
  string telefono
  audit created_by, created_at, modified_by, modified_at
}
PREDIO {
  int id_predio PK
  string codigo_catastral
  int id_ciudadano FK
  geometry ubicacion
  float area_m2
  string uso_suelo
  audit created_by, created_at, modified_by, modified_at
}
TRAMITE {
  int id_tramite PK
  int id_ciudadano FK
  int id_tipo_tramite FK
  date fecha_solicitud
  string estado
  audit created_by, created_at, modified_by, modified_at
}
PAGO_IMPUESTO {
  int id_pago PK
  int id_ciudadano FK
  int id_predio FK
  float valor
  date fecha_pago
  int id_metodo_pago FK
  audit created_by, created_at, modified_by, modified_at
}
TIPO_TRAMITE {
  int id_tipo_tramite PK
  string nombre
  string descripcion
}
METODO_PAGO {
  int id_metodo_pago PK
  string nombre
  string detalle
}
EMPLEADO {
  int id_empleado PK
  string nombre
  string cargo_actual
  date fecha_ingreso
  int id_dependencia FK
  audit created_by, created_at, modified_by, modified_at
}
CONTRATO {
  int id_contrato PK
  int id_empleado FK
  int id_proveedor FK
  date fecha_inicio
  date fecha_final
  float valor_contrato
  string objeto
  audit created_by, created_at, modified_by, modified_at
}
PROVEEDOR {
  int id_proveedor PK
  string razon_social
  string nit
  string direccion
  string telefono
  string categoria_ciiu
  audit created_by, created_at, modified_by, modified_at
}
SERVICIO {
  int id_servicio PK
  string nombre
  string descripcion
}
SOLICITUD {
  int id_solicitud PK
  int id_servicio FK
  int id_ciudadano FK
  date fecha_solicitud
  string estado
  text observaciones
  audit created_by, created_at, modified_by, modified_at
}
EMPRESA {
  int id_empresa PK
  string nombre
  string nit
  string tipo_empresa
  string direccion
  string telefono
  string representante_legal
  audit created_by, created_at, modified_by, modified_at
}
PROGRAMA {
  int id_programa PK
  string nombre
  string descripcion
  string objetivo
  date fecha_inicio
  date fecha_fin
  string dependencia_responsable
  int id_empresa FK
  audit created_by, created_at, modified_by, modified_at
}
PROYECTO {
  int id_proyecto PK
  string nombre
  string descripcion
  string objeto
  float presupuesto
  date fecha_inicio
  date fecha_fin
  string estado
  int id_programa FK
  int id_empresa FK
  audit created_by, created_at, modified_by, modified_at
}