IT2726

FACULTAD DE INGENIERA
ESCUELA DE INGENIERA VESPERTINA
IMPLEMENTACIN DE PROCESOS DE CONTROL INTERNO

EN GESTION INFORMTICA
ALVARO ESTEBAN JORDAN DIAZ

FABIOLA ANDREA SOTO GODOY
Profesor Gua: Ral Riquelme Rojas
MEMORIA PARA OPTAR AL TTULO DE INGENIERO EN INFORMTICA Y

GESTIN
SANTIAGO CHILE
NOVIEMBRE, 2009
RESUMEN EJECUTIVO
La presente memoria trata sobre la implementacin de procesos de control interno en

gestin informtica para el caso de una empresa (la cual, por peticin expresa de la
empresa, no ser revelada) de retail, la cual es analizada bajo las normas, directrices
y tpicos necesarios para la implementacin de estos controles atachado a los
procedimientos propios del rea informtica.
Es as como, en esta memoria, se presentan fundamentos para los sistemas de

control interno, del conjunto de medidas, polticas y procedimientos establecidos en
las empresas para proteger el activo, minimizar las posibilidades de fraude,
incrementar la eficiencia operativa y optimizar la calidad de la informacin y servicio
prestado por el rea en estudio. Se ha centrado en el terreno informtico
administrativo, teniendo nfasis en las actividades diarias y mnimas que tiene que
tener un rea informtica en su quehacer dentro de la sociedad en estudio.
Adems, se expresa el estado actual de la empresa en estudio, resultado de las

evaluaciones realizadas segn metodologas establecidas para la revisin por parte
de los estamentos del control interno, evidenciando esta, deficiencias en materia de
documentacin, actualizacin, formalizacin y difusin de polticas y normas, planes
y manuales, adems de estndares y acciones mnimas o de consideracin dentro
del rea informtica.
A raz de esto, se a han calificado y cuantificado los hallazgos surgidos del estudio,
se han establecido pautas y recomendaciones de accin para polticas y normas,
planes y manuales, procedimientos y temas a tener en cuenta que ayuden al
cumplimiento de las funciones y responsabilidades informticas del rea, en forma
interna y con su entorno, proporcionando un anlisis objetivo para mejorar el
funcionamiento no solo del rea informtica, si no que tambin da una mirada acerca
de la responsabilidad que el departamento tiene con las dems operaciones de la
empresa.
AGRADECIMIENTOS
Quiero agradecer a todos quienes de alguna u otra forma me alentaron a terminar

este proyecto. A mi familia por su constante apoyo y paciencia, a mis amigos,
compaeros de universidad, compaeros de trabajo dentro y fuera de la Universidad
y a los distintos profesores que me acompaaron en este camino.
Alvaro Jordan Daz
Agradezco a mi familia y amigos por el apoyo constante en este largo camino que
llega a su fin.
Fabiola Soto Godoy
DEDICATORIAS
Dedicada a mi padre, Ivn Jordan, que gracias a su ejemplo soy quien he logrado
ser.
Alvaro Jordan Daz
NDICE
INTRODUCCIN ........................................................................................................ 9
CAPITULO I .............................................................................................................. 12
ANTECEDENTES GENERALES .............................................................................. 12
1.1
1.2
1.3
OBJETIVO GENERAL ............................................................................................................................. 13

OBJETIVOS ESPECFICOS ...................................................................................................................... 13
METODOLOGA..................................................................................................................................... 14
CAPITULO II ............................................................................................................. 17
MARCO TERICO ................................................................................................... 17
2.1
2.1.1
2.1.2
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.2.7
2.2.8
2.3
2.3.1
2.3.2
2.4
2.5
2.5.1
2.5.2
2.6
TEORA GENERAL DE SISTEMAS ........................................................................................................... 17

Concepto de Sistema ....................................................................................................................... 21
Tipos de sistemas ............................................................................................................................ 23
SISTEMAS DE INFORMACIN PARA GESTIN ........................................................................................ 23
Tipos de sistemas de informacin ................................................................................................... 25
Aplicacin de los sistemas de informacin ..................................................................................... 26
Concepto de Sistemas de Informacin para Gestin ...................................................................... 27
Problemas del entorno socio-tcnico ............................................................................................. 28
Particularidades del recurso Informacin ..................................................................................... 30
Anlisis de los diferentes tipos de informacin a considerar ......................................................... 31
Problemas del entorno cultural ...................................................................................................... 34
Estructura del Sistema de Informacin para Gestin..................................................................... 36
AUDITORIA........................................................................................................................................... 36
Evolucin de la Auditoria ............................................................................................................... 36
Conceptualizacin de la auditoria.................................................................................................. 38
COBIT 4.0 Y EL CONTROL DE PROYECTOS TIC ................................................................................... 39
COBIT Y OTRAS NORMAS .................................................................................................................... 47
COBIT y ISO/IEC 17799:2005 ....................................................................................................... 47
COBIT y Sarbanes Oxley ................................................................................................................ 47
ASPECTOS LEGALES ............................................................................................................................. 48
CAPITULO III ............................................................................................................ 52

INTRODUCCIN A LA AUDITORA ........................................................................ 52
3.1
3.2
3.3
3.4
3.4.1
3.4.2
3.5
3.5.1
3.6
3.6.1
3.6.2
CONTROL INTERNO INFORMTICO ........................................................................................................ 52

AUDITORIA INFORMTICA.................................................................................................................... 53
CONTROL INTERNO Y AUDITORIA INFORMTICOS: CAMPOS ANLOGOS ............................................... 54
SISTEMA DE CONTROL INTERNO INFORMTICO ................................................................................... 55
Definicin y tipos de controles internos ......................................................................................... 55
Implantacin de un sistema de controles internos informticos ..................................................... 58
METODOLOGAS DE CONTROL INTERNO Y SEGURIDAD ......................................................................... 60
Introduccin a las metodologas .................................................................................................... 60
METODOLOGAS DE EVALUACIN DE SISTEMAS ................................................................................... 64
Conceptos fundamentales ............................................................................................................... 64
Tipos de metodologas .................................................................................................................... 65
3.6.2.1
Metodologas cuantitativas ..........................................................................................................................66
3.6.3
3.6.4
Metodologas cualitativas/subjetivas.............................................................................................. 67
Metodologas ms comunes ............................................................................................................ 69
3.6.4.1
Metodologas de anlisis de riesgos ............................................................................................................69
3.7
CONTROL INTERNO INFORMTICO. SUS MTODOS Y PROCEDIMIENTOS. LAS HERRAMIENTAS DE

CONTROL. ........................................................................................................................................................... 71
3.7.1
La funcin de control ...................................................................................................................... 71
3.7.2
Metodologas de clasificacin de la informacin y de obtencin de los procedimientos de control
.75
3.7.3
Las herramientas de control ........................................................................................................... 76
CAPITULO IV............................................................................................................ 78
PRESENTACIN DE LA EMPRESA ....................................................................... 78
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
PLATAFORMA OPERATIVA ................................................................................................................... 78

REAS DENTRO DE LA EMPRESA........................................................................................................... 80
DEPARTAMENTO INFORMTICA ........................................................................................................... 81
FUNCIONES DE TI ................................................................................................................................. 81
REAS Y CARGOS ................................................................................................................................ 82
ORGANIGRAMA TI ............................................................................................................................... 83
DETALLE DE CARGOS POR PERSONA .................................................................................................... 84
CAPITULO V............................................................................................................. 86
HERRAMIENTAS Y ANALISIS DEL ESTUDIO ....................................................... 86
5.1
METODOLOGA DE ESTUDIO ................................................................................................................. 86
5.2
ESTUDIO Y ANLISIS ............................................................................................................................ 88
5.2.1. Encuesta a usuarios ........................................................................................................................ 88
5.2.1.1.
5.2.1.2.
Identificacin del pblico objetivo ..............................................................................................................89

Recoleccin de datos ....................................................................................................................................89
5.3
RESULTADOS GENERALES. ................................................................................................................... 99
5.4
RESULTADOS DESTACADOS POR CATEGORAS .................................................................................... 100
5.5
CHECK LIST PARA LAS REVISIONES A LA EMPRESA. ........................................................................ 106
5.6
INFORME CON OBSERVACIONES DE CONTROL INTERNO Y RECOMENDACIONES DE MEJORA ................ 106
5.6.1. Informe detallado de Hallazgos y Recomendaciones segn el Caso ............................................ 110
CAPITULO VI.......................................................................................................... 131

OBSERVACIONES Y RECOMENDACIONES ....................................................... 131
6.1
NORMAS PARA DOCUMENTACIN ...................................................................................................... 131
6.1.1
Estructura de un sistema de documentacin ................................................................................ 131
6.1.2
Sistema de procedimientos ........................................................................................................... 133
6.1.3
Como documentar los procedimientos ......................................................................................... 133
6.1.4
Documentacin Tcnica ............................................................................................................... 136
6.1.5
Caractersticas de una buena documentacin .............................................................................. 137
6.2
GUA DE USUARIO .............................................................................................................................. 140
6.2.1
Identificacin y tabla de contenido............................................................................................... 141
6.2.2
Contenido del manual ................................................................................................................... 142
6.3
MANUAL DE PROCEDIMIENTOS .......................................................................................................... 146
6.3.1
Contenido del Manual de Procedimientos .................................................................................... 147
6.4
PLAN DE CONTINGENCIAS .................................................................................................................. 149
6.4.1
Objetivos ....................................................................................................................................... 150
6.4.2
Fases de la Metodologa para el Desarrollo de un Plan de Contingencia de los Sistemas de
Informacin................................................................................................................................................. 150
6.5
QUE ES LA SEGURIDAD? ................................................................................................................... 151
6.5.1
Qu queremos proteger? ............................................................................................................ 152
6.5.2
De que nos protegemos?............................................................................................................. 153
6.6
MONITOREO ....................................................................................................................................... 154
6.6.1
Procesos ....................................................................................................................................... 155
CONCLUSIN ........................................................................................................ 161

REFERENCIAS BIBLIOGRFICAS ....................................................................... 164
ANEXOS ................................................................................................................. 166
NDICE DE FIGURAS
Figura 2.1: Energa de Retorno (retroalimentacin) .................................................. 23

Figura 2.2: Componentes de un sistema de informacin para la gestin .................. 28
Figura 2.3: Sistemas de informacin para gestin soportados por la base de datos 29
Figura 2.4: El recurso informacin: disparidad de caractersticas segn el destino de
la informacin. ........................................................................................................... 32
Figura 2.5: El recurso informacin: disparidad de caractersticas segn el tipo de
problema. .................................................................................................................. 33
Figura 2.6: El problema del desarrollo de proyectos informticos, basado en un
informe del Government Accounting Office de los EE.UU......................................... 35
Figura 3.1: Pirmide de accin para el control interno y la seguridad. ...................... 62
Figura 3.2: Esquema bsico de una metodologa de anlisis de riesgos .................. 69
Figura 4.1: Organigrama del rea informtica de la empresa en estudio ................. 83
NDICE DE TABLAS
Tabla 3.1: Similitudes y diferencias entre control interno y auditoria informtica. ..... 55
Tabla 3.2: Pros y contras de las metodologas cuantitativas y cualitativas. .............. 68
Tabla 5.1: Total de personas de la empresa ............................................................. 99
Tabla 5.2: Totales Encuesta empresa ....................................................................... 99
Tabla 5.3: Totales y subtotales encuesta ................................................................ 100
Tabla 5.4: Resumen de frecuencia de mantencin de equipos ............................... 104
Tabla 5.5: Resumen de Vas de comunicacin con el rea informtica .................. 105
Tabla 5.6: Resumen de hallazgos y riesgos encontrados en la Empresa ............... 109
Tabla 6.1: Tabla resumen de porcentajes de los manuales .................................... 156
Tabla 6.2: Tabla Resumen de servidores para plan de contingencia. ..................... 158
NDICE DE GRFICOS
Grfico 5.1: Resultado de la encuesta para los procedimientos generales para las
reas de la empresa. ............................................................................................... 101
Grfico 5.2: Resultado de la encuesta para la comunicacin de las principales
actividades de las reas de la empresa. ................................................................. 101
Grfico 5.3: Resultado de la encuesta para las polticas del uso de los recursos
informticos. ............................................................................................................ 102
Grfico 5.4: Resultado de la encuesta para la existencia de algn manual de uso de
la plataforma ERP. .................................................................................................. 103
Grfico 5.5: Resultado de la encuesta para la calificacin de la plataforma
informtica. .............................................................................................................. 103
Grfico 5.6: Resultado de la encuesta para la forma de atencin del rea soporte
informtico. .............................................................................................................. 104
INTRODUCCIN
El control interno es una funcin que tiene por objeto salvaguardar y preservar los
bienes de la empresa, evita desembolso indebido de fondos y ofrece la seguridad de
que no se contraigan obligaciones sin autorizacin.
Sin duda, el cambio de los enfoques que las empresas han tenido durante los ltimos
decenios ha sido importante y constante. Si en un principio, las empresas fijaban sus
bienes principales en lo material, hoy en da es la informacin la cual toma la mayor
preponderancia como activo principal de las organizaciones a cualquier nivel,
llegando incluso a tomar un mayor valor que la misma infraestructura de estas.
Estamos envueltos en un mundo en que la informacin es constantemente transada

por todos los niveles de una organizacin, en sus ciclos cotidianos del rubro en el
que est inserta, en las transacciones entre empresas, en las decisiones futuras de
negocio, en los riesgos y aciertos para decisiones que deben ser tomadas en
minutos por personas que pueden o no estar fsicamente en las dependencias de la
organizacin. Somos actores de un mundo en que la informacin est presente en
todos lados, que se actualiza a cada momento y que est disponible a travs de
muchos medios, incluso en nuestros telfonos celulares.
Es as como el manejo de la informacin por parte de las empresas es crucial, no

solo para resguardar sus bienes y transacciones, sino que para poder comprender
mejor el mundo que rodea a la organizacin, la cual se comunica e interacta con su
entorno. Los sistemas de informacin asociadas a las TI son quienes estn
encargados de mantener con vitalidad y dinamismo esta informacin, nutriendo a la
empresa y todos sus actores de un producto actualizado, comn para todos y
preponderante a la hora de guiar los pasos de la empresa hacia nuevos objetivos y
metas.
Pero todo este ir y venir de informacin debe estar regido por ciertos patrones que
ordenen y regulen los flujos de datos que se manejan a diario, as como tambin los
medios por los cuales fluye este bien inmaterial, los procedimientos, normas y
polticas que lo rodean, para que as, esta sea consistente, veraz y siempre
disponible para las personas de la sociedad. Es as como existen estamentos
encargados de la supervisin, regulacin y optimizacin de los procesos que
interactan en este proceso. Hablamos pues de la auditoria, entendido en su
concepcin global y del control interno, dos conceptos similares pero distintos.
El Instituto de Auditores Internos de los Estados Unidos define la auditoria interna

como una actividad independiente que tiene lugar dentro de la empresa y que est
encaminada a la revisin de operaciones contables y de otra naturaleza, con la
finalidad de prestar un servicio a la direccin.
La direccin de la organizacin tiene la responsabilidad de decidir el alcance

adecuado del sistema de control interno. La naturaleza de los controles depende de
la clase de grado de control, distribucin geogrfica y estructura de la organizacin,
entre los factores ms importantes.
El control interno tiene limitaciones, puesto que no garantiza, por si mismo, una
administracin eficiente y tampoco puede evitar el fraude, cuando se da la
complicidad entre los cargos de confianza. Los objetivos de salvaguarda de los
activos, integridad de los datos, efectividad del sistema y eficiencia del sistema solo
se pueden conseguir si la direccin de una organizacin establece un sistema de
control interno. Tradicionalmente, los principales componentes de un sistema de
control interno han incluido:
La segregacin de funciones
La delegacin de la responsabilidad y de la autoridad
Existencia de personal competente y de confianza
El sistema de autorizaciones
10
Documentacin y registros adecuados
El control fsico sobre activos y registros
La adecuada supervisin de la gestin
La verificacin independiente de las operaciones
Es as pues, que la carencia de control en las actividades que se realizan en el rea

de informtica de la empresa bajo estudio, motiva a quienes realizan esta memoria a
poner mayor atencin en este tema.
Se presentar la situacin actual del rea de informtica de una determinada

empresa, donde se enfocar principalmente en las posibles deficiencias en el uso de
manuales de procedimientos, manuales de uso, documentacin y/o registros,
seguridad de informacin y planes de contingencia.
Para determinar las deficiencias ms significativas dentro del rea, se realiz un

estudio basado en:
Encuestas a personal de rea Informtica: se les pregunt sobre los registros

que llevan, la documentacin, los servicios que prestan, entre otros.
Encuestas a personal de otras reas: se les pregunt sobre los servicios que
reciben del rea de informtica, sobre el sistema que utilizan, entre otros.
Check-list: lista de ciertos temas que, segn los alumnos de esta tesis,
deberan tener bien desarrollados.
En base a los resultados obtenidos en el estudio, se realiz una serie de propuestas

referente a los temas ya mencionados.
11
CAPITULO I
ANTECEDENTES GENERALES
Al compartir las experiencias laborales de quienes realizan esta memoria se encontr

que en las empresas en las se ha estado, haba una gran deficiencia en comn en el
rea de TI, el control interno.
Falta de actualizacin y conocimiento de los procedimientos propios, falta de

documentacin, el no cumplimiento de procedimientos, polticas y/o normativas, entre
otros. Es por esto, que este trabajo propone desarrollar una gua de posibles
soluciones para que las empresas puedan regular estos temas.
Porque establecer pautas de estndares ya existentes? Simple. Estas pautas no se

logran de un da para otro. Son el fruto de estudios y anlisis del da a da, son el
esfuerzo, el ensayo y error de mtodos y esfuerzos de hacer bien las cosas dentro
de empresas y sociedades. Y es necesario contar con mtodos generales, pautas y
polticas de trabajo que permitan llegar a una estandarizacin de procesos y obtener,
no solo un departamento de informtica ms estable y funcional, si no que demostrar
que en base a un buen trabajo metodolgico de buenas practicas se pueden
optimizar recursos, tanto en tiempo como recursos monetarios, cambiando la forma
de trabajar dentro de un departamento de TI.
Adems, quienes desarrollan esta memoria se han visto envueltos en auditorias

externas hacia los departamentos informticos, abarcando desde el trato de los datos
dentro de la organizacin, los cambios realizados en SW y HW, la documentacin de
procesos, etc. descubriendo as las carencias que ha tenido la forma de trabajar del
informtico. Cmo cambiar este tpico? Cmo estar a resguardo de que los
cambios y actividades realizados se respaldaran como departamento informtico
ante auditorias o reclamos de usuarios? Hay que implantar la sana costumbre de
llevar controles y documentar lo que se hace, pero, como se logra esto? Hay que
ser metdico.
12
1.1
Objetivo General
El objetivo principal de esta memoria es proponer un marco de referencia que refleje

las buenas prcticas de control interno para el rea de TI de la empresa en estudio,
con el fin de mejorar los resultados en futuras auditorias. Para esto, es necesario
mejorar procedimientos, metodologas de trabajo, ensear a documentar todo, etc.
Verificando el cumplimiento de estos trminos en forma cuantitativa y cualitativa.
1.2
Objetivos Especficos
La consecucin del objetivo general del proyecto se desglosa en objetivos

especficos necesarios para lograr un ptimo funcionamiento del departamento
informtico. Estos objetivos son:
Determinar el estado actual del rea de TI en estudio: Se debe presentar

un estado actual de la problemtica de la empresa en estudio, cuantificando y
calificando (nivel de riesgo y continuidad de negocio) los procesos naturales
de esta.
Mejorar la elaboracin de procedimientos. Se aconseja y orienta sobre lo

que se debe incluir y como difundirlo en la organizacin. Dentro de este punto
se tratan lo siguiente:
o Mejoramiento de los planes de contingencia. Elaboracin de planes
de respuesta a riesgos y problemas, generales o puntuales. Qu se
incluye y qu no debe ir.
o Definicin responsabilidades.
o Definicin de pautas de seguridad de informacin.
13
Elaborar pautas para manuales de uso: Se definen aspectos bsicos de lo

que debera llevar un manual de uso a nivel tanto de usuario como de
operador.
Definir pautas para la creacin de polticas y normativas. Cmo crear una

poltica dentro
del
departamento de
informtica, como reportarla
estandarizarla. Como llevar un control sobre el nivel de cumplimiento de las

distintas polticas impulsadas y su nivel de xito.
o Niveles de cumplimiento (porcentual)
o Niveles de aceptacin (porcentual)
Fomentar cultura sobre la documentacin. Tratar de ensear que es lo que

se debe documentar y como. Se pretende establecer un sistema de medicin
sobre el nivel de cumplimiento de este tema.
Establecer metodologas de trabajo: Como conseguir los objetivos

planteados. Metodologas de trabajo grupal e individual para poder mantener
control sobre los procesos del departamento informtico y como poder auditar
internamente estos procedimientos y responsabilidades.
1.3
Metodologa
Etapa de Organizacin: En esta etapa se organiza y conforma el grupo de proyecto,

as como tambin se establece el tema a tratar, el alcance que esta memoria tendr,
los objetivos, la metodologa de trabajo y el alcance que tendr.
Etapa de Introduccin y marco terico de Investigacin: Esta etapa recopila

informacin acerca de la empresa en estudio, as como tambin conocimientos
bsicos de ciertos temas para poder abordar de mejor manera la problemtica a
solucionar. Se investigarn los siguientes temas:
14
Informacin de la empresa
Manuales de uso, procedimientos y contingencias.
Auditoria de sistemas.
Con el fin de desarrollar de forma ptima los temas anteriormente mencionados se

necesitar tener claro los siguientes conceptos:
Optimizacin de procesos.
Estructura de polticas empresariales.
Buenas prcticas. (Metodologas y teoras).
Administracin de RRHH.
Seguridad de la informacin.
Aspectos legales de auditoria y manejo de informacin.
Resultado de la etapa: al terminar esta etapa se espera contar con una base
conceptual slida, para dar inicio a la prxima etapa.
Etapa de Desarrollo: Esta etapa consta de tres partes:

1. Anlisis de caso: En esta etapa se analiza el caso de la empresa, detectando
las distintas problemticas existentes con respecto a los puntos a investigar en
este trabajo. Se busca lo siguiente:
Analizar la empresa enfocndose al rea informtica. Estructura y

metodologa de trabajo existente.
Clasificacin y cuantificacin de problemas detectados.
Evaluacin final de la empresa.
2. Propuestas metodolgicas: En esta etapa se desarrollarn los objetivos que

se pretende abordar en este trabajo, teniendo en cuenta las deficiencias del
caso.
15
3. Implementacin de propuestas metodolgicas: Una vez analizado el caso

y teniendo definidas las pautas metodolgicas se determinarn mtodos de
implementacin de las soluciones propuestas al caso.
Resultado de la etapa de desarrollo: Al terminar la etapa de desarrollo se debe

contar con un anlisis y entendimiento acabado del caso de uso, as como tambin
con una base de conocimiento metodolgico de las propuestas de solucin que
permitan dar una respuesta a los problemas con que cuenta la empresa estudiada.
Etapa de Evaluacin y Conclusin: Esta etapa tiene como fundamento evaluar la

informacin presentada en el proyecto, la implementacin y solucin propuesta, as
como tambin la estructura general del proyecto y su presentacin.
16
CAPITULO II
MARCO TERICO
La informacin ocupa cada vez ms un lugar preponderante en la escala de valores

empresariales, sobre todo, a medida que crece la empresa y se dividen y
especializan sus funciones, la coordinacin necesaria slo puede alcanzarse con un
buen sistema de informacin.
Se entiende por informacin al conjunto de datos que sirven para tomar una decisin.
En consecuencia, su necesidad es evidente tanto en la planificacin estratgica a
largo plazo como en la fijacin de estndares para la planificacin a corto. La
informacin tambin es necesaria para el estudio de las desviaciones y de los
efectos de las acciones correctoras; es un componente vital para el Control.
Finalmente, la incorporacin de la informtica en la empresa, al igual que en los

dems aspectos de la sociedad, va a introducir un enfoque nuevo del tratamiento de
los datos que cambiar en alto grado las funciones que actualmente existen en las
empresas.
En base a lo anterior y con el fin de poder explicar mejor los temas a tratar, este
capitulo brindar una base terica y conceptual de: Teora General de Sistemas,
Sistemas de Informacin para la gestin, Auditoria y aspectos legales de los delitos
informticos.
2.1
Teora General de Sistemas
La Teora General de Sistemas lleva la atencin al carcter dinmico y a la

naturaleza interrelacionada de las empresas, su gestin y su entorno.
La Teora General de Sistemas ofrece una solucin cuando se contempla la empresa

como formando un todo unitario y en una eficaz relacin con el entorno econmicosocial dentro del cual desarrolla su actividad. Las empresas son sistemas abiertos
17
que reciben entradas (flujos de materias y energa, trabajo, capital, informacin, etc.),
las transforman (operaciones que aaden valor o utilidad), y generan unas salidas
(bienes y servicios, progreso de la empresa y su personal, satisfaccin, beneficios
sociales, etc.).
La Teora General de Sistemas
entonces, nos proporcionar los conceptos y
mtodos que constituirn un marco de referencia fructfero para el estudio de las

organizaciones y facilitarn la integracin del conocimiento fragmentario que existe
sobre ellas.
La importancia que este enfoque interdisciplinario tendr para la Organizacin de

Empresas es indudable, pero en el rea de los sistemas de informacin para gestin,
es ya un enfoque imprescindible para un desarrollo eficaz.
La Teora General de Sistemas describe un nivel de construccin de modelos que

abarca la necesidad de un cuerpo sistemtico de construcciones tericas que pueda
discutir, analizar y explicar las relaciones generales del mundo emprico y
administrativo. Segn Boulding1 ese es el destino de la Teora General de Sistemas.
Por supuesto que no se busca establecer una teora general de prcticamente

cualquier cosa, nica y total, que reemplace todas las teoras especiales de cada
disciplina en particular.
Los objetivos de la Teora General de Sistemas pueden ser fijados a diferentes

grados de ambicin y de confianza. A un nivel de ambicin bajo pero con un alto
grado de confianza, su propsito es describir las similitudes en las construcciones
tericas de las diferentes disciplinas, cuando stas existen, y desarrollar modelos
tericos que tengan aplicacin al menos en dos campos diferentes de estudio. A un
nivel ms alto de ambicin, pero, quizs, con un grado de confianza menor, espera
K. Boulding. General Systems Theory the Skeleton of Sciencie, Management Sciencie 2, (1956),
197-208.
18
desarrollar algo parecido a un espectro de teoras, un sistema de sistemas que

pueda llevar a cabo la funcin de un gestalt2 en las construcciones tericas. Este
espectro o gestalt ha tenido gran valor en campos especficos del conocimiento
humano, al dirigir las investigaciones hacia los vacos que ellos revelan. Por ejemplo,
tenemos el caso de la tabla peridica de elementos en qumica. Durante muchas
dcadas dirigieron la investigacin hacia el descubrimiento de elementos
desconocidos para llenar los vacos de la tabla, hasta que stos fueron
completamente llenados.
Sistemas: El concepto de sistemas ha sido utilizado por dos lneas de

pensamiento diferentes. La primera es la teora de sistemas generales,
corriente iniciada por von Bertalanffy y continuada por Boulding3 y otros. El
esfuerzo central de este movimiento es llegar a la integracin de las ciencias.
El segundo movimiento es bastante ms prctico y se conoce con el nombre
de ingeniera de sistemas o ciencias de sistemas iniciada por la
Investigacin de Operaciones, seguida por la administracin cientfica y
finalmente por el Anlisis de Sistemas.
En general, podemos sealar que, ante la palabra sistemas, todos los que la han
definido estn de acuerdo en que es un conjunto de partes coordinadas y en
interaccin para alcanzar un conjunto de objetivos.
La Teora General de Sistemas trata de ver el conjunto antes que las partes, sus
interrelaciones antes que el anlisis de cada elemento y trata de reconocer los
objetivos del sistema. Se estudian los sistemas en su interaccin con el medio, sobre
la base de un comportamiento aleatorio cuando el sistema no es predecible.
Gestalt: (palabra alemana que significa, aproximadamente configuracin). Es la experiencia

