FONDO DE DESARROLLO DE PROYECTOS DE CUNDINAMARCA FONDECUN CONVOCATORIA PÚBLICA POR SORTEO IPS CONTRATO INTERADMINISTRATIVO No.

Transcripción

1 FONDO DE DESARROLLO DE PROYECTOS DE CUNDINAMARCA FONDECUN CONVOCATORIA PÚBLICA POR SORTEO IPS CONTRATO INTERADMINISTRATIVO No. 029 DE 203 SECRETARÌA DE HACIENDA DE CUNDINAMARCA ANEXO TECNICO SUMINISTRO DE SOFTWARE Y SERVICIO ESPECIALIZADO PARALA EVALUACIÓN DE LA CALIDAD DE LOS DATOS, SU LIMPIEZA Y POSTERIOR CONSOLIDACIÓN DE LAS BASES DE DATOS DEL IMPUESTO DE VEHÍCULOS DE CUNDINAMARCA DENTRO DE UN REPOSITORIO CENTRAL UNIFICADO BOGOTÁ D.C., DICIEMBRE DE 203

2 TABLA DE CONTENIDO ANEXO TECNICO. INTRODUCCION 2. BREVE DESCRIPCIÓN DEL ESTADO ACTUAL 2.. ESTADÍSTICAS Y VOLÚMENES ACTUALES 3. ALCANCE Y CONDICIONES 3. HERRAMIENTAS TECNOLOGICAS 3.2. METODOLOGIA 4. MODELO DE ARQUITECTURA Y DE GESTIÓN DE LA CALIDAD DE LOS DATOS 4.. ENFOQUE DE LA GESTIÓN DE LA CALIDAD DE LOS DATOS 4.2. ASPECTOS DE LA GESTIÓN DE CALIDAD DE LOS DATOS 5. SERVICIOS PROFESIONALES ESPECIALIZADOS 5. ALCANCE DE SERVICIOS 5.2. EQUIPO DE TRABAJO 5.3. ENTREGABLES 5.4 SOPORTE ANEXO. GLOSARIO DE TÉRMINOS 2

3 . Introducción Dentro de las acciones incluidas en el Plan Operativo del contrato interadministrativo, está prevista la contratación del SUMINISTRO DE SOFTWARE Y SERVICIO ESPECIALIZADO LA EVALUACIÓN DE LA CALIDAD DE LOS DATOS, SU LIMPIEZA Y POSTERIOR CONSOLIDACIÓN DE LAS BASES DE DATOS DEL IMPUESTO DE VEHÍCULOS DE CUNDINAMARCA DENTRO DE UN REPOSITORIO CENTRAL UNIFICADO, con el fin de garantizar la eficiente y oportuna gestión del recaudo de los ingresos dentro de las políticas de financiación de los programas que integran el Plan de Desarrollo. El presente documento determina el alcance y las especificaciones técnicas que se deben cumplir para la prestación de los servicios que a continuación se describen y que harán parte de las condiciones de contratación del servicio mencionado oportunamente. Lo anterior, en concordancia con el objetivo principal de la Secretaría de Hacienda del Departamento de Cundinamarca, el cual es garantizar la eficiente y oportuna gestión del recaudo de los ingresos dentro de las políticas de financiación de los programas que integran el Plan de Desarrollo. Así mismo busca: Incrementar el recaudo de impuestos vehiculares. Eliminar sobrecargas al proceso de recaudo de impuestos vehiculares. Disminuir los gastos por atención de peticiones, quejas y reclamos de los usuarios Disminuir el número de liquidaciones erradas Evitar el deterioro de la imagen institucional por no contar con información confiable Fortalecer el proceso de fiscalización del impuesto de vehículos del departamento. La Secretaría de Hacienda de Cundinamarca desea seleccionar la propuesta más favorable para contratar los servicios profesionales especializados en la evaluación de la calidad de los datos y la consolidación de las bases de datos del impuesto de vehículos de Cundinamarca en un Repositorio Unificado de Información. En cumplimiento de este propósito, la Secretaria de Movilidad del Departamento de Cundinamarca suscribió en el año 2002 un contrato de concesión con la empresa Data Tools Ltda. para administrar: capturar, mantener, gestionar la calidad y consolidar toda la información relacionada con el registro, novedades e información básica de los vehículos pertenecientes al parque automotor del departamento, integrándola con las entidades de orden nacional, departamental y municipal. De la misma forma, en el año 2003, la Secretaría de Hacienda del Departamento de Cundinamarca suscribió un contrato prorrogado hasta el 4 de Diciembre de 203- con la firma QUIPUX S.A para el licenciamiento, mantenimiento y soporte del software 3

