DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE

DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL
SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE
Noviembre de 2013

Documento de Recomendaciones de Sostenibilidad del SAE
FORMATO PRELIMINAR AL DOCUMENTO
Título:
DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL
SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE
Fecha elaboración
aaaa-mm-dd:
2013-11-07
Sumario:
Información respecto de las recomendaciones para la sostenibilidad a largo
plazo del Sistema de Aseguramiento Electrónico – SAE.
Palabras Claves:
Documento, Recomendaciones, Sostenibilidad, Mejoramiento, SAE,
Aseguramiento Electrónico.
Formato: DOC Lenguaje: Español
Dependencia: Oficina de Sistemas e Informática de la Contraloría General de la República
Código: Versión: 1.0 Estado: Generado
Categoría: Documento Técnico
Autor (es):
Oportunidad Estratégica
Contrato Nº 291 de 2013
Firmas:
Revisó:
Oficina de Sistemas e Informática de la
Contraloría General de la República
Aprobó: Supervisor del contrato Nº 291 de 2013
Información
Adicional:
Ubicación:
Esta copia impresa del presente documento y sus anexos, tiene un archivo
magnético asociado al documento y está localizado bajo el nombre
12_SAE_Documento_Recomendaciones_Sostenibilidad.pdf, en disco
adjunto.

CONTROL DE CAMBIOS
VERSIÓN FECHA RESPONSABLE DESCRIPCIÓN
1.0 2013-11-07 Oportunidad Estratégica Elaboración del documento

TABLA DE CONTENIDO
DERECHOS DE AUTOR.............................................................................................................1
CRÉDITOS..................................................................................................................................2
1. INTRODUCCIÓN .................................................................................................................3
2. PROCESOS.........................................................................................................................3
2.1 SITUACIÓN ACTUAL ..................................................................................................3
2.2 RECOMENDACIONES................................................................................................5
3. RECURSO HUMANO ..........................................................................................................6
3.2 RECOMENDACIONES................................................................................................8
4. TECNOLOGÍA......................................................................................................................9
4.2 RECOMENDACIONES..............................................................................................10
5. SEGURIDAD......................................................................................................................11
5.1 SITUACIÓN ACTUAL ................................................................................................11
6. ADMINISTRACIÓN DE DATOS .........................................................................................13
6.1 SITUACIÓN ACTUAL ................................................................................................13
6.2 ANÁLISIS DE LA BASE DE DATOS DE SAE............................................................14
7. ASPECTOS JURÍDICOS SOBRE SAE, FIRMA ELECTRÓNICA Y LAS ENTIDADES DE
CERTIFICACIÓN CERRADAS..................................................................................................46
ANEXO. MODELO RELACIONAL BASE DE DATOS SAE .......................................................58

Documento de Recomendaciones de Sostenibilidad del SAE 1
DERECHOS DE AUTOR
La autoría de lo consignado en este documento es de Oportunidad Estratégica, quien a través
de un equipo de profesionales interdisciplinario, lo elaboró, presentó y obtuvo su aprobación
por parte de la Contraloría General de la República, en el marco de ejecución del contrato Nº
291 de 2013, suscrito con el objeto de: Prestación de servicios profesionales especializados
para el acompañamiento al proceso de implementación del Sistema de Aseguramiento
Electrónico – SAE. La Contraloría General de la República y Oportunidad Estratégica,
autorizan a que éste sea reproducido gratuitamente, en cualquier formato o medio sin requerir
un permiso expreso para ello, bajo las siguientes condiciones:
1. La copia no se hace con el fin de distribuirla comercialmente.
2. Los materiales no se deben utilizar en un contexto engañoso.
3. Las copias serán acompañadas por las palabras "copiado/distribuido con permiso de
la Contraloría General de la República. Todos los derechos reservados."
4. El título del documento y el autor (Oportunidad Estratégica) deben ser incluidos al ser
reproducidos como parte de otra publicación o servicio.
Si se desea copiar o distribuir el documento con otros propósitos, debe solicitar el permiso
entrando en contacto con la Oficina de Sistemas e Informática de la Contraloría General de la
República.

CRÉDITOS
Dentro del marco de implantación del Sistema de Aseguramiento Electrónico – SAE de la
Contraloría General de la República - CGR, se han generado por parte de la Oficina de
Sistemas e Informática, Oficina de Capacitación Producción de Tecnología y Cooperación
Internacional, Dirección de Impresión, Archivo y Correspondencia, Contraloría Delegada de
Investigaciones, Juicios Fiscales y Jurisdicción Coactiva, Contraloría Auxiliar para el Sistema
General de Regalías, Unidad de Investigaciones Especiales contra la Corrupción, Unidad de
Seguridad y Aseguramiento Tecnológico e Informático y del Equipo de Trabajo que ha venido
liderando la implementación e implantación del Sistema de Aseguramiento Electrónico - SAE,
un conjunto de ideas, lineamientos y/o parámetros que han contribuido para la elaboración de
este documento y en especial en lo que respecta a las recomendaciones de sostenibilidad del
SAE.

1. INTRODUCCIÓN
En los últimos dos años la Contraloría General de la República (CGR) ha realizado dos
proyectos informáticos que dan soporte a procesos misionales de la entidad: el Proceso
General de Auditoría, mediante la aplicación SICA (Sistema Integrado de Control de Auditoría),
y el Proceso de Control Fiscal, mediante SAE (Sistema de Aseguramiento Electrónico), el cual
permite tener un repositorio de información de los Procesos de Responsabilidad Fiscal,
asegurando a través de la firma digital y el estampado de tiempo, la autenticidad de las
actuaciones.
Además de lo anterior hay otros aplicativos que dan apoyo a procesos importantes de la
entidad, como es el caso de SIPAR (Sistema de Apoyo a la Participación Ciudadana),
SIGEDOC (Sistema de Control Documental), Kactus (Sistema de recursos humanos), y SIREF
(Sistema de Responsabilidad Fiscal), entre otros.
Lo anterior ha conducido a la necesidad de fortalecer el área informática en todos sus aspectos,
para poder responder a las exigencias que trae consigo la implantación de este tipo de
aplicaciones. A pesar de los logros que se han obtenido al respecto en los últimos tiempos, se
requiere todavía trabajar en algunos aspectos para darle sostenibilidad a los importantes
avances que se han hecho con la implantación de las mencionadas aplicaciones. Esto también
permitirá darle una mayor institucionalidad al área informática, haciéndola menos vulnerable a
los vaivenes de personal que a veces se presentan, y contribuirá a darle una mayor estabilidad
al uso de herramientas automatizadas para soportar los procesos de la CGR.
Además de lo anterior, la introducción en la entidad de algunas tecnologías complejas como los
certificados y firmas digitales, así como el estampado cronológico, aumentan aún más las
exigencias sobre la Oficina de Sistemas e Informática, teniendo en cuenta que si se hace la
solicitud para acreditarse como entidad de certificación cerrada, esto va a implicar un análisis de
los procesos por parte de una entidad externa: la ONAC (Organismo Nacional de Acreditación
de Colombia).
En particular, en lo que tiene que ver con la aplicación SAE, hay algunas condiciones que
contribuirán a darle una mayor sostenibilidad a su implantación en la entidad. En el presente
documento se hace una presentación de las mismas, clasificándolas en seis aspectos:
procesos, recurso humano, tecnología, seguridad, administración de datos y aspectos jurídicos.
2. PROCESOS
2.1 SITUACIÓN ACTUAL
A medida que las instituciones evolucionan y que su área informática maneja servicios cada vez
más complejos, surge la necesidad de que sus procesos sean más maduros y formalizados. No

basta únicamente con que el área informática maneje los artefactos tecnológicos, sino que se
requiere que esto sea hecho siguiendo unos ciertos principios, los cuales garantizan la
confiabilidad y seguridad de los servicios prestados. Además de lo anterior, en la medida en
que las empresas son cada vez más dependientes de los servicios informáticos, los
requerimientos sobre la calidad, por ejemplo la disponibilidad, se vuelven mayores. Para
enfrentar esta situación se acude a la formalización de los procesos del área de Sistemas, la
cual da una mayor garantía de la calidad del servicio prestado.
El estándar más conocido con respecto a la formalización de los procesos informáticos es ITIL
(Information Technology Infrastructure Library), el cual es una buena guía con respecto a los
procesos que deben ser manejados en el área informática. El ideal para una empresa es que,
por medio de un marco de referencia como el anterior, se puedan definir unos procesos
informáticos que se adecúen a sus particularidades, con el nivel de profundidad que sea
requerido. Actualmente, existe una gran distancia entre lo planteado por ITIL y lo existente en la
CGR.
Un primer aspecto que convendría resaltar es que para ITIL lo que maneja el área informática
son servicios, y no únicamente tecnología. Esto, más que un cambio de terminología, constituye
una nueva perspectiva sobre el tema, la cual se debe difundir en toda la organización. No se
trata simplemente de manejar unos artefactos tecnológicos como el hardware o las
aplicaciones, sino de prestar servicios a la empresa, los cuales deben tener una cierta calidad,
y por lo tanto deben poder ser evaluados y tener un proceso de mejoramiento continuo.
Con respecto a los servicios informáticos, ITIL establece que se deben establecer procesos
relacionados con su estrategia, su diseño, su transición, su operación, y su mejoramiento
continuo. Al analizar el caso de la CGR se ve que las actividades de la Oficina de Sistemas e
Informática han sido manejadas de una manera informal, lo cual ha llevado a que muchos de
los procesos planteados por ITIL no existan y a que otros tengan debilidades. Es así como, por
ejemplo, en muchos casos el nivel de disponibilidad de los servicios como el soporte al Proceso
de Responsabilidad Fiscal a través de SAE es incierto (en muchos casos ni siquiera se sabe
cuál es). Otro ejemplo sería con respecto al manejo de incidentes, los cuales son tratados
según el criterio de quien fue informado del mismo, y no siguiendo un proceso formal que
garantice un buen manejo. Es el caso, por ejemplo, de algunos incidentes en los que los
usuarios acuden al grupo de redes sin haber hecho una verificación básica de que las
conexiones físicas están debidamente realizadas. En otros casos hay debilidades en los
procesos, como es el caso de los servicios relacionados con certificados y firmas digitales, en
los cuales, si no se siguen ciertas formalidades, los procesos pierden una parte importante de
su legitimidad.
Últimamente la Oficina de Sistemas e Informática ha tomado conciencia de la debilidad en el
área de procesos y ha constituido un grupo denominado Control de Calidad, el cual ha venido
trabajando en el tema, y ha iniciado el proceso de formalización de los procesos, como es el
caso del relacionado con el control de cambios, pero con algunas limitaciones importantes: es

