Auditoria de La Adquisición de Software

AUDITORIA
DE
LA
ADQUISICIN
DE
SOFTWARE
AREA: III Contabilidad y Auditora .
TEMA: 2 Auditora - La auditora de Sistemas Electrnicos de Informacin.
CONGRESO: 15 Congreso Nacional de Profesionales en Ciencias Econmicas Salta 20,21

y 22 de Octubre de 2004.
RESUMEN DEL TRABAJO
Los procesos organizacionales han pasado a estar soportados en su mayora en sistemas de

informacin que normalmente son adquiridos a empresas especializadas en la temtica.
El presente trabajo busca brindar una herramienta para aquellos auditores que deben evaluar
un proceso de adquisicin de software, donde se analizan diversos aspectos relacionados con
la revisin de dicho proceso.
Para esto se propone una visin amplia de esta tarea de revisin a partir de la incorporacin de
la evaluacin del Ambiente del Proyecto y del Impacto del mismo en lo que hace al Negocio
y a Aspectos Funcionales y Tecnolgicos.
Tambin 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 ADQUISICIN DE SOFTWARE
ndice del Trabajo

INTRODUCCIN
ROL ESPERADO DEL AUDITOR
ENFOQUES PARA ENCARAR LA AUDITORA DEL PROCESO DE ADQUISICIN 5
ETAPAS DE LA REVISIN DEL PROCESO DE ADQUISICIN DEL SOFTWARE 6
REVISIN DEL PROYECTO
AMBIENTE DEL PROYECTO
OBJETIVOS DE CONTROL Y RIESGOS DEL AMBIENTE
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 TECNOLGICO
19
OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS AL IMPACTO TECNOLGICO
22
REVISIN DEL PROCESO DE ADQUISICIN E IMPLANTACIN
22
REVISIN DEL REQUERIMIENTO
23
OBJETIVOS DE CONTROL Y RIESGO DE LA ETAPA DE REVISIN DE LOS REQUERIMIENTOS

24
PAGINA 1
REVISIN DEL DISEO DEL REQUERIMIENTO
25
OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE REVISIN DEL DISEO DEL

REQUERIMIENTO
25
REVISIN DEL PROCESO DE SELECCIN DE LA SOLUCIN
26
OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE SELECCIN DE LA SOLUCIN
26
REVISIN DE LA ETAPA DE INSTALACIN Y CUSTOMIZACIN
27
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE INSTALACIN CUSTOMIZACIN DEL

PRODUCTO
28
REVISIN DE LA ETAPA DE PRUEBA Y PARALELO
28
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE PRUEBA Y PARALELO
29
REVISIN DEL PROCESO DE ENTREGA Y ACEPTACIN DEL SISTEMA
30
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE ENTREGA Y ACEPTACIN DEL

SISTEMA
31
REVISIN DE LA ETAPA DE MANTENIMIENTO
31
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE MANTENIMIENTO
32
CONCLUSIN
33
BIBLIOGRAFA CONSULTADA
33
PAGINA 2
Introduccin
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 estratgico indispensable para las organizaciones, muchas de las cuales veran
inviable su negocio sin este recurso.
Esta suerte de vinculo entre sistemas y negocios tambin a provocado que los tiempos de
respuesta que se le exigen a la gente de sistemas para la produccin y/o adaptacin de los
sistemas sean cada vez menores debido fundamentalmente a la dinmica que el mercado le
imprime a los negocios.
A esto se debe sumar que muchas empresas a tomado la decisin 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 decisin de las empresas para optar por la adquisicin 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 produccin del software que
el mercado no provee.
Si bien lo expresado en los prrafos anteriores de por s justifica la intervencin del Auditor
en la seleccin del software, se pueden enumerar otros motivos por los que se justifica la
auditoria del proceso de adquisicin del software:
PAGINA 3
El gasto destinado a software es un componente cada vez ms importante de la inversin

en Tecnologa Informtica que realizan las empresas.
El software es un producto muy difcil de evaluar. Un mayor control el proceso de
seleccin y adquisicin 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 despus 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 participacin 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 desvos o problemas
que encuentren. Este enfoque se asimilara a cualquier otra revisin de las adquisiciones
que realiza la organizacin.
Participar en el proceso de seleccin realizando las tareas mencionadas en el punto anterior
pero adems emitiendo opinin 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 tambin asesorar en el proceso de seleccin 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 opinin o recomendacin
PAGINA 4
respecto de un producto determinado. Este enfoque podra implicar que el auditor se

involucre, pero en cierta forma esta intervencin en el proceso de adquisicin se puede
justificar en el hecho de que el auditor luego deber realizar la revisin de los controles
internos de la organizacin que estarn soportados en el sistema que se adquiera y por lo
tanto es preferible que acte de manera proactiva, es decir antes de encontrarse con un
hecho ya consumado.
Enfoques para encarar la auditora del proceso de

adquisicin
Ms all del rol que le toque jugar al auditor, la propuesta de revisin 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 adquisicin: Es decir determinar si la adquisicin del software fue
realizada de acuerdo a prcticas 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 revisin incluye aspectos relacionados con
el gerenciamiento y calidad del proyecto. El proceso de adquisicin se considera una etapa
dentro de la evaluacin del proyecto.
-Evaluar el impacto del software adquirido en relacin al negocio: En este caso, adems
de los aspectos enunciados anteriormente se incluye el anlisis del ambiente del proyecto es
decir que se evalan otros aspectos tales como la existencia de un plan de sistemas, nivel de
integracin de dicho plan con el plan estratgico de negocios, organizacin 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 problemtica propuesta, en el entendimiento de que luego cada profesional podr limitar