perceptiva normal en la cual la totalidad es vista o comprendida como algo ms que la simple suma de sus
partesEl ejemplo clsico es un dibujo que puede ser percibido ya sea como florero o como dos caras humanas.
J.A. Brussel y G.L. Cantzlaar: Diccionario de Psiquiatra (Mxico, CECSA Ed. 1972) p. 128.
3
Este es el enfoque que se ha querido desarrollar al hablar de la Teora General de Sistemas.
19
La forma de abordar estos sistemas ser observando sus entradas y salidas para
determinar qu estmulos en las variables de entrada producen cambios en las
variables de salida. Se sugiere que de esta manera sera posible construir un modelo
matemtico del sistema con el fin de predecir, en trminos probabilstico, su
comportamiento.
Para el caso de este trabajo, se requieren ciertas definiciones que describen algunos
comportamientos en sistemas, sobre todos aquellos desarrollados por el hombre.
Homestasis: Un sistema homeosttico es aquel que no cambia en el tiempo,

pero en el cual cambian sus componentes y el ambiente donde se encuentra.
En otras palabras, es un sistema esttico con componentes y entornos
dinmicos, que mantiene su estado constante en un entorno cambiante a
travs de ajustes internos, aplicable a reas de trabajo estticas que no se
adaptan a los cambios del entorno laboral.
Autorregulacin: Se refiere a las tareas de ajuste que realizan algunos

elementos del sistema para mantener constante su estado interno.
Normalmente corresponde, en la naturaleza, a un punto de equilibrio abstracto
al cual se tiende pero nunca se llega y, en sistemas construidos por el
hombre, hay dispositivos que estn en permanente funcionamiento para lograr
el equilibrio deseado y otros que mantienen el estado de un sistema entre
ciertos lmites. En el caso de estudio, el propio sistema realiza las
correcciones necesarias para mantenerse en el estado deseado, de acuerdo
con la variacin de elementos externos.
Retroalimentacin: Puede ser de dos tipos, negativa o positiva. Es negativa,

cuando los mecanismos de ajuste interno actan en forma inversamente
proporcional al estmulo externo. Es positiva, cuando los mecanismos de
ajuste interno actan en forma directamente proporcional al estmulo externo.
20
Recursividad: Se refiere a sistemas viables, capaces de adaptarse y

sobrevivir, los cuales contienen otros sistemas viables y a su vez estn
contenidos en un sistema viable superior.
Sinergia: Este concepto dice que el todo es diferente a la suma de sus partes.
Entropa: Los sistemas viables son capaces de adaptarse y sobrevivir. Podra

agregarse que importan del medio lo necesario para sobrevivir y exportan una
cantidad de energa un poco menor que la importada porque, en el proceso de
transformacin desde entrada a salida, parte de la energa se ocup en la
organizacin del sistema, en mantener unidas sus partes. Esto lo medira la
entropa, que en fsica es una medida de desorganizacin correspondiente a
la incesante prdida de energa al interior del sistema.
2.1.1 Concepto de Sistema

Un sistema es4:
a. Un conjunto de elementos (que son partes u rganos componentes del
sistema), esto es, los subsistemas;
b. Los elementos se interrelacionan de manera dinmica (esto es, interaccin e
interdependencia) y forman una red de comunicacin y relaciones, en funcin
de la dependencia recproca entre ellos;
c. Desarrollan una actividad o funcin (que es la operacin, actividad o proceso
del sistema);
d. Para lograr uno o ms objetivos o propsitos (que constituyen la finalidad para
la que fue creado el sistema).
En funcin de estas cuatros caractersticas, el sistema es un todo organizado con

lgica. Este aspecto de totalidad e integridad es el fundamento del sistema. Cuando
se habla de naturaleza sistmica, sta se refiere al funcionamiento global, total e
4
Adalberto Chiavenato, Teoria peral da administraao, Vol. 2. Sao Paulo, Makron Books, p.382
21
integrado en que el todo es mayor (o diferente) que la suma de sus partes. Para
funcionar, el sistema requiere los siguientes parmetros:
Entradas o insumos (inputs): todo sistema recibe o importa del ambiente

externo insumos necesarios para funcionar. Los insumos pueden ser recursos,
energa o informacin.
Operacin o procesamiento: todo sistema procesa o convierte sus entradas a

travs de sus subsistemas. Cada tipo de entrada se procesa en los
subsistemas especficos, es decir, especializados en procesarlos.
Salidas o resultados (outputs): todo sistema coloca en el ambiente externo las

salidas o resultados de sus operaciones o procesamiento. Las entradas se
procesan debidamente, se convierten en resultados y luego se exportan hacia
el ambiente. Las salidas, productos o servicios prestados, energa o
informacin, son consecuencias de las operaciones o procesos realizados por
los diversos subsistemas en conjunto.
Retroaccin o retroalimentacin (feedback): retorno o entrada de nuevo al

sistema de parte de sus salidas o resultados, que influyen en su
funcionamiento. La retroalimentacin es informacin o energa de retorno que
vuelve al sistema para retroalimentarlo o modificar su funcionamiento, en
trminos de resultados o salidas. La retroalimentacin es un mecanismo
censor que permite al sistema orientarse frente al ambiente externo y detectar
los desvos que deben corregirse para alcanzar los objetivos.
22
Operacin o
Procesamiento
Entradas
Salidas
Retroalimentacin
Figura 2.1: Energa de Retorno (retroalimentacin)
Fuente: Elaboracin propia
2.1.2 Tipos de sistemas
Los sistemas pueden ser cerrados o abiertos, dependiendo de dos circunstancias:
a. Permeabilidad o apertura de sus fronteras o lmites. Cuanto mayor sea la

permeabilidad, mayor es el intercambio entre el sistema y el ambiente que lo
rodea externamente. El sistema es cerrado cuando tiene muy pocas entradas
o salidas frente al ambiente, y es abierto cuando tiene muchas entradas y
salidas frente al ambiente.
b. Adems de esto, los sistemas cerrados nunca existe un sistema

completamente cerrado o hermtico- son aquellos en los que las entradas o
salidas son limitadas y pueden preverse perfectamente, pues guardan entre s
una relacin de causa y efecto que puede conocerse.
2.2
Sistemas de Informacin para Gestin
Los sistemas de informacin para la gestin (SIG) constituyen un campo de

conocimientos reciente en el contexto de la direccin general de la empresa.
23
Un sistema de informacin es un conjunto organizado de elementos, los cuales

formarn parte de alguna de las siguientes categoras:
Personas.
Datos.
Actividades o tcnicas de trabajo.
Recursos materiales en general (tpicamente recursos informticos y de

comunicacin, aunque no tienen por qu ser de este tipo obligatoriamente).
Todo ese conjunto de elementos interactan entre si para procesar los datos y la
informacin (incluyendo procesos manuales y automticos) y distribuirla de la
manera ms adecuada posible en una determinada organizacin en funcin de sus
objetivos.
Normalmente el trmino es usado de manera errnea como sinnimo de sistema de

informacin informtico, estos son el campo de estudio de la tecnologa de la
informacin (IT), y aunque puedan formar parte de un sistema de informacin (como
recurso material), por s solos no se pueden considerar como sistemas de
informacin, este concepto es ms amplio que el de sistema de informacin
informtico. Por lo tanto, un sistema de informacin es todo aquel sistema que
permite tener a disposicin informacin que se necesite.
Algunas razones sobre el por qu se debe tener en cuenta el estudio y anlisis de los
Sistemas de Informacin para Gestin dentro de la empresa son:
Fuente de empleo: "El 90% de los puestos de trabajo creados desde 1970
pertenece a informacin/ educacin/ servicios; slo el 5% corresponde a
fabricacin.
La Unin Europea la ha sealado como una de las reas prioritarias de

investigacin y desarrollo (educacional y empresarial).
24
La Tecnologa de Informacin (TI) es una fuerza econmica y social de los 90,

al igual que calidad lo fue en los 80, finanzas en los 70, mercados en los 60, y
produccin en los 50.
Los Sistemas de Informacin forman un componente de la empresa del que

dependen todos los dems, y especialmente los procesos de planificacin,
control, toma de decisiones y operaciones. Si la informacin de partida falla,
no es de esperar mejor fortuna en las decisiones de ella derivadas.
La inclusin de la Tecnologa de Informacin (TI) en los planes estratgicos de

muchas empresas estn convirtiendo a este departamento en un subsistema
clave dentro de las polticas competitivas.
Para poder aplicar plenamente las TIs es necesario comprender algunas ideas
bsicas, expuestas en los apartados siguientes.
2.2.1 Tipos de sistemas de informacin
Segn la funcin a la que vayan destinados o el tipo de usuario final del mismo, los
SI pueden clasificarse en: (esta clasificacin obedece a un punto de vista
empresarial)
Sistema de procesamiento de transacciones (TPS).- Gestiona la informacin

referente a las transacciones producidas en una empresa u organizacin.
(internas o externas)
Sistemas de informacin gerencial.- Orientados a solucionar problemas

empresariales en general.
25
Sistemas de soporte a decisiones.- Herramienta para realizar el anlisis de las

diferentes variables de negocio con la finalidad de apoyar el proceso de toma
de decisiones.
Sistemas de informacin ejecutiva.- Herramienta orientada a usuarios de nivel

gerencial, que permite monitorizar el estado de las variables de un rea o
unidad de la empresa a partir de informacin interna y externa a la misma.
Sistemas y aplicaciones destinadas a ayudar al trabajo diario del

administrativo de una empresa u organizacin.
Sistema Planificacin de Recursos (ERP).- Integran la informacin y los

procesos de una organizacin en un solo sistema.
Segn el entorno de aplicacin
Entorno transaccional: Una transaccin es un suceso o evento que

crea/modifica los datos. El procesamiento de transacciones consiste en
captar, manipular y almacenar los datos, y tambin, en la preparacin de
documentos; en el entorno transaccional, por tanto, lo importante es qu datos
se modifican y cmo, una vez ha terminado la transaccin.
Entorno decisional: En una empresa, las decisiones se toman a todos los

niveles y en todas las reas, por lo que todos los SI de la organizacin deben
estar preparados para asistir en esta tarea.
2.2.2 Aplicacin de los sistemas de informacin
Los sistemas de informacin tratan el desarrollo, uso y administracin de la

infraestructura de la tecnologa de la informacin en una organizacin.
26
El mayor de los activos de una compaa hoy en da es su informacin, representada

en su personal, experiencia, conocimiento, innovaciones (patentes, derechos de
autor, secreto comercial). Para poder competir, las organizaciones deben poseer una
fuerte infraestructura de informacin, en cuyo corazn se sita la infraestructura de la
tecnologa de informacin. De tal manera que el sistema de informacin se centre en
estudiar las formas para mejorar el uso de la tecnologa que soporta el flujo de
informacin dentro de la organizacin, detectando errores e incentivando polticas y
normativas apuntadas a la deteccin temprana de errores y a la mejora continua de
los sistemas.
2.2.3 Concepto de Sistemas de Informacin para Gestin
El concepto del Sistema de Informacin para Gestin no ha cambiado mucho en las

dos ltimas dcadas.
Fundamentalmente consiste en un sistema integrado usuario-mquina que

desempea cuatro funciones principales:
registrar las transacciones u operaciones diarias de la empresa,
aportar informacin para planificacin y control,
ayudar a la toma de decisiones, y
tomar decisiones previamente programadas.
La primera funcin es la ms extendida, de tal manera que se estima que el 95% de

todas las aplicaciones actuales de los computadores se incluyen en esta categora.
27
Figura 2.2: Componentes de un sistema de informacin para la gestin

Fuente: apuntes de auditoria informtica de Fco. Javier Navarra Garca
Los sistemas de ayuda a la toma de decisiones constituyen la tercera va a

considerar. Consisten en una interaccin directa hombre/mquina, tpicamente a
travs de lenguajes de interrogacin a una Base de Datos (BD) o a una Base de
modelos (BM). Esta ltima permite analizar los datos de diversas formas
(optimizacin, simulacin, descripcin,..). De esta manera, el ordenador no solo
aporta informacin sino que tambin ayuda activamente en diversas etapas del
proceso de toma de decisiones.
2.2.4 Problemas del entorno socio-tcnico
El problema capital de los SIGs y origen de todos los dems reside en su

complejidad. Se trata de sistemas sociales y tcnicos que adems pueden verse
gravemente afectados por factores de tipo de volumen, comunicativo, econmico,
psicolgico o poltico.
28
Empezando con los problemas de volumen, la infinidad de datos y aplicaciones que

se utilizan en la empresa ha llevado a abandonar el concepto de un nico sistema
completamente integrado, en favor de una federacin de subsistemas que se van
incorporando al SIG con arreglo a un plan maestro, normas y procedimientos
preestablecidos.
Figura 2.3: Sistemas de informacin para gestin soportados por la base de datos
En cuanto a la comunicacin, algunos autores estiman que un 80% de los problemas

de las empresas radican en problemas de esta ndole.
En el caso de los SIGs, en donde los sistemas que se construyen requieren de la

participacin y colaboracin de personas de muy diversas procedencias, la
necesidad de conseguir una comunicacin fluida, fiable, y que no fomente falsas
expectativas es vital.
Respecto al econmico, estamos en la economa de la informacin y todava no

hemos aprendido a valorarla adecuadamente. La consideracin de beneficios
intangibles, la convergencia de los objetivos del SIG con los de la empresa, y la
adecuacin a la capacidad tcnica disponible, son factores adicionales que pueden
limitar en cualquier momento los resultados potenciales.
29
Los factores psicolgicos, y especialmente los referentes a la motivacin, suponen

otro imperativo para lograr la aceptacin, uso, colaboracin, responsabilizacin y
apoyo, tanto de la alta direccin como de los usuarios.
El carcter interdepartamental de muchas de las aplicaciones tambin precisa de la

creacin de grupos de trabajo, siendo muy conveniente el conocimiento de
disciplinas como la dinmica de grupos y relaciones interpersonales, as como
tambin los procesos que son llevados a cabo de lo medular de cada departamento.
La visin que tienen los departamentos sobre sus propias acciones, as como sus
procesos es esencial dentro de la concepcin de los sistemas de informacin, as
como su control y correccin posterior (en los casos que se requiera)
Su flexibilidad y maleabilidad. El hecho de ser modificable a voluntad. Hace que un

cambio radical de diseo en un producto sea fcil de introducir y apenas encarezca
los costes; basta con cambiar los programas y/o los diseos de las Bases de Datos
en cuestin.
El aprendizaje continuo a que da lugar. Adems de la formacin necesaria en el uso

de las herramientas, como sucede en la tecnologa tradicional, aqu hace falta
tambin aprender cmo aplicarla en el conjunto de problemas correspondientes. Este
proceso suele empezar automatizando formas antiguas de hacer las cosas.
Obteniendo mejoras en eficiencia, y continuando con cambios posteriores ms
profundos y eficaces a medida que se va aprendiendo de su uso.
2.2.5 Particularidades del recurso Informacin
La informacin constituye hoy en da uno de los recursos ms importantes de

muchas empresas. Sin embargo, presenta caractersticas que ninguno de los dems
recursos posee, y que contribuyen a incrementar los problemas anteriormente
citados.
30
A diferencia del carbn, automviles, alimentos o ropa, la informacin es expandible

(crece con el uso); est diseminada (tiende a difundirse o filtrarse, siendo difcil
mantenerla secreta); y es compartible (si doy comida o vendo un coche dejo de tener
esos recursos, si doy informacin no dejo de poseerla, sino que el dador y el receptor
la comparten).
Adems, el recurso informacin es algo ms que el recurso fsico o dato; requiere de

una interpretacin de los datos dentro de un contexto determinado.
Por ltimo, el costo de la informacin crece con la precisin, cantidad o volumen,

calidad, rapidez de respuesta, y distribucin. Proporcionar la informacin adecuada,
en el instante adecuado, a la persona adecuada, con el coste mnimo, son los
objetivos tradicionales del SIG desde el punto de vista de apoyo a los dems
subsistemas de la empresa.
2.2.6 Anlisis de los diferentes tipos de informacin a considerar
La dificultad, una vez ms, aumenta por la disparidad de propiedades y consiguiente

tratamiento, segn se analice el origen de la informacin o su destino.
Influencia del tipo de problema
Las tomas de decisiones se pueden clasificar en un rango de tipos, estando en un

extremo las estructuradas y en el otro las no estructuradas. Otras formas de dar
nombre a estos tipos son: programadas y no programadas, implcitas y abiertas,
analticas y sintticas.
Dentro del primer grupo se incluyen aquellas decisiones repetitivas y rutinarias, para
las que existe previamente un mtodo bien definido para su tratamiento. En
consecuencia son candidatas a una plena automatizacin.
31
El otro grupo corresponde a decisiones para las que hace falta definir el
procedimiento para abordar el problema, ya sea por el carcter nuevo del mismo, por
su complejidad o por su importancia.
Influencia del destino de la informacin
En la figura 2.4 se muestran las diferentes caractersticas de la informacin necesaria

para el desempeo de las funciones de gestin en los tres niveles tpicos: operativo,
gestin y estratgico.
Figura 2.4: El recurso informacin: disparidad de caractersticas segn el destino de la informacin.

La disparidad que se muestra, unida al hecho de que la implantacin de las TIs

conlleva un proceso de aprendizaje continuo y consiguientes mejoras, cambios y
desarrollo de nuevas aplicaciones, hace que la creacin del SI totalmente integrado
sea ineficiente e ineficaz.
32
Ello es debido, en primer lugar, al elevado coste que supondra la realizacin de un

sistema tan complejo y con tan diversos usos; lo segundo, porque las fuentes de
informacin son tambin, en gran medida, distintas segn su finalidad.
Fusin de ambas perspectivas
Las dos perspectivas anteriores se pueden combinar como se muestra la siguiente

figura, denominando decisiones semiestructuradas aquellas en las que alguna de las
fases de inteligencia, diseo o seleccin no est estructurada.
Figura 2.5: El recurso informacin: disparidad de caractersticas segn el tipo de problema.

Al mismo tiempo sealan las siguientes consecuencias:
Necesidad de distribuir adecuadamente los esfuerzos de desarrollo de

aplicaciones entre las seis reas en funcin de su importancia para cumplir los
objetivos de la empresa y no empecinarse slo en alguna de ellas, como
puede ser el caso tpico del control de operaciones estructuradas por la
tendencia natural hacia ellas.
33
El proceso continuo de aprendizaje de las TIs hace que lo que inicialmente no

estaba estructurado con el tiempo se entienda mejor y pase a estar
estructurado, y plenamente, o en menor medida, mecanizable.
Los problemas menos estructurados requieren ms atencin para la parte de

definicin del problema y desarrollo, mientras que los estructurados se centran
bsicamente en la implantacin de un modelo general predeterminado, por
ejemplo, de Investigacin Operativa. Esto hace que los procedimientos y
conocimientos requeridos en cada uno de los dos casos sean distintos.
Tanto en usuarios como en analistas los conocimientos implicados son muy

distintos, segn se trate de un problema de control de operaciones o de
planificacin estratgica.
En el primer caso, es tambin ms un proceso de aplicacin de un modelo

preexistente, mientras que en el segundo centra su atencin en la creacin de un
modelo nuevo.
Adems, el control de operaciones suele ser repetitivo y la eficiencia de diseo es un

factor muy relevante, mientras que el segundo caso suele corresponder a modelos
de un slo uso pero de amplia repercusin en la empresa, siendo por ello la situacin
opuesta.
2.2.7 Problemas del entorno cultural
Ya en publicaciones de los 60s se daba una seal de alarma sobre la falta de

resultados satisfactorios en los SIGs y se sealaba cinco supuestos errores sobre su
diseo, muy extendidos entre los directivos.
Dichos errores se siguen cometiendo en la actualidad. A continuacin destacamos

tres de ellos, por su especial importancia.
34
La limitacin ms crucial de la mayora de directivos es la falta de informacin.

Aun cuando esto es un factor importante, es ms limitante el exceso de
informacin irrelevante. Esto nos da a pensar en Bases de Datos infinitas,
sobrecarga de informacin y problemas de estrs; as como disear sistemas
con filtros, rutas de distribucin, etc.
El director necesita la informacin que desea. Los problemas del mundo real
son muy complejos y tienen un elevado grado de incertidumbre. En
consecuencia, hay tendencia a reducirla con informacin, necesaria real o
presumible, orientndose as de nuevo hacia la sobrecarga de informacin.
Directores controlados por ordenador. Las TIs se estn introduciendo por

todas las partes de las empresas; el director debe conocerlas lo suficiente
para poder valorar si las TIs estn haciendo lo que se supone que deben
hacer.
Las consecuencias de fracasos de implantacin de SIGs pueden verse en un

reciente informe del Govemment Accounting Office de los EEUU sobre el desarrollo
de proyectos informticos, recogido en el siguiente cuadro.
Figura 2.6: El problema del desarrollo de proyectos informticos, basado en un informe del
Government Accounting Office de los EE.UU.
35
2.2.8 Estructura del Sistema de Informacin para Gestin
Ante cualquier estudio relativo a cualquier sistema complejo, siempre es necesario

ver el sistema desde la concepcin completa y no desde lo particular (mirar el
bosque antes que concentrarse en un rbol de este bosque) como es el caso de un
automvil, que puede explicarse en trminos de sus caractersticas externas (forma,
color, tamao, etc.), o por sus componentes (chasis, motor, transmisin..), su uso
(deportivo, familiar, utilitario,..), etc., puede obtenerse una mejor comprensin del
concepto del SIG analizndolo bajo diferentes criterios.
Cada una de estas clasificaciones aporta informacin adicional para entender mejor
el sistema en estudio.
Las clasificaciones relevantes, en nuestro caso son:
Componentes del SIG: computador y dems equipo fsico; programas; BD;

Base de Modelos; Procedimientos y manuales; y recursos humanos. La
integracin de todos estos elementos se consigue por diferentes vas, tales
como
Bases
de
Datos,
planificacin,
directrices,
procedimientos,
normalizaciones, etc.
2.3
Funciones del SIG
Departamento al que va dirigido
Tipo de apoyo en la toma de decisiones
Nivel de la pirmide de gestin al que va dirigido
Salidas del SIG

Auditoria
2.3.1 Evolucin de la Auditoria
ARCHIE MAC GHEE (performing the operational audit)

los ojos y odos del rey.
36
A.C. LITTLETON (evolucin de la contabilidad hasta 1900),

Epitafio en la tumba de Richard Bowle (16/12/1626): Sirvi como auditor en la tierra
a varios seores, pero tambin se prepar para rendir su propia cuenta al seor del
cielo
Inicios: cautelar bienes y la forma como son administrados, informando de ello a sus
dueos.
1729: Dirigida a descubrir fraudes y/o errores en la contabilizacin (tcnicos o

transgresin a P.C.G.A.)
1877: Fbrica de armamentos KRUPP (manual de auditoria interna) impuls que sus
auditores internos, adems de examinar el aspecto contable, proporcionen
sugerencias para mejorar las reas de la empresa.
1940: se marca la diferencia en cuanto a que el auditor externo dirige su examen a

determinar la razonabilidad de los estados financieros y prestar asesora sobre la
gestin, mientras que el auditor interno no slo se debe pronunciar respecto del
sistema contable de la empresa si no que adems de todos los procedimientos
establecidos para la marcha institucional comprendiendo esto, el examen y
evaluacin de los procedimientos administrativos, financieros y legales.
1950: se inicia una nueva era en la conceptualizacin del trabajo del auditor
procurando que en lo principal esta profesin evale y recomiende cursos de accin
en pro de la eficacia, eficiencia y economicidad de las gestiones institucionales.
1973: frente a diversos hechos en los cuales se detecta el abuso del procesador
electrnico de datos para obtener beneficios de carcter personal, no acordes con
los intereses de las instituciones, se dictan normas de auditoria (S.A.S.) en las cuales
se establece la obligatoriedad de los auditores de conocer lo suficiente de los
37
sistemas de informacin automatizados para proporcionar opiniones sobre los grados

de privacidad, seguridad, rendimiento y confiabilidad de la informacin y los recursos
en su obtencin involucrados.
1980: se formaliza la concepcin de la Auditoria Computacional como una accin

moderna de los auditores para enfrentar los delitos de Cuello y Corbata o delitos
informticos. Se genera la concepcin de equipos interdisciplinarios de profesionales.
2.3.2 Conceptualizacin de la auditoria
Concepto amplio de auditoria: Es una tcnica moderna de control que comprende un

examen sistemtico (mtodo), critico (pruebas) y selectivo (muestras) de funciones,
operaciones e informes con la finalidad de emitir una opinin objetiva, fundamentada
e imparcial del objeto en revisin.
Es un examen o revisin efectuada por un profesional independiente.
Cualquier aspecto de la organizacin formal es susceptible de ser auditado y

con ello ser objeto de revisin.
Es un examen que proporciona elementos de juicio que sustentan la opinin

profesional.
Es selectivo al trabajar sobre la base de muestras, de no ser as, el trabajo del

auditor tendra una duracin que podra atentar respecto de la oportunidad y
su costo probablemente seria impermisible.
El trabajo sobre muestras permite establecer que su conclusin pueda

hacerse extensiva hacia el universo, siempre que dicha muestra sea
representativa de la poblacin examinada.
38
Es critico porque esta destinado a poner en tela de juicio todas y cada una de
las formas como se realizan y se organizan las diferentes funciones,
procedimientos o tareas e, incluso, los valores aceptados y practicados por las
personas que integran la organizacin. Dicho de otra manera, todo es
susceptible de mejorarse.
A lo descrito, merecen agregarse los siguientes comentarios:

o La actitud crtica del auditor significa no dar por conocido algo si no se
tienen los elementos de juicio suficientes como para tener una razonable
seguridad de que as ocurri.
o Esta actitud crtica significa verificar o probar las afirmaciones hechas por
la empresa o su personal, satisfacindose una vez conseguidas las
evidencias ms concluyentes posibles.
Debe ser sistemtico, es decir que el trabajo de auditoria debe contemplar la

universalidad de lo que se examina para lo cual se deben aplicar mtodos,
normas y metodologas.
2.4
COBIT 4.0 y el Control de Proyectos TIC
COBIT es un acrnimo para Control Objectives for Information and related

Technology (Objetivos de Control para tecnologa de la informacin y relacionada COBIT-); desarrollada por la Information Systems Audit and Control Association
(ISACA) y el IT Governance Institute (ITGI).
COBIT es una metodologa aceptada mundialmente para el adecuado control de

proyectos de tecnologa, los flujos de informacin y los riesgos que stas implican. La
metodologa COBIT se utiliza para planear, implementar, controlar y evaluar el
gobierno sobre TIC; incorporando objetivos de control, directivas de auditoria,
medidas de rendimiento y resultados, factores crticos de xito y modelos de
madurez.
39
Como modelo COBIT es constantemente actualizado, siendo COBIT 4.0 la ltima

actualizacin relevante en este estndar internacional; el cual permite a las empresas
aumentar su valor TIC y reducir los riesgos asociados a proyectos tecnolgicos. Ello
gracias a que COBIT 4.0 se estructura a partir de parmetros generalmente
aplicables y aceptados, para mejorar las prcticas de planeacin, control y seguridad
de las Tecnologas de Informacin.
El trmino "generalmente aplicable y aceptado" es utilizado en el mismo sentido que

los Principios de Contabilidad Generalmente Aceptados (PCGA o GAAP por sus
siglas en ingls), proveyendo un marco de referencia para la Administracin
(gerencia), Usuarios y Auditores.
COBIT contribuye a reducir las brechas existentes entre los objetivos de negocio, y
los beneficios, riesgos, necesidades de control y aspectos tcnicos propios de un
proyecto TIC; proporcionando un Marco Referencial Lgico para su direccin
efectiva.
Qu ofrece COBIT?
El marco referencial conceptual de la metodologa COBIT proporciona una visin