un grupo reducido, que no cuenta con el tiempo suficiente pues tiene asignadas otras
responsabilidades, y además requiere una mayor capacitación sobre el tema.
Los procesos del área informática a veces se relacionan con toda la organización, por lo cual es
conveniente tener una visión global de los mismos. Es el caso, por ejemplo, de los procesos
relacionados con el manejo de certificados y firmas digitales y estampado cronológico, los
cuales afectan a todos los funcionarios de la CGR. Por esta razón sería conveniente que la
labor de definición e implantación de los procesos sea liderada por una dependencia que tenga
una mayor visibilidad y empoderamiento en la institución, como es el caso de la Oficina de
Planeación, con el apoyo de la Oficina de Sistemas e Informática.
2.2 RECOMENDACIONES
En cuanto al aspecto de los procesos de la Oficina de Sistemas e Informática, se presentan las
siguientes recomendaciones:
- Sería conveniente que la CGR se concientice de la dependencia de las actividades de la
entidad del área informática, por lo que es necesario reforzar los procesos relacionados con
ésta. Sin embargo hay que tener presente que las labores de implantación de procesos en
cualquier entidad son dispendiosas, puesto que en muchos casos son vistas por los
funcionarios como un obstáculo para el desempeño de sus funciones. Esto requiere todo un
cambio cultural que permitirá que puedan llevarse a cabo satisfactoriamente, exigiendo una
labor continuada que toma un período considerable de tiempo.
- Generar los mecanismos requeridos para crear en la entidad, la perspectiva de que la labor
del área informática no consiste únicamente en manejar tecnología, sino en crear servicios,
los cuales deben tener una calidad y un proceso de evaluación y mejoramiento continuo.
- Estudiar el proceso seguido en otras entidades similares para la implantación de procesos
en el área informática, y con base en esa experiencia iniciar un proyecto formal que permita
darle un mayor alcance al tema dentro de la CGR. En el contexto de la actual consultoría de
Oportunidad Estratégica se ha establecido contacto con entidades como el Banco de la
República y el Ministerio de Hacienda, quienes han manifestado su disposición a apoyar a la
CGR en este aspecto.
- Para obtener el aval como entidad certificadora cerrada se requiere que los procesos
relacionados con la administración de certificados y firmas digitales, y estampado
cronológico sean muy sólidos. Por consiguiente, es muy importante trabajar en la
consolidación de los mismos, para lo cual pueden servir como guía las experiencias de
entidades certificadoras como el Banco de la República, el cual, en el desarrollo de la actual
consultoría con Oportunidad Estratégica, manifestó su disposición a apoyar a la CGR en
este tema.

- Fortalecer el equipo de trabajo de la Oficina de Sistemas e Informática que trabaja en el
área de procesos, dándoles más tiempo y capacitación para trabajar en el tema. Esto podría
estar acompañado de una consultoría especializada, dentro de la cual se podría capacitar a
los empleados de la CGR y darle una mayor vitalidad al proceso.
- Constituir un grupo de trabajo, liderado por la Oficina de Planeación, para trabajar en la
definición e implantación de los procesos informáticos. Esto podría implicar fortalecer el
grupo de la Oficina de Planeación que trabaja en el área de procesos.
3. RECURSO HUMANO
El avance vertiginoso que ha ocurrido en la CGR con respecto a la implantación de aplicaciones
que apoyan procesos misionales de la entidad, como es el caso de SICA y SAE, ha llevado a
que exista un desajuste entre la organización y la composición de la Oficina de Sistemas e
Informática; al igual que la magnitud de los desafíos que debe asumir. Uno de los aspectos en
los que esto es evidente es en lo relacionado con el recurso humano.
De un área informática en donde las personas desarrollan y/o mantienen aplicaciones por
solicitud de las diferentes dependencias, y se tienen unas labores de apoyo para actividades
como la administración de redes y bases de datos, a un nivel muy operativo; se debe pasar a
una en la que haya un mayor grado de especialización y en donde cada persona debe tener un
conocimiento más profundo de su tema.
Es por eso que no basta con que la persona sea capaz de administrar la red o la base de datos
de una aplicación, siguiendo las indicaciones del proveedor de la misma, sino que se requiere
un conocimiento más profundo que le permita asumir los retos que implica una nueva
concepción en donde la Oficina de Sistemas e Informática proporciona servicios a las demás
áreas, con un alto nivel de calidad, que debe ser evaluado permanentemente. Al analizar el
nivel de desarrollo de la CGR con respecto al aspecto anteriormente mencionado se encuentra
que hay debilidades.
Si bien el área de desarrollo y mantenimiento de aplicaciones cuenta con alguna solidez por
haber participado en el pasado en otros proyectos, en el caso específico de SAE podría
enfrentar dificultades por el desconocimiento que tiene del framework Procesa, que constituye
la base de SAE. De acuerdo con lo anterior, en este momento la dependencia de la CGR con
respecto a al proveedor Mnemo es muy grande. Es urgente entonces, que haya un proceso de
transferencia de conocimiento con respecto a este framework, a los funcionarios de la Oficina
de Sistemas e Informática que van a asumir la labor de mantenimiento de la aplicación.
De igual forma, sería muy conveniente que otros funcionarios de la Oficina de Sistemas e
Informática puedan tener un conocimiento adecuado del framework Procesa para poder

emprender el proyecto de integración de aplicaciones de la CGR usando como base este bus
empresarial.
Recientemente se han presentado algunos problemas de desempeño de SAE por el acceso
simultáneo de varios usuarios a la aplicación. El diagnóstico de problemas de esta naturaleza
es complejo y requiere un amplio conocimiento de la aplicación, del framework Procesa, de
bases de datos y de técnicas de afinamiento de las mismas. Es muy importante por lo tanto que
Mnemo pueda resolver el problema antes de que la aplicación sea recibida por la CGR. Pero
surge además la pregunta de hasta dónde los funcionarios de la Oficina de Sistemas e
Informática pueden enfrentar problemas de esta naturaleza, o para contratar a un consultor
especializado que los resuelva.
Un aspecto que se introdujo con la implantación de SAE, que va a ser extendido a otras
aplicaciones como SICA y el correo electrónico, fue el uso de certificados y firmas digitales para
la autenticación segura de los funcionarios y para garantizar la autenticidad de sus actuaciones.
Sin embargo, esto no estuvo acompañado de un proceso de capacitación sobre los principios
básicos y las implicaciones del uso de este tipo de mecanismos, para todos los funcionarios de
la CGR.
Tampoco hubo una capacitación a los funcionarios del SOC, de la Oficina de Sistemas e
Informática, con respecto a los conceptos básicos y la administración de los mismos. Lo que se
realizó fue una inducción a los encargados con respecto a cómo usar la herramienta para la
expedición de certificados y firmas. Sin embargo, el manejo de una entidad certificadora cerrada
requiere mucho más que lo anterior. En otras entidades con más experiencia en el manejo de
este tema, se cuenta con una unidad de seguridad informática en donde se manejan dichos
temas, con gente especializada en estos aspectos. La experiencia de estas empresas puede
ser de gran valor para la CGR.
Con el uso masivo de aplicaciones como SICA y SAE surgió la necesidad de tener un mejor
control de la calidad prestada por estos servicios. Uno de los aspectos que se volvió crítico fue
el de la atención adecuada a los usuarios funcionales, a través de una mesa de ayuda, la cual
va a ser muy importante en los inicios del uso masivo de SAE. Esto conduce a la necesidad de
contar con un grupo de apoyo que pueda ayudar a los usuarios a resolver sus problemas a nivel
funcional y técnico, lo cual es especialmente crítico en las Gerencias Departamentales
Colegiadas, en donde hay menos recursos de ayuda para los usuarios funcionales.
Por ahora este requerimiento se está supliendo por parte de los funcionarios del grupo SAE, por
medio del correo electrónico, pero esto no parece suficiente.
Otra de las necesidades que surge con el uso masivo de aplicaciones como SICA y SAE, es la
de contar con el personal adecuado para soportar la infraestructura de apoyo a estas
aplicaciones, y poder resolver problemas técnicos en lo referente a temas como redes, bases
de datos y hardware. Actualmente, algunos de estos aspectos están siendo asumidos por