4 Qx-Impuestos-Plus que permite el recaudo y cargue de los pagos del impuesto de vehículos así como su liquidación y fiscalización. Ahora bien, en la ejecución de la operación diaria y particularmente en el proceso de carga de los datos de vehículos producidos por el sistema Circulemos de la firma Data Tools Ltda. al sistema Qx-Impuestos-Plus, la Secretaría de Hacienda del Departamento ha venido detectando distintos errores (exactitud, consistencia, integridad, validez) en la calidad de los datos de vehículos, circunstancia que origina entre otras dificultades, la sobrecarga del proceso, gastos por atención de peticiones, quejas y reclamos de los usuarios, exigencias de cumplimiento de requisitos legales, liquidaciones erradas, deterioro de la imagen institucional, desperdicios en tiempos y recursos y dificultades en la fiscalización del impuesto de vehículos del departamento. Paralelamente, existe un convenio con tres entidades bancarias (BBVA, AV Villas y Colpatria) para llevar a cabo actividades de Recaudo de Impuestos (ver Figura ), cuya información es remitida en medio magnético a la Entidad mensualmente con un archivo de imágenes de los formularios con las declaraciones de pago del impuesto de vehículos diligenciados por los contribuyentes. Los datos de los archivos planos enviados por estas Entidades se consolidan y se cargan en el Aplicativo SIVC (Sistema de Información de Vehículos de Cundinamarca), se publican en la página web del departamento para consulta de los usuarios y posteriormente los datos son exportados al Sistema Qx-Impuestos-Plus que sirve de base para la liquidación del impuesto de vehículos de Cundinamarca. Se ha establecido que la información del Aplicativo SIVC, la página web y el Sistema Qx-Impuestos-Plus, no es totalmente consistente. Figura. Declaración de Pagos realizada en los Bancos 4

5 Debido a esta situación, la Secretaría de Hacienda de Cundinamarca ha elaborado un plan estratégico tendiente a resolver las dificultades estructurales que propician los inconvenientes de calidad en los datos de vehículos del Departamento. Una de estas acciones está relacionada con la creación de un Modelo de Arquitectura y Gobierno de los Datos inexistente en la actualidad- que incluye una estrategia de gestión de calidad de los datos, cuyo punto de partida es la evaluación de la calidad de los datos, la detección de los errores, su limpieza y monitoreo y posterior consolidación de las Bases de Datos del Impuesto de vehículos de Cundinamarca en un Repositorio Unificado de Información. 2. Breve descripción del estado actual El sistema de información Circulemos que permite administrar: capturar la información de vehículos de las inspecciones de tránsito de Cundinamarca (doce (2) de orden departamental y cinco (5) del orden municipal), mantener, gestionar la calidad y consolidar toda la información del registro, novedades e información básica de los vehículos pertenecientes al parque automotor del departamento, es una aplicación Web Based Application (Web Enabled) de Arquitectura Cliente-Servidor con un servidor de Base de Datos Informix V con facilidades OLTP (Procesamiento de Datos en Línea). El sistema de información de Qx-Impuestos-Plus es una aplicación desarrollada en Power Buider con arquitectura cliente-servidor para los procesos centralizados (digitación, fiscalización, procesos de cobro, conciliaciones bancarias, etc.) y Java en arquitectura multinivel con diseño WEB para los procesos descentralizados (consultas, liquidación, expedición de certificados, etc.). La información se almacena en un motor de base de datos relacional Oracle. El aplicativo SIVC está desarrollado sobre MS Access 97 (ver figura 2) y los datos se han almacenado en un motor de Base de Datos SQL Server Así mismo, la Secretaría de Transporte y Movilidad de Cundinamarca tiene otra concesión con la empresa SIETT para los trámites de tránsito y novedades registradas periódicamente, como multas, traspasos, etc. Por otra parte, están las inspecciones de tránsito municipales quienes envían periódicamente archivos en Excel con actualizaciones y novedades de vehículos allí registrados; es de anotar que su comportamiento ha sido variable y el reporte de la información no ha sido constante. Algunas de las bases de datos representan fuentes primarias o secundarias de datos cuyos accesos serán facilitados por la Secretaría de Hacienda. El Contratista podrá acceder a las Bases de Datos y documentos físicos de las inspecciones de tránsito departamentales y municipales de Cundinamarca, localizadas en: CAQUEZA(D), CHIA(M), CHOCONTA(D), COTA(D), EL ROSAL(D), FACATATIVA(D), FUNZA(M), FUSAGASUGA(M), GIRARDOT(M), LA CALERA(D), MOSQUERA(D), PACHO(M), RICAURTE(D), SOACHA(D), UBATE(D), VILLETA(D) y ZIPAQUIRA(D). Nota: La (D) hace referencia a las inspecciones de tránsito departamentales y la (M) a las municipales. 5