integral, capaz de responder a las necesidades de directivos, usuarios (de diverso
nivel) y auditores (internos y externos).
Cobit 4.0 busca enlazar los objetivos empresariales con los objetivos TIC y los
procesos TIC. En la prctica esto se logra identificando los 1). Requerimientos del
negocio para la informacin y los 2) recursos de TIC que son impactados en forma
primaria por cada objetivo de control, asociado a cada 3) proceso TIC.
40
1. Requerimientos de negocio para la informacin:
Efectividad
Eficiencia
Confidencialidad
Integridad
Disponibilidad
Cumplimiento
Confiabilidad
2. Recursos TIC:
Datos
Aplicaciones
Tecnologa
Instalaciones
Personal
3. Procesos de TIC:
Cuatro dominios en lnea con el ciclo administrativo o ciclo de vida aplicable a
los procesos de TI:
Planeacin y organizacin
Adquisicin e implementacin
Entrega y soporte
Monitoreo
Asociados a los 4 dominios existen 34 procesos de alto nivel, desagregados en 302

procesos y/o actividades menor jerarqua.
Para cada proceso de alto nivel existen objetivos, medidas de control de diversa
naturaleza, indicadores asociados (de objetivo clave -key goal indicator, KGI- y de
rendimiento clave -key performance indicator, KPI-), adems de modelos de
madurez.
41
Para cada medida de control se lleva a cabo una clasificacin dentro del marco
referencial CobIT:
Primario: es el grado al cual el objetivo de control definido impacta directamente el
requerimiento de informacin de inters.
Secundario: es el grado al cual el objetivo de control definido satisface nicamente

de forma indirecta o en menor medida el requerimiento de informacin de inters.
Blanco (vaco): podra aplicarse; sin embargo, los requerimientos son satisfechos
ms apropiadamente por otro criterio en este proceso y/o por otro proceso.
A su vez cada proceso y/o actividad de menor jerarqua involucra una sumatoria de
buenas prcticas necesarias de considerar para el cumplimiento de los requisitos de
control exigidos para cada caso, estableciendo los resultados deseados o propsitos
a ser alcanzados mediante su implementacin.
Adicional al Marco Referencial, COBIT dispone tambin de Guas de Auditoria, las

cuales contienen los pasos de auditoria correspondientes a cada uno de los 34
objetivos de control de TI de alto nivel para proporcionar asistencia a los auditores de
sistemas en la revisin de los procesos de TIC con respecto a los 302 objetivos
detallados de control recomendados para proporcionar a la gerencia certeza o una
recomendaciones de mejoramiento.
Incorpora adems de un Conjunto de Herramientas de Implementacin, la cual

proporciona:
Una Sntesis Ejecutiva, que permite a la alta gerencia conciencia y

entendimiento de COBIT.
Casos de estudio y lecciones aprendidas por organizaciones que han aplicado

COBIT rpida y exitosamente.
42
Diversas herramientas, tales como: Diagnstico de la Conciencia de la

Gerencia (Management Awareness Diagnostic) y el Diagnstico de Control de
TI (IT Control Diagnostic).
Adicionalmente, se incorporan preguntas y respuestas ms frecuentes acerca

de CObIT y varias presentaciones para distintos niveles jerrquicos y
audiencias dentro de las organizaciones.
Por qu la necesidad de un mtodo de control para TIC, como COBIT?
Un elemento crtico para el xito y la supervivencia de las organizaciones, es la

administracin estratgica de la informacin vinculada a ella. Esta criticidad tiene su
origen en el nacimiento de las sociedades de la informacin y la economa del
conocimiento, caracterizadas entre otros aspectos por:
La creciente dependencia de informacin y en los sistemas tecnolgicos que
proporcionan dicha informacin.
El uso de la informacin para generar conocimiento organizacional (gestin del

conocimiento) como variable indispensable para obtener una ventaja competitiva.
La creciente vulnerabilidad y un amplio espectro de amenazas, tales como las "ciber

amenazas" y la guerra de informacin (information warfare).
La escala y el costo de las inversiones actuales y futuras en informacin y en

tecnologa de informacin, que obligan a administrar los riesgos y evaluar los costos
involucrados.
El notable potencial que tienen las tecnologas para cambiar radicalmente las
organizaciones y las prcticas de negocio, crear nuevas oportunidades y reducir
radicalmente los costos. En resumen, agregar valor al negocio.
43
Las organizaciones se reestructuran con el fin de perfeccionar sus operaciones y al

mismo tiempo aprovechar los avances en tecnologa de sistemas de informacin
para mejorar su posicin competitiva.
A pesar de que muchas organizaciones reconocen los beneficios potenciales que las
tecnologas de informacin pueden proporcionar, el camino de integrar este potencial
al flujo de objetivos estratgicos, propios del negocio; ha sido en la prctica bastante
difcil de planificar, implementar, controlar y evaluar.
Las razones pueden ser variadas, entre otras:
Un nuevo paradigma que necesita ser no slo conocido sino tambin

asimilado
organizacionalmente
(planificacin,
control,
normativas,
procedimientos, cultura organizacional, entre otros).
Competencias no desarrolladas en plenitud para liderar y gestionar los

procesos asociados al desarrollo de un proyecto TIC, como insumo
estratgico a la perspectiva del negocio.
Las TIC vistas como instrumento, ms que como variable de creacin de valor
organizacional.
Ausencia de metodologas integrales y comnmente aceptadas para la

planeacin, implementacin, control y evaluacin de proyectos TIC.
Como consecuencia de lo anterior, muchos proyectos TIC se encuentran, en mayor o

menor grado, desvinculados de la perspectiva estratgica y dbilmente integrados a
las dimensiones relevantes a travs de las cuales una organizacin se desarrolla;
poniendo en jaque la perspectiva estratgica implcita en la decisin de incorporar
TIC en una organizacin:
La creacin de valor, ya sea creando, aportando, expandiendo o transformado las
ventajas competitivas de la empresa.
El conocimiento y administracin de los riesgos relacionados a la implementacin de
una nueva tecnologa, optimizando la inversin asociada.
44
Cul es el aporte de COBIT 4.0 a una organizacin?
En
un
sentido
conceptual,
la
metodologa
COBIT
4.0
permite
integrar
sistemticamente la dimensin del negocio (la esencia estratgica de la actividad

organizacional),
con
la
dimensin
tecnolgica
(propia
de
la
planeacin,
implementacin, control y evaluacin de un proyecto TIC), independientemente de la

realidad
tecnolgica
que
cada
organizacin
haya
decidido
adoptar.
Bajo la perspectiva de COBIT 4.0, un proyecto TIC debe responder sistemticamente

a los objetivos estratgicos del negocio, hecho que puede verificarse tanto en las
dimensiones que considera, como en la forma en que las relaciona. A partir de ello
surgen distintas instancias de control, indicadores de desempeo y de proceso,
modelos de madures, etc.; capaces de responder a diversas necesidades de
informacin y de control por parte de variados usuarios, de acuerdo a su naturaleza.
Por ejemplo, los directivos de una empresa pueden enfocarse en sus requerimientos
de negocio (traducido por el marco referencial en siete requerimientos de informacin
especficos) y obtener un balance adecuado en el empleo de los recursos
disponibles. Un Directivo de TI puede monitorear los recursos de TI por los cuales
debe responder. Responsables de procesos, especialistas de TI y usuarios pueden
tener un inters en procesos o resultados de control particulares. Por su parte, los
auditores tendrn un marco referencial para ejercer una cobertura de control de
naturaleza
sistmica,
pero
su
vez
estricta
en
el
detalle
especfico.
En efecto, el concepto fundamental del marco referencial CObIT se refiere a que el

enfoque del control en TI se lleva a cabo visualizando la informacin necesaria para
dar soporte a los procesos de negocio y considerando a la informacin como el
resultado de la aplicacin combinada de recursos relacionados con la Tecnologa de
Informacin que deben ser administrados por procesos de TIC.
45
Es esta interrelacin de dimensiones lo que permite COBIT se posicione como una

metodologa de control de nivel superior, logrando adems integrar la dimensin del
control con la dimensin estratgica (asociada a la naturaleza del negocio).
Lo anterior no es menor si consideramos que la experiencia internacional muestra

que slo el 16% de los proyectos TIC en USA. y la UE son exitosos. Esta ltima
estim que pierde 118 billones de euros en proyectos TIC fracasados.
Gran parte del origen de estos fracasos se debe a que los proyectos TIC, al carecer
de una dimensin estratgica que le permita vincularse sistemticamente a las
necesidades de negocio, terminan por instrumentalizarse y autoreferenciarse como
un fin en si mismos, ms que como una variable integrada a una estrategia de
creacin de valor a partir de ella.
Una visin instrumentalista estima que, por definicin, un proyecto TIC ser valorado,
comprendido, asimilado y utilizado por la organizacin a travs de todas sus
dimensiones relevantes. Que las necesidades de control y sus indicadores asociados
deben responder prioritariamente a la lgica del rendimiento del proyecto
(indicadores KPI), minimizando los vnculos asociados a los requerimientos
estratgicos del negocio, los cuales se expresan a travs de indicadores de
desempeo (KPI).
Este hecho se manifiesta an con mayor fuerza a nivel de Gobierno Electrnico,

como el caso del PMG de Gobierno Electrnico en Chile. En la prctica, muchos
proyectos TIC terminan siendo procesos de soporte informtico (o al menos
asimilndose a estos en su concepcin lgica, implementacin y evaluacin); ms
que a proyectos de creacin de valor que permitan crear, aportar, expandir o
transformar las ventajas competitivas de la organizacin, a travs de las TICS. Estos
ltimos casos son emblemticos (a menudo vinculados a liderazgos personales),
reducidos en cantidad y muy recurrentes a la hora de mostrar resultados.
46
En resumen, independientemente de la realidad tecnolgica de cada caso concreto,

COBIT determina, con el respaldo de las principales normas tcnicas internacionales,
un conjunto de mejores prcticas para la seguridad, la calidad, la eficacia y la
eficiencia en TI que son necesarias para alinear TI con el negocio, identificar riesgos,
entregar valor al negocio, gestionar recursos y medir el desempeo, el cumplimiento
de metas y el nivel de madurez de los procesos de la organizacin.
Proporciona a gerentes, interventores, y usuarios TI con un juego de medidas

generalmente aceptadas, indicadores, procesos y las mejores prcticas para ayudar
a ellos en el maximizar las ventajas sacadas por el empleo de tecnologa de
informacin y desarrollo de la gobernacin apropiada TI y el control en una empresa.
2.5
COBIT y otras normas
2.5.1 COBIT y ISO/IEC 17799:2005
Las dos normas internacionales usadas hoy son COBIT Y ISO/IEC 17799:2005.
COBIT (Objetivos de Control para la Informacin y la Tecnologa relacionada) fue
liberado y usado principalmente por la comunidad TI. En 1998, las Directrices de
Direccin fueron aadidas, y COBIT se hizo el marco internacionalmente aceptado
para la gobernacin TI y el control. ISO/IEC 17799:2005 (el Cdigo de prctica para
la Seguridad de Informacin la Direccin) es tambin un estndar internacional y es
la mejor prctica para poner en prctica la direccin de seguridad. Las dos normas
no compiten el uno con el otro y en realidad complementan el uno al otro. COBIT
tpicamente cubre una ms amplia rea mientras ISO/IEC 17799 profundamente es
enfocado en el rea de seguridad.
2.5.2 COBIT y Sarbanes Oxley
Requieren las empresas pblicas que son sujetos a EE UU Sarbanes Oxley el Acto
de 2002 para adoptar los marcos de control siguientes: el Comit de Patrocinar las
Organizaciones de la Comisin de Treadway (COSO) el Control Interno Integr el
47
Marco y los Objetivos de Control del Instituto de Gobernacin TI para la Informacin

y la Tecnologa Relacionada (COBIT). En el escogimiento cul de los marcos de
control para poner en prctica para cumplir con Sarbanes-Oxley, las Seguridades
estadounidenses y la Comisin De cambio sugieren que las empresas sigan el marco
COSO.
COSO el Control Interno Se integr el Marco declara que el control interno es un

proceso - establecido por la junta directivo de una entidad, la direccin, y otro
personal - diseado para proporcionar el aseguramiento razonable en cuanto al logro
de objetivos indicados.
COBIT se acerca al control de TI por mirar la informacin que es necesario para

apoyar exigencias de negocio y los recursos asociados TI y procesos. COSO
objetivos de control enfocan la eficacia, la eficacia de operaciones, el reportaje
confiable financiero, y el cumplimiento con leyes y regulaciones. COBIT es ampliado
para cubrir la calidad y exigencias de seguridad en siete categoras de traslapo, que
incluyen la eficacia, la eficacia, la confidencialidad, la integridad, la disponibilidad, el
cumplimiento, y la fiabilidad de informacin.
Estas categoras forman la fundacin para los objetivos de control del COBIT. Los
dos marcos tambin tienen el pblico diferente. COSO es til para la direccin en
general, mientras COBIT es til para la direccin, usuarios, e interventores. COBIT
expresamente es enfocado (concentrado) en mandos de TI. A causa de estas
diferencias, interventores no deberan esperar una relacin de uno a uno entre los
cinco componentes de control de COSO y los cuatro dominios COBIT objetivos.
2.6
Aspectos Legales
Ley 19.223 Tipifica figuras penales relativas a la informtica
48
Qu es lo que se protege en la Ley de Delitos Informticos?

Toda tipificacin de delitos pretende, en ltimo trmino, proteger bienes jurdicos. Los
bienes jurdicos son intereses relevantes de las personas en tanto sujetos sociales,
considerados especialmente valiosos y consecuentemente, dignos de proteccin
penal frente a conductas que los daan o ponen en peligro.
As, respecto del delito de hurto, por ejemplo, el bien jurdico protegido es la
propiedad. En el caso del homicidio, el bien jurdico protegido es la vida.
En el caso de los delitos tipificados en la Ley 19.233, es un nuevo bien jurdico que
ha surgido con el uso de las modernas tecnologas computacionales: la calidad, la
pureza e idoneidad de la informacin en cuanto tal, contenida en un sistema
automatizado de tratamiento de la misma y de los productos que de su operacin se
obtengan.
Sin embargo, no slo se protege ese bien sino que adems, concurren otros, tales
como: el patrimonio, en el caso de los fraudes informticos; la privacidad, intimidad y
confidencialidad de los datos como es el caso del espionaje informtico; la seguridad
y fiabilidad del trfico jurdico y probatorio en el caso de las falsificaciones de datos
probatorios va medios informticos; el derecho de propiedad sobre la informacin y
sobre los elementos fsicos, materiales de un sistema informtico, en el caso de los
delitos de daos.
Qu es un delito informtico?
Se ha conceptualizado el delito informtico de distinta manera, entre las cuales
podemos sealar:
Aquellos delitos perpetrados por medio del uso de computadores y todos los
delitos en que se dae a los computadores o a sus componentes;
Todas aquellas acciones u omisiones tpicas, antijurdicas y dolosas, trtese

de hechos aislados o de una serie de ellos, cometidos contra personas
naturales o jurdicas, realizadas en uso de un sistema de tratamiento de
49
informacin y destinadas a producir u perjuicio en la vctima a travs de

atentados a la sana tcnica informtica, lo cual, generalmente, producir de
manera colateral lesiones a distintos valores jurdicos, reportndose, muchas
veces, un beneficio ilcito en el agente, sea o no de carcter patrimonial, actu
con o sin nimo de lucro (Marcel Huerta y Claudio Lbano).
Lo esencial radica en que, tanto los medios de comisin como el objeto del delito,
dicen relacin con dispositivos habitualmente utilizados en actividades informticas.
Cules son las conductas sancionadas en la Ley?

La Ley N 19.233 contempla cuatro artculos, que si bien corresponde cada uno a un
tipo de conducta distinta, se pueden clasificar en dos grandes figuras delictivas:
I) Sabotaje Informtico;
II) Espionaje Informtico.
Estas dos figuras se subdividen en categoras distintas, atendiendo al objeto contra

el cual se atenta y/o al modus operandi.
A continuacin se transcriben las disposiciones de la citada ley que tipifican los

delitos informticos:
Articulo 1. El que maliciosamente destruya o inutilice un sistema de tratamiento de

informacin o sus partes o componentes, o impida, obstaculice o modifique su
funcionamiento, sufrir la pena de presidio menor en su grado medio a mximo.
Si como consecuencia de estas conductas, se afectaren los datos contenidos en el
sistema, se aplicar la pena sealada en el inciso anterior, en su grado mximo.
Articulo 2: El que con nimo de apoderarse, usar, o conocer indebidamente de la

informacin contenida en un sistema de tratamiento de la misma, lo intercepte,
interfiera o acceda a l, ser castigado con presidio menor en su grado mnimo a
medio.
50
Articulo 3. El que maliciosamente altere, dae o destruya los datos contenidos en

un sistema de tratamiento de la informacin, ser castigado con presidio menor en su
grado medio.
Articulo 4. El que maliciosamente revele o difunda los datos contenidos en un

sistema de informacin sufrir la pena de presidio menor en su grado medio.
Si quien incurriere en estas conductas es el responsable del sistema de informacin,
la pena se aumentar en un grado.
En que consiste el Sabotaje Informtico?

El Sabotaje Informtico (articulo 1 y 3 de la Ley N 19.223) comprende aquellas
conductas tipificadas atendiendo al objeto que se afecta o atenta con la accin
delictual, y que puede ser un sistema de tratamiento de la informacin o de sus
partes componentes, el funcionamiento de un sistema de tratamiento de la
informacin, y/o los datos contenidos en un sistema automatizado de tratamiento de
la informacin. El atentado a estos objetos puede ser a travs de su destruccin,
inutilizacin, obstaculizacin o modificacin.
En que consiste el Espionaje Informtico?

El Espionaje Informtico (articulo 2 y 4 de la Ley N 19.223) comprende aquellas
figuras delictivas que atienden al modo operativo que se ejecuta y que pueden ser,
en primer lugar, delitos de apoderamiento indebido (apropiarse de la informacin),
uso indebido (usar la informacin para cualquier fin) o conocimiento indebido de la
informacin, cometidos interfiriendo, interceptando o meramente accediendo al
sistema de tratamiento de datos. Estas figuras se encuentran descritas en el artculo
2 de la Ley, y comprende lo comnmente conocido como Hawking.
En segundo lugar, comprende tambin los delitos de revelacin indebida y difusin
de datos contenidos en un sistema de tratamiento de la informacin (artculo 4 de la
ley).
51
CAPITULO III
INTRODUCCIN A LA AUDITORA
3.1
Control interno informtico
El control interno informtico controla diariamente que todas las actividades de

sistemas de informacin sean realizadas cumpliendo los procedimientos, estndares
y normas fijados por la Direccin de la Organizacin y/o la Direccin Informtica, as
como los requerimientos legales.
La misin del control interno informtico es asegurarse de que las medidas que se
obtienen de los mecanismos implantados por cada responsable sean correctas y
vlidas.
Control interno informtico suele ser un rgano staff de la Direccin del

Departamento de Informtica y est dotado de las personas y medios materiales
proporcionados a los cometidos que se le encomienden.
Como principales objetivos podemos indicar los siguientes:
Controlar que todas las actividades se realicen cumpliendo los procedimientos

y normas fijados, evaluar su bondad y asegurarse del cumplimiento de las
normas legales.
Asesorar sobre el conocimiento de las normas.
Colaborar y apoyar el trabajo de Auditoria informtica, as como de las

auditorias externas al grupo.
Definir, implantar y ejecutar mecanismos y controles para comprobar el logro

de los grados adecuados del servicio informtico, lo cual no debe considerarse
como que la implantacin de los mecanismos de medida y responsabilidad del
52
logro de esos niveles se ubique exclusivamente en la funcin de control

interno, sino que cada responsable de objetivos y recursos es responsable de
esos niveles, as como de la implantacin de los medios de medida
adecuados.
3.2
Auditoria informtica
La auditoria informtica es el proceso de recoger, agrupar y evaluar evidencias para

determinar si un sistema informatizado salvaguarda los activos, mantiene la
integridad de los datos, lleva a cabo eficazmente los fines de la organizacin y utiliza
eficientemente los recursos. De este modo la auditoria informtica sustenta y
confirma la consecucin de los objetivos tradicionales de la auditoria:
Objetivos de proteccin de activos e integridad de datos.
Objetivos de gestin que abarcan, no solamente los de proteccin de activos

sino tambin los de eficacia y eficiencia.
El auditor evala y comprueba en determinados momentos del tiempo los controles y

procedimientos informticos ms complejos, desarrollando y aplicando tcnicas
mecanizadas de auditoria, incluyendo el uso del software. En muchos casos, ya no
es posible verificar manualmente los procedimientos informatizados que resumen,
calculan y clasifican datos, por lo que se deber emplear software de auditoria y
otras tcnicas asistidas por ordenador.
El auditor es responsable de revisar e informar a la Direccin de la Organizacin

sobre el diseo y el funcionamiento de los controles implantados y sobre la fiabilidad
de la informacin suministrada.
Se puede establecer tres grupos de funciones a realizar por un auditor informtico:
53
Participar en las revisiones durante y despus del diseo, realizacin,

implantacin y explotacin de aplicaciones informticas, as como en las fases
anlogas de realizacin de cambios importantes.
Revisar y juzgar los controles implantados en los sistemas informticos para

verificar su adecuacin a las rdenes e instrucciones de la Direccin,
requisitos legales, proteccin de confidencialidad y cobertura ante errores y
fraudes.
Revisar y juzgar el nivel de eficacia, utilidad, fiabilidad, y seguridad de los

equipos e informacin.
3.3
Control interno y auditoria informticos: campos anlogos
La evolucin de ambas funciones ha sido espectacular durante la ltima dcada.

Muchos controles internos fueron una vez auditores. De hecho, mucho de los
actuales responsables de Control Interno Informtico recibieron formacin en
seguridad informtica tras un paso por la formacin en auditoria. Numerosos
auditores se pasan al campo de Control Interno Informtico debido a la similitud de
los objetivos profesionales de control y auditoria, campos anlogos que propician una
transicin natural.
Aunque ambas figuras tienen objetivos comunes, existen diferencias que conviene
matizar:
54
CONTROL INTERNO
INFORMTICO
AUDITOR INFORMTICO
PERSONAL INTERNO
Conocimientos especializados en tecnologas de
SIMILITUDES
informacin Verificacin del cumplimiento de controles

internos, normativa y procedimientos establecidos por la
direccin informtica y la direccin general para los sistemas
de informacin.
DIFERENCIAS
- Anlisis de los controles en
- Anlisis de un momento
el da a da
informtico determinado
- Informa a la direccin del
- Informa a la direccin
departamento de informtica
general de la organizacin
- Slo personal interno
- Personal interno y/o
- El enlace de sus funciones
externo
es nicamente sobre el
- Tiene cobertura sobre
departamento de informtica
todos los componentes de

los sistemas de informacin
de la organizacin
Tabla 3.1: Similitudes y diferencias entre control interno y auditoria informtica.

Fuente: Elaboracin Propia.
3.4
Sistema de Control Interno Informtico
3.4.1 Definicin y tipos de controles internos
Se puede definir el control interno como cualquier actividad o accin realizada

manual y/o automticamente para prevenir, corregir errores o irregularidades que
puedan afectar al funcionamiento de un sistema para conseguir sus objetivos.
55
Los controles cuando se disean, desarrollen e implanten han de ser al menos

completos, simples, fiables, revisables, adecuados y rentables. Respecto a esto
ltimo habr que analizar el coste-riesgo de su implantacin.
Los controles internos que se utilizan en el entorno informtico continan

evolucionando hoy en da a medida que los sistemas informticos se vuelven
complejos. Los progresos que se producen en la tecnologa de soportes fsicos y de
software han modificado de manera significativa los procedimientos que se
empleaban tradicionalmente para controlar los procesos de aplicaciones y para
gestionar los sistemas de informacin.
Para asegurar la integridad, disponibilidad y eficacia de los sistemas se requieren

complejos mecanismos de control, la mayora de los cuales son automticos. Resulta
interesante observar, sin embargo, que hasta en los sistemas servidor/cliente
avanzados, aunque algunos controles son completamente automticos, otros son
completamente manuales, y muchos dependen de una combinacin de elementos de
software y de procedimientos.
Histricamente, los objetivos de los controles informticos se han clasificado en las

siguientes categoras:
Controles preventivos: para tratar de evitar el hecho, como un software de

seguridad que impida los accesos no autorizados al sistema.
Controles detectivos: cuando fallan los preventivos para tratar de conocer

cuanto antes el evento. Por ejemplo, el registro de intentos de acceso no
autorizados, el registro de la actividad diaria para detectar errores u
omisiones, etc.
Controles correctivos: facilitan la vuelta a la normalidad cuando se han

producido incidencias. Por ejemplo, la recuperacin de un fichero daado a
partir de las copias de seguridad.
56
Como el concepto de controles se origin en la profesin de auditoria, resulta

importante conocer la relacin que existe entre los mtodos de control, los objetivos
de control y los objetivos de auditoria. Se trata de un tema difcil por el hecho de que,
histricamente, cada mtodo de control ha estado asociado unvocamente con un
objetivo de control (por ejemplo, la seguridad de ficheros de datos se consegua
sencillamente manteniendo la sala de ordenadores cerrada con llave).
Sin embargo, a medida que los sistemas informticos se han vuelto ms complejos,
los controles informticos han evolucionado hasta convertirse en procesos integrados
en los que se atenan las diferencias entre las categoras tradicionales de controles
informticos.
Por ejemplo, en los actuales sistemas informticos puede resultar difcil ver la
diferencia entre seguridad de los programas, de los datos y objetivos de control del
software del sistema, porque el mismo grupo de mtodos de control satisface casi
totalmente los tres objetivos de control.
La relacin que existe entre los mtodos de control y los objetivos de control puede
demostrarse mediante el siguiente ejemplo, en el que un mismo conjunto de mtodos
de control se utiliza para satisfacer objetivos de control tanto de mantenimiento como
de seguridad de los programas:
Objetivo de Control de mantenimiento: asegurar que las modificaciones de los

procedimientos programados estn adecuadamente diseadas, probadas,
aprobadas e implementadas.
Objetivo de Control de seguridad de programas: garantizar que no se pueden

efectuar cambios no autorizados en los procedimientos programados.
57
3.4.2 Implantacin de un sistema de controles internos informticos
Los controles pueden implantarse a varios niveles diferentes. La evaluacin de los

controles de la Tecnologa de la Informacin exige analizar diversos elementos
interdependientes. Por ello es importante llegar a conocer bien la configuracin del
sistema, con el objeto de identificar los elementos, productos y herramientas que
existen para saber dnde pueden implantarse los controles, as como para identificar
posibles riesgos.
Para llegar a conocer la configuracin del sistema es necesario documentar los

detalles de la red, as como los distintos niveles de control y elementos relacionados:
Entorno de red: esquema de la red, descripcin de la configuracin hardware

de comunicaciones, descripcin del software que se utiliza como acceso a las
telecomunicaciones, control de red, situacin general de los ordenadores de
entornos de base que soportan aplicaciones crticas y consideraciones
relativas a la seguridad de la red.
Configuracin del ordenador base: configuracin del soporte fsico, entorno

del sistema operativo, software con particiones, entornos (pruebas y real),
bibliotecas de programas y conjunto de datos.
Entorno de aplicaciones: procesos de transacciones, sistemas de gestin de

bases de datos y entornos de procesos distribuidos.
Productos y herramientas: software para desarrollo de programas, software

de gestin de bibliotecas y operaciones automticas.
Seguridad del ordenador base: identificar y verificar usuarios, control de

acceso, registro e informacin, integridad del sistema, controles de
supervisin, etc.
Para la implantacin de un sistema de controles internos informticos habr que

definir:
58
Gestin de sistemas de informacin: polticas, pautas y normas tcnicas que

sirvan de base para el diseo y la implantacin de los sistemas de
informacin y de los controles correspondientes.
Administracin de sistemas: controles sobre la actividad de los centros de

datos y otras funciones de apoyo al sistema, incluyendo la administracin de
las redes.
Seguridad: incluye las tres clases de controles fundamentales implantados en

el software del sistema, integridad del sistema, confidencialidad (control de
acceso) y disponibilidad.
Gestin del cambio: separacin de las pruebas y la produccin a nivel de

