auditoria computacional o informatizada

CAPÍTULO 51

La auditoría computacional O informatizadaGERARDO GÁLVEZ MENESES

Ingeniero comercial Universidad de Chile

Introducción /51-1186 Conceptos previos / 51-1186 Lá información /51-1186 La organización / 51-1187

La auditoría computarizada /51- 1187 Definición / 51-1187Justificación /51-1188

Funciones de la auditoría computarizada /51-1189 Perfil del auditor computarizado /51-1190

Metodología de la auditoría computarizada Definición de ámbitos y objetivos / 51-1191 Estudio inicial / 51-1192Determinación de perfiles / 51-1192 Elaboración de planes / 51-1193 Elaboración de programas /51-1193 Realización de las actividades /51-1193 Elaboración del informe final / 51-1194

/51-1191

Reglas básicas en la realización de una auditoría /51-1194

Técnicas y herramientas usadas en auditoría computarizada Simuladores /51-1195Paquetes de auditoría / 51-1195Monitores /51-1196Matrices de riesgos / 51-1196

/51-1195

1185

Auditoría computacional o informatizada

Introducción

Conceptos previos

La computación aparece inicialmente en la empresa como solución a problemas específicos de tipo operacional (gestión de stocks, facturación, etc.), permitiendo el tratamiento repetitivo de grandes masas de datos. A medida que se generaliza su uso debido, sobre todo, a la bajada en los costes de los computadores, su uso se extiende a toda la empresa. Paralelamente se produce un aumento de los costes de personal.

Dentro de una empresa dada, un departamento de computación posee, en principio, dos funciones claramente definidas: desarrollo de sistemas computarizados y explotación de sistemas computarizados. Las actividades llevadas a cabo por la función de desarrollo se refieren fundamentalmente a estudios de viabilidad, diseño y realización de sistemas computarizados, así como a su implantación en forma de software para unas máquinas determinadas.

Las de explotación, por su parte, tienen que ver con la ejecución de los trabajos precisos para obtener la información que se proporciona:.;á a los usuarios, a partir de los sistemas desarrollados, además de la custodia de información, equipos e instalaciones. Al departamento de computación se le deben fijar objetivos claros y mensurable s en cuanto a calidad, capacidad, velocidad y economía.- Una de las tareas del auditor computacional es lograr que se pase de una función computarizada abstracta, como muchas veces ocurre en la actualidad, a otra en que los criterios fundamentales que se le exijan sean los asociados a la rentabílidad, asumiendo la calidad como uno de ellos.

Existen áreas de actuación de importancia para el auditor computacional, que se derivan de las carar:;terísticas deseables de la función computacional y de las cuales el auditor deberá verificar su existencia, entre ellas, la seguridad física y la prevención, así como la detección y corrección de errores y fraudes.

La información

La información se ha convertido en un factor de suma importancia para el éxito de cualquier negocio. Ésta puede provenir del exterior de la empresa (clientela, gobierno, sociedad, competencia), o bien gestarse internamente.

Por otra parte, existen flujos de información formalizados, a través de normas o procedimientos propios del negocio, y flujos de información no formalizados.

El sistema computarizado es un subconjunto del flujo formalizado, que se muestra en diferen te grado según el nivel de estructura de la empresa de la que se trate. Así pues, en el aspecto operacional es normal encontrar un alto grado de computarización en las empresas, mientras que en cuanto a tácticas y, sobre todo, a estrategias, el grado es bastante menor.

1. El nivel gerencial (estratégico) es el encargado de determinar los objetivos, políticas y misiones. Emplea información más elaborada como pueden ser las tendencias de la empresa, márgenes, rentabilidad por productos o departamentos. En general, maneja modelos o funciones de los' datos y se caracteriza por trabajar con pequeños volúmenes de información, pocos datos muy elaborados, realizar tratamientos de cálculos muy complejos y procesos imprevisibles, llevar a cabo pocas consultas, operaciones y actualizaciones, que suponen, a veces, la realización de un gran número de tratamientos de la información. El tiempo de respuesta en muchos casos es tan sólo de horas o minutos.

2. El nivel ejecutivo (táctico) traduce en tácticas los objetivos, políticas y misiones que le han sido fijados por el nivel gerencial; es decir, dispone adecuadamente de los recursos para alcanzar los objetivos, y cumple las misiones que corresponden a las políticas fijadas. Emplea infor

1186

La auditoría computacional o informatizada

mación elaborada; normalmente no le interesa el saldo de una cuenta, sino el saldo medio de las cuentas de un colectivo determinado.

3. El nivel operacional ejecuta las órdenes que le ha entregado el nivel ejecutivo. Maneja información elemental, no integrada, como puede ser el saldo de una cuenta para comprobar si puede aceptarse el pago de un cheque. Se caracteriza, en general, por manejar un elevado volumen de datos elementales, por realizar tratamientos de procesos simples, previsibles y rutinarios, llevar a cabo un elevado número de consultas y actualizaciones en un tiempo rápido de respuesta, y contar con extensos archivos.

El sistema de información general de la empresa debe estar configurado de forma tal que pro-porcione a cada nivel (gerencial, ejecutivo y operacional), información oportuna y exacta, a tiempo, fiable, necesaria y suficiente.

La organización

Existe una estrecha relación entre organización y computación que conviene aclarar, ya que en muchos casos da lugar a confusiones. Tal vez se deban en parte a la similitud de objetivos de ambas funciones, que sólo se diferencian en el campo de aplicación y en las distintas técnicas y métodos utilizados, de ahí que no sea siempre fácil delimitar el campo de acción y responsabilidades de cada una de ellas en una empresa, lo que puede ocasionar problemas de solapamiento e interferencia, así como de áreas sin cubrir. El objetivo de la organización es la proposición, valoración e implantación de los recursos, su organización y estructuración, así como el diseño de normas y procedimientos para optimizar su rendimiento.

El objetivo de la computación es similar, pero trata de recursos computarizados. Desde este punto de vista la computación vendría a formar parte de la organización a modo de subconjunto. Cualquier sistema computarizado es dirigido, utilizado y aprovechado por personas estructuradas en órganos de la empresa, trabajando según normas y procedimientos administrativos.

Un proyecto de implantación de un sistema computarizado como soporte de un conjunto de operaciones empresariales tendrá una pequeña probabilidad de éxito si no se usan en sus fases de diseño y desarrollo a los técnicos y profesionales en racionalización y organización administrativa.

Son muchos los casos de sistemas computarizados correctos en principio, pero que han fracasado por no haber participado en su desarrollo los técnicos en organización. Esta carencia ha comportado la imposibilidad de su aplicación práctica en la realidad, o su escasa rentabilidad, ya que aspectos como el diseño en planta, la definición de puestos de trabajo o la racionalización de circuitos administrativos son puntos que a menudo infravalora u olvida el técnico en computación. Para lograr un trabajo de calidad y obviar los inconvenientes recién señalados se debe optar por un trabajo coordinado de ambas clases de especialistas.

En la actualidad aún es habitual encontrar que la función de auditoría computacional en la empresa se dedique a asegurar la existencia y verificar la adecuación y cumplimiento de medidas y procedimientos que garanticen la cobertura contra riesgos, olvidando aspectos tan importantes de gestión empresarial como la propia consecución de beneficios.

La. auditoría computacional

Definición

La norma AFNORl X50-109 define auditoría como: «Examen metódico de una situación relativa a un producto, proceso u organización, en materia de calidad, realizado en cooperación con los interesados, a fin de verificar la concordancia de la realidad con lo preestablecido, y la adecuación al objetivo buscado».

1187


Esta definición puede ser aplicada al concepto de auditoría computacional, en la cual el campoexaminado se referirá a productos, procesos y organizaciones computarizados.

Ahondando un poco más en la definición se pueden examinar los términos siguientes:

1. Metódico: esto quiere decir que el examen se ha de realizar en forma ordenada y planificada. 2. Calidad: conjunto de características de un elemento (producto, servicio, etc.) encaminadas a

lograr que sea capaz de satisfacer unas necesidades dadas. (ANSI2/ASQC3 A3-1978).3. Cooperación con los interesados: el resultado de la auditoría se entregará al interesado, y habrá que

recabar su ayuda para obtener acceso a la información precisa para realizar el análisis.4. Concordancia de la realidad con lo preestablecido: se entiende que cualquier producto, pro

ceso y organización, ha de comportarse de acuerdo a unas normas o planes previos. Uno de losobjetivos de la auditoría es comprobar que realmente se actúa de acuerdo a lo dispuesto.

5. Adecuación al objetivo buscado: además de comprobar el cumplimiento de planes y normas,ha de juzgarse sobre lo acertado de esos planes y normas, y en caso de haber discrepancia conel comportamiento real, averiguar sobre lo acertado de éste.

La definición antes citada pue~e ser complementada con las siguientes:

«Actividad para determinar, por medio de la investigación, la adecuación de los procedimientos establecidos, instrucciones, especificaciones, codificaciones, estándares, y otros requisitos, la adhesión a los mismos, así como la eficacia de su instrumentación» (ANSI N45.2.10.1973).

«Conjunto de técnicas y actividades destinadas a analizar, evaluar, verificar y recomendar sobre el control, la planificación, la adecuación, eficacia y seguridad de la función computacional en la empresa».

«Examen discontinuo de un sistema computacional, o del servicio computacional, a petición de su dirección, para mejorar la rentabilidad, la seguridad y la eficacia» (P. Van der GHINST -CEGOS).

Justificación

La auditoría computacional surge como una necesidad ante la creciente utilización de computadores y paquetes de aplicación en las empresas, a través de las cuales se canaliza la mayor parte de la información de interés sobre las mismas.

La aparición del computador supuso un trastorno inicial en el trabajo de los auditores. La dificultad estribaba en que era un elemento desconocido hasta entonces, gobernado por programas realizados con complicados lenguajes, de documentación escasa o inexistente, que se imponía como un componente más a estudiar en un flujo de trabajo o de información.

Una primera aproximación tendente a salvar este obstáculo consiste en considerar el computador, su entorno y los programas de aplicación, analizando sus entradas y salidas para verificar su concordancia con lo establecido.

El restringido ámbito de aplicación inicial de la computación en las empresas permitía este comportamiento, ya que el riesgo asumido era soportable, y el esfuerzo que exigía la capacitación precisa para examinar los procesos y entornas computarizados era más costoso (o así lo parecía) que ese riesgo.

La idea de que el riesgo era menor que el existente en la realidad, venía propiciado por la idea de infalibilidad del computador, sin considerar que la máquina ejecuta programas según las estrictas instrucciones proporcionadas por los programadores y que es controlada por operadores, tratándose en ambos casos de personas en absoluto infalibles.

1. AFNOR: Asociación francesa de normalización.2. ANSI: Asociación estadounidense de normalización.3. ASQC: Asociación estadounidense de control de calidad.

1188


A medida que va transcurriendo el tiempo, la importancia de la computación se hace cada vezmás notoria en las empresas.

Muchas de ellas sufrieron desastres importantes en sus centros de proceso de datos, con pérdidas tanto de equipos como de soportes de información, llegando incluso en algunos casos a disolverse ante la incapacidad de afrontar los problemas creados por esta situación.

A raíz de la gran cantidad de problemas surgidos, aparece una postura nueva que consiste en minimizar el riesgo de esos desastres, en hacerlos menos probables y en disminuir su impacto sobre la empresa en caso de que se produzcan.

Se comienza a tener conciencia de que la vulnerabilidad de un centro de proceso de datos es tanto o mayor que la de cualquier otro departamento en la empresa. Se hace patente la posibilidad de que éste pueda sufrir algún percance, dado que con frecuencia es posible hallar una fuerte cantidad de dinero invertido en computadores y, el valor que se puede otorgar a la información contenida dentro puede ser comparable o incluso superior. Gracias a este reconocimiento, se crean centros dotados de fuertes medidas de seguridad, ubicados en lugares «estratégicos», en vez de ubicarse en lugares céntricos y ser mostrados a todos los visitantes, como venía ocurriendo hasta ahora.

El hecho de que la simple información almacenada en'un disco magnético, por ejemplo, puede contener los datos sobre el estado de las cuentas corrientes de clientes, hace posible que alguien con los conocimientos adecuados pueda modificar fraudulentamente esa información, genere transacciones falsas, se incremente el saldo de su cuenta, o su salario, ordene transferencias falsas de fondos, venda el fichero de clientes a una empresa competidora, o lo que es más común, que un «pequeño» error no intencionado, produzca efectos desastrosos, dada la gran cantidad de elementos que pueden ser afectados por ese error antes de ser detectado y corregido.

Se estima que la incidencia de fraudes de este tipo es elevadísima, estimándose que sólo se detectan un 10% de ellos y que muy pocos casos salen a la luz pública por el temQr de las empresas a perder prestigio y confianza.

Ante esta situación, se entiende y establece que la 'función de auditoría debe prestar especial atención a lo que ocurre en el desarrollo y explotación de sistemas computarizados, aplicando en algunos casos técnicas tan clásicas como la de verificar la adecuada separación de funciones y responsabilidades, así como la adecuada implantación de controles que permitan detectar rápidamente un fraude o error y tomar las medidas apropiadas para subsanarlo.

Por otra parte se considera el estudio de la adecuación y eficacia de los sistemas computarizados. En general, en la actualidad se considera al departamento de computación como un servicio más, sometido a los mismos controles de eficacia y rentabilidad que los restantes de la empresa.

En resumen, la auditoría computacional surge como respuesta a una serie de riesgos planteados por el uso de la computación en las empresas, a saber: físicos, económicos, de descontrol, incapacidad, ineficacia, costes y, por otra parte, a la importancia que asume la información dentro de la empresa.

Funciones de la auditoría computacionalEn una primera aproximación se pueden establecer tres grupos de funciones a realizar por el auditor computacional:

1. Participar en las revisiones durante y después del di1:!eño, realización, implantación y explotación de aplicaciones computacionales, así como en las fases análogas de realización de cambios importantes.

2. Revisar y juzgar los controles implantados en los sistemas computacionales para verificar su adecuación a las órdenes e instrucciones de la dirección, requisitos legales, protección de con-fidencialidad y cobertura ante errores y fraudes.