6 Fuentes secundarias facilitadas por la Secretaría de Hacienda de Cundinamarca: Base de Datos de DataTools, Base de datos del SIETT, Base de Datos de Quipux. Figura 2. Pago de declaraciones de impuestos a través del Aplicativo SIVC. 2.. Estadísticas y volúmenes actuales A continuación presentamos algunas estadísticas que describen los volúmenes aproximados de los datos que deben manejarse durante el desarrollo y ejecución del contrato. Las cifras correspondientes al año 202 fueron las obtenidas hasta el mes de Abril inclusive. a) Vehículos registrados por año según inspección de tránsito. Inspección de Tránsito Carga Inicial Del 2003 al Total Exentos Activos CAQUEZA(D) CHIA(M) CHOCONTA(D)

7 COTA(D) EL ROSAL FACATATIVA(D) FUNZA FUSAGASUGA( M) GIRARDOT(M) LA CALERA(D) MOSQUERA(D) PACHO(M) RICAURTE(D) SOACHA(D) UBATE(D) VILLETA(D) ZIPAQUIRA(D) DESCONOCIDO Total por Vigencia b) Registro de propietarios por año según inspección de tránsito. Inspección de Tránsito Carga Inicial Del 2003 al Total Exentos Activos CAQUEZA(D) CHIA(M) CHOCONTA(D) COTA(D)

8 EL ROSAL FACATATIVA(D) FUNZA FUSAGASUGA( M) GIRARDOT(M) LA CALERA(D) MOSQUERA(D) PACHO(M) RICAURTE(D) SOACHA(D) UBATE(D) VILLETA(D) ZIPAQUIRA(D) DESCONOCIDO Total por Vigencia

9 3. Alcance y condiciones SUMINISTRO DE SOFTWARE Y SERVICIO ESPECIALIZADO PARA LA EVALUACIÓN DE LA CALIDAD DE LOS DATOS, SU LIMPIEZA Y POSTERIOR CONSOLIDACIÓN DE LAS BASES DE DATOS DEL IMPUESTO DE VEHÍCULOS DE CUNDINAMARCA DENTRO DE UN REPOSITORIO CENTRAL UNIFICADO Dentro de las condiciones requeridas se tienen dos componentes: Solución de Software y la metodología de implementación. 3.. Solución de Software Se requiere una plataforma unificada de integración y limpieza de datos que permita la incorporación de prácticas tales como perfilamiento de datos, rutinas de calidad, enriquecimiento y monitoreo basados en fuentes ciertas, corrección y consolidación desde distintas fuentes que soporten el proceso de gestión de la calidad de los datos y que de manera natural permita la creación y definición de entidades maestras. El software ofertado debe estar ubicado en la categoría de "leaders" en el cuadrante mágico de Gartner de Data Quality (Octubre 203). El software debe contar con los requerimientos mínimos descritos a continuación:. Capa de Arquitectura ETL Num. Requerimientos Funcionales y Técnicos Análisis de la funcionalidad de la solución de ETL 2 La solución debe incluir capacidades para la extracción de datos mediante mecanismos de acceso nativo a cualquier fuente de datos propia como de terceros en los formatos preestablecidos (Texto, Excel, Base de Datos). La herramienta de software de ETL o ELT debe contar con una interfaz manipulable (gráfica y paramétrica) por el usuario para el proceso de extracción, transformación y carga 3 La solución debe permitir la conexión vía ODBC y OLE DB. Natural se refiere a que el software cuente con las capacidades de gestión de datos maestros (MDM) y que estén inmersas para su explotación y utilización de manera nativa en el mismo software de calidad e integración de datos. 9