software y controles de procedimientos para la migracin de programas
software aprobados y probados.
La implantacin de una poltica y cultura sobre la seguridad requiere que sea

realizada por fases y est respaldada por la direccin. Cada funcin juega un papel
importante en las distintas etapas:
Direccin de Negocio o Direccin de Sistemas de Informacin (SI): han de definir la

poltica y/o directrices para los sistemas de informacin en base a las exigencias del
negocio, que podrn ser internas o externas.
Direccin de Informtica: ha de definir las normas de funcionamiento del entorno

informtico y de cada una de las funciones de Informtica mediante la creacin y
publicacin de procedimientos, estndares, metodologas y normas, aplicables a
todas las reas de Informticas as como a los usuarios, que establezcan el marco
de funcionamiento.
Control Interno Informtico: ha de definir los diferentes controles peridicos a realizar

en cada una de las funciones informticas, de acuerdo al nivel de riesgo de cada una
de ellas, y ser diseados conforme a los objetivos de negocio y dentro del marco
legal aplicable. stos se plasmarn en los oportunos procedimientos de control
59
interno y podrn ser preventivos o de deteccin. Realizar peridicamente la revisin

de los controles establecidos de Control Interno Informtico informando de las
desviaciones a la Direccin de Informtica y sugiriendo cuantos cambios crea
convenientes en los controles, as como transmitir constantemente a toda la
organizacin de Informtica la cultura y polticas del riesgo informtico.
Auditor interno/externo informtico: Ha de revisar los diferentes controles internos

definidos en cada una de las funciones informticas y el cumplimiento de normativa
interna y externa, de acuerdo al nivel de riesgo, conforme a los objetivos definidos
por la Direccin de Negocio y la Direccin de Informtica. Informar a la alta
Direccin de los hechos observados y al detectarse deficiencias o ausencias de
controles, recomendarn acciones que minimicen los riesgos que pueden originarse.
La creacin de un sistema de control informtico es una responsabilidad de la

Gerencia y un punto destacable de la poltica en el entorno informtico.
3.5
Metodologas de control interno y seguridad
3.5.1 Introduccin a las metodologas
Segn el diccionario de la lengua de la real academia espaola, mtodo es el modo

de decir o hacer con orden una cosa. Asimismo define el diccionario la palabra
metodologa como conjunto de mtodos que se siguen en una investigacin
cientfica o en una exposicin. Esto quiere decir que cualquier proceso cientfico
debe estar sujeto a una disciplina definida con anterioridad que llamaremos
metodologa
La informtica ha sido tradicionalmente una materia compleja en todos sus aspectos,

por lo que se hace necesaria la utilizacin de metodologas en el diseo de ingeniera
dentro de las reas de la informtica, as como tambin de su control.
60
Las metodologas usadas por un profesional dicen mucho de las formas de entender
el trabajo, estando directamente relacionadas con la experiencia profesional
acumuladas en base al conocimiento del comportamiento humano en forma de
ensayo y error.
Asimismo una metodologa es necesaria para que un equipo de profesionales

alcance un resultado homogneo tal como si lo hiciera uno solo, por lo que resulta
habitual
el
uso
de
metodologas
en
las
empresas
auditoras/consultoras
profesionales, desarrolladas por los ms expertos, para conseguir resultados

homogneos en equipos de trabajo heterogneos.
La proliferacin de metodologas en el mundo del control informtico se pueden

observar en los primeros aos de la informtica, en la que existen muchas disciplinas
cuyo uso de metodologas constituye una prctica habitual, siendo una de ellas la
seguridad de los sistemas de informacin.
Si definimos la seguridad de los sistemas de informacin como doctrina que trata de

los riesgos informticos o creados por la informtica, entonces la auditoria es una de
las figuras involucradas en este proceso de proteccin y conservacin de la
informacin y de sus medios de proceso.
Por tanto, el nivel de seguridad informtica en una entidad es un objetivo a evaluar y

esta directamente relacionado con la calidad y eficacia de un conjunto de acciones y
medidas destinadas a proteger y preservar la informacin de la sociedad y sus
medios.
Es as entonces como la informtica crea unos riesgos informticos de los que hay
que proteger y preservar a la sociedad con un entramado de contramedidas, y la
calidad y la eficacia de las mismas es el objetivo de evaluar para poder identificar as
sus puntos dbiles y mejorarlos. Esta es una de las funciones que adquieren
entonces los auditores y controladores internos informticos.
61
Para explicar este aspecto se dir que cualquier contramedida nace de la

composicin de varios factores que se expresa en la siguiente figura.
Figura 3.1: Pirmide de accin para el control interno y la seguridad.

Fuente: Auditoria informtica: Un enfoque practico. Mario G. Piattini, Emilio del Peso.
La normativa: debe definir de forma clara y precisa todo lo que debe existir y ser
cumplido, tanto desde el punto de vista conceptual, como prctico, desde lo general
a lo particular. Se basa en estndares, polticas, marco jurdico, polticas y normas de
la empresa y prctica profesional.
La organizacin: la integran personas especficas y con actuaciones concretas,

procedimientos definidos metodolgicamente y aprobados por la direccin de la
empresa. Este aspecto es importante, dado que sin l, nada es posible. Se pueden
establecer controles sin alguno de los dems aspectos, pero nunca sin personas, ya
62
que son estas las que realizan los procedimientos y desarrollan los planes (Plan de
Seguridad, Plan de contingencias, auditorias, etc.)
Las metodologas: son necesarias para desarrollar cualquier proyecto que nos
propongamos de manera ordenada y eficaz.
Los objetivos de control: son los objetivos a cumplir en el control de procesos. Este
concepto es el ms importante despus de la organizacin, y solamente de un
planteamiento de los mismos saldrn unos procedimientos eficaces y realistas.
Los procedimientos de control: son los procedimientos operativos de las distintas

reas de la empresa, obtenidos con una metodologa apropiada, para la consecucin
de uno o varios objetivos de control, y por lo tanto deben de estar documentados y
aprobados por la direccin.
Tecnologa de seguridad: son todos los elementos, ya sean software o hardware, que
ayudan a controlar un riesgo informtico. Dentro de este concepto estn los
cifradores, autentificadores, equipos "tolerantes a fallos", las herramientas de control,
etc.
Las herramientas de control: son elementos de hardware que permiten definir uno o
varios procedimientos de control para cumplir una normativa y un objetivo de control.
Todos estos factores estn relacionados entre s, as como la calidad de cada una o
con la de los dems. Cuando se evala el nivel de seguridad de sistemas en una
institucin o sociedad, se estn evaluando todos estos factores y se plantea un plan
de seguridad nuevo que mejore todos estos factores.
Llamaremos "plan de seguridad" a una estrategia planificada de acciones y proyectos

que lleven a un sistema de informacin y sus centros de procesos de una situacin
inicial determinada (y a mejorar) a una situacin mejorada.
63
3.6
Metodologas de evaluacin de sistemas
3.6.1 Conceptos fundamentales
En el mundo de la seguridad de los sistemas se utilizan todas las metodologas

necesarias para realizar un plan de seguridad adems de las de auditoria
informtica.
Las dos metodologas de evaluacin de sistemas por antonomasia son las de

"anlisis de riesgo" y las de "auditoria informtica" con dos enfoques distintos. La
auditoria informtica solo identifica el nivel de exposicin por la falta de controles,
mientras el anlisis de riesgos facilita la evaluacin de los riesgos y recomienda
acciones en base al costo-beneficio de las mismas.
Introduzcamos una serie de definiciones para profundizar en estas metodologas.
Amenaza: una(s) persona(s) o cosa(s) vista(s) como posible fuente de peligro o

catstrofe. Ejemplos: inundacin, incendio, robo de datos, sabotaje, falta de
procedimientos de emergencia, aplicaciones mal diseadas, etc.
Vulnerabilidad: la situacin creada, por la falta de uno o varios controles, con la que
la amenaza pudiera acaecer y as afectar el entorno informtico. Ejemplos: falta de
control de acceso lgico, falta de control de versiones inexistentes de un control de
soportes magnticos, falta de separacin de entornos en el sistema, falta de cifrado
de las telecomunicaciones, etc.
Riesgo: la probabilidad de que una amenaza llegue a acaecer por una vulnerabilidad.
Ejemplo: los datos estadsticos de cada evento de una base de datos de incidentes.
64
Exposicin o impacto: la evaluacin del efecto del riesgo. Ejemplo: Es frecuente

evaluar el impacto en trminos econmicos, aunque no siempre lo es, como vidas
humanas, imagen de la empresa, honor, defensa nacional, horas-hombre, etc.
Las amenazas reales se presentan de forma compleja y son difciles de controlar,

sobre todo si no estn en nuestras manos. Por ejemplo factores externos como los
meteorolgicos.
Todos los riesgos que se presentan podemos:
Evitarlos: por ejemplo, no construir un centro de cmputo donde hay peligro de

constantes inundaciones.
Transferirlos: por ejemplo, uso de housing para servidores.
Reducirlos. Por ejemplo, sistemas de deteccin y extincin de incendios.
Asumirlos. Que es lo que se hace si no se controla el riesgo en absoluto.
Para los tres primeros, se acta si se establecen controles o contramedidas. Todas

las metodologas existentes en seguridad de sistemas van encaminadas a establecer
y mejorar un entramado de contramedidas que garanticen que la probabilidad de que
las amenazas se materialicen en hechos (por falta de control) sea lo ms baja
posible o al menos quede reducida de una forma razonable en costo-beneficio.
3.6.2 Tipos de metodologas
Todas las metodologas existentes desarrolladas y utilizadas en la auditoria y el

control informtico, se pueden agrupar en dos grandes familias. Estas son:
Cuantitativas: Basadas en un modelo matemtico numrico que ayuda a la

realizacin del trabajo.
Cualitativas: Basadas en el criterio y raciocinio humano capaz de definir un

proceso de trabajo, para seleccionar en base a la experiencia acumulada.
65
3.6.2.1 Metodologas cuantitativas
Diseadas para producir una lista de riesgos que pueden compararse entre si con
facilidad por tener asignados unos valores numricos. Estos valores en el caso de
metodologas de anlisis de riesgos o de planes de contingencias son datos de
probabilidad de ocurrencia (riesgo) de un evento que se debe extraer de un registro
de incidencias donde el nmero de incidencias tienda al infinito o sea suficientemente
grande. Esto no pasa en la prctica, y se aproxima ese valor de forma subjetiva
restando as rigor cientfico al clculo. Pero dado que el clculo se hace para ayudar
a elegir el mtodo entre varias contramedida podramos aceptarlo.
Hay varios coeficientes que conviene definir.
A.L.E. (Annualized Loss Expantacy): multiplicar la prdida mxima posible de

cada bien/recurso por la amenaza con probabilidad ms alta.
Reduccin del A.L.E.: Es el cociente entre el costo anualizado de la instalacin

y el mantenimiento de la medida contra el valor total del bien/recurso que se
esta protegiendo, en tanto por ciento.
Retorno de la inversin (R.O.I.): ALE original menos el ALE reducido (como

resultado de la medida), dividido por el costo anualizado de la medida.
Todos estos coeficientes y otros diseados por los autores de las metodologas son
usados para el juego de simulacin que permite elegir entre varias contramedidas en
el anlisis de riesgos.
Por tanto se ve con claridad dos grandes inconvenientes que presentan estas
metodologas: por una parte la debilidad de los datos de la probabilidad de
ocurrencia por los pocos registros y la poca significacin de los mismos a nivel
mundial, y por otro, la imposibilidad o dificultad de evaluar econmicamente todos los
66
impactos que pueden acaecer frente a la ventaja de poder usar un modelo

matemtico para el anlisis.
3.6.3 Metodologas cualitativas/subjetivas
Basadas en mtodos estadsticos y lgica borrosa (humana, no matemtica, FUZZY

LOGIC). Precisan que se involucre un profesional experimentado.
La tendencia de uso en la realidad es una mezcla de ambas. En la figura siguiente se
observa un cuadro comparativo.
67
Cuantitativa
Cualitativa/Subjetiva
Enfoca pensamientos mediante el uso

de nmeros.
P
R
Enfoque lo amplio que se desee
Facilita la comparacin de
Plan de trabajo flexible y
vulnerabilidades muy distintas.
reactivo.
Proporciona una cifra justificante
Se concentra en la identificacin
para cada contramedida.
de eventos.
O
S
Incluye factores intangibles.

Estimacin de probabilidad depende
de estadsticas fiables inexistentes.
Depende fuertemente de la
habilidad y calidad del personal
involucrado.
Puede excluir riesgos
C
O
N
Estimacin de las prdidas
significantes desconocidos
potenciales slo si son valores
(depende de la capacidad del
cuantificables.
profesional para usar el check-
list/gua)
Identificacin de eventos reales
A
S
ms claros al no tener que
Metodologas estndares.
aplicarles probabilidades
complejas de calcular
Difcil de mantener o modificar.
Dependencia de un profesional
Dependencia de un profesional.
Tabla 3.2: Pros y contras de las metodologas cuantitativas y cualitativas.

Fuente: Referencia del libro Auditoria informtica. Un enfoque practico. Mario G Piattini y Emilio del
Peso.
68
3.6.4 Metodologas ms comunes

Las metodologas ms comunes de evaluacin de sistemas que podemos encontrar
son de anlisis de riesgos o de diagnsticos de seguridad, las de plan de
contingencias, y las de auditoria de controles generales.
3.6.4.1 Metodologas de anlisis de riesgos
Estn desarrolladas para la identificacin de la falta de controles y el establecimiento

de un plan de contramedidas. Existen las cuantitativas y las cualitativas, de las que
existen una gran cantidad de ambas clases y solo citaremos algunas de ellas.
Es esquema bsico de una metodologa de anlisis de riesgos es en esencia el

representado en la figura siguiente
Figura 3.2: Esquema bsico de una metodologa de anlisis de riesgos.

Fuente: Auditoria informtica: un enfoque practico de Mario G Piattini y Emilio del Peso. Elaboracin
Propia.
En base a unos cuestionarios se identifican vulnerabilidades y riesgos y se evala el

impacto para ms tarde identificar las contramedidas y el costo. La siguiente etapa
es la ms importante, pues mediante un juego de simulacin (el Que Pasa Si...)
analizamos el efecto de las distintas contramedidas en la disminucin de los riesgos
69
analizados, eligiendo de esta manera un plan de contramedidas (plan de seguridad)

que compondr el informe final de la evaluacin.
De forma genrica las metodologas existentes se diferencian en:
Si son cuantitativas o cualitativas, o sea para el Que Pasa Si?... utilizan un

modelo matemtico o algn sistema cercano a la eleccin subjetiva. Aunque,
bien pensado, al aproximar las probabilidades por esperanzas matemticas
subjetivamente, las metodologas cuantitativas, aunque utilicen aparatos
matemticos en sus simulaciones, tienen un gran componente subjetivo.
Y adems se diferencian en el propio sistema de simulacin.
Dentro de las muchas metodologas que han sido analizadas por muchos
fabricantes y consultores a travs del mundo estn: ANALIZY, BDSS, BIS ISK
ASSESOR, BUDDY SYSTEM, COBRA, CRAMM, DDIS MARION AP+,
MELISA, RISAN, RISKPAC, RISKWATCH y la espaola MAGERIT.
Pero para efectos de este trabajo de investigacin se tomar la metodologa PRIMA

(Prevencin de riesgos informticos con metodologa abierta). Esta metodologa es
un compendio de metodologas espaolas desarrolladas entre los aos 1990 y la
actualidad con un enfoque subjetivo. Sus caractersticas son:
Cubrir las necesidades de los profesionales que desarrollan cada uno de los
proyectos necesarios de un plan de seguridad.
Fcilmente adaptable a cualquier tipo de herramienta.
Posee cuestionarios de preguntas para la identificacin de debilidades o falta

de controles.
Posee listas de ayuda para los usuarios menos experimentados de

debilidades riesgos y contramedidas (sistema de ayuda).
Permite fcilmente la generacin de informes finales.
70
Las Listas de ayuda y los cuestionarios son abiertos, y por lo tanto es posible
introducir informacin nueva o cambiar la existente. De ah la expresin
Abierta de su nombre.
Tiene un Que Pasa Si...? cualitativo, y capacidad de aprendizaje al poseer

una base de conocimiento o registro de incidentes que van variando las
esperanzas matemticas de partida y adaptndose a los entornos
Fases de metodologa prima
Siguiendo esta metodologa, y apuntando al desarrollo de este trabajo de

investigacin en conjunto con los sistemas y funcionamiento de la sociedad
estudiada es que seguimos las siguientes metodologas y resultados existentes y
esperados:
Anlisis de riesgos
Plan de contingencias informtico y recuperacin de negocio
Plan de restauracin interno informtico
Clasificacin de la informacin
Definicin y desarrollo de procedimiento de control informtico
Plan de Cifrado
Auditoria informtica
Definicin y desarrollo de control de acceso lgico. Entornos distribuidos y
single sig-on
3.7
Control interno
informtico. Sus mtodos
y procedimientos. Las
herramientas de control.
3.7.1 La funcin de control
Hoy en da la tendencia generalizada es contemplar, al lado de la figura del auditor

informtico, la de control interno informtico.
71
Aunque hay una cierta polmica profesional con esta funcin y no existe una
aceptacin tan clara como la funcin de auditoria informtica, parece razonable y sin
intencin de crear doctrina definirla como existe en general en muchas
multinacionales.
La funcin de Control informtico Independiente debera ser en primer lugar

independiente del departamento controlado. Ya que "por segregacin de funciones la
informtica no debera controlarse a si misma". Partiendo de la base de un concepto
en el que la seguridad de sistemas abarca un campo mucho mayor de lo que es la
seguridad lgica podramos decir que:
El rea informtica monta los procesos informticos seguros
El control interno monta los controles
la auditoria informtica evala el grado de control
Por tanto podramos decir que existen claras diferencias entre las funciones de
control informtico y las de auditoria informtica
La auditoria informtica
Tiene la funcin de vigilancia y evaluacin mediante dictmenes , y todas sus

metodologas van encaminadas a esta funcin
Tiene sus propios objetivos distintos a los auditores de cuentas, aunque

necesarios para que estos puedan utilizar la informacin de sus sistemas para
sus evaluaciones financieras y operativas.
Evalan eficiencia, costo y seguridad en su ms amplia visin, esto es todos

los riesgos informticos, ya sean los clsicos (confidencialidad, integridad y
disponibilidad), o los costos y los jurdicos, dado que ya no hay una clara
separacin en la mayora de los casos
Operan segn el plan auditor
72
Utilizan metodologas de evaluacin del tipo cualitativo con la caracterstica de

las pruebas de auditoria
Establecen planes quincenales como ciclos completos
Sistemas de evaluacin de repeticin de la auditoria por nivel de exposicin

del rea auditada y el resultado de la ltima auditoria de esta rea
La funcin de soporte informtico de todos los auditores (opcionalmente),

aunque dejando claro que no se debe pensar con esto que la auditoria
informtica consiste en esto solamente.
Control interno informtico.
Tiene funciones propias (administracin de la seguridad lgica, etc.)
Funciones de control dual con otros departamentos
Funcin normativa y del cumplimiento del marco jurdico
Operan segn procedimientos de control en los que ven involucrados y que

luego se desarrollaran.
Al igual que en la auditoria y de forma opcional pueden ser el soporte

informtico de control interno no informtico
Se puede pasar a proponer funciones de control interno ms comunes:
Definicin de propietarios y perfiles segn "Clasificacin de la informacin"

(utilizando metodologa)
Administracin delegada en Control Dual (dos personas intervienen en una

accin como medida de control) de la seguridad lgica.
Responsable del desarrollo y actualizacin del Plan de Contingencias,

Manuales de procedimientos y Plan de Seguridad.
Promover el Plan de Seguridad informtica al Comit de Seguridad.
Dictar Normas de Seguridad informtica
Definir Normas de Seguridad informtica
Definir procedimientos de Control

73
Control del Entorno de Desarrollo
Control de Soportes Magnticos segn la Clasificacin de la informacin
Control de Soportes Fsicos (Listados, etc.)
Control de informacin comprometida o sensible
Control de microinformtica y usuarios
Control de calidad de software
Control de calidad del servicio informtico
Control de costos
Responsable del departamento (gestin de recursos humanos y tcnicos)
Control de licencias y relaciones contractuales con terceros
Control y manejo de claves de cifrado
Relaciones externas con entidades relacionadas con la seguridad de la

informacin
Definicin de requerimientos de seguridad en proyectos nuevos
Vigilancia del cumplimiento de normas y controles
Control de cambios y versiones
Control de paso de aplicaciones a explotacin
Control de medidas de seguridad fsica o corporativa en la informtica
Responsable de datos personales (Cdigo Penal)
Controles y funciones que se le designen.
Todas estas funciones son un poco ambiciosas para desarrollarlas desde el instante
inicial de la implementacin de esta figura, pero no se debe perder el objetivo de que
el control informtico es el componente de la "actuacin segura" entre los usuarios, la
informtica y control interno todo ellos auditados por auditoria informtica.
74
3.7.2 Metodologas de clasificacin de la informacin y de obtencin de los

procedimientos de control
Obtencin de los procedimientos de control
Es frecuente encontrar manuales de procedimientos en todas las reas de la

empresa que explican las funciones y como se realizan las distintas tareas
diariamente, siendo estos necesarios para que los auditores realicen sus revisiones
operativas, evaluando si los procedimientos son correctos y estn aprobados y sobre
todo si se cumplen.
Pero desde el punto de vista informtico se debe preguntar si estos procedimientos

son suficientes y como se pueden arreglar.
La respuesta las da la metodologa que se expone a continuacin que dar el plan de

accin a seguir.
Metodologa
Fase I. Definicin de objetivos de control. Se compone de tres tareas.
Tarea 1. Anlisis de la empresa. Se estudian los procesos, organigramas y

funciones.
Tarea 2. Recopilacin de estndares. Se estudian todas las fuentes de informacin
necesarias para conseguir definir en la siguiente fase los objetivos de control a
cumplir.
Tarea 3. Definicin de objetivos de control
75
Fase II Definicin de los Objetivos de Control
Tarea 1. Definicin de los Controles: Con los objetivos de control definidos

analizamos los procesos y vamos definiendo los distintos controles que se necesiten.
Tarea 2. Definicin de Necesidades Tecnolgicas (hardware y herramientas de
control).
Tarea 3. Definicin de las necesidades de recursos humanos.
Fase III Implementacin de los controles
Una vez definidos los controles, las herramientas de control y los recursos humanos
necesarios, no resta ms que implementarlos en forma de acciones especficas.
Terminado el proceso de implementacin de acciones habr que documentar los

procedimientos nuevos y revisar los afectados de cambio. Los procedimientos
resultantes sern:
Procedimientos propios de control de la actividad informtica (control interno)
Procedimientos de distintas reas usuarias de informtica, mejoradas.
Procedimientos de reas informticas, mejoradas.
Procedimientos de control dual entre control interno informtico y el rea

informtica, los usuarios informticos, y el rea de control no informtico.
3.7.3 Las herramientas de control
En la tecnologa de la seguridad informtica que se ve envuelta en los controles,

existe tecnologa hardware (como los cifradores) y software. Las herramientas de
control son elementos de software que por sus caractersticas funcionales permiten
vertebrar un control de una manera ms actual y ms automatizada. Pero no
olvidemos que la herramienta en si misma no es nada.
Recordemos que el control se define en todo un proceso metodolgico, y en un punto
del mismo se analiza si existe una herramienta incluida, y al final documentar los
76
procedimientos de las distintas reas involucradas para que estas los cumplan y
sean auditados. O sea, que tener una herramienta sin mas y ver que se podra hacer
con esta es un error profesional grave, que no conduce nada, comparable a trabajar
sin mtodo e improvisando en cualquier disciplina informtica.
Las herramientas de control (software) ms comunes son las de:
Seguridad Lgica del sistema
Seguridad lgica complementaria al sistema (desarrollado a medida)
Seguridad lgica para entornos distribuidos.
Control de acceso fsico. Control de presencia
Control de copias.
Control de Soportes magnticos.
Gestin y control de impresin y envos de listados por la red.
Control de proyectos.
Control de versiones.
Control y gestin de incidencias.
Control de cambios.
Etc.
Todas estas herramientas estn inmersas en controles nacidos de unos objetivos de

control y que regulan la actuacin de las distintas reas involucradas. Por ejemplo, si
el objetivo de control es "separacin de entornos entre desarrollo y produccin",
debera haber un procedimiento en desarrollo de "paso de aplicaciones a
explotacin" y otro en explotacin de "paso de explotacin de aplicaciones de
desarrollo". Soportado todo por una herramienta de control de acceso lgico que en
un proceso de clasificacin ha definido distintos perfiles en desarrollo y explotacin, y
tras implementarlo en la herramienta, impide acceder a unos y a otros al entorno que
no es el suyo. Por lo tanto, para pasar una aplicacin de uno a otro cuando esta
terminada, se necesita un procedimiento en el que intervengan las dos reas y un
control informtico que acta de llave.
77
CAPITULO IV
PRESENTACIN DE LA EMPRESA
La empresa en estudio esta insertada en el rubro del retail de artculos de oficina

