Pcia. Bs - As. - Elissondo - R32301el

TITULO DEL TRABAJO: AUDITORIA DE LA
ADQUISICIÓN DE SOFTWARE
AREA: III Contabilidad y Auditoría .
TEMA: 2 Auditoría - La auditoría de Sistemas Electrónicos de Información.
CONGRESO: 15 Congreso Nacional de Profesionales en Ciencias Económicas – Salta 20,21
y 22 de Octubre de 2004.
AUTOR: Cr. Luis Elissondo – Miembro del Centro de Estudios Contables de la Facultad de
Ciencias Económicas de la Universidad Nacional del Centro de la Provincia de Buenos Aires-
Trabajo Coordinado por el Dr. Cayetano Mora – Tomo XXXVI Folio 126 del Consejo
Profesional de Cs. Económicas de la Provincia de Buenos Aires.
DATOS DOMICILIO: FERNÁNDEZ DE LA CRUZ 975 – 7000 TANDIL – PCIA BUENOS
AIRES – TEL. 02293-15640151

TITULO DEL TRABAJO: AUDITORIA DE LA
ADQUISICIÓN DE SOFTWARE
AREA: III Contabilidad y Auditoría .
TEMA: 2 Auditoría - La auditoría de Sistemas Electrónicos de Información.
CONGRESO: 15 Congreso Nacional de Profesionales en Ciencias Económicas – Salta 20,21
y 22 de Octubre de 2004.
RESUMEN DEL TRABAJO
Los procesos organizacionales han pasado a estar soportados en su mayoría en sistemas de
información que normalmente son adquiridos a empresas especializadas en la temática.
El presente trabajo busca brindar una herramienta para aquellos auditores que deben evaluar
un proceso de adquisición de software, donde se analizan diversos aspectos relacionados con
la revisión de dicho proceso.
Para esto se propone una visión amplia de esta tarea de revisión a partir de la incorporación de
la evaluación del Ambiente del Proyecto y del Impacto del mismo en lo que hace al Negocio
y a Aspectos Funcionales y Tecnológicos.
También se incorporan para cada etapa cuadros donde se indican los objetivos de control,
riesgos relacionados y actividades a realizar para verificar los objetivos de control que se
proponen.
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Índice del Trabajo
INTRODUCCIÓN 3
ROL ESPERADO DEL AUDITOR 4
ENFOQUES PARA ENCARAR LA AUDITORÍA DEL PROCESO DE ADQUISICIÓN

5
ETAPAS DE LA REVISIÓN DEL PROCESO DE ADQUISICIÓN DEL SOFTWARE 6
REVISIÓN DEL PROYECTO 6
AMBIENTE DEL PROYECTO 7
OBJETIVOS DE CONTROL Y RIESGOS DEL AMBIENTE 9
IMPACTO DEL PROYECTO 12
IMPACTO EN EL NEGOCIO 13
OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS CON EL IMPACTO EN EL NEGOCIO 16
IMPACTO FUNCIONAL 16
OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS CON EL IMPACTO FUNCIONAL 18
IMPACTO TECNOLÓGICO 19
OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS AL IMPACTO TECNOLÓGICO 22
REVISIÓN DEL PROCESO DE ADQUISICIÓN E IMPLANTACIÓN 22
REVISIÓN DEL REQUERIMIENTO 23
OBJETIVOS DE CONTROL Y RIESGO DE LA ETAPA DE REVISIÓN DE LOS REQUERIMIENTOS
24
PAGINA 1
REVISIÓN DEL DISEÑO DEL REQUERIMIENTO 25
OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE REVISIÓN DEL DISEÑO DEL
REQUERIMIENTO 25
REVISIÓN DEL PROCESO DE SELECCIÓN DE LA SOLUCIÓN 26
OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE SELECCIÓN DE LA SOLUCIÓN 26
REVISIÓN DE LA ETAPA DE INSTALACIÓN Y CUSTOMIZACIÓN 27
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE INSTALACIÓN CUSTOMIZACIÓN DEL
PRODUCTO 28
REVISIÓN DE LA ETAPA DE PRUEBA Y PARALELO 28
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE PRUEBA Y PARALELO 29
REVISIÓN DEL PROCESO DE ENTREGA Y ACEPTACIÓN DEL SISTEMA 30
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE ENTREGA Y ACEPTACIÓN DEL
SISTEMA 31
REVISIÓN DE LA ETAPA DE MANTENIMIENTO 31
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE MANTENIMIENTO 32
CONCLUSIÓN 33
Bibliografía Consultada 33
PAGINA 2
Introducción
Cada vez son mas las organizaciones que se ven sometidas a la tarea de seleccionar el
software con el cual se soportaran sus procesos de negocios. El software se ha vuelto un
recurso estratégico indispensable para las organizaciones, muchas de las cuales verían
inviable su negocio sin este recurso.
Esta suerte de vinculo entre sistemas y negocios también a provocado que los tiempos de
respuesta que se le exigen a la gente de sistemas para la producción y/o adaptación de los
sistemas sean cada vez menores debido fundamentalmente a la dinámica que el mercado le
imprime a los negocios.
A esto se debe sumar que muchas empresas a tomado la decisión de disminuir de manera
sensible los servicios propios de sistemas y han optado por tercerizar el desarrollo de sus
aplicaciones y el resto de las funciones asociadas al mismo.
Otro elemento que gravita en la decisión de las empresas para optar por la adquisición de
desarrollos realizados por terceros es no volver a inventar la rueda tomando los sistemas que
ya existen en e mercado y dedicando su equipo de sistemas a la producción del software que
el mercado no provee.
Si bien lo expresado en los párrafos anteriores de por sí justifica la intervención del Auditor
en la selección del software, se pueden enumerar otros motivos por los que se justifica la
auditoria del proceso de adquisición del software:
PAGINA 3
 El gasto destinado a software es un componente cada vez más importante de la inversión
en Tecnología Informática que realizan las empresas.
 El software es un producto muy difícil de evaluar. Un mayor control el proceso de
selección y adquisición aumenta la posibilidad de éxito final del proyecto.
 El índice de fracasos en proyectos de desarrollo es alta, lo cual nota la inexistencia o mal
funcionamiento de los controles de este proceso. Los datos del Government Accounting
Office Report (EEUU) muestran este hecho:
 Un 1,5 % se usó tal y como se entregó

 Un 3,0 % se usó después de algunos cambios
 Un 19,5 % se usó y luego se abandono o se rehizo
 Un 47 % se entregó pero nunca se usó
 Un 29 % se pagó pero nunca se entregó
Rol esperado del auditor
Si bien no es el objetivo de este trabajo establecer cual debe ser el rol del auditor en cuanto al
grado de participación en este tipo de procesos, podemos decir que las posibilidades son las
siguientes:
 Analizar el proceso una vez que el mismo aconteció y establecer los desvíos o problemas
que encuentren. Este enfoque se asimilaría a cualquier otra revisión de las adquisiciones
que realiza la organización.
 Participar en el proceso de selección realizando las tareas mencionadas en el punto anterior