10 4 La solución debe contener capacidades de alto desempeño para la integración de datos mediante mecanismos de acceso nativos a cualquier fuente de datos propia como de terceros, calidad de datos, ETL (extracción, transformación y carga de información), ELT (extracción, carga de información y transformación) sincronización de datos, así como el almacenamiento de alto desempeño y diseminación de información para cumplir con requerimientos de aplicaciones de manejo de modelos analíticos y de inteligencia de negocios Las capacidades de Integración y Calidad de Datos deben estar integradas con un ambiente de análisis y modelado predictivo de manera natural. La arquitectura de la solución debe ser suficientemente flexible de manera que permita la extensión de la funcionalidad requerida para el proceso de extracción, transformación y carga, si es requerido. Soportar el disparo de procesos ETL con base en estas dependencias: Hora y fecha, creación de un archivo y en la ejecución satisfactoria de otro proceso ETL. La solución deberá ser capaz de crear sus propias transformaciones usando un asistente para transformaciones permitiendo reutilizar las mismas. Debe Proveer búsqueda y clarificación de la información contenida en SAP de manera nativa Debe Proveer integración de metadatos que permiten la exploración de datos de SAP sin conocimientos profundos de su estructura, en doble vía: lectura y escritura. Performance de la solución 2 3 La solución debe permitir el procesamiento en paralelo y multi-hilo y el balanceo automático de carga. De requerirse, la solución debe poder conectarse directamente a las Bases de Datos operacionales del negocio sin tener que cargar o copiar los datos en áreas especiales de almacenamiento para su proceso y análisis. La solución debe incluir puntos de reinicio y soportar la recuperación y el relanzamiento automático de procesos, en caso de que estos sufran interrupciones. 4 Debe ser capaz de soportar el alto volumen de datos de manera fácil y ágil. 5 Soporte para el control de versiona miento, documentación y colaboración nativo para soportar proyectos de tipo empresarial 0

11 6 Debe contar con su propio lenguaje de programación (de cuarta generación) para extender las funcionalidades y creación de nuevas transformaciones. 7 8 Arquitectura de la Plataforma de calidad y de integración La plataforma deberá añadir valor a los datos existentes mediante la generación y uso de diversas fuentes de información y metadatos. El proceso de gestión de la calidad de los datos debe permitir la trazabilidad del mismo y sus resultados. 9 La plataforma debe permitir la comunicación asíncrona a través de colas de mensajes. 20 La plataforma deberá añadir valor a los datos existentes mediante la aplicación de diversas fuentes de información propias y de terceros así como sus metadatos La plataforma deberá permitir la ejecución de los procesos de limpieza en línea y en batch. Debe contar con APIs que permitan la interacción con diferentes aplicaciones standard como C++/C#, COM, JAVA, Perl,.NET 23 La plataforma deberá de permitir la integración con SOA La plataforma deberá contar con eventos específicos para monitoreo tales como lanzar procesos en batch o en tiempo real, generar log de errores a un repositorio, archivo plano o base de datos, enviar notificaciones vía correo electrónico, establecer variables de ambiente o lanzar programas externos. La plataforma debe considerar la elaboración y aplicación de plantillas para la configuración del proceso de calidad de los datos de las fuentes operacionales. 2. Capa Limpieza y Calidad de Datos: Num. Requerimientos Funcionales y Técnicos Características de la Plataforma Deberá contar con una interfaz amigable y sencilla de usar para administrar los procesos de Integración y de Calidad La plataforma deberá ser capaz de homologar y estandarizar la información de las diferentes fuentes de información La plataforma deberá realizar la validación de la información extraída de las diversas fuentes e interactuar con múltiples tipos de estructuras de datos

