MODELO RACI

RACI

matriz de la asignación de responsabilidades (RACI por las iniciales de los tipos de responsabilidad) se utiliza generalmente en la gestión de proyectos para relacionar actividades con recursos (individuos o equipos de trabajo). De esta manera se logra asegurar que cada uno de los componentes del alcance esté asignado a un individuo o a un equipo.

Rol			Descripción
R	Responsible	Responsable	Este rol corresponde a quien efectivamente realiza la tarea. Lo más habitual es que exista sólo un encargado (R) por cada tarea; si existe más de uno, entonces el trabajo debería ser subdividido a un nivel más bajo, usando para ello las matrices RASCI.
A	Accountable	Quien rinde cuentas	Este rol se responsabiliza de que la tarea se realice y es el que debe rendir cuentas sobre su ejecución. Sólo puede existir una persona que deba rendir cuentas (A) de que la tarea sea ejecutada por su responsable (R).
C	Consulted	Consultado	Este rol posee alguna información o capacidad necesaria para realizar la tarea.
I	Informed	Informado	Este rol debe ser informado sobre el avance y los resultados de la ejecución de la tarea. A diferencia del consultado (C), la comunicación es unidireccional.

En esta matriz se asigna el rol que el recurso debe jugar para cada actividad dada. No es necesario que en cada actividad se asignen los cuatro roles, pero sí por lo menos el de responsable (A) y el de encargado (R). Un mismo recurso puede tener más de un rol para una tarea, por ejemplo puede ser el encargado (R) y responsable (A) del mismo, en cuyo caso se anotará R/A.

Estas matrices se pueden construir en alto nivel (grupos de tareas generales) o en un nivel detallado (tareas de nivel bajo).

Una matriz de alto nivel se puede graficar con el listado de todos los entregables del proyecto definidas en la EDT versus los recursos definidos en el OBS. No todos los recursos tendrán necesariamente una entrada para cada actividad. Una matriz de bajo nivel se puede utilizar para designar roles, responsabilidades y niveles de autoridad para actividades específicas.

En esta matriz se asigna el rol que el recurso debe jugar para cada actividad dada. No es necesario que en cada actividad se asignen los cuatro roles, pero sí por lo menos el de responsable (A) y el de encargado (R). Un mismo recurso puede tener más de un rol para una tarea, por ejemplo puede ser el encargado (R) y responsable (A) del mismo, en cuyo caso se anotará R/A.

Estas matrices se pueden construir en alto nivel (grupos de tareas generales) o en un nivel detallado (tareas de nivel bajo).

Una matriz de alto nivel se puede graficar con el listado de todos los entregables del proyecto definidas en la EDT versus los recursos definidos en el OBS. No todos los recursos tendrán necesariamente una entrada para cada actividad. Una matriz de bajo nivel se puede utilizar para designar roles, responsabilidades y niveles de autoridad para actividades específicas.

En esta matriz se asigna el rol que el recurso debe jugar para cada actividad dada. No es necesario que en cada actividad se asignen los cuatro roles, pero sí por lo menos el de responsable (A) y el de encargado (R). Un mismo recurso puede tener más de un rol para una tarea, por ejemplo puede ser el encargado (R) y responsable (A) del mismo, en cuyo caso se anotará R/A.

Estas matrices se pueden construir en alto nivel (grupos de tareas generales) o en un nivel detallado (tareas de nivel bajo).

Una matriz de alto nivel se puede graficar con el listado de todos los entregables del proyecto definidas en la EDT versus los recursos definidos en el OBS. No todos los recursos tendrán necesariamente una entrada para cada actividad. Una matriz de bajo nivel se puede utilizar para designar roles, responsabilidades y niveles de autoridad para actividades específicas.

En esta matriz se asigna el rol que el recurso debe jugar para cada actividad dada. No es necesario que en cada actividad se asignen los cuatro roles, pero sí por lo menos el de responsable (A) y el de encargado (R). Un mismo recurso puede tener más de un rol para una tarea, por ejemplo puede ser el encargado (R) y responsable (A) del mismo, en cuyo caso se anotará R/A.

Estas matrices se pueden construir en alto nivel (grupos de tareas generales) o en un nivel detallado (tareas de nivel bajo).

