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


REVISIÓN DEL DISEÑO DEL REQUERIMIENTO 25

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

REQUERIMIENTO 25

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

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

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

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

PRODUCTO 28

REVISIÓN DE LA ETAPA DE PRUEBA Y PARALELO 28

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

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

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

SISTEMA 31

REVISIÓN DE LA ETAPA DE MANTENIMIENTO 31

OBJETIVOS DE CONTROL Y RIESGOS DE LA ETAPA DE MANTENIMIENTO 32

CONCLUSIÓN 33

Bibliografía Consultada 33

PAGINA 2


Introducción

Cada vez son mas las organizaciones que se ven sometidas a la tarea de seleccionar el

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

recurso estratégico indispensable para las organizaciones, muchas de las cuales verían

inviable su negocio sin este recurso.

Esta suerte de vinculo entre sistemas y negocios también a provocado que los tiempos de

respuesta que se le exigen a la gente de sistemas para la producción y/o adaptación de los

sistemas sean cada vez menores debido fundamentalmente a la dinámica que el mercado le

imprime a los negocios.

A esto se debe sumar que muchas empresas a tomado la decisión de disminuir de manera

sensible los servicios propios de sistemas y han optado por tercerizar el desarrollo de sus

aplicaciones y el resto de las funciones asociadas al mismo.

Otro elemento que gravita en la decisión de las empresas para optar por la adquisición de

desarrollos realizados por terceros es no volver a inventar la rueda tomando los sistemas que

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

el mercado no provee.

Si bien lo expresado en los párrafos anteriores de por sí justifica la intervención del Auditor

en la selección del software, se pueden enumerar otros motivos por los que se justifica la

auditoria del proceso de adquisición del software:

PAGINA 3


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

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

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

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

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

funcionamiento de los controles de este proceso. Los datos del Government Accounting

Office Report (EEUU) muestran este hecho:

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

Un 3,0 % se usó después de algunos cambios

Un 19,5 % se usó y luego se abandono o se rehizo

Un 47 % se entregó pero nunca se usó

Un 29 % se pagó pero nunca se entregó

Rol esperado del auditor

Si bien no es el objetivo de este trabajo establecer cual debe ser el rol del auditor en cuanto al

grado de participación en este tipo de procesos, podemos decir que las posibilidades son las

siguientes:

Analizar el proceso una vez que el mismo aconteció y establecer los desvíos o problemas

que encuentren. Este enfoque se asimilaría a cualquier otra revisión de las adquisiciones

que realiza la organización.

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

pero además emitiendo opinión sobre el software que se debe adquirir desde el punto de

vista de la calidad del control interno y de los posibles inconvenientes que se pueden

presentar. Esto implica también asesorar en el proceso de selección indicando los controles

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

materia de seguridad y controles, etc., pero sin emitir una opinión o recomendación

PAGINA 4


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

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

justificar en el hecho de que el auditor luego deberá realizar la revisión de los controles

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

tanto es preferible que actúe de manera proactiva, es decir antes de encontrarse con un

hecho ya consumado.

Enfoques para encarar la auditoría del proceso de adquisición

Más allá del rol que le toque jugar al auditor, la propuesta de revisión que aquí se realiza tiene

diversas formas de ser abordada de acuerdo al trabajo que se le encomiende al auditor. Esto

es:

-Evaluar el proceso de adquisición: Es decir determinar si la adquisición del software fue

realizada de acuerdo a prácticas razonables para este tipo de procedimiento. Es decir tomar el

proceso como un elemento aislado y puntual.

-Evaluar el proyecto en forma integral: Aquí la revisión incluye aspectos relacionados con

el gerenciamiento y calidad del proyecto. El proceso de adquisición se considera una etapa

dentro de la evaluación del proyecto.

-Evaluar el impacto del software adquirido en relación al negocio: En este caso, además

de los aspectos enunciados anteriormente se incluye el análisis del ambiente del proyecto es

decir que se evalúan otros aspectos tales como la existencia de un plan de sistemas, nivel de

integración de dicho plan con el plan estratégico de negocios, organización del área de

sistemas, etc.

En este trabajo se propone el último de estos enfoques a efectos de dar un tratamiento amplio

PAGINA 5


a la problemática propuesta, en el entendimiento de que luego cada profesional podrá limitar

la aplicación de esta propuesta de acuerdo a la realidad que lo rodea y de los recursos de los

que dispone.

Etapas de la revisión del proceso de adquisición del Software

Tomando la propuesta más amplia, se proponen las siguientes etapas de revisión:

Gráfico 1 – Etapas de la Revisión

Revisión del Proyecto: La existencia de un proyecto adecuadamente administrado y