Mnemo, pero se requiere que, cuando termine el contrato con esta compañía, la Oficina de
Sistemas e Informática pueda asumir estas funciones.
Algunos funcionarios manifestaron que han recibido una buena capacitación con respecto a
aspectos operativos, usualmente con los proveedores de los productos, sobre el manejo de las
herramientas, pero que requieren una mayor formación en aspectos más conceptuales. Según
ellos se requeriría una mayor capacitación en aspectos como diseño y administración de redes
y aspectos conceptuales de bases de datos. También se requeriría una mayor apropiación por
parte de los encargados, de la estructura de la base de datos de SAE, para poderle dar un
apoyo técnico adecuado al proceso de mantenimiento y eventual modificación del aplicativo.
3.2 RECOMENDACIONES
Con respecto a los recursos humanos de la Oficina de Sistemas e Informática, Oportunidad
Estratégica presenta las siguientes recomendaciones:
- Es muy importante que los encargados de SAE tengan una muy buena capacitación en el
framework Procesa, para que puedan darle un soporte adecuado a la aplicación; y
adicionalmente, porque esta herramienta podrá servir de base para hacer una integración
de las aplicaciones de la CGR.
- Adelantar las actividades requeridas para que todos los funcionarios de la CGR reciban una
buena capacitación con respecto al manejo de certificados y firmas digitales, y estampado
cronológico, teniendo en cuenta que éstos están siendo usados en SAE, y muy pronto
también en aplicaciones como SICA y el correo electrónico.
- Sería muy recomendable que los funcionarios del Centro de Operaciones de Seguridad
(SOC), quienes están a cargo del manejo de la expedición de certificados y firmas digitales,
reciban una capacitación a este respecto, que cubra aspectos conceptuales y no
únicamente lo referente al uso de la herramienta para expedirlos. Esta podría ser una
exigencia del Organismo Nacional de Acreditación de Colombia – ONAC, para la
acreditación de la CGR como una entidad de certificación cerrada.
- Convendría reforzar la mesa de ayuda de SAE, con el fin de darle un apoyo adecuado a los
usuarios de SAE en aspectos funcionales y técnicos, lo cual es especialmente crítico en el
caso de las Gerencias Departamentales Colegiadas. También se requiere que los usuarios
de SICA y de correo electrónico puedan tener un soporte adecuado, con respecto al uso de
certificados y firmas digitales. Esto implicaría revisar la organización de la mesa de ayuda,
su conformación, la dedicación de las personas a esta labor y el tipo de canal(es) que
es(son) más conveniente(s). La experiencia de SICA en este tema puede ser de gran valor.
- Es muy importante que algunos funcionarios de la Oficina de Sistemas e Informática puedan
conocer muy bien la estructura de la base de datos de SAE para poder dar un soporte

adecuado. Esto requiere un proceso de capacitación de Mnemo con respecto a la última
versión de la misma.
- Sería muy recomendable reforzar el grupo de apoyo técnico de la Oficina de Sistemas e
Informática en aspectos conceptuales relacionados con redes y bases de datos. Esto podría
lograrse a través de la capacitación de los funcionarios actuales. También, podría pensarse
en contratar una consultoría especializada que, además de realizar la labor de soporte,
capacite a los funcionarios de la CGR para asumir esta labor.
4. TECNOLOGÍA
Con el fin de evitar dificultades en la implantación de aplicaciones como SICA y SAE, la Oficina
de Sistemas e Informática tuvo en cuenta las recomendaciones de los proveedores, con
respecto a sus requerimientos de hardware y de software básico. Esto ha llevado a que en
general la infraestructura de apoyo a estas aplicaciones haya respondido adecuadamente. Han
existido, sin embargo, algunas dificultades que es conveniente señalar.
El tiempo de respuesta de SAE ha sido en general bueno, pero últimamente, a raíz del uso
simultáneo de la aplicación por los usuarios, se han presentado problemas de desempeño, a
pesar de que la CGR siguió las indicaciones de Mnemo con respecto a la infraestructura
requerida. Lo más recomendable al respecto sería hacer pruebas de carga de la aplicación con
el fin de garantizar que se va a comportar adecuadamente ante su uso masivo y hacer los
correctivos del caso, con el apoyo de Mnemo.
En algunas Gerencias Departamentales Colegiadas, especialmente en las que se tiene
comunicación a través de satélite, se han presentado algunas dificultades que han hecho que la
comunicación no funcione adecuadamente. Esto se ha producido, debido en parte, a que los
requerimientos de comunicación de SAE son muy grandes, puesto que se transmiten
documentos voluminosos, y en algunos casos videos, que consumen un ancho de banda muy
grande.
Lo más recomendable para enfrentar esta situación sería hacer un seguimiento a las eventuales
dificultades de comunicación con las Gerencias Departamentales Colegiadas, especialmente
las que tienen comunicación satelital, hacer un dimensionamiento del ancho de banda
requerido; aumentarlo si se encuentra que es necesario y es posible, o fijar reglas que impidan
que el canal pueda ser saturado. Por ejemplo, en alguna ocasión se detectó que el canal de
una Gerencia Departamental Colegiada se saturó porque muchos funcionarios estaban
descargando el antivirus simultáneamente. Habría que fijar reglas que impidan que ocurran este
tipo de incidentes.

Otra dificultad que se ha tenido, es que los usuarios funcionales de SAE no siempre cuentan
con una estación de trabajo adecuada para poder trabajar con SAE. La CGR ha hecho un
esfuerzo importante últimamente para modernizar las estaciones de trabajo de sus funcionarios.
Habría que verificar que este problema ya ha sido resuelto satisfactoriamente, especialmente
en las Gerencias Departamentales Colegiadas.
Se ha presentado otra problemática relacionada con la configuración de las estaciones de
trabajo de los funcionarios, debido a que existe alguna heterogeneidad al respecto. Lo más
recomendable para enfrentar esta situación sería analizar la posibilidad de usar la tecnología de
clientes virtuales, la cual facilitaría la homogeneización de la estructura de las estaciones de
trabajo y daría un mayor nivel de seguridad.
Por otra parte, a raíz de la implantación de aplicaciones como SICA y SAE, ha surgido la
necesidad de que exista una integración de las diferentes aplicaciones que se usan en la CGR,
para poder tener una visión más consistente de la información que se maneja en la entidad y
para facilitar la labor de los funcionarios, evitando que tengan que introducir más de una vez la
misma información a diferentes aplicaciones. Esto plantea un problema, que puede ser
enunciado como la definición de una arquitectura, que permita una interacción adecuada entre
las diferentes aplicaciones de la entidad.
El ideal sería que, más que un conjunto de aplicaciones aisladas, haya una plataforma común a
la cual se integran las diferentes aplicaciones para poder interactuar con otras. La realización
de un proyecto de esta naturaleza puede ser compleja, pero conviene ir tomando decisiones
que permitan que se avance en esta dirección. Algunas medidas que se podrían ir trabajando a
este respecto serían: (i) la unificación de la codificación de las entidades sujetos de control de
la CGR en todas las aplicaciones, (ii) el establecimiento de reglas que se deben cumplir cuando
se desarrolla o adquiere una nueva aplicación, y (iii) la definición de un mecanismo de
integración. Contar en la actualidad con Procesa, que es una herramienta para lograr este
propósito, puede ser de utilidad al respecto.
4.2 RECOMENDACIONES
Con respecto a la tecnología en la Oficina de Sistemas e Informática, se presentan las
- Realizar pruebas de carga a SAE para detectar eventuales problemas de tiempos de
respuesta muy grandes, cuando es usada simultáneamente por un número alto de usuarios,
y conjuntamente con Mnemo, tomar los correctivos del caso.
- Hacerle seguimiento al comportamiento de los canales de comunicación con las Gerencias
Departamentales Colegiadas, con el fin de analizar si son adecuados, si requieren ser
aumentados, o si es necesario fijar reglas de utilización para evitar que se bloqueen.

- Verificar que todos los funcionarios de la CGR tengan una estación de trabajo, que les
permita trabajar adecuadamente con SAE.
- Analizar la posibilidad de usar la tecnología de clientes virtuales, para facilitar la
homogeneización de la configuración de las estaciones de trabajo, y contribuir a dar un
mayor nivel de seguridad.
- Empezar a trabajar en la definición de una arquitectura que permita la integración de las
diferentes aplicaciones existentes, y de las que se desarrollen/adquieran en el futuro. Para
ello se puede aprovechar las facilidades que ofrece Procesa.
5. SEGURIDAD
En los últimos tiempos, y a un paso acelerado, la CGR ha venido avanzando hacia el reemplazo
de los documentos físicos por documentos electrónicos. Pero, a diferencia del mundo físico, en
donde la experiencia de muchos años le ha permitido crear mecanismos de protección
adecuados, en el ámbito electrónico tiene poca experiencia. Además, los cambios han ocurrido
en forma tan veloz, que la Entidad no ha tenido tiempo de adaptarse a los nuevos
requerimientos de seguridad que implica el mundo electrónico. De igual forma, en la medida en
que siga avanzando en la eliminación de los documentos físicos, se volverá cada vez más
dependiente de los electrónicos, y por lo tanto de su seguridad.
A veces se piensa que la seguridad informática tiene que ver con artefactos tecnológicos, pero
la realidad es que es mucho más que eso. Se trata de mantener la confidencialidad, la
integridad y la disponibilidad de la información almacenada en medio electrónicos. Y para
garantizarlas se requiere trabajar en los tres frentes que conforman todo proyecto informático: la
tecnología, los procesos y el recurso humano.
Desde hace algún tiempo, y principalmente en los últimos dos años, la CGR ha venido
desarrollando actividades encaminadas a fortalecer la seguridad informática. El desarrollo de
una infraestructura física con altos estándares de seguridad, la conformación de un grupo de
trabajo en informática forense, la constitución de un grupo de seguridad, el SOC, dentro de la
Oficina de Sistemas e Informática, vienen a complementar otra iniciativa anterior, la existencia
de una Unidad de Seguridad Informática en la entidad, la USATI, con un alto empoderamiento
dentro de la organización. Todo lo anterior representa un gran avance con respecto a la
seguridad informática, pero se requiere seguir trabajando en su fortalecimiento.
Usualmente, las empresas modernas con una complejidad y dimensión como las de la CGR,
cuentan con una unidad de seguridad informática, a cargo de un oficial de seguridad (CSO, o
Chef Security Officer). En la CGR existe la USATI, la cual tiene esa misión, pero habría que
fortalecerla y hacer una mejor integración con la Oficina de Sistemas e Informática, a través del

