Objectives and Key Results · ใช้ในการว ดความสั ําเร็จของโครงการ 3 เหตุผลในการว ดผลการปฏั
UNIVERSIDAD DE CHILE DEPARTAMENTO DE CIENCIAS DE … · también se aplicaron objetivos de control...
61
UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN MANTENIMIENTO DE SOFTWARE: ADMINISTRACIÓN DE ÓRDENES DE CAMBIO MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN HENRY EDWARD STRANGE SOBARZO PROFESOR GUÍA: SERGIO F. OCHOA DELORENZI MIEMBROS DE LA COMISIÓN: JUAN FERNANDO ALVAREZ RUBIO SANDRA XIMENA DE LA FUENTE GONZALEZ SANTIAGO DE CHILE DICIEMBRE 2007
Transcript of UNIVERSIDAD DE CHILE DEPARTAMENTO DE CIENCIAS DE … · también se aplicaron objetivos de control...
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
MANTENIMIENTO DE SOFTWARE: ADMINISTRACIÓN DE ÓRDENE S DE
CAMBIO
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN
HENRY EDWARD STRANGE SOBARZO
PROFESOR GUÍA:
SERGIO F. OCHOA DELORENZI
MIEMBROS DE LA COMISIÓN:
JUAN FERNANDO ALVAREZ RUBIO
SANDRA XIMENA DE LA FUENTE GONZALEZ
SANTIAGO DE CHILE
DICIEMBRE 2007
2
RESUMEN DE LA MEMORIA
PARA OPTAR AL TITULO DE
INGENIERO CIVIL EN COMPUTACIÓN
POR: HENRY STRANGE S.
FECHA: 24/12/2007
PROF. GUIA: Sr. SERGIO OCHOA
“MANTENIMIENTO DE SOFTWARE: ADMINISTRACIÓN DE ÓRDENES DE CAMBIO”
Este trabajo de título fue realizado para una de las más grandes compañías embotelladoras del
país, ubicado en Santiago, Chile. El objetivo general fue proponer y evaluar las herramientas a
utilizar en la administración de órdenes de cambio, con el objetivo de garantizar el correcto y
seguro funcionamiento de los sistemas aplicativos que la Compañía desarrolle o adquiera. Como
resultado se esperaba implantar una herramienta de software y un conjunto de políticas, normas y
objetivos de control necesarios para alcanzar los objetivos deseados.
La embotelladora contaba con un proceso de administración de órdenes de cambio que
presentaba algunas deficiencias, debido a que muchos de sus sub-procesos eran realizados en
forma manual y con falta de los controles necesarios.
La herramienta que se implantó es una herramienta de SAP que adhiere al estándar de facto
internacional ITIL (Information Technology Infrastructure Library) para los procesos TI. Pero
además, se diseñaron políticas y normas que establecen una estructuración de los procesos, como
también se aplicaron objetivos de control del estándar Cobit (Control Objectives for Information
and related Technology). Finalmente, se consideraron los objetivos necesarios para cumplir con
las exigencias de la ley Sarbanes-Oxley.
El resultado final fue una re-estructuración del proceso de administración de órdenes de cambio,
aplicando una herramienta (software) del mercado en conjunto con normas, políticas y objetivos
de control establecidos. Y al aplicar todo esto en conjunto se logró:
• Segregar algunas funciones que tendían a fusionarse; al definir claramente los perfiles y
las obligaciones de los participantes.
3
• Facilitar la auditoria interna y externa; al incorporar un seguimiento automatizado de los
procesos.
• Acelerar el proceso de desarrollo y mantenimiento; al automatizar muchos procesos
manuales.
• Aumentar la transparencia de los procesos; al permitir un seguimiento en línea del estado
de los procesos.
• Mejorar la disponibilidad de la documentación de los procesos; al almacenarlos en un
repositorio centralizado y altamente accesible.
Se recomienda finalmente que la embotelladora haga un mantenimiento continuo del trabajo
hecho aquí para mantener su vigencia y efectividad. Los elementos planteados en este trabajo
deben ir evolucionando en conjunto con los procesos de la empresa y de las necesidades y
requisitos de los usuarios de los sistemas aplicativos.
4
INDICE DE CONTENIDO
1 INTRODUCCIÓN................................................................................................................... 5 1.1 JUSTIFICACIÓN ............................................................................................................. 7 1.2 OBJETIVOS Y ALCANCE DEL TRABAJO.................................................................. 9
1.3 PLAN DE TRABAJO....................................................................................................... 9 1.4 RESULTADOS ESPERADOS....................................................................................... 10
2 CONCEPCIÓN DE LA SOLUCIÓN.................................................................................... 12 2.1 REQUISITOS ................................................................................................................. 12 2.2 FLUJO DE TRABAJO CORRECCIÓN URGENTE..................................................... 13
2.3 FLUJO DE TRABAJO CORRECCIÓN NORMAL...................................................... 15
2.4 PERFILES DE USUARIOS ........................................................................................... 16 2.5 TAREAS......................................................................................................................... 17 2.6 BOSQUEJO DE LA SOLUCIÓN .................................................................................. 18
3 FRAMEWORK PROPUESTO ............................................................................................. 21 3.1 BUENAS PRÁCTICAS ................................................................................................. 21 3.2 OBJETIVOS DE CONTROL......................................................................................... 29
3.2.1 OBJETIVOS DE CONTROL COBIT..................................................................... 29
3.2.2 OBJETIVOS DE CONTROL SARBANES-OXLEY............................................. 30
3.3 CHECKLIST PARA LOS OBJETIVOS DE CONTROL.............................................. 30
3.3.1 OBJETIVOS DEL CHECKLIST ............................................................................ 31
3.3.2 ALCANCE DEL CHECKLIST............................................................................... 31
3.3.3 DESARROLLO DEL CHECKLIST....................................................................... 32
3.3.4 CONCLUSIONES DEL CHECKLIST................................................................... 35
3.4 CREACIÓN DE POLÍTICAS Y PROCEDIMIENTOS ................................................ 35
3.4.1 DESARROLLO....................................................................................................... 36 3.4.2 PLANTILLA PARA UNA POLÍTICA................................................................... 38
3.5 POLÍTICA DESARROLLADA ..................................................................................... 39
3.5.1 INTRODUCCIÓN................................................................................................... 39 3.5.2 ALCANCE .............................................................................................................. 39 3.5.3 DECLARACIONES DE LA POLÍTICA................................................................ 40
3.5.4 REFERENCIAS ...................................................................................................... 41 3.5.5 ACCIONES DISCIPLINARIAS............................................................................. 41
3.5.6 DEFINICIONES...................................................................................................... 41 3.6 NORMA DESARROLLADA ........................................................................................ 42
3.6.1 INTRODUCCIÓN................................................................................................... 43 3.6.2 GENERAL .............................................................................................................. 43 3.6.3 SEPARACIÓN DE AMBIENTES Y FUNCIONES .............................................. 44
3.6.4 DESARROLLO / ADQUISICIÓN DE SISTEMAS............................................... 46
3.6.5 PRUEBA DE LOS SISTEMAS .............................................................................. 52
3.6.6 PUESTA EN PRODUCCIÓN................................................................................. 54
3.6.7 DOCUMENTACIÓN.............................................................................................. 56 4 CONCLUSIONES................................................................................................................. 59 5 BIBLIOGRAFÍA Y REFERENCIAS ................................................................................... 61
5
1 INTRODUCCIÓN
Los sistemas de planificación de recursos de la empresa (en inglés ERP, Enterprise Resource
Planning) son sistemas de gestión de información que integran y automatizan muchas de las
prácticas de negocio asociadas con los aspectos operativos o productivos de una Compañía. Los
ERP son sistemas integrales de gestión para la empresa. Se caracterizan por estar compuestos por
diferentes partes integradas en una única aplicación. Estas partes (llamados módulos) son de
diferente uso, por ejemplo: producción, ventas, compras, logística, contabilidad (de varios tipos),
gestión de proyectos, GIS (sistema de información geográfica), inventarios y control de
almacenes, pedidos, nóminas, etc.
El ERP integra todo lo necesario para el funcionamiento de los procesos de negocio de la
empresa. No podemos hablar de ERP en cuanto a que tan sólo se integra uno, o una pequeña
parte de los procesos de negocio. La propia definición de ERP indica la necesidad de
"disponibilidad de toda la información para todo el mundo todo el tiempo". Los objetivos
principales de los sistemas ERP son los siguientes:
• Optimización de los procesos empresariales.
• Acceso a toda la información de forma confiable, precisa y oportuna (integridad de datos).
• La posibilidad de compartir información entre todos los componentes de la organización
(como por ejemplo entre los componentes de finanzas y recursos humanos).
• Eliminación de datos y operaciones innecesarias de reingeniería.
El propósito fundamental de un ERP es otorgar apoyo a los clientes del negocio, con tiempos
rápidos de respuesta, como también un eficiente manejo de información que permita la toma
oportuna de decisiones y disminución de los costos totales de operación. SAP AG (Systeme,
Anwendungen und Produkte), es el primer proveedor de aplicaciones de software empresarial
(ERP) en el mundo. Como empresa, comercializa un conjunto de aplicaciones de software para
soluciones integradas de negocios, que proveen soluciones escalables que permiten mejorar
continuamente, con más de 1.000 procesos de negocio que integran las mejores prácticas
empresariales desarrollados en un trabajo conjunto con los clientes. SAP es considerada como el
6
tercer proveedor independiente de software del mundo y el mayor fabricante europeo de
software. Con 12 millones de usuarios, 100.600 instalaciones, y más de 1.500 socios, es la
compañía más grande de software Inter-empresa.
En general se recomienda separar los sistemas de SAP en tres ambientes. Un ambiente de
Desarrollo (DEV) donde se realizan los desarrollos, un ambiente de Prueba (QAT: Quality
Assurance Testing) para asegurar la calidad donde se realizan todas las pruebas, y un sistema de
Producción (PRD) donde se importan los desarrollos después de ser probados en QAT.
Solution Manager de SAP es una plataforma centralizada para administrar soluciones que provee
las herramientas, el contenido integrado, y el acceso a SAP necesario para implementar,
mantener, operar, y monitorear las soluciones en SAP. Ayuda a minimizar los riesgos y reducir
el costo total de propiedad (proveniente del término anglosajón Total Cost of Ownership o TCO).
Solution Manager de SAP corre dentro de la topología de la solución y facilita el mantenimiento
técnico de los sistemas distribuidos de SAP.
Algunas de las herramientas de SAP Solution Manager incluyen soporte para pruebas, mesa de
ayuda, administración centralizada de sistemas, monitoreo de soluciones, administración de
servicios, procesamiento de servicios, entrenamiento para usuarios finales, y administración de
cambios. Este último se refiere a la administración de órdenes de cambio generados a partir de
un requerimiento de software detectado por un usuario del sistema.
Solution Manager administra el ciclo de vida de los sistemas. La administración de órdenes de
cambio permite administrar los proyectos de SAP Solution Manager (mantenimiento,
implementación, plantilla, y mejora/upgrade) desde arriba hacia abajo; comenzando con
administración de cambios y planificación de proyectos, pasando por administración de recursos
y control de costos, hasta el transporte físico de cambios desde el ambiente de Desarrollo hacia el
ambiente de Producción.
Continuos cambios de software y configuración, como también grandes implementaciones son
desafíos constantes para manejar la consistencia de datos y asegurar el control de los proyectos.
La administración de órdenes de cambio, como parte de SAP Solution Manager, integra la
funcionalidad de mesa de ayuda para manejar las órdenes de cambio.
7
Los procesos soportados por la administración de órdenes de cambio incluyen correcciones
urgentes para implementar cambios directos y rápidos en el ambiente de Producción, y
actividades de ciclos de mantenimiento tales como entregas (releases) regulares, e
implementación, mejoras, o proyectos de plantilla. Están soportados los cambios multi-sistemas
(crosssystem) y multi-componente (cross-component). Solution Manager permite operar la
administración de las órdenes de cambio con los siguientes flujos:
• Corrección Urgente, que es un flujo simplificado para acelerar la ejecución del cambio.
• Corrección Normal, que es un flujo que incluye pasos más exigentes como por ejemplo el
control de las actividades detallado del desarrollador y del tester.
• Existen otros flujos que no es del caso tratar aquí.
En este trabajo de título se planteó tomar la administración de órdenes de cambio que
proporciona SAP Solution Manager y extender su funcionalidad para que ésta se acomode a las
necesidades específicas de la Compañía. La extensión requerida era considerable, ya que los
procesos de la Embotelladora distan bastante de la funcionalidad básica que ofrece el producto.
La Compañía es una de las principales Embotelladoras del país, contando con una presencia en
dos países más de Sudamérica dotado de más de 6.000 empleados entre los tres países.
Actualmente, la Compañía cotiza acciones en la Bolsa de Nueva York (NYSE) por lo que se
encuentra sujeto a la Ley Sarbanes-Oxley, que se creó para proteger los intereses y entregar
mayor confianza a los accionistas de dicha bolsa.
1.1 JUSTIFICACIÓN
Algunas de las deficiencias de la antigua administración de órdenes se señalan a continuación:
• Administración descentralizada al utilizar papel, correo, fax, teléfono, etc: Utilizando
sólo estas herramientas, se dificultaba el seguimiento de las órdenes de cambio. Esto
entorpecía la recopilación de información lo que iba en desmedro de la calidad de ésta al
no poder registrar todos los acontecimientos como por ejemplo los llamados telefónicos.
8
• No existía un control sobre los tiempos de recepción, ejecución, pruebas, y entrega de los
cambios: Esto obstaculizaba el control sobre las órdenes de cambio y dificultaba la
administración de proyectos lo que provocaba un manejo tardío e ineficiente en el
procesamiento de las órdenes de cambio.
• Gasto de recursos innecesarios (horas hombre, papel, fax, teléfono, espacio para
archivos): Todo gasto innecesario para cualquier empresa significa pérdidas indeseadas
que se deben evitar en lo posible.
• Riesgo de errores y pérdida de información: Existía la posibilidad de errores por la mala
interpretación de documentos manuscritos o en la falta de documentación de una
conversación por teléfono por ejemplo. Y existían riesgos de pérdida de información al
archivar equivocadamente o simplemente al extraviar un documento como también al
suprimir equivocadamente algún correo por ejemplo. Y como estos, existían muchos
riesgos a lo largo del proceso de administración de las órdenes de cambio.
• Riesgo de dilatación de los procesos y burocracia innecesaria: La falta de control y
seguimiento centralizado en el manejo de las órdenes de cambio colocaba a ciertos
empleados en una posición donde podían abusar de esta falta de control quedando el
desarrollo de muchas actividades a discreción única y exclusiva de ellos.
Este trabajo logró automatizar la administración de las órdenes de cambio a través de una
herramienta de software, y de esta manera minimizar las deficiencias y los riesgos antes
mencionados.
Características de la administración de órdenes de cambio:
• Administración de los mantenimientos e implementaciones a través de múltiples
componentes.
• Administración avanzada de órdenes de servicio junto con la administración de proyectos
para controlar, planificar, diseñar, desarrollar, testear, y puesta en marcha.
• Administración manejada por un flujo de trabajo comprensivo de actividades distribuidas
incluyendo planificación, desarrollo, mantenimiento, y producción.
9
• Seguimiento avanzado de cambios en los proyectos.
1.2 OBJETIVOS Y ALCANCE DEL TRABAJO
El objetivo general que persiguió este trabajo de título fue investigar, diseñar, implementar y
probar un sistema de administración de órdenes de cambio para el mantenimiento de software
SAP. Para probar la eficacia del diseño se aplicaró a un ambiente de Producción de SAP en una
empresa Embotelladora líder del mercado local (de aquí en adelante, la Compañía). Los objetivos
específicos que se derivaron de este objetivo general fueron los siguientes:
1. Diseñar un proceso de atención de órdenes de cambio, más seguro, eficiente y confiable.
2. Garantizar el correcto y seguro funcionamiento de los sistemas aplicativos que la
Compañía desarrolle o adquiera.
3. Detectar las extensiones necesarias para complementar el proceso diseñado para cumplir
con las necesidades particulares de la Compañía y desarrollar la documentación (políticas
y normas) que garantice el cumplimiento de los objetivos.
4. Implantar y probar la solución en el escenario real.
1.3 PLAN DE TRABAJO
Para alcanzar los objetivos definidos, se diseñó el siguiente plan de trabajo:
1. Detallar formalmente el flujo de trabajo empleado antiguamente para la administración de
órdenes de cambio dentro de la Compañía y detectar sus posibles falencias (2 semanas).
2. Investigar buenas prácticas para la administración de órdenes de cambio en un ambiente
de Producción de SAP (3 semanas).
3. Investigación y práctica en la utilización de SAP Solution Manager como herramienta
para administrar órdenes de cambio en un ambiente de Producción de SAP (3 semanas).
4. Investigación de cómo crear y modificar políticas de seguridad (1 mes).
5. Investigación de cómo crear y modificar normas (1 mes).
10
6. Diseñar políticas, normas para la administración de órdenes de cambio que se ajusta a las
necesidades de la Compañía (1 mes).
7. Definir perfiles de usuarios necesarios para la administración de órdenes de cambio
teniendo en cuenta la segregación de deberes y detallar las obligaciones y limitaciones de
cada uno (3 semanas).
8. Desarrollar políticas y normas que rigen el proceso para lograr el cumplimiento de los
objetivos (1,5 meses).
9. Realización de pruebas y ajustes a la solución propuesta (1 mes).
10. Confección del documento final del trabajo de título (2.5 meses).
Cronograma de Actividades:
Mes / Tarea
1 2 3 4 5 6 7 8
1 XX
2 XXX
3 X XX
4 XX XX
5 XXXX
6 XXXX
7 XXX
8 X XXXX X
9 XXX X
10 XXX XXX XXXX
1.4 RESULTADOS ESPERADOS
Con esta solución se lograron los siguientes resultados esperados:
• Mayor control y estandarización a los cambios en los procesos: Es necesario mantener un
control permanente de todos los cambios de modo que quede constancia de quienes
participaron en el cambio y cuales fueron las acciones realizadas por cada uno de ellos.
Para esto se utilizan autorizaciones especiales para que ciertas tareas sólo sean realizadas
11
por personas específicas. Todo esto debe ser documentado de una forma transparente,
reuniendo toda la información requerida, y manteniéndola disponible en todo momento de
manera centralizada. De este modo, se logra cumplir con los requerimientos de la
Compañía, la ley Sarbanes-Oxley, de los auditores, etc.
• Ayudar a planear, trazar y monitorear cambios en los distintos procesos de la Compañía:
Esto ayuda a desarrollar los cambios en una forma eficiente, ahorrando recursos
importantes para la Compañía asociados a este tipo de administración, particularmente
para el área de proyectos y de TI. Además de registrar y regular todos los cambios
desarrollados junto con su documentación relevante. Reduciendo de esta forma el riesgo
de corrección y fracaso de proyectos además de los tiempos de corrección,
implementación, y fase de puesta en marcha.
• Ser rol clave en el mantenimiento de los procesos a través de su ciclo de vida: Se logró
centralizar todas las actividades relacionadas con el mantenimiento de los procesos en una
sola herramienta. Logrando así una mayor eficiencia a lo largo del ciclo de vida de todos
los procesos.
• Aplicar políticas y normas para garantizar el correcto y seguro funcionamiento de los
sistemas aplicativos que la Compañía desarrolle o adquiera: Además de proveer las
herramientas necesarias para garantizar un correcto control, auditabilidad y una eficiente
administración de la seguridad de las mismas.
12
2 CONCEPCIÓN DE LA SOLUCIÓN
La solución inicial se basó en el flujo de trabajo por defecto definido para la solución SAP
Solution Manager. Esta solución contempla dos posibilidades, las correcciones urgentes y las
correcciones normales. A continuación se detalla el flujo de trabajo para cada una de ellas.
Además se definen los perfiles involucrados en los flujos junto con las tareas que deben realizar
cada uno de ellos.
2.1 REQUISITOS
A continuación se detalla una lista de los requisitos más importantes de la solución desarrollada:
1. Permitir la documentación comprensible de cambios planificados e implementados y sus
ramificaciones. Estos documentos deben estar estructurados y almacenados en un
repositorio centralizado.
2. Aumentar la eficiencia en proyectos de administración de cambio, siguiendo una
metodología estricta que permita minimizar los errores y así disminuir los recursos
utilizados.
3. Minimizar perturbaciones en el negocio, realizando pruebas rigurosas y confirmando su
éxito antes de implantar en los sistemas productivos.
4. Permitir seguimiento y facilitar la auditoria de las órdenes de cambio, registrando todas
las intervenciones a través del ciclo de mantenimiento identificando las acciones
realizadas y los usuarios involucrados.
5. Aumentar la calidad y transparencia en los proyectos de cambio, identificando los
procedimientos a seguir y las responsabilidades de los involucrados.
6. Estandarizar el proceso de registro, clasificación, aprobación, implementación y
evaluación de las órdenes de cambio, facilitando futuras auditorias y manejando la
segregación de funciones.
7. Asegurar confiabilidad en los proyectos de cambio aumentando la transparencia y
mejorando la documentación.
13
8. Reducir Costo Total de Propiedad (TCO,Total Cost of Ownership), al hacer más eficiente
el proceso de administración de cambios.
9. Mantener toda la información relevante a un cambio en un lugar centralizado y accesible
en todo momento.
10. Conformar a estándares internacionales como ITIL, Cobit y la ley de Sarbanes-Oxley.
2.2 FLUJO DE TRABAJO CORRECCIÓN URGENTE
El flujo antiguo de actividades diseñado para procesar las órdenes de cambios en la Compañía
partía con la detección de un requerimiento por un usuario. Este requerimiento se documentaba
(en papel) en una orden de cambio que debía ser aprobada por el líder de módulo y el jefe de
área. Una vez aprobada se enviaba al jefe de mantenimiento quien lo archivaba e iniciaba el
desarrollo del cambio documentando avances y pruebas a través de correos electrónicos.
El flujo propuesto por SAP Solution Manager igualmente comienza con la detección de un
requerimiento, pero este requerimiento se ingresa directamente en SAP Solution Manager que
administrará la solicitud de comienzo a fin, identificando con detalle cada paso y cada usuario
que participa del flujo.
14
Figura 3-1: Administración de órdenes de cambio – corrección urgente
Cualquier usuario puede actuar como Solicitante e iniciar el flujo al generar un Mensaje de
Soporte. El Mensaje de Soporte es recibido en la Mesa de Soporte y debe tomar una de varias
opciones:
o Enviarlo al Jefe de Mantenimiento (cambios urgentes).
o Enviarlo al Jefe de Mantenimiento para realizarlo más tarde (cambios de baja
prioridad).
o Rechazarlo por ser de otra área (Ej.: cambios de hardware) o ser inválido.
Al ser aceptado, el Mensaje de Soporte se queda con un estado de procesamiento y se genera una
Solicitud de Modificación. Esta Solicitud de Modificación es recibida por el jefe de
mantenimiento quien debe aprobarlo o rechazarlo. Al rechazarlo, se cierra el proceso y se da por
concluida la Solicitud de Modificación y el Mensaje de Soporte. Al aprobar la Solicitud de
Jefe de Mantenimiento
Ciclo de Mantenimiento
Mensaje de Soporte
Administración de Órdenes de Cambio – Corrección Urgente
Solicitud de Cambio
Documento de Cambio
Empleado Mesa de Soporte
Desarrollador
Solicitante
Operador TI
Mes
a de
Sop
orte
A
dmin
istr
ació
n de
Órd
enes
de
Cam
bio
Transportes controlados
Transportes controlados
Lista de Tareas
15
Modificación se crea un Documento de Modificación y se abre el proceso de desarrollo. Toda la
documentación del resto del proceso será anexada en este Documento de Modificación por cada
uno de los involucrados. Además el Documento de Modificación indicará el estado en que se
encuentra actualmente (por ejemplo: en desarrollo, listo para pasar a testing, testing exitoso, etc.).
Luego de ser aprobado, el Jefe de Mantenimiento asigna un desarrollador quien realiza el
desarrollo en DEV y asigna un tester. El tester debe importar lo desarrollado en DEV a QAT y
realizar las pruebas pertinentes. Si no son exitosas las pruebas, entonces se vuelve el estado del
Documento de Modificación a “en desarrollo” indicando el resultado de las pruebas y esto se
repite hasta conseguir éxito en las pruebas. Una vez que el téster comprueba el correcto
funcionamiento del desarrollo, declara las pruebas como exitosas. El jefe de mantenimiento debe
confirmar toda la documentación y aprobar su paso a Producción. Si el paso es aprobado, el
Operador TI debe importar los cambios al ambiente de Producción. Finalmente el Jefe de
Mantenimiento debe confirmar los cambios para que todos los usuarios sepan que el cambio se
realizó.
2.3 FLUJO DE TRABAJO CORRECCIÓN NORMAL
Si la solicitud era de baja prioridad y fue dejada para realizarla más tarde, se genera un flujo
alternativo. Estas solicitudes se acumulan ya que no son críticas para el proceso. Al juntar varias
solicitudes, el Jefe de Mantenimiento decide lanzar un Nuevo Release de actualizaciones. Se
generan los Documentos de Modificación de los cambios y se unen al flujo anterior.
16
Figura 3-2: Administración de órdenes de cambio – corrección normal
2.4 PERFILES DE USUARIOS
En este escenario de trabajo están presentes distintos actores, los cuales tienen roles (en muchos
casos) complementarios. Los roles identificados son los siguientes:
Solicitante: Proveer información sobre el cambio o problema.
Mesa de Soporte: Punto de contacto entre los usuarios y el área de Sistemas. Maneja
incidentes y solicitudes.
Jefe de Mantenimiento: Asegurar que se utilicen métodos y procedimientos
estandarizados. Acepta las solicitudes, las monitorea y aprueba su paso a producción.
Desarrollador: Implementar y documentar los cambios en el sistema de desarrollo.
Administración de Órdenes de Cambio – Corrección Normal
Mensaje de Soporte
Solicitud de Cambio
Documento de Cambio Ciclo de
Mantenimiento
Empleado Mesa de Soporte
Desarrollador
Operador TI
Jefe de Mantenimiento
Solicitante
Mes
a de
Sop
orte
A
dmin
istr
ació
n de
Órd
enes
de
Cam
bio
Transportes controlados
Transportes controlados
17
Tester: Seguir las instrucciones de los principales casos de uso.
Operador TI: Se preocupa de la documentación del proceso. Proporciona soporte al
cambio y está encargado de importar a producción.
2.5 TAREAS
Como parte de las actividades que deben ejecutar estos interlocutores, las más importantes son las
siguientes:
Mesa de Soporte
• Analizar Mensaje.
• Aprobar o Rechazarlo.
• Cambiar Status del mensaje.
• Crear Solicitud de Modificación.
Jefe de Mantenimiento
• Analizar la solicitud y llenar los campos vacíos.
• Aprobar o Rechazarla.
• Describir la modificación a realizar en el campo Descripción del documento de
modificación.
• Seleccionar al Desarrollador y Tester.
• Aprobar el paso a producción.
• Confirmar la corrección.
Desarrollador
• Analizar las modificaciones pedidas.
• Enviar las tareas al sistema de desarrollo.
• Realizar las modificaciones.
18
• Liberar las tareas en el sistema de desarrollo.
• Hacer un plan de test y adjuntarlo al documento de modificación.
• Escribir sobre los cambios en el campo Guía de Test
• Pasar corrección a test.
Tester
• Seguir paso a paso el Plan de Test en QA.
• Declarar éxito o fracaso del test.
• Escribir su impresión en el campo Informe Test.
Operador TI
• Analizar el documento de modificación.
• Ver que la documentación sea consistente.
• Importar a Producción.
• Cambiar Status del documento a Completado.
2.6 BOSQUEJO DE LA SOLUCIÓN
Para desarrollar la solución se basó en una solución de SAP (Solution Manager) definido en los
flujos anteriores. Solution manager incorpora las mejores prácticas (best practices) definidas por
SAP. Además está alineado a los procesos de la Biblioteca de Infraestructura de Tecnologías de
Información (ITIL – Information Technology Infrastructure Library), el estándar de facto para la
administración de servicios TI. Como está definido en ITIL, el objetivo de la administración del
cambio es realizar los cambios en forma económica y dentro del tiempo requerido con el mínimo
riesgo.
COBIT (Control Objectives for Information and related Technology, en castellano Objetivos de
Control para la Información y Tecnología relacionada) se enfoca en qué se requiere para lograr
una administración y un control adecuado de TI, y se posiciona en un nivel alto. COBIT ha sido
19
alineado y armonizado con otros estándares y mejores prácticas más detallados de TI. COBIT
actúa como un integrador de todos estos materiales guía, resumiendo los objetivos clave bajo un
mismo marco de trabajo integral que también se vincula con los requerimientos de gobierno y de
negocios.
COSO (y similares marcos de trabajo) es generalmente aceptado como el marco de trabajo de
control interno para las Compañías. COBIT es el marco de trabajo de control interno
generalmente aceptado para TI.
COBIT es un marco de referencia y un juego de herramientas de soporte que permiten a la
gerencia cerrar la brecha con respecto a los requerimientos de control, temas técnicos y riesgos de
negocio, y comunicar ese nivel de control a los participantes. COBIT permite el desarrollo de
políticas claras y de buenas prácticas para control de TI a través de las Compañías. COBIT
constantemente se actualiza y armoniza con otros estándares. Por lo tanto, COBIT se ha
convertido en el integrador de las mejores prácticas de TI y el marco de referencia general para el
gobierno de TI que ayuda a comprender y administrar los riesgos y beneficios asociados con TI.
La estructura de procesos de COBIT y su enfoque de alto nivel orientado al negocio brindan una
visión completa de TI y de las decisiones a tomar acerca de TI. Los beneficios de implementar
COBIT como marco de referencia de gobierno sobre la TI incluyen:
• Mejor alineación, con base en su enfoque de negocios.
• Una visión, entendible para la gerencia, de lo que hace TI.
• Propiedad y responsabilidades claras, con base en su orientación a procesos.
• Aceptación general de terceros y reguladores.
• Entendimiento compartido entre todos los participantes, con base en un lenguaje común.
• Cumplimiento de los requerimientos COSO para el ambiente de control de TI.
Sobre la base ofrecida por Solution Manager, se desarrollaró las modificaciones necesarias para
que la solución se adhiriera al marco definido por COBIT respecto a la administración de
20
cambios. Esto se encuentra especificado en el documento de COBIT en el capítulo de adquirir e
implantar punto 6 (AI6). Los objetivos de control definidos en éste se detallan en la sección 4.2.1
Objetivos de Control COBIT.
21
3 FRAMEWORK PROPUESTO
A continuación se presenta el framework de trabajo propuesto, el cual está constituido por la definición de buenas prácticas, los objetivos de control, un checklist para los objetivos de control, el procedimiento para la creación de políticas, y finalmente las políticas y normas desarrolladas.
3.1 BUENAS PRÁCTICAS
A continuación se detallan las buenas prácticas definidas en tres áreas: general, administración de requerimientos y administración en producción. GENERAL
Área Mejor Práctica Criterios Política de administración, procedimientos, y estándares están integrados y comunicados a TI y las funciones de administración del negocio.
• Existe una política escrita para la administración de cambios, que define todos los roles, responsabilidades, y procedimientos relacionados a la administración de cambios, aprobado por el CIO / Director de TI, y el gerente de seguridad de la información de negocio.
• Están comunicados los procedimientos y estándares de la administración de cambios que definen las técnicas y tecnologías que serán utilizadas en la Compañía para soportar la política definida.
• Las políticas, procedimientos, y estándares son revisados periódicamente por la gerencia de TI.
Organización
Los roles y responsabilidades que afectan a la administración de cambios están definidos, designados a personal calificado, comunicado a la organización, y se cumplen durante el proceso de administración de cambios.
• La cantidad y calidad del personal de soporte son apropiados con respecto a la complejidad de la organización, la complejidad y el desempeño de las redes y aplicaciones de la organización, y respecto a lo crítico que son estos sistemas para el negocio.
• El personal responsable del análisis de negocio deben ser competentes y fluidos en los sistemas TI de la organización, y deben estar en contacto con las políticas, procedimientos, y personas de gerencia.
• El personal responsable del análisis técnico deben ser peritos en los sistemas TI de la organización, y deben tener experiencia y/o haber sido entrenado en la administración de proyectos para estos sistemas.
• El equipo de administración de cambios de
22
“Mayor impacto” debe contar con suficiente autoridad para analizar, priorizar, y disponer de los recursos para la implementación de proyectos.
• El equipo de administración de cambios de “Menor impacto” debe contar con suficiente autoridad para analizar, priorizar, y disponer de los recursos para el diseño e implementación del cambio.
• Los administradores de configuración / liberación (release) tienen asignados la responsabilidad de mantener la integridad de los ambientes en los sistemas TI. La función de administración de liberación monitorea y controla la puesta en producción de los cambios entre ambientes lógicos, permitiendo a los equipos de desarrollo y de pruebas, enfocarse en sus especialidades. El personal con responsabilidad de administración / liberación no están asignados para desarrollar o testear cambios de infraestructura de los cuales son responsables de promover.
• Los desarrolladores son asignados en equipos, administrados de acuerdo a las prioridades de los proyectos y negocios.
• La responsabilidad de QA de todo el sofware desarrollado es asignado a una organización de pruebas independiente.
• Equipos de control de producción / sistemas son asignados para operar y administrar todos los sistemas de producción.
Administración de resultados
Se capturan indicadores de desempeños claves o KPIs (por su nombre en inglés Key Performance Indicators) en forma periódica de todo el proceso de administración de cambios, y estos son utilizados por la gerencia para alterar o ajustar los procedimientos y practicas.
• La gerencia captura métricas para los procesos de administración de requerimientos, identificando cuellos de botellas y técnicas exitosas para mejorar en forma continua este proceso.
• Periódicamente se capturan métricas del proceso de administración de puesta en producción, indicando a la gerencia los éxitos y obstáculos en este proceso.
• La métricas KPI cubren las siguientes áreas por periodo, categorías, y nivel de riesgos: el volumen de cambios procesados; el tiempo promedio de giro (turnaround) de un cambio; el número de solicitudes recibidos; número de solicitudes rechazados; número de cambios cancelados; número de cambios que generan solicitudes follow-on; número de cambios que no pasan las pruebas de aceptación; y el número de cambios de emergencias solicitados e implementados. Las
23
métricas también reúnen la cantidad de recursos requeridos para cada mejora y proyecto, como también cualquier mantenimiento técnico o de sistema que puede ser mejorados para hacer el proceso más efectivo y eficiente.
Los sistemas son monitoreados para la integridad por una unidad organizacional interna.
• La funcionalidad de las aplicaciones y redes son monitoreadas por una unidad de negocio interno que representa efectivamente una población de usuarios y solicitan cambios en representación de ellos.
Diseño Los requerimientos
de mejora y/o arreglos de errores (bugs) se desarrollan y documentan en forma coordinada.
• Los requerimientos y especificaciones son documentadas, relacionando las necesidades técnicas y de negocio (funcional, mercado, regulatorio, etc) de la solución.
• El trabajo de diseño es coordinado con usuarios de sistemas, personal de pruebas, y la función de seguridad de información para asegurar la suficiente comprensión de los requerimientos técnicos y de negocio, y del impacto en los actuales sistemas productivos.
• Prototipos de solución son presentados a la administración de proyectos de la organización para su aprobación antes del diseño final y el trabajo de construcción / configuración / integración subsiguiente.
• El diseño de la solución integra los requerimientos de los procesos, usurarios, tecnología, y elementos de datos en conformidad a los acuerdos de nivel de servicios.
• Los diseños de solución son creados dentro de los estándares organizacionales para el desarrollo, arquitectura, directrices de ingeniería, convenciones de nombres, y requerimientos de seguridad.
• Se produce un plan de implementación que detalla los recursos, tiempos, y puntos de coordinación para la solución, incluyendo la construcción / configuración / integración y prueba de la solución.
24
ADMINISTRACIÓN DE REQUERIMIENTOS
Área Mejor Práctica Criterios Los requerimientos de mejora y reportes de errores (bugs) son capturados y enviados a gerencia de TI y de negocio para su revisión.
• El personal responsable para los roles de soporte de infraestructura son cargados con la responsabilidad de capturar, priorizar, y presentar las solicitudes de cambio al proceso de administración de cambios apropiado.
• Personal de soporte de infraestructura categoriza las solicitudes de cambio basado en prioridad como mejoras, errores, parches, actualizaciones, y cualquier otra necesidad de “emergencia”. La ruta subsiguiente de esta solicitud depende de esta prioridad.
Soporte de infraestructura
Las solicitudes y son administrados a través del ciclo de vida la administración de cambios.
• Personal de soporte de infraestructura tienen la habilidad de manejar el proceso de administración de solicitudes, incluyendo: medir el criterio de desempeño del proceso, escalar solicitudes inactivas, priorizar arreglos de “emergencia”, y reportar el progreso de las solicitudes a los usuarios.
Se realiza un análisis de negocio para determinar la probabilidad de éxito, significancia para el negocio, recursos requeridos, y justificación de negocio.
• Un rol de analista de negocio analiza solicitudes para evaluar el riesgo de la implementación de la solución y determinar un impacto menor / mayor al negocio.
• Si es impacto menor, el analista de negocio envía las solicitud a análisis técnico (incluye reportes de error).
• Si es impacto mayor, la función de analista de negocio realiza la justificación de negocio en conjunto con un análisis técnico, incluyendo probabilidad de éxito, significancia para el negocio, recursos requeridos, e interdependencias de los sistemas. Una vez completado, el analista de negocios prioriza basado en el análisis y envía a gerencia de negocios para la toma de una decisión.
Análisis de solicitudes
Se realiza un análisis técnico para determinar dependencias de sistemas, recursos / técnicas de tecnología requeridas, y estimaciones del
• Para los reportes de errores (bugs), una función de analista técnico evalúa y envía el reporte a los equipos de desarrollo apropiados para un acción inmediata.
• Una función de analista técnico identifica la viabilidad técnica de solicitudes de cambio, incluyendo impactos a infraestructuras y desarrollos, pruebas, y fechas de liberación existentes.
25
proyecto. Reportes de solicitudes
La organización es capaz de retener visibilidad del estado de las solicitudes y proyectos a medida que son analizados, priorizados, diseñados, desarrollados, probados, y puestos en producción.
• Las herramientas de soporte de infraestructura son capaces de retener la visibilidad y el estado de las solicitudes a través de cada fase del proceso de administración de cambios, incluyendo detalles de la puesta en producción del cambio.
• Las herramientas y personas del soporte de infraestructura están integrados a la mesa de ayuda (help desk) y herramientas de administración de empresas, para analizar y priorizar las solicitudes rápidamente.
Un equipo de administradores de negocio revisa las solicitudes de “mayor impacto” y las prioriza basado en las necesidades de negocio.
• El equipo revisa las solicitudes de cambio determinadas como de mayor impacto al negocio, y prioriza las iniciativas para el diseño e implementación.
• El equipo intercambia análisis y opiniones regularmente y llegan a decisiones concluyentes relacionados con solicitudes de cambio mayores.
Administración de proyectos
Un equipo de personal de TI revisa solicitudes de “menor impacto” y los prioriza basado en las necesidades de negocio.
• El equipo revisa las solicitudes de cambio determinadas como de menor impacto al negocio, y prioriza las solicitudes para su diseño e implementación.
• El equipo analiza y prioriza las solicitudes de cambio menores.
ADMINSTRACIÓN DE PUESTA EN PRODUCCIÓN
Área Mejor Práctica Criterios Ambientes lógicos
La organización define ambientes TI separados, cada uno con su configuración, responsabilidad operacional, y control de accesos propios.
• La organización tiene, como mínimo, tres ambientes funcionales primarios separados: Desarrollo, Prueba (Test/QA), y Producción, consistiendo cada uno de los niveles de componentes apropiados (cliente, servidor, base de datos, etc)
• Administradores de liberación / configuración pueden tener acceso a todos los ambientes, dependiendo de las necesidades del proceso.
• Múltiples ambientes de cada uno de los tipos primarios pueden ser utilizados, siempre y cuando estén lógicamente separados.
• Los ambientes DEV y TEST/QA, pueden ser definidos para compartir el mismo equipo físico, pero deben estar aislados lógicamente en instancias separadas, para que el acceso de sistema de un
26
ambiente no permita el mismo acceso a otro ambiente en el mismo hardware.
Los ambientes de
desarrollo (DEV) se utilizan para construir, configurar, e integrar cambios de infraestructura.
• Al nivel de plataforma, base de datos, y redes, los desarrolladores no tienen acceso a otros ambientes que no sean su ambiente DEV asignado.
Los ambientes de Prueba (TEST/QA) se utilizan para asegurar la funcionalidad, desempeño, y conformidad al negocio de las soluciones antes de la puesta en producción.
• Sólo personal del equipo de pruebas tiene acceso a su ambiente TEST/QA asignado.
• La mesa de ayuda de la organización administra y soporta los ambientes TEST/QA.
• Un ambiente TEST/QA es configurado para reaplicar (lo más cercano posible) el desempeño del ambiente PROD para el cual la soluciones son implementadas o cambiadas.
Los ambientes de producción (PROD) se utilizan para soportar los requerimientos de infraestructura TI del negocio.
• El acceso al ambiente PROD al nivel de aplicación es limitado a los usuarios autorizados para utilizar el sistema de producción.
• El acceso al ambiente PROD al nivel de plataforma, red, y datos es extremadamente limitado al personal que esté autorizado para configurar y/o administrarlo.
• El ambiente PROD no esta físicamente localizado con otros ambientes, teniendo su propio hardware y conectividad para asegurar la disponibilidad en el evento de que se produzca alguna caída de los sistemas DEV o TEST/QA.
Proceso El proceso de
administración de cambios sigue una orden lógica y es controlado para asegurar la evolución lógica de mejoras efectivas a los ambientes de producción.
• Los proyectos de “mayor impacto” primero se construyen / configuran como prototipos para justificarlos y demostrar su viabilidad ante la gerencia. Pruebas preliminares (incluyendo funcionalidad y desempeño), aceptación de negocio, y ajustes al diseño son utilizados como especificaciones para el desarrollo de la solución.
• Los cambios de infraestructura primero se construyen / configuran / integran en los ambientes de Desarrollo, seguidos de pruebas en el ambiente TEST/QA, y son puestos en producción en el ambiente de producción mediante pasos intermedios como requerido por las necesidades del negocio.
• Existen procedimientos para asegurar que los cambios al sistema pueden ser cancelados o
27
restaurados a un estado anterior en forma inmediata, en el evento de una puesta en producción no deseado o fracasado.
Las solicitudes de emergencia se manejan de manera similar a las solicitudes normales, con las diferencias que permiten un desarrollo, prueba, y liberación expedita.
• Los cambios de emergencia / error (o bug) son verificados por análisis técnico y de negocio, y avanzan por un proceso de promoción y puesta en producción simplificado y expedito. Liberaciones de emergencia deben ser autorizados por un administrador predeterminado, y documentado en el sistema apropiado para propósitos de auditoria.
• Todos los cambios de emergencia deben ser probados en todas las fases para asegurar un desempeño de calidad sin agregar disturbios adicionales a los sistemas actuales.
• Las liberaciones de emergencia deben ser comunicados a la población de usuarios y administradores para alertarlos a las necesidades e impactos de los cambios de emergencia.
La función de gerencia de configuración / liberación provee administración y control sobre la administración de puesta en producción.
• La función de gerencia de liberación tiene la responsabilidad de controlar la puesta en producción de los cambios de una ambiente al siguiente. Ningún otro rol debe estar permitido trasladar los cambios de un ambiente a otro, y la función de administración de liberación tiene la autoridad de aprobar o rechazar los cambios y/o puestas en producción. Esta función puede ser realizada por personal distinto para cada etapa de promoción, dependiendo de los requerimientos del negocio.
• La gerencia de liberación administra el control de versiones y bibliotecas de programas, y otro software de sistemas que automatizan el proceso de puesta en producción del cambio.
• Todos los cambios hechos para puesta en producción en cada ambiente son documentados para el manejo de versiones, date/time stamp, identificación del usuario que hace la puesta en producción del cambio, y pasos de ejecución para la puesta en producción.
• Los cambios que fallan en su puesta en producción son analizados para determinar las causas de raíz, y esto se documenta para futura referencia de la organización.
• Se mantiene la disponibilidad de los componentes de la infraestructura dentro de los acuerdos de nivel de servicio y los requerimientos de negocios. Si la disponibilidad de estos componentes deben
28
ser interrumpidas, el downtime para la puesta en producción debe ser agendado en forma apropiada y los usuarios de los sistemas afectados notificados con anterioridad a la puesta en producción del cambio para asegurar continuidad de negocio.
Los procesos definidos son los que se enumeran a continuación:
1. Administración de cambios – El proceso que asegura que todos los cambios a la
infraestructura TI son llevados a cabo de manera planificada y autorizada.
2. Administración de issue y solicitud – El proceso que captura, analiza, prioriza, y reporta
el estado de las solicitudes de cambios a la infraestructura TI.
3. Administración de puesta en producción – El proceso de construir, configurar, integrar,
probar, y liberación de los cambios a la infraestructura TI dentro del negocio.
4. Solicitudes de arreglo / mejora – Solicitudes de negocio para mejorar la funcionalidad o
desempeño de la infraestructura TI existente.
5. Soporte de infraestructura - Una función organizacional que captura issues y solicitudes
de la infraestructura TI, los prioriza y envía a análisis, y administra su evolución a través
del ciclo de vida de la solución.-
6. Análisis de negocio – Análisis realizado a las solicitudes de infraestructura TI para
determinar la probabilidad de éxito, la relevancia de la solicitud en el negocio, y estimar
los recursos requeridos.
7. Análisis técnico – Análisis realizado a las solicitudes de infraestructura TI para
determinar su impacto en las dependencias del sistema, viabilidad técnica, y para definir
con mayor certeza los recursos tecnológicos y técnicas requeridas para el proyecto.
8. Ambiente – Un sistema computacional separado lógicamente de otras redes
computacionales, pensado para un propósito de negocio distintivo en el ciclo de vida de la
solución.
29
3.2 OBJETIVOS DE CONTROL
Los objetivos de control junto con las estructuras organizacionales fueron diseñados para
asegurar, de una manera razonable, que:
• Se alcancen los objetivos del negocio.
• Los eventos no deseados son prevenidos o detectados y corregidos.
Para lograr los objetivos de control, se implementan políticas, planes, procedimientos y controles.
3.2.1 OBJETIVOS DE CONTROL COBIT
Los objetivos de control definidos para la administración de cambios en COBIT son las
siguientes:
AI6.1 Estándares y procedimientos para cambios
Establecer procedimientos de administración de cambio formales para manejar de manera
estándar todas las solicitudes (incluyendo mantenimiento y patches) para cambios a
aplicaciones, procedimientos, procesos, parámetros de sistema y servicio, y las plataformas
fundamentales.
AI6.2 Evaluación de impacto, priorización y autorización
Garantizar que todas las solicitudes de cambio se evalúan de una estructurada manera en
cuanto a impactos en el sistema operacional y su funcionalidad. Esta evaluación deberá
incluir categorización y priorización de los cambios. Previo a la migración hacia
producción, los interesados correspondientes autorizan los cambios.
AI6.3 Cambios de emergencia
Establecer un proceso para definir, plantear, evaluar y autorizar los cambios de emergencia
que no sigan el proceso de cambio establecido. La documentación y pruebas se realizan,
posiblemente, después de la implantación del cambio de emergencia.
AI6.4 Seguimiento y reporte del estatus de cambio
Establecer un sistema de seguimiento y reporte para mantener actualizados a los solicitantes
de cambio y a los interesados relevantes, acerca del estatus del cambio a las aplicaciones, a
30
los procedimientos, a los procesos, parámetros del sistema y del servicio y las plataformas
fundamentales.
AI6.5 Cierre y documentación del cambio
Siempre que se implantan cambios al sistema, actualizar el sistema asociado y la
documentación de usuario y procedimientos correspondientes. Establecer un proceso de
revisión para garantizar la implantación completa de los cambios.
3.2.2 OBJETIVOS DE CONTROL SARBANES-OXLEY
Los objetivos de control definidos en “IT Control Objectives for Sarbanes-Oxley: The Role of IT
in the Design and Implementation of Internal Control Over Financial Reporting, 2nd Edition” son
los siguientes:
• Las solicitudes de cambio a programas, cambios al sistema y el mantenimiento
(incluyendo cambios al software del sistema) son estandarizadas, logeados, aprobados,
documentados y sujeto a procedimientos formales de administración de cambios.
• Solicitudes de cambios de emergencias son documentados y sujetos a procedimientos
formales de administración de cambios.
• Existen controles para restringir la migración de programas a producción sólo a
individuos autorizados.
• La gerencia de TI implementa software de sistema que no perjudica la seguridad de los
datos y programas almacenados en el sistema.
3.3 CHECKLIST PARA LOS OBJETIVOS DE CONTROL
Cobit es un framework para administrar la governancia del riesgo y el control de la Tecnología de
la Información (TI). Cobit incluye controles para cubrir todos los aspectos de la governancia de la
TI, y provee objetivos a nivel de entidad como también a nivel de actividades junto con sus
controles asociados.
31
La ley Sarbanes-Oxley fue impulsado por el congreso de los Estados Unidos de América con el
objetivo de asignar una responsabilidad corporativa explícita sobre los estados financieros de una
empresa. La ley fue creada para restaurar la confianza de los accionistas en el mercado público de
los E.E.U.U., que se vio dañado por escándalos empresariales y lapsos en la gobernabilidad
corporativa.
Este checklist se enfoca principalmente en el proceso de Administrar Cambios, aplicando los
objetivos de control definidos en el Cobit como también los controles generales de TI que
permitirá al proceso conformar a la Ley Sarbanes-Oxley.
La administración de cambio, en el contexto de la ley Sarbanes-Oxley, maneja; como una
organización modifica la funcionalidad del sistema para ayudar al negocio a cumplir con sus
objetivos de reportes financieros. Las deficiencias en esta área podrían afectar significativamente
los reportes financieros. Por ejemplo, cambios a los programas que asignan datos financieros a
cuentas requieren de aprobaciones apropiadas y pruebas antes de efectuar el cambio para que se
mantenga una clasificación apropiada y la integridad de los reportes.
3.3.1 OBJETIVOS DEL CHECKLIST
Controlar la evaluación de impacto, autorización e implantación de todos los cambios a la
infraestructura de TI, aplicaciones y soluciones técnicas, minimizando errores que se deben a
especificaciones incompletas de la solicitud y detener la implantación de cambios no autorizados.
Sin perder de vista la conformidad a la ley de Sarbanes-Oxley.
3.3.2 ALCANCE DEL CHECKLIST
Todos los cambios, incluyendo el mantenimiento de emergencia y parches, relacionados con la
infraestructura y las aplicaciones dentro del ambiente de producción, deben administrarse
formalmente y controladamente. Los cambios (incluyendo procedimientos, procesos, sistema y
parámetros del servicio) se deben registrar, evaluar y autorizar previo a la implantación y revisar
contra los resultados planeados después de la implantación. Esto garantiza la reducción de riesgos
que impactan negativamente la estabilidad o integridad del ambiente de producción.
32
También está dentro del alcance de este trabajo todos los controles que ayudan a mitigar los
riesgos que podrían afectar los estados financieros (controles Sarbanes-Oxley). Estos controles
proporcionan una seguridad razonable que los cambios de sistema que afectan reportes
financieros son autorizados y debidamente testeados antes de ser migrados a producción.
3.3.3 DESARROLLO DEL CHECKLIST
Para lograr los objetivos planteados se deberán cumplir los siguientes objetivos de control
definidos en Cobit:
• AI6.1 Estándares y procedimientos para cambios. Establecer procedimientos de
administración de cambio formales para manejar de manera estándar todas las solicitudes
(incluyendo mantenimiento y parches) para cambios a aplicaciones, procedimientos,
procesos, parámetros de sistema y servicio, y las plataformas fundamentales.
• AI6.2 Evaluación de impacto, priorización y autorización. Garantizar que todas las
solicitudes de cambio se evalúan de una estructurada manera en cuanto a impactos en el
sistema operacional y su funcionalidad. Esta evaluación deberá incluir categorización y
priorización de los cambios. Previo a la migración hacia producción, los interesados
correspondientes autorizan los cambios.
• AI6.3 Cambios de emergencia. Establecer un proceso para definir, plantear, evaluar y
autorizar los cambios de emergencia que no sigan el proceso de cambio establecido. La
documentación y pruebas se realizan, posiblemente, después de la implantación del
cambio de emergencia.
• AI6.4 Seguimiento y reporte del estatus de cambio. Establecer un sistema de seguimiento
y reporte para mantener actualizados a los solicitantes de cambio y a los interesados
relevantes, acerca del estatus del cambio a las aplicaciones, a los procedimientos, a los
procesos, parámetros del sistema y del servicio y las plataformas fundamentales.
• AI6.5 Cierre y documentación del cambio. Siempre que se implantan cambios al sistema,
actualizar el sistema asociado y la documentación de usuario y procedimientos
correspondientes. Establecer un proceso de revisión para garantizar la implantación
completa de los cambios.
33
Para comprobar el cumplimiento de estos objetivos se confeccionó el siguiente checklist:
� Los procedimientos de cambio están formalmente definidos, incluidos los cambios de
emergencia.
� Los procedimientos son conocidos por los empleados que realizan los cambios.
� Los cambios son evaluados (en cuanto a riesgo).
� Los cambios se clasifican por prioridad.
� Los cambios se autorizan antes de realizarlos.
� Hay un seguimiento del estado de los cambios.
� Se pueden ver reportes de los cambios.
Por el lado de Sarbanes-Oxley, se definen los siguientes controles.
• Las solicitudes de cambio a programas, cambios al sistema y el mantenimiento
(incluyendo cambios al software del sistema) son estandarizadas, logeados, aprobados,
documentados y sujeto a procedimientos formales de administración de cambios.
• Solicitudes de cambios de emergencias son documentados y sujetos a procedimientos
formales de administración de cambios.
• Existen controles para restringir la migración de programas a producción sólo a
individuos autorizados.
• La gerencia de TI implementa software de sistema que no perjudican la seguridad de los
datos y programas almacenados en el sistema.
Para comprobar estos controles se confeccionó el siguiente checklist:
� Existe una documentación del proceso de administración de cambios, y es mantenido para
reflejar el proceso actual.
� Existen procedimientos para la administración de cambios en el ambiente productivo,
incluyendo cambios a programas, mantenimiento del sistema y cambios a la
infraestructura.
� Evalúe el proceso utilizado para controlar y monitorear las solicitudes de cambio.
34
� Considere si las solicitudes de cambio son iniciada en forma apropiada, contando con
aprobación y seguimiento del mismo.
� Determine si los cambios a programas son realizados en un ambiente controlado y
segregado.
� Seleccione una muestra de cambios realizados a aplicaciones/sistemas para determinar si
fueron testeados adecuadamente y aprobados antes de pasar a un ambiente productivo.
Establece si lo siguiente está incluido en el proceso de aprobación: operaciones,
seguridad, administración de infraestructura TI y administración de TI.
� Evalúe procedimientos diseñados para determinar que sólo cambios
aprobados/autorizados son migrados a producción.
� Trace la muestra de cambios hacia el log de solicitud de cambio y su documentación de
soporte.
� Confirme que estos procedimientos atienden la implementación oportuna de parches y
software de sistema. Seleccione una muestra para determinar la conformidad a los
procedimientos documentados.
� Determine si existe un proceso para controlar y supervisar cambios de emergencia.
� Determine si un camino de auditoria existe de todas las actividades de emergencia y
verifique que sea revisada en forma independiente.
� Determine que los procedimientos requieran que los cambios de emergencia sean
soportados por una documentación apropiada.
� Establezca que procedimientos de “backout” son desarrollados para cambios de
emergencia.
� Evalúe procedimientos asegurando que todos los cambios de emergencia son testeados y
sujetos a procedimientos de aprobación estándares después de realizados. Revise una
muestra de cambios guardados como cambios de “emergencia”, y determine si contienen
la aprobación necesaria y si el acceso necesario caducó después de cierto tiempo fijado.
Establezca que la muestra de cambios fueron bien documentados.
35
� Evalúe las aprobaciones requeridas antes de migrar un programa a producción. Considere
aprobaciones de los dueños de sistema, personal de desarrollo y operaciones
computacionales.
� Confirme que hay una segregación de deberes adecuada entre el personal responsable de
la migración del programa a producción y el personal de desarrollo. Obtenga y testea la
evidencia para soportar esta aseveración.
� Determine que una evaluación de riesgo del impacto potencial de los cambios a un
software de sistema se realicen. Revise los procedimientos para testear los cambios a
software de sistemas en un ambiente de desarrollo antes que se apliquen en producción.
Verifique que existan procedimientos de “backout”.
3.3.4 CONCLUSIONES DEL CHECKLIST
Se pueden mitigar los riesgos generales de TI implementando los objetivos de control definidos
en el framework de Cobit. Particularmente existen objetivos de control definidos para conformar
a la ley Sarbanes-Oxley. Estos controles son todos aquellos que tienen influencia directa sobre los
estados financieros de la organización. Estos objetivos de control se pueden cumplir total o
parcialmente mediante controles configurados automáticos, definición de procedimientos,
programas de control, estrategias de liberación, manejo de perfiles, controles manuales, o un
conjunto de algunos o todos los controles mencionados. Por parte de la auditoria se privilegia los
controles automáticos antes que los manuales ya que se considera más duro en el sentido que no
permite que se materialice el riesgo del “error humano”.
3.4 CREACIÓN DE POLÍTICAS Y PROCEDIMIENTOS
Una política es una declaración o un plan formal, breve, y de alto nivel que captura las creencias,
metas, objetivos, y procedimientos aceptables de una organización para un tema o área
específica. Las políticas exponen acciones requeridas, y pueden incluir indicaciones a estándares.
Los atributos de una política incluyen:
• Requiere cumplimiento (obligatorio).
• La falta de cumplimiento resulta en acciones disciplinarias.
36
• Enfocado a resultados deseados, no en el proceder de la implementación.
• Complementado con estándares y directrices (guidelines).
OBJETIVOS
Identificar las acciones necesarias para las tareas relacionadas con la Creación de Políticas y
Procedimientos de la Compañía.
ALCANCE
Todos los procedimientos que requieran ser creados de la Compañía.
VIGENCIA
Este procedimiento de Creación de Políticas y Procedimientos entrará en vigencia a partir del
01/05/2007.
RESPONSABLES
Todos los Dueños de Procesos y Jefaturas / Gerencias de Área son responsables del
cumplimiento de este procedimiento.
3.4.1 DESARROLLO
OPORTUNIDAD
Este procedimiento debe ser llevado a cabo cada vez que se requiera crear una Política o un
Procedimiento en la Compañía relacionado con TI. Entre los motivos que desencadenan la
creación de un documento de este tipo se destaca:
• Una exigencia del Área de revisar y actualizar sus procedimientos semestralmente.
• La Política o Norma implantada por la Compañía hace necesario que el área modifique su
forma de trabajo.
• Adquisición de una nueva herramienta o la realización de una nueva actividad por el área
que obliga a realizar las actividades de distinta manera, por lo que debe realizarse un
nuevo procedimiento o formulario.
37
Descripción Responsable 1. Analizar el proceso que impulsa el procedimiento, política o
formulario y analizar si este requerimiento involucra a distintos entes de la Compañía.
2. Si el procedimiento puede afectar a otras áreas o entes realizar
una reunión con todos los entes involucrados para que realicen la evaluación de los lineamientos del procedimiento / formulario.
3. Realizar la evaluación de los lineamientos del procedimiento
y dejar los documentos en la Minuta de Reunión. 4. Desarrollar la Política, Formulario o Procedimiento solicitado. 5. Entregar y explicar la política / procedimiento al contralor de
normativa. 6. Validar y dar visto bueno en caso que corresponda. 7. Entregar a Gerencia de Área. 8. Revisar el procedimiento, formulario o política creados para
verificar si cumple con el requerimiento inicial. 9. Si no aprueba el documento realizado, informar al Dueño del
Proceso y volver al paso 1 de este procedimiento. 10. Si aprueba el documento desarrollado, dejar el documento
como versión inicial e indicar la fecha de vigencia del documento y el nombre de quien lo realizó.
11. Realizar la publicación y difusión oficial del documento para
que entre en funcionamiento. 12. Si el nuevo procedimiento involucra un cambio importante en
la forma de actuar de los usuarios afectados, realizar una capacitación para implantar el procedimiento con todos los usuarios involucrados. Se debe registrar la capacitación.
13. Almacenar el documento en el repositorio de procedimientos.
Dueño del Proceso Dueño del Proceso Entes Involucrados Dueño del Proceso Dueño del Proceso Contralor de Normativa Dueño del Proceso Gerencia de Área Gerencia de Área Dueño del Proceso Dueño del Proceso Dueño del Proceso Dueño del Proceso
38
3.4.2 PLANTILLA PARA UNA POLÍTICA
A continuación se muestra la estructura de una política tipo, junto con las preguntas que se deben
contestar.
INTRODUCCIÓN O VISIÓN GENERAL
• ¿Porque se implementa esta política?
• ¿Cuáles comportamientos se intenta gobernar?
• ¿Qué problema o conflicto se pretende resolver con esta política?
• ¿Cuál es el beneficio general?
ALCANCE
• ¿Quién debe observar la política?
• ¿Quién debe comprender la política para desarrollar su trabajo?
• ¿Qué grupos o tecnologías están incluidas en la política?
• ¿Existen excepciones a la política?
DECLARACIONES DE LA POLÍTICA
• ¿Cuáles comportamientos se intenta gobernar?
• ¿Cuáles son las responsabilidades que deben cumplir cada individuo para lograr la
adhesión?
• ¿Cuáles son los requerimientos técnicos generales de los individuos y dispositivos para
estar en adherencia con la política?
REFERENCIAS
• Documentación de estándares correspondientes.
• Enlaces a las directrices relacionadas con las declaraciones de la política.
ACCIONES DISCIPLINARIAS
• Esta sección identifica las penalidades por violar la política.
39
DEFINICIONES
• Define acrónimos y términos técnicos que permiten un mejor entendimiento de la política
por parte del lector.
HISTORIAL DE REVISIONES
• Contiene un breve resumen de las revisiones hechas a la política, comenzando por la
fecha de implementación inicial.
3.5 POLÍTICA DESARROLLADA
La política expuesta a continuación fue desarrollada utilizando la plantilla del punto anterior.
3.5.1 INTRODUCCIÓN
La infraestructura de TI de la Compañía está en continua expansión y se torna cada vez más
compleja. Hay más personas dependientes de los sistemas de información, mayor cantidad de
equipos clientes, sistemas administrativos en expansión y renovación, y mayor cantidad de
aplicaciones. A medida que crezca la interdependencia de la infraestructura TI, se vuelve esencial
la necesidad de un fuerte proceso de administración de cambios.
Continuamente se requiere realizar mejoras o mantenimientos a los sistemas de información,
éstos pueden ser planificados o no. Es crítico administrar estos cambios para disponer de una
infraestructura de TI robusta que pueda entregar valor a la empresa.
El propósito de la política de administración de cambios es manejar los cambios de manera
racional y predecible para que los empleados y clientes se puedan adaptar fácilmente a estos
cambios. Los cambios requieren de una planificación seria, monitoreo cuidadoso, y post
evaluación para reducir los impactos negativos a la comunidad de usuarios y aumentar el valor a
los recursos de información.
3.5.2 ALCANCE
La política de administración de cambios aplica a todos los individuos que instalan, operan, o
realizan mantenimiento de recursos de información.
40
3.5.3 DECLARACIONES DE LA POLÍTICA
• Cada cambio a un recurso de información de la Compañía tales como: sistemas
operativos, hardware computacional, redes, y aplicaciones está sujeto a la política de
administración de cambios y debe seguir los procedimientos de la administración de
cambios.
• Un comité de administración de cambios, asignado por la gerencia de TI, se reunirá
regularmente para revisar solicitudes de cambio y asegurar que los procedimientos se
están ejecutando satisfactoriamente.
• Se debe presentar una solicitud de cambio formal para todos los cambios, sean
programados o no.
• Todas las solicitudes de cambio programado debe ser presentado de acuerdo a los
procedimientos de administración de cambios para que el comité tenga el suficiente
tiempo para revisar la solicitud, determinar y revisar fallas potenciales, y tomar la
decisión de permitir o detener la solicitud.
• Cada solicitud de cambio programado debe recibir la aprobación formal del comité antes
de proceder con el cambio.
• El líder designado del comité de administración de cambios puede denegar cambios
programados por razones que incluyen, pero no están limitados a, planificación
inadecuada, planificación de retroceso inadecuada, la programación de cambio impactará
negativamente un proceso de negocio clave tal como cierre de balance, o si no se puede
disponer de los recursos necesarios en forma oportuna. Recursos adecuadas puede ser un
problema para los fines de semana, festivos, o durante eventos especiales.
• Una vez completados los procedimientos de la administración de cambios para un cambio
programado o no programado, se debe notificar el cambio al cliente (o usuario).
• Se debe completar la revisión de cambios para todo cambio, programado o no
programado, exitoso o no.
• Se debe mantener una bitácora de administración de cambios para todos los cambios. La
bitácora debe contener, pero no está limitada a:
o Fecha de presentación y fecha del cambio.
41
o Información de contacto del dueño y del encargado.
o Naturaleza del cambio.
o Indicar éxito o fracaso
• Todos los sistemas de información de la Compañía deben adherirse a un proceso de
administración de cambios que cumple los estándares enfatizados arriba.
3.5.4 REFERENCIAS
Procedimientos y estándares definidos.
3.5.5 ACCIONES DISCIPLINARIAS
El incumplimiento de esta política puede resultar en una acción disciplinaria que puede incluir el
desahucio de empleados y temporales; la terminación de relaciones en el caso de contratistas o
consultores; despido para practicantes y voluntarios; o suspensión o expulsión en el caso de un
estudiante. Adicionalmente, los individuos están sujetos a perder los privilegios y accesos a los
recursos de información de la empresa como también eventualmente recibir sanciones civiles o
penales.
3.5.6 DEFINICIONES
Recurso de Información – cualquier y todo papel impreso, dispositivo de pantalla, medio de
almacenamiento, y todas las actividades relacionado a la computación que involucra cualquier
dispositivo capaz de recibir correo electrónico, navegar sitios web, o capaces de recibir,
almacenar, administrar, o transmitir datos electrónicos incluyendo, pero no limitado a,
mainframes, servidores, computadores personales, notebooks, hand-helds, PDAs, localizador,
sistemas de procesamiento distribuido, recursos de telecomunicación, redes, teléfonos, máquinas
de fax, e impresoras.
Dueño – El gerente o agente responsable de la función soportada por el recurso, el individuo que
tiene la responsabilidad de llevar a cabo el programa que utiliza los recursos. El dueño es
responsable de establecer los controles que proporcionan la seguridad. El dueño de una colección
de información es la persona responsable de los resultados de negocio de ese sistema. En ciertas
ocasiones pueden existir múltiples dueños de distintos departamentos para una misma función.
42
Encargado – Guardián o apoderado; el retenedor de datos, el agente encargado de implementar
los controles especificados por el dueño. El encargado es responsable del procesamiento y
almacenamiento de la información. Para aplicaciones grandes (mainframe, servidores) el
encargado es Servicios de Información; para mini y micro aplicaciones el dueño o usuario pueden
retener las responsabilidades de encargado. El encargado es normalmente un proveedor de
servicios.
Administración de cambios – El proceso de controlar las modificaciones al hardware, software,
firmware, y documentación para asegurar que los recursos de información estén protegidos contra
cambios inadecuados antes, durante, y después de la implementación de sistemas.
Cambio: –
• Cualquier implementación de una nueva funcionalidad.
• Cualquier interrupción de servicio.
• Cualquier reparación de una funcionalidad existente.
• Cualquier eliminación de una funcionalidad existente.
Cambio programado – La notificación formal recibido, revisado, y aprobado por el proceso de
revisión previo al cambio siendo ejecutado.
Cambio no programado – La falta de presentar una notificación al proceso formal con
anterioridad al cambio siendo ejecutado. Los cambios no programados sólo serán aceptables en el
evento de una falla de sistema o el descubrimiento de una vulnerabilidad de seguridad.
3.6 NORMA DESARROLLADA
La norma expuesta a continuación es una extensión de una norma existente (en desarrollo) en la
embotelladora.
43
3.6.1 INTRODUCCIÓN
OBJETIVO
Garantizar el correcto y seguro funcionamiento de los sistemas aplicativos que la Compañía
desarrolle o adquiera y, que éstas a su vez provean de las herramientas necesarias para garantizar
un correcto control, auditabilidad y una eficiente administración de la seguridad de las mismas.
ALCANCE
Todos los ambientes de procesamiento, las aplicaciones, sistemas operativos, utilitarios y
software base que se instalen en la Compañía.
VIGENCIA
Esta norma de Seguridad en el Desarrollo y Mantenimiento de Sistemas Aplicativos entrará en
vigencia a partir del 01/12/2007.
RESPONSABLES
La Unidad Central de Sistemas Corporativa
DOCUMENTOS RELACIONADOS
• Metodología para la Implantación de Proyectos SAP
• Manual de Mantenimiento a Sistemas Existentes en Ambiente AS400
• Procedimiento de traspaso a ambiente Productivo AS400.
• Norma de roles y responsabilidades de seguridad de la información.
Nota: Sólo se indican los documentos que deben estar relacionados, pero no forman parte del
trabajo de título.
3.6.2 GENERAL
El desarrollo, adquisición, mantenimiento o instalación de software o hardware que maneje
recursos de información, debe ser normado y coordinado con la Unidad Central de Sistemas, de
manera que se resguarde la homogeneidad, integridad, calidad y seguridad de los recursos.
44
Las etapas de diseño o evaluación técnica de todo proyecto o recurso relacionado con el
procesamiento, almacenamiento y transmisión de la información, debe ser objeto de un análisis
de riesgo de seguridad, sobre la base de los cuales se adopten o parametricen los controles
automáticos internos y administrativos pertinentes.
La Compañía debe contar con herramientas y técnicas formales para conducir el desarrollo,
mantenimiento y adquisición de los sistemas, los que deben incorporar los elementos de
seguridad requeridos por la Compañía.
3.6.3 SEPARACIÓN DE AMBIENTES Y FUNCIONES
Para un correcto traspaso del hardware, software base y sistemas de aplicación a producción, se
debe tener una estructura de separación de ambientes que considere:
AMBIENTE DE DESARROLLO
Ambiente donde residen todos los recursos informáticos necesarios para efectuar tareas de
análisis y programación en sus etapas de desarrollo, mantenimiento y prueba. Es de uso exclusivo
del personal de desarrollo y comprende:
• Ambiente para los utilitarios de desarrollo: Donde reside el software utilizado por el
personal del área de Desarrollo para la realización de sus trabajos (utilitarios,
compiladores, etc.).
• Ambiente para desarrollo de las tareas de análisis y programación: Donde residen los
programas / configuraciones que están siendo desarrollados / mantenidos y los archivos de
prueba.
Para el ambiente de desarrollo se debe implementar la arquitectura lógica de modo que:
• Los perfiles de usuario con funciones de desarrollo no puedan acceder a los recursos
informáticos de producción salvo, en modo consulta, en casos justificados ante
situaciones de emergencia operativa o en horario de Emergencia y con la autorización
correspondiente.
• Se deben realizar todos los desarrollos, modificaciones y pruebas de programas en el
ambiente de desarrollo.
45
AMBIENTE DE PRUEBA
Consiste en el ambiente donde el área solicitante de la aplicación o los lideres de SAP (en caso de
desarrollos en SAP) realizan las pruebas integrales con los usuarios, sin intervención de los
desarrolladores (salvo en el caso en que éstos deban preparar datos, etc. para la prueba). En este
ambiente se certifica que la aplicación cumple con los requerimientos establecidos. Luego se da
la autorización para la posterior puesta en producción. Residen los programas fuentes, sus
correspondientes programas objeto y las respectivas configuraciones necesarias para las pruebas.
AMBIENTE DE PRODUCCIÓN
Ambiente de trabajo donde reside la información y programas en operación, siendo el lugar de
trabajo del personal afectado a tareas de producción. En este ambiente se realiza el procesamiento
de los datos reales operativos y comprende:
• Ambiente para programas ejecutables: Donde residen las versiones aprobadas de los
programas objetos y las correspondientes configuraciones.
• Ambiente para datos reales: Donde residen los archivos físicos de los datos y las vistas
lógicas asociadas utilizadas por las aplicaciones.
Para el ambiente de producción se debe implementar la arquitectura lógica de modo que:
• Los perfiles de usuario con funciones de operación sólo puedan acceder al ambiente de
desarrollo para efectuar copias de respaldo.
• Los perfiles de usuario con funciones de operación no puedan acceder a los recursos
informáticos (utilitarios) que permitan realizar modificaciones a los programas y a los
datos, o poseer accesos que les permitan ejecutar operaciones altamente riesgosas (como
bajadas de memoria, cambios de configuración de los sistemas operativos, etc.).
• Sólo pueda acceder a los recursos de seguridad el Administrador de Sistemas
correspondiente.
• Como excepción, ante situaciones de emergencia operativa o en horario de Emergencia,
cuando el personal del área de Desarrollo requiera el acceso a los programas y datos
reales para tareas de soporte, debe previamente obtener la autorización expresa del
Propietario de datos correspondiente y para el caso de AS400 cumplir con el
Procedimiento de traspaso a ambiente Productivo AS400. El Propietario de datos puede
46
autorizar el acceso por un tiempo determinado, a su discreción, con los siguientes
permisos:
o Con un usuario con permisos de consulta sobre los programas / configuraciones y
los datos de la aplicación.
o Con un usuario de máximos permisos sobre la aplicación, que adicionalmente
debe ser auditado automáticamente por el sistema.
La Unidad Central de Sistemas deberá velar que los ambientes de desarrollo y pruebas sean
compatibles y reflejen adecuadamente la parametrización del ambiente de producción, de manera
de asegurar que los traspasos al ambiente de producción funcionen adecuadamente.
3.6.4 DESARROLLO / ADQUISICIÓN DE SISTEMAS
GENERAL
Para todo proyecto que se desarrolle y/o compre, la Compañía debe contar con toda la
documentación que respalde las aprobaciones necesarias para la compra y/o desarrollo de
sistemas de aplicación.
La documentación necesaria para comenzar el proyecto consiste en la solicitud por escrito, por
parte del Jefe o Gerente del área solicitante a la Unidad Central de Sistemas, quién deberá evaluar
el proyecto. Para ello, la UCS deberá generar los formularios necesarios para registrar las
especificaciones, requerimientos y otros datos necesarios para llevar a cabo el proyecto. Todas las
aprobaciones deben quedar documentadas formalmente.
Todas las aplicaciones nuevas deben tener definidos sus requerimientos de acceso, integridad y
privacidad de datos, durante la etapa de definición. Es responsabilidad del Jefe de Proyectos de la
Unidad Central de Sistemas asegurar que todas las especificaciones estén de acuerdo a los
requerimientos de esta norma. Se debe cumplir con las siguientes disposiciones:
• Asegurar que los sistemas desarrollados o adquiridos se puedan manejar en forma
coordinada y coherente con los sistemas de seguridad instalados en las plataformas donde
se ejecuten.
47
• Verificar que la arquitectura de todo sistema aplicativo o software de base contemple una
separación lógica de sus componentes, de forma tal que permita una eficiente
administración de seguridad (segregación de funciones y/o tareas incompatibles, controles
por oposición, etc.).
• Controlar que las funciones sensibles de los sistemas aplicativos soliciten al usuario
controles adicionales para su autenticación (diferente de su contraseña) al momento de
llevar a cabo la función, de forma de reconfirmar la identidad del usuario que efectúa la
operación.
• Verificar que los sistemas incluyan:
o Registros de pistas de auditoría, sobre transacciones de archivos críticos.
o Información necesaria para poder reconstruir o revertir lo que se realizó.
o Mecanismos de recuperación de los datos, de manera de garantizar la continuidad
de las operaciones.
• Evaluar las funciones provistas por los nuevos sistemas aplicativos o de base que pudieran
comprometer la seguridad de los datos. Definir e implementar los procedimientos de
seguridad de accesos y parámetros necesarios, para controlar dichas funciones. Analizar el
impacto de los mismos sobre los sistemas de seguridad y efectuar las modificaciones que
correspondan.
• Asegurar que todo servicio de desarrollo adquirido contemple la utilización de una
metodología que cubra la totalidad del ciclo de vida de la aplicación y documente cada
uno de sus pasos, ésta será la definida por la Compañía y en caso que la Compañía no
tenga definida una metodología, el proveedor deberá utilizar una metodología propia.
• Asegurar que la documentación de los sistemas describa todos los controles de seguridad
y como se han de implementar.
Si se están desarrollando proyectos paralelos en SAP y con distintas consultoras, se debe nombrar
a un coordinador que conozca en profundidad la aplicación para evitar conflicto en las
parametrizaciones. El coordinador debe validar que las parametrizaciones de un proyecto no
“sobre escriban” las del otro y viceversa.
48
REQUERIMIENTOS DE SEGURIDAD DE SISTEMAS
La Unidad Central de Sistemas debe asegurar que los sistemas de información que desarrollen,
mantengan o adquieran, tengan incorporadas las medidas de seguridad que se especifica en las
normas de seguridad de la información. Los requerimientos de seguridad deben ser identificados
y aprobados antes del desarrollo de los sistemas de información. Todos los requerimientos de
seguridad, deben ser identificados en la fase de requerimientos de un proyecto y justificados,
aprobados y documentados como una parte de la totalidad del caso de negocios de un sistema de
información.
Los requerimientos de seguridad de sistemas, se realizan para asegurar que todos los sistemas de
aplicación a desarrollar y/o adquirir provean las herramientas necesarias para garantizar la
seguridad de los datos y permitir un correcto control y auditabilidad (manuales técnicos,
manuales de usuario, controles automáticos, etc.). Los controles deben ser introducidos en la
etapa de diseño. En el anexo A se detallan algunos controles automáticos que se pueden
implementar.
Pueden ser necesarios controles adicionales para sistemas que procesan o tienen impacto en
recursos sensibles, valiosos o críticos para la organización. Tales controles deben ser
determinados sobre la base de requerimientos de seguridad y evaluación de riesgo de cada uno de
los activos identificados. Para el desarrollo, mantenimiento y/o adquisición de software de
aplicación deben tenerse en cuenta las siguientes consideraciones:
Control de los accesos
Todo software de aplicación debe poseer un sistema de control de accesos de los usuarios a los
recursos, que permita:
• Identificación del usuario que ingresa a la aplicación.
• Posibilidad de separar las distintas funcionalidades y transacciones desde un punto de
vista de control interno y segregación de funciones.
• Asignación de accesos a las transacciones a través de grupos / perfiles tipos que luego
serán asignados a los usuarios correspondientes.
49
Controles de Entrada
Los datos de entrada en los sistemas de aplicación, deben ser validados para asegurar que son
correctos y apropiados. Los controles deben ser aplicados a las entradas de las transacciones,
datos permanentes (nombres y direcciones, límites de crédito, números de referencia al cliente) y
tablas de parámetros (tasa de impuestos, índice de conversión de dinero). Para esto se deben
considerar los siguientes controles:
• Controles de entrada para detectar los siguientes errores:
o valores fuera de rango;
o caracteres inválidos en campos de datos;
o datos faltantes o incompletos;
o controles de datos no autorizados o inconsistentes.
• Determinación de las responsabilidades de todo el personal involucrado en el proceso de
entrada de datos.
Controles de Salida
La Compañía debe garantizar la validación de los datos de salida de un sistema de aplicación,
asegurando que el procesamiento de la información almacenada sea correcto y adecuado a las
necesidades de cada proceso de información. La validación de salidas puede incluir:
• Comprobaciones de la razonabilidad para probar si los datos de salida son aceptables;
• Control de conciliación de cuentas para asegurar el procesamiento de todos los datos;
• Provisión de información suficiente, para que el sistema de procesamiento subsiguiente,
determine la exactitud, totalidad, precisión y clasificación de la información;
• Procedimientos para responder a las pruebas de validación de salidas;
• Definición de las responsabilidades de todo el personal involucrado en el proceso de
salida de datos.
Controles de parámetros y eventos de seguridad
La aplicación debe contar con reportes de control de acuerdo con las definiciones de seguridad
implementadas. Debe incluir registros de pistas de auditoría sobre transacciones de archivos
críticos para identificar usuario, fecha, hora, estación de trabajo, función realizada, y otros datos
necesarios para el control.
50
Evaluación por el área de Seguridad de la Información / Control Interno
El área de Seguridad de la Información / Control Interno debe evaluar, desde el punto de vista de
control interno, las nuevas funcionalidades y/o aplicaciones y definir los controles
correspondientes.
DESARROLLOS EXTERNOS
Cuando la Compañía opte para los desarrollos y/o mantenciones a los sistemas aplicativos por
proveedores externos, se deberá cumplir de igual forma con los requerimientos y normativas de
seguridad. Se debe realizar la diligencia debida para toda la selección de proveedores y
tecnología, considerando que ésta debe estar acorde a las regulaciones y legislación aplicable, y
los requisitos de seguridad de la información que son necesarios para asegurar el cumplimiento
con los estándares y políticas de la Compañía. Por lo tanto, la Unidad Central de Sistemas debe
considerar y evaluar los siguientes aspectos en el proceso de selección de su proveedor:
• Posibilidad de que la Compañía adquiera el código fuente de las aplicaciones.
• Descripción de las metodologías empleadas para el Desarrollo y Mantenimiento, Pruebas
y Traspaso a Producción de las aplicaciones, en caso de no aplicarse las definidas por la
Compañía.
• El Proveedor debería dar su acuerdo por escrito al derecho de la Compañía a realizar
auditorias de calidad del trabajo que se encuentre realizando el Proveedor para la
Organización.
• Indicar los lenguajes y herramientas utilizadas para el Desarrollo y Mantenimiento de
Sistemas.
• Definición de las condiciones del servicio de Desarrollo y Mantenimiento de Sistemas:
recursos involucrados, control de calidad, documentación mínima, forma de costeo y
propiedad intelectual de lo obtenido de dichos desarrollos.
• Consultar si el Proveedor estará obligado a prestar asistencia para la migración de los
datos y programas en caso de un eventual traslado del procesamiento a otra plataforma o
proveedor.
• Determinar a quien compete la responsabilidad sobre la actualización de la
documentación de los sistemas aplicativos.
51
• Asegurar que los sistemas a desarrollar por el Proveedor se puedan manejar en forma
coordinada y coherente con los sistemas de seguridad instalados en las plataformas donde
se ejecuten.
• Verificar que la arquitectura de todo sistema aplicativo o software de base contemple una
separación lógica de sus componentes, de forma tal que permita una eficiente
administración de su seguridad (segregación de funciones y/o tareas incompatibles,
controles por oposición, etc.).
• Controlar que las funciones sensibles de los sistemas aplicativos soliciten al usuario
controles adicionales para su autenticación (diferente de su contraseña) al momento de
llevar a cabo la función, de forma de reconfirmar la identidad del usuario que efectúa la
operación.
• Asegurar que si la adquisición incluye la prestación de servicios de operación y/o
mantenimiento de los sistemas, se incluya en el contrato el compromiso del Proveedor de
garantizar la continuidad de la prestación del servicio. Asimismo, dejar por escrito el
derecho de que la Compañía pueda recuperar los códigos fuentes correspondientes a su
Sistema, en caso que el Proveedor descontinúe sus servicios.
• Asegurar que la documentación de los sistemas describa todos los controles de seguridad
y como se han de implementar.
• Exigir como lugar de desarrollo de las aplicaciones, las instalaciones de la Compañía,
independiente del tipo de proyecto desarrollado, salvo para el caso de que la Compañía
sólo requiera de expertos externos y que revise el resultado en un esquema de laboratorio
de pruebas en las instalaciones de la Compañía, por ejemplo: La Homologación máquinas
Hand-held, en donde no hay valor agregado teniendo a los consultores fuera de sus
instalaciones, que es donde tienen la plataforma tecnológica requerida.
• Dar a conocer y verificar el cumplimiento de esta norma por los proveedores externos.
Además la Compañía debe definir en los contratos de desarrollo y mantenimiento de sistemas, los
requerimientos de seguridad que los sistemas a desarrollar por el Proveedor deben incluir:
52
• Registros de pistas de auditoría sobre transacciones de archivos críticos. Como mínimo
cada registro debe tener campos para identificar: usuario, fecha, hora, función realizada
(alta, baja, modificación).
• Mecanismos de controles de acceso (Contraseñas: largo mínimo, cambio periódico,
historial, bloqueo después de intentos fallidos).
• Registro de eventos de seguridad (intentos fallidos de conexión, intentos de accesos no
autorizados, etc.)
• Información necesaria para poder reconstruir o revertir lo que se realizó. (Por ejemplo
dato anterior y posterior).
• Mecanismos de recuperación de los datos, de manera de garantizar la continuidad de las
operaciones.
Asimismo, estos contratos deben incluir los siguientes aspectos:
• Acuerdos de licencia, propiedad de los códigos fuentes y derechos de propiedad
intelectual.
• Derecho a revisar y auditar el trabajo realizado por el tercero para verificar la integridad y
calidad del mismo.
• Definición de los requerimientos contractuales para la calidad del código a desarrollar por
el tercero.
• Realizar pruebas antes de la instalación del sistema, para verificar que el programa no
contenga código malicioso.
• Procedimiento o medida preventiva para la recuperación del código fuente, en caso que el
proveedor falle o discontinúe su servicio.
• Acuerdos de los niveles de servicio.
3.6.5 PRUEBA DE LOS SISTEMAS
Las características de las pruebas de seguridad de la información deben ser realizadas como parte
de un sistema de prueba. Es la responsabilidad del dueño de la información asegurarse que sean
tomadas las medidas apropiadas para proteger la información sensible en la fase de pruebas. Toda
53
prueba debe ser realizada en ambientes seguros separados, como se estipula en el punto 3
(Separación de Ambientes y Funciones).
La Unidad Central de Sistemas debe proteger y controlar los datos de prueba que se utilicen en la
aceptación del sistema. Se debe evitar el uso de bases de datos operativas que contengan
información personal o estratégica. Si se utiliza información de esta índole, ésta debe ser
despersonalizada antes del uso. Se deben aplicar los siguientes controles para proteger los datos
operativos, cuando los mismos se utilizan con propósitos de prueba:
• Los procedimientos de control de accesos, que se aplican a los sistemas de aplicación en
operación, también deben aplicarse a los sistemas de aplicación de prueba.
• Se debe llevar a cabo una autorización del propietario de los datos por separado, cada vez
que se copia información operativa a un sistema de aplicación de pruebas.
• Se debe borrar la información operativa de un sistema de aplicación de prueba
inmediatamente después de completada la misma.
• La copia y el uso de información operacional deben ser registrado a fin de suministrar una
pista de auditoria.
Para tareas de análisis y/o desarrollo cuando sea necesaria la copia de archivos con información
operativa real, se debe solicitar la correspondiente autorización expresa del Propietario de datos,
que debe quedar convenientemente registrada y conservada en poder del solicitante y una copia
al Administrador de Sistemas.
Las pruebas deben ser definidas en la etapa de diseño concienzudamente de manera de incluir la
mayor cantidad de escenarios y casos de prueba, de esta manera, disminuye el riesgo que una
aplicación falle. Cada vez que se realicen las pruebas, se debe documentar las pruebas realizadas
y los resultados obtenidos. Con el resultado de las pruebas, el área solicitante del requerimiento
debe dar la autorización a la Unidad Central de Sistemas para traspasar la aplicación a
producción. Para el caso de SAP, la autorización la entregará el Líder del Módulo que es quién
prueba.
54
El plan a diseñar debe considerar la ejecución de pruebas para verificar el correcto
funcionamiento de los controles de seguridad diseñados en las aplicaciones, de manera de reducir
al mínimo la probabilidad de existencia de vulnerabilidades (ausencia o falla de controles de
seguridad). El Anexo B contiene una serie de lineamientos y consideraciones al desarrollar un
plan de pruebas para los distintos sistemas aplicativos.
3.6.6 PUESTA EN PRODUCCIÓN
A fin de establecer un adecuado método para la puesta en producción del software base y los
sistemas aplicativos, se deben tener en cuenta las siguientes consideraciones:
• Verificar el cumplimiento de todos los puntos de control existentes para los desarrollos /
mantenimientos / adquisiciones de sistemas aplicativos o software base de acuerdo con las
metodologías de desarrollo, mantenimiento y adquisición de la Compañía.
• Impedir técnicamente que personal de desarrollo realice modificaciones a los sistemas
aplicativos en el ambiente de pruebas.
• Impedir que personal de desarrollo instale sistemas aplicativos en el ambiente de
producción.
• Asegurar que todo programa que se encuentre en condiciones de ser probado por el Sector
Usuario haya sido sometido a los siguientes controles:
o Comparación de las versiones para verificar la validez de los cambios realizados.
o Análisis de la existencia de rutinas o sentencias no autorizadas.
• Asegurar que exista una única versión de cada uno de los programas en los ambientes de
prueba y producción, tanto del programa fuente como del ejecutable y la correcta
correspondencia de los mismos.
Para el uso de versiones diferentes a las estándar se debe contar con la aprobación del Gerente de
Sistemas, Jefe de Proyectos o Jefe de Mantenimiento, según corresponda.
• El Oficial de Seguridad debe asegurar que los sistemas desarrollados o adquiridos se
puedan manejar en forma coordinada y coherente con los sistemas de seguridad instalados
en las plataformas donde se ejecuten.
55
• La información que se utilice para las pruebas debe ser revisada y aprobada, no se debe
exponer la información sensible para este fin.
• Aprobar y autorizar el pasaje a producción una vez realizadas las pruebas.
• Llevar un registro de todas las instalaciones efectuadas en el ambiente de producción. En
la misma se debe indicar como mínimo fecha, hora, ambiente de procesamiento,
identificación, recurso informático y responsable interviniente.
• Establecer un procedimiento de emergencia para dejar sin efecto los cambios efectuados y
poder recuperar las versiones autorizadas anteriormente, en caso de generarse problemas
no solucionables durante la instalación y período de control.
Todas las modificaciones efectuadas en caso de mantenimientos de emergencia deben ser
posteriormente sometidas a los controles definidos para la operatoria normal.
• Deben existir procedimientos que definan los pasos a seguir ante puestas en producción
planificadas y de emergencia.
• Realizar a posteriori, si no se realizaron en el momento de la instalación, los controles
correspondientes a los mantenimientos de emergencia.
• Coordinar con el Administrador de Sistemas que la seguridad correspondiente a todo
nuevo desarrollo / modificación sea implementada junto con su instalación en producción.
• Se debe controlar y aprobar toda modificación que se efectúe a las versiones existentes de
los sistemas de aplicación antes del pasaje a producción. Este rol está dado por la cadena
y estructura del proyecto a través de su Líder, además del Líder de módulo, aprobación de
pruebas por parte del Área Usuaria, del rol “Autorización de la Unidad Central de
Sistemas” y finalmente el Líder de la Sociedad.
• El área de soporte debe instalar el software de base o modificaciones a versiones
existentes en el ambiente de producción.
• El área de soporte debe implementar los parámetros de seguridad junto con la instalación
del software en producción.
56
• La Unidad Central de Sistemas es responsable de llevar un inventario de las versiones de
todas las instalaciones de software efectuadas en los equipos de procesamiento
centralizado, indicando como mínimo la versión, la fecha y hora de la instalación.
• Permitir a los consultores y/o desarrolladores internos la visualización de la
parametrización, y tablas de parametrización, en ambiente productivo.
• Verificar que previo a realizar algún traspaso de ambiente (mandante para SAP) los
consultores o desarrolladores internos revisen que una misma tabla está idéntica en
desarrollo, prueba y producción, excepto por las modificaciones que ha realizado para
transportar.
• Verificar que si una aplicación pasa al ambiente de prueba, se parametriza y después de
las pruebas se determina que no pasará al ambiente productivo, se deben volver a la
normalidad las parametrizaciones.
• Debe ser desarrollado el material adecuado de capacitación y documentación operativa
antes de que la aplicación sea puesta en ambiente productivo.
En caso de no poder aplicar lo antes descrito por tratarse de “paquetes cerrados”, se los deberá
someter a pruebas técnicas y funcionales que aseguren el cumplimiento de todo lo descrito en la
presente Norma. La Unidad Central de Sistemas deberá velar que el ambiente de prueba y
desarrollo, sean compatibles y reflejen adecuadamente al mandante de producción.
3.6.7 DOCUMENTACIÓN
Toda aplicación debe contar con los correspondientes documentos:
• Manual de usuario.
• Manual de Sistemas, el cuál indica las funcionalidades, configuraciones y
parametrizaciones del sistema.
• Manual Técnico, el cuál indica los procedimientos operativos y técnicos de la
implementación e instalación del sistema.
• Plan de pruebas, resultados, excepciones, y acciones tomadas.
57
Estos documentos deben ser tratados como documentos confidenciales y formales de la
Compañía, y los cambios deben ser autorizados por el nivel gerencial, y su custodia y
mantenimiento son responsabilidad de la Unidad Central de Sistemas. Si se realiza un
mantenimiento de una aplicación, aunque ésta sea menor, los cambios deben quedar reflejados en
los manuales correspondientes, de manera que éstos se encuentren actualizados y vigentes.
CONTROLES AUTOMÁTICOS PARA LOS SISTEMAS DE APLICACI ÓN
A continuación se detallan algunos de los controles automáticos para los sistemas de aplicación:
Tipos de Controles Controles Automáticos a Implementar
Controles de Entrada
- Identificación de autorización de usuario. - Validaciones de datos en línea. - Selección de datos en tablas ya validadas. - Totales de control de los campos numéricos. - Dígitos de verificación generados por algoritmos. - Verificación de límite y/o racionalidad.
Controles de Procesamiento
- Verificación de secuencias en los procesos. - Validaciones previas de los archivos de trabajo
antes de la actualización final. - Archivo de errores producidos. - Archivos de transacciones efectuadas.
Controles de Salida - Reportes de los resultados de los procesos. - Reportes de los errores producidos. - Registros en archivos de auditoría.
CONSIDERACIONES PARA LA REALIZACIÓN DE PRUEBAS
Preparación del ambiente de prueba
• Para lograr un exitoso proceso de prueba, el entorno de prueba adecuado debe ser
establecido previamente a la realización de dichas pruebas. Este debería contener todos
los componentes necesarios para testear los scripts desarrollados y permitir la finalización
de las pruebas dentro del tiempo planificado.
58
• Para asegurar que este ambiente ha sido creado correctamente, será necesario correr una
prueba de línea de base y compararlo con producción. Adicionalmente, antes que las
pruebas comiencen, se debe tomar un backup a ser utilizado en caso que una restauración
sea necesaria.
Procesamiento de los resultados de las pruebas
• Los resultados de todas las pruebas deben ser cuidadosamente revisados. Para ello se
deberá comparar los resultados obtenidos con los resultados esperados, y en base a ello
determinar si la prueba fue exitosa o no.
• Los problemas obtenidos deberán ser clasificados como así también su severidad e
impacto sobre otros aspectos del procesamiento.
• Si el resultado de la prueba es aceptado, deben ser registrados en el Log de prueba, y el
formulario debe ser firmado por la persona responsable de la aprobación.
• Si el resultado de la prueba no es aceptable, deberán ser analizados para determinar las
acciones necesarias para completar una prueba exitosa. Los Logs de prueba deberán
reflejar los resultados reales y las acciones a ser tomadas para identificar y/o corregir el
problema.
Preparación del reporte final de la prueba
• El reporte final de la prueba deberá documentar la finalización exitosa de la prueba y
validar que todos los criterios de aceptación han sido alcanzados. Deberá incluir
documentación de lo siguiente:
o Resumen ejecutivo con la aprobación de los resultados de la prueba y certificación
del sistema.
o Resultados de la prueba.
o Excepciones si no se aprueba la aplicación y medidas de acción a tomar.
59
4 CONCLUSIONES
El objetivo de la administración de cambios es garantizar el correcto y seguro funcionamiento de
los sistemas aplicativos que una Compañía desarrolle o adquiera y, que éstas a su vez provean de
las herramientas necesarias para garantizar un correcto control, auditabilidad y una eficiente
administración de la seguridad de las mismas. Esto se puede lograr aplicando distintos y variados
enfoques. Ninguno de los enfoques puede asegurar en un 100% todos estos objetivos, y tampoco
existe un único enfoque correcto aplicable a todos los casos. Cada industria y cada empresa son
distintas y deben aplicar los criterios que mejor se acomoden a su realidad y sus necesidades.
En general para lograr estos objetivos, es recomendable integrar buenas prácticas y establecer
objetivos de control que ayudan a alcanzar los objetivos propuestos por la empresa. Las buenas
prácticas se pueden desarrollar internamente de acuerdo a la experiencia alcanzada por la
empresa y sus empleados, pueden ser adoptadas de otras industrias y adaptadas a las necesidades
locales, pueden ser desarrolladas conjuntamente con otras empresas de la industria
complementando las experiencias de cada una, o bien pueden estar integradas implícita o
explícitamente en los sistemas aplicativos de la empresa. Igualmente, los objetivos de control
pueden ser desarrollados de muchas formas pero en general existen estándares internacionales
como ITIL y Cobit que definen objetivos de control para todos los procesos TI y son
ampliamente aceptados por las industrias como estándares de facto. Además estos estándares son
desarrollados y actualizados en forma continua.
En este trabajo se ha puesto en producción una herramienta que logra automatizar un gran
número de buenas prácticas, logrando los objetivos expuestos, incluyendo muchos de los
objetivos de control definidos por COBIT y para la ley Sarbanes-Oxley. Estos últimos, son
importantes para mitigar una gran cantidad de riesgos relacionados con los estados financieros de
una empresa. Además se ha desarrollado una política y normas que regulan el proceso de
administración de cambios. Todos los procesos y procedimientos que se desarrollen a futuro
deben adherirse a la política y las normas definidas. Esto permitirá la gobernabilidad del proceso
de administración de cambios y asegura un alineamiento de las personas y de todas las
actividades que participan en este proceso. En concreto, algunas de las mejoras que se han
observado son las siguientes:
60
• Segregar algunas funciones que tendían a fusionarse al definir claramente los perfiles y
las obligaciones de los participantes.
• Facilitar la auditoria interna y externa al incorporar un seguimiento automatizado de los
procesos.
• Acelerar el proceso de desarrollo y mantenimiento al automatizar muchos procesos
manuales.
• Aumentar la transparencia de los procesos al permitir un seguimiento en línea del estado
de los procesos.
• Mejorar la disponibilidad de la documentación de los procesos al almacenarlos en un
repositorio centralizado y accesible en todo momento.
Se recomienda finalmente que la embotelladora haga un mantenimiento continuo del trabajo
hecho aquí para mantener su vigencia y efectividad. Los elementos planteados en este trabajo
deben ir evolucionando en conjunto con los procesos de la empresa y de las necesidades y
requisitos de los usuarios de los sistemas aplicativos.
61
5 BIBLIOGRAFÍA Y REFERENCIAS
[Dart, 2002] Dart, R., Schneider, B. Practical Workflow for SAP. Galileo Press. Bonn, Germany,
2007.
[ITGI, 2006] IT Governance Institute. IT Control Objectives for Sarbanes-Oxley: The Role of IT
in the Design and Implementation of Internal Control Over Financial Reporting, 2nd
Edition. Printed in the United States of America.
[Juerging, 2007] Juerging, J. Engineering Change Orders influencing manufacturing start-ups in
the automobile industry. White Paper, 2007. URL:
http://www.mastercontrol.com/white_papers/engineering-change/engineering-change-
order-eco.html.
[Linkies, 2006] Linkies, M., Off, F. SAP Security and Authorizations. Galileo Press. Fort Lee
(NJ). Bonn, Germany, 2007.
[PCAOB, 2007] Public Company Accounting Oversight Board. URL: http://www.pcaobus.org/
Última visita: Octubre del 2007.
[Melich, 2007] Melich, M. SAP Solution Manager, SAP Press. 2007.
[SANS, 2007] SANS Institute. URL: http://www.sans.org. Última visita: Noviembre del 2007.
[SAP, 2007a] SAP: Business Software Solutions Applications and Services. URL:
http://www.sap.com. Última visita: Junio del 2007.
[SAP, 2007b] SAP: Service MarketPlace. URL: http://service.sap.com. Última visita: Junio del
2007.
[SAP, 2007c] SAP: Help Portal. URL: http://help.sap.com. Última visita: Junio del 2007.
[SAP, 2007d] SAP: Developers’ Network. URL: http://www.sdn.sap.com. Última visita: Julio del
2007.
[Schäfer, 2007] Schäfer, M., Melich, M. SAP Solution Manager. Galileo Press. Boston (MA),
USA. Bonn, Germany, 2007.