la aplicacin de esta propuesta de acuerdo a la realidad que lo rodea y de los recursos de los
que dispone.
Etapas de la revisin del proceso de adquisicin del

Software
Tomando la propuesta ms amplia, se proponen las siguientes etapas de revisin:
Etapas de Revisin
Revisin del Proyecto

Proceso de Adquisicin
Seguimiento
Grfico 1 Etapas de la Revisin
Revisin del Proyecto: La existencia de un proyecto adecuadamente administrado y

en el cual se trabaja con una metodologa preestablecida permite presumir que el
proceso de adquisicin de software se realiza en un ambiente planificacin y mayor
control.
Proceso de Adquisicin: Es la adquisicin en si misma que abarcar desde el proceso

de establecimiento de requerimientos hasta la adquisicin.
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.
Revisin 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 revisin 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 aproximacin a cerca de la calidad del
proyecto. Dentro de estos encontramos la posibilidad de verificar la existencia de un
plan estratgico de sistemas, la forma en que el proyecto es administrado, la
metodologa utilizada y el nivel tecnolgico de la organizacin.
Impacto del Proyecto: El objetivo de medir el impacto del
proyecto es para
determinar los riesgos a los que se encuentra sometida la organizacin al incorporar el

software en cuestin. Es as que se debe revisar lo relacionado con el impacto sobre el
esquema de negocios, el impacto que implicara un cambio tecnolgico y el impacto
que un nuevo sistema tendra sobre aspectos funcionales, es decir sobre los procesos
que se realizan en la organizacin.
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 revisin mas intensiva de algunos puntos.
Digamos entonces que en esta etapa de la revisin 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
Informacin sobre el ambiente
Plan Estrategico
De Sistemas
Administracin
del
Proyecto
Ambiente del Proyecto

Metodologa
Tecnologa
Grfico 2 Aspectos del Ambiente
Plan estratgico de Sistemas: La existencia de una planificacin del recurso informtico y el

grado de integracin del mismo con el Plan Estratgico de Negocio nos permite establecer el
grado de importancia que la organizacin le da a sus sistemas y adems que las acciones son
realizadas de acuerdo a una planificacin previa evitando de esta forma que el accionar solo
obedezca a impulsos que nada tienen que ver con criterios bsicos de administracin.
Administracin del proyecto: Deben existir adecuadas pautas para el manejo de proyectos
como son: la determinacin de un lder de proyecto, la asignacin calidad de los recursos
humanos involucrados, la existencia de herramientas para el seguimiento de los proyectos y la
existencia de informes peridicos de avance del mismo.
Metodologa: La existencia de una metodologa 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.
Tecnologa: El nivel tecnolgico alcanzado por los aplicativos que integran la cartera de
aplicaciones es un elemento de vital importancia para determinar si la nueva aplicacin a ser
incorporada representa un salto cualitativo que la organizacin puede asimilar sin mayores
PAGINA 8
dificultades. En este sentido es fundamental verificar la existencia de una planificacin de la

incorporacin de los recursos tecnolgicos, esto permite inferir que cada salto tecnolgico
es medido adecuadamente a efectos de determinar su impacto en la organizacin.
En el prximo punto se establecen los objetivos de control, riesgos asociados y revisiones

mnimas a realizar para verificar el ambiente del proyecto. Es importante aclarar que se habla
de revisiones mnimas 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) especficamente
orientado al anlisis de cada uno de ellos.
Mas bien se intenta que el auditor pueda delimitar ms claramente las responsabilidades al
momento de emitir su opinin. Esto quiere decir que si desde el nivel directivo no existe una
preocupacin e involucramiento en tipo de proyectos nunca existi una directiva al respecto
son tambin responsables por los resultados que se obtengan.
Objetivos de Control y Riesgos del Ambiente