grupo SOC. Los funcionarios de esta última, que están encargados de aspectos de seguridad
como el análisis de vulnerabilidades o la administración de certificados y firmas digitales, tienen
poca comunicación con la USATI, hasta el punto de que no están muy enterados de lo que ésta
hace.
Por otra parte, no se ha desarrollado un plan de seguridad informática para la entidad, el cual
debería estar dirigido a enfrentar los problemas de seguridad de una manera sistemática: definir
cuáles son los recursos electrónicos que conviene proteger de acuerdo con su importancia y el
riesgo de ser atacados; y definir un plan para protegerlos.
Una dificultad que se enfrenta para realizar lo anterior, es la falta de un grupo humano con las
calificaciones requeridas para enfrentar un proyecto de esa magnitud. Convendría reforzar al
equipo actual.
La seguridad informática depende de muchos factores: las instalaciones físicas, la red, las
aplicaciones, los datos, los procesos y las personas. En algunos de ellos, la CGR ha hecho
avances importantes, pero en otros no tanto. Por ejemplo, no existen normas con respecto a la
seguridad que deben tener las aplicaciones para evitar ataques, sólo recientemente se ha
hecho el primer estudio de vulnerabilidades. Adicionalmente, los procesos del área informática
que pueden afectar la seguridad son muy informales y no se ha trabajado mucho en crear una
cultura de seguridad de la información entre todos los funcionarios de la organización. Para
enfrentar las debilidades anteriores convendría trabajar en el fortalecimiento de los procesos
que tienen que ver con la seguridad.
La introducción del uso de certificados y firmas digitales, al igual que la solicitud que piensa
hacer la CGR, para ser reconocida como una entidad de certificación cerrada, implica que tiene
que hacer un gran esfuerzo por robustecer los procesos relacionados con este tema. Existen
todavía debilidades que convendría superar.
Otro aspecto que vale la pena mencionar, es la falta de un plan de continuidad de negocio que
permita reanudar las actividades en el caso de fallas mayores. Uno de los componentes de este
plan es la existencia de un sitio alterno, el cual permitiría la recuperación en un tiempo menor,
pero no es el único.
5.2 RECOMENDACIONES
Con respecto a la seguridad en la Oficina de Sistemas e Informática, se presentan las
- Es muy importante que la CGR tome consciencia de la importancia que reviste el tema de la
seguridad informática, teniendo en cuenta la dependencia cada vez mayor que tiene la
entidad con respecto a los recursos informáticos.

- Es igualmente deseable crear una cultura de seguridad de la información entre todos los
funcionarios de la entidad.
- Si bien podría tomar algún tiempo, se recomienda que la CGR, con ayuda de guías como el
estándar 27001 relacionado con la seguridad de la información, pueda ir fortaleciendo la
seguridad informática. El ideal sería obtener esta certificación, pero si no se logra, al menos
convendría que se haga un análisis de los aspectos críticos para la entidad y se trabaje en
enfrentarlos. Dentro de esta actividad convendría reforzar los procesos relacionados con la
seguridad.
- Para poder obtener el reconocimiento como una entidad de certificación cerrada, se
requiere que los procesos relacionados con la administración de firmas y certificados
electrónicos, así como de estampado cronológico, sean muy robustos. Es muy importante
entonces trabajar en la consolidación de los mismos, para lo cual pueden servir como guía
las experiencias de entidades certificadoras como el Banco de la República, quien durante
el desarrollo de la actual consultoría con Oportunidad Estratégica manifestó su disposición a
apoyar a la CGR en este tema.
- Es muy conveniente que haya una mayor integración entre la USATI y el grupo SOC.
- Se recomienda reforzar el grupo de apoyo técnico de la Oficina de Sistemas e Informática,
en aspectos conceptuales relacionados con seguridad. Esto se puede lograr a través de la
capacitación de los funcionarios actuales. También, es conveniente considerar la
contratación de una consultoría especializada que, además de realizar la labor de soporte,
capacite a los funcionarios de la CGR para asumir esta labor.
- Se recomienda contar con un plan de continuidad de negocio.
6. ADMINISTRACIÓN DE DATOS
Cuando las instituciones desarrollan o adquieren aplicaciones sin una visión integradora, con el
tiempo empiezan a surgir problemas de consistencia de los datos. Esto es algo relativamente
frecuente en las empresas, puesto que la visión de una arquitectura empresarial, y dentro de
ella de una arquitectura da datos, es relativamente reciente.
En el caso de la CGR existen aplicaciones que apoyan actividades importantes de la entidad
como SIPAR, SIGEDOC, SIREF, y últimamente SICA y SAE. Sin embargo, no se ha tenido en
cuenta la conveniencia de que en todas ellas la codificación y el nombre de las entidades, los
municipios y otros elementos que se manejan, sea idéntica, e igual también a la utilizada por el
Estado. Esto puede conducir a inconsistencias, puesto que dos aplicaciones podrían arrojar
información diferente sobre el mismo tema, y además se dificultaría el proceso de realizar

análisis de información sobre los datos, el cual es uno de los valores agregados más
importantes del manejo de información en forma electrónica.
La necesidad de agilizar el proceso de implantación de aplicaciones como SICA y SAE ha
conducido al fenómeno anterior, pero, una vez realizada ésta de forma exitosa, conviene ir
pensando hacia el futuro próximo en enfrentar esta problemática.
El ideal sería que una dependencia dentro de la CGR, la Oficina de Planeación, se encargara
de definir cuál es la nomenclatura, codificación y el nombre que debería dársele a cada entidad,
municipio, y otros elementos que utilizan las aplicaciones, y que esta fuera utilizada en todas las
aplicaciones, y en general en toda la documentación que haga referencia a ellos. Además
debería coincidir con la asignada por el Estado.
El proceso para que la situación ideal anterior pueda llevarse a la práctica es relativamente
dispendioso, debido a que implica modificar las bases de datos de las aplicaciones y se podría
presentar un conflicto entre la nomenclatura anterior y la nueva, que habría que entrar a
resolver. Con respecto a las nuevas aplicaciones que se desarrollen o adquieran, se
recomienda velar por la utilización de la nomenclatura definida por la Oficina de Planeación.
A largo plazo, lo ideal sería que los diferentes datos y servicios que se manejan en la entidad
puedan organizarse en una Arquitectura Orientada a Servicios - SOA (Service Oriented
Architecture). Así como el directorio activo es un servicio que es utilizado por todas las
aplicaciones para la autenticación de los usuarios, podrían existir otros servicios como consultar
información sobre auditorías, que podría ser suministrada por SICA y utilizable por las demás
aplicaciones, o consultar información sobre Procesos de Responsabilidad Fiscal, la cual podría
ser proporcionada por SAE o SIREF, y usada por las demás aplicaciones. Un primer paso para
lograr esto, sería trabajar en la unificación de la nomenclatura de entidades, municipios y
elementos afines. Esto facilitaría enormemente la integración entre las diferentes aplicaciones.
6.2 ANÁLISIS DE LA BASE DE DATOS DE SAE
El análisis que se desarrolla a continuación es un análisis preliminar sobre la Base de Datos
que actualmente está funcionando en la CGR. Éste análisis se ha desarrollado mediante la
comparación entre el documento de la Estructura de Base de Datos elaborado por MNEMO1
y
la estructura de Base de Datos entregada el día 16 de Octubre por la CGR a Oportunidad
Estratégica. Esta estructura es la que soporta actualmente el Sistema de Aseguramiento
Electrónico de Expedientes – SAE.
El documento de la Estructura de Base de Datos elaborado por MNEMO2
, fue entregado por
MNEMO DE COLOMBIA S.A.S. a la Contraloría General de la Republica (CGR) en agosto de
2013 y al equipo de Oportunidad Estratégica, el día 17 de Septiembre.
1
(Sistema de Aseguramiento de Expedientes Electrónico - Estructura de Base de Datos - Contraloría General de la
República de Colombia V4.0, 16 de Julio de 2013)
2
Ibíd.

Para realizar el análisis del que se hace mención, se realizó un proceso de ingeniera inversa en
la reconstrucción del modelo de datos, haciendo uso de la técnica Entidad – Relación, modelo
que se adjunta al presente documento (Ver Anexo).
De este ejercicio se evidenció que:
a. La arquitectura de datos que funciona actualmente dentro de la CGR, contempla la
definición de 7 esquemas o módulos de datos principales, asociados a igual número de
usuarios, los cuales son mencionados a continuación.
Tabla 1. Esquemas Base de Datos SAE - Elaboración Oportunidad Estratégica
ESQUEMA - USUARIO DESCRIPCIÓN
1. KEYONECA
Esquema que contempla la gestión de datos asociado con las actividades
de la Autoridad Certificadora.
2. PROCESA_ENGINE
Esquema que contempla la gestión de datos asociados al motor
PROCESA3
3. PROCESA_GESTEXP No fue suministrada ésta información por parte de MNEMO.
4. PROCESA_PROC
Esquema que contempla la gestión de datos asociada con el Proceso de
Responsabilidad Fiscal dentro de la CGR.
5. PROCESA_REPO No fue suministrada ésta información por parte de MNEMO.
6. PROCESA_WD No fue suministrada ésta información por parte de MNEMO.
7. TRUSTEDX
Esquema en el que se describe y administra la estructura de datos del
Hardware Security Module (HSA).
Este esquema soporta la plataforma donde generan, almacenan y donde
se protegen las claves criptográficas generadas para la firma digital.
El análisis que se presenta se centrará en los objetos (Tablas, Vistas, Índices, Paquetes,
Procedimientos, Funciones, Disparadores y Secuencias), que hacen parte del esquema
PROCESA_PROC.
3
Plataforma que permite que diferentes procesos desplegados se integren de forma sencilla con los procesos,
servicios, aplicaciones y arquitecturas existentes dentro de la CGR como lo son SICA, SIREF, SIGEDOC, SIPAR,
entre otros.

