Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Pcia. Bs - As. - Elissondo - R32301el
Pcia. Bs - As. - Elissondo - R32301el
ADQUISICIÓN DE SOFTWARE
y 22 de Octubre de 2004.
AUTOR: Cr. Luis Elissondo – Miembro del Centro de Estudios Contables de la Facultad de
Trabajo Coordinado por el Dr. Cayetano Mora – Tomo XXXVI Folio 126 del Consejo
ADQUISICIÓN DE SOFTWARE
y 22 de Octubre de 2004.
RESUMEN DEL TRABAJO
El presente trabajo busca brindar una herramienta para aquellos auditores que deben evaluar
Para esto se propone una visión amplia de esta tarea de revisión a partir de la incorporación de
la evaluación del Ambiente del Proyecto y del Impacto del mismo en lo que hace al Negocio
También se incorporan para cada etapa cuadros donde se indican los objetivos de control,
riesgos relacionados y actividades a realizar para verificar los objetivos de control que se
proponen.
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
INTRODUCCIÓN 3
IMPACTO EN EL NEGOCIO 13
IMPACTO FUNCIONAL 16
IMPACTO TECNOLÓGICO 19
24
PAGINA 1
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
REQUERIMIENTO 25
PRODUCTO 28
SISTEMA 31
CONCLUSIÓN 33
Bibliografía Consultada 33
PAGINA 2
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Introducción
Cada vez son mas las organizaciones que se ven sometidas a la tarea de seleccionar el
recurso estratégico indispensable para las organizaciones, muchas de las cuales verían
Esta suerte de vinculo entre sistemas y negocios también a provocado que los tiempos de
respuesta que se le exigen a la gente de sistemas para la producción y/o adaptación de los
sistemas sean cada vez menores debido fundamentalmente a la dinámica que el mercado le
A esto se debe sumar que muchas empresas a tomado la decisión de disminuir de manera
sensible los servicios propios de sistemas y han optado por tercerizar el desarrollo de sus
Otro elemento que gravita en la decisión de las empresas para optar por la adquisición de
desarrollos realizados por terceros es no volver a inventar la rueda tomando los sistemas que
el mercado no provee.
Si bien lo expresado en los párrafos anteriores de por sí justifica la intervención del Auditor
en la selección del software, se pueden enumerar otros motivos por los que se justifica la
PAGINA 3
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
funcionamiento de los controles de este proceso. Los datos del Government Accounting
Si bien no es el objetivo de este trabajo establecer cual debe ser el rol del auditor en cuanto al
grado de participación en este tipo de procesos, podemos decir que las posibilidades son las
siguientes:
Analizar el proceso una vez que el mismo aconteció y establecer los desvíos o problemas
que encuentren. Este enfoque se asimilaría a cualquier otra revisión de las adquisiciones
pero además emitiendo opinión sobre el software que se debe adquirir desde el punto de
vista de la calidad del control interno y de los posibles inconvenientes que se pueden
presentar. Esto implica también asesorar en el proceso de selección indicando los controles
materia de seguridad y controles, etc., pero sin emitir una opinión o recomendación
PAGINA 4
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
justificar en el hecho de que el auditor luego deberá realizar la revisión de los controles
tanto es preferible que actúe de manera proactiva, es decir antes de encontrarse con un
hecho ya consumado.
Más allá del rol que le toque jugar al auditor, la propuesta de revisión que aquí se realiza tiene
diversas formas de ser abordada de acuerdo al trabajo que se le encomiende al auditor. Esto
es:
realizada de acuerdo a prácticas razonables para este tipo de procedimiento. Es decir tomar el
-Evaluar el proyecto en forma integral: Aquí la revisión incluye aspectos relacionados con
-Evaluar el impacto del software adquirido en relación al negocio: En este caso, además
de los aspectos enunciados anteriormente se incluye el análisis del ambiente del proyecto es
decir que se evalúan otros aspectos tales como la existencia de un plan de sistemas, nivel de
integración de dicho plan con el plan estratégico de negocios, organización del área de
sistemas, etc.
En este trabajo se propone el último de estos enfoques a efectos de dar un tratamiento amplio
PAGINA 5
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
la aplicación de esta propuesta de acuerdo a la realidad que lo rodea y de los recursos de los
que dispone.
Etapas de Revisión
Proceso de Adquisición
Seguimiento
control.
PAGINA 6
AUDITORIA DE LA ADQUISICIÓN 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 revisión en
dos aspectos:
Ambiente del Proyecto: Por ambiente del proyecto se entiende a todos aquellos
software en cuestión. Es así que se debe revisar lo relacionado con el impacto sobre el
que un nuevo sistema tendría sobre aspectos funcionales, es decir sobre los procesos
El ambiente del proyecto esta conformado por diversos aspectos, la inexistencia total o parcial
de estos elementos no implica que debamos inferir que el proyecto adolece de graves
falencias. Significa que deberemos realizar una revisión mas intensiva de algunos puntos.
Digamos entonces que en esta etapa de la revisión se trata de establecer si los puntos de apoyo
del proyecto son los adecuados para que el mismo pueda llegar a un buen fin.
PAGINA 7
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Metodología Tecnología
grado de integración del mismo con el Plan Estratégico de Negocio nos permite establecer el
grado de importancia que la organización le da a sus sistemas y además que las acciones son
realizadas de acuerdo a una planificación previa evitando de esta forma que el accionar solo
obedezca a impulsos que nada tienen que ver con criterios básicos de administración.
Administración del proyecto: Deben existir adecuadas pautas para el manejo de proyectos
predeterminados que deben ser seguidos por los distintos proyectos como una forma de
Tecnología: El nivel tecnológico alcanzado por los aplicativos que integran la cartera de
incorporada representa un salto cualitativo que la organización puede asimilar sin mayores
PAGINA 8
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
incorporación de los recursos tecnológicos, esto permite inferir que cada “salto” tecnológico
mínimas a realizar para verificar el ambiente del proyecto. Es importante aclarar que se habla
de revisiones mínimas ya que no es el objetivo del trabajo auditar cada uno de los elementos
Mas bien se intenta que el auditor pueda delimitar más claramente las responsabilidades al
momento de emitir su opinión. Esto quiere decir que si desde el nivel directivo no existe una
PAGINA 9
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
PAGINA 10
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Los recursos asignados para Existen etapas del Verificar que la existencia o
cada etapa del proyecto son proyecto que no se pueden disponibilidad de recursos
los adecuados de acuerdo a cumplir por falta de humanos y materiales al
las prioridades fijadas. recursos o los recursos no proyecto son los adecuados.
son los adecuados.
Inadecuada
administración de
prioridades y asignación
de recursos.
Las etapas previstas deben ser Existen desviaciones que Verificación de los
cumplimentadas en tiempo y no son adecuadamente controles establecidos por el
forma finalizadas en tiempo y responsable del proyecto y
forma. de las acciones correctivas
No se corrige los errores o correspondientes.
desviaciones
Existe un cierre del proyecto El proyecto no queda Existe un documento donde
formalmente terminado. se informa los resultados del
No se realiza un proyecto y donde se indica
evaluación final. la liberación de los recursos
afectados.
Metodología
Objetivo de Control Riesgos Asociados Verificaciones a Realizar
Existe una metodología y la No se aplica una Existe documentada una
misma se encuentra metodología para el metodología de trabajo.
adecuadamente formalizada. desarrollo del proyecto
PAGINA 11
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
aplicada por todos los propio criterio para el metodológicas iguales son
integrantes de los distintos desarrollo de las tareas. aplicadas de la misma forma
proyectos en los distintos proyectos.
La metodología es La metodología utilizada Existe un proceso de
adecuadamente actualizada. no es aplicada porque a revisión y actualización
quedado desactualizada periódica de la metodología
para resolver los empleada.
problemas actuales.
Tecnología
Objetivo de Control Riesgos Asociados Verificaciones a Realizar
Se realiza una planificación En la organización hay Existencia de un plan de
de los aspectos tecnológicos y diversas tecnologías en desarrollo tecnológico y de
es periódicamente revisada uso que son incompatibles compatibilidad entre
entre sí. distintos estándares.
La tecnología está
desactualizada.
No existen planes de
actualización de la
tecnología.
El objetivo de medir el impacto que el proyecto tiene es a efectos de determinar los riesgos a
PAGINA 12
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Negocio Tecnológico
Funcional
El principal riesgo está dado el tamaño del proyecto. Existen diversos factores que nos
determinar otros aspectos tales como el impacto del proyecto en el negocio, el impacto
Impacto en el negocio
De acuerdo al tipo de aplicación que se adquiere esta puede ser más o menos vital para el
PAGINA 13
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
que permitirá la autogestión de los clientes a través de internet no hay duda que el impacto es
muy importante. Lo mismo cuando el software en cuestión soporta tareas que son el “core
Esto tiene sin duda impacto cuando se audita la fase de Análisis de Necesidades y de
adecuadamente explicitados en los requerimientos para que el software que se adquiera los
respete, caso contrario deberán figurar en los requerimientos de customización del mismo.
Impacto en el Negocio
Riesgo Medio Riesgo Alto
Tamaño del Proyecto
Grande
Problemas de Peligra la
adminisración supervivencia
Bajo Alto
Impacto en el proceso de Negocio
Alto impacto en el negocio y Proyecto Amplio – Alto Riesgo: En este caso se trata de un
proyecto de alto impacto en el negocio y de una alta complejidad importante dada su tamaño.
El riesgo esta dado básicamente porque existe la posibilidad de que el proyecto tenga
PAGINA 14
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
porque se trata de un proyecto fundamental para el desarrollo del negocio. En este caso el
que se basa en el sistema que se adquiere y la imposibilidad de volver a invertir los recursos
Alto impacto en el negocio y Proyecto reducido – Riesgo Medio: La variante respecto del
caso anterior es que el grado de complejidad o tamaño del proyecto en este caso es reducida lo
cual permitiría por un lado contar con mayores posibilidades de éxito en la administración del
proyecto y en caso de existir inconvenientes es más fácil atacarlos. De todas formas aún
Bajo Impacto en el negocio y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto de alta complejidad pero que no tiene un impacto alto sobre el negocio. De todas
formas aún tratándose de una situación operativa sabemos que estas tampoco son ajenas al
desarrollo del negocio. En este caso se ha calificado el riesgo como medio debido a que no se
Bajo Impacto en el Negocio y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de menor relevancia que no afectará la continuidad del negocio. En este punto el
riesgo esta dado por la mala utilización de los fondos destinados al proyecto.
PAGINA 15
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Impacto en el Negocio
Objetivo de Control Riesgos Asociados Verificaciones a Realizar
El proyecto se encuentra Los sistemas no El plan estratégico de
dentro del marco del plan de responden a las sistemas es coordinado con
negocios de la empresa. necesidades del negocio. el plan de negocios.
Las especificaciones La habilidades propias del En la documentación de los
establecidas contemplan los negocio no se encuentran requerimientos se
factores esenciales del apoyadas por los nuevos identifican las habilidades
negocio. sistemas. principales que distinguen a
la empresa.
El sistema tiene la capacidad El sistema se muestra Se ha previsto que el o los
de adaptarse a nuevas reglas inflexible ante nuevos sistemas sean
del negocio. cambios. parametrizables y flexibles
para adaptarse a los
cambios.
Se ha medido adecuadamente El negocio se ve Se ha previsto el alcance e
el impacto del proyecto en el seriamente cuestionado impacto del proyecto como
negocio ante el fracaso del así también las
proyecto de sistemas. consecuencias del fracaso
del mismo.
Impacto Funcional
En este caso lo que se mide es la viabilidad operativa del proyecto, es decir si el mismo podrá
posterior implementación.
Cantidad de Procesos y Profundidad del Cambio: En este caso se debe sopesar que
grado variación que sufren que puede ir de un cambio menor hasta la desaparición del
proceso.
PAGINA 16
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
caso es que el nuevo sistema reemplaza a más de un sistema anterior (como es el caso
cuando se instalan sistemas integrados que reemplazan a más de una aplicación) por lo
Impacto Funcional
Riesgo Riesgo Alto
Tamaño del Proyecto
Amplio
Moderado
Viabilidad del
Problemas de Proyecto
Administración
Riesgo
Reducido
Bajo Alto
Impacto funcional
Alto impacto Funcional y Proyecto Amplio – Riesgo Alto: En este caso se encuentra en
juego la viabilidad del proyecto en cuanto a la posibilidad real de implementación del mismo
En este tipo de proyecto además de la propia complejidad de tener que actuar con múltiples
usuarios que tienen múltiples intereses que deberán tenerse en cuenta, se encuentra la
PAGINA 17
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Alto impacto Funcional y Proyecto reducido – Riesgo Moderado: La variante respecto del
caso anterior es que tiene un alto impacto en los aspectos funcionales pero la problemática se
ve acotada a un sector.
donde una falla en los requerimientos que se hagan a los autopartistas puede afectar los plazos
de entregas de los automóviles y por ende incumplir con las entregas pactadas a los clientes.
En este caso el riesgo está dado fundamentalmente por el grado de adaptación operativa del
sector en cuestión.
Bajo Impacto Funcional y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organización pero que no comprende a un gran número
de procesos.
En este caso el riesgo esta dado fundamentalmente por los inconvenientes que puedan surgir
Bajo Impacto Funcional y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de menor tamaño acotado a un sector y que afecta procesos poco relevantes.
PAGINA 18
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Impacto Funcional
Objetivo de Control Riesgos Asociados Verificaciones a Realizar
Todos los sectores Los sectores no conocen Existencia de
involucrados conocen el como el proyecto o nuevo comunicaciones internas
proyecto y como este los sistema los afectará que establezcan el alcance y
afecta profundidad del proyecto
Los sectores participan del Los sectores se ven Existencia de un foro de
proyecto. imposibilitados de discusión o comité de
establecer los usuarios.
requerimientos de Existencia de un registro de
información. requerimientos.
Todos los procesos afectados Existen procesos que no Existe un equipo de trabajo
han sido considerados y se son soportados por el que se encarga de la
han identificado los procesos sistema. interface entre el proyecto
que cambian, los que Se siguen realizando de sistemas y los nuevos
desaparecen y los nuevos procesos que no tienen procesos.
procesos sentido en un nuevo Existe documentación
esquema de trabajo. donde se formalizan los
Se desconocen los nuevos nuevos procesos.
procesos.
Se han respetado las pautas Los cambios de procesos
Se ha realizado la revisión
de control interno. que surgen de la
de los puntos de control
implementación del nuevo
interno.
sistema han afectado el
Los nuevos puntos de
control interno. control interno se
encuentran adecuadamente
formalizados.
Las relaciones entre sectores Existe descoordinación Se han formalizado
y aplicaciones se han entre áreas y sistemas. adecuadamente las
establecido correctamente interfaces entre sectores y
aplicaciones.
Impacto tecnológico
ya que son múltiples los factores que intervienen en una mejora tecnológica y por lo tanto
PAGINA 19
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
importantes.
de trabajo orientados a objetos con entornos visuales, implica nuevas formas de tratar la
los datos. Si tomamos por ejemplo la incorporación de bases de datos las mismas por un
lado facilitan el desarrollo y modificación de los sistemas pero a su vez tienen su propio
aspectos tecnológicos.
y de memoria del equipo necesario para correr dicho software. Lo que implica que el
adquieren sistemas que corren sobre base de datos es si las licencias se encuentran
PAGINA 20
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Impacto Tecnológico
Amplio
Moderado
Posible fracaso
Problemas de del proyecto
administración
Riesgo
Reducido
Riesgo Bajo Moderado
Posibles
demoras
Bajo Alto
Impacto tecnológico
Alto impacto Tecnológico y Proyecto Amplio – Alto Riesgo: En este caso el problema esta
recursos a un nuevo entorno visual con lo cual la introducción del nuevo sistema también
del caso anterior es que tiene un alto impacto en los aspectos tecnológico pero la
en este caso también lo importante es establecer cuán critico es el sector o proceso al que se
Bajo Impacto Tecnológico y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organización pero no existen cambios tecnológicos
sustantivos.
PAGINA 21
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Bajo Impacto Tecnológico y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de que no implica un cambio tecnológico sustancial y que no impacta sobre gran
parte de la organización. Este seria el caso de una actualización a una nueva versión del
Impacto Tecnológico
Objetivo de Control Riesgos Asociados Verificaciones a Realizar
Existe un plan de La infraesctructura Existencia de un plan a
infraestructura tecnológica. tecnológica crece en mediano y largo plazo
forma errática acerca de la infraestructura
tecnológica de la
organización.
La infraestructura tecnológica Existen dificultades para Existencia de un proceso de
se encuentra adecuadamente correr nuevas aplicaciones actualización tecnológica.
actualizada y el personal debido a que en algunos Existen actividades de
capacitado en el uso de la sectores la tecnología es capacitación en nuevas
misma. obsoleta. tecnologías.
Existe nueva tecnología
pero no se utiliza
adecuadamente.
Existe un responsable de Los nuevos sistemas son Existe un registro de la
evaluar los nuevos incompatibles con los infraestructura actual.
requerimientos tecnológicos y anteriores. En cada nuevo proyecto se
la compatibilidad con la La infraestructura debe ser establecen los
infraestructura actual actualizada sobre la requerimientos de
marcha. infraestructura y el grado de
compatibilidad.
En el proyecto se indican
los nuevos requerimientos y
el impacto financiero de los
mismos.
PAGINA 22
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
profundidad del análisis de cada etapa. Es decir que si no se observa la utilización de una
metodología y no existen controles propios de un proyecto son muestras que indican que el
Proceso de Adquisición
Revisión
Revisión del Revisión de la
Proceso
requerimiento especificación
selección
Revisión Revisión de
Revisión de la
Proceso de pruebas
Entrega
customización e instalación
Para cada una de las etapas de la ejecución del proyecto aquí propuestas se indicará objetivo
etapa. Además se propone una lista con los objetivos de control, los riesgos y las revisiones a
realizar.
fundamental la etapa de Relevamiento de las necesidades de los futuros usuarios del sistema a
En esta etapa se establece el contacto con las necesidades que posee la organización. En esta
Producto de esta etapa debe surgir un documento denominado Requerimientos del Sistema
PAGINA 23
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
parametrización exigidos.
sistema.
Se han identificado posibles Existen soluciones en el Documento donde se
soluciones que establece el mercado que no se han informan posibles
mercado y que podrían llegar tenido en cuenta. alternativas de solución.
a satisfacer los
requerimientos.
que será el documento base para que los proveedores realicen sus ofertas. Por lo tanto en el
En esta etapa también se establecerá como se realizará el proceso de adquisición, las etapas
PAGINA 25
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Una vez determinado los requerimientos técnicos y legales del punto anterior, a los que
los requerimientos.
Esta etapa cubre desde la invitación a cotizar ( o licitación, esto depende de la mecánica
PAGINA 26
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
deberá dar el soporte y capacitación para que esta etapa pueda ser llevada adelante por el
personal de la empresa.
Si los parámetros no son adecuadamente definidos pueden surgir problemas durante las
pruebas o lo que es más grave puede ser que surjan cuando el sistema ya este en marcha.
PAGINA 27
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
En esta etapa que comienza luego de la capacitación del personal y de realizado el proceso de
sistema, pruebas de performance del hardware, pruebas de las interfaces con otros
PAGINA 28
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
y el sistema o sistemas anteriores (puede ser que el nuevo sistema reemplace a más
actividad de control para determinar las diferencias entre uno y otro sistema.
Paralelo.
PAGINA 29
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Una vez realizada la etapa de prueba y paralelo y de pasado un tiempo prudencial se procede a
PAGINA 30
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
régimen normal.
El mantenimiento es el servicio adicional que presta el proveedor una vez que el sistema se
adecuadamente que se entiende por mantenimiento y soporte del sistema cuando este es
PAGINA 31
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Conclusión
En el presente trabajo intenta alertar sobre las distintas implicancias que tiene la incorporación
PAGINA 32
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
puntual, sino que se debería tomar en un sentido más amplio. Es así que se incorpora la
evaluación de lo que se denominó el Ambiente del Proyecto y también el impacto que dicho
De esta forma el auditor tendrá una visión mas amplia de los riesgos asociados y podrá
formular un plan de trabajo que agregue valor al proceso de adquisición del software y que le
tipo de inversiones.
Bibliografía Consultada
IFAC - International Standard on Auditing 401 – Auditing in a computer information
Computadorizado.
Organización mediante Sistemas de Información – Sexta Edición Año 2002 - Página 341
PAGINA 33