Cuadro 1 - Objetivos de control Relacionados con Plan Estratgico de Sistemas
Plan Estratgico 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 mximo de la
crecimiento del negocio y se organizacin.
organizacin.
encuentra
adecuadamente Inflexibilidad
de
los Verificacin
de
la
aprobado por la direccin y es sistemas ante nuevos actualizacin peridica del
peridicamente revisado ante requerimientos
plan.
cambios en la planificacin organizacionales.
Revisin
de
la
de la organizacin.
Desvinculacin entre los documentacin
del
distintos sistemas.
directorio
(actas
de
Comportamiento
reuniones, instrucciones de
desordenado y errtico en la direccin, existencia de
el desarrollo y adquisicin un responsable de la
PAGINA 9
de aplicaciones.
Desconocimiento de la
existencia o alcance del
plan por parte de las
distintas
reas
organizacionales.
La asignacin de recursos
no es la adecuada dado la
dimensin del proyecto.
formulacin, etc.
Los
cambios
de
los
proyectos impactan en el
plan de sistemas.
Cuadro 2 -Objetivos de Control y Riesgos Asociados con la Administracin del Proyecto

Administracin del Proyecto
Objetivo de Control
Riesgos Asociados
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 integracin entre los proyecto
plan de sistemas de la distintos proyectos.
Existencia de un plan del
organizacin.
Descoordinacin 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
adecuadamente dimensionado para llevar adelante el
y su impacto adecuadamente proyecto.
valorado. (para mayor detalle
ver en este trabajo punto
Impacto del Proyecto)
Verificar
la
adecuada El sistema no responde a
participacin de los usuarios las necesidades de los
en el proyecto.
usuarios.
Los usuarios no participan
en las distintas etapas del
proyecto.
Existencia
de
una
evaluacin del proyecto en
cuento a su impacto en el
negocio,
en
aspectos
funcionales y tecnolgico.
Se
ha
realizado
el
presupuesto financiero del
proyecto y se ha realizado la
comparacin del proyecto
contra otros proyectos de
inversin.
Se
contempla
la
participacin de usuarios a
travs de comits u otras
formas de organizacin.
Existe un registro con las
inquietudes de los usuarios.
PAGINA 10
Debe existir un responsable o

director del proyecto que
establezca el adecuado uso de
los recursos y resuelva los
problemas que puedan surgir.
El
proyecto
no es
adecuadamente dirigido y
las tareas no son llevadas
adelante en tiempo y
forma.
No se miden los desvos y
se toman las acciones
correctivas respectivas.
Superposicin
de
funciones y problemas de
coordinacin.
Los tiempos, grado de

avance y recursos asignados
a
los
proyectos
son
peridicamente
revisados
por el responsable del
proyecto.
Existe un mecanismo de
resolucin problemas.
Existencia de un documento
donde
se
establezcan
responsabilidades y tareas.
Existen
etapas
del
proyecto que no se pueden
cumplir por falta de
recursos o los recursos no
son los adecuados.
Inadecuada
administracin
de
prioridades y asignacin
de recursos.
Las etapas previstas deben ser Existen desviaciones que
cumplimentadas en tiempo y no son adecuadamente
forma
finalizadas en tiempo y
forma.
No se corrige los errores o
desviaciones
Existe un cierre del proyecto El proyecto no queda
formalmente terminado.
No
se
realiza
un
evaluacin final.
Verificar que la existencia o

disponibilidad de recursos
humanos y materiales al
proyecto son los adecuados.
Los recursos asignados para

cada etapa del proyecto son
los adecuados de acuerdo a
las prioridades fijadas.
Verificacin de los controles

establecidos
por
el
responsable del proyecto y
de las acciones correctivas
correspondientes.
Existe un documento donde
se informa los resultados del
proyecto y donde se indica
la liberacin de los recursos
afectados.
Cuadro 3 - Objetivos de Control y Riesgos Asociados con la Metodologa

Metodologa
Objetivo de Control
Riesgos Asociados
Existe una metodologa y la No
se
aplica
una Existe documentada una
misma
se
encuentra metodologa
para
el metodologa de trabajo.
adecuadamente formalizada. desarrollo del proyecto
La metodologa abarca todo
el proceso del ciclo de vida de
los sistemas y contempla los
pasos para la adquisicin de
aplicaciones.
La metodologa no abarca
todas la etapas del
desarrollo de sistemas.
No
existe
una
metodologa
para
la
adquisicin
de
aplicaciones
La metodologa es conocida y Cada proyecto aplica su
Amplitud y alcance de la
metodologa utilizada.
Existencia
de
una
metodologa
para
la
adquisicin de software.
Verificar
que
etapas
PAGINA 11
aplicada por todos los

integrantes de los distintos
proyectos
La
metodologa
es
adecuadamente actualizada.
propio criterio para el metodolgicas iguales son

desarrollo de las tareas.
aplicadas de la misma forma
en los distintos proyectos.
La metodologa utilizada Existe un proceso de
no es aplicada porque a revisin y actualizacin
quedado
desactualizada peridica de la metodologa
para
resolver
los empleada.
problemas actuales.
Cuadro 4 - Objetivos de Control y Riesgos Asociados con la Tecnologa

Tecnologa
Objetivo de Control
Riesgos Asociados
Se realiza una planificacin En la organizacin hay
de los aspectos tecnolgicos y diversas tecnologas en
es peridicamente revisada
uso que son incompatibles
entre s.
La
tecnologa
est
desactualizada.
No existen planes de
actualizacin
de
la
tecnologa.
Existe una definicin
estndares tecnolgicos.
de La
adquisicin
de
tecnologa se realiza sin
tener en cuenta ningn
estndar lo que provoca
incompatibilidades.
Los nuevos proyectos se Los nuevos proyectos
ajustan a los estndares establecen sus propios
establecidos.
estndares
Existencia de un plan de
desarrollo tecnolgico y de
compatibilidad
entre
distintos estndares.
Los estndares tecnolgicos

estn
adecuadamente
definidos y formalizados.
Los responsables de los
nuevos proyectos toman
como base los estndares
establecidos.
Existe una planificacin para No existe pautas para la Existencia de un plan de

la
adquisicin
e incorporacin de nueva adquisicin
de
nueva
implementacin de nuevas metodologa
tecnologas.
tecnologas.
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 organizacin al incorporar el software en cuestin.
PAGINA 12
Analisis del Impacto del

Proyecto
Negocio
Tecnolgico
Tamao del Proyecto

Funcional
Grfico 3 Impacto del Proyecto
El principal riesgo est dado el tamao del proyecto. Existen diversos factores que nos
permiten establecer el tamao 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 ms de

un nivel de la organizacin 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 inversin.
El tamao del proyecto no es el nico elemento que es generador de riesgo, pudindose

determinar otros aspectos tales como el impacto del proyecto en el negocio, el impacto
funcional y el impacto tecnolgico, elementos que combinados con el tamao pueden
considerarse como elementos potenciadores del riesgo.
Impacto en el negocio
De acuerdo al tipo de aplicacin que se adquiere esta puede ser ms o menos vital para el
PAGINA 13
desenvolvimiento del negocio. Es decir que si estamos evaluado la adquisicin de un software

que permitir la autogestin de los clientes a travs de internet no hay duda que el impacto es
muy importante. Lo mismo cuando el software en cuestin soporta tareas que son el core
competence de la organizacin, es decir que el sistema a adquirir respeta o potencia los
procesos que hoy le permiten a la organizacin diferenciarse del resto.
Esto tiene sin duda impacto cuando se audita la fase de Anlisis de Necesidades y de
establecimiento de requerimientos ya que sin duda estos procesos debern estar
adecuadamente explicitados en los requerimientos para que el software que se adquiera los
respete, caso contrario debern figurar en los requerimientos de customizacin del mismo.
Grande
Reducido
Tamao del Proyecto
Impacto en el Negocio
Riesgo Medio
Riesgo Alto
Problemas de
adminisracin
Peligra la
supervivencia
Riesgo Bajo
Riesgo Medio
Mala utilizacin
de recursos
Demora en la
implementacin
de negocios
Bajo
Alto
Impacto en el proceso de Negocio
Grfico 4 Impacto en el Negocio
En el grfico 4 se entrecruza la variable tamao del proyecto con impacto en el proceso de

negocios. Pudindose 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 tamao.
El riesgo esta dado bsicamente porque existe la posibilidad de que el proyecto tenga
PAGINA 14
inconvenientes si no existe una administracin y recursos adecuados al tamao y adems

porque se trata de un proyecto fundamental para el desarrollo del negocio. En este caso el
riesgo emergente es el peligro de desaparicin de la organizacin 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 implementacin.
Alto impacto en el negocio y Proyecto reducido Riesgo Medio: La variante respecto del
caso anterior es que el grado de complejidad o tamao del proyecto en este caso es reducida lo
cual permitira por un lado contar con mayores posibilidades de xito en la administracin del
proyecto y en caso de existir inconvenientes es ms fcil atacarlos. De todas formas an
existiendo posibilidades de recuperar la situacin el riesgo sigue importante ya que es la
funcin 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 an tratndose de una situacin 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 utilizacin 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
Objetivo de Control
El proyecto se encuentra
dentro del marco del plan de
negocios de la empresa.
Las
especificaciones
establecidas contemplan los
factores
esenciales
del
negocio.
Impacto en el Negocio
Riesgos Asociados
Los
sistemas
no
responden
a
las
necesidades del negocio.
La habilidades propias del
negocio no se encuentran
apoyadas por los nuevos
sistemas.
El sistema tiene la capacidad El sistema se muestra

de adaptarse a nuevas reglas inflexible ante nuevos
del negocio.
cambios.
Se ha medido adecuadamente El
negocio
se
ve
el impacto del proyecto en el seriamente
cuestionado
negocio
ante el fracaso del
proyecto de sistemas.
El plan estratgico de
sistemas es coordinado con
el plan de negocios.
En la documentacin de los
requerimientos
se
identifican las habilidades
principales que distinguen a
la empresa.
Se ha previsto que el o los
sistemas
sean
parametrizables y flexibles
para adaptarse a los
cambios.
Se ha previsto el alcance e
impacto del proyecto como
as
tambin
las
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 organizacin sin mayores problemas.
La medicin del impacto funcional esta dada fundamentalmente por:
Cantidad de Sectores Involucrados: A mayor cantidad de sector ms difcil su posterior

implementacin.
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 variacin que sufren que puede ir de un cambio menor hasta la desaparicin 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 organizacin debe
analizarse el grado de compatibilidad y la existencia de adecuadas interfaces. El otro

caso es que el nuevo sistema reemplaza a ms de un sistema anterior (como es el caso
cuando se instalan sistemas integrados que reemplazan a ms de una aplicacin) por lo
que se debern administrar mltiples paralelos con los sistemas anteriores.
Amplio
Reducido
Tamao del Proyecto
Impacto Funcional
Riesgo
Moderado
Problemas de
Administracin
Riesgo Bajo
Riesgo Alto
Viabilidad del
Proyecto
Riesgo
Moderado
Adaptacin
operativa
Bajo
Alto
Impacto funcional
Grfico 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 implementacin 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 adems de la propia complejidad de tener que actuar con mltiples
usuarios que tienen mltiples intereses que debern tenerse en cuenta, se encuentra la
complejidad de implementar un sistema en ms de un sector. Para este punto es importante
establecer si el proyecto puede ser implementado por mdulos 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 problemtica se
ve acotada a un sector.
A efectos de establecer el riesgo en este caso lo importante es establecer cun critico es el

sector que se encuentra involucrado en el proyecto. Si se trata de un sector crtico como
podra ser la automatizacin 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 automviles y por ende incumplir con las entregas pactadas a los clientes.
En este caso el riesgo est dado fundamentalmente por el grado de adaptacin operativa del
sector en cuestin.
Bajo Impacto Funcional y Proyecto Amplio Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organizacin pero que no comprende a un gran nmero
de procesos.
En este caso el riesgo esta dado fundamentalmente por los inconvenientes que puedan surgir
de la administracin de un proyecto que abarca ms de un sector.
Bajo Impacto Funcional y Proyecto Reducido Riesgo Bajo: En este caso se trata de
proyecto de menor tamao 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
Objetivo de Control
Todos
los
sectores
involucrados conocen el
proyecto y como este los
afecta
Los sectores participan del
proyecto.
Todos los procesos afectados

han sido considerados y se
han identificado los procesos
que cambian, los que
desaparecen y los nuevos
procesos
Se han respetado las pautas

de control interno.
Las relaciones entre sectores

y aplicaciones se han
establecido correctamente
Impacto Funcional
Riesgos Asociados
Los sectores no conocen Existencia
de
como el proyecto o nuevo comunicaciones
internas
sistema los afectar
que establezcan el alcance y
profundidad del proyecto
Los sectores se ven Existencia de un foro de
imposibilitados
de discusin o comit de
establecer
los usuarios.
requerimientos
de Existencia de un registro de
informacin.
requerimientos.
Existen procesos que no Existe un equipo de trabajo
son soportados por el que se encarga de la
sistema.
interface entre el proyecto
Se siguen realizando de sistemas y los nuevos
procesos que no tienen procesos.
sentido en un nuevo Existe
documentacin
esquema de trabajo.
donde se formalizan los
Se desconocen los nuevos nuevos procesos.
procesos.
Los cambios de procesos Se ha realizado la revisin
que
surgen
de
la de los puntos de control
implementacin del nuevo interno.
sistema han afectado el Los nuevos puntos de
control interno.
control
interno
se
encuentran adecuadamente
formalizados.
Existe
descoordinacin Se
han
formalizado
entre reas y sistemas.
adecuadamente
las
interfaces entre sectores y
aplicaciones.
Impacto tecnolgico
Si el proyecto representa un paso importante en cuanto al tipo de tecnologa implica un riesgo
ya que son mltiples los factores que intervienen en una mejora tecnolgica y por lo tanto
surgen nuevos riesgos a los que la organizacin est expuesta.
La medicin o graduacin del impacto tecnolgico 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 administracin de los recursos y de aspectos de seguridad son muy
importantes.
Ambiente de Desarrollo: La incorporacin de bases de datos relacionales o de ambientes

de trabajo orientados a objetos con entornos visuales, implica nuevas formas de tratar la
informacin en cuanto a controles que se realizan en la captura y en almacenamiento de
los datos. Si tomamos por ejemplo la incorporacin de bases de datos las mismas por un
lado facilitan el desarrollo y modificacin de los sistemas pero a su vez tienen su propio
esquema de seguridad de acceso a los datos y permiten el acceso y modificacin de los
mismos sin necesidad de contar con una aplicacin para hacerlo.
Conocimiento de la Tecnologa: Cuando el cambio tecnolgico es muy importante es

probable que las personas que hoy se encuentran en la organizacin no tengan el
conocimiento suficiente para administrar la misma. Si este es el caso en el proyecto deber
estar considerado el plan de capacitacin adecuado para el personal involucrado en
aspectos tecnolgicos.
Equipamiento y Licencias: Normalmente los cambios en la tecnologa del software

vienen acompaados 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 anlisis de la infraestructura existente y el proceso de
adquisicin 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
Amplio
Reducido
Tamao del Proyecto
Impacto Tecnolgico
Riesgo
Moderado
Problemas de
administracin
Riesgo Bajo
Riesgo Alto
Posible fracaso
del proyecto
Riesgo
Moderado
Posibles
demoras
Bajo
Alto
Impacto tecnolgico
Grfico 6 Impacto Tecnolgico
Alto impacto Tecnolgico y Proyecto Amplio Alto Riesgo: En este caso el problema esta
en la diseminacin de la tecnologa en muchas reas de la organizacin. Si el nivel de retraso
en equipamiento y plataforma de software es importante en muchas reas de la organizacin,
el trabajo de actualizacin ser mayor. La tecnologa tambin impacta en la adaptacin de los
recursos a un nuevo entorno visual con lo cual la introduccin del nuevo sistema tambin
deber afrontar esta dificultad.
Alto impacto Tecnolgico y Proyecto reducido Riesgo Moderado: La variante respecto

del caso anterior es que tiene un alto impacto en los aspectos tecnolgico
pero la
problemtica se ve acotada a un sector o proceso especifico. A efectos de establecer el riesgo

en este caso tambin lo importante es establecer cun critico es el sector o proceso al que se
encuentra involucrado en el proyecto.
Bajo Impacto Tecnolgico y Proyecto Amplio Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organizacin pero no existen cambios tecnolgicos
sustantivos.
PAGINA 21
Bajo Impacto Tecnolgico y Proyecto Reducido Riesgo Bajo: En este caso se trata de
proyecto de que no implica un cambio tecnolgico sustancial y que no impacta sobre gran
parte de la organizacin. Este seria el caso de una actualizacin a una nueva versin del
aplicativo que ya esta en uso y en la cual los cambios no son sustantivos.
Objetivos de Control y Riesgos asociados al Impacto Tecnolgico

Cuadro 7 Objetivos de Control y Riesgos Asociados con el Impacto Tecnolgico
Impacto Tecnolgico
Objetivo de Control
Riesgos Asociados
Existe
un
plan
de La
infraesctructura Existencia de un plan a
infraestructura tecnolgica.
tecnolgica
crece
en mediano y largo plazo
forma errtica
acerca de la infraestructura
tecnolgica
de
la
organizacin.
La infraestructura tecnolgica Existen dificultades para Existencia de un proceso de
se encuentra adecuadamente correr nuevas aplicaciones actualizacin tecnolgica.
actualizada y el personal debido a que en algunos Existen
actividades
de
capacitado en el uso de la sectores la tecnologa es capacitacin en nuevas
misma.
obsoleta.
tecnologas.
Existe nueva tecnologa
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 tecnolgicos 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.
Revisin del Proceso de Adquisicin e Implantacin

En esta etapa de la revisin es donde propiamente se verifica el proceso de adquisicin del
software. Las revisiones realizadas en los puntos anteriores sern el indicativo de la
PAGINA 22
profundidad del anlisis de cada etapa. Es decir que si no se observa la utilizacin de una
metodologa y no existen controles propios de un proyecto son muestras que indican que el
proceso de adquisicin debe ser analizado con mayor profundidad.
Proceso de Adquisicin
Revisin del
requerimiento
Revisin de la
especificacin
Revisin
Proceso
seleccin
Revisin
Proceso de
customizacin
Revisin de
pruebas
e instalacin
Revisin de la
Entrega
Grfico 7 Proceso de Adquisicin
Para cada una de las etapas de la ejecucin del proyecto aqu propuestas se indicar objetivo
de
la
etapa,
principales
actividades
involucradas
el
producto
final
de
la
etapa. Adems se propone una lista con los objetivos de control, los riesgos y las revisiones a
realizar.
Revisin del Requerimiento

Ya sea para la construccin o para la adquisicin de un sistema de informacin 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 organizacin. En esta
etapa se utilizan diversas herramientas como son: encuestas, entrevistas, obtencin de
documentacin, mapeo de procesos, etc. .
Producto de esta etapa debe surgir un documento denominado Requerimientos del Sistema
PAGINA 23
donde se determina: Identificacin de la situacin actual, identificacin de los actuales

recursos tecnolgicos, necesidades de proceso y de informacin a ser satisfechas por el
sistema, controles que deben estar presentes en el sistema, grado de flexibilidad y
parametrizacin exigidos.
Objetivos de Control y Riesgo de la Etapa de Revisin de los

Requerimientos
Cuadro 8 Objetivos de Control y Riesgos Etapa Revisin del Requerimiento

Revisin de los requerimientos
Objetivo de Control
Riesgos Asociados
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
informacin 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 informacin.
actividad
de
la Dicho
documento
fue
organizacin.
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.
organizacin.
Existe un documento donde
se establecen las interfaces
con otros sistemas.
Se
ha
identificado
la No
se
tiene
la Existe un documento donde
capacidad tecnolgica actual infraestructura tecnolgica 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 tecnolgica
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 podran llegar tenido en cuenta.
alternativas de solucin.
a
satisfacer
los
requerimientos.
Revisin del Diseo 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 informacin, de control y legales.
En esta etapa tambin se establecer como se realizar el proceso de adquisicin, las etapas
contractuales y la lista de proveedores a ser invitados en el proceso de licitacin.
Objetivos de Control y Riesgos del Proceso de Revisin del Diseo del

Requerimiento
Cuadro 9 Objetivos de Control y Riesgos Asociados con Diseo del Requerimiento
Revisin del Diseo del Requerimiento
Objetivo de Control
Riesgos Asociados
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 construccin 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 tcnicas de ningn tipo de convencin mismo respeta las tcnicas
modelado.
o tcnica.
establecidas.
Problemas
de
interpretacin
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.
lgica ni fsica.
requerimentos de control
interno
El grado de flexibilidad o de El sistema no admite Se ha definido el grado de
parametrizacin 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 administracin de la contempla las pautas de seguridad fsica y lgica.
seguridad fsica y lgica.
mnimas de seguridad.
Se ha indicado el nivel de El sistema no responde Los lotes de prueba han
respuesta requerido por el ante los volmenes de contemplado los respectivos
sistema en transacciones por transacciones que debe requerimientos de esfuerzo.
minuto o en alguna otra administrar.
mtrica que se considere
apropiada.
Revisin del proceso de Seleccin de la Solucin

Una vez determinado los requerimientos tcnicos y legales del punto anterior, a los que
denominaremos pliegos, se continua con la etapa de seleccin de la solucin que se ajuste a
los requerimientos.
Esta etapa cubre desde la invitacin a cotizar ( o licitacin, esto depende de la mecnica
seleccionada) a los proveedores hasta la determinacin de la solucin seleccionada.
Objetivos de control y riesgos del Proceso de Seleccin de la Solucin

Cuadro 10 Objetivos de Control y Riesgos Asociados con la Seleccin de la Solucin
Revisin del proceso de seleccin de la Solucin
Objetivo de Control
Riesgos Asociados
Se
ha
realizado
una Los
proveedores
y/o Una vez definidas las
investigacin
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
mnimos podran cumplir con el
confeccionado una lista de establecidos.
requerimiento realizado.
posibles proveedores.
PAGINA 26
La documentacin que se La documentacin 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 anlisis 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 evaluacin
seleccin 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.
evaluacin debe asegurar
requerimientos.
El plan de capacitacin 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
organizacin.
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
estn algunos aspectos.
requerimientos.
claramente
especificados
como as tambin las
responsabilidades de cada
parte.
Revisin de la Etapa de Instalacin y Customizacin

En esta etapa se realiza la instalacin y configuracin del sistema para que se adapte a las
caractersticas 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 capacitacin para que esta etapa pueda ser llevada adelante por el
personal de la empresa.
Si los parmetros no son adecuadamente definidos pueden surgir problemas durante las
pruebas o lo que es ms grave puede ser que surjan cuando el sistema ya este en marcha.
PAGINA 27
Objetivos de control y riesgos de la etapa de Instalacin Customizacin del

Producto
Cuadro 11 Objetivos de Control y Riesgos Asociados con la Customizacin
Revisin del Proceso de Instalacin y Customizacin del Producto
Objetivo de Control
Riesgos Asociados
La instalacin del Hardaware Existen demoras en la Se ha establecido un plan de
necesario se cumpliment en implementacin debido a instalacin 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 instalacin de software de Existe demoras en la Se ha establecido un plan de
base se cumplimento en instalacin debido a que instalacin del software de
tiempo y forma
no se ha realizado la base y se han contemplado
instalacin del software de los
requerimientos
base o el mismo est mal establecidos
por
el
instalado.
proveedor.
Todos los parmetros de Existen parmetros no Los parmetros han sido
funcionamiento se encuentran definidos que provocan el adecuadamente establecidos
adecuadamente definidos.
mal funcionamiento del y los usuarios participan en
sistema.
su definicin.
La definicin de los Se
ha
realizado
la
parmetros no es la capacitacin suficiente para
adecuada y provoca el la adecuada definicin de
malfuncionamiento
del los parmetros.
sistema.
Revisin de la Etapa de Prueba y Paralelo

En esta etapa que comienza luego de la capacitacin del personal y de realizado el proceso de
capacitacin. 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 aceptacin del

producto y es cuando se verifica que se cumple con lo indicado en la
especificacin del requerimiento. Las principales actividades de esta etapa son:
Armado de lotes de prueba, ejecucin de las pruebas, verificacin del
cumplimiento de los requerimientos, simulacin de cierres o procesos crticos del
sistema, pruebas de performance del hardware, pruebas de las interfaces con otros
PAGINA 28
sitemas, pruebas de aspectos de seguridad fsica y lgica, incorporacin o

Migracin 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 ms
de un sistema) por lo que implica duplicacin 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.
Revisin del Proceso de Prueba y Paralelo
Objetivo de Control
Riesgos Asociados
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 Revisin de los lotes de
contemplan casos complejos por las pruebas que luego pruebas y verificacin de
provocan errores en el que los usuarios han
sistema.
intervenido en la definicin
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 recuperacin de backups.
ataques.
Las pruebas deben incluir
un test de penetracin a los
sistemas a efectos de
verificar la seguridad lgica.
El proceso de conversin de Los datos registrados del Existe un plan conversin
datos de un sistema a otro se sistema
anterior
no de datos.
ha
realizado pueden ser utilizados.
Se ha realizado un adecuado
satisfactoriamente.
La
informacin estudio de las estructuras de
recuperada del sistema datos del sistema anterior y
anterior no es confiable.
del nuevo establecindose
Existen errores en la las
respectivas
PAGINA 29
conversin de los datos.
El paralelo se ha realizado No se ha realizado