Una matriz de alto nivel se puede graficar con el listado de todos los entregables del proyecto definidas en la EDT versus los recursos definidos en el OBS. No todos los recursos tendrán necesariamente una entrada para cada actividad. Una matriz de bajo nivel se puede utilizar para designar roles, responsabilidades y niveles de autoridad para actividades específicas.

EJEMPLO

Pasos Para Auditoria

                          

 PLANEACIÓN

Para hacer una adecuada planeación de la auditoria en informática, hay que seguir una serie de pasos previos que permitirán dimensionar el tamaño y características de área dentro del organismo a auditar, sus sistemas, organización y equipo.

Es fundamental, pues habrá que hacerla desde el punto de vista de los dos objetivos:

• Evaluación de los sistemas y procedimientos.
• Evaluación de los equipos de cómputo.

Para hacer una planeación eficaz, lo primero que se requiere es obtener información general sobre la organización y sobre la función de informática a evaluar. Para ello es preciso hacer una investigación preliminar y algunas entrevistas previas, con base en esto planear el programa de trabajo, el cual deberá incluir tiempo, costo, personal necesario y documentos auxiliares a solicitar o formular durante el desarrollo de la misma.

INVESTIGACIÓN PRELIMINAR

Se deberá observar el estado general del área, su situación dentro de la organización, si existe la información solicitada, si es o no necesaria y la fecha de su última actualización.

Se debe hacer  solicitando y revisando  los siguientes puntos:

ADMINISTRACIÓN

Se recopila la información para obtener una visión general del departamento por medio de observaciones, entrevistas preliminares y solicitud de documentos para poder definir el objetivo y alcances del departamento.

A NIVEL DEL ÁREA DE INFORMÁTICA

Objetivos a corto y largo plazo.

RECURSOS MATERIALES Y TECNICOS

Solicitar documentos sobre los equipos, número de ellos, localización y características.

• Estudios de viabilidad.
• Número de equipos, localización y las características (de los equipos instalados y por instalar y programados)
• Fechas de instalación de los equipos y planes de instalación.
• Contratos vigentes de compra, renta y servicio de mantenimiento.
• Contratos de seguros.
• Convenios que se tienen con otras instalaciones.
• Configuración de los equipos y capacidades actuales y máximas.
• Planes de expansión.
• Ubicación general de los equipos.
• Políticas de operación.
• Políticas de uso de los equipos.

SISTEMAS

Descripción general de los sistemas instalados y de los que estén por instalarse que contengan volúmenes de información.

• Manual de formas.
• Manual de procedimientos de los sistemas.
• Descripción genérica.
• Diagramas de entrada, archivos, salida.
• Salidas.
• Fecha de instalación de los sistemas.
• Proyecto de instalación de nuevos sistemas.

Debemos evaluar que pueden presentarse las siguientes situaciones.

Se solicita la información y se ve que:

• No tiene y se necesita.
• No se tiene y no se necesita.

Se tiene la información pero:

• No se usa.
• Es incompleta.
• No esta actualizada.
• No es la adecuada.
• Se usa, está actualizada, es la adecuada y está completa.

En el caso de No se tiene y no se necesita, se debe evaluar la causa por la que no es necesaria. En el caso de No se tiene pero es necesaria, se debe recomendar que se elabore de acuerdo con las necesidades y con el uso que se le va a dar.

 En el caso de que se tenga la información pero no se utilice, se debe analizar por que no se usa. En caso de que se tenga la información, se debe analizar si se usa, si está actualizada, si es la adecuada y si está completa.

• Estudiar hechos y no opiniones (no se toman en cuenta los rumores ni la información sin fundamento)
• Investigar las causas, no los efectos.
• Atender razones, no excusas.
• No confiar en la memoria, preguntar constantemente.
• Criticar objetivamente y a fondo todos los informes y los datos recabados.

PERSONAL PARTICIPANTE

Una de las partes más importantes dentro de la planeación de la auditoria en informática es el personal que deberá participar y sus características.

En primer lugar se debe pensar que hay personal asignado por la organización, con el suficiente nivel para poder coordinar el desarrollo de la auditoria, proporcionar toda la información que se solicite y programar las reuniones y entrevistas requeridas.