3. Revisar y juzgar el nivel de eficacia, utilidad, fiabilidad y seguridad de equipos e información.

1189


La EDP Auditors Foundation realizó, en 1980, una encuesta para obtener una lista de las funciones realizadas por los auditores computacionales, con indicación del porcentaje de esfuerzo dedicado a cada una de ellas. Como resultado, obtuvo una lista de 77 tareas, que agrupó en los 11 conjuntos que se muestran:

1. Revisión de controles en los sistemas de aplicación (Verificar que el sistema proporcionainformación oportuna, exacta, necesaria y suficiente: 9%).

2. Revisión de medidas de seguridad (Revisar métodos, procedimientos y medidas para asegurar la adecuada protección de información, software, equipos e instalaciones: 14%).

3. Revisión de la integridad de la información (Verificar que la información es completa, coherente y correcta: 13%).

4. Revisión de los procedimientos de operación (Verificar que las aplicaciones se procesen enforma y entorno adecuado y controlado: 12%).

5. Revisión del desarrollo de sistemas (Verificar la existencia, adecuación e integridad de planes y controles: 9%).

6. Gestión y planificación de la auditoría computacional (Planificar, organizar y controlar lafunción de auditoría computacional; 9%).

7. Revisión de los procesos de mantenimiento de software (Revisar normas y procedimientospara realizar modificaciones en el software: 6%).

8. Revisión del proceso de desarrollo de sistemas (Verificar que se emplea una metodologíaadecuada para el desarrollo: 5%).

9. Revisión del software básico (Revisar controles sobre el mismo, existencia y cumplimientode normas sobre su uso: 5%).

10. Revisión de planes y gestión (RevisaT planes, políticas, reglas de gestión, procedimientos admi-nistrativos del departamento, para verificar la adecuación a los fines de la empresa: 5%). 11. Revisión

de contratos (Verificar que la compra o alquiler de hardware, software o serviciosse hace en forma legal, económica y provechosa para la empresa: 3%).

Se hace notar que las cifras no indican la importancia relativa de las tareas, sino los consumosde esfuerzos que implican.

Es importante dejar sentado que la auditoría de un sistema computaTizado debe abordar el aná' lisis y revisión, no sólo en el ámbito estricto del departamento, sino que ha de estudiar los sistemas desde que se originan los datos de entrada, en los departamentos usuarios, hasta que

usuarios reciben la información de salida.La auditoría que revisa sólo los aspectos puramente computarizados no tendrá una visión real; dél sistema. En

efecto, en muchas ocasiones, un irreprochable proceso computarizado no es útil ' porque no hay una adecuada distribución de los informes de salida, o porque no hay manuales' actualizados de usuario; otras veces, un gasto importante en asegurar la confidencialidad de los datos es desperdiciado por la inexistencia de normas y disciplina de protección de la confiden"'" cialidad en los departamentos usuarios. Por ello, el auditor computacional debe realizar parte de sus tareas sobre procesos y circuitos fuera del departamento de computación.

1190

Perfil del auditor computacional

El perfil de conocimientos y experiencias deseable en un auditor computacional puede obtenerse a partir de los grupos de funciones recién citadas en el apartado anterior. Cabe hacer notar la dificultad de que una sola persona posea todos esos conocimientos y experiencias, dada la disparidadentre los puntos mencionados. "

A modo de ejemplo, el último punto citado implica conocimientos importantes sobre legislaf ción mercantil, mientras que otros tales como el referido a revisión del software básico exige Calla cimientos sobre sistemas operativos así como la auditoría sobre la adecuación del parque compu tacional a las necesidades de la empresa, o la configuración y uso de recursos hardware, aspecto!


que normalmente exigen la utilización de un asesor en temas técnicos: gestión de bases de datos, gestión de teleproceso, gestión de configuración, hardware, etc.

Por ello, en teoría el auditor computacional debe tener un conocimiento general de todos los puntos objeto de examen o revisión, con lo que podrá determinar qué y cuantos colaboradores, con qué perfiles, precisa para que le ayuden en su trabajo.

Los profesionales pueden acceder desde dos vías a la auditoría computacional: el auditor financiero u organizativo, que adquiere la formación y experiencia en computación, y la contraria, el técnico.en computación que se capacita en los principios y técnicas de la auditoría.

Metodología de la auditoría computacionalEl método que se expondrá es común a la implantación de un órgano de auditoría computacional, o control interno en una empresa, y a la realización de una auditoría puntual de la totalidad o parte de un departamento de computación.

Definición de ámbito y objetivos

Este primer paso consiste en una serie de reuniones o entrevistas con el peticionario de la auditoría o, si se trata de implantar la función de auditoría computacional, con la persona u órgano a quien compete ese elemento estructural.

Como resultado de esas entrevistas se ha de conseguir un documento inicial de exposición deobjetivos.

Puede ocurrir que la persona entrevistada (el peticionario) indique que se le haga una propuesta de posibles ámbitos de trabajo, en cuyo caso se le preparará un documento en el que figurarán las alternativas siguientes:

1. Desarrollo de la totalidad de la función de auditoría en la empresa, revisando incluso la utilidad para los usuarios finales, por medio de muestreos, entrevistas o análisis exhaustivo. 2. Auditoría exclusiva

del interior del departamento de computación. 3. Auditoría de algún subsistema o aplicación, como pudiera ser del parque de computadoras, su

adecuación, utilización, eficacia, etc.4. Auditoría de alguna función en particular como, por ejemplo, de las medidas de seguridad y

privacidad.5. Auditoría de la metodología de análisis y desarrollo de sistemas computarizados.

Ha de obtenerse un acuerdo formal sobre objetivos y ámbito de trabajo, plasmado en un documen to de especificaciones iniciales, firmado y validado. En cuanto a los objetivos, pueden consistir en:

1. Mejorar costes, plazos o calidad.2. Aumentar la seguridad o la fiabilidad. 3. Evaluar el funcionamiento de un órgano.

Estos objetivos posibles afectan a:

1. Funciones administrativas: organización y personal, planeación, análisis de costes y contabilidad, desarrollo de procedimientos administrativos, asuntos legales. 2. Función de desarrollo de sistemas:

desarrollo en sí, mantenimiento. 3. Función de operación: operación en sí, control de entrada y salida, teleproceso, soporte técnico,

etcétera. 4. Servicios exteriores: servicios suministrados, servicios recibidos. 5. Soporte a la propia auditoría: organización, planeación, formación.

1191


Estudio inicial

A partir de la definición anterior de objetivos y ámbito, deberá realizarse un estudio global que permita conocer volúmenes y complejidad de las tareas a realizar.

El trabajo se realiza a partir de entrevistas, cuestionarios y, posiblemente, muestreos para obtener una idea de la dimensión y complejidad del ámbito de estudio, lo que permitirá estimar esfuerzos. Como elementos fundamentales a considerar, pueden citarse la estructura y volumen de los elementos a estudiar:

1192

1. Organización.a) Órganos.b) Número de clases diferentes de puestos de trabajo. c) Cantidad de personas por cada clase de puesto.d) Relaciones entre órganos (jerárquicas y funcionales). e) Flujos de información.

2. Aplicaciones computacionales. .a) Cantidad, tamaño y complejidad de los programas.b) Antigüedad. .

c) Documentación.d) Cantidad y complejidad de archivos.e) Método de diseño.

3. Entorno operativo.a) Configuración de hardware y software básico.b) Número de centros.c) Redes de comunicaciones.d) Distribución (de datos, aplicaciones, diseño y desarrollo).

4. Metodología de trabajo.a) Normas y procedimientos.

. b) Documentación (manuales).c) Estándares.d) Planificación, control y administración.

A partir de esos parámetros, se ha de obtener una definición de la envergadura del trabajo. .. El informe obtenido en esta etapa ha de presentarse a validación por los técnicos y enlaces eo

auditoría para determinar si es correcto. Ha de obtene¡;se, finalmente, un informe validado sobr los parámetros observados respecto a dimensiones del trabajo y el esfuerzo a realizar.

Determinación de perfiles

A partir de la definición del punto anterior se podrá obtener una lista de los perfiles técnicos pr cisos de las personas que habrán de colaborar en la realización de la auditoría. Fundamenta mente se tratará de:

1. Expertos en comunicación. 2. Expertos en bases de datos.3. Expertos en configuración de hardware; adecuación y medidas de eficacia y rendimiento. 4. Expertos en organización y racionalización del trabajo administrativo.5. Técnicos computacionales en general.6. Psicólogos.


Del mismo modo se estimarán los recursos materiales necesarios en cuanto a:

1. Software.a) Paquetes de auditoría. b) Compilad ores.c) Lenguajes.d) Monitores.e) Informes contables.

2. Hardware.a) Tiempo de computador. b) Equipos específicos.

Elaboración de planes

Se aborda a continuación la elaboración de un plan, en que se indicarán:

1. Listas de actividades a realizar, estructuradas según su secuencia lógica, así como perfiles de las personas para ejecutarlas, e inventario de medios necesarios. 2. Esfuerzos estimados para cada actividad por cada

recurso preciso. 3. Se debe concretar en ellas la ayuda a recibir en la realización de la auditoría en cuanto a:a) Personal técnico y administrativo.b) Software (equipos, tiempo de máquina).c) Presupuesto inicial.d) Contenido (aspectos) de los informes finales.e) Boceto.

El plan se discute con los peticionarios de la auditoría hasta obtener un acuerdo provisional, sobre todo de los cuatro últimos apartados.

ElaboraciQn de programas

Un plan se convierte en programa cuando las actividades pasan de estar asignadas a recursos tipo (perfiles) a ser asignadas a recursos concretos (personas u órganos), con fechas de iniciación y ter-minación previstas para la realización. Es posible que de este hecho se derive la necesidad de realizar ajustes en presupuestos o calendario, debido a indisponibilidades o incompatibilidades de recursos. Hay que tener presente que en la elaboración de planes no se pueden establecer calendarios, ya que se trabaja con recursos genéricos y no concretos. Como resultado de esta etapa se obtendrá: el programa, el calendario en firme y el presupuesto en firme.

Una vez más hay que realizar una reunión con los peticionarios, o enviarles los tres puntos, para obtener un acuerdo escrito, o un contrato.

Realización de las actividades

A partir de la definición en firme, se puede com'enzar la realización de la auditoría, teniendo en cuenta que puede abordarse:

1. Por temas o funciones. Por ejemplo, realizando en primer lugar todos los trabajos relacionadoscon seguridad; en segundo lugar, todos los relacionados con estructura, etc.

2. Por órganos auditados. Por ejemplo, se hace el estudio completo de la sección X y luego de lasección Y, etc.

1193


En el primer caso la realización de las actividades conlleva más tiempo, pero se obtiene un tra bajo de más calidad. Si se opta por escoger la segunda alternativa se ahorra tiempo, las actividades se pueden realizar más rápidamente, pero se obtiene un trabajo de menos calidad.

Elaboración del informe final

En cada fase del trabajo se entregan borradores de los informes, a las personas implicadas, ya que puede haber existido algún error de apreciación, que en la crítica y validación del borrador, debería detectarse. También pueden ponerse de manifiesto aspectos oscuros, temas tratados incompleta o erróneamente, o bien, asuntos no tratados. Es decir, a medida que se realizan los estudios de órganos, funciones o temas, se entregan borradores para su crítica y validación. Con los informes validados se elabora el informe final, que se entrega al peticionario. O sea, que a partir de una sistematización de estos informes parciales, se obtiene el informe final cuyo contenido consistirá en:

1. Presentación.2. Definición de ámbitos y objetivos. .3. Enumeración de temas, órganos, aplicaciones, etc., considerados. 4. Análisis.

a) Situación prevista.b) Situación real.c) Tendencias.d) Puntos débiles y amenazas que suponen. e) Puntos fuertes y oportunidades.

5. Recomendaciones.

a) Descripción.b) Plan de implantación.c) Beneficios.d) Plan de seguimiento y control.

Ocasionalmente, se puede determinar que las personas que han realizado la auditoría intervendrán en el futuro para seguir el cumplimiento de los planes de acción recomendados en aspectos definidos previamente.

Reglas básicas en la realización de una auditoría

Se indican en este apartado una serie de principios básicos a tener en cuenta en la realización de una auditoría de cara a lograr una mayor efectividad en el trabajo por parte del auditor computacional.

1. Fomentar la cooperación de los elementos auditados. Normalmente se suele adoptar una actitud defensiva ante el auditor, ya que se piensa que éste busca culpables. Para evitar esa situación, o incluso que se llegue a un boicot más o menos abierto, es preciso convencer a todos los implicados de que el auditor sólo busca mejoras y soluciones.

2. Contar con el apoyo de la dirección, ya que se deberán realizar entrevistas y solicitar documentación y posiblemente trabajos de los elementos auditados.

3. Cuidar aspectos protocolarios; explicar al jefe de una unidad qué es lo que se desea obtener enuna entrevista con un subordinado suyo; establecer una diferencia clara entre los jefes y losempleados.

1194


4. Realizar una presentación o entrevista inicial en que se explique el objetivo, su justificación yse aclaren dudas.

5. Solicitar con la antelación precisa la información inicial a obtener. Es decir, solicitar la información precisa antes de comenzar los trabajos (manuales de normas, etc.).

6. No adelantar resultados parciales sobre un área o función determinadas; las visiones o análisis parciales pueden causar impresiones falsas y además ser erróneas.

7. Comentar con los interesados los resultados obtenidos antes de presentarlos a niveles superiores.

Evidentemente, en caso de que se investiguen posibles fraudes o irregularidades maliciosas, la estrategia es distinta, debiendo cuidar que se realicen y preparen los trabajos pertinentes con el mayor sigilo posible.

1. No emitir juicios que no estén sólidamente basados.2. El auditor observa, juzga, recomienda. Al ser un personaje independiente de la función o ele

mento auditado, no es responsable, ni realizador, ni usuario.

Técnicas y herramientas utilizadas en la

auditoría computacionalLas técnicas utilizadas son las habituales de la auditoría; muestreo, revisión, entrevista, prueba y simulación. Todas ellas han sido ampliamente desarrolladas en las primeras secciones de esta enciclopedia en las que se estudia la auditoría clásica. En cuanto a las herramientas utilizadas se pueden mencionar: cuestionarios, estándares, simuladores, paquetes de auditoría, matrices de riesgo y monitores. Las dos primeras fueron también desarrolladas en las secciones destinadas ala auditoría tradicional; las siguientes se explican a continuación. .