satisfactoriamente
y
las paralelo
de
algunas
diferencias han sido aclaradas operaciones o servicios.
adecuadamente.
No se han detectado
algunas diferencias.
No se determina si las
diferencias
son
por
problemas con el sistema
anterior y propias del
nuevo sistema.
No se realizan las
correcciones
de
las
diferencias detectadas
El paralelo se prolonga
por demasiado tiempo.
No existe una fecha de fin
del paralelo.
Existe
resistencia
a
abandonar el paralelo.
El paralelo es abandonado
an existiendo diferencias
no identificadas.
equivalencias.
Se
han
probado
los
programas conversores.
Se
han
revisado
la
informacin del sistema
anterior a nivel de totales y
de un muestreo de datos
individuales que asegure la
confiabilidad de los datos.
Existe una planificacin del
paralelo con el sistema
anterior y esa planificacin
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.
La
diferencias
son
detectadas en su totalidad.
Las diferencias deben ser
identificadas y su causa
esclarecida.
Las diferencias u errores
deben ser corregidos y
asegurarse
su
correcto
funcionamiento.
El paralelo se realiza dentro
de los plazos establecidos
en la planificacin.
Al momento de abandonar
el paralelo existe expresa
conformidad de los usuarios
y todas las diferencias han
sido aclaradas y corregidas.
Revisin del Proceso de Entrega y Aceptacin del Sistema

