You are on page 1of 35

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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.

Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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
Verificaciones a Realizar
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

AUDITORIA DE LA ADQUISICIN DE SOFTWARE

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