desarrollo de procesos de gestión de · pdf filecontrol de las operaciones batch. este...

Universidad Politécnica de Madrid

Facultad de Informática Estudios de Doctorado

DESARROLLO DE PROCESOS DE GESTIÓN DE SERVICIOS

DE EXPLOTACIÓN SIGUIENDO EL MODELO

CMMI

Alumno: Sr. Juan Raggio Pérez [email protected]

Tutor: Sr. Tomás San Feliu Gilabert [email protected]

Gestión de Servicios de Explotación bajo CMMI

Pág. 2 de 61

INDICE

1 INTRODUCCIÓN ........................................................................................... 3

2 SERVICIOS DE EXPLOTACIÓN ...................................................................... 4 2.1 APROXIMACIÓN A LOS SERVICIOS DE EXPLOTACIÓN.........................................4

3 MODELOS PARA GESTIONAR LA EXPLOTACIÓN DE LOS SISTEMAS DE TI ..... 7 3.1 COBIT .................................................................................................................................. 7 3.2 EL MODELO ITIL (IT Infrastructure Library) ............................................................. 15 3.3 MOF (MICROSOFT OPERATIONS FRAMEWORK) ........................................................ 22

4 CMMI – MODELO DE GESTIÓN PARA LOS SERVICIOS DE EXPLOTACIÓN .... 27 4.1 ESTRUCTURA CMMI POR ETAPAS ................................................................................. 28 4.2 NIVELES DE MADUREZ CMMI ...................................................................................... 31 4.3 CMMI EN LA GESTIÓN DE SERVICIOS DE EXPLOTACIÓN ........................................ 43

5 CONCLUSIONES ......................................................................................... 49

6 ANEXO – A LEY SARBANES OXLEY........................................................... 51

7 ANEXO - B SIX SIGMA ............................................................................. 59

8 REFERENCIAS ............................................................................................ 61


Pág. 3 de 61

1 INTRODUCCIÓN La necesidad de disponer de unos servicios de explotación alineados con los requerimientos del negocio, se ha vuelto un requisito dentro de las organizaciones. Además si añadimos el hecho de una posible externalización de estos servicios, estaremos ante un conjunto de actividades que, de alguna forma, deben ser controlados bajo un modelo o esquema. Otro ejemplo de la importancia que tienen los servicios de explotación para las organizaciones y para los organismos externos, lo podemos encontrar en el modelo que ha generado ISACA para el cumplimiento de la Ley Sarbanes Oxley en el ámbito de los sistemas de información, modelo que se presenta en uno de los Anexos de este documento. La línea que sigue este documento es la exponer la complejidad y heterogeneidad de los servicios de explotación, a través de un listado de servicios tomados de una operativa real y de los modelos que existen y que implementados desde distintos ámbitos o entornos se utilizan para el control y gestión de los mismos. Posteriormente se presenta el modelo CMMI como paradigma de la gestión de los servicios de explotación para el “que hacer” a través de su transición desde una orientación software a una hardware y para el “como hacerlo” mediante su conjunción con otros esquemas o modelos.


Pág. 4 de 61

2 SERVICIOS DE EXPLOTACIÓN

2.1 APROXIMACIÓN A LOS SERVICIOS DE EXPLOTACIÓN La siguiente lista presenta un amplio conjunto de servicios que quedan dentro del ámbito de lo que se considera la explotación de los sistemas de TI: SERVICIOS DE HELP DESK El Servicio de Help Desk proporciona un punto único de contacto para los requerimientos de usuario de los usuarios finales receptores de servicios. Cualquier usuario final, ante cualquier tipo de incidencia o consulta informática relacionada con los servicios que le pueda surgir, se podrá poner en contacto con el help-desk, bien a través de un portal web, bien telefónicamente. En ambos casos el help-desk será el encargado de resolverla o bien de distribuirla a los grupos de solución que corresponda, gestionando el seguimiento de la incidencia hasta su solución y cierre. SERVICIO DE INFORMACIÓN AL USUARIO El objetivo de este servicio es proporcionar un medio para informar a todos los usuarios sobre las novedades, incidencias, indisponibilidades y eventos varios, relacionados con los servicios, ajustándose a los requerimientos acordados. GESTIÓN Y CONTROL DE SISTEMAS Este servicio fija la utilización de procedimientos y disciplinas para gestionar los sistemas de información. El Manual de Procedimientos contendrá, entre otros, los siguientes procedimientos para la gestión y control de los sistemas:

Gestión de la disponibilidad. Es el proceso de coordinación de la información, de las herramientas y de los procedimientos correspondientes necesarios para maximizar la disponibilidad del Servicio.

Gestión de la capacidad. Es el proceso de desarrollo y mantenimiento de los planes tácticos y estratégicos que posibilitan, mediante el seguimiento continuado de los entornos operativos, la verificación de que éstos se ajustan a las necesidades de negocio. El objetivo principal de este proceso es el uso eficiente de los recursos de TI.

Servicios de Gestión de espacio y almacenamiento. El objetivo de este proceso es el uso eficiente del espacio de los dispositivos de almacenamiento, maximizando su utilización.

Gestión de cambios. Proceso de recepción, evaluación, aprobación, planificación, prueba, coordinación, ejecución, verificación y control de los cambios que afectan a la prestación de servicios y a los entornos operativos. El objetivo principal de este proceso es asegurar que los cambios se realizan de forma correcta, en el plazo programado, con los recursos previstos y con el mínimo impacto en el servicio.

Gestión de la configuración. Es el proceso que regula tanto los cambios en la configuración de las máquinas y del software como el mantenimiento de los esquemas de configuración de los sistemas. El objetivo principal de este proceso es facilitar la integración de actividades de configuración a través de plataformas y tecnologías.

Gestión de rendimiento. Proceso de control, evaluación, análisis y elaboración de informes sobre el rendimiento de los sistemas en comparación con los Niveles de Servicio. El objetivo principal de este proceso es mantener el óptimo funcionamiento y rendimiento de los recursos de TI.

Gestión de incidencias. El objetivo de este proceso es la identificación, registro, seguimiento, coordinación entre los grupos de resolución y corrección de los elementos que afectan a la prestación de los distintos servicios.

Gestión de problemas. El objetivo de este proceso es la identificación, registro, seguimiento, resolución y corrección de las causas-origen del problema que afectan a la prestación de los servicios.

Gestión de copia y recuperación. Este proceso cubre la planificación, prueba e implementación de estándares y procedimientos de copia y restauración, así como de recuperación, requeridos para prestar de la manera acordada un servicio de IT en caso de fallo. El objetivo de este proceso es garantizar la recuperación consistente de los sistemas, subsistemas y aplicaciones.


Pág. 5 de 61

SOPORTE Y MANTENIMIENTO DE SISTEMAS

Soporte de Bases de Datos. Diseño físico, instalación, mantenimiento y administración de las bases de datos.

Soporte de Hardware. Estandarizar las tareas de instalación, mantenimiento y desinstalación del hardware objeto del servicio.

Soporte de Software. Soporte asociado a los sistemas y subsistemas operativos, compiladores, bases de datos, lenguajes de programación, productos y herramientas operativas necesarias para la prestación del servicio. Adicionalmente, el proceso de Soporte de Software gestiona las peticiones de distribución de Software y mantiene los repositorios correspondientes. Asegura también el correcto control de las diferentes versiones del Software.

OPERACIÓN Y MONITORIZACIÓN DE LOS SISTEMAS.

Control de las Operaciones Batch. Este proceso tiene por objetivo gestionar las operaciones de los trabajos por lotes, incluyendo la planificación y preparación de los recursos, jobs y ficheros involucrados. Incluye también los controles para monitorizar los trabajos y la obtención de copias de seguridad en los puntos oportunos. Control de Entorno de Impresión. Tiene por objetivo la gestión de las colas y subsistemas de impresión para la ejecución de las tareas de impresión. Esto implica asegurarse de que las impresoras están operativas. Control de Operaciones con Cintas. El proceso de Control de Operaciones con Cintas tiene por objetivo controlar los recursos de cintas magnéticas y los inventarios de medios magnéticos. Monitorización de Operaciones. Su objetivo es mantener la vigilancia continua sobre la disponibilidad y estado de los recursos (infraestructura TI, Infraestructura de Red, Sistemas, Sub-sistemas y aplicaciones que permitan la monitorización automática), con el fin de informar, registrar y actuar de forma proactiva y reactiva ante eventos que puedan afectar al Servicio. Mejora de operaciones. Su objetivo es el soporte efectivo y eficiente de los procesos operacionales proporcionando información para la mejora continua de los mismos.

SOPORTE A ACTIVIDADES DE PREPRODUCCIÓN, DESARROLLO Y PRUEBAS Gestión de los entornos de Pre-producción, Desarrollo y Pruebas de todos los sistema, y soporte técnico a los equipos de desarrollo y mantenimiento de las aplicaciones. SERVICIO DE ELABORACIÓN DE INFORMES El objetivo de este proceso es proporcionar los informes necesarios para: realizar el seguimiento de los servicios contratados y cumplimiento de los ANS acordados, obtener información sobre los servicios estructurada de tal manera que pueda ser valiosa para el seguimiento del negocio y el funcionamiento de las distintas unidades. SERVICIO DE CONSOLIDACIÓN Y REUBICACIÓN Instalar, readaptar y reubicar las máquinas según se estime necesario para realizar las actividades de acuerdo con los Niveles de Servicio, y sin que se cause perjuicios en las operaciones de negocio.


Pág. 6 de 61

SERVICIO DE SEGURIDAD Desarrollo de un documento detallado que definirá los controles de seguridad acordados y que recogerá, entre otra información, la relación de responsabilidades y las medidas de seguridad a fijar.

Gestión de la Seguridad. Revisión de las políticas y procedimientos de seguridad para comprobar su efectividad y recomendar mejoras. Seguridad Física. Asegurar los controles de seguridad física. Control de acceso lógico. Gestión de controles de seguridad lógica Seguridad en la Red de Área Local y WAN. Gestión de la seguridad en los elementos de electrónica de red (switches, routers, hubs) y cableado de la red de área local y red WAN.

OTROS SERVICIOS.

Tecnología. Su objetivo es revisar las propuestas de proveedores que afecten a la prestación de los servicios para facilitar la compatibilidad de los sistemas existentes y futuros con los estándares cambiantes de la industria. Relación con el Proveedor y Valoración de Productos. Su objetivo es disponer de información actualizada de los últimos desarrollos tecnológicos de los productos, de mano de los proveedores de telecomunicaciones y de servicios o productos. Reuniones de Revisión de los Servicios. Mantener reuniones de revisión con los proveedores de los servicios.

SERVICIOS DE MICROINFORMÁTICA.

Gestión de inventario de equipos. Su objetivo es el registro, mantenimiento y disponibilidad de la información correcta acerca del hardware y del software instalado en los equipos. Gestión de incidencias (soporta a usuarios). Se identificará la fuente de las incidencias, y se aportará una solución. Servicio de Mantenimiento del Hardware. Instalación, configuración, cambio, actualización y desinstalación de componentes hardware. Gestión de Backup y Recuperación de Servidores. backup de los Servidores del Entorno Microinformático con herramientas, de forma remota y centralizada en la medida de lo posible. Gestión LAN/WAN WAN. Instalación, soporte, configuración, cambio o desinstalación de todos los elementos que conforman la red LAN/WAN. Homologación de hardware y software. Se homologará el nuevo software y hardware sobre la plataforma vigente en cada momento.

Esta lista solo pretende dar una visión aproximada del amplio conjunto de actividades que pueden quedar recogidas dentro de lo que se conocen como servicios de explotación. Hablar de servicios de explotación resulta complejo dado que es un actividad que en su mas amplia expresión presenta múltiples interacciones con otras actividades de TI, como el desarrollo de software entendido como la construcción de herramientas ad-hoc para la gestión de nuestros sistemas. Es por esto que se observa la necesidad de modelar de alguna forma estos servicios, con el objetivo de permitir su control y mejora continua. Aquí es donde entran esquemas como los proporcionados por COBIT, ITIL, MOF y CMMI.


Pág. 7 de 61

3 MODELOS PARA GESTIONAR LA EXPLOTACIÓN DE LOS SISTEMAS DE TI

3.1 COBIT El modelo COBIT (Objetivos de Control para la Información y las Tecnologías) promovido desde la Governance, Control and Audit for Information and Related Technology y esponsorizado por la Information Systems Audit and Control Foundation (ISACF), proporciona “prácticas sanas” a través de un Marco Referencial de dominios y procesos y presenta actividades en una estructura manejable y lógica, para ayudar a salvar las brechas existentes entre riesgos de negocio, necesidades de control y aspectos técnicos. COBIT se estructura sobre la base de los siguientes elementos:

Resumen Ejecutivo. Es una síntesis ejecutiva que proporciona a la alta gerencia entendimiento y conciencia sobre los conceptos clave y principios de COBIT. Marco Referencial. Describe en detalle los 34 objetivos de control de alto nivel e identifica los requerimientos de negocio para la información y los recursos de TI que son impactados de forma directa por cada objetivo de control. Objetivos de Control Detallado. Contienen declaraciones de los resultados deseados o propósitos a ser alcanzados mediante la implementación de los 302 objetivos de control detallados y específicos a través de los 34 procesos de TI. Guías de Auditoria. Herramienta para la aplicación del Marco Referencial y los Objetivos de Control. Proporcionan una estructura sencilla para auditar y evaluar controles, con base en prácticas de auditoria generalmente aceptadas y compatibles con el sistema COBIT. Guías Gerenciales. Conformada por Modelos de Madurez, Factores Críticos de Éxito, Indicadores Clave de objetivos e Indicadores Claves de Rendimiento. Proporciona un marco para dar respuesta a la gerencia en aspectos referentes al control y medida de la actividad de IT referente a los 34 procesos de IT.

MARCO REFERENCIAL

Marco referencial sobre la base de tres puntos estratégicos:

(1) recursos de TI

(2) requerimientos de negocio para la información

(3) procesos de TI


Pág. 8 de 61

RECURSOS DE TI - Datos. Con el fin de asegurar que los requerimientos de negocio para la información

son satisfechos, deben definirse Los elementos de datos en su más amplio sentido, (por ejemplo, externos e internos), estructurados y no estructurados, gráficos, sonido, etc.

- Aplicaciones. Se entiende como sistemas de aplicación la suma de procedimientos

manuales y programados. - Tecnología. La tecnología cubre hardware, software, sistemas operativos, sistemas