12 Debe contar con procesos automatizados para el manejo de perfiles, limpieza, mejora y monitoreo de los datos que permita la creación de información consistente. La plataforma deberá permitir el perfileo de datos operacionales y monitorear las actividades ejecutadas sobre los datos mediante un GUI interactivo. La plataforma permitirá el uso de clusters y otras técnicas avanzadas de calidad de datos para la unificación de registros La plataforma debe permitir flexibilidad en la personalización de reglas de limpieza de acuerdo a las necesidades de negocio específicas de la Secretaria de Hacienda. La plataforma debe contar con una base de datos de conocimiento propia basada en algoritmos heurísticos y fonéticos que permita ser personalizada con editores de expresiones regulares, vocabularios, esquemas, gramática y fonética. La plataforma deberá tener la capacidad de implementar KPI y Dashboards que evalúen la calidad de datos en sus seis dimensiones principales: Precisión, Completitud, Consistencia, Integridad, Estructura y Validez La plataforma deberá permitir analizar la estructura de tablas, relaciones, campos, detectando inconsistencias entre ellas Debe contar con diferentes funciones para evaluación de la calidad de los datos, tales como: Análisis estadístico Histogramas Valores nulos Data Explorer Overlap La plataforma deberá permitir generar métricas personalizadas, tales como reglas de negocio, tareas y ejecución de procesos. Deberá permitir identificar redundancia de metadatos y datos de diferentes fuentes, de manera exacta y a través de un match code que permita utilizar definiciones entre las columnas coincidentes y con diferentes análisis de sensibilidad. Deberá ser capaz de generar reportes y estadísticas de las bases de datos antes de la limpieza y en fases posteriores para un seguimiento progresivo. 40 La plataforma debe contener herramientas de edición controlada de datos La plataforma debe disponer de analizadores sintácticos que permitan el parsing de textos a fin de obtener la comprensión de los mismos. La plataforma debe disponer de los procedimientos y herramientas que permitan la complementación y enriquecimiento de los datos objeto del análisis y limpieza. La plataforma deberá permitir monitorear la calidad de los datos, así como generar alertas en cuanto ocurra alguna inconsistencia de calidad. 2

13 44 La plataforma debe contar con todas y cada una de las áreas Funcionales de Calidad de Datos nombradas a continuación:. Perfilamiento de Datos 2. Validación de tipo de datos y formatos 3. Validación en dependencia de datos 4. Optimización de algoritmos de coincidencias 5. Lógica Difusa 6. Exactitud en modelos coincidentes 7. Configuración de reglas de coincidencias 8. Análisis Sintáctico 9. Limpieza de datos sensible a contextos 0. Configuración de Reglas de Limpieza. Fusiones y supervivencia 2. Enriquecimiento de Datos 3. Estandarización 4. Integración de Fuentes Externas 5. Monitoreo de Calidad 6. Soporte de Tipos de Dato 45 Deberá permitir integrarse de forma nativa con estrategias de Master Data Management y de Gobierno de Datos, de esta forma se podrá escalar la solución a nuevos requerimientos de negocio de forma transparente 3. Capa Administración, Seguridad e Infraestructura de los Datos: Num. Requerimientos Funcionales y Técnicos Seguridad y Administración de la Plataforma La administración de la seguridad debe basarse en la definición y asignación de Roles y permisos para todos los usuarios del sistema. La administración de la seguridad debe extenderse hasta el control de los Repositorios, fuentes de información, metadata, ETL, sistemas operativos, mecanismos de integración y de presentación y demás herramientas utilizadas para el mejoramiento de la calidad de los datos. La plataforma debe permitir la administración de alertas mediante la aplicación de diversas facilidades como el envío de mensajes a los usuarios vía correo electrónico. 3