Una vez realizada la etapa de prueba y paralelo y de pasado un tiempo prudencial se procede a
la aceptacin del producto y a la culminacin 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

rgimen normal.
Objetivos de Control y Riesgos de la Etapa de Entrega y Aceptacin del

Sistema
Cuadro 13 Objetivos de Control y Riesgos Asociados con el Impacto en el Negocio
Revisin de la Entrega y Aceptacin del Sistema.
Objetivo de Control
Riesgos Asociados
Las pruebas y paralelo del El sistema es entregado Se
ha
realizado
la
sistema
han
culminado sin haberse culminado con finalizacin de las etapas de
satisfactoriamente.
la etapa de prueba y pruebas y paralelo con la
paralelo.
aceptacin de los usuarios.
Se han cerrado todos los El
sistema
se
han Se
ha
realizado
la
incidentes originados en entregado con errores o conclusin de todos los
errores de programa o por diferencias pendientes de incidentes por errores o
diferencias detectadas en el resolucin.
diferencias.
paralelo
No existen modificaciones o El sistema es entregado Se ha verificado que no
adaptaciones pendientes a la an
faltando
la existen
modificaciones
fecha de entrega.
incorporacin de algunas pendientes.
mejoras
Existe un documento de El
sistema
no
es Se debe verificar
la
aceptacin 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 resolucin
estos deben estar indicados
como as tambin el plazo
de resolucin de los
mismos.
Revisin de la Etapa de Mantenimiento