• Técnico en informática.
• Experiencia en el área de informática.
• Experiencia en operación y análisis de sistemas.
• Conocimientos de los sistemas más importantes.

EVALUACIÓN DE SISTEMAS

Deberá establecer los servicios que se presentarán en un futuro contestando preguntas como las siguientes:

• ¿Cuáles servicios se implementarán?
• ¿Cuándo se pondrán a disposición de los usuarios?
• ¿Qué características tendrán?
• ¿Cuántos recursos se requerirán?

La estrategia de desarrollo deberá establecer las nuevas aplicaciones, recursos y la arquitectura en que estarán fundamentados:

• ¿Qué aplicaciones serán desarrolladas y cuando?
• ¿Qué tipo de archivos se utilizarán y cuando?
• ¿Qué bases de datos serán utilizarán y cuando?
• ¿Qué lenguajes se utilizarán y en que software?
• ¿Qué tecnología será utilizada y cuando se implementará?
• ¿Cuantos recursos se requerirán aproximadamente?
• ¿Cuál es aproximadamente el monto de la inversión en hardware y software?

En lo referente a la consulta a los usuarios, el plan estratégico debe definir los requerimientos de información de la dependencia.

• ¿Qué estudios van a ser realizados al respecto?
• ¿Qué metodología se utilizará para dichos estudios?
• ¿Quién administrará y realizará dichos estudios?

En el área de auditoria interna debe evaluarse cuál ha sido la participación del auditor y los controles establecidos.

Por último, el plan estratégico determina la planeación de los recursos.

• ¿Contempla el plan estratégico las ventajas de la nueva tecnología?
• ¿Cuál es la inversión requerida en servicios, desarrollo y consulta a los usuarios?

EVALUACIÓN DEL ANÁLISIS

• La planeación estratégica: agrupadas las aplicaciones en conjuntos relacionados entre sí y no como programas aislados. Las aplicaciones deben comprender todos los sistemas que puedan ser desarrollados en la dependencia, independientemente de los recursos que impliquen su desarrollo y justificación en el momento de la planeación.
• Los requerimientos de los usuarios.
• El inventario de sistemas en proceso al recopilar la información de los cambios que han sido solicitados, sin importar si se efectuaron o se registraron.

La situación de una aplicación en dicho inventario puede ser alguna de las siguientes:

• Planeada para ser desarrollada en el futuro.
• En desarrollo.
• En proceso, pero con modificaciones en desarrollo.
• En proceso con problemas detectados.
• En proceso sin problemas.
• En proceso esporádicamente.

Es importante revisar la situación en que se encuentran los manuales de análisis y si están acordes con las necesidades de la dependencia. En algunas ocasiones se tiene una microcomputadora, con sistemas sumamente sencillos y se solicita que se lleve a cabo una serie de análisis que después hay que plasmar en documentos señalados en los estándares, lo cual hace que esta fase sea muy compleja y costosa. Los sistemas y su documentación deben estar acordes con las características y necesidades de una dependencia específica.

Se debe evaluar la obtención de datos sobre la operación, flujo, nivel, jerarquía de la información que se tendrá a través del sistema. Se han de comparar los objetivos de los sistemas desarrollados con las operaciones actuales, para ver si el estudio de la ejecución deseada corresponde al actual.

La auditoria en sistemas debe evaluar los documentos y registros usados en la elaboración del sistema, así como todas las salidas y reportes, la descripción de las actividades de flujo de la información y de procedimientos, los archivos almacenados, su uso y su relación con otros archivos y sistemas, su frecuencia de acceso, su conservación, su seguridad y control, la documentación propuesta, las entradas y salidas del sistema y los documentos fuentes a usarse.

Con la información obtenida podemos contestar a las siguientes preguntas:

• ¿Se está ejecutando en forma correcta y eficiente el proceso de información?
• ¿Puede ser simplificado para mejorar su aprovechamiento?
• ¿Se debe tener una mayor interacción con otros sistemas?
• ¿Se tiene propuesto un adecuado control y seguridad sobre el sistema?
• ¿Está en el análisis la documentación adecuada?