14 La plataforma deberá tener la posibilidad de programar la ejecución de los eventos y procesos en batch o en tiempo real y generar log de errores en un repositorio, archivo plano o base de datos que puede ser consultado por las partes interesadas. La administración de la seguridad debe contar con sistema de control de acceso de roles, perfiles, cuentas de usuario y contraseñas por cada usuario. La seguridad provista por la plataforma debe poderse aplicar a nivel de registro de Base de Datos. La administración de la seguridad de la información (Bases de Datos Estructuradas y no Estructuradas, Repositorios generados por la solución) debe ser realizada de manera centralizada por parte del personal de la Secretaria de Hacienda. La plataforma debe soportar encriptación, Single Sign On, Autorización basada en metadatos y disponibilidad de funciones de la aplicación basada en roles La plataforma debe manejar plantillas de control de acceso que eviten tener que configurar repetidamente los mismos permisos explícitos para las mismas identidades en varios objetos. La plataforma debe contar con mecanismos específicos de autenticación como LDAP, PAM (Pluggable Authentication Module) para entornos Linux, host y autenticación integrada con Windows. La plataforma deberá ser compatible con sistemas operativos: Linux, Windows, AIX, Solaris y Bases de Datos Oracle, Informix, Postgres, MySql, SQL Server. La plataforma debe permitir la creación de usuarios, roles y grupos que permitan la correcta administración. La plataforma debe poder exportar e importar los metadatos correspondientes a usuarios, grupos y roles con fines de migración o paso a ambientes productivos. La plataforma debe basarse en su totalidad en un sistema integrado de metadatos para definir roles, permisos, procesos de carga, procesos extracción, transformaciones, fuentes de datos, datos objetivo, entre otros 60 La plataforma debe utilizar protocolos seguros como SSL para proteger identidades La plataforma debe contar con controladores nativos para la conexión con bases de datos al menos para Oracle, DB2, SAP, Informix y MySQL. La plataforma deberá ser capaz de alertar a los usuarios vía mail o realizar tareas específicas en caso que el proceso ETL falle. Deberá soportar los siguientes estándares tecnológicos y de transporte de datos: XML, J2EE y CWM, a través de una arquitectura abierta de metadatos. 4

15 4. Capa de Datos Maestros: Num. Requerimientos Funcionales y Técnicos Planeación y Crecimiento de la Solución 64 La plataforma deberá contener características básicas de una solución de MDM 65 La plataforma deberá contar con un repositorio integrado que almacene entidades maestras o datos maestros, los componentes de metadatos asociados a las tareas de calidad, reglas, templates, definición de las entidades maestras, entre otros. 66 La plataforma debe tener la capacidad de crear definiciones de entidades maestras Debe contar con capacidades de resolución de entidades y registros sobrevivientes con fines de MDM La plataforma debe poder migrar sus características básicas de una solución de MDM a características o versiones avanzadas de MDM Debe tener una interfaz gráfica donde se visualice los datos maestros, permita editar los registros sobrevivientes, monitorear el linaje de datos, entre otros. Debe contar con la posibilidad de automatizar los procesos que mantengan actualizado el modelo de datos maestros La plataforma debe contar con algunos templates o plantillas para elaborar entidades maestras El proponente deberá especificar el nombre de la herramienta de software ofertada e indicar que cumple con la totalidad de los requerimientos. Queda claro que un proponente no cumple alguno o algunos de los requerimiento técnico no se satisface(n) con una plataforma integrada de manera nativa. Nota: Esta capacidad será verificada por el supervisor del contrato en el momento de la instalación de la plataforma. El proponente deberá describir la visión de arquitectura de solución para la implementación de su software, deberá presentar las características de hardware y software requeridas, incluyendo la descripción de: Servidores y sus capacidades Sistemas Operativos Bases de datos y plataforma compatible Requerimientos de red 5

16 Estaciones y características de los puestos de trabajo para el equipo del proyecto. Nota: Este documento no será objeto de evaluación. Esta documentación será verificada por el Supervisor del Contrato en el momento del inicio de la ejecución del proyecto con el propósito de realizar los respectivos ajustes para la entrega del Plan de Trabajo Metodología Los servicios de calidad y limpieza de datos solicitados por la Secretaría de Hacienda de Cundinamarca comprenden un proceso con las siguientes fases: a) Entender el Negocio b) Conocer los Datos de la Organización c) Identificar Datos y Reglas para el proceso de calidad d) Construir la Arquitectura de los Datos e) Evaluar los resultados y refinar el proceso f) Desplegar los datos obtenidos. A continuación se presentan sus principales características: a. Entender el Negocio Establecer los objetivos y principios del negocio, los flujos de información con todas sus interdependencias, los procesos y funciones principalmente los relacionados con el Impuesto de Vehículos de Cundinamarca, las partes interesadas y la organización dispuesta para la generación, procesamiento, actualización, despliegue y análisis de los datos. Efectuar un análisis de madurez y capacidad de la organización que establezca los factores, condiciones, capacidad de los procesos, utilización de estándares y en general las fortalezas y debilidades de los procesos y funciones relacionados con el Impuesto de Vehículos de Cundinamarca. Realizar una valoración (Assessment) de la situación actual con el análisis de los factores que condicionan la calidad de los datos del Impuesto de Vehículos de Cundinamarca. Realizar un análisis de riesgos inherente y residual considerando el resultado de los ítems precedentes que permitan valorar, definir y establecer el plan de mitigación de los riesgos asociados a las dimensiones de calidad de los datos definidas. Elaborar el Plan del Proyecto que permita cumplir con el objetivo. b. Conocer los Datos de la Organización Realizar un inventario de las fuentes de datos, identificando la fuente de datos, su ubicación, los tipos de datos que maneja (operativo, colaborativo, analítico, estructurado, no estructurado), el propietario de los datos, su responsable o custodio, la aplicación que los genera y mantiene, la arquitectura de las aplicaciones de soporte, el 6

