FRAMEWORK PARA EL DESARROLLO DE ARQUITECTURAS DE
INFORMACION EN UN CONTEXTO DE ARQUITECTURA
EMPRESARIAL
NIXON ALONSO DUARTE ACOSTA
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERIA, DEPARTAMENTO DE INGENIERIA DE
SISTEMAS Y COMPUTACION
MAESTRIA EN INGENIERIA DE SISTEMAS Y COMPUTACION
BOGOTA, DC
JULIO 2012
FRAMEWORK PARA EL DESARROLLO DE ARQUITECTURAS DE
INFORMACION EN UN CONTEXTO DE ARQUITECTURA EMPRESARIAL
NIXON ALONSO DUARTE ACOSTA
Documento de tesis presentado como requisito parcial para el grado de:
MAESTRIA EN INGENIERIA DE SISTEMAS Y COMPUTACION
Director: Profesor Asociado, PhD. José Abasolo
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERIA, DEPARTAMENTO DE INGENIERIA DE
SISTEMAS Y COMPUTACION
MAESTRIA EN INGENIERIA DE SISTEMAS Y COMPUTACION
BOGOTA, DC
JULIO 2012
AGRADECIMIENTOS
A Dios y María santísima que me permitieron realizar este estudio de maestría.
A mi esposa Yenny, mis hijos Verónica y Samuel que son mi inspiración, y por
brindarme su apoyo, tolerancia y comprensión durante largas horas de estudio.
Al PhD. José Abasolo, por su confianza y asesoría durante el desarrollo de este
interesante e importante tema.
TABLA DE CONTENIDO
1. INTRODUCCION ..................................................................................... 12
1.1 Justificación ........................................................................................... 14
1.2 Objetivo general ..................................................................................... 15
1.3 Objetivos específicos ............................................................................ 15
1.4 Alcance ................................................................................................... 16
1.5 Estructura del documento..................................................................... 17
2. ESTADO DEL ARTE ............................................................................... 19
2.1 Enfoques de arquitectura empresarial ................................................. 19
2.1.1 Zachman .......................................................................................... 20
2.1.1.1 Las perspectivas ......................................................................... 21
2.1.1.2 Las dimensiones ......................................................................... 22
2.1.1.3 Zachman y la arquitectura de datos ............................................ 23
2.1.2 Framework de arquitectura empresarial federal ........................... 24
2.1.3 TOGAF (The Open Group Architecture Framework) ..................... 30
2.1.3.1 El Ciclo ADM............................................................................... 31
2.1.3.2 Alcance ....................................................................................... 36
2.1.3.3 División de Arquitecturas ............................................................ 39
2.1.3.4 Principios de Datos ..................................................................... 40
2.1.3.5 TOGAF y La Arquitectura de Datos ............................................ 41
2.1.4 Arquitectura de información empresarial según [1] ..................... 44
2.1.4.1 Principios de arquitectura de información ................................... 45
2.1.4.2 Dominios de datos ...................................................................... 45
2.1.4.3 AIE y la arquitectura de datos ..................................................... 60
2.1.5 Análisis ............................................................................................ 61
2.2 GOBIERNO DE DATOS .......................................................................... 63
2.2.1 Diseñando gobierno de datos por Vijay Khatri y Carol V. Brown 63
2.2.1.1 Principios de datos ..................................................................... 65
2.2.1.2 Calidad de los datos ................................................................... 65
2.2.1.3 Metadatos ................................................................................... 65
2.2.1.4 Acceso a Datos ........................................................................... 66
2.2.1.5 Ciclo de Vida de los Datos .......................................................... 66
2.2.2 El proceso unificado de gobierno de datos de IBM ...................... 66
2.2.3 Gobierno de datos: ¿Qué funciona y que no? por Rob Karel ...... 72
2.2.3.1 Catalizadores de Gobierno de Datos .......................................... 73
2.2.3.2 Framework de gobierno de datos................................................ 73
2.2.3.3 Inhibidores de la Adopción de un Gobierno de Datos ................. 73
2.2.3.4 Preparación del gobierno de datos ............................................. 74
2.2.3.5 Diseñe el gobierno basado en la cultura de la empresa .............. 74
2.2.4 Análisis ............................................................................................ 76
3. FRAMEWORK DE ARQUITECTURA DE INFORMACION EN UN
CONTEXTO DE ARQUITECTURA EMPRESARIAL (FAI) ................................... 78
3.1 Elementos estructurales del framework .............................................. 80
3.1.1 Repositorio de recursos ................................................................. 81
3.1.2 Metodologías ................................................................................... 83
3.1.3 Repositorio de arquitectura ............................................................ 83
3.2 Metodologías ......................................................................................... 84
3.2.1 Guía Metodológica para el proyecto inicial ................................... 84
3.2.1.1 Elementos estructurales ............................................................. 85
3.2.1.2 Desarrollo metodológico ............................................................. 86
3.2.2 Guía metodológica para gobierno de datos ................................ 127
3.2.2.1 Preparación .............................................................................. 129
3.2.2.2 Diseño ...................................................................................... 129
3.2.2.3 Evaluación de Madurez ............................................................ 130
3.2.2.4 Mapa de proyectos ................................................................... 131
3.2.2.5 Modelo Organizacional ............................................................. 131
3.2.2.6 Definir Métricas ......................................................................... 132
3.2.2.7 Gobierno de datos maestros ..................................................... 133
3.2.2.8 Gobierno de análisis ................................................................. 133
3.2.2.9 Gestionar la seguridad y privacidad .......................................... 133
3.2.2.10 Medir Resultados ...................................................................... 134
4 APLICACIÓN DE LA GUIA METODOLOGICA PARA EL PROYECTO
INICIAL DE ARQUITECTURA DE INFORMACION EN LA ADMINISTRADORA
COLOMBIANA DE PENSIONES COLPENSIONES .......................................... 135
4.1 ETAPA 1: PREPARACION ................................................................... 136
4.1.1 Conociendo la organización - COLPENSIONES.......................... 136
4.1.2 Grupos de apoyo ........................................................................... 146
4.1.3 Modelos de referencia .................................................................. 147
4.1.4 Alcance de la arquitectura de información.................................. 147
4.1.5 Herramientas y técnicas ............................................................... 148
4.2 ESTADO ACTUAL DE ARQUITECTURA DE INFORMACION ............. 148
4.2.1 Entrevistas ..................................................................................... 149
4.2.2 Entidades de negocio ................................................................... 149
4.2.3 Modelo conceptual ........................................................................ 156
4.2.4 Análisis del estado actual de la AI ............................................... 157
4.2.4.1 Análisis de fuentes de datos ..................................................... 157
4.2.4.2 Gobierno de datos .................................................................... 174
4.2.4.3 Análisis de la Información ......................................................... 176
4.3 ESTADO DESEADO DE ARQUITECTURA DE INFORMACION .......... 240
4.3.1 Blueprint de arquitectura de información.................................... 241
4.4 MAPA DE PROYECTOS ....................................................................... 256
4.4.1 Definición de proyectos ................................................................ 256
4.4.2 Priorización de proyectos ............................................................. 258
5 CONCLUSIONES Y TRABAJO FUTURO ............................................. 260
5.1 CONCLUSIONES DEL TRABAJO REALIZADO .................................. 260
5.2 TRABAJO FUTURO ............................................................................. 262
6 BIBLIOGRAFIA ..................................................................................... 263
ANEXOS ............................................................................................................ 267
TABLA DE PLANTILLAS
Plantilla 1. Procesos vs Entidades ...................................................................... 104
Plantilla 2. Descripción de una entidad de negocio [23] ...................................... 107
Plantilla 3. Inventario de Fuentes de Datos [23] .................................................. 109
Plantilla 4.Entidades de Negocio vs Fuentes de Datos [23] ................................ 110
Plantilla 5. Estado actual de gobierno de datos .................................................. 112
Plantilla 6. Matriz de consolidación de brecha, soluciones dependencias [16] ... 124
Plantilla 7. Definición incremental de arquitectura [16] ....................................... 125
Plantilla 8. Descripción de hallazgo [23] .............................................................. 275
Plantilla 9. Indicadores de calidad de datos [23] ................................................. 275
Plantilla 10. Mediciones de los indicadores de calidad [23] ................................. 276
Plantilla 11. Calculo de Indicadores [23] ............................................................. 277
Plantilla 12. Diagnóstico de calidad [23] .............................................................. 277
TABLA DE FIGURAS
Figura 1. Marco de Referencia de Zachman ......................................................... 21
Figura 2. DRM Áreas de estandarización [35] ....................................................... 27
Figura 3. Contexto de los datos [34] ..................................................................... 28
Figura 4. Descripción de los datos [34] ................................................................. 28
Figura 5. Compartir Datos [34] .............................................................................. 29
Figura 6. Marco de implementación de DRM ....................................................... 29
Figura 7. Arquitectura Empresarial según TOGAF [14] ......................................... 30
Figura 8. El ciclo ADM [16] ................................................................................... 32
Figura 9. Desarrollo incremental de la arquitectura [16] ........................................ 38
Figura 10. Dominios de datos [1] .......................................................................... 46
Figura 11. Modelo de madurez de metadatos [1] .................................................. 47
Figura 12. Representación de la misma persona en diferentes contextos de
aplicación [21] ....................................................................................................... 54
Figura 13. Sistema central de datos maestros [21] ............................................... 56
Figura 14. Sistema maestro principal [21] ............................................................. 57
Figura 15. Repositorio principal ............................................................................ 58
Figura 16. Visión general del proceso unificado de gobierno de datos de IBM ..... 67
Figura 17. Roles y responsabilidades [22] ........................................................... 73
Figura 18. Dimensiones de AE y sus relaciones [27] ............................................ 78
Figura 19. Elementos estructurales del framework de AI ...................................... 80
Figura 20. Repositorio de recursos de AI .............................................................. 82
Figura 21. Metodologías para Proyectos de AI ..................................................... 83
Figura 22. Elementos Estructurales Metodología Proyecto Inicial ......................... 85
Figura 23. Etapa de preparación de la metodología del proyecto inicial................ 86
Figura 24. Actividades en la etapa de preparación ............................................... 87
Figura 25. Grupos de trabajo ................................................................................ 88
Figura 26. Modelo para definir el alcance de la AI ................................................ 92
Figura 27. Dominios de Datos Empresariales ....................................................... 94
Figura 28. Gobierno de Datos Modelo de Referencia ........................................... 95
Figura 29. Etapa de Estado Actual de la metodología del proyecto inicial ............ 99
Figura 30. Actividades de la etapa de Estado Actual .......................................... 100
Figura 31 Modelo Conceptual nivel 0 [23] ........................................................... 105
Figura 32. Actividades del Análisis de Estado Actual de AI................................. 113
Figura 33. Método para análisis de calidad de datos .......................................... 115
Figura 34. Actividades en la etapa de Estado Deseado de AI ............................. 120
Figura 35. Blueprint de Arquitectura de Datos .................................................... 121
Figura 36. Etapa de Mapa de Proyectos en la metodología de proyecto inicial... 123
Figura 37. Actividades de la etapa de Mapa de Proyectos................................. 123
Figura 38. Técnica de evaluación del valor de negocio [16] ................................ 126
Figura 39. Guía Metodológica para Diseño de un Gobierno de Datos ................ 128
Figura 40. Blueprint de AI para Colpensiones .................................................... 242
Figura 41. Estado deseado de los Datos Maestros ............................................. 247
Figura 42. Grafica de evaluación del Riesgo vs Beneficio .................................. 259
LISTA DE TABLAS
Tabla 1. Evaluación de criterios por cada uno de los enfoques de AE .................. 62
Tabla 2. Dominios de decisión para gobierno de datos [18] .................................. 64
Tabla 3. Framework para los dominios de decisión de datos ................................ 64
Tabla 4.Evaluación de criterios por cada uno de las propuestas de gobierno de
datos..................................................................................................................... 77
Tabla 5. Inventario inicial de fuentes de datos .................................................... 165
Tabla 6. Lista de las 16 fuentes de datos más importantes ................................ 167
Tabla 7. Otras fuentes de datos .......................................................................... 168
Tabla 8. Entidades de Negocio vs Fuentes de Datos .......................................... 170
Tabla 9. Matriz de consolidación de brecha, soluciones y dependencia. ............ 257
Tabla 10. Valores de evaluación del Riesgo vs Beneficio ................................... 259
12
1. INTRODUCCION
En un contexto empresarial, la Arquitectura de Información debe organizar,
gestionar y gobernar la totalidad de los datos. Pero esto es un tema bastante
complejo que se plantea en este trabajo desde dos perspectivas: la primera tiene
que ver con la variedad existente de recursos que se deben considerar en un
proyecto de Arquitectura de Información (en adelante AI). La segunda perspectiva
aborda la complejidad que genera el organizar, gestionar y gobernar grandes
volúmenes de información con su diversidad en usos y también su variedad de
formatos en los que esta se puede encontrar almacenada.
Algunos de los recursos con los que se cuenta actualmente para el desarrollo de
una AI abordan temas como técnicas de integración de datos, enfoques
arquitecturales para gestión de datos maestros (MDM por sus siglas en ingles),
propuestas para gobierno de datos, marcos de arquitectura empresarial, aspectos
de seguridad, calidad de datos, fuentes de datos, principios de datos,
herramientas tecnológicas, técnicas de modelado de datos, dimensiones de
calidad de datos, entre otros. Los marcos de Arquitectura Empresarial (en
adelante AE), consideran algunos de los recursos mencionados dentro de sus
propuestas (cada una diferente entre sí), desde un enfoque genérico que no
describe cómo se deben orquestar e implementar estos recursos de forma
organizada.
La variedad de usos y el volumen de información en los contextos empresariales
han crecido considerablemente en los últimos años. Esto porque las empresas
actuales trabajan en línea a nivel mundial y acumulan enormes volúmenes de
información principalmente sobre sus productos, servicios, sus clientes y sus
comportamientos. Adicionalmente, las empresas suman a su entorno información
no tradicional proveniente de redes sociales, multimedia, fuentes de datos
13
heterogéneas y muchas de estas fuentes son desestructuradas. En consecuencia
la complejidad de la información es bastante significativa y las empresas deben
buscar mecanismos que les permitan organizar, gestionar y gobernar la
información como un activo más de la empresa y que pueda ser utilizada como un
insumo que apalanque las estrategias de negocio.
En este trabajo se presenta un Framework para el Desarrollo de Arquitecturas de
Información en un Contexto de Arquitectura Empresarial (en adelante FAI), con el
fin de mitigar las problemáticas antes mencionadas. También con el ánimo de
disminuir el vacío existente en los frameworks de AE para el tema de AI, en lo que
respecta a guías metodológicas y modelos de referencia que faciliten las labores
de organizar, gestionar y gobernar la información. El FAI toma elementos
principalmente de varios Frameworks de Arquitectura Empresarial y de propuestas
de gobierno de datos, para extenderlos y/o adaptarlos a las necesidades
requeridas en proyectos de AI.
El FAI, propone conceptualmente tres elementos estructurales que son el
repositorio de recursos, metodologías y un repositorio de arquitectura de
información.
El repositorio de recursos, en este trabajo se centra principalmente en la
propuesta de modelos de referencia para gobierno de datos, dominios de datos y
alcance de la AI. También se describe un método para la calidad de los datos y se
propone una serie de plantillas como un medio para documentar cada una de las
actividades de acuerdo a la guía metodológica. El modelo de referencia para
gobierno de datos propone los temas principales que se deben considerar en el
desarrollo de AI. Para dominio de datos se propone un enfoque segmentado,
donde para disminuir la complejidad de uso de la información se propone dividir
los datos empresariales en los 5 dominios de datos propuesto en [1]. Para la
definición del alcance de la AI, también se propone un enfoque segmentado y
centrado principalmente en los datos operacionales y analíticos. Se toma como
14
base específicamente los datos operacionales y analíticos, porque se considera
que los metadatos y los datos maestros, aunque se trabajan de forma
independiente, intervienen directamente y son considerados de forma implícita.
En las metodologías se proponen tres guías metodológicas para el desarrollo de
AI, a saber: guía metodológica para el proyecto inicial, para proyectos particulares
y para el gobierno de datos. En la guía metodológica para el proyecto inicial se
proponen cuatro etapas, empezando por la etapa de preparación donde se debe
entender el contexto donde se desarrollara la AI, luego se debe entender el estado
actual de los datos, posteriormente se deben entender las necesidades del
negocio y proponer el estado deseado de los datos, y por último se deben
identificar, priorizar y proponer la ruta de ejecución de los proyectos que ayudaran
a superar la brecha entre el estado actual y el estado deseado.
Este trabajo se enfoca en los datos operacionales, porque fue donde se
identificaron los principales vacíos y por ende problemáticas al momento del
desarrollo de una AI. Los datos analíticos no se consideran en este trabajo, porque
ya existe una metodología completa y bien detallada propuesta por Ralph Kimball
que ya aborda este tema. Los proyectos de datos analíticos se pueden llevar a
cabo independiente del estado de los datos operacionales aunque éstos sean un
completo caos, pero la complejidad de las técnicas de integración es considerable.
Pero, si los datos operacionales son organizados, gestionados y gobernados
adecuadamente, el desarrollo de los proyectos de datos analíticos serán menos
complejos y las técnicas de integración de datos serán relativamente sencillas.
1.1 Justificación
Las necesidades de hoy exigen a las empresas flexibilidad de adaptación,
operación eficiente para disminuir sus costos, heterogeneidad, operación
orientada a los clientes, información precisa y oportuna que le permita hacer
15
monitoreo constante, poder de prevención o reacción en tiempo real, manejo de
indicadores de negocio y evolución en el tiempo. Pero actualmente las empresas
sufren operacional y financieramente por tener silos de negocios soportados por
componentes tecnológicos aislados, generando un alto costo de operación,
integración y estandarización. En consecuencia difícilmente se puede contar con
información actualizada y consolidada que muestre la operación diaria del
negocio. Estos problemas, son generados porque el negocio e IT no tienen o no
comparten la misma visión del negocio y no trabajan en la misma dirección.
Con la propuesta del FAI se busca resolver los problemas operacionales que
presentan actualmente las empresas, por no organizar y gestionar
adecuadamente la información de forma tal que sea un activo más que apoye
adecuadamente las estrategias de negocio.
1.2 Objetivo general
Desarrollar un framework para el desarrollo de arquitecturas de información en un
contexto de arquitectura empresarial.
1.3 Objetivos específicos
Para responder al objetivo general del proyecto se deben cumplir los siguientes
objetivos específicos:
Identificar fortalezas y debilidades desde el punto de vista de la AI de los
frameworks de arquitectura empresarial más utilizados empresarialmente.
Identificar fortalezas y debilidades de las propuestas de gobierno de datos más
representativas y utilizadas por las organizaciones.
Hacer una propuesta para el framework de arquitectura de información que
integre las fortalezas de los frameworks de arquitectura empresarial.
16
Hacer una propuesta de guías metodológicas que faciliten el desarrollo de
arquitecturas de información en un contexto de arquitectura empresarial en su
fase inicial.
Hacer una propuesta de modelos de referencia y plantillas que apoyen el
desarrollo de las guías metodológicas.
1.4 Alcance
Este trabajo de investigación propone un framework para el desarrollo de
arquitecturas de información en un contexto de arquitectura empresarial. El
framework consta estructuralmente de 3 componentes conceptuales, donde el
primer componente es el repositorio de recursos de AI, el segundo las
metodologías y el tercero el repositorio de arquitectura.
En el repositorio de recursos de AI, para el alcance de este trabajo se proponen
modelos de referencia para dominios de datos, gobierno de datos, alcance de la AI
y una serie de plantillas como herramientas para organizar la información
capturada durante el desarrollo de la AI.
Se proponen tres guías metodológicas, una para el proyecto inicial, otra para
proyectos particulares y una tercera para el gobierno de datos. Como parte de
este trabajo solo se propone, desarrolla y valida con un caso de estudio la guía
metodológica para el proyecto inicial de AI. La guía metodológica para proyectos
particulares no se encuentra dentro del alcance y la guía para gobierno de datos
solo se realiza la propuesta.
La aplicación se hará en la Administradora Colombiana de Pensiones
COLPENSIONES, la cual es una empresa del sector público, donde se aplicara la
guía metodológica para el proyecto inicial de la AI. La información utilizada para
ilustrar la aplicación de la propuesta, fue tomada del proyecto desarrollado por el
17
CIFI 1 de la Universidad de los Andes, para la Administradora Colombiana de
Pensiones COLPENSIONES. En este proyecto participo un grupo de profesionales
que crearon una serie de documentos, pero principalmente se utiliza aquí la
información de los documentos [23] y [31]. El documento [31] corresponde a un
estudio previo de COLPENSIONES realizado por el Grupo de la Protección Social.
El repositorio de arquitectura, donde se deben organizar y gestionar los artefactos
generados durante el desarrollo de la AI, no se encuentra en el alcance de este
trabajo.
1.5 Estructura del documento
Los siguientes capítulos de este documento se estructuran como se describe a
continuación:
En el capítulo 2 se presenta el análisis del estado del arte que sustenta la creación
del FAI. A través de este capítulo se presentan dos análisis: en el primer análisis
se realiza una revisión de los framework de arquitectura empresarial y en el
segundo análisis se lleva a cabo una revisión de varias propuestas en el tema de
gobierno de datos.
En el capítulo 3 se presenta el Framework de Arquitectura de Información en un
contexto de Arquitectura Empresarial (FAI). En este capítulo se presentan los
elementos estructurales del framework y se describen tres metodologías que son
los componentes principales de este framework. La primera metodología trata del
primer proyecto que se debe realizar en todo trabajo de AI, la segunda
metodología trata los aspectos de los proyectos particulares que son el resultado
del primer proyecto y la tercera metodología cubre el tema de gobierno de datos.
1 Centro de Estudios e Investigación de la Facultad de Ingeniería
18
En el capítulo 4 se presenta un caso de estudio donde se ilustra la aplica del FAI
con información tomada del proyecto desarrollado por el CIFI de la Universidad de
los Andes, para la Administradora Colombiana de Pensiones COLPENSIONES.
En el capítulo 5 se presentan las conclusiones y se definen los trabajos futuros
para continuar con el desarrollo del FAI en los aspectos que no fueron
desarrollados completamente.
19
2. ESTADO DEL ARTE
El estado del arte se aborda desde dos perspectivas. La primera desde la
Arquitectura Empresarial enfatizando en lo que ofrecen específicamente en el área
de Arquitectura de Datos y la segunda desde el Gobierno de Datos.
En la primera parte se estudian tres enfoques de Arquitectura Empresarial:
TOGAF, Zachman y la propuesta descrita en [1]. También se realiza un análisis
comparativo de estos tres enfoques.
En la segunda parte se aborda el tema de Gobierno de Datos desde tres
perspectivas: Diseñando gobierno de datos por Vijay Khatri y Carol V. Brown, el
Proceso unificado de gobierno de datos de IBM y Gobierno de datos ¿Qué
funciona y que no? por Rob Karel. También se realiza un análisis respectivo de las
tres propuestas.
2.1 Enfoques de arquitectura empresarial
Desde que se publicó el primer artículo en 1987 por J.A. Zachman según [1] se
han publicado o surgido varias metodologías, entre las más reconocidas se
encuentran:
The Open Group Architectural Framework (TOGAF)
The Zachman Framework for Enterprise Architectures (Zachman)
The Federal Enterprise Architecture (FEA)
The Gartner Methodology (formerly Meta Framework)
Para el estudio del estado del arte se tomaran como referencia las tres primeras
propuestas y adicionalmente la propuesta descrita en [1]. Para el alcance de este
20
trabajo solo se analizara la propuesta de cada uno de los enfoques, desde la
perspectiva que cada uno propone para el tema de Arquitectura de Datos.
Ninguna de estas propuestas metodológicas son realmente completas y cada una
tiene una fortaleza diferente a las otras. Otro aspecto a destacar es que estas
propuestas metodológicas son realmente vistas como frameworks de arquitectura
con propuestas macros y no llegan al nivel de explicar metodológicamente con el
nivel de detalle necesario de cómo desarrollar un proyecto de arquitectura de
datos en un contexto de arquitectura empresarial. En la práctica una empresa
necesitaría un complemento de cada una para llevar a cabo un proyecto de
arquitectura de datos, además de la experiencia de los arquitectos empresariales y
de datos. Por estas razones se tomaran las fortalezas de las cuatro propuestas
seleccionadas y adicionalmente se extenderá con el objeto de proponer una
metodología mejorada.
2.1.1 Zachman
Según la propia descripción de John Zachman este enfoque se considera una
taxonomía y no una metodología ni un framework, donde su definición es:
“Una estructura lógica para clasificar y organizar las representaciones descriptivas
de una Empresa, las cuales son especialmente significativas tanto para la
dirección y control de la organización como para el desarrollo de sus sistemas” [4].
Como puede observarse en la Figura 1, el marco de referencia es una matriz de 6
filas (la sexta fila es la empresa en operación) por 6 columnas, donde cada tipo de
artefacto es caracterizado por una celda, la que a su vez es resultado del cruce de
una fila y de una columna. Cada fila representa una perspectiva o vista de cierto
rol participante en la empresa (ejecutivo, negocio, diseñador, constructor,
programador y usuario), la cual es combinada con seis dimensiones expresadas
21
en forma de interrogantes (¿Qué?, ¿Cómo?, ¿Dónde?, ¿Quién?, ¿Cuándo? y
¿Por qué?).
Figura 1. Marco de Referencia de Zachman2
2.1.1.1 Las perspectivas
El Ejecutivo se ocupa del contexto de la empresa, de su entorno competitivo, de
las fuerzas internas y externas que influyen en su competitividad, del
posicionamiento de sus productos y servicios, que lo obligan a especificar sus
alcances a largo plazo; esta perspectiva cubre los componentes del nivel
2 Tomado de http://www.zachman.com/
22
estratégico. El Negocio se interesa en la operación de la empresa, para lo cual
requiere del modelado de la empresa mediante modelos de procesos, de flujos de
trabajo, de logística empresarial, de modelos semánticos y de planes de negocio
que le permitan controlar la operación de la empresa; esta perspectiva se centra
en el proceso de negocio, por lo que constituye en buena medida el nivel de
procesos. El Diseñador o Arquitecto tiene que ver con la especificación de los
planos conceptuales de los sistemas de información que se requieren para
soportar la operación de los procesos. El Constructor o Ingeniero se encarga del
ensamblado y fabricación de los diversos componentes de los sistemas de
información de acuerdo con las restricciones de la tecnología utilizada. El
Programador trabaja en la fabricación de los componentes de acuerdo con las
especificaciones del constructor. Las perspectivas del diseñador, constructor y
programador se ubican claramente en el nivel de sistemas de información [13].
2.1.1.2 Las dimensiones
El Dato responde a la interrogante ¿Qué?, para la perspectiva de nivel ejecutivo
se refiere a la lista de cosas importantes para el negocio como clientes,
proveedores, productos, servicios, contratos, facturas, etc.; conforme se va
descendiendo a las perspectivas inferiores se van teniendo diferentes
descripciones relacionadas con la visión particular de cada perspectiva: desde la
gestión del negocio se ven las cosas como entidades representadas en un modelo
conceptual que caracteriza el negocio, pero al diseñador le interesa un modelo
lógico que pueda conducir a una base de datos para su almacenamiento
correspondiente, lo que la visión del constructor transforma en un modelo físico
como una tabla de base de datos, que para el programador será una entidad de
almacenamiento como un archivo o un registro. La Función se ocupa de la
pregunta ¿Cómo?, cubriendo desde la lista de procesos esenciales del negocio
(perspectiva del planeador), su modelado correspondiente (dueño), hasta la
23
especificación de los programas (programador) asociados a la funcionalidad de
negocio. La Ubicación representa el ¿Dónde?, reflejando desde la lista de las
localidades donde se ubica el negocio (perspectiva del planeador), su modelado
logístico (dueño), hasta la configuración de las direcciones de red (programador).
La Persona tiene que ver con el ¿Quién?, considerando la lista de unidades
organizacionales importantes para el negocio (planeador), su modelo de flujo de
trabajo (dueño), hasta la especificación de las restricciones de seguridad
(programadores y usuarios). El Tiempo captura el ¿Cuándo?, incluyendo desde la
lista de eventos importantes para el negocio (planeador), su modelo de planeación
operacional (dueño), hasta la especificación de temporizadores (programador). La
Motivación explica la interrogante ¿Por qué?, abarcando desde la lista de objetivos
y metas (planeador), su plan de negocio para operar la empresa (dueño), hasta la
especificación de las reglas de negocio correspondientes (programador). [13]
2.1.1.3 Zachman y la arquitectura de datos
El framework de Zachman es considerado como una meta modelo que define una
estructura para clasificar y organizar una serie de artefactos que describen la
empresa. En consecuencia no contempla aspectos de como iniciar un proyecto de
arquitectura de datos, ni mucho menos cuales son las etapas a seguir.
A nivel de datos define la dimensión Datos que corresponde al interrogante
¿Qué?, y a través de las perspectivas, identifica una serie de artefactos,
empezando por la definición del contexto del negocio, seguido por el
modelamiento del contexto, identificación las entidades de negocio y describiendo
como se relacionan entre sí con la ayuda de un modelo conceptual.
Posteriormente se especifica la necesidad de un modelo físico de datos que
después será transformado en la implementación de una fuente de datos.
24
Como se puede observar, este enfoque provee una estructura donde define una
serie de entregables, pero carece de un proceso de transformación y ejecución de
un proyecto de arquitectura de datos en un contexto de arquitectura empresarial.
2.1.2 Framework de arquitectura empresarial federal
El Framework de Arquitectura Empresarial Federal (FEAF por sus siglas en inglés)
proporciona un estándar para el desarrollo y documentación de las descripciones
de la arquitectura de áreas de alta prioridad. Este provee una guía para la
descripción de las arquitecturas de segmentos funcionales de múltiples
organizaciones del gobierno federal.
La Arquitectura Empresarial Federal es una base de información de valor
estratégico que define el negocio, la información necesaria para operar el negocio,
las tecnologías necesarias para apoyar las operaciones del negocio y los procesos
de transición para la aplicación de las nuevas tecnologías en respuesta a las
necesidades cambiantes del negocio.
El CIO Council3 propuso tres enfoques para FEAF4:
Enfoque convencional: este enfoque requiere de un gran esfuerzo en tiempo y
dinero, porque se aborda el problema global para toda la federación. Este
enfoque puede presentar problemas como parálisis por el análisis a
consecuencia de la complejidad del esfuerzo federal.
Enfoque por segmentos: Promueve el desarrollo incremental de los segmentos
de la arquitectura dentro de un marco de arquitectura empresarial estructurada.
Este enfoque se centra en grandes áreas de negocio y es más probable que
tenga éxito, porque el esfuerzo se limita a funciones comunes o empresas
específicas.
3 Chief Information Officer Council
4 Federal Enterprise Architecture Framework
25
Enfoque de Status Quo: Este enfoque representa el funcionamiento normal del
negocio tras el fracaso continuo del esfuerzo por compartir información y poder
hacer frente a la rápida evolución del entorno. Este enfoque daría lugar a
reproceso de negocios, disminución de la productividad y la pérdida de
oportunidades.
FEAF consta de ocho componentes necesarios para el desarrollo y mantenimiento
de la Arquitectura Empresarial Federal según el CIO Council. A continuación se
realiza una descripción general sobre cada uno de estos ocho componentes según
[33]:
Motivadores de Arquitectura: Representa dos tipos de estímulos externos para
la AE, el primero, corresponde a los motivadores de negocio que pueden ser
nueva legislación, fuerzas del mercado, nuevas iniciativas de administración. El
segundo estimulo externo, hace referencia a los motivadores de diseño, lo cual
incluye nuevo y mejoras en el software y hardware.
Dirección Estratégica: guía el desarrollo de la AE deseada y consta de una
visión, principios, metas y objetivos.
Arquitectura Actual: define la situación actual de la AE y está compuesta de
dos partes: la situación actual para el negocio y el diseño de arquitectura que
consta de datos, aplicación y tecnología.
Arquitectura Objetivo: define la situación deseada de la AE y también está
compuesta de dos partes: la situación deseada para el negocio y el diseño de
arquitectura que consta de datos, aplicaciones y tecnología.
Procesos de Transición: soporta la migración de la situación actual a la
situación deseada de la AE. Esto incluye capital IT, planificación de
inversiones, plan de migración, gestión de la configuración y gestión del
cambio.
Segmentos de Arquitectura: un segmento es considerado como una empresa
dentro de la empresa federada. Los segmentos son áreas de negocio
transversales como por ejemplo las compras a través de comercio electrónico.
26
Modelos Arquitectónicos: define los modelos de negocio y diseño que
describen los componentes de los segmentos de la empresa.
Estándares: este se refiere a todos los estándares o normas, directrices y
mejores prácticas.
La arquitectura empresarial federal, consta de cinco modelos de referencia
relacionados entre sí, diseñados para facilitar el análisis y la identificación de
inversiones duplicadas, las carencias y colaboraciones entre las agencias [35].los
cinco modelos de referencia son:
Modelo de referencia del rendimiento (PRM por sus siglas en ingles).
Modelo de referencia del negocio (BRM por sus siglas en ingles).
Modelo de referencia de componentes de servicio (SRM por sus siglas en
ingles).
Modelo de referencia técnico (TRM por sus siglas en ingles).
Modelo de referencia de datos(DRM por sus siglas en ingles).
2.1.2.1 Modelo de Referencia de Datos (DRM)
El DRM es un marco de trabajo flexible basado en estándares que permiten el
intercambio de información y la reutilización para todo el gobierno federal, a través
de la descripción y descubrimiento estándar de datos comunes y la promoción de
prácticas de gestión de datos uniformes [35].
El DRM proporciona un medio estándar a través del cual los datos se pueden
describir, clasificar y compartir (ver Figura 2).
El marco de implementación de DRM se presenta en la Figura 6. Este marco
proporciona un mapa de ruta para ser utilizado por arquitectos empresariales y
arquitectos de datos para guiar sus esfuerzos en el intercambio de datos dentro de
27
las comunidades de interés. El mapa de ruta se basa en las siguientes
afirmaciones básicas [34]:
Figura 2. DRM Áreas de estandarización [35]
El Contexto de los Datos es un área de estandarización de los datos en DRM. Una
comunidad de interés, debe ponerse de acuerdo sobre los datos necesarios para
satisfacer sus necesidades de negocio de misión compartida. Una comunidad de
interés debe ser capaz de responder preguntas básicas acerca de los activos de
datos que administra: ¿Cuáles son los datos que necesita?, ¿Quién es
responsable de mantener los datos?, ¿Cuál es la vinculación con el modelo de
referencia del negocio?, ¿Qué servicios están disponibles para acceder a los
datos?, ¿Cuáles son las fuentes de datos donde se almacenan los datos? [34].
La Descripción de los Datos es un área de estandarización de los datos en DRM,
donde una comunidad de interés debe ponerse de acuerdo en el significado y la
estructura de los datos que necesita, con el fin de utilizar eficazmente los datos.
28
Figura 3. Contexto de los datos [34]
Figura 4. Descripción de los datos [34]
Compartir Datos es un área de estandarización de los datos en DRM, donde se
proporciona una guía para los tipos de servicios que deben ser provisionados en
una comunidad de interés para que el intercambio de información sea posible.
29
Figura 5. Compartir Datos [34]
Figura 6. Marco de implementación de DRM
30
2.1.3 TOGAF (The Open Group Architecture Framework)
Es un frameworks de AE elaborado y aprobado por los miembros del Foro de
Arquitectura The Open Group. Está basado en el Framework de Arquitectura
Técnica para la Gestión de la Información (TAFIM5 por sus siglas en inglés) del
departamento de defensa de los Estados Unidos de América.
Actualmente se encuentra en la versión 9.1. TOGAF es un método detallado y un
conjunto de recursos de apoyo para el desarrollo de una AE. Es uno de los
frameworks de AE mas difundidos debido a que cuenta con una buena cantidad
de información disponible y de acceso público. Este divide la organización en 4
dominios de arquitectura (ver Figura 7): Arquitectura de Negocio, Arquitectura de
Aplicaciones, Arquitectura de Datos y Arquitectura de Tecnología [16].
Figura 7. Arquitectura Empresarial según TOGAF [14]
TOGAF se describe como un framework, pero la parte más importante de TOGAF
es el Architecture Development Method, más conocido como ADM. ADM es como
una receta para la creación de una arquitectura. Una receta puede ser calificada
como un proceso. Dado que ADM es la parte más visible de TOGAF, podemos
5 Technical Architecture Framework for Information Management
31
clasificar a TOGAF como un proceso arquitectónico en lugar de framework, o una
metodología, ya que describe un proceso bien definido como ADM.
TOGAF visto como un proceso arquitectónico, complementa a Zachman;
recordemos, que es una taxonomía de arquitectura. Zachman indica la forma de
clasificar los artefactos. TOGAF le da un proceso de creación de ellos.
La versión 9 de TOGAF cuenta con 6 partes principales [16]:
ADM (Architecture Development Method): Describe 10 fases genéricas para el
desarrollo de una AE.
Directrices y Técnicas para ADM: Conjunto de buenas prácticas para el uso de
ADM.
Framework de Contenido de Arquitectura: Provee un meta modelo conceptual
el cual describe los artefactos de arquitectura.
Enterprise Continuum: Suministra un modelo para estructurar un “repositorio
virtual” que contendrá los elementos de valor reutilizable para la AE como
modelos, patrones y descripciones arquitectónicas entre otros.
Modelos de Referencia: Son arquitecturas genéricas de un alto nivel
abstracción que pueden ser utilizadas para construir la arquitectura de
cualquier sistema.
Framework de Gobierno de Arquitectura: Garantiza que la organización
disponga de una estructura organizacional que permita la ejecución del
proyecto, la cual incluye definición de roles, responsabilidades, recurso
humano capacitado y modelos de certificación, entre otros.
2.1.3.1 El Ciclo ADM
Continuamos con un repaso de ADM porque este contiene una fase C
denominada Arquitectura de Sistemas de Información, donde encontramos la
Arquitectura de Datos (AD), la cual es el componente de referencia más
32
importante en el desarrollo de esta propuesta metodológica. ADM es un método
genérico para el desarrollo de AE, el cual está diseñado para hacer frente a la
mayoría de los requisitos del sistema y de la organización. Sin embargo, a
menudo será necesario modificar o ampliar ADM para adaptarse a necesidades
concretas [16]. El ciclo ADM consta de 10 fases, mostradas en la Figura 8, donde
incrementalmente se define, ejecuta y controla la AE de forma iterativa.
Figura 8. El ciclo ADM [16]
33
Fase Preliminar: en esta fase la empresa se prepara para iniciar el proyecto de
AI, definiendo el alcance, los principios, la estructura de gobierno y principalmente
el compromiso con el nivel estratégico. En esta fase se deben definir los diferentes
ajustes que se le deben hacer a ADM de acuerdo a las necesidades del proyecto.
Fase A. Visión de la Arquitectura: marca el inicio de una iteración ADM al definir
el alcance, restricciones y expectativas. Se realiza una primera validación del
contexto del negocio.
Aclarar y acordar el propósito de los esfuerzos de AE es una de las partes
fundamentales de esta etapa, y el objetivo debe estar claramente reflejado en la
visión que se crea. Los proyectos de arquitectura se realizan con un propósito
específico en mente, un conjunto específico de motivadores de negocio que
representan el retorno de la inversión para los interesados en el desarrollo de la
arquitectura. Aclarar el propósito y demostrar cómo se lograra el desarrollo de la
arquitectura propuesta, es la clave principal de la visión de arquitectura [16].
La visión de negocio define el estado deseado o futuro de una determinada
organización o empresa en términos de su objetivo fundamental o dirección
estratégica. La misión de negocio define el objetivo fundamental de una empresa y
básicamente describe porque existe y como este soporta el avance hacia el logro
de la visión [17].
La declaración de visión y misión de negocio se utilizan a menudo para apoyar
proyectos de mejoramiento. En términos de arquitectura éstos proporcionan un
objetivo estratégico y un medio para validar muchos de los objetivos de la
arquitectura. La visión y misión también ayudan a validar los principios de
arquitectura. Es importante revisar y validar la visión y misión en los compromisos
de la arquitectura que soportan la transformación del negocio, ya que ayudara a la
toma de decisiones en la reestructuración de la empresa [17].
Algunos ejemplos de misiones de negocio son:
34
3M: “Resolver problemas sin resolver de forma innovadora.”
Mary Kay Cosmetics: “Ofrecer oportunidades sin límite a las mujeres.”
Merck: “Preservar y mejorar la vida humana.”
Wal-Mart: “Brindar a la gente común la oportunidad de comprar lo mismo
que los ricos.”
Walt Disney: ”Hacer feliz a las personas.”
Fase B. Arquitectura del Negocio: No es diseñar el negocio es entender su
estructura según el alcance definido en la fase A, se realiza una comprensión de la
organización en aspectos como estructura organizacional, objetivos del negocio,
motivadores, estrategias, funciones, servicios, procesos y la interrelación entre
ellos. El objeto de esta fase es definir una situación actual y un estado deseado
para los procesos de negocio respectivos.
La estrategia de negocio proporciona la dirección y descripción de cómo una
empresa quiere lograr su visión de negocio en un plazo determinado y la forma
como se puede lograr mediante una serie de actividades claves. Es el “Que y
Como”. La estrategia de negocio es importante para la arquitectura a corto y largo
plazo porque brinda un marco de referencia para evaluar como la arquitectura
debe apoyar o alinearse con la estrategia de negocio.
La estrategia de negocio no siempre está disponible, ya que puede ser
información confidencial. Sin embargo para un trabajo de arquitectura como parte
de un proyecto de transformación de la empresa, es importante comprender la
estratégica de negocio, para lo cual es necesario preparar entrevistas con los
ejecutivos principales.
Algunos ejemplos de estrategias de negocio;
Autoservicio.
Flexibilidad.
Automatización de procesos de negocio.
35
Indicadores y control de procesos.
Ajustarse a algún marco de referencia.
Los motivadores de negocio deben ser: específicos, medibles, agresivos pero
viables, orientados al resultado y limitados en el tiempo. Un motivador de negocio
es una descripción corta que define clara y específicamente los resultados
deseados de negocio de una organización así como las actividades necesarias
para lograrlo [19].
Se deben identificar claramente los motivadores de negocio y encontrar las
relaciones entre los motivadores de negocio y los objetivos de la AI.
Fase C. Arquitectura de Sistemas de Información: en esta fase el objetivo es
describir y entender la arquitectura de los sistemas de información que requiere el
negocio para alcanzar su visión, soportando sus estrategias de negocio y
evidenciando su integración. Aquí también se debe establecer el estado actual, el
estado futuro y análisis gap del panorama de los sistemas de información. Esta
fase cubre dos temas principales:
Arquitectura de Aplicaciones: el trabajo en esta etapa corresponde a identificar
cuáles y como son las aplicaciones y su arquitectura que soportan y soportaran
el negocio y su integración.
Arquitectura de Datos: El objetivo de esta etapa es identificar y entender las
entidades de datos relevantes para la empresa, no el diseño de sistemas de
almacenamiento lógico o físico.
Fase D. Arquitectura Tecnológica: el objetivo en esta fase es identificar y definir
los componentes tecnológicos básicos que soportaran la solución a nivel de
sistemas de información. Principalmente se definen plataformas de hardware y
software base.
Fase E. Oportunidades y Soluciones: esta fase se debe evaluar y seleccionar
opciones de implementación, tomar decisiones si se debe comprar o desarrollar
36
internamente. También se debe definir las dependencias de los proyectos, costos
y beneficios con el objeto de crear un plan general de implementación y migración.
Fase F. Planeación de la Migración: en esta fase se debe priorizar los proyectos
de implementación de acurdo a los aspectos definidos en la fase E tales como
dependencia, costos y beneficios de los proyectos de migración, el resultado es
un mapa de proyectos detallado de implementación, calidad de datos y migración.
Fase G. Gobernabilidad de la implementación: el aspecto principal en esta fase
es asegurar que se definan las condiciones de gobierno necesarias para llevar a
cabo los proyectos de implementación, teniendo en cuenta actividades como:
formular recomendaciones para cada proyecto, diseñar y construir los
mecanismos y estructuras de gobierno para los proyectos, definir los roles de
gobierno necesario y asegurar que los proyectos respetaran la arquitectura.
Fase H. Administración del cambio de la Arquitectura: el objetivo principal es
definir los procesos de gestión del cambio necesarios para mantener vigente la
AE, las actividades principales de estos procesos deben ser: monitorear nuevos
desarrollos, monitorear cambios en el entorno del negocio y determinar si es
necesario iniciar un nuevo ciclo de evolución de la AE.
2.1.3.2 Alcance
El alcance de la AI debe ser definido para asegurar el cubrimiento de los temas
relevantes para el negocio. Este determina el nivel de granularidad y detalle para
cada uno de los aspectos de las áreas a cubrir y asegura el apropiado
cumplimiento de las expectativas según el acuerdo con las partes interesadas en
el proyecto de AI. El alcance controla el desarrollo de la arquitectura y asegura
que todas las actividades se enfoquen en solucionar los problemas del negocio. El
alcance de arquitectura es un artefacto obligatorio, porque este define y
37
proporciona un medio para asegurar el cumplimiento de las expectativas de los
interesados en el proyecto de AI [17].
Cuatro dimensiones se suelen utilizar para definir y limitar el alcance de una
arquitectura [16]:
Enfoque o alcance de la empresa: ¿cuál es la extensión total de la empresa y
a cuanto de esa extensión debe enfocarse el esfuerzo de arquitectura?
o Muchas empresas son muy grandes que pueden comprender una
federación de unidades organizativas y que se podrían considerar
empresas con derechos propios.
o Las empresas modernas cada vez se extienden más allá de sus límites
tradicionales de la empresa comercial tradicional para adoptar una
combinación con proveedores, clientes y socios.
Dominios de Arquitectura: una descripción completa de arquitectura
empresarial debe contener los cuatro dominios de arquitectura (negocio,
aplicaciones, datos y tecnología), pero la realidad de las limitaciones de
recursos y tiempo a menudo significa que no hay tiempo o recursos suficientes
para realizar un top-down de la arquitectura que abarque los cuatro dominios.
Alcance vertical o nivel de detalle: se debe tener cuidado para seleccionar el
nivel de detalle adecuado a ser capturado, porque el uso previsto de la
arquitectura y las decisiones se toman basados en este. Es importante que un
nivel coherente y equitativo de la profundidad sea realizado en cada dominio
de la arquitectura. Si se omite un detalle importante, la arquitectura puede ser
no útil. Si se incluyen detalles innecesarios el proyecto de arquitectura puede
exceder el tiempo y los recursos disponibles y la arquitectura resultante puede
ser confusa.
Periodo de tiempo: cuando el alcance de la empresa es grande y la
arquitectura objetivo es particularmente complejas, el desarrollo de la
38
arquitectura, puede encontrarse con grandes dificultades, e incluso resultar
“misión imposible”, especialmente si se lleva a cabo por primera vez. En tales
casos una visión más amplia se puede tomar, por el cual una empresa está
representada por varias instancias de arquitectura diferentes, cada instancia
representa a la empresa en un instante de tiempo determinado. Una instancia
de arquitectura representara el estado actual de la empresa (As-Is), otra
instancia de arquitectura puede definir parcialmente la arquitectura objetivo
(To-Be). Las instancias de arquitecturas de transición o intermedias cada una
compuesta por su propio conjunto de descripciones de la arquitectura objetivo.
Típicamente el alcance de una arquitectura es primero expresada en términos del
alcance de la empresa, periodo de tiempo y nivel de detalle:
Figura 9. Desarrollo incremental de la arquitectura [16]
39
Existen dos enfoques básicos para el desarrollo de arquitecturas:
Vertical: la empresa se divide en segmentos, donde cada segmento
representa una línea de negocio independiente dentro de la empresa en
general y cada uno con su arquitectura empresarial junto con sus cuatro
dominios (negocio, aplicaciones, datos y tecnología), estos dominios de
arquitectura se pueden desarrollar separadamente con miras a una integración
posterior.
Horizontal: la empresa se divide en súper-dominios en el cual cada dominio de
arquitectura (negocio, aplicaciones, datos y tecnología) cubre toda la empresa
en general como un proyecto independiente de los otros, posiblemente con
personal diferente y con miras a una integración posterior.
2.1.3.3 División de Arquitecturas
Es necesario dividir las arquitecturas por las siguientes razones:
Porque abordar los problemas dentro de una única arquitectura es demasiado
complejo.
Para resolver conflictos entre arquitecturas correspondientes a trabajos
realizados en diferentes líneas de tiempo. Esto porque el estado de la empresa
cambia con el tiempo y una arquitectura desarrollada en una línea de tiempo
es muy diferente a otra desarrollada en un momento diferente.
Permite que diferentes personas trabajen en diferentes elementos de
arquitectura al mismo tiempo, además permite la división de arquitectos por
grupos especializados de trabajo en los diferentes segmentos de arquitectura.
Descripción de los criterios de clasificación:
40
Asunto: la división de arquitectura son naturalmente organizadas en grupos de
acuerdo a la gestión operativa o de control. Ejemplos de particiones pueden
ser: aplicaciones, departamentos, productos, servicios, procesos, entre otros.
Punto de vista: Definición del tema específico de acuerdo a los requerimientos
de negocio.
Nivel de detalle: El nivel de detalle dentro de la arquitectura está directamente
relacionado con el grupo de interés en la arquitectura. Las arquitecturas con
menos detalle son de interés para los gerentes o ejecutivos, las arquitecturas
con un incremento en el detalle es de interés para el personal operativo. Para
la definición del nivel de detalle se propone la utilización del framework de
Zachman en la dimensión de Datos para las perspectivas de esquema
Contextual, conceptual, lógico y Físico.
Nivel de abstracción: el nivel de abstracción de una arquitectura tiene una
fuerte influencia sobre la forma en que la arquitectura será usada. Por ejemplo
las arquitecturas que ofrecen una representación muy directa de las soluciones
normalmente se utilizan para la compresión del estado actual y futuro de la
empresa. las arquitecturas con un nivel de abstracción más alto normalmente
se utilizan para comunicar los conceptos o modelos de referencia que se
pueden aplicar a los problemas específicos en arquitecturas futuras.
Precisión: Definición del gobierno y gestión del cambio para garantizar que la
arquitectura evolucione de acuerdo a la realidad cambiante de la empresa, de
tal forma que permita controlar las sucesivas versiones de los artefactos
arquitectónicos.
2.1.3.4 Principios de Datos
Los principios son normas y directrices generales, con la intención de que sean
duraderos y que reara vez sean modificados, para informar y apoyar la forma
que una organización establece para el cumplimiento de su misión. A su vez, los
41
principios pueden ser sólo un elemento en un conjunto estructurado de ideas, que
colectivamente definen y guían a la organización, a través de acciones y
resultados.
Los principios de datos proporcionan orientación sobre el uso y el despliegue de
todos los recursos y activos en toda la empresa, con el fin de hacer el entorno de
la información lo más productivo y rentable como sea posible.
En [1] se encuentra una descripción detallada de ejemplos de principios de datos
propuestos por TOGAF.
2.1.3.5 TOGAF y La Arquitectura de Datos
TOGAF a través del método ADM dedica una sección al tema de arquitectura de
datos donde hace referencia a tres consideraciones principales para Arquitectura
de Datos [16]:
Gestión de Datos: cuando una empresa decide emprender un proyecto de AE,
es importante entender y abordar los problemas de gestión de datos, para lo
cual debe definir un método estructurado y exhaustivo que le permite un uso
eficaz de los datos y aprovechar sus ventajas competitivas. Las
consideraciones que se deben tener en cuenta son:
o Identificar los principales componentes de aplicación que servirán de
referencia en la identificación de los datos maestros de la empresa.
o Identificar estándares propios de la empresa y analizar si es necesario
adoptarlos.
o Entender claramente cómo las entidades de datos son utilizadas por las
funciones de negocio, procesos y servicios.
o Es necesario entender cómo y dónde las entidades de datos de la
empresa se crean, almacenan, transportan y consultan.
42
o Identificar el nivel de complejidad de las transformaciones de datos
necesarias para el intercambio de información entre las aplicaciones.
o Identificar cuáles serán los requerimientos de software necesarios como
apoyo para la integración de datos. Por ejemplo el uso de herramientas
ETL o herramientas de perfilamiento para evaluar la calidad de los
datos.
Migración de datos: cuando existen aplicaciones y es necesario
reemplazarlas, surgirá la necesidad de migrar los datos (maestros,
transaccionales y metadatos) a la nueva aplicación. En consecuencia se deben
identificar las necesidades de migración de datos y establecer indicadores de
transformación y limpieza requerida para obtener los datos en un formato que
cumpla con los requisitos de las nuevas aplicaciones. Aquí es importante
también asegurarse que toda la empresa tenga una definición común de datos.
Gobierno de datos: son las consideraciones para garantizar que la empresa
tiene las dimensiones necesarias que permitan la transformación, de la
siguiente forma:
o Estructura: esta dimensión se refiere a si la empresa tiene la estructura
organizacional necesaria y los organismos de normalización para
gestionar los aspectos de transformación de las entidades de datos.
o Sistema de gestión: en esta dimensión la empresa debe contar con un
sistema que le permita gestionar los aspectos de gobierno sobre las
entidades de datos durante todo su ciclo de vida.
o Personas: esta dimensión se refiere a los datos relacionados con las
habilidades y los roles que la empresa requiere para su transformación.
Si la empresa carece de recursos y habilidades, se debe considerar
tanto la adquisición de las habilidades críticas o de formación de
recursos internos existentes a través de un programa bien definido de
aprendizaje.
43
TOGAF también define una serie de pasos a seguir para la ejecución de la fase de
arquitectura de datos, los pasos son los siguientes:
Seleccionar modelos de referencia, puntos de vista y herramientas: se debe
revisar, validar y definir si es necesario el conjunto de principios de datos (ver
principios de datos). Seleccionar modelos de referencia como por ejemplo
eTOM (enhanced Telecom Operations Map), ARTS Data Model for the Retail
industry, Energistics Data Model for the Petrotechnical industry, entre otros.
Un modelo de referencia es un conjunto de convenciones o patrones usados
para poder medir o determinar la situación actual de una empresa respecto al
modelo de referencia. Esto permite realizar un análisis comparativo y así
determinar o cuantificar la brecha que existe entre la situación actual y el
marco de referencia. Seleccionar puntos de vista relevantes para la
arquitectura de datos, como por ejemplo, puntos de vista de auditores, reportes
de tiempo real entre otros. También se deben identificar las herramientas y
técnicas necesarias que deben ser utilizadas para la captura, modelamiento y
análisis en asociación con los puntos vistas seleccionadas, algunas técnicas de
modelamiento de datos son:
o Diagrama Entidad-Relación
o Diagrama de clases.
o Modelamiento de objetos
o Diagrama de diseminación de datos
o Diagrama de ciclo de vida de datos
o Diagrama de seguridad de datos
o Diagrama de migración de datos
Desarrollo de una descripción de la situación actual de la arquitectura de datos:
desarrollo de una descripción de referencia de la arquitectura de datos
existentes en la medida necesaria para apoyar la arquitectura destino. El
44
alcance y nivel de detalle dependerá del alcance y objetivos del trabajo de
arquitectura.
Descripción del desarrollo de la situación deseada de la arquitectura de datos.
Realizar análisis de brecha.
Definir componentes del mapa de proyectos
Resolver los impactos sobre la arquitectura
Revisión de la conducta formal de los stakeholder
Finalizar la arquitectura de datos
Crear documento de definición de arquitectura
TOGAF ofrece un método en general que aplica para todos los dominios de
arquitectura empresarial, lo que implica un nivel de abstracción muy alto porque la
arquitectura de negocios, aplicaciones, datos e infraestructura, aunque se
relacionan entre sí son aspectos muy diferentes. Además TOGAF se limita a
mencionar los temas que se deben tener en cuenta, pero no proporciona un
método paso a paso con las tareas específicas de cómo, porque y para que
ejecutar cada una de las tareas en el desarrollo de arquitectura de datos.
2.1.4 Arquitectura de información empresarial según [1]
La arquitectura de información empresarial (en adelante AIE) descrita en [1],
describe los principios y directrices que permiten una implementación coherente
de las soluciones de tecnología de la información, de cómo los datos e información
son gobernados y compartidos en toda la empresa, así como también de qué se
necesita para garantizar una visión de confianza sobre la información.
45
2.1.4.1 Principios de arquitectura de información
A continuación se presentan algunos ejemplos de los principios básicos que guían
una arquitectura de la información:
El acceso y el intercambio de información: los servicios de información
deben facilitar el acceso sin restricciones a los usuarios adecuados en el
momento adecuado.
Servicio de reutilización: facilitar el descubrimiento, la selección y
reutilización de los servicios de información y siempre que sea posible
fomentar el uso de interfaces uniformes.
Gestión de la información: tecnología de la información adecuada debe
apoyar la ejecución eficaz de una estrategia de gestión de la información.
Estándares: Un conjunto de normas coherentes para los datos y la tecnología
debe ser definida para promover la simplificación a través de la infraestructura
de la información.
2.1.4.2 Dominios de datos
En una empresa existen varios tipos de datos que pueden ser usados en toda la
empresa, como pueden ser usados solo en una línea de negocio de la empresa.
Los datos pueden ser estructurados o no estructurados y también se pueden ver
desde una perspectiva de cómo son almacenados. A continuación la AIE propone
5 dominios de datos:
46
Figura 10. Dominios de datos [1]
Metadatos
Definidos como datos sobre los datos, los metadatos son la información que
describe las características de los datos corporativos y otras entidades. Los
metadatos son el dominio de datos que convierte datos en información útil sobre
el negocio. Los metadatos pueden ser vistos como una colección de datos e
información utilizada para medir, desarrollar y operar un entorno
empresarial. También incluyen información crítica del negocio o vínculos a la
información que se encuentra fuera de la visión tradicional pura de los datos. Los
metadatos son a menudo divididos en metadatos técnicos y metadatos de
negocio.
Los niveles de madurez de uso en metadatos se pueden ver en la Figura 11:
47
Figura 11. Modelo de madurez de metadatos [1]
Nivel 1: Metadatos Técnicos: Un ejemplo de este nivel más bajo de metadatos,
es el catálogo de DB2, el cual consiste en un conjunto de tablas que contienen
información sobre los datos de control de DB2. Las tablas del catálogo de DB2
contiene información sobre los objetos de DB2 tales como tablas, vistas, índices,
procedimientos almacenados, funciones definidas por el usuario, etc.
Nivel 2: Metadatos de Negocio: Definir y consumir metadatos de negocio es
esencial para las empresas de hoy. Un buen ejemplo de metadatos de negocio es
la descripción de términos y de reglas de negocio.
Nivel 3: Metadatos de Negocio y Técnicos Alineados: El siguiente nivel de
madurez en términos de generación y consumo de metadatos es la alineación. Es
decir, es necesario que haya una relación o vínculo entre los metadatos de
negocio y técnicos. Un ejemplo consistiría en tener un link entre un reporte de BI y
los objetos de IT.
48
Nivel 4: Metadatos Para Gestión del Negocio: El siguiente nivel de uso de los
metadatos es caracterizado por los metadatos de escenarios de casos de uso que
permiten la gestión y optimización del negocio. Esto permite al líder de ventas
expresar requerimientos mediante el uso del lenguaje de negocio, donde a través
del uso de metadatos éstos requerimientos son traducidos al dominio de TI.
Nivel 5: Metadatos Para Innovación del Negocio: Permite mejorar la visión
empresarial, innovación, ideas y oportunidades de negocio. Permitiendo un
análisis y modelo de negocio predictivo. Para seguir analizando y optimizando el
negocio es necesario orquestar todo mediante el uso y exploración de metadatos
de negocio y técnicos.
Hay diferentes niveles de detalle para los metadatos que corresponden a la
arquitectura de información empresarial. Además del nivel conceptual, lógico y
físico, se adiciona un nivel contextual al más alto nivel y un nivel de
implementación al más bajo nivel:
Nivel Contextual: Describe el contexto de todos los objetos de metadatos y
sirve como una base general para describir con más detalle las circunstancias
y condiciones para las especificaciones de los objetos de metadatos en los
niveles posteriores.
Nivel conceptual: Proporciona una descripción de alto nivel de los objetos de
metadatos. Este puede incluir una descripción de alto nivel de las estructuras
de datos y sus relaciones incluyendo taxonomías.
Nivel Lógico: Contiene los datos de nivel lógico de objetos de metadatos,
como los componentes y sus relaciones. Incluye diagramas detallados del
modelo de metadatos, detallando descripciones y las interacciones de los
objetos de metadatos.
Nivel físico: Describe todos los objetos de metadatos del nivel físico. Contiene
los aspectos operativos, tales como quien es el propietario de un objeto de
49
metadato en particular, donde se encuentra (localización), quien está permitido
para consumir los metadatos, etc.
Nivel de Implementación: Contiene el nivel más bajo de descripción de los
objetos de metadatos que están relacionados con aspectos de implementación
y ejecución. Esto también está relacionado con los productos de
implementación y mapeo de los productos.
Los metadatos generalmente se dividen en dos categorías: metadatos de negocio
y metadatos técnicos.
Metadatos de Negocio: Este tipo de metadatos define reglas de negocio
como definiciones de negocio, datos de negocio, terminología y glosario de
negocio, calidad de datos, algoritmos de negocio y utilización de lenguaje de
negocio. Los metadatos de negocio incluyen información contextual acerca de
la información recuperada o consultada, taxonomías que definen la
organización del negocio, jerarquía de productos y vocabulario usado para
definir los términos de negocio.
Los siguientes son ejemplos de metadatos de negocio:
Modelo de negocio: es una descripción general de trabajo que aborda
factores internos y externos de la operación en curso de la empresa. Entre más
maduro el ambiente de arquitectura de negocio, el modelo de negocio se
convierte en un framework que permite la transformación de ideas innovadoras
en valor comercial para la empresa.
Reglas de negocio: estas normas o reglas rigen los procesos de negocio e
incluyen las reglas de validación, reglas de uso y otros imperativos y directrices
para controlar la ejecución correcta de todos los procesos de negocio.
Planeación y gestión del rendimiento del negocio: estos son los
indicadores de rendimiento (KPIs) y otras métricas de rendimiento. Además
incluye metadatos que permite a los canales financieros la planificación,
50
previsión, elaboración de informes y la gestión del rendimiento empresarial.
Esto debe ser apoyado por productos y herramientas.
Reglas de calidad de datos de negocio: hay reglas para gestionar la calidad
de datos de negocio. Por ejemplo, estas reglas permiten la gobernabilidad de
datos de negocio para ser implementados apropiadamente.
Glosario de negocio: esto captura el diccionario de datos de negocio y
vocabulario de negocio, que son las entidades y elementos usados en
esquemas de negocio y otras definiciones de negocio.
Reportes y panel de control: estos metadatos contienen las especificaciones
y definiciones de informes de gestión, panel de control y cuadros de mando
(scorecards). Esto describe el contenido, estructura, coherencia, propietario y
argumento de todos los informes o reportes.
Políticas y procedimientos operacionales: estas son las normas o políticas
que describen los aspectos operacionales de la empresa. Unos ejemplos son:
o Procedimientos para manejar la relación con socios comerciales y
proveedores.
o Políticas de comunicación externa y reportes.
o Pautas de conducta de negocios.
Metadatos Técnicos: Los metadatos técnicos definen las estructura de los
sistemas informáticos, aplicaciones, sistemas de bases de datos, sistemas de
integración de información empresarial (EIIS), sistemas de gestión de datos
maestros (MDM), bodegas de datos (DW), incluyendo data mart y otros medios
técnicos. Idealmente, los metadatos técnicos son derivados de las
especificaciones funcionales y de negocio, donde una porción significante de
los metadatos técnicos son automáticamente generados por los sistemas
mencionados. Los metadatos técnicos se refieren a la ubicación de las fuentes
de datos, protocolos de acceso, esquemas físicos y lógicos de las fuentes de
datos, tales como modelos de entidad-relación, modelos de objetos y modelos
ontológicos. Los siguientes son ejemplos de metadatos técnicos:
51
o Modelo técnico: estos son los modelos de datos lógicos y físicos,
modelos multidimensionales como son procesamiento analítico en línea
(OLAP), procesamiento analítico en línea multidimensional (MOLAP),
procesamiento analítico en línea relacional (ROLAP) y otros cubos,
modelos de data-mining (incluyendo modelos predictivos), modelos de
datos maestros.
o Navegación de metadatos: esto describe la vinculación de datos y el
movimiento de datos dentro de los ambientes mencionados en el punto
anterior e incluye las jerarquías de negocio, lugares de origen y destino,
las especificaciones de asignación, las columnas y campos de origen,
diseño de la fuente de extracción de datos, diseño de transformación y
las especificaciones, normas de calidad de los datos, puntos de diseño,
campos derivados y campos y columnas destino.
o Metadatos operacionales: esto describe como se gestionan los datos
en un sistema desde la creación hasta su punto final. Estos metadatos
se utilizan para describir los aspectos del ciclo de vida de los datos
dentro de un sistema. Esto está relacionado con los trabajos en batchs
de aplicaciones y aplicaciones de integración de datos.
o Metadatos de despliegue: esto incluye artefactos relacionados con
SOA en la empresa, modelos de implementación, modelos de servicios
y su relación con modelos existentes como bases de datos.
o Metadatos de reportes y panel de control: esto incluye
especificaciones de reportes de inteligencia de negocio (BI), la
generación y programación de reportes de BI, el propietario y modelos
de uso.
o Metadatos de seguridad: esto incluye la autorización y autenticación
para acceder y modificar los metadatos, una matriz de seguridad para la
generación de metadatos (basada en sistemas y control de usuarios), y
una matriz de seguridad de uso para la exploración de metadatos.
52
o Metadatos de aplicaciones y sistemas: esto incluye nombre y
descripción, matriz de uso y propietario, datos de uso y alcance, y
control de versiones.
Fuentes de Metadatos: Que son las fuentes de metadatos? En otras palabras
donde suele encontrarse los metadatos de la empresa? Puede ser difícil llegar a
especificar una lista completa de todas las fuentes potenciales de metadatos. Sin
embargo, es posible identificar metadatos en los siguientes sistemas de IT y
partes de la empresa:
Sistemas operacionales: estos son, por ejemplo, sistemas específicos de la
industria como pueden ser sistemas bancarios, sistemas de soporte
operacional en telecomunicaciones y sistemas en el sector de seguros.
Software Middleware: los metadatos también se encuentran en todo el
software middleware, tales como software de integración de información
empresarial (EII), software de integración de aplicaciones empresariales (EAI)
y también en software de administración de contenidos empresariales (ECM).
Sistemas de Bases de Datos: todos los sistemas de gestión de bases de
datos contienen metadatos, tales como descripción de tablas, índices y otros
objetos de bases de datos. Estos metadatos son utilizados con propósitos de
mantenimiento y optimización.
Aplicaciones: esto incluye paquetes de aplicaciones como ERPs, CRMs,
aplicaciones web, aplicaciones móviles, etc.
Bodegas de Datos (DW): esto incluye metadatos contenidos en el DW y data
marts. Un ejemplo de metadatos en este contexto son los cubos OLAP.
Herramientas de reportes de BI: estos metadatos están relacionados con la
generación de tableros de control de inteligencia de negocios, mediciones de
KPIs y otros reportes análisis incluyendo los de propósito de gestión de
rendimiento.
53
Políticas y procedimientos: las políticas o al menos ciertos atributos de las
políticas podría ser considerada como metadatos. Por ejemplo, procedimientos
de copias de seguridad de una base de datos o realizar tareas de
mantenimiento de cualquier sistema o aplicación puede ser visto como una
descripción o un conjunto de órdenes que deben seguirse.
Procesos: esto aplica para procesos de negocio y técnicos por igual. Ellos son
caracterizados a través de atributos y especificaciones detalladas. Los
procesos de negocio también pueden ser vinculados a las regulaciones que se
deben cumplir.
Personas: los directores de proyectos, arquitectos de soluciones, socios y
también los clientes, son una de las mejores fuentes de metadatos y sus
conocimientos sobre los datos influye sobre la ejecución de los procesos de
negocio.
Datos Maestros
Los datos maestros son los objetos de negocio que se utilizan en las diferentes
aplicaciones de la empresa, junto con sus metadatos asociados, características,
definiciones, funciones, conexiones y taxonomías. Los datos maestros son las
“cosas” importantes que se registran en los sistemas operacionales, las que son
medidas y reportadas en los sistemas de información y analizadas en los sistemas
analíticos de la empresa. Algunos ejemplos de datos maestros son [21]:
Clientes
Proveedores
Productos
Cuentas
Contratos
Lugares
54
Los datos maestros tienden a existir en más de una línea de negocio dentro de la
organización, por lo que el cliente puede aparecer en el sistema de ventas como
también en el sistema de finanzas. Los datos maestros tienden a ser relativamente
estáticos y no cambian con frecuencia.
En la Figura 12se consideran los clientes de una empresa, donde cada cliente
puede participar en una serie de operaciones de negocio: ventas, finanzas,
servicio al cliente. Algunos de los clientes pueden participar en diferentes
contextos, tal vez como vendedores o proveedores. En cada uno de estos
contextos, el cliente puede desempeñar un papel diferente, y a su vez, la empresa
puede valorar algunos de los atributos sobre los demás en función del contexto.
Pero claramente quiere asegurarse de que los procesos de negocio no fracasen
porque el cliente aparece varias veces en diferentes conjuntos de datos y que las
actividades del cliente sean finalmente reflejadas en los informes de gestión [21].
Figura 12. Representación de la misma persona en diferentes contextos de aplicación [21]
55
Para el ejemplo anterior es conveniente que todas las aplicaciones de negocio
lleguen a un acuerdo sobre cuáles son las entidades y sus actividades. Podemos
resumir esto en dos objetivos:
Integrar las múltiples variaciones de las entidades empresariales en una sola
fuente de la verdad.
Permitir a las aplicaciones empresariales compartir la misma visión de los
objetos de negocio dentro de la empresa.
En otras palabras, se deben definir datos maestros como solución al ejemplo
mencionado anteriormente.
Gestión de datos maestros: La gestión de datos maestros (ahora en adelante
MDM por sus siglas en ingles), no es una tecnología o un producto específico,
MDM es un conjunto o mezcla de aplicaciones de negocio, métodos y
herramientas. Bajo este contexto se pueden poner en práctica las políticas,
procedimientos e infraestructura que soporte la captura, integración y posterior uso
compartido de datos maestros precisos, oportunos, consistentes y completos.
Enfoques arquitecturales de MDM: Pueden existir muchas formas de
implementar un repositorio de datos maestros. Aquí, analizaremos tres enfoques
arquitectónicos de forma conceptual para el desarrollo de un MDM, cada enfoque
frente a las diferentes necesidades de una organización. Es interesante notar, que
una vez que el concepto de MDM es aceptado dentro de una organización, es
relativamente fácil hacer la transición [22].
1. Sistema central de datos maestros: En un sistema central de datos maestros
(ver Figura 13), cada dominio de datos y cada conjunto de atributos asociados
56
a cada modelo de datos maestros es definido y gestionado dentro de un
sistema maestro único. El repositorio central es la fuente principal para la
gestión de los objetos de datos maestros que posteriormente son publicados a
los sistemas de aplicación. Los atributos básicos se gestionan localmente en
cada aplicación y son ligados a la instancia maestra mediante una llave
primaria global. En este enfoque, las instancias de nuevos datos pueden ser
creadas en cada aplicación, pero deben ser sincronizados con el sistema
central [21].
Figura 13. Sistema central de datos maestros [21]
57
Sistema maestro principal: En un sistema maestro principal (ver Figura 14), un
sistema de aplicación existente es seleccionado para ser el maestro, y otros
sistemas se vuelven dependientes de ese sistema, como el repositorio central. En
este enfoque los atributos básicos son creados y gestionados exclusivamente en
el maestro y debe existir un proceso para mapear objetos entre diferentes
sistemas.
Figura 14. Sistema maestro principal [21]
Repositorio central: Un repositorio central (ver Figura 15) se utiliza para
gestionar el sistema maestro principal y los datos no se replican en otros sistemas.
Las aplicaciones solicitan información al repositorio central y proporcionan
actualizaciones al repositorio central. Dato que solo existe un acopia de los datos
58
maestros, todas las aplicaciones son modificadas para interactuar con el
repositorio central, mediante un enfoque orientado a servicios.
Figura 15. Repositorio principal
Datos Operacionales
El concepto de datos operacionales se aplica a los datos estructurados creados y
utilizados por las transacciones comerciales y por lo tanto también se conoce
como datos transaccionales que describen lo que está pasando en el negocio.
59
Los datos operacionales son el nivel de granularidad de la información que tiene la
finalidad operativa de representar el detalle de la actividad diaria de una empresa.
En muchas industrias, las transacciones comerciales, tales como pedidos, facturas
y la información de cobros se consideran datos operativos.
Los datos operativos a menudo incorporan los datos maestros. Un ejemplo es el
cliente y el producto información utilizada para crear una orden. Sin embargo, al
caracterizar los datos operacionales, los requisitos de exactitud, exhaustividad,
coherencia, oportunidad, relevancia y la confianza a menudo no son tan altos
como para los datos maestros o datos analíticos. Esto es motivado por el hecho
de que los datos operativos se utilizan generalmente en un departamento o unidad
de negocio. Los datos maestros, por ejemplo, se propagan en toda la empresa [1].
Datos no Estructurados
Los datos no estructurados son también conocidos como contenido. Se denomina
datos no estructurados por razones de integridad, ya que es más amplio que lo
gestionado por un ECM. Los datos no estructurados no poseen definiciones de
tipo, no se encuentran organizados bajo algún patrón, no existe el concepto de
variables o atributos. Algunos ejemplos son: documentos de texto, hojas de
cálculo, imágenes de documentos escaneados, e-mail, paginas html, entre otros.
Estos tipos de datos generalmente se encuentran en un repositorio de
información, donde para recuperar este tipo de documentos solo podemos hacerlo
con el nombre del archivo.
Datos Analíticos
Los datos analíticos se derivan generalmente de poner los datos operacionales en
un contexto analítico. En algunos casos, los datos analíticos se producen por la
60
ejecución de informes directamente sobre el sistema operacional. Sin embargo el
caso más común es el movimiento de datos operacionales a sistemas de análisis
como una bodega de datos (de ahora en adelante DW por sus siglas en ingles).
Para un DW en un contexto empresarial, la transferencia de datos desde múltiples
sistemas operacionales hacia el DW, requiere la capacidad de un sistema de
integración de información empresarial (EII) [1].
Para los datos analíticos en un dominio de DW, los requerimientos para exactitud,
consistencia y relevancia son generalmente altos, porque las decisiones se toman
sobre la base de reportes estratégicos y tácticos de inteligencia de negocio (BI).
Por lo tanto los datos operacionales son típicamente estandarizados, limpiados,
organizados y duplicados para asegurar la precisión y consistencia mientras son
movidos a un DW, el cual es requerido para satisfacer las necesidades de
información [1].
Desde un punto de vista de integridad de datos, no todos los atributos son
relevantes para la elaboración de reportes. Por lo tanto, ciertos atributos de las
entidades de negocio como son las facturas o clientes pueden ser no necesarios
en un entorno analítico y se mantienen en sus sistemas operacionales o MDM. La
oportunidad de los datos analíticos depende del propósito analítico. Si un DW, por
ejemplo, es utilizado únicamente para presentar reportes de BI estratégicos o
tácticos, bastaría con cargar los datos operacionales del último mes en el DW, sin
importar los dos últimos días. Sin embargo si es necesario presentar reportes
sobre una base diaria, la oportunidad para obtener los datos operacionales y
moverlos al DW es significativamente mayor.
2.1.4.3 AIE y la arquitectura de datos
Se debe aclarar que la AIE no propone una metodología, ni un método, ni mucho
menos un framework para el desarrollo de proyectos de AI. Pero si define y
61
describe una serie de temas que se deben considerar cuando se habla de AI. A
diferencia de TOGAF y Zachman, en [1] se tocan temas cruciales como modelos
de madurez, dividir los datos empresariales en dominios, también propone un
modelo de referencia para gobierno de datos, a diferencia de TOGAF que solo
menciona este tema y Zachman que sencillamente lo ignora.
El trabajo en [1] es muy importante también porque describe extensamente cada
uno de los dominios de datos y tocando temas como: escenarios de negocio para
cada dominio, escenarios operacionales, diagramas, aseguramiento de calidad y
enfoques arquitecturales entre otros.
2.1.5 Análisis
Como se puede apreciar, las propuestas son diferentes y afirmar que una es mejor
que otra, es muy difícil; la respuesta seria “depende”, depende de las necesidades
de la empresa o proyecto. Los niveles de calificación son una propuesta de Roger
Session para comparar metodologías de AE. Aquí se utilizaran para evaluar las
metodologías de AE particularmente en el aspecto de AI. Los niveles de
calificación son:
1. Hace un trabajo muy pobre en esta área.
2. Hace un mal trabajo en esta área.
3. Hace un trabajo aceptable en esta área.
4. Hace un muy buen trabajo en esta área.
A continuación se realizara una comparación teniendo en cuenta 8 criterios que
son relevantes a la hora de realizar o ejecutar un proyecto de AI:
1. Proveedor neutral: se refiere al hecho de no estar sujeto a un proveedor
específico y estar pagando licencias, mantenimiento o consultorías, siempre a
la misma empresa.
62
2. Información disponible y de acceso público: se refiere al hecho de tener
información disponible sin costo alguno. Información completa de la
metodología.
3. Modelo de Referencia para el alcance del proyecto: se refiere al hecho de
proponer modelos de referencia específicamente para definir el alcance en los
proyectos de AI.
4. Modelo de Referencia para Gobierno de datos: se refiere al hecho de tener un
modelo de referencia para la definición de gobierno de datos en AI.
5. Modelo de Referencia para Datos Empresariales: se refiere al hecho de
proporcionar un modelo de referencia para segmentar o dividir los datos
empresariales en dominios.
6. Modelos de Madurez en Arquitectura de Datos: se refiere al hecho de
proporcionar un modelo que permita definir una medida de avance o progreso
de la AI en la empresa.
7. Guía Metodológica: se refiere al hecho de proporcionar un proceso paso a
paso principalmente del cómo desarrollar un proyecto de AI.
8. Gestión de Datos: se refiere al hecho de proporcionar un método estructurado
que permita entender el uso u operaciones que la empresa realiza sobre los
datos.
CRITERIOS CALIFICACION
TOGAF ZACHMAN AIE FEA
Proveedor neutral 4 1 1 3
Información disponible y de acceso público 4 2 3 4
Modelo de Referencia para el alcance del proyecto 1 1 1 1
Modelo de Referencia para Gobierno de datos 1 1 4 1
Modelo de Referencia para Datos Empresariales 1 1 4 1
Modelos de Madurez en Arquitectura de Datos 1 1 1 1
Guía Metodológica 2 1 1 2
Gestión de Datos 3 1 2 3
Tabla 1. Evaluación de criterios por cada uno de los enfoques de AE
63
En la Tabla 1 se observa que cada una de los enfoques de AE tiene sus fortalezas
y debilidades. Uno de los objetivo de este trabajo es proponer una metodología
que agrupe las fortalezas y además complemente los aspectos que presentan
debilidades en cada uno de los enfoques evaluados en la Tabla 1.
.
2.2 GOBIERNO DE DATOS
El Gobierno de Datos es la disciplina que se encarga de tratarlos datos como un
activo de la empresa. Se trata del ejercicio de las políticas de decisión para
optimizar, proteger y aprovechar los datos como un activo empresarial. Se trata de
la orquestación de las personas, procesos, la tecnología y la política dentro de una
organización, para obtener el óptimo valor de los datos de la empresa. El Gobierno
de Datos desempeña un papel fundamental en la alineación de políticas dispares
ya menudo conflictivas que causan anomalías en los datos maestros. El gobierno
de datos define quien tiene los derechos y la responsabilidad de la toma de
decisiones sobre los datos de una empresa [26].
2.2.1 Diseñando gobierno de datos por Vijay Khatri y Carol V. Brown
El framework para gobierno de datos (ver Tabla 2) incluye 5 dominios de toma de
decisión relacionados entre sí [18]. En la Tabla 3 se resume el alcance de cada
uno de los dominios de decisión con ejemplos de los tipos de decisión que se
deben tomar en cada dominio. En la última columna de la tabla se proporcionan
ejemplos de los posibles roles que pueden ser establecidos para la toma de
decisiones en los diferentes dominios.
64
Tabla 2. Dominios de decisión para gobierno de datos [18]
Tabla 3. Framework para los dominios de decisión de datos
65
2.2.1.1 Principios de datos
Los principios de datos establecen el enlace con el negocio. Para alinear el
negocio con el uso de los datos, los principios de datos establecen la medida de
los datos como un activo de la empresa y por lo tanto definen cuales son las
políticas específicas, normas y directrices adecuadas. Manteniendo la noción de
los datos como un activo los principios de datos también establecen y fomentan
oportunidades para compartir y reusar los datos. Cada principio es apoyado por
una razón fundamental y un conjunto de implicaciones [18].
2.2.1.2 Calidad de los datos
La calidad de los datos impacta a la empresa a nivel operacional y a nivel
estratégico. Una pobre calidad en los datos genera costos operacionales y en lo
estratégico la información no es confiable para la toma de decisiones estratégicas.
La calidad de los datos se refiere a la capacidad que tienen los datos para
satisfacer los requerimientos de uso dentro de la empresa. La calidad de los datos
tiene múltiples dimensiones como: precisión, oportunidad, integridad y credibilidad,
estas dimensiones son relativas y deben ser definidas de acuerdo al contexto de
uso de los datos [18].
2.2.1.3 Metadatos
Se define como los “datos sobre los datos”, los metadatos proporcionan un
mecanismo para obtener una descripción concisa y coherente de los datos,
ayudando así a interpretar el significado o la semántica de los datos [18].
66
2.2.1.4 Acceso a Datos
Acceso a los datos se basa en la capacidad de los beneficiarios de datos para
asignar un valor a las diferentes categorías de datos. Un Análisis de riesgos
efectivo por parte de agentes de seguridad de datos, consiste en identificar las
necesidades de datos de la empresa y definir políticas que garanticen la
confidencialidad, integridad y disponibilidad de los datos.
2.2.1.5 Ciclo de Vida de los Datos
Ser consciente de que todos los datos se mueven a través de las etapas del ciclo
de vida es fundamental para el diseño de la gobernabilidad de datos. Mediante la
comprensión de cómo los datos se utilizan, y cuánto tiempo debe conservarse, las
organizaciones pueden desarrollar métodos para asignar los patrones de uso de
los medios de almacenamiento óptimo, lo que minimiza el costo total de
almacenamiento de datos a través de su ciclo de vida.
2.2.2 El proceso unificado de gobierno de datos de IBM
Muchas empresas vienen de un procedimiento manual que establece los pasos
para implementar un programa de gobierno de datos. Obviamente, todas las
empresas pondrán en práctica la gobernanza de datos de manera diferente, sobre
todo debido a los diferentes objetivos de las empresas. Algunas empresas podrían
centrarse en la calidad de los datos, otros en los clientes, y otros más en asegurar
la privacidad de los datos sensibles de los clientes. Algunas organizaciones
adoptaran un programa de Gobierno de Datos formal, mientras que otras querrán
poner en práctica algo que es más ligero y táctico [26].
67
Figura 16. Visión general del proceso unificado de gobierno de datos de IBM
La Figura 16muestra los diez pasos (pasos del 1-9 y 14) necesarios para sentar
las bases de un efectivo programa de Gobierno de Datos. La empresa entonces
selecciona uno o más de los cuatro pasos opcionales, es decir: Gobierno de Datos
Maestros, Gobierno Analítico, Gestión de Seguridad y Privacidad y la gestión del
Ciclo de Vida de la Información. Finalmente, el proceso unificado de gobierno de
datos necesita ser medido, y los resultados transmitidos periódicamente a los
sponsor ejecutivos [26].
Veamos con más detalle cada uno de los pasos:
Definir el problema de negocio: La razón principal de fracaso de los
programas de gobierno de datos es que no identifican un problema de negocio
tangible. Es imperativo que la organización defina el alcance inicial del
programa de gobierno de datos en torno a un problema de negocio específico,
68
como un problema en auditoría, una pérdida de datos, o la necesidad de
mejorar la calidad de los datos con fines de gestión de riesgos. Una vez que el
programa de gobierno de datos comienza a hacer frente a los problemas
identificados de negocio, este recibirá el apoyo de las funciones de negocio
para ampliar su alcance a otras zonas.
Obtener patrocinio ejecutivo: Es importante establecer el patrocinio
principalmente de ejecutivos de TI y negocio para el programa de gobierno de
datos. La mejor manera de obtener patrocinio es definir el valor en términos de
un caso de negocio. Por ejemplo, el caso de negocio podría ser enfocado en
perfilamiento de clientes, en mejorar la calidad de los datos para apoyar un
programa centrado en el cliente.
Realizar una evaluación de madurez: Toda organización necesita llevar a
cabo una evaluación de madurez de su gobierno, de preferencia sobre un
periodo de tiempo anual. El IBM Data Governance Council ha desarrollado un
modelo de madurez basado en 11 categorías (ver capítulo 5 en [26]), tales
como “Gestión de Riesgos de Datos y Cumplimiento”, “Creación de Valor”, y
“Administración”. La organización de Gobierno de Datos debe evaluar el nivel
actual de madurez (estado actual) y el nivel futuro deseado de la madurez
(estado futuro), que suele ser de 12 a 18 meses por lo menos. Esta duración
debe ser suficiente para producir resultados, pero lo suficientemente corto
como para asegurar la continua aceptación por parte de las principales partes
interesadas.
Construir un mapa de proyectos: La organización de Gobierno de Datos
debe desarrollar un plan de trabajo para cerrar la brecha entre el estado actual
y el estado futuro deseado para las 11 categorías de madurez de la
gobernabilidad de datos. Por ejemplo, la organización de gobierno de datos
podría revisar la brecha de vencimientos para la administración y determinar
que la empresa debe nombrar a los administradores de datos para centrarse
en temas específicos tales como clientes, proveedores, y producto. El
69
programa de gobierno de datos también debe incluir éxitos rápidos, áreas
donde la iniciativa puede generar valor al negocio en plazos cortos.
Establecer un modelo de organización: La organización de gobierno de
datos debe construir un modelo para dirigir sus operaciones, y para asegurar
quien tiene la autoridad suficiente para actuar como árbitro en situaciones
críticas. La organización de gobierno de datos funciona mejor en un formato de
tres niveles. El nivel superior es el Consejo de Gobierno de Datos, que se
compone de los principales líderes funcionales y de negocio que dependen de
los datos como un activo de la empresa. El nivel intermedio es el grupo de
gobierno de datos de trabajo, que consiste en los mandos medios que se
reúnen con más frecuencia. El último nivel consiste en la comunidad de
administradores de datos, que es responsable de la calidad de los datos en el
día a día.
Construir el diccionario de datos: La gestión eficaz de los términos de
negocios puede ayudar a asegurar que el mismo lenguaje descriptivo se aplica
en toda la organización. Un diccionario de datos o glosario de negocio es un
repositorio con las definiciones de los principales términos. Se utiliza para
obtener la consistencia y el acuerdo entre las partes técnicas y de negocio de
una organización. Por ejemplo, ¿cuál es la definición de un “cliente”? Es un
cliente alguien que ha hecho una compra, o alguien que está considerando
hacer una compra? Es un antiguo empleado todavía clasificado como un
“empleado”?, Son los términos “socio” y “distribuidor” sinónimos?, Estas
preguntas pueden ser contestadas mediante la construcción de un diccionario
común de datos. Una vez implementado, el diccionario de datos puede abarcar
toda la organización para asegurar que los términos de negocios están
vinculados a través de metadatos a los términos técnicos, y que la
organización tiene un entendimiento único y común.
Comprender los datos: Alguien dijo una vez: “No se puede gobernar lo que
no entendemos”. Hoy en día existen pocas aplicaciones standalone. Los datos
más bien, se componen de los sistemas, y “sistemas de sistemas”, con
70
aplicaciones y bases de datos esparcidos por toda la empresa, pero
integrados, o están relacionados entre sí por lo menos. El modelo de base de
datos relacional en realidad empeora las cosas mediante la fragmentación de
las entidades de negocio para su almacenamiento. Pero, ¿cómo está todo lo
relacionado? El equipo de gobierno de datos necesita descubrir las relaciones
entre los datos críticos en toda la empresa. El descubrimiento de datos puede
incluir relaciones simples y difíciles de encontrar, así como la ubicación de los
datos sensibles dentro de los sistemas de TI de la empresa.
Crear un repositorio de metadatos: Los metadatos son datos acerca de los
datos. Se trata de información sobre las características de cualquier artefacto
de datos, como su nombre técnico, la razón social, ubicación, la importancia y
relaciones con los artefactos de datos de la empresa. El programa de gobierno
de datos va a generar una gran cantidad de metadatos de negocio desde el
diccionario de datos y una gran cantidad de metadatos técnicos durante la fase
de descubrimiento. Estos metadatos debe ser almacenado en un repositorio
para que pueda ser compartido y aprovechado en varios proyectos.
Definir métricas: El gobierno de datos debe contar con indicadores sólidos
para medir y monitorear el progreso. El equipo de gobierno de datos debe
reconocer que cuando se mide algo, mejora el rendimiento. Como resultado, el
equipo de gobierno de datos debe recoger unos pocos indicadores principales
de rendimiento (KPIs) para medir el desempeño continuo del programa.
Estos son los nueve primeros pasos requeridos. El paso final requerido se discute
más adelante. La empresa también tiene que seleccionar al menos una de los
cuatro pasos de datos opcionales de Gobierno (Gobierno de Datos Maestros,
análisis de Gobierno, Seguridad y privacidad, y la información del ciclo de vida de
Gobierno).
Gobierno de datos maestros: La información más valiosa dentro de una
empresa son los datos críticos de negocio como los clientes, productos,
71
materiales, proveedores y cuentas, que comúnmente se conoce como datos
maestros. A pesar de su importancia, los datos maestros a menudo se replican
y se dispersan a través de procesos de negocio, sistemas y aplicaciones en
toda la empresa. El gobierno de datos maestros es una práctica continua,
mediante el cual los empresarios definen los principios, políticas, procesos,
reglas de negocio y métricas para la consecución de los objetivos de negocio,
mediante la gestión de la calidad de sus datos maestros.
Gobierno de análisis: Las empresas han invertido grandes sumas de dinero
para construir bodegas de datos para obtener una perspectiva competitiva. Sin
embargo, estas inversiones no siempre han dado resultados, como
consecuencia, las empresas están cada vez más examinando sus inversiones
en el análisis. Se define el “Análisis de Gobernabilidad” como el
establecimiento de políticas y procedimientos para alinear mejor a los usuarios
de negocio con las inversiones en infraestructura analítica.
Gestionar la seguridad y privacidad: El líder del gobierno de datos,
especialmente los que informan al jefe de seguridad de la información, a
menudo tienen que lidiar con cuestiones relacionadas con la seguridad de los
datos y la privacidad. Algunos de los retos comunes de seguridad de datos y
desafíos de privacidad que incluyen los siguientes:
o Donde esta nuestra información confidencial?.
o La organización ha enmascarado sus datos confidenciales en los
entornos que no son de producción (desarrollo, pruebas y capacitación)
para cumplir con las regulaciones de privacidad?.
o Están los controles de auditoría de base de datos en el lugar para evitar
el acceso de los usuarios privilegiados, por ejemplo, como
administradores de bases, a los datos privados, como los sueldos de los
empleados y listas de clientes?
Gobierno del ciclo de vida de la información: El ciclo de vida de la
información se inicia con la creación de datos y termina con su extracción de la
72
producción. La organización de gobierno de datos tiene que lidiar con las
siguientes cuestiones relativas al ciclo de vida de la información:
o ¿Cuál es nuestra política respecto a la digitalización de documentos de
papel?
o ¿Cómo introducir los datos estructurados y no estructurados bajo un
marco común de políticas y de gestión?
Medir los resultados: La organización de gobierno de datos debe asegurar la
mejora continua mediante un seguimiento constante de las métricas. En el
paso 9, el equipo de gobierno de datos establece las métricas. En esta etapa,
el equipo de Gobierno Datos informa sobre los avances contra esas métricas a
las partes interesadas de alto nivel de TI y el negocio.
2.2.3 Gobierno de datos: ¿Qué funciona y que no? por Rob Karel
El Gobierno de Datos no es un concepto nuevo. Profesionales de la gestión del
conocimiento y la información han luchado con la calidad y la confidencialidad en
los datos la mayor parte de la historia de la computación. Lo que ha cambiado en
la última década es la constatación de que los datos no sólo tienen valor dentro de
la aplicación y los usuarios que los capturan, sino en toda la organización también.
Esta demanda de funciones y arquitecturas cruzadas de los mismos datos está
obligando a las empresas y los líderes de TI, por primera vez a reconocer las
dependencias y las percepciones de conflicto de valor de los datos. Muchos
gerentes de información están apostando al gobierno de datos para mitigar el
aumento de estos conflictos. Forrester define la gobernabilidad de datos como:
“El proceso por el cual una organización formaliza el deber fiduciario para la
gestión de los activos de datos críticos para su éxito”.
73
2.2.3.1 Catalizadores de Gobierno de Datos
Las iniciativas comunes de gestión de información que impulsan la necesidad de
un gobierno de datos son: cumplimiento de normas o políticas de uso de los datos,
migración de datos legados, fusiones y adquisiciones, BI operacional, data
warehousing empresarial, IaaS, gestión de datos maestros, gestión de metadatos,
entre otros.
2.2.3.2 Framework de gobierno de datos
Varios roles y responsabilidades deben ser definidos y asignados de forma
apropiada en un programa de gobierno de datos, Forrester en la Figura 1 define
cuatro roles principales para el gobierno de datos:
Figura 17. Roles y responsabilidades [22]
2.2.3.3 Inhibidores de la Adopción de un Gobierno de Datos
Los inhibidores del éxito de un gobierno de datos comúnmente son: falta de
participación del negocio, la falta de un modelo de negocio y ambigüedad en el
retorno de la inversión, alcance poco realista, entre otros.
74
2.2.3.4 Preparación del gobierno de datos
Al momento de diseñar una metodología para gobierno de datos para una
empresa, se deben considerar los siguientes temas:
Evangelización: apoyo ejecutivo y definir el enfoque requerido para empezar.
Alcance: como definir el alcance y enfocarse en los datos más críticos?.
Propiedad: quien debe ser el titular o propietario de los datos críticos?
Programa de Gestión: quien lidera el programa el negocio o IT?
Estructura de la empresa: la empresa es centralizada, descentralizada o mixta?
Dotación de Personal: la dedicación de tiempo de los roles es medio tiempo o
tiempo completo? Existe personal con las capacidades adecuadas?
Financiación: de donde vienen los fondos? O se puede sustentar de un proyecto
ya existente?
Motivador de negocio: cuál es el mejor motivador de negocio que ayude a
construir el caso de negocio para el gobierno de datos?.
Inhibidores: cuales son los principales inhibidores?.
Plazo: la empresa está preparada? Si no es ahora entonces cuando?
2.2.3.5 Diseñe el gobierno basado en la cultura de la empresa
Acéptalo desde el principio: la cultura existente de su empresa no va a cambiar
para apoyar el gobierno de datos, así que en su lugar trabajamos para entender su
cultura y aprovechar sus puntos fuertes. Por ejemplo, en una cultura donde cada
unidad de negocio opera de forma independiente y da prioridad a su propia
dirección estratégica, será apropiado fomentar un enfoque de gobierno de datos
75
descentralizado, donde expertos en la materia en diferentes unidades de negocio
colaboren unos con otros, evitando así un rol de liderazgo centralizado pueda ser
visto como una amenaza.
Iniciar poco a poco e ir creciendo: iniciar un programa de gobierno de datos
como parte de un proyecto financiado por la gestión de datos. Muchas empresas
ponen en marcha el gobierno dentro de un proyecto de BI o DW, una iniciativa
MDM, o dentro de un CRM o ERP.
Definir los patrocinadores ejecutivos y administradores de datos desde el
comienzo y utilizarlos como sus evangelistas: El éxito de los programas de
gobierno de datos puede comenzar como un esfuerzo comunitario, pero no muy a
menudo. La mayoría de las organizaciones requieren de arriba hacia abajo las
prioridades para lograr cambios reales en la gestión y calidad de los datos.
No olvidar el caso de negocio: Usar medidas cualitativas y cuantitativas de las
principales funciones de negocio, tales como marketing, finanzas, ventas
y operaciones de call center, para justificar los programas de gobierno.
Incluir la participación en las metas del empleado: Nada mata a un programa
de gestión de datos más rápido que esperar que la participación voluntaria.
Premiar a los administradores en las evaluaciones de su desempeño mediante el
reconocimiento de su participación y las contribuciones. Y si algunos no colaboran,
escalar a su jefe directo.
Dar Prioridad a un Enfoque Centralizado: las decisiones a nivel corporativo
deben ser manejadas de forma centralizada, pero los datos relevantes para una
sola línea de negocio pueden ser manejados de forma descentralizada.
76
2.2.4 Análisis
Se pueden observar que existen diversas propuestas para gobierno de datos y
muy diversas entre sí, cada propuesta aborda el tema desde perspectivas muy
diferentes y abordan temas igualmente importantes. Los niveles de calificación son
una propuesta de Roger Session para comparar metodologías de AE. Aquí se
utilizaran para evaluar las propuestas de Gobierno de Datos. Los niveles de
calificación son:
1. Hace un trabajo muy pobre en esta área.
2. Hace un mal trabajo en esta área.
3. Hace un trabajo aceptable en esta área.
4. Hace un muy buen trabajo en esta área.
A continuación se realizara una comparación teniendo en cuenta 5 criterios que
son relevantes a la hora de iniciar un proyecto de Gobierno de Datos:
1. Guía Metodológica: se refiere al hecho de proporcionar un proceso paso a
paso principalmente del cómo iniciar e implementar un proyecto de Gobierno
de Datos.
2. Modelo de Madurez: se refiere al hecho de proporcionar un modelo que
permita definir una medida de avance o progreso del Gobierno de Datos en la
empresa.
3. Preparación del Gobierno de Datos: se refiere al hecho de proporcionar
información sobre los aspectos que se deben considerar previamente a iniciar
un esfuerzo formal de implantación de un Gobierno de Datos.
4. Diseño del Gobierno de Datos: se refiere al hecho de proporcionar una forma o
método a seguir para diseñar el Gobierno de Datos.
5. Información disponible y de acceso público: se refiere al hecho de tener
información disponible sin costo alguno. Información completa de la
metodología.
77
CRITERIOS CALIFICACION
Vijay Khatri y Carol V. Brown AIE
Rob Karel (Forrester)
Guía metodología 1 4 2
Modelo de madurez 1 4 1
Preparación 1 1 4
Diseño 1 1 4
Información disponible 3 4 3
Tabla 4.Evaluación de criterios por cada uno de las propuestas de gobierno de datos
En la Tabla 4 se puede apreciar que cada una de las propuestas de Gobierno de
Datos tiene aspectos importantes y también podemos observar que la debilidad de
una es la fortaleza de otra. Uno de los objetivo de este trabajo es proponer un
modelo de referencia para Gobierno de Datos, que agrupe las fortalezas y además
complemente eliminando las debilidades que presentan cada una de las
propuestas evaluadas en la Tabla 4.
78
3. FRAMEWORK DE ARQUITECTURA DE INFORMACION EN UN CONTEXTO
DE ARQUITECTURA EMPRESARIAL (FAI)
Se habla de Arquitectura Empresarial porque corresponde a una forma de
representar una empresa donde se consideran todos y cada uno de los elementos
que la componen, incluyendo la relación entre los principales activos como
procesos, estrategias, datos, aplicaciones y tecnología [27]. En la Figura 18 se
observan las dimensiones que componen una Arquitectura Empresarial y sus
respectivas relaciones:
Figura 18. Dimensiones de AE y sus relaciones [27]
Como se puede apreciar en la Figura 18, la arquitectura de información es uno de
los elementos principales en la arquitectura empresarial donde los datos se ven
como un activo más de la empresa otorgando la importancia que realmente tienen
como recurso estratégico para el negocio. En consecuencia es necesario estudiar
diferentes técnicas y tecnologías de integración de datos, enfoques arquitecturales
y productos que pueden ser utilizados para compartir, intercambiar e integrar
datos e información en las empresas.
79
También se puede observar que la arquitectura de información se relaciona
directamente con el negocio, aplicaciones e infraestructura mediante las
relaciones A, C y D respectivamente. Estas relaciones muestran que la
arquitectura de información debe estar alineada con las otras dimensiones y que
cualquier esfuerzo que se realice a nivel de datos debe responder a necesidades
del negocio o de aplicaciones.
En el análisis del estado del arte se analizaron tres enfoques de arquitectura
empresarial y se enfatizó en el tema de Arquitectura de Información (de ahora en
adelante AI) donde se descubrieron vacíos tales como:
Ausencia de una guía metodológica para el desarrollo de proyectos de AI.
Carencia de un modelo de referencia para la definición del alcance de un
proyecto de AI.
Insuficiencia de los modelos de referencia para la definición de un Gobierno
de Datos.
Insuficiencia de las guías metodológicas para el diseño de Gobierno de Datos.
Falta de un repositorio de recursos para el desarrollo de proyectos de AI.
El objetivo principal de esta propuesta es proponer un framework para el
desarrollo de proyectos de AI, que responda a temas como: una guía metodología
para el desarrollo de proyectos de AI, una guía metodológica para el diseño de
gobierno de datos, definición de un repositorio de recursos para el desarrollo de
proyectos de AI y definición de un repositorio de AI.
Con esta propuesta también se quiere dejara un lado el alto nivel de abstracción
existente en los framework de AE y alcanzar el nivel de detalle necesario que le
permita convertirse en una herramienta de apoyo eficiente para el desarrollo de
proyectos de AI.
Los elementos estructurales de esta propuesta fueron tomados de TOGAF [16] e
IBM [1]. Las etapas como: Preparación, Modelos de Referencia, Estado Actual de
80
AI, Estado Deseado de AI y Mapa de Proyectos, son tomadas del Framework de
arquitectura empresarial TOGAF. Pero las actividades que se deben realizar
dentro de cada etapa son propias de esta propuesta metodológica.
A continuación se detalla el contenido de cada una de las secciones de este
capítulo:
En la sección 3.1 se presentan los elementos estructurales del FAI y se hace una
descripción global de cada uno.
En la sección 3.2 se describe y explica paso a paso las metodologías propuestas
para el proyecto inicial y para gobierno de datos. La metodología para proyectos
particulares no está dentro del alcance de este trabajo, pero se hace una
descripción global.
3.1 Elementos estructurales del framework
Consta de tres elementos principales que son el repositorio de recursos, el
repositorio de arquitectura y las metodologías. En la Figura 19 se muestran los
elementos estructurales.
Figura 19. Elementos estructurales del framework de AI
81
Los recursos como modelos de referencia, herramientas tecnológicas, plantillas,
matrices, métodos de calidad de datos, técnicas de integración de datos, entre
otros, son utilizados por las metodologías para el desarrollo del proyecto inicial, los
proyectos particulares y el proyecto de gobierno de datos. Las metodologías
también crean y consultan artefactos del repositorio de arquitectura que son
generados por proyectos finalizados o proyectos en curso de AI.
El principio para organizar el FAI en los elementos estructurales presentados en la
Figura 19 fue tomado de TOGAF, donde se habla de repositorios de arquitectura
que son consumidos durante el desarrollo de las AI, bien sea para consultar, editar
o crear recursos.
3.1.1 Repositorio de recursos
La principal ventaja de crear un repositorio de recursos es poder gestionar, difundir
y facilitar el acceso a material técnico con información de interés para el desarrollo
de proyectos de AI. Una propuesta de lo que se debe encontrar en el repositorio
de recursos es:
Modelos de referencia
o Dominios de datos
o Gobierno de datos
o Alcance de proyectos de AI
o Modelos de madurez
Matrices
Plantillas
Método para calidad de datos
Herramientas tecnológicas
Diagramas
o Modelo conceptual
82
o Ciclo de vida de los datos
o Diseminación de datos
Principios de datos
Enfoques arquitecturales para MDM
Técnicas de integración de datos
Los recursos que aparecen de color negro en la Figura 20, son propuestas que
surgen como producto del análisis de los frameworks de AE en el tema de AI y
que llegan a cubrir varios de los vacíos que presentan estos frameworks.
Figura 20. Repositorio de recursos de AI
83
3.1.2 Metodologías
Se plantean 3 metodologías que se deben considerar en un trabajo de AI. Cada
una de las metodologías consta estructuralmente de una serie de pasos o
actividades que se desarrollan de forma ordenada e iterativa. Por cada actividad
se describe cuáles son las entradas necesarias para la ejecución, cuales son los
roles involucrados y cuáles son los artefactos que produce. En la Figura 21 se
presentan las tres metodologías que hacen parte del FAI.
Figura 21. Metodologías para Proyectos de AI
Estas tres metodologías nacen como producto del análisis de la revisión
bibliográfica, donde se identificó principalmente el vacío de guías metodológicas
con el detalle necesario para facilitar el desarrollo de las AI.
3.1.3 Repositorio de arquitectura
La ejecución de cada una de las metodologías durante el desarrollo de los
proyectos involucrados en la AI, producirá una serie de artefactos como resultado
de los esfuerzos realizados en la ejecución de las actividades propuestas por cada
una de las metodologías. Estos artefactos deben ser almacenados en un
repositorio de arquitectura y TOGAF proporciona un modelo de cómo se debe
84
estructurar y almacenar los artefactos producidos de forma consistente y
estructurada.
El alcance de este trabajo no cubre una descripción y explicación detallada sobre
el repositorio de arquitectura. Pero en TOGAF [16] se puede encontrar mayor
información al respecto.
3.2 Metodologías
En esta sección se describen las tres metodologías que guían paso a paso el
desarrollo de un proyecto de AI. A continuación se describe el contenido de esta
sección:
En la sección 3.2.1 se describe la metodología que se debe seguir en el proyecto
inicial de una AI. Se describen los elementos estructurales de la metodología y las
actividades que los conforman.
En la sección 3.2.2 se describe la metodología que se propone para el diseño y
gestión de un gobierno de datos.
La guía metodología para el desarrollo de los proyectos particulares no está en el
alcance de este trabajo.
3.2.1 Guía Metodológica para el proyecto inicial
El objetivo principal del proyecto inicial es conocer la empresa y entender sus
procesos de negocio, cómo genera valor, cuáles son sus clientes, identificar cual
es la situación actual de los datos en la empresa, cuáles son las necesidades y
situación deseada que demanda el negocio. Además se debe crear un mapa de
proyectos priorizados que permita superar la brecha que existe entre la situación
actual y la deseada.
85
En la elaboración de esta guía metodológica se tomaron elementos de los
frameworks de AE Zachman, FEAF, TOGAF, la propuesta de IBM y también
propuestas originales.
3.2.1.1 Elementos estructurales
En la Figura 22 se muestran los elementos estructurales de la propuesta
metodológica. La primera etapa se realiza una vez y después se ejecutan las
demás etapas iterativamente durante el trabajo de AI. Aunque el proyecto inicial es
uno solo, este se puede dividir en varias etapas que cubren temas específicos
como: dimensiones de datos, dimensiones de calidad de datos, seguridad de los
datos y gobierno de datos.
Figura 22. Elementos Estructurales Metodología Proyecto Inicial
86
3.2.1.2 Desarrollo metodológico
Esta propuesta plantea una secuencia metodológica de 4 etapas (ver Figura 22)
que se aplican al proyecto inicial de AI. Para cada una de las etapas se plantea
una serie de actividades que guían un desarrollo ordenado y estructurado.
También se sugiere el uso de algunas herramientas con fines específicos. Cada
usuario está en libertad de extender o adaptar la metodología según sus
necesidades. Se recomienda que los artefactos generados en cada una de las
actividades sean almacenados en un repositorio empresarial.
El principio para definir las cuatro etapas de Preparación, Estado Actual, Estado
Deseado y Mapa de Proyectos de forma muy general, se toma de TOGAF y FEAF.
Preparación
Como se ilustra en la Figura 23, la etapa de Preparación es el primer paso en la
metodología del proyecto inicial. Este paso dará la orientación que se necesita
para conocer el contexto de la empresa.
Figura 23. Etapa de preparación de la metodología del proyecto inicial
87
En esta etapa se debe tener un primer acercamiento mediante una reunión que
formalice el inicio del proyecto y se presente cada uno de los involucrados en el
proyecto de AI.
El objetivo principal es conocer la empresa y su modelo de negocio, identificando
su naturaleza, a través de su misión, visión, organigrama, motivadores y
estrategias de negocio. En esta etapa es importante identificar dentro de la
empresa los grupos de trabajo implicados en la AI y que apoyaran el grupo
responsable de la AI. También se debe definir el alcance de la AI y las
herramientas y técnicas que deben ser utilizadas. Las actividades a realizar se
muestran en la Figura 24.
Figura 24. Actividades en la etapa de preparación
La etapa de preparación se empieza explicando cuales son los grupos de trabajo
que se deben crear dentro de la empresa para apoyar el desarrollo de la AI. Se
continua con la explicación de lo que se debe hacer para conocer el contexto de la
organización o empresa. Posteriormente se explican tres actividades
complementarias que no tienen un orden de ejecución ni dependencia. En el
Alcance de AI se explica cómo definir el alcance de una AI. En la actividad de
Modelos de Referencia se proponen varios modelos de referencia que apoyaran el
88
desarrollo de la AI y en la actividad de Herramientas y Técnicas se describen
diversas herramientas tecnológicas y técnicas de modelamiento de datos que
existen y ayudaran a entender la complejidad de los datos empresariales.
Grupos de Apoyo
Entradas: Organigrama
Salidas: Definición de grupos de Apoyo.
En esta actividad se identifican los actores a diferentes niveles dentro de la
empresa y que tienen una relación directa con el desarrollo del proyecto de AI. El
objetivo es clasificarlos en grupos de trabajo con responsabilidades definidas
dentro del proyecto de AI, cada uno de estos grupos es un elemento que conoce
el funcionamiento de la empresa desde su perspectiva, ya sea a nivel estratégico,
negocio o técnico.
Los grupos de trabajo apoyaran al grupo de AI a levantar y validar la información
de cómo la empresa funciona en su estado actual, de cuáles son sus motivadores
de negocio, de cómo se visualiza la empresa en un futuro cercano.
Figura 25. Grupos de trabajo
Grupo estrategico
Grupo de negocio
Grupo de arquitectura
89
Los grupos de trabajo o apoyo tienen su origen en la propuesta de IBM, donde
recomienda definir organizacionalmente una estructura con responsabilidades
claras para el desarrollo de una AI.
Grupo estratégico: conformado por los altos ejecutivos de la organización, como
el CEO, FEO, CIO y los dueños de cada uno de los temas estratégicos, como el
aspecto financiero, relación con el cliente y ejecución de procesos principales.
Este grupo es responsable de promover la ejecución de los procesos estratégicos
y lideran el cambio positivo al interior de la organización, mostrando de esta forma
su nivel de compromiso con las metas planteadas.
La responsabilidad de este grupo de apoyo es ayudar al grupo de AI a conocer la
empresa e identificar el modelo de negocio. Para esto es importante suministrar la
información disponible que se encuentre en documentos oficiales de la empresa.
Si no existe la información disponible formalmente en documentos, se debe
programar reuniones, para realizar el levantamiento respectivo de la información
necesaria.
Grupo de negocio: este grupo está integrado por los líderes de las unidades de
negocio, usuarios dueños de procesos y analistas con un alto nivel de experiencia
del negocio y de las operaciones que se realizan. Son quienes en realidad
conocen como funciona la organización.
La responsabilidad de este grupo en el proyecto de AI, es suministrar la
información necesaria para identificar y modelar los procesos de negocio, que
representan la operación diaria del negocio. Esto es vital para poder identificar la
situación actual de la empresa.
Grupo de Arquitectura: los miembros de este grupo conocen a fondo los
recursos de tecnología disponibles en la organización, además de identificar las
tecnologías de información que pudiesen ser adoptadas, para obtener un impacto
positivo en las operaciones que se realizan. El grupo de apoyo está encabezado
90
por los arquitectos empresariales, seguido por quienes ejecuten las funciones de
arquitecto de software, ingeniero de software, arquitecto de datos, data stewart,
stewarship, líder de infraestructura, entre otros.
Con la ayuda de este grupo se debe poder identificar cuáles son los recursos
tecnológicos que se utilizan para apoyar el negocio, específicamente en cada uno
de sus procesos y como éstos recursos soportan los motivadores y estrategias de
negocio.
Conociendo la Organización
Entradas: Misión, visión, organigrama, listado de motivadores, estrategias de
negocio, cadena de valor y canvas.
Grupos de apoyo: estratégico y negocio.
El trabajo en esta actividad consiste en identificar y estudiar la entradas, utilizando
como fuente principal de información el grupo estratégico. La forma de solicitar la
información puede ser directamente, concertando una cita y/o solicitud mediante
un e-mail. La primera vez es recomendable concertar una cita para efectos de
presentación e identificación de los integrantes de los grupos de trabajo,
posteriormente las solicitudes se pueden hacer por medio electrónico y/o también
realizar reuniones cuando sea necesario para aclarar y validar información.
Uno de los objetivos de la misión es definir la razón de ser de la empresa y que
producto o servicio ofrece a sus clientes. La misión es importante porque sirve de
guía para el desarrollo de cualquier actividad en la operación del negocio. La
visión define las metas a mediano y largo plazo de la empresa, además establece
el nivel de posicionamiento en el mercado o de reconocimiento por sus clientes. El
organigrama es un medio grafico que permite tener un conocimiento general de
91
cómo se encuentra estructurada la empresa y de cómo se encuentran definidos
los niveles de responsabilidad y mando.
Los motivadores permiten conocer las razones del cambio o del porque la
empresa desea emprender los proyectos de AI y la estrategia de negocio
proporciona la dirección y descripción de cómo una empresa quiere lograr su
visión de negocio en un plazo determinado y la forma como se puede lograr
mediante una serie de actividades claves. Es el “Que y Como”. La estrategia de
negocio es importante para la arquitectura a corto y largo plazo porque brinda un
marco de referencia para evaluar como la arquitectura debe apoyar o alinearse
con la estrategia de negocio.
En el anexo N° 2 se encuentra información relacionada con el canvas.
Alcance de la AI
Salida: Alcance del proyecto de AI.
Grupos de apoyo: Estratégico y Negocio.
Pensar en realizar un trabajo de arquitectura sobre todos los datos de una
empresa es una aventura épica y con una probabilidad de riesgo bastante alta
para el fracaso del proyecto. En la Figura 6 se propone un modelo de referencia
para definir el alcance de un proyecto de AI.
Este modelo toma el paradigma de diseño de algoritmos llamado divide y vencerás
y lo aplica a la solución de un problema de arquitectura de datos: el algoritmo
consiste en la solución recursiva de un problema (datos empresariales)
dividiéndolo en varios sub-problemas (proyecto inicial y proyectos particulares) y al
final la solución de cada uno de los proyectos se combinan para dar una solución
al problema original [28]. La principal ventaja de esta estrategia es realizar varios
proyectos donde los resultados se reflejen a corto plazo.
92
Figura 26. Modelo para definir el alcance de la AI
Para definir el alcance de un proyecto de AI se aborda el problema desde dos
dominios: datos analíticos y datos operacionales. Los datos maestros y los
metadatos no son explícitos porque se considera que los metadatos y los datos
maestros, aunque se trabajan de forma independiente, intervienen directamente y
son considerados de forma implícita dentro de los datos operacionales y
analíticos.
Lo primero que se debe hacer en AI para el dominio de datos operacionales es
realizar un proyecto inicial. El objetivo principal del proyecto inicial es conocer la
empresa y entender sus procesos de negocio, como genera valor, cuáles son sus
clientes. También en este proyecto se identifica cual es la situación actual de los
datos en la empresa, cuáles son las necesidades y situación deseada que
demanda el negocio. Además se debe crear un mapa de proyectos priorizados
que permita superar la brecha que existe entre la situación actual y la deseada.
93
El mapa de proyecto da origen a los proyectos particulares que son abordados
desde tres perspectivas: datos maestros, datos transaccionales y datos no
estructurados. Para los datos maestros pueden surgir también varios proyectos,
donde cada proyecto se puede realizar para un dato maestro (cliente, proveedor,
producto) en particular o para un grupo y cada uno de estos proyectos particulares
puede abordar aspectos de calidad, seguridad, gestión, migración o integración.
Para los datos transaccionales también se pueden considerar los mismos
aspectos referidos para datos maestros, pero si se debe hacer claridad y enfatizar
principalmente en la solución de problemáticas como: datos que se necesitan y no
están completos o no se encuentran, datos con múltiples fuentes de datos,
asegurar una sola fuente de datos con información correcta, datos que no son
necesarios, datos que no son creados, datos que no son consumidos y datos que
no se encuentran donde se necesitan.
En este trabajo se propone una guía metodológica para el desarrollo del proyecto
inicial y otra guía metodológica para el desarrollo de los proyectos particulares. La
guía metodológica explica detalladamente que actividades se deben ejecutar para
el desarrollo de cada uno de los proyectos.
En este trabajo el alcance no cubre el desarrollo de proyectos de datos analíticos,
porque ya existe una metodología bastante madura propuesta por Ralph Kimball.
La propuesta de este modelo de referencia es original, producto del trabajo
realizado.
Modelo de referencia de información empresarial
Como se puede apreciar en la Figura 27, esta propuesta divide los datos
empresariales en 5 dominios que permiten visualizar los datos existentes en una
empresa desde 5 grandes perspectiva que son importantes en el momento de
definir el alcance de una AI.
94
Iniciar un proyecto de AI sobre todos los datos de una empresa es un esfuerzo
muy costoso financieramente, y los resultados o retorno de la inversión se
reflejarían a largo plazo y esto puede llevar al fracaso del proyecto. Si
visualizamos los datos de una empresa desde 5 dominios, estaríamos partiendo
desde uno de los más importantes paradigmas de diseño de algoritmos llamado
divide y vencerás, que consiste en la solución recursiva de un problema
(Información empresarial) dividiéndolo en varios subproblemas (dominios de
datos) y al final la solución de cada uno de los subproblemas se combinan para
dar una solución al problema original [28].Esta es una forma de realizar proyectos
donde los resultados se reflejen a corto plazo.
Como referencia para los dominios de información en una empresa, se tomó el
modelo definido en [1] donde definen los 5 dominios de datos.
Figura 27. Dominios de Datos Empresariales
En [1] se puede consultar más información sobre cada uno de los dominios de
datos.
Datos Analíticos
Datos Operacionales
Datos Maestros
Metadatos
Datos No Estructurados
95
Modelo de referencia de gobierno de datos
Así como existe gobierno para recursos humanos, financieros, para activos fijos y
corrientes, gobierno de tecnología y de sistemas de información, donde el objetivo
principal es generar confianza entre los diferentes actores como empleados,
socios, proveedores, clientes y demás, se hace necesario definir un gobierno que
le permita a la empresa ver a los datos como un activo más de la empresa y le dé
la importancia que realmente tienen los datos como recurso estratégico para el
negocio y que le permita tener a disposición información de calidad, suficiente y
oportuna.
El gobierno de datos permite a una empresa definir principios, procesos,
estándares, técnicas de integración, enfoques arquitecturales, quiénes (roles) y
responsabilidades, que garanticen la toma de decisiones correctas de los
diferentes actores o usuarios de los datos a cualquier nivel de la empresa y esto
solo se puede cumplir si se cuenta con datos e información oportuna y con altos
estándares de calidad. El fundamento principal de esta propuesta para gobierno
de datos, es proponer un enfoque fraccionado e iterativo que permita a la empresa
centrarse en los problemas fundamentales y guie la toma de decisiones que
deben ser ejecutadas. Se propone el siguiente (ver Figura 28)modelo de
referencia donde se consideran los principales temas que se deben abordar en un
gobierno de datos:
Diseño Organizacional
Principios de Datos Roles y Responsabilidades
Seguridad y
Privacidad
Dominios de Datos Calidad de Datos
Métricas
Figura 28. Gobierno de Datos Modelo de Referencia
96
En la Figura 28 se observan los 7 temas que aborda el modelo de referencia
propuesto para gobierno de datos, a continuación se describe cada uno:
Diseño organizacional: en [22] habla del diseño de gobierno de datos donde se
deben considerar aspectos como: evangelización, alcance, propiedad de los
datos, gestión del proyecto, dedicación de tiempo de los roles, financiación,
motivador de negocio, inhibidores y principalmente conocer la cultura de la
empresa para conocer su forma de operar, que puede ser centralizada,
descentralizada o mixta. Entonces en una cultura donde cada unidad de negocio
opera de forma independiente y da prioridad a su propia dirección estratégica,
será apropiado fomentar un enfoque de gobierno de datos descentralizado [22]. Es
de aclarar que aunque los datos relevantes para una línea de negocio pueden ser
manejados de forma centralizada, las decisiones a nivel corporativo deben ser
manejadas de forma centralizada.
Principios de datos: Los principios de datos según [16] nos permiten comunicar
al negocio cuales son las medidas establecidas sobre los datos, que los definen
como un activo para la empresa. La importancia radica en las políticas, normas y
directrices que fomentan y establecen la forma de compartir y reusar los datos a
nivel empresarial. Los principios de datos sugeridos son los establecidos según
[16]: Los datos son un activo, los datos son compartidos, los datos son accesibles,
vocabulario y definición de datos común, los datos son gestionados y los datos
son protegidos. Aquí se referencian varios principios de datos, pero es decisión del
usuario tomar éstos como una referencia y utilizarlos o crear sus propios principios
de datos.
Roles y responsabilidades: La organización de gobierno de datos debe construir
un modelo para dirigir sus operaciones, y para asegurar quien tiene la autoridad
suficiente para actuar como árbitro en situaciones críticas [1]. En consecuencia,
varios roles y responsabilidades deben ser definidos y asignados de forma
apropiada en un programa de gobierno de datos, en [22] se definen cuatro roles y
97
sus principales responsabilidades para un gobierno de datos: el patrocinador
ejecutivo, el director del programa de gobierno de datos, un director representante
del negocio y un director representante del área de IT.
Seguridad y privacidad: según [1] en este tema se debe lidiar con algunos retos
comunes de seguridad de datos, desafíos de privacidad y que debe incluir la
respuesta a los siguientes interrogantes:
¿Dónde está nuestra información confidencial?
¿La organización ha enmascarado sus datos confidenciales en los entornos
que no son de producción (desarrollo, pruebas y capacitación) para cumplir con
las regulaciones de privacidad?
¿Están los controles de auditoría de base de datos en el lugar para evitar el
acceso de los usuarios privilegiados, por ejemplo como: administradores de
bases a los datos privados, como los sueldos de los empleados y listas de
clientes?
Dominios de datos: para dominios de datos ver en este documento la sección de
Modelo de referencia de información empresarial.
Calidad de datos: La calidad de los datos se refiere a la capacidad que tienen los
datos para satisfacer los requerimientos de uso dentro de la empresa. La calidad
de los datos tiene múltiples dimensiones como: precisión, oportunidad, integridad,
credibilidad, entre otros. Ver [29] para más información sobre dimensiones y
métricas. Estas dimensiones son relativas y deben ser definidas de acuerdo al
contexto de uso de los datos [18]. En este documento en la sección de Análisis de
la información, se propone un método de calidad de datos que consiste en un
proceso iterativo y continúo para alcanzar la calidad de datos.
Métricas: Es importante que el gobierno de datos cuente con indicadores sólidos
para medir y monitorear el progreso. El equipo de gobierno de datos debe
98
reconocer que cuando se mide algo, mejora el rendimiento. Como resultado, el
equipo de gobierno de datos debe recoger unos pocos indicadores principales de
rendimiento (KPIs) para medir el desempeño continuo del programa [1]. Aquí se
debe realizar un diagnóstico que ayude a medir la calidad actual de la información
crítica, identificando donde se encuentran los mayores problemas y priorizando las
áreas con las que hay que abordar primero en el proyecto de AI. Para mayor
detalle ver en la sección de repositorio de recursos el método de calidad de datos.
Como complemento del modelo de referencia, se presenta una metodología para
el diseño y gestión del gobierno de datos en la sección 3.2.2.
Este modelo de referencia es producto de la revisión y análisis del estado del arte
para el tema de gobierno de datos. Aquí se toman elementos de las tres
propuestas analizadas.
Herramientas Tecnológicas y Técnicas de Modelamiento
Es importante, seleccionar herramientas y técnicas de modelamiento que permitan
mitigar la creciente complejidad de las fuentes de datos y el contexto de las
empresas. Los arquitectos de datos enfrentan desafíos únicos y uno de los más
grandes es adquirir una comprensión minuciosa de la gran cantidad de datos
atesorados de la empresa y cómo están relacionados entre sí. El correcto
modelado es esencial si se está realizando un trabajo de arquitectura desde el
principio o sobre fuentes de datos existente, porque este impactará directamente
la calidad de los datos.
Las herramientas para el trabajo de AI deben permitir principalmente lo siguiente:
crear modelos de datos conceptuales y físicos.
explorar y visualizar la estructura de las fuentes de datos.
Relacionar fuentes de datos.
comparar estructuras de fuentes de datos.
99
Descubrir similitudes entre fuentes de datos.
Analizar modelos y fuentes de datos para validar estándares.
En el anexo N° 3 se presentan varias soluciones que existen en el mercado y que
facilitan las actividades a desarrollaren una AI.
En las técnicas de modelamiento se encuentran los diagramas que son la
representación conceptual y grafica de los datos de una empresa. Los diagramas
facilitan la comprensión de los datos más importantes, desde cómo se relacionan,
cuáles son sus características, como se almacenan y cuál es su ciclo de vida. Es
por esto que es importante definir las técnicas apropiadas de modelamiento de
datos que se usaran durante la captura, modelamiento y análisis de datos. En el
anexo N° 4 se presentan algunas técnicas de modelamiento.
El principio de esta actividad es tomado de TOGAF, pero se extiende en este
trabajo.
Estado Actual de Arquitectura de Información
Figura 29. Etapa de Estado Actual de la metodología del proyecto inicial
100
Como se ilustra en la Figura 29, la etapa de Estado Actual es el segundo paso en
la metodología del proyecto inicial. Esta etapa dará la orientación que se necesita
para conocer el estado actual de la información en la empresa.
El objetivo fundamental de esta etapa es proporcionar una descripción del estado
actual de los datos en la empresa, proporcionando una vista de los elementos que
son parte de la AI y de cómo se relacionan e interactúan entre sí y con elementos
externos para soportar la operación del negocio. Para esta etapa se propone una
serie de 7 actividades como se muestra en la Figura 30.
Figura 30. Actividades de la etapa de Estado Actual
En la etapa del estado actual se empieza con el tema de las Entrevistas, donde se
habla de las entrevistas como una herramienta que ayuda a entender y conocer la
situación actual de los datos y también permite conocer que problemáticas existen
relacionadas con los datos y cuales es el estado deseado de los datos.
101
Posteriormente se tienen dos actividades que son: la actividad de Procesos de
Negocio y la actividad de Entidades de Negocio. Estas dos actividades se pueden
hacer en paralelo o se puede continuar con alguna de las dos, para efectos de
este trabajo se recomienda empezar procesos de negocio. En la actividad de
procesos de negocio, principalmente se debe conocer y entender los procesos de
negocio involucrados en la AI. En la actividad de Entidades de Negocio la tarea
principal es identificar las entidades de negocio y su relación con los procesos de
negocio. En la cuarta actividad se habla del Modelo Conceptual de datos que
corresponde a la descripción de cómo las entidades de negocio se relacionan e
interactúan entre sí. Seguidamente se tienen dos actividades (5ª y 6ª) que
tampoco tienen un orden de ejecución. En la actividad Gobierno de Datos el
objetivo es identificar que existe actualmente en la empresa en el tema de
Gobierno de Datos y en la actividad Fuentes de Datos la principal motivación es
conocer la situación actual de las diversas fuentes de datos que existen en la
empresa y como estas se relacionan o integran para soportar el negocio. Por
último se tiene una 7ª actividad que corresponde al Análisis del Estado Actual de
AI.
Entrevistas
Salidas: Acta de entrevista, documento o grabación con la información capturada
en la entrevista.
Grupo de apoyo: Estratégico y/o Negocio.
El objetivo principal de las entrevistas es servir como una herramienta que ayude
al grupo de AI a entender el negocio, conocer la situación actual y futura según los
requerimientos del negocio capturados en cada sesión de entrevista. Para esto se
recomienda seguir los siguientes pasos:
102
Paso 1: Realizar una primera entrevista que reúna a los integrantes de los grupos
de trabajo definidos en la etapa de preparación y el grupo directamente
responsable de la AI. Aquí se deben tratar temas como:
Presentación de los involucrados en el proyecto de AI.
Conocer el negocio: ver en la etapa de preparación la actividad de Conociendo
la Organización.
Comunicar el alcance del proyecto.
Definir representantes de cada grupo y del proyecto de AI, estas personas
serán las encargadas de gestionar la agenda de entrevistas.
Paso 2: Previamente a cada una de las siguientes entrevistas se debe tener en
cuenta los siguientes temas:
Enviar documento formal de la información capturada en la entrevista
inmediatamente anterior, para su respectiva validación y certificación por el
grupo de apoyo correspondiente.
Enviar agenda de los temas a tratar en la entrevista. Por cada tema se
recomienda también enviar una especie de cuestionario, que le permita al
entrevistado prepararse para la entrevista. Esto también permite que el
desarrollo de la entrevista sea planeado, se capture la información pertinente y
se optimice el tiempo empleado en la entrevista.
Paso 3: Definir claramente el líder de la entrevista, esta persona debe pertenecer
al grupo responsable del desarrollo del proyecto de AI y es la persona responsable
de la ejecución del cuestionario que cubrirá los temas a tratar, previamente
enviados al entrevistado.
Paso 4: Capturar las memorias de la entrevista. Se recomienda que cada una de
las entrevistas se grabe preferiblemente en video o en su defecto solo voz. Esto
ayudara a capturar la información sin traumatismos que puede traer el capturar la
103
información manualmente, además también se puede posteriormente analizar n
veces la entrevista y extraer la información.
Para las entrevistas se proponen dos plantillas, ver Anexo N° 5 y Anexo N° 6,
donde se muestra un formato para el acta de entrevistas y un formato para
registrar tareas pendientes definidas y que se deben realizar después de la
entrevista. Una de estas tareas puede ser enviar un correo con documentación
referente al tema de la entrevista.
El origen para proponer una actividad para entrevistas es tomado de la
metodología Kimball.
Procesos de Negocio
Entradas: Procesos de negocio, información de las entrevistas.
Salidas: Entendimiento de los procesos de negocio por parte del grupo de AI.
Aquí el grupo de AI debe reunirse y analizar la información capturada en las
entrevistas y los procesos de negocio, con el objetivo de asegurar que todo el
grupo de AI comprenda la operación del negocio y específicamente de los
procesos que estarán involucrados en la AI de acuerdo al alcance definido
previamente.
El principio de esta actividad es tomado de TOGAF y la metodología Kimball.
Entidades de Negocio
Entradas: Información capturada en las entrevistas.
Artefacto: matriz Procesos de negocio vs Entidades.
Grupos de trabajo: Negocio y Arquitectura.
104
Para identificar las entidades de negocio, se debe entender el contexto de la
empresa a través de sus procesos de negocio. Por cada proceso se deben
identificar cuáles son los objetos que pueden existir y de los cuales se desea
persistir o se persiste información. Aquí se sugiere utilizar la
Plantilla 1. Procesos vs Entidades donde se identifica cada uno de los procesos y
se cruzan con las entidades de negocio. La información que tiene la plantilla es
solo para dar un ejemplo de cómo se diligencia
PROCESOS / ENTIDADES Producto Cliente Proveedor Empleado Almacén Promoción
Ventas X X
X X X
Compras X
X X X
Inventario X
X
Plantilla 1. Procesos vs Entidades
Esta plantilla proporciona un espacio para relacionar de forma escrita y grafica los
procesos de negocio con las entidades de negocio. Esta plantilla se llena como
producto del análisis de las entrevistas realizadas para entender el negocio desde
la perspectiva de los datos.
El tema de entidades de negocio es tomado de Zackman, TOGAF e IBM.
Modelo Conceptual
Entradas: reglas de negocio,
Plantilla 1. Procesos vs Entidades.
105
Artefactos: diagrama del modelo conceptual, descripción y glosario de las
entidades de negocio.
Grupos de trabajo: Negocio y Arquitectura.
El modelo conceptual representa el primer nivel de abstracción sobre las
entidades de negocio, desde el punto de vista funcional de la empresa. Este
permite representar gráficamente las reglas del negocio las cuales se traducen en
la forma como las entidades de negocio se relacionan entre sí.
Figura 31 Modelo Conceptual nivel 0 [23]
Cuando se trabaja bajo el análisis conceptual de una situación, nos referimos a la
abstracción de hechos reales de los cuales se emite un concepto o es posible
106
hacer una idea de ello. Para poder realizar la abstracción de un tema en un área
específica, es necesario tener los requerimientos formulados por los usuarios con
respecto a este. Estos requerimientos contienen el conjunto de hechos, términos
y reglas de negocio que dan pauta a la creación del modelo conceptual donde por
medio de este se podrá realizar una descripción de alto nivel de las fuentes de
datos actuales o futuras. Para manipular este esquema se utiliza un modelo
conceptual que proporciona un lenguaje que permite utilizar un conjunto de
símbolos (estándares) para la creación de este.
La Figura 31 presenta a modo de ejemplo un modelo conceptual que hace parte
del caso de estudio que se verá en el capítulo 4:
Una vez realizado el trabajo de identificar las entidades principales y de generar el
modelo conceptual, se debe realizar una descripción detallada de cada una de las
entidades y sus respectivas relaciones. Para esto se sugiere utilizar la Plantilla 2.
La información en la plantilla hace parte del caso de estudio que se verá en el
capítulo 4. Esta plantilla se crea como una herramienta que permite registrar
información de forma ordenada y estructurada de cada una de las entidades de
negocio identificadas. La información incluye definición, descripción general,
entidades hijas y entidades relacionadas.
107
Plantilla 2. Descripción de una entidad de negocio [23]
El tema de modelo conceptual es originalmente tomado de TOGAF y Zachman.
Fuentes de Datos
Entradas: documentación y/o trabajos previos si existen, información capturada en
las entrevistas.
Artefacto: Inventario de las fuentes de datos, matriz de Fuentes de datos vs
Entidades de negocio, diagrama de ciclo de vida y diagrama de diseminación de
datos.
Grupos de trabajo: Arquitectura.
108
La tarea en este punto es consultar con el grupo de arquitectura y buscar dentro
de la organización si existe algún inventario realizado previamente sobre las
diferentes fuentes de datos existentes. Si ya existe se debe validar si se encuentra
sincronizado con la última versión de cada fuente de datos, caso contrario se debe
actualizar. Si no existe ningún trabajo o inventario realizado, se debe construir un
inventario de las fuentes de datos principales o importantes para el trabajo que se
está realizando. Seguir la Plantilla 3para realizar el inventario.
Adicionalmente se recomienda tener en cuenta los siguientes aspectos:
Identificar fuentes de datos principales: sobre el inventario de las fuentes de
datos, se debe aplicar un filtro para identificar las de mayor relevancia para el
desarrollo del proyecto de AI. Se deben seleccionar las fuentes de datos que
soportan la operación del negocio (procesos misionales) y gestionan los datos
maestros. Las fuentes de datos que soportan el funcionamiento u operación de
alguna aplicación específica deben ser descartadas.
La Plantilla 3 permite documentar mediante información detallada cada una de las
fuentes de datos e incluye información sobre su identificación, descripción,
tamaño, numero de tablas, número de procedimientos almacenados, numero de
vistas y numero de disparadores. En la Plantilla 3 se observa un ejemplo con la
información que se debe incluir. La información en la plantilla hace parte del caso
de estudio que se verá en el capítulo 4.
109
Plantilla 3. Inventario de Fuentes de Datos [23]
Matriz de relación entre Entidades de Negocio vs fuentes de datos: esta
matriz sirve como herramienta de análisis para identificar temas como:
Cuáles son las Entidades con mayor número de relaciones respecto a las
fuentes de datos. Estas entidades son críticas para el funcionamiento de la
empresa.
Cuáles son las fuentes de datos con mayor concentración de Entidades
principales. Con esto identificamos cuales son las fuentes de datos
fundamentales para el funcionamiento del negocio.
Entidades que fueron identificadas a nivel de negocio pero que no tienen
representación explicita sobre ninguna fuente de datos. Puede suceder que
dicha entidad exista sobre alguna o varias fuentes de datos, con nombres
110
diferentes. Por ejemplo, conceptualmente la entidad Persona no existe
explícitamente sobre alguna fuente de datos, pero para una fuente de datos
puede existir como empleado y para otra como afiliado, esto es importante
para el análisis posterior.
La Plantilla 4proporciona un espacio para registrar de forma escrita y grafica la
relación que existen entre las fuentes de datos y las entidades de negocio. La
importancia de esta plantilla se explica más adelante, cuando es utilizada en el
estado actual. La información en la plantilla hace parte del caso de estudio que se
verá en el capítulo 4.
Plantilla 4.Entidades de Negocio vs Fuentes de Datos [23]
Diagrama de diseminación de datos: este diagrama (ver Anexo N° 4) permite
visualizar la relación y/o dependencia entre las entidades de negocio, las
funcionalidades de negocio y las fuentes de datos, ver figura 1. De esta forma
podemos tener una visión general del estado actual de los datos respecto a las
fuentes donde se encuentran almacenados, además de visualizar el cómo
cooperan estas fuentes de datos entre sí para dar soporte al negocio.
Diagrama de ciclo de vida de los datos: Este diagrama (ver Anexo N° 4) ayuda
a identificar las necesidades de datos comunes que tiene el negocio y será el
punto de partida para diseñar fuentes de datos comunes que permitan compartir
recursos de datos. Este diagrama brinda una visión global de todos los actores del
Fuentes de datos PERSONA AFILIACION RECAUDOHISTORIA
LABORAL
BONO
PENSIONAL
RECONOCI-
MIENTO
PAGO
PRESTACIONES
CUOTAS
PARTES
PENSIONALES
CUOTASCOBRAR X X X
CUOTASPAGAR X X X
DB_COBRAR Ver Nota 2 X X
DEVOLUCIONES X X X
GPROC X
HISTLAB X X X
Entidades de Negocio
111
sistema que realizan operaciones sobre los datos, operaciones tales como
creación, consulta, actualización y borrado.
El tema de fuentes de datos es originalmente tomado de TOGAF y Zachman
Gobierno de Datos
Entrada: modelo de referencia de gobierno de datos.
Artefacto: plantilla de gobierno de datos.
Grupos de apoyo: estratégico, negocio y arquitectura.
El objetivo principal en esta actividad es identificar el estado actual del gobierno de
datos. Como diseñar y gestionar un gobierno de datos se trata en la sección 3.2.2.
Tomando el modelo de referencia de gobierno de datos (ver Figura 28) y la
plantilla definida para gobierno de datos (ver Plantilla 5), en este paso se debe
hacer un levantamiento de información, para entender e identificar lo que se tiene
implementado de gobierno de datos en la empresa.
Con los grupos de apoyo a través de entrevistas o reuniones, se debe identificar:
Si en la empresa se tienen definidos claramente cada uno de los criterios
propuestos para gobierno de datos.
Para cada Rol que se encuentre definido, cuales son las responsabilidades
definidas y que tipos de decisiones se toman.
Puede suceder que los roles no estén definidos tal como lo estipula el modelo
de referencia, pero si existan las responsabilidades en otros roles diferentes a
los mencionados por el modelo de referencia. También puede pasar que una
persona asuma las responsabilidades de varios roles.
Puede suceder también que la guía metodológica no sea exactamente igual al
modelo de referencia, pero se debe documentar también utilizando los
112
comentarios o las observaciones si existe algún rol parecido con
responsabilidades iguales o similares.
La Plantilla 5 proporciona un espacio donde se puede registrar de forma escrita la
situación actual del gobierno de datos en una empresa. Los criterios que se tienen
en cuenta son los definidos por el modelo de referencia de gobierno de datos (ver
sección de Modelo de referencia de gobierno de datos) donde se explican los
temas que aborda cada uno de los criterios. Esta plantilla permite evaluar el
gobierno de datos de la empresa contra el modelo de referencia, indicando si
existe alguno de esos criterios implantados y describiendo cual es la situación
respectiva. Esta plantilla es importante como una entrada para realizar el análisis
del estado actual y el estado deseado.
Plantilla 5. Estado actual de gobierno de datos
El principio de gobierno de datos es tomado de TOGAF y FEAF, donde solo lo
abordan de manera global.
CRITERIOS EXISTE (S/N) DESCRIPCION
Diseño organizacional
Principios de datos
Roles y responsabilidades
Seguridad y privacidad
Dominios de datos
Calidad de datos
Metricas
COMENTARIOS
113
Análisis Estado Actual
Entradas: modelo conceptual, diagrama de ciclo de vida de los datos, glosario de
las entidades de negocio, inventario de las fuentes de datos, matriz de Entidades
vs Fuentes de datos, y situación actual del gobierno de datos.
Artefacto: análisis estado actual de AI.
Aquí se debe realizar un análisis explicando las causas de los problemas
identificados y que se vienen presentando recurrentemente en el negocio como
consecuencia del estado actual de los datos. Esta actividad está compuesta por
otras tres actividades (ver Figura 32): análisis de la información, riesgos de
seguridad y gobierno de datos.
Figura 32. Actividades del Análisis de Estado Actual de AI
114
Las actividades no tienen un orden de ejecución definido (ver Figura 32). A
continuación se explica cada una de estas actividades.
El principio de Análisis del Estado Actual de AI, fue tomado de TOGAF. Pero en
este trabajo se extendió proponiendo tres actividades que para el alcance de este
trabajo se consideran fundamentales. Cada una de estas actividades es producto
del trabajo realizado.
Análisis de la información
Es importante realizar un análisis de la información, porque en la operación diaria
de cualquier negocio se toman decisiones estratégicas, operacionales y dichas
decisiones deben ser tomadas usando la información y los hechos para tener un
mayor grado de seguridad en la toma de una buena decisión ya sea estratégica u
operacional.
Difícilmente se puede encontrar un método único para alcanzar la calidad de los
datos y más que un método debe ser un proceso iterativo y continúo. De [25] se
tomó la propuesta para realizar un análisis de calidad de datos y se adaptó en este
trabajo para proponer un método iterativo (ver Figura 33).
Este método consta de 7 pasos que se describen a continuación:
Identificar información crítica para el negocio: existe tanta información en una
organización que difícilmente podemos dedicar suficientes recursos para mejorar
la calidad de toda la información, por lo que hay que fraccionar e identificar cual
es la información que tiene un mayor impacto en las operaciones del negocio. La
información o datos críticos para el negocio son los que soportan los procesos
misionales de la empresa. Priorizar los procesos misionales depende de varios
factores como el que mayor impacto tiene en los ingresos, el que más costos
genera, el menos eficiente en tiempos de ejecución, entre otros. También no
115
debemos olvidarnos de la información que apoya los procesos estratégicos,
porque es allí donde se toman las decisiones importantes para el negocio.
Figura 33. Método para análisis de calidad de datos
Definir indicadores de calidad: la pregunta que se debe responder es: ¿qué
factores se deben tomar en consideración para afirmar que un dato es de calidad
para la empresa? la respuesta son los indicadores de calidad de datos. Existen
muchos indicadores de calidad, pero se sugiere trabajar con los siguientes:
exactitud, totalidad, oportunidad, relevancia, nivel de detalle y consistencia. Para
mayor información sobre los indicadores (dimensiones) de calidad y como definir
métricas ver [29].
Realizar mediciones iniciales para detectar posibles problemas de calidad de
datos: Este paso es un diagnóstico que nos ayuda a medir la calidad actual de la
1. Identificar información
crítica
2. Definir Indicadores de calidad
3. Realizar mediciones
4. Automatizar indicadores de calidad
5. Definir responsables
6. Diagnóstio
7. Monitoreo
de los indicadores
116
información crítica definida en el paso 1, identificando donde se encuentran los
mayores problemas de calidad de datos. Para detectar problemas en la calidad de
datos se sugiere responder las siguientes preguntas:
o ¿Existe una fuente única de información o existe más de una?: En la mayoría
de las empresas NO se tiene una única fuente de información, existen diversos
sistemas formales y no formales y esto es un gran problema a la hora de tomar
decisiones basadas en la información. Para responder esta pregunta se deben
revisar y analizar las matrices: Fuentes de Datos vs Entidades de Negocio, el
diagrama de diseminación de datos y el diagrama de ciclo de vida de los datos
también puede ayudar.
o ¿Cómo asegurar una fuente única de datos con información correcta?: esto
principalmente se consigue implementando de forma adecuada dos iniciativas
principales: Gobierno de datos y Gestión de Datos Maestros (MDM).
o ¿Existen datos con alguna de las siguientes características?: incompletos,
innecesarios, no disponibles, no son creados, no consumidos, no relacionados,
no se encuentran donde se necesitan. Esta información se debe conseguir
mediante entrevistas con los usuarios de los datos y el grupo de arquitectura.
Automatizar indicadores de calidad: En este paso se realizan programas que
ayuden a medir periódicamente la calidad de la información, lo que no se puede
medir no se puede administrar y no se puede mejorar. Estos indicadores deben
estar al alcance de las personas que serán las responsables de monitorear y
mejorar la calidad de la información.
Definir responsables de calidad de datos: Una de los factores críticos de éxito
de un proyecto de calidad de datos es definir un responsable de cada indicador,
esta persona debe monitorear las tendencias del indicador y realizar planes de
acción encaminados a la mejora de los indicadores. Ver gobierno de datos en
modelos de referencia.
117
Diagnóstico de calidad de datos: en estos diagnósticos se determinan las
posibles causas de la mala calidad de Datos y se definen planes de acción con
responsables para mejorar el indicador. Entre los planes de acción normalmente
se incluye el establecer controles preventivos y correctivos para mejorar la calidad
de los datos.
Monitoreo de los indicadores de calidad: Si los empleados no perciben las altas
expectativas por parte de la gerencia o directivos, el proyecto tendrá resultados
limitados, es importante que los indicadores de calidad de datos se revisen
periódicamente, asegurando su seguimiento y mejoramiento permanente. Para
esto se sugiere realizar reuniones periódicas.
Riesgos de seguridad
Existen diversas metodologías de análisis de riesgos informáticos, lo cual no es el
alcance de este trabajo, pero si revisaremos algunos temas a tener en cuenta
cuando realizamos un trabajo de AI. Los riesgos de seguridad básicamente
comprometen los siguientes indicadores de calidad: confidencialidad, integridad y
disponibilidad de los sistemas de información. Dependiendo del contexto de la
empresa, se puede llegar a tener diferentes amenazas que comprometan los
indicadores antes mencionados. Los riesgos de información se pueden presentar
a nivel de hardware y a nivel de datos.
Los riesgos a nivel de hardware obedecen a desastres naturales, fluctuaciones en
el voltaje, vandalismo, entre otros. Los riesgos a nivel de datos son motivados por
acciones como el robo de información, espionaje, virus, alteración y destrucción.
Ante un riesgo concreto, la empresa tiene tres alternativas: aceptar, mitigar o
transferir (mediante un contrato de seguro) el riesgo. Para mitigar el riesgo la
empresa debe tomar medidas o políticas de controles de seguridad.
118
Las medidas de control ayudan a definir restricciones y otro tipo de medidas que
se deben imponer a los usuarios o sistemas internos y externos a la empresa,
para proteger los datos de los riesgos ya señalados, así como para mitigar el
riesgo y los daños que puedan ocurrir. Las medidas de control sugeridas son:
o Copia de seguridad: La manera más fácil de evitar la pérdida de datos debido
a desastres naturales, virus o errores humanos es duplicar automáticamente
todos los datos de manera periódica, es decir hacer una copia de seguridad de
datos.
o Control de acceso: Los controles de acceso son medidas para asegurar que
solo las personas o aplicaciones autorizadas puedan acceder a los datos.
Estas generalmente son códigos de accesos, con políticas de cambio periódico
y que no se puedan repetir códigos previamente utilizados.
o Revisión de auditoria: A pesar de las precauciones existentes para evitar un
uso abusivo del sistema, esto sucede algunas veces. Por lo tanto, se necesitan
medidas adicionales para mantener el registro de las transacciones, de modo
que: cuando se detecten abusos, pueda dárseles seguimiento y que el temor a
ser descubierto desaliente el abuso.
o Estándares de seguridad: se recomienda seguir alguno de los estándares de
seguridad ya existente, tales como el libro naranja Trusted Computer System
Evaluation Criteria (TCSEC), El Criterio Europeo de Evaluación de Seguridad
en Tecnología de la Información (ITSEC), Dimensiones de Calidad de Datos
según ISO/IEC 25012, entre otros. Es criterio de la empresa y dependiendo del
contexto revisar y seleccionar el estándar adecuado. Esto les ayudara a definir
un estándar que se ajuste a las necesidades propias del negocio, no se deben
inventar uno, deben seleccionar lo mejor de cada estándar o lo que mejor se
ajuste a las necesidades.
119
Gobierno de datos
La información fundamental para realizar el análisis del gobierno de datos es la
que se captura en la actividad de la situación actual del gobierno de datos, donde
se puede evidenciar si la empresa tiene y sigue una guía metodológica que facilite
el funcionamiento de un gobierno de datos y donde también se puede observar si
se cuenta con una estructura organizacional de roles bien definida junto con sus
respectivas responsabilidades.
Si la empresa no cuenta con un gobierno de datos claramente definido puede
impactar directamente el negocio, puesto que trae consecuencias como falta de
confianza en los datos para la toma de decisiones estratégicas, no contar con
información oportuna, una calidad pobre de los datos que se evidencia en
duplicación, replicación de datos sin ningún tipo de control, datos incompletos,
datos innecesarios, datos que se necesitan y que no están disponibles, datos que
no son creados, datos que existen y nunca se utilizan, entre otros. Todo esto
debe repercutir y explicar los diversos problemas que se presenten a cualquier
nivel de la empresa, estos problemas pueden ser altos costos en la operación,
problemas a la hora de tomas decisiones estratégicas, demora en los tiempos de
respuesta de los procesos misionales, problemas operacionales a nivel
tecnológico porque es difícil de administrar, operar, mantener, escalar e integrar.
Estado Deseado de Arquitectura de Información
En esta etapa no se suele utilizar los mismos lenguajes y formalismos de la
situación actual, puesto que solo es un borrador de muy alto nivel. Uno de los
objetivos principales en esta etapa es definir globalmente como debería ser la AI
para apoyar las estrategias de negocio y argumentar la necesidad de alinearse o
no con alguno de los marcos de referencia propuestos. Se proponen dos
actividades a desarrollar en esta etapa (ver Figura 34).
120
Figura 34. Actividades en la etapa de Estado Deseado de AI
El principio de la etapa Estado Deseado es tomado de TOGAF y FEAF. Pero el
concepto de Blueprint para AI y Gobierno de Datos es tomado originalmente del
curso de Diseño de Software Basado en Patrones.
Blueprint de Arquitectura de Información
Entradas: situación actual de AI, modelos de referencia.
Artefactos: blueprint de AI.
Grupos de apoyo: estratégico y de negocio.
Permite definir políticas globales que se deben respetar, también organiza y
relacionar todos los elementos que hacen parte de la solución de AI y considera
todos los aspectos como, principios de datos, gobierno de datos, seguridad,
técnicas de integración, MDM, almacenamiento, entre otros.
121
Figura 35. Blueprint de Arquitectura de Datos
El blueprint para AI está compuesto por zonas y define las políticas globales que
se deben respetar. También organiza y relaciona los aspectos que hacen parte de
la solución. Una zona es un espacio de la AI con una frontera definida y
representa claramente un objetivo para responder a una necesidad. También
enmarca un conjunto de estándares, métodos, funcionalidades, servicios, técnicas
y tecnologías que deben respetar unas políticas y reglas empresariales.
Tomando como blueprint de arquitectura de información la Figura 35, podemos
asumir que la empresa desea llegar a tener una política general sobre los datos a
través de unos principios de datos, desea implantar un gobierno de datos donde la
prioridad debe ser la calidad de los datos. También se puede deducir que
cualquier usuario de datos debe pasar una zona de seguridad que deberá
implantar estándares de seguridad y de esta forma poder consumir los datos que
necesite. También se puede observar la necesidad de trabajar en temas de
auditoria, BI, minería, bodega de datos y que además desea implantar técnicas de
integración de datos y técnicas de gestión de datos maestros.
Zona de auditoria
Zona
de
fuen
tes d
e da
tos
Zona de BI, mineria
y bodega de datos
Zona de monitoreo
Principios de Datos
Gobierno de Datos
Calidad de Datos
Zona de consulta,
creacion, modificación
y busquedaZo
na d
e us
uario
s de
dato
s
Zona
de
segu
ridad
Zona
de
Inte
grac
ión
Zona
MDM
122
Blueprint de Gobierno de Datos
Entradas: Modelo de referencia de gobierno de datos.
Artefacto: situación deseada de gobierno de datos.
Grupos de apoyo: estratégico y negocio.
Aquí el objetivo principal es definir, establecer y explicar la necesidad de alinearse
total o parcialmente con el modelo de referencia que se expone en la sección
Modelo de referencia de gobierno de datos. El blueprint de gobierno de datos es el
mismo modelo de referencia (ver Figura 28) si la decisión es ajustarse
completamente al modelo de referencia.
Tomando la Figura 28 como blueprint, podemos deducir que la empresa desea
tener un diseño de gobierno de datos, donde se debe definir una estructura
organizacional específica para el gobierno de datos, definir principios de datos,
definir roles y responsabilidades para el gobierno de datos. Además se desea
definir políticas para seguridad y privacidad de datos y también definir políticas de
calidad. También se observa que se desea definir políticas sobre dominios de
datos y finalmente se deben definir métricas que permitan medir el impacto del
gobierno de datos en el negocio.
Como complemento a esta actividad en la sección3.2.2 se propone una guía
metodológica para diseñar y gestionar un gobierno de datos.
Mapa de proyectos
Mapa de Proyectos es la última etapa (ver Figura 36) definida en la metodología
de proyecto inicial. El principal objetivo en esta etapa es responder a la pregunta
¿Cómo ir del estado actual al estado deseado?
123
Figura 36. Etapa de Mapa de Proyectos en la metodología de proyecto inicial
Para responder a la pregunta se plantean dos actividades (ver Figura 37). Para
estas actividades se tomó como referencia las técnicas de planeación de
migración que se encuentra en [16] y también se tomó información de [27] sobre
priorización de proyectos. En la siguiente sección se explica cada una de las
actividades propuestas.
Figura 37. Actividades de la etapa de Mapa de Proyectos
124
La etapa de mapa de proyectos es tomado de TOGAF.
Definición de proyectos
Siguiendo la propuesta de [16], se plantea una matriz como técnica de
Consolidación de Brecha, Soluciones y Dependencias (ver Plantilla 6). Esta
técnica le permite al grupo de AI agrupar y analizar las brechas identificadas como
resultado del trabajo realizado en las etapas de estado actual y estado deseado,
con el propósito de evaluar posibles soluciones y dependencias. La información
presentada en la Plantilla 6 es solo a modo de ejemplo.
Plantilla 6. Matriz de consolidación de brecha, soluciones dependencias [16]
N° GAP Posible Solución Dependencias
Diseño y construccion de
fuente de datos para MDM
Migracion de Clientes
Migracion de Productos
Ejecutar metodo para el
dato maestro Cliente
Ejecutar metodo para el
dato maestro Producto
3Integracion de datos
operacionales
Diseño y construccion de
tecnicas de integracion de datos
4 Gobierno de datosDiseño y gestion de gobierno de
datos
Implementación gobierno
de datos
5 ……… … …
6 …….. … …
Matriz de Consolidación de Brecha, Soluciones y Dependencias
Diseño y construccion de MDMAmbiente MDM1
Metodo para calidad de datosCalidad de Datos2
125
La Plantilla 6 es una herramienta donde se definen temas globales de trabajo, con
sus posibles soluciones y respectiva dependencias que dan origen a los proyectos
que se deben ejecutar. Los temas de trabajo se toman del blueprint de
arquitectura que se definió para datos y para gobierno. Para cada tema de trabajo
se debe especificar cuáles son los proyectos que se deben ejecutar, por ejemplo,
para el tema de MDM se puede llegar a definir un proyecto para el diseño e
implementación de uno de los enfoques arquitecturales para MDM, también definir
como proyecto el diseño de la fuente de datos para MDM, otro proyecto puede ser
la migración de los datos de Clientes.
Una vez finalizada la primera técnica (ver Plantilla 6), se prosigue con la técnica de
definición de arquitectura incremental, para esto se crea una tabla (ver ) que
permite al grupo de AI planificar por proyecto una serie de arquitecturas de
transición que describen el estado de la AI en momentos determinados.
Plantilla 7. Definición incremental de arquitectura [16]
Priorización de Proyectos
Para la priorización de proyectos se toma la propuesta de [16] que habla de la
técnica de evaluación del valor del negocio. Esta técnica consiste en la
Arquitectura de Transicion 1 Arquitectura de Transicion 2 Arquitectura de Transicion 3
N° Proyecto Julio 2012 - Diciembre 2012 Enero 2012 - Junio 2012 Julio 2013 - Diciembre 2013 Comentarios
1 Diseño y construcción MDM Diseño y fuente de datos Migracion clientes Migracion Productos
2Integracion datos operacionales
Diseño y construcción de la
tecnica de integracionDatos de clientes
Datos de productos
3Calidad de datos
Preparacion metodo de
calidad de datos
Proceso de calidad para
clientes
Proceso de calidad para
productos
4
Gobierno de datos Diseño
Definicion de roles y
responsabilidades
compartidas
Definicion de roles y
responsabilidades unicas
para Gobierno de datos
5 … … … … …
. … … … … …
.
.
.
.
126
elaboración de una matriz basada en una dimensión índice de valor y una
dimensión índice de riesgo (ver Figura 38). El índice de valor debe incluir criterios
como el cumplimiento de los principios, la contribución financiera, la alineación
estratégica, y la posición competitiva. El índice de riesgo debe incluir criterios
como el tamaño y la complejidad, la tecnología, la capacidad de organización, y el
impacto de un fracaso. A cada criterio se debe asignar un peso individual [16]. La
priorización de proyectos es una tarea que principalmente debe hacer el CEO en
compañía de los mandos medios y el grupo de arquitectura.
Figura 38. Técnica de evaluación del valor de negocio [16]
A continuación se mencionan varios criterios que se deben consideran al memento
de realizar una priorización de proyectos:
Beneficios que le aporta el proyecto a la organización:
127
o Aumento de ingresos o disminución de costos: por factores tales como
captación de nuevos clientes, extensión del negocio hacia nuevos canales,
lanzamiento de nuevos productos.
o Mejora del servicio por agilización de procesos: mejorar la información para
soportar la atención al cliente, reducción de errores de datos.
Factores que representan un riesgo:
o Uso de tecnologías no probadas
o Restricciones de tiempo
Capacidad o disponibilidad de los medios para manejar el proyecto
o Disponibilidad de recursos (técnicos, personal capacitado, presupuesto)
o Adaptabilidad de las fuentes de datos involucradas a la nueva arquitectura
de información.
3.2.2 Guía metodológica para gobierno de datos
Como resultado del análisis del estado del arte, se observa que existen diversas
propuestas para gobierno de datos y muy diversas entre sí, cada propuesta
aborda el tema desde perspectivas diferentes y abordan temas igualmente
importantes. En consecuencia si una empresa desea diseñar e implementar su
gobierno de datos debe hacer una ardua tarea de revisar cada una de las
propuestas y realizar un análisis para determinar que le sirve y que no le sirve de
acuerdo a sus necesidades. Además estas propuestas no cuentan con una guía
metodológica completa sobre como diseñar e implementar un gobierno de datos.
Para resolver el problema identificado en el análisis del estado del arte, se
propone una guía metodológica (ver Figura 39), donde se proponen una serie de
10 actividades que guían el diseño e implementación de un gobierno de datos. En
esta guía se buscó incluir los aspectos elementales tomados de las propuestas
128
analizadas en el estado del arte y que se deben considerar en la definición de la
guía metodológica en la cual se busca un fácil y rápido de entendimiento de como
diseñar y gestionar un gobierno de datos.
PreparacionMapa de Proyectos
DiseñoEvaluación de
Madurez
Modelo Organizacional
Definir Metricas
Gobierno de Datos Maestros
Gobierno de Analisis
Gestión de Seguridad y Privacidad
Medir Resultados
Figura 39. Guía Metodológica para Diseño de un Gobierno de Datos
De las 10 actividades propuestas en la guía metodológica 3 son opcionales y 7
son obligatorias. Se recomienda que la empresa seleccione por lo menos 1 de las
tres actividades opcionales [26]. A continuación se describe para cada una de las
actividades los aspectos que se deben considerar.
La guía metodológica propuesta tiene su origen en las tres propuestas de gobierno
de datos analizadas en el estado del arte y reúne los elementos principales de
cada una.
129
3.2.2.1 Preparación
En esta etapa se deben definir aspectos como la evangelización que debe ser
asumida preferiblemente por el CEO o algún representante en su nombre que
actúe como apoyo ejecutivo para que los empleados de la empresa vean el
proyecto de AI como algo importante para la compañía y que deben brindar su
apoyo incondicional. En reunión con el CEO se debe también definir el alcance del
gobierno de datos, quienes serán los responsables de los datos críticos, quien
coordinara o liderará el proyecto, si el negocio o IT.
También es importante identificar la estructura organizacional de la empresa y
conocer si es centralizada, descentralizada o mixta. Definir si se requieren roles de
medio tiempo o tiempo completo y si en la empresa existe personal capacitado en
el tema. Establecer la financiación del proyecto de gobierno de datos para saber si
es un proyecto global e independiente de los demás proyectos o si se adhiere y
sustenta en algún proyecto ya existente, puede ser un proyecto de BI, o un
proyecto de calidad de datos o cualquier proyecto referente a datos.
3.2.2.2 Diseño
Se debe tener claro desde un comienzo que la cultura existente de su empresa no
va a cambiar para apoyar el gobierno de datos, así que en su lugar se debe
trabajar para entender su cultura y aprovechar sus puntos fuertes. Por ejemplo, en
una cultura donde cada unidad de negocio opera de forma independiente y da
prioridad a su propia dirección estratégica, será apropiado fomentar un enfoque de
gobierno de datos descentralizado, donde expertos en la materia en diferentes
unidades de negocio colaboren unos con otros, evitando así un rol de liderazgo
centralizado pueda ser visto como una amenaza.
El éxito de varias empresas según [22] radica en poner en marcha el gobierno
dentro de un proyecto de BI o DW, una iniciativa MDM, o dentro de un CRM o
130
ERP. Básicamente utilizan un enfoque donde van creciendo proyecto a proyecto
hasta cubrir todos los datos empresariales.
Es importante definir los patrocinadores ejecutivos y administradores de datos
desde el comienzo y utilizarlos como sus evangelistas. La mayoría de las
organizaciones requieren que la alta gerencia y sus ejecutivos definan las
prioridades para lograr cambios reales en la gestión y calidad de los datos [22].
Es importante usar medidas cualitativas y cuantitativas de las principales
funciones de negocio, tales como marketing, finanzas, ventas y operaciones de
call center, para justificar los programas de gobierno.
También es vital incluir la participación en las metas del empleado porque nada
mata a un programa de gestión de datos más rápido que esperar la participación
voluntaria. Se debe premiar a los administradores en las evaluaciones de su
desempeño mediante el reconocimiento de su participación y las contribuciones. Y
si algunos no colaboran, escalar a su jefe directo [22].
A nivel de estructura organizacional del gobierno de datos se debe dar prioridad a
un enfoque centralizado. Es de aclarar que aunque las decisiones a nivel
corporativo se recomienda manejarlas de forma centralizada, los datos relevantes
para una sola línea de negocio pueden ser manejados de forma descentralizada
[22].
3.2.2.3 Evaluación de Madurez
De acuerdo con [26], toda organización necesita llevar a cabo una evaluación de
madurez de su gobierno, de preferencia sobre un periodo de tiempo anual. El IBM
Data Governance Council ha desarrollado un modelo de madurez basado en 11
categorías (ver capítulo 5 en [26]), tales como “Gestión de Riesgos de Datos y
Cumplimiento”, “Creación de Valor”, y “Administración”. La organización de
131
Gobierno de Datos debe evaluar el nivel actual de madurez (estado actual) y el
nivel futuro deseado de la madurez (estado futuro), que suele ser de 12 a 18
meses por lo menos. Esta duración debe ser suficiente para producir resultados,
pero lo suficientemente corto como para asegurar la continua aceptación por parte
de las principales partes interesadas.
En el apéndice D de [26] se encuentra un ejemplo de un cuestionario de
evaluación para determinar el nivel de madurez del gobierno de datos. También en
el capítulo 5 se describe detalladamente esta actividad.
3.2.2.4 Mapa de proyectos
Se debe desarrollar un plan de trabajo para cerrar la brecha entre el estado actual
y el estado futuro deseado para las 11 categorías de madurez de la gobernabilidad
de datos (ver capítulo 5 en [26]). Por ejemplo, la organización de gobierno de
datos podría revisar la brecha de vencimientos para la administración y determinar
que la empresa debe nombrar a los administradores de datos para centrarse en
temas específicos tales como clientes, proveedores, y producto. El programa de
gobierno de datos también debe incluir éxitos rápidos, áreas donde la iniciativa
puede generar valor al negocio en plazos cortos.
En el capítulo 6 de [26], se hace una explicación detallada sobre este tema.
3.2.2.5 Modelo Organizacional
La organización de gobierno de datos debe construir un modelo para dirigir sus
operaciones, y para asegurar quien tiene la autoridad suficiente para actuar como
árbitro en situaciones críticas. La organización de gobierno de datos funciona
mejor en un formato de tres niveles. El nivel superior es el Consejo de Gobierno
de Datos, que se compone de los principales líderes funcionales y de negocio que
132
dependen de los datos como un activo de la empresa. El nivel intermedio es el
grupo de gobierno de datos de trabajo, que consiste en los mandos medios que se
reúnen con más frecuencia. El último nivel consiste en la comunidad de
administradores de datos, que es responsable de la calidad de los datos en el día
a día [26].
En el capítulo 7 de [26], se hace una explicación detallada sobre este tema.
3.2.2.6 Definir Métricas
El gobierno de datos debe contar con indicadores sólidos para medir y monitorear
el progreso. Como resultado, el equipo de gobierno de datos debe recoger unos
pocos indicadores principales de rendimiento (KPIs) para medir el desempeño
continuo del programa. En el apéndice E de [26] se explica mediante un ejemplo
los aspectos como principios, políticas, procedimientos y reglas de negocio, los
cuales se deben entender y trabajar previamente a definir las métricas, puesto que
las métricas dependen de esos aspectos.
Estos son los nueve primeros pasos requeridos. El paso final requerido se discute
más adelante. La empresa también tiene que seleccionar al menos una de los
cuatro pasos de datos opcionales de Gobierno (Gobierno de Datos Maestros,
análisis de Gobierno, Seguridad y privacidad, y la información del ciclo de vida de
Gobierno).
En el capítulo 9 de [26], se hace una explicación detallada sobre este tema.
133
3.2.2.7 Gobierno de datos maestros
Aquí se debe crear una práctica continua, mediante el cual se debe definir los
principios, políticas, procesos, reglas de negocio y métricas (ver apéndice E en
[26]), específicamente para datos maestros, de tal forma que ayude en la
consecución de los objetivos de negocio, mediante la gestión de la calidad de los
datos maestros.
En el capítulo 14 de [26], se hace una explicación detallada sobre este tema.
3.2.2.8 Gobierno de análisis
En esta etapa se debe definir las políticas y procedimientos para alinear los
usuarios de negocio con las inversiones en infraestructura analítica. Para esto el
gobierno de datos debe plantearse y responder las siguientes preguntas:
o ¿Cuantos usuarios de los datos existen en la empresa por área de
negocio?
o ¿Cuantos reportes se deben crear por área de negocio?
o ¿Cuántos reportes se ejecutan por mes?
o ¿Cada cuánto tiempo necesitan ejecutar cada reporte?
o ¿Se puede entrenar a los usuarios de negocio para generar sus propios
reportes?
El tema de gobierno de análisis está relacionado con el área de BI, para lo cual se
recomienda seguir la metodología Kimball. También en el capítulo 15 de [26], se
hace una explicación detallada sobre este tema.
3.2.2.9 Gestionar la seguridad y privacidad
Aquí se deben gestionar los temas relacionados con la seguridad de los datos y la
privacidad. Algunos de los retos comunes de seguridad de datos y desafíos de
privacidad son:
134
Donde esta nuestra información confidencial?
La organización ha enmascarado sus datos confidenciales en los entornos que
no son de producción (desarrollo, pruebas y capacitación) para cumplir con las
regulaciones de privacidad?
Están los controles de auditoría de base de datos en el lugar para evitar el
acceso de los usuarios privilegiados, por ejemplo, como administradores de
bases, a los datos privados, como los sueldos de los empleados y listas de
clientes?
Controles de acceso.
Copias de seguridad.
Seguir alguno de los estándares de seguridad ya existente, tales como el libro
naranja Trusted Computer System Evaluation Criteria (TCSEC), El Criterio
Europeo de Evaluación de Seguridad en Tecnología de la Información (ITSEC),
Dimensiones de Calidad de Datos según ISO/IEC 25012, entre otros.
En el capítulo 16 de [26], se hace una explicación detallada sobre este tema.
3.2.2.10 Medir Resultados
El gobierno de datos debe asegurar una mejora continua mediante un seguimiento
constante de las métricas definidas. Entonces para medir los resultados y hacer el
seguimiento continuo se sugiere utilizar el método para análisis de calidad de
datos que se describe en la sección Análisis de la información. Como
complemento se puede revisar el capítulo 18 de [26].
135
4 APLICACIÓN DE LA GUIA METODOLOGICA PARA EL PROYECTO INICIAL
DE ARQUITECTURA DE INFORMACION EN LA ADMINISTRADORA
COLOMBIANA DE PENSIONES COLPENSIONES
La guía metodológica para el desarrollo del proyecto inicial de arquitectura de
información, fue probada en el proyecto de arquitectura de información que hace
parte integral del proyecto de arquitectura empresarial, para la creación de la
Administradora Colombiana de Pensiones COLPENSIONES que tiene su origen
en un esfuerzo del estado por unificar las diversas administradoras de pensiones
de orden estatal que existen a nivel nacional y departamental.
El objetivo principal del proyecto, es diagnosticar la situación actual de las
tecnologías de información y comunicaciones del Instituto de los Seguros Sociales
(ISS) y la Caja de Previsión Social de Comunicaciones (Caprecom), a partir de
estudios existentes y de validación directa, teniendo en cuenta la estrategia de
negocio de COLPENSIONES, los requerimientos normativos de la
Superintendencia Financiera de Colombia, las perspectivas de Gobierno de
Tecnología e Informática (TI), Arquitectura Empresarial de TI, y Soporte y entrega
de servicios de TI. También considera el diseño del Plan Estratégico de
Tecnologías de Información y Comunicaciones (TIC’s) de COLPENSIONES, con
base en las mejores prácticas y utilización de las tecnologías de punta en
información y comunicaciones. Además de la elaboración del plan de
implementación integral.
En este trabajo se abordara el objetivo principal del proyecto de creación de
COLPENSIONES, desde una perspectiva de arquitectura de información en un
contexto de arquitectura empresarial, donde se considera como punto de partida la
situación actual de la arquitectura de información del ISS y Caprecom para la
creación de la nueva empresa COLPENSIONES.
136
Es así como en la sección 4.1, se presenta la primera etapa de la metodología
llamada Preparación, donde se abordan las actividades de grupos de apoyo,
conociendo la organización, alcance de la AI, modelos de referencia, herramientas
y técnicas.
En la sección 4.2, se presenta la segunda etapa de la metodología llamada Estado
Actual, donde se abordan las actividades de entrevistas, procesos de negocio,
entidades de negocio, modelo conceptual, gobierno de datos, fuentes de datos y el
análisis de la situación actual.
La tercera etapa de la metodología llamada Estado Deseado donde se abordan
las actividades de Blueprint de Gobierno de Datos y Blueprint de Arquitectura de
Datos se presenta en la sección 4.3.
La cuarta y última etapa de la metodología llamada Mapa de Proyectos donde se
abordan las actividades de Priorización de Proyectos y Ruta de Ejecución se
presenta en la sección 4.4.
4.1 ETAPA 1: PREPARACION
4.1.1 Conociendo la organización - COLPENSIONES
La actividad de conociendo la organización se empezó con una primera reunión de
lanzamiento del proyecto, donde se presentó formalmente el proyecto de AI como
parte integral del proyecto de AE. En el anexo N° 5 de este trabajo se encuentra
una copia del acta de la reunión. Además en el anexo N° 6 se encuentra una copia
de la plantilla donde se relaciona la información solicitada durante la reunión. A
continuación se describe la información que se solicitó y que es fundamental para
conocer la organización y entender el contexto donde se desarrollara el proyecto
de AI.
137
La información que se presenta durante el desarrollo de esta actividad fue tomada
de [31].
Misión
Somos la Administradora del régimen de prima media con prestación definida que
garantiza el reconocimiento de las prestaciones económicas y los beneficios
económicos periódicos en condiciones de sostenibilidad, eficiencia y economía,
orientada al exitoso cumplimiento de los procesos que le permiten el desarrollo de
su objeto con un talento humano eficiente, competente y comprometido logrando
la satisfacción de nuestros clientes.
Visión
Colpensiones se constituirá en una Empresa innovadora y sólida con altos
estándares deservicio y líder en el aseguramiento del sistema pensional
colombiano, apoyada en macroprocesos, tecnología y talento humano de la mejor
calidad, para crear y mantener relaciones a largo plazo con clientes leales y
satisfechos.
Objetivo general y objetivos específicos
En desarrollo de las disposiciones que regulan el sistema general de seguridad
social en pensiones y de la disposición de creación prevista en el artículo 155 de
la Ley 1151 de 2007, la Administradora Colombiana de Pensiones, Colpensiones
tiene como objetivo general cumplir con la administración estatal del régimen
solidario de prima media con prestación definida y con los servicios y prestaciones
especiales que las normas legales le asignen, incluyendo los beneficios
económicos periódicos a que se refiere la Constitución y la Ley.
138
Son objetivos específicos de la Administradora Colombiana de Pensiones,
Colpensiones:
Administrar el régimen solidario de prima media con prestación definida de forma
que se dé cumplimiento al ordenamiento normativo que constituye el Sistema
General de Seguridad Social en Pensiones.
Administrar los beneficios económicos periódicos de que trata el artículo 58 de la
Constitución Política y las normas legales y reglamentarias que lo desarrollen.
Adelantar la gestión comercial, la gestión de servicio al cliente, la gestión de
historia pensional, la gestión de nómina, la gestión de reconocimiento de
prestaciones económicas a su cargo y la gestión de recursos públicos del régimen
y los servicios que administre. (Esta corresponde a función y como objetivo no es
claro), proponemos:
Implementar el proceso de gestión comercial para propender la afiliación,
fidelización del cliente y por ende el posicionamiento de la Administradora.
Mantener el proceso de servicio a los afiliados y no afiliados para lograr la
satisfacción del usuario.
Mantener actualizadas las historias pensionales para lograr el reconocimiento
oportuno delos beneficios y prestaciones económicas.
Establecer mecanismos para generar la nómina con las respectivas novedades de
pensionados para lograr el pago oportuno de las mesadas pensionales.
Desarrollar y retroalimentar el macroproceso estratégico de la Administradora en
caminado al logro del objeto social.
Desarrollar la gestión y los sistemas de control y auditoría que requieran la
empresa y el régimen y servicios a su cargo.
139
Cumplir con las disposiciones normativas que regulan su existencia y operatividad,
como también con las actividades de apoyo, administrativas, financieras,
contractuales, de talento humano y documental requeridas por la empresa para el
desarrollo de su objeto.
Identificación del mapa de proceso o cadena de valor
La identificación del mapa de procesos se realiza en los siguientes cuadros:
140
141
Para desarrollar las funciones misionales, Colpensiones debe adelantar
programas de publicidad, comunicación y promoción de su actividad como
administradora, afiliar, disponer de un sistema de información que le permita llevar
el registro de afiliados, diseñar una estructura de atención al usuario, recaudar y
administrar la cuenta común donde ingresan las cotizaciones de los afiliados, junto
con las inversiones y reservas, reconocer el ingreso, cobrar bonos pensionales y
cuotas partes, mantener y actualizar la historia pensional de los afiliados,
reconocer y pagar a los beneficiarios oportunamente las prestaciones económicas
a su cargo, y ejercer control sobre toda la operación como administradora del
régimen de prima media y de beneficios económicos periódicos.
Con el fin de dar cumplimiento al objetivo establecido por la Ley, y basados en los
componentes de un sistema de pensiones y de beneficios, se determinan los
macroprocesos, procesos, subprocesos y procedimientos, que proporcionan la
visión sistémica requerida para la definición de una estructura orgánica adecuada,
que permita el cumplimiento de la misión institucional, en condiciones de eficiencia
y eficacia que optimicen el beneficio de su población objetivo. El modelo de
operación agrupa cuatro macroprocesos:
142
Macroprocesos Estratégicos
Son aquellos que orientan, evalúan y hacen seguimiento a la gestión de la entidad,
incluye procesos relativos al establecimiento de políticas, estrategias, fijación de
objetivos, provisión de comunicación y aseguramiento de la disponibilidad de
recursos necesarios para cumplir con su objeto y revisión por la dirección.
Los macroprocesos estratégicos en Colpensiones agruparán los procesos que
materializan el objetivo, las políticas, la estrategia corporativa y el
direccionamiento de la Administradora. Estos procesos establecerán y controlarán
las metas, estimularán la dinámica organizacional a través de la conducción
tecnológica, la planeación corporativa, la gestión jurídica y doctrinal y la gestión
documental. Adicionalmente, apoyarán la excelencia Institucional a través de la
optimización delos procesos de manera planificada, organizada, integrada y
sistémica en procura de mayor calidad y competitividad.
Macroprocesos Misionales
Son aquellos que contribuyen directamente al cumplimiento de los objetivos y a la
razón de ser de la organización; su objetivo fundamental es entregar los productos
o servicios que el cliente o usuario requiere para satisfacer sus necesidades.
Incluyen todos los procesos que proporcionan el resultado previsto por la entidad
en el cumplimiento de su objeto social o razón de ser.
Los macroprocesos misionales en Colpensiones reflejarán la misión institucional;
así mismo, representarán la esencia y el deber ser de la administradora del
régimen de prima media. Mediante su ejecución se obtendrán los servicios con
valor agregado para la satisfacción de los clientes.
143
Macroprocesos de Apoyo
Son aquellos que dan soporte para el buen funcionamiento y operación de los
procesos estratégicos, misionales y de control y evaluación de la organización.
Incluyen todos aquellos procesos para la provisión de los recursos que son
necesarios en los procesos estratégicos, misionales y de medición, análisis y
mejora.
Los macroprocesos de apoyo, aunque no están ligados directamente a la misión
de la administradora, resultarán necesarios para que los estratégicos, misionales y
de control y evaluación puedan cumplir sus objetivos. Así mismo, .le permitirán a
Colpensiones la sinergia organizacional y proporcionarán los medios y condiciones
para una dinámica institucional efectiva.
Macroprocesos de Control y Evaluación
Son aquellos que adelantan las mismas dependencias responsables del proceso y
la oficina de control interno o quien haga sus veces, para verificar que los
resultados y acciones previstas se cumplieron de conformidad con lo planeado.
Incluyen aquellos procesos necesarios para medir y recopilar datos destinados a
realizar el análisis del desempeño y la mejora de la eficacia y la eficiencia.
Albergan, en consecuencia, procesos de medición, seguimiento, auditoría,
acciones correctivas y preventivas, y son una parte integral de los procesos
estratégicos, de apoyo y los misionales.
A continuación se presentan de manera gráfica los macroprocesos y procesos que
al interrelacionarse entre sí, permitirán de forma eficiente y eficaz el cumplimiento
del objeto misional de la administradora.
144
Identificación de productos y servicios ofrecidos
Para efectos de este trabajo solo se tienen en cuenta los procesos misionales.
145
146
Organigrama
4.1.2 Grupos de apoyo
Grupos de apoyo es la actividad donde se listan los principales roles involucrados
en el proyecto.
Grupo Estrategico
•Presidente
•Vicepresidentes
•Gerente del proyecto
Grupo de Negocio
•Gerentes
•Coordinadores
•Funcionarios
Grupo de Arquitectura
•Coordinador de Tecnología
•Arquitecto de aplicaciones
•DBA's
•Desarrolladores de BD's
147
4.1.3 Modelos de referencia
Para el desarrollo de este proyecto se tomara como modelo de referencia para el
tema de dominios de datos el presentado en la sección Modelo de referencia de
información empresarial, para el tema de gobierno de datos se tomara como
modelo de referencia el presentado en la sección Modelo de referencia de
gobierno de datos y para la definición del alcance del proyecto se tomara como
modelo de referencia el presentado en la sección Alcance de la AI.
4.1.4 Alcance de la arquitectura de información
Tomando como herramienta el modelo de referencia para la definición del alcance
del proyecto de AI, se define lo siguiente:
Para la fase inicial de este proyecto solo se enfocara en el domino de Datos
Maestros.
Grupo de Apoyo Nombres Rol Telefono Correo
Pedro Duarte Presidente 4162700 Ext 105
Jaime Perez Vicepresidente de tecnologia 4162700 Ext 106 [email protected]
Teresa Salcedo Vicepresidente Administrativo 4162700 Ext 107
Jhon Carranza Vicepresidente Comercial 4162700 Ext 108 [email protected]
Leandro SantamariaVicepresidente de servicio
al cliente 4162700 Ext 109 leandro.santamaria@
Carlos MarchenaVicepresidente de gestion
historia pensional 4162700 Ext 110 carlos.marchena@
Camilo A. ZuñigaVicepresidente de beneficios
y prestaciones 4162700 Ext 111 camilo.zuniga@
Camilo Torres Gerente de proyecto 4162700 Ext 112 camilo.torres@
Miguel Rodriguez Gerente de mercadeo 4162720 Ext 141
Rene Mendoza Gerente de ingresos 4162721 Ext 142 rene.mendoza@
Jairo Rodriguez Gerente de recaudo 4162722 Ext 143 jairo.rodriguez@
Zonia Villamizar Gerente de cobro 4162720 Ext 142
Monica Lopez Gerente de archivo 4162721 Ext 143 monica.lopez@
Clara Rincon Gerente de determinación 4162722 Ext 144
Armando Becerra Coordinador de Tecnlogia 4162720 Ext 123 armando.becerra@
Santiago Toro Arquitecto de aplicaciones 4162721 Ext 124 santiago.toro@
Beatriz Vaca Lider de DBA's 4162722 Ext 125 beatriz.vaca@
Sonia Sanchez Lider de desarrolladores 4162720 Ext 124 sonia.sanchez@
Grupo Estrategico
Grupo de Negocio
Grupo de Arquitectura
148
El alcance de este proyecto, solo llega hasta la ejecución del proyecto inicial de AI.
La ejecución de los proyectos particulares está fuera del alcance de la fase inicial.
La descripción de los temas que se encuentras dentro del alcance definido para el
proyecto de AI en su fase inicial, es la siguiente:
Describir la Arquitectura de Información actual del Instituto de Seguros Sociales
(ISS), la Arquitectura de Información objetivo de Colpensiones y el Mapa de
proyectos para superar la brecha existente entre la situación actual y la situación
deseada. La primera hace referencia a toda la información relacionada con la
Arquitectura actual de información (situación actual), la segunda hace referencia a
la propuesta de la Arquitectura deseada de Información (situación deseada) y el
mapa de proyectos trata el tema de definición de proyectos, priorización y ruta de
ejecución.
4.1.5 Herramientas y técnicas
La herramienta seleccionada para realizar el trabajo de AI es Enterprise Architect,
esta herramienta fue seleccionada por su capacidad para:
Crear modelos de datos conceptuales y físicos.
Explorar y visualizar la estructura de las fuentes de datos.
Relacionar fuentes de datos.
Comparar estructuras de fuentes de datos.
Descubrir similitudes entre fuentes de datos.
Analizar modelos y fuentes de datos para validar estándares.
4.2 ESTADO ACTUAL DE ARQUITECTURA DE INFORMACION
En esta sección se comienza con las entrevistas que es la actividad donde el
grupo de AI se reunió con los grupos de negocio y de arquitectura para capturar la
149
información necesaria y analizarla para determinar el estado actual de la
información.
Seguidamente al análisis de la información capturada en las entrevistas se
identificó y documentaron las entidades de negocio y también se creó el modelo
conceptual de datos.
Posteriormente se realizaron entrevistas para identificar la situación actual del
gobierno de datos y las fuentes de datos. También se presenta la relación
existente entre el modelo conceptual y las fuentes de datos; aquí se puede
apreciar si hay elementos conceptuales no incluidos en las fuentes de datos, o si
hay fuentes de datos no consideradas en el modelo conceptual.
Por último se aborda el tema de la robustez de los datos, el cual es abordado en
tres aspectos: Análisis de la información donde se revisan las dimensiones de
calidad de los datos, Riegos de seguridad donde se revisan las medidas de control
existentes y para finalizar se hace una análisis de la situación actual de gobierno
de datos.
4.2.1 Entrevistas
Se realizaron una serie de entrevistas para complementar y validar la información
suministrada en la etapa de preparación. Primero se realizaron entrevistas con el
grupo de negocio y posteriormente se realizaron entrevistas con el grupo de
arquitectura.
4.2.2 Entidades de negocio
Como resultado del análisis de las entrevistas realizadas al grupo de negocio se
identificaron las entidades de negocio y reglas de negocio que describen como se
150
relacionan entre sí. A continuación se utiliza la Plantilla 2 para describir cada uno
de las entidades de negocio identificadas:
Entidad de negocio EN-D001 Persona
Definición Contiene la información básica sobre todos los entes
que tienen relación con el negocio de pensiones de la
organización. Los bancos, Asofondos, la
Superintendencia Financiera, los aportantes, los
beneficiarios y cualquier otro ente están representados
en esta entidad.
Descripción general Las personas juegan roles que definen cuál es su
relación con la organización. Las reglas que gobiernan
los roles son:
Para que un ente exista en la entidad Persona,
debe tener o haber tenido una relación con la
organización; en otras palabras, en esta entidad no
existen personas sin relaciones actuales o pasadas
con la organización.
Una persona puede jugar más de un rol, lo que
refleja el hecho de que las personas pueden tener
más de una relación con la entidad; por ejemplo, un
empleador que sea persona natural puede también
ser un afiliado o un pensionado.
En la generalidad de los casos, los roles son
jugados de manera temporal; por ejemplo, la
persona comienza a hacer aportes en una cierta
fecha y (posiblemente) termina de hacerlos en otra
fecha. Lo anterior explica por qué este modelo no
151
Entidad de negocio EN-D001 Persona
muestra muchas de las entidades que normalmente
se manejan como afiliados, aportantes, etc.
Las personas se dividen en personas naturales y
personas jurídicas, estos 2 subconjuntos son disyuntos
y existe cierta especialización, por ejemplo, las
personas jurídicas no pueden ser afiliados.
Entidades hijas Natural (en adelante Persona Natural)
Jurídica (en adelante Persona Jurídica)
Entidades
relacionadas
Afiliación
Recaudo
Nómina Pensionados Cuota Parte Pensional
Bono Pensional
Entidad de negocio EN-D002 Afiliación
Definición Representa la información asociada al rol de afiliado de
una persona.
Descripción general Una afiliación se produce bajo las siguientes
circunstancias: primero, una persona natural adquiere
el carácter de afiliado al Sistema General de
Pensiones; segundo, una persona (natural o jurídica)
adquiere el carácter de empleador de otra persona
natural.
Entidades hijas Ninguna
Entidades
relacionadas
Persona
Persona Natural
Historia_Laboral
Reconocimiento
Recaudo
152
Entidad de negocio EN-D002 Afiliación
Bono_Pensional
Entidad de negocio EN-D003 Recaudo
Definición Representa la información asociada a los aportes
periódicos recibidos en las cuentas de los afiliados,
realizados por un empleador.
Descripción general Un recaudo proviene de una persona, bien sea natural o jurídica, por concepto de aportes hacia una persona natural. Así mismo, un recaudo es procesado por una persona jurídica que asume el rol de operador y es recibido por una persona jurídica que asume el rol de banco. Una agregación de recaudos compone una historia laboral. Un recaudo se clasifica en: Recaudos pagados, los que efectivamente fueron
recibidos; pueden estar asociados a un afiliado
válido o a una persona natural que no es un
afiliado (lo que hoy se conoce como aportes de no
vinculados).
Recaudos presuntos, son recaudos que no se
recibieron para afiliados válidos y que para esos
afiliados no existe una novedad que justifique el no
aporte. Actualmente son conocidos como aportes
presuntos o como debido cobrar dependiendo de la
época en que se generaron.
Los recaudos pueden ser pagados (efectivamente
recibidos) o presuntos (los que se esperaban y que no
llegaron).
Entidades hijas Pagado (en adelante Recaudo Pagado)
Presunto (en adelante Recaudo Presunto)
Entidades Persona
153
Entidad de negocio EN-D003 Recaudo
relacionadas Historia_Laboral
Afiliación
Entidad de negocio EN-D004 Historia_Laboral
Definición Representa la información acumulada de los aportes
para un afiliado específico.
Descripción general La información de historia laboral puede corresponder a varios empleadores o a aportes como independiente y carecerá de aquellos periodos en los que no hubo aportes. El histórico de aportes registrados en la historia laboral pertenecen a una afiliación específica; la historia laboral es base de cálculo tanto para un bono pensional como para un reconocimiento. Parte de la historia laboral está constituida por la información de los aportes que le fueron consignados al afiliado en otras administradoras en que pudo haber estado. Estas administradoras envían la información de aportes en el momento en que se realiza el traslado del afiliado. Dicha información pasa a formar parte de la historia laboral del afiliado.
Así mismo, la historia laboral es la base para el
reconocimiento; el vínculo entre éstas dos se da a
través de la afiliación, puesto que un reconocimiento
pertenece a una afiliación específica y a su vez una
afiliación comprende un conjunto de historias laborales
del individuo.
Entidades hijas Ninguna
Entidades
relacionadas
Afiliación
Recaudo
Entidad de negocio EN-D005 Bono Pensional
154
Entidad de negocio EN-D005 Bono Pensional
Definición Representa la información asociada a los bonos
pensionales de todas las clases, ya sean emitidos por
el ISS o por otras entidades.
Descripción general Un bono pensional es contribuido por una persona jurídica específica; además, un bono pensional es una parte integral de un reconocimiento. El bono pensional toma como base de cálculo la historia laboral de un afiliado; el vínculo entre estas dos se da a través de la afiliación, puesto que un bono pensional se asocia a una afiliación específica y a su vez una afiliación comprende un conjunto de historias laborales del afiliado.
Entidades hijas Ninguna
Entidades
relacionadas
Afiliación
Persona Jurídica
Reconocimiento
Entidad de negocio EN-D006 Reconocimiento
Definición Representa los datos asociados al reconocimiento de la
pensión.
Descripción general El reconocimiento contiene información tal como la fecha en que se genera, criterios usados, número de semanas incluidas, datos de bonos incluidos y cuotas partes pensionales que serán parte del reconocimiento de la pensión. El reconocimiento es causado a una afiliación y tiene como base la historia laboral (a través de la afiliación), el bono pensional (si existe) y la cuota parte pensional (si existe), del afiliado. El reconocimiento es el proceso por medio del cual se realiza el cálculo de la pensión.
Entidades hijas Ninguna
Entidades
relacionadas
Afiliación
Bono Pensional
Cuota Parte Pensional
155
Entidad de negocio EN-D006 Reconocimiento
Nómina Pensionados
Entidad de negocio EN-D007 Nómina Pensionados
Definición Representa la información asociada a los pagos
realizados a los beneficiarios de prestaciones.
Descripción general Representa los pagos realizados a los pensionados o quienes tengan derecho a dicha pensión (en ausencia del pensionado), en base al reconocimiento que previamente se les ha hecho. En caso de que existan cuotas partes pensionales, el ISS calcula el total de las mismas por cada entidad concurrente para enviar la respectiva cuenta de cobro. El beneficiario de una pensión es una persona natural.
Entidades hijas Ninguna
Entidades
relacionadas
Persona Natural
Reconocimiento
Cuota Parte Pensional
Entidad de negocio EN-D008 Cuota Parte Pensional
Definición Representa información relacionada con montos
periódicos que la organización debe pagar a otras
entidades para contribuir al pago de pensionados en
otras entidades o que recibe de otras entidades para
contribuir al pago de pensionados de la organización.
Descripción general Las cuotas partes pensionales están destinadas a uno de los pensionados de la organización; así mismo las cuotas partes pensionales son provistas por una persona jurídica, cuando son recibidas, o pueden estar dirigidas a una persona jurídica, cuando son emitidas; en cualquier caso, las operaciones de cobro y pago de las cuotas partes pensionales son entre personas jurídicas.
Entidades hijas Ninguna
156
Entidad de negocio EN-D008 Cuota Parte Pensional
Entidades
relacionadas
Nómina Pensionados Persona Jurídica
Reconocimiento
4.2.3 Modelo conceptual
El modelo conceptual de las entidades de negocio representa el primer nivel de
abstracción acerca de los datos fundamentales desde el punto de vista del
negocio, y cómo estos datos cumplen con unas reglas de negocio para
relacionarse entre sí; por ejemplo, una afiliación implica la existencia de una
persona natural (el afiliado) y una persona (natural o jurídica) el empleador, este
último podría ser vacío para el caso de los trabajadores independientes.
157
Este modelo conceptual fue creado inicialmente con la información capturada y
analizada de las entrevistas con el grupo de negocio. Posteriormente fue validado
con el grupo de arquitectura.
4.2.4 Análisis del estado actual de la AI
En esta sección se presenta el análisis realizado a la situación actual de la
arquitectura de información desde cuatro perspectivas; análisis de las fuentes de
datos, análisis de la información, análisis de gobierno de datos y análisis de
riesgos de seguridad. Para cada una de estas perspectivas se presenta una serie
de hallazgos como producto del análisis realizado y que se documentan siguiendo
la plantilla correspondiente.
4.2.4.1 Análisis de fuentes de datos
Por fuentes de datos se entiende todos aquellos conjuntos de información que son
creados, consultados, modificados o borrados como parte de los procesos de
negocio de las entidades.
A diferencia del modelo conceptual presentado en el numeral anterior, las fuentes
de datos tienen existencia real, son objetos del mundo físico, utilizadas
actualmente o con potencial de uso en la organización.
Las más comunes e importantes fuentes de datos son las bases de datos (en
adelante BD) de uso corriente en la organización. Inicialmente se manejó un
inventario entregado por el ISS de cerca de 50 bases de datos.
La información de las fuentes de datos fue capturada de las entrevistar realizadas
al grupo de arquitectura. A continuación se utiliza Plantilla 3 para documentar el
158
inventario de fuentes de datos, donde se presenta la lista de las fuentes de datos,
una descripción y datos técnicos asociados.
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
afe
Soporta la
aplicación para
controlar el flujo de
expedientes de
solicitud de
prestaciones
económicas
44000 358 1047 44 42
auditoria
Mantiene los
registros de
inclusiones o
modificaciones el
tablas de otras
bases de datos
475000 511 5 3 0
autol
Mantiene
información de
recaudos del año
1995 (junio) al
2006 base para
migración a
Sabass recaudo.
Esta BD se usa
sólo eventualmente
en casos de
corrección de HL
570000 1467 1525 106 135
autol_2000 Autoliquidación 33000 79 2 1 144
159
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
Año 2000
autol_2001 Autoliquidación
Año 2001 33000 82 1 1 144
autol_2002 Autoliquidación
Año 2002 33000 78 3 1 144
autol_2003 Autoliquidación
Año 2003 33000 78 3 1 144
autol_2004 Autoliquidación
Año 2004 33000 78 3 3 144
autol_2005 Autoliquidación
Año 2005 33000 78 3 1 144
autol_2006 Autoliquidación
Año 2006 33000 78 3 1 144
autol_95 Autoliquidación
Año 1995 33000 113 35 1 138
autol_96 Autoliquidación
Año 1996 33000 107 7 1 144
autol_97 Autoliquidación
Año 1997 33000 107 36 1 144
autol_98 Autoliquidación
Año 1998 33000 146 30 1 144
autol_99 Autoliquidación
Año 1999 33000 112 13 1 150
autol_com
Información
complementaria
para el recaudo
1995 - 2006
66000 1856 476 1 0
160
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
basica
Información de la
Base de datos de
la Registraduría
33000 13 289 2 3
bonos
Incluye la
información de
Bonos
Pensionales,
modalidad 1 y 2
6600 115 160 65 15
comprobador
Información
comprobación de
derechos EPS
84000 70 16 6 3
cuotascobrar
Mantiene la
información de las
cuotas partes
pensionales por
cobrar a otras
entidades
7000 39 103 20 0
cuotaspagar
Mantiene la
información de las
cuotas partes
pensionales por
pagar a otras
entidades
1100 15 18 9 15
db_cobrar
Incluye la
información del
debido cobrar para
aportantes entre
1967 y 1994
4400 30 35 3 78
161
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
devoluciones
Mantiene la
información de
devoluciones que
debe hacerse a las
otras
administradoras
para el caso de
aportes de no
vinculados y
traslados de
régimen
También contiene
las devoluciones
que deben hacer
las otras
administradoras a
la organización en
razón de traslados
y de aportes de no
vinculados (en las
otras
administradoras) a
vinculados ISS
60200 113 198 46 30
digitalizahl
Información de las
imágenes
digitalizadas de los
expedientes de
pensiones de la
Seccional Valle
5500 13 0 2 0
exterior Información de 2200 67 96 8 112
162
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
afiliación y
facturación de los
afiliados a
“Colombianos en el
Exterior”
gesoiss Información de la
ARP 2200 44 84 12 132
gestion_doc
umentos
Información del
proyecto de gestión
documental
(inactiva)
2200 17 1 1 51
gproc
Soporta 9 módulos
que son usados
para automatizar
los procesos de
recaudos
33000 340 1593 42 15
histlab
Contiene la Historia
Laboral del periodo
1967 a 1994
138000 251 469 37 237
hlintranetweb
Un subconjunto de
HISTLAB que es
usado para
responder las
consultas de HL
desde la intranet
6000 65 31 1 0
hltradicional
Contiene
procedimientos y
tablas de trabajo
para consulta de
1200 570 47 1 0
163
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
HL periodos 67 -
94
interfaz_histl
ab
Inactiva.
Información de
proyecto para
consolidación de
HL
2200 24 19 1 0
master Base de datos
propia de Sybase 500 59 15 2 0
model Base de datos
propia de Sybase 3 0 0 1 0
nominapen
Soporta la
aplicación de
Nómina de
Pensionados
84300 636 1150 148 302
nominapen_
historico
Mantiene la
información
histórica de la
Nómina de
Pensionados (oct
2003 a la fecha)
181000 36 5 23 0
pensionados
BD de trabajo para
apoyar migración
de nómina de
pensionados
67000 993 892 229 9
pensiones
Soporta
aplicaciones de
Sentencias
Judiciales y
2200 76 19 4 96
164
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
Cálculos
Actuariales
procesos_gn
i
Base de datos de
apoyo a procesos
GNI
131000 592 429 419 0
procesos_gn
i_autoliss
Base de datos de
apoyo a procesos
GNI
12000 150 164 1 0
recaudo_inc
onsistencias
Mantiene la
información de
inconsistencias de
recaudo. Una vez
corregidas, los
registras pasan a
SABASS recaudos
119000 76 19 53 45
sabass
Incluye toda la
información de
afiliaciones
162000 285 527 159 399
sabass_reca
udo
Incluye toda la
información del
recaudo,
comenzando en
1995
1130000 207 523 294 48
siafeps Información de la
EPS del ISS 132000 220 358 78 489
sybmgmtdb Base de Datos del
sistema 1000 12 55 1 0
sybsystemdb Base de Datos del
sistema 3 1 0 1 0
165
Nombre Descripción Tamaño
(Mb)
Número
de
Tablas
Número
de
Procedi-
mientos
Número
de
Vistas
Número de
Disparado-
res
sybsystempr
ocs
Base de Datos del
sistema 500 6 564 1 0
tempdb
Base de Datos
temporal del
sistema
39004 0 0 1 0
temporal
Información de
auditoría de las BD
del sistema
autol_95 a
autol_2006
12000 770 2 1 0
traslados_pe
nsiones
Soporta la
información de
traslados entrantes
y salientes desde y
hacia otras
administradoras
3300 53 161 14 0
Tabla 5. Inventario inicial de fuentes de datos
Además de las bases de datos listadas anteriormente, existen las bases de datos
de: Tutelas, Derechos de petición, CIANI (que soporta los procesos jurídicos a
nivel nacional por demandas en contra del ISS) y Procesos de cobro coactivo (que
soporta los procesos de recuperación de cartera a través de vías coercitivas
legales).
Sobre este inventario inicial, el ISS identificó las 16 principales bases de datos, las
cuales se muestran en la siguiente sección.
166
Fuentes de datos consideradas en este estudio
A continuación se muestra el nombre y la descripción de las 16 fuentes de datos
principales del ISS.
Secuencia Base de datos Descripción
1 AFE Soporta la aplicación para controlar el flujo de
expedientes de solicitud de pensiones
2
AUDITORIA Mantiene los registros de inclusiones o
modificaciones en tablas de otras bases de
datos
3 CUOTASCOBRAR Mantiene la información de las cuotas partes
pensionales por cobrar a otras entidades
4 CUOTASPAGAR Mantiene la información de las cuotas partes
pensionales por pagar a otras entidades
5 DB_COBRAR Incluye la información del debido cobrar para
aportantes entre 1967 y 1994
6
DEVOLUCIONES Mantiene la información de devoluciones que
deban hacerse a las otras administradoras para
el caso de aportes de no vinculados y traslados
de régimen
También contiene las devoluciones que deben
hacer las otras administradoras a la
organización en razón de traslados y de aportes
de no vinculados (en las otras administradoras)
a vinculados ISS
7 GPROC Soporta 9 módulos que son usados para
automatizar los procesos de recaudo
167
Secuencia Base de datos Descripción
8 HISTLAB Contiene la Historia Laboral del periodo 1967 a
1994
9 HLINTRANETWEB Un subconjunto de HISTLAB que es usado para
responder las consultas de HL desde la Intranet
10 HLTRADICIONAL Mantiene la HL para periodos posteriores a
1994
11 NOMINAPEN Soporta la aplicación de Nómina de
Pensionados
12 NOMINAPENHISTOR
ICO
Mantiene la información histórica de la nómina
de pensionados
13
RECAUDO
INCONSISTENCIAS
Mantiene la Información de inconsistencias de
recaudo. Una vez corregidas, los registros
pasan a SABASS recaudos.
14 SABASS Incluye toda la información de afiliaciones y
soporta la aplicación del mismo nombre
15 SABBAS RECAUDO Incluye toda la información del recaudo
comenzando en 1995
16
TRASLADOS
PENSIONES
Soporta la información de traslados entrantes y
salientes desde y hacia las otras
administradoras
Tabla 6. Lista de las 16 fuentes de datos más importantes
Nota: las bases de datos con texto de color negro son parte del presente
documento.
168
Otras fuentes de datos consideradas en el estudio
Se han considerado otras fuentes de datos que por la situación actual de la
organización son ampliamente utilizadas (o podrán serlo) en la operación normal.
Secuencia Fuente de Datos Medio Descripción
1 Facturación de
Aportes
Microfichas,
Imágenes,
Documentos
Información resultante de los
procesos de facturación del
periodo 67 - 94
2 Información sistema
ALA
Microfichas,
Imágenes,
Documentos
Resultado de la información
provista por los empleadores que
usaban (o usan), el sistema ALA
para informar los aportes
3 Tarjetas de Reseña Papel,
Archivo
magnético en
C/marca y
otras
seccionales
Tarjetas usadas en las
seccionales comenzando en
1967
4 Auto Liquidación de
Aportes
Documentos,
Magnético
Archivos que contienen
información de aportes para el
periodo 1995 - 2005
Tabla 7. Otras fuentes de datos
Relación entre las entidades de negocio y las fuentes de datos
A partir de las entidades de negocio y las fuentes de datos se puede establecer la
manera en que estas últimas implementan las primeras en la actualidad; a partir
169
de ello se analiza esta relación. A continuación se utiliza la Plantilla 4 para
representar gráficamente la dependencia entre entidades de negocio y las fuentes
de datos.
Entidades de Negocio
Fuentes de datos PERSON
A
AFILIACIO
N
RECAUD
O
HISTORI
A
LABORAL
BONO
PENSIONA
L
RECONOCI
-
MIENTO
PAGO
PRESTACI
O- NES
CUOTAS
PARTES
PENSIONALE
S
CUOTASCOBRAR
Ver
Nota 1
X X X
CUOTASPAGAR
X X X
DB_COBRAR
Ver
Nota 2 X
X
DEVOLUCIONES X X X
GPROC
X
HISTLAB X
X
X
HLTRADICIONAL
X
NOMINAPEN X
X X
RECAUDO
INCONSISTENCIA
S
X
X
SABASS X
X X X
X
SABBAS
RECAUDO X X X X X
TRASLADOS
PENSIONES X
X
FACTURACION
APORTES
Ver
Nota 3
Ver
Nota 3
INFORMACION
SISTEMA ALA X
Ver
Nota 4
Ver
Nota 4
TARJETAS DE
RESEÑA
Ver
Nota 5
Ver
Nota 5
Ver
Nota 5
AUTOLIQUIDACIO
N DE APORTES X X X
X
170
Tabla 8. Entidades de Negocio vs Fuentes de Datos
En la Tabla 8, una “X” en el cruce de una entidad de negocio con una fuente de
datos, indica que la fuente mantiene información que es parte de la entidad de
negocio.
Esta matriz muestra que la entidad de negocio Reconocimiento tiene relación con
la mayoría de las bases de datos consideradas en este estudio; lo mismo ocurre,
aunque en menor proporción, con las entidades de afiliación e historia laboral.
Por el lado de las fuentes de datos, Sabass y Sabass Recaudo tienen una buena
proporción de la información de las entidades.
Esta matriz también muestra las tablas que son críticas para el funcionamiento de
la organización; aquellas que más relaciones tienen con las entidades del negocio
son más críticas que las que sólo tienen unas cuantas relaciones.
Todas las entidades de negocio tienen relaciones con una o más de las fuentes
datos, lo que permite asegurar que no se han considerado entidades que no estén
representadas en las fuentes.
Nota 1: La entidad de negocio “Persona”, tal como está concebida, no está
representada en las fuentes de datos, sino que más bien está diluida en ellas a
través de tablas (que en realidad corresponden a roles de las personas), como
afiliados, empleadores, bancos etc.
Nota 2: Esta fuente de datos está destinada para mantener la información del
periodo 1967 1994.
Nota 3: Existe la relación si es necesario que se realicen correcciones basadas en
la facturación de aportes.
Nota 4: Existe la relación si es necesario que se realicen correcciones basadas en
la información del sistema ALA.
171
Nota 5: La relación se produce si es necesario correlacionar los números de
afiliación con el documento de identidad del afiliado.
Hallazgos
Después de realizar un análisis, a nivel de esquema de las bases de datos del ISS
Sabass, Sabass Recaudo, AFE y Nómina de Pensionados, se presenta a
continuación lo observado según la relación que tienen con las líneas de negocio,
los conceptos ontológicos que manejan y su diseño lógico y físico.
A continuación los hallazgos se documentan de acuerdo a la Plantilla 8.
Hallazgo H-D001 Relación de las cuatro principales bases de
datos con las líneas de negocio
Descripción general Algunas de las bases de datos analizadas se relacionan con
las tres líneas de negocio del ISS, mientras que otras son
específicas para pensiones.
Análisis Sabass y Sabass Recaudo son compartidas por las tres
líneas de negocio del ISS: salud, pensión y riesgos
profesionales. Como tales, contienen datos que en algunos
casos son comunes a las líneas y en otros casos son
específicos a una línea en particular. Para el reconocimiento
de pensión, se debe conservar información de aportes en
salud. También se debe mantener información de la línea
salud para los casos de recuperación de cartera que deben
ir al ISS y no a la actual EPS.
Las bases de datos AFE y Nómina de Pensionados son
específicas para la línea de pensiones.
Soporte Modelos entidad/relación de las cuatro bases de datos en
estudio, proporcionados por el ISS.
172
Hallazgo H-D001 Relación de las cuatro principales bases de
datos con las líneas de negocio
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D002 Conceptos ontológicos manejados por las
cuatro principales bases de datos
Descripción general Las cuatro bases de datos analizadas, Sabass, Sabass
Recaudo, AFE y Nómina de Pensionados, manejan sus
propios conceptos ontológicos.
Análisis La base de datos Sabass tiene información de Afiliados
(incluidos pensionados), Afiliaciones, Aportantes, Historia
Laboral y Reconocimientos tales como pensiones y auxilios
funerarios.
La base de datos Sabass Recaudo maneja Aportes.
La base de datos AFE maneja trámites de reconocimientos
de pensiones.
La base de datos Nómina de Pensionados maneja pagos a
pensionados.
Soporte Modelos entidad/relación de las cuatro bases de datos en
estudio, proporcionados por el ISS.
Severidad Alta
173
Hallazgo H-D002 Conceptos ontológicos manejados por las
cuatro principales bases de datos
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D003 Diseño de las cuatro principales bases de datos
Descripción general En cuanto al diseño de las cuatro principales bases de
datos, pueden existir problemas de no-conformidad y
replicación; existen problemas de coexistencia de datos
distintos al objeto de cada base de datos, así como
integridad referencial6.
Análisis Cada una de las bases de datos analizadas maneja
información de personas, naturales y jurídicas, en los roles
de afiliado, aportante, beneficiario, pensionado. No se ha
hecho aún una validación de consistencia (“conformidad”)
entre ellas, pero existe la posibilidad de que no sean
“conformes”.
Las personas, naturales y jurídicas, pueden jugar diversos
roles simultáneamente y/o a lo largo del tiempo. Por
ejemplo, una persona natural puede ser simultáneamente
afiliado y aportante. El diseño de las bases de datos
consideradas maneja los roles como entidades distintas
6Se entiende por integridad referencial la capacidad de las bases de datos que permite que un
campo definido como llave foránea en una entidad (tabla en este caso) sólo pueda contener
valores que existen como llave primaria de la entidad referenciada.
174
Hallazgo H-D003 Diseño de las cuatro principales bases de datos
replicando posiblemente información propia de la persona y
no del rol.
En las bases de datos coexisten datos propios del modelo
ontológico del negocio con otros que sirven de apoyo a la
lógica de las aplicaciones utilizadas. Los primeros interesan
al nuevo negocio de Colpensiones, mientras los otros no
necesariamente.
En la base de datos Sabass se observa un problema de
integridad referencial específicamente en lo que se refiere a
la entidad Sucursal.
Soporte Modelos entidad/relación de las cuatro bases de datos en
estudio, proporcionados por el ISS.
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
4.2.4.2 Gobierno de datos
En esta sección, se presenta el estado actual del gobierno de datos que fue
identificado de acuerdo a las entrevistas realizadas con el grupo estratégico y de
negocio, además de documentos suministrados vía e-mail.
Se utiliza la Plantilla 8 para documentar los hallazgos sobre el gobierno de datos.
175
Hallazgo H-D005 Falta de una autoridad de la información
Descripción general La organización carece de un área / funcionario cuyo
responsabilidad primordial sea la de mantener la calidad de
los datos.
Análisis Ninguna de las áreas que actualmente realizan corrección
de los datos, tiene como responsabilidad principal mantener
la calidad de los datos y además tiene otras funciones
diferentes de la corrección.
Existe un comité para atacar problemas de información,
conformado por la GNI y por el DNAR, pero nuevamente la
función principal de esas áreas no es la corrección y el
mantenimiento de los datos
Soporte Documento word “Organigrama ISS JK” de fecha Julio 31,
2010. Reuniones realizadas en particular octubre 19, correo
enviado por José Bocanegra a la Universidad en octubre 22,
2010
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
A continuación se utiliza la Plantilla 5 para documentar la situación actual del
gobierno de datos, de acuerdo a los criterios definidos por el modelo de referencia
de gobierno de datos seleccionado en la etapa de preparación.
176
CRITERIOS EXISTE (S/N) OBSERVACIONES
Guía metodológica
Diseño organizacional N
Principios de datos N
Roles y responsabilidades S Comité para problemas de información
Seguridad y privacidad N
Dominios de datos N
Calidad de datos S independiente por áreas
Métricas N
COMENTARIOS
No existe un gobierno de datos definido y en su defecto existe un comité para atacar problemas de información y se dedican a solucionar problemas y no a prevenirlos como debería ser el orden de proceder en este aspecto.
Cada área o en el peor de los casos por aplicación se hacen esfuerzos independientes y no coordinados para la corrección de datos.
Ni el comité ni los grupos que hacen corrección de datos tienen como objetivo principal la calidad de los datos y cumplen con otras responsabilidades asignadas como de mayor prioridad.
4.2.4.3 Análisis de la Información
En la actualidad existe un comité que se encarga de generar proyectos que
buscan el mejoramiento de la calidad de la información, así como la implantación
de proyectos que mejoren la operación.
Es así como a la fecha existen algo más de 30 proyectos en marcha, como se
muestra en el Anexo N° 8. En este anexo, los valores anotados en la columna
avance corresponden a un avance estimado en cuanto a lo que el proyecto
necesita para ponerse en marcha y no al valor efectivamente avanzado en la
resolución del problema.
Como se puede apreciar, existe una amplia gama de proyectos que este comité ha
emprendido, una parte de los proyectos implica la construcción de código ad-hoc
para realizar las modificaciones objeto del proyecto.
177
La GNI ha informado que existen procedimientos claros para mantener las
diferentes versiones del código necesario para hacer los cambios (utilizando
Sourcesafe y Sharepoint); así mismo existen procedimientos claramente
establecidos para poner el software desarrollado en producción y existe total
independencia entre los servidores de desarrollo y producción.
Sin embargo, no existe un grupo independiente (auditoría), que pruebe que los
cambios a aplicar son precisos; las pruebas las realizan los funcionarios del área
usuaria y el personal de la GNI .
En conclusión, esta sección ha mostrado cómo en los últimos años ha habido un
esfuerzo importante en el proceso de reconstrucción de los datos que no fueron
actualizados en su oportunidad. Es claro que los esfuerzos hechos a posteriori son
más complicados, pueden tener problemas de identificación de información, son
intensivos en recursos humanos y no siempre generan los mejores resultados.
A esto hay que sumar el hecho que la organización debe otorgar pensiones a
afiliados con tiempos trabajados en entidades públicas, lo que exige conseguir
información de dichas entidades o aquellas que las hayan reemplazado.
Mucho se ha hecho en el ISS para mejorar los datos; persiste sin embargo la
impresión que el esfuerzo no ha logrado alcanzar los niveles requeridos para dar
un óptimo servicio. Sin duda, hay mucho campo para mejoramiento, comenzando
por el diseño de buenos indicadores que permitan validar cuál es realmente la
calidad de la información (particularmente confiabilidad, integridad y completitud)
que maneja la organización.
Hallazgos
Esta sección del documento presenta los hallazgos sobre la Arquitectura de
Información actual y es un complemento a la información contenida en las
secciones anteriores.
178
Están clasificados por generales, específicos y por entes externos al ISS. Cada
uno de los hallazgos se presenta de acuerdo al formato de la Plantilla 8.
Hallazgos generales
Hallazgo H-D006 No existe suficiente información sobre los datos
Descripción general Falta información más precisa (o al menos el grupo no tuvo
acceso a la información), sobre la calidad de los datos.
Análisis Existe información básica sobre la calidad de los datos, pero
ante lo crítico del problema, sería de esperarse que dicha
información fuera mucho más sofisticada de tal forma que
sirviera de base para la toma de decisiones sobre el
mejoramiento de calidad de los mismos.
Podrían ejecutarse ejercicios de estratificación (o alguna otra
clasificación que aporte claridad al problema de información),
Para decidir si todos los casos se tratan de la misma manera.
Podría ser que en algunos casos, procesos automáticos
sofisticados pudieran ayudar a resolver situaciones que no
necesiten la intervención de un funcionario del ISS.
Existe información valiosa que no se está aprovechando,
derivada de los procesos de reconocimiento de pensiones.
Se podría aprender mucho al tipificar el tipo de proceso
requerido al momento del reconocimiento, para así intentar
una clasificación de historias laborales de afiliados que se
encuentren próximos a pensionarse y los tipos de procesos
que se prevé podrían ser necesarios para esos afiliados
Soporte Reuniones con José David Márquez en diferentes fechas,
Reunión con Sandra P Quevedo en noviembre 3, 2010
Severidad Alta
Media
Baja
179
Hallazgo H-D006 No existe suficiente información sobre los datos
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D007 Falta información sobre el uso potencial de
fuentes alternas de datos
Descripción general Información más detallada sobre las fuentes alternas de
información, podría ayudar a diseñar nuevos procesos de
depuración.
Análisis Existen fuentes alternas de datos que hoy se usan de
manera marginal, sobre las cuales no se tiene un buen
conocimiento (tal como volúmenes, estado, diseños,
confiabilidad y ubicación). Si se adquiere conocimiento
preciso de dichas fuentes (más la identificación de fuentes
que aún no se han descubierto), se podría identificarlas
como posibles entradas en procesos masivos que podrían
ayudar en la corrección de inconsistencias y en la aplicación
de aportes faltantes.
Soporte Visita a la Seccional Cundinamarca para verificar las tarjetas
de reseña en octubre 19, 2010
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
180
Hallazgo H-D008 Algunas soluciones son aisladas y puntuales
Descripción general Algunos proyectos producen soluciones que no están
integradas con otras soluciones ya implantadas o que
resuelven sólo una parte del problema
Análisis Existe dispersión de esfuerzos en producir soluciones, a lo
largo de varias entrevistas se ha encontrado que los
usuarios han construido pequeñas aplicaciones para atender
problemas que no son resueltos por la aplicación provista.
Estas soluciones son necesariamente aisladas y puntuales.
Soporte Visita a la Seccional Cundinamarca en octubre 19, 2010 en
donde se encontró una aplicación para consultar números
de afiliación. Reunión de reconocimiento en de noviembre 2,
2010, se describió una aplicación hecha por los usuarios.
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgos específicos
Hallazgo H-D009 Uso de llaves ad hoc para identificar a
empleadores y afiliados
Descripción general Al inicio del ISS y durante varios años, el Instituto empleó
llaves diferentes de la cédula y el NIT para identificar a
afiliados y empleadores
Análisis La decisión de utilizar dichas llaves, propias sólo del ISS,
181
Hallazgo H-D009 Uso de llaves ad hoc para identificar a
empleadores y afiliados
estructuradas para incluir información adicional (por ejemplo
la seccional de ISS y hasta la actividad económica del
empleador) ha causado serios problemas para
correlacionarlas con las llaves actuales de cédula y NITS.
Es así como diferentes afiliados pueden compartir el mismo
número de afiliación, un afiliado tener más de un número de
afiliación, o un empleador tener diferentes números
patronales si tenía oficinas en más de una seccional del ISS
o si algún funcionario decidía incluir al empleador con una
nueva actividad económica.
La puesta en uso de ese método de identificación aunado a
pobres procedimientos y controles y a limitantes en el
espacio de almacenamiento (típicas en los equipos de
cómputo de hace unos cuantos años), comenzó a generar
problemas que aún hoy se viven. La actual incapacidad para
asociar un número de afiliación con una cédula de
ciudadanía para algunos afiliados (o el intenso esfuerzo
necesario para hacerlo), es una muestra de la problemática
asociada con esta decisión tomada hace ya muchos años.
Soporte Reunión para ver paso a paso corrección de HL 67-94
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
182
Hallazgo H-D011 Problemas causados por falta de actualización
oportuna
Descripción general Los esfuerzos por mantener una historia laboral actualizada
son recientes, comparado con la edad de la información.
Análisis Durante varios años el ISS no mantuvo un registro
automático de los aportes de los empleadores y de la
historia laboral de los afiliados.
La carencia de esta actividad, que debió ser periódica,
consistente y precisa, produjo grandes problemas cuando se
decidió que se debería actualizar esta información. De
hecho, en este momento se siguen viviendo las
consecuencias de esta falta de procesamiento.
Las últimas administraciones en el ISS han hecho un
esfuerzo grande para generar y mantener la HL, pero aún
quedan vacíos de información que deben ser corregidos
manualmente ya sea del periodo 67 – 94 o post 94.
Soporte Reuniones de verificación del paso a paso periodos 67 – 94
y post 94
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D012 Problemas causados por la dispersión de datos
en diferentes BD
Descripción general Datos dispersos en diferentes BD causan riesgos de no
actualización de todas las instancias cuando se actualiza
183
Hallazgo H-D012 Problemas causados por la dispersión de datos
en diferentes BD
una de ellas.
Análisis Puesto que las BD no están integradas, la información
común debe replicarse en cada una de ellas. Ocurre
entonces que la modificación de información de una de las
instancias debe generar actualizaciones en todas las demás
con el propósito de mantener la información al mismo nivel
de actualización. Inevitablemente ocurre que al cabo de
algún tiempo se tienen datos diferentes sobre el mismo
sujeto y se desconoce cuál es la información correcta.
Soporte Revisión de los diccionarios de datos provistos por el ISS.
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D023 Problemas estructurales en base de datos AFE
Descripción general La base de datos AFE contiene información duplicada sobre
personas, que también existe en la base de datos de
afiliación Sabass; además, la base de datos AFE contiene
información de acceso/actividad de los diferentes
operadores.
Análisis La información de personas, en su rol de afiliado, reside en la
base de datos Sabass; sin embargo, en la base de datos
AFE, específicamente en la tabla Gral_Ma_Persona, se
184
Hallazgo H-D023 Problemas estructurales en base de datos AFE
duplica esta información para aquellos afiliados que solicitan
el reconocimiento de la pensión, pues nuevamente se
especifica información personal como nombres, sexo, fecha
de nacimiento, datos de contacto, además de tener extenso
detalle sobre números anteriores de afiliación (estructurados
como diferentes atributos en la tabla), datos sobre
invalidez/muerte del afiliado, entre otros.
De igual forma sucede con información sobre el otorgamiento
de la pensión, tal como número de resolución, fecha de
resolución, tipo de riesgo por el que se otorga, que reposa en
AFE en la tabla Gral_Ma_Persona, así como en Sabass y en
NominaPen.
Se presenta la misma situación con la información de
aportantes, que reside en la base de datos Sabass en este
rol; en el caso de AFE, en la tabla Gral_Ma_Entidad, se
duplica información como razón social, tipo de aportante y
datos de contacto.
Lo anterior conduce a que actualizaciones en la información
de personas sobre una de las bases de datos, Sabass o
AFE, deban ser aplicadas a la otra para mantenerlas
consistentes. En caso de que un proceso de actualización no
exista, se corre el riesgo de mantener distintas versiones de
la misma información, una de las cuales es válida y otra
desactualizada.
Así mismo, la base de datos AFE contiene información
dedicada al control de acceso/actividad de los diferentes
operadores (tablas BPM); estas tablas deberían estar en una
base de datos que pueda ser accedida por todas las
aplicaciones que requieran estos servicios de control de
acceso/actividad; de esta manera no sería necesario que al
185
Hallazgo H-D023 Problemas estructurales en base de datos AFE
mismo funcionario/contratista se le creen diferentes registros
en diferentes bases de datos, bastaría con tener una sola
entrada por operador y diferentes roles dependiendo del área
en que trabaje.
Soporte Diccionarios de datos Sabass, AFE y NominaPen.
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D033Caprecom - Historia Laboral anterior a 1994 no
existe
Descripción general La información de la HL en Caprecom anterior a 1994 no se
mantuvo en la entidad.
Análisis Antes de la Ley 100 de 1993, la entidad no mantuvo
información de los aportes hechos por los diferentes
empleadores.
En consecuencia, cuando se hace el reconocimiento de
pensión a afiliados que trabajaron en ese periodo, debe
recurrirse a las entidades que hicieron los aportes para
allegar la información necesaria.
Soporte Reunión con directivos de Caprecom en Diciembre 2 de 2010
Severidad Alta
Media
Baja
186
Hallazgo H-D033Caprecom - Historia Laboral anterior a 1994 no
existe
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D034Caprecom - Historia Laboral 1994 y posterior
existe parcialmente
Descripción general La información de la HL en Caprecom de los años 1994 y
posteriores existe y por tanto debe ser tenida en cuenta.
Análisis A raíz de la Ley de 1993, Caprecom no pudo hacer nuevas
afiliaciones.
En el Foncap (Fondo de Pensiones de Caprecom), se
mantiene la historia laboral de los afiliados, comenzando
aproximadamente en 1998.
Actualmente esta información se tiene en cuenta para el
cálculo pensional, lo que no está incluido en la HL se ingresa
manualmente en el liquidador (tal como se explica en el
hallazgo anterior).
En la actualidad existen más o menos 3.5 millones de
registros en la base de datos de HL, los cuales deberán ser
tenidos en cuenta en el momento de la conversión de
Caprecom a la nueva entidad.
Soporte Reunión con directivos de Caprecom en Diciembre 2 de 2010
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
187
Hallazgo H-D034Caprecom - Historia Laboral 1994 y posterior
existe parcialmente
Por discutir
Hallazgos generales con relación a entes externos al ISS
Hallazgo H-D014 Problemas originados por los empleadores
Descripción general La organización recibe información de aportes proveniente
de los empleadores. Esa información puede tener problemas
de calidad
Análisis La organización tiene que recibir información originada por
entes externos que no son especializados en la generación y
procesamiento de dicha información.
Es el caso de los empleadores para quienes la generación
mensual de información hacia los entes de la seguridad
social es una carga adicional al de su normal
funcionamiento, por lo que no es de extrañar que ellos
produzcan información que no sea de la mejor calidad.
La organización debe ser consciente de que es inevitable
recibir información de baja calidad y en consecuencia debe
ser validada y complementada con especial cuidado y a la
brevedad posible, así mismo deben establecerse
mecanismos para prevenirlos, probablemente a través de
una comunicación más fluida con los entes que originan la
información.
La falta de mecanismos de rápida detección, corrección y
prevención influyó negativamente en el sistema de
Autoliquidación de Aportes (ALA), lo que causó problemas
que muchos años después aun están vigentes.
Soporte Reuniones de levantamiento de información. Particularmente
188
Hallazgo H-D014 Problemas originados por los empleadores
reunión con Colpensiones en Sep. 13 de 2010.
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Es de anotar que con el uso de “PILA” la calidad de una parte de la información ha
mejorado mucho (por ejemplo en lo que tiene que ver con completitud de la
información), mientras que otra parte de la información aún tiene problemas
relacionados con identificación de los afiliados y aportes de no vinculados.
Evidentemente PILA ha contribuido a mejorar el sistema, pero podría ayudar a
solucionar problemas aún presentes en el sistema, a través de filtros adicionales.
Hallazgo H-D017 Problemas relacionados con la estructura y el
contenido de la información de historia laboral que
acompaña a cada traslado
Descripción general Aún persisten problemas relacionados con la estructura y el
contenido de la información de la historia laboral que
acompaña a cada traslado.
Análisis Los ciclos de traslados son bastante largos, esto incide
negativamente en cómo se va depurando el proceso, puesto
que las solicitudes de traslado radicadas por una
administradora son respondidas por la otra administradora
varias semanas después (radicadas el octavo día del mes,
respondidas el día 30 del mes siguiente). Esto implica que
189
Hallazgo H-D017 Problemas relacionados con la estructura y el
contenido de la información de historia laboral que
acompaña a cada traslado
errores en la información de la historia laboral deben esperar
un nuevo ciclo, lo cual hace que el proceso de depuración
avance lentamente.
La información de traslado desde el ISS hacia las
administradoras se llama Novedad 200 y contiene 7
diferentes tipos de registros
La información de traslado desde las administradoras hacia
el ISS se llama Novedad 207 y contiene los mismos 7
diferentes tipos de registros
Sin embargo hay diferencias en los diseños de los registros
en las novedades 200 y 207.
ISS envía la información de Nómina de Pensionados cada
mes a Asofondos para que las administradoras verifiquen
que no se vayan a producir dobles pensiones.
Antes del 2006, cada administradora enviaba la información
de traslados (HL) directamente al ISS, cada formato era
diferente y nunca se aplicaron esas novedades en el ISS.
En el 2007 la Superintendencia Financiera intervino y emitió
circulares para organizar los procesos.
Ahora es Asofondos la entidad encargada de enviar la HL de
las administradoras (comenzó con la HL de septiembre de
2006), y, aunque el formato es único, existen diferentes
interpretaciones entre administradoras (cada una puede
incluir información que después no encaja con las
validaciones del ISS).
Lo anterior causa problemas; si las administradoras tienen
diferentes interpretaciones y el ISS tiene también su propia
interpretación, entonces en temas complejos se crean
190
Hallazgo H-D017 Problemas relacionados con la estructura y el
contenido de la información de historia laboral que
acompaña a cada traslado
situaciones que deben ser discutidas, llegarse a un acuerdo
e incluir los cambios. Esto toma tiempo especialmente con
los ciclos tan largos que tienen los traslados.
Para traslados realizados antes de 2006, se creó la
modalidad de “traslados por demanda”, en donde el ISS pide
la HL del afiliado y Asofondos pide a la administradora
confirmar si la HL que ya envió esta completa; en caso
contrario la administradora envía la información a
Asofondos, quien la remite al ISS
Existen también las “HL por contingencia” para afiliados que
están en procesos de pensionarse o para afiliados fallecidos.
Para los dos casos anteriores, Asofondos hace validaciones
sencillas sobre la información que se va a mandar, pero
cuando el ISS aplica validaciones más fuertes, encuentra
inconsistencias que hacen que no pueda aplicarla.
El 88% de la deuda presunta resulta ser falta de novedades
(particularmente novedades de retiro del afiliado).
Cuando se trata de trámites de pensiones que ya están en
curso (HL por contingencia), el trámite en Asofondos –
Administradoras toma entre una semana y dos meses.
En este momento se tienen más o menos 2000 trámites
urgentes en proceso.
Otros posibles problemas:
Administradora acreditó aporte de afiliado que ya se ha
traslado al ISS, tiene que enviar al ISS esa fracción de
HL y el valor correspondiente.
Administradora acreditó por error un aporte a un afiliado
191
Hallazgo H-D017 Problemas relacionados con la estructura y el
contenido de la información de historia laboral que
acompaña a cada traslado
que después se trasladó al ISS, la administradora debe
pedir al ISS la devolución de ese valor y la corrección de
la HL del afiliado.
Multiafiliación, la administradora que no se queda con el
afiliado debe devolver la comisión.
Si la información que la administradora envió no pasa la
validación de Asofondos, entonces esa información no es
visible en las consultas que hace el ISS.
Soporte Reunión con Asofondos en Oct. 4 de 2010
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-D020 Información contenida en la nueva cédula
Descripción general Desde mediados del año está vigente la nueva cédula que
contiene elementos que pueden ayudar en la operación de la
organización.
Análisis La nueva cédula podría servir como elemento de soporte en
la operación de la organización. En particular, la nueva
cédula tiene un código de barras bidimensional, que
almacena información sobre las huellas digitales de
cualquiera de los dedos de los portadores, de tal forma que
una persona no puede substituir a otra.
192
Hallazgo H-D020 Información contenida en la nueva cédula
Se debería iniciar un proyecto que investigue las reales
posibilidades del uso de la misma. Parte de este proyecto
podría ser identificar si la Registraduría ya corrigió problemas
que fueron detectados por el ISS hace algún tiempo, de tal
forma que pueda darse plena validez a su información.
Soporte Este sitio web contiene información sobre características de
la nueva cédula:
http://www.registraduria.gov.co/Informacion/cedulas_2010_a
bcpreguntas.htm
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Análisis cuantitativo
Se diseñaron indicadores que ayuden a determinar el estado de los datos respecto
a confiabilidad, integralidad (o consistencia) y completitud.
El fin principal es que dicho indicadores constituyan una forma objetiva en que los
diferentes actores al interior de la entidad puedan evaluar la salud de los datos.
Los indicadores son valores numéricos, que pueden ser calculados de manera
sencilla y en forma periódica, tal que:
Los indicadores representan un valor objetivo ligado al estado de los datos.
Los indicadores pueden ser recalculados.
193
Se puede establecer valores aceptables y óptimos para los indicadores, de
tal forma que dichos valores pueden ser utilizados como metas de
mejoramiento de la calidad de los datos.
Puesto que los indicadores pueden calcularse en cualquier momento del
tiempo, se puede ver de manera histórica la evolución del estado de los
datos.
Puesto que la fluidez de los procesos misionales depende en gran medida de la
confiabilidad de la información involucrada en cada uno de ellos, la existencia de
indicadores sobre dicha información permite identificar proyectos que deben ser
adelantados para mejorar la condición de dichos datos, de tal forma que mejores
datos ayuden a que los procesos sean más precisos y eficientes.
En este trabajo solo se proponen los indicadores descritos en este documento; sin
embargo, en la medida en que sea necesario, Colpensiones podrá diseñar nuevos
indicadores para evaluar otros aspectos de la calidad de los datos.
Los indicadores descritos aquí, han sido calculados usando una muestra del total
de los registros de las bases de datos, más adelante se presenta la metodología
empleada en el cálculo del tamaño de la muestra y de la manera en que se
seleccionaron los registros para la misma.
Todos los resultados mostrados en esta sección del documento fueron obtenidos
gracias a la asesoría de personal de la GNI, algunos de ellos fueron verificados
con la ayuda de personal del DNC.
Los valores obtenidos y presentados están abiertos a discusión; así mismo, las
consultas a las bases de datos para la creación de tablas temporales y las
consultas que generaron los valores usados para calcular los índices están a
disposición del personal técnico de Colpensiones y del ISS.
194
Para el análisis cuantitativo se utilizó el método para análisis de calidad de datos
explicado en la sección 0 y que se implementó como se describe en las siguientes
secciones.
Identificar Información crítica
Los procesos, actividades estratégicas y relevantes de la empresa y que están
directamente relacionados con su función, misión y obtención de resultados,
productos o servicios necesarios para sus clientes esta representados por los
procesos misionales de la empresa. En consecuencia la información crítica se
identificó como la información que está directamente relacionada y da soporta a
los procesos misionales. Los procesos misionales del ISS son afiliación, recaudo,
historia laboral, reconocimiento y nómina de pensionados. Para efectos de este
caso de estudio solo se ilustrara con el proceso de afiliación. Los restantes
procesos se pueden desarrollar realizando otros proyectos que progresiva e
iterativamente vayan cubriendo cada uno de los procesos.
Continuando con la implementación del diagnóstico, se contempló dos posibles
escenarios, los cuales se describen a continuación:
Escenario 1 Escenario 2
Infraestructura Colpensiones proporciona la
infraestructura necesaria para
la ejecución de las consultas,
mediante un servidor que
contiene la base de datos
forense, con alta disponibilidad
y capacidad de procesa-
miento.
La infraestructura para la
ejecución de consultas es la
de producción del ISS, con
disponibilidad y capacidad de
procesamiento limitadas.
Datos a analizar La totalidad de los datos están
disponibles para ser
Sólo una muestra de los
195
analizados. datos será analizada.
Ejecución de
consultas
Personal del ISS recibe las
consultas escritas, las ejecuta
y devuelve los resultados, que
después son analizados.
Personal del ISS recibe las
consultas escritas, las
ejecuta y devuelve los
resultados, que después son
analizados.
Para el presente diagnóstico la estrategia utilizada correspondió a la propuesta en
el Escenario 2; sin embargo, estas mismas pruebas pueden ser realizadas en un
futuro con la totalidad de los datos, como se plantea en el Escenario 1.
De esta forma, la implementación procedió de la siguiente manera:
Definición del tamaño de la muestra para que sea estadísticamente significativa:
Se utiliza un producto disponible en la web que permite calcular el tamaño de la
muestra dependiendo del nivel de confianza, el intervalo de confianza y el tamaño
de la población. Para el caso de archivos que tienen cerca de 6.5 millones de
registros, un intervalo de confianza de 2 y un nivel de confianza del 95%, es
necesario tener una muestra de 2400 registros. Este es el sitio web en donde se
puede realizar el cálculo:http://www.surveysystem.com/sscalc.htm
Definir Indicadores de Calidad
Puesto que la información almacenada en las bases de datos y archivos en
general pretende representar la realidad, es necesario que esta representación se
mantenga tan fiel como sea posible.
La realidad es muy grande y no es necesario ni útil almacenar toda la información
respecto a dicha realidad, el subconjunto de la realidad que es necesario guardar,
se conoce como la realidad de interés.
196
Una característica de la realidad es su potencial de cambio, mientras que una
parte de la misma se puede considerar muy estable (como el género del afiliado),
otra parte es por naturaleza variable, (un afiliado puede cambiar de dirección de
residencia, tener un nuevo empleador, cambiar su salario o quedar desempleado),
de tal forma que una vez se almacena información de dicha realidad, existe el
potencial de que la representación quede desactualizada en algún momento
futuro; por otra parte, la representación de la realidad puede quedar inexacta
desde el mismo momento en que se captura e igualmente la representación de la
realidad podría no ser capturada y de esta manera la representación quedar
incompleta.
Las categorías de indicadores de estado de los datos que se han definido, se
presentan a continuación utilizando el formato de la Plantilla 9:
Categoría de
Indicador
CI-D001: Completitud
Definición Es la medida que indica si la realidad de interés está
totalmente representada, este indicador no tiene en cuenta la
exactitud de la información, sólo si esta existe o no.
Nivel de cálculo Atributo
Registro
Ejemplo Parte de la realidad de interés es la fecha de nacimiento de los
afiliados; en este caso, el indicador de completitud permite
determinar el porcentaje de afiliados para los que se conoce
este atributo de interés.
Categoría de
Indicador
CI-D002: Confiabilidad
Definición Es la medida que indica la veracidad de la información
respecto a lo que intenta representar, normalmente se elige un
197
Categoría de
Indicador
CI-D002: Confiabilidad
patrón contra el cual comparar la información almacenada,
contando el número de casos en que se encuentra diferencias
Nivel de cálculo Atributo
Ejemplo El nombre de los afiliados puede ser verificado contra el
registro maestro de la Registraduría Nacional; en este caso,
un indicador de confiabilidad permite determinar el porcentaje
de veracidad de este nombre respecto al registro maestro.
Categoría de
Indicador
CI-D003: Consistencia
Definición Es la medida que indica el grado de coherencia entre dos
distintas representaciones de la realidad.
Nivel de cálculo Atributo (en tablas y/o bases de datos)
Ejemplo La dirección de contacto de las personas puede residir en
distintas fuentes de datos; un indicador de consistencia
permite determinar el porcentaje en que estas dos
representaciones del mismo atributo son las mismas.
Categoría de
Indicador
CI-D004: Accesibilidad7
Definición Indicador utilizado para representar la facilidad o dificultad de
acceder a la información.
Nivel de cálculo Este indicador no se produce a través de cálculos, sino a
través de observaciones.
Ejemplo Una fuente de datos puede ser una base de datos; en este
7El indicador no está incluido en el presente documento puesto que a la fecha no existen
mediciones confiables del mismo.
198
Categoría de
Indicador
CI-D004: Accesibilidad7
caso, accesibilidad representa el conjunto de condiciones y
restricciones existentes para que un usuario autorizado pueda
tener acceso a la información, por ejemplo acceder a la
información en una microficha es normalmente más demorado
que acceder a la misma información almacenada en una base
de datos.
Igualmente acceder a información almacenada en un servidor
que tenga demasiada carga podría tomar varios minutos, lo
cual impacta el servicio que podría prestarse en una ventanilla
a un afiliado
Categoría de
Indicador
CI-D005: Oportunidad8
Definición Indicador utilizado para representar la facilidad o dificultad de
obtener de información en el momento en que se necesita
Nivel de cálculo Este indicador no se produce a través de cálculos, si no a
través de observaciones
Ejemplo Este indicador está diseñado para mostrar cómo la
información está disponible de manera conveniente para suplir
una necesidad de la organización; de esta manera, si para la
atención en ventanilla se necesita información que no está
disponible, se puede afirmar que no existe oportunidad. Esta
carencia puede darse por la inexistencia de la información o
por la imposibilidad de accederla. No debe confundirse este
indicador con el de accesibilidad en cual mide la facilidad /
dificultad de acceder a la información
8El indicador no está incluido en el presente documento puesto que a la fecha no existen mediciones
confiables del mismo.
199
Realizar Mediciones
Para este estudio, se ha identificado un conjunto de atributos claves para los
procesos misionales de ISS (afiliación, recaudo, historia laboral, reconocimiento y
nómina de pensionados). A continuación se presenta la descripción de cada uno
de ellos, las bases de datos en las que residen, así como los cálculos de
indicadores propuestos para los mismos. Para describir las mediciones que se
realizaran se utiliza la Plantilla 10.
Atributo 1: Nombres de Afiliados
Este atributo proporciona la completa identificación de un afiliado al ISS; no-
completitud, no-confiablidad o inconsistencias en este atributo pueden impactar
negativa y fuertemente el flujo del proceso de reconocimiento de la pensión.
En la siguiente cuadro se muestra la relación de este atributo en las principales
bases de datos. Un “NO” en la columna Tabla indica que el atributo no se
encuentra en la base de datos en cuestión; en caso contrario, se especifica, la
tabla o tablas en que se encuentran los nombres del afiliado:
Base de datos Tabla
AFE Gral_Ma_Persona
Cuotas Cobrar Beneficiario
Cuotas Pagar T_CuotaPartePensionado
DB_Cobrar NO
Devoluciones Dafp_Afiliado
Histlab Afiliado
NominaPen Persona
Sabass Afiliado
200
Base de datos Tabla
Sabass Recaudo NO
Traslados Pensiones STI_Afiliado
En general, las bases de datos contienen el nombre de los afiliados como un
conjunto de 4 atributos: primer apellido, segundo apellido, primer nombre, segundo
nombre.
Debido a la importancia de este atributo para el proceso de reconocimiento de
pensión, así como a su visible replicación en las distintas bases de datos, se han
definido una serie de mediciones, a través de consultas a las distintas bases de
datos, para determinar el estado de este atributo en cuanto a completitud,
confiabilidad y consistencia. A continuación se presenta la descripción de estas
mediciones:
Prueba Descripción
Q-D001:
Completitud de información de
afiliados
Mediante esta prueba se calcula el indicador de
completitud para los nombres de los afiliados en
la base de datos de afiliación Sabass, indicando
porcentaje de valores nulos y no nulos.
Q-D007:
Confiabilidad del nombre de
afiliados
Mediante esta prueba se calcula el indicador de
confiabilidad para los nombres de los afiliados de
la base de datos Sabass respecto a la tabla de
personas de la Registraduría Nacional.
Q-D009:
Confiabilidad de la identificación
de los afiliados
Mediante esta prueba se calcula el indicador de
confiabilidad para la identificación de los afiliados,
a partir de su nombre en Sabass; esto con el fin
de identificar afiliados doblemente registrados en
201
Prueba Descripción
Sabass.
Q-D015:
Consistencia de nombres de
afiliados en Sabass y AFE
Mediante esta prueba se calcula el indicador de
consistencia para el nombre de los afiliados en
Sabass respecto a AFE; inconsistencia se da en
la medida en que el nombre reportado en AFE no
es el mismo que el reportado en Sabass para el
mismo tipo y número de documento.
Q-D016:
Consistencia de nombre de
afiliados en Sabass y Nómina
de Pensionados
Mediante esta prueba se calcula el indicador de
consistencia para el nombre de los afiliados en
Sabass respecto a Nómina de Pensionados;
inconsistencia se da en la medida en que el
nombre reportado en Nómina de Pensionados no
es el mismo que el reportado en Sabass para el
mismo tipo y número de documento.
Atributo 2: Sexo
El sexo o género es una característica de los afiliados primordial para el proceso
de reconocimiento, pues en base a este se calcula el total de semanas de
cotización requeridas para la decisión del otorgamiento de la pensión así como la
edad mínima de pensión. A continuación se detalla la aparición de este atributo de
los afiliados en las distintas bases de datos:
Base de datos Tabla
AFE Gral_Ma_Persona
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
202
Base de datos Tabla
Devoluciones Dafp_Afiliado
Histlab Afiliado
NominaPen Pensionado
Sabass Afiliado
Sabass Recaudo NO
Traslados Pensiones STI_Afiliado
De esta forma, se han definido las siguientes mediciones para la obtención de
indicadores de completitud, confiabilidad y consistencia de este atributo:
Prueba Descripción
Q-D001:
Completitud de información de
afiliados
Mediante esta prueba se calcula el indicador de
completitud para el sexo de los afiliados en la
base de datos de afiliación Sabass, indicando
porcentaje de valores nulos, válidos y no válidos;
los valores no válidos son los que se encuentra
por fuera del rango definido para este atributo en
Sabass.
Q-D014:
Consistencia entre sexo y
nombre de afiliados
Mediante esta prueba se calcula el indicador de
consistencia para el sexo de un afiliado respecto
a su nombre en Sabass; inconsistencia se da en
la medida en que el sexo del afiliado no
corresponde a un conjunto de nombres típicos
para el sexo específico.
Q-D017:
Consistencia de sexo de
afiliados en Sabass y AFE
Mediante esta prueba se calcula el indicador de
consistencia para el sexo de un afiliado en
Sabass respecto a AFE; inconsistencia se da en
la medida en que el sexo del afiliado en AFE no
203
Prueba Descripción
corresponde al reportado en Sabass para el
mismo número y tipo de documento.
Q-D018:
Consistencia de sexo de
afiliados en Sabass y Nómina
Pensionados
Mediante esta prueba se calcula el indicador de
consistencia para el sexo de un afiliado en
Sabass respecto a Nómina Pensionados;
inconsistencia se da en la medida en que el sexo
del afiliado en Nómina Pensionados no
corresponde al reportado en Sabass para el
mismo número y tipo de documento.
Atributo 3: Fecha de nacimiento
La edad de un afiliado es una característica clave en el proceso de
reconocimiento, puesto que esta influye directamente en la decisión del
otorgamiento; si un afiliado no ha cumplido la edad mínima requerida para acceder
a la pensión de vejez, no se le debe reconocer la pensión. Inconsistencias en este
atributo pueden causar inconvenientes y demoras en el proceso de
reconocimiento.
A continuación se muestra en qué bases de datos está presente el atributo fecha
de nacimiento de un afiliado:
Base de datos Tabla
AFE Gral_Ma_Persona
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones Dafp_Afiliado
204
Base de datos Tabla
Histlab Afiliado
NominaPen Persona
Sabass Afiliado
Sabass Recaudo NO
Traslados Pensiones STI_Afiliado
A continuación se presentan las mediciones que permiten obtener indicadores de
completitud, confiabilidad y consistencia de este atributo en las distintas bases de
datos identificadas.
Prueba Descripción
Q-D001:
Completitud de información de
afiliados
Mediante esta prueba se calcula el indicador de
completitud para la fecha de nacimiento de los
afiliados en la base de datos de afiliación Sabass,
indicando porcentaje de valores nulos, válidos y
no válidos; los valores no válidos representan
fechas de nacimiento anteriores a 1900.
Q-D009:
Confiabilidad de la identificación
de afiliados
Mediante esta prueba se calcula el indicador de
confiabilidad para la identificación de los afiliados,
a partir de su nombre y identificación; esto con el
fin de identificar afiliados doblemente registrados
en Sabass.
Q-D019:
Consistencia de fecha de
nacimiento de afiliados en
Sabass y AFE
Mediante esta prueba se calcula el indicador de
consistencia para la fecha de nacimiento de un
afiliado en Sabass respecto a AFE;
inconsistencia se da en la medida en que la fecha
de nacimiento del afiliado en AFE no corresponde
a la reportada en Sabass para el mismo número
205
Prueba Descripción
y tipo de documento.
Q-D020:
Consistencia de fecha de
nacimiento de afiliados en
Sabass y Nómina Pensionados
Mediante esta prueba se calcula el indicador de
consistencia para la fecha de nacimiento de un
afiliado en Sabass respecto a Nómina
Pensionados; inconsistencia se da en la medida
en que la fecha de nacimiento del afiliado en
Nómina Pensionados no corresponde a la
reportada en Sabass para el mismo número y
tipo de documento.
Atributo 4: Fecha de vinculación de afiliado
La fecha de vinculación de un afiliado ayuda a comprobar, en el momento de la
decisión de reconocimiento, si este ha cumplido el mínimo de semanas requerido
para obtener una pensión de vejez.
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones NO
Histlab Afiliado
NominaPen NO
Sabass Afiliado
Sabass Recaudo NO
Traslados Pensiones NO
206
Para este análisis, se debe tener en cuenta que la fecha de vinculación de un
afiliado en la base de datos Sabass corresponde a la primera fecha en que se
relacionó con el ISS, aún cuando este afiliado se haya trasladado a otra AFP. A
continuación se detallan los cálculos propuestos para medir distintos indicadores
sobre este atributo:
Prueba
Descripción
Q-D001:
Completitud de información
de afiliados
Mediante esta prueba se calcula el indicador
de completitud para la fecha de vinculación
de los afiliados en la base de datos de
afiliación Sabass, indicando porcentaje de
valores nulos, válidos y no válidos, los
valores no válidos representan fechas de
vinculación anteriores a 1967.
Atributo 5: Estado de afiliado
La correcta clasificación de un afiliado como pensionado o no pensionado del ISS
es vital para evitar pérdidas de tiempo y recursos en el proceso de reconocimiento;
en ocasiones, sólo después de adelantar las primeras actividades de este proceso
se identifica que el solicitante de la pensión ya adquirió el estatus de pensionado.
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
207
Base de datos Tabla
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones NO
Histlab Afiliado
NominaPen NO
Sabass Afiliado
Sabass Recaudo NO
Traslados Pensiones NO
A continuación se detalla el cálculo que permite obtener el indicador de
consistencia para este atributo:
Prueba Descripción
Q-D012:
Consistencia de estado de
afiliado
Mediante esta prueba se calcula el indicador de
confiabilidad para el atributo de estado de afiliado
respecto a si es o no pensionado en Sabass;
inconsistencia se da en la medida en que un
afiliado reportado como no-pensionado en Sabass
se encuentra en Nómina de Pensionados como
pensionado.
Atributo 6: Identificación de aportante
Tanto el NIT como la razón social de un aportante son fundamentales para
identificarlo durante su relación con el ISS; procesos como la construcción de
historia laboral completa y correcta en el momento que se solicite pueden verse
208
seriamente impactados por incoherencias en estos atributos. A continuación se
muestra la aparición de éstos en las distintas bases de datos:
Base de datos Tabla
AFE Gral_Ma_Entidad
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar RegistroMaestro
Devoluciones Dafp_Empleador
Histlab Aportante
NominaPen NO
Sabass Aportante
Sabass Recaudo NO
Traslados Pensiones STI_Aportante
A continuación se detallan los cálculos necesarios para medir los distintos
indicadores sobre los atributos de identificación de aportantes:
Prueba Descripción
Q-D002:
Completitud de información de
aportantes
Mediante esta prueba se calcula el indicador de
completitud para la razón social de los aportantes
en la base de datos de afiliación Sabass,
indicando porcentaje de valores nulos y no nulos.
Q-D008:
Confiabilidad del NIT de
aportantes
Mediante esta prueba se calcula el indicador de
confiabilidad del NIT de aportantes en la base de
datos Sabass, comparando los tres primeros
dígitos con los patrones “800” y “900” para los
209
Prueba Descripción
aportantes con tipo de documento NIT.
Atributo 7: Naturaleza de aportante
La naturaleza de un aportante es importante para la correcta identificación del
mismo; esta naturaleza puede ser útil para validaciones de reglas de negocio
posteriores (por ejemplo, si el aportante es de carácter público o privado).
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones NO
Histlab Aportante
NominaPen NO
Sabass Aportante
Sabass Recaudo NO
Traslados Pensiones STI_Aportante
A continuación se detallan las consultas propuestas para obtener indicadores
sobre este atributo:
210
Prueba Descripción
Q-D002:
Completitud de información de
aportantes
Mediante esta prueba se calcula el indicador de
completitud para la naturaleza de los aportantes
en la base de datos de afiliación Sabass,
indicando porcentaje de valores nulos, válidos y no
válidos; los valores no válidos son aquellos fuera
del rango definido para este campo en Sabass.
Atributo 8: Ciclo de cotización
El ciclo de cotización refleja el mes del año al que corresponde un pago de un
aportante para un afiliado específico; es un atributo vital en el cálculo de semanas
cotizadas durante la decisión de reconocimiento de pensión. La presencia de este
atributo en las bases de datos se puede ver a continuación:
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones Dafp_Historia
Histlab NO
NominaPen NO
Sabass NO
Sabass Recaudo PagoAfiliadoPension
Traslados Pensiones NO
211
A continuación se detallan las consultas sobre las bases de datos que permiten
calcular indicadores sobre este atributo:
Prueba Descripción
Q-D003:
Completitud de información de
recaudo
Mediante esta prueba se calcula el indicador de
completitud para el atributo ciclo de cotización en
la base de datos Sabass_Recaudo, indicando
porcentaje de valores nulos, válidos y no válidos;
los valores no válidos son aquellos ciclos de
cotización con año menor a 1995.
Q-D004:
Completitud de aportes para
afiliados
Mediante esta consulta se calcula el indicador de
completitud de aportes a partir del atributo ciclo
de cotización, identificando aportes que se
esperaban y no se recibieron.
Atributo 9: Días cotizados
Así como el ciclo de cotización, para el cálculo de semanas cotizadas por un
afiliado durante el proceso de reconocimiento de pensión, es necesario establecer
los días que efectivamente cotizó en cada ciclo. Inconsistencias o falta de
completitud en este atributo pueden dificultar o impedir el correcto cálculo de
semanas, y por ende la decisión de otorgamiento de pensión.
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
212
Base de datos Tabla
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones NO
Histlab NO
NominaPen NO
Sabass RelacionSeguro
Sabass Recaudo PagoAfiliadoPension
Traslados Pensiones NO
A continuación se presentan las consultas que permiten calcular los indicadores
sobre este atributo:
Prueba Descripción
Q-D003:
Completitud de información de
recaudo
Mediante esta prueba se calcula el indicador de
completitud para el atributo días cotizados en
Sabass_Recaudo, indicando porcentaje de
valores nulos, válidos y no válidos; los valores no
válidos son aquellos menores a 0 y mayores al
número de días del mes respectivo.
Q-D004:
Completitud de aportes para
afiliados
Mediante esta consulta se calcula el indicador de
completitud de aportes a partir del atributo ciclo
de cotización, identificando aportes que se
esperaban y no se recibieron.
Q-D006:
Completitud de historia laboral
post-94
Mediante esta prueba se calcula el indicador de
completitud para el atributo días cotizados en una
relación laboral en Sabass; los valores no válidos
con aquellos menores a 0 y mayores al número
213
Prueba Descripción
de días del mes respectivo.
Atributo 10: Novedad
Las novedades laborales son importantes para determinar los ciclos y/o días en
que efectivamente se debieron reportar aportes por un afiliado específico y para
reconstruir la historia laboral completa de un afiliado; estas novedades tienen un
tipo (ejemplo: retiro o licencias), días que aplica la novedad y fecha en que se
produce la novedad. Inconsistencias en este atributo pueden dificultar
procedimientos como la detección de deudas en aportes, o la generación de la
historia laboral completa cuando esta se requiere.
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones NO
Histlab NovedadNoCorrelacionada
NominaPen NO
Sabass NovedadLaboral
Sabass Recaudo PagoAfiliadoPension
Traslados Pensiones NO
214
A continuación se presentan las consultas que permiten calcular los indicadores
sobre los atributos de novedad en relaciones laborales:
Prueba Descripción
Q-D005:
Completitud de información de
novedades laborales
Mediante esta prueba se calcula el indicador de
completitud para los atributos que tienen que ver
con novedades laborales, indicando porcentaje
de valores válidos y no válidos; los valores no
válidos para tipo de novedad son aquellos fuera
del rango para este atributo en Sabass, para
fecha de novedad aquellos con año menor a
1967 y para días de novedad aquellos menores a
0.
Atributo 11: Fecha de ingreso en relación laboral
Una historia laboral completa es fundamental para que el proceso de
reconocimiento de la pensión se lleve a cabo sin contratiempos; mantener las
fechas de ingreso y retiro de relaciones laborales completas es vital para la
reconstrucción de esta historia laboral en el reconocimiento.
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
215
Base de datos Tabla
Devoluciones NO
Histlab NO
NominaPen NO
Sabass RelacionLaboral
Sabass Recaudo NO
Traslados Pensiones NO
En la siguiente tabla se presentan las consultas definidas para el cálculo de los
distintos indicadores sobre este atributo:
Prueba Descripción
Q-D006:
Completitud de historia laboral
post-94
Mediante esta prueba se calcula el indicador de
completitud para los atributos que tienen que ver
con relaciones o vínculos laborales, indicando
porcentaje de valores válidos y no válidos; los
valores no válidos son aquellos con año menor a
1995.
Q-D013:
Consistencia entre fechas de
ingreso y retiro en relaciones
laborales
Mediante esta prueba se calcula el indicador de
consistencia entre fecha de ingreso y fecha de
retiro de cada relación laboral en Sabass;
inconsistencia en estos campos se da cuando la
fecha de ingreso es mayor a la fecha de retiro.
Atributo 12: Fecha de retiro en relación laboral
Una historia laboral completa es fundamental para que el proceso de
reconocimiento de la pensión se lleve a cabo sin contratiempos; mantener las
216
fechas de ingreso y retiro de relaciones laborales completas es vital para la
reconstrucción de esta historia laboral en el reconocimiento.
Base de datos Tabla
AFE NO
Cuotas Cobrar NO
Cuotas Pagar NO
DB_Cobrar NO
Devoluciones NO
Histlab NO
NominaPen NO
Sabass RelacionLaboral
Sabass Recaudo NO
Traslados Pensiones NO
A continuación se presentan las consultas definidas para el cálculo de los distintos
indicadores sobre este atributo:
Prueba Descripción
Q-D006:
Completitud de historia laboral
post-94
Mediante esta prueba se calcula el indicador de
completitud para los atributos que tienen que ver
con relaciones o vínculos laborales, indicando
porcentaje de valores válidos y no válidos; los
valores no válidos son aquellos con año menor a
1995.
217
Prueba Descripción
Q-D013:
Consistencia entre fechas de
ingreso y retiro en relaciones
laborales
Mediante esta prueba se calcula el indicador de
consistencia entre fecha de ingreso y fecha de
retiro de cada relación laboral en Sabass;
inconsistencia en estos campos se da cuando la
fecha de ingreso es mayor a la fecha de retiro.
Para el detalle del cálculo de indicadores solo se ilustraran las pruebas: Q-D001,
Q-D007, Q-D009, Q-D012, Q-D014, Q-D015, Q-D016, Q-D017, Q-D018, Q-D019,
Q-D020, Q-D021, Q-D022.
Detalle del cálculo de indicadores
Como se ha mencionado en este documento, la metodología que se aborda
permite la creación de tablas de trabajo temporales que contienen la muestra de
los datos clave identificados; posterior a ello, se ejecutan las consultas sobre estas
tablas.
Cabe anotar que para la extracción de las tablas de trabajo se tienen en cuenta los
siguientes criterios:
Se toma una muestra de los afiliados vivos no pensionados en Sabass, con un
95% de confidencia; esta muestra alimenta una tabla temporal de afiliados.
A partir de la muestra anterior, se seleccionan los datos requeridos en las demás
tablas de trabajo de Sabass o Sabass_Recaudo requeridas para el cálculo de
indicadores, poblando nuevas tablas temporales.
Para el caso de los aportantes, se toma una muestra con el mismo porcentaje de
confidencia para aportantes activos; posteriormente se pueblan las demás tablas
de trabajo mediante el mismo criterio.
218
Para el caso de cálculo de indicadores de consistencia entre bases de datos, en
este caso Sabass, AFE y NominaPen, se toma una muestra de personas de las
dos últimas y de las mismas personas en Sabass.
A continuación se utiliza la Plantilla 11 para mostrar la información detallada,
relacionada con el cálculo de los indicadores de completitud, confiabilidad y
consistencia para los diferentes atributos clave; en cada caso se especifica el
objetivo del cálculo, su justificación, el indicador que mide, los valores que se
obtienen mediante la consulta, la forma de calcular el indicador y, por último, los
resultados obtenidos.
Prueba No. Q-D001: Completitud de información de afiliados
Objetivo Determinar el porcentaje de completitud de los atributos
básicos de afiliados.
Justificación Los atributos básicos de los afiliados son fundamentales para
determinar la posible fecha de pensión, si un afiliado no tiene
estos datos completos no se podrá determinar su fecha de
pensión, por lo que se requerirá un proceso adicional que
permita recopilar estos datos.
Indicador que
mide
Completitud
Valores
obtenidos
mediante
consulta
Número total de afiliados (NT) Número total de afiliados que no reportan primer apellido y
primer nombre (NN) Número total de afiliados que no reportan sexo o con sexo
inválido (NS) Número total de afiliados que no reportan fecha de
nacimiento o con fecha de nacimiento inválida (NFN) Número total de afiliados que no reportan fecha de
afiliación o con fecha de afiliación inválida (NFA) Cálculo del
indicador
Completitud de nombres de afiliados: 100 – (NN / NT) * 100 Completitud de sexo de afiliados: 100 – (NS / NT) * 100 Completitud de fecha de nacimiento de afiliados :
100 – (NFN / NT) * 100 Completitud de fecha de afiliación: 100 – (NFA / NT) * 100
219
Prueba No. Q-D001: Completitud de información de afiliados
Resultados Valores obtenidos
Número total de afiliados (NT) = 2.400 Número total de afiliados que no reportan primer apellido y
primer nombre (NN) = 0 Número total de afiliados que no reportan sexo o con sexo
inválido (NS) = 0 Número total de afiliados que no reportan fecha de
nacimiento o con fecha de nacimiento inválida (NFN) = 0 Número total de afiliados que no reportan fecha de
afiliación o con fecha de afiliación inválida (NFA) = 5 Completitud de nombres de afiliados
Porcentaje de completitud: 100 – (NN / NT) = 100%
Número de casos incompletos por millón: 1.000.000 * (NN /
NT) = 0
Completitud de sexo de afiliados
Porcentaje de completitud: 100 – (NS / NT) = 100%
Número de casos incompletos por millón: 1.000.000 * (NS / NT)
= 0
Completitud de fecha de nacimiento de afiliados
Porcentaje de completitud: 100 – (NFN / NT) = 100%
Número de casos incompletos por millón: 1.000.000 * (NFN /
NT) = 0
Completitud de fecha de afiliación
Porcentaje de completitud: 100 – (NFA / NT) = 99.79%
Número de casos incompletos por millón: 1.000.000 * (NFN /
NT) = 2.083
Prueba No. Q-D007: Confiabilidad del nombre de afiliados
Objetivo Determinar el nivel de confiabilidad del nombre de los afiliados.
Justificación Comparar los nombres de los afiliados contra una base de datos
de referencia permite asegurar qué tan precisos son los datos
220
Prueba No. Q-D007: Confiabilidad del nombre de afiliados
respecto al patrón; es vital que en el momento del otorgamiento
este se haga a la persona indicada y no a otra que lo podría
estar suplantando.
Indicador que
mide
Confiabilidad
Valores
obtenidos
mediante
consulta
Número total de afiliados vivos no pensionados (NA) Número total de documentos de identidad no encontrados
en tabla maestra (NAN) Número total de registros diferentes contra tabla maestra
(NAD) Número total de registros similares contra tabla maestra
(NAS) Número total de registros iguales contra tabla maestra (NAI)
Cálculo del
indicador
Resultados Valores obtenidos
Número de afiliados vivos no pensionados (NA) = 2.400 Número total de documentos de identidad no encontrados
en tabla maestra (NAN) = 118 Número total de registros diferentes contra tabla maestra
(NAD) = 148 Número total de registros similares contra tabla maestra
(NAS) = 958 Número total de registros iguales contra tabla maestra (NAI)
= 1.176 Peso = 0,9 (un nombre semejante aporta 90% de
confiabilidad) Confiabilidad del nombre de afiliados
Porcentaje de confiabilidad = (NAI + (NAS * castigo) / NAN) *
100 = 89.3%
Número de casos no-confiables por millón = 1.000.000 –
(1.000.000 * (NAI + (NAS * castigo) / NAN)) = 106.836
Prueba No. Q-D009: Confiabilidad de la identificación de los afiliados
Objetivo Determinar el nivel de confiabilidad del número y tipo de
221
Prueba No. Q-D009: Confiabilidad de la identificación de los afiliados
documento de los afiliados.
Justificación La precisión en la identificación de afiliados permite evitar
inconvenientes o demoras en procesos posteriores por causa
de información incorrecta; registros duplicados con mismos
nombres y número de identificación pero distinto tipo de
identificación involucran un problema en esta precisión.
Indicador que
mide
Confiabilidad
Valores
obtenidos
mediante
consulta
Número de afiliados (NA) Número de nombres y tipos de documento encontrados
repetidos en el conteo de afiliados (NANF)
Cálculo del
indicador
100 - (NANF/NA) * 100
Resultados Valores obtenidos
Número de afiliados (NA) = 2.400 Números de nombres y fechas de nacimiento encontrados
repetidos (NANF) = 0 Confiabilidad de la identificación de afiliados
Porcentaje de confiabilidad: 100 – (NANF / NA) * 100 = 100%
Número de casos no-confiables por millón: 1.000.000 * (NANF /
NA) = 0
Prueba No. Q-D012: Consistencia de estado de afiliado
Objetivo Determinar el nivel de consistencia entre el reporte de un
afiliado como no-pensionado y su existencia en la nómina de
pensionados.
Justificación La existencia de personas ya pensionadas que no han sido
correctamente marcadas en la base de datos de afiliación
222
Prueba No. Q-D012: Consistencia de estado de afiliado
permite identificar problemas que deben ser corregidos, para
evitar posteriores inconvenientes en los procesos.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Una tabla que contiene:
Número total de afiliados (NA) Número de afiliados que reportan estado no pensionado mientras se encuentran como pensionado en Nómina (NAI)
Cálculo del
indicador
100 – (NAI / NA) * 100
Resultados Valores obtenidos
Número total de afiliados (NA) = 2.400 Número de afiliados que reportan estado no pensionado mientras se encuentran como pensionado en Nómina (NAI) = 0
Consistencia de estado de afiliado
Porcentaje consistencia: 100 – (NAI / NA) * 100 = 100%
Número de registros inconsistentes por millón = 1.000.000 *
(NAI / NA) = 0
Prueba No. Q-D014: Consistencia entre sexo y nombre de afiliados
Objetivo Determinar el nivel de consistencia entre el género de un
afiliado y su nombre.
Justificación El género es un factor primordial en la decisión de otorgamiento
de una pensión a cierta edad; inconsistencias entre nombre y
género pueden indicar problemas y/o demoras futuras en el
proceso de otorgamiento.
Indicador que
mide
Consistencia
Valores Número de afiliados (NA)
223
Prueba No. Q-D014: Consistencia entre sexo y nombre de afiliados
obtenidos
mediante
consulta
Número de registros encontrados consistentes con género respecto a nombre (NAI)
Cálculo del
indicador
100 – (NAI / NA) * 100
Resultados Valores obtenidos
Número de afiliados (NA) = 2.400 Número de registros encontrados consistentes con género
respecto a nombre (NAI) = 7 Consistencia entre sexo y nombre de afiliados
Porcentaje consistencia: 100 – (NAI / NA) * 100 = 99.7%
Número de casos inconsistentes por millón: 1.000.000 * (NAI /
NA) = 2.917
Prueba No. Q-D015: Consistencia de nombres de afiliados en Sabass y
AFE
Objetivo Determinar el nivel de consistencia entre los nombres de los
afiliados de AFE respecto a Sabass.
Justificación El nombre de los afiliados es un atributo fundamental en el
proceso de reconocimiento; inconsistencias en este atributo
pueden ocasionar problemas o demoras en este proceso.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
Número de afiliados en AFE encontrados en Sabass (NAS) Número de afiliados en AFE encontrados en Sabass pero
con nombre inconsistente (NAN)
224
Prueba No. Q-D015: Consistencia de nombres de afiliados en Sabass y
AFE
consulta
Cálculo del
indicador
100 – (NAN / NAS) * 100
Resultados Valores obtenidos
Número de afiliados en AFE encontrados en Sabass (NAS): 2.397
Número de afiliados en AFE encontrados en Sabass con nombre inconsistente (NAN): 142
Consistencia de nombres de afiliados en Sabass y AFE
Porcentaje de consistencia: 100 – (NAN / NAS) * 100 = 94.07%
Número de casos inconsistentes por millón: 1.000.000 * (NAN /
NAS) = 59.241
Prueba No. Q-D016: Consistencia de nombres de afiliados en Sabass y
Nómina de Pensionados
Objetivo Determinar el nivel de consistencia de nombres de afiliados en
Nómina de Pensionados respecto a Sabass.
Justificación El nombre de los afiliados es un atributo fundamental para la
identificación completa de los mismos; errores en este atributo
pueden ocasionar inconvenientes en los pagos a las personas
adecuadas.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Número de afiliados en Nómina Pensionados encontrados en Sabass (NAS)
Número de afiliados en Nómina Pensionados encontrados en Sabass pero con nombre inconsistente (NAN)
Cálculo del
indicador
100 – (NAN / NAS) * 100
225
Prueba No. Q-D016: Consistencia de nombres de afiliados en Sabass y
Nómina de Pensionados
Resultados Valores obtenidos
Número de afiliados en Nómina Pensionados encontrados en Sabass (NAS) = 2.159
Número de afiliados en Nómina Pensionados encontrados en Sabass pero con nombre inconsistente (NAN) = 155
Consistencia de nombres de afiliados en Sabass y Nómina
de Pensionados
Porcentaje consistencia: 100 –(NAN / NAS) * 100 = 92.8%
Número de casos inconsistentes por millón: 1.000.000 * (NAN /
NAS) = 71.792
Prueba No. Q-D017: Consistencia de sexo de afiliados en Sabass y AFE
Objetivo Determinar el nivel de consistencia del sexo de los afiliados de
AFE respecto a Sabass.
Justificación El sexo de los afiliados es un atributo fundamental en el proceso
de reconocimiento; inconsistencias en este atributo pueden
ocasionar problemas o demoras en este proceso.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Número de afiliados en AFE encontrados en Sabass (NAS) Número de afiliados en AFE encontrados en Sabass pero
con sexo inconsistente (NAN)
Cálculo del
indicador
100 – (NAN / NAS) * 100
Resultados Valores obtenidos
Número de afiliados en AFE encontrados en Sabass (NAS) = 2.397
Número de afiliados en AFE encontrados en Sabass con sexo inconsistente (NAN) = 14
226
Prueba No. Q-D017: Consistencia de sexo de afiliados en Sabass y AFE
Consistencia de sexo de afiliados en Sabass y AFE
Porcentaje consistencia: 100 – (NAN / NAS) * 100 = 99.4%
Número de casos inconsistentes por millón: 1.000.000 – (NAN /
NAS) = 5.841
Prueba No. Q-D018: Consistencia de sexo de afiliados en Sabass y
Nómina de Pensionados
Objetivo Determinar el nivel de consistencia del sexo de afiliados en
Nómina de Pensionados respecto a Sabass.
Justificación El sexo de los afiliados es un atributo fundamental para el
otorgamiento de pensión; errores en este atributo pueden
ayudar a detectar incoherencias en el otorgamiento.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Número de afiliados en Nómina Pensionados encontrados en Sabass (NAS)
Número de afiliados en Nómina Pensionados encontrados en Sabass pero con sexo inconsistente (NAN)
Cálculo del
indicador
100 – (NAN / NAS) * 100
Resultados
obtenidos
Valores obtenidos
Número de afiliados en Nómina Pensionados encontrados en Sabass (NAS) = 2.159
Número de afiliados en Nómina Pensionados encontrados en Sabass pero con sexo inconsistente (NAN) = 3
Consistencia de sexo de afiliados en Sabass y Nómina
Pensionados
Porcentaje consistencia: 100 – (NAN / NAS) * 100 = 99.7%
Número de casos inconsistentes por millón: 1.000.000 * (NAN /
227
Prueba No. Q-D018: Consistencia de sexo de afiliados en Sabass y
Nómina de Pensionados
NAS) = 1.389
Prueba No. Q-D019: Consistencia de fecha de nacimiento de afiliados
en Sabass y AFE
Objetivo Determinar el nivel de consistencia de la fecha de nacimiento de
los afiliados de AFE respecto a Sabass.
Justificación La fecha de nacimiento de los afiliados es un atributo
fundamental en el proceso de reconocimiento; inconsistencias
en este atributo pueden ocasionar problemas o demoras en este
proceso.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Número de afiliados en AFE encontrados en Sabass (NAS) Número de afiliados en AFE encontrados en Sabass pero con fecha de nacimiento inconsistente (NAN)
Cálculo del
indicador
100 – (NAN / NAS) * 100
Resultados Valores obtenidos
Número de afiliados en AFE encontrados en Sabass (NAS) = 2.397 Número de afiliados en AFE encontrados en Sabass pero con fecha de nacimiento inconsistente (NAN) = 922
Consistencia de fecha de nacimiento de afiliados en Sabass
y AFE
Porcentaje consistencia: 100 – (NAN / NAS) * 100 = 61.5%
Número de casos inconsistentes por millón: 1.000.000 * (NAN /
NAS) = 384.647
228
Prueba No. Q-D020: Consistencia de fecha de nacimiento de afiliados
en Sabass y Nómina de Pensionados
Objetivo Determinar el nivel de consistencia de la fecha de nacimiento de
afiliados en Nómina de Pensionados respecto a Sabass.
Justificación La fecha de nacimiento de los afiliados es un atributo
fundamental para el otorgamiento de pensión; errores en este
atributo pueden ayudar a detectar incoherencias en el
otorgamiento.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Número de afiliados en Nómina Pensionados encontrados en Sabass (NAS) Número de afiliados en Nómina Pensionados encontrados en Sabass pero con fecha de nacimiento inconsistente (NAN)
Cálculo del
indicador
100 – (NAN / NAS) * 100
Resultados Valores obtenidos
Número de afiliados en Nómina Pensionados encontrados en Sabass (NAS) = 2.159 Número de afiliados en Nómina Pensionados encontrados en Sabass pero con fecha de nacimiento inconsistente (NAN) = 831 Consistencia de fecha de nacimiento de afiliados en Sabass
y Nómina de Pensionados
Porcentaje consistencia = 100 – (NAN / NAS) * 100 = 61.5%
Número de casos inconsistentes por millón = 1.000.000 * (NAN /
NAS) = 384.900
Prueba No. Q-D021: Consistencia de afiliados en Sabass y AFE
Objetivo Determinar el nivel de consistencia de los afiliados existentes en
AFE y Sabass.
229
Prueba No. Q-D021: Consistencia de afiliados en Sabass y AFE
Justificación Es vital que la información que reside en las diferentes fuentes
de datos sea consistente respecto a otras fuentes y sus
objetivos; si una persona existe en AFE como solicitante de una
pensión, debería residir así mismo en Sabass como afiliado.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Número de afiliados en AFE (NA) Número de afiliados en AFE no encontrados en Sabass
(NAN)
Cálculo del
indicador
100 – (NA / NAN) * 100
Resultados Valores obtenidos
Número de afiliados en AFE (NA) = 2.400 Número de afiliados en AFE no encontrados en Sabass
(NAN) = 3 Consistencia de afiliados en Sabass y AFE
Porcentaje consistencia = 100 – (NA / NAN) * 100 = 99.9%
Número de casos inconsistentes por millón = 1.000.000 * (NA /
NAN) = 1.250
Prueba No. Q-D022: Consistencia de afiliados en Sabass y Nómina
Pensionados
Objetivo Determinar el nivel de consistencia de los pensionados
residentes en Sabass y Nómina de Pensionados.
Justificación Es vital que la información que reside en las diferentes fuentes
de datos sea consistente respecto a otras fuentes y sus
objetivos; si una persona existe en Nómina Pensionados como
pensionado, debería residir así mismo en Sabass como afiliado
230
Prueba No. Q-D022: Consistencia de afiliados en Sabass y Nómina
Pensionados
(afiliado pensionado, en este caso).
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Número de afiliados en Nómina Pensionados (NA) Número de afiliados en Nómina Pensionados no
encontrados en Sabass (NAN)
Cálculo del
indicador
100 – (NA / NAN) * 100
Resultados Valores obtenidos
Número de afiliados en Nómina Pensionados (NA) = 2.400 Número de afiliados en Nómina Pensionados no
encontrados en Sabass (NAN) = 241 Consistencia de afiliados en Sabass y Nómina Pensionados
Porcentaje consistencia = 100 – (NAN / NA) * 100 = 89.9%
Número de casos inconsistentes por millón = 1.000.000 – (NAN
/ NA) = 100.417
Automatizar Indicadores de Calidad
La automatización de los indicadores se implementó a través de Jobs
programados que se ejecutan semanalmente y ejecutan las consultas definidas en
la sección anterior. La información extraída es cargada en las tablas temporales
que fueron creadas para soportar la ejecución del método para el análisis de la
calidad de los datos.
Es de aclarar que la automatización se aplica sobre las fuentes de datos que
continúen soportando y se integren en la operación de Colpensiones.
231
Definir Responsables
Durante la ejecución del proyecto inicial la responsabilidad es del grupo de AI,
pero la responsabilidad se debe transferir a las personas que asumen los roles y
responsabilidades que debe definir el gobierno de datos en el estado deseado.
Diagnostico
La Plantilla 12 es utilizada para presentar los resultados obtenidos de las
mediciones realizadas para cada uno de los indicadores y atributos considerados
previamente.
Categoría de
Indicador
Prueba
Porcentaje
(completos,
confiables o
consistente
s)
Número de
casos por
millón
(incompletos,
no-confiables o
inconsistentes) Nombre Atributo
Completitud Q-D001:
Completitud de
información de
afiliados
Nombre 100% 0
Sexo 100% 0
Fecha de
nacimiento
100% 0
Fecha de
afiliación
99.79% 2.083
Q-D002:
Completitud de
información de
aportantes
Razón social 96.04% 39.503
Naturaleza 48.4% 515.927
Q-D003: Ciclo de 100% 0
232
Categoría de
Indicador
Prueba
Porcentaje
(completos,
confiables o
consistente
s)
Número de
casos por
millón
(incompletos,
no-confiables o
inconsistentes) Nombre Atributo
Completitud de
información de
recaudo
cotización
IBC 100% 0
Salario base 100% 0
Días cotizados 100% 0
Q-D004:
Completitud de
aportes para
afiliados
Varios
atributos clave
de aportes
En proceso
En proceso
Q-D005:
Completitud de
información de
novedades laborales
Tipo de
novedad
96.08% 39.226
Días de
novedad
95.08% 49.165
Fecha de
novedad
100% 0
Q-D006:
Completitud de
historia laboral post-
94
Fecha de
ingreso
85.99% 140.112
Fecha de retiro 99.93% 725
Días cotizados 79.96% 230.379
Confiabilidad Q-007: Confiabilidad
del nombre de
afiliados
Nombre 89.3% 106.836
Q-D008:
Confiabilidad del NIT
NIT 91.45% 85.495
233
Categoría de
Indicador
Prueba
Porcentaje
(completos,
confiables o
consistente
s)
Número de
casos por
millón
(incompletos,
no-confiables o
inconsistentes) Nombre Atributo
de aportantes
Q-D009:
Confiabilidad de la
identificación de los
afiliados
Identificación 100% 0
Consistencia Q-D010:
Consistencia entre
fecha de nacimiento
y fecha de
vinculación
Fecha de
nacimiento y
fecha de
vinculación
99.83% 1.667
Q-D011:
Consistencia entre
sexo y número de
documento
Sexo y número
de documento
89.08% 109.185
Q-D012:
Consistencia de
estado de afiliado
Estado afiliado 100% 0
Q-D013:
Consistencia entre
fechas de ingreso y
retiro en relaciones
laborales
Fecha de
ingreso y
fecha de retiro
98.32% 16.796
Q-D014:
Consistencia entre
sexo y nombre de
Sexo y nombre 99.7% 2.917
234
Categoría de
Indicador
Prueba
Porcentaje
(completos,
confiables o
consistente
s)
Número de
casos por
millón
(incompletos,
no-confiables o
inconsistentes) Nombre Atributo
afiliados
Q-D015:
Consistencia de
nombres de afiliados
en Sabass y AFE
Nombre 94.07% 59.241
Q-D016:
Consistencia de
nombres de afiliados
en Sabass y Nómina
Pensionados
Nombre 92.8% 71.792
Q-D017:
Consistencia de
sexo de afiliados en
Sabass y AFE
Sexo 99.4% 5.841
Q-D018:
Consistencia de
sexo de afiliados en
Sabass y Nómina
Pensionados
Sexo 99.7% 1.389
Q-D019:
Consistencia de
fecha de nacimiento
de afiliados en
Sabass y AFE
Fecha de
nacimiento
61.5% 384.647
Q-D020: Fecha de 61.5% 384.647
235
Categoría de
Indicador
Prueba
Porcentaje
(completos,
confiables o
consistente
s)
Número de
casos por
millón
(incompletos,
no-confiables o
inconsistentes) Nombre Atributo
Consistencia de
fecha de nacimiento
de afiliados en
Sabass y Nómina
Pensionados
nacimiento
Q-D021:
Consistencia de
afiliados en Sabass
y AFE
Identificación 99.9% 1.250
Q-D022:
Consistencia de
afiliados en Sabass
y Nómina
Pensionados
Identificación 89.9% 100.417
Monitoreo de los Indicadores
El monitoreo de los indicadores será considerado dentro de las políticas que serán
definidas por el gobierno de datos, puesto que es importante que los indicadores
de calidad de datos se revisen periódicamente, asegurando su seguimiento y
mejoramiento permanente. En una primera instancia se sugiere realizar reuniones
periódicas que monitoreen las tendencias delos indicadores y realicen planes de
acción encaminados a la mejora de los indicadores.
236
Riesgos de Seguridad
En esta sección se presentan los hallazgos de riesgos de seguridad identificados y
que básicamente comprometen los indicadores de confidencialidad, integridad y
disponibilidad de los sistemas de información. Se utiliza la Plantilla 8 para describir
cada uno de los hallazgos.
Hallazgo H-S001 Integridad - Potenciales problemas causados por
falta de una auditoría de sistemas
Descripción general Correcciones a las bases de datos son probadas por los
usuarios y el personal de la GNI, pero no por un ente
independiente especializado en auditoría.
Análisis La no existencia de un área especializada en probar
cambios y detectar posibles problemas puede llevar a que
se instalen cambios que produzcan efectos indeseados en
las tablas modificadas.
Un área ágil, proactiva y estructurada alrededor de procesos
claros y completos de prueba, podría aportar grandes
beneficios en las pruebas de los cambios a instalar en
producción.
Soporte Correo del ingeniero Orlando Bernal enviado en Noviembre
2, 2010
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
237
Hallazgo H-S002Confidencialidad – Prácticas irregulares en la
seguridad de los datos
Descripción general La información debe ser protegida para evitar especulación
no garantizada, interpretación incorrecta y uso inapropiado.
Análisis En el sistema de administración de pensiones se han
detectado, con mayor frecuencia y gravedad que en otros
sectores, una serie de prácticas irregulares de servidores
públicos y terceros queafectan directamente la moralidad
pública y el patrimonio estatal, pues no solo se tienen
controlesdébiles sino también la presencia de algunas
personas inescrupulosas manejando temas especialmente
sensibles con un criterio de beneficio personal o privado y no
con la visión del servicio público, del Estado, del sistema
pensional o del pensionado.
Soporte Documento realizado en septiembre de 2009: Estudio
Técnico de Estructura y Planta de personal Ajustado.
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
Hallazgo H-S003Integridad - Problemas originados en el
intercambio de información con Asofondos
Descripción general La organización debe mantener intercambio de información
con Asofondos, existen problemas que deben ser resueltos
Análisis Debe anotarse que en la actualidad existe una relación fluida
238
Hallazgo H-S003Integridad - Problemas originados en el
intercambio de información con Asofondos
de colaboración entre las dos entidades, además los
beneficios que obtiene el ISS de tal relación no representan
ningún costo para la organización.
Asofondos funciona como un repositorio de información de
las administradoras hacia el ISS y como una puerta de
acceso de las administradoras hacia el ISS, los problemas
identificados son:
Problemas de traslados, los ciclos son muy largos y
hacer cambios toma mucho tiempo.
Diferentes interpretaciones de las normas produce que
resultados aceptados por una administradora pueden
fallar en otra administradora que reciba su información.
Información inexistente en las administradoras que hacen
que las validaciones en el ISS fallen (por ejemplo falta
salario base porque la administradora nunca lo almaceno
y el ISS no puede acreditar si ese dato hace falta).
Soporte Reunión con Asofondos en Oct. 4 de 2010
Severidad Alta
Media
Baja
Confirmación Confirmado
Confirmado parcialmente
Por discutir
239
Hallazgo H-S004Disponibilidad - Relación con Sistemas y
Computadores
Descripción general Sistemas y Computadores (SyC) ha aportado buenos
servicios al ISS, pero deben revisarse los contratos que
sustentan la prestación de los mismos
Análisis La relación debe estar apoyada en contratos que sean
suficientemente específicos en cuanto a:
Propiedad del software que se entrega o se pone al servicio del ISS, debe tenerse la claridad de quién es el dueño del software que se desarrolló, si es del ISS o es de SYC; en este último caso el contrato debe contener una cláusula que afirme que SyC es el único dueño de dicho software y que en caso de reclamación de un tercero sobre propiedad del mismo al ISS (o de cualquier otra entidad que lo reemplace), SyC saldrá en defensa de la organización.
Propiedad o licencia del software de base en donde está montado el software desarrollado por SyC, debe afirmarse que SyC tiene las licencias legales y que saldrá en defensa del ISS o de la entidad que lo reemplace en caso de reclamaciones de terceros respecto a la legalidad de las licencias necesarias para que el software de SyC ejecute propiamente.
Propiedad de los datos y las imágenes, debe ser específico en el sentido que ambos son propiedad del ISS o de la entidad que lo reemplace y que SyC no puede hacer uso distinto de los mismos.
Soporte Colpensiones envió copia de uno de los contratos
(90007819) en octubre 27, 2010, pero la UA no conoce otros
contratos. Este contrato en poder de la UA carece de
cláusulas que desarrollen los temas nombrados excepto por
una mención a la defensa del ISS por parte de SyC.
Severidad Alta
Media
Baja
Confirmación Confirmado
240
Hallazgo H-S004Disponibilidad - Relación con Sistemas y
Computadores
Confirmado parcialmente
Por discutir
4.3 ESTADO DESEADO DE ARQUITECTURA DE INFORMACION
Tal como se expresó en el diagnóstico inicial de la estructura de las bases de
datos del ISS, en la actualidad existen dos grandes problemas: primero, que en las
bases de datos actuales conviven mezclas de información entre pensiones y las
dos otras líneas de negocio que el ISS manejó en su momento; segundo, que la
estructura actual de mantener información duplicada ha conducido a situaciones
de no- consistencia.
Existen casos en que el sistema de pensiones debe mantener información de las
otras líneas de negocios; sin embargo, por la manera en que las BD fueron
construidas, la información de las líneas de negocio está entremezclada.
Así mismo, el incluir información de los diferentes productos en las mismas tablas,
limita el que la organización pueda incluir de forma sencilla nuevos productos. En
la actualidad, probablemente se comenzaría una nueva BD con tablas
especializadas para el nuevo producto y también se crearían nuevas tablas para
mantener una instancia no controlada de personas.
Por otro lado, al no disponer de información de los roles que las diferentes
personas juegan frente al ISS, se debe mantener la información básica de cada
una de dichas personas en las diferentes tablas creadas para ese propósito, lo
cual en el mediano y largo plazo causa que algunas de las entradas
correspondientes a una persona se actualicen mientras que las demás no; por
241
ejemplo, si una persona tiene el rol de afiliado y de empleador, entonces está
creado dos veces en las BD relacionadas.
4.3.1 Blueprint de arquitectura de información
Se considera que las actuales estructuras de información no son suficientemente
flexibles y poderosas para soportar los nuevos requerimientos que la entidad va a
enfrentar.
De acuerdo con lo anterior, se hace necesario el diseño de una AI que permita:
El diseño y puesta en marcha de un Gobierno de datos
Llegar a un punto en donde los datos, que anteriormente se encontraban
dispersos, tengan una capa de abstracción la cual permita que las aplicaciones
existentes, y también las nuevas que se desarrollen a futuro, tengan un solo
punto de acceso.
Implementar eficientemente un sistema MDM el cual permita centralizar el
acceso a los datos que hacen parte del core del negocio.
Vocabulario común y definición de datos.
Independencia tecnológica y por tanto la AI debe operar en una variedad
de plataformas tecnológicas.
La AI debe promover la interoperabilidad entre aplicaciones, negocio y
tecnología.
Control de acceso a los datos.
Evitar la replicación no controlada de información.
El blueprint de AI se diseñó respetando los lineamientos establecidos por el grupo
de arquitectura de aplicaciones y de negocio, donde se definió la utilización de un
modelo de referencia SOA. Es así, como en la Figura 40se muestra el Blueprint de
AI deseada que describe globalmente los componentes que responden a las
necesidades expuestas.
242
ZONA DE GOBIERNO DE DATOS
Zon
a d
e C
on
tro
l de
Acc
eso
Zon
a d
e S
erv
icio
s d
e D
ato
s
Zona de Integración de Datos
Zon
a d
e F
ue
nte
s d
e D
ato
s
Zona MDM
Figura 40. Blueprint de AI para Colpensiones
A continuación se describe la responsabilidad de cada una de las zonas
propuestas en el blueprint de AI:
Gobierno de datos
Esta zona representa la necesidad de implementar un gobierno de datos que se
debe conformar de acuerdo al modelo de referencia descrito en la sección y
seguir la guía metodológica descrita en la sección 3.2.2.
Responsabilidades:
Definir una estructura organizacional especializada para el gobierno de datos.
Garantizar que el trabajo de evangelización sea asumido por el CEO.
Ligar el proyecto de gobierno de datos a cada uno de los proyectos que se
realicen a nivel de AI. Estos proyectos pueden ser el de MDM, de calidad de
datos, de BI, etc.
243
Fomentar las normas, políticas y directrices que establecen la forma de
compartir y usar los datos a nivel empresarial. Para lo cual se evaluaran los
principios de datos propuestos por TOGAF.
Fomentar un enfoque de gobierno de datos mixto, donde las decisiones sobre
los datos relevantespor línea de negocios se tomen de forma descentralizada,
pero las decisiones a nivel corporativo sobre los datos transversales a todas
las líneas de negocio se deben tomar de forma centralizada.
Definir políticas de seguridad y privacidad que garanticen la identificación y
protección de la información confidencial y establecer controles de auditoria.
Implementación y vigilancia de un programa de mejora continua, de calidad de
datos, a través del método propuesto en la sección 0.
Monitorear el desempeño del gobierno de datos a través del monitoreo de
indicadores que permita hacer diagnósticos continuos sobre la calidad actual
de la información. Los indicadores y métricas corresponden a los definidos en
la sección del análisis del estado actual de la información.
Zona de control de acceso
Esta zona involucra las capacidades necesarias que se deben ejecutar para
brindar aspectos de seguridad como la autenticación, autorización y auditoria
(AAA), que garanticen la protección de los datos.
Para garantizar los aspectos de seguridad AAA se debe implementar mecanismos
de gestión de información básica de identidades de usuarios, contraseñas,
atributos, grupos y perfiles. Las identidades son necesarias para autenticara a los
usuarios y determinar qué tipo de recursos puede consumir. La identidad requiere
de contraseñas, certificados o datos que solo puede proporcionar un usuario.
Responsabilidades:
244
Entrada única de los usuarios para que con un único inicio de sesión puedan
entrar o acceder a todos los servicios que estén autorizados para su perfil.
Controlar el tiempo de sesión e inactividad.
Gestionar la información de la identidad a través de un directorio LDAP.
Garantizar que todos los usuarios consumidores de datos deben pasar por esta
zona sin excepción antes de llegar propiamente a los datos.
Autenticación, Autorización y Auditoria a través de un componente de software
comercial.
Zona de servicios de datos
En esta zona se define el portafolio de servicios compuestos y necesarios para
proporcionar los mecanismos de consulta, persistencia o actualización de
información en diversas fuentes de datos de forma unificada. El principal objetivo
de esta zona es proporcionar beneficios de optimización, disponibilidad de la
información, proporcionar información precisa, actualizada y asegurar la integridad
de la información.
Responsabilidades:
Garantizar la disponibilidad de servicios para consultar, guardar o actualizar
información.
Garantizar que todas las peticiones de usuarios que consumen información
deben pasar previamente por la zona de control de acceso para poder utilizar
los servicios de datos.
La información para los usuarios solo debe estar disponible a través de los
servicios de datos.
Permitir la integración de datos desde diferentes fuentes de datos que pueden
ser internas o externas a la empresa.
Operar en ambientes heterogéneos de fuentes de datos.
Permitir la integración de fuentes de datos legadas.
245
Zona de integración de datos
Esta zona proporciona los mecanismos necesarios para corregir los problemas de
dispersión, incompatibilidad de datos y mezcla de información de pensiones y las
otras líneas de negocio que actualmente existen en el ISS.
La solución a este problema se aborda desde la perspectiva de las técnicas de
integración de datos que existen actualmente en la industria y para lo cual se
establece un enfoque hibrido entre consolidación y federación.
El enfoque de consolidación de datos se orienta a la integración de múltiples
fuentes de datos y con diferentes tecnologías entre sí, para ser unificadas en una
única fuente de datos que puede ser utilizada por aplicaciones de reportes o
análisis de información como una bodega de datos, donde es aceptable una
latencia en la actualización de datos entre las fuentes origen y la fuente destino.
El enfoque federado de datos se propone para satisfacer los requerimientos de
negocio que demandan acceso sobre los datos reales y no sobre copias.
Principalmente este enfoque se establece porque permite integrar múltiples
fuentes de datos como si fuese una sola, y también porque el factor rendimiento
no es crítico para el contexto del negocio en Colpensiones. Adicionalmente según
[32], la federación de datos es la solución más usada para solucionar problemas
de información en casos de compras o unión de empresas para crear una nueva,
como es el caso de Colpensiones.
Responsabilidades:
Transformación de grandes volúmenes de información entre las fuentes de
datos origen y la fuente de dato destino.
Integrar múltiples fuentes de datos y con tecnologías diferentes.
Proporcionar información en tiempo real y tiempo temprano según
requerimientos del negocio.
Proporcionar un único acceso a los datos y vista unificada de los datos.
246
Análisis de las fuentes de datos para determinar su contenido y calidad de
datos. Para esto se recomienda la utilización de herramientas de perfilamiento
de datos.
Zona MDM
Esta zona proporciona los mecanismos necesarios para el diseño de una nueva
estructura que permita:
Una sólida definición de personas.
Separar las personas de los roles que juegan frente a la organización.
Resolver la mezcla de productos existente en las bases de datos actuales.
Soportar la incorporación de nuevos productos que ofrezca la organización, por
ejemplo BEPs, independientes de los actuales.
Evitar la replicación no controlada de información.
Crear una clara separación entre vínculos laborales y aportes.
Centrarse en el núcleo del negocio, evitando la mezcla de este con tablas
temporales, de reportes, de trabajo, etc.
Así, esta nueva estructura, detallada en el siguiente diagrama de alto nivel,
debería estar compuesta de:
Un conjunto de datos maestros, o directorio, que abarque los principales
aspectos del negocio: personas y productos.
Unas sub-estructuras específicas para los aspectos del negocio que interesa
detallar: historia laboral, producto pensiones y posiblemente otros productos.
Un conjunto de datos específicos de los productos existentes; por ahora, el
producto pensiones.
247
Figura 41. Estado deseado de los Datos Maestros
A continuación se describe la estructura propuesta, y se detallan las entidades que
hacen parte de la misma.
Maestro persona: Este diagrama contiene la estructura propuesta para manejar
la información de personas (naturales o jurídicas), tales como su información de
contacto, la historia que pueda existir respecto a los cambios de número de
documento de identidad o nombres y los roles que puede jugar respecto a los
productos que ofrece la organización.
248
La importancia de esta estructura es que permite un manejo unificado de la
información de personas naturales o jurídicas, de tal forma que exista un único
repositorio en donde la información de personas es almacenada.
De esta manera, cualquier actualización a la información de personas es
compartida para todas las aplicaciones. Así mismo, se tendrá la información de
todos los posibles roles que una persona juega frente a la organización.
Se ha añadido una estructura de grupo familiar que podría ser utilizada para
realizar proyectos de inteligencia de negocios, tales como minería de datos.
A continuación se utiliza la Plantilla 2 para presentar el detalle de las entidades
propuestas para esta estructura.
Entidad de negocio EN-DT001: Persona
Definición Entidad de negocio que representa a todos los entes que tienen relación con el negocio de la organización.
Descripción general Entidad que agrupa a todas las personas naturales o jurídicas que tienen relación (desde el punto de vista del negocio), con la organización.
La idea de agrupar a todas las personas en una sola tabla, surge del hecho que debe existir un único repositorio en donde mantener esta información. De esta manera, si se presenta un cambio en la información de una persona, habrá un único sitio en donde realizarlo, sin necesidad de hacerlo repetidamente en los diversos sitios en donde podría estar almacenado.
Puesto que una persona puede tener diferentes relaciones con la entidad (por ejemplo ser empleador y afiliado al mismo tiempo), se definieron los roles (o comportamientos), que representan dichas relaciones.
Las reglas que gobiernan los roles son:
Para que un ente exista en la entidad Persona, debe jugar o haber jugado un rol con la organización; en otras palabras, en esta entidad no existen personas sin relaciones actuales o pasadas con la organización.
Una persona puede jugar más de un rol, lo que refleja el
249
Entidad de negocio EN-DT001: Persona
hecho de que las personas pueden tener más de una relación con la entidad; por ejemplo, un empleador que sea persona natural puede también ser un afiliado o un pensionado.
En la generalidad de los casos, los roles son jugados de manera temporal; por ejemplo, para el producto Prestación Económica, la persona se afilia en una cierta fecha, por lo que adquiere el rol de afiliado, y posteriormente se pensiona, por lo que adquiere el rol de pensionado.
Entidades hijas Natural (en adelante PersonaNatural)
Jurídica (en adelante PersonaJurídica)
Entidades relacionadas
DatosContacto
DeudaPresunta
Devolucion
Historia_Id
Historia_nombres
Otorgamiento
OtorgamientoPersonaRol
PersonaNatural
PersonaProductoRol
Planilla
TipoDocumento
TipoProducto
VinculoLaboral
Atributos #id_persona
tipo_doc
num_doc
nombres_razonsocial
primer_apellido
segundo_apellido
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT002: PersonaNatural
Definición Entidad de negocio que representa a los individuos que se
250
Entidad de negocio EN-DT002: PersonaNatural
relacionan con la organización.
Descripción general Una persona natural es un individuo que tiene relación con la organización; así como la entidad Persona, una Persona Natural puede jugar distintos roles a través del tiempo. Esta entidad es una especialización de la entidad persona, puesto que contiene información específica del individuo, por ejemplo género o fecha de nacimiento.
Entidades hijas Ninguna
Entidades relacionadas
Afiliacion DetalleAfiliadosRecibidos DeudaPresunta GrupoFamiliar Persona PersonaJurídica RepresentanteLegal TipoRolFamiliar VinculoLaboral
Atributos genero fecha_nacimiento fecha_expedicion_documento_identidad
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT003: PersonaJurídica
Definición Entidad de negocio que representa a las personas jurídicas que se relacionan la organización.
Descripción general Una persona jurídica es aquella entidad o empresa de la que se quiere mantener información; estas personas jurídicas también juegan roles tales como, Administradora de Fondos de Pensiones, operador del sistema PILA. La entidad persona jurídica es una especialización de la entidad persona puesto que almacena información que es específica de las personas jurídicas, por ejemplo fecha de constitución.
Entidades hijas Ninguna Entidades relacionadas
ActividadEconomica BonoPensional CuentaCobro DetalleEntidadConcurrente Otorgamiento PersonaNatural Planilla RepresentanteLegal
251
Entidad de negocio EN-DT003: PersonaJurídica
Atributos naturaleza_juridica FechaConstitución
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT014: PersonaProductoRol
Definición Entidad de negocio que representa el rol desempeñado por una persona en un producto, durante un periodo de tiempo específico.
Descripción general Las personas naturales o jurídicas juegan roles en los diferentes productos que la organización ofrece, ejemplos de estos roles para el producto pensiones son afiliado, aportante, pensionado, abogado, entre otros. La naturaleza de estos roles es temporal.
Entidades hijas Ninguna
Entidades relacionadas
PersonaNatural Rol
Atributos fecha_desde fecha_hasta estado
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT015: RepresentanteLegal
Definición Entidad de negocio que representa la relación de representante legal entre una persona natural y una persona jurídica.
Descripción general Las personas jurídicas tienen representantes legales; éstos son personas naturales y pueden ser de interés para la entidad dado que los cobros persuasivos y coactivos tienen que ver con el representante legal.
Entidades hijas Ninguna Entidades relacionadas
PersonaNatural PersonaJuridica
Atributos fecha_desde fecha_hasta
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT016: GrupoFamiliar
Definición Entidad de negocio que representa el grupo familiar al que pertenece una persona natural que tiene relación con la
252
Entidad de negocio EN-DT016: GrupoFamiliar
organización.
Descripción general Las personas naturales pertenecen a grupos familiares; en los cuales desempeñan roles (padre, madre, hijo, abuelo). Estas entidades están previstas para el caso de que la entidad pueda recolectar este tipo de información para posteriormente hacer algún tipo de venta cruzada.
Entidades hijas Ninguna
Entidades relacionadas
Persona Natural TipoRolFamiliar
Atributos #id Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT017: TipoRolFamiliar
Definición Entidad de negocio que representa el rol desempeñado por una persona dentro de un grupo familiar.
Descripción general Las personas naturales pertenecen a grupos familiares; en su grupo familiar, las personas naturales desempeñan roles (padre, madre, hijo, abuelo).
Entidades hijas Ninguna
Entidades relacionadas
GrupoFamiliar PersonaNatural
Atributos id_tiporolfamiliar nombre_tiporolfamiliar
Base de datos en que reside
No definida en este nivel de detalle
Maestro producto: esta estructura contiene la información sobre cada uno de los
productos que la entidad ofrece; inicialmente, contendrá solo la información de
pensiones pero en la medida en que se creen nuevos productos se podrá incluir
su información en esta estructura.
Se propone que las entidades de esta estructura contengan información sobre las
condiciones del producto, por ejemplo los requisitos que una persona debe cumplir
para adquirir el producto.
Así mismo, contendrá información sobre las características mismas del producto,
de tal forma que cambios en la operatividad del mismo, puedan ser incorporados
en las entidades, sin que haya necesidad de cambiar la lógica de las aplicaciones.
253
Esto permitiría escribir aplicaciones más generales que puedan manejar diferentes
productos, puesto que parte de la lógica está en la estructura y no en la aplicación.
Por ejemplo, uno de los atributos propuestos es si el producto debe tener cobro
persuasivo y cobro coactivo y a los cuántos meses de no pago se deberían iniciar
dichos procesos. De esta forma, cambios en el número de meses en que deben
iniciarse los procesos sólo afectarán la estructura de datos y no la lógica de las
aplicaciones.
Opciones de lógica más complicadas podrían ser incluidas (probablemente a
través del uso de nueva entidades), permitiendo que las aplicaciones sean más
generales y tengan menos código.
A continuación se utiliza la Plantilla 2 para presentar el detalle de las entidades
propuestas para esta estructura.
Entidad de negocio EN-DT018: TipoProducto
Definición Entidad de negocio que representa cada tipo de producto ofrecido por la organización.
Descripción general La organización puede ofrecer distintos tipos de productos a sus clientes; ejemplos de estos productos son pensiones o BEPs. El objetivo de tener esta entidad, es ofrecer flexibilidad para la creación de nuevos productos, de esta manera si la organización tiene la oportunidad de ofrecer un nuevo producto, podrá incluir su descripción y crear lógicas acordes con el mismo.
Entidades hijas Pensión BEP Descripción de cualquier otro producto financiero ofrecido
Entidades relacionadas
PersonaProductoRol Requisito TipoProductoRequisito
Atributos id ley_origen productos_por_persona unidades_saldo cobro_persuasivo? cobro_coactivo? meses_inactivar_cuenta
Base de datos en que reside
No definida en este nivel de detalle
254
Entidad de negocio EN-DT019: Pensión
Definición Entidad de negocio que mantiene información exclusiva de pensiones.
Descripción general Esta entidad es una especialización de la entidad TipoProducto y como tal, mantiene la información especializada necesaria para caracterizar el negocio de pensiones, por ejemplo puede mantener la información de lógicas que pueden aplicarse a procesos de pensiones.
Entidades hijas Ninguna Entidades relacionadas
Ninguna
Atributos Atributos de entidad padre TipoProducto Atributos propios del producto Pensión
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT020: BEP
Definición Entidad de negocio que representa el tipo de producto BEP.
Descripción general Esta es una especialización de la entidad TipoProducto y como tal mantiene la información especializada necesaria para caracterizar el tipo de producto BEP; este comprende el ahorro a largo plazo de las personas de escasos recursos para la obtención de beneficios económicos periódicos; esta entidad mantendrá información exclusivamente relacionada con BEPS. Además el diseño de esta entidad será diferente al de otras tablas que son hijas de la tabla TipoProducto.
Entidades hijas Ninguna
Entidades relacionadas
Ninguna
Atributos Atributos de entidad padre TipoProducto Atributos propios del producto BEP
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT021: Requisito
Definición Entidad de negocio que representa los requisitos que aplican para los diferentes productos.
Descripción general Los productos ofrecidos por la organización tienen una serie de requisitos que deben ser cumplidos; por ejemplo, un requisitos es que la persona tenga un ingreso inferior a 2 SML, esta información podría quedar almacenada allí y en conjunto con la tabla TipoProductoRequisito, podría usarse cuando los posibles clientes preguntan y cuando se necesite
255
Entidad de negocio EN-DT021: Requisito
hacer validaciones de información que está ingresando
Entidades hijas Ninguna
Entidades relacionadas
TipoProducto
Atributos id_requisito nombre_requisito
Base de datos en que reside
No definida en este nivel de detalle
Entidad de negocio EN-DT022: TipoProductoRequisito
Definición Entidad de negocio que representa la asociación entre un tipo de producto y un requisito.
Descripción general Ersta tabla ofrece el enlace entre los posibles requisitos y los posibles productos, de esta manera un producto puede ser asociado con los requisitos que apliquen, previamente creados en la tabla Requisito, también un mismo requisito puede ser usado por diferentes productos.
Entidades hijas Ninguna
Entidades relacionadas
TipoProducto
Atributos Ninguno
Base de datos en que reside
No definida en este nivel de detalle
Enfoque Arquitectural para MDM: para la captura, integración, uso compartido
de los datos maestros y respeto de las políticas establecidas por la arquitectura de
negocio y aplicaciones, que exigen alinear tecnología y el negocio para mejorar el
rendimiento de los procesos de negocio y ser una empresa ágil y competitiva, se
propone utilizar un enfoque arquitectural de repositorio central, donde los datos
maestros no son replicados y en consecuencia las aplicaciones deben solicitar y
actualizar la información directamente en el repositorio central. Las aplicaciones
interactúan con el repositorio central mediante un enfoque orientado a servicios.
Para mayor información sobre enfoques arquitecturales de MDM consultar [32].
Responsabilidades:
256
Reutilizar y potenciar otras aplicaciones CRM’s, ERP’s y otras aplicaciones
legadas.
Agilidad para adaptarse al cambio a causa de nuevas reglamentaciones.
Flexibilidad para reducir tiempos y costos de implantación de nuevos
requerimientos funcionales.
Favorecer la evolución, cambio y crecimiento del negocio.
Favorecer el mapeo directo entre procesos de negocio y datos empresariales.
Favorecer el desarrollo en paralelo.
4.4 MAPA DE PROYECTOS
4.4.1 Definición de proyectos
Para superar la brecha existente entre el Estado Actual y el Estado Deseado, se
han identificado un conjunto de proyectos organizados en una línea de tiempo,
durante la cual Colpensiones gradualmente integrara en su funcionamiento la
información heredada del ISS y de esta forma gradualmente alcanzara el estado
deseado. A continuación se utiliza la Plantilla 6 para consolidación de brecha,
soluciones y dependencias para superar la brecha.
257
Tabla 9. Matriz de consolidación de brecha, soluciones y dependencia.
A continuación se utiliza la Plantilla 7 para describir incrementalmente las
arquitecturas de transición.
N° Zona GAP Posible Solución Descripción Dependencias
3 MDM
Consolidar
informacion de
Personas y
Productos.
Enfoque arquitectural de repositorio
central para MDM.
4 Servicios de DatosPortafolio de
servicios de dato
Arquitectura orientada a servicios
(SOA)
El enfoque SOA es un requisito
definido por la arquitectura de
aplicaciones y en consecuencia
la arquitectura de información
debe cumplirlo.
Arquitectura de
aplicaciones.
5
6
Integracion de Datos
Matriz de Consolidación de Brecha, Soluciones y Dependencias
1
Oficina de Gobierno
de Datos.
Proceso de calidad
de datos.
Definición y creación de la oficina de
Gobierno de Datos.
Metodo para analisis de calidad de
datos.
2
Dispersión e
Incompatibilidad de
datos.
Mezcla de
información.
Tecnica de integración de datos
hibrida entre consolidación y
federación.
Se definen e implementan los
recursos financieros, logisticos,
tecnicos y humanos para la
implantación de una entidad
organizacional destinada
Integración de datos y
MDM.Gobierno de Datos
258
4.4.2 Priorización de proyectos
En reunión con el grupo estratégico y de negocio, cada proyecto se analizó de
acuerdo a dos factores: índice de beneficios e índice de riesgos. La escala de
valores utilizada es de 1 a 5 donde 1 representa el valor más bajo y 5 el valor más
alto. A continuación se muestran los valores asignados por proyecto y la gráfica
correspondientes.
Arquitectura de Transicion 1 Arquitectura de Transicion 2 Arquitectura de Transicion 3
N° Proyecto Julio 2012 - Diciembre 2012 Enero 2012 - Junio 2012 Julio 2013 - Diciembre 2013 Comentarios
1 MDM
Diseño e implementación
del repositorio central.
2 MDM migracion de datos A
Consolidar informacion de
Personas de los 80s y 90s.
Consolidar información de
Productos.
Esta informacion corresponde a
personas
proximas a pensionarse.
3 MDM Migracion de datos B
Consolidar información de
Personas de los años 2000 al
presente.
Consolidar información de
Productos.
Esta informacion corresponde a
personas que
les falta varios años para empezar el
proceso de liquidacion pensional.
4 MDM Migracion de datos C
Consolidar información de
Personas de antes de los
80s.
Consolidar información de
Productos.
La informacion de estos años
corresponde a
pesonar ya pensionadas.
5 Federación de datosDiseño y construcción de la
Federación
6 Migración de afiliaciones A
Integrar información de
Afiliaciones asociada al
proyecto 2 (MDM migración
de datos A).
Esta informacion corresponde a
afiliaciones de personas
proximas a pensionarse.
7 Migración de afiliaciones B
Integrar información de
Afiliaciones asociada al
proyecto 3 (MDM migración
de datos B).
Esta informacion corresponde a
afiliaciones de personas que
les falta varios años para empezar el
proceso de liquidacion pensional.
8 Migración de afiliaciones B
Integrar información de
Afiliaciones asociada al
proyecto 4 (MDM migración
de datos C).
La informacion de estos años
corresponde a afiliaciones de
pesonar ya pensionadas.
9 Gobierno de datosDiseño e implantación del
gobierno de datos.
Ejecucion del proceso de
calidad de datos.
Evaluacion de Madurez de la
AI.
Ejecucion del proceso de
calidad de datos.
Evaluacion de Madurez de la
AI.
259
Proyecto Riesgo Beneficio Tamaño MDM 1 5 3 MDM migración de datos A 2 5 4 MDM Migración de datos B 2 4 5 MDM Migración de datos C 1 2 4 Federación de datos 3 4 4 Migración de afiliaciones A 4 5 4 Migración de afiliaciones B 3 3 5 Migración de afiliaciones C 1 1 5 Gobierno de datos 1 4 3
Tabla 10. Valores de evaluación del Riesgo vs Beneficio
Figura 42. Grafica de evaluación del Riesgo vs Beneficio
En evaluación del riesgo vs beneficio para cada proyecto se analizaron aspectos
de riesgo como complejidad, tamaño, la tecnología y el impacto en caso del
fracaso. Para el beneficio se analizaron aspectos como cumplimiento de los
principios, la contribución financiera y la alineación estratégica.
0
1
2
3
4
5
6
0 1 2 3 4 5
Ben
efic
io
Riesgo
260
Es así, como podemos afirmar que la mayor prioridad de ejecución la tienen los
proyectos MDM, Gobierno de datos, MDM migración de datos A y MDM migración
de datos B porque son los proyectos que representan el mayor beneficio para el
negocio con el menor riesgo. En su orden de prioridad siguen los proyectos
Federación de datos, Migración de afiliaciones A, Migración de afiliaciones B
porque son los que representan también un mayor beneficio para el negocio pero
con un mayor nivel de riesgo.
Los proyectos de MDM Migración de datos C y Migración de afiliaciones C son los
proyectos con menor riesgo pero también el aporte al negocio es mínimo, puesto
que corresponde a información de personas ya pensionadas. En consecuencia, en
este momento la decisión recomendada es dejar esta información donde esta y no
hacerle ningún tratamiento por el momento.
5 CONCLUSIONES Y TRABAJO FUTURO
5.1 CONCLUSIONES DEL TRABAJO REALIZADO
Se presentó una solución para el desarrollo de arquitecturas de información en un
contexto de arquitectura empresarial, que integra elementos de AI propuestos por
los frameworks de AE, ampliamente aceptados pero que las propuestas difieren
entre sí. También la solución incluye una serie de propuesta a nivel de modelos de
referencia y plantillas que apoyan el desarrollo metodológico.
Los aportes realizados son:
Un framework que define conceptualmente tres elementos estructurales
necesarios para el desarrollo de arquitecturas de información en un contexto
de arquitectura empresarial. Estos elementos estructurales son el repositorio
261
de recursos de AI, las guías metodológicas y el repositorio de arquitectura de
información.
Modelo de referencia para dividir la complejidad de los datos empresariales en
dominios de datos.
Modelo de Referencia para describir la situación deseada de un gobierno de
datos y que también permite evaluar la situación actual del gobierno.
Modelo de Referencia para definir el alcance de una AI en un contexto de AE.
Propuesta de tres guías metodológicas que apoyan y facilitan el desarrollo de
arquitecturas de información en un contexto de AE. Las guías metodológicas
son para el desarrollo del proyecto inicial de AI, para el desarrollo de proyectos
particulares y para el gobierno de datos.
Definición y validación de la guía metodológica para el desarrollo del proyecto
inicial de AI, la cual propone 4 macro etapas que posibilitan el desarrollo
ordenado e iterativo de arquitecturas de información en un contexto de AE.
Propuesta de la guía metodológica para gobierno de datos que ayuda en el
diseño e implementación de un gobierno de datos.
Estos aportes se consideran novedosos, toda vez que en la revisión realizada del
estado del arte no se encontraron soluciones que cumplieran con las necesidades
sentidas en el desarrollo de arquitecturas de información, necesidades como guías
metodológicas, modelos de referencia, plantillas que faciliten la documentación de
la AI, identificación y organización de recursos necesario para el desarrollo de AI.
En el trabajo de revisión del estado del arte, se identificó la diferencia marcada
alrededor de las propuestas para el desarrollo de arquitecturas de información en
el contexto de arquitectura empresarial, que tienen los frameworks de AE más
aceptados. Esta diferencia en las propuestas muestra que en la actualidad no
existe unificación de conceptos y propuestas metodológicas con el nivel de detalle
necesario que guíen el desarrollo de arquitecturas de información en un contexto
de AE.
262
La aplicación de la propuesta mediante el caso de estudio permitió probar, ajustar
y mejorar principalmente las plantillas, los modelos de referencia y la guía
metodológica para el desarrollo del proyecto inicial de una AI.
5.2 TRABAJO FUTURO
Este trabajo contaba principalmente con una restricción de tiempo en su ejecución,
lo que limito el poder ejecutar el FAI completamente. Solo se abordaron los
aspectos más importantes del repositorio de recursos, la ejecución y validación de
la guía metodológica del proyecto inicial de la AI. Para un trabajo futuro se sugiere:
Complementar el repositorio de recursos de AI.
Validar la guía metodológica de gobierno de datos.
Proponer y validar una guía metodológica para el desarrollo de proyectos
particulares.
La propuesta se validó con un caso de estudio donde se fusionaban un conjunto
de empresas para dar origen a una nueva. Para un trabajo futuro se propone
validar el comportamiento del FAI en las siguientes situaciones:
Creación de una empresa nueva que no cuente con información heredada de
otras empresas.
En una empresa que ya esté constituida con varios años de operación y que
deciden emprender un proyecto de AI, pero que necesitan mantener la
operación del negocio.
En una empresa donde solo necesiten realizar un esfuerzo de AI solo para un
proceso de negocio.
263
6 BIBLIOGRAFIA
[1] The Art of Enterprise Information Architecture. Mario Godinez, Eberhard
Hechler, Klaus Koenig, Steve Lockwood, Martin Oberhofer, Michael Schroeck.
System-Based Approach for Unlocking Business Insight.IBM Press Pearson pl,
2010.
[2] Data Model Patterns A Metadata Map. David C. Hay. The Morgan Kaufmann
Series in Data Management Systems, 2006.
[3] “Framework” The American Heritage Dictionary of the English Language,
Fourth Edition. Houghton Mifflin Company.
[4] The Framework for Enterprise Architecture: Background, Description and Utility
by John A. Zachman, published by Zachman Institute for Framework
Advancement (ZIFA) Document ID 810-231-0531.
[5]John Zachman's Concise Definition of the Enterprise, 2008 John A. Zachman,
CEO www.ZachmanInternational.com
[6] Nongeospatial Metadata for the Ecological Sciences. Michener, W. et. al.
Ecological Applications 7(1). 1997. pp. 330-342.
[7] Golfarelli, M. “The Dimensional Fact Model: a Conceptual Model for Data
Warehouse”. International Journal of Cooperative Information System, Vol. 7, No.
2&3, pp. 215-247.
[8] Gorczynska, R. “Modelling Meta Data for Multidimensional Data”. Journal of
Data Warehousing, Vol. 3, No 4, pp. 32-42.
[9] Katic, N. “A Prototype Model for Data Warehouse Security Based on Metadata”.
Proceeding DEXA 98.
264
[10] Jarke, M. “Concept Base – a deductive object base for meta data
management”. Journal of Intelligent Information Systems (Special Issue on
Advances in Deductive Object-Oriented Database), Vol 4, No 2, app. 167-192.
[11] Muller, R. “An Integrative and Uniform Model for Metadata Management in
Data Warehousing Environments”. Proceeding of the International Workshop on
Desing and Management of Data Warehouses, Heidelberg. Germany, 1999.
[12] Jeusfeld, M.A. “Design and Analysis of Quality Information for Data
Warehouses”. Proc. 17th International Conference on Conceptual Modelling
(ER’98), Singapore.
[13] Pereira, C. and Sousa, P. (2004) A Method to define an Enterprise
Architecture using the Zachman Framework, Proceedings of the 2004 ACM
Symposium on Applied Computing, 1366-1371.
[14] Roger Sessions, Comparison of the Top Four Enterprise Architecture
Methodologies.
[15] Data Model Patterns A Metadata Map. The Morgan Kaufmann Series in Data
Management Systems.
[16] The Open Group Architecture Framework (TOGAF), Version 9.1, Enterprise
Edition.
[17] The Integrated Architecture Framework Explained. Jack van’t Wout, Maarten
Waage, Herman Hartman, Max Stahlecker, Aaldert Hofman. Published by
Springer-Verlag Berlin Heidelberg 2010.
[18] Designing Data Governance. Vijay Khatri and Carol V. Brown.Communication
of the ACM, January 2010.
[19] Universidad de los Andes: Arquitectura y Diseño de Software, Motivadores de
Negocio.
265
[20] Trends 2007: Master Data Management. Ray Wang, Rob Karel, and Kyle
McNabb.second document in the “Master Data Management” series. February 26,
2007.
[21] Master Data and Master Data Management: An Introduction. David Loshin.
DataFlux White Paper.
[22] Data Governance: What Works And What Doesn’t. By Rob Karel with J. Paul
Kirby, Boris Evelson, Connie Moore, and Jamie Barnett.Forrester September 10,
2007.
[23] Universidad de los Andes. Arquitectura de información para la Administradora
Colombiana de Pensiones COLPENSIONES, 2011.
[24] Harold F. Tipton, Micki Krause (eds.), Information Security Management
Handbook, 5th Ed., CRC Press, 2006.
[25] Universidad de San Martin de Porres, Calidad de datos: un nuevo enfoque de
la mejora permanente. Boletín informativo N°
60.(http://www.usmp.edu.pe/publicaciones/boletin/fia/info60/calidad.html) (Six
Sigma)
[26] Sunil Soares, The IBM Data Governance Unified Process, Driving Business
Value with IBM Software and Best Practices, MC Press.
[27] Universidad de los Andes. Curso de diseño de software basado en patrones,
2009.
[28] Heileman, Gregory L.Estructuras de datos, algoritmos y programación
orientada a objetos. Madrid ; Santafé de Bogotá : McGraw-Hill, c1998.
[29] Carlo Batini,Cinzia Cappiello, Chiara Francalanci y Andrea Maurino.
Methodologies for Data Quality Assessment and Improvement. ACM Computing
Surveys, Vol. 41, No. 3, Article 16, Publication date: July 2009.
266
[30] Tomado de Osterwalder, Alexander; Pigneur, Yves; Smith, Allan; et. al.
(2009). Business Model Generation. Nueva Jersey: Hoboken Publication. ISBN
9782839905800.
[31] Administradora colombiana de pensiones COLPENSIONES, Estudio técnico
estructura y planta de personal ajustada, Grupo de la protección social.
[32] Colin White. Data Integration: Using ETL, EAI and EII Tools to Create an
Integrated Enterprise. The Data Warehousing Institute. November 2005.
[33] The Chief Information Officers Council, Federal Enterprise Architecture
Framework, version 1.1 September 1999.
[34] Federal Enterprise Architecture Program, The Data Reference Model, version
2.0 November 17 de 2005.
[35] Executive Office of the President of the United States, FEA Consolidated
Reference Model Document, version 2.3 october 2007.
267
ANEXOS
Anexo N° 1: Glosario de Términos
En esta sección se presenta la definición de un conjunto de términos que son
necesarios para la adecuada interpretación de este trabajo. Están organizados
según su aparición a lo largo del documento y no por orden alfabético.
Anexo N° 2: Canvas
El Canvas es un modelo de negocio creado por Alexander Osterwalder el cual
describe de manera lógica la forma en que las organizaciones crean, entregan y
capturan valor. La herramienta no es más que un lienzo con distintos apartados
interrelacionados entre ellos que cubren todos los aspectos básicos de un
negocio: segmentos de clientes, propuesta de valor, canales, relación con los
clientes, fuentes de ingresos, recursos clave, actividades clave, socios clave y
estructura de costos [30].
268
Anexo N° 3: Herramientas Tecnológicas
Enterprise Architect, Modelio-Open, TOAD, Rational Rose Data Modeler, entre
otros. También Modelio-Open provee soporte para los diagramas y matrices
sugeridos por TOGAF.
Anexo N° 4: Técnicas de Modelamiento
Diagrama de Clases/Entidad-Relación
Utilizados en el modelo conceptual que permite modelar las entidades de negocio
y como se relacionan entre sí para soportar el negocio dentro de la empresa.
Diagrama de Clases
269
Diagrama Entidad Relación
Diagrama de Diseminación de Datos
Según TOGAF este diagrama permite visualizar la relación entre las entidades de
negocio, los servicios de negocio y las fuentes de datos. Con este diagrama se
puede identificar replicación de datos y también permite visualizar los sistemas
que utilizan y/o soportan las entidades de negocio. A continuación se presenta a
modo de ejemplo un diagrama tomado de [23] y que hace parte del caso de
estudio visto en capítulo 4.
Diagrama de Diseminación de Datos
270
Para realizar el diagrama de diseminación de datos se aconseja tener en cuenta lo
siguiente:
1. Preferiblemente hacer un diagrama por cada entidad de negocio.
2. Identificar las fuentes de datos donde se encuentren datos de la entidad de
negocio.
3. Identificar dependencias entre las fuentes de datos.
4. Identificar técnicas de integración de datos.
5. Para cada fuente de dato realizar una descripción básica que incluya: el
formato de los datos. Puede estar como datos estructurados o no
estructurados como imágenes o microfichas. Cantidad de registros e
información de los datos que indique la fecha del primer registro y la fecha del
último registro.
6. Hacer un diagrama no formal (como el que se muestra en la figura anterior)
donde se muestre gráficamente la información mencionada en los puntos del 1
al 5.
Diagrama de Ciclo de Vida de Datos
Este es un diagrama que permite visualizar el ciclo de vida de los datos, desde su
creación, consulta, transformación y eliminación, según las reglas o limitaciones
por procesos de negocio. Este diagrama nos ayuda a identificar las necesidades
de datos comunes que tiene el negocio y será el punto de partida para diseñar
fuentes de datos comunes que permitan compartir recursos de datos.
Para realizar un diagrama de ciclo de vida se aconseja tener en cuenta los
siguientes aspectos:
1. Identificar las entidades de negocio que se incluirán
2. Identificar procesos de negocio y clasificar en misionales, estratégicos y de
apoyo.
271
3. Identificar aplicaciones y componentes de software
4. Identificar fuentes de datos
5. Hacer un diagrama donde se describa gráficamente para cada entidad de
negocio, donde se crea, se consulta, se transforma y elimina.
A continuación se presenta una aproximación de lo que se debe incluir en un
diagrama de ciclo de vida de los datos.
Diagrama de ciclo de vida de los datos
Adicionalmente para cada una de las entidades de negocio se debe hacer una
descripción del ciclo de vida que debe ser evidente en el diagrama.
272
Anexo N° 5: Acta de Entrevista o Reunión
Este formato proporciona un espacio donde se puede relacionar de forma escrita
lo tratado y acordado en la entrevista. Además la creación y publicación de un acta
proporciona constancia oficial de lo tratado y acordado en la entrevista. A
continuación se muestra la plantilla con información de ejemplo:
273
Adicionalmente no olvidar que el acta debe también incluir la hora de inicio,
finalización y las firmas de los asistentes.
Anexo N° 6: Registro pendiente de entrevistas
Este formato proporciona un espacio para registrar temas o tareas acordadas para
realizar posterior a la entrevista. Estas tareas pueden ser: enviar documentación
de constitución de la empresa, sobre los procesos de negocio, portafolio de
productos y servicios entre otros. A continuación se muestra el formato con
información de ejemplo.
274
Anexo N° 7 Otras plantillas
La Plantilla 8 permite describir y documentar los hallazgos identificados durante el
desarrollo de la AI. Un hallazgo en este trabajo se define como una debilidad
identificada en cualquier aspecto de la AI.
Para cada una de las plantillas se presenta información tomada del caso de
estudio para ilustrar como se debe diligenciar.
Hallazgo H-D005 Falta de una autoridad de la información
Descripción general La organización carece de un área / funcionario cuyo
responsabilidad primordial sea la de mantener la calidad de
los datos.
Análisis Ninguna de las áreas que actualmente realizan corrección
de los datos, tiene como responsabilidad principal mantener
la calidad de los datos y además tiene otras funciones
diferentes de la corrección.
Existe un comité para atacar problemas de información,
conformado por la GNI y por el DNAR, pero nuevamente la
función principal de esas áreas no es la corrección y el
mantenimiento de los datos
Soporte Documento word “Organigrama ISS JK” de fecha Julio 31,
2010. Reuniones realizadas en particular octubre 19, correo
enviado por José Bocanegra a la Universidad en octubre 22,
2010
Severidad Alta
Media
Baja
Confirmación Confirmado
275
Hallazgo H-D005 Falta de una autoridad de la información
Confirmado parcialmente
Por discutir
Plantilla 8. Descripción de hallazgo [23]
La Plantilla 9 permite describir los indicadores de calidad que se consideren para
el análisis del estado de la información.
Categoría de
Indicador
CI-D001: Completitud
Definición Es la medida que indica si la realidad de interés está
totalmente representada, este indicador no tiene en cuenta la
exactitud de la información, sólo si esta existe o no.
Nivel de cálculo Atributo
Registro
Ejemplo Parte de la realidad de interés es la fecha de nacimiento de los
afiliados; en este caso, el indicador de completitud permite
determinar el porcentaje de afiliados para los que se conoce
este atributo de interés.
Plantilla 9. Indicadores de calidad de datos [23]
La Plantilla 10 permite documentar las mediciones que se realizaran de acuerdo a
cada uno de los indicadores de calidad y su respectiva información asociada.
Prueba Descripción
Q-D001:
Completitud de información de
afiliados
Mediante esta prueba se calcula el indicador de
completitud para los nombres de los afiliados en
la base de datos de afiliación Sabass, indicando
porcentaje de valores nulos y no nulos.
Q-D007: Mediante esta prueba se calcula el indicador de
276
Prueba Descripción
Confiabilidad del nombre de
afiliados
confiabilidad para los nombres de los afiliados de
la base de datos Sabass respecto a la tabla de
personas de la Registraduría Nacional.
Plantilla 10. Mediciones de los indicadores de calidad [23]
La Plantilla 11 permite describir detalladamente los cálculos que se realizaran
respecto a cada indicador de calidad y la información asociada.
Prueba No. Q-D012: Consistencia de estado de afiliado
Objetivo Determinar el nivel de consistencia entre el reporte de un
afiliado como no-pensionado y su existencia en la nómina de
pensionados.
Justificación La existencia de personas ya pensionadas que no han sido
correctamente marcadas en la base de datos de afiliación
permite identificar problemas que deben ser corregidos, para
evitar posteriores inconvenientes en los procesos.
Indicador que
mide
Consistencia
Valores
obtenidos
mediante
consulta
Una tabla que contiene:
Número total de afiliados (NA) Número de afiliados que reportan estado no pensionado mientras se encuentran como pensionado en Nómina (NAI)
Cálculo del
indicador
100 – (NAI / NA) * 100
Resultados Valores obtenidos
Número total de afiliados (NA) = 2.400 Número de afiliados que reportan estado no pensionado mientras se encuentran como pensionado en Nómina (NAI) = 0
Consistencia de estado de afiliado
277
Prueba No. Q-D012: Consistencia de estado de afiliado
Porcentaje consistencia: 100 – (NAI / NA) * 100 = 100%
Número de registros inconsistentes por millón = 1.000.000 *
(NAI / NA) = 0
Plantilla 11. Calculo de Indicadores [23]
La Plantilla 12 permite documentar el diagnostico de calidad de los datos, de
acuerdo a los resultados obtenidos de la ejecución de los cálculos establecidos
para los indicadores de calidad.
Categoría de
Indicador
Prueba
Porcentaje
(completos,
confiables o
consistentes)
Número de
casos por millón
(incompletos,
no-confiables o
inconsistentes)
Nombre Atributo
Completitud Q-D001: Completitud
de información de
afiliados
Nombre 100% 0
Sexo 100% 0
Fecha de
nacimiento
100% 0
Fecha de
afiliación
99.79% 2.083
Q-D002: Completitud
de información de
aportantes
Razón social 96.04% 39.503
Naturaleza 48.4% 515.927
Plantilla 12. Diagnóstico de calidad [23]
278
Anexo N° 8 Proyectos en marcha para el mejoramiento de la calidad de
información
Secuen
cia
Tema Detalle Volumen
Aproximado
Avance
1 IDENTIFICACIÓN
DE
APORTANTES
TIPO
AGREMIACIÓN
Marcar en Sabass aquellos
aportantes tipo agremiación o
cooperativas
No disponible 10%
2 CRUCE DE
TRASLADOS
INGRESOS Y
EGRESOS ISS –
ASOFONDOS
Procesamiento de información
enviada por Asofondos para que
el ISS evalúe los resultados y
envíe respuesta
No disponible 25%
3 NOVEDAD 911 Posibilidad de utilizar información
de Asofondos proveniente de los
fondos de cesantías, para
actualizar datos de empleadores,
afiliados y relación laboral
No disponible 12%
4 MARCACIÓN DE
PENSIONADOS
DE OTRAS
AFP’S
Posibilidad de utilizar información
de Asofondos sobre pensionados
de otras administradoras para
actualizar bases de datos del ISS
No disponible 15%
5 RELACIONES
LABORALES
INCONSISTENTES
Revisar los casos en que los
registros de la tabla
RelacionSeguro no tienen un
registro correspondiente en
RelacionLaboral.
No disponible 0%
6 DATOS
INCONSISTENTES
EN UBICACIÓN
DEL AFILIADO
Se pretende corregir información
de dirección y teléfono para
afiliados que tengan esos campos
nulos, con menos de 2 caracteres
o con un código especial
A Septiembre
30, 2010,
quedaban cerca
de 1.5 millones
de registros con
esta
93%
279
Secuen
cia
Tema Detalle Volumen
Aproximado
Avance
información
inválida
7 NOVEDADES EN
LÍNEA
Proyecto para incluir nuevas
funcionalidades en los servicios
en línea
No disponible 95%
8 FECHAS DE
RETIRO
MENORES A
FECHAS DE
INGRESO EN
RELACIÓN
SEGURO
Inconsistencia de información. 357,313
registros
0%
9 ALTO RIESGO Incluir la información de alto
riesgo en el formulario de
afiliación, así mismo generar los
cambios necesarios para su
procesamiento
No disponible 50%
10 AFILIADOS
REPETIDOS
Esto para atender estadísticas de
la contraloría (menos de 2,000
casos), sin embargo la búsqueda
en la base de datos produjo cero
resultados
Cero 0%
11 FECHAS DE
VINCULACIÓN
INCONSISTENTES
Corrección de fecha de
vinculación para aquellos casos
en que esta fecha es menor a la
del inicio del sistema o posterior a
la fecha actual
118.017
registros
corregidos.
39,181 registros
pendientes de
corrección
100%
12 CAMBIO DE
TIPO Y NÚMERO
DE
DOCUMENTO
PARA
Cambios en los aplicativos para
uso de tipo y número de
identificación del afiliado, puesto
en producción en septiembre
2010
Todos los
registros de la
BD
100%
280
Secuen
cia
Tema Detalle Volumen
Aproximado
Avance
AFILIADOS
13 ACTUALIZACIÓN
DE FECHAS DE
NACIMIENTO
INCONSISTENTES
Proceso de corrección de
información de fechas de
nacimiento, utilizando información
provista por Ministerio de
Protección Social y Asofondos
Fechas de
nacimiento
nulas: 5.270
Fechas de
nacimiento año
1900 y antes:
3.121
Fechas de
nacimiento
mayor o igual a
la fecha de
vinculación:
427
Fecha de
nacimiento
superior a la
fecha actual: 7
70%
14 ACTUALIZACIÓN
DE NOMBRES Y
APELLIDOS
INCONSISTENTES
Proceso de corrección de
nombres usando fuentes
provistas por Asofondos, BD de
recaudo y Registraduría
Menos de 8,000
registros aún
tienen algún
tipo de
inconsistencia
80%
15 FECHAS DE
INGRESO NULAS
TABLA
RELACIONSEGUR
O
Corrección de información
inconsistente en tabla relación
seguro. Proceso extrae
información de recaudo y autol
para generar la fecha de ingreso
Antes del
proceso
existían
5.301.335
registros con el
problema en
tabla relación
seguro
Se depuraron
92%
281
Secuen
cia
Tema Detalle Volumen
Aproximado
Avance
528,997
registros
16 MARCACIÓN DE
COMITÉS DE
MULTIVINCULAD
OS EN SABASS
Marcar registros que son
multiafiliados
Se procesaron
1,909 registros
de los cuales
864 fueron
marcados, los
demás tienen
glosas
90%
17 AFILIADOS
FALLECIDOS
Proceso para corregir procesos
de creación que ingresaba los
registros con estado fallecido
No disponible 90%
18 NÚMEROS DE
DOCUMENTO
ALFANUMÉRICO
S PARA
AFILIADOS Y
APORTANTES
Adecuar lo necesario para
guardar números de identificación
que efectivamente contienen
caracteres alfanuméricos
No disponible 5%
19 APORTANTES
CON TIPO DE
DOCUMENTO
NIT, NÚMERO
DE
DOCUMENTO <>
9 DÍGITOS Y
FUERA DE LAS
SERIES 800 A
900
Corrección de esta anomalía 14,391 registros
candidatos a
ser cambiados
90%
20 DEPURACIÓN DE
DEPARTAMENTOS
Y MUNICIPIOS
INCONSISTENTES
Corrección de municipios que
desaparecieron de DIVIPOLA o
que fueron creados últimamente
Numero bajo de
registros
cambiados,
esta tabla es
100%
282
Secuen
cia
Tema Detalle Volumen
Aproximado
Avance
muy pequeña
21 RAZÓN SOCIAL
DEL
APORTANTE
CON
CARACTERES
ESPECIALES
Reemplazar caracteres
especiales en la columna razón
social
En Oct/2009 se
hizo corrección
de 1.807
registros, sin
embargo en
sept 30, 2010 el
conteo de
registros con el
defecto fue de
212,580
100%
22 TIPO
AFILIACIÓN
NULA O VACÍA
TABLA
RELACIÓN
LABORAL
Corregir columna tipo de afiliación
(rl_tipoAfiliacion)
Se corrigieron
12.157.592
registros, sin
embargo
898.965
registros no
existen en tabla
RelacionSeguro
100%
23 TIPO AFILIADO
(BENEFICIARIO)
INCONSISTENTE
TABLA AFILIADO
SEGURO
Se descubrió un error en un
programa que actualiza esta
información, se hizo corrección de
la columna afectada
5,416 registros 100%
24 IDENTIFICACIÓN
DE
APORTANTES
DE
NATURALEZA
PÚBLICA
A partir de un archivo se
marcaron los aportantes de
naturaleza pública
De 4,414
registros en el
archivo de
entrada se
modificaron
1296 en Sabass
100%
25 CAMBIOS DE
ESTADO DE LOS
AFILIADOS
Procesos sucesivos se han
ejecutado a lo largo del tiempo
813,145
afiliados
marcados en la
98%
283
Secuen
cia
Tema Detalle Volumen
Aproximado
Avance
BD histórica de
pensiones
26 RÉGIMEN
SUBSIDIADO
Conjunto de actividades
tendientes a mejorar la calidad de
los datos de los afiliados a
régimen subsidiado
Totales por
diferentes
actividades
62%
27 MULTIVINCULAD
OS EN
PENSIONES
(decr 3995 /
2008)
Utilizando información
proveniente de Asofondos, se
ejecutaron varios procesos para
actualizar la pertenencia de los
afiliados a las diferentes
administradoras
Totales por
diferentes
actividades
100%
28 TRASLADOS
INGRESOS
Este proceso a cargo de SyC
utiliza información entregada por
Asofondos para marcar los
registros de traslados ingresos,
sin embargo la mayor parte de la
información resulto rechazada en
el proceso
14,691
registros
entregados por
Asofondos, 6
registros
actualizados en
la BD
75%
29 TRASLADOS
EGRESOS
Este proceso a cargo de SyC
utiliza información entregada por
Asofondos para marcar los
registros de traslados egresos
No disponible 65%
30 CONTINUIDAD
PATRONAL NIT
Crear relaciones seguro y
relaciones laborales
4,033 registros
procesados
hasta antes del
procesos de
septiembre
2010
90%
31 RUAF /
CIRCULAR 040
Este no es un proceso de
depuración
89%
32 AFILIADOS
BORRADOS
Se desarrolló este proceso para
corregir situación creada por mal
206,761
registros
90%
284
Secuen
cia
Tema Detalle Volumen
Aproximado
Avance
funcionamiento de un software recuperados
33 BORRADO DE
INFORMACIÓN
DE EPS
Este no es un proceso de
depuración
90%
34 BORRADO DE
INFORMACIÓN
DE ARP
Este no es un proceso de
depuración
85%
35 CONVENIO DE
ACTUALIZACIÓN
BASE DE DATOS
REGISTRADURÍ
A
Este no es un proceso de
depuración
100%
36 AFILIADOS
CAJANAL
Incorporación en las BD del ISS
de los afiliados enviados por
Cajanal.
100%
37 COLOMBIANOS
EN EL
EXTERIOR
Este no es un proceso de
depuración
100%
38 ACTUALIZACIÓN
DE NOVEDADES
DE PÁGINA WEB
Este no es un proceso de
depuración
100%