Simuladores

Dado que entre los elementos a observar figuran configuraciones hardware y software a veces hay que utilizar herramientas especiales para poder deducir el comportamiento del elemento en cuestión ante situaciones límite, como pueden ser un corte de luz, un tráfico muy elevado de información, etc. Se trata, en definitiva, de comprobar si poseen las características necesarias para hacer frente a estas situaciones. Hay simuladores basados en productos software y otros que usan una mezcla de hardware y software.

Para ayudas en el diseño de redes de comunicaciones, por ejemplo, se pueden usar productos que simulan y predicen el comportamiento de una configuración ante un suceso determinado, indicando capacidad de proceso, cuellos de botella, etc., o bien que rastrean el comportamiento de un elemento en una situación real.

Paquetes de auditoría

Son herramientas comúnmente usadas por personas que realizan auditoría por medio de la com-putadora. Son programas o conjuntos de programas que permiten, con órdenes sencillas y de pequeño formato, generar programas que realizan funciones típicas de muestreo al azar, muestrear según otros criterios, selección de información que cumpla determinados requisitos, estudios estadísticos, edición de informes, etc.

Estos paquetes permiten un ahorro considerable de necesidad de formación computacional por parte del auditor, así como una elevada velocidad de realización de los programas precisos.

1195


Monitores

Se trata de software, hardware, o combinación de ambos, que miden el comportamiento de un sistema o componente del sistema, en una situación e instante real. Se diferencian de los simuladores en que éstos predicen o infieren el comportamiento de un elemento, mientras que los monitores sólo miden, no provocan o simulan determinadas situaciones.

Matrices de riesgos

Las matrices de riesgo, también llamadas de amenazas, son las herramientas utilizadas para ana lizar riesgos y establecer medidas de cobertura. Se define la exposición a un suceso como la probabilidad de que se produzca ese suceso, mientras que el riesgo de un suceso viene determinado como el producto de la exposición por el coste del suceso.

El riesgo da una medida en dinero del coste probable que supone para una instalación la existencia de una posible amenaza. Es importante calcular el riesgo de una instalación o un sistema ante un suceso determinado, ya que del.análisis del conjunto de los riesgos se deriva la definición de prioridades y recursos que deben dedicarse a cubrirlos.

Por ejemplo, un incendio total en un centro de proceso de datos puede ocasionar unos daños de 500 millones de unidades monetarias, con una probabilidad de que se produzca un incendio cada 200 años. El riesgo que sufre la instalación es, pues, de:

500.000.000 u.m.200 años

= 2.500.000 u.m./año

El coste medio de recuperación de un error en un proceso de facturación puede ser de 30.000unidades monetarias, y se producen 100 errores al año.

Elriesgo es de 30.000 u.m. x 100 = 3.000.000 u.m./año.De ahí se deduce que una exposición elevada puede ocasionar riesgos elevados, aunque el

coste unitario sea pequeño.Ha de tenerse en cuenta, cuando se habla de coste del suceso, que a veces es difícil de evaluar. Por ejemplo, en

el caso de una empresa con tratamientos computarizados en línea, el coste de una catástrofe, como podría ser un incendio del centro de proceso de datos será igual al coste de reposición de equipos + pérdida de beneficios (no obtenidos) + pérdida de clientela y negocio por disminución o interrupción de la capacidad de operación.

Como herramientas para análisis de riesgos y medidas de cobertura, se usan las denominadas matrices de riesgos o amenazas, algunas de cuyas variantes son:

1. Matriz 1 (probabilidad, amenaza, impacto)2. Matriz 2 (amenaza, medida de cobertura, efecto) 3. Matriz 3 (amenaza, recurso, medida de cobertura)

1196

CAPÍTULO 52

Auditoría de la planificación

GERARDO GÁLVEZ MENESES

Ingeniero comercial Universidad de Chile

Ámbito de actuación de la auditoría /52-1198

Auditoría de la función de planificación /52-1198 Conceptos relativos a la función de planificación /52-1198 Problemas asociados a la función de planificación / 52-1198 Niveles de planificación /52-1199

El plan estratégico de sistemas /52-1200Contenido del plan estratégico de sistemas /52-1200 Resumen del plan estratégico de sistemas / 52-1202 Planes tácticos / 52-1203Planes operacionales /52-1203Revisión de la planificación por el auditor / 52-1203

1197


Ámbito de actuación de la auditoría

El ámbito de actuación de la auditoría es bastante amplio. Puede actuar sobre:

1. La función de planificación.2. La construcción o desarrollo de sistemas. 3. La organización y la administración.4. El entorno operativo.5. La explotación.6. La gestión.

En este capítulo se tratará la actuación de la auditoría sobre la función de planificación. En los siguientes capítulos se tratarán otros ámbitos de actuación de la auditoría.

Auditoría de la función de planificación

Conceptos relativos a la función de planificación

. Bajo el término planificación se engloban dos actividades relacionadas aunque diferentes: la actividad de diseñar planes y la de ejecutar las tareas según los planes previstos.

En un departamento de computación los planes deben referirse a objetivos, actividades, plazos, costes y recursos.

Deben existir los mecanismos precisos (normas, procedimientos, órganos de planificación, seguimiento y control), que aseguren la existencia, adecuación y cumplimiento de planes, controles, administración y medidas de gestión.

La ausencia de algunos de ellos es un síntoma, sobre todo en grandes instalaciones, de posibles deficiencias en cuanto a falta de coherencia, calidad o economía en las mismas.

Problemas asociados a la función de planificaciónli,

Aplicaciones inconexas. La implantación de la computación en la empresa se produce normalmente para solucionar un problema muy concreto y local, que consiste en aglutinar en un sólo departamento la gestión de stock, el proceso de capitalización y el control de cuentas de clientes.

A medida que se va verificando la utilidad de la computación, se amplía su uso a otros depar -tamentos, pero en cada caso se contemplan soluciones concretas con desarrollo de software específico para cada problema operacional.

" '1

,~~,','

Información redundante, incoherente e inconexa. Como derivación del problema antes citado, se puede llegar a una situación que se presenta actualmente en muchos bancos, en la que cada área de negocio (cuentas personales, préstamos, valores, etc.) tiene ficheros propios de clientes, con formatos incompatibles, por lo que se duplican en grado excesivo ciertos datos. Una persona que sea titular de varias cuentas corrientes y una cuenta de ahorro a plazo y varios depósitos de valores, puede tener sus datos personales repetidos, con distinto grado de actualización, tantas veces como cuentas tenga. Corregir estos problemas, y sobre todo evitar que se vuelvan a producir en el futuro, es uno de los objetivos de la planificación. Ha de considerarse que los productos computarizados deben adecuarse a la estructura de la información empresarial.

La misión de desarrollo de sistemas es lograr un sistema integrado por subsistemas o aplicaciones interconectadas con software común y datos comunes, de redundancias controladas y coherentes. Este sistema integrado no se logra sin los planes adecuados.

'1

" ,,1'1"

!;,1~

"'"

"

1,1