17 grado de exposición, modificación, alteración o pérdida del dato de interés, las restricciones de seguridad que tiene y los aspectos susceptibles de mejora de la fuente. Identificar los usos de los datos de las fuentes de datos con base en los fines del negocio. Categorizar y/o crear una taxonomía de los datos de acuerdo con los procesos y funciones del negocio que los requieren, estableciendo los grupos de información a ser utilizados en el proceso. Evaluar la calidad de los datos y clasificar los resultados en términos de su exactitud, validez, consistencia, estandarización, deduplicación y demás dimensiones aportadas, para los datos relacionados con el Impuesto de Vehículos. El objetivo de ésta actividad consiste en identificar aquellos conjuntos o grupos de datos en donde una mala calidad cause un impacto negativo y significativo en la liquidación del impuesto de vehículos. Establecer el tipo, la complejidad y la clase de transformaciones requeridas por los datos a fin de satisfacer las necesidades del negocio. La evaluación de la calidad de los datos debe establecer un gap entre los niveles de calidad actuales y los deseados. Uno de los objetivos del plan de trabajo es la disminución de las brechas identificadas en el análisis. c. Identificar Datos y Reglas para el proceso de calidad Identificar y seleccionar las fuentes de datos internas y externas que serán utilizadas en el proceso de depuración y calidad de los datos de impuestos de vehículos de Cundinamarca. Identificar y documentar los tipos de reglas de decisión (validación, complementación, deduplicación, estandarización, etc.) que serán utilizadas en el proceso. d. Construir la Arquitectura de los Datos Crear un Modelo de Arquitectura para gestionar la calidad de los datos relacionados con el impuesto de vehículos de Cundinamarca. Este Modelo debe permitir la extracción, limpieza y transformación de los datos de las fuentes operacionales relacionadas con el impuesto de vehículos de Cundinamarca en un área temporal de calidad con la aplicación de un motor de reglas de decisión que permita gestionar dimensiones tales como la exactitud, consistencia, integridad, estructura y completitud de los datos del impuesto de vehículos. Crear y configurar las reglas de decisión que permitirán la gestión de la calidad de los datos relacionados con el impuesto de vehículos de Cundinamarca. Realizar la limpieza, transformación y enriquecimiento de los datos almacenados en el área temporal (Staging Área). Actualizar las fuentes de datos operacionales, una vez realizada la limpieza, transformación y enriquecimiento de los datos almacenados en el área temporal (Staging Área). Crear y/o actualizar el Repositorio Unificado de Información a partir de las reglas de decisión configuradas, permitiendo poblar los datos del mismo con la selección de los 7