6.2.1 Análisis de las Tablas
Oportunidad Estratégica identifico a partir de la información suministrada por la CGR, que en el esquema PROCESA_PROC, existen
139 entidades, sin embargo en el documento Estructura de Base de Datos V4.0 entregado por MNEMO a la CGR solo se hace mención
de 124 entidades, y son estas 124 las que son objeto de análisis, dado que de las 15 restantes MNEMO no ha entregado
documentación.
A continuación se presentan algunas observaciones y recomendaciones sobre las entidades que presentan algunas oportunidades de
mejora dentro del modelo de datos.
Tabla 2. Tabla comparativa entre la estructura de base de datos que funciona en la CGR y lo documentado por MNEMO.
ANALISIS COMPARATIVO ENTRE: LA ESTRUCTURA DE BASE DE DATOS QUE FUNCIONA A OCTUBRE 16 DE 2013 EN LA CGR Y LA
ESTRUCTURA DOCUMENTADA Y ENTREGADA A LA CGR POR MNEMO, EN EL DOCUMENTO “ESTRUCTURA BASE DE DATOS PRF v4.0 ”.
Número
de la
Entidad
Entidad
Descripción de la entidad e Información de
los atributos
Inconsistencias u observaciones
encontradas
Recomendación
1 ACCION_TIPO_PRF
Tabla maestra que almacena todas las acciones
que se pueden realizar para el Expediente de
Responsabilidad Fiscal en función de si el PRF
es ordinario o verbal.
ID_TIPO (NUMBER): Almacena el tipo de PRF.
 1 á Ordinario.
 o 2 á Verbal.
ID_ACCION (VARCHAR2 200 BYTE):
Almacena la acción que se puede realizar. Estas
acciones corresponden con las acciones
definidas en la entidad 4. En esta entidad están
todas las acciones de menú posibles.
Está definido como VARCHAR de 100
Byte en la base de datos que está
funcionando en el CGR
2
ACCIONES_ESTADO_
ANTIP
Tabla maestra que almacena las acciones que
se pueden realizar en función del estado en el
que se encuentre el expediente de
Antecedentes e Indagación Preliminar
ID_STATE_INFO (VARCHAR2 400 BYTE):
estado en el que se encuentra el expediente.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
ID_ACCION (VARCHAR2 200 BYTE):
Almacena la acción que se puede realizar. Estas
acciones corresponden con las acciones
definidas en la entidad 4. En esta entidad están
todas las acciones de menú posibles.
Está definido como VARCHAR de 100
Byte en la base de datos que está
funcionando en el CGR
Solicitar a MNEMO realizar la
actualización de este campo en la
documentación correspondiente .
MENSAJE_CAMBIO_ETAPA (VARCHAR2 4000
BYTE): Almacena el mensaje a mostrar en los
cambios de etapas donde se pueden introducir
múltiples autos.
4 ACCIONES_MENU
Tabla maestra que almacena todas las acciones
que se pueden ejecutar desde el proceso de
menú, independientemente del tipo de
expediente y del estado.
ID_ACCION (VARCHAR2 100 BYTE): Acción a
realizar. Tiene que tener coherencia con las
acciones puestas en los puntos 1, 2.y 3.
DESCRIPCION (VARCHAR2 1000 BYTE):
Descripción de la acción, y que aparece en el
proceso de menú para que el usuario elija una
tanto para el expediente de Antecedentes e
Indagación Preliminar como para el
Procedimiento de Responsabilidad Fiscal.
DESCRIPCION_I18N (VARCHAR2 1000
BYTE):
Este atributo no se encuentra
documentado en la estructura que SAE
entrega a la CGR, sin embargo en la base
de datos que actualmente está funcionado
en la CGR este atributo hace parte de
esta entidad.
No existe un documento de control de
cambios donde se documenten éstas
modificaciones en la Base de Datos.
Revisar la pertinencia de este campo.
actualización de la documentación
correspondiente o en su defecto
proceder con la eliminación del campo de
la estructura.
5 ACTUACIONES
Tabla que almacena todas las actuaciones tanto
procesales (PRF Ordinario) como de la etapa de
pruebas (PRF Ordinario) como de la Audiencia
de Descargos (PRF Verbal) para todos los
expedientes generados, sin asociarlas a
ninguna etapa de ningún expediente (en los
siguientes puntos están las relaciones con el

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
expediente).
ID_ACTUACION (NUMBER): Identificador de la
actuación. Es un número autogenerado.
N_AUTO (VARCHAR2 200 BYTE): Número de
auto (PRF Ordinario).
FECHA (DATE): Fecha de la actuación (PRF
Ordinario).
CUANTIA (FLOAT): Cuantía de la actuación
(PRF Ordinario).
ID_TIPO_ACTUACION (NUMBER): Identificador
del tipo de actuación elegida. Tiene una
referencia con la entidad 115.
TIMESTAMP (DATE): Fecha interna de
inserción del registro en la tabla.
ACTUACION (VARCHAR2 500 BYTE):
Descripción del tipo de actuación elegida. Tiene
una referencia con la entidad 115.
Según la documentación entregada por
MNEMO, la entidad ACTUACIONES
cuenta con dos IDs, uno es la llave
primaria de la entidad “id_actuacion”, y el
otro hace referencia a una llave foránea
“id_tipo_actuacion”.
La llave foránea “id_tipo_actuacion” es la
llave primaria de la entidad
TIPOS_ACTUACIONES.
Por consiguiente, es en ésta entidad en
dónde se debe hacer la descripción
correspondiente al registro “Actuacion”,
puesto que es una característica propia de
la entidad TIPOS_ACTUACIONES y no de
la entidad ACTUACIONES.
Se recomienda hacer la corrección de
este registro dentro de la base de datos,
porque es un dato que se está
capturando en dos lugares, lo que
provocaría redundancia de información.
N_SESION (VARCHAR2 200 BYTE): Número
de sesión (PRF Verbal).
FECHA_ACTA (DATE): Fecha del acta (PRF
Verbal).
FECHA_SESION (DATE): Fecha de la sesión
(PRF Verbal).
ACTA (VARCHAR2 4000 BYTE): Descripción
del acta (PRF Verbal).

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
N_PROCESO (VARCHAR2 100 BYTE): Número
de proceso (PRF Ordinario).
FECHA_ULT_NOT (DATE): Fecha de la última
modificación.
NUM_PROVIDENCIA (VARCHAR2 200 BYTE) Estos atributos no se encuentran
documentados en la estructura que SAE
en la CGR estos atributos hacen parte de
esta entidad.
Revisar la pertinencia de estos campos.
proceder con la eliminación de estos
campos dentro de la estructura.
FECHA_PROVIDENCIA (DATE)
HORA_INICIO_SESION (VARCHAR2 20 BYTE)
HORA_FIN_SESION (VARCHAR2 20 BYTE)
10 ACUSES
Tabla que almacena todas las notificaciones a
todos los destinatarios enviadas. Esta tabla
también almacena si el sistema ha recibido el
acuse de recibo y la fecha del acuse.
ID_ACUSE (NUMBER): Identificador del acuse.
Es un número autogenerado.
REMITENTE (VARCHAR2 200 BYTE): Correo
del usuario remitente del acuse, que es el
mismo que el destinatario de la notificación.
No existe una estandarización en la
definición de la longitud de los campos.
Hay entidades en las que se define el
campo correo con una longitud de hasta
4000 bytes
Establecer que todos los campos
asociados con el registro de direcciones
de correo electrónico cuenten con la
misma longitud.
ACUSE (VARCHAR2 20 BYTE): Indica con
Sí/No si se ha recibido el acuse por parte del
remitente.
Si el campo se está utilizando para el
registro de un indicador de Si o No, se
debe considerar como con campo tipo
CHAR y de una longitud menor.
FECHA_ACUSE (TIMESTAMP): Fecha en la
que se envía el acuse de recibo.
11
ACUSES_NOTIFICACI
ONES
Tabla que almacena la relación de todos los
envíos para esperar el acuse y la notificación
que se ha creado en el sistema.
ID_NOTIFICACION (NUMBER): Identificador de
la notificación creada.
ID_ACUSE (NUMBER): Identificador del acuse.
No es clara la diferencia en término de
longitud con el campo ID_ACUSE de la
estructura ACUSES

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
12 ANTECEDENTES
Tabla que almacena todos los antecedentes
para todos los expedientes. Las relaciones con
las diferentes etapas tanto del expediente de
Antecedentes e Indagación Preliminar como del
PRF se ven en los puntos siguientes.
ID_ANTECEDENTE (NUMBER): Identificador
del antecedente. Es un número autogenerado.
CODIGO_SIGEDOC (VARCHAR2 200 BYTE):
Código SIGEDOC del antecedente.
Establecer a nivel de un servicio con
SIGEDOC, la validación de esté código
de manera conjunta con el campo
FECHA_SIGEDOC.
FECHA_SIGEDOC (DATE): Fecha SIGEDOC
del antecedente.
Establecer a nivel de un servicio con
SIGEDOC, la validación de esta fecha de
manera conjunta con el campo
CÓDIGO_SIGEDOC.
ORIGEN_ANTECEDE (VARCHAR2 200 BYTE):
Descripción del Origen del antecedente. Tiene
relación con la tabla de la entidad 89.
La descripción del campo
“origen_antecedente” no es un dato que
dependa de la clave primaria
“id_antecedente”.
Este es un atributo que depende de la llave
primaria de la entidad
ORIGEN_APERTURA.
Es recomendable contemplar la
posibilidad de retirar éste campo de esta
entidad, dado que al existir ya en la
entidad ORIGEN_APERTURA se
estaría generando redundancia en la
información registrada.
DESTINO_ANTECEDENTE (VARCHAR2 200
BYTE): Destinatario del antecedente.
TIMESTAMP (DATE): Fecha interna de creación
del registro en la tabla.
ID_ORIGEN_ANTECEDENTE (NUMBER):
Identificador del origen del antecedente. Tiene
relación con la tabla de la entidad 89.
REMITENTE_ANTECEDENTE (VARCHAR2
200 BYTE): Remitente del antecedente.
15 APODERADOS
Tabla que almacena todos los apoderados
registrados en el sistema.
ID_APODERADO (NUMBER):
Identificador del apoderado. Es un número
autogenerado.
Se está generando un identificador dentro
de la entidad cuando se puede utilizar uno
de sus atributos como identificador.
Verificar que la identificación de los
apoderados sea a partir del número de
su documento de identificación o número
de tarjeta profesional.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
N_CEDULA (VARCHAR2 200 BYTE): Número
de cédula del apoderado.
Este puede ser el Identificador de la
entidad apoderados.
NOMBRE (VARCHAR2 200 BYTE): Nombre del
apoderado.
TARJETA_PROFESIONAL (VARCHAR2 200
BYTE): Número de tarjeta profesional del
apoderado.
EMAIL (VARCHAR2 400 BYTE): Dirección de
correo electrónico del apoderado.
Está definido como (VARCHAR DE 4000)
en el modelo que está funcionando en la
CGR.
de correo electrónico cuente con la
misma longitud y denominación para la
identificación de la columna.
17 AUTOS_AAINDP
Tabla que almacena todos los autos de apertura
de la indagación preliminar para todos los
expedientes, independientemente de si
corresponden a los expedientes de
Antecedentes e Indagación Preliminar o al PRF.
Las relaciones del auto de apertura con los
expedientes tanto del expediente de
ID_AUTO (NUMBER): Identificador del auto de
apertura de indagación preliminar. Es un
número autogenerado.
El identificador de esta entidad está
declarado como un número autogenerado
pero los autos de apertura de Indagación
Preliminar ya cuentan con un número
generado desde SIREF.
Para mantener la integridad entre los
diferentes sistemas de la entidad e
incrementar el nivel de trazabilidad, es
recomendable que el identificador no sea
un valor autogenerado sino que se
aproveche el valor generado desde el
SIREF.
NUM_IP (VARCHAR2 60 BYTE): Número de
indagación preliminar.
NUM_AUTO_IP (VARCHAR2 60 BYTE):
Número de auto.
FECHA_APERTURA (DATE): Fecha de
apertura de la indagación preliminar.
CUANTIA (FLOAT): Cuantía del auto de
apertura de la indagación preliminar.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
18 AUTOS_AAINDP_ANIP
Tabla que almacena la relación entre el auto de
apertura de la indagación preliminar realizado
(entidad 17) y el expediente con el que se está
trabajando. Esta tabla está destinada a guardar
las relaciones de la etapa del auto de apertura
de la indagación preliminar del tipo de
expediente Antecedentes e Indagación
Preliminar.
ID_REQUEST: Identificador interno del
expediente.
No definen el tipo de dato en el Documento
Esquema de la base de datos.
Actualizar documentación entregada por
parte de MNEMO
ID_AUTO: Identificador del auto.
No definen el tipo de dato en el Documento
Esquema de la base de datos.
Actualizar documentación entregada
por parte de MNEMO
20 AUTOS_ACINDP
Tabla que almacena todos los autos de cierre de
la indagación preliminar para todos los
expedientes, independientemente de si
corresponden a los expedientes de
Antecedentes e Indagación Preliminar o al PRF.
Las relaciones del auto de cierre con los
expedientes tanto del expediente de
ID_AUTO (NUMBER): Identificador del auto de
cierre de indagación preliminar. Es un número
autogenerado.
NUM_IP (VARCHAR2 60 BYTE): Número de
NUM_AUTO (VARCHAR2 60 BYTE): Número
de auto.
El identificador de esta entidad está
declarado como un número autogenerado,
pero los autos ya cuentan con un número
generado desde SIREF.
Para mantener la integridad entre los
diferentes sistemas de la entidad e
incrementar el nivel de trazabilidad, es
recomendable que el identificador no sea
un valor autogenerado sino que se
aproveche el valor generado desde el
SIREF.
FECHA_AUTO (DATE): Fecha de cierre de la

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
CUANTIA (FLOAT): Cuantía del auto de cierre
de la indagación preliminar.
EMAIL_DESTINATARIO (VARCHAR2 200
BYTE): Dirección de correo electrónico del
destinatario.
Se define e-mail como un VARCHAR de
200 byte, es una declaración que no
guarda ninguna correspondencia en
longitud con la declaración de este mismo
campo en otras entidades.
26 COMP_SEGUROS
Tabla maestra que almacena todas las
compañías de seguros utilizados en el proceso
de la aplicación SAE.
ID_COMP (NUMBER): Identificador de la
compañía de seguros. Es un valor numérico
autogenerado.
DESCRIPCION (VARCHAR2 200 BYTE):
Nombre de la compañía de seguros.
NIT (VARCHAR2 200 BYTE): Código NIT.
Este podría ser el identificado de la entidad
PK
Se recomienda el contemplar la
posibilidad de analizar éste campo como
el identificador de la entidad, teniendo en
cuenta que las compañías cuentan con
un identificador Único (NIT).
correo electrónico de la compañía aseguradora.
Definición del correo como un campo de
2000 byte
27 CONSULTAS
Tabla que almacena todas las segundas
instancias / consultas para todos los
expedientes. Las relaciones de la segunda
instancia / consulta con el expediente del PRF
están descritas en el siguiente punto.
ID_CONSULTA (NUMBER): Identificador de la
consulta. Es un valor numérico autogenerado.
FECHA (DATE): Fecha de la consulta.
del tipo de actuación. Está relacionado con el
identificador de la tabla de la entidad 116.
DESC_TIPO_ACTUACION (VARCHAR2 200 Problemas de Normalización, 2da Forma Esta descripción se debe realizar en la

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
BYTE): Nombre del tipo de actuación realizada
para la consulta. Está relacionado con la tabla
de la entidad 116.
Normal entidad TIPOS_ACTUACIONES, habría
que validar si las actuaciones definidas
en esa entidad son las misma que se
describen en esta entidad
auto correspondiente a la segunda instancia.
NUM_PROVIDENCIA (VARCHAR 200 BYTE) Estos atributos no se encuentran
esta entidad.
29 DECISIONES
Tabla que almacena todas las decisiones
realizadas sobre recursos interpuestos para
todos los expedientes. Las relaciones entre las
decisiones realizadas y los recursos
interpuestos están descritas en el siguiente
punto.
ID_DECISION (NUMBER): Identificador de la
decisión. Es un valor autogenerado.
auto.
FECHA (DATE): Fecha de la decisión.
del tipo de actuación. Está relacionado con el
Problemas de normalización en su
segunda forma normal, esta descripción ya
está definida en la entidad
TIPOS_ACTUACIONES
DESC_TIPO_ACTUACION (VARCHAR2 200
BYTE): Nombre del tipo de actuación realizada
para la decisión. Está relacionado con la tabla
de la entidad 117.
Problemas con la 2da Forma Normal, este
es un registro que se debe definir en una
entidad que administre Tipos de
Actuaciones.
Esta es una característica que ya se está
ingresando en la entidad
TIPOS_ACTUACIONES por medio del
atributo Actuacion.
FECHA_ULT_NOT (DATE): Fecha de la última
notificación.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
NUM_PROVIDENCIA (VARCHAR 200) Estos atributos no se encuentran
esta entidad.
37
DOCUMENTOS_ACTU
ACIONES
Tabla que almacena la relación entre el
identificador del auto de las actuaciones
(Audiencia de Descargos, Etapa de pruebas del
PRF Ordinario o Actuaciones Procesales)
(entidad 5) y el identificador del documento
(entidad 32).
En la base de datos que está funcionando
en la CGR el identificador o la llave
primaria de esta entidad es
ID_ACTUACION (NUMBER) y ID_DOC
(NUMBER)
Es recomendable que la CGR, haga una
solicitud del documento de la estructura
de datos actualizado por parte de
MNEMO y que además, éste sea
consistente con la información que
registra, ya que de ello depende la
correcta administración a futuro.
ID_AUTO (NUMBER): Identificador del auto.
No es un campo de esta entidad por ende
hace parte del identificador en esta
entidad.
ID_DOC (NUMBER): Identificador del
documento.
58 ENTIDADES
Tabla maestra que almacena todas las
entidades existentes para el proceso de la
aplicación SAE. Cada entidad queda asociada al
municipio que corresponde.
ID_ENTIDAD (NUMBER): Identificador de la
entidad. Es un valor numérico autogenerado.
ID_EXTERNO (VARCHAR2 20 BYTE):
Identificador externo de la entidad.
NOMBRE (VARCHAR2 4000 BYTE): Nombre
de la entidad.
DIRECCION (VARCHAR2 4000 BYTE):
Dirección de la entidad.
ACTIVO (NUMBER): Flag para indicar un activo
lógico.
 1 Activo.
 0 Desactivo.