de administración de bases de datos, redes, multimedia, etc. - Instalaciones. Recursos para alojar y dar soporte a los sistemas de información. - Personal. Habilidades del personal, conocimiento, conciencia y productividad para

planear, organizar, adquirir, entregar, soportar y monitorear servicios y sistemas de información.

REQUERIMIENTOS DE NEGOCIO

- Requerimientos de Calidad Calidad Costo Entrega (de servicio)

- Requerimientos Fiduciarios (COSO)

Efectividad & Eficiencia de operaciones Confiabilidad de la información Cumplimiento de la las leyes y regulaciones

- Requerimientos de Seguridad

Confidencialidad Integridad Disponibilidad A partir de estos requerimientos se extraen siete categorías distintas: Efectividad. Se refiere a que la información relevante sea pertinente para el proceso del negocio, así como a que su entrega sea oportuna, correcta, consistente y de manera utilizable. Eficiencia. Se refiere a la provisión de información a través de la utilización óptima (más productiva y económica) de recursos. Confidencialidad. Se refiere a la protección de información sensible contra divulgación no autorizada. Integridad. Se refiere a la precisión y suficiencia de la información, así como a su validez de acuerdo con los valores y expectativas del negocio. Disponibilidad. Se refiere a la disponibilidad de la información cuando ésta es requerida por el proceso de negocio ahora y en el futuro. También se refiere a la salvaguarda de los recursos necesarios y capacidades asociadas.

Cumplimiento. Se refiere al cumplimiento de aquellas leyes, regulaciones y acuerdos contractuales a los que el proceso de negocios está sujeto, por ejemplo, criterios de negocio impuestos externamente.

Confiabilidad de la información. Se refiere a la provisión de información apropiada para la administración con el fin de operar la entidad y para ejercer sus responsabilidades de reportes financieros y de cumplimiento.


Pág. 9 de 61

DOMINIOS

Planificación y organización Cubre la estrategia y las tácticas y se refiere a la identificación de la forma en que la tecnología de información puede contribuir de la mejor manera al logro de los objetivos del negocio. Además, la consecución de la visión estratégica necesita ser planeada, comunicada y administrada desde diferentes perspectivas. Finalmente, deberán establecerse una organización y una infraestructura tecnológica apropiadas. Adquisición e implementación Para llevar a cabo la estrategia de TI, las soluciones de TI deben ser identificadas, desarrolladas o adquiridas, así como implementadas e integradas dentro del proceso del negocio. Además, este dominio cubre los cambios y el mantenimiento realizados a sistemas existentes. Entrega y Soporte En este dominio se hace referencia a la entrega de los servicios requeridos, que abarca desde las operaciones tradicionales hasta el entrenamiento, pasando por seguridad y aspectos de continuidad. Con el fin de proveer servicios, deberán establecerse los procesos de soporte necesarios. Este dominio incluye el procesamiento de los datos por sistemas de aplicación, frecuentemente clasificados como controles de aplicación. Monitoreo Todos los procesos necesitan ser evaluados regularmente a través del tiempo para verificar su calidad y suficiencia en cuanto a los requerimientos de control.


Pág. 10 de 61

La siguiente tabla proporciona una indicación por proceso y dominio de TI de los criterios de información que se ven afectados por los objetivos de alto nivel, así como una indicación de los recursos de TI que son aplicables.


Pág. 11 de 61

Sobre la base del esquema presentado, intentemos identificar los objetivos de control y objetivos de control detallado para la gestión de los servicios de explotación de TI: AI - Adquisición e Implementación AI-1 Identificar soluciones AI-1.1 Definición de requerimientos de información AI-1.2 Formulación de acciones alternativas AI-1.4 Requerimientos de servicios de terceros AI-1.5 Estudios de factibilidad tecnológica AI-1.7 Arquitectura tecnológica AI-1.10 Diseño de pistas de auditoria AI-1.12 Selección de software del sistema AI-3 Adquirir y mantener la arquitectura tecnológica AI-3.1 Evaluación de nuevo hardware y software AI-3.2 Mantenimiento preventivo para hardware AI-3.3 Seguridad del software del sistema AI-3.4 Instalación del software del sistema AI-3.5 Mantenimiento del software del sistema AI-3.6 Controles para cambios del software del sistema AI-3.7 Uso y monitoreo de utilidades del sistema AI-4 Procedimientos de desarrollo y mantenimiento de sistemas AI-4.1 Requerimientos Operacionales y Niveles de Servicio AI-4.2 Manual de Procedimientos para Usuario AI-4.3 Manual de Operación AI-3.5 Material de Entrenamiento AI-5 Instalar y acreditar sistemas AI-5.1 Entrenamiento AI-5.3 Plan de Implementación AI-5.12 Promoción a Producción AI-6 Administrar cambios AI-6.1 Inicio y Control de Solicitudes de Cambio AI-6.2 Análisis de Impacto AI-6.3 Control de Cambios AI-6.4 Cambios de Emergencia AI-6.5 Documentación y Procedimientos AI-6.6 Mantenimiento Autorizado AI-6.7 Política de Liberación de Software AI-6.8 Distribución de Software

DS - Entrega y Soporte DS-1 Definir Niveles de Servicio DS-1.1 Marco de Referencia para acuerdos de Nivel de Servicio DS-1.2 Aspectos sobre los Acuerdos de Nivel de Servicio DS-1.3 Procedimientos de Desempeño DS-1.4 Monitoreo y Reporte DS-1.5 Revisión de Contratos y Acuerdos de Nivel de Servicio DS-1.7 Programa de Mejoramiento del Servicio DS-2 Administrar servicios prestados por terceros DS-2.3 Contratos con Terceros DS-2.5 Contratos con Outsourcing DS-2.6 Continuidad del Servicios DS-2.7 Relaciones de Seguridad DS-2.8 Monitoreo DS-3 Administrar desempeño y capacidad DS-3.5 Administración de Desempeño Proactivo DS-3.6 Pronóstico de Carga de Trabajo DS-3.7 Administración de Capacidad de Recursos DS-3.8 Disponibilidad de Recursos DS-3.9 Calendario / Programación de recursos


Pág. 12 de 61

DS-5 Garantizar la Seguridad de Sistemas DS-5.3 Seguridad de Acceso a Datos en Línea DS-5.9 Administración Centralizada de Identificación y Derechos de Acceso DS-5.17 Protección de las funciones de seguridad DS-5.19 Prevención, Detección y Corrección de Software“Malicioso” DS-5.20 Arquitecturas de Firewall y conexión a redes públicas DS-8 Apoyar y asistir a los clientes de TI DS-8.1 Help Desk DS-8.2 Registro de consultas del Cliente DS-8.3 Escalado de consultas del Cliente DS-8.4 Monitoreo de Atención a Clientes DS-8.5 Análisis y Reporte de Tendencia DS-9 Administrar la configuración DS-9.1 Registro de la Configuración DS-9.2 Base de la Configuración DS-9.4 Control de la Configuración DS-9.5 Software no Autorizado DS-9.6 Almacenamiento de Software DS-9.7 Procedimientos para la Administración dela Configuración DS-9.8 Contabilidad y registro del Software DS-10 Administrar problemas e incidentes DS-10.1 Sistema de Administración de Problemas DS-10.2 Escalamiento de Problemas DS-10.3 Seguimiento de Problemas y Pistas de Auditoría DS-10.4 Autorizaciones para acceso temporal y de emergencia. DS-10.5 Prioridades en Procesos de Emergencia DS-11 Administrar datos DS-11.17 Protección de Información Sensitiva durante transmisión y transporte DS-11.18 Protección de Información Sensitiva a ser Desechada DS-11.19 Administración de Almacenamiento DS-11.20 Períodos de Retención y Términos de Almacenamiento DS-11.21 Sistema de Administración de la Librería de Medios DS-11.22 Responsabilidades de la Administración de la Librería de Medios DS-11.23 Respaldo y Restauración DS-11.24 Funciones de Respaldo DS-11.25 Almacenamiento de Respaldo DS-13 Administrar operaciones DS-13.1 Manual de Instrucciones y procedimientos de Operaciones de procesamiento DS-13.2 Documentación del Proceso de Inicio y de otras operaciones DS-13.3 Calendario / programación de Trabajos DS-13.4 Ejecución de los Trabajos estándar programados DS-13.5 Continuidad de Procesamiento DS-13.6 Bitácoras de Operación DS-13.8 Operaciones Remotas

Como vemos COBIT proporciona un esquema de referencia para abordar esta gestión, pero puede resultar un poco difícil llegar a delimitar las acciones concretas que se deben ejecutar para poner en practica estos objetivos de control. Podemos acudir a las Guías de Auditoria las cuales dan puntos de referencia sobre los aspectos perseguidos con el control pero como su propio nombre indica están plenamente orientadas hacia la actividad de auditoria. También podemos hacer uso de la Guías o Directrices Gerenciales de COBIT, las cuales ayudan a la Gerencia a cumplir de una forma mas efectiva con las necesidades y requerimientos del Gobierno de TI. Las Directrices son acciones genéricas orientadas a proveer a la Administración la dirección para mantener bajo control la información de la empresa y sus procesos relacionados, para monitorear el logro de las metas


Pág. 13 de 61

organizacionales, para monitorear el desempeño de cada proceso de TI y para llevar a cabo un benchmarking de los logros que se producen en la organización.[1] Las Directrices Gerenciales de COBIT son genéricas y son acciones orientadas al propósito de responder los siguientes tipos de preguntas gerenciales:

¿Qué tan lejos debemos ir y es el costo justificado para el beneficio obtenido? ¿Cuáles son los indicadores de buen desempeño? ¿Cuáles son los factores críticos de éxito? ¿Cuáles son los riesgos de no lograr nuestros objetivos? ¿Qué hacen otros? ¿Cómo nos podemos medir y comparar?

Las Guías Gerenciales de COBIT se construyen sobre:

- Factores Críticos de Éxito(Critical Success Factors), que definen o determina cuales son las mas importantes directrices que deben ser consideradas por la Administración para lograr control sobre y dentro de los procesos de TI.

- Indicadores Claves del logro de Objetivos o de Resultados (Key Goal Indicators),

los cuales definen los mecanismos de medición que indicarán a la Gerencia—después del hecho– si un proceso de TI ha satisfecho los requerimientos del negocio.

- Modelos de Madurez, para el control sobre los procesos de TI de tal forma que la

Administración puede ubicarse en el punto donde la organización está hoy, donde está en relación con los “mejores de su clase” en su industria y con los estándares internacionales y así mismo determinar a donde quiere llegar. Los modelos de madurez establecidos por COBIT para cada uno de los 34 Objetivos de Control son:

No existe (0). Ausencia total de procesos reconocidos como tal. La organización no ha reconocido la necesidad de su existencia. Inicial /Ad Hoc (1). Existen evidencias de que la organización ha reconocido de que existe la necesidad y que se debe trabajar en paliarla. Sin embrago los procesos no están estandarizados y cada persona realiza y desarrolla su procesos en base a su buen criterio. No existe una visión global de gestión, por lo que la gestión no es organizada. Repetible pero intuitivo (2). Se han desarrollado procesos, a tal nivel que llegan a ser usados por diferentes personas para realizar la misma tarea. La formación no esta normalizada y por tanto los procedimientos no se comunican de manera formal, por lo que su difusión queda en manos del individuo. Hay un alto grado de dependencia del conocimiento del individuo y por tanto los errores suelen ser comunes. Proceso definido (3). Los procesos están estandarizados y documentados, y son comunicados a través de la formación. Sin embrago son los individuos los que trabajan con estos procedimientos y los que pueden detectar desviaciones en los mismos. Los procedimientos en si no son sofisticados pero son la formalización de practicas existentes. Gestionado y medido (4). .ES posible monitorizar y medir el cumplimento de los procedimientos y tomar acciones cuando se observe que los procedimientos no funcionan eficazmente. Los procesos están bajo constante mejora y proporcionan buenas practicas. La automatización y las herramientas son usadas de forma fragmentada y limitada.


Pág. 14 de 61

Optimizado (5). Los procesos han sido refinados hasta el nivel de buenas practicas, basados en los resultados de la mejora continua y modelos de madurez de otras organiaciones. Los sistemas de TI son usados de una forma integra para automatizar el workflow, además de proporcionar herramientas para mejora las calidad y la eficacia, lo que hace que la empresa se adapte de forma rápida al cambio.

- Indicadores Clave de desempeño(Key Performance Indicators), los cuales son

indicadores primarios que definen la medida para conocer qué tan bien se está ejecutando el proceso de TI frente o comparado contra el objetivo que se busca.

Todo esto pone de manifiesto que si bien el modelo COBIT a través de sus objetivos de control nos informa de lo que debemos hacer para gestionar los servicios de explotación aún necesitamos de algún otro modelo, como ITIL, que nos indique el como.[2]


Pág. 15 de 61

3.2 EL MODELO ITIL (IT Infrastructure Library) Information Technology Infraestructure Library, en adelante ITIL, surge como modelo desde la CCTA (UK) orientado hacia la gestión de las operaciones y servicios de los sistemas y tecnologías de la información y comunicación (Information and Communications technology Systems - ICT). Este modelo está solidamente establecido en Europa, Australia y USA. ITIL es un marco de buenas practicas documentadas de forma abstracta, con el objetivo de poder ser aplicadas en cualquier organización de TI. Está específicamente desarrollado para los servicios de mantenimiento y operación de TI, y proporciona objetivos de servicio además de actividades e indicadores clave de servicio. El marco de actuación de ITIL queda representado en le siguiente grafico.

SOCIOS(partners)

TECNOLOGÍA

EL NEGOCIO

GESTIONDE LA

APLICACIÓN

USUARIOS

SERVICIOS

CLIENTES

GESTIÓN DEL NIVEL DE SERVICIO

GESTIÓN DE LA CAPACIDAD

GESTIÓN FINANCIERA

GESTIÓN DE LA DISPONIBILIDAD

CONTINUIDAD DEL SERVICIO

SERVÏCIO DE ESCRITORIO

GESTIÓN DE INCIDENTES

GESTIÓN DE PROBLEMAS

GESTIÓN DE LA CONFIGURACIÓN

GESTIÓN DEL CAMBIO

GESTIÓN DE VERSIONES

SERVICIO ENTREGADO SERVICIO SOPORTADO

GESTIÓN DEL SERVICIO

DESARROLLODISEÑO Y PLANIFICACIÓN OPERACIONES

SOPORTE TÉCNICO

GESTIÓN DE LA INFRAESTRUCTURA DE ICT

SOCIOS(partners)

TECNOLOGÍA

EL NEGOCIO