pero además emitiendo opinión sobre el software que se debe adquirir desde el punto de
vista de la calidad del control interno y de los posibles inconvenientes que se pueden
presentar. Esto implica también asesorar en el proceso de selección indicando los controles
deseables, calidad del armado de lotes de prueba, sugiriendo posibles adaptaciones en
materia de seguridad y controles, etc., pero sin emitir una opinión o recomendación
PAGINA 4
respecto de un producto determinado. Este enfoque podría implicar que el auditor se
involucre, pero en cierta forma esta intervención en el proceso de adquisición se puede
justificar en el hecho de que el auditor luego deberá realizar la revisión de los controles
internos de la organización que estarán soportados en el sistema que se adquiera y por lo
tanto es preferible que actúe de manera proactiva, es decir antes de encontrarse con un
hecho ya consumado.
Enfoques para encarar la auditoría del proceso de

adquisición
Más allá del rol que le toque jugar al auditor, la propuesta de revisión que aquí se realiza tiene
diversas formas de ser abordada de acuerdo al trabajo que se le encomiende al auditor. Esto
es:
-Evaluar el proceso de adquisición: Es decir determinar si la adquisición del software fue
realizada de acuerdo a prácticas razonables para este tipo de procedimiento. Es decir tomar el
proceso como un elemento aislado y puntual.
-Evaluar el proyecto en forma integral: Aquí la revisión incluye aspectos relacionados con
el gerenciamiento y calidad del proyecto. El proceso de adquisición se considera una etapa
dentro de la evaluación del proyecto.
-Evaluar el impacto del software adquirido en relación al negocio: En este caso, además
de los aspectos enunciados anteriormente se incluye el análisis del ambiente del proyecto es
decir que se evalúan otros aspectos tales como la existencia de un plan de sistemas, nivel de
integración de dicho plan con el plan estratégico de negocios, organización del área de
sistemas, etc.
En este trabajo se propone el último de estos enfoques a efectos de dar un tratamiento amplio
PAGINA 5
a la problemática propuesta, en el entendimiento de que luego cada profesional podrá limitar
la aplicación de esta propuesta de acuerdo a la realidad que lo rodea y de los recursos de los
que dispone.
Etapas de la revisión del proceso de adquisición del

Software
Tomando la propuesta más amplia, se proponen las siguientes etapas de revisión:
Etapas de Revisión
Revisión del Proyecto
Proceso de Adquisición
Seguimiento
Gráfico 1 – Etapas de la Revisión
 Revisión del Proyecto: La existencia de un proyecto adecuadamente administrado y
en el cual se trabaja con una metodología preestablecida permite presumir que el
proceso de adquisición de software se realiza en un ambiente planificación y mayor
control.
 Proceso de Adquisición: Es la adquisición en si misma que abarcar desde el proceso
de establecimiento de requerimientos hasta la adquisición.
 Seguimiento: Una vez instalado el sistema y estabilizado se debe verificar que el
sistema cumple con lo establecido y que el servicio de mantenimiento y soporte
pactado con el proveedor se cumple satisfactoriamente.
Revisión del Proyecto
PAGINA 6
Como se han mencionado en el punto anterior el objetivo es revisar aspectos que permiten
establecer la eficiencia y eficacia del proyecto encarado. Para esto se ha divido la revisión en
dos aspectos:
 Ambiente del Proyecto: Por ambiente del proyecto se entiende a todos aquellos
aspectos, que si bien no se encuentran directamente vinculados, influyen sobre el
mismo y permiten tener un primer grado de aproximación a cerca de la calidad del
proyecto. Dentro de estos encontramos la posibilidad de verificar la existencia de un
plan estratégico de sistemas, la forma en que el proyecto es administrado, la
metodología utilizada y el nivel tecnológico de la organización.
 Impacto del Proyecto: El objetivo de medir el impacto del proyecto es para
determinar los riesgos a los que se encuentra sometida la organización al incorporar el
software en cuestión. Es así que se debe revisar lo relacionado con el impacto sobre el
esquema de negocios, el impacto que implicaría un cambio tecnológico y el impacto
que un nuevo sistema tendría sobre aspectos funcionales, es decir sobre los procesos
que se realizan en la organización.
Ambiente del Proyecto
El ambiente del proyecto esta conformado por diversos aspectos, la inexistencia total o parcial
de estos elementos no implica que debamos inferir que el proyecto adolece de graves
falencias. Significa que deberemos realizar una revisión mas intensiva de algunos puntos.
Digamos entonces que en esta etapa de la revisión se trata de establecer si los puntos de apoyo
del proyecto son los adecuados para que el mismo pueda llegar a un buen fin.
Dentro de los aspectos a ser considerados en el ambiente encontramos:
PAGINA 7
Información sobre el ambiente
Plan Estrategico Administración

De Sistemas del
Proyecto
Ambiente del Proyecto
Metodología Tecnología
Gráfico 2 – Aspectos del Ambiente
Plan estratégico de Sistemas: La existencia de una planificación del recurso informático y el
grado de integración del mismo con el Plan Estratégico de Negocio nos permite establecer el
grado de importancia que la organización le da a sus sistemas y además que las acciones son
realizadas de acuerdo a una planificación previa evitando de esta forma que el accionar solo
obedezca a impulsos que nada tienen que ver con criterios básicos de administración.
Administración del proyecto: Deben existir adecuadas pautas para el manejo de proyectos
como son: la determinación de un líder de proyecto, la asignación calidad de los recursos
humanos involucrados, la existencia de herramientas para el seguimiento de los proyectos y la
existencia de informes periódicos de avance del mismo.
Metodología: La existencia de una metodología permite establecer la existencia de pasos
predeterminados que deben ser seguidos por los distintos proyectos como una forma de
asegurar la calidad de los mismos.
Tecnología: El nivel tecnológico alcanzado por los aplicativos que integran la cartera de
aplicaciones es un elemento de vital importancia para determinar si la nueva aplicación a ser
incorporada representa un salto cualitativo que la organización puede asimilar sin mayores
PAGINA 8
dificultades. En este sentido es fundamental verificar la existencia de una planificación de la
incorporación de los recursos tecnológicos, esto permite inferir que cada “salto” tecnológico
es medido adecuadamente a efectos de determinar su impacto en la organización.
En el próximo punto se establecen los objetivos de control, riesgos asociados y revisiones
mínimas a realizar para verificar el ambiente del proyecto. Es importante aclarar que se habla
de revisiones mínimas ya que no es el objetivo del trabajo auditar cada uno de los elementos
del ambiente ya que esto requerirá de un esfuerzo (tiempo y recursos) específicamente
orientado al análisis de cada uno de ellos.
Mas bien se intenta que el auditor pueda delimitar más claramente las responsabilidades al
momento de emitir su opinión. Esto quiere decir que si desde el nivel directivo no existe una
preocupación e involucramiento en tipo de proyectos ó nunca existió una directiva al respecto
son también responsables por los resultados que se obtengan.
Objetivos de Control y Riesgos del Ambiente
Cuadro 1 - Objetivos de control Relacionados con Plan Estratégico de Sistemas
Plan Estratégico de Sistemas