El usuario puede ingresar un valor de
hasta 38 dígitos, perdiéndose de esta
forma la garantía sobre la información
almacenada.
Si el campo se está utilizando para el
registro de un indicador de 1 o 0, se debe
considerar como campo tipo CHAR y de
una longitud menor.
NIT (VARCHAR2 200 BYTE): Código NIT.
Se recomienda contemplar la posibilidad
de establecer éste atributo como el

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
identificador de la entidad, dado que el
NIT de las Entidades en Colombia es
Únicos e irrepetible.
ID_MUNICIPIO (NUMBER): Identificador del
municipio al que corresponde. Corresponde con
el identificador de la tabla de la entidad 84.
ID_ORDEN (NUMBER)
esta entidad.
la estructura.
70 EXPEDIENTES
Tabla maestra donde se guarda el identificador
de los dos tipos de expedientes que hay, junto
con un número que indica el próximo a utilizar y
el año. Se utiliza junto con un procedimiento
almacenado que posteriormente se explica
en la entidad 1 para construir el código de
expediente “TIPO-AÑO-NUMERO”.
Este procedimiento almacenado no se
encuentra documentado en el documento
Estructura de Bases de Datos PRF V4.0
entregado por MNEMO a la CGR.
Es recomendable que la CGR, solicite a
MNEMO la documentación de este
procedimiento.
TIPO (VARCHAR2 10 BYTE): Identificador del
tipo de expediente.
NUMERO (NUMBER): Número del próximo
expediente que se genere.
ANOEXP (NUMBER): Año actual. De esta
manera cada vez que cambia el año se resetea
la columna NUMERO a 1.
No es claro cómo se realiza esta tarea.
Este procedimiento almacenado no se
encuentra documentado en el documento
Estructura de Bases de Datos PRF V4.0
entregado por MNEMO a la CGR.
Es recomendable que la CGR, solicite a
MNEMO la documentación de este
procedimiento.
73 GARANTES
Tabla que almacena los datos de todos los
garantes existentes en la aplicación. Las tablas
de relación con el PRF Ordinario y Verbal se
muestran a continuación de esta.
ID_GARANTE (NUMBER): Identificador del
garante introducido.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
COMP_ASEGURADORA (VARCHAR2 200
BYTE): Nombre de la compañía aseguradora.
N_POLIZA_VIGENCIA (VARCHAR2 200
BYTE): Número de póliza – vigencia.
Numero de póliza y el tiempo de vigencia
son dos atributos diferentes
Se recomienda crear un atributo para el
número de la póliza y otro para la
vigencia, puesto que ningún atributo
dentro de una entidad debe depender
más que de la entidad misma.
FECHA_VINCULACION (DATE): Fecha de
vinculación.
FECHA_COMUNICACION (DATE): Fecha de
comunicación.
VALOR_AMPARADO (FLOAT): Valor
amparado.
TIMESTAMP (DATE): Fecha interna en el
momento del registro del garante.
ID_COMP (NUMBER): Identificador de la
compañía aseguradora seleccionado.
EMAIL_COMP_ASEGURADORA (VARCHAR
2000 BYTE)
Este campo no se encuentra definido
dentro de la documentación de la
estructura de datos entregado por MNEMO
a la CGR, pero si es un campo que se
encuentra dentro de la entidad que
aparecen en la estructura de base de
datos que funciona en la CGR.
modificaciones en la Base de datos
Revisar la pertinencia del campo para
realizar la actualización de la
documentación correspondiente o en su
defecto proceder con la eliminación del
campo de la estructura.
76 GRUPOS_FALLOS
Tabla que guarda la relación entre los grupos
intervinientes desde que se finaliza el fallo de
primera instancia, pasando por el grupo
intermedio, que decide un usuario del grupo de
segunda instancia para que sea el propietario de
ejecutar la segunda instancia del expediente. Estructura de datos sin identificador de
llave primaria.
Teniendo en cuenta el nombre de esta
entidad, se deduciría que es una entidad
de rompimiento entre las entidades
GRUPOS y FALLOS, pero como el
modelo no contempla la existencia de la
entidad GRUPOS, se puede concluye
que no lo es, por consiguiente su llave
privada no es compuesta una opción
sería Id_grupos_fallos (NUMERIC)”.
Se recomienda hacer las observaciones
correspondientes a MNEMO, teniendo en
ORIGEN (VARCHAR2 200 BYTE): Se almacena
el grupo que realiza la primera instancia.
INTERMEDIO (VARCHAR2 200 BYTE): Grupos
que deciden quién ejecuta la segunda instancia
del expediente.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
DESTINO (VARCHAR2 200 BYTE): Grupo que
se encarga de realizar la segunda instancia del
expediente.
cuenta que en la CGR se ha presentado
“Perdida de Documentos” cuando el
proceso pasa de primera a segunda
instancia.
Según aquí lo descrito, ésta es la entidad
que guarda la relación entre los grupos
intervinientes desde que se finaliza el
fallo de primera instancia, pasando por el
grupo intermedio, que decide un usuario
del grupo de segunda instancia para que
sea el propietario de ejecutar la segunda
instancia del expediente.
77 GRUPOS_ROL
Tabla que relaciona el nombre del grupo con su
DN existente en el LDAP.
Estructura de datos sin identificador de
llave primaria.
El identificador de esta entidad podría
ser ID_GRUPO_ROL.
GRUPO (VARCHAR2 200 BYTE): Nombre del
grupo.
ROL_DN (VARCHAR2 200 BYTE): DN existente
en el LDAP.
No es claro a que se hace referencia
cuando se habla del DN.
Es recomendable que la CGR solicite la
documentación de
PERMISOS_TRAMITACION (VARCHAR2 4000
BYTE): Grupos que tienen potestad para
tramitar los expedientes de algún propietario del
campo GRUPO.
TIPO_GRUPO (NUMERIC)
esta entidad.
la estructura.
82
MEDIDAS_CAUTELAR
ES
Tabla que almacena todas las medidas
cautelares creadas para todos los expedientes
generados del PRF. La relación de la medida
cautelar con el expediente en cuestión se
muestra en el siguiente punto.
ID_MEDIDA (NUMBER): Identificador de la
medida cautelar. Es un valor numérico

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
autogenerado.
FECHA_MEDIDA_DECRETADA (DATE): Fecha
de la medida decretada.
FECHA_MEDIDA_PRACTICADA (DATE):
Fecha de la medida practicada.
ID_TIPO_MEDIDA (NUMBER): Identificador del
tipo de medida. Está relacionado con el
DESC_MEDIDA (VARCHAR2 500 BYTE):
Nombre del tipo de medida seleccionado. Está
relacionado con la tabla de la entidad 120.
Problema de normalización: 2da Forma
Normal, este campo es un atributo que
pertenece a la entidad
TIPOS_MEDIDAS_CAUTELARES
Esta descripción se debería hacer en una
entidad llamada
TIPOS_MEDIDAS_CAUTELARES
CUANTIA_MEDIDA (FLOAT): Cuantía de la
medida.
FECHA_MEDIDA_REGISTRADA (DATE) Estos atributos no se encuentran
esta entidad.
NUM_PROVIDENCIA (VARCHAR 200)
84
MUNICIPIOS_DEPART
AMENTO
Tabla maestra que guarda los municipios que
intervienen en el proceso de la aplicación SAE y
la relación con su departamento. Se utiliza de
filtro en función del departamento elegido
(entidad 31) y para filtrar las entidades que se
pueden seleccionar (entidad 58).
ID_DEPARTAMENTO (NUMBER): Identificador
del departamento.
ID_MUNICIPIO (NUMBER): Identificador del
municipio.
De no haberse tenido en cuenta, se
podría contemplar el incluir los códigos
de Departamento y Municipio, que tienen
establecidos el Departamento

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
Administrativo Nacional de Estadísticas –
DANE.
DESC_MUNICIPIO (NUMBER): Nombre del
municipio.
Se pueden tener en cuenta los códigos y
nombres que el Departamento
Administrativo Nacional de Estadísticas
DANE tiene para los Departamentos y
Municipios.
ACTIVO (NUMERIC)
Este campo no se encuentra definidos
a la CGR, pero si es un campo que se
encuentra dentro de la entidad de la
estructura de base de datos que funciona
en la CGR.
modificaciones en la Base de datos
Revisar la pertinencia del campo para
realizar la actualización de la
defecto proceder con la eliminación del
campo de la estructura.
87
NOTIFICACIONES_ELE
CTRONICAS
Tabla que almacena todas las notificaciones
electrónicas creadas para todas las etapas en
las que existen notificaciones electrónicas.
ID_NOTIFICACION (NUMBER): Identificador de
la notificación. Es un número autogenerado.
FECHA_ENVIO (TIMESTAMP): Fecha en la que
se envía la notificación.
TIMESTAMP_IN (DATE): Fecha en la que se
registra en el sistema la notificación.
EXPEDIENTE (VARCHAR2 200 BYTE): Código
del expediente al que se asocia la notificación.
CUERPO (VARCHAR2 4000 BYTE): Cuerpo del
texto que se envía en la notificación.
LUGAR_NOTIFICACION (VARCHAR 200) Estos campos no se encuentran definidos
a la CGR, pero si son campos que se
encuentran dentro de la entidad de la
estructura de base de datos que funciona
actualmente en la CGR.
Estos campos no se encuentran
definidos dentro de la documentación de
la estructura de datos entregado por
MNEMO a la CGR, pero si es un campo
que se encuentra dentro de la entidad de
la estructura de base de datos que
funciona en la CGR.
NUM_PROCESO (VARCHAR 200)
FECHA_ENVIO_SUSTANCIADOR
(TIMESTAMP 6)
NOMBRE_SUSTANCIADOR (VARCHAR 4000) 1. Este dato se puede incorporar en ésta 1. Si esta información no está siendo

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
Entidad a partir del identificador del
sustanciador, lo ideal sería que fuera el
documento de identidad (Cédula).
2. Este campo no se encuentra definido
estructura de datos que MNEMO entrega a
la CGR.
3. No existe un documento de control de
inferida desde el Directorio Activo Es
recomendable la creación de una entidad
SUSTANCIADORES, para identificar al
sustanciador con el documento de
identidad, no con el nombre ya que ésta
es una característica propia de otra
entidad no de la entidad
NOTIFICACIONES_ELECTRONICAS.
2. Verificar la pertinencia de los campos
para realizar la actualización de la
defecto proceder con la eliminación de
los campos de la estructura.
GRUPO_SUSTANCIADOR (VARCHAR 4000
BYTE)
1. El sustanciador debe pertenecer a un
grupo, atributo que idealmente se debería
asignar al Sustanciador en la Entidad
SUSTANCIADORES si ésta se define
dentro del modelo de datos.
2. Este campo no se encuentra definido
estructura de datos que MNEMO entrega a
la CGR.
1. Si esta información no está siendo
inferida desde el Directorio Activo. Es
recomendable la creación de la entidad
GRUPO_SUSTANCIADORES, se
podrían definir aspectos como
id_grupo_sustanciador,
nombre_grupo_sustanciador, entre los
demás que se requieran para poder
desarrollar de la mejor manera el PRF.
2. Verificar la pertinencia de los campo
ID_TIPO_NOTIFICACION (NUMERIC) 1. Problema de normalización, por no
contemplarse la 2da Forma Normal.
2. Este campo no se encuentra definidos
estructura de datos.
1. Se deberían administrar estos tipos
desde otra entidad lo ideal sería la
creación de una entidad llamada
TIPO_NOTIFICACIONES, entidad
desde donde se pueden administrar el
Id_Tipo_Notificacion y el
Tipo_notificación.
2. Verificar la pertinencia de los campos
TIPO_NOTIFICACION (VARCHAR 200 BYTE)

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
ETAPA (VARCHAR 200 BYTE)
 Problema de Normalización, incurren en