iniciando su operacin en Chile en el ao 1993 entregando un servicio integral en el
Abastecimiento de Productos de Oficina y Soluciones Logsticas en el servicio de
custodia, administracin y distribucin de productos no estratgicos a clientes
corporativos, tales como impresos, formularios, artculos de merchandising, etc.
En enero del ao 2003, pasa a ser parte de un consorcio internacional, que agrupa
ms de 200 empresas en el rubro Distribucin y Retail. En este contexto, la empresa
en estudio se desarrolla llegando a ser 100% profesionalizada y cuyos ejecutivos
reportan a un directorio internacional.
La plataforma tecnolgica con que cuenta esta empresa es nica y esta construida
en asociacin entre los sistemas informticos, los soportes Web y la logstica de la
cadena de abastecimiento.
4.1. Plataforma Operativa
La empresa en estudio cuenta con una plataforma operativa basada en PC`s de

usuarios con sistema operativo Windows 98 SE y XP, siendo la primera la usada por
el comn de los usuarios. Esto se debe a que el ERP usado y creado para la
empresa esta desarrollado en Clipper 5.01.
La intranet es administrada bajo plataforma Operativa Novell va Advantage

Management Utility brindando la conexin y administracin de archivos compartidos
y red de usuarios, adems de los sistemas de e-commerce.
El sistema computacional de la empresa, cubre el 100% de las actividades

comerciales, logsticas y administrativas, apoyando la labor comercial y entregando
78
informacin relevante tanto para la operacin interna como para la gestin de cada
empresa que opere con esta, destacndose los siguientes reportes:
Consumos por centros de costo
Generacin y mantencin de O/C
Detalle de artculos adquiridos por perodo
Registro de pedido habitual
Detalle de cuenta corriente en lnea
Cdigos de barra por cada tem y bulto a despachar.
Peso especfico de cada producto y pedido
Lectura automtica de rdenes de pedidos, etc.
Por otro lado, la empresa dispone de su propio Portal de Compras en Lnea para
hacer pedidos por Internet, estando el sistema en lnea con su sistema ERP,
manejando desde clientes comunes a corporativos, work flow de aprobaciones por
cada jefatura o centro de costo, coordinadores de compras, control de presupuestos,
control y administracin del gasto en tiempo real, listas de productos adjudicadas,
etc.
Adems de esto, la empresa cuenta con un sistema operativo Novell 5.1 el cual sirve
para los ambientes de desarrollo, produccin, pruebas y como base operativa para
las redes de usuarios e impresin.
79
4.2. reas dentro de la empresa
La empresa cuenta con las siguientes reas funcionales:
rea de finanzas
o Contabilidad
Tesorera
Rol de Pagos
o Crdito y Cobranza
rea de RRHH
rea de ventas
o Ventas
Asistencia BackOffice
Asistencia Venta y servicio al cliente
o Comercio
o Convenios
rea de marketing
o Compras
o Importaciones
o Marketing y Diseo
rea de Informtica
rea de Bodega
o Operaciones
Control de Operaciones
Centro de distribucin (papelera, Picking, granel)
Despacho
Recepcin
o Facturacin
80
4.3. Departamento Informtica
El departamento de informtica es un organismo dependiente de la gerencia general

encargada de mantener en un funcionamiento optimo las tecnologas de TI con las
que cuenta la empresa en estudio, as como la implementacin de nuevas
tecnologas aplicadas al desarrollo y servicio de la empresa en todos tus procesos.
4.4. Funciones de TI
Las reas de trabajo en TI dentro de la empresa en cuestin se dividen dentro de la

clasificacin, enfoque operacional y orientacin que brinda a la empresa el sistema
operativo Novel 5.1.
1. Tecnologas. Mantencin y prevencin
Apunta a mantener la disponibilidad de uso de los servidores, la red y los equipos

conectados a ella, para que las tareas apoyadas por los sistemas no se interrumpan
(servicio de uptime). Para esto se realizan mantenciones correctivas y preventivas de
hardware para mantener un servicio de soporte de servidores y red (se incluyen las
actividades que permiten administrar el servidor Novell) adems de la solucin de
problemas de usuarios individuales con respecto a hardware,
software (como
aplicaciones de oficina y ERP) y servicios (como Internet, intranet y correo

electrnico).
2. Operaciones y Soporte Usuarios
Esta rea busca solucionar problemas de usuario, capacitacin producto de la

operacin de los mdulos de los sistemas Clipper (ERP) y herramientas de software
de oficina y conectividad con las que cuentan todos los usuarios. Este soporte se
organizara como una mesa de ayuda, operando en forma preventiva y reactiva segn
el caso que se presente.
81
Adems de aplicar controles a la informacin y procesos para asegurar la calidad de

los datos. Tambin deben asegurase que el rea finanzas tenga la informacin
necesaria para cumplir con los cierres contables y los reportes a la casa matriz.
3. Desarrollo y Programacin Pginas Web
Esta rea se encarga del desarrollo en ambientes Web, datawarehouse y

programacin para la pgina Web. En general administrara cualquier proyecto o
requerimiento de los usuarios que requiera programacin, ya sea internos o clientes.
4. Mantencin Sistemas Clipper ERP
Encargados de la mantencin del sistema ERP dentro de la empresa, llevando a

cabo la recepcin, anlisis y desarrollo de los nuevos requerimientos que la empresa
necesita para la correcta continuidad operacional y del negocio de la empresa.
4.5. reas y Cargos
Se han definido las siguientes reas y cargos por rea.
1.- Tecnologa
Networking
Soporte Clipper & Networking
2.- Operaciones y Soporte Usuarios
Administrador de Operaciones y Soporte Usuarios.
Soporte de Operaciones y Usuarios.
82
3.- Desarrollo y Programacin Pgina Web.
Desarrollador Web
Supervisor de desarrollos.
4.- Mantencin Sistemas Clipper
Analista Programador Clipper
4.6. Organigrama TI
Gerente General
Jefe Informtica
Tecnologa
Operacin y
Soporte Usuario
Desarrollo y
programacin
pgina Web
Mantencin Sistema
Clipper
Figura 4.1: Organigrama del rea informtica de la empresa en estudio

83
4.7. Detalle de Cargos por Persona
rea
Cargo
Tecnologa
Networking
Soporte Clipper y Networking
Operaciones y Soporte
Administrador
Novell
Soporte
Desarrollo y Programacin
Desarrollador Web
Pginas Web ( Internet )
Desarrollos Internet
Sistemas Clipper
Analista Programador Clipper
Tabla 4.1: Detalle de cargos rea informtica empresa en estudio

Tecnologa
Encargado de las redes, en cuanto a hardware y software, involucrando servidores,

switch, router, sistemas operativos, sistemas de respaldos y seguridad.
Operacin y Soporte de Novell
Encargados del optimo funcionamiento de los equipos de los usuarios y sus

software instalados.
Velar por el ptimo control y funcionamiento de la mesa de ayuda.
Obtener el mejor tiempo de respuesta a las necesidades de los problemas de

los usuarios.
84
Desarrollo y Programacin de Pginas Web. (Internet)
Se encarga de la supervisin de los desarrollos externos, mantencin y

mejoras a los sistemas desarrollados en forma interna.
Controla los cambios efectuados por empresas de servicios.
Da soporte a usuarios internos y externos.
Sistemas Clipper
Velar por el ptimo funcionamiento de los sistemas actuales.
Entregar informacin y aclarar dudas a los nuevos usuarios de los sistemas,

dando nfasis en los informes gerenciales y estadsticos.
Desarrollo de nuevas aplicaciones y proponer nuevas mejoras de acuerdo a

las nuevas necesidades de la empresa.
Servicios Externalizados
Cableado de voz / Datos / Elctricos
Soporte y Mantencin Servidor Novell.
Servidor de correos
85
CAPITULO V
HERRAMIENTAS Y ANALISIS DEL ESTUDIO
5.1 Metodologa de estudio
Para el estudio de la situacin actual de la sociedad se recurri, entre otros mtodos,

a un pauteo de cosas que se debieran tener como mnimo dentro del funcionamiento
habitual dentro del rea informtica de la sociedad.
La revisin de la sociedad contempla los siguientes aspectos.
Manuales: se revisa la existencia y el estado de los siguientes tipos de manuales:
Manuales de procedimientos.
Manuales de uso de plataformas, tanto de usuarios como tcnicos.
Manuales tcnicos del uso de software y hardware.
Manuales de seguridad.
Manuales de operacin.
Otros.
Procedimientos: Se revisa la existencia y estado de los siguientes tipos de

procedimientos:
Procedimientos de contingencia.
Procedimientos generales de informtica.
Procedimiento de solicitudes de cuentas.
Procedimientos de actualizacin de sistemas.
Procedimientos de control interno dentro del rea informtica.
Procedimiento de respaldo y control de informacin.
Procedimientos estandarizados de seguridad de la informacin.
Procedimientos para la generacin de reportes de incidencias.
Otros.
86
Revisin de infraestructura: Se revisan las condiciones actuales de la sala de

servidores de la sociedad.
Polticas: Se revisan las distintas polticas informticas existentes como
Polticas de seguridad.
Polticas de uso de infraestructura informtica.
Polticas de acceso y uso de la informacin.
Otras
Metodologas: se revisan las actuales metodologas existentes, entre las cuales se

revisan:
Metodologas de trabajo dentro del rea informtica.
Metodologas de administracin de sistemas, controles de cambio y

requerimientos.
Metodologas del manejo de los recursos informticos. Atencin de

requerimiento de sistemas, software y hardware.
Otras
Para llevar a cabo esta revisin se procedi a realizar una serie de visitas a las
dependencias de la sociedad, teniendo la siguiente metodologa de trabajo:
Se pide la documentacin requerida, ya sea en formato digital o impreso, para

revisar el estado de esta, as como su nivel de formalizacin y actualizacin.
Se entrevista al personal del rea informtica de la sociedad acerca de cmo

se generan los documentos antes mencionados, como se realizan las
revisiones, aprobaciones y actualizaciones.
En el caso de las visitas a infraestructuras, se lleva un "check list" de las cosas

a revisar.
Se contrasta lo observado en las distintas visitas con lo obtenido en las

distintas entrevistas hechas al personal de la sociedad adems de las
conversaciones con el personal del rea informtica.
87
5.2 Estudio y anlisis
El estudio realizado a la sociedad consta de una recopilacin de datos en base a dos

grandes instancias definidas por los alumnos tesistas. La primera consta de una
encuesta realizada a un segmento de trabajadores de la empresa y la segunda
corresponde a visitas hechas a las instalaciones de la sociedad, realizando en estas,
encuestas personales y revisiones presenciales basados en la elaboracin de un
check list como pauta de revisin.
5.2.1. Encuesta a usuarios
Esta etapa consta de una serie de preguntas elegidas por los alumnos tesistas en
base a distintos tpicos que abarca este estudio con la finalidad de obtener una
mirada a la percepcin que tienen los usuarios de los sistemas informticos y el
funcionamiento del departamento, as como tambin evidenciar fallas en los que
pudiera estar cayendo el rea informtica de la sociedad en estudio.
Para esto, se decidi dividir la encuesta en secciones de modo de que al usuario no

se le haga tan tedioso poder responderla. Esta divisin consta de los siguientes
puntos:
Introduccin: Una breve descripcin del propsito de la encuesta junto con

las indicaciones para contestarla.
Preguntas Generales: Esta seccin consta de preguntas de orden general

para los usuarios, preguntas que apuntan ms al diario vivir dentro de la
sociedad.
Sistema: Esta seccin consta de preguntas relacionadas con la calidad del

sistema ERP con que cuenta la sociedad, la evaluacin del usuario respecto a
la herramienta as como tambin a la calidad y continuidad del servicio
entregado.
88
Soporte informtico: Esta seccin consta de preguntas relacionadas con la

calidad de atencin prestada por el rea de soporte informtico, as como las
formas en que se relacionan los usuarios al acudir al rea de soporte.
Nivel de satisfaccin: Esta seccin consta de preguntas apuntadas a

conocer el nivel de satisfaccin de los usuarios presentados ante las distintas
entidades que componen el rea informtica de la sociedad. Esta rea es
evaluada segn los patrones establecidos en las preguntas. Tambin se
recogen datos de vas de comunicacin con el rea informtica y
recomendaciones de los usuarios hacia el rea.
Esta encuesta fue confeccionada entre la semana del 18 y 31 de mayo por medio de
la herramienta Web www.encuestafacil.com y tomada durante el mes de junio,
siendo enviada a 60 usuarios de las diferentes reas de la sociedad.
5.2.1.1. Identificacin del pblico objetivo
El estudio se orient a analizar un grupo focalizado de personas que son las que
ocupan normalmente el sistema ERP con el que cuenta la sociedad. Son estas
personas las que estn en contacto diario con la aplicacin, piden soporte informtico
a nivel de software y hardware, adems de orientacin sobre los procesos que
realiza el ERP en el que hacer de la empresa.
5.2.1.2. Recoleccin de datos
Para la obtencin de los datos se recurri a la elaboracin de la encuesta por medio

de la herramienta Web proporcionada por el sitio www.encuestafacil.com .
Esta herramienta permite la creacin de encuestas moldendolas segn modelos

pre-hechos, por lo cual la encuesta se basa en un modelo de satisfaccin al cliente,
permitiendo la realizacin de preguntas con varias alternativas, de respuesta libre y
de matriz de evaluacin.
89
El cuestionario final es enviado a travs de un link por medio de correo electrnico

hacia los usuarios finales, quedando grabadas sus respuestas en una base de datos
relacional alojada en los servidores de la pgina.
Una vez cumplido los plazos estipulados para la recoleccin de los datos estos
pueden ser exportados de diferentes formas (csv para ser utilizados por spss o
Excel, mediante el navegador) eligiendo finalmente la entrega de resultados a travs
de grficos para Microsoft Excel.
El cuestionario final entregado al personal de la sociedad es el siguiente:
Introduccin
A continuacin se presentan una serie de preguntas sobre el funcionamiento del rea
informtica, tanto en servicios, polticas y metodologa. Al contestar estas preguntas
seleccione solo una de las alternativas la cual represente de mejor manera su
opinin o realidad. Adems hay preguntas en las cuales se les pide algn comentario
extra aparte de la opcin que elija; por favor responda en forma breve y clara.
Cabe sealar que esta encuesta es totalmente confidencial.
Preguntas Generales
A continuacin se presentan una serie de preguntas generales sobre su rea y su
trabajo. Por favor conteste todas las preguntas eligiendo la alternativa que ms
refleje su realidad
1. Sobre el funcionamiento dentro de mis obligaciones laborales y materiales de

apoyo, por ejemplo manuales de uso:
a. Tuve una capacitacin y me entregaron material de apoyo el cual me fue muy
til
b. Tuve una capacitacin y me entregaron material de apoyo, pero no entend su
contenido
90
c. Tuve una capacitacin pero no me entregaron material de apoyo

d. No tuve capacitacin, pero me entregaron material de apoyo
e. No recib ninguna capacitacin ni material de apoyo
2. Sobre los procedimientos generales dentro de su rea:

a. Estn claros, definidos, documentados y son de conocimiento pblico
b. Estn definidos y documentados, pero no son de conocimiento pblico
c. Estn definidos y documentados, pero no son del todo claros
d. Desconozco si es que existe algn procedimiento de trabajo en mi rea
e. No existe ningn procedimiento de trabajo en mi rea.
3. Cmo se entera de las principales actividades de su rea?

a. Leyendo documentos impresos establecidos por la empresa
b. Leyendo documentos enviados por e-mail establecidos por la empresa
c. Siendo informados verbalmente en una reunin del rea
d. Por un compaero o supervisor
e. Otro (Por favor especifique)
4. Sobre polticas de uso de los recursos informticos (ingreso al sistema,

herramientas de oficina como planillas de clculo, procesadores de texto, etc.,
correo, etc.):
a. Si, existen polticas y estn publicadas dentro de las oficinas
b. Si, existen polticas y son entregadas fsicamente al ingresar a la empresa
c. Si, existen polticas y son entregadas por medio digital (va correo)
d. Desconozco si existen polticas para el uso de recursos informticos
e. No, no existe ninguna poltica para el uso de recursos informticos
f. Otro (Por favor especifique)
91
5. Qu importancia tiene para Ud. los software de oficina (planillas de clculo,

procesadores de texto, correo, visor de imgenes, etc.) instalados en su equipo para
su trabajo diario
a. muy importantes
b. importantes
c. indiferente
d. baja
e. muy baja
6. Sobre el funcionamiento de las herramientas computacionales, por parte de

informtica al ingresar a su trabajo:
a. Tuve una capacitacin y me fue muy til
b. Tuve una capacitacin, pero muy breve
c. Tuve una capacitacin pero no entend su contenido
d. Mis compaeros de trabajo me ensearon a ocupar algunas herramientas
e. No recib ninguna capacitacin
7. Crees que los cables estn bien instalados y ordenados dentro de tu lugar de
trabajo?
a. Si, estn bien instalados y ordenados y s que cable es para que.
b. Si, estn bien instalados y ordenados, pero no se qu cable es para que
c. Si, estn bien instalados, pero desordenados
d. No, estn mal instalados y desordenados, pero puedo trabajar
e. No, estn mal instalados y desordenados interrumpiendo mi trabajo a cada
rato
92
Sistema
A continuacin se presentan preguntas relativas al sistema informtico de la
empresa.
8. Cmo calificara la plataforma informtica de trabajo (Clipper)

a. excelente, cubre todas mis necesidades
b. Muy buena, es una herramienta muy completa
c. Buena, me ayuda en mi trabajo, pero le agregara algunas funciones
d. Regular, sus funciones son complejas y es dificultoso trabajar con ella
e. Mala, no cubre ninguna de mis necesidades
9. Qu porcentaje de tiempo esta Ud. Con sistema?

a. del 90% al 100% del tiempo
b. del 80% al 90% del tiempo
c. del 70% al 80% del tiempo
d. del 50% al 70% del tiempo
e. menos al 50% del tiempo
10. Sabe ud si existe algn manual de uso de la plataforma operacional (Clipper)?

a. si, lo utilizo cada vez que tengo alguna duda del sistema
b. si, lo he ledo pero no lo ocupo
c. si, lo he ledo pero no lo encuentro claro
d. s, pero no lo he ledo
e. No, desconozco si existe algn manual de uso.
11. Conoce los pasos a seguir para pedir algn cambio de equipo y/o programa de
su equipo?
a. SI
b. NO
93
12. Si su respuesta fue afirmativa indique si se genera algn documento (en papel o
va e-mail) al solicitar el cambio. Si su respuesta es NO indique el porqu.
13. Cuando hay una falla de sistema, cual es el tiempo de respuesta por parte de
informtica?
a. 30 min.
b. 1hr
c. 2hr
d. 4hr
e. 5hr o ms.
14. Cul es la efectividad de informtica para resolver los problemas de sistema?

a. Excelente
b. Muy buena
c. Buena
d. Regular
e. Mala
f. Muy mala
15. Conoces las medidas de seguridad que informtica a tomado para tu equipo?
a. S, tengo conocimiento de las medida de seguridad y estoy de acuerdo con
ellas
b. S, tengo conocimiento de las medida de seguridad pero no estoy de acuerdo
con ellas
c. Si, s que hay medidas de seguridad, pero las desconozco
d. Desconozco si existen medidas de seguridad para mi equipo
e. No existe ninguna medida de seguridad para mi equipo
94
16. Crees conveniente que los equipos estn protegidos con contraseas?
Fundamente su respuesta
Soporte Informtico
Por favor, a continuacin se presentan algunas preguntas sobre la atencin por parte
del rea informtica hacia usted. Piense en las experiencias que ha tenido y
responda las siguientes preguntas:
17. Al llamar al rea de soporte informtico:

a. Le piden sus datos y el problema que presenta
b. Solo le piden sus datos y van a revisar
c. Solo le piden el problema y van a revisar
d. Le piden sus datos y el problema y lo revisan remotamente
e. Le piden sus datos y el problema y le dicen que hacer para solucionarlo
18. Sobre el trato recibido por parte de informtica al hacer alguna peticin:
a. El trato es bueno y responden mis consultas en forma oportuna
b. El trato es bueno, pero se demoran en responder
c. El trato es regular, pero responden a mis consultas
d. El trato es regular y demoran en responder mis consultas
e. El trato es malo y no atienden mis consultas oportunamente
19. Cunto tiempo tuvo que esperar antes de poder hablar con alguien del rea de
soporte?
a. Inmediatamente
b. Menos de 3 minutos
c. Entre 3 y 5 minutos
d. Entre 5 y 10 minutos
e. Ms de 10 minutos
95
20. Cuando tiene algn problema con su equipo a quien pide ayuda?
a. A alguien de informtica
b. Al rea de soporte informtico
c. A algn compaero
d. A nadie
e. Otro (Por favor especifique)
21. Cuando ud. reporta un problema:

a. Este queda resuelto definitivamente
b. El problema queda solucionado temporalmente, volviendo a ocurrir al tiempo
despus
c. El problema queda resuelto, pero no del todo (el equipo no queda como
estaba antes)
d. El problema se resolver dentro del da, quedando durante este tiempo sin
equipo de trabajo.
e. El problema no queda resuelto.
22. Cuanto se demoran en atender algn problema con su equipo?

a. Van a los pocos (1 a 15 minutos) minutos que solicito atiendan mi problema
b. Van a los pocos (1 a 15 minutos) minutos que solicito atiendan mi problema
c. Van a las horas (entre 1 y 3 horas) despus que solicito atiendan mi problema
d. Ms de tres horas.
23. En total, cmo calificara el proceso hasta que se resolvi su problema?

a. Muy Bueno
b. Bueno
c. Neutro
d. Pobre
e. Muy Pobre
96
24. Sabe usted si le hacen mantencin a su equipo?

a. Si
b. No
25. Si su respuesta anterior es afirmativa, indique cada cuanto se realiza esta

mantencin
a. Semanalmente
b. Cada dos semanas
c. Mensualmente
d. Anualmente
e. Cuando surge algn problema
Nivel de satisfaccin
Las siguientes preguntas estn relacionadas con el nivel de satisfaccin que usted,
como usuario, tiene con respecto al rea informtica. Por favor, conteste las
preguntas siguientes segn sea su realidad y opinin. Por ltimo le pedimos que,
segn sus palabras, nos diga en que podemos mejorar para brindar un mejor
servicio.
28. De 1 a 5 (1 es muy malo, 3 es regular y 5 es muy bueno), cmo calificara el

tiempo de respuesta de la persona a quien le solicito asistencia sobre problemas con
la plataforma Clipper. Si a la (s) persona (s) que es nombrada como opcin usted
nunca le ha pedido ayuda, por favor seleccione la opcin "no aplica"
97
27.
De 1 a 5 (1 es muy malo, 3 es regular y 5 es muy bueno), cmo calificara el
tiempo de respuesta de la persona a quien le solicito asistencia sobre problemas con

su computador. Si a la (s) persona (s) que es nombrada como opcin usted nunca le
ha pedido ayuda, por favor seleccione la opcin "no aplica"
28. De estas dos preguntas anteriores; usted solicita asistencia va (puede

seleccionar ms de una opcin):
Correo electrnico
Va telfono
Hablando con alguien de informtica en persona.
Hablando con alguien ajeno a informtica en persona.
Va mensaje Novell (mensajera interna)
Otro (por favor especifique)
29. Por favor, dganos en que podemos mejorar.
98
5.3 Resultados Generales.
La recoleccin y visualizacin de los datos era en forma inmediata a travs de la

pgina de administracin de encuestafacil, lo que permite ir viendo el avance de la
encuesta, obteniendo los siguientes datos:
totales
total de personas en la em presa
total de personas que ocupan el sistem a
279
181
Tabla 5.1: Total de personas de la empresa.

Obteniendo as que las personas que ocupan el sistema, representan el 64,87 % del
total de la empresa, pasando a ser el 100 % de la muestra para efecto de la
encuesta.
totales
total de personas que ocupan el sistem a
total de encuestas enviadas
total de encuestas contestadas
% totales
181
60
50
33,15%
27,62%
Tabla 5.2: Totales Encuesta empresa.

Fuente: Elaboracin Propia
Se enviaron 60 encuestas del total de personas que ocupan el sistema, lo que

representa un 33,15% de stas, siendo respondidas 50 lo que correspondera a un
27,62% del total de personas que ocupan el sistema y el 83.33% de las encuestas
enviadas.
Los motivos de no haber obtenido el total de respuestas de las encuestas fueron el

no tener tiempo para responder y el olvido de las personas de responder o terminar
de responder las encuestas, adems de sentirse comprometidos con algunas
respuestas, a pesar de dejar en manifiesto que la encuesta era absolutamente
confidencial.
99
Al margen de los resultados obtenidos por respuesta, se observaron dentro de las

sugerencias (que no eran respuestas obligatorias) datos que pueden hacer una
especie de resumen de lo obtenido a lo largo de la encuesta, esto es:
Total de respuestas
Sub totales
50
Porcentaje
Comentario
26
52%
Tiempos de respuesta
8%
Mejoras de sistema
11
22%
Mejora de equipos
18%
Instructivos y Capacitacin
Tabla 5.3: Totales y subtotales encuesta.

El propsito de la encuesta, adems de reflejar el sentir de las personas que

conforman la sociedad en estudio hacia el rea informtica, es apoyar y reafirmar los
hallazgos hechos en la revisin presencial a las instalaciones de la sociedad.
5.4 Resultados destacados por categoras
Temas generales
Dentro de esta seccin se evidenci una clara ausencia de procedimientos y polticas
no solo a nivel informtico, si no que tambin dentro de todos los niveles de las reas
encuestadas. Es as como la definicin y publicacin de procedimientos de las reas
encuestadas arrojo un claro desconocimiento de documentos que existan en su
rea, o bien, si existen, no son claros o no se manejan a cabalidad.
100
Adems, se evidencia la poca estandarizacin para la difusin de estas polticas,

procedimientos o actividades esenciales de las reas de trabajo de la empresa
encuestada.
Sobre los procedimientos generales dentro de su area:
8%
Estn claros, definidos, documentados y son de

conocimiento pblico
18%
Estn definidos y documentados, pero no son de

conocimiento pblico
14%
40%
Estn definidos y documentados, pero no son del

todo claros
Desconozco si es que existe algn procedimiento de
trabajo en mi rea
20%
No existe ningn procedimiento de trabajo en mi
rea.
Grfico 5.1: Resultado de la encuesta para los procedimientos generales para las reas de la
empresa.
Cmo se entera de las principales actividades de su rea?
6%
24%
Leyendo documentos impresos establecidos

por la empresa
Leyendo documentos enviados por e-mail
establecidos por la empresa
28%
Siendo informados verbalmente en una

reunin del rea
Por un compaero o supervisor
42%
Otro (Por favor especifique)
Grfico 5.2: Resultado de la encuesta para la comunicacin de las principales actividades de las reas
de la empresa.
101
Un punto interesante dentro de esta seccin y que, compete directamente al rea

informtica, es la nula difusin de las polticas que el rea informtica tiene para el
uso de los recursos informticos para los usuarios de la sociedad en estudio. Es as
como se demuestra en el resultado siguiente obtenido de la encuesta:
Sobre polticas de uso de los recursos informticos (ingreso al sistema, herramientas

de oficina como planillas de calculo, procesadores de texto, etc. , correo, etc.):
30
25
20
15
10
5
0
Si, existen polticas y Si, existen politicas y Si, existen politicas y
Desconozco si
No, no existe ninguna
estn publicadas
son entregadas
son entregadas por existen politicas para politica para el uso de
dentro de las oficinas
fisicamente al
medio digital (via
el uso de recursos recursos informaticos
ingresar a la empresa
correo)
informaticos
Otro (Por favor

especifique)
Grfico 5.3: Resultado de la encuesta para las polticas del uso de los recursos informticos.
Sistemas
Dentro de esta seccin, si bien se evala de buena forma el funcionamiento, a
plataforma ERP y el up time de sistema, se evidencia una nula existencia de
manuales de uso, tanto a nivel de usuario como a nivel tcnico de la plataforma
operacional ERP como se ve en el siguiente grafico:
102
Sabe ud si existe algun manual de uso de la plataforma

operacional (clipper)?
50
45
40
35
30
25
20
15
10
5
0
si, lo utilizo cada
vez que tengo
alguna duda del
sistema
si, lo he ledo pero si, lo he ledo pero

no lo ocupo
no lo encuentro
claro
si, pero no lo he
ledo
no, desconozco si
existe algn
manual de uso.
Grfico 5.4: Resultado de la encuesta para la existencia de algn manual de uso de la plataforma
ERP.
Como calificara la plataforma informtica de trabajo (clipper)
11%
2%
excelente, cubre todas mis necesidades
6%
Muy buena, es una herramienta muy

completa
Buena, me ayuda en mi trabajo, pero le
agregara algunas funciones
36%
45%
Regular, sus funciones son complejas y

es dificultoso trabajar con ella
Mala, no cubre ninguna de mis
necesidades
Grfico 5.5: Resultado de la encuesta para la calificacin de la plataforma informtica.

103
Soporte
Si bien, la percepcin de que el rea
de soporte funciona de una forma
medianamente buena y oportuna, se destacan resultados que evidencian la falta de

control y documentacin de los procesos e incidentes diarios del rea informtica.
Adems, se evidencia un comportamiento y una estrategia ms bien reactiva que
preventiva ante los incidentes de usuarios, dejando la sensacin de que los planes
de contingencia no estn del todo definidos o implementados.
Los grficos siguientes demuestran estas conclusiones:
Al llamar al rea de soporte informtico:
4%
2% 2%
Le piden sus datos y el problema que

presenta
Solo le piden sus datos y van a revisar
9%
19%
Solo le piden el problema y van a revisar

Le piden sus datos y el problema y lo revisan
remotamente
Le piden sus datos y el problema y le dicen
que hacer para solucionarlo
64%
Grfico 5.6: Resultado de la encuesta para la forma de atencin del rea soporte informtico.
Preguntas
Cada cuanto se realiza esta mantencin?
Respuestas
Semanalmente
Cada dos semana
Mensualmente
Anualmente
Cuando surge algn problema
N
Respuesta Porcentaje
por pregunta respecto
al total
0
0%
0
0%
3
6%
2
4%
45
90%
50
100%
Tabla 5.4: Resumen de frecuencia de mantencin de equipos

Fuente: Elaboracin Propia
104
Nivel de Satisfaccin
Si bien esta seccin es de mayor importancia para el rea informtica, para su
anlisis y desglose interno, de ella se puede desprender un resultado que es menos
implcito que los anteriores; los medios y vas de comunicacin con el rea
informtica, evidenciando as una falta de norma o estandarizacin de canalizacin
de requerimientos de la empresa con el rea informtica.
Preguntas
De estas dos preguntas anteriores; usted solicita va asistencia: (puede
seleccionar mas de una opcin)
Respuestas
Va Correo electrnico
Va telfono
Hablando con alguien de informtica en persona
Hablando con alguien ajeno a informtica en persona
Va mensaje Novell
N
Respuesta
por
pregunta
34
43
27
1
5
0
110
Porcentaje
respecto
al total
31%
39%
25%
1%
5%
0%
100%
Tabla 5.5: Resumen de Vas de comunicacin con el rea informtica

Para ver el detalle numrico de toda la encuesta revisar el Anexo 2.
105
5.5 Check List para las revisiones a la empresa.
En un principio, el estudio tena contemplado un cuestionario para ser entregado al

personal de informtica, para que ellos lo respondieran y as poder contrastar sus
respuestas con las entregadas por el personal de la sociedad. Se fijo un cuestionario
y se fijo el plazo de un mes para que fuese contestado. Esto no sucedi como se
esperaba, siendo respondidas solamente 1 de 5 encuestas, lo que representa
solamente el 20 % de la poblacin total del rea informtica, cuando se esperaba el
100 % (o sea que las cinco personas que trabajan en el rea informtica
respondieran la encuesta).
Ante la situacin que se presentaba se decidi abordar una estrategia diferente, por
lo cual se decidi realizar una serie de visitas a las instalaciones de la sociedad con
el fin de revisar en terreno los temas que estn relacionados con el estudio. As,
adems, se obtendran datos directamente de la fuente, por lo que la percepcin de
veracidad de la informacin entregada por parte de los usuarios seria notablemente
ms sustentable.
Es as como se elaboro el check list que se muestra en el anexo 1.
5.6 Informe con observaciones de control interno y recomendaciones de

mejora
En el presente informe, se utilizar una categorizacin de riegos, segn sean estos

de impacto alto, medio o bajo.
Riesgos Altos: No se han diseado los controles, que permitan una efectividad
operacional adecuada desde un mbito de Control interno, o su efecto potencial es
significativo.
106
Riesgos Medios: Los controles han sido diseados, pero requieren mejoras en su
diseo y/o no operan en forma efectiva.
Riesgos Bajos: Si bien existen controles, estos
podran ser mejorados
contribuyendo al sistema de mejoramiento contino de la empresa.
Las debilidades y su impacto se presentan de manera resumida en la siguiente tabla

llamada Resumen de hallazgos. Cada debilidad tiene asociado un impacto
potencial, categorizado como sigue:
Objetivos estratgicos: El hallazgo afecta especialmente la consecucin de los

objetivos y planes estratgicos definidos por la administracin.
Cumplimiento: El hallazgo afecta especialmente aspectos relacionados con el

cumplimiento normativo, regulatorio o interno.
Operacin: El hallazgo afecta especialmente la eficacia o eficiencia de los procesos

internos.
En el siguiente cuadro se detallan todas las debilidades encontradas en conjunto con

sus respectivos impactos, as como nuestra percepcin del riesgo asociado junto con
las recomendaciones de mejora.
107
PROCESO
HALLAZGO
OBJETIVOS
ESTRATEGICOS
CUMPLIMIENTO
Inexistencia de un manual de descripcin de cargos
OPERACION
RIESGO
ALTO
No existe un rea de auditoria interna local encargada de la

2
evaluacin y mejoramiento de los procedimientos de control
MEDIO
interno.
3
La sociedad no documenta las reuniones efectuadas por el

comit de informtica.
Inexistencia de una estandarizacin en la administracin de
la captura de requerimientos de cambios a los sistemas
Inexistencia de un ambiente de desarrollo segregado del
ambiente Web y ambiente de Produccin
Deficiencias de control sobre el registro y almacenaje de
respaldos de informacin.
Inexistencia de revisiones peridicas a las cuentas de
usuarios y sus perfiles.
BAJO
BAJO
ALTO
MEDIO
MEDIO
BAJO
MEDIO
Inexistencia de un estndar de documentacin en la

8
programacin del cdigo fuente del sistema ERP y Web de

la sociedad
Inexistencia de plan de pruebas a los registros del sistema

Web y Productivo
108
OBJETIVOS
ESTRATEGICOS
PROCESO
HALLAZGO
10
Falta de evidencia de aprobaciones sobre las modificaciones

a aplicaciones.
11
12
13
14
15
16
17
18
19
20
21
Inexistencia de manuales de usuarios y tcnicos

actualizados.
Inexistencia de polticas de seguridad de la informacin
Inexistencia de manuales de operacin de sistemas.
Inexistencia de plan de contingencias
Inexistencia de metodologa formal de administracin de
requerimientos de cambios y mantenciones
CUMPLIMIENTO
OPERACION
RIESGO
BAJO
BAJO
ALTO
ALTO
Inexistencia de procedimientos formales para la creacin,

mantencin y eliminacin de cuentas de usuario del sistema
ERP y Red
Inexistencia de una estandarizacin en la administracin de
la captura de requerimientos de cambios de Software y
Hardware
Inexistencia de un procedimiento formal para la creacin,
mantencin y eliminacin de cuentas de usuarios del
sistema ERP
La sociedad no cuenta con un plan estratgico formal de
mediano y largo plazo
Inexistencia de un diagrama de sistema y servidores
Falta de control y administracin sobre los software y
herramientas de monitoreo de la sociedad
ALTO
BAJO
ALTO
MEDIO
ALTO
BAJO
BAJO
MEDIO
Tabla 5.6: Resumen de hallazgos y riesgos encontrados en la Empresa.

109
5.6.1. Informe detallado de Hallazgos y Recomendaciones segn el Caso

1. Inexistencia de un manual de descripcin de cargos
Nivel de Riesgo:
Alto.
Riesgo:
Incremento del riesgo de que el personal realice procedimientos propios o asuma
responsabilidades distintas a las esperadas.
Descripcin del problema:

Durante las visitas y el estudio se pudo constatar que si bien existen algunos
avances en materia de descripcin de cargos para el personal, es necesario
desarrolla un trabajo general que involucre todos los involucrados en el rea, lo cual
permitir entre otros aspectos, aumentar la eficiencia operativa y delimitar
responsabilidades.
Dicha descripcin de cargos debiera contener a los menos: nombre, del cargo,
descripcin del mismo, detalle de las operaciones a realizar, cargo al que debe
reportar, cargos subordinados y nivel tcnico requerido.
Impacto:
Operacin.
Acciones / Recomendaciones:
Completar el proceso de descripcin de cargos a nivel de toda el rea informtica
110
2. No existe un rea de auditoria interna local encargada de la evaluacin y

mejoramiento de los procedimientos de control interno.
Nivel de Riego:
Medio.
Descripcin del Problema:

De la revisin a la sociedad de nota que no cuenta con un departamento de Auditora
Interna. Consideramos importante recomendar la implantacin de dicha unidad
orientada a fortalecer el control
interno y mejorar la eficiencia operativa de la
sociedad. Algunos aspectos de inters a ser considerados por esta Unidad, entre
otros, son:
Dependencia jerrquica de la direccin superior
Personal idneo para las labores de evaluacin, implantacin y control de

procedimientos
Plan de auditoria formal que detalle las reas a cubrir, los objetivos, alcances
y resultados del trabajo realizado.
Conocimiento de polticas, responsabilidades, alcance de las tareas y el

desempeo de los distintos departamentos.
Coordinacin de esfuerzos con los auditores externos.
Riesgos:
El no contar con un departamento de auditoria interna, obstaculiza que la alta
administracin logre hacer un seguimiento ms eficaz de la situacin y el grado de
mejora de sus controles operacionales y de negocio.
Impacto:
Cumplimiento.
111
Evaluar la creacin e implementacin de un rea de auditoria interna dentro de la
sociedad.
3. La sociedad no documenta las reuniones efectuadas por el comit de

informtica.
Nivel de Riesgo:
Bajo

Durante la revisin de constato que no existe ningn registro formalizado, mediante
minutas u otro documento, en el cual se registren las reuniones efectuadas por el
comit de informtica, conformado por responsables del rea IT y las distintas reas
usuarias.
En este sentido la existencia de minutas de reuniones permitira a la sociedad

mantener un registro y evidenciar las resoluciones adoptadas por el comit, las
responsabilidades adquiridas, temas tratados, plazos para efectuar las actividades y
tareas definidas.
Riesgo:
Responsabilidades, plazos y tareas adquiridas en el comit podran eventualmente
no cumplirse.
Impacto:
Cumplimiento
Generar y mantener minutas de las reuniones efectuadas por el comit de
informtica.
112
4. Inexistencia de una estandarizacin en la administracin de la captura de

requerimientos de cambios a los sistemas
Nivel de Riesgo:
Bajo

Durante la revisin a los procedimientos de modificaciones a los sistemas de
informacin, se observo que no existe una estandarizacin en la administracin de la
captura de requerimientos de cambios a los sistemas.
Actualmente los requerimientos de cambio o modificaciones a los sistemas, se

realizan mediante correo electrnico o va telefnica, ya que si bien, se ha
desarrollado un formulario estndar para la realizacin de la captura de informacin,
este aun no ha sido incorporado al procedimiento de modificacin de sistemas de la
sociedad en estudio.
Riesgo:
Solicitudes o requerimientos no autorizados.
Impacto:
Cumplimiento.
Formalizar y difundir el nuevo formulario de requerimientos de cambios de sistemas
con el fin de ser utilizado en la administracin de modificaciones a los sistemas de
informacin.
113
5. Inexistencia de un ambiente de desarrollo segregado del ambiente Web y

Productivo.
Nivel de Riesgo:
Alto

Durante la visita se efectu una revisin a la segregacin de los ambientes de
desarrollo, pruebas, produccin y Web, observando que solo se utilizan los
servidores que mantienen los ambientes productivos y desarrollo, los cuales son
utilizados para realizar desarrollos y pruebas sobre las modificaciones realizadas a
las aplicaciones.
Riesgo:
Acciones no autorizadas sobre programas y datos en los sistemas de produccin y
Web podran ser realizadas por personal no autorizado. Riesgo de un manejo
indebido de la informacin al no tener un ambiente separado de produccin y Web.
Adicionalmente la informacin contenida en los sistemas podra no ser confiable.
Impacto:
Cumplimiento.
Definir un ambiente de desarrollo WEB segregado, con el objeto de no modificar los
sistemas de informacin, funciones y diseo directamente en este ambiente.
114
6. Deficiencias de control sobre el registro y almacenaje de respaldos de

informacin
Nivel de Riesgo:
Medio.

Durante la revisin, observamos las siguientes debilidades:
Las cintas magnticas que poseen el respaldo de la informacin diaria no son

almacenadas en un lugar seguro, ya que actualmente estn son depositadas
en dependencias de la sociedad sin el resguardo necesario.
Las cintas magnticas que poseen el respaldo de la informacin de cierre de

mes son almacenadas dentro de las dependencias de la sociedad hasta que
son entregadas a la empresa que las guarda, no llevando un registro de:
o quien entrega la cinta
o a quien le entrega la cinta
o firmas del receptor y del depositante.
o Fecha y hora en que se produce la entrega.
Comunicacin a los dems entes del departamento de que se ha entregado la

cinta.
Los respaldos realizados no son probados
Riesgo:
Eventual mantencin de respaldos con informacin daada. No probar los respaldos
podra ocasionar problemas al momento de requerir su restauracin.
Impacto:
Cumplimiento
115
Almacenar, registrar y probar adecuadamente los respaldos de informacin de la
sociedad con el objeto de garantizar razonablemente que la informacin se
encuentre protegida frente a situaciones de contingencia. Probar un servidor de
prueba con la informacin respaldada para ver si carga de buena forma puede ser
una solucin.
7. Inexistencia de revisiones peridicas a las cuentas de usuarios y sus

perfiles.
Nivel de riesgo:
Medio

Durante la revisin correspondiente a la asignacin de perfiles, se observa que no
existe una revisin peridica por parte de los responsables de cada rea de negocio
a las cuentas de usuarios con sus respectivos perfiles existentes en las aplicaciones
de la compaa.
Esta revisin se debera efectuar en forma peridica por parte de los responsables
de cada rea de trabajo, incluyendo todas las cuentas de usuarios con sus
respectivos permisos a las aplicaciones utilizadas por la compaa.
Riesgo:
Accesos no autorizados ni formalizados. Eventuales accesos indebidos a los
sistemas, manejo indebido de los datos privados de usuarios y/o la sociedad as
como datos en el sistema de produccin.
Impacto:
Cumplimiento
116
Efectuar revisiones peridicas a las cuentas de usuarios y sus respectivos perfiles
por parte de los responsables de cada rea de negocio.
Efectuar procedimientos estandarizados para esta revisin y para la baja de cuentas
de usuarios.
8. Inexistencia de un estndar de documentacin de la programacin de

cdigo fuente del sistema ERP y Web de la sociedad.
Nivel de riesgo:
Bajo

Durante la revisin se observa que no existe un estndar de documentacin en la
programacin del cdigo fuente en el sistema ERP y WEB, para la realizacin de
modificaciones del sistema.
En este sentido, mantener un estndar de documentacin sobre el cdigo fuente de

las aplicaciones en produccin permitira a la sociedad limitar su dependencia sobre
desarrolladores experimentados, facilitando as no solo la modificacin de sistemas si
no que tambin una mejor comunicacin y entendimiento entre los programadores.
Riesgo:
Alta dependencia de los actuales desarrolladores.
Impacto:
Cumplimiento
Desarrollar un procedimiento de documentacin estndar para la administracin del
cdigo fuente de las aplicaciones en ambientes de produccin y Web.
117
9. Inexistencia de plan de pruebas a los registros del sistema Web y

Productivo
Nivel de riesgo:
Medio

Durante la revisin se verifico que en la actualidad no existe un plan de pruebas que
permita asegurar el correcto procesamiento de los registros, ante cada mantencin
realizada sobre el sistema Web y el sistema de produccin. Las pruebas se realizan
en forma intuitiva y en base a resultados esperados.
De acuerdo a lo anterior, la existencia de un plan de pruebas debera contemplar,

entre otros, la realizacin de acciones que aseguren la completitud, restriccin,
validez y precisin de los registros procesador por los sistemas, ante cada
modificacin a ser introducida.
Riesgo:
Introduccin de modificaciones podran comprometer el correcto procesamiento de la
informacin que se trafica a travs de la Web y por intermedio del sistema de
produccin ERP.
Impacto:
Cumplimiento
Establecer un plan formal de pruebas para todas las modificaciones realizadas al
sistema Web y ambiente productivo.
118
10. Falta de evidencia formal de aprobaciones sobre las modificaciones

aplicaciones
Nivel de riesgo:
Bajo

Durante la revisin observamos que, si bien, los usuarios realizan una aprobacin de
los modificaciones solicitadas a los sistemas, dicha aprobacin no se encuentra
debidamente formalizada.
Des este modo, al existir una aprobacin formal por parte del usuario, permitira a la
Administracin asegurar y respaldar que las modificaciones introducidas al ambiente
de produccin satisfacen los requerimientos especificados en la sociedad del
usuario.
Riesgo:
Introduccin de modificaciones no solicitadas o defectuosas al ambiente de
produccin de los sistemas.
Impacto:
Cumplimiento
Establecer un procedimiento formal en el cual los usuarios entreguen su aprobacin
sobre las modificaciones realizadas a las aplicaciones, de acuerdo a la solicitud
generada por estos.
119
11. Inexistencia de manuales de usuarios y tcnicos actualizados.
Nivel de riesgo:
Bajo

Durante la revisin se observ que, en la actualidad, los manuales de aplicaciones
no son actualizados con cada modificacin realizada a los sistemas. Adicionalmente
se constata que no todas las aplicaciones en ambiente de produccin cuentan con
sus respectivos manuales.
En este sentido, mantener manuales de usuario actualizados para todas las

aplicaciones en produccin facilita el entendimiento de nuevos usuarios y permite
contar con material de consulta sobre los sistemas en operacin.
Riesgo:
Dificultad en el entrenamiento de nuevos usuarios. Alta dependencia de personal
experimentado.
Impacto:
Cumplimiento
Confeccionar manuales de usuarios y manuales tcnicos para las aplicaciones y
establecer un procedimiento por el cual se contemple la actualizacin de dicha
documentacin, para toda modificacin realizada a los sistemas.
120
12. Inexistencia de polticas de seguridad de la informacin
Nivel de riesgo:
Alto

Durante la revisin se observa que no existen polticas o procedimientos mediante
los cuales los usuarios se informen sobre los aspectos relativos a la seguridad de la
informacin. En la actualidad, las polticas existentes son directamente aplicadas
mediante la configuracin del Proxy, para el uso de Internet.
En este sentido, una adecuada poltica de seguridad orientada a los usuarios

permitir a la sociedad mantener un ambiente controlado en todos los niveles. Tal
poltica debera contemplar, al menos:
Utilizacin de Internet
Utilizacin de correo electrnico
Uso de claves y protectores de pantalla
Instalacin de software legal
Utilizacin de discos flexibles y discos porttiles
Uso adecuado de los recursos informticos (cuidado del teclado, Mouse,

pantalla etc.)
Comportamiento adecuado del usuario en su puesto de trabajo frente a los

recursos informticos.
Procedimiento establecido para cambios de equipos y sistemas
Uso y acceso a los recursos compartidos en red.
Deberes, obligaciones y prohibiciones del uso intelectual de la informacin de

la sociedad, as como el uso de aplicaciones propias de la empresa.
121
Riesgo:
Accesos no autorizados a informacin sensible. Utilizacin indebida a los recursos
computaciones de la sociedad. Desinformacin de los usuarios sobre el buen uso de
los recursos computacionales de la sociedad as como tambin del manejo de la
informacin.
Impacto:
Objetivos Estratgicos.
Elaborar y difundir una poltica de seguridad de la informacin orientndola a los
usuarios.
13. Inexistencia de manuales de operacin de sistemas
Nivel de riesgo:
Alto

Durante la revisin se constata que, en la actualidad, no existen manuales de
operacin de los sistemas en ambiente de produccin. Cabe sealar que estos
deben incluir procedimientos escritos y claramente definidos para todas las
actividades operativas que actualmente no se encuentran cubiertas por los
procedimientos existentes.
Es recomendable desarrollar, al menos, documentos tales como:
Proceso formal para la solicitud, administracin y eliminacin de cuentas de

usuario a nivel de sistema operativo y base de datos.
Estndares de configuracin de los servidores, bases de datos y equipos de

comunicaciones.
122
Procedimiento para el traspaso de programas al ambiente de produccin,

incluyendo mecanismos de verificacin y su debida documentacin.
Manual que describa la programacin y ejecucin de los procesos batch.
Riesgo:
Alta dependencia del personal experimentado, accesos no autorizados y dificultad en
la administracin de los procesos.
Impacto:
Cumplimiento.
Elaborar un manual de operaciones de los recursos informticos.
14. Inexistencia de plan de contingencias.
Nivel de riesgo:
Alto

Durante la revisin, se evidencia que no existe un plan de contingencias
documentado, aprobado, difundido y aprobado peridicamente, el cual establezca
planes de accin sobre qu hacer en caso de desastre y quines son los
responsable de la recuperacin de las operaciones ante una contingencia
operacional y tecnolgica, de manera de asegurar la continuidad operacional de la
sociedad.
Riesgo:
Interrupcin de las operaciones, dificultad en la recuperacin de la informacin
perdida de informacin.
123
Impacto:
Objetivos estratgicos.
Formalizar el plan de contingencias sobre los sistemas de la sociedad. Establecer un
plan de revisin peridica de los procedimientos establecidos en ste y formalizarlos
en todos los niveles involucrados de la sociedad.
15. Inexistencia de metodologa formal de administracin de requerimientos

de cambios y mantenciones.
Nivel de riesgo:
Bajo

Como resultado de el anlisis asociado a la administracin de cambios de sistemas,
se verifica la existencia de procedimientos informales que consisten en realizar
solicitudes, especificaciones y autorizaciones mediante correo electrnico o va
telefnica, sin embargo, para dicho proceso no se han documentado ni formalizado
las etapas, involucrados y responsabilidades asociadas.
Riesgo:
Dificultad en establecimiento de responsabilidades con respecto al proceso de
cambio de sistemas. Ineficiencia en la toma de requerimientos, debido al
desconocimiento de los canales formales de atencin de solicitudes de cambio.
Impacto:
Cumplimiento.
124
Documentar y formalizar la metodologa de administracin de requerimientos de
cambios y mantenciones existente.
16. Inexistencia de un procedimiento formal de documentacin para la

creacin, mantencin y eliminacin de cuentas de usuarios del sistema
ERP y red.
Nivel de riesgo:
Alto

Durante la revisin se observ que, en la actualidad, no se mantienen archivados los
documentos generados desde el departamento de RRHH para la creacin y
eliminacin de cuentas de usuarios.
El procedimiento de para la creacin y eliminacin de cuentas, con sus respectivos

perfiles, no cuenta con un procedimiento de actualizacin y mejoramiento continuo,
adems que no se mantiene un procedimiento de mantencin o modificacin de
cuentas y perfiles de usuarios.
Riesgo:
Eventuales errores
en la creacin y mantencin de usuarios. Accesos no
autorizados. Usuarios pueden tener asociadas mayores atribuciones de las que

justifica su cargo. Perdida de comprobantes de creacin, modificacin o eliminacin
de usuarios por parte de informtica.
Impacto:
Cumplimiento.
125
Actualizar formalmente la creacin, mantencin y eliminacin de cuentas de usuarios
para el sistema, incluyendo el almacenamiento de los comprobantes de cuentas de
usuarios.
17. Inexistencia de una estandarizacin en la administracin de la captura

de requerimientos de cambios de Software y Hardware
Nivel de Riesgo:
Medio

Durante la revisin e investigacin a los procedimientos de captura de requerimientos
de cambios de software o hardware, se observo que no existe una estandarizacin
en la administracin de la captura de requerimientos por parte del rea de soporte.
Actualmente los requerimientos de cambio o modificaciones de hardware o software,

se realizan mediante correo electrnico, va telefnica, mensajera interna o, incluso,
en forma verbal a los encargados de soporte, no teniendo un conducto regular
estandarizado o formal.
Si bien, se han informado los estndares para la realizacin de la captura de
requerimientos, este an no ha sido incorporado al procedimiento de modificacin y
captura de requerimientos de la sociedad en estudio.
Riesgo:
Solicitudes o requerimientos no autorizados. Tiempos de respuesta afectados debido
al olvido de actividades no registradas adecuadamente.
Impacto:
Cumplimiento.
126
Formalizar y difundir el nuevo formulario de requerimientos de cambios de software
y hardware con el fin de ser utilizado por el rea de soporte para estandarizar y
formalizar la captura de requerimientos de cambio de software y hardware. Junto con
esto, publicar una poltica pblica para la sociedad para establecer el conducto
regular para la captura de requerimientos por parte del rea de soporte.
18. Inexistencia de un procedimiento formal de documentacin para la

creacin, mantencin y eliminacin de cuentas de usuarios del sistema
ERP.
Nivel de riesgo:
Alto

Durante la revisin se observo que, en la actualidad, no se mantienen archivados los
documentos generados desde el departamento de RRHH para la creacin y
eliminacin de cuentas de usuarios.
El procedimiento de para la creacin y eliminacin de cuentas, con sus respectivos

perfiles, no cuenta con un procedimiento de actualizacin y mejoramiento continuo,
adems que no se mantiene un procedimiento de mantencin o modificacin de
cuentas y perfiles de usuarios.
Riesgo:
Eventuales errores
en la creacin y mantencin de usuarios. Accesos no
autorizados. Usuarios pueden tener asociadas mayores atribuciones de las que

justifica su cargo. Perdida de comprobantes de creacin, modificacin o eliminacin
de usuarios por parte de informtica.
127
Impacto:
Cumplimiento.
Actualizar formalmente la creacin, mantencin y eliminacin de cuentas de usuarios
para el sistema, incluyendo el almacenamiento de los comprobantes de cuentas de
usuarios.
19. La sociedad no cuenta con un plan estratgico formal de mediano y

largo plazo.
Nivel de Riesgo:
Bajo

Durante la visita se evidencio que el rea informtica no cuenta con un plan
informtico a mediano y/o largo plazo formalmente estructurado, documentado y
publicado.
Actualmente, el plan es difundido dentro del rea informtica mediante una reunin
informativa, la cual no est documentada. Esta reunin es de carcter meramente
informativo, no contando este plan, con la aprobacin ni modificacin de los actores
del rea informtica.
Riesgo:
Incumplimiento de los objetivos propuestos. Responsabilidades, plazos y tareas
podran no ser cubiertas por el personal informtico y/o afectar eventualmente las
tareas adquiridas.
Impacto:
Cumplimiento
128
Se recomienda establecer la instancia de revisin y aprobacin por parte de los
actores del rea informtica. Adems se debe de hacer de conocimiento pblico del
rea el plan informtico, incluyendo plazos, personal involucrado y presupuestos.
20. Inexistencia de un diagrama estndar de sistema y servidores.
Nivel de Riesgo:
Bajo

Durante la revisin hecha al rea informtica de la sociedad, se evidencio la
existencia de un documento que cuenta con la descripcin de los servidores, as
como los diagramas de servidores y redes de las antiguas instalaciones. Este
documento no est actualizado, ni formalizado ni aprobado por el personal del rea.
No existe un procedimiento adecuado de documentacin ni actualizacin de este
documento.
Riesgo:
Desactualizacin de los planes de contingencia. Dependencia del personal tcnico
en caso de emergencia. Nivel de cumplimiento del plan de continuidad del negocio
afectado debido a la actualizacin de los documentos
Impacto:
Cumplimiento
Se recomienda establecer un plan de trabajo que implique la actualizacin y revisin
de un documento estndar para los sistemas y servidores de la sociedad, as como
tambin actualizar constantemente los diagramas de redes y servidores que cuenta
la sociedad
129
21. Falta de control y administracin sobre los software y herramientas de

monitoreo de la sociedad
Nivel de Riesgo:
Medio

Durante la revisin se pudo constatar que no existe un control fehaciente sobre la
utilizacin de software de escritorio y monitoreo de redes por parte de la sociedad.
Se establece que no existen controles reales sobre licencias e inventario del software
libres o con licencias de pruebas de las herramientas utilizadas en la sociedad.
Riesgo:
Utilizacin indebida de software licenciado o con proteccin del uso por parte del
autor. Inexistencia de un inventario del software utilizado por la sociedad as como
tambin de las licencias utilizadas por equipos.
Impacto:
Operacin.
Se recomienda crear un documento donde se establezca el inventario de licencias
del software que lo requieran. As como tambin un inventario del software que se
utilizan en la sociedad.
130
CAPITULO VI
OBSERVACIONES Y RECOMENDACIONES
Segn los hallazgos encontrados en la sociedad, en particular el rea informtica,

producto del estudio realizado y las visitas a la sociedad se concluye, en forma
general, que la sociedad debera considerar lo siguiente:
Documentacin: aprender a realizar documentacin formal y eficiente. Tener

el hbito de respaldar las actividades que se realizan con algn registro,
generacin de informes, etc.
Manuales de usuarios: tener manuales de usuarios disponibles de los

sistemas.
Procedimientos: tener un formato nico en la empresa para la realizacin de

procedimientos. Revisarlos, aprobarlos, difundirlos y actualizarlos.
Plan de contingencias: Crear, revisar, formalizar, aprobar, difundir y actualizar

el plan de contingencias cuando corresponda.
Conceptos de seguridad de la informacin: no perder los puntos claves de la

seguridad
de
la
informacin
(privacidad,
integridad,
disponibilidad,
autenticidad)
6.1
Normas para Documentacin
6.1.1 Estructura de un sistema de documentacin

Los
procedimientos
son
componentes
fundamentales
de
un
sistema
de
documentacin. Las normas ISO 9001 ANSI/ASQC especifican lo que un

administrador
debe
cumplir
para
establecer
mantener
un
sistema
de
documentacin. La serie de estndares ISO 9000-9004 entregan lineamientos

generales de cmo debe ser un sistema de calidad, estructurado y documentado.
Una forma de visualizar la estructura de un sistema de calidad, segn las normas
ISO, es mediante cuatro niveles que son:
131
Manual de calidad
El manual describe las polticas de la empresa, y en general la estructura y mtodos

inherentes a los sistemas, para la unin de requerimientos y estndares.
Sistemas de procedimientos
Los procedimientos son utilizados para especificar el quien hace que, cuando y que
documentacin es utilizada para verificar la calidad de las actividades que deben ser
ejecutadas como requerimiento. Los procedimientos describen los pasos de cada
departamento o persona que debe asumir responsabilidades definidas por la
organizacin, mtodos y polticas.
Instrucciones de trabajo
Las instrucciones de trabajo son utilizadas para detallar el como una tarea particular
debe ser realizada. Tambin entregan conocimiento y/o lineamientos necesarios para
tomar decisiones o interpretar informacin. En particular, los siguientes tipos de
instrucciones de trabajos son utilizados:
o Instrucciones relacionadas a sistemas: entrega instrucciones detalladas
de cmo se debe llevar a cabo los controles, inspecciones o pruebas
especficas, o como se debe procesar materiales o documentar.
o Instrucciones relacionadas a proyectos: traslada los requerimientos

especficos de un proyecto dentro de la documentacin de trabajo tal
como dibujos, lista de materiales, tarjetas de ruta, inspecciones
especiales, pruebas, instrucciones de procesamiento o empaque, etc.
Registros y formas
Los registros son utilizados para entregar evidencia segn que un producto o servicio
fue llevado a cabo, y el sistema de la empresa a sido implementado correctamente.
Las formas se refieren a etiquetas, marcas estampas y otras que permiten
132
identificar el estado del material, producto, equipamiento y otros dispositivos

utilizados en la empresa para implementar un requerimiento especfico.
6.1.2 Sistema de procedimientos

Un procedimiento es una serie de pasos seguidos en un orden regular, definitivo con
el propsito de cumplir cierta tarea. Ms especficamente un buen procedimiento
puede ser dirigido y contestado por las siguientes preguntas:
Quin es responsable de realizar una tarea?
Qu es lo que la tarea necesita para ser realizada y cual es su propsito?
Donde la tarea debe ocurrir y ser aplicada?
Cuando debe concluir? En que secuencia, frecuencia, periodo del da, etc.
Como debe ser la documentacin para verificar que una tarea fue concluida
correctamente?
6.1.3 Como documentar los procedimientos

Muchas compaas documentan cada uno de sus procedimientos utilizando algunos
de los siguientes formatos:
Formularios escritos.
El formato escrito es el ms comn, consistente en procedimientos estructurados

primeramente en sentencias, organizadas en:
o Propsito: una orientacin breve del objetivo del procedimiento,
indicando adems porque este procedimiento es importante.
o mbito: una descripcin de las reas funcionales, personal, y otros
aspectos
organizacionales
cubiertos
afectados
por
los
procedimientos.
o Procedimientos y documentos relacionados: una lista de ttulos y
nmero de documentos de otros procedimientos referenciados por uno
especfico.
Generando
formularios
con
una
referencia
de
los
procedimientos que pueden ser listados en ellos.

133
o Definicin: instrucciones que definen el significado y contexto de

trminos
utilizados
en
las
referencias
procedimientos.
Este
encabezado es considerado opcional, y a menudo no es utilizado.

o Instrucciones de procedimientos: serie de directivas que especifican
quien hace que, cuando y como, cuyo resultado es verificado.
Las instrucciones de procedimientos son tpicamente numeradas para
su fcil referencia y para mostrar el flujo de la lgica de la ejecucin de
un procedimiento, cuando cambia de persona o departamento.
Diagrama de Flujo.
Un diagrama de flujo es una representacin esquemtica o dibujo que muestra todos

los pasos de un proceso. Es frecuentemente el primer o segundo paso utilizado por
el equipo de analistas:
o Para un mejor entendimiento del punto de accin o decisin en que se
encuentra en un proceso.
o Para determinar como un proceso trabaja actualmente.
o Para determinar como un proceso debera trabajar.
Un diagrama de flujo es una herramienta til para identificar prdidas y

oportunidades para el mejoramiento de un sistema, al mostrar procesos complejos
en forma efectiva. Tambin muestra grandes dibujos de procesos y procedimientos,
que permiten a los analistas hacerse las siguientes preguntas:
o Puede ser simplificado?
o Puede ser reorganizado?
o Puede ser combinado?
o Puede ser eliminado?
Formulario de tabulacin.
El formulario de tabulacin entrega una forma sencilla de entender un conjunto de

puntos clave donde el control y responsabilidad, para las actividades de los
procedimientos, son transferidas de una persona o departamento a otro. Algunas
134
empresas lo utilizan en todos sus procedimientos debido a que entrega numerosos

beneficios a cambio de un pequeo esfuerzo adicional.
Documentacin de sistemas
Las normas no especifican quien debe documentar los procedimientos. Si bien
cualquiera podra tener la experiencia, conocimiento y tiempo para documentar
procedimientos, existen una serie de factores a considerar antes de comenzar esta
actividad significativa.
Una vez que se tiene claro quien hace que, cuando y como debe terminar un
procedimiento, cada administrador de las reas cubiertas por el procedimiento
debe involucrarse directamente en el desarrollo de la documentacin, revisin
y aprobacin.
De ser un desarrollo de documentacin externo, es deseable que sea una

institucin dedicada al tema.
El nmero de personas que deben participar en el estudio y desarrollo de un

sistema de documentacin depender de una serie de factores, tales como
tipo de organizacin, diversidad de fuentes tcnicas, distintas especialidades,
estandarizacin, etc. Para determinar esto hay que tener en cuenta que:
a. Los procedimientos a menudo involucran especificaciones pasos
interrelacionados y complejos, en orden a asegurar la calidad y
mantener el control. Ambos requieren la combinacin de conocimiento
de muchas personas para aclarar y describir adecuadamente pasos
relacionados. En breve, dos cabezas piensan mejor que una.
b. Los equipos unidos permiten que la carga de trabajo (que puede ser
sustancial), sea repartida entre sus miembros.
c. A
menudo
algunas
documentaciones
son
demasiado
simples,
redundantes, inefectivas y sin valor agregado en su estandarizacin y

formato de documentacin. La sinergia de equipo de trabajo es til para
identificar prdidas en la actividad de procedimientos actuales y evitar
estandarizaciones inefectivas y prcticas costosas en el negocio que lo
hagan menos competitivo.
135
Equipos de documentacin
Una estructura ideal para un equipo de documentacin puede estar compuesta por
administradores, asesores y personal que son directamente responsables de
establecer, ejecutar y mantener los procedimientos. La documentacin es un trabajo
tpico para equipos que identifican caminos de accin para cumplir una misma tarea.
Esto es particularmente cierto en organizaciones con mltiples operaciones.
Teniendo un equipo compuesto por personal el cual est directamente involucrado
con los procedimientos puede entregar una oportunidad de discutir y llegar a
consenso respecto a la mejor manera de cumplir una cierta tarea. En esencia,
desarrollar procedimientos es ms que un ejercicio de documentacin. Es una
oportunidad de evaluar la actual operacin, identificar y eliminar prdidas e
ineficiencias, y establecer un mtodo estndar que refleje la mejor forma de cumplir
con las tareas requeridas por la organizacin. Es importante tener en cuenta la
constante revisin de los estndares establecidos para mantener la competitividad
disminuyendo la variabilidad en los procesos y costos en la forma actual de
operacin.
6.1.4 Documentacin Tcnica
La documentacin tcnica se puede definir como aquella que trata de temas de
naturaleza tcnica. Por tcnica se puede entender como todo lo que tiene relacin
con reas especializadas de la ciencia y tecnologa. Con el tremendo incremento de
la utilizacin de los computadores muchos de los trabajos de documentacin tcnica
estn relacionados con ellos y reas de alta tecnologa, donde los documentos se
necesitan para producir software de documentacin, manuales de usuarios, y una
gran variedad de otra documentacin tcnica.
Existe una gran diferencia entre la documentacin tcnica y la composicin de otro

tipo. El primer objetivo de cualquier comunicacin tcnica es transmitir informacin
136
tcnica adecuadamente. El escritor tcnico esta orientado en comunicar,

sacrificando muchas veces estilo, gracia, claridad tcnica, precisin y organizacin.
6.1.5 Caractersticas de una buena documentacin

Las caractersticas generales que debe poseer una buena documentacin tcnica,
para lograr una efectiva recepcin por parte del lector, deben ser:
Tcnicamente exacta
El propsito de la documentacin tcnica es transmitir informacin. Su contenido

debe ser cierto, y tan correcto como sea posible. La falta de exactitud puede causar
prdida de credibilidad por parte del lector, y se puede llegar a pensar que el autor no
conoce con exactitud la materia documentada. Por otra parte hay que considerar que
la documentacin tcnica se utiliza para la toma de decisiones, operacin de
equipos, manejo de sistemas, investigaciones cientficas, etc., basados en los textos
entregados. Para lograr una mayor exactitud de la documentacin, se puede
recomendar que toda documentacin tcnica sea revisada por una o ms personas
familiarizadas con el tema y con la edicin tcnica.
til
Por la relevancia que puede adquirir la documentacin, es muy importante

asegurarse que contenga informacin til, eliminando aquellas partes ornamentales,
que no aportan y que presentan informacin de soporte innecesaria. Puede ser que
el autor encuentre una determinada parte muy apasionante, sin embargo los lectores
no tienen tiempo para ello, ya que buscan lo que exactamente el autor conoce
respecto a un tema, ni de ms, ni de menos.
Por ejemplo un usuario final no tiene por que saber como fue inventado un software,
cuantas lneas de cdigo tiene o en que lenguaje fue escrito, a menos que dicha
informacin sea importante para l. Debe saber simplemente como se utiliza la
opcin tal o cual de la aplicacin.
137
Concisa
Si los lectores son personas extremadamente ocupadas, la documentacin tcnica

debe ser lo ms simple y que no demande mucho tiempo para su comprensin.
Adems la documentacin tiene un costo de desarrollo, por tanto mientras ms
concisa sea esta, se puede salvar tiempo y costos de impresin. La principal razn
por la cual la documentacin tcnica suele ser muy larga, se debe a que la
correccin y eliminacin de ideas repetidas es un trabajo muy duro, que la mayora
de los profesionales que desarrollan la documentacin tcnica no estn dispuestos a
realizar.
Completa
No se debe confundir el trmino conciso con brevedad, ya que ello puede dejar fuera
importante informacin, que para personas que no estn acostumbradas a un
determinado tema los puede llevar a cometer errores. Una buena documentacin
tcnica significa que debe contener todo lo que el lector debe saber sin dejar lo
esencial fuera de ella. En particular se debe ser muy cuidadoso cuando se editan
especificaciones, lista de caractersticas, grficos.
Clara
El xito de la documentacin tcnica se fundamenta en que sea entendible por la

audiencia. Como ejemplo se puede mencionar;
o Escribir corto y simple, utilizando palabras, prrafos y sentencias
cortas.
o No utilizar jergas. Esto lleva a que los lectores no especializados no
entiendan el contenido de la documentacin, haciendo que pierdan el
inters por ella.
o Presentar la idea en forma lgica y ordenada, de a un paso a la vez.
o Utilizar grfica. En ocasiones un dibujo o grfico dice ms que muchas
palabras, presentando la informacin ms efectivamente que en forma
escrita.
138
Consistente
La documentacin tcnica debe ser consistente en la forma que se desarrolla, es

decir la utilizacin de las maysculas, ttulos, uso indiscriminado de abreviaciones,
puntuacin, reglas de gramtica, etc. Es necesario definir una forma consistente para
escribir la documentacin de manera tal que el lector tenga la percepcin que fue
escrita por una persona con educacin en literatura con una forma clara de
comunicacin.
Correcta escritura, puntuacin y gramtica
Toda escritura, a excepcin de algunos dialectos, poesa, etc., deben seguir reglas
de lectura, puntuacin y gramtica. Si bien los lectores estn interesados en el
contenido ms que en el buen uso de las reglas gramaticales, rpidamente se dan
cuenta de palabras errneas, gramtica pobre, nomenclatura incorrecta de las cosas
que son escritas por otros individuos.
Orientada
Normalmente se presenta la dificultad de definir en lenguaje adecuado para llegar a

un grupo amplio de lectores, es decir se puede escribir en un nivel muy alto para
lectores tcnicos calificados, dejando fuera a muchos lectores que no cuentan con
suficiente preparacin, o por otra parte escribir en un nivel muy bajo lo que hace que
la lectura se torne aburrida para aquellos lectores ms preparados. Para poder llegar
ms precisamente a un grupo de lectores se puede recomendar:
o Definir adecuadamente la audiencia, considerando sus diferentes
especialidades.
o Ponerse en el lugar de la audiencia, entendiendo sus necesidades,
intereses y nivel de entendimiento tcnico.
o Mantener el equilibrio en el lenguaje y orientacin de la documentacin,
sin dejar de entregar el adecuado contenido.
o La mejor manera de exponer las ideas en forma clara es tomndose su
tiempo. No se debe sentir que se tiene que exponer todo su
conocimiento tcnico de una vez.
139
Bien organizada
Una organizacin pobre es uno de los mayores obstculos que las personas
perciben del material tcnico, al momento de leerlo. Lo primero es planificar lo que se
desea escribir, para luego definir el contenido y formato del informe o reporte. Dividir
el proyecto en pequeas partes, tales como unidades, captulos, etc., de manera de
poder abordar cada una por separado, en forma fcil de manejar. Algunas formas de
organizacin pueden ser:
o Por orden de ubicacin.
o Por orden de incremento de su dificultad.
o Orden secuencial.
o Orden Alfabtico.
o Orden cronolgico.
o Problema/solucin.
o Pirmide invertida u orden decreciente.
o Orden deductivo, de lo general a lo particular.
Interesante
Es muy importante obtener la total atencin del lector, se debe recordar que su
documento est compitiendo con muchas otras fuentes de informacin, por lo cual
hay que poner cuidado en hacer una documentacin que sea interesante y
entretenida para el lector.
6.2
Gua de usuario
Este manual tiene como objetivo principal servir de ayuda y gua al usuario final, en
la operacin y manejo de sistema. Debe considerar aspectos que le permitan poder
manejar en forma eficiente la aplicacin y resolver problemas que se le presenten a
lo largo de su utilizacin.
140
De los documentos que se deben construir como parte de la documentacin de

sistema, ste probablemente es el que debe recibir la mayor cantidad de trabajo
manual. Adems y como se ver ms adelante, este documento ser la fuente
principal de la ayuda en lnea del sistema y por lo tanto sus textos interactan con
el usuario.
6.2.1 Identificacin y tabla de contenido

La identificacin y tabla de contenido se refiere a las primeras pginas de los
manuales que sern entregados a los usuarios del sistema. Es importante que todos
los manuales posean el mismo diseo, ayudar a identificar la personalidad de la
documentacin. La tabla de contenido debe construirse con la ayuda del procesador
de textos que se est utilizando.
A continuacin, se describe el contenido de cada pgina hasta la tabla de contenido:
Pagina numero uno
En la primera pgina de la gua no es mostrada la numeracin pero corresponde al

nmero romano uno. Puede perfectamente, ser equivalente con la portada externa
del manual excepto el dibujo o diseo de la portada (en caso de ser un producto a
comercializar). Debe contener lo siguiente:
o Nombre comercial de la aplicacin. Es decir, como ser conocido el
producto por los usuarios o clientes de l.
o Titulo, el cual debe indicar el nombre largo de la aplicacin o sistema.
o Numero de versin.
o Sistemas operativos en los cuales es posible instalarlo.
o Nombre de la empresa propietaria de la aplicacin o sistema
Pagina numero dos
Es la contra tapa de la anterior y utilizada para indicaciones de marcas y licencias.

Tampoco es mostrada la numeracin y corresponde al nmero escrito en romano
dos. A continuacin y a modo de ejemplo se transcribe un mensaje usado por
Microsoft Corp. en sus manuales:
141
La informacin de este documento esta sujeta a cambio sin previo aviso y no

representa ningn compromiso para (indicar el nombre de su empresa). No esta
permitida cualquier reproduccin o parcial o total de este manual o transmitido en
cualquier forma o por cualquier medio, electrnico o mecnico, incluidos fotocopia o
grabacin, para cualquier propsito sin el expreso consentimiento escrito de (indicar
el nombre de su empresa).
Adems se indica el ao y lugar de confeccin del manual. Si el producto est

inscrito como marca registrada, indicar su nmero. Reconocer todas las marcas
registradas que se hacen referencia dentro del documento.
Por ltimo, indicar mediante una codificacin de documento, el nmero asignado al
manual.
Pagina numero tres
Desde esta pgina en adelante, se debe ubicar la tabla de contenido. Por favor, no
intente construirla manualmente ya que con seguridad la numeracin de pginas se
volver inconsistente en la pgina de actualizacin. Si esto ocurre provocar
frustracin a un usuario que busca un tema y no lo encuentra donde el propio manual
dice que est. Requiere de parte del encargado de documentar, un trabajo ordenado
y consistente a travs del documento. El uso de plantillas para especificar los
nombres de ttulos, tipos y tamaos de letras, tabulaciones y sangras son de uso
obligatorio para el logro de este objetivo.
6.2.2 Contenido del manual

Este manual debera contener a lo menos los siguientes elementos:
Notas para el usuario
Se debe entregar al usuario una breve descripcin de las caractersticas y utilidad de

la aplicacin a utilizar. Por otro lado debe entregar la forma de abordar el manual, ya
sea si se trata de un usuario principiante, intermedio o avanzado, ya que
dependiendo del grado de conocimiento que posea el usuario acerca de la
142
aplicacin, la informacin a buscar ser distinta, por lo que este manual debe tratar
de cubrir todas las necesidades de los usuarios.
Debe tambin entregar la forma cmo esta estructurado el manual, describiendo
brevemente la informacin que puede el usuario obtener en cada una de las partes,
es decir, cmo est organizada la informacin, enumerar procedimientos, secciones,
mostrar ilustracin de cmo se presenta la informacin en un captulo. Tambin es
importante en este punto, destacar el requerimiento de hardware o equipamiento
fsico que necesitar el usuario para proceder a instalar la aplicacin.
Convenciones tipogrfica
Esto tiene por objetivo explicar los trminos y acuerdos sobre notacin usados en la
documentacin. Consiste en describir o explicar el lenguaje y forma que adoptarn
las palabras que se utilizarn. Sirve para ayudar al usuario a localizar e identificar
fcilmente la informacin.
A continuacin se presenta un ejemplo de la forma de presentar las convenciones
usadas en un manual.
o Negrita: se usa para nombres de mens, comandos, cuadros de
dilogo, modificadores y cualquier otro texto que el usuario deba
escribir tal como se indique.
o Cursiva: Parmetros. Podr proporcionar el texto para cualquier
elemento mostrado en cursiva. Por ejemplo, si desea usar un
parmetro que solicite un nombre_de_archivo, deber escribir el
nombre del archivo especifico. Los trminos nuevos tambin aparecen
en cursiva: El trmino se explicar la primera vez que se presente.
o F1 (AYUDA): Las teclas de funcin y las especiales pueden aparecer
escritas en letra mayscula negrita y van acompaadas de su
correspondiente pulsacin o secuencia de pulsaciones, seguida del
nombre de la funcin. Los nombres de teclas separados por un ms (+),
indican que deben mantenerse pulsada la primera tecla al mismo
tiempo que se pulse la segunda y a continuacin soltar ambas.
143
Introduccin.
La introduccin como su nombre lo indica le debe proporcionar al usuario una visin

de lo que tratara el capitulo en materia.
La generacin de un diagrama que entregue una visin global del entorno
administrativo en el cual se inserta el sistema, ser de gran ayuda para el usuario
novato dentro la organizacin. La confeccin de este tipo de diagramas
confeccionado con tcnicas de workflow clarificar bastante.
Una descripcin de la estructura de mens de la aplicacin, usando graficas de rbol
para representar la jerarqua de cada una de las opciones, es parte fundamental de
esta parte del manual de usuario.
Descripcin operativa de procesos
Se debe describir en forma general los procesos que contiene la aplicacin junto con
el objetivo principal de cada uno de estos. Tambin se debe describir y explicar las
salidas de los procesos ya sean listados o pantallas, a fin de entregarle todas las
herramientas y el conocimiento necesario al usuario para poder interactuar con la
aplicacin. Esta descripcin de las salidas debe considerar todos aquellos campos
que contiene junto a una ilustracin de las mismas.
Adems de esta descripcin de objetivos y muestra visual de los procesos se debe
considerar la forma de operar la aplicacin, es decir, ensear a travs de ejemplos la
utilizacin de cada uno de los procesos junto a la forma y datos que se deben
introducir en cada uno de estos procesos.
Dentro de este punto es necesario considerar:
o Descripcin de los componentes de las pantallas: En esta descripcin
se debe considerar cada uno de los campos que componen la pantalla.
Esta descripcin debe considerar la forma de llenar estos campos
aludiendo el tipo de dato que se debe introducir. Idealmente, se debe
crear un mecanismo de extraccin de la informacin de especificacin
de formulario hecha por el encargado de desarrollo, de tal forma de no
duplicar esfuerzos de documentacin.
144
o Imgenes: Consiste en combinar el texto con dibujos, esto permite que

el texto visualmente sea ms agradable y se facilita su lectura.
o Ejemplos prcticos: Se debe incluir ejemplos y casos prcticos donde le

entreguen al usuario la facilidad de comprender el funcionamiento de la
aplicacin, y permitirle aprender y practicar a la vez.
Mensaje de error
La construccin de la explicacin de los mensajes de error en este manual,

simplemente debiera ser la conclusin de un trabajo iniciado junto con el desarrollo
del sistema. Una base de datos con los mensajes de error que sern desplegados al
usuario debe ser cuidadosamente planificada y centralmente administrada. No
somos partidarios de que cada programador en forma aislada y como resultado de su
inspiracin escriba mensajes del tipo: Horror, esto nunca debiera ocurrir. Una
base de datos de mensajes de error debiera contener por lo menos los siguientes
atributos:
a. Cdigo numrico del mensaje, de no ms de cuatro dgitos.
b. Nivel de urgencia del mensaje para el sistema, distinguiendo las siguientes
categoras: Informativo (advertencia, no provoca consecuencias en la
operatoria o es muy obvia su solucin), Error (la operatoria se ve
momentneamente suspendida hasta que el problema se solucione), Error
fatal (ocurri un error que suspende la operatoria normal del sistema y
deben tomarse medidas ms drsticas para reiniciar la operatoria normal).
c. Descripcin corta del mensaje de error, de no ms de 80 caracteres.
d. Explicacin o circunstancias en las cuales el mensaje de error puede
ocurrir, en un texto de hasta 255 caracteres.
e. Accin o acciones posibles a ser tomadas en caso de suceder, en un texto
de hasta 255 caracteres.
Como se puede ver, la conclusin de los mensajes de error del sistema, si en el
desarrollo del proyecto se contempl desde un principio, resulta en un tema trivial. Si
no fue considerada de esta forma o alguna similar, el rastreo y organizacin de todos
145
los mensajes existentes, el manejo de las duplicaciones y mensajes poco claros lo

transformar en una misin imposible.
Glosario
Consiste en entregar en forma ms amplia el significado de alguna palabra o frase

utilizada en la documentacin. Recordemos que en las convenciones tipogrficas se
defini que este tipo de palabras o frases se escribirn con letra cursiva.
6.3
Manual de Procedimientos
El Manual de Procedimientos es un documento que describe en forma lgica,

sistemtica y detallada las actividades del rea de acuerdo a sus atribuciones para la
ejecucin eficiente de las mismas, sealando generalmente quin, cmo, cundo,
dnde y para qu han de realizarse. En otras palabras, es el documento que
contiene la descripcin de actividades que deben seguirse en la realizacin de las
funciones de una unidad administrativa, o de dos o ms de ellas.
El manual incluye adems los puestos o unidades administrativas que intervienen

precisando su responsabilidad y participacin.
Suelen contener informacin y ejemplos de formularios, autorizaciones o documentos

necesarios, mquinas o equipo de oficina a utilizar y cualquier otro dato que pueda
auxiliar al correcto desarrollo de las actividades dentro de la empresa.
Utilidad
Permite conocer el funcionamiento interno por lo que respecta a descripcin

de tareas, ubicacin, requerimientos y a los puestos responsables de su
ejecucin.
Auxilian en la induccin del puesto y al adiestramiento y capacitacin del

personal ya que describen en forma detallada las actividades de cada puesto.
Determina en forma ms sencilla las responsabilidades por fallas o errores.
146
Facilita las labores de auditoria, evaluacin del control interno y su evaluacin.
Aumenta la eficiencia de los empleados, indicndoles lo que deben hacer y

cmo deben hacerlo.
Ayuda a la coordinacin de actividades.
Construye una base para el anlisis posterior del trabajo y el mejoramiento de

los sistemas, procedimientos y mtodos.
6.3.1 Contenido del Manual de Procedimientos

La informacin que integrar el Manual de Procedimientos depender de lo que se
pretenda mostrar o dar a conocer con este documento, sin embargo, pueden
considerarse los siguientes puntos:
Portada/Identificacin
Este documento debe incorporar la siguiente informacin:
o Logotipo de la organizacin.
o Nombre oficial de la organizacin.
o Denominacin y extensin. De corresponder a una unidad en particular
debe anotarse el nombre de la misma.
o Fecha de elaboracin.
o Nmero de revisin (en su caso).
o Unidades responsables de su elaboracin, revisin y/o autorizacin.
o Clave de la forma. En primer trmino, las siglas de la organizacin, en
segundo lugar las siglas de la unidad administrativa donde se utiliza la
forma y, por ltimo, el nmero de la forma. Entre las siglas y el nmero
debe colocarse un guin o diagonal.
ndice
Relacin de los captulos y pginas correspondientes que forman parte del
documento.
147
Introduccin
Exposicin sobre el documento, su contenido, objeto, reas de aplicacin e
importancia de su revisin y actualizacin. Puede incluir un mensaje de la
mxima autoridad de las reas comprendidas en el manual.
Objetivos de los procedimientos

Explicacin del propsito que se pretende cumplir con los procedimientos.
Los objetivos son uniformar y controlar el cumplimiento de las rutinas de
trabajo y evitar su alteracin arbitraria; simplificar la responsabilidad por fallas
o errores; facilitar las labores de auditoria; facilitar las labores de auditoria, la
evaluacin del control interno y su vigilancia; que tanto los empleados como
sus jefes conozcan si el trabajo se est realizando adecuadamente; reducir los
costos al aumentar la eficiencia general, adems de otras ventajas
adicionales.
Responsables
Unidades administrativas y/o puestos que intervienen en los procedimientos
en cualquiera de sus fases.
Descripcin de Procedimientos
Presentacin por escrito, en forma narrativa y secuencial, de cada una de las
operaciones que se realizan en un procedimiento, explicando en qu
consisten, cundo, cmo, dnde, con qu, y cunto tiempo se hacen,
sealando los responsables de llevarlas a cabo. Cuando la descripcin del
procedimiento es general, y por lo mismo comprende varias reas, debe
anotarse la unidad administrativa que tiene a su cargo cada operacin. Si se
trata de una descripcin detallada dentro de una unidad administrativa, tiene
que indicarse el puesto responsable de cada operacin. Es conveniente
codificar las operaciones para simplificar su comprensin e identificacin, an
en los casos de varias opciones en una misma operacin.
148
Diagramas de Flujo
Representacin grfica de la sucesin en que se realizan las operaciones de
un procedimiento y/o el recorrido de formas o materiales, en donde se
muestran las unidades administrativas (procedimiento general), o los puestos
que intervienen (procedimiento detallado), en cada operacin descrita.
Adems, suelen hacer mencin del equipo o recursos utilizados en cada caso.
Los diagramas representados en forma sencilla y accesible en el manual,
brinda una descripcin clara de las operaciones, lo que facilita su
comprensin. Para este efecto, es aconsejable el empleo de smbolos y/o
grficos simplificados.
Formularios
Formas impresas que se utilizan en un procedimiento, las cuales se intercalan
dentro del mismo o se adjuntan como apndices. En la descripcin de las
operaciones que impliquen su uso, debe hacerse referencia especfica de
stas, empleando para ello nmeros indicadores que permitan asociarlas en
forma concreta. Tambin se pueden adicionar instructivos para su llenado.
Firmas de Autorizacin
El contenido del Manual de Procedimientos vara de acuerdo al objetivo de la

Dependencia o Entidad y es muy similar al de Organizacin, por lo que slo se
definir la descripcin de procedimientos y los diagramas de flujo.
6.4
Plan de Contingencias
Podramos definir a un plan de contingencias como una estrategia planificada con

una serie de procedimientos que nos faciliten o nos orienten a tener una solucin
alternativa que nos permita restituir rpidamente los servicios de la organizacin ante
la eventualidad de todo lo que lo pueda paralizar, ya sea de forma parcial o total.
149
El plan de contingencia es una herramienta que ayudar a que los procesos crticos
de la empresa u organizacin continen funcionando a pesar de una posible falla en
los sistemas computarizados. Es decir, un plan que le permite al negocio u
organizacin, seguir operando aunque sea al mnimo.
6.4.1 Objetivos
Garantizar la continuidad de las operaciones de los elementos considerados

crticos que componen los Sistemas de Informacin.
Definir acciones y procedimientos a ejecutar en caso de fallas de los

elementos que componen un Sistema de Informacin.
6.4.2 Fases de la Metodologa para el Desarrollo de un Plan de Contingencia

de los Sistemas de Informacin
Hay que tener presente que mucho depender de la infraestructura de la empresa y
de los servicios que sta ofrezca para determinar un modelo de desarrollo de plan,
no existe un modelo nico para todos, lo que se intenta es dar los puntos ms
importantes a tener en cuenta.
La presente metodologa se podra resumir en ocho fases de la siguiente manera:
Planificacin: preparacin y aprobacin de esfuerzos y costos.
Identificacin de riesgos: funciones y flujos del proceso de la empresa.
Identificacin
de
soluciones:
Otras
opciones,
Evaluacin
de
Riesgos
de
fallas
interrupciones.
Estrategias:
soluciones
alternativas,
procedimientos
manuales.
Documentacin del proceso: Creacin de un manual del proceso.
Realizacin de pruebas: seleccin de casos soluciones que probablemente

funcionen.
150
Implementacin: creacin de las soluciones requeridas, documentacin de

los casos.
6.5
Monitoreo: Probar nuevas soluciones o validar los casos.
Que es la seguridad?
La seguridad est finamente ligada a la certeza. Para entender esta definicin, hay
que aclarar que no existe seguridad absoluta, ms bien, lo que se intenta es
minimizar el impacto y/o riesgo. Por tal motivo, cuando hablamos de seguridad,
debemos hacerlo en carcter de niveles, y lo que se intenta y se debe hacer es llevar
a cabo una organizacin efectiva a fin de lograr llegar a los niveles ms altos.
Las tcnicas para llegar a una correcta organizacin estn basadas en cuatro pilares
fundamentales que hacen que la INFORMACIN se encuentre protegida. Estos
pilares se ocupan principalmente de proteger cuatro aspectos de la informacin:
Confidencialidad
La informacin puede ser accedida nicamente por las personas que tienen
autorizacin para hacerlo. Por ejemplo, cuando decimos que Internet es una red de
redes, estamos diciendo que hay medios que se entrelazan entre s para lograr una
vinculacin. Es por ello que la confidencialidad se puede ver amenazada si alguien
intercepta los paquetes que viajan de un lado a otro.
Integridad
Cuando nos referimos a integridad, queremos decir que estamos totalmente seguros
de que la informacin no ha sido borrada, copiada o alterada, no slo en su trayecto,
sino tambin desde su origen.
151
Disponibilidad
Este trmino hace referencia al mtodo de precaucin contra posibles daos tanto en
la informacin como en el acceso a la misma: ataques, accidentes o, simplemente,
descuidos pueden ser los factores que obligan a disear mtodos para posibles
bloqueos.
Autenticidad
Algunos profesionales de la seguridad no incluyen este tem cuando hablan de los

pilares, sino que nombren los tres anteriores. Particularmente, creemos que no se
puede soslayar este concepto, debido al hecho de que integridad nos informa que el
archivo, por ejemplo, no ha sido retocado ni editado, y autenticidad nos informa que
el archivo en cuestin es el real.
6.5.1 Qu queremos proteger?

La seguridad informtica intenta proteger cinco elementos:
Hardware
El hardware se encuentra compuesto por el conjunto de sistemas fsicos del
sistema informtico, en otros trminos, de nuestra computadora: gabinete,
placa madre, microprocesadores, disco duro, unidades de almacenamiento
extrable, monitor, Mouse, teclado, cables, etc.
Software
El software consiste en el conjunto de sistemas lgicos que hacen funcional al
hardware: sistemas operativos, aplicaciones, programas, etc.
Datos
Conjunto de sistemas lgicos que tienen como funcin manejar el software y el
hardware (registros, entradas en base de datos, paquetes que viajan por los
cables de red; hasta un bit es un dato).
152
Vale declarar que no es lo mismo dato que informacin. Un dato no tiene

coherencia por s solo, sino que la tiene por medio de un entorno o contexto.
Si bien el dato es esencial, el juicio sobre lo que se debe hacer con el mismo
se realiza por medio de un programa o persona.
A diferencia de los datos, la informacin s tiene significado. Es ms, los datos

se convierten en informacin cuando su creador les aade significado.
Elementos fungibles
Son elementos que se gastan o se desgastan con el uso continuo (papel,
controladora fiscal, impresora/tner, disquetes, insumos en general y todo lo
que de alguna manera est conectado a una mquina).
Una buena administracin se basa en controlar los recursos de la empresa, ya
que los mismos no son infinitos ni el dinero con el que se cuenta es ilimitado, y
menos para usarlo como gasto y no como inversin. Para lograr eficiencia y
calidad se tiene que tomar conciencia y crear una poltica para el correcto uso
de las herramientas con las que cuenta la empresa.
6.5.2 De que nos protegemos?

Esta pregunta es tan amplia como su respuesta. Hay muchas clasificaciones que van
variando segn cada autor y cada investigador del tema, pero la mayora tienen un
punto de vista en comn: nos protegemos de las personas.
A esta altura de los tiempos y con las sociedades que evolucionan, suena raro decir
que estamos cuidndonos de nosotros mismos y, ms an sabiendo que esos
elementos que protegemos son, en su mayora, cosas creadas por nosotros mismos.
El factor ms importante que incita a las personas a cometer actos en contra de los
cuatro pilares es, sin ninguna duda, el poder. El poder reside en los datos y en la
informacin.
153
Factores Humanos
Al hablar de factores humanos, incluimos al software y/o malware, ya que los mismos
fueron ideados y creados por personas.
Personal o ex - empleados
Hackers, crackers y lamers
Cliqueadores y gecece
Intrusos por paga
Cyberterroristas
Software con errores
Puertas traseras
Otros mtodos (virus, canales ocultos, gusanos, troyanos, conejos, bombas,

etc.).
Factores no Humanos
Las amenazas ambientales, si bien dependiendo de la ubicacin geogrfica pueden
tener ms o menos periodicidad catastrfica, no son hechos que ocurran
frecuentemente. Pero esto no es motivo suficiente para no considerar la
circunstancia de que, si sucede, el dao ser severo.
Las catstrofes ms comunes son los terremotos, incendios, atentados, tormentas,
etc.
6.6
Monitoreo
Todos los procesos de una organizacin necesitan ser evaluados regularmente a

travs del tiempo para verificar su calidad y suficiencia en cuanto a los
requerimientos de control, integridad y confidencialidad. Este es, precisamente, el
mbito de este dominio.
154
6.6.1 Procesos
Documentacin
El proceso de documentacin, al ser un proceso de aprendizaje y de creacin de

hbitos, en esta instancia es un tanto difcil de cuantificar.
Manuales de usuarios
Para los manuales de usuario se propone establecer dos instancias de control. Estas
etapas se dividen en revisiones internas como externas.
Revisiones externas: Estas revisiones deben realizarse por organismos externos al

departamento de informtica, teniendo como mnimo una revisin de los siguientes
tpicos:
Cumplimiento del formato estndar de la empresa para los manuales de

usuario
Tener el contenido adecuado para el tipo de manual elaborado
Cumplir con las distintas etapas de aprobacin dentro del departamento

elaborador del documento.
Cumplimiento de las fechas establecidas
Revisiones Internas: Estas revisiones apuntan llevar un control sobre la elaboracin

de los manuales correspondientes al rea informtica. Para poder controlar los
estados de avance de las distintas etapas de la elaboracin de los manuales, se
propone elaborar una tabla que refleje los porcentajes de estos avances. Como
ejemplo se puede establecer la siguiente tabla:
155
Tipo de Manual
Manual 1
Manual 2
Manual X
% de Avance
% Revision
% Version Final
Total por Manual
Totales %
Tabla 6.1: Tabla resumen de porcentajes de los manuales

Fuente: elaboracin propia.
La tabla contiene los siguientes aspectos:

% de Avance: Es el porcentaje de progreso con el que cuenta el manual que esta
siendo elaborado.
% Revisin: Estado expresado en porcentaje en que se encuentra la revisin del
Manual en cuestin.
% Versin Final: Estado expresado en porcentaje de la versin final del manual en
cuestin.
Total por Manual: Es el total, expresado en porcentaje, del global de la confeccin del
manual en cuestin. El calculo expresa la suma en total de los distintos avances por
manual dividido por tres, es decir:
(% de Avance + % Revisin + % Versin Final)/3
Totales %: Es el total general y por sectores, de los avances con los que cuenta la
elaboracin de los distintos manuales. Los totales se calculan de la siguiente
manera:
Totales de % de Avance, Revisin y Versin Final = Es la suma de los porcentajes

por sector, dividido por el numero de manuales en elaboracin.
Totales de % General: Es la suma de los totales por manual, dividido por el nmero
de manuales en elaboracin.
156
Esta tabla, permitir estableces los % de avance tanto en la confeccin revisin y

estado final de los manuales as como tambin permite tener una visin generalizada
del estado global de la confeccin de los manuales.
Procedimientos
Para la revisin de los procedimientos se recomienda lo siguiente:
Establecer fechas para la generacin, revisin, aprobacin y difusin de los

distintos procedimientos del rea informtica para con la empresa. Una vez
planteadas las fechas, se debe llevar un control del cumplimiento de las
fechas dadas, para as poder establecer el nivel de cumplimiento de los
tiempos.
Generacin de instancias internas y externas para la revisin de los

contenidos de los distintos procedimientos elaborados por parte del rea
informtica para con la empresa, as como tambin con el correcto
cumplimiento del formato establecido para este tipo de documento.
Establecer una tabla como la 6.1 para el control de los porcentajes de

avances de la generacin de procedimientos por parte del rea informtica
para con la empresa.
Plan de contingencias
Para el plan de contingencia se recomienda establecer una tabla en la que se

detallen los siguientes puntos:
Fecha de realizacin del plan as como de la ultima actualizacin
Quien es el que realiza el plan
Quien revisa el plan
Quien Aprueba el plan
Es recomendable de que el plan de contingencias cuente con una tabla especial para
los servidores y equipos dedicados para funciones atachadas al rea informtica,
adems de tablas resmenes para las contingencias generales y puntuales. Estas
tablas deberan, al menos, contar con lo siguiente:
157
Tabla Servidores
Nombre del servidor
Tipo
Aplicaciones presentes
Sistema Operativo / Nivel de actualizacin
SW. de seguridad (nombre de la aplicacin y estado)
o Antivirus
o Respaldo
o Firewall
Funcionalidad
Medida de contingencia
Nombre Servidor
Servidor de ejemplo
Tipo
Aplicaciones Presentes
Sistema Operativo /
Nivel de actualizacion
SW. De Seguridad
Antivirus
Respaldo
Firewall
Funcion
Medida de Contingencia
Tabla 6.2: Tabla Resumen de servidores para plan de contingencia.

Fuente: elaboracin propia.
158
Tabla Contingencias generales
Nombre de la contingencia
Servicio
o Origen
o Proveedor
Accin
o Responsable
o Plan
Recuperacin
o hrs. estimadas
o Contrato de soporte
Datos de contacto
Tabla Contingencias Detalle
Accin
o Plan
o Proveedor
o Responsable
Recuperacin
o Hrs. estimadas
o Contrato de soporte
Seguridad de la Informacin.
Para el tpico de seguridad de la informacin se recomienda establecer una

pauta de temas a revisar segn las indicaciones aqu dadas. Esta pauta debe
seguir una estructura del tipo check list, para as poder establecer los porcentajes
de cumplimiento de acuerdo a la cantidad de temas cumplidos.
159
La revisin del cumplimiento de este check list debe estar dada por el departamento
interno de informtica, as como tambin se recomienda realizar una revisin a travs
de un organismo externo a la empresa para as poder mantener la objetividad de la
revisin.
160
CONCLUSIN
El objetivo principal de esta memoria fue establecer puntos de referencia que reflejen
como pueden comportarse los departamentos de informtica en el mbito de las
buenas prcticas que las doctrinas para el control interno informtico establecen,
con el fin de mejorar los resultados en futuras auditorias, colaborando as con el
orden y funcionamiento de las reas de TI.
A travs de las metodologas de trabajo aqu expuestas se pueden obtener

resultados que permitan ver el funcionamiento de la sociedad en la cual se
desenvuelve el rea informtica tanto a nivel de servicio como desempeo interno,
logrando as obtener una imagen propia del comportamiento del rea en sus distintos
procesos y desempeo, como la imagen que la sociedad tiene del rea en si.
El trabajo del rea de control interno es de una complejidad particular, ya que ha

quedado de manifiesto en el estudio de que no siempre es fcil obtener resultados
ptimos de trabajo cuando una metodologa de trabajo es objetada o se le
encuentran fallas que estn normadas dentro de las revisiones establecidas por los
cnones internacionales para los departamentos de control interno. Recordemos que
por ms metodolgicos que seamos y se busque con esto la perfeccin de
funcionamiento esto no se logra en un 100%. Trabajamos con seres humanos, y
estos en su complejidad y riqueza de conocimientos
es tambin un ser de
costumbres que no siempre son fciles de cambiar.
Mejorar procedimientos, metodologas de trabajo, ensear a documentar, creacin

de polticas y normas, recomendaciones de mejoras a los procesos y documentos,
etc. Es lo que se logro establecer y verificar, cuantificando y cualificando riesgos
necesarios para la continuidad y mejor funcionamiento de los procesos asociados al
rea informtica de la sociedad estudiada.
161
De los resultados generales obtenidos a partir de la realizacin de la encuesta al

personal de la empresa, se pueden concluir algunos puntos interesantes como:
Si bien es cierto, la evaluacin en cuanto a la calidad de la atencin y calidad

de solucin por parte del rea informtica a nivel de programacin y soporte
es buena, los tiempos de respuesta es el punto a mejorar y queja constante
dentro de las respuestas y evaluaciones de los encuestados.
Resalta de que, si bien es cierto existen ciertos mecanismos a nivel de reas

para la comunicacin de polticas, procedimientos, manuales, etc. informtica
no cuenta con una comunicacin efectiva sobre los usuarios finales para la
difusin de estos documentos. Esto implica adems, el descubrimiento para el
rea informtica de una inquietud a nivel de usuarios de la necesidad de ser
capacitados e instruidos en las herramientas informticas para que estos, en
la medida que se pueda, encuentren con una autonoma al momento de
resolver problemas pequeos pero que no son solucionables por ellos
mismos. Si a esto ltimo se le suma que los tiempos de respuestas por parte
de informtica no son buenos, este pequeo problema se puede volver mayor.
El rol de soporte informtico es un poco difuso dentro de la empresa,

teniendo en cuenta que la mayora de los encuestados se refieren ms a
informtica que a soporte informtico. Por ejemplo, en el caso de que un
usuario tenga un problema con su equipo llama a alguien de informtica en
vez de llamar a alguien se soporte. Lo mismo pasa si el usuario tiene
problemas con la aplicacin ERP, se llama a alguien de informtica que a
algn programador.
Queda de manifiesto la poca claridad de los usuarios en cuanto a las polticas

de seguridad que informtica tiene a nivel de sistema y de hardware. El
usuario solo se limita a la proteccin de claves y virus, siendo que esas no son
las nicas medidas.
162
Si bien es cierto, la comunicacin con el rea informtica se hace a travs de

canales de comunicacin directa y formal dentro de la empresa, la generacin
de algn reporte o el establecimiento de un procedimiento estndar es nulo.
Todos estos puntos evidencian que la falta de un compromiso por parte del rea
informtica para normar procedimientos y trabajar con estndares mnimos dentro de
la empresa. Se deben establecer polticas, normas y procedimientos claros por parte
de informtica para las dems reas, para el trabajo conjunto en el mejoramiento del
andar tecnolgico de la empresa.
163
REFERENCIAS BIBLIOGRFICAS
(1)
Piattini M., Del Peso E., Auditoria Informtica: Un enfoque prctico,

Editorial Alfaomega, Mxico, 1998.
(2)
Navarra Garca, Fco. Javier, Apuntes de Auditoria Informtica, Disponible

en: http://www.escet.urjc.es/~ai/T1Apuntes.pdf
(3)
Soriano
Guzmn,
Genaro,
La
auditoria
interna
en
el
proceso
administrativo, Editorial CENAPEC, 1992
(4)
Rusenas, Rubn Oscar, Manual de Control Interno, Editorial Cangallo,

1978
(5)
Len Lefcovich, Mauricio, Control Interno, Un enfoque sistmico y de

mejora
continua,
Disponible
en:
http://www.wikilearning.com/monografia/auditoria_interna/11489
(6)
Instituto Nacional de Estadstica e Informtica de Lima, Gua Prctica

para el desarrollo de planes de contingencia de Sistemas de Informacin ,
2001
(7)
Chiavetano I., Administracin proceso administrativo, Mc Graw Hill,

Colombia, 2001.
(8)
Firtman S., Seguridad Informtica, MP Ediciones, Argentina, 2005.
(9)
Bravo J., Desarrollo de Sistemas de Informacin Una Visin Prctica,

Editorial Evolucin, Chile, 1996.
164
(10)
Johansen O., Introduccin a la Teora General de Sistemas, Editorial

Limusa, Mxico, 2002.
(11)
Araya A., Broquedis P., Espinoza S., Fuenzalida J., Oyanedel R., Mtodo
para la Generacin y Mantencin de la Documentacin de Sistemas de
Informacin, Santiago Chile, 1996.
(12)
Merida J., Fundamentos sobre auditoria: Auditoria y el medio ambiente

informtico, Santiago Chile.
(13)
Contralora Universitaria, Universidad de Concepcin, Los Delitos

Informticos,
2007,
Disponible
en:
http://www2.udec.cl/contraloria/docs/materias/delitosinformaticos.pdf
(14)
Palma
J.,
Manual
de
Procedimiento,
Disponible
en:
http://www.monografias.com/trabajos13/mapro/mapro.shtml
(15)
Espinola M., El aporte de COBIT 4.0 al control de proyectos TIC,

Disponible en: http://www.gestionpublica.cl/gerenciapublica/tema/35/cobit4.0-y-el-control-de-proyectos-tic/
165
ANEXOS
Anexo1: Check List
Administracin del rea IT
Estrategia a mediano y largo plazo del departamento de TI.

Existencia de servicios externalizados.
Existencia de Auditoria Interna de Sistemas.
Comit de Informtica. Forma y funcionamiento.
Grado de utilizacin de los sistemas en el funcionamiento
Percepcin de calidad del servicio proporcionado / benchmark con el mercado.
Descripcin de los principales sistemas y servidores que soportan dichas aplicaciones.
Polticas, Normas, Manuales

y Procedimientos IT:
Existencia de manuales con Polticas, Normas y Procedimientos del

rea de Informtica, sealando su nivel de formalizacin, grado de
aplicacin, origen del desarrollo y frecuencia de actualizacin, con
respecto a las siguientes actividades:
Administracin IT
Operaciones
Seguridad
Desarrollo de sistemas
Procedimientos de control de cambios a programas
Metodologa de Desarrollo y Mantencin de Sistemas

Manuales de usuarios y tcnicos.
Revisiones de Seguridad:
Mecanismos de monitoreo, administracin y control de redes. Documentacin existente y procedimientos

existentes.
Software y herramientas utilizados.
Procedimientos de Administracin
de Problemas y requerimientos:
Nivel de formalizacin, grado de aplicacin, origen del desarrollo

y frecuencia de actualizacin de estos procedimientos
Manejo de interrupciones de los distintos servicios informticos.
Modificaciones de emergencia a sistemas o datos.
Mecanismos de seguimiento y control gerencial.
Comunicacin interna
Comunicacin de responsabilidades y obligaciones a los empleados.

Efectividad de canales de comunicacin para acciones incorrectas
Existencia de canales de comunicacin de reclamos y su correcta canalizacin.
Documentacin formal de las reuniones realizadas en el departamento de Informtica.
Estndar de documentacin en la programacin del cdigo fuente de los sistemas (ERP, Web).
166
Organizacin:
Organigrama de la sociedad.
Organigrama especfico del rea de Informtica.
Estructura de Hardware:
Diagrama de comunicaciones, que especifique el hardware de red, el tipo de red, protocolos y velocidad de los enlaces.
Estructura de Software:
Diagrama de Contexto de nivel cero, que especifique claramente las interfaces entre las distintas aplicaciones.
Administracin del rea IT:
Descripciones de cargo del personal del rea de Informtica.

Plan de sistemas para el ao en curso, que incluya presupuestos.
Informes de auditoria informtica.
Procedimientos de Administracin
de Problemas:
Plan de Contingencias.
Plan de Contingencias documentado, aprobado, difundido y probado.
Cambios
Descripcin de los cambios relacionados con el rea IT ocurridos en el perodo.

Formulario estndar para los requerimientos de cambios a los sistemas.
El formulario de requerimientos de cambios es el nico medio existente para notificar los cambios.
Actividades de mantencin
Administracin de actividades de mantencin.

Especificacin, autorizacin y registro de requerimientos de cambios de sistemas, software y hardware.
Unidades, sistemas y testing de usuarios
Autorizacin de transferencias al ambiente de produccin
(incluyendo correcciones de emergencia y accesos de desarrollo al ambiente de produccin).
Actualizacin tcnica y documentacin / entrenamiento de usuarios.
Administracin de bases de datos.
Administracin de seguridad
de la informacin
Administracin de seguridad incluyendo polticas de seguridad y procesos de personal.

Configuracin de roles, responsabilidades y procedimientos.
Conocimiento de los usuarios, educacin y entrenamiento sobre seguridad.
Monitoreo de incidentes de seguridad y conformidad con los procedimientos documentados.
167
Procedimientos de seguridad
Administracin de seguridad lgica sobre acceso de usuarios a nivel de sistema operativo.

Administracin de seguridad lgica sobre datos.
Administracin continuada de seguridad dentro de los sistemas que corren sobre este ambiente.
Administracin del sistema y cuentas privilegiadas.
Seguridad fsica. Sala de servidores:
Existencia de extintores de acuerdo a la norma.
Existencia de aire acondicionado (temperatura adecuada).
Existencia de detectores de humo.
Existencia de detectores de humedad.
Existencia de piso antiesttico.
Existencia de Racks para la segregacin de servidores.
Paredes y cielo antiinflamable o con material retardante.
Canalizacin estndar para el cableado de red
y telefona (en caso de que exista).
Altura e inclinacin del nivel de suelo de la sala
de servidores respecto al exterior.
Existencia de un sistema UPS con sus mantenciones al da.
Existencia de sistema de alarmas para las distintas
eventualidades (humo, humedad y temperatura).
Existencia de control de acceso.
Control de conexiones a redes externas (Internet, EDI, EFI, etc.).
Manejo de respaldos de informacin.
Respaldo de informacin.
Control sobre el almacenaje de los respaldos de
informacin (lugar seguro y adecuado).
Pruebas de los respaldos realizados.
Registro o bitcora de los respaldos realizados.
Administracin de las operaciones

computarizadas
Establecimiento de nivel de requerimientos de servicios.

Configuracin de roles, responsabilidades y procedimientos.
Planes de continuidad del negocio.
Administracin de redes.
168

IT2726

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IT2726

Încărcat de

Drepturi de autor:

Formate disponibile

FACULTAD DE INGENIERA

ESCUELA DE INGENIERA VESPERTINA

IMPLEMENTACIN DE PROCESOS DE CONTROL INTERNO

ALVARO ESTEBAN JORDAN DIAZ

Profesor Gua: Ral Riquelme Rojas

MEMORIA PARA OPTAR AL TTULO DE INGENIERO EN INFORMTICA Y

La presente memoria trata sobre la implementacin de procesos de control interno en

Es as como, en esta memoria, se presentan fundamentos para los sistemas de

Adems, se expresa el estado actual de la empresa en estudio, resultado de las

Quiero agradecer a todos quienes de alguna u otra forma me alentaron a terminar

Alvaro Jordan Daz

Fabiola Soto Godoy

Alvaro Jordan Daz

OBJETIVO GENERAL ............................................................................................................................. 13

TEORA GENERAL DE SISTEMAS ........................................................................................................... 17

CAPITULO III ............................................................................................................ 52

CONTROL INTERNO INFORMTICO ........................................................................................................ 52

Metodologas cuantitativas ..........................................................................................................................66

Metodologas de anlisis de riesgos ............................................................................................................69

CONTROL INTERNO INFORMTICO. SUS MTODOS Y PROCEDIMIENTOS. LAS HERRAMIENTAS DE

PLATAFORMA OPERATIVA ................................................................................................................... 78

Identificacin del pblico objetivo ..............................................................................................................89

CAPITULO VI.......................................................................................................... 131

CONCLUSIN ........................................................................................................ 161

Figura 2.1: Energa de Retorno (retroalimentacin) .................................................. 23

Estamos envueltos en un mundo en que la informacin es constantemente transada

Es as como el manejo de la informacin por parte de las empresas es crucial, no

El Instituto de Auditores Internos de los Estados Unidos define la auditoria interna

La direccin de la organizacin tiene la responsabilidad de decidir el alcance

La delegacin de la responsabilidad y de la autoridad

Existencia de personal competente y de confianza

Documentacin y registros adecuados

El control fsico sobre activos y registros

La adecuada supervisin de la gestin

La verificacin independiente de las operaciones

Es as pues, que la carencia de control en las actividades que se realizan en el rea

Se presentar la situacin actual del rea de informtica de una determinada

Para determinar las deficiencias ms significativas dentro del rea, se realiz un

Encuestas a personal de rea Informtica: se les pregunt sobre los registros

En base a los resultados obtenidos en el estudio, se realiz una serie de propuestas

Al compartir las experiencias laborales de quienes realizan esta memoria se encontr

Falta de actualizacin y conocimiento de los procedimientos propios, falta de

Porque establecer pautas de estndares ya existentes? Simple. Estas pautas no se

Adems, quienes desarrollan esta memoria se han visto envueltos en auditorias

El objetivo principal de esta memoria es proponer un marco de referencia que refleje

La consecucin del objetivo general del proyecto se desglosa en objetivos

Determinar el estado actual del rea de TI en estudio: Se debe presentar

Mejorar la elaboracin de procedimientos. Se aconseja y orienta sobre lo

Elaborar pautas para manuales de uso: Se definen aspectos bsicos de lo

Definir pautas para la creacin de polticas y normativas. Cmo crear una

informtica, como reportarla

estandarizarla. Como llevar un control sobre el nivel de cumplimiento de las

Fomentar cultura sobre la documentacin. Tratar de ensear que es lo que

Establecer metodologas de trabajo: Como conseguir los objetivos

Etapa de Organizacin: En esta etapa se organiza y conforma el grupo de proyecto,

Etapa de Introduccin y marco terico de Investigacin: Esta etapa recopila

Manuales de uso, procedimientos y contingencias.

Con el fin de desarrollar de forma ptima los temas anteriormente mencionados se

Estructura de polticas empresariales.

Buenas prcticas. (Metodologas y teoras).

Aspectos legales de auditoria y manejo de informacin.

Etapa de Desarrollo: Esta etapa consta de tres partes:

Analizar la empresa enfocndose al rea informtica. Estructura y

Clasificacin y cuantificacin de problemas detectados.