18 mejores datos obtenidos en el proceso de limpieza, transformación y enriquecimiento de los datos. Generar y presentar informes de avance del proyecto con los indicadores resultantes del proceso de extracción, transformación y cargue de los datos de las fuentes operacionales y del Repositorio Unificado de Información. e. Evaluar los resultados y refinar el proceso Realizar una inspección selectiva de la exactitud, validez, consistencia, deduplicación y enriquecimiento de los datos transformados y cargados en las fuentes operacionales y en el Repositorio Unificado de Información. Determinar el cumplimiento de los objetivos del proceso de calidad de datos del impuesto de vehículos generando un Reporte consolidado que incluya las fuentes operacionales y el Repositorio Unificado de Información. Efectuar los ajustes que correspondan en el Modelo de Arquitectura y en los datos de las fuentes operacionales y del Repositorio Unificado de Información. f. Desplegar los Datos Los datos depurados, transformados y enriquecidos deben ser puestos a disposición de los usuarios en el repositorio unificado para ser explotados para la toma de decisiones de la organización. La revisión de los resultados obtenidos debe permitir realizar los ajustes que correspondan en un marco de mejora continua. Para cada uno de los procesos anteriores el proponente debe contar con metodologías propias para el adecuado desarrollo de las actividades. EL proyecto debe estar alineado a un marco de gestión de proyectos de acuerdo a la definición del PMI. Nota: Este documento no será objeto de evaluación. Esta documentación será verificada por el Supervisor del Contrato en el momento del inicio de la ejecución del proyecto con el propósito de realizar los respectivos ajustes para la entrega del Plan de Trabajo. Es necesario que el PROPONENTE explique en forma detallada la metodología de trabajo que seguirá para la prestación de los servicios objeto de esta Invitación. El PROPONENTE debe incluir como mínimo dentro de la metodología las siguientes etapas. Planeación 2. Análisis y Diagnóstico. 3. Depuración, Estructuración y Replicación de Datos. 8

19 Modelo de Arquitectura Colaboración e-business PORTAL 4. Diseño y ejecución de pruebas para replicación de datos en las fuentes. 5. Salida a Producción. 6. Monitoreo y Garantía Nota: Este documento no será objeto de evaluación. Esta documentación será verificada por el Supervisor del Contrato en el momento del inicio de la ejecución del proyecto con el propósito de realizar los respectivos ajustes para la entrega del Plan de Trabajo. 4. Modelo de Arquitectura y de Gestión de la Calidad de los Datos 4.. Enfoque de la gestión de la calidad de los datos El Modelo Conceptual de Arquitectura en el que se desarrollará toda la gestión de la calidad de los datos relacionados con el impuesto de vehículos de la Secretaría de Hacienda de Cundinamarca, tiene el siguiente enfoque: Fuentes de Datos Operacionales 2 Área de Calidad y Transformación de los Datos Motor 7 E Fuentes de Datos Operacionales con Calidad 8 Interoperabilidad 9 Despliegue 0 Trámites E 3 ERP Área Temporal 4 Impuestos 5 Repositorio de Reglas T Trámites ERP T Staging Area Q Impuestos Hoja de Vida de Vehículos L 6 Motor de Reglas L Hoja de Vida de Vehiculos REPOSITORIO UNIFICADO DE INFORMACIÓN P L ATAF O R MA D E S E R VI CI O S CO M P AR T I D A 4 Figura 3. Modelo Conceptual de Arquitectura para la gestión de la calidad de los datos. 9

20 Su descripción metodológica se presenta a continuación: Fuentes de Datos Operaci onales Las fuentes de datos operacionales corresponden a las Bases de Datos existentes en la Entidad, es decir Registro Trámites de Vehículos, Impuestos de Vehículos, Hojas de Vida de Vehículos, SIVC, Archivos Excel, Archivos Manuales y el ERP de SAP. Estas fuentes operacionales constituyen el core del proyecto de calidad de datos de la Organización. ETL 2 Son las técnicas y herramientas que permitirán la Extracción de los Datos de las fuentes operacionales de la Entidad, su limpieza y transformación al igual que su cargue inicial en un área temporal de calidad. Area Temporal 3 Es posible extraer los datos de las fuentes operacionales y descargarlos en un área temporal (intermedia) con una estructura que permita la aplicación de las reglas de limpieza y transformación de los datos de entrada, incluyendo la utilización de las distintas fuentes (internas, externas, sustitutas, masivas). Repositorio de Reglas 4 En este repositorio se almacenarán todas las reglas funcionales, técnicas, de dominio y demás reglas generadas. Además deben incluirse aquellas reglas que ha desarrollado el Contratista para llevar a cabo el proyecto de calidad de datos. Al cabo del mismo este Repositorio quedará en poder de la Entidad. Es un Área que permite realizar funciones como: Staging Area 5 Recibir los datos extraídos del área temporal una vez depurados Facilitar la extracción de los datos desde las fuentes operacionales del negocio Permitir realizar la limpieza de los datos Mejorar la calidad de los datos Proveer la integración con el repositorio de reglas del negocio a ser utilizadas en el proceso de calidad de datos. 20