la 2da Forma Normal, este registro deberá
ser una entidad aparte.
 Este campo no se encuentra
documentado dentro de la estructura
entregada por MNEMO a la CGR
 Sería recomendable la existencia de
una entidad llamada ETAPAS donde se
haga la clasificación y se asigne un
identificador para cada una de las
etapas definidas dentro del PRF.
 Realizar la actualización del documento
Estructura Base de Datos PRF V4.0
FECHA_ASIG_COMPETENTE (TIMESTAMP 6)
esta entidad.
la estructura.
91 RECURSOS
Tabla que almacena todos los recursos
interpuestos a los fallos para todos los
expedientes generados del PRF. La relación del
recurso interpuesto con el fallo se muestra en
los siguientes puntos.
ID_RECURSO (NUMBER): Identificador del
recurso. Es un valor numérico autogenerado.
FECHA (DATE): Fecha del recurso interpuesto.
ID_TIPO_RECURSO (NUMBER): Identificador
del tipo de recurso seleccionado. Está
relacionado con el identificador de la tabla de la
entidad 122.
DESC_TIPO_RECURSO (VARCHAR2 200
BYTE): Nombre del tipo de recurso
seleccionado. Está relacionado con la tabla de
la entidad 122.
Problemas con la 2da Forma Normal, este
es un registro que se debe definir en una
entidad que administre Tipos de Recursos.
Esta es una característica que se debe
ingresar desde la entidad
RIA_TIPOS_RECURSOS o en la entidad
TIPOS_RECURSOS, no en ésta entidad.
Ésta descripción no se encuentra dentro
de ninguna de la entidades

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
mencionadas.
auto del recurso interpuesto.
N_FALLO (VARCHAR2 200 BYTE): Número de
fallo asociado al recurso.
NUM_PROVIDENCIA (VARCHAR 200) Estos atributos no se encuentran
esta entidad.
92
RECURSOS_APE_FAL
LO
Tabla que relaciona el identificador del recurso
interpuesto (entidad 91) con el fallo (entidad 71).
En esta tabla únicamente se almacenan
aquellas relaciones correspondientes a los
recursos de apelación del PRF.
Son los mismos identificadores de la
entidad RECURSOS_REPO_FALLO, lo
que indica que más de una entidad esta
almacenando la misma información. La
clave de estas entidades es conformada
por los mismos campos de las entidades
RECURSOS y FALLOS
Es recomendable validar cuales son los
tipos de recursos existentes en la entidad
TIPOS_RECURSOS ya que estos dos
identificadores son los mismos de la
entidad RECURSOS_REPO_FALLO.
Sería importante realizar un análisis de
los datos que se están consignando en
ésta entidad.
ID_FALLO (NUMBER): Identificador del fallo.
recurso.
93
RECURSOS_REPO_FA
LLO
Tabla que relaciona el identificador del recurso
interpuesto (entidad 91) con el fallo (entidad 71).
En esta tabla únicamente se almacenan
aquellas relaciones correspondientes a los
recursos de reposición del PRF.
Son los mismos identificadores de la
entidad RECURSOS_APE_FALLO, lo que
indica que más de una entidad esta
RECURSOS y FALLOS
Es recomendable validar cuales son los
tipos de recursos existentes en la entidad
TIPOS_RECURSOS ya que estos dos
identificadores son los mismos de la
entidad RECURSOS_APE_FALLO
Sería importante realizar un análisis de
los datos que se están consignando en
ésta entidad.
ID_FALLO (NUMBER): Identificador del fallo.
recurso.
94 RESPONSABLES
Tabla que almacena todos los presuntos
responsables que intervienen para todos los
expedientes de todas las etapas (Auto de
Apertura de la Indagación Preliminar, Auto de
Cierre de la Indagación Preliminar y Auto de
Apertura del PRF Ordinario). Las relaciones con

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
cada etapa se muestran en los siguientes
puntos.
ID_PRESPONSABLE (NUMBER): Identificador
del presunto responsable. Es un valor numérico
autogenerado.
Si es un número autogenerado, cual es la
relación con la estructura
RESPONDSABLES.
Una mejor práctica sería el hacer uso del
número de identificación del
Responsable (NIT o Cédula), como
identificador de ésta estructura.
MOTIVO_IMPUTACION (VARCHAR2 4000
BYTE): Motivo de la imputación.
NOMBRE (VARCHAR2 200 BYTE): Nombre del
presunto responsable.
N_CEDULA (VARCHAR2 200 BYTE): Número
de cédula.
CARGO (VARCHAR2 200 BYTE): Cargo del
presunto responsable.
DIRECCION (VARCHAR2 200 BYTE): Dirección
del presunto responsable.
correo del presunto responsable.
RECIBIR_NOTIFICACIONES (NUMBER): Indica
si el presunto responsable da autorización a
recibir notificaciones en el sistema.
Está definido como un valor numérico,
dando la opción de ingresar por lo menos a
nivel de base de datos un valor compuesto
hasta por 38 dígitos.
Una mejor opción es definir éste campo
como un valor lógico 1-0, se pueden
presentar inconvenientes si se ingresan
valores diferentes al 1-0
95
RESPONSABLES_AAI
NDP_ANIP
Tabla que relaciona el identificador del
responsable (entidad 94) con el expediente al
que va asociado. Esta tabla está destinada a
guardar las relaciones para el auto de apertura
de la indagación preliminar para el expediente
de Antecedentes e Indagación Preliminar.
Son los mismos identificadores de las
entidades
RESPONSABLES_ACINDP_PRF,
RESPONSABLES_AAINDP_ANIP lo que
RESPONSABLES.
Se puede estar presentando la siguiente
situación, teniendo en cuenta que el
identificador de un RESPONSABLES no
es la cédula sino un valor autogenerado
Es recomendable validar como se hace
la validación de la información que debe
almacenarse esta entidad, ya que el
identificador es el mismo de las
entidades según la documentación
entregada por MNEMO.
RESPONSABLES_AAINDP_PRF,
RESPONSABLES_AAPRF,
RESPONSABLES_ACINDP_ANIP
RESPONSABLES_ACINDP_PRF.
ID_REQUEST (NUMBER): Identificador interno
del expediente.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
entonces la combinación de los registros
ID_REQUEST e ID_PRESPONSABLE,
nunca van a generar un error de
identificador, pero en términos de
información si se pueden presentar
inconsistencias.
96
RESPONSABLES_AAI
NDP_PRF
de la indagación preliminar para el expediente
de PRF.
entidades
RESPONSABLES
entidades, según la documentación
RESPONSABLES_AAPRF,
RESPONSABLES_AAINDP_ANIP ,
ID_REQUEST (NUMBER): Identificador
interno del expediente.
97
RESPONSABLES_AAP
RF
del PRF Ordinario para el expediente de PRF.
entidades
RESPONSABLES.
inconsistencias.
entidades, según documentación
RESPONSABLES_AAPRF,
RECIBIR_NOTIFICACIONES (NUMBER): Indica
si el presunto responsable da autorización a
recibir notificaciones en el expediente.
Está definido como un valor numérico,
dando la opción de ingresar por lo menos a
nivel de base de datos un valor compuesto
Una mejor opción es definir éste campo
como un valor lógico 1-0, se pueden
presentar inconvenientes si se ingresan

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
hasta por 38 dígitos. valores diferentes al 1-0
98
RESPONSABLES_ACI
NDP_ANIP
guardar las relaciones para el auto de cierre de
la indagación preliminar para el expediente de
Antecedentes e Indagación Preliminar.
entidades
RESPONSABLES.
inconsistencias.
RESPONSABLES_AAPRF,
99
RESPONSABLES_ACI
NDP_PRF
guardar las relaciones para el auto de cierre de
la indagación preliminar para el expediente de
PRF.
entidades
RESPONSABLES.
RESPONSABLES_AAPRF,
RESPONSABLES_ACINDP_ANIP.
ID_REQUEST (NUMBER): Identificador interno
del expediente.