GESTIONDE LA

APLICACIÓN

USUARIOS

SERVICIOSSERVICIOS

CLIENTES

GESTIÓN DEL NIVEL DE SERVICIO

GESTIÓN DE LA CAPACIDAD

GESTIÓN FINANCIERA

GESTIÓN DE LA DISPONIBILIDAD

CONTINUIDAD DEL SERVICIO





GESTIÓN DEL CAMBIO






GESTIÓN DEL CAMBIO


SERVICIO ENTREGADO SERVICIO SOPORTADO

GESTIÓN DEL SERVICIO

DESARROLLODISEÑO Y PLANIFICACIÓN OPERACIONES

SOPORTE TÉCNICO

GESTIÓN DE LA INFRAESTRUCTURA DE ICT


Pág. 16 de 61

Si vemos los servicios de explotación como el conjunto de actividades y el mantenimiento diario de los de los sistemas y tecnologías de la información, entonces asimilamos estas actividades al proceso de Operaciones del ICT Infrastructure Management (ICTIM) recogido en ITIL. Dentro de ICTIM, el proceso de Operaciones asegura la efectividad en la gestión operacional de las tecnologías e infraestructuras, al recoger todas las actividades y medidas que permiten y mantiene el uso de los sistemas de información y telecomunicaciones. ITIL define el proceso de Operaciones como:

Todas las actividades y medidas necesarias para habilitar y/ mantener el optimo uso de los sistemas y tecnologías de la información y comunicación con el propósito de alcanzar los Acuerdos de Nivel de Servicio y objetivos de negocio fijados.

ITIL ve a todos los procesos como un conjunto de entradas que bajo la aplicación de un determinado conjunto de funciones provocan unas salidas,. Además considera estas funcionas sujetas a un ciclo de mejora continuo con el objeto de mantenerlas alineadas a las necesidades cambiantes del negocio:

CONTROLCOMPARAR

NORMALIZAR

MONITORIZAR

FUNCIONInput Output

CONTROLCOMPARAR

NORMALIZAR

MONITORIZAR

FUNCIONInput Output


Pág. 17 de 61

CONCEPTOS BÁSICOS EN ITIL PARA EL PROCESO DE OPERACIONES Objeto Gestionado (Managed Object) Un Objeto Gestionado (MO) es para el modelo de gestión del Open Systems Interconneection (OSI) un recurso que esta sujeto a gestión. Un MO es la representación de un recurso de infraestructura técnica a ser gestionado.. Un MO se define en base a los atributos que posee, las operaciones que puede realizar, las notificaciones que puede dar y las relaciones que puede establecer con otro MO. Dominio de Gestión (Management Domain) Un dominio de gestión es un conjunto de MO, al los que se les puede aplicar un conjunto común de Políticas de Sistemas de Gestión. Un dominio de gestión posee al menos dos de las siguientes propiedades:

- Un nombre único. - Identificación de una colección de MO, los cuales son miembros del dominio. - Identificación de relaciones inter-dominios aplicables a las relaciones de un

dominio con otro (reglas, practicas, procedimientos). OBJETIVOS PRINCIPALES DE ITIL PARA EL PROCESO DE OPERACIONES - Operar, gestionar y mantener un esquema de infraestructura tecnológica de sistemas

de información y comunicaciones de principio a fin que facilite la entrega de los servicios de ICT al negocio, y que suponga la comunión entre los requerimientos y objetivos acordados.

- Asegurar que la infraestructura de ICT es fiable, robusta, segura, consistente y posibilita la eficiencia y efectividad de los procesos de negocio de la organización.

- Asegurar que todas los requerimientos operacionales de los proceso de ICT están cubiertos y proporcionan un nivel de servicio operacional en línea con los Acuerdos de Nivel de Servicio fijados.

ALCANCE DE ITIL PARA EL PROCESO DE OPERACIONES: Entrada • La infraestructura de ICT. • Acuerdos de Nivel de Operación (OLA1), los cuales fijan y documentan los objetivos y

requerimientos para la infraestructura de ICT. Es crucial que estos acuerdos estén soportados por Acuerdos de Nivel de Servicio (SLA2).

• Contratos consistentes y que incluyan Acuerdos de Nivel de Servicios.

1 OLA (Operational Level Agreement - Acuerdo de Nivel de Operaciones); es un acuerdo interno que contempla los servicios que dan soporte a la organización de TI para que ésta a su vez proporcionen servicios a terceros. 2 SLA (Service Level Agreement - Acuerdo de Nivel de Servicio); acuerdo establecido entre TI y los clientes a los que presta el servicio.


Pág. 18 de 61

• Procesos y procedimientos operacionales. • Estrategias, planes, políticas, estándares y arquitecturas. Procesos • Eventos, avisos, alertas y alarmas a ser procesadas y gestionadas:

- Progreso y resolución de todos los mensajes de eventos, avisos, alertas y alarmas.

- Relación con la gestión de incidentes y problemas. - Relación con la disponibilidad, seguridad y gestión de la capacidad.

• Gestión total de la infraestructura operacional de ICT:

- Rendimiento y configuración adaptada a la infraestructura operacional en conjunción con la Gestión de la Capacidad y la Gestión del Cambio.

- Configuración y reconfiguración de los Objetivos de Gestión (MO). - Adaptación del Sistemas y rendimiento.

• Planificación de la Carga De Trabajo:

- Planificación de la gestión y mantenimiento de los Procesos Batch. - Gestión de la impresión y de los datos de salida.

• Revisión y Mantenimiento:

- Backups y restauración. - Mantenimiento de la infraestructura de ICT. - Administración de las bases de datos. - Mantenimiento de la documentación. - Disponibilidad, y test de esfuerzo y recuperación. - Chequeo de la salud de la infraestructura. - Revisión de logs.

• Gestión del Almacenamiento:

- Mantenimiento de los datos y de los ficheros del sistema. - Gestión y Administración de las bases de datos. - Gestión de medios. - Revisión de logs. - Gestión y planificación de Backups. - Reportes de uso.

• Relación con las otras áreas de ICT, especialmente con la Soporte Técnico, el soporte

externalizado, y los ingenieros y técnicos de mantenimiento. • Proactividad para la mejora de los procesos de operaciones bajo la Gestión de Control

de Cambios. Entregables • Una estable y segura infraestructura de ICT.


Pág. 19 de 61

• Una Librería de Documentos segura que contenga el detalle de todas los procesos operacionales.

• Un log o base de datos de todas los eventos, alertas y alarmas operacionales. La

mayoría de estos debería alimentar al proceso de Gestión de Incidencias y ser recogidos como incidentes.

• Un conjunto de scripts operacionales. • Un conjunto de trabajos operacionales para todos los trabajo batch, gestión de la

impresión y calendario de backups de datos y ficheros del sistema. • Gestión de reportes y de la información. • Reporte de las revisiones por excepción. • Reporte de auditoria para la eficiencia, efectividad y cumplimiento. IMPLICACIONES DE LA GESTIÓN DE PROCESOS DE OPERACIONES EN ITIL • Control y gestión operacional de los servicios, componentes y sus configuraciones:

- Instalación. - Desinstalación. - Distribución. - Control de la Operación. - Desarrollo y mantenimiento de un conjunto de herramientas para la gestión

operacional. - Configuración y reconfiguración. - Procesos de mantenimiento preventivo. - Inventario y Mantenimiento.

• Gestión de todas los eventos de la infraestructura de ICT:

- Monitorizar eventos. - Detección de eventos. - Registro (log) de eventos. - Examen y filtrado de eventos. - Procesado, correlación y escalado de eventos. - Resolución de eventos. - Cierre de eventos. - Gestión del ciclo de vida de los eventos. - Agrupado de eventos. - Reporte de eventos.

• Gestión y planificación de las cargas de trabajo y de las salidas:

- Planificar las cargas de trabajo y su gestión. - Planificación y gestión de las salidas de datos y de impresión. - Control y Distribución segura de los datos de salida. - Planificación de las pruebas de carga y de los test de fallo.

• Gestión del almacenamiento, de backups y de los procesos de restauración:


Pág. 20 de 61

- Gestión del almacenamiento y su ubicación. - Sistemas de backup y restauración. - Gestión de la información. - Gestión y Administración de las bases de datos.

• Gestión y control de todos los aspectos de la seguridad operacional de ICT:

- Monitoreo de la seguridad. - Control de la seguridad tanto física como lógica.

• Gestión de los procesos de soporte operacional:

- Mantenimiento de la documentación operacional - Recogida de todo tipo de información y logs relacionados con la operación de ICT. - Análisis de la información. - Scripting.

• Proactividad en la gestión operacional de los procesos:

- Revisión de los procesos relacionados con la operación en la búsqueda de la eficiencia, la eficacia y el cumplimiento.

- Auditoria interna o externa de todos los procesos operacionales. - Instigar la acción para buscar remedios y mejoras en la infraestructura

operacional. - Instigar la acción para buscar remedios y mejoras en los procesos operacionales. - Adaptación operacional.

TÉCNICAS, HERRAMIENTAS Y TECNOLOGÍAS Técnicas • Centro de Operaciones, en el que se integren procesos, personas y productos del área

de operaciones y del área de gestión de incidentes. • Análisis de eventos y tendencias. • Revisiones y valoraciones internas. • Benchmarking Externo. • Proceso de mejora continua. Herramientas • Herramientas para la gestión de sistemas y redes. • Herramientas para la gestión del entorno. • Herramientas para la gestión del servicio, de aplicaciones y de bases de datos. • Herramientas de diagnostico.


Pág. 21 de 61

• Herramientas de planificación. • Herramientas par al agestión del almacenamiento. • Herramientas para la mejora del rendimiento. • Herramientas para la gestión del servicio. Las Tecnologías Cada vez que se incorpore una nueva tecnología, Operaciones debe trabajar con otras áreas de proceso durante el testeo de la misma, con el objetivo de:

- Asegurar que cualquier sistema nuevo pasa los criterios operacionales de aceptación, con el objetivo de alcanzar de manera holgada sus requerimientos operativos.

- Se deben desarrollar nuevos soportes o material de gestión, procesos y

procedimientos, antes y durante el despliegue de la nueva tecnología.

- Se deben desarrollar características y conocimientos nuevos, para soportar las nuevas tecnologías. Esto se puede conseguir de manera formal a través de la formación o del propio entrenamiento que proporciona el trabajo.

ROLES OPERACIONALES • Gestor de los Servicios en Producción / Gestor de Operaciones / Jefe de Turno. • Analista de Operaciones. • Gestor de Almacenamiento y Backups. • Analista de Planificación. • Administrador de Bases de Datos. Como se constata ITIL presenta un modelo muy completo, en que detalla no solo las actividades a desarrollar sino que las enlaza con las posible entradas o elementos de partida y con los objetivos que se pueden alcanzar (entregables). ITIL también documenta las técnicas , herramientas y considera el factor tecnología como algo a valorar dentro de sus esquema, además de detallar el conjunto mínimo de roles necesarios para el desarrollo con garantías de los procesos.[3]


Pág. 22 de 61

3.3 MOF (MICROSOFT OPERATIONS FRAMEWORK) MOF es un marco de referencia que adopta y se adapta al modelo ITIL, modelo éste generalmente aceptado como el que aglutina las mejores prácticas de operaciones dentro de IT. Las visión de MOF es crear una probada y completa guía de operaciones para alcanzar fiabilidad, disponibilidad, soportabilidad y operatividad en sistemas de misión crítica en producción sobre la plataforma de productos Microsoft. MOF también presenta un Modelo de Madurez el cual fija la situación actual de los procesos y sirve de referencia en la actividad de mejora. El Modelo de Madurez MOF se base en los siguientes niveles:

Madurez 0 - Incompleto (no existe). La función no se realiza o se encuentran problemas para realizar las practicas básicas y no es posible identificar los entregables del proceso. En resumen:

- No se realiza. - No hay evidencia de resultados.

Madurez 1 - Realizado (informal). Las practicas básicas se realizan pero sin documentarse y seguirse formalmente. El rendimiento depende del conocimiento y esfuerzo individual. Existen entregables identificados. En resumen:

- Acuerdo general (implícito/explicito) de que se realiza. - De algún modo se identifica la practica y los resultados, aunque no se haga

seguimiento de los mismos. Madurez 2 – Gestionado (documentado). Se llevan a cabo las practicas básicas de cada proceso de forma planificada, documentada y controlada. Se verifica que se trabaja de acuerdo a los procedimientos. Los entregables se adaptan a estándares y requerimientos. En resumen:

- Roles y responsabilidades identificados. - Parámetros de tiempo de respuesta y calidad definidos. - Proceso planificado y registrado. - Entregables del proceso identificados y documentados (resultados estandarizados).

Madurez 3 - Establecido (procedimentado). Las practicas básicas se realizan de acuerdo a procesos bien definidos, documentados y aprobados. Se planifica y gestiona haciendo uso de procedimientos estándares para toda la organización. En resumen:

- Proceso definido, documentado y aprobado. Existen lista de distribución y plantillas para los informe que se generan.

- Utilizar herramientas y recursos de apoyo al proceso. Madurez 4 - Predecible (medido). Se recogen y analizan medidas detalladas del rendimiento, lo que conduce a una comprensión cualitativa de la capacidad del procedimiento y a una mejora en la capacidad de predicción del rendimiento. El rendimiento es gestionado objetivamente. En resumen:

- Ejecución consistente en todos los casos. - Resultados medidos y analizados (métricas de la función). - Métricas de la calidad. - Desempeño predecible.

Madurez 5 - Optimizado (adaptable). Se establecen objetivos cuantitativos de efectividad y eficacia del rendimiento basados en los objetivos del negocio. La mejora continua del proceso es posible gracias a la realimentación cuantitativa obtenida del rendimiento de los procesos definidos. En resumen:

- Objetivos de desempeño definidos para el proceso. - Efectividad del proceso medida según los objetivos del negocio.


Pág. 23 de 61

- Se aplican mejoras en los procesos no eficaces. - Desempeño optimizado en línea con los objetivos del negocio.

Para el control de la actividad de mejora MOF usa lo que se conocen como Matrices de Madurez, y en las que para cada función MOF se informa de su estado.

Proceso Matriz de Madurez

Nivel de Madurezdel ProcesoProceso Matriz de

MadurezNivel de Madurez

del Proceso

A partir del estado actual y como herramienta de ayuda para alcanzar el nivel objetivo deseado se dispone de Guías, que recogen lo conocido como Actividades Básicas, las cuales presentan las siguientes características:

- Son actividades que tiene que ser realizadas para llevar a cabo la función. - Forman un subconjunto de las mejores practicas. - Están compuestas por tareas. - Están en el nivel de Madurez 1.

El modelo de proceso MOF para los servicios de explotación es el siguiente:

Operación

Optimización

Soporte

Cambio

Revisión de preparación

Revisión de Acuerdo de Servicio

Revisión de Operaciones

Revisión de Post-Implementación

• Adm. de sistemas• Monitorización y control• Adm. Servicios Directorio• Adm. Seguridad• Adm. de Redes• Adm. de Almacenamiento• Supervisión de trabajos automatizados

• Gestión de la Configuración• Gestión de la puesta en producción• Gestión del cambio

• Help Desk• Gestión de Problemas• Fallover & Recovery

• Gestión e la capacidad• Gestión de la Disponibilidad• Gestión de costes• Gestión fuerza de trabajo• Planificar Contingencia• Gestión de Niveles de Servicio

Operación

Optimización

Soporte

Cambio

Revisión de preparación

Revisión de Acuerdo de Servicio

Revisión de Operaciones

Revisión de Post-Implementación

• Adm. de sistemas• Monitorización y control• Adm. Servicios Directorio• Adm. Seguridad• Adm. de Redes• Adm. de Almacenamiento• Supervisión de trabajos automatizados

• Gestión de la Configuración• Gestión de la puesta en producción• Gestión del cambio

• Help Desk• Gestión de Problemas• Fallover & Recovery

• Gestión e la capacidad• Gestión de la Disponibilidad• Gestión de costes• Gestión fuerza de trabajo• Planificar Contingencia• Gestión de Niveles de Servicio


Pág. 24 de 61

CAMBIOS Misión Introducción efectiva de cambios aprobados en el ambiente de TI de forma

rápida y con mínima interrupción del servicio.

Objetivos Claves - Respuesta efectiva a necesidades y demandas del negocio. - Mantenimiento de entornos gestionados en un estado conocido. - Gestión del cambio como un paquete cuantificable y cualitativo. - Despliegue fluido de nuevos servicios seguros.

OPERACIONES Misión Ejecutar y monitorizar, de forma eficiente, las tareas y actividades

operativas diarias requeridas para administrar un servicio de TI.

Objetivos Claves - Alcanzar y mantener los niveles de servicio acordados en los acuerdos de servicio (SLA y OLA).

- Asegurar que los estándares, procesos y procedimientos de operaciones se aplican a las soluciones de servicio.

- Respuesta PROACTIVA a condiciones cambiantes ANTES de que ocurran incidentes de soporte.

- Automatizar, automatizar, automatizar. SOPORTE Misión Resolución a tiempo de incidentes problemas, errores y consultas dentro de

los acuerdos de servicio establecidos.

Objetivos Claves - Integrar los procesos, procedimientos y herramientas, así como el staff requerido para identificar, priorizar, asignar, diagnosticar, controlar y resolver: incidentes, problemas, errores, requerimientos y consultas.

- Proveer una comunicación clara y concisa con el cliente. - Balancear la “auto ayuda” con la asistencia in-situ. - Mecanismos de help-desk internos y externos completamente

coordinados - Procedimientos –inteligentes- de recuperación.

OPTIMIZACIÓN Misión Optimizar (reducir) costos y al mismo tiempo mantener y mejorar los niveles

de servicio.

Objetivos Claves - Examinar las estructuras de costos, evaluaciones de staff, análisis de disponibilidad y análisis de capacidad y prospección

- Planificación de contingencia - Identificar los requerimientos para csarios para dar respuesta a cambios

en las necesidades del negocio.


Pág. 25 de 61

Para este modelo de proceso la Matriz de Madurez podría ser la siguiente:

Ges

tión d

el C

ambio

Ges

tión d

e Configura

ciones

Ges

tión d

e Ver

siones

Adm

. de

Ser

vici

os

de

Direc

torio

Adm

. de

Red

Adm

. de

Seg

uri

dad

Adm

. D

e Sis

tem

as

Contr

ol y

Monitori

zaci

ón d

e Ser

vici

os

Ges

tión d

e Alm

acen

am

iento

Ges

tión d

e ce

ntr

o d

e Ser

vici

os

Ges

tión d

e In

ciden

cias

Ges

tión d

e Pr

oble

mas

Ges

tión d

e N

ivel

de

Ser

vici

o

Ges

tión d

e Cap

acid

ad

Ges

tión d

e D

isponib

ilidad

Ges

tión F

inanci

era

Ges

tión d

e co

ntinuid

ad d

e Ser

vici

o

Madurez 5 - ADAPTABLE

Madurez 4 - MEDIBLE

Madurez 3 - PROCEDIMENTADO

Madurez 2 - DOCUMENTADO

Madurez 1 - INFORMAL

Madurez 0 - NO EXISTE

Evaluación Global 0,5 0,5 1 0 1 0,5 0,5 0,5 1 1 1 1 0,5 0,5 0,5 1,5 0

De esta evaluación, podrían surgir las siguientes conclusiones:

- La mayoría de las funciones de gestión de servidos se realizan de una u otra forma.

- Existe mucha voluntad para mantener los niveles de disponibilidad, aunque esto implique exceso en la carga de trabajo

- No están formalizadas las actividades que se realizan. - La documentación existente, es de difícil acceso debido a su dispersión. - Se carece de canales de revisión y aprobación de documentos, generando falta de

fiabilidad en cuento a su vigencia. - Las empresas externalizadas usan herramientas distintas que las nuestras para

distintas actividades, lo que genera dificultadas de integración y en ocasiones duplicidad del trabajo.

- Las labores de soporte se realizan de forma puramente reactivas.


Pág. 26 de 61

Y de estas conclusiones podrían surgir planes de revisión, tales como: Revisión de Versión Lista Objetivo Determinar el nivel de preparación de las operaciones y el personal de soporte, así como la habilidad para instalar y dar soporte a una versión dentro de los niveles de servicio acordados. Puntos clave de evaluación

- Grado de preparación de la versión mediante pruebas y métricas de control de calidad. - Grado de preparación del staff de soporte. - Disponibilidad de los procesos recurridos. - El plan de instalación / implementación. - El plan de contingencia. - Impactos potenciales sobre otros sistemas.

REVISIÓN DE OPERACIONES Objetivo Mejorar las efectividad de las operaciones diarias asociadas a soluciones de servicio particulares. Y la retención de conocimiento corporativo. Puntos clave de evaluación

- Revisión operacional de punta a punta. - Adherencia a los requerimientos de los SLA/OLA. - Oportunidades de eficiencia. - Cambios en procedimientos, automatización. - Cantidad de personal y requerimientos de pericias. - Retención de conocimiento. - Capturar conocimiento (know-how) critico de operaciones.

REVISIÓN DE NIVELES DE SERVICIO Objetivo Evaluar y mejorar la alineación de las necesidades del negocio versus los servicios de TI utilizando un conjunto aprobado de criterios para una solución de servicio. Puntos clave de evaluación

- Niveles de servicio alcanzados versus los requeridos. - Costo del servicio. - Satisfacción del cliente (expectativas de la gerencia). - Requerimientos de negocio cambiantes.

Como vemos este modelo parte de una análisis previo de como se gestiona el proceso, para posteriormente y tras haber detectado las carencias y planteado el nivel que se quiere alcanzar, definir los planes de acción necesarios. El modelo MOF como los anteriores busca que el área de TI pase de ser una organización reactiva, con mucha presión a una organización de servicio, proactiva, con tiempos de respuesta rápidos y enfocada al servicio del cliente.


Pág. 27 de 61

4 CMMI – MODELO DE GESTIÓN PARA LOS SERVICIOS DE EXPLOTACIÓN

El Capability Maturity Model Integration (en adelante CMMI) es una fusión de modelos de mejora de procesos para ingeniería de sistemas, ingeniería del software, desarrollo de productos integrados y adquisición del software. Fue creado por el Software Engineering Institute (SEI - Instituto de Ingeniería del Software) de la Carnegie Mellon University con el objetivo de extender y combinar la gran cantidad de modelos creados por el SEI, entre otros, el Capability Maturity Model3 for Software (SW-CMM), el Systems Engineering Capability Model y el Integrated Product Development, y otras organizaciones a lo largo de los años. Es uno de los modelos más utilizados en la industria del software. Entre sus principales características tenemos:

- El disminuir o eliminar la redundancia en el trabajo. - Aumentar la fiabilidad en la predicción de costos. - Aumenta el rehúso de productos y procesos. - Disminuir costos debido a través de la evaluación y mejora continua de los

procesos. Proporciona objetivos cuantificables y una aproximación al “que hacer” aunque no sea un precepto. Además, las valoraciones están orientadas a determinar si se alcanza un determinado nivel de madurez en el proceso. Este modelo permite que las empresas dispongan de practicas que pueden ser comparadas con las de otras compañas. CMMI mide el proceso de madurez en cinco niveles: nivel 1 inicial, nivel 2 gestionado, nivel 3 definido, nivel 4 gestionado cuantitativamente, nivel 5 optimizado. MODELOS CMMI CMMI ha sido diseñado para dar cobertura a uno o mas cuerpos de conocimiento. Estos cuerpos de conocimiento es lo que se entiende como modelos o disciplinas CMMI, siendo estas las siguientes:

- Software Engieenering (SW). - Systems Engineering + Software Engineering (SE/SW). - Systems Engineering + Software Engineering + Integrated Product and Process

Development (SE/SW/IPPD). - Systems Engineering + Software Engineering + Integrated Product and Process

Development + Supplier Sourcing (SE/SW/IPPD/SS). Las organizaciones elegirán el modelo CMMI que mejor se adapte a sus prioridades y objetivos de mejora, y servirán de guía para asegurar la madurez, estabilidad y solidez de los procesos.

3 El modelo CMM v1.0 (Capability Maturity Model) inicial fue desarrollado por el Instituto del Ingeniería del Software (Software Engineering Institute ESI) específicamente para la mejora continua en los procesos software. Su primera release surge en 1990, su rápida y exitosa aceptación en otras áreas, hizo que se desarrollan modelos para otras disciplinas y funciones.


Pág. 28 de 61

REPRESENTACIONES CMMI Uno representación CMMI se debe entender como la forma en que vamos a trabajar con un modelo. CMMI posee dos representaciones:

- Staged (por etapas). Se refiere al modelo de madurez de una organización vista de forma global. Sus características principales son:

Proporciona una secuencia de mejoras, empezando con una gestión de practicas básicas que progresan a través de un conjunto predefinido y sucesivo de niveles, en los que de menor nivel sirven de base para los mayores.

Permite la comparación dentro de la organización y con otras organizaciones a través del uso de los niveles de madurez.

Proporciona una fácil migración desde SW-CMM a CMMI. Proporciona un esquema de medida simple que permite la comparación

entre organizaciones.

- Continuos (continua). Se refiere a la capacidad de un Área de Proceso de forma individual. Sus características principales son:

Permite seleccionar el orden en que la mejora se llevara a cabo en línea con los requerimientos de negocio y la necesidad de mitigar los riesgos identificados.

Permite comparar entre empresas o dentro de una misma empresa, los resultados obtenidos por área de proceso tras la adopción del modelo.

Proporciona una fácil migración desde EIA/IS 731 (Electronic Industries Alliance Interim Standard) a CMMI.

Ofrece una fácil comparación entre la mejora de procesos del International Organization for Standarization and International Electrothechnical Commission (ISO/IEC) 15504, dado que la organización de las áreas de procesos es similar.

El elegir una representación u otra depende del juicio profesional y de los objetivos que se pretenden alcanzar. Independientemente de esto se debe tener claro que ambas representaciones han sido diseñadas para proporcionar los mismos resultados.

4.1 ESTRUCTURA CMMI POR ETAPAS DEFINICIONES

- Implementación. Es realizar una tarea en un área de proceso (conjunto de tareas relacionadas en un área de interés).

- Institucionalización. Resultado de implementar el proceso una y otra vez. Es

cuando se puede decir que el proceso se ha integrado en la organización.

- Desarrollo. Fase de Construcción de un ciclo de vida, incluido el mantenimiento.

- Proyecto. Actividades y recursos necesarios para proporcionar un producto al cliente.


Pág. 29 de 61

- Producto. Servicio o sistema o producto tangible que se le da al usuario.

- Nivel de Madurez. Es el nivel de desempeño que puede esperarse de una organización.

- Áreas de Proceso. Cada nivel de madurez se compone de áreas de proceso que es

un grupo de practicas o actividades realizadas de manera colectiva para conseguir un objetivo.

- Prácticas. Como los objetivos están en un alto nivel de abstracción, cada objetivo

tiene prácticas asociadas que son tareas específicas que deben ser realizadas en el área de proceso para conseguir un objetivo. Hay dos tipos de prácticas:

Prácticas específicas: Relacionadas con objetivos específicos. Prácticas genéricas: asociadas con objetivos genéricos para la

institucionalización.

- Objetivo: Cada área de proceso tiene varios objetivos que deben ser satisfechos para cumplir con el objetivo de dicha área. Hay dos tipos de objetivos:

Objetivos específicos: Objetivos específicos del área de proceso. Objetivos genéricos: Objetivos comunes a varias áreas de proceso del

modelo.

- Características Comunes. Agrupa juntas las prácticas genéricas en un área de proceso dependiendo de la función que dichas prácticas realicen.


Pág. 30 de 61

NIVELES DE MADUREZ Y MEJORA QUE SE PRODUCE


Pág. 31 de 61

4.2 NIVELES DE MADUREZ CMMI NIVEL 2 - PROCESO GESTIONADO Introducción

- Se introducen dos nuevos conceptos: Integración del producto y Desarrollo de procesos. Gestión de los proveedores.

- Llegar al nivel 2 es la barrera más grande de las organizaciones.

El nivel de madurez 2 consiste en siete áreas de proceso, que contribuirán a proyectar la eficacia de la gestión. Objetivos Genéricos Practicas Genéricas El proceso esta institucionalizado como un “proceso gestionado”4.

(1) Establecer una política organizacional. (2) Plan de procesos. (3) Proporcionar recursos. (4) Asignar responsabilidades. (5) Formación y entrenamiento del personal. (6) Gestión de la configuración. (7) Identificar e involucrar a los participantes relevantes. (8) Control y monitoreo de los procesos. (9) Asumir una evaluación objetiva. (10) Revisar el estatus con los gestores de más alto nivel.

Gestión de Requerimientos Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Gestión de Requerimientos. (1) Obtener y comprender los requerimientos.