El mantenimiento es el servicio adicional que presta el proveedor una vez que el sistema se
encuentra en rgimen.
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
Revisin de la etapa de Mantenimiento.
Objetivo de Control
Riesgos Asociados
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
correccin de errores.
actualizacin y correccin
de errores.
El sistema es actualizado El proveedor no realiza Verificar que los cambios
peridicamente o ante nuevos actualizaciones peridicas 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
ms 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 documentacin 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 actualizacin
de
los
prestaciones.
respectivos
manuales de
usuarios.
Se debe verificar si los
cambios en la nueva versin
afectan los procesos y
controles actuales.
Se debe verificar que el
proveedor cuente con un
programa de capacitacin y
actualizacin.
Conclusin
En el presente trabajo intenta alertar sobre las distintas implicancias que tiene la incorporacin
PAGINA 32
de tecnologa informtica en el mbito de una organizacin y por lo tanto que aspectos

mnimos se deberan tener presente al evaluar un proceso de adquisicin de software.
En ese sentido se remarca la necesidad no solo de evaluar a la adquisicin como un proceso
puntual, sino que se debera tomar en un sentido ms amplio. Es as que se incorpora la
evaluacin de lo que se denomin el Ambiente del Proyecto y tambin el impacto que dicho
proyecto tiene en la organizacin en lo que hace al Negocio en s mismo y tambin en lo
relativo a aspectos Funcionales y aspectos Tecnolgicos.
De esta forma el auditor tendr una visin mas amplia de los riesgos asociados y podr
formular un plan de trabajo que agregue valor al proceso de adquisicin del software y que le
permitan a la organizacin alcanzar satisfactoriamente el objetivo propuesto al realizar este
tipo de inversiones.
Bibliografa Consultada
IFAC - International Standard on Auditing 401 Auditing in a computer information