Número
de la
Entidad
Entidad
los atributos
encontradas
Recomendación
inconsistencias.
100 RIA_DECISIONES
Decisiones que se realizan sobre recursos de
actuaciones realizadas, en las etapas de
Actuaciones Procesales, Autos de Pruebas,
Auto de imputación fiscal o Audiencia de
Descargos. La tabla de relación con los recursos
aparece seguidamente.
ID_DECISION (NUMBER): Identificador de la
decisión creada.
ID_TIPO_DECISION (NUMBER): Tipo de
decisión tomada.
DESC_TIPO_DECISION (VARCHAR2 200
BYTE): Descripción de la decisión tomada.
Problema de normalización con la 2da
forma normal
Ésta descripción debe ser la misma que
se ingresa en la entidad
RIA_TIPOS_DECISION, habría que
mirar si se trata de las mismas
Decisiones. De no ser así sería
recomendable la existencia de una
entidad TIPO_DECISIONES donde se
registre el identificador de éstas, el tipo
de decisión y la descripción de ésta.
auto de la decisión.
FECHA (DATE): Fecha en la que se toma la
decisión.
OBSERVACIONES (VARCHAR2 4000 BYTE):
Observaciones.
TIMESTAMP (DATE): Fecha interna de la
creación de la decisión.
102 RIA_RECURSOS
Tabla que almacena los recursos realizados
sobre actuaciones, en las etapas de
Actuaciones Procesales, Autos de Pruebas,
Auto de Imputación Fiscal o Audiencia de
Descargos. Las tablas de relación con las
diferentes etapas de actuaciones aparecen
seguidamente.
De tener consignada la misma
información en estas entidades
RECURSOS y RIA_RECURSOS
Es recomendable hacer uso de una sola
entidad.

DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE

DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE

Recomendados

Recomendados

Más contenido relacionado

Similar a DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE

Similar a DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE (20)

Más de cgroportunidadestrategica

Más de cgroportunidadestrategica (7)

Último

Último (16)

DOCUMENTO DE RECOMENDACIONES DE SOSTENIBILIDAD DEL SISTEMA DE ASEGURAMIENTO ELECTRÓNICO – SAE