en el cual se trabaja con una metodología preestablecida permite presumir que el

proceso de adquisición de software se realiza en un ambiente planificación y mayor

control.

Proceso de Adquisición: Es la adquisición en si misma que abarcar desde el proceso

de establecimiento de requerimientos hasta la adquisición.

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

sistema cumple con lo establecido y que el servicio de mantenimiento y soporte

pactado con el proveedor se cumple satisfactoriamente.

Revisión del Proyecto

PAGINA 6


Como se han mencionado en el punto anterior el objetivo es revisar aspectos que permiten

establecer la eficiencia y eficacia del proyecto encarado. Para esto se ha divido la revisión en

dos aspectos:

Ambiente del Proyecto: Por ambiente del proyecto se entiende a todos aquellos

aspectos, que si bien no se encuentran directamente vinculados, influyen sobre el

mismo y permiten tener un primer grado de aproximación a cerca de la calidad del

proyecto. Dentro de estos encontramos la posibilidad de verificar la existencia de un

plan estratégico de sistemas, la forma en que el proyecto es administrado, la

metodología utilizada y el nivel tecnológico de la organización.

Impacto del Proyecto: El objetivo de medir el impacto del proyecto es para

determinar los riesgos a los que se encuentra sometida la organización al incorporar el

software en cuestión. Es así que se debe revisar lo relacionado con el impacto sobre el

esquema de negocios, el impacto que implicaría un cambio tecnológico y el impacto

que un nuevo sistema tendría sobre aspectos funcionales, es decir sobre los procesos

que se realizan en la organización.

Ambiente del Proyecto

El ambiente del proyecto esta conformado por diversos aspectos, la inexistencia total o parcial

de estos elementos no implica que debamos inferir que el proyecto adolece de graves

falencias. Significa que deberemos realizar una revisión mas intensiva de algunos puntos.

Digamos entonces que en esta etapa de la revisión se trata de establecer si los puntos de apoyo

del proyecto son los adecuados para que el mismo pueda llegar a un buen fin.

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

PAGINA 7


Gráfico 2 – Aspectos del Ambiente

Plan estratégico de Sistemas: La existencia de una planificación del recurso informático y el

grado de integración del mismo con el Plan Estratégico de Negocio nos permite establecer el

grado de importancia que la organización le da a sus sistemas y además que las acciones son

realizadas de acuerdo a una planificación previa evitando de esta forma que el accionar solo

obedezca a impulsos que nada tienen que ver con criterios básicos de administración.

Administración del proyecto: Deben existir adecuadas pautas para el manejo de proyectos

como son: la determinación de un líder de proyecto, la asignación calidad de los recursos

humanos involucrados, la existencia de herramientas para el seguimiento de los proyectos y la

existencia de informes periódicos de avance del mismo.

Metodología: La existencia de una metodología permite establecer la existencia de pasos

predeterminados que deben ser seguidos por los distintos proyectos como una forma de

asegurar la calidad de los mismos.

Tecnología: El nivel tecnológico alcanzado por los aplicativos que integran la cartera de

aplicaciones es un elemento de vital importancia para determinar si la nueva aplicación a ser

incorporada representa un salto cualitativo que la organización puede asimilar sin mayores

PAGINA 8


dificultades. En este sentido es fundamental verificar la existencia de una planificación de la

incorporación de los recursos tecnológicos, esto permite inferir que cada “salto” tecnológico

es medido adecuadamente a efectos de determinar su impacto en la organización.

En el próximo punto se establecen los objetivos de control, riesgos asociados y revisiones

mínimas a realizar para verificar el ambiente del proyecto. Es importante aclarar que se habla

de revisiones mínimas ya que no es el objetivo del trabajo auditar cada uno de los elementos

del ambiente ya que esto requerirá de un esfuerzo (tiempo y recursos) específicamente

orientado al análisis de cada uno de ellos.

Mas bien se intenta que el auditor pueda delimitar más claramente las responsabilidades al

momento de emitir su opinión. Esto quiere decir que si desde el nivel directivo no existe una

preocupación e involucramiento en tipo de proyectos ó nunca existió una directiva al respecto

son también responsables por los resultados que se obtengan.

Objetivos de Control y Riesgos del Ambiente

Cuadro 1 - Objetivos de control Relacionados con Plan Estratégico de Sistemas

Plan Estratégico de 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


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


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


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


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


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


porque se trata de un proyecto fundamental para el desarrollo del negocio. En este caso el

riesgo emergente es el peligro de desaparición de la organización o del proyecto de negocios

que se basa en el sistema que se adquiere y la imposibilidad de volver a invertir los recursos

para intentar un nuevo proceso de implementación.