(2) Obtener acuerdo sobre los requerimientos. (3) Gestionar los cambios de requerimientos. (4) Mantener la trazabilidad bidireccional de los requerimientos. (5) Identificar las inconsistencias entre el trabajo real a realizar y los

requerimientos.

4 Proceso gestionado (Managed Process) es un proceso que se planifica y ejecuta de acuerdo a una política.


Pág. 32 de 61

Planificación del Proyecto Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Establecer las Estimaciones. (1) Estimar el alcance del proyecto.

(2) Establecer las estimaciones de las tareas y productos del trabajo. (3) Definir el ciclo de vida del proyecto. (4) Determinar las estimaciones de esfuerzo y costo.

Desarrollar el Plan del Proyecto. (1) Establecer el presupuesto y cronograma. (2) Identificar los riesgos del proyecto. (3) Plan para la gestión de los datos del proyecto. (4) Plan para los recursos del proyecto. (5) Plan para las habilidades y conocimiento necesarias. (6) Plan para involucrar a los participantes. (7) Establecer el plan del proyecto.

Obtener Compromiso con el Plan. (1) Revisión de los planes que afectan al proyecto. (2) Reconciliar el trabajo y niveles del recurso. (3) Obtener el compromiso sobre el plan.

Supervisión y Control del Proyecto Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Control del proyecto contra el plan. (1) Control del proyecto para planificación de parámetros.

(2) Supervisar los compromisos. (3) Control de los riesgos del proyecto. (4) Supervisar la gestión de los datos. (5) Supervisar la implicación de los participantes. (6) Revisiones del progreso. (7) Revisiones de los hitos.

Gestionar las acciones correctivas.

(1) Analizar los problemas. (2) Adoptar las acciones correctivas. (3) Gestionar la acción correctiva.

Gestión de los Acuerdos con el Proveedor Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Establecer los acuerdos con el proveedor.

(1) Determinar el tipo de adquisición. (2) Selección de los proveedores. (3) Establecer los acuerdos del proveedor.

Satisfacer los acuerdos con el proveedor.

(1) Repasar los productos de COTS. (2) Ejecutar el acuerdo con el proveedor. (3) Aceptar el producto adquirido. (4) Productos de transición.

Medición y Análisis Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Alinear las actividades de medida y análisis.

(1) Establecer los objetivos de la medición. (2) Especificar las medidas. (3) Especificar los datos a ser recogidos y los procedimientos de

almacenamiento. (4) Especificar los Procedimientos de análisis.

Proporcionar los resultados de la medición.

(1) Recopilar los datos de la medición. (2) Analizar los datos de la medición. (3) Guardar datos y resultados. (4) Comunicar los resultados.


Pág. 33 de 61

Asegurar la calidad del proceso y del producto Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Evaluar los procesos y productos de trabajo objetivamente.

(1) Evaluar los procesos objetivamente. (2) Evaluar los productos de trabajo y servicios objetivamente.

Dar una visión objetiva. (1) Comunicar y asegurar la resolución de los asuntos de no cumplimiento.

(2) Establecer registros.

Gestión de la configuración Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Establecer las líneas base. (1) Identificar los elementos de la configuración.

(2) Establecer un sistema de gestión de configuración. (3) Crear un modelo para liberar las líneas bases de configuración.

Rastrear y controlar los cambios. (1) Dejar rastro de las peticiones de cambio. (2) Controlar los elementos de la configuración.

Establecer la integridad. (1) Establecer los registros de gestión de la configuración. (2) Realizar auditorias de la configuración.


Pág. 34 de 61

NIVEL 3 - PROCESO DEFINIDO Introducción

- Proceso proactivo y caracterizado por la organización.

- Proceso en el que la organización entera participa en el proceso eficiente del proyecto software.

- Los procesos están estandarizados, documentados e institucionalizados con

mayor rigurosidad.

- Se institucionaliza un proceso estándar de desarrollo de software que integra: Los procesos de ingeniería de software. Gerencia de proyectos de software.

- La organización tiene cimientos para futuros progresos, significativos y

continuos.

- Aún cuando el Proceso Definido es poderoso, todavía es tan sólo cualitativo, hay pocos datos que indiquen cuanto se produce y cuánto efectivo es el proceso en sí.

- El debate acerca del valor de las mediciones y su utilidad continúa abierto

debido a la ausencia de una norma que fije cuáles son los pasos de un proyecto y cuáles los elementos a medir.

Objetivos Genéricos Practicas Genéricas El proceso esta institucionalizado como un “proceso gestionado”5.

(1) Establecer una política organizacional. (2) Plan de procesos. (3) Proporcionar recursos. (4) Asignar responsabilidades. (5) Formación y entrenamiento del personal. (6) Establecer un “proceso definido”. (7) Gestión de la configuración. (8) Identificar e involucrar a los participantes relevantes. (9) Control y monitoreo de los procesos. (10) Recoger la mejora que se produce en la información. (11) Asumir una evaluación objetiva. (12) Revisar el estatus con los gestores de más alto nivel.

5 Proceso gestionado (Managed Process) es un proceso que se planifica y ejecuta de cuerdo una política.


Pág. 35 de 61

Áreas claves del proceso - Categoría: Ingeniería Desarrollo de Requisitos Cubre el desarrollo de requisitos del cliente, producto, y componente el producto. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Desarrollo de requisitos del cliente. (1) Licitar necesidades.

(2) Desarrollar los requisitos del cliente. Desarrollo de requisitos del producto.

(1) Establecer los requisitos del producto y de los componentes del producto.

(2) Asignar los requisitos de los componentes del producto. (3) Identificar las interfaces entre requisitos.

Análisis validación de requisitos. (1) Establecer conceptos operacionales y escenarios. (2) Establecer una definición de funcionalidad requerida. (3) Analizar requisitos. (4) Analizar requisitos dentro de un marco de “coste-beneficio”. (5) Validar los requisitos mediante múltiples métodos de comprensión.

Soluciones Técnicas Diseño, desarrollo y puesta en práctica de las soluciones técnicas. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Seleccionar las soluciones para los componentes del producto.

(1) Desarrollar en detalle soluciones alternativas y criterios de selección. (2) Evolución operacional de conceptos y escenarios. (3) Seleccionar las soluciones de los componentes del producto.

Desarrollar el diseño. (1) Diseño de productos o componentes del producto. (2) Establecer un paquete de datos técnicos. (3) Desarrollar interfaces usando distintos criterios. (4) Mejorar en el análisis que nos llevara a hacer, comprar o reutilizar.

Implementar el diseño del producto. (1) Implementar el diseño. (2) Desarrollar documentación soporte del producto.

Integración del Producto Asegurar la integración del producto. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Preparar la integración del producto. (1) Determinar la secuencia de integración.

(2) Establecer el entorno de integración del producto. (3) Establecer los procedimientos y criterios de integración del producto.

Asegurar la Compatibilidad de la Interface.

(1) Revisar la completitud y descripción de las interfaces. (2) Gestión de interfaces.

Ensamblar los componentes del producto y la entrega del producto.

(1) Confirmar la preparación de los componentes del producto para la integración.

(2) Ensamblar los componentes del producto. (3) Evaluar el ensamblado de los componentes del producto. (4) Empaquetar y entregar el producto y los componentes del producto.


Pág. 36 de 61

Verificación Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Preparar la verificación (1) Seleccionar los productos del trabajo a ser verificados.

(2) Establecer el entorno de verificación. (3) Establecer los procedimientos y criterios de verificación.

Mejora en la revisiones puntuales. (1) Preparar las revisiones puntuales. (2) Conducir las revisiones puntuales. (3) Analizar los datos de las revisiones puntuales.

Verificar del trabajo los productos seleccionados.

(1) Mejorar la verificación. (2) Analizar el resultado de la verificación e identificar las acciones

correctivas.

Validación Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Preparar la validación (4) Seleccionar los productos a ser validados.

(5) Establecer el entorno de validación. (6) Establecer los procedimientos y criterios de validación.

Validar los productos y componentes del producto.

(3) Mejorar la validación. (4) Analizar el resultado de la validación.

Áreas claves del proceso - Categoría: Administración Proceso Enfoque de procesos en organización Enfocar a la organización hacia la gestión de los procesos. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Determinar las oportunidades de mejora en los procesos.

(1) Establecer las necesidades procesos en la organización. (2) Evaluar los procesos de la organización. (3) Identificar la mejora en los procesos de la organización.

Planificar e Implementar las actividades de mejora en los procesos.

(1) Establecer planes de acción para los procesos. (2) Implementar planes de acción para los procesos. (3) Desarrollar procesos en la organización. (4) Incorporar la experiencia que existe dentro de los procesos

implantados en la organización.

Definición de procesos en la organización Correcta definición de los procesos de la organización. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Establecer procesos en la organización.

(1) Establecer procesos estándar. (2) Establecer ciclos de vida en los modelos de descripción. (3) Establecer criterios patrón y guías. (4) Establecer el repositorio de medidas en la organización. (5) Establecer una librería de procesos en la organización.


Pág. 37 de 61

Entrenamiento y formación Educación y entrenamiento para mejorar la eficacia y la eficiencia. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Establecer capacidades de formación en la organización.

(1) Establecer las necesidades estratégicas de formación. (2) Determinar que necesidades formativas que son responsabilidad de

la organización. (3) Establecer un plan de formación dentro de la organización. (4) Establecer capacidades de formación.

Proporcionar la formación necesaria. (1) Entregar la formación. (2) Establecer un registro de la formación. (3) Asegurar la efectividad de la formación.

Áreas claves del proceso - Administración Proyectos Gestión Integrada de los Proyectos para la integración de productos y el desarrollo de procesos6 Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Usar el proceso definido del proyecto.

(1) Establecer el “proceso definido” para el proyecto. (2) Usar los procesos de la organización para planificar las actividades

del proyecto. (3) Integración de planes. (4) Gestión de proyectos usando los planes integrados. (5) Contribuir al establecimiento de los procesos de la organización.

Coordinación y colaboración con usuarios relevantes.

(1) Gestionar la participación de los usuarios relevantes. (2) Gestionar dependencias. (3) Resolver los aspectos relativos s la coordinación.

Usar la visión de proyecto compartido para IPPD. (Use the Project´s Shared Vision for IPPD)

(1) Definir el contexto para la visión del proyecto compartido. (2) Establecer la visión del proyecto compartido.

Organizar equipos integrados de integración de productos y desarrollo de procesos. (Organize Integrated Teams for IPPD)

(1) Determinar la estructura de los equipos integrados para el proyecto. (2) Desarrollar distribuciones preliminares de requerimientos para los

equipos integrados. (3) Establecer los equipos integrados.

Gestión de Riesgos Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Preparar la gestión de riesgos. (6) Determinar las fuentes de riesgo y sus categorías.

(7) Definir los parámetros del riesgo. (8) Establecer una estrategia para la gestión del riesgo.

Identificar y analizar riesgos. (4) Identificar el riesgo. (5) Evaluar, categorizar y priorizar riesgos.

Mitigar el riesgo. (6) Desarrollar planes para mitigar el riesgo. (7) Implementar los planes para mitigar el riesgo.

6 Integrated Project Management for IPPD (Integrated Product and Process Development)


Pág. 38 de 61

Equipos Integrados Formar y mantener equipos integrados. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Establecer la composición de los equipos.

(1) Identificar las tareas de los equipos. (2) Identificar las necesidades de conocimiento y cualidades. (3) Asignar el personal adecuado a los distintos equipos.

Gobernar las operaciones de los equipos.

(1) Establecer una visión compartida. (2) Establecer los compromisos del equipo. (3) Definir roles y responsabilidades. (4) Establecer procedimientos para la operación. (5) Fijar las interfaces para la colaboración entre los equipos.

Gestión Integrada de Proveedores Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Analizar y seleccionar las fuentes para los productos.

(1) Analizar fuentes potenciales de productos. (2) Evaluar y determinar las fuentes de los productos.

Coordinar el trabajo con los proveedores.

(1) Monitorizar los procesos de selección de proveedores. (2) Evaluar los productos obtenidos de los proveedores seleccionados. (3) Revisar los acuerdos y relaciones fijadas con los proveedores.

Áreas claves del proceso - Soporte Análisis y Resolución de Decisiones Análisis sistemático y puesta en práctica de las decisiones acordadas. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Evaluar Alternativas. (1) Establecer guías para el análisis de decisiones.

(2) Establecer criterios de evaluación. (3) Identificar soluciones alternativas. (4) Seleccionar métodos de evaluación. (5) Evaluar alternativas. (6) Seleccionar soluciones.

Entorno organizativo par la Integración Ambiente organizativo adecuado para el desarrollo integrado del producto y del proceso. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Proporcionar integración de productos y desarrollo de procesos para la infraestructura. (Provide IPPD Infraestructure)

(1) Establecer la visión compartida de la organización. (2) Establecer un entorno integrado de trabajo. (3) Identificar la pericias necesarias para los requerimientos asociados a

la integración de productos y el desarrollo de procesos. Gestión de personas para la integración.

(1) Establecer mecanismo de liderazgo. (2) Establecer incentivos para la integración. (3) Establecer mecanismos para compatibilizar las responsabilidades

laborales con las relacionadas con el hogar.


Pág. 39 de 61

NIVEL 4 - PROCESO GESTIONADO CUANTITATIVAMENTE Introducción

- Los proyectos son gestionados “por los números.”

- Las decisiones organizacionales se toman “por los números.”

- Los procesos, los servicios y la calidad del producto se miden “por los números.”

- Proceso de refinamiento sucesivo(el paso al nivel 4 no es un cambio fácil).

- No se añaden metas genéricas en el nivel 4 a partir del nivel 3.

- El nivel de madurez podría no probar el beneficio esperado (análisis de C/B).

- Lo que hace este nivel de madurez distinto son las dos áreas de procesos: Proceso organizacional del desarrollo. Gestión de proyectos cuantitativa.

- Objetivos: Entendimiento cuantitativo de la ejecución de los procesos de la

organización. Proporcionar, para la gestión cuantitativa de proyectos:

Datos de ejecución de procesos. Líneas Base. Modelos.

- Necesidades:

Compromiso y la participación de la alta dirección. Alto grado de experiencia. Personal numeroso.

- Importante:

Uso de Herramientas automatizadas para la recogida de datos. División del repositorio de medidas en capas. Experiencia en la recogida de datos.


Pág. 40 de 61

Rendimiento de los Procesos en la Organización Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Establecer líneas base y modelos de ejecución.

(1) Seleccionar procesos. (2) Establecer medidas de ejecución de procesos. (3) Establecer objetivos de calidad y ejecución de procesos. (4) Establecer líneas base de ejecución de procesos. (5) Establecer modelos de ejecución de procesos.

