Download - Auditoria de La Adquisición de Software
AUDITORIA DE LA ADQUISICIÓN DE
SOFTWARE
AREA: III Contabilidad y Auditoría .
TEMA: 2 Auditoría - La auditoría de Sistemas Electrónicos de Información.
CONGRESO: 15 Congreso Nacional de Profesionales en Ciencias Económicas – Salta 20,21
y 22 de Octubre de 2004.
RESUMEN DEL TRABAJO
Los procesos organizacionales han pasado a estar soportados en su mayoría en sistemas de
información que normalmente son adquiridos a empresas especializadas en la temática.
El presente trabajo busca brindar una herramienta para aquellos auditores que deben evaluar
un proceso de adquisición de software, donde se analizan diversos aspectos relacionados con
la revisión de dicho proceso.
Para esto se propone una visión amplia de esta tarea de revisión a partir de la incorporación de
la evaluación del Ambiente del Proyecto y del Impacto del mismo en lo que hace al Negocio
y a Aspectos Funcionales y Tecnológicos.
También se incorporan para cada etapa cuadros donde se indican los objetivos de control,
riesgos relacionados y actividades a realizar para verificar los objetivos de control que se
proponen.
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Índice del Trabajo
INTRODUCCIÓN 3
ROL ESPERADO DEL AUDITOR 4
ENFOQUES PARA ENCARAR LA AUDITORÍA DEL PROCESO DE ADQUISICIÓN 5
ETAPAS DE LA REVISIÓN DEL PROCESO DE ADQUISICIÓN DEL SOFTWARE 6
REVISIÓN DEL PROYECTO 6
AMBIENTE DEL PROYECTO 7
OBJETIVOS DE CONTROL Y RIESGOS DEL AMBIENTE 9
IMPACTO DEL PROYECTO 12
IMPACTO EN EL NEGOCIO 13
OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS CON EL IMPACTO EN EL NEGOCIO 16
IMPACTO FUNCIONAL 16
OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS CON EL IMPACTO FUNCIONAL 18
IMPACTO TECNOLÓGICO 19
OBJETIVOS DE CONTROL Y RIESGOS ASOCIADOS AL IMPACTO TECNOLÓGICO 22
REVISIÓN DEL PROCESO DE ADQUISICIÓN E IMPLANTACIÓN 22
REVISIÓN DEL REQUERIMIENTO 23
OBJETIVOS DE CONTROL Y RIESGO DE LA ETAPA DE REVISIÓN DE LOS REQUERIMIENTOS
24
PAGINA 1
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
REVISIÓN DEL DISEÑO DEL REQUERIMIENTO 25
OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE REVISIÓN DEL DISEÑO DEL
REQUERIMIENTO 25
REVISIÓN DEL PROCESO DE SELECCIÓN DE LA SOLUCIÓN 26
OBJETIVOS DE CONTROL Y RIESGOS DEL PROCESO DE SELECCIÓN DE LA SOLUCIÓN 26
REVISIÓN DE LA ETAPA DE INSTALACIÓN Y CUSTOMIZACIÓN 27
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE INSTALACIÓN CUSTOMIZACIÓN DEL
PRODUCTO 28
REVISIÓN DE LA ETAPA DE PRUEBA Y PARALELO 28
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE PRUEBA Y PARALELO 29
REVISIÓN DEL PROCESO DE ENTREGA Y ACEPTACIÓN DEL SISTEMA 30
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE ENTREGA Y ACEPTACIÓN DEL
SISTEMA 31
REVISIÓN DE LA ETAPA DE MANTENIMIENTO 31
OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE MANTENIMIENTO 32
CONCLUSIÓN 33
Bibliografía Consultada 33
PAGINA 2
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
software con el cual se soportaran sus procesos de negocios. El software se ha vuelto un
recurso estratégico indispensable para las organizaciones, muchas de las cuales verían
inviable su negocio sin este recurso.
Esta suerte de vinculo entre sistemas y negocios también a provocado que los tiempos de
respuesta que se le exigen a la gente de sistemas para la producción y/o adaptación de los
sistemas sean cada vez menores debido fundamentalmente a la dinámica que el mercado le
imprime a los negocios.
A esto se debe sumar que muchas empresas a tomado la decisión de disminuir de manera
sensible los servicios propios de sistemas y han optado por tercerizar el desarrollo de sus
aplicaciones y el resto de las funciones asociadas al mismo.
Otro elemento que gravita en la decisión de las empresas para optar por la adquisición de
desarrollos realizados por terceros es no volver a inventar la rueda tomando los sistemas que
ya existen en e mercado y dedicando su equipo de sistemas a la producción del software que
el mercado no provee.
Si bien lo expresado en los párrafos anteriores de por sí justifica la intervención del Auditor
en la selección del software, se pueden enumerar otros motivos por los que se justifica la
auditoria del proceso de adquisición del software:
PAGINA 3
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
El gasto destinado a software es un componente cada vez más importante de la inversión
en Tecnología Informática que realizan las empresas.
El software es un producto muy difícil de evaluar. Un mayor control el proceso de
selección y adquisición aumenta la posibilidad de éxito final del proyecto.
El índice de fracasos en proyectos de desarrollo es alta, lo cual nota la inexistencia o mal
funcionamiento de los controles de este proceso. Los datos del Government Accounting
Office Report (EEUU) muestran este hecho:
Un 1,5 % se usó tal y como se entregó
Un 3,0 % se usó después de algunos cambios
Un 19,5 % se usó y luego se abandono o se rehizo
Un 47 % se entregó pero nunca se usó
Un 29 % se pagó pero nunca se entregó
Rol esperado del auditor
Si bien no es el objetivo de este trabajo establecer cual debe ser el rol del auditor en cuanto al
grado de participación en este tipo de procesos, podemos decir que las posibilidades son las
siguientes:
Analizar el proceso una vez que el mismo aconteció y establecer los desvíos o problemas
que encuentren. Este enfoque se asimilaría a cualquier otra revisión de las adquisiciones
que realiza la organización.
Participar en el proceso de selección realizando las tareas mencionadas en el punto anterior
pero además emitiendo opinión sobre el software que se debe adquirir desde el punto de
vista de la calidad del control interno y de los posibles inconvenientes que se pueden
presentar. Esto implica también asesorar en el proceso de selección indicando los controles
deseables, calidad del armado de lotes de prueba, sugiriendo posibles adaptaciones en
materia de seguridad y controles, etc., pero sin emitir una opinión o recomendación
PAGINA 4
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
respecto de un producto determinado. Este enfoque podría implicar que el auditor se
involucre, pero en cierta forma esta intervención en el proceso de adquisición se puede
justificar en el hecho de que el auditor luego deberá realizar la revisión de los controles
internos de la organización que estarán soportados en el sistema que se adquiera y por lo
tanto es preferible que actúe de manera proactiva, es decir antes de encontrarse con un
hecho ya consumado.
Enfoques para encarar la auditoría del proceso de adquisición
Más allá del rol que le toque jugar al auditor, la propuesta de revisión que aquí se realiza tiene
diversas formas de ser abordada de acuerdo al trabajo que se le encomiende al auditor. Esto
es:
-Evaluar el proceso de adquisición: Es decir determinar si la adquisición del software fue
realizada de acuerdo a prácticas razonables para este tipo de procedimiento. Es decir tomar el
proceso como un elemento aislado y puntual.
-Evaluar el proyecto en forma integral: Aquí la revisión incluye aspectos relacionados con
el gerenciamiento y calidad del proyecto. El proceso de adquisición se considera una etapa
dentro de la evaluación del proyecto.
-Evaluar el impacto del software adquirido en relación al negocio: En este caso, además
de los aspectos enunciados anteriormente se incluye el análisis del ambiente del proyecto es
decir que se evalúan otros aspectos tales como la existencia de un plan de sistemas, nivel de
integración de dicho plan con el plan estratégico de negocios, organización del área de
sistemas, etc.
En este trabajo se propone el último de estos enfoques a efectos de dar un tratamiento amplio
PAGINA 5
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
a la problemática propuesta, en el entendimiento de que luego cada profesional podrá limitar
la aplicación de esta propuesta de acuerdo a la realidad que lo rodea y de los recursos de los
que dispone.
Etapas de la revisión del proceso de adquisición del Software
Tomando la propuesta más amplia, se proponen las siguientes etapas de revisión:
Gráfico 1 – Etapas de la Revisión
Revisión del Proyecto: La existencia de un proyecto adecuadamente administrado y
en el cual se trabaja con una metodología preestablecida permite presumir que el
proceso de adquisición de software se realiza en un ambiente planificación y mayor
control.
Proceso de Adquisición: Es la adquisición en si misma que abarcar desde el proceso
de establecimiento de requerimientos hasta la adquisición.
Seguimiento: Una vez instalado el sistema y estabilizado se debe verificar que el
sistema cumple con lo establecido y que el servicio de mantenimiento y soporte
pactado con el proveedor se cumple satisfactoriamente.
Revisión del Proyecto
PAGINA 6
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
aspectos, que si bien no se encuentran directamente vinculados, influyen sobre el
mismo y permiten tener un primer grado de aproximación a cerca de la calidad del
proyecto. Dentro de estos encontramos la posibilidad de verificar la existencia de un
plan estratégico de sistemas, la forma en que el proyecto es administrado, la
metodología utilizada y el nivel tecnológico de la organización.
Impacto del Proyecto: El objetivo de medir el impacto del proyecto es para
determinar los riesgos a los que se encuentra sometida la organización al incorporar el
software en cuestión. Es así que se debe revisar lo relacionado con el impacto sobre el
esquema de negocios, el impacto que implicaría un cambio tecnológico y el impacto
que un nuevo sistema tendría sobre aspectos funcionales, es decir sobre los procesos
que se realizan en la organización.
Ambiente del Proyecto
El ambiente del proyecto esta conformado por diversos aspectos, la inexistencia total o parcial
de estos elementos no implica que debamos inferir que el proyecto adolece de graves
falencias. Significa que deberemos realizar una revisión mas intensiva de algunos puntos.
Digamos entonces que en esta etapa de la revisión se trata de establecer si los puntos de apoyo
del proyecto son los adecuados para que el mismo pueda llegar a un buen fin.
Dentro de los aspectos a ser considerados en el ambiente encontramos:
PAGINA 7
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Gráfico 2 – Aspectos del Ambiente
Plan estratégico de Sistemas: La existencia de una planificación del recurso informático y el
grado de integración del mismo con el Plan Estratégico de Negocio nos permite establecer el
grado de importancia que la organización le da a sus sistemas y además que las acciones son
realizadas de acuerdo a una planificación previa evitando de esta forma que el accionar solo
obedezca a impulsos que nada tienen que ver con criterios básicos de administración.
Administración del proyecto: Deben existir adecuadas pautas para el manejo de proyectos
como son: la determinación de un líder de proyecto, la asignación calidad de los recursos
humanos involucrados, la existencia de herramientas para el seguimiento de los proyectos y la
existencia de informes periódicos de avance del mismo.
Metodología: La existencia de una metodología permite establecer la existencia de pasos
predeterminados que deben ser seguidos por los distintos proyectos como una forma de
asegurar la calidad de los mismos.
Tecnología: El nivel tecnológico alcanzado por los aplicativos que integran la cartera de
aplicaciones es un elemento de vital importancia para determinar si la nueva aplicación a ser
incorporada representa un salto cualitativo que la organización puede asimilar sin mayores
PAGINA 8
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
dificultades. En este sentido es fundamental verificar la existencia de una planificación de la
incorporación de los recursos tecnológicos, esto permite inferir que cada “salto” tecnológico
es medido adecuadamente a efectos de determinar su impacto en la organización.
En el próximo punto se establecen los objetivos de control, riesgos asociados y revisiones
mínimas a realizar para verificar el ambiente del proyecto. Es importante aclarar que se habla
de revisiones mínimas ya que no es el objetivo del trabajo auditar cada uno de los elementos
del ambiente ya que esto requerirá de un esfuerzo (tiempo y recursos) específicamente
orientado al análisis de cada uno de ellos.
Mas bien se intenta que el auditor pueda delimitar más claramente las responsabilidades al
momento de emitir su opinión. Esto quiere decir que si desde el nivel directivo no existe una
preocupación e involucramiento en tipo de proyectos ó nunca existió una directiva al respecto
son también responsables por los resultados que se obtengan.
Objetivos de Control y Riesgos del Ambiente
Cuadro 1 - Objetivos de control Relacionados con Plan Estratégico de Sistemas
Plan Estratégico de SistemasObjetivo de Control Riesgos Asociados Verificaciones a Realizar
El Plan de sistemas contempla las necesidades organizaciones y el crecimiento del negocio y se encuentra adecuadamente aprobado por la dirección y es periódicamente revisado ante cambios en la planificación de la organización.
Los sistemas no responden a las necesidades de la organización.Inflexibilidad de los sistemas ante nuevos requerimientos organizacionales.Desvinculación entre los distintos sistemas.Comportamiento desordenado y errático en el desarrollo y adquisición
Existencia de un plan formalizado y aprobado por el nivel máximo de la organización.Verificación de la actualización periódica del plan.Revisión de la documentación del directorio (actas de reuniones, instrucciones de la dirección, existencia de un responsable de la
PAGINA 9
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
de aplicaciones.Desconocimiento de la existencia o alcance del plan por parte de las distintas áreas organizacionales.La asignación de recursos no es la adecuada dado la dimensión del proyecto.
formulación, etc.Los cambios de los proyectos impactan en el plan de sistemas.
Cuadro 2 -Objetivos de Control y Riesgos Asociados con la Administración del Proyecto
Administración del ProyectoObjetivo de Control Riesgos Asociados Verificaciones a Realizar
El proyecto se encuentra adecuamente definido y aprobado por la autoridad competente y se inserta en el plan de sistemas de la organización.
El proyecto no fue adecuadamente aprobado y formalizadoMala integración entre los distintos proyectos.Descoordinación con las áreas usuarias.
Existencia de un documento (memorando o norma interna) donde se aprueba el proyectoExistencia de un plan del área de sistemas.Existencia de un “proyect“ donde se establecen los plazos y los recursos asignados.
El proyecto debe ser adecuadamente dimensionado y su impacto adecuadamente valorado. (para mayor detalle ver en este trabajo punto Impacto del Proyecto)
Existencia de problemas para llevar adelante el proyecto.
Existencia de una evaluación del proyecto en cuento a su impacto en el negocio, en aspectos funcionales y tecnológico. Se ha realizado el presupuesto financiero del proyecto y se ha realizado la comparación del proyecto contra otros proyectos de inversión.
Verificar la adecuada participación de los usuarios en el proyecto.
El sistema no responde a las necesidades de los usuarios.Los usuarios no participan en las distintas etapas del proyecto.
Se contempla la participación de usuarios a través de comités u otras formas de organización.Existe un registro con las inquietudes de los usuarios.
PAGINA 10
AUDITORIA DE LA ADQUISICIÓN 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 desvíos y se toman las acciones correctivas respectivas.Superposición de funciones y problemas de coordinación.
Los tiempos, grado de avance y recursos asignados a los proyectos son periódicamente revisados por el responsable del proyecto.Existe un mecanismo de resolución problemas.Existencia de un documento donde se establezcan responsabilidades y tareas.
Los recursos asignados para cada etapa del proyecto son los adecuados de acuerdo a las prioridades fijadas.
Existen etapas del proyecto que no se pueden cumplir por falta de recursos o los recursos no son los adecuados.Inadecuada administración de prioridades y asignación de recursos.
Verificar que la existencia o disponibilidad de recursos humanos y materiales al proyecto son los adecuados.
Las etapas previstas deben ser cumplimentadas en tiempo y forma
Existen desviaciones que no son adecuadamente finalizadas en tiempo y forma.No se corrige los errores o desviaciones
Verificación de los controles establecidos por el responsable del proyecto y de las acciones correctivas correspondientes.
Existe un cierre del proyecto El proyecto no queda formalmente terminado.No se realiza un evaluación final.
Existe un documento donde se informa los resultados del proyecto y donde se indica la liberación de los recursos afectados.
Cuadro 3 - Objetivos de Control y Riesgos Asociados con la Metodología
MetodologíaObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Existe una metodología y la misma se encuentra adecuadamente formalizada.
No se aplica una metodología para el desarrollo del proyecto
Existe documentada una metodología de trabajo.
La metodología abarca todo el proceso del ciclo de vida de los sistemas y contempla los pasos para la adquisición de aplicaciones.
La metodología no abarca todas la etapas del desarrollo de sistemas.No existe una metodología para la adquisición de aplicaciones
Amplitud y alcance de la metodología utilizada.Existencia de una metodología para la adquisición de software.
La metodología es conocida y Cada proyecto aplica su Verificar que etapas
PAGINA 11
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
aplicada por todos los integrantes de los distintos proyectos
propio criterio para el desarrollo de las tareas.
metodológicas iguales son aplicadas de la misma forma en los distintos proyectos.
La metodología es adecuadamente actualizada.
La metodología utilizada no es aplicada porque a quedado desactualizada para resolver los problemas actuales.
Existe un proceso de revisión y actualización periódica de la metodología empleada.
Cuadro 4 - Objetivos de Control y Riesgos Asociados con la Tecnología
TecnologíaObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Se realiza una planificación de los aspectos tecnológicos y es periódicamente revisada
En la organización hay diversas tecnologías en uso que son incompatibles entre sí.La tecnología está desactualizada.No existen planes de actualización de la tecnología.
Existencia de un plan de desarrollo tecnológico y de compatibilidad entre distintos estándares.
Existe una definición de estándares tecnológicos.
La adquisición de tecnología se realiza sin tener en cuenta ningún estándar lo que provoca incompatibilidades.
Los estándares tecnológicos están adecuadamente definidos y formalizados.
Los nuevos proyectos se ajustan a los estándares establecidos.
Los nuevos proyectos establecen sus propios estándares
Los responsables de los nuevos proyectos toman como base los estándares establecidos.
Existe una planificación para la adquisición e implementación de nuevas tecnologías.
No existe pautas para la incorporación de nueva metodología
Existencia de un plan de adquisición de nueva tecnologías.
Impacto del proyecto
El objetivo de medir el impacto que el proyecto tiene es a efectos de determinar los riesgos a
los que se encuentra sometida la organización al incorporar el software en cuestión.
PAGINA 12
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Gráfico 3 – Impacto del Proyecto
El principal riesgo está dado el tamaño del proyecto. Existen diversos factores que nos
permiten establecer el tamaño del proyecto:
Cantidad de áreas involucradas: La existencia de distintas áreas con diversos
intereses que deben ser satisfechos por el sistema.
Niveles organizacionales involucrados: Si el sistema va a ser utilizado por más de
un nivel de la organización deben contemplarse las necesidades de niveles
gerenciales, gerencias medias y el nivel operativo.
Cantidad de Recursos Involucrados: Cantidad de personas que directa o
indirectamente se encuentran vinculadas al proyecto y volumen de la inversión.
El tamaño del proyecto no es el único elemento que es generador de riesgo, pudiéndose
determinar otros aspectos tales como el impacto del proyecto en el negocio, el impacto
funcional y el impacto tecnológico, elementos que combinados con el tamaño pueden
considerarse como elementos potenciadores del riesgo.
Impacto en el negocio
De acuerdo al tipo de aplicación que se adquiere esta puede ser más o menos vital para el
desenvolvimiento del negocio. Es decir que si estamos evaluado la adquisición de un software
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
competence” de la organización, es decir que el sistema a adquirir respeta o potencia los
procesos que hoy le permiten a la organización diferenciarse del resto.
Esto tiene sin duda impacto cuando se audita la fase de Análisis de Necesidades y de
establecimiento de requerimientos ya que sin duda estos procesos deberán estar
adecuadamente explicitados en los requerimientos para que el software que se adquiera los
respete, caso contrario deberán figurar en los requerimientos de customización del mismo.
Gráfico 4 – Impacto en el Negocio
En el gráfico 4 se entrecruza la variable tamaño del proyecto con impacto en el proceso de
negocios. Pudiéndose determinar cuatro situaciones:
Alto impacto en el negocio y Proyecto Amplio – Alto Riesgo: En este caso se trata de un
proyecto de alto impacto en el negocio y de una alta complejidad importante dada su tamaño.
El riesgo esta dado básicamente porque existe la posibilidad de que el proyecto tenga
inconvenientes si no existe una administración y recursos adecuados al tamaño y además
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
riesgo emergente es el peligro de desaparición de la organización o del proyecto de negocios
que se basa en el sistema que se adquiere y la imposibilidad de volver a invertir los recursos
para intentar un nuevo proceso de implementación.
Alto impacto en el negocio y Proyecto reducido – Riesgo Medio: La variante respecto del
caso anterior es que el grado de complejidad o tamaño del proyecto en este caso es reducida lo
cual permitiría por un lado contar con mayores posibilidades de éxito en la administración del
proyecto y en caso de existir inconvenientes es más fácil atacarlos. De todas formas aún
existiendo posibilidades de recuperar la situación el riesgo sigue importante ya que es la
función de negocios la que se ve comprometida.
Bajo Impacto en el negocio y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto de alta complejidad pero que no tiene un impacto alto sobre el negocio. De todas
formas aún tratándose de una situación operativa sabemos que estas tampoco son ajenas al
desarrollo del negocio. En este caso se ha calificado el riesgo como medio debido a que no se
afecta directamente la continuidad del negocio.
Bajo Impacto en el Negocio y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de menor relevancia que no afectará la continuidad del negocio. En este punto el
riesgo esta dado por la mala utilización de los fondos destinados al proyecto.
PAGINA 15
AUDITORIA DE LA ADQUISICIÓN 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
Impacto en el NegocioObjetivo de Control Riesgos Asociados Verificaciones a Realizar
El proyecto se encuentra dentro del marco del plan de negocios de la empresa.
Los sistemas no responden a las necesidades del negocio.
El plan estratégico de sistemas es coordinado con el plan de negocios.
Las especificaciones establecidas contemplan los factores esenciales del negocio.
La habilidades propias del negocio no se encuentran apoyadas por los nuevos sistemas.
En la documentación de los requerimientos se identifican las habilidades principales que distinguen a la empresa.
El sistema tiene la capacidad de adaptarse a nuevas reglas del negocio.
El sistema se muestra inflexible ante nuevos cambios.
Se ha previsto que el o los sistemas sean parametrizables y flexibles para adaptarse a los cambios.
Se ha medido adecuadamente el impacto del proyecto en el negocio
El negocio se ve seriamente cuestionado ante el fracaso del proyecto de sistemas.
Se ha previsto el alcance e impacto del proyecto como así también 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 organización sin mayores problemas.
La medición del impacto funcional esta dada fundamentalmente por:
Cantidad de Sectores Involucrados: A mayor cantidad de sector más difícil su
posterior implementación.
Cantidad de Procesos y Profundidad del Cambio: En este caso se debe sopesar que
porcentaje de procesos se cambian o modifican en el proyecto y a su vez cual es el
grado variación que sufren que puede ir de un cambio menor hasta la desaparición del
proceso.
PAGINA 16
AUDITORIA DE LA ADQUISICIÓN 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 organización debe
analizarse el grado de compatibilidad y la existencia de adecuadas interfaces. El otro
caso es que el nuevo sistema reemplaza a más de un sistema anterior (como es el caso
cuando se instalan sistemas integrados que reemplazan a más de una aplicación) por lo
que se deberán administrar múltiples paralelos con los sistemas anteriores.
Gráfico 5 – Impacto Funcional
Alto impacto Funcional y Proyecto Amplio – Riesgo Alto: En este caso se encuentra en
juego la viabilidad del proyecto en cuanto a la posibilidad real de implementación del mismo
dado que al tratarse de un proyecto de tipo amplio se encontrará a mas de un sector
involucrado y a mucho de los procesos organizacionales.
En este tipo de proyecto además de la propia complejidad de tener que actuar con múltiples
usuarios que tienen múltiples intereses que deberán tenerse en cuenta, se encuentra la
complejidad de implementar un sistema en más de un sector. Para este punto es importante
establecer si el proyecto puede ser implementado por módulos de forma tal de ir
PAGINA 17
AUDITORIA DE LA ADQUISICIÓN 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 problemática se
ve acotada a un sector.
A efectos de establecer el riesgo en este caso lo importante es establecer cuán critico es el
sector que se encuentra involucrado en el proyecto. Si se trata de un sector crítico como
podría ser la automatización de requerimientos de autopartes en una industria automotriz, en
donde una falla en los requerimientos que se hagan a los autopartistas puede afectar los plazos
de entregas de los automóviles y por ende incumplir con las entregas pactadas a los clientes.
En este caso el riesgo está dado fundamentalmente por el grado de adaptación operativa del
sector en cuestión.
Bajo Impacto Funcional y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organización pero que no comprende a un gran número
de procesos.
En este caso el riesgo esta dado fundamentalmente por los inconvenientes que puedan surgir
de la administración de un proyecto que abarca más de un sector.
Bajo Impacto Funcional y Proyecto Reducido – Riesgo Bajo: En este caso se trata de
proyecto de menor tamaño acotado a un sector y que afecta procesos poco relevantes.
Objetivos de Control y Riesgos asociados con el Impacto Funcional
PAGINA 18
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Cuadro 6 – Objetivos de Control y Riesgos Asociados con el Impacto Funcional
Impacto FuncionalObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Todos los sectores involucrados conocen el proyecto y como este los afecta
Los sectores no conocen como el proyecto o nuevo sistema los afectará
Existencia de comunicaciones internas que establezcan el alcance y profundidad del proyecto
Los sectores participan del proyecto.
Los sectores se ven imposibilitados de establecer los requerimientos de información.
Existencia de un foro de discusión o comité de usuarios.Existencia de un registro de requerimientos.
Todos los procesos afectados han sido considerados y se han identificado los procesos que cambian, los que desaparecen y los nuevos procesos
Existen procesos que no son soportados por el sistema.Se siguen realizando procesos que no tienen sentido en un nuevo esquema de trabajo.Se desconocen los nuevos procesos.
Existe un equipo de trabajo que se encarga de la interface entre el proyecto de sistemas y los nuevos procesos.Existe documentación donde se formalizan los nuevos procesos.
Se han respetado las pautas de control interno.
Los cambios de procesos que surgen de la implementación del nuevo sistema han afectado el control interno.
Se ha realizado la revisión de los puntos de control interno.Los nuevos puntos de control interno se encuentran adecuadamente formalizados.
Las relaciones entre sectores y aplicaciones se han establecido correctamente
Existe descoordinación entre áreas y sistemas.
Se han formalizado adecuadamente las interfaces entre sectores y aplicaciones.
Impacto tecnológico
Si el proyecto representa un paso importante en cuanto al tipo de tecnología implica un riesgo
ya que son múltiples los factores que intervienen en una mejora tecnológica y por lo tanto
surgen nuevos riesgos a los que la organización está expuesta.
La medición o graduación del impacto tecnológico esta dado por:
PAGINA 19
AUDITORIA DE LA ADQUISICIÓN 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 administración de los recursos y de aspectos de seguridad son muy
importantes.
Ambiente de Desarrollo: La incorporación de bases de datos relacionales o de ambientes
de trabajo orientados a objetos con entornos visuales, implica nuevas formas de tratar la
información en cuanto a controles que se realizan en la captura y en almacenamiento de
los datos. Si tomamos por ejemplo la incorporación de bases de datos las mismas por un
lado facilitan el desarrollo y modificación de los sistemas pero a su vez tienen su propio
esquema de seguridad de acceso a los datos y permiten el acceso y modificación de los
mismos sin necesidad de contar con una aplicación para hacerlo.
Conocimiento de la Tecnología: Cuando el cambio tecnológico es muy importante es
probable que las personas que hoy se encuentran en la organización no tengan el
conocimiento suficiente para administrar la misma. Si este es el caso en el proyecto deberá
estar considerado el plan de capacitación adecuado para el personal involucrado en
aspectos tecnológicos.
Equipamiento y Licencias: Normalmente los cambios en la tecnología del software
vienen acompañados con nuevos requerimientos en cuanto a velocidad de procesamiento
y de memoria del equipo necesario para correr dicho software. Lo que implica que el
proyecto debe contemplar el análisis de la infraestructura existente y el proceso de
adquisición de nuevo equipamiento. Otro aspecto importante a tener presente cuando se
adquieren sistemas que corren sobre base de datos es si las licencias se encuentran
incluidas en el precio o deben ser adquiridas en forma separada.
PAGINA 20
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Gráfico 6 – Impacto Tecnológico
Alto impacto Tecnológico y Proyecto Amplio – Alto Riesgo: En este caso el problema esta
en la diseminación de la tecnología en muchas áreas de la organización. Si el nivel de retraso
en equipamiento y plataforma de software es importante en muchas áreas de la organización,
el trabajo de actualización será mayor. La tecnología también impacta en la adaptación de los
recursos a un nuevo entorno visual con lo cual la introducción del nuevo sistema también
deberá afrontar esta dificultad.
Alto impacto Tecnológico y Proyecto reducido – Riesgo Moderado: La variante respecto
del caso anterior es que tiene un alto impacto en los aspectos tecnológico pero la
problemática se ve acotada a un sector o proceso especifico. A efectos de establecer el riesgo
en este caso también lo importante es establecer cuán critico es el sector o proceso al que se
encuentra involucrado en el proyecto.
Bajo Impacto Tecnológico y Proyecto Amplio – Riesgo Medio: En este caso se trata de un
proyecto que abarca a gran parte de la organización pero no existen cambios tecnológicos
sustantivos.
PAGINA 21
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
aplicativo que ya esta en uso y en la cual los cambios no son sustantivos.
Objetivos de Control y Riesgos asociados al Impacto Tecnológico
Cuadro 7 – Objetivos de Control y Riesgos Asociados con el Impacto Tecnológico
Impacto TecnológicoObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Existe un plan de infraestructura tecnológica.
La infraesctructura tecnológica crece en forma errática
Existencia de un plan a mediano y largo plazo acerca de la infraestructura tecnológica de la organización.
La infraestructura tecnológica se encuentra adecuadamente actualizada y el personal capacitado en el uso de la misma.
Existen dificultades para correr nuevas aplicaciones debido a que en algunos sectores la tecnología es obsoleta.Existe nueva tecnología pero no se utiliza adecuadamente.
Existencia de un proceso de actualización tecnológica.Existen actividades de capacitación en nuevas tecnologías.
Existe un responsable de evaluar los nuevos requerimientos tecnológicos y la compatibilidad con la infraestructura actual
Los nuevos sistemas son incompatibles con los anteriores.La infraestructura debe ser actualizada sobre la marcha.
Existe un registro de la infraestructura actual.En cada nuevo proyecto se establecen los requerimientos de infraestructura y el grado de compatibilidad.En el proyecto se indican los nuevos requerimientos y el impacto financiero de los mismos.
Revisión del Proceso de Adquisición e Implantación
En esta etapa de la revisión es donde propiamente se verifica el proceso de adquisición del
software. Las revisiones realizadas en los puntos anteriores serán el indicativo de la
PAGINA 22
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 debe ser analizado con mayor profundidad.
Gráfico 7 – Proceso de Adquisición
Para cada una de las etapas de la ejecución del proyecto aquí propuestas se indicará objetivo
de la etapa, principales actividades involucradas y el producto final de la
etapa. Además se propone una lista con los objetivos de control, los riesgos y las revisiones a
realizar.
Revisión del Requerimiento
Ya sea para la construcción o para la adquisición de un sistema de información es
fundamental la etapa de Relevamiento de las necesidades de los futuros usuarios del sistema a
efectos que el mismo cubra las mismas.
En esta etapa se establece el contacto con las necesidades que posee la organización. En esta
etapa se utilizan diversas herramientas como son: encuestas, entrevistas, obtención de
documentación, mapeo de procesos, etc. .
Producto de esta etapa debe surgir un documento denominado Requerimientos del Sistema
PAGINA 23
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
donde se determina: Identificación de la situación actual, identificación de los actuales
recursos tecnológicos, necesidades de proceso y de información a ser satisfechas por el
sistema, controles que deben estar presentes en el sistema, grado de flexibilidad y
parametrización exigidos.
Objetivos de Control y Riesgo de la Etapa de Revisión de los Requerimientos
Cuadro 8 – Objetivos de Control y Riesgos – Etapa Revisión del Requerimiento
Revisión de los requerimientosObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Se han establecido en forma clara todos los requerimientos de todos los usuarios.
El sistema no contempla todas las necesidades de los sectores usuarios.Algunos aspectos funcionales no se encuentran soportados.Las necesidades de información de los niveles directivos no se encuentran totalmente cubiertas.El sistema no contempla aspectos de control interno.El sistema no contempla aspectos legales o normativos propios de la actividad de la organización.
Existe un documento adonde se establecen cuales son los usuarios que representan a cada sector.Existe un documento donde se establece como se realizará el contacto con los áreas usuarias.Se ha analizado el sistema actual y se han identificado las fortalezas y debilidades del mismo.Existe un documento donde se establecen los requerimientos funcionales de control, legales y de información.Dicho documento fue aceptado por las áreas intervinientes.
Se han identificado adecuadamente las interfaces con otros sistemas de la organización.
El sistema no puede integrarse con los sistemas existentes.
Se han analizado las interfaces con otros sistemas.Existe un documento donde se establecen las interfaces con otros sistemas.
Se ha identificado la capacidad tecnológica actual de la empresa y las necesidades que plantea el nuevo sistema.
No se tiene la infraestructura tecnológica adecuada para implementar el nuevo sistema
Existe un documento donde se han establecido razonablemente las necesidades de infraestructura tecnológica que plantea el nuevo
PAGINA 24
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
sistema.Se han identificado posibles soluciones que establece el mercado y que podrían llegar a satisfacer los requerimientos.
Existen soluciones en el mercado que no se han tenido en cuenta.
Documento donde se informan posibles alternativas de solución.
Revisión del Diseño del requerimiento
Esta etapa es fundamental porque de la misma debe surgir el documento de requerimientos
que será el documento base para que los proveedores realicen sus ofertas. Por lo tanto en el
mismo deben figurar los aspectos funcionales, de información, de control y legales.
En esta etapa también se establecerá como se realizará el proceso de adquisición, las etapas
contractuales y la lista de proveedores a ser invitados en el proceso de licitación.
Objetivos de Control y Riesgos del Proceso de Revisión del Diseño del Requerimiento
Cuadro 9 – Objetivos de Control y Riesgos Asociados con Diseño del Requerimiento
Revisión del Diseño del RequerimientoObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Se ha realizado un modelo del sistema que incluye el modelo de procesos y de datos.
El modelo de procesos y datos no es lo suficientemente claro o no representa fielmente los requerimientos.En la construcción del modelo de procesos y de datos no se han tenido en cuenta los requerimientos oportunamente relevados.
Existe un modelo de procesos y de datos.El modelo fue construido teniendo en cuenta los requerimentos de los usuarios.
El modelo fue construido respetando las técnicas de modelado.
El modelo no respeta ningún tipo de convención o técnica.Problemas de interpretación de las especificaciones.
Existe un modelo y el mismo respeta las técnicas establecidas.
En el modelo se han El sistema no contempla Existe un documento donde
PAGINA 25
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
identificados todas los aspectos de control interno.
aspectos de seguridad lógica ni física.
se establecen los requerimentos de control interno
El grado de flexibilidad o de parametrización del sistema permite nuevas operaciones
El sistema no admite cambios o nuevas operaciones.
Se ha definido el grado de flexibilidad del sistema.
Se han establecido las interfaces con otros sistemas y son contempladas en el modelo del sistema y en la estructura de datos
El modelo no contempla las interfaces con otros sistemas.
Verificar la existencia de interfaces con otros sistemas y si las mismas han sido contempladas.
Se ha definido como debe ser la administración de la seguridad física y lógica.
El sistema no adquirido no contempla las pautas mínimas de seguridad.
Verificar especificaciones de seguridad física y lógica.
Se ha indicado el nivel de respuesta requerido por el sistema en transacciones por minuto o en alguna otra métrica que se considere apropiada.
El sistema no responde ante los volúmenes de transacciones que debe administrar.
Los lotes de prueba han contemplado los respectivos requerimientos de esfuerzo.
Revisión del proceso de Selección de la Solución
Una vez determinado los requerimientos técnicos y legales del punto anterior, a los que
denominaremos pliegos, se continua con la etapa de selección de la solución que se ajuste a
los requerimientos.
Esta etapa cubre desde la invitación a cotizar ( o licitación, esto depende de la mecánica
seleccionada) a los proveedores hasta la determinación de la solución seleccionada.
Objetivos de control y riesgos del Proceso de Selección de la Solución
Cuadro 10 – Objetivos de Control y Riesgos Asociados con la Selección de la Solución
Revisión del proceso de selección de la SoluciónObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Se ha realizado una investigación previa de productos existentes en el mercado y se ha confeccionado una lista de posibles proveedores.
Los proveedores y/o productos que se ofrecen no cumplen con los requisitos mínimos establecidos.
Una vez definidas las necesidades se confeccionó una lista de proveedores que podrían cumplir con el requerimiento realizado.
PAGINA 26
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
La documentación que se entrega al proveedor es la adecuada.
La documentación no contempla aspectos importantes del sistema.
Existe el o los documentos donde se establecen los requerimientos y los mismos son adecuados para el fin.
Todos los proveedores seleccionados tienen la capacidad para llevar el proyecto adelante.
El proveedor seleccionado tiene problemas financieros y de personal que repercuten en el proyecto.El proveedor es nuevo en este tipo de productos y tiene dificultades para cumplir con las entregas pactadas.
En el análisis de los proveedores se tuvieron en cuenta aspectos relevantes de los proveedores como antecedentes, cartera de clientes, plataforma instalada, productos, etc.
Los elementos o pautas de selección fueron establecidos de antemano y aseguran que el producto cumpla con los requerimientos.
El sistema no tiene una adecuada interfaz.La perfomance no es la adecuada.El plan de capacitación no es adecuado.No se contemplan aspectos funcionales y de control que son importantes para la organización.
Los criterios de evaluación fueron previamente definidos y el documento de evaluación debe asegurar que se cumplan los principales aspectos establecidos en el requerimiento.
El contrato fue realizado teniendo en cuenta las etapas establecidas y los productos de cada etapa están claramente especificados como así también las responsabilidades de cada parte.
El proveedor no cumple con lo pautado porque el contrato es ambiguo en algunos aspectos.
El contrato debe asegurar que se cumpla con lo establecido en los requerimientos.
Revisión de la Etapa de Instalación y CustomizaciónEn esta etapa se realiza la instalación y configuración del sistema para que se adapte a las
características de la empresa. Este servicio puede o no estar incluido en el servicio prestado
por el proveedor. En caso que no lo realice el proveedor directamente el mismo al menos
deberá dar el soporte y capacitación para que esta etapa pueda ser llevada adelante por el
personal de la empresa.
Si los parámetros no son adecuadamente definidos pueden surgir problemas durante las
pruebas o lo que es más grave puede ser que surjan cuando el sistema ya este en marcha.
PAGINA 27
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Objetivos de control y riesgos de la etapa de Instalación Customización del ProductoCuadro 11 – Objetivos de Control y Riesgos Asociados con la Customización
Revisión del Proceso de Instalación y Customización del ProductoObjetivo de Control Riesgos Asociados Verificaciones a Realizar
La instalación del Hardaware necesario se cumplimentó en tiempo y forma.
Existen demoras en la implementación debido a que el hardaware no está disponible en tiempo y forma establecidos.
Se ha establecido un plan de instalación del hardware acorde con los tiempos establecidos para el proyecto.
La instalación de software de base se cumplimento en tiempo y forma
Existe demoras en la instalación debido a que no se ha realizado la instalación del software de base o el mismo está mal instalado.
Se ha establecido un plan de instalación del software de base y se han contemplado los requerimientos establecidos por el proveedor.
Todos los parámetros de funcionamiento se encuentran adecuadamente definidos.
Existen parámetros no definidos que provocan el mal funcionamiento del sistema.La definición de los parámetros no es la adecuada y provoca el malfuncionamiento del sistema.
Los parámetros han sido adecuadamente establecidos y los usuarios participan en su definición.Se ha realizado la capacitación suficiente para la adecuada definición de los parámetros.
Revisión de la Etapa de Prueba y Paralelo
En esta etapa que comienza luego de la capacitación del personal y de realizado el proceso de
capacitación. El objetivo de la misma es probar los aspectos funcionales y de performance del
sistema y realizar el paralelo entre el sistema anterior y el nuevo sistema:
Etapa de Prueba: Esta etapa es fundamental para la posterior aceptación del
producto y es cuando se verifica que se cumple con lo indicado en la
especificación del requerimiento. Las principales actividades de esta etapa son:
Armado de lotes de prueba, ejecución de las pruebas, verificación del
cumplimiento de los requerimientos, simulación de cierres o procesos críticos del
sistema, pruebas de performance del hardware, pruebas de las interfaces con otros
PAGINA 28
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
sitemas, pruebas de aspectos de seguridad física y lógica, incorporación o
Migración de datos del sistema anterior
Etapa de Paralelo: En esta etapa se encuentra en funcionamiento el nuevo sistema
y el sistema o sistemas anteriores (puede ser que el nuevo sistema reemplace a más
de un sistema) por lo que implica duplicación de muchas tareas y una mayor
actividad de control para determinar las diferencias entre uno y otro sistema.
Objetivos de control y riesgos de la etapa de prueba y paralelo
Cuadro 12 – Objetivos de Control y Riesgos Asociados con la Etapa de Prueba y
Paralelo.
Revisión del Proceso de Prueba y ParaleloObjetivo de Control Riesgos Asociados Verificaciones a Realizar
Las pruebas contemplan los requerimientos o prestaciones requeridas.
Las pruebas no cubren los requerimientos indicados en las especificaciones.
Existe un plan de pruebas y esta compatibilizado con los requerimientos.
Las pruebas son suficientes y contemplan casos complejos
Existen casos no cubiertos por las pruebas que luego provocan errores en el sistema.
Revisión de los lotes de pruebas y verificación de que los usuarios han intervenido en la definición de los mismos.
Las pruebas contemplan los especificaciones de rendimiento establecidas en el requerimiento.
No se han realizado pruebas de situaciones extremas.
Las pruebas contemplan situaciones extremas tales como alto volumen de transacciones.
En las pruebas se ha revisado el Plan de Seguridad de la Empresa.
No se han realizado pruebas de situaciones especiales.El sistema es vulnerable a ataques.
Las pruebas deben contemplar situaciones tales como cortes de luz, recuperación de backups.Las pruebas deben incluir un test de penetración a los sistemas a efectos de verificar la seguridad lógica.
El proceso de conversión de datos de un sistema a otro se ha realizado satisfactoriamente.
Los datos registrados del sistema anterior no pueden ser utilizados.La información recuperada del sistema anterior no es confiable.
Existe un plan conversión de datos.Se ha realizado un adecuado estudio de las estructuras de datos del sistema anterior y del nuevo estableciéndose
PAGINA 29
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
Existen errores en la conversión de los datos.
las respectivas equivalencias.Se han probado los programas conversores.Se han revisado la información del sistema anterior a nivel de totales y de un muestreo de datos individuales que asegure la confiabilidad de los datos.
El paralelo se ha realizado satisfactoriamente y las diferencias han sido aclaradas adecuadamente.
No se ha realizado paralelo de algunas operaciones o servicios.
Existe una planificación del paralelo con el sistema anterior y esa planificación asegura que todas las prestaciones sean verificadas y de esa forma se asegure el adecuado funcionamiento posterior.El paralelo contempla situaciones o procesos especiales como los cierres de mes o de ejercicio.
No se han detectado 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
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 prolonga por demasiado tiempo.No existe una fecha de fin del paralelo.Existe resistencia a abandonar el paralelo.El paralelo es abandonado aún existiendo diferencias no identificadas.
El paralelo se realiza dentro de los plazos establecidos en la planificación.Al momento de abandonar el paralelo existe expresa conformidad de los usuarios y todas las diferencias han sido aclaradas y corregidas.
Revisión del Proceso de Entrega y Aceptación del Sistema
Una vez realizada la etapa de prueba y paralelo y de pasado un tiempo prudencial se procede a
PAGINA 30
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
la aceptación del producto y a la culminación de la etapa de puesta en marcha del sistema. A
esta altura del proyecto se considera que el sistema se ha estabilizado y se encuentra en
régimen normal.
Objetivos de Control y Riesgos de la Etapa de Entrega y Aceptación del Sistema
Cuadro 13 – Objetivos de Control y Riesgos Asociados con el Impacto en el Negocio
Revisión de la Entrega y Aceptación del Sistema.Objetivo de Control Riesgos Asociados Verificaciones a Realizar
Las pruebas y paralelo del sistema han culminado satisfactoriamente.
El sistema es entregado sin haberse culminado con la etapa de prueba y paralelo.
Se ha realizado la finalización de las etapas de pruebas y paralelo con la aceptación de los usuarios.
Se han cerrado todos los incidentes originados en errores de programa o por diferencias detectadas en el paralelo
El sistema se han entregado con errores o diferencias pendientes de resolución.
Se ha realizado la conclusión de todos los incidentes por errores o diferencias.
No existen modificaciones o adaptaciones pendientes a la fecha de entrega.
El sistema es entregado aún faltando la incorporación de algunas mejoras
Se ha verificado que no existen modificaciones pendientes.
Existe un documento de aceptación final.
El sistema no es formalmente aceptado.
Se debe verificar la existencia de un documento donde los usuarios dan la conformidad final del producto. Si el sistema se aceptara con problemas pendientes de resolución estos deben estar indicados como así también el plazo de resolución de los mismos.
Revisión de la Etapa de Mantenimiento
El mantenimiento es el servicio adicional que presta el proveedor una vez que el sistema se
encuentra en régimen. Es fundamental que en el contrato se haya especificado
PAGINA 31
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
adecuadamente que se entiende por mantenimiento y soporte del sistema cuando este es
incluido en el precio del servicio.
Objetivos de Control y Riesgos de la Etapa de Mantenimiento
Cuadro 14 – Objetivos de Control y Riesgos Asociados con la Etapa de Mantenimiento
Revisión de la etapa de Mantenimiento.Objetivo de Control Riesgos Asociados Verificaciones a Realizar
El soporte brindado por el proveedor es el adecuado.
Cuando se presentan dudas sobre el sistema no hay a quien recurrir.
El proveedor tiene previsto un adecuado servicio de soporte al usuario y resuelve los incidentes en un tiempo prudencia.
El proveedor cumple en tiempo y forma con la corrección de errores.
Existen errores que nunca son subsanados.
El proveedor brinda un servicio permanente de actualización y corrección de errores.
El sistema es actualizado periódicamente o ante nuevos requerimientos legales o impositivos.
El proveedor no realiza actualizaciones periódicas del sistema con lo cual el mismo queda desactualizado ante cambios normativos e impositivos.El proveedor no presta más el servicio.
Verificar que los cambios normativos e impositivos son actualizados en el sistema por el proveedor.
Las nuevas versiones son actualizadas sin problemas y los usuarios son capacitados adecuadamente.
Existe problemas en las conversiones de datos.No hay documentación sobre las mejoras.Los usuarios no aprovechan adecuadamente las nuevas prestaciones.
Las conversiones de versiones son realizadas por personal especializado y previamente realizadas en un ambiente de prueba.El proveedor incluye la actualización de los respectivos manuales de usuarios.Se debe verificar si los cambios en la nueva versión afectan los procesos y controles actuales.Se debe verificar que el proveedor cuente con un programa de capacitación y actualización.
PAGINA 32
AUDITORIA DE LA ADQUISICIÓN DE SOFTWARE
ConclusiónEn el presente trabajo intenta alertar sobre las distintas implicancias que tiene la incorporación
de tecnología informática en el ámbito de una organización y por lo tanto que aspectos
mínimos se deberían tener presente al evaluar un proceso de adquisición de software.
En ese sentido se remarca la necesidad no solo de evaluar a la adquisición como un proceso
puntual, sino que se debería tomar en un sentido más amplio. Es así que se incorpora la
evaluación de lo que se denominó el Ambiente del Proyecto y también el impacto que dicho
proyecto tiene en la organización en lo que hace al Negocio en sí mismo y también en lo
relativo a aspectos Funcionales y aspectos Tecnológicos.
De esta forma el auditor tendrá una visión mas amplia de los riesgos asociados y podrá
formular un plan de trabajo que agregue valor al proceso de adquisición del software y que le
permitan a la organización alcanzar satisfactoriamente el objetivo propuesto al realizar este
tipo de inversiones.
Bibliografía Consultada IFAC - International Standard on Auditing 401 – Auditing in a computer information
systems environment. Año 2004.
ISACA - Cobit 3ra. Edición – Objetivos de Control para la Información y Tecnologías
Relacionadas – Año 2003.
Federación Argentina de Consejos Profesionales de Ciencias Económicas – CECYT -
Informe 6 - Pautas para el Examen de Estados Contables en un Contexto
Computadorizado.
Laudon y Laudon – Sistemas de Información Gerencial – Capitulo 11 – Rediseño de la
Organización mediante Sistemas de Información – Sexta Edición Año 2002 - Página 341
Matías Fernández Díaz – Adquisición de Recursos de Tecnología Informática – Revista
Sindicatura – Abril 1998 – Página 97.
PAGINA 33