systems environment. Ao 2004.
ISACA - Cobit 3ra. Edicin Objetivos de Control para la Informacin y Tecnologas

Relacionadas Ao 2003.
Federacin Argentina de Consejos Profesionales de Ciencias Econmicas CECYT Informe 6 -
Pautas para el Examen de Estados Contables en un Contexto
Computadorizado.
Laudon y Laudon Sistemas de Informacin Gerencial Capitulo 11 Rediseo de la

Organizacin mediante Sistemas de Informacin Sexta Edicin Ao 2002 - Pgina 341
Matas Fernndez Daz Adquisicin de Recursos de Tecnologa Informtica Revista

Sindicatura Abril 1998 Pgina 97.
PAGINA 33

Auditoria de La Adquisición de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Auditoria de La Adquisición de Software

Uploaded by

Copyright:

Available Formats

AUDITORIA

AREA: III Contabilidad y Auditora .

TEMA: 2 Auditora - La auditora de Sistemas Electrnicos de Informacin.

CONGRESO: 15 Congreso Nacional de Profesionales en Ciencias Econmicas Salta 20,21

RESUMEN DEL TRABAJO

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

ndice del Trabajo

ROL ESPERADO DEL AUDITOR

ENFOQUES PARA ENCARAR LA AUDITORA DEL PROCESO DE ADQUISICIN 5