Alto impacto en el negocio y Proyecto reducido – Riesgo Medio: La variante respecto del

caso anterior es que el grado de complejidad o tamaño del proyecto en este caso es reducida lo

cual permitiría por un lado contar con mayores posibilidades de éxito en la administración del

proyecto y en caso de existir inconvenientes es más fácil atacarlos. De todas formas aún

existiendo posibilidades de recuperar la situación el riesgo sigue importante ya que es la

función de negocios la que se ve comprometida.

Bajo Impacto en el negocio y Proyecto Amplio – Riesgo Medio: En este caso se trata de un

proyecto de alta complejidad pero que no tiene un impacto alto sobre el negocio. De todas

formas aún tratándose de una situación operativa sabemos que estas tampoco son ajenas al

desarrollo del negocio. En este caso se ha calificado el riesgo como medio debido a que no se

afecta directamente la continuidad del negocio.

Bajo Impacto en el Negocio y Proyecto Reducido – Riesgo Bajo: En este caso se trata de

proyecto de menor relevancia que no afectará la continuidad del negocio. En este punto el

riesgo esta dado por la mala utilización de los fondos destinados al proyecto.

PAGINA 15


Objetivos de Control y Riesgos asociados con el Impacto en el Negocio

Cuadro 5 – Objetivos de Control y Riesgos Asociados con el Impacto en el Negocio

Impacto en el 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


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


implementando el sistema en forma gradual.

Alto impacto Funcional y Proyecto reducido – Riesgo Moderado: La variante respecto del

caso anterior es que tiene un alto impacto en los aspectos funcionales pero la problemática se

ve acotada a un sector.

A efectos de establecer el riesgo en este caso lo importante es establecer cuán critico es el

sector que se encuentra involucrado en el proyecto. Si se trata de un sector crítico como

podría ser la automatización de requerimientos de autopartes en una industria automotriz, en

donde una falla en los requerimientos que se hagan a los autopartistas puede afectar los plazos

de entregas de los automóviles y por ende incumplir con las entregas pactadas a los clientes.

En este caso el riesgo está dado fundamentalmente por el grado de adaptación operativa del

sector en cuestión.

Bajo Impacto Funcional y Proyecto Amplio – Riesgo Medio: En este caso se trata de un

proyecto que abarca a gran parte de la organización pero que no comprende a un gran número

de procesos.

En este caso el riesgo esta dado fundamentalmente por los inconvenientes que puedan surgir

de la administración de un proyecto que abarca más de un sector.

Bajo Impacto Funcional y Proyecto Reducido – Riesgo Bajo: En este caso se trata de

proyecto de menor tamaño acotado a un sector y que afecta procesos poco relevantes.

Objetivos de Control y Riesgos asociados con el Impacto Funcional

PAGINA 18


Cuadro 6 – Objetivos de Control y Riesgos Asociados con el Impacto Funcional

Impacto 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


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


Gráfico 6 – Impacto Tecnológico

Alto impacto Tecnológico y Proyecto Amplio – Alto Riesgo: En este caso el problema esta

en la diseminación de la tecnología en muchas áreas de la organización. Si el nivel de retraso

en equipamiento y plataforma de software es importante en muchas áreas de la organización,

el trabajo de actualización será mayor. La tecnología también impacta en la adaptación de los

recursos a un nuevo entorno visual con lo cual la introducción del nuevo sistema también

deberá afrontar esta dificultad.

Alto impacto Tecnológico y Proyecto reducido – Riesgo Moderado: La variante respecto

del caso anterior es que tiene un alto impacto en los aspectos tecnológico pero la

problemática se ve acotada a un sector o proceso especifico. A efectos de establecer el riesgo

en este caso también lo importante es establecer cuán critico es el sector o proceso al que se

encuentra involucrado en el proyecto.

Bajo Impacto Tecnológico y Proyecto Amplio – Riesgo Medio: En este caso se trata de un

proyecto que abarca a gran parte de la organización pero no existen cambios tecnológicos

sustantivos.

PAGINA 21


Bajo Impacto Tecnológico y Proyecto Reducido – Riesgo Bajo: En este caso se trata de

proyecto de que no implica un cambio tecnológico sustancial y que no impacta sobre gran

parte de la organización. Este seria el caso de una actualización a una nueva versión del

aplicativo que ya esta en uso y en la cual los cambios no son sustantivos.

Objetivos de Control y Riesgos asociados al Impacto Tecnológico

Cuadro 7 – Objetivos de Control y Riesgos Asociados con el Impacto Tecnológico

Impacto Tecnoló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


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


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


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


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


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


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


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


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


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


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


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

Documents

Auditoria de La Adquisición de Software