Objetivo de Control Riesgos Asociados Verificaciones a Realizar
El Plan de sistemas Los sistemas no Existencia de un plan
contempla las necesidades responden a las formalizado y aprobado por
organizaciones y el necesidades de la el nivel máximo de la
crecimiento del negocio y se organización. organización.
encuentra adecuadamente Inflexibilidad de los Verificación de la
aprobado por la dirección y es sistemas ante nuevos actualización periódica del
periódicamente revisado ante requerimientos plan.
cambios en la planificación organizacionales. Revisión de la
de la organización. Desvinculación entre los documentación del
distintos sistemas. directorio (actas de
Comportamiento reuniones, instrucciones de
desordenado y errático en la dirección, existencia de
el desarrollo y adquisición un responsable de la
PAGINA 9
de aplicaciones. formulación, etc.

Desconocimiento de la Los cambios de los
existencia o alcance del proyectos impactan en el
plan por parte de las plan de sistemas.
distintas áreas
organizacionales.
La asignación de recursos
no es la adecuada dado la
dimensión del proyecto.
Cuadro 2 -Objetivos de Control y Riesgos Asociados con la Administración del Proyecto
Administración del Proyecto

El proyecto se encuentra El proyecto no fue Existencia de un documento
adecuamente definido y adecuadamente aprobado (memorando o norma
aprobado por la autoridad y formalizado interna) donde se aprueba el
competente y se inserta en el Mala integración entre los proyecto
plan de sistemas de la distintos proyectos. Existencia de un plan del
organización. Descoordinación con las área de sistemas.
áreas usuarias. Existencia de un “proyect“
donde se establecen los
plazos y los recursos
asignados.
El proyecto debe ser Existencia de problemas Existencia de una

adecuadamente dimensionado para llevar adelante el evaluación del proyecto en
y su impacto adecuadamente proyecto. cuento a su impacto en el
valorado. (para mayor detalle negocio, en aspectos
ver en este trabajo punto funcionales y tecnológico.
Impacto del Proyecto) Se ha realizado el
presupuesto financiero del
proyecto y se ha realizado la
comparación del proyecto
contra otros proyectos de
inversión.
Verificar la adecuada El sistema no responde a Se contempla la
participación de los usuarios las necesidades de los participación de usuarios a
en el proyecto. usuarios. través de comités u otras
Los usuarios no participan formas de organización.
en las distintas etapas del Existe un registro con las
proyecto. inquietudes de los usuarios.
PAGINA 10
Debe existir un responsable o El proyecto no es Los tiempos, grado de

director del proyecto que adecuadamente dirigido y avance y recursos asignados
establezca el adecuado uso de las tareas no son llevadas a los proyectos son
los recursos y resuelva los adelante en tiempo y periódicamente revisados
problemas que puedan surgir. forma. por el responsable del
No se miden los desvíos y proyecto.
se toman las acciones Existe un mecanismo de
correctivas respectivas. resolución problemas.
Superposición de Existencia de un documento
funciones y problemas de donde se establezcan
coordinación. responsabilidades y tareas.
Los recursos asignados para Existen etapas del Verificar que la existencia o
cada etapa del proyecto son proyecto que no se pueden disponibilidad de recursos
los adecuados de acuerdo a cumplir por falta de humanos y materiales al
las prioridades fijadas. recursos o los recursos no proyecto son los adecuados.
son los adecuados.
Inadecuada
administración de
prioridades y asignación
de recursos.
Las etapas previstas deben ser Existen desviaciones que Verificación de los
cumplimentadas en tiempo y no son adecuadamente controles establecidos por el
forma finalizadas en tiempo y responsable del proyecto y
forma. de las acciones correctivas
No se corrige los errores o correspondientes.
desviaciones
Existe un cierre del proyecto El proyecto no queda Existe un documento donde
formalmente terminado. se informa los resultados del
No se realiza un proyecto y donde se indica
evaluación final. la liberación de los recursos
afectados.
Cuadro 3 - Objetivos de Control y Riesgos Asociados con la Metodología
Metodología
Existe una metodología y la No se aplica una Existe documentada una
misma se encuentra metodología para el metodología de trabajo.
adecuadamente formalizada. desarrollo del proyecto
La metodología abarca todo La metodología no abarca Amplitud y alcance de la

el proceso del ciclo de vida de
todas la etapas del metodología utilizada.
los sistemas y contempla los desarrollo de sistemas. Existencia de una
pasos para la adquisición de No existe una metodología para la
aplicaciones. metodología para la adquisición de software.
adquisición de
aplicaciones
La metodología es conocida y Cada proyecto aplica su Verificar que etapas
PAGINA 11
aplicada por todos los propio criterio para el metodológicas iguales son
integrantes de los distintos desarrollo de las tareas. aplicadas de la misma forma
proyectos en los distintos proyectos.
La metodología es La metodología utilizada Existe un proceso de
adecuadamente actualizada. no es aplicada porque a revisión y actualización
quedado desactualizada periódica de la metodología
para resolver los empleada.
problemas actuales.
Cuadro 4 - Objetivos de Control y Riesgos Asociados con la Tecnología
Tecnología
Se realiza una planificación En la organización hay Existencia de un plan de
de los aspectos tecnológicos y diversas tecnologías en desarrollo tecnológico y de
es periódicamente revisada uso que son incompatibles compatibilidad entre
entre sí. distintos estándares.
La tecnología está
desactualizada.
No existen planes de
actualización de la
tecnología.
Existe una definición de La adquisición de Los estándares tecnológicos

estándares tecnológicos. tecnología se realiza sin están adecuadamente
tener en cuenta ningún definidos y formalizados.
estándar lo que provoca
incompatibilidades.
Los nuevos proyectos se Los nuevos proyectos Los responsables de los
ajustan a los estándares establecen sus propios nuevos proyectos toman
establecidos. estándares como base los estándares
establecidos.
Existe una planificación para No existe pautas para la Existencia de un plan de

la adquisición e incorporación de nueva adquisición de nueva
implementación de nuevas metodología tecnologías.
tecnologías.
Impacto del proyecto
El objetivo de medir el impacto que el proyecto tiene es a efectos de determinar los riesgos a
los que se encuentra sometida la organización al incorporar el software en cuestión.
PAGINA 12
Analisis del Impacto del

Proyecto
Negocio Tecnológico
Tamaño del Proyecto
Funcional
Gráfico 3 – Impacto del Proyecto
El principal riesgo está dado el tamaño del proyecto. Existen diversos factores que nos
permiten establecer el tamaño del proyecto:
 Cantidad de áreas involucradas: La existencia de distintas áreas con diversos
intereses que deben ser satisfechos por el sistema.
 Niveles organizacionales involucrados: Si el sistema va a ser utilizado por más de
un nivel de la organización deben contemplarse las necesidades de niveles
gerenciales, gerencias medias y el nivel operativo.
 Cantidad de Recursos Involucrados: Cantidad de personas que directa o
indirectamente se encuentran vinculadas al proyecto y volumen de la inversión.
El tamaño del proyecto no es el único elemento que es generador de riesgo, pudiéndose
determinar otros aspectos tales como el impacto del proyecto en el negocio, el impacto
funcional y el impacto tecnológico, elementos que combinados con el tamaño pueden
considerarse como elementos potenciadores del riesgo.
Impacto en el negocio
De acuerdo al tipo de aplicación que se adquiere esta puede ser más o menos vital para el
PAGINA 13
desenvolvimiento del negocio. Es decir que si estamos evaluado la adquisición de un software
que permitirá la autogestión de los clientes a través de internet no hay duda que el impacto es
muy importante. Lo mismo cuando el software en cuestión soporta tareas que son el “core
competence” de la organización, es decir que el sistema a adquirir respeta o potencia los
procesos que hoy le permiten a la organización diferenciarse del resto.
Esto tiene sin duda impacto cuando se audita la fase de Análisis de Necesidades y de
establecimiento de requerimientos ya que sin duda estos procesos deberán estar
adecuadamente explicitados en los requerimientos para que el software que se adquiera los
respete, caso contrario deberán figurar en los requerimientos de customización del mismo.
Impacto en el Negocio
Riesgo Medio Riesgo Alto
Grande
Problemas de Peligra la
adminisración supervivencia
Riesgo Bajo Riesgo Medio

Reducido
Mala utilización Demora en la

de recursos implementación
de negocios
Bajo Alto
Impacto en el proceso de Negocio
Gráfico 4 – Impacto en el Negocio
En el gráfico 4 se entrecruza la variable tamaño del proyecto con impacto en el proceso de
negocios. Pudiéndose determinar cuatro situaciones:
Alto impacto en el negocio y Proyecto Amplio – Alto Riesgo: En este caso se trata de un
proyecto de alto impacto en el negocio y de una alta complejidad importante dada su tamaño.
El riesgo esta dado básicamente porque existe la posibilidad de que el proyecto tenga
PAGINA 14
inconvenientes si no existe una administración y recursos adecuados al tamaño y además
porque se trata de un proyecto fundamental para el desarrollo del negocio. En este caso el
riesgo emergente es el peligro de desaparición de la organización o del proyecto de negocios
que se basa en el sistema que se adquiere y la imposibilidad de volver a invertir los recursos
para intentar un nuevo proceso de implementación.
Alto impacto en el negocio y Proyecto reducido – Riesgo Medio: La variante respecto del
caso anterior es que el grado de complejidad o tamaño del proyecto en este caso es reducida lo
cual permitiría por un lado contar con mayores posibilidades de éxito en la administración del
proyecto y en caso de existir inconvenientes es más fácil atacarlos. De todas formas aún
existiendo posibilidades de recuperar la situación el riesgo sigue importante ya que es la
función de negocios la que se ve comprometida.
Bajo Impacto en el negocio y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto de alta complejidad pero que no tiene un impacto alto sobre el negocio. De todas
formas aún tratándose de una situación operativa sabemos que estas tampoco son ajenas al
desarrollo del negocio. En este caso se ha calificado el riesgo como medio debido a que no se
afecta directamente la continuidad del negocio.
Bajo Impacto en el Negocio y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de menor relevancia que no afectará la continuidad del negocio. En este punto el
riesgo esta dado por la mala utilización de los fondos destinados al proyecto.
PAGINA 15
Objetivos de Control y Riesgos asociados con el Impacto en el Negocio
Cuadro 5 – Objetivos de Control y Riesgos Asociados con el Impacto en el Negocio
Impacto en el Negocio
El proyecto se encuentra Los sistemas no El plan estratégico de
dentro del marco del plan de responden a las sistemas es coordinado con
negocios de la empresa. necesidades del negocio. el plan de negocios.
Las especificaciones La habilidades propias del En la documentación de los
establecidas contemplan los negocio no se encuentran requerimientos se
factores esenciales del apoyadas por los nuevos identifican las habilidades
negocio. sistemas. principales que distinguen a
la empresa.
El sistema tiene la capacidad El sistema se muestra Se ha previsto que el o los
de adaptarse a nuevas reglas inflexible ante nuevos sistemas sean
del negocio. cambios. parametrizables y flexibles
para adaptarse a los
cambios.
Se ha medido adecuadamente El negocio se ve Se ha previsto el alcance e
el impacto del proyecto en el seriamente cuestionado impacto del proyecto como
negocio ante el fracaso del así también las
proyecto de sistemas. consecuencias del fracaso
del mismo.
Impacto Funcional
En este caso lo que se mide es la viabilidad operativa del proyecto, es decir si el mismo podrá
ser incorporado a la organización sin mayores problemas.
La medición del impacto funcional esta dada fundamentalmente por:
 Cantidad de Sectores Involucrados: A mayor cantidad de sector más difícil su
posterior implementación.
 Cantidad de Procesos y Profundidad del Cambio: En este caso se debe sopesar que
porcentaje de procesos se cambian o modifican en el proyecto y a su vez cual es el
grado variación que sufren que puede ir de un cambio menor hasta la desaparición del
proceso.
PAGINA 16
 Cantidad de aplicaciones involucradas: En el caso que el sistema que se adquiera tenga
muchas vinculaciones con otros sistemas ya existentes en la organización debe
analizarse el grado de compatibilidad y la existencia de adecuadas interfaces. El otro
caso es que el nuevo sistema reemplaza a más de un sistema anterior (como es el caso
cuando se instalan sistemas integrados que reemplazan a más de una aplicación) por lo
que se deberán administrar múltiples paralelos con los sistemas anteriores.
Impacto Funcional
Riesgo Riesgo Alto
Amplio
Moderado
Viabilidad del
Problemas de Proyecto
Administración
Riesgo
Reducido
Riesgo Bajo Moderado

Adaptación
operativa
Bajo Alto
Impacto funcional
Gráfico 5 – Impacto Funcional
Alto impacto Funcional y Proyecto Amplio – Riesgo Alto: En este caso se encuentra en
juego la viabilidad del proyecto en cuanto a la posibilidad real de implementación del mismo
dado que al tratarse de un proyecto de tipo amplio se encontrará a mas de un sector
involucrado y a mucho de los procesos organizacionales.
En este tipo de proyecto además de la propia complejidad de tener que actuar con múltiples
usuarios que tienen múltiples intereses que deberán tenerse en cuenta, se encuentra la
complejidad de implementar un sistema en más de un sector. Para este punto es importante
establecer si el proyecto puede ser implementado por módulos de forma tal de ir
PAGINA 17
implementando el sistema en forma gradual.
Alto impacto Funcional y Proyecto reducido – Riesgo Moderado: La variante respecto del
caso anterior es que tiene un alto impacto en los aspectos funcionales pero la problemática se
ve acotada a un sector.
A efectos de establecer el riesgo en este caso lo importante es establecer cuán critico es el
sector que se encuentra involucrado en el proyecto. Si se trata de un sector crítico como
podría ser la automatización de requerimientos de autopartes en una industria automotriz, en
donde una falla en los requerimientos que se hagan a los autopartistas puede afectar los plazos
de entregas de los automóviles y por ende incumplir con las entregas pactadas a los clientes.
En este caso el riesgo está dado fundamentalmente por el grado de adaptación operativa del
sector en cuestión.
Bajo Impacto Funcional y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organización pero que no comprende a un gran número
de procesos.
En este caso el riesgo esta dado fundamentalmente por los inconvenientes que puedan surgir
de la administración de un proyecto que abarca más de un sector.
Bajo Impacto Funcional y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de menor tamaño acotado a un sector y que afecta procesos poco relevantes.
Objetivos de Control y Riesgos asociados con el Impacto Funcional
PAGINA 18
Cuadro 6 – Objetivos de Control y Riesgos Asociados con el Impacto Funcional
Impacto Funcional
Todos los sectores Los sectores no conocen Existencia de
involucrados conocen el como el proyecto o nuevo comunicaciones internas
proyecto y como este los sistema los afectará que establezcan el alcance y
afecta profundidad del proyecto
Los sectores participan del Los sectores se ven Existencia de un foro de
proyecto. imposibilitados de discusión o comité de
establecer los usuarios.
requerimientos de Existencia de un registro de
información. requerimientos.
Todos los procesos afectados Existen procesos que no Existe un equipo de trabajo
han sido considerados y se son soportados por el que se encarga de la
han identificado los procesos sistema. interface entre el proyecto
que cambian, los que Se siguen realizando de sistemas y los nuevos
desaparecen y los nuevos procesos que no tienen procesos.
procesos sentido en un nuevo Existe documentación
esquema de trabajo. donde se formalizan los
Se desconocen los nuevos nuevos procesos.
procesos.
Se han respetado las pautas Los cambios de procesos
Se ha realizado la revisión
de control interno. que surgen de la
de los puntos de control
implementación del nuevo
interno.
sistema han afectado el
Los nuevos puntos de
control interno. control interno se
encuentran adecuadamente
formalizados.
Las relaciones entre sectores Existe descoordinación Se han formalizado
y aplicaciones se han entre áreas y sistemas. adecuadamente las
establecido correctamente interfaces entre sectores y
aplicaciones.
Impacto tecnológico
Si el proyecto representa un paso importante en cuanto al tipo de tecnología implica un riesgo
ya que son múltiples los factores que intervienen en una mejora tecnológica y por lo tanto
surgen nuevos riesgos a los que la organización está expuesta.
La medición o graduación del impacto tecnológico esta dado por:
PAGINA 19
 Cambio de Plataforma: Cuando se pasa de plataformas cerradas a plataformas abiertas.
O de un ambiente de mainframes a un ambiente de redes. En este caso los cambios en
criterios de administración de los recursos y de aspectos de seguridad son muy
importantes.
 Ambiente de Desarrollo: La incorporación de bases de datos relacionales o de ambientes
de trabajo orientados a objetos con entornos visuales, implica nuevas formas de tratar la
información en cuanto a controles que se realizan en la captura y en almacenamiento de
los datos. Si tomamos por ejemplo la incorporación de bases de datos las mismas por un
lado facilitan el desarrollo y modificación de los sistemas pero a su vez tienen su propio
esquema de seguridad de acceso a los datos y permiten el acceso y modificación de los
mismos sin necesidad de contar con una aplicación para hacerlo.
 Conocimiento de la Tecnología: Cuando el cambio tecnológico es muy importante es
probable que las personas que hoy se encuentran en la organización no tengan el
conocimiento suficiente para administrar la misma. Si este es el caso en el proyecto deberá
estar considerado el plan de capacitación adecuado para el personal involucrado en
aspectos tecnológicos.
 Equipamiento y Licencias: Normalmente los cambios en la tecnología del software
vienen acompañados con nuevos requerimientos en cuanto a velocidad de procesamiento
y de memoria del equipo necesario para correr dicho software. Lo que implica que el
proyecto debe contemplar el análisis de la infraestructura existente y el proceso de
adquisición de nuevo equipamiento. Otro aspecto importante a tener presente cuando se
adquieren sistemas que corren sobre base de datos es si las licencias se encuentran
incluidas en el precio o deben ser adquiridas en forma separada.
PAGINA 20
Impacto Tecnológico
Riesgo Riesgo Alto
Amplio
Moderado
Posible fracaso
Problemas de del proyecto
administración
Riesgo
Reducido
Riesgo Bajo Moderado
Posibles
demoras
Bajo Alto
Impacto tecnológico
Gráfico 6 – Impacto Tecnológico
Alto impacto Tecnológico y Proyecto Amplio – Alto Riesgo: En este caso el problema esta
en la diseminación de la tecnología en muchas áreas de la organización. Si el nivel de retraso
en equipamiento y plataforma de software es importante en muchas áreas de la organización,
el trabajo de actualización será mayor. La tecnología también impacta en la adaptación de los
recursos a un nuevo entorno visual con lo cual la introducción del nuevo sistema también
deberá afrontar esta dificultad.
Alto impacto Tecnológico y Proyecto reducido – Riesgo Moderado: La variante respecto
del caso anterior es que tiene un alto impacto en los aspectos tecnológico pero la
problemática se ve acotada a un sector o proceso especifico. A efectos de establecer el riesgo
en este caso también lo importante es establecer cuán critico es el sector o proceso al que se
encuentra involucrado en el proyecto.
Bajo Impacto Tecnológico y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organización pero no existen cambios tecnológicos
sustantivos.
PAGINA 21
Bajo Impacto Tecnológico y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de que no implica un cambio tecnológico sustancial y que no impacta sobre gran
parte de la organización. Este seria el caso de una actualización a una nueva versión del
aplicativo que ya esta en uso y en la cual los cambios no son sustantivos.
Objetivos de Control y Riesgos asociados al Impacto Tecnológico
Cuadro 7 – Objetivos de Control y Riesgos Asociados con el Impacto Tecnológico
Impacto Tecnológico
Existe un plan de La infraesctructura Existencia de un plan a
infraestructura tecnológica. tecnológica crece en mediano y largo plazo
forma errática acerca de la infraestructura
tecnológica de la
organización.
La infraestructura tecnológica Existen dificultades para Existencia de un proceso de
se encuentra adecuadamente correr nuevas aplicaciones actualización tecnológica.
actualizada y el personal debido a que en algunos Existen actividades de
capacitado en el uso de la sectores la tecnología es capacitación en nuevas
misma. obsoleta. tecnologías.
Existe nueva tecnología
pero no se utiliza
adecuadamente.
Existe un responsable de Los nuevos sistemas son Existe un registro de la
evaluar los nuevos incompatibles con los infraestructura actual.
requerimientos tecnológicos y anteriores. En cada nuevo proyecto se
la compatibilidad con la La infraestructura debe ser establecen los
infraestructura actual actualizada sobre la requerimientos de
marcha. infraestructura y el grado de
compatibilidad.
En el proyecto se indican
los nuevos requerimientos y
el impacto financiero de los
mismos.
Revisión del Proceso de Adquisición e Implantación
En esta etapa de la revisión es donde propiamente se verifica el proceso de adquisición del
software. Las revisiones realizadas en los puntos anteriores serán el indicativo de la
PAGINA 22
profundidad del análisis de cada etapa. Es decir que si no se observa la utilización de una
metodología y no existen controles propios de un proyecto son muestras que indican que el
proceso de adquisición debe ser analizado con mayor profundidad.
Proceso de Adquisición
Revisión
Revisión del Revisión de la
Proceso
requerimiento especificación
selección
Revisión Revisión de
Revisión de la
Proceso de pruebas
Entrega
customización e instalación
Gráfico 7 – Proceso de Adquisición
Para cada una de las etapas de la ejecución del proyecto aquí propuestas se indicará objetivo
de la etapa, principales actividades involucradas y el producto final de la
etapa. Además se propone una lista con los objetivos de control, los riesgos y las revisiones a
realizar.
Revisión del Requerimiento
Ya sea para la construcción o para la adquisición de un sistema de información es
fundamental la etapa de Relevamiento de las necesidades de los futuros usuarios del sistema a
efectos que el mismo cubra las mismas.
En esta etapa se establece el contacto con las necesidades que posee la organización. En esta
etapa se utilizan diversas herramientas como son: encuestas, entrevistas, obtención de
documentación, mapeo de procesos, etc. .
Producto de esta etapa debe surgir un documento denominado Requerimientos del Sistema
PAGINA 23
donde se determina: Identificación de la situación actual, identificación de los actuales
recursos tecnológicos, necesidades de proceso y de información a ser satisfechas por el
sistema, controles que deben estar presentes en el sistema, grado de flexibilidad y
parametrización exigidos.
Objetivos de Control y Riesgo de la Etapa de Revisión de los

Requerimientos
Cuadro 8 – Objetivos de Control y Riesgos – Etapa Revisión del Requerimiento
Revisión de los requerimientos

Se han establecido en forma El sistema no contempla Existe un documento
clara todos los requerimientos todas las necesidades de adonde se establecen cuales
de todos los usuarios. los sectores usuarios. son los usuarios que
Algunos aspectos representan a cada sector.
funcionales no se Existe un documento donde
encuentran soportados. se establece como se
Las necesidades de realizará el contacto con los
información de los niveles áreas usuarias.
directivos no se Se ha analizado el sistema
encuentran totalmente actual y se han identificado
cubiertas. las fortalezas y debilidades
El sistema no contempla del mismo.
aspectos de control Existe un documento donde
interno. se establecen los
El sistema no contempla requerimientos funcionales
aspectos legales o de control, legales y de
normativos propios de la información.
actividad de la Dicho documento fue
organización. aceptado por las áreas
intervinientes.
Se han identificado El sistema no puede Se han analizado las
adecuadamente las interfaces integrarse con los sistemas interfaces con otros
con otros sistemas de la existentes. sistemas.
organización. Existe un documento donde
se establecen las interfaces
con otros sistemas.
Se ha identificado la No se tiene la Existe un documento donde
capacidad tecnológica actual infraestructura tecnológica se han establecido
de la empresa y las adecuada para razonablemente las
necesidades que plantea el implementar el nuevo necesidades de
nuevo sistema. sistema infraestructura tecnológica
que plantea el nuevo
PAGINA 24
sistema.
Se han identificado posibles Existen soluciones en el Documento donde se
soluciones que establece el mercado que no se han informan posibles
mercado y que podrían llegar tenido en cuenta. alternativas de solución.
a satisfacer los
requerimientos.
Revisión del Diseño del requerimiento
Esta etapa es fundamental porque de la misma debe surgir el documento de requerimientos
que será el documento base para que los proveedores realicen sus ofertas. Por lo tanto en el
mismo deben figurar los aspectos funcionales, de información, de control y legales.
En esta etapa también se establecerá como se realizará el proceso de adquisición, las etapas
contractuales y la lista de proveedores a ser invitados en el proceso de licitación.
Objetivos de Control y Riesgos del Proceso de Revisión del Diseño del

Requerimiento
Cuadro 9 – Objetivos de Control y Riesgos Asociados con Diseño del Requerimiento
Revisión del Diseño del Requerimiento

Se ha realizado un modelo del El modelo de procesos y Existe un modelo de
sistema que incluye el modelo datos no es lo procesos y de datos.
de procesos y de datos. suficientemente claro o no El modelo fue construido
representa fielmente los teniendo en cuenta los
requerimientos. requerimentos de los
En la construcción del usuarios.
modelo de procesos y de
datos no se han tenido en
cuenta los requerimientos
oportunamente relevados.
El modelo fue construido El modelo no respeta Existe un modelo y el
respetando las técnicas de ningún tipo de convención mismo respeta las técnicas
modelado. o técnica. establecidas.
Problemas de
interpretación de las
especificaciones.
En el modelo se han El sistema no contempla Existe un documento donde
PAGINA 25
identificados todas los aspectos de seguridad se establecen los

aspectos de control interno. lógica ni física. requerimentos de control
interno
El grado de flexibilidad o de El sistema no admite Se ha definido el grado de
parametrización del sistema cambios o nuevas flexibilidad del sistema.
permite nuevas operaciones operaciones.
Se han establecido las El modelo no contempla Verificar la existencia de
interfaces con otros sistemas las interfaces con otros interfaces con otros
y son contempladas en el sistemas. sistemas y si las mismas han
modelo del sistema y en la sido contempladas.
estructura de datos
Se ha definido como debe ser El sistema no adquirido no Verificar especificaciones
la administración de la contempla las pautas de seguridad física y lógica.
seguridad física y lógica. mínimas de seguridad.
Se ha indicado el nivel de El sistema no responde Los lotes de prueba han
respuesta requerido por el ante los volúmenes de contemplado los respectivos
sistema en transacciones por transacciones que debe requerimientos de esfuerzo.
minuto o en alguna otra administrar.
métrica que se considere
apropiada.
Revisión del proceso de Selección de la Solución
Una vez determinado los requerimientos técnicos y legales del punto anterior, a los que
denominaremos pliegos, se continua con la etapa de selección de la solución que se ajuste a
los requerimientos.
Esta etapa cubre desde la invitación a cotizar ( o licitación, esto depende de la mecánica
seleccionada) a los proveedores hasta la determinación de la solución seleccionada.
Objetivos de control y riesgos del Proceso de Selección de la Solución
Cuadro 10 – Objetivos de Control y Riesgos Asociados con la Selección de la Solución
Revisión del proceso de selección de la Solución

Se ha realizado una Los proveedores y/o Una vez definidas las
investigación previa de productos que se ofrecen necesidades se confeccionó
productos existentes en el no cumplen con los una lista de proveedores que
mercado y se ha requisitos mínimos podrían cumplir con el
confeccionado una lista de establecidos. requerimiento realizado.
posibles proveedores.
PAGINA 26
La documentación que se La documentación no Existe el o los documentos

entrega al proveedor es la contempla aspectos donde se establecen los
adecuada. importantes del sistema. requerimientos y los
mismos son adecuados para
el fin.
Todos los proveedores El proveedor seleccionado En el análisis de los
seleccionados tienen la tiene problemas proveedores se tuvieron en
capacidad para llevar el financieros y de personal cuenta aspectos relevantes
proyecto adelante. que repercuten en el de los proveedores como
proyecto. antecedentes, cartera de
El proveedor es nuevo en clientes, plataforma
este tipo de productos y instalada, productos, etc.
tiene dificultades para
cumplir con las entregas
pactadas.
Los elementos o pautas de El sistema no tiene una Los criterios de evaluación
selección fueron establecidos adecuada interfaz. fueron previamente
de antemano y aseguran que La perfomance no es la definidos y el documento de
el producto cumpla con los adecuada. evaluación debe asegurar
requerimientos. El plan de capacitación no que se cumplan los
es adecuado. principales aspectos
No se contemplan establecidos en el
aspectos funcionales y de requerimiento.
control que son
importantes para la
organización.
El contrato fue realizado El proveedor no cumple El contrato debe asegurar
teniendo en cuenta las etapas con lo pautado porque el que se cumpla con lo
establecidas y los productos contrato es ambiguo en establecido en los
de cada etapa están algunos aspectos. requerimientos.
claramente especificados
como así también las
responsabilidades de cada
parte.
Revisión de la Etapa de Instalación y Customización

En esta etapa se realiza la instalación y configuración del sistema para que se adapte a las
características de la empresa. Este servicio puede o no estar incluido en el servicio prestado
por el proveedor. En caso que no lo realice el proveedor directamente el mismo al menos
deberá dar el soporte y capacitación para que esta etapa pueda ser llevada adelante por el
personal de la empresa.
Si los parámetros no son adecuadamente definidos pueden surgir problemas durante las
pruebas o lo que es más grave puede ser que surjan cuando el sistema ya este en marcha.
PAGINA 27
Objetivos de control y riesgos de la etapa de Instalación Customización del

Producto
Cuadro 11 – Objetivos de Control y Riesgos Asociados con la Customización
Revisión del Proceso de Instalación y Customización del Producto

La instalación del Hardaware Existen demoras en la Se ha establecido un plan de
necesario se cumplimentó en implementación debido a instalación del hardware
tiempo y forma. que el hardaware no está acorde con los tiempos
disponible en tiempo y establecidos para el
forma establecidos. proyecto.
La instalación de software de Existe demoras en la Se ha establecido un plan de
base se cumplimento en instalación debido a que instalación del software de
tiempo y forma no se ha realizado la base y se han contemplado
instalación del software de los requerimientos
base o el mismo está mal establecidos por el
instalado. proveedor.
Todos los parámetros de Existen parámetros no Los parámetros han sido
funcionamiento se encuentran definidos que provocan el adecuadamente establecidos
adecuadamente definidos. mal funcionamiento del y los usuarios participan en
sistema. su definición.
La definición de los Se ha realizado la
parámetros no es la capacitación suficiente para
adecuada y provoca el la adecuada definición de
malfuncionamiento del los parámetros.
sistema.
Revisión de la Etapa de Prueba y Paralelo
En esta etapa que comienza luego de la capacitación del personal y de realizado el proceso de
capacitación. El objetivo de la misma es probar los aspectos funcionales y de performance del
sistema y realizar el paralelo entre el sistema anterior y el nuevo sistema:
 Etapa de Prueba: Esta etapa es fundamental para la posterior aceptación del
producto y es cuando se verifica que se cumple con lo indicado en la
especificación del requerimiento. Las principales actividades de esta etapa son:
Armado de lotes de prueba, ejecución de las pruebas, verificación del
cumplimiento de los requerimientos, simulación de cierres o procesos críticos del
sistema, pruebas de performance del hardware, pruebas de las interfaces con otros
PAGINA 28
sitemas, pruebas de aspectos de seguridad física y lógica, incorporación o
Migración de datos del sistema anterior
 Etapa de Paralelo: En esta etapa se encuentra en funcionamiento el nuevo sistema
y el sistema o sistemas anteriores (puede ser que el nuevo sistema reemplace a más
de un sistema) por lo que implica duplicación de muchas tareas y una mayor
actividad de control para determinar las diferencias entre uno y otro sistema.
Objetivos de control y riesgos de la etapa de prueba y paralelo
Cuadro 12 – Objetivos de Control y Riesgos Asociados con la Etapa de Prueba y
Paralelo.
Revisión del Proceso de Prueba y Paralelo

Las pruebas contemplan los Las pruebas no cubren los Existe un plan de pruebas y
requerimientos o prestaciones requerimientos indicados esta compatibilizado con los
requeridas. en las especificaciones. requerimientos.
Las pruebas son suficientes y Existen casos no cubiertos Revisión de los lotes de
contemplan casos complejos por las pruebas que luego pruebas y verificación de
provocan errores en el que los usuarios han
sistema. intervenido en la definición
de los mismos.
Las pruebas contemplan los No se han realizado Las pruebas contemplan
especificaciones de pruebas de situaciones situaciones extremas tales
rendimiento establecidas en el extremas. como alto volumen de
requerimiento. transacciones.
En las pruebas se ha revisado No se han realizado Las pruebas deben
el Plan de Seguridad de la pruebas de situaciones contemplar situaciones tales
Empresa. especiales. como cortes de luz,
El sistema es vulnerable a recuperación de backups.
ataques. Las pruebas deben incluir
un test de penetración a los
sistemas a efectos de
verificar la seguridad lógica.
El proceso de conversión de Los datos registrados del Existe un plan conversión
datos de un sistema a otro se sistema anterior no de datos.
ha realizado pueden ser utilizados. Se ha realizado un adecuado
satisfactoriamente. La información estudio de las estructuras de
recuperada del sistema datos del sistema anterior y
anterior no es confiable. del nuevo estableciéndose
Existen errores en la las respectivas
PAGINA 29
conversión de los datos. equivalencias.

Se han probado los
programas conversores.
Se han revisado la
información del sistema
anterior a nivel de totales y
de un muestreo de datos
individuales que asegure la
confiabilidad de los datos.
El paralelo se ha realizado No se ha realizado Existe una planificación del
satisfactoriamente y las paralelo de algunas paralelo con el sistema
diferencias han sido aclaradas operaciones o servicios. anterior y esa planificación
adecuadamente. asegura que todas las
prestaciones sean
verificadas y de esa forma
se asegure el adecuado
funcionamiento posterior.
El paralelo contempla
situaciones o procesos
especiales como los cierres
de mes o de ejercicio.
No se han detectado La diferencias son
algunas diferencias. detectadas en su totalidad.
No se determina si las Las diferencias deben ser
diferencias son por identificadas y su causa
problemas con el sistema esclarecida.
anterior y propias del Las diferencias u errores
nuevo sistema. deben ser corregidos y
No se realizan las asegurarse su correcto
correcciones de las funcionamiento.
diferencias detectadas
El paralelo se prolonga El paralelo se realiza dentro
por demasiado tiempo. de los plazos establecidos
No existe una fecha de fin en la planificación.
del paralelo. Al momento de abandonar
Existe resistencia a el paralelo existe expresa
abandonar el paralelo. conformidad de los usuarios
El paralelo es abandonado y todas las diferencias han
aún existiendo diferencias sido aclaradas y corregidas.
no identificadas.
Revisión del Proceso de Entrega y Aceptación del Sistema
Una vez realizada la etapa de prueba y paralelo y de pasado un tiempo prudencial se procede a
la aceptación del producto y a la culminación de la etapa de puesta en marcha del sistema. A
PAGINA 30
esta altura del proyecto se considera que el sistema se ha estabilizado y se encuentra en
régimen normal.
Objetivos de Control y Riesgos de la Etapa de Entrega y Aceptación del

Sistema
Cuadro 13 – Objetivos de Control y Riesgos Asociados con el Impacto en el Negocio
Revisión de la Entrega y Aceptación del Sistema.

Las pruebas y paralelo del El sistema es entregado Se ha realizado la
sistema han culminado sin haberse culminado con finalización de las etapas de
satisfactoriamente. la etapa de prueba y pruebas y paralelo con la
paralelo. aceptación de los usuarios.
Se han cerrado todos los El sistema se han Se ha realizado la
incidentes originados en entregado con errores o conclusión de todos los
errores de programa o por diferencias pendientes de incidentes por errores o
diferencias detectadas en el resolución. diferencias.
paralelo
No existen modificaciones o El sistema es entregado Se ha verificado que no
adaptaciones pendientes a la aún faltando la existen modificaciones
fecha de entrega. incorporación de algunas pendientes.
mejoras
Existe un documento de El sistema no es Se debe verificar la
aceptación final. formalmente aceptado. existencia de un documento
donde los usuarios dan la
conformidad final del
producto. Si el sistema se
aceptara con problemas
pendientes de resolución
estos deben estar indicados
como así también el plazo
de resolución de los
mismos.
Revisión de la Etapa de Mantenimiento
El mantenimiento es el servicio adicional que presta el proveedor una vez que el sistema se
encuentra en régimen. Es fundamental que en el contrato se haya especificado
adecuadamente que se entiende por mantenimiento y soporte del sistema cuando este es
PAGINA 31
incluido en el precio del servicio.
Objetivos de Control y Riesgos de la Etapa de Mantenimiento
Cuadro 14 – Objetivos de Control y Riesgos Asociados con la Etapa de Mantenimiento
Revisión de la etapa de Mantenimiento.

El soporte brindado por el Cuando se presentan El proveedor tiene previsto
proveedor es el adecuado. dudas sobre el sistema no un adecuado servicio de
hay a quien recurrir. soporte al usuario y resuelve
los incidentes en un tiempo
prudencia.
El proveedor cumple en Existen errores que nunca El proveedor brinda un
tiempo y forma con la son subsanados. servicio permanente de
corrección de errores. actualización y corrección
de errores.
El sistema es actualizado El proveedor no realiza Verificar que los cambios
periódicamente o ante nuevos actualizaciones periódicas normativos e impositivos
requerimientos legales o del sistema con lo cual el son actualizados en el
impositivos. mismo queda sistema por el proveedor.
desactualizado ante
cambios normativos e
impositivos.
El proveedor no presta
más el servicio.
Las nuevas versiones son Existe problemas en las Las conversiones de
actualizadas sin problemas y conversiones de datos. versiones son realizadas por
los usuarios son capacitados No hay documentación personal especializado y
adecuadamente. sobre las mejoras. previamente realizadas en
Los usuarios no un ambiente de prueba.
aprovechan El proveedor incluye la
adecuadamente las nuevas actualización de los
prestaciones. respectivos manuales de
usuarios.
Se debe verificar si los
cambios en la nueva versión
afectan los procesos y
controles actuales.
Se debe verificar que el
proveedor cuente con un
programa de capacitación y
actualización.
Conclusión
En el presente trabajo intenta alertar sobre las distintas implicancias que tiene la incorporación
PAGINA 32
de tecnología informática en el ámbito de una organización y por lo tanto que aspectos
mínimos se deberían tener presente al evaluar un proceso de adquisición de software.
En ese sentido se remarca la necesidad no solo de evaluar a la adquisición como un proceso
puntual, sino que se debería tomar en un sentido más amplio. Es así que se incorpora la
evaluación de lo que se denominó el Ambiente del Proyecto y también el impacto que dicho
proyecto tiene en la organización en lo que hace al Negocio en sí mismo y también en lo
relativo a aspectos Funcionales y aspectos Tecnológicos.
De esta forma el auditor tendrá una visión mas amplia de los riesgos asociados y podrá
formular un plan de trabajo que agregue valor al proceso de adquisición del software y que le
permitan a la organización alcanzar satisfactoriamente el objetivo propuesto al realizar este
tipo de inversiones.
Bibliografía Consultada
 IFAC - International Standard on Auditing 401 – Auditing in a computer information
systems environment. Año 2004.
 ISACA - Cobit 3ra. Edición – Objetivos de Control para la Información y Tecnologías
Relacionadas – Año 2003.
 Federación Argentina de Consejos Profesionales de Ciencias Económicas – CECYT -
Informe 6 - Pautas para el Examen de Estados Contables en un Contexto
Computadorizado.
 Laudon y Laudon – Sistemas de Información Gerencial – Capitulo 11 – Rediseño de la
Organización mediante Sistemas de Información – Sexta Edición Año 2002 - Página 341
 Matías Fernández Díaz – Adquisición de Recursos de Tecnología Informática – Revista
Sindicatura – Abril 1998 – Página 97.
PAGINA 33

Pcia. Bs - As. - Elissondo - R32301el

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Pcia. Bs - As. - Elissondo - R32301el

Cargado por

Copyright:

Formatos disponibles

TITULO DEL TRABAJO: AUDITORIA DE LA

AREA: III Contabilidad y Auditoría .

TEMA: 2 Auditoría - La auditoría de Sistemas Electrónicos de Información.

CONGRESO: 15 Congreso Nacional de Profesionales en Ciencias Económicas – Salta 20,21

Ciencias Económicas de la Universidad Nacional del Centro de la Provincia de Buenos Aires-

Profesional de Cs. Económicas de la Provincia de Buenos Aires.

DATOS DOMICILIO: FERNÁNDEZ DE LA CRUZ 975 – 7000 TANDIL – PCIA BUENOS

AIRES – TEL. 02293-15640151

AREA: III Contabilidad y Auditoría .

TEMA: 2 Auditoría - La auditoría de Sistemas Electrónicos de Información.

CONGRESO: 15 Congreso Nacional de Profesionales en Ciencias Económicas – Salta 20,21

Los procesos organizacionales han pasado a estar soportados en su mayoría en sistemas de

información que normalmente son adquiridos a empresas especializadas en la temática.

un proceso de adquisición de software, donde se analizan diversos aspectos relacionados con

la revisión de dicho proceso.

y a Aspectos Funcionales y Tecnológicos.

Índice del Trabajo

ROL ESPERADO DEL AUDITOR 4

ENFOQUES PARA ENCARAR LA AUDITORÍA DEL PROCESO DE ADQUISICIÓN

ETAPAS DE LA REVISIÓN DEL PROCESO DE ADQUISICIÓN DEL SOFTWARE 6

REVISIÓN DEL PROYECTO 6

AMBIENTE DEL PROYECTO 7

OBJETIVOS DE CONTROL Y RIESGOS DEL AMBIENTE 9

IMPACTO DEL PROYECTO 12

OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS CON EL IMPACTO EN EL NEGOCIO 16

OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS CON EL IMPACTO FUNCIONAL 18

OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS AL IMPACTO TECNOLÓGICO 22

REVISIÓN DEL PROCESO DE ADQUISICIÓN E IMPLANTACIÓN 22

REVISIÓN DEL REQUERIMIENTO 23

OBJETIVOS DE CONTROL Y RIESGO DE LA ETAPA DE REVISIÓN DE LOS REQUERIMIENTOS

REVISIÓN DEL DISEÑO DEL REQUERIMIENTO 25

OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE REVISIÓN DEL DISEÑO DEL

REVISIÓN DEL PROCESO DE SELECCIÓN DE LA SOLUCIÓN 26

OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE SELECCIÓN DE LA SOLUCIÓN 26

REVISIÓN DE LA ETAPA DE INSTALACIÓN Y CUSTOMIZACIÓN 27

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE INSTALACIÓN CUSTOMIZACIÓN DEL

REVISIÓN DE LA ETAPA DE PRUEBA Y PARALELO 28

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE PRUEBA Y PARALELO 29

REVISIÓN DEL PROCESO DE ENTREGA Y ACEPTACIÓN DEL SISTEMA 30

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE ENTREGA Y ACEPTACIÓN DEL

REVISIÓN DE LA ETAPA DE MANTENIMIENTO 31

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE MANTENIMIENTO 32

software con el cual se soportaran sus procesos de negocios. El software se ha vuelto un

inviable su negocio sin este recurso.

imprime a los negocios.

aplicaciones y el resto de las funciones asociadas al mismo.

ya existen en e mercado y dedicando su equipo de sistemas a la producción del software que

auditoria del proceso de adquisición del software:

 El gasto destinado a software es un componente cada vez más importante de la inversión

en Tecnología Informática que realizan las empresas.

 El software es un producto muy difícil de evaluar. Un mayor control el proceso de

selección y adquisición aumenta la posibilidad de éxito final del proyecto.

 El índice de fracasos en proyectos de desarrollo es alta, lo cual nota la inexistencia o mal

Office Report (EEUU) muestran este hecho:

 Un 1,5 % se usó tal y como se entregó

Rol esperado del auditor

que realiza la organización.

 Participar en el proceso de selección realizando las tareas mencionadas en el punto anterior

deseables, calidad del armado de lotes de prueba, sugiriendo posibles adaptaciones en

respecto de un producto determinado. Este enfoque podría implicar que el auditor se

involucre, pero en cierta forma esta intervención en el proceso de adquisición se puede

internos de la organización que estarán soportados en el sistema que se adquiera y por lo

Enfoques para encarar la auditoría del proceso de