- Línea base de ejecución de proceso:

Resultados históricos logrados siguiendo un proceso. Uso: comparar ejecución real vs ejecución esperada de procesos.

- Modelo de ejecución de procesos :

Relaciones entre atributos de un proceso y sus productos de trabajo.

Uso: estimar o predecir un valor crítico que no puede ser medido por el momento.

- Medidas; deben proporcionar Rangos vs. datos puntuales, además indican

áreas de debilidad a reforzar. Las medidas a considerar son: De proceso:

Esfuerzo, tamaño ,costo, planificación. Revisando la productividad en las fases del cv.

De producto: Fiabilidad, densidad de defectos.

Gestión Cuantitativa de Proyectos Gestión cuantitativa de los procesos para lograr los objetivos de calidad y ejecución del proceso establecidos por el proyecto. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Gestionar el proyecto cuantitativamente.

(1) Establecer los objetivos del proyecto. (2) Componer los procesos definidos. (3) Elegir los subprocesos que serán gestionados estadísticamente. (4) Gestionar la ejecución de proyectos.

Gestionar de manera estadística el rendimiento y ejecución de los de subprocesos.

(1) Elegir las medidas y técnicas analíticas. (2) Aplicar los métodos estadísticos para comprender la variación. (3) Monitorizar la ejecución de los subprocesos elegidos. (4) Archivar los datos de gestión estadística.


Pág. 41 de 61

NIVEL 5 - OPTIMIZANDO LOS PROCESOS Introducción

- Áreas del Nivel 5: Innovación y Despliegue Organizacional. Análisis y Resolución de las Causas.

- Para satisfacer los objetivos del Nivel 5 se tienen que haber satisfecho los

objetivos de los Niveles 2,3 y 4.

- Objetivos: Mejorar la calidad general de los procesos de la organización. Forma de alcanzarlo:

Identificar las causas de la variación. Determinar la raíz de las causas de las condiciones

identificadas. Hacer pruebas de las mejoras del proceso. Incorporar las mejoras y acciones correctivas en los

procesos estándar de la organización. Innovación y Despliegue Organizacional Selección y despliegue de las mejoras incrementales e innovadoras que mejoren los procesos y tecnologías de la organización. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Selección de mejoras. (1) Reunir y analizar propuestas de mejoras.

(2) Identificar y analizar innovaciones. (3) Pruebas de las mejoras. (4) Seleccionar mejoras para desplegarlas.

Desplegar mejoras (1) Plan de despliegue. (2) Gestión de despliegue. (3) Medida de los efectos de mejora.

- Las propuestas de mejora de procesos y mejoras tecnológicas están incluidas

en este área de proceso.

- Etapas a seguir en esta área de proceso: Presentar las propuestas de mejora. Revisar y analizar las propuestas. Prueba piloto de las propuestas. Medir las mejoras para ver si son efectivas en las pruebas. Planear el despliegue de las mejoras. Desplegar las mejoras. Medir la eficacia de las mejoras a través de la organización o

proyecto.


Pág. 42 de 61

Análisis y Resolución de las Causas Identificar las causas de los defectos y otros problemas, y tomar acciones preventivas para evitar que sucedan en un futuro. Consta de los siguientes objetivos y practicas especificas.

Objetivos Específicos Practicas Especificas Determinar las causas de los defectos.

(1) Seleccionar los datos de los defectos para su análisis. (2) Analizar las causas.

Tratar las causas de los defectos. (1) Implementar las acciones propuestas. (2) Evaluar los efectos de los cambios. (3) Guardar los datos.

- Etapas a seguir en esta área de proceso:

Buscar los defectos y problemas en la organización. Seleccionar los datos a analizar. Analizar las causas. Preparar propuestas para tratar los problemas. Implementar las propuestas. Evaluar los efectos de los cambios.


Pág. 43 de 61

4.3 CMMI EN LA GESTIÓN DE SERVICIOS DE EXPLOTACIÓN Como se ha comentado anteriormente CMMI es una colección de buenas prácticas alineadas con el concepto de modelos de madurez. Debido a la herencia de SW/CMM y tal y como se ha visto en la descripción de las áreas de procesos, objetivos y las practicas, está muy orientado hacia desarrollo y mantenimiento de software. Si bien CMMI es la evolución e integración de un conjunto de modelos de madures, el desarrollo y mantenimiento de software, fijan en gran medida su líneas de actuación. En el otro punto nos encontramos con ITIL modelo totalmente orientado a los servicios de mantenimiento y gestión de las operaciones. ITIL y CMMI son dos modelos de madurez claramente distintos pero no mutuamente exclusivos. Las principales diferencias se deben a que CMMI esta focalizado en la madurez de los procesos software a través de una actividad de mejora continua e ITIL se centra en el entendimiento y desarrollo de todas las áreas referentes a la infraestructura de TI, además de incorporar el ciclo de vida del hardware dentro de una organización ¿CUÁL ELEGIR ITIL ó CMMI?. No existe razón alguna que nos obligue a decantarnos por un modelo u otro, dado que entre otros aspectos ITIL no ha sido prescrito y el marco de referencia que ITIL conforma es muy similar al de CMMI, por lo que bien podrían ser usados de forma conjunta. ¿CÓMO CONJUGAR ITIL Y CMMI? ITIL, desde el punto de vista de su estructura, se puede entender como un marco objetivo de las áreas de gestión, centrado en aquellas que hace bien tales como la Gestión de la Capacidad, la Gestión del Nivel de Servicio y todas las demás incluyendo la Gestión de Release7 (software y hardware). Es en la Gestión de Release (software) donde CMMI entra con todo su potencial y se constituye en el modelo especifico que subyace para la Gestión de Release (en el caso del desarrollo de software) en nuestra organización bajo ITIL. El que sólo se considere el aspecto software es consecuencia de que CMMI no contempla el elemento hardware.

7 La versión uno de ITIL no incorporaba el ciclo de vida de hardware dentro de la Gestión de Release, aspecto que ha sido subsanado en las nuevas versiones.


Pág. 44 de 61

CMMI COMO MODELO PARA GESTIONAR SERVICIOS DE EXPLOTACIÓN Con lo visto anteriormente todo el modelo CMMI sólo seria de aplicabilidad para la gestión de las versiones software que se generan en los servicios de explotación. Entonces, ¿debemos desistir de nuestra idea y tomar como referencia de modelos para la gestión de servicios de explotación los que se definieron anteriormente, o por otro lado olvidar el marco de acción que se auto-impone el modelo CMMI y “usarlo” en otros ámbitos?. La respuesta es que sí, y la mejor forma de comprobarlo es ver si para un servicio de explotación determinado los objetivos y practicas definidos por el modelo CMMI son de aplicabilidad. Partamos de las áreas de procesos, objetivos y practicas de nivel 2, consideremos como servicio de explotación la gestión de Acuerdos de Nivel de Servicio de explotación con un proveedor externo, y marquemos las prácticas CMMI que consideremos de aplicabilidad con una A:

objetivos específicos

prácticas especificas aplicable

Obtener y comprender los requerimientos. A

Obtener acuerdo sobre los requerimientos. A

Gestionar los cambios de requerimientos. A

Mantener la trazabilidad bidireccional de los requerimientos. A Gest

ión

de

Req

ueri

mie

nto

s

Gestión de Requerimientos

Identificar las inconsistencias entre el trabajo real a realizar y los requerimientos. A

Estimar el alcance del proyecto. A

Establecer las estimaciones de las tareas y productos del trabajo. A

Definir el ciclo de vida del proyecto. A

Establecer las Estimaciones

Determinar las estimaciones de esfuerzo y costo. A

Establecer el presupuesto y cronograma. A

Identificar los riesgos del proyecto. A

Plan para la gestión de los datos del proyecto. A

Plan para los recursos del proyecto. A

Plan para las habilidades y conocimiento necesarias. A

Plan para involucrar a los participantes. A

Desarrollar el Plan del Proyecto.

Establecer el plan del proyecto. A

Revisión de los planes que afectan al proyecto. A

Reconciliar el trabajo y niveles del recurso. A

Pla

nif

icaci

ón

d

el P

royect

o

Obtener Compromiso con el Plan

Obtener el compromiso sobre el plan. A Control del proyecto para planificación de parámetros. A Supervisar los compromisos. A Control de los riesgos del proyecto. A Supervisar la gestión de los datos. A Supervisar la implicación de los participantes. A Revisiones del progreso. A

Control del proyecto contra el plan.

Revisiones de los hitos. A Analizar los problemas. A Adoptar las acciones correctivas. A

Su

perv

isió

n y

C

on

tro

l d

el P

royect

o

Gestionar las acciones correctivas.

Gestionar la acción correctiva. A Determinar el tipo de adquisición. A Selección de los proveedores. A

Gest

ió

n d

e

los

Acu

ed

Establecer los acuerdos con el proveedor. Establecer los acuerdos del proveedor. A


Pág. 45 de 61

objetivos específicos

prácticas especificas aplicable

Repasar los productos de COTS. B8 Ejecutar el acuerdo con el proveedor. A Aceptar el producto adquirido. A

Satisfacer los acuerdos con el proveedor.

Productos de transición. A Establecer los objetivos de la medición. A

Especificar las medidas. A

Especificar los datos a ser recogidos y los procedimientos de almacenamiento. A

Alinear las actividades de medida y análisis

Especificar los Procedimientos de análisis. A Recopilar los datos de la medición. A Analizar los datos de la medición. A Guardar datos y resultados. A

Med

ició

n y

A

nálisi

s

Proporcionar los resultados de la medición

Comunicar los resultados. A

Evaluar los procesos objetivamente. A Evaluar los procesos y productos de trabajo objetivamente.

Evaluar los productos de trabajo y servicios objetivamente. A

Comunicar y asegurar la resolución de los asuntos de no cumplimiento. A

Ase

gu

rar

la

cali

dad

D

el p

roce

so y

d

el p

rod

uct

o

Dar una visión objetiva.

Establecer registros. A

Identificar los elementos de la configuración. A Establecer un sistema de gestión de configuración. A

Establecer las líneas base.

Crear un modelo para liberar las líneas bases de configuración. A Dejar rastro de las peticiones de cambio. A Rastrear y controlar

los cambios. Controlar los elementos de la configuración. A Establecer los registros de gestión de la configuración. A G

est

ión

de la

con

fig

ura

ció

n

Establecer la integridad. Realizar auditorias de la configuración. A

El ejercicio se ha desarrollado a un nivel muy básico, pero incluso a este nivel se observa con claridad la posible aplicabilidad del modelo CMMI para la gestión de servicios de explotación. Subamos un nivel y veamos si las áreas de proceso, objetivos y practicas de nivel 3, son tan válidas como las de nivel 2 para un servicio de explotación como el indicado:

objetivos específicos prácticas especificas aplicable Licitar necesidades. A Desarrollo de requisitos

del cliente. Desarrollar los requisitos del cliente. A Establecer los requisitos del producto y de los componentes del producto. A Asignar los requisitos de los componentes del producto. A

Desarrollo de requisitos del producto.

Identificar las interfaces entre requisitos. A Establecer conceptos operacionales y escenarios. A Establecer una definición de funcionalidad requerida. A Analizar requisitos. A Analizar requisitos dentro de un marco de “coste-beneficio”. A

Desa

rro

llo

de

Req

uis

ito

s

Análisis validación de requisitos.

Validar los requisitos mediante múltiples métodos de comprensión. A Desarrollar en detalle soluciones alternativas y criterios de selección. A Evolución operacional de conceptos y escenarios. A

Seleccionar las soluciones para los componentes del producto. Seleccionar las soluciones de los componentes del producto. A

Diseño de productos o componentes del producto. A Establecer un paquete de datos técnicos. A Desarrollar interfaces usando distintos criterios. A

So

luci

on

es

Técn

icas

Desarrollar el diseño.

Mejorar en el análisis que nos llevará a hacer, comprar o reutilizar. A

8 Por la propia definición de COTS (fragmentos de código), esta practica no seria de aplicabilidad plena para la gestión de servicios de explotación, salvo que se acotara su alcance al software usado en la gestión de servicios de explotación.


Pág. 46 de 61

objetivos específicos prácticas especificas aplicable Implementar el diseño. A Implementar el diseño

del producto. Desarrollar documentación soporte del producto. A Determinar la secuencia de integración.. A Establecer el entorno de integración del producto A

Preparar la integración del producto.

Establecer los procedimientos y criterios de integración del producto. A Revisar la completitud y descripción de las interfaces. A Asegurar la

Compatibilidad de la Interface. Gestión de interfaces. A

Confirmar la preparación de los componentes del producto para la integración.

A

Ensamblar los componentes del producto. A Evaluar el ensamblado de los componentes del producto. A In

teg

raci

ón

del P

rod

uct

o

Ensamblar los componentes del producto y la entrega del producto.

Empaquetar y entregar el producto y los componentes del producto. A Seleccionar los productos del trabajo a ser verificados. A Establecer el entorno de verificación. A

Preparar la verificación

Establecer los procedimientos y criterios de verificación. A Preparar las revisiones puntuales. A Conducir las revisiones puntuales. A

Mejora en la revisiones puntuales.

Analizar los datos de las revisiones puntuales. A Mejorar la verificación. A

Veri

fica

ció

n

Verificar del trabajo los productos seleccionados. Analizar el resultado de la verificación e identificar las acciones correctivas. A

Seleccionar los productos a ser validados. A Establecer el entorno de validación. A

Preparar la validación

Establecer los procedimientos y criterios de validación. A Mejorar la validación. A

Valid

aci

ón

Validar los productos y componentes del producto. Analizar el resultado de la validación. A

Establecer las necesidades procesos en la organización.. A Evaluar los procesos de la organización A

Determinar las oportunidades de mejora en los procesos. Identificar la mejora en los procesos de la organización. A

Establecer planes de acción para los procesos. A Implementar planes de acción para los procesos. A Desarrollar procesos en la organización. A

En

foq

ue d

e p

roce

sos

en

org

an

izaci

ón

Planificar e Implementar las actividades de mejora en los procesos.

Incorporar la experiencia que existe dentro de los procesos implantados en la organización.

A

Establecer procesos estándar. A Establecer ciclos de vida en los modelos de descripción. A Establecer criterios patrón y guías. A Establecer el repositorio de medidas en la organización. A

Defi

nic

ión

de

pro

ceso

s e

n la

org

an

izaci

ón

Establecer procesos en la organización.