""""

"

1

,'" ' k

~í\ .

1198 ,WI,~


Parque computarizado caótico. La política de adquisición (compra, alquiler, leasing) de equipos computarizados a veces no está definida y planeada, y las responsabilidades en este sentido se hallan dispersas. Con ello se logra tener en una misma instalación elementos hardware o software incompatibles, e incluso en franca competencia.

Rumbo indeterminado del departamento. La inexistencia o incumplimiento de planes provoca la existencia de instalaciones donde se realizan muchos anteproyectos, se empiezan menos proyectos, se terminan menos y muy pocos se usan o sirven para algo.

Desconexión del departamento con la realidad de la empresa. Evidentemente, los planes de mayor nivel del departamento han de ser aprobados y controlados por la dirección de la empresa. Ello produce un deseable contraste del mundo computarizado con la empresa, con adecuación de aquél a las necesidades y objetivos de ésta.

Objetivos inexistentes, desconocidos o mal formulados. Los objetivos han de ser claros y medibles. Suelen encontrarse definiciones de objetivos que no son tal sino enumeraciones de medios. Por ejemplo, mecanizar un servicio no es un objetivo. Un objetivo podría ser bajar en un 20 % los costes de ese servicio.

Niveles de planificación

Existen diversas terminologías para definir los niveles y clases de planes, en función de su contenido y alcance. Se adopta la siguiente clasificación en tres niveles:

Planificación estratégica (alto nivel). El plan estratégico define misiones, objetivos y políticas. Se contempla a largo plazo (5 años) y su ámbito abarca el sistema de información (toda la empresa). Como ejemplo de objetivos podrían citarse:

a) Tiempo medio de servicio a un cliente inferior a un minuto.b) Tiempo de servicio a un cliente inferior a dos minutos en el 95% de los casos. c) Coste por operación inferior a 25 unidades monetarias.d) Incrementar el margen de intermediación un 15%.e) Aumentar el pasivo en un 25%.

Cuando los objetivos se alcanzan, las misiones se cumplen. Como ejemplo de políticas sepodrían citar las siguientes:

a) Descentralizar los equipos y desarrollo de software. b) Promover el uso de máquinas de autoservicio.c) Frenar el incremento de la plantilla de personal.

Las políticas que restringen las variables de actuación han de respetarse.

Planificación táctica (medio nivel). El plan táctico dispone adecuadamente los recursos disponibles para cumplir las misiones y alcanzar los objetivos fijados dentro de las políticas determinadas: Tiene una duración de 1 a 2 años, se refiere.a proyectos (parte de la empresa).

Dentro de las tácticas que pueden emplearse para lograr los objetivos, acordes con las políticas fijadas, se citan:

a) ¿Menos clientes, más rentables?b) ¿Racionalizar diseño en plantas de oficinas?

1199


c) ¿Más oficinas? d) ¿Más clientes?e) ¿Mecanizar operaciones A, B, C? f) ¿Teleproceso?

Planificación operacional (bajo nivel). El plan operacional es un desglose a mayor nivel de detalle del plan táctico. Sus características son análogas a las de éste en cuanto a la definición de su contenido. Pero es un plan a corto plazo y está referido exclusivamente a sub proyectos o a fases de subproyectos.

Como ejemplo de un plan operacional podrían citarse:

a) Realizar curso X para los puestos Y, Z de trabajo. b) Realizar el programa P: Programación, Pruebas

El plan estratégico de sistemas

En diversas metodologías y bibliografía sobre el tema, el plan estratégico de sistemas se conoce también con los nombres de plan computacional, plan de sistemas o plan a largo plazo. Sus carac-terísticas son las siguientes:

La duración suele cubrir un plazo de 4 a 5 años, ya que dada la evolución del mercado y la tecnología computarizada, es poco práctico y realista hacer planes a más largo plazo. Así, la dura- I ción de la aplicación del plan nunca puede ser superior a 4 o 5 años porque la tecnología com- '1 putacional tiene una tasa de innovación tal que hace imposible predecir la oferta tecnológica a !,¡d~mayor plazo. !

La realización y responsabilidad del plan corresponde a la dirección del departamento, J

empleándose para ello los asesores internos o externos que se precisen. Debe estar enmarcado \1'¡'(en los planes de la empresa y ser coherente con ellos. Además requiere ser revisado y aproba- '¡¡i~

do por las áreas de negocio y la dirección de la empresa. La información de que se nutre está .\11formada por:

"~

"'10.~i,¡~

1. Planes de la empresa.2. Directrices que le han sido fijadas.3. Información del entorno técnico, del mercado y la competencia.4. Información de gestión interna del departamento.5. Información procedente de órganos usuarios.6. Información procedente de intercambios de experiencias con otros centros similares.

."¡,,,,¡w

!

Además de revisarse y aprobarse, debe ser publicado en los ámbitos de difusión pertinentes de 'mii!!

la empm,a, con objeto de qne ,ea conocido po< quiene, deban n,ado. Su ,ev;,;6n y coceecdón .., .:.

(o confirmación) se realiza cada 6 o a lo sumo 12 meses, o en cualquier momento en caso de pre- i; sentarse desviaciones de importancia de las hipótesis, previsiones o desarrollo del plan.

Hil de ser usado como marco de referencia para todos los trabajos del departamento: desarrollo de sistemas, adquisición de equipo o software básico, comunicaciones, etc.

1200

Contenido del plan estratégico de sistemasEl plan ha de formularse de acuerdo a una serie de premisas, puntos de partida y previsiones (hipótesis), sobre el cumplimiento en las cuales se basa. Un modelo de contenido podría ser el siguiente:


1. Situación actual. En esta etapa se analiza el punto de partida, definiendo no sólo la situación del departamento sino, sobre todo, teniendo en cuenta el alcance del plan, la de la empresa, y la de la competencia. La existencia de productos tecnológicos (hardware, software, facilidades de comunicación) determina también los posibles útiles en que se puede apoyar el sistema de información mecanizado. Por otra parte, ha de especificarse la situación (puntos débiles y fuertes) del propio departamento, para aprovechar en el futuro los puntos fuertes (oportunidades) y corregir los débiles (amenazas). Aspectos como la carga de trabajo que se tiene en la actuali-dad, sobre todo la de mantenimiento de aplicaciones, la formación y experiencia de las personas, la carga de equipos, etc., son importantes a la hora de definir la situadón actual.

2. Hipótesis. Se formulan unas previsiones sobre el comportamiento de la empresa en cuanto acapacidad, necesidades, oferta y demanda, la tecnología, competencia, etc., para el período de tiempo en que se deberá aplicar el plan. Se supone que se cumplirán esas previsiones, en cuyo caso se deberán alcanzar los objetivos fijados. A lo largo de la vida del plan deberán hacerse las revisiones precisas, sobre todo, si se detecta que alguna de las previsiones no se cumple, en cuyo caso habrá que realizar las correcciones pertinentes al plan.

3. Políticas de empresa. Las impone la dirección de la misma, y consisten en restricciones a las posibles variables de actuación para cumplir las misiones y alcanzar los objetivos. Se trata de decisiones de alto nivel, como descentralización o centralización del proceso de datos, descentralización del desarrollo de software, autonomía o conexión a grandes centros, líneas privadas o públicas de comunicación, modelo de centro usuario computacional, estructura, personal, equipo, etc. Esas decisiones, que han de respetarse durante largo tiempo, y usarse entodos los subsistemas a implantar, vienen fijadas por la dirección.

4. Objetivos del departamento. Constituyen' la parte fundamental del plan y consisten en definir los objetivos claros y mediblesque debe conseguir la función computacional en la empresa.Pueden resumirse en: .

a) Calidad y cantidad del servicio. b) Coste del servicio.

Normalmente, no se suele hablar de costes de los planes de proyectos, ni de los de las aplicaciones ni incluso, de los de la totalidad del departamento. Es misión del auditor, entre otras, lograr que el profesional de la computación hable en términos de coste y magnitudes medibles, en lugar de referirse a beneficios intangibles. Como ejemplo de posibles objetivos pueden citarse:

a) Tiempos de respuesta a procesos en línea.b) Capacidad de proceso de trabajos y transacciones; tráficos.c) Tasas de errores e indisponibilidad.d) Coste de cada servicio.e) Servicios mecanizados a implantar y correspondiente justificación económica.f) Captación de mercado por medio de servicios a clientes.

Hasta ahora los puntos mencionados se articulan en la proposición: Partiendo de 1 (situación. actual), si se cumple 2 (hipótesis), lograremos 4 (objetivos del departamento) respetando 3 (políticas de

empresa). Los siguientes aspectos definen cómo se van a lograr esos objetivos.

5. Arquitectura del subsistema de información mecanizada. Indica el diseño funcional global del subsistema a lograr. Es posible que a lo largo del plazo del plan no se prevea obtener la totalidad del subsistema. En cualquier caso, ha de indicarse la arquitectura total, aclarando quéparte del mismo deberá realizarse a lo largo del período planificado. Se deberá indicar quéaplicaciones se realizarán, su impacto sobre áreas usuarias y la interrelación entre ellas.

1201

j


6. Necesidades de seguridad, confidencialidad y control. La importancia de este punto radica en el hecho de que, actualmente, la posesión de información de calidad condiciona más que nunca el éxito de una empresa. Además, la capacidad de procesar los elevados volúmenes de información que guardan las computadoras, y la posibilidad de copiar esa información a un bajo coste, hace preciso considerar la información como un activo de la empresa, y equiparar la pérdida de confidencialidad o la destrucción de información a pérdida de dinero. El fraude por medio de la computación, puesto de relieve en los medios de comunicación, ha de preocupar lo bastante como para que se adopten adecuados sistemas de control de acceso a la información.

7. Arquitectura técnica. Una vez definido el modelo funcional, se deberá definir en qué elementos de hardware y software se implantará ese modelo. En cuanto al hardware habrá que considerar:

a) Equipos centrales: clase, cantidad y configuración.b) Equipos distribuidos: clase, cantidad y configuración.c) Redes de comunicaciones: volumen, clase, tipología.d) Máquinas para incremento de la calidad y productividad del propio departamento.

y en lo que se refiere al software:

1202

a) Software básico.b) Sistemas operativos.c) Gestores de bases de datos.d) Gestores de comunicaciones.e) Paquetes de aplicaciones.f) Software para incrementar la calidad y productividad del propio departamento. g) Aplicaciones propias.

No se trata de definir marcas y modelos, sino características y requisitos que han de cumplir. La selección de los mismos podrá hacerse a posteriori.

8. Necesidades de personala) Cantidad de personas por cada perfil preciso.b) Planes de formación.c) Planes de contratación.d) Manera de contactar con personas e instantes en que se deberá poder disponer de ellas.

9. Riesgos y contingencias. Dado que en el análisis de la situación actual se han detectado puntos débiles, que en el futuro podrán convertirse en amenazas, y que el plan se basa en el cum -plimiento de unas previsiones, es posible, desde el momento en que se esté elaborando el plan, definir una lista de posibles riesgos, con el impacto que tendrían sobre el mismo, y las medidas correctoras a adoptar en caso de que se presentaran. En definitiva, se trataría en este punto de describir los posibles riesgos, explicar cuáles serían sus síntomas, qué elementos se verían afect?-dos y cuáles serían las acciones a ejecutar si estos hechos se produjesen.

Resumen del plan estratégico de sistemas

La totalidad del plan tiene el siguiente significado. A partir de 1 (situacion actual), y suponiendo 2 (hipótesis), de acuerdo a 3 (políticas de empresa), lograremos 4 (objetivos del departamento) implantando un sistema que hará 5 (arquitectura del subsistema de información mecanizada), con los requisitos 6 (necesidades de seguridad, confidencialidad y control), sobre un conjunto de


hardware y software 7 (arquitectura técnica), para lo que se prevén unas necesidades de personal 8 (necesidades de personal). Existen los riesgos 9 (Riesgos y contingencias), que habrá que vigilar adecuadamente.

Planes tácticos

Representan el nivel intermedio, con un alcance de 1 o 2 años. En realidad no hay un plan táctico sino un conjunto de ellos, ya que existen planes independientes, relativos a proyectos identificados y definidos en el plan estratégico, que determina la estructura maestra a que todos deben acomodarse. Los planes tácticos los realiza la dirección del departamento, pero deben ser conocidos y aprobados en el ámbito de la dirección de la empresa.

Han de revisarse y confirmarse (o modificarse) trimestralmente y su seguimiento es responsabilidad del comité de computación. El contenido de estos planes es un programa (plan con responsables concretos de cada actividad y fechas de ejecución) de cada proyecto.

Planes operacionales

Son los que tienen mayor grado de detalle y alcance a corto plazo. La responsabilidad de su con -fección, seguimiento y control, atañe al jefe de proyecto, en el caso de referirse a construcción de sistemas, y al jefe de la unidad orgánica correspondiente, en el caso de explotación. Como norma, puede indicarse que el grado de detalle que ha de alcanzarse en este nivel debe llegar a definir actividades de duración semanal o quincenal.

Revisión de la planificación por el auditor

Como se ha dicho, los planes deben existir, estar formalizados adecuadamente, ser razonables y coherentes con la planificación global de la empresa, además de mantenerse y utilizarse. El audi tor ha de verificar pues:

1. Que existan documentos aprobados por los órganos competentes en que se reflejan los tresniveles de planificación.

2. Que estén publicados y sean conocidos por las personas dentro de sus ámbitos de difusión. 3. Que sean realistas y armónicos con los de la empresa.4. Que existan las normas y procedimientos precisos para su confección, publicación y manteni

miento. .

5. Que esas normas y procedimientos sean adecuados y seguidas.6. Que se revisen con la periodicidad adecuada, así como en caso de ocurrir algún suceso que lo

exigiera.7. Que se incorporen a los planes las modificaciones que se haya creído preciso indicando:

a) Por qué (causa).b) Quién decide la modificación.c) En qué consiste la modificación.d) Beneficios u objetivos a conseguir con ella.

1203

CAPÍTULO 53

Auditoría de sistemas

JAIME LINDEGAARD VEGA

Técnico en ComputaciónSocio International Multimedia Design

Auditoría de la construcción de sistemas /53-1206 Problemas asociados a la construcción de sistemas / 53-1206 Puntos clave de la construcción de sistemas / 53-1207

Auditoría del proceso de construcción de sistemas /53-1207 Principios fundamentales de la gestión de proyectos / 53-1208 La planificación en la construcción de sistemas /53-1208 Fases en el proceso de construcción de sistemas /53-1208 Puntos clave de la buena planificación de un proyecto /53-1209

Auditoría de la calidad de un producto computarizado Principios clave /53-1211Definición de calidad /53-1211Plan de garantía de calidad del software / 53-1211 Medidas de control interno del software / 53-1213

/53-1211

1205


Auditoría de la construcción de sistemas

Con este nombre se engloba la actividad de definir, diseñar, realizar, implantar y, a veces, de mantener un subsistema computarizado o aplicación computarizada. Ello implica no sólo desarrollo de software, sino también la realización de manuales de usuario, documentación, formación de usuarios, definición e implantación o racionalización de circuitos administrativos, etc.

El origen del trabajo de construcción de un subsistema puede ser una petición de un órgano usuario, uria orden de la dirección de la empresa, el resultado de un estudio organizativo, o una propuesta del propio departamento de computación. La actividad de construcción de sistemas es de vital importancia, ya que en ella se diseñan las características funcionales y técnicas, por lo que evidentemente, una actividad de mala calidad puede proporcionar productos no utilizables.

El consumo de recursos, sobre todo de personal, de esta actividad, suele suponer el 40% del total de la función computacional, lo que hace de gran importancia su estudio y diagnóstico por parte del auditor computacional.

Problemas asociados a la construcción de sistemas

Los problemas derivados de la construcción de sistemas pueden resumirse en los siguientes cinco apartados:

1. Construcción de sistemas inadecuados: sus características lo hacen inútil para el fin que estaba previsto.

2. Sistemas ineficaces: la ineficacia es uno de los apartados de la falta de adecuación, relacionada con la capacidad de proceso y la satisfacción de las necesidades del usuario. Parámetrostípicos de eficacia son:

a) El número máximo de accesos que puede soportar. b) El tiempo de respuesta.c) El coste de acceso.

3. Sistema inseguro: presenta dos aspectos, facilidad de intrusión y realización d'e operaciones nopermitidas, y admisión de datos incorrectos (o rechazo, como erróneos, de datos correctos).

4. Sistema difícilmente mantenible: se supone que el mantenimiento engloba funciones de solución de fallos y defectos, ampliación, modificación a petición de usuarios o del propio departamento de computación

5. Sistema no fiable: presenta fallos (errores o averías) con frecuencia.

Esas amenazas se refieren al producto de la actividad de construcción de sistemas. Hay otras amenazas que afectan no al producto sino al método de trabajo, a la propia actividad de construcción.

Usando un símil en la industria, diríamos que la posibilidad de obtener una pieza defectuosa es una amenaza sobre el producto, mientras que emplear tres horas en elaborar una pieza que razonablemente podría elaborarse en una hora, es una amenaza sobre la propia actividad de construcción. Las amenazas sobre la actividad de construcción son:

a) Incapacidad para realizar el trabajo previsto: no son infrecuente s los casos en que, en un momento dado, se ha de desechar todo lo realizado hasta ese instante y recomenzar, o encomendar el trabajo a otro equipo, incluso en el exterior del departamento.

b) Incumplimiento de plazos: excesivo consumo de recursosc) Sistemas inacabados: en computación suele ser frecuente encontrarse con sistemas que se

encuentran próximos a su terminación, y pasan largos períodos de tiempo en ese estado, sin que se produzca avance alguno.

;1

'¡

1206


Puntos clave de la construcción de sistemas

El auditor ha de vigilar dos elementos:

1. El producto obtenido (el sistema)2. La actividad de construcción (el método)

Para el primero ha de asegurar su calidad. En cuanto a la actividad debe vigilar que el trabajo se haga en forma planificada, controlada y administrada. Su objetivo, respecto al producto (sistema), es verificar y asegurar que posee un elevado grado de calidad. Respecto a la actividad de construcción, ha de velar para que se realice en forma planeada y controlada, con plazos y costes razonables.

Como ejemplo de preguntas a realizar sobre la actividad de construcción de sistemas y los sis temas obtenidos como producto, pueden citarse:

. ¿Es el sistema interesante para la empresa?. ¿Es el sistema interesante y útil para los departamentos usuarios?. ¿Su funcionamiento es el más simplificado posible?. ¿Es fácil de mantener?. ¿Cuenta con buena documentación?. ¿Es modular (capacidad de crecimiento y reutilización)?. ¿Tiene suficiente flexibilidad (capacidad de absorber las modificaciones que impongan las peticiones y necesidades de los usuarios o la tecnología)?. ¿Hace un uso adecuado de los recursos hardware y software?. ¿Tiene los mecanismos precisos de seguridad, confidencialidad y control?. ¿Están definidos los objetivos del sistema?. ¿Están definidos los participantes en la construcción de sistemas y sus responsabilidades?. ¿Se ha hecho el análisis adecuado? .. ¿Están previstos los procedimientos de planificación, control y administración del proyecto? . ¿Está previsto

el plan de transición del viejo al nuevo sistema?. ¿Está prevista la formación y asistencia a usuarios?. ¿Intervienen todos los implicados (usuarios, técnicos, representantes de explotación, etcétera)?

Es un vicio común en la construcción de sistemas el no prestar la atención precisa a las etapas iniciales del proyecto y pasar rápidamente a hacer el análisis técnico (orgánico).

Ha de tenerse en cuenta que un error u omisión en las etapas anteriores (definición de requi sitos o análisis funcional) suele implicar la adopción de un sistema inútil, o bien el tener que rehacer todo lo que se había realizado hasta la detección de ese error u omisión, por lo que el riesgo que se asume es muy elevado.

Auditoría del proceso de construcción de sistemasEl auditor ha de analizar y asegurarse de la existencia, adecuación y cumplimiento de las funciones de planificación, control y administración de recursos y actividades.

Estas funciones son responsabilidad del jefe <;le proyecto. Ha de tenerse en cuenta que esas funciones consumen tiempo, por lo que deberán estar previstas en el cálculo de cargas de trabajo. Una persona puede dirigir, controlar y supervisar el trabajo de cinco a ocho colaboradores, y esta ocupación normalmente consumirá todo su tiempo útil. La dirección de un proyecto puede estar encomendada a usuarios, técnicos en organización y técnicos en computación.

En rigor, en cuanto a su función propia, el jefe de proyecto precisa solamente conocimientos de técnicas de planificación, técnicas de administración y dirección de recursos, así como técnicas de control de avance de proyectos.

1207


Evidentemente, la primera parte (técnicas de planificación), exige conocer la estructura básica o modelo de realización del proyecto; fases, actividades, técnicas, perfiles de los profesionales que intervienen, etc.

Las demás técnicas son comunes a la dirección de cualquier tipo de proyecto (marketing, ingeniería, etc.).

Principios fundamentales de la gestión de proyectos

En la gestión de proyectos hay que tener en cuenta los siguientes principios fundamentales:

1. El proyecto ha de descomponerse, por medio de un proceso analítico, en partes cada vez más elementales, hasta llegar a tener unidades controlables y medibles; se debe saber cuándo empiezan, cuándo terminan, y en qué grado de realización (porcentaje) se está en un instante dado.

2. Las unidades han de estructurarse en el tiempo teniendo en cuenta precedencias y prioridades. 3. Se estiman coste, plazos y esfuerzos para cada unidad de trabajo y para el conjunto de ellos.

Han de tenerse en cuenta las esperas motivadas por precedencias, y el consumo de tiempo y esfuerzos que implican las entrevistas, reuniones, trabajo de coordinación, etc.

4. Asignación de unidades de trabajo a recursos concretos. Como consecuencia de este puntopuede ser preciso reestructurar las actividades.

. 5. Definición de calendarios, con fechas estimadas para los sucesos más importantes.Normalmente se suelen establecer varios (optimistas, más probable y pesimista), en función delas estimaciones realizadas.

6. Definición, implantación y uso de mecanismos de control, medida y corrección de desviaciones. Para este punto deben sentarse normas y procedimientos de informe de actividad, informe de avances, control y evaluación de cambios, evaluaciones de la realidad frente a lo planificado, ajustes y correcciones, e implantación y seguimiento de normas y estándares, sobre todo tendentes a garantizar la calidad del producto: documentación, modo y técnicas de trabajo, repaso y verificación de las pruebas y validaciones, características del producto (modularidad, flexibilidad, reutilidad, etc.).

¡~

'.

,~

1i!

"

La planificación en la construcción de sistemasjj 1

.

El plan estratégico o computacional identifica y define las líneas maestras de todos y cada uno de los proyectos a realizar, así como los contactos y relaciones entre ellos.

Cada proyecto, por separado, ha de tener un plan a nivel táctico y operacional (medio y cortoplazo), y debe ser posible, estar formalizado, y ser correcto.

Normalmente la descomposición de un proyecto, se suele hacer en tres o cuatro niveles, queson: proyecto, fase, actividad, tarea o paso.

No hay un acuerdo sobre las fases típicas de un proyecto computarizado, cada metodologíatiene las suyas, aunque sí hay ciertas similitudes entre ellas.

.,"I!:,,~

1208

Fases en el proceso de construcción de sistemas

Como norma general, cualquier metodología ha de prever y sistematizar (o dar como realizada por órganos aparte) las tareas siguientes:

1. Estudio de mercado: para el producto que ha de soportarse por medio del sistema computarizado.

2. Estudio de viabilidad o rentabilidad: determinar que es posible y rentable utilizar la funcióncomputacional como soporte del producto en cuestión, y en qué grado y forma.


3. Estudio inicial: estudio breve de los elementos dimensionales del sistema computarizado a implantar; volúmenes, tendencias, funciones, requisitos, cuyo objetivo es proporcionar una definición global de la arquitectura del sistema; presentación de posibles alternativas de solución para que los órganos apropiados elijan la más conveniente; estructuración global.

4. Estudio detallado: una vez definido el modelo elegido, definición de todas y cada una de las funciones a soportar por el sistema; definición de las cadenas en que se resolverá el sistema. Estimación mucho más firme. Escritura de los cuadernos de especificaciones de los programasa realizar. Planes de detalle para la transición del sistema antiguo al nuevo.

5. Realización: programación, prueba e integración de programas, cadenas y aplicaciones.6. Implantación: inicialización de ficheros, formación y entrenamiento de usuarios; transición

paulatina, tal vez con fase en paralelo; medida y evaluación de resultados esperados contra los previstos; corrección de fallos y defectos.

7. Explotación: utilización rutinaria del sistema durante un período más o menos largo de tiempo. En esta etapa hay actividades de mantenimiento (preventivo, correctivo y modificativo), asícomo de seguimiento y medida de resultados.

8. Baja del sistema: al cabo de cierto tiempo se sustituye el producto por otro debido a su obso lescencia técnica; incapacidad de soporte técnico; incapacidad de soportar los requisitos y necesidades de exactitud, tiempo de respuesta, volumen de uso, cantidad de usuarios; o a repetidos fallos o defectos que lo hacen poco fiable.

El conjunto de las ocho etapas citadas se conoce como «ciclo de vida del software». A lo largode esa vida, el auditor computacional ha de revisar la calidad o adecuación del producto, o bien la

calidad o adecuación del método de diseño, desarrollo, implantación y control.

Puntos clave de la buena planificación de un proyecto

Para tener una buena planificación hay que tener muy presente los diez puntos siguientes:

1. La planificación y estructuración ha de realizarse previendo esperas, aprobaciones, reuniones,validaciones, etc.

2. Los representantes de los usuarios han de considerarse como miembros participantes del proyecto, con tareas y responsabilidades asignadas, así como con planificación de los momentosen que han de participar y con qué esfuerzo. Este uso de recursos de usuarios debe ser, lógicamente, conocido y aprobado por los jefes de los mismos.3. A lo largo del proyecto aparecen instantes en que se pueden tomar dos o más caminos diferentes:

a) ¿Centralizar o descentralizar?b) ¿Dispositivos de una clase o de otra?c) ¿Desarrollo propio o contratación de un paquete? d) ¿Modificación de estructura del servicio usuario?

Algunos de estos caminos pueden ser decididos por el equipo de proyecto: otros estarán fijados por las políticas de la empresa, pero otros exigirán la decisión de un nivel superior, deigual forma que si surge una diferencia grave de estimación o apreciación entre miembros del proyecto.

. El órgano con capacidad de resolver o de obtener la resolución de esas alternativas debe estar especificado claramente en la definición del proyecto.

4. Como resultado de los trabajos, aparecerán visiones de síntesis de situaciones reales, apreciaciones, etc., que podrán ser más o menos acertadas, teniendo en cuenta que el estudio de departamentos usuarios, o

el conocimiento de técnicas complejas, como diseño de sistemas online, no es todo lo profundo que debiera por parte de los miembros del proyecto como para poder asumir con

certeza la totalidad de las visiones. En esos casos harán falta valuadores y ase

1209


sores. El jefe de una sección dirá si la visión global de la misma, si las deficiencias a solucionar o las necesidades detectadas son acertadas o no.

5. La estimación de costes, plazos y esfuerzos ha de realizarse a partir de estándares de la instalación; los de otras instalaciones no suelen servir. Como factores a tener en cuenta para estimar un proyecto, los más importantes son:a) Complejidad:. Servicios de la empresa afectados: cantidad, interrelaciones con otros, estructura, cantidad

de puestos de trabajo diferentes, número de efectivos/clase de puesto.. Aplicación piloto en uso de un hardware o software básico determinados.. Inexperiencia en uso de hardware o software determinados de la instalación.. Usuarios que nunca han empleado servicios computarizados.. Aplicaciones en tiempo real.. Tráfico elevado.. Criticidad.. Experiencia y formación de los recursos.. Metodología de trabajo.. Herramientas de ayuda: diccionario de datos, editores, útiles para prueba y depuración,

generadores de programas, paquetes de control de proyectos.. Lenguajes de programación.. Entorno de la instalación: tecnológico, metodológico.b) Cantidad y complejidad de informes y destinatarios de los mismos.c) Cantidad y complejidad de transacciones de entrada.d) Controles y validaciones a realizar.e) Cantidad y complejidad de archivos y bases de datos.f) Necesidades de flexibilidad y crecimiento.

6. Ha de verificarse la adecuación de personas a las actividades encomendadas: experiencia, conocimientos, características humanas: facilidad de comunicación, trabajo en equipo, etc.

7. Ha de verificarse la existencia de mecanismos de comunicación entre los distintos proyectos yentre las partes de cada uno de ellos. La incomunicación se traduce en aplicaciones y ficherosinconexos, trabajos inútiles o duplicados y diseños faltos de calidad.Uno de los principios para lograr una función computarizada de calidad es que se ha de lograr un sistema de información integrada, con redundancias controladas. Se debe lograr un modelo en el ámbito estratégico, táctico y operacional con aplicaciones que compartan información e incluso software.

8. Existencia de un mecanismo dé control de cambios: gran parte de los defectos de un sistema software se introducen en él debido a la incorrecta aplicación de un cambio de especificaciones. Normalmente, se suele hacer un esfuerzo inicial, al arrancar el proyecto, y al realizar cada fase de trabajo, en planificar, analizar, evaluar el impacto del trabajo sobre los elementos organizativos correspondientes, etc. Sin embargo, una vez terminada la fase x, cuando en una fase posterior surge una modificación se realiza a toda prisa, con un análisis superficial, realizado por pocas o una sola persona, con un riesgo elevado de producir efectos no deseables sobre otros elementos del sistema. El auditor debe verificar la existencia y adecuación de un procedimiento que asegure:

. a) Que los cambios lleguen a conocimiento de todos los afectados.b) Que se aprueben y validen por los órganos pertinentes.c) Que se analice su impacto, sobre planes y calendarios, y si es preciso, se reevalúen éstos. d) Que quede un registro adecuado del cambio: fecha, peticionario, validador, motivo, des

cripción, impacto y acciones realizadas.

El registro es muy útil como herramienta para detectar problemas de diseño: un volumen elevado de cambios suele implicar diseños faltos de calidad.

1210


9. Existencia de reuniones de repaso y coordinación: se comunica el estado de las actividades que desarrollan unos miembros del proyecto a los demás, se realizan revisiones cruzadas, se intercambian experiencias y se explican los problemas detectados, con lo que hay posibilidad de que los demás miembros ayuden a resolverlos. La realización de estas reuniones tiene como resultado un aumento de la cohesión y sinergia de grupo y un fuerte aumento de la calidad.

10. Mecanismo de control de proyectos: en un centro de desarrollo con cierto número de personas (a partir de 40-50) puede ser útil emplear una herramienta software, desarrollada en el propio centro o un paquete están dar. Sus ventajas son la estandarización, que obliga a formalizar la planificación y administración por escrito, economiza tiempo y errores, permite realizar simulaciones. El inconveniente principal, aparte del precio del paquete o desarrollo, estriba en que es innecesario para pequeños proyectos.

Auditoría de la calidad de un producto computarizado

El auditor computacional debe realizar revisiones sobre la calidad de las aplicaciones desde fases muy tempranas del ciclo de vida software. Ha de considerarse que el coste de una aplicación puede ser bastante elevado, por lo que si se obtiene como producto algo inútil, se ha realizado un gasto que es muchas veces mayor, que el coste de un posible fraude o error, para los cuales se prevén mecanismos adecuados de control.

Principios clave

El coste de resolución de un error u omisión, cometido en un punto dado de la vida de un producto software, aumenta exponencialmente con el tiempo transcurrido (o el esfuerzo realizado), hasta que se detecta y se adoptan las medidas correctoras precisas. Esto supone que un diagnóstico temprano puede ahorrar cantidades importantes de esfuerzo, tiempo y dinero.

Las funciones de auditoría o de control interno han de intervenir desde las fases iniciales del proyecto, en aspectos determinados, o propios, fijados por hitos (principio o final de una fase, etc.), periódicamente (quincenal o merisualmente) o en aspectos elegidos al azar (muestreos). Evidentemente, el auditor no puede revisar y asegurar la bondad del producto en su totalidad, ya que ello le exigiría uq esfuerzo de magnitud similar al de todo el proyecto, por lo que ha de concentrarse en puntos claves (seguridad, calidad de diseño, control) y verificar que los trabajos se realizan con métodos apropiados que aseguren una elevada probabilidad de éxito.

Definición de calidad

Como síntesis de varias definiciones, se pueden citar como características deseables del software: la utilidad, la fiabilidad, la exactitud, la seguridad, la modularidad, la flexibilidad, la comodidad, el mantenimiento, la dimensión adecuada, la documentación adecuada, la aceptación por los usuarios, la existencia de mecanismos de medida de nivel de servicio de los usuarios, la existencia de mecanismos de cOI1trol interno que proporcionen seguridad, privac~dad, controles de fechas, arqueos, cuadres, etc.

Plan de garantía de calidad del software

Es un plan de aplicación a uno, o a todos los productos software, de un modelo planificado y sis -temático de acciones necesarias para obtener un grado adecuado de confianza de que el producto en cuestión cumple con los requisitos, entre ellos el de calidad.

1211


El contenido del diseño preliminar del modelo propuesto por la IEEE (Asociación de Ingenieros Eléctricos y Electrónicos de USA) consiste en:

1. Propósito: justificación de por qué se decide implantar el plan de garantía de calidad del software. 2. Documentos a que se hace referencia: normalizados, lista de ellos.3. Gestión del plan: organización del plan, tareas, responsabilidades.4. Documentación: propósito, documentación (especificación de requisitos, descripción del

diseño, plan de verificación y validación, informe de verificación y validación, documentación para los usuarios).

5. Otra documentación: plan de desarrollo del software, plan de gestión de configuración delsoftware, normas y procedimientos.

6. Documentación adicional: definición de requisitos del usuario, especificaciones de relaciones externas (ficheros, bases de datos, software).

7. Especificaciones de relaciones internas.8. Manual de entrenamiento.9. Manual de operación.

10. Manual de instalación.11. Manual de mantenimiento.12. Plan de entrenamiento.13. Normas, prácticas y convenios: propósito, contenido (requisitos, diseño, implantación, prue

-ba, documentación).14. Revisiones y auditorías: propósito, requisitos mínimos a revisar (requisitos del software, dise

ño preliminar, diseño crítico, plan de verificación y validación, auditoría funcional, auditoría física).

15. Gestión de la configuración software.16. Gestión de problemas.17. Herramientas, técnicas y metodología.18. Control del software.19. Control físico: acceso no autorizado, daño, inadecuación o degradación.20. Control de proveedores de software.21. Registro, mantenimiento y retención de la documentación de garantía de calidad.

Como se puede observar se trata de un modelo ambicioso, que normalmente no puede implantarse inicialmente en una empresa, sino que es el resultado de una evolución paulatina, ya que es difí cil su aceptación por parte de personas no habituadas a metodologías de trabajo y documentación.

En él se ven involucrados no sólo la función de auditoría computacional sino también los órganos de control interno o control de calidad de la función de desarrollo, así como los propios recursos de desarrollo, sobre todo los jefes de proyecto, que han de prever en su planificación las tareas necesarias para garantizar la calidad.

Lograr la implantación de un modelo planificado de garantía de calidad del software en un centro de desarrollo supone una gran ayuda para lograr la estandarización de productos, y por tanto, su auditoría. Como camino para su implantación, lógicamente deben seguirse las fases siguientes:

a) Propuest¡¡. a la dirección.b) Aceptación por la dirección.c) Presentación al personal de desarrollo.d) Aceptación del personal de desarrollo.e) Planificación de la implantación: identificación de recursos precisos, planificación en el tiem

po, evaluación de riesgos.f) Formación del personal.g) Distribución del plan.h) Ejecución del plan.

1

'11, ,

~

I

1212

f,y~~;,'" ,,',

,;r.

I ,

l

fl '"

J, LJ,J:"¡¡,

~

fÓ

1, "

Auditoría de sistel

Medidas de control interno del software

Debido a que el software de aplicación constituye la plasmación para un sistema computariza de un procedimiento anteriormente realizado en forma manual, ha de dotársele de las medie de control precisas: prevención, detección y corrección de errores, fallos y fraudes o sabotajes

En principio las medidas citadas han de definirse funcionalmente, como si se fueran a impla tar en sistemas administrativos comunes. Ejemplos de ello serían los códigos autoverificados,uso de sumarios de importes y fechas, doble pulsación de datos muy importantes, verificacion de formato y verosimilitud, control de acceso a la información, custodia de documentos negad bles, etc.

Esas medidas funcionales, complementadas con otras que son específicamente precisas por t peculiaridades del proceso computarizado (respaldos, etc.) se traducirán en especificaciones ql ha de cumplir el software.

A continuación se especifican familias de controles a implantar en el software:

1. Controles en entrada: cuadres de totales (importes, fechas, suma de códigos), validación de fo: matas, control de verosimilitud, dígitos de autoverificación, controles de acceso, custodia d documentos según normas legales e internas

2. Controles en procesos: etiquetas (asegurar que se usan los archivos correctos), registro de control (arqueos, secuencia de fechas), tratamiento de errores (detección de transacciones inco rrectas con los archivos maestros existentes), procedimientos de recuperación y re arranque registro para auditoría (debe poderse seguir la pista desde un suceso hasta su origen), contra les de integridad (contadores de registros, etc.), histórico de cantidades (hoy = ayer + moví mientas de hoy), seguridad lógica (control de acceso y de autorización)

3. Controles en salida: etiquetas y títulos (asegurar que se tratan los archivos o listados correctos), cuadres y conciliaciones, informes sobre cantidades y calidad de informes emitidos, con objeto de asegurar que se envíen todos y que son correctos, distribución (instrucciones y controles pertinentes), custodia de documentos negociables, formularios numerados, instrucciones para garantizar la confidencialidad.

4. Debido a las peculiaridades del proceso de datos, hay que prestar gran atención a los controles de recuperación y rearranque. En efecto, en cualquier momento puede estropearse un disco magnético, que contiene una gran cantidad de información (cientos de millones de caracteres), o un programa que está actualizando un fichero puede acabar anormalmente, dejando el fichero que se está actualizando en un estado extraño (parte actualizada y parte sin actualizar). Por otra parte, hay procesos de gran duración (6, 7, 10 horas) que pueden terminar anormalmente, por ejemplo, después del 90% de ese tiempo. Hay que tener prevista una solución a todos esos problemas.Para controlar la amenaza de soporte destruido, se tienen respaldos (backups) o copias de los ficheros, de manera que se puede trabajar con esas copias.En caso de que termine anormalmente un programa que está actualizando un fichero, se implantartlos denominados checkpoints, (puntos de chequeo), lugares en los que se puede comprobar que hasta ese momento el proceso realizado es correcto. Si el error se produjera en un instante posterior, sólo se tendrá que relanzar el trabajo a partir de ese punto, sin necesidad de repetir el trabajo anterior. Normalmente se suelen utilizar ckeckpoints cada cierto tiempo (10-15 minutos), o cada cierto número de registros procesados.Otro de los aspectos a prever es el de la retención de ficheros durante cierto tiempo. Los sopor tes de información deben guardarse durante' el tiempo preciso para asegurarse de que si se detecta una incorrección en un fichero posterior, éste se pueda regenerar adecuadamente.

1213

CAPÍTULO 54

Auditoría de la organización y administración, entorno operativo y control de gestiónGERARDO GÁLVEZ MENESES

Ingeniero Comercial Universidad de Chile

EUGENIA LINDEGAARD VEGA

Ingeniero Comercial Universidad de Chile

Auditoría de la organización y administración /54-1216

Problema~. asociados a la organización y administración /54-1216

Aspectos <I¡ considerar /54-1216Estructura /54-1216Definición de funciones y responsabilidades / 54-1216 Normas y.procedimientos internos / 54-1217Dotación y asignación de recursos humanos y materiales Políticas de personal/ 54-1218Relaciones con usuarios / 54-1218Relaciones con proveedores /54-1219

/54-1217

Auditoría del entorno operativo /54-1219Seguridad /54-1220Planes de contingencia /54-1221Configuración, adecuación y uso del parque computacional Configuración y uso del hardware /54-1222 Configuración y uso de software básico /54-1223Red de comunicaciones /54-1224

/ 54-1222

Auditoría del control de gestión /54-1225 Control de objetivos / 54-1225Control de rendimientos / 54-1226 Control de presupuestos /54-1226 Imputación de costes /54-1227

1215


Auditoría de la organización y administraciónUna definición de la misión de la organización es la de «garantizar la adecuada disposición y uso de los recursos factoriales en orden a lograr el máximo nivel de eficacia, según los objetivos y políticas fijadas».

La administración, por su parte, se encarga o trata de las relaciones económicas con clientes y proveedores, así como con los propios miembros del departamento.

Problemas asociados a la organización y administración1. Ineficacia: se define la ineficacia como la incapacidad de cumplir objetivos razonables a coste

razonable. La ineficacia se puede traducir en costes no razonables, plazos no razonables, calidad insuficiente e incapacidad de afrontar el volumen de trabajo o servicio demandado

2. Personal desmotivado o descontento: hay que tener en cuenta que un centro de proceso de datos es uno de los puntos importantes de la empresa. Está dotado de equipos costosos y maneja volúmenes grandes y críticos de información. Ante las posibilidades de los equipos, se ha encargado al centro de proceso de datos de cubrir servicios vitales, como el soporte de atención y gestión de cuentas, clientes, etc.El personal computacional está pues, en una posición privilegiada para ocasionar trastornos importantes a la empresa, por medio del sabotaje, sin realizar acciones violentas ni a veces detectables.

3. Fraude: Es preciso tenerlo en cuenta, puesto que los estados de contratos económicos (cuentas, etc.) están implantados como información sobre soportes computarizados, a veces accesibles con facilidad por personas con ligeros o medios conocimientos técnicos. También es posible que se realice por medio de pagos supuestos o no procedentes a proveedores.

Aspectos a considerarEn una auditoría de la función de organización y administración se deben considerar los siguientes aspectos: .

Estructura .\;~

La adecuación o inadecuación de la articulación de órganos, sus flujos de trabajo, funciones, etc., debido a que pueden introducir puntos fuertes o débiles.

Definición de funciones y responsabilidades

! I

;\\11

Una adecuada definición de funciones y responsabilidades tiene dos efectos fundamentales: la disminución del riesgo de fraude, que se logra separando las funciones de ejecución y control, y el aumento de la eficacia y motivación que se produce cuando el personal tiene claros sus ámbitos de actuación y sabe qué puede y debe hacer. Además es importante en cuanto a criterios de eficacia. para evitar solapamientos y áreas sin cubrir.

El manual de funciones debe estar aprobado, además conocido y utilizado en caso de conflictos y para la determinación de categorías y puestos de trabajo.

Respecto a su contenido, ha de ser completo. es decir, debe tener previstas todas las funciones precisas. sin solapamientos, ser claro y definir qué tipo de acción ejecuta cada puesto implicado. Desde el punto de vista del auditor, ha de prestarse especial atención a la separación de las funciones de control y de ejecución.

i,1

,,:, ii¡'~

1216 ,mi,I',.-

Auditoría de la organización y administración, entorno operativo y control de gestión

Una herramienta útil para plasmar la distribución de funciones es la matriz de responsabilidades en que se indica la responsabilidad del puesto en la función (realiza, asesora, colabora, aprueba, controla), prestando atención además de a los solapamientos posibles, a los aspectos sin cubrir.

Normas y procedimientos internos

Su existencia, la adecuación y el cumplimiento son decisivos para asegurar una gestión eficaz, una estandarización, el flujo de información ascendente, descendente y horizontal. Definen y fijan requ:isitos de calidad, método de trabajo, circuitos de información y tratamientos, etc.

Son vitales para lograr un funcionamiento coordinado de los elementos del departamento,niveles de calidad aceptables, así como para garantizar la capacidad de mantener los sistemas.

Deben determinar también las normas administrativas, de forma que una persona recién ingresada puede encontrar información suficiente sobre los fines, medios y costumbres del departamento.

Como contenido típico de un manual figuran al menos los siguientes apartados:

1. Descripción del manual: índice, justificación, actualización (procedimiento de recogida desugerencias), distribución.

2. Procedimientos generales del departamento: estrategias, política y estructuras.3. Procedimientos y normas relativas a administración.4. Procedimientos y normas relativas a explotación: documentación, controles y verificaciones,

configuración hardware, entrada de datos, ejecución, salida de información, biblioteca desoportes.

5. Normas y directrices para'uso de los recursos hardware y software.6. Biblioteca de software.7. Nomenclatura de elementos computarizados (sistemas, aplicaciones, cadenas, pasos, progra

mas, <etc.).8. Uso de recursos de tiempo compartido.9. Procedimientos relativos a construcción de sistemas: dirección de proyectos, descomposi

ción de proyectos, metodología de desarrollo y realización, documentación de desarrollo.10. Procedimientos administrativos generales relativos a gestión de personal, aprovisionamien

to, seguridad y coordinación y comunicación.

Dotación y asignación de recursos humanos y materiales

Puede haber varios métodos de reclutar personas y de asignarlas a actividades concretas del departamento. El resultado puede ser el de tener personas infrautilizadas mientras otras están sobrecargadas de trabajo.

Una de las causas que originan mayor grado de ineficacia suele ser la falta o inadecuación de los procedimientos de control de la carga de las personas, encontrándose repartido el trabajo de forma tal que durante unos meses hay una presión enorme seguida por etapas de ocio casi total.

Hay cargas de trabajo generalizados a fin de semestre y, sobre todo, a fin de año, ya que se suelen fijar en esas fechas las entregas de trabajos. .

Con una adecuada planificación, que no implique la terminación de todas las actividades en las mismas fechas para todos los proyectos, sino que se esparzan a lo largo del año, se eliminan las sobrecargas totales del departamento.

Otra forma de actuar consiste en la implantación de circuitos y procedimientos de medida de actividad para determinar quienes están sobrecargados y quiénes ociosos. Esta actuación se complementa :con una disciplina de asignación y liberación de recursos.

1217


Políticas de personal

Este punto puede influir sobre el grado de satisfacción o descontento de las personas. Puede también ahorrarse una importante cantidad de tiempo si están escritas las políticas de selección, formación, promoción, premios y sanciones, y terminación de empleo.

En cuanto a la selección debe estar claro desde el principio si las convocatorias para cubrir pla zas en el departamento han de ser presentadas primero al personal de otros departamentos de la empresa y realizarse exámenes restringidos, o si se podrán ofrecer al exterior de la empresa.

Deberá determinarse también la participación de representantes de trabajadores en los procesos de selección.

Cuando se pueda esperar la capacitación correspondiente para los puestos de programador de aplicaciones e, incluso de analista de aplicaciones y analista funcional, puede ser rentable elegir gente con trayectoria interesante en la empresa y darle formación computacional. Estas personas sienten afección por la empresa y conocen el negocio, circuitos y procedimientos administrativos, por lo que si bien tardarán más tiempo en comenzar a rendir los primeros resultados, llevan adelantados unos conocimientos de la empresa que presentan un gran valor potencial.

Al contrario, los puestos fuertemente técnjcos, programadores y analistas de sistemas, técnicos en software básico, gestión de configuraciones, bases de datos y teleproceso, que exigen un largo tiempo de formación y experiencia, han de cubrirse con personas del exterior de la empresa.

La formación es otro punto clave en el departamento. Gran parte del éxito o fracaso de un sistema y, sobre todo, su eficacia y consumo de recursos está ocasionada por la experiencia y conocimientos de los profesionales implicados.

En general, deben estar definidos tanto las carreras profesionales, conocimientos y capacidades precisas para cada puesto de trabajo y caminos de formación para lograrlos, como los procedimientos de planificación de la formación de cada persona (definición, calendario, registro de resultados y aprovechamiento, etc.), procedimientos de elección del catálogo de cursos de interés, a partir de la oferta externa e interna, las medidas del grado de utilidad y satisfacción y los procedimientos administrativos (presupuesto, inscripciones, avisos a los alumnos, pagos, etc.).

La definición de los planes de formación comienza con una definición apropiada de puestosde trabajo. /'

En cuanto a la promoción, suele existir una equivalencia fija entre puesto de trabajo (función realizada) y escala retributiva (salario). Para evitar esto se puede establecer un 'sistema que permita variaciones de nivel salarial, sin necesidad de cambiar de puestos de trabajo.

Deben estar previstos los procedimientos (y respetarse), de evaluación del personal, criterios de promoción, control de calidad del trabajo, etc., de forma que nadie pueda cuestionar razonablemente un premio o sanción.

Igualmente, en caso de existir retribuciones variables, debe estar definido sobre la base de qué,por quién y en qué cuantía se concederán.

Han de estar definidos claramente qué conductas serán merecedoras de sanción y qué clase desanción.

.1

"'¡'~ I ]

I

,~

Relaciones con usuarios

La imagen que el usuario tiene de la calidad y nivel de servicio que le proporciona la función computacional viene determinada principalmente por dos factores: funcionamiento, para el exterior de explotación, y trato que recibe en sus relaciones personales con el departamento (consultas, peticiones no rutinarias, modificaciones pequeñas, participación en el desarrollo de aplicaciones, etc.).

La indefinición de un interlocutor único, en los niveles de área de negocio, desarrollo y explotación hace que el usuario no sepa a quién consultar. '

La solución a estos problemas estriba en la creación de una función, con la dotación de recursos que precise, de atención al usuario, de forma que centre y distribuya todas las consultas rela

it"

¡1'~ ~

1218


tivas a explotación. Además, deben determinarse interlocutores únicos y estables, a nivel área de negocio, e implantarse mecanismos adecuados de control de cambios y problemas de desarrollo.

Relaciones con proveedores

Las relaciones han de ser de tipo contractual, de compra, alquiler o prestación de servicios. En ellas ha de determinarse:

1. Cómo, quién y sobre la base de qué contrata. Esto define los circuitos y procedimientos a seguir para contratar algo con un proveedor. Normalmente se destina un presupuesto anual para contratos de este tipo, que se entrega al departamento para que disponga de él en determinadas condiciones, como suelen ser no sobrepasar el presupuesto o pedir conformidad si se sobrepasa un tope fijado. Debe indicarse cómo se elaborarán los pliegos de condiciones a presentar a proveedores, cómo y quién evaluará las ofertas recibidas y qué trámites (asesoría jurídica, etc.) han de seguirse antes de su aceptación.Como norma, no se suelen admitir contratos sin haber evaluado varias alternativas, y en el caso de software, sinhaberlo probado durante cierto tiempo. Deben quedar registros de las pruebas efectuadas, de los r,esultados obtenidos, de los estudios de rentabilidad, etc., indicando quién se responsabiliza de ellos. El auditor ha de prestar atención a estos procesos.Es importante, dada la criticidad de la ÍLmción computacional, que nunca se hagan contratos con un solo suministrador. Han de diversificarse los proveedores para minimizar la probabilidad de desasistencia, falta de servicio por huelga, sobrecarga del proveedor, etc. Todo ello debe hacerse incluso cuando se trata de alta tecnología puesto que existen en el mercado máquinas compatibles.

2. Cómo han de ser los contratos. El auditor ha de hacer presión para que se encuentren contempladas no sólo las típicas cláusulao¡, legales, sino las que confieran al contrato la capacidad de que su cumplimiento sea mensurable. En un contrato típico figurarán las siguientes cláusulas:

a) Plazos de entrega, instalación y entrada del objeto en cuestión a pleno funcionamiento, b) Penalizaciones en caso de incumplimiento de plazos.c) Compromisos mensurables de calidad y capacidad.

o Fiabilidad: tiempo medio entre fallos (MTBF), tiempo medio de reparación (MTTR).. Penalizaciones si hay incumplimientos.. Capacidad: almacenamiento real para usuario, proceso, configuración (variabilidad), crecimiento y cambio.

d) Compatibilidad: protocolos y estándares que soporta y cumple.e) Coste: alquiler, mantenimiento y compra.

En el caso de compra de software figurarán, además:

a) Formatos que se entregan: fuentes o ejecutables. b) Documentación que se entrega.c) Máquinas y sistemas operativos que lo soportan.

Auditoría del entorno operativoSe entienden por entorno operativo los elementos físicos, o sea, máquinas, redes de comunicación, edificios, soportes físicos de información y hasta las personas precisas para la ejecución y funcionamiento de los sistemas computacionales en régimen de producción,

La misión del auditor computacional consiste en velar para que el entorno sea seguro, fiable, eficaz y adecuado a las necesidades de la empresa.

1219


El entorno operativo puede verse afectado por:

1. Siniestro o catástrofe natural (fuego, inundación, derrumbe).2. Atentado.3. Sabotaje.4. Falta de capacidad: no poder satisfacer la cantidad de servicios demandados.5. Falta de disponibilidad: frecuentes averías, que impiden el uso a lo largo del tiempo que se

espera del sistema.6. Errores: salidas no correspondientes a las entradas recibidas.7. Robos: de equipos, de información, de tiempo de máquina (robo de uso), de consumibles, de

documentos.a. Fraude: uso de sistemas computacionales para realizarlos.9. Pérdida de confidencialidad: difusión de información reservada.

10. Falta de adecuación: costes excesivos, plazos excesivos, falta de calidad.

Todos los factores mencionados pueden incidir sobre aspectos relacionados con la seguridad (física y lógica), planes de contingencias, configuración y uso de hardware y software básico, y redde comunicaciones.

Seguridad

Se refiere a las medidas orientadas a minimizar los riesgos de pérdida de capacidad de proceso, pérdidas materiales debidas a siniestros, catástrofes, atentado, sabotaje, y pérdidas de confidencialidad, fraude y robo. Estas medidas deben proteger a las personas, los soportes de información, las instalaciones y los equipos, en ese orden de prioridad.

Para lograr un adecuado nivel de cobertura de riesgo hay que tener en cuenta que:

1. Las medidas de seguridad tienen un coste. La adopción de límites adecuados, más o menos próximos al 100% para la cobertura de riesgos, ha de hacerse en función de la naturaleza del negocio y del coste que implican las medidas adoptadas.

2. Una adecuada disciplina organizativa es el soporte preciso para la implantación de medidas deseguridad. Si ésta se consigue, se obtienen importantes disminuciones de determinados riesgos.

3. La existencia de dispositivos duplicados, caminos alternativos de acceso a la información ycopias de los soportes es indispensable.

4. Los planes de contingencia son vitales.

Hay ciertas medidas claves a tener en cuenta en este sentido, tales como:

a) Discreción, evitando visitas multitudinarias, no convertir a los centros en escaparates, noefectuar publicidad, etc.

b) Dirección consciente de las amenazas y de las medidas de seguridad. Puede ser indispensable adoptar medidas impopulares o costosas que han de contar con el apoyo de la dirección.

c) Realización de simulacros y revisiones de la utilización y activación de los planes y medidas de seguridad. En muchos centros los dispositivos de extinción están desconectados o el

personal no sabe qué hacer si suena la señal de incendio.d) Atención a los problemas de descontento del personal. e) Adecuada definición de funciones y responsabilidades, con separación de las funciones

de ejecución de las de control.f) Adecuada protección contra intrusos, o accesos no autorizados a una parte del personal,

áreas restringidas, barreras físicas y vigilantes.g) Dirección de explotación (o alguien en concreto) que sea responsable de la dirección y coor

dinación del programa de seguridad.

1220


Planes de contingencia

El propósito de estos planes es proporcionar directrices definidas que permitan a la dirección, técnicos y usuarios afrontar la degradación de sistemas, hardware, comunicaciones y servicios, así como los fallos y situaciones adversas ocasionadas por circunstancias accidentales o deliberadas.

Contienen un análisis de los síntomas, situaciones adversas, efectos que originarán y acciones y actores que puedan intervenir para controlar estas situaciones. Deben permitir la detección, diagnóstico y actuación, y con ellos se pretende:

1. Minimizar el impacto de las amenazas sobre la empresa.2. Limitar la extensión del conflicto, los daños causados y prevenir su propagación. 3. Proporcionar modos alternativos de funcionamiento.4. Proporcionar una degradación controlada.5. Adiestrar y familiarizar al personal con los procedimientos de emergencia.6. Proporcionar una rápida y controlada restauración del servicio.

Posibles situaciones a tratar en planes de contingencia son: incendio, averías físicas, error o fallo de aplicación, destrucción de un fichero o disco, etc.

Realizar y poner en marcha un plan completo de este tipo puede ser complicado, ha de plani ficarse y realizarse en un tiempo de uno a dos años y ser constantemente actualizado implantando nuevos elementos susceptibles de fallos y aportando nuevas experiencias y mayores conocimientos. El método de trabajo para realizarlo consiste en:

1. Realizar un análisis de la criticidad de los servicios computarizados proporcionados, clasificándolos en vitales, importantes y anexos, además tener en cuenta si no admiten demora, o si se pueden atrasar 24, 48 o más de 48 horas.

2. Realizar un estudio considerando las prioridades antes asignadas de riesgos sobre los sérvicios, impacto sobre la empresa y definición de posibles medidas de control para afrontar y minimizar los riesgos.

3. Elegir de entre las posibles medidas, a la vista de sus costes y efecto sobre el riesgo, cuál o cuales se implantarán.

4. Plasmar los resultados en planes.5. Difundir los planes y formar al personal.6. Revisar periódicamente los planes y realizar simulacros para probar su eficacia yel grado de

entrenamiento de las personas implicadas en su ejecución.

Cada plan deberá contener:

1. Listas de acciones a ejecutar, con las personas que intervienen en las mismas, y sus responsabilidades en la ejecución. .

2. Listas de personas o entidades a quien se debe avisar (servicios públicos(policía, hospitales,etc.), dirección del departamento o de la empresa, técnicos, proveedores). 3. Lista de lugares en que se hallan

los respaldos a conseguir (confidencial). 4. Lista de maquinaria a reemplazar.5..Lista de procesos a realizar en los respaldos.

6. Lugar en que se proporcionarán servicios de apoyo o proceso de información.

Debe quedar perfectamente claro quién tiene la responsabilidad de desencadenar la ejecución de un plan de contingencia, ante qué situación y cuándo se considerará terminada la contingencia, lo que ocasiona la terminación de la ejecución del plan y la vuelta a la situación normal.

El auditor computacional debe verificar la existencia de medidas y planes reales, completos, conocidos y con personas entrenadas en su ejecución.

1221

Auditoría cornputacional o ínforrnatizada

La actuación no ha de limitarse a realizar un estudio sobre una muestra, sino que debe verificar la cobertura razonable de los riesgos posibles. Así mismo, debe probar la eficacia de los mismos por medio de simulacros, arqueos y verificaciones, asegurándose de que los respaldos previstos existen realmente.

Una medida interesante consiste en presentarse un día inesperadamente para retirar los ficheros existentes de un proceso determinado y hacer que ese proceso se ejecute ese día según los procedimientos previstos en los planes de contingencias. Suele ocurrir que faltan ficheros o que fallan los procedimientos de trabajo.

De igual modo, se puede simular el mal funcionamiento o avería de un elemento físico determinado (canal, unidad de control, etc.), con objeto de comprobar si las medidas de funcionamiento de degradado son eficaces.

Una de las formas de conseguir respaldos de equipos consiste en lograr contratos de asistencia mutua con una instalación similar. Por ese contrato cada uno de los centros se compromete a que, en caso de necesidad del otro, se le permitirá el uso de determinados recursos en una cantidad y forma 'pactada.

Configuración, adecuación y uso 'del parque computacional

El auditor debe verificar que:

1. La configuración deLhardware sea adecuada y equilibrada.2. Se hace un uso adecuado de los recursos existentes.3. Existe un control riguroso sobre el parque en cuanto a su ubicación (dónde están las máquinas,

sobre todo las distribuidas) y a su estado (operativas, averiadas, pedidos pendientes de instalación).4. La configuración contempla la existencia de caminos alternativos y dispositivos alternativos,

para el caso de averías. .

5. Hay un control del consumo y uso de recursos, se conocen sus tendencias y se tienen previstas las necesidades de crecimiento.

Dado que cualquier elemento del hardware puede averiarse, hay que prever que se pueda uti lizar un dispositivo similar no averiado para acceder a los datos o dispositivos dependientes del averiado.

Configuración y uso del hardware

Lo normal es que el auditor computacional solicite la asistencia de un técnico en configuración y software básico, a los que consultará:

1. Si la configuración es adecuada.2. Si hay desequilibrios (elementos muy cargados y otros similares descargados).3. Si están previstos los caminos alternativos para casos de avería.4. Si hay: correspondencia entre las características de los distintos elementos (capacidad de acce

so, velocidad de acceso, velocidad de transferencia de datos, etc.).

Luego se pueden examinar las medidas de carga de las máquinas y el dimensionamiento de losdistintos elementos, en función del uso que se realiza de los recursos disponibles.

Hay una serie de módulos del sistema operativo (de contabilidad) que proporcionan información detallada sobre el uso de recursos (carga de UCP, carga de canales, de discos, etc.).

Esa información ha de vigilarse para tratar de predecir la carga futura, y prever ampliaciones yconfiguraciones nuevas, con la antelación suficiente, y teniendo en cuenta que:

1222


1. El dimensionamiento ha de hacerse de forma que se puedan cubrir las demandas en horas ydías de máximo sobrecargo.

2. El dimensionamiento debe hacerse previendo unas holguras, una vez previstas las variacionesen el futuro, como cobertura de posibles riesgos en la tendencia.

3. Los plazos de entrega, instalación y puesta en marcha de determinados equipos pueden ser largos.

Configuración y uso de software básico

El software básico comprende los sistemas operativos, sistemas de gestión de bases de datos y de comunicaciones. Su incidencia sobre el rendimiento del parque computarizado es crítica, ya que se configuran por medio de gran número de parámetros a los que los técnicos dan valor. La elección de un valor incorrecto para alguno de esos parámetros puede ocasionar una caída exagerada de la capacidad de proceso o un incremento desmesurado de los tiempos de respuesta.

Los parámetros que se definen son, por ejemplo, gestión de prioridades, distribución de capacidad entre los programas ejecutándose concurrentemente, preferencia a tiempo real o a tiempo diferido, gestión de colas, etc.

Al gobernar los sistemas operativos todos los programas que se ejecutan dentro de los computadores, y al realizar la misma función respecto a la gestión de mensajes y transacciones, los gestores de comunicaciones, o peticiones de acceso o actualización a bases de datos, cualquier pequeña alteración introducida en alguno de ellos puede provocar graves efectos sobre los programas gobernados,

La gran complejidad de las interacciones entre los componentes del hardware básico, y entre éstos y los programas y transacciones o mensajes gobernados, hace que pueda ser difícil el diagnóstico de la causa de los posibles errores, y, a partir del diagnóstico, su corrección.

Un técnico con suficiente experiencia y conocimientos puede introducir alteraciones con comportamiento errático, de forma que sea más difícil todavía su detección.

Del mismo modo, se pueden introducir modificaciones en el software básic(j" con fines fraudulentos, tales como introducción de transacciones falsas, borrado de registros para pistas de auditoría, salto de las protecciones software para prevención de acceso a datos sensibles, o introducción de transacciones restringidas, modificación de asientos, saldos de cuentas o cantidades, etcétera.

La posibilidad de realizar una alteración incorrecta, de forma no intencionada, o sea, de introducir un error, puede producir graves efectos, que pueden llegar, incluso, a la paralización del sistema.

Como medidas de control para afrontar estas amenazas pueden citarse:

1. Realizar periódicamente comparaciones entre copias fidedignas del software y las copias quese están ejecutando para detectar cualquier variación entre ellas.

2. Restringir fuertemente el uso de determinados programas de utilidad, ya que estos, manejados por técnicos experimentados, pueden modificar el contenido de bibliotecas, saltándoseincluso medidas de protección.

3. Imponer un procedimiento único y controlado de altas y modificaciones sobre las bibliotecas de programas reales.

4. . Imponer la norma de que los trabajos sobre' archivos reales sólo se ejecuten desde las bibliotecas reales, que están protegidas de modificaciones no autorizadas.

5. Revisar, por medio de programas de selección, los logs (historiales) del sistema para ver si se hanproducido situaciones irregulares o intentos de violación de medidas de protección de acceso. 6. Analizar los

fallos producidos, que pueden indicar errores o intentos de fraude o sabotaje 7. Perseguir los intentos de acceso no autori~ado a datos o procesos.

8. Usar asesores externos para estudiar la adecuación de la definición, configuración y uso delsoftware básico.

1223

Auditoría computacional o informatízada

9. Implantar estrictas medidas de control administrativo sobre protección de confidencialidady acceso o modificación de archivos reales.

10. Cifrar la información crítica para que no pueda ser comprensible ni aún en el caso de que seobtenga acceso o copia fraudulenta.

11. Control del personal de mantenimiento de software básico que no pertenezca a la empresa. 12. Control estricto de los programas que entran en modo autorizado.13. Verificar el comportamiento del sistema ante sobrecargas de trabajo. La sobrecarga puede

ocasionar que se realicen procesos que no entran en funcionamiento normalmente, y que, por tanto, están insuficientemente piobados.

, Red de comunicaciones

El impacto de la factura anual del concepto «transmisión de datos» en una empresa con teleproceso y un número importante de terminales puede ser elevado.

Se pueden tener varias posibilidades a la hora de configurar una red, lográndose para cada tipode configuración costes dispersos.

En función de las características concretas de cada problema a solucionar, puede haber casosen que las redes privadas, o una combinación de red privada y pública, puede ser más barata.

- El auditor debe preocuparse de aspectos como:

1. Topología y dimensionamiento de la red.2. Uso de red pública y de red privada.3. Estudio de cargas y posibles saturaciones.4. Seguridad y confidencialidad de la información y de la red.

En cuanto a la topología, la forma física de la red y las interconexiones entre sus elementos pueden afectar en gran manera su coste, eficacia y capacidad de elegir caminos alternativos en caso de avería de líneas o de elementos inteligentes (controladores, concentradores, etc.).

Actualmente, los terminales tienen cierta capacidad de funcionamiento autónomo, de formaque aunque haya un corte en la línea, pueden continuar realizando algunas de ~us tareas.

De igual modo, los controladores inteligentes (tienen capacidad de proceso y memoria) realizan funciones de concentración de datos, de forma que la línea que los conecta al ordenador central tiene una alta velocidad, y las líneas que unen el controlador con los terminales, inferior.

En cuanto al dimensionamiento, cargas y saturaciones, la capacidad de transmisión de datosse mide en baudios (bits/segundo).

La carga de tráfico de datos afecta al tiempo de respuesta, que tiene comportamiento exponencial, por lo que han de estudiarse los posibles cuellos de botella (controladores, concentradores, líneas, etc.) y dotarlos de la capacidad necesaria para afrontar el tráfico actual y el previsible en el plazo de tiempo que se contemple.

En una red con cientos de líneas y controladores, de los que penden millares de terminales, abundan las averías, sobre todo en los dispositivos con parte mecánica (impresora). Deben estar previstos y ser utilizados los mecanismos de control de estado de la red, como detección, diagnóstico y reparación de averías,. controlando el trabajo de los técnicos propios, de las casas de mantenimiento y de la telefónica.

Dada la complejidad del problema, existen minicomputadoras con software especialmentediseñados para realizar estas tareas.

En el caso de líneas telefónicas públicas, los datos circulan y se almacenan temporalmente encomputadores y controladores de la compañía, por lo que la vulnerabilidad aumenta.

Como norma, toda transmisión de información confidencial o que implique movimientos odisposición de dinero, ha de hacerse en modo cifrado.

El problema de prevención, detección y corrección de errores introducidos por los componentes de la red (módem, líneas, etc.) está usualmente tratado por los protocolos estándar de

1224


comunicación de datos que prevén la transmisión de información redundante, de forma que cualquier variación, por error, en el contenido de los mensajes, sea detectada, y en algunos casos, corregida.

Auditoría del control de gestiónLa implantación de adecuados mecanismos de control de gestión permite manejar los problemas asociados a esta función, como son:

1. Costes excesivos o desequilibrados.2. Plazos excesivos.3. Incapacidad de cumplir objetivos.4. Utilización poco eficaz de los recursos.

Para ello el control de gestión debe estar plasmado en normas y procedimientos que permitan un control de objetivos, tanto de nivel de servicio en explotación, como de calidad y cantidad de proyectos de desarrollo realizados. Estas normas y procedimientos deben permitir además un control de presupuestos, de proyectos, de pedidos pendientes, de rendimientos y la imputación de costes a usuarios.

La información de todos estos puntos debe estar integrada y tratada por el sistema interno de información de gestión, permitiendo a la dirección del departamento conocer en cada momento el estado del mismo y sus niveles de eficacia.

Control de objetivos

Los mecanismos de control de objetivos pueden consistir en procedimientos adminIstrativos basados en trabajos manuales sobre los indicadores de cumplimiento (tiempos, coste, productividad, tasa de errores, etc.) y con revisión periódica de los mismos, o en sistemas mecanizados, basados en paquetes o desarrollos propios de control de proyectos.

En el caso .de explotación, los objetivos de disponibilidad se suelen fijar en el ámbito de equi pos centrales, con lo cual los datos se pueden obtener a partir de los informes de los módulos de contabilidad del sistema operativo, que guardan información de los fallos habidos. Hay paquetes que permiten tener esa información con una elaboración mínima.

Si se quieren obtener informes reales sobre los tiempos de respuesta a transacciones, esos tiempos han de tomarse en los terminales, manualmente, por muestreo, o en caso de terminales inteligentes, grabando registros de tiempos en el momento de empezar a sacar la respuesta por el terminal de salida, y procesando luego todos esos registros para calcular los tiempos de respuesta.

En el caso de trabajos en tiempo diferido, la implantación de las llamadas hojas de trabajo, físi -camente o como registros en un soporte mecanizado (sobre los que se va anotando los instantes de creación en el usuario final, entrada en producción, entrada en operación, entrada en distribución y recepción por el usuario final) permite el análisis de cumplimiento de plazos.

Respecto a los objetivos de cantidad de servicio proporcionado, las ya citadas rutinas de con-tabUidad del sistema operativo proporcionan información sobre cantidad de trabajos o transacciones procesados, así como sobre unidades de imputación de consumo de recursos empleadas en cada uno de ellos.

Para el caso de desarrollo, los objetivos se deben expresar en términos de calidad (tasa de errores, tasa de fallos), plazos de entrega y cantidad de proyectos realizados.

Se pueden tener medidas orientativas sobre la calidad del diseño y realización del software a partir del número de fallos y errores producidos, del nivel de satisfacción del usuario y, sobre todo, del tiempo y esfuerzos dedicados a mantenimiento correctivo.

1225


Un sistema de control de proyectos en el que se introduzcan los pedidos recibidos y en el que se pueda registrar información de tipo histórico sobre los problemas detectados, recursos consumidos, plazos teóricos y reales de entrega, etc., es la base del análisis de cumplimiento de objetivos de desarrollo.

Los síntomas preocupantes, desde el punto de vista del auditor, relativos a control de objetivos son:

1. Ausencia de objetivos formales.2. Objetivos virtuales, se imponen pero no se controla su cumplimiento.3. Inexistencia de mecanismos de evaluación y estimación de plazos, esfuerzos y consumos4. Falta de mecanismos definidos de control de cumplimientos.5. Falta de mecanismos de autorregulación, medida de desviaciones de la situación real con la

prevista y actuación correctora.

Control de rendimientos

Deben existir unos estándares aceptados de.productividad media de personas y equipos. En forma continua, muestral o ante determinadas circunstancias, deben existir mecanismos de medida de la actividad realizada, comparación con los estándares, análisis de desviaciones y acciones correctivas (que pueden consistir en revisar los estándares).

La forma de implantar los estándares debe ser:

1. Determinación de las magnitudes a controlar.2. Fijación de unos estándares iniciales, a partir de muestreos o de datos obtenidos de negocios

similares.3. Definición de circuitos y procedimientos de informe de la actividad realizada.4. Arranque inicial del sistema (rodaje en que se determina si hay grandes discrepancias entre los

estándares iniciales y la realidad; se analizan las discrepancias yse actúa en consecuenciamodificando los estándares o modificando los métodos de trabajo).

5. Publicación de los estándaresal terminar la fase de rodaje.6. Puesta en marcha del sistema.7. Explotación del sistema, previendo su mantenimiento y ajuste.

Para personas de desarrollo como medidas de rendimiento pueden definirse las siguientes:

1. Líneas de codificación desarrolladas.2. Cuadernos de especificaciones desarrollados. 3. Diseños de archivos realizados.

Control de presupuestos

Las tasas de incremento del presupuesto de la función computacional suelen ser preocupantes. No resulta extraño encontrarse presupuestos que se han triplicado en 4 años, a veces sin un aumento ostensible de la utilidad de la función para la empresa.

La evolución de la tecnología, de los nuevos productos y de los servicios de teleproceso hacen fluctuar la distribución porcentual de los costes entre los distintos apartados. Se presentan ciertas tendencias:

1. Los costes de equipos por unidad de servicio que proporcionan, disminuyen en forma acelerada, mientras que los salarios aumentan. 2. La velocidad y capacidad de los equipos aumenta en forma

acelerada. 3. La productividad del personal computacional aumenta sólo ligeramente.

1226

",...


Estas tendencias hacen que se deba prestar atención a comunicaciones, paquetes y personal, debiendo existir políticas para:

1. Aumentar la productividad del personal.2. Sustituir tareas manuales por tareas mecanizadas, con menos consumo de recursos humanos. 3. Atender al diseño de redes.

El auditor debe analizar la composición de las partidas que integran el coste computacional, determinar su equilibrio, las tendencias (coherentes con las existentes en el ámbito nacional y mundial) y, sobre todo, la evolución en el tiempo (incremento anual) y el coste computacional expresado en porcentaje del volumen de ingresos de la empresa.

Imputación de costes

El primer principio a establecer para la implantación de un sistema de imputación de costes es el de si se factura en base de política de costing (el departamento no tendrá ni beneficios ni pérdidas) o de pricing (puede haber beneficio o pérdida). De igual modo habrán de sentarse políticas de promoción (favorecer con tarifas reducidas) o de penalización (tarifas altas para horas de sobrecarga) de determinados servicios.

Definidos los principios se hará un estudio de los costes y de su distribución por productos oservicios.

El primer paso consiste en definir esos costes. A efectos de clasificación, se pueden agrupar en:

1. Costes de explotación. 2. Costes de desarrollo. 3. Gastos generales.

Cada usuario tendrá en uso, más o menos exclusivo, dispositivos que habrá que cargarle a él:terminales, microcomputadoras, líneas telefónicas, concentradores u otras máquinas.

Los gastos generales del departamento son del tipo: amortización y mantenimiento de edificios,energía'eléctrica, agua, teléfono, seguros, impuestos, material de oficina y vigilancia.

Los costes de personal directivo y de staff de todo el departamento se considerarán costes de estructura, igual que los gastos generales, a prorratear entre los servicios de desarrollo y explotación, según criterios a determinar (por ejemplo, proporcional al volumen total de cada servicio).

Los costes de explotación son: amortización, alquiler y mantenimiento de hardware y software, consumibles (papel, tóner, cintas magnéticas, disk packs), personal y parte proporcional de los gastos generales del departamento (por ejemplo, energía eléctrica específica de la sala de operaciones), asesorías, servicios contratados (para toma de datos, distribución de listados, etc.)

Los costes de desarrollo son: amortización, alquiler y mantenimiento de hardware y software específico de desarrollo, personal, asesores, servicios contratados (programación y análisis, entrada de datos), recursos consumidos de explotación que ésta le factura (consumo de tiempo de máquina, impresión, almacenamiento) y parte proporcional de los gastos generales del departamento.

El tercer paso consiste en definir las unidades de medición de consumos para realizar la imputacióh (facturación).

En explotación, las rutinas de contabilidad dentro del sistema operativo proporcionan:

1. Consumo de tiempo de UCP2. Actividad de acceso a ficheros3. Líneas o páginas impresas4. Cantidad de caracteres en dispositivos de acceso directo y tiempo que han permanecido en

línea.

1227


Con estos valores se pueden definir las unidades para la utilización de recursos:

. Uso de máquina. Actividad de acceso . Almacenamiento

. Impresión

segundo CPU

EXCP (consumo de actividad E/S)

Kilocarácter almacenadopor horas en línea

Línea impresa o página impresa

Para el caso de servicios de teleproceso, se imputará a éste el coste de las unidades y software básico que le corresponde específicamente (controladores de comunicación, módem, equipo auxiliar de comunicaciones, herramientas de rastreo y optimización de comunicaciones).

En cuanto al desarrollo, la unidad de facturación será el día hombre de analista y día hombrede programador.

Respecto al coste que le factura explotación por uso de recursos máquina, dado que las rutinas de contabilidad del sistema operativo permiten imputarlo al proyecto dentro del cual se usan esos recursos de explotación, se puede cargar directamente al coste de desarrollo.

Una vez definidos los costes y su estructuración con vistas a la imputación y a las unidades defacturación, queda por aplicar la política de costing o pricing.

No hay que olvidar que las normas y procedimientos de control de gestión deben permitir, además, el control de proyectos, tema desarrollado en otro apartado de esta misma sección, y el control de pedidos pendientes.

auditoria computacional o informatizada

Documents