ETAPAS DE LA REVISIN DEL PROCESO DE ADQUISICIN DEL SOFTWARE 6

REVISIN DEL PROYECTO

AMBIENTE DEL PROYECTO

OBJETIVOS DE CONTROL Y RIESGOS DEL AMBIENTE

IMPACTO DEL PROYECTO

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

OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS CON EL IMPACTO FUNCIONAL

OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS AL IMPACTO TECNOLGICO

REVISIN DEL PROCESO DE ADQUISICIN E IMPLANTACIN

REVISIN DEL REQUERIMIENTO

OBJETIVOS DE CONTROL Y RIESGO DE LA ETAPA DE REVISIN DE LOS REQUERIMIENTOS

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

REVISIN DEL DISEO DEL REQUERIMIENTO

OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE REVISIN DEL DISEO DEL

REVISIN DEL PROCESO DE SELECCIN DE LA SOLUCIN

OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE SELECCIN DE LA SOLUCIN

REVISIN DE LA ETAPA DE INSTALACIN Y CUSTOMIZACIN

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE INSTALACIN CUSTOMIZACIN DEL

REVISIN DE LA ETAPA DE PRUEBA Y PARALELO

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

REVISIN DEL PROCESO DE ENTREGA Y ACEPTACIN DEL SISTEMA

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE ENTREGA Y ACEPTACIN DEL

REVISIN DE LA ETAPA DE MANTENIMIENTO

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE MANTENIMIENTO

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

El gasto destinado a software es un componente cada vez ms importante de la inversin

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

Un 3,0 % se us despus 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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

respecto de un producto determinado. Este enfoque podra implicar que el auditor se

Enfoques para encarar la auditora del proceso de

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

a la problemtica propuesta, en el entendimiento de que luego cada profesional podr limitar

Etapas de la revisin del proceso de adquisicin del

Revisin del Proyecto

Grfico 1 Etapas de la Revisin

Revisin del Proyecto: La existencia de un proyecto adecuadamente administrado y

Proceso de Adquisicin: Es la adquisicin en si misma que abarcar desde el proceso

Seguimiento: Una vez instalado el sistema y estabilizado se debe verificar que el

Revisin del Proyecto

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

Impacto del Proyecto: El objetivo de medir el impacto del

determinar los riesgos a los que se encuentra sometida la organizacin al incorporar el

Ambiente del Proyecto

Dentro de los aspectos a ser considerados en el ambiente encontramos:

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

Informacin sobre el ambiente

Ambiente del Proyecto

Grfico 2 Aspectos del Ambiente