Establecer una librería de procesos en la organización. A Establecer las necesidades estratégicas de formación. A Determinar que necesidades formativas que son responsabilidad de la organización.

A

Establecer un plan de formación dentro de la organización. A

Establecer capacidades de formación en la organización.

Establecer capacidades de formación. A Entregar la formación. A Establecer un registro de la formación. A E

ntr

en

am

ien

to y

fo

rmaci

ón

Proporcionar la formación necesaria.

Asegurar la efectividad de la formación. A Establecer el “proceso definido” para el proyecto. A Usar los procesos de la organización para planificar las actividades del proyecto.

A

Integración de planes. A Gestión de proyectos usando los planes integrados. A

Usar el proceso definido del proyecto.

Contribuir al establecimiento de los procesos de la organización. A Gestionar la participación de los usuarios relevantes. A Gestionar dependencias. A

Coordinación y colaboración con usuarios relevantes. Resolver los aspectos relativos s la coordinación. A

Gest

ión

In

teg

rad

a d

e lo

s P

royect

os

para

la

inte

gra

ció

n d

e p

rod

uct

os

y

el d

esa

rro

llo

de p

roce

sos

Usar la visión de proyecto compartido para IPPD

Definir el contexto para la visión del proyecto compartido. A


Pág. 47 de 61

objetivos específicos prácticas especificas aplicable compartido para IPPD. (Use the Project´s Shared Vision for IPPD)

Establecer la visión del proyecto compartido. A

Determinar la estructura de los equipos integrados para el proyecto. A

Desarrollar distribuciones preliminares de requerimientos para los equipos integrados. A

Organizar equipos integrados de integración de productos y desarrollo de procesos. (Organize Integrated Teams for IPPD) Establecer los equipos integrados. A

Determinar las fuentes de riesgo y sus categorías. A Definir los parámetros del riesgo. A

Preparar la gestión de riesgos.

Establecer una estrategia para la gestión del riesgo. A Identificar el riesgo. A Identificar y analizar

riesgos. Evaluar, categorizar y priorizar riesgos. A Desarrollar planes para mitigar el riesgo. A

Gest

ión

de

Rie

sgo

s

Mitigar el riesgo. Implementar los planes para mitigar el riesgo. A Identificar las tareas de los equipos. A Identificar las necesidades de conocimiento y cualidades. A

Establecer la composición de los equipos.

Asignar el personal adecuado a los distintos equipos. A Establecer una visión compartida. A Establecer los compromisos del equipo. A Definir roles y responsabilidades. A Establecer procedimientos para la operación. A

Eq

uip

os

Inte

gra

do

s

Gobernar las operaciones de los equipos.

Fijar las interfaces para la colaboración entre los equipos. A Analizar fuentes potenciales de productos. A Analizar y seleccionar las

fuentes para los productos. Evaluar y determinar las fuentes de los productos. A

Monitorizar los procesos de selección de proveedores. A Evaluar los productos obtenidos de los proveedores seleccionados. A

Gest

ión

In

teg

rad

a d

e

Pro

veed

ore

s

Coordinar el trabajo con los proveedores.

Revisar los acuerdos y relaciones fijadas con los proveedores. A Establecer guías para el análisis de decisiones.. A Establecer criterios de evaluación. A Identificar soluciones alternativas A Seleccionar métodos de evaluación. A Evaluar alternativas. A A

nálisi

s y

Reso

luci

ón

de

Deci

sio

nes

Evaluar Alternativas.

Seleccionar soluciones. A Establecer la visión compartida de la organización. A Establecer un entorno integrado de trabajo. A

Proporcionar integración de productos y desarrollo de procesos para la infraestructura. (Provide IPPD Infraestructure)

Identificar la pericias necesarias para los requerimientos asociados a la integración de productos y el desarrollo de procesos. A

Establecer mecanismo de liderazgo. A Establecer incentivos para la integración. A

En

torn

o o

rgan

izati

vo

p

ara

la

In

teg

raci

ón

Gestión de personas para la integración.

Establecer mecanismos para compatibilizar las responsabilidades laborales con las relacionadas con el hogar.

A

Si consideramos el valor A como que esas las prácticas puede ser consideradas para los servicios de explotación, podemos afirmar que CMMI es un modelo válido para la gestión de los servicios de explotación. Por supuesto se deberán rehacer ajustes en el modelo, y aquellas áreas de procesos, objetivos y practicas con marcado carácter y orientación hacia el desarrollo y mantenimiento de software tendrán que ser revisadas y readaptadas. La pregunta es, ¿cómo llevamos a cabo el desarrollo del modelo?, es decir, si tomamos a CMMI como base de lo que se debe hacer, ¿quién o qué nos va a indicar el cómo?.


Pág. 48 de 61

Podemos acudir al conjunto de elementos o componentes que forman parte del modelo CMMI:

- Notas (Notes). - Procesos Relacionados (Related Process). - Subpracticas ( Subpractices). - Typical work Products. - Discipline Amplifications. - Generic Practice Elaborations.

Si bien estos elementos son un complemento al modelo CMMI, puede que no llegaran a aportar suficiente información sobre el “cómo”. Por tanto se propone hacer uso de otros modelos o esquemas, tales como:

- ITIL, su enfoque hacia la explotación de sistemas le hace una fuente de información y conocimiento de primera mano, además de incorporar el detalle suficiente para sentar las bases del “cómo”.

Una revisión de ambos modelos puede que nos de una visión de la escasa duplicidad entre ambos por lo que surgirá, entre otros, la necesidad de:

Un gran esfuerzo de sincronización entre ambos. Una clara definición de interfaces roles y responsabilidades.

Todo esto permitirá que las mejoras de un modelo impacten positivamente en los aspectos de calidad del otro.

- Los modelos PSP (Personal Software Process) y TSP (Team Software Process). Estos modelos surgen bajo la premisa de dotar a las actividades software de equipos humanos cualificados y adaptativos, prestando gran atención a la forma de trabajo en equipo. [4] Si conseguimos desligar la connotación software de estos modelos y tomamos la filosofía subyacente, estos modelos bien pudieran ser utilizados para todas aquellas área de proceso, objetivos y practicas, donde el elemento principal son las personas, como por ejemplo el área de proceso de CMMI “Equipos Integrados”.

- Método SIX SIGMA (ver ANEXO B). Si bien su puesta en marcha pudiera resultar o parecer compleja, su implantación sólo puede reportar beneficios. Ya existen resultados contrastados sobre la validez de este modelo para alcanzar niveles de madurez de CMMI Nivel 4 y Nivel 5. [5]


Pág. 49 de 61

5 CONCLUSIONES Como se ha puesto de manifiesto a lo largo de la exposición, los servicios de explotación abarcan ámbitos de actuación muy dispares, además de incorporar complejidades derivadas de su operatividad y del conjunto de entes (personas incluidas) que intervienen en su ejecución. Los servicios de explotación están al mismo nivel en cuento a necesidad de control que el resto de actividades de TI, sirva de referencia el hecho de que el desarrollo de la ley Sarbanes Oxley (ver ANEXO A) en cuanto a sistemas, implica actividades relacionadas con el gestión de la explotación de los sistemas de información. [5] [6] Este conjunto tan amplio de servicios deben de alguna forma ser controlados y medidos. Este aspecto hace que surjan modelos, entre los cuales están los descritos en este documento, con sus propios condicionantes y orientaciones:

- COBIT, surge dentro del ámbito de la Auditoria de Sistemas y esta principalmente orientado al control de las actividades, además no sólo se focaliza en los servicios de explotación sino que cubre todo el espectro relacionado con los sistemas y tecnologías de la información. Además últimamente esta sufriendo una transformación orientándose hacia lo que se conoce como EL GOBIERNO DE LAS TECNOLOGÍAS DE LA INFORMACIÓN.

- MOF, es un modelo que surge a la sombra de una gran empresa tecnológica, para

dar cobertura a la implantación de sus propios productos. Aunque esto no de be limitar su uso dado que sus preceptos pueden ser aislados.

- ITIL. La marcada orientación de este modelo hacia los servicios de explotación

dando información de cómo se deben acometer estos servicios implica que deba ser considerado como un punto de referencia. En contrapartida la ausencia de un modelo de madurez explícitamente definido puede jugar en contra para su adopción.

- CMMI surge como un modelo muy orientado hacia los procesos software, pero

como hemos visto también es valido para los servicios de explotación. CMMI debe verse como punto de referencia para saber lo que se debe hacer. El valor intrínsico de CMMI y su conjunción con otros modelos, tales como, ITIL, SIX-SIGMA, PSP o TSP, le da el suficiente apresto para ser valido en la gestión de los servicios de explotación.

Además la adopción de CMMI supone una ventaja competitiva para las empresas que prestan servicios de tecnología frente a otras, dado que van a poder disponer de un modelo de madurez que actuará como medida comparativa de la calidad del servicio que prestan. Sin olvidar la mejora que supone para la empresa el hecho de considerar la mejora continua como parte integral de su operativa de sistemas y tecnologías de la información.


Pág. 50 de 61

Si realizamos una sumatoria de todo lo comentado, y le añadimos el hecho de que todos estos modelos, a pesar de tener sus propias definiciones y esquemas para afrontar los objetivos perseguidos, siguen un mismo patrón de comportamiento:

CONTROLAR DEFINIR

MEDIR

ANALIZAR

MEJORAR

CONTROLAR DEFINIR

MEDIR

ANALIZAR

MEJORAR

DEFINIR Establecer los fines y objetivos del proyecto MEDIR Identificar el conjunto de rangos potenciales y establecer líneas bases para los distintos niveles. ANALIZAR Evaluar los datos y la información, obtenida de los evento. Para identificar patrones de comportamiento. MEJORAR Desarrollar, implementar y evaluar soluciones paliativas para las carencias detectadas. CONTROLAR Asegurar que los problemas están identificados y que los nuevos métodos pueden ser aplicados.

Entonces deberemos ver a CMMI, al menos desde el plano teórico, como un modelo válido para la gestión de servicios de explotación. Queda por delante desarrollarlo y ver su comportamiento en un entorno real. Solo una última advertencia referente al uso que le demos a CMMI:

- Si adoptamos el modelo CMMI desde el punto de vista de la evaluación, entendida esta como la búsqueda de lo mínimo exigido para satisfacer el modelo y pasar el test, estaremos llevando a nuestra organización al fracaso en cuanto a satisfacer verdaderamente el modelo por la falta de institucionalización y no dará un verdadero valor de negocio a nuestra organización.

- Si por el contrario adoptamos un punto de vista de mejora de proceso,

entendida esta como la búsqueda de lo mejor para la organización y su crecimiento, estaremos aprovechando la esencia del modelo y sus efectos repercutirán para bien en nuestra empresa.


Pág. 51 de 61

6 ANEXO – A LEY SARBANES OXLEY El incluir este anexo obedece al hecho de que incluso para aspectos regulativos de ámbito financieros como la Ley Sarbanes Oxley, se pone de manifiesto la importancia de las tecnologías de la información (incluida la gestión de los servicios de explotación) en los proceso de negocio y la necesidad de su correcto modelado y control, dado que repercuten en el funcionamiento de la organización de forma global. La Ley Sarbanes Oxley es promulgada el 30 de julio de 2002, para proteger a los inversores mejorando la ACCURACY y la confianza de las notificaciones corporativas realizadas cumpliendo con las leyes financieras, y otros propósitos. Su ámbito de aplicación es para todas aquellas empresas cuyos valores, acciones y obligaciones, coticen en Wall Street. La Ley es interpretada y reglamentada por la SEC (Securities and Exchange Commission) y el PCAOB (Public Company Accounting Oversight Board). Como secciones de gran impacto y repercusión de la Ley tenemos: Sección 302. Corporate Responsibility for Financial Reports. Requiere que el Consejero Delegado y el Director Financiero certifiquen anualmente que:

- Han revisado el informe y no contiene ninguna declaración falsa. - Son responsables del establecimiento y mantenimiento de los controles internos. - Han diseñado controles que aseguren que la información tratada por ellos es

correcta. - Han evaluado la efectividad de los controles. - Han presentado en el informe las conclusiones sobre la efectividad de los

controles internos basados en su evaluación. - Han comunicado al Comité de Auditoria y a los auditores las deficiencias

significativas detectadas en los controles, así como cualquier caso de fraude, material o no, identificado, que implique a la dirección o a los empleados.

Sección 404. Management Assessment of Internal Controls. Requiere que anualmente la Dirección prepare un informe de control interno que:

- Determine su responsabilidad en establecer y mantener una adecuada estructura de control interno y unos adecuados procedimientos para la elaboración en tiempo, forma y contenido de la información financiera de la sociedad.

- Contendrá una evaluación de la efectividad de la estructura de control interno y los procedimientos.

El Auditor Externo deberá dar una opinión sobre las afirmaciones de la Dirección. PCAOB – Estándar de auditoría nº 2. Establece, una auditoría de control interno sobre el reporte financiero realizada en conjunción con una auditoría de estados financieros;

- Contempla tanto el trabajo que se requiere para auditar el control interno sobre reporte financiero como la relación de esa auditoría con la de los estados financieros, y

- Se refiere a la atestación de la evaluación de la Dirección de la efectividad del control interno como la auditoría del control interno sobre el reporte financiero.


Pág. 52 de 61

La Dirección debe basar su evaluación de la efectividad del control interno de la compañía sobre reporte financiero en base a un modelo de control reconocido y adecuado establecido por un consejo de expertos. En EEUU, el Committee of Sponsoring Organizations ("COSO") de la Comisión Treadway ha publicado Internal Control – Integrated Framework. La publicación de COSO (en adelante COSO) provee un modelo adecuado para los propósitos de la evaluación de la Dirección.

METODOLOGÍA COSO La metodología COSO establece una definición de control interno y facilita un modelo en base al cual las empresas puedan evaluar los sistemas de control interno así como mejorarlos, y por tanto sienta las bases para formular el modelo de control interno exigido por la Ley. El control interno se define como un proceso efectuado por el Consejo de Administración, la Dirección y el resto de personal de un entidad con el objeto de proporcionar un grado de seguridad razonable en cuanto a la consecución de objetivos dentro de las siguientes categorías:

- Operativos: referente a la utilización eficaz y eficiente de los recursos de una entidad.

- Financiero: referente a la preparación y publicación de estados financieros fiables. - Cumplimiento: referente al cumplimiento por parte de la entidad de las leyes y

normas que le sean aplicables.


Pág. 53 de 61

El control interno consta de cinco componentes relacionados entre sí e inherentes al estilo de gestión de la empresa:

- Entorno de control. - Evaluación de riesgos. - Actividades de control. - Información y comunicación. - Supervisión.

Dado que COBIT se formuló en línea con los requerimientos exigidos en la metodología COSO, éste modelo proporciona una optima plataforma sobre la que construir los requerimientos que sobre tecnologías de la información recoge la Ley:


Pág. 54 de 61


Pág. 55 de 61

A partir de la metodología COSO y de COBIT se puede construir un marco de control que para los procesos de Desarrollo, Cambios a Programas, Acceso a Programas y Datos, y Operaciones. Además se incluir un proceso denominado Entorno de Control que servirá para valorar el estado general del área de TI.

Entorno de Control de TI Es la extensión del componente del entorno global de control en la organización de TI. Representa el “tone at the top” de la organización de TI y debería ser evaluado de una forma similar al entorno de control de la compañía en su conjunto Sub-componentes típicos clave:

- Valores éticos y de integridad. - Compromiso con la competencia y desarrollo de las personas. - Filosofía de la Dirección y estilo de operar. - Estructura de la organización. - Asignación de autoridad y responsabilidad. - Políticas y procedimientos de Recursos Humanos. - Participación de aquellos encargados del gobierno.


Pág. 56 de 61

Desarrollo Procesos y controles utilizados por la compañía para desarrollar, configurar, e implementar nuevas aplicaciones con el objetivo de satisfacer los objetivos financieros, operativos, y de cumplimiento del negocio. Sub-componentes típicos clave:

- Gestión de programa de actividades de desarrollo. - Inicio de proyectos (planificación de proyectos, definición del alcance, y requerimientos de

aprobación). - Análisis y diseño, incluyendo especificaciones técnicas y de negocio. - Procedimientos de selección de paquetes SW/HW. - Pruebas y aseguramiento de la calidad. - Conversión de datos. - Procedimientos de paso a explotación. - Documentación de usuario y técnica, y formación.

La Dirección debería documentar, probar y evaluar los controles para asegurar:

- El desarrollo y adquisición de nuevos sistemas se aprueba por un nivel apropiado tanto de la Dirección de TI como del negocio.

- La metodología de desarrollo de sistemas tiene controles apropiados y se cumple para el desarrollo o adquisición de sistemas y aplicaciones utilizadas para el proceso de reporte financiero.

- Los controles existentes que son afectados por el diseño e implementación de nuevos sistemas son modificados o rediseñados para retener su integridad.

- Se llevan a cabo las pruebas adecuadas para todos los desarrollos de sistemas y aplicaciones que se utilizan en los procesos de reporte financiero.

- Todas las pruebas se aprueban por los usuarios y por un adecuado nivel tanto de la Dirección de TI como del negocio.

- Se desarrolla una documentación adecuada de sistema, usuario y control para nuevos sistemas y aplicaciones utilizados durante los procesos de reporte de los estados financieros.

- El desarrollo de interfaces para asegurar que se transfiere los datos completamente y precisamente.

- El acceso restringido para migrar sistemas y aplicaciones nuevos al entorno de producción. - La información migrada a la nueva aplicación o sistema mantiene su integridad. - Se forma a los usuarios en los nuevos sistemas y aplicaciones de acuerdo a un plan de

formación definido. Cambios a Programas Procesos y controles utilizados por la compañía para asegurar que las modificaciones a programas son satisfactorias para los objetivos financieros, operativos, y de cumplimiento del negocio. Sub-componentes típicos clave:

- Gestión de programa de actividades de cambio. - Especificación, autorización, y seguimiento. - Construcción, incluyendo controles de los entornos de desarrollo y del código fuente. - Pruebas y aseguramiento de la calidad. - Autorización del paso al entorno de producción. - Documentación técnica y de usuario, y formación.


- Cualquier cambio a los sistemas y aplicaciones que proporcionan control sobre reporte financiero ha sido adecuadamente autorizado por la Dirección apropiada.

- Se modifica la documentación de sistema, usuario y control para reflejar adecuadamente cambios a los sistemas relevantes para el reporte financiero.

- Se prueban los cambios a aplicaciones y sistemas y se documentan los resultados.


Pág. 57 de 61

- Acceso restringido para migrar cambios a sistemas y aplicaciones al entorno de producción. - No se realizan cambios no autorizados a ficheros de sistema de aplicaciones, debidos a la

migración en producción. - Todos los cambios autorizados a sistemas y aplicaciones se migran al entorno de

producción. - Se forma a los usuarios sobre los cambios a sistemas y aplicaciones.

Acceso a Programas y Datos (Seguridad) Procesos y controles implantados para asegurar el que acceso a recursos del sistema y datos es autenticado y autorizado para satisfacer los objetivos financieros, operativos, y de cumplimiento del negocio. Sub-componentes típicos clave:

- Políticas y procedimientos. - Organización y gestión. - Administración de la seguridad de las aplicaciones. - Administración de la seguridad de los datos. - Administración de la seguridad de los sistemas operativos. - Seguridad de la red interna. - Seguridad de la red perimetral. - Seguridad física.


- Se gestiona la seguridad de la información para guiar la implementación consistente de prácticas de seguridad.

- Los usuarios son conscientes de la posición de la organización con respecto a la seguridad de la información ya que pertenece a la información de reporte financiero.

- El acceso lógico a la información existente en recursos informáticos está restringido adecuadamente por la implementación de mecanismos de identificación, autenticación, y autorización.

- Se han establecido procedimientos de forma que las cuentas de usuario son creadas, modificadas, y borradas a tiempo.

- Se revisa periódicamente la necesidad de los derechos de acceso. - Existe un mecanismo efectivo para registrar la actividad de seguridad, identificar

violaciones de seguridad, y escalar y actuar ante ellos a tiempo. Operaciones Procesos y controles implantados sobre las operaciones del día a día de los sistemas de TI y aplicaciones para asegurar que los sistemas en producción son capaces de satisfacer los objetivos financieros, operativos, y de cumplimiento del negocio. Sub-componentes típicos clave:

- Políticas y procedimientos. - Organización y gestión. - Planificación y ejecución de procesos batch. - Gestión de copias de seguridad. - Procedimientos de recuperación de fallos operativos.


- Existen procedimientos adecuados de realización y restauración de copias de seguridad de forma que los datos, transacciones, y programas que son necesarios para el reporte financiero pueden ser recuperados.

- Existen procedimientos efectivos y se siguen para probar periódicamente la efectividad del proceso de restauración y la calidad de los soportes físicos de las copias de seguridad.

- Sólo las personas autorizadas tienen acceso a las copias de seguridad - Los procedimientos de gestión de problemas son efectivos para registrar, analizar, y


Pág. 58 de 61

resolver incidentes, problemas, y errores de sistemas y aplicaciones a tiempo. - Los trabajos de sistema, incluyendo trabajos batch e interfaces, para aplicaciones

relevantes de reporte financiero o datos son procesados a tiempo de una forma completa y precisa.

Tras esto el siguiente paso es identificar los objetivos de control y objetivos de control detallado que deben ser considerados para el modelo de control de interno:

OBJETIVOS DE CONTROL COBIT

Des

arro

llo d

e Pr

ogra

mas

Cam

bio

s a

Progra

mas

Oper

acio

nes

Acc

esos

a Pr

ogra

mas

y d

atos

AI-2 Adquisición y Mantenimiento de Software de Aplicación X X X X AI-3 Adquisición y Mantenimiento de Arquitectura de Tecnología X X X AI-4 Desarrollo y Mantenimiento de Procedimientos relacionados con Tecnología de Información

X X X X

AI-5 Instalación de Sistemas X X X X AI-6 Gestión de Cambios X X ES-1 Definición de Niveles de Servicio X X X X ES-2 Administración de Servicios prestados por Terceros X X X X ES-5 Garantizar la Seguridad de Sistemas X X ES-9 Gestión de la Configuración X X ES-10 Administración de Problemas e Incidencias X ES-11 Gestión de Datos X X ES-13 Gestión de Operaciones X X


Pág. 59 de 61

7 ANEXO - B SIX SIGMA Método que nace en los años ochenta en Motorola, como un programa de reducción radical de defectos en los productos que fabricaba. Pero el fenómeno Six Sigma no llega como tal, hasta mediados de los noventa. Un líder como Jack Welch, entonces máximo ejecutivo de General Electric, adopta Six Sigma como filosofía de gestión, impregna a toda la organización de esta filosofía y “convierte un monstruo en una empresa eficiente”, multiplicando varias veces el valor bursátil de la compañía. Desde su origen, Six-Sigma se puede entender, interpretar y utilizar bajos diferentes perspectivas:

- Es una orientación estratégica, que busca la perfección, ¡o casi!, en los procesos empresariales, asociando la variabilidad de los procesos a la insatisfacción de los clientes y a los costes de la mala calidad.

- Es una manera global de ver los procesos y sus actividades para trabajar mejor

en lugar de trabajar más.

- Es un conjunto de valores que cambia la forma tradicional de comprender y gestionar las organizaciones.

- Es un método estructurado y un conjunto de herramientas para analizar los

procesos e identificar oportunidades para mejorar radicalmente su funcionamiento.

Six-Sigma se basa en una serie de factores clave que permiten conseguir resultados importantes y sostenidos y transformar a la organización que adopta el modelo:

- Orientación al cliente. En Six-Sigma el cliente es lo primero.

- Focalización en procesos. Los esfuerzos de mejora se concentran en el resultado de los procesos.

- Implantación por proyecto, fijando objetivos y beneficios para cada proyecto.

- Medición, rigurosa y sistemática, del rendimiento de los procesos y de su eficacia

y eficiencia a través del coste de la mala calidad. Six-Sigma es un programa en el que participa toda la empresa, desde el vértice hasta la base. Esquemáticamente la organización para implantar Six-Sigma, en la empresa seria:

- La Dirección que selecciona y define los proyectos, garantiza su alineamiento con la estrategia del negocio y se compromete a que dichos proyectos consigan los resultados previstos. A los directivos responsables de los proyectos se les denomina Champions.

- Los especialistas, Master Black Belts, Black Belts y Green Belts, seleccionados

entre los mejores y formados intensamente para que sean capaces de aplicar la metodología Six-Sigma en el desarrollo de los proyectos.


Pág. 60 de 61

- Las personas de la organización, quienes participan colaborando con los

especialistas en el desarrollo de los proyectos. La metodología de mejora de Six-Sigma es conocida como DMAMC por las cinco fases a través de las cuales discurre un proyecto: definir, medir, analizar, mejorar y controlar.

- Definir: el objetivo de esta fase es concretar por qué se realiza el proyecto (prueba de la necesidad), cual es el problema a resolver, qué objetivos se quieren alcanzar, cuáles son los beneficios estimados y quién será el especialista y el equipo que desarrollará el proyecto.

- Medir: el objetivo de esta fase es doble. Por una parte, se trata de identificar y

seleccionar las variables del proyecto que condicionan su resultado, y por otra, evaluar el rendimiento actual del proceso, utilizando para ello datos válidos y expresar dicho rendimiento mediante su valor sigma.

- Analizar: el objetivo final de esta fase es identificar cuáles son las pocas variables

(causas9 que determinan realmente el funcionamiento del proceso y, por tanto, su rendimiento. Esta fase es la que más se apoya en los métodos estadísticos.

- Mejorar, el objetivo es introducir en el proceso los cambios favorables para

mejorar radicalmente su rendimiento.

- Controlar: establecer un método de control del proceso que permita asegurar los resultados obtenidos y mantenerlos en el tiempo.

VISIONPRIORIDAD

CAMINODEFINICIÓN

CO

MU

NIC

AC

IÓN

Y C

OO

RD

INA

CIÓ

N

ALTA DIRECCION

CAMPEÓN DIRECCIONESFUNCIONALES

DIRECTORFINANCIERO

MASTERCINTURÓN NEGRO

ENSEÑARAPOYAR

ASESORAR

MEDICIÓNANALIZARMEJORAR

CONTROLAR

CINTURÓNNEGRO

CINTURÓNNEGRO

CINTURÓNNEGRO

CINTURÓNVERDE

CINTURÓNVERDE

CINTURÓNVERDE

CINTURÓNVERDE

CINTURÓNVERDE

VISIONPRIORIDAD

CAMINODEFINICIÓN

CO

MU

NIC

AC

IÓN

Y C

OO

RD

INA

CIÓ

N

ALTA DIRECCION

CAMPEÓN DIRECCIONESFUNCIONALES

DIRECTORFINANCIERO

MASTERCINTURÓN NEGRO

ENSEÑARAPOYAR

ASESORAR

MEDICIÓNANALIZARMEJORAR

CONTROLAR

CINTURÓNNEGRO

CINTURÓNNEGRO

CINTURÓNNEGRO

CINTURÓNVERDE

CINTURÓNVERDE

CINTURÓNVERDE

CINTURÓNVERDE

CINTURÓNVERDE


Pág. 61 de 61

8 REFERENCIAS

[1] COBIT 3ª Edición - Directrices de Auditoria Governance, Control and Audit for Information and Related Technology

[2] IT Governance and Its Mechanisms

Steven De Haes and Wim Van Grembergen [3] Best Practice For ICT INFRAESTRUCTURE MANAGEMENT

(ITIL the key to Managing IT services) [4] Pathways to Process Maturity: The Personal Software Process and Team

Software Process. Mapping TSP to CMMI Jim McHale Software Engineering Institute Carnegie Mellon University

[5] Using SIX SIGMA to achieve CMMI Levels 4 y 5

CMMI Technology Conference & User Group 17-20 November 2003 Rick Hefner Northrop Grumman

[6] PUBLIC COMPANY ACCOUNTING OVERSIGHT BOARD

- AUDITING STANDARD No. 1 – References In Auditors' Reports To The Standards Of The Public Company Accounting Oversight Board

- AUDITING STANDARD No. 2 – An Audit Of Internal Control Over Financial Reporting Performed In Conjunction With An Audit Of Financial Statements

- AUDITING STANDARD No. 3 – Audit Documentation And Amendment To Interim Auditing Standards

- STAFF QUESTIONS AND ANSWERS. Auditing Internal Control Over Financial Reporting:

June 23, 2004 October 6, 2004 November 22, 2004

[7] ISACA

IT Control Objectives for Sarbanes-Oxley Appendices: Company-level Questionnaire IT Control Objectives

URL http://www.pcaobus.org http://www.isaca.org http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx http://www.sei.cmu.edu/cmmi/ http://www.itil-itsm-world.com/

desarrollo de procesos de gestión de · pdf filecontrol de las operaciones batch. este...

Documents