Tecnología de Información Gerencia de Servicios (Basado en ITIL)

A mis hijos Miguel y Manuel Gracias por su soporte e inspiración en los momentos difíciles. J. Lloréns Fábregas

i

ii

Prefacio

Informática no es un problema técnico…. Es un problema de gerencia. Hasta hace pocos años en los departamentos IBM o de “procesamiento de datos”, como se les solía llamar, la administración de los servicios era bastante simple, sólo teníamos que preocuparnos de guardar ordenadamente unos “decks" de tarjetas perforadas en los que residían los programas o algunos archivos de datos y, en las organizaciones más sofisticadas, guardar ordenadamente unos cuantos carretes de cinta magnética, donde residían los archivos de datos más importantes. Junto con esos elementos, unos instructivos que le indicaban al personal de operación los pasos que debían ejecutarse, completaban el conjunto de componentes necesarios para prestar el servicio requerido por los usuarios, que normalmente se concretaba en un listado o reporte. La tecnología de información, como se le denomina hoy día, ha evolucionado dramáticamente, las facilidades y posibilidades que disponemos en la actualidad eran inimaginables en aquellas épocas; a veces, hasta nosotros mismos nos sorprendemos de las capacidades que nos traen las nuevas tecnologías. A pesar de ello, no es poco frecuente oír a los ejecutivos y usuarios de las empresas quejarse continuamente de los servicios de informática. Siempre se habla de que el departamento de tecnología de información es una especie de caja negra capaz de absorber más y más recursos, sin que la empresa reciba una contraprestación razonable. Del lado de informática también es frecuente oír quejas sobre la cantidad de recursos que se les otorga y del bajo reconocimiento que reciben los denodados esfuerzos que se invierten para brindar un servicio de calidad. Obviamente, los técnicos de tecnología de información no somos ni unos buenos comunicadores, ni unos buenos administradores. Evidentemente, hay que acercar esos dos extremos, especialmente porque la tecnología de información es un arma fundamental para que cualquier empresa pueda competir con éxito en su mercado. Como de iii

costumbre, es más fácil decirlo que hacerlo; sin embargo, al igual que la tecnología, las disciplinas de gerencia de los servicios de tecnología de información han venido evolucionando y madurando significativamente y su inserción metódica en cualquier organización de informática puede significar una contribución importante para que pueda entregarse un servicio de alta calidad, con un costo razonable. En el presente libro nos proponemos discutir sobre ese conjunto de disciplinas de administración de servicios de tecnología de información, no sin antes enfatizar que estas no constituyen una panacea y que su aplicación debe ser realizada desde una comprensión profunda de las verdaderas necesidades de la empresa y de sus objetivos estratégicos y desde un compromiso activo con el logro de dichos objetivos. Como es costumbre, hemos tratado de producir un texto que pueda acompañar a gerentes y administradores de TI en su empeño por ordenar y disciplinar la gestión de servicios, para ello hemos puesto nuestros mejores esfuerzos, esperamos no defraudarlos.

iv

Tecnología de Información Administración de Servicios Índice general Capítulo I Disciplinas de administración de servicios de TI 1. 2. 3. 4. 5. 6. 7. 8.

¿Qué es Gobernanza de TI? ........................................................... 3 La administración de servicios de TI ............................................. 6 ¿Qué es COBIT?............................................................................ 7 ¿Qué es ITIL? ................................................................................ 9 ¿Qué es ISO 20000? .................................................................... 13 ¿Qué es CMM? ............................................................................ 16 ¿Qué es MOF? ............................................................................. 20 Principales disciplinas de administración de TI........................... 21

Capítulo II Centro de atención 1. ¿Qué es un centro de atención a usuarios?................................... 31 1.1. Ventajas................................................................................ 32 1.2. Barreras ................................................................................ 32 2. Modalidades................................................................................. 32 3. Planificación ................................................................................ 33 4. Facilidades ................................................................................... 34 5. Estructura ..................................................................................... 35 6. Actividades .................................................................................. 36 6.1. Atención de llamadas ........................................................... 36 6.2. Cierre del reporte ................................................................. 37 6.3. Manejo desde inicio hasta cierre .......................................... 40 6.4. Centro de información ......................................................... 40 6.5. Actividades adicionales........................................................ 41 7. Evaluación de la disciplina .......................................................... 41

v

Capítulo III Manejo de Incidentes 1. ¿En qué consiste el manejo de incidentes?................................... 45 1.1. Ventajas................................................................................ 47 1.2. Barreras ................................................................................ 47 2. Requerimientos ............................................................................ 48 3. Clasificación de los incidentes ..................................................... 48 4. Escalamiento y soporte ................................................................ 50 5. Actividades................................................................................... 50 5.1. Registro de incidentes .......................................................... 51 5.2. Clasificación de los incidentes ............................................. 47 5.3. Análisis, Resolución y Cierre de Incidentes......................... 52 6. Evaluación de la disciplina........................................................... 53

Capítulo IV Manejo de problemas 1. ¿En qué consiste el manejo de problemas? ................................. 57 1.1. 1Ventajas.............................................................................. 58 1.2. Barreras ................................................................................ 59 2. Actividades................................................................................... 59 2.1. Control de problemas ........................................................... 60 2.2. Control de errores................................................................. 63 2.3. Revisión de post implementación y cierre ........................... 64 3. Evaluación de la disciplina........................................................... 64 4. Ejemplo ........................................................................................ 65

Capítulo V Administración de Configuraciones 1. ¿En qué consiste la administración de configuraciones? ............. 69 1.1. Ventajas................................................................................ 70 1.2. Barreras ................................................................................ 70 2. Terminología................................................................................ 71 2.1. Ítems de configuración ......................................................... 71 2.2. Base de datos de configuraciones......................................... 72 2.3. Línea base de configuración................................................. 72 2.4. Sistema de administración de configuraciones. ................... 72 vi

2.5. Ambientes operacionales ..................................................... 73 3. Proceso......................................................................................... 75 3.1. Planificación ........................................................................ 76 3.2. Clasificación y Registro ....................................................... 77 3.3. Alcance ................................................................................ 77 3.4. Nivel de detalle y Profundidad............................................. 78 3.5. Nomenclatura....................................................................... 78 3.6. Control ................................................................................. 79 3.7. Auditorías............................................................................. 79 4. Evaluación de la disciplina .......................................................... 80

Capítulo VI Administración de versiones 1. ¿En qué consiste la administración de versiones? ....................... 83 1.1. Ventajas................................................................................ 85 1.2. Barreras ................................................................................ 85 2. Consideraciones de tipo práctico ................................................. 86 2.1. Tipos de versiones................................................................ 86 2.2. Actualización y custodia de componentes ........................... 87 2.3. Versiones anteriores............................................................. 88 2.4. Nomenclatura de versiones .................................................. 88 2.5. Estatus de una versión.......................................................... 89 3. Actividades de administración de versiones ................................ 89 3.1. Planificación ........................................................................ 90 3.2. Verificación de cumplimiento de estándares ....................... 91 3.3. Verificación de cumplimiento de pruebas............................ 91 4. Implementación ........................................................................... 93 5. Soporte inicial .............................................................................. 94 6. Evaluación de la disciplina .......................................................... 94

Capítulo VII Administración de cambios 1. ¿En qué consiste la administración de cambios? ......................... 97 1.1. Ventajas................................................................................ 98 1.2. Barreras ................................................................................ 98 2. Elementos .................................................................................... 99 3. Roles ............................................................................................ 99 vii

4. Actividades................................................................................. 100 4.1. Registrar ............................................................................. 101 4.2. Aceptación de la solicitud .................................................. 102 4.3. Clasificación....................................................................... 102 5. Aprobación y Planificación........................................................ 104 6. Implementación.......................................................................... 105 7. Evaluación.................................................................................. 106 8. Evaluación de la disciplina......................................................... 106

Capítulo VIII Monitorización y control 1. ¿En qué consiste monitorización y control?............................... 111 1.1. Ventajas.............................................................................. 113 1.2. Barreras .............................................................................. 114 2. Ciclo de monitorización ............................................................. 114 3. Terminología.............................................................................. 115 4. Herramientas .............................................................................. 116 5. Niveles de monitorización.......................................................... 117 6. Formas de monitorización.......................................................... 118 7. Implementación de la disciplina................................................. 119 8. Evaluación de la disciplina......................................................... 119

Capítulo IX Administración de niveles de servicio 1. ¿En qué consiste la administración de niveles de servicio? ....... 123 1.1. Ventajas.............................................................................. 124 1.2. Barreras .............................................................................. 125 2. Terminología.............................................................................. 125 2.1. Proveedores, clientes y usuarios......................................... 125 2.2. Catálogo de servicios ......................................................... 126 2.3. Acuerdo de nivel de servicio .............................................. 127 2.4. Acuerdo de nivel operacional ............................................ 127 2.5. Programa de calidad de servicio......................................... 127 3. Creación del catálogo de servicios ............................................. 128 4. Proceso ....................................................................................... 130 4.1. Preparación......................................................................... 130 4.2. Seguimiento........................................................................ 131 viii

4.3. Revisión continua............................................................... 132 5. Evaluación de la disciplina ........................................................ 132

Capítulo X Administración Financiera de TI 1. ¿En qué consiste la administración financiera de TI?................ 137 1.1. Ventajas.............................................................................. 138 1.2. Barreras .............................................................................. 138 2. Terminología.............................................................................. 138 2.1. Costos y gastos................................................................... 139 2.2. Depreciación y amortización ............................................. 141 3. Planificación .............................................................................. 142 3.1. Catálogo de servicios ......................................................... 143 3.2. Costeo de servicios ............................................................ 144 3.3. Proyectos............................................................................ 145 3.4. Costeo de proyectos ........................................................... 145 4. Elaboración del presupuesto ...................................................... 146 5. Contabilidad............................................................................... 147 6. Actividades de la administración financiera de TI .................... 148 7. Evaluación de la disciplina ........................................................ 150

Capítulo XI Administración de la capacidad 1. ¿Qué es administración de la capacidad?................................... 155 1.1. Ventajas.............................................................................. 157 1.2. Barreras .............................................................................. 157 2. Actividades ................................................................................ 158 2.1. Plan de Capacidad.............................................................. 159 2.2. Estimación.......................................................................... 160 2.3. Asignación de recursos ...................................................... 160 2.4. Monitorización................................................................... 161 3. Administración de la demanda .................................................. 161 4. Evaluación de la disciplina ........................................................ 162

ix

Capítulo XII Continuidad de los servicios de TI 1. ¿Qué es administración de la continuidad? ................................ 167 1.1. Ventajas.............................................................................. 169 1.2. Barreras .............................................................................. 169 2. El plan de continuidad del negocio - (BCP)............................... 170 3. Terminología.............................................................................. 172 4. Preparación................................................................................. 173 4.1. Evaluación de riesgos......................................................... 173 4.2. Identificar procesos críticos ............................................... 173 4.3. Selección de estrategias de recuperación ........................... 174 5. Alcance de la continuidad de servicios ...................................... 175 6. Organización y planificación ..................................................... 177 6.1. Plan de mitigación de riesgos............................................. 177 6.2. Plan de manejo de emergencias ......................................... 177 6.3. Plan de recuperación .......................................................... 178 7. Continuidad de servicios en el día a día..................................... 178 7.1. Adiestramiento ................................................................... 179 7.2. Actualización...................................................................... 179 8. Evaluación de la disciplina......................................................... 180

Capítulo XIII Administración de la disponibilidad 1. ¿Qué es administración de la disponibilidad? ............................ 183 1.1. Cálculo de la disponibilidad ............................................... 185 1.2. Ventajas.............................................................................. 185 1.3. Barreras .............................................................................. 186 2. Requerimientos de disponibilidad.............................................. 186 3. Plan de disponibilidad ................................................................ 187 4. Monitorización de la disponibilidad........................................... 187 5. Mediciones ................................................................................. 189 6. Evaluación de la disciplina......................................................... 189

x

Capítulo XIV Seguridad de la información 1. ¿En qué consiste la administración de seguridad? ..................... 193 1.1. Ventajas.............................................................................. 194 1.2. Barreras .............................................................................. 195 2. La seguridad en el nivel de la empresa ...................................... 195 3. Actividades ................................................................................ 197 4. Políticas de seguridad ............................................................... 198 5. El plan de seguridad................................................................... 198 6. Cumplimiento de la normativa de seguridad ............................. 199 7. Evaluación y mantenimiento ..................................................... 200 8. Evaluación de la disciplina ........................................................ 201

Capítulo XV Medición 1. ¿En qué consiste la medición de los servicios de TI? ................ 205 1.1. ¿Por qué medir? ................................................................. 206 1.2. ¿Qué debemos medir?........................................................ 206 1.3. ¿Quiénes participan en la medición? ................................. 207 1.4. Criterios para definir indicadores....................................... 207 1.5. Interpretación de indicadores ............................................. 208 2. Uso de los indicadores ............................................................... 208 3. Algunos indicadores o mediciones ............................................ 209 Anexo I -

Implantación de las Disciplinas de Administración de Servicios de TI............................................................ 213 Anexo II - COBIT - Procesos de TI ............................................. 217 Anexo III - COBIT - Relaciones de los Objetivos de Control ...... 219 Bibliografía ..................................................................................... 235

xi

xii

Capítulo I

Disc iplina s de Adm inist ra c ión de Se rvic ios de T I

Capítulo I

Disciplinas de administración de servicios de TI Tabla de contenido 1.2.3.4.5.6.7.8.-

2

¿Qué es Gobernanza de TI? .......................................................... 3 La administración de servicios de TI ............................................ 6 ¿Qué es COBIT?........................................................................... 7 ¿Qué es ITIL? ............................................................................... 9 ¿Qué es ISO 20000? ................................................................... 13 ¿Qué es CMM? ........................................................................... 17 ¿Qué es MOF? ............................................................................ 20 Principales disciplinas de administración de TI ......................... 21

Disciplinas de administración de servicios de TI


1.- ¿Qué es Gobernanza de TI? 1.1.-

Gobernanza Empresarial

El diccionario de la real academia española define el término gobernanza como: 1. Arte o manera de gobernar que se propone como objetivo el logro de un desarrollo económico, social e institucional duradero, promoviendo un sano equilibrio entre el Estado, la sociedad civil y el mercado de la economía. 2. Acción y efecto de gobernar o gobernarse. En el año 2002, los temas de gobernanza corporativa y control tomaron un fuerte impulso como producto de los escándalos financieros que llevaron al colapso a importantes corporaciones –como la petrolera ENRON- y que demostraron la necesidad de nuevas regulaciones para fortalecer la gobernanza corporativa en Europa y Estados Unidos. El Banco Internacional de Pagos (Bank of Internacional Settlements) de Basilea – Suiza, creado en 1930, es actualmente el principal centro para la cooperación internacional de bancos centrales y supervisores bancarios. En el año 1974, estableció un comité de supervisión bancaria encargado de generar los estándares mínimos para los países miembros del grupo de los diez –el G10-. Este comité, si bien no posee ninguna autoridad de supervisión sobre los países miembros y sus conclusiones no tienen ninguna fuerza legal, ha formulado una serie principios y estándares de supervisión bancaria, que han sido acogidos no sólo por los países miembros del G10, sino por la mayoría de los países del mundo. En Junio de 2004, el comité de supervisión bancaria de Basilea publicó el documento conocido como Basilea II, que es el segundo de los acuerdos de Basilea, que pasó a constituirse como un estándar internacional y es una referencia para todos los reguladores bancarios. En sus documentos, el Banco Internacional de Pagos de Basilea establece la siguiente definición para gobernanza: 3

Capítulo I

“Gobernanza corporativa es un conjunto de relaciones entre la gerencia de la organización, la junta directiva, los accionistas y otros grupos de interés. La gobernanza corporativa provee la estructura a través de la cual se fijan los objetivos de la organización y los medios para alcanzarlos, así como también, se determinan los mecanismos de medición del desempeño. Una buena gobernanza corporativa debe incentivar apropiadamente a la junta directiva y a la gerencia a perseguir objetivos que estén en el interés de la empresa y sus accionistas y debe facilitar el monitoreo efectivo, estimulando, de esta forma, a las empresas a utilizar los recursos más eficientemente.” Vemos pues, que la gobernanza corporativa incluye la distribución de derechos y responsabilidades de los participantes en una corporación, tales como directores, gerentes, accionistas y otras partes involucradas o interesadas –stakeholders-, estableciendo claramente las reglas y procedimientos para la toma de decisiones en los asuntos corporativos. Si bien el foco de la gobernanza corporativa está en las finanzas y las auditorías, también incluye otras funciones corporativas como tecnología de información, recursos humanos y cumplimiento de requerimientos ambientales. Resumiendo, podemos definir la gobernanza empresarial o corporativa como el conjunto de prácticas y responsabilidades cumplidas por la dirección ejecutiva de una empresa, con el fin de: • Proporcionar dirección estratégica • • •

Asegurar de que los objetivos se cumplen Comprobar que los riesgos se administran adecuadamente Verificar que los recursos de la organización se utilizan adecuadamente Es importante visualizar la diferencia entre gobernanza empresarial y gestión o administración; podemos decir que la gobernanza empresarial establece el ambiente donde los gerentes pueden actuar. Mientras que la administración incluye las actividades de • • • • 4

Definir normas y formas de comportamiento Rendir cuentas Velar por una utilización adecuada de los recursos Definir de un ciclo de regulación en sus procesos


•

Establecer una cartera de proyectos

•

Responder a las exigencias tanto del gobierno, como de los usuarios. La gobernanza, por el contrario, incluye las actividades de: • Establecer orientación y direccionamiento • Establecer un marco general para decidir • Establecer una definición de valores y principios • Promover ciclos de regulación y adaptación • Dictar lineamientos estratégicos y tácticos • •

Responder a las exigencias de la sociedad y de los accionistas. Mirar al futuro y visualizar nuevas oportunidades

1.2.- Gobernanza de TI Dentro del nuevo concepto de gobernanza corporativa o gobernanza empresarial, se hizo lógico plantearse que los controles establecidos sobre la función de tecnología de información deben estar en un nivel adecuado, puesto que TI es fundamental para el cumplimiento de los procesos del negocio. La gobernanza de TI no es una disciplina aislada, sino que es una parte integral de la gobernanza empresarial o corporativa y tiene como propósito: establecer el liderazgo, las estructuras organizativas y los procesos necesarios para asegurar que la TI apoye el logro de los objetivos y las estrategias de la empresa. La gobernanza de las tecnologías de información y comunicaciones constituye una responsabilidad tanto de la gerencia técnica, como de la directiva de la empresa y puede decirse que: • Establece la estructura que vincula procesos, recursos e información de TI con las estrategias y objetivos de la compañía. • Integra e institucionaliza las mejores prácticas de planificación y organización, de adquisición e implementación, de entrega y soporte y de monitorización del desempeño de la función de TI. Obviamente, este nuevo concepto de gobernanza de TI requiere la existencia de normas y estándares de uso, por lo que, en el tiempo, han ido apareciendo varios, entre los cuales debemos mencionar: • ITIL (Information Technology Infrastructure Library- Biblioteca de infraestructura de tecnología de información) 5

Capítulo I

•

COBIT (Control Objectives for Information and related Technology – Objetivos de control para la información y la tecnología relacionada) • CMM(Capability Maturity Model – Modelo de madurez de la capacidad) • ITSEC(Information Technology Security Evaluation CriteriaCriterios de evaluación de seguridad de la tecnologñia de información) • Microsoft Operations Framework -basado en ITIL-. Cada uno de esos estándares, han hecho enormes contribuciones a la gobernanza de TI, dentro de su nivel de especialización, haciendo que, hoy día, el desafío de la gerencia de TI sea hallar la mejor forma de utilizarlos, combinándolos inteligentemente y aprovechándolos al máximo.

2.- La administración de servicios de TI Observamos en el punto anterior que la gobernanza de TI enfatiza la importancia de la gestión de servicios de TI, en términos de alinear el soporte a los procesos del negocio, mejorar la calidad de los servicios, reducir los costos de los servicios, reducir el tiempo de entrega y reducir los riesgos de TI. En efecto, la tecnología de información constituye un elemento de apoyo fundamental de cualquier empresa, para lograr su funcionamiento eficiente y para materializar y cumplir sus objetivos estratégicos, por lo que, dada esta dependencia, se hace imprescindible que los servicios de tecnología de información operen en forma eficaz y eficiente y para ello es necesario incorporar y aplicar los conocimientos que conforman las mejores prácticas en el área de gestión de servicios de TI. El gran desafío que enfrentan los profesionales de la informática es alinear los servicios de TI con las necesidades del negocio, con eficiencia y dentro de una relación costo / beneficio razonable. Todos los esquemas que se han desarrollado y que citamos en el punto anterior -ITIL, COBIT, CMM, ITSEC, MOF- constituyen un marco de referencia para organizar el funcionamiento de los procesos de administración de servicios de TI, todos ellos adoptan un conjunto de mejores prácticas recogidas por diferentes organizaciones, que se complementan para describir las disciplinas que permiten administrar eficaz y eficientemente los servicios de TI, optimizando sus beneficios y 6


garantizando la integración de éstos a la cadena de valor de las unidades de negocio. Centenares de organizaciones en el mundo aplican esos marcos de trabajo, puesto que han sido desarrollados tomando en cuenta la dependencia creciente que tienen las empresas modernas en la tecnología, para alcanzar sus objetivos y, porque, además, permiten definir procedimientos que hagan más eficiente la administración de los servicios de TI, estableciendo orden y un esquema de trabajo comunes. Es oportuno señalar, sin embargo, que ninguno de estos marcos de trabajo constituye una solución por si mismo, pues para lograr sus objetivos, es necesario adaptarlos a cada empresa en particular e insertarlos en las operaciones diarias de TI, desarrollando los procedimientos y el personal de soporte capaz de aplicarlos y ponerlos en práctica.

3.- ¿Qué es COBIT? La Asociación para el Control y Auditoría de los Sistemas de Información (Information Systems Audit and Control Association1) y el Instituto de Gobernanza de TI (IT Governance Institute2) son las principales organizaciones que han desarrollado COBIT (Control Objectives for Information and related Technology - Objetivos de control para la información y la tecnología relacionada), con el fin de ser empleado no solamente por los auditores de una empresa, sino también como una guía integral para lo que se denomina los “dueños de proceso” y para la gerencia de las empresas. La dinámica de los negocios requiere, cada vez más, la autonomía de los dueños de proceso, de tal forma que puedan asumir la responsabilidad total de todos aspectos del proceso que les corresponde y, a su vez, ello requiere que se establezcan controles adecuados. Con esa finalidad, COBIT se ha desarrollado como una herramienta para el dueño de proceso del negocio, facilitándole el cumplimiento de esas responsabilidades. 1

Inicialmente fundada como una asociación de auditores -EDP Auditors Association- en 1967, hoy día ISACA tiene más de 65 mil miembros en unos 140 países, incluyendo una variedad de profesionales relacionados con TI, como auditores de sistemas, consultores, profesionales de seguridad de TI, reguladores, gerentes de TI, etc. Actualmente existen alrededor de 170 capítulos de ISACA alrededor del mundo.

2

El ITGI, instituto afiliado a ISACA, fue creado en los Estados Unidos, el año 1998, reconociendo la importancia que, para las empresas, tiene la función de TI. 7

Capítulo I

COBIT establece un marco de trabajo que parte de una premisa muy simple y práctica: “el dueño de un proceso y la organización requieren información para alcanzar sus objetivos, por ello los recursos de TI deben ser manejados por un conjunto de procesos estructurados adecuadamente”. El marco de COBIT establece un sistema que incluye 34 objetivos de control de alto nivel, uno para cada uno de los procesos de TI, agrupados en cuatro dominios: planificación y organización adquisición e implantación entrega y soporte seguimiento o monitorización. Esta estructura cubre todos los aspectos de la información de una empresa y de la tecnología que la soporta y estos 34 objetivos de control permiten que el dueño de un proceso de negocio pueda asegurarse que se esté ejerciendo un control adecuado sobre la función de TI. Además, correspondiendo a cada uno de los 34 controles de alto nivel, COBIT incluye una guía para auditar, que permite revisar la función de TI contra unos 318 objetivos detallados de control, lo cual, a su vez, permite ayudar a la gerencia a verificar su cumplimiento o determinar las mejoras que requieren los procesos para lograrlo. De más reciente desarrollo son las pautas para la gerencia de COBIT, que permiten que la gerencia de la empresa pueda manejar con mayor eficacia las necesidades y los requerimientos de la gobernanza de TI. Tales pautas para la gerencia de COBIT son genéricas y orientadas a la acción, con el fin de dar respuesta a preguntas como las siguientes: • ¿Qué tan lejos debemos ir? • ¿Está justificado el costo por los beneficios? • ¿Cuáles son los indicadores de buen funcionamiento? • ¿Cuáles son los factores críticos del éxito? • ¿Cuáles son los riesgos de no alcanzar nuestros objetivos? • ¿Qué hacen otras empresas? • ¿Cómo medirnos y compararnos? COBIT también incluye:

8


•

•

Modelos de madurez, para que la gerencia de una organización pueda tener control sobre los procesos de TI, estableciendo las brechas entre lo que se tiene en el presente y lo que debiera ser. Un conjunto de indicadores que permitan establecer si los procesos de TI alcanzan sus objetivos de soporte al negocio y si se están cumpliendo con eficiencia.

•

Un sistema de herramientas para llevar COBIT a la práctica, basadas en las lecciones aprendidas por las organizaciones que lo han hecho en el pasado. Para resumir, podemos decir que COBIT ha sido diseñado como una herramienta que permite que los directivos de una empresa cumplan una eficaz y eficiente gobernanza de TI y que comprendan los riesgos y beneficios asociados a la tecnología de información.

4.- ¿Qué es ITIL? La Biblioteca de Infraestructura de Tecnología de Información (Information Technology Infrastructure Library - ITIL) fue desarrollada por la dependencia gubernamental del Reino Unido, denominada Office of Goverment Comerce (OGC) -Oficina Gubernamental de Comercio-, hacia finales de 1980. En esta librería se recogieron las mejores experiencias en el manejo de los servicios de tecnología de información, para uso del gobierno del Reino Unido. Hoy día, ITIL se ha convertido en un estándar de facto para la gestión de los servicios de informática, pues ha demostrado ser de gran utilidad en muchas organizaciones, como base para organizar y desarrollar los servicios de TI. ITIL ofrece un enfoque sistemático para la prestación de servicios de tecnología de información con alta calidad, por lo que las empresas modernas, que dependen cada vez más de esa tecnología, adoptan con gran interés el conjunto de disciplinas de servicio que presenta ITIL, con el fin de que sus servicios de TI realmente apoyen el logro de sus objetivos y constituyan el respaldo que requiere la eficiencia de sus operaciones. Si observamos que la fase de desarrollo e implantación, dentro del ciclo de vida de los productos y servicios de tecnología de información, constituye sólo el 30% de los costos y el tiempo, mientras que la fase de operación de esos servicios ocupa el 70 %, es fácil explicarse la importancia que tiene la administración eficiente de esos servicios.

9

Capítulo I

4.1.- Los procesos de ITIL ITIL fue publicado originalmente a fines de 1980, constaba de 10 libros y cubría las áreas de Soporte de Servicios y Prestación de Servicios. Con los años, ITIL se ha ido convirtiendo en algo más que una serie de libros sobre los servicios de tecnología de información. Los libros originales se fueron expandiendo y se le fueron añadiendo libros complementarios que cubrían una numerosa variedad de temas, desde el cableado hasta la gestión de la continuidad del negocio. A partir del año 2000, la OCG acometió una revisión de la biblioteca, con la participación de consultores, especialistas y proveedores de tecnología de información, creándose una nueva versión que facilitó el acceso a la información necesaria para administrar los servicios. En esa nueva versión, los libros se agruparon en dos áreas: soporte de servicios y prestación de servicios. En esas dos grandes áreas, se agruparon diversos procesos íntimamente interrelacionados: • Procesos de soporte Escritorio de servicios (Service Desk). Administración de la Configuración (Configuration Management). Administración de Incidentes (Incident Management). Administración de Problemas (Problem Management). Administración de Cambios (Change Management). Administración de la Distribución (Release Management). • Procesos de entrega de servicios Administración de la Capacidad (Capacity Management). Administración de la Disponibilidad (Availability Management). Administración de la Continuidad (Continuity Management). Administración Financiera (Financial Management). Administración del Nivel de Servicio (Service Level Management).

10


4.2.- ITIL versión 3 La más reciente versión de ITIL –versión 3- desarrollada el año 2006, ha ampliado significativamente el alcance de ITIL, presentando una organización diferente e introduciendo el concepto del ciclo de vida de los servicios. La versión 3 de ITIL incluye los siguientes 5 libros, para cada fase del ciclo de vida: 1. Estrategias de Servicios (Service Strategies) En esta fase se analizan y comprenden los planes del negocio, para traducirlos en estrategias de TI que permiten planificar la gestión de servicios de TI. 2. Diseño de Servicios (Service Design) En esta fase se diseñan nuevos servicios o se modifican para ser introducidos en un ambiente de producción. Esto es, incluye el desarrollo de nuevos servicios y sus procesos relacionados, así como la modificación de servicios existentes. 3. Transición de Servicios (Service Transition) En esta fase se crean las estrategias de transición y puesta en producción de los servicios nuevos o modificados. 4. Operación de Servicios (Service Operations) En esta fase se cumplen las actividades y procesos requeridos para que los usuarios del negocio reciban los servicios con el nivel de calidad requerido. 5. Mejora Continua de Servicios (Continuous Service Improvement CSI) Esta fase centra su atención en la medición y el análisis de los procesos, con el fin de establecer un adecuado ciclo de mejora permanente sobre los servicios existentes. En estas fases del ciclo de vida de los servicios se agrupan las funciones y procesos de la siguiente forma: 1. Funciones y procesos en la fase de estrategia de servicios 1.1. Administración financiera (Financial Management) 1.2. Administración de la cartera de servicios (Service Portafolio Management -SPM) 1.3. Administración de la demanda (Demand Management)

11

Capítulo I

2. Funciones y procesos en la fase de diseño de servicios 2.1. Administración del catálogo de servicios (Service Catalogue Management) 2.2. Administración de niveles de servicio (Service Level Management) 2.3. Administración de la capacidad (Capacity Management) 2.4. Administración de la disponibilidad (Availability Management) 2.5. Administración de la continuidad de servicios de TI (IT Service Continuity Management) 2.6. Administración de la seguridad de información (Information Security Management ) 2.7. Administración de proveedores (Supplier Management ) 3. Funciones y procesos en la fase de transición de servicios 3.1. Planificación de la transición y soporte (Transition Planning and Support ) 3.2. Administración de cambios (Change Management) 3.3. Administración de la configuración (Service Asset and Configuration Management) 3.4. Administración de versiones y su implantación (Release and Deployment Management) 3.5. Validación y prueba de servicios (Service Validation and Testing) 3.6. Evaluación (Evaluation) 3.7. Administración del conocimiento (Knowledge Management) 4. Funciones y procesos en la fase de operación de servicios 4.1. Administración de eventos (Event Management) 4.2. Administración de Incidentes (Incident Management) 4.3. Atención de requerimietos (Request Fulfillment) 4.4. Administración de problemas (Problem Management) 4.5. Administración de acceso (Access Management) 4.6. Monitorización y control (Monitoring and Control) 4.7. Operaciones de TI (IT Operations) 4.8. Escritorio de servicios (Service Desk)

12


5. Funciones y procesos en la fase de mejora continua de servicios 5.1. Mejora continua de procesos (CS improvement Process) 5.2. Reporte de servicios (Service Reporting)

5.- ¿Qué es ISO 20000? Con el éxito de ITIL, en año 1991 la organización BSI -British Standards- promovió la creación de estándares y normas específicas para tecnología de información y publicó la BS-15000, que con el tiempo ha dado lugar a las normas ISO 20000, que se han establecido como estándar internacional para la gestión de servicios de tecnología de información. ISO 20000, publicado en Marzo de 2006, se basa en dos documentos, BS15000-1 y BS15000-2, publicados en 2002 y 2003 respectivamente, y que, a su vez, fueron precedidos por una versión inicial de BS15000-1, publicada en el año 2000. Hoy día, el estándar contiene dos partes: ISO/IEC 20000-1 e ISO/IEC 20000-2. La primera parte, ISO 20000-1, es la especificación de la gestión de servicios y la segunda parte, ISO 20000-2, contiene la descripción de las “mejores prácticas” en materia de gestión de servicios de TI. Los objetivos de la norma ISO 20000 se podrían definir de la siguiente forma: • Promover la adopción de procesos integrados para suministrar los servicios de TI. • Medir la comprensión y aplicación de las “buenas prácticas”. • Ayudar a las organizaciones a generar servicios de calidad dentro de un marco de eficiencia. Se estima que la norma ISO 20000 será una norma de enorme éxito en los años venideros, pues: • Las empresas dependen cada vez más de sus sistemas de TI y requieren una gestión eficaz y eficiente. • Las fallas e incidentes cada vez impactan más a las empresas, por lo que se requiere un sistema de gerencia capaz de manejarlos adecuadamente. • Las infraestructuras de TI son cada vez más complejas y se requiere que sean operadas y administradas eficientemente. • Poseer la certificación ISO 20000 será una ventaja competitiva y una referencia positiva muy valorada por los clientes. 13

Capítulo I

El portal de la GSTI, ISO 20000 Central -puede ser visitado en la dirección internet http://20000.fwtk.org/- ha identificado que la implementación de las normas ISO 20000 puede derivar beneficios e introducir mejoras tales como: • La alineación de los servicios de TI con la estrategia del negocio • La creación de un marco formal para los proyectos de mejora de los servicios • La provisión de un marco de comparación con las mejores prácticas • La creación de una ventaja competitiva por medio de la prestación de servicios consistentes y económicamente eficaces • La creación de una cultura proactiva, debido a la fijación de propietarios y responsables de los procesos a todos los niveles • La reducción de los riesgos y, por lo tanto, reducción de los costos en términos de la recepción externa de los servicios • La simplificación en la introducción de cambios organizacionales importantes por medio de la creación de un enfoque consistente y normalizado • La mejora en la reputación y percepción • El cambio de procesos reactivos a procesos proactivos • La mejora en las relaciones ínter departamentales por medio de una mejor definición de responsabilidades y objetivos A pesar de que entre ITIL e ISO 20000 existe una gran interrelación, puede observarse que existen importantes diferencias: • •

•

• • 14

ISO 20000 es certificable; ITIL no, son sólo unas “buenas prácticas”. Para certificar ISO 20000 no es necesario implantar ITIL, pero su utilización puede hacer el sistema más robusto y más sencillo el cumplimiento de la normativa ISO 20000. La estructuración de la organización no es un requisito de ISO 20000 mientras que la adopción de PDCA (Plan, Do, Check, Act) es fundamental. ISO 20000 incluye relaciones y control de proveedores y subcontratistas. El Plan de Continuidad de Negocio no es obligatorio en ITIL.


•

ITIL cubre la gestión financiera mientras que ISO 20000 cubre presupuestos y contabilidad. • ISO 20000 incluye requerimientos de Seguridad de la Información (ISO 27001). Resumiendo, podemos afirmar que uno de los objetivos fundamentales del modelo ITIL y, por tanto, de las normas ISO 20000 es estimular la mejora continua de la calidad en la gestión de los servicios de TI. Dentro de las normas ISO 20000, se considera la aplicación del modelo de mejora permanente de la calidad PDCA, conocido como “Círculo de Deming” o esquema de “Plan-Do-Check-Act”. Este esquema, originalmente definido por Walter A. Shewhart3 fue desarrollado y aplicado posteriormente por W. Edward Deming4 en sus trabajos sobre Calidad Total. El Ciclo PDCA básico consiste en una serie de cuatro pasos que se llevan a cabo consecutivamente: 1. P: PLAN (Planear): establecer los planes. 2. D: DO (Hacer): llevar a cabo los planes. 3. C: CHECK (Verificar): verificar si los resultados concuerdan con lo planeado. 4. A: ACT (Actuar): actuar para corregir los problemas encontrados. Un factor importante para lograr esta mejora continua es realizar comprobaciones periódicas de la calidad de gestión de los servicios de TI. En tal sentido, la ISO 20000 proporciona una forma de verificar el comportamiento de una organización en relación con el objetivo de seguir mejorando la calidad de los servicios. En ISO 20000, el servicio de TI se divide en 7 subprocesos integrados: 1. Servicios de entrega y soporte Incluye los servicios que proporciona la organización TI para apoyar adecuadamente las funciones del negocio y satisfacer las necesidades de sus clientes y usuarios: administración de niveles de servicio, administración de la continuidad y 3

W. A. Shewhart es conocido como el padre del control estadístico de calidad

4

W. Edward Deming, profesor de estadística, fundador de la Calidad Total 15

Capítulo I

2.

3.

4.

5.

6.

7.

16

disponibilidad, administración de la capacidad, administración del presupuesto, manejo de incidentes y de problemas. Servicios de planificación para implementación Incluye los servicios que la organización de TI planifica para implementar o actualizar los servicios: administración de cambios, administración de la entrega de servicio y administración de implantación. Administración de Seguridad Incluye los controles de seguridad que se implementan y mantienen para mitigar el impacto y reducir la posibilidad de incidentes en relación con el almacenamiento, transmisión y proceso de la información. Perspectiva de negocio Se centra en los principios y requerimientos clave de la organización y operación del negocio: administración de relaciones de negocio, administración de proveedores y administración de niveles de servicio. Administración de resolución Incluye los servicios que se prestan para minimizar los trastornos al negocio, mediante la detección y análisis proactivo de causas y definición de acciones para mejorar: manejo de incidentes, manejo de problemas, administración de cambios, administración de configuración e informes de servicio. Administración de proceso de control Se centra en la administración de cambios y configuración de servicios para dar soporte al negocio: administración de la configuración, administración de cambios, manejo de incidentes y manejo de problemas. Administración de implantación Se centra en la puesta en marcha de servicios, sistemas, programas y equipos nuevos o modificados.


6.- ¿Qué es CMM? El Modelo de Madurez de la Capacidad (CMM - Capacity Maturity Model) fue desarrollado en 1986 por el Instituto de Ingeniería de Sistemas (SEI) de la universidad Carnegie Mellon. Este modelo describe un marco de referencia para el desarrollo y mantenimiento de software en las organizaciones, así como para la adquisición de software. CMM constituye un modelo en el que el mejoramiento de los procesos de software se implementa incrementalmente. El modelo CMM puede ser adaptado y moldeado a cualquier organización en particular, dentro del marco de los procedimientos que establece. El modelo CMM se centra en el concepto de madurez de los procesos, concepto que define como el grado de definición de los procesos y el grado de cumplimiento de los mismos en el manejo de los proyectos de software. En nuestro medio, esos procesos se suelen englobar dentro del término de metodología de desarrollo y mantenimiento de sistemas; por lo que podríamos afirmar que la madurez está determinada por el nivel de claridad y precisión en la definición de la metodología y en el grado de compromiso que existe dentro de la organización para cumplirla, utilizarla para establecer los productos o entregables y ajustar los planes, de tal manera que los proyecto sea controlables. En el año 2002, el CMM fue reemplazado por una nueva versión, Integración de Modelos de la Madurez de las Capacidades (Capacity Maturity Model Integration). Al igual que para CMM, la principal premisa de CMMI es que “La calidad de un producto la determina de manera importante la calidad del proceso que se sigue para desarrollarlo y mantenerlo” Hoy día, CMMI es un modelo de referencia sobre buenas prácticas maduras, consolidadas, y probadas para el desarrollo y mantenimiento de productos y servicios, cubriendo todo el ciclo de vida, desde la concepción hasta la instalación y mantenimiento. Integra la Ingeniería de Software, la Ingeniería de Sistemas y la Adquisición de Productos y Servicios. CMMI es: • Un guía para mejorar los procesos y comprobar la capacidad de un grupo al ejecutarlos • Un modelo de madurez, esto es, de directrices, prácticas y disciplinas basadas en las mejores prácticas de la industria. 17

Capítulo I

•

Un marco de referencia para calificar y diagnosticar el progreso de una organización. • Indica qué deben hacer los procesos, no cómo deben hacerlo. CMMI no es: • Una metodología de desarrollo o dirección de proyectos. • NO compite con metodologías de desarrollo como RUP, TOGAF, etc. • NO compite con PMBOK del PMI ni con PRINCE 2 u otras disciplinas de administración de proyectos • No es un estándar de procesos. CMMI, en muchas empresas se complementa con otros modelos, como los que arriba hemos citado.

6.1.- Niveles en CMMI El modelo CMMI establece varias etapas dentro de la evolución de los procesos de desarrollo y mantenimiento de software: 1. Inicial: Las organizaciones que están en esta etapa, se caracterizan por tener procesos desorganizados, poco predecibles y que no pueden ser controlados adecuadamente. Los procedimientos, cuando existen, se abandonan en momentos de crisis y no hay la capacidad para derivar experiencias y repetir los procesos que hayan resultado exitosos. El éxito de los proyectos depende casi exclusivamente de las capacidades individuales 2. Gestionado: En esta etapa, las organizaciones utilizan la ingeniería de software para establecer los procesos básicos de dirección de proyectos, para planificar, para controlar los costos y asegurar la calidad de los productos. Entre las disciplinas que se aplican en esta etapa están: Administración de requerimientos Planificación de proyectos Seguimiento y control de proyectos Administración de acuerdos con proveedores Aseguramiento de la calidad de procesos y productos 18


Administración de la configuración 3. Definido: En esta etapa las organizaciones han definido y documentado los estándares y procedimientos de desarrollo y mantenimiento y, adicionalmente, todos los proyectos siguen un proceso estándar para desarrollar y mantener software. En esta etapa se añaden diferentes disciplinas como: Desarrollo de requerimientos Integración de productos Verificación Validación Administración integrada de proyectos Administración de riesgos Administración integrada de proveedores 4. Cuantitativamente Gestionado: En esta etapa, adicionalmente a las definiciones realizadas en la etapa anterior, los productos y las actividades se miden y evalúan cuantitativamente. Se mide la calidad y la efectividad del proceso, a través de criterios cuantitativos, y se verifica el cumplimiento de los objetivos de negocio En esta etapa se añaden diferentes disciplinas como: Medición del desempeño de los procesos en la organización Administración cuantitativa de proyectos 5. En Optimización: Esta etapa se caracteriza por la mejoría cuantificable y continua de las prácticas de desarrollo y mantenimiento, mediante la retroalimentación de las mediciones y la realización de proyectos piloto destinados a evaluar nuevas ideas y tecnologías. En esta etapa se añaden diferentes disciplinas como: Innovación y despliegue organizativo Análisis causal Las claves para implementar exitosamente CMMI son: Involucrar a los ejecutivos de la empresa

19

Capítulo I

No perder de vista los objetivos de negocio y revisarlos periódicamente Aprovechar estas iniciativas para mejorar realmente los procesos Involucrar a los afectados por el proceso Hacerlos partícipes de las decisiones Crear una cultura de mejora Definir procedimientos simples y útiles, que aporten verdadero valor a la gente que los usa Aprovechar prácticas que sabemos que funcionan para nosotros Educación y formación Sesiones de formación, tanto formales como informales Considerar las nuevas capacidades y los conocimientos que serán requeridos. Comunicación interna y externa Buscar el apoyo de consultores y otros grupos de la organización Cumplir un plan de comunicación

7.- ¿Qué es MOF? El marco de operaciones de Microsoft (Microsoft Operations Framework - MOF) es un conjunto de prácticas recomendadas por Microsoft, a partir de las cuales se pueden diseñar los procedimientos, controles y funciones necesarios para que la infraestructura de TI pueda ser administrada con eficacia. MOF está basado en la Biblioteca de infraestructuras de TI (ITIL) y está orientada a la plataforma de Microsoft. MOF ofrece directrices sobre la forma de planificar, implementar y mantener los procesos operativos de TI que respaldan las soluciones de servicio críticas. MOF es un modelo genérico y, por este motivo, debe adaptar muchas de las recomendaciones para usarlas en una empresa en particular.

20


MOF es un modelo estructurado y flexible que está basado en lo siguiente: •

Los equipos de consultoría y soporte técnico de Microsoft y sus experiencias de trabajo con clientes empresariales y socios, además de grupos internos de operaciones de TI en Microsoft. • La Biblioteca de infraestructuras de TI (ITIL), que describe los procesos y las prácticas recomendadas necesarios para el suministro de soluciones de servicio críticas. • ISO/IEC 15504, de la Organización Internacional de Normalización (ISO), que proporciona un enfoque normalizado para evaluar la madurez del proceso de software. Los detalles que integran el marco MOF pueden obtenerse en forma gratuita en la siguiente dirección de internet: https://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx

8.- Principales disciplinas de administración de TI La administración de servicios de TI consiste en la administración de todos los componentes de la infraestructura de una organización e incluye las tareas administrativas diarias, planificadas y a solicitud, necesarias para que el sistema de TI funcione correctamente.

Todas las tareas de administración de operaciones se deben describir mediante procedimientos escritos, con el fin de que todos los empleados 21

Capítulo I

de soporte sigan los mismos métodos, utilicen las herramientas convenientemente y cumplan con los estándares. Independientemente del marco de referencia que se utilice, puede decirse que el conjunto de disciplinas de administración de servicios de tecnología de información está conformado por las siguientes: 1. Centro de atención 2. Manejo de incidentes 3. Manejo de problemas 4. Administración de la configuración 5. Administración de versiones 6. Administración de cambios 7. Monitorización y control 8. Administración de niveles de servicio 9. Administración financiera de los servicios TI 10. Administración de la capacidad 11. Administración de la continuidad de los servicios TI 12. Administración de la disponibilidad 13. Administración de la seguridad de información Es muy importante destacar que la mayoría de las disciplinas mencionadas no podrá ser implementada correctamente si no se cuenta con el apoyo de las herramientas adecuadas, especialmente las disciplinas de centro de atención, administración de configuraciones y monitorización y control. Afortunadamente en el mercado existe una amplia oferta de paquetes de software de gran calidad, que ofrecen diferentes capacidades y facilidades. Entre ellos, podemos citar los siguientes: • Tívoli de la empresa IBM • Unicenter y otros productos de la empresa Computer Associates • Vantage y otros productos de la empresa Compuware • HP Service Management Center • • • • 22

HP OpenView Patrol y otros productos de la empresa BMC LANDesk Software Axios Systems


•

OpTier's CoreFirst

8.1.- Centro de atención El centro de atención a los usuarios constituye el centro de las comunicaciones de los usuarios con la función de TI, por lo que es el punto más crítico en la construcción de una buena relación con el cliente. El objetivo principal de un centro de atención es servir como punto de contacto entre los usuarios y la gerencia de servicios TI. En su concepción más moderna, también debe funcionar como punto de enlace de todos los procesos destinados a dar soporte al usuario: • Registrando y haciendo seguimiento de todas las llamadas recibidas de los usuarios. • Aplicando soluciones temporales a los errores conocidos, integrándose, de esta forma, con la disciplina de manejo de incidentes. • Tramitando los cambios solicitados por los usuarios, mediante peticiones de servicio, integrándose, de esta forma, con las disciplinas de administración de cambios y de versiones.

8.2.- Manejo de incidentes Es la disciplina orientada a la restauración rápida del servicio, clasificando los incidentes y haciendo seguimiento de la solución de los incidentes. El manejo de incidentes guarda una estrecha relación con la disciplina de manejo de problemas, pero a diferencia de ésta, no se ocupa de analizar e identificar las causas que puedan haber causado un determinado incidente, sino que, como ya apuntáramos, centra su atención exclusivamente en restaurar el servicio. Establece la forma de: • Identificar • Analizar • • •

Corregir Hacer seguimiento Recuperar la operación normal

23

Capítulo I

8.3.- Manejo de problemas Es la disciplina orientada a la prevención y solución de los problemas que presenten los servicios de TI, controlando los problemas y errores, y actuando proactivamente ante los estos. Incluye Políticas y Procedimientos de: • Detección • Registro • Seguimiento

8.4.- Administración de la configuración Esta disciplina tiene como objetivo controlar los activos de TI: • Manteniendo un control detallado de todos los componentes de la infraestructura TI, tanto hardware como software, almacenando esa información en una base de datos de configuración – inventario de hardware y software-. • Suministrando información actualizada sobre la configuración de la infraestructura de TI, para el cumplimiento de los diferentes procesos de administración de servicios.

8.5.- Administración de versiones La administración de versiones es la disciplina que centra su atención en la implementación y en el control de calidad de todo el software y hardware instalado o a ser instalado en el ambiente de producción. La administración de versiones se integra con las disciplinas de administración de cambios y de configuraciones, para asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la base de datos de administración de configuraciones, de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI.

8.6.- Administración de cambios Dentro del ámbito de TI el cambio es constante: nuevas aplicaciones, cambios en las aplicaciones, entonación de sistemas, crecimiento, actualización tecnológica, corrección de problemas, prevención de problemas, cambios por requerimientos legales, cambios por requerimientos del negocio. 24


Esta disciplina tiene como objetivos: • Evaluar el impacto (consecuencias) de un cambio • Asegurar la participación coordinada de todas las unidades afectadas por un cambio • Evitar cualquier posible falla en la implantación • Prevenir interrupciones en el servicio como consecuencia de un cambio Establece los procedimientos para: • Solicitar e informar un cambio • Evaluar el impacto y categorizar los cambios (urgentes, de menor impacto, severos, etc.) • Justificar y aprobar • Coordinar • Implantar • Controlar la calidad

8.7.- Monitorización y control Se entiende como monitorización a la observación continua del comportamiento de los elementos que integran la infraestructura tecnológica, a los fines de detectar cualquier cambio en ese comportamiento. Esta disciplina tiene como objetivos: • Mantener un seguimiento del funcionamiento de los diferentes componentes de la infraestructura tecnológica. • Reportar los cambios que se identifiquen en ese funcionamiento, con el fin de que puedan iniciarse las acciones correctivas que pudiesen ser necesarias.

8.8.- Administración de niveles de servicio Esta disciplina tiene como objetivos: • Definir el nivel de calidad del servicio que requiere cada usuario • Crear compromisos formales o acuerdos de servicio suscritos conjuntamente con los usuarios. • Controlar el cumplimiento de los compromisos •

Incluye procedimientos para: 25

Capítulo I

•

•

• •

Negociar y establecer el nivel de calidad para los servicios que requiere cada usuario, dentro del marco de las prioridades del negocio y de las capacidades del centro de computación. Desglosar dichos servicios en niveles mesurables y cuantificables (oportunidad de los resultados, disponibilidad de la aplicación, tiempos de respuesta, período de proceso, horario de proceso, etc.). Determinar los factores que favorecen o desfavorecen los niveles de servicio. Hacer seguimiento al cumplimiento de los niveles de servicio prestados.

8.9.- Administración financiera de los servicios TI Esta disciplina permite tener una correcta comprensión de los costos de los servicios de TI y facilita la: • • •

Elaboración de presupuestos Identificación de elementos de costo y sus categorías Estimación y seguimiento de los costos

8.10.- Administración de la capacidad Esta disciplina permite asegurar el crecimiento ordenado de la instalación y evitar los problemas que podrían ocasionarse por carencia de los equipos necesarios Incluye procedimientos para: • Definir y cuantificar la carga de trabajo • Evaluar el consumo actual de recursos • •

Pronosticar el crecimiento Justificar la adquisición de nuevos equipos

8.11.- Administración de la continuidad de los servicios TI Esta disciplina permite preparar al centro de computación para garantizar la continuidad de sus operaciones aún cuando alguna catástrofe (como incendio, inundación o terremoto, etc.) haya destruido parcial o totalmente sus instalaciones. La disciplina incluye procedimientos para: • Identificar riesgos 26


•

Identificar aplicaciones críticas

• •

Identificar archivos críticos Identificar componentes críticos de hardware, software y telecomunicaciones Determinar formas alternas de proceso para aplicaciones críticas Definir equipos de contingencia

• • • • • •

Asegurar los respaldos correctos a las bibliotecas y los archivos críticos Almacenar los respaldos fuera de la instalación Trazar los planes de contingencia Probar periódicamente los planes de contingencia (simulacros)

8.12.- Administración de la disponibilidad La administración de la disponibilidad es la disciplina responsable de optimizar y monitorizar los servicios TI, con el fin de que estos funcionen ininterrumpidamente, en forma confiable, cumpliendo los acuerdos de servicio, a un costo razonable. La satisfacción del cliente y la rentabilidad de los servicios TI dependen en gran medida de la efectividad con que se cumpla esta disciplina. Incluye procedimientos para: • Cálculo y monitorización de la disponibilidad • Planificación, monitorización e información

8.13.- Administración de la seguridad de información La administración de la seguridad es la disciplina que vela por la integridad de la información; para que esta sea correcta y completa, esté siempre a disposición de los procesos del negocio y sea utilizada sólo por aquellos funcionarios que tengan autorización para hacerlo.

27

Capítulo I

28

Capítulo II

Ce nt ro de At e nc ión

Capítulo II

Centro de atención Tabla de contenido

1.- ¿Qué es un centro de atención a usuarios? .................................31 1.1.Ventajas .............................................................................32 1.2.Barreras..............................................................................32 2.- Modalidades ...............................................................................32 3.- Planificación ...............................................................................33 4.- Facilidades ..................................................................................34 5.- Estructura....................................................................................35 6.- Actividades .................................................................................36 6.1.Atención de llamadas.........................................................36 6.2.Cierre del reporte ...............................................................37 6.3.Manejo desde inicio hasta cierre........................................40 6.4.Centro de información .......................................................40 6.5.Actividades adicionales .....................................................41 7.- Evaluación de la disciplina .........................................................41

30

Centro de atención

Centro de atención

1.- ¿Qué es un centro de atención a usuarios? El objetivo principal de un centro de atención es servir como punto de contacto entre los usuarios y la gerencia de servicios TI. En su concepción más moderna, también debe funcionar como punto de enlace de todos los procesos destinados a dar soporte al usuario: • Registrando y haciendo seguimiento de todas las llamadas recibidas de los usuarios. • Aplicando soluciones temporales a los errores conocidos, integrándose, de esta forma, con la disciplina de manejo de incidentes. • Tramitando los cambios solicitados por los usuarios, mediante peticiones de servicio, integrándose, de esta forma, con las disciplinas de administración de cambios y de versiones.

31

Capítulo II

Para el buen desenvolvimiento de las operaciones del negocio, es importante que los usuarios perciban que están recibiendo una atención personalizada y ágil: Al solicitar soporte técnico en el uso de los recursos informáticos. En la solución rápida de las fallas y las interrupciones del servicio. Es importante observar que la disciplina de centro de atención también juega un papel importante en el soporte al negocio, pues permite identificar nuevas oportunidades para la gerencia de TI, a través de su contacto con los usuarios.

1.1.- Ventajas Los principales beneficios de la correcta implementación de un centro de atención pueden resumirse en: • Mejor atención al usuario que repercute en un mayor grado de satisfacción. • Identificación de nuevas oportunidades para apoyar al negocio. • •

Centralización de procesos que mejoran la gestión de la información y la comunicación. Soporte diligente al servicio

1.2.- Barreras La implantación de un centro de atención puede tropezar con una serie de barreras como las que a continuación enumeramos: • No se adoptan facilidades adecuadas de comunicación, en calidad y cantidad. •

• •

No se adecuan las facilidades de oficina para que el personal técnico pueda atender con comodidad las llamadas de los usuarios. No se adiestra adecuadamente al personal. No se establecen protocolos de comunicación con los usuarios o no se instruyen adecuadamente al personal.

2.- Modalidades El contacto con el usuario puede adquirir diversas modalidades, dependiendo de la amplitud de los servicios que se piensen ofrecer: • 32

Call center:

Centro de atención

•

•

•

Su objetivo es gestionar un alto volumen de llamadas y dirigir los requerimientos de los usuarios a las unidades de soporte que correspondan, de acuerdo con la naturaleza de la llamada, con la excepción de los casos más triviales. Centro de ayuda (Help Desk): Su principal objetivo es similar al del call center (recibir todas las llamadas e los usuarios), pero adicionalmente, busca ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo posible las interrupciones del servicio y canalizar aquellos requerimientos más complejos hacia las unidades de soporte que correspondan Centro de servicios (Service Desk): Es el centro de comunicación entre usuario y todos los servicios de TI ofrecidos por la organización, pues además de ofrecer los servicios que ofrecen las dos modalidades anteriores, ofrece servicios adicionales a los usuarios y la organización TI, tales como: Supervisar los contratos de mantenimiento. Administrar las licencias de software. Supervisar los acuerdos de servicio con los usuarios. Línea caliente para clientes (Customer Hot Line): Una línea caliente normalmente está dedicada a atender las llamadas de los clientes de la empresa (externos a la organización), para solicitar asistencia o presentar quejas o problemas en relación con los productos o servicios que la empresa mercadea.

3.- Planificación La implementación de un centro de atención requiere una meticulosa planificación. Como primer paso debe establecerse: • ¿Cuáles son las necesidades? • • •

¿Qué tipo de centro se desea? call center, centro de ayuda o centro de servicios. ¿Cuáles serán sus funciones? ¿Quiénes serán los responsables del mismo? 33

Capítulo II

•

¿Qué calificaciones profesionales deberán tener sus integrantes?

•

¿Cómo se prestará el servicio técnico? ¿con personal y recursos propios o utilizando un proveedor de este tipo de servicios? ¿Qué estructura queremos darle al centro de atención? ¿centralizado o descentralizado? ¿En qué horarios deberá funcionar el centro de servicios?

• • • •

¿Qué herramientas tecnológicas de apoyo se requieren? ¿Qué métricas serán utilizadas para evaluar el desempeño del centro de atención? Adicionalmente, será muy importante preparar charlas, cursos y guías de trabajo para el personal, de tal forma que en todo momento se establezca una interacción respetuosa y amable con el cliente (usuario). Recíprocamente, será siempre importante desarrollar material de divulgación para los usuarios, de tal forma que estos conozcan cómo operará el centro y qué deben esperar de este servicio. Un activo muy importante para un centro de atención serán los protocolos de comunicación con los usuarios, que facilite la identificación de los problemas, su posible solución y la ruta que debe seguir si el problema requiere ser escalado hacia otros grupos de soporte. Será también fundamental establecer los procedimientos de seguimiento a las llamadas que se transfieran a otras instancias de soporte, con el fin de asegurar que cualquier llamada que haya recibido el centro sea atendida adecuada y rápidamente.

4.- Facilidades Hoy día existen innumerables facilidades para que un centro de atención pueda funcionar eficientemente: 1. Dispositivos de comunicación, como los ACD (automatic call distribution), que permiten administrar eficientemente el flujo de las llamadas y su atención ordenada, o como las facilidades de correo de voz. 2. Paquetes de software que permiten apoyar la operación de un centro de atención. Estos paquetes ofrecen facilidades para registrar cada llamada recibida y dejar la huella de todas las acciones tomadas, hasta el momento de su cierre, en que el usuario exprese su aceptación de la solución recibida, lo cual permite que los supervisores del centro de atención puedan hacer seguimiento de los 34

Centro de atención

problemas reportados que aun no hayan recibido una solución definitiva. Estos paquetes de software, normalmente asociados al tipo de sistemas que se denominan de CRM (Customer Records Management), también incluyen facilidades para que, a través de la disciplina de administración de la configuración, se actualice el inventario de hardware y software, para que, de esta forma, el técnico del centro de atención, al atender una llamada de un usuario, puede consultar al sistema y conocer todo el software y los dispositivos que ese usuario pueda tener instalados en su estación de trabajo. 3. Facilidades para prestar soporte de forma remota. Aunque el usuario esté en una localidad lejana, el técnico de soporte, con la autorización del usuario, puede tomar control de la estación de trabajo del usuario y aplicar los correctivos que pudieran ser necesarios. En general, la meta debe ser implantar un centro de servicios dotado de herramientas y gobernados con procedimientos que le permitan alinearse con los procesos de negocio, mejoren la satisfacción de los clientes (usuarios), optimicen la imagen externa de la organización de TI y se constituyan en una fuente de información para identificar nuevas oportunidades de servicio y formas de mejorarlo.

5.- Estructura Como arriba señaláramos, el centro de atención es el punto de contacto central de toda la organización TI con sus clientes y usuarios. Por tal razón es imprescindible que: • Sea fácilmente accesible. • •

Ofrezca un servicio de calidad, consistente y homogéneo. Informe a los usuarios (dar un “feed back” adecuado) y lleve un registro de toda la interacción con los mismos. • Acumule experiencias, para atender con mayor eficacia los casos similares que puedan presentarse en el futuro Para cumplir estos objetivos es necesario implementar una adecuada estructura organizativa y de procedimientos; así mismo, los integrantes del centro de servicios deben: • Conocer todos los protocolos de interacción con el cliente: guiones, listas de chequeo, etc. • Disponer de herramientas de software que les permitan llevar un registro de la interacción con los usuarios. 35

Capítulo II

• •

Estar informados acerca de los criterios para escalar a instancias superiores. Tener acceso rápido a las bases de datos de inventario de hardware y software, así como a las bases de conocimiento (lecciones aprendidas), para ofrecer un mejor servicio a los usuarios.

•

Recibir entrenamiento continuo sobre los productos y las facilidades instalados en la empresa. Dependiendo de las características de la empresa y del servicio que se desee brindar, el centro de atención puede tener un perfil organizativo diferente: centralizado, descentralizado o mixto. Todo ello dependerá de: • Si los usuarios se encuentran en diversas localidades geográficos • Si están involucrados diferentes idiomas, productos y servicios. • •

Si los usuarios trabajan en diferentes horarios. Si se necesita dar algunos de los servicios de mantenimiento o atención en el lugar donde esté el usuario. La estructura centralizada es la estructura más común, aun para empresas que, como los bancos, tienen usuarios dispersos en diferentes localidades. Las ventajas son obvias, pues pueden aprovecharse mejor los recursos humanos y resulta mucho más fácil mantenerlo actualizado. Hoy día, dadas las grandes capacidades de los canales de comunicación, existe una tendencia creciente a tercerizar (outsorcing) parte de los servicios de soporte, dejando principalmente en la empresa las funciones de monitorización y medición de los servicios prestados por el proveedor, así como la supervisión de los contratos de mantenimiento y niveles de servicio y la administración de las licencias de software.

6.- Actividades 6.1.- Atención de llamadas Como puede verse en las gráficas que se muestran en las páginas siguientes, las principales actividades que cumple un centro de atención son: 1. Recibir las llamadas de los usuarios y registrarlas en la base de datos. 2. Asignar un código identificador a cada llamada registrada. Este código se acostumbra a informárselo al usuario, con el fin de que, en caso de cualquier reclamo u observación, se haga referencia al mismo. 36

Centro de atención

3. Revisar la base de datos de configuraciones, con el fin de conocer en detalle los componentes que el usuario tiene instalados en su estación de trabajo. 4. Siguiendo los protocolos establecidos para ello, solicitar al usuario toda la información posible sobre el problema o la falla que reporta, con el fin de poder encontrar la solución adecuada. 5. Si se estima que el problema puede estar en la estación de trabajo, tratar de guiar al usuario telefónicamente, para que el mismo resuelva la falla. 6. En caso de que no sea posible, tomar el control de la estación de trabajo del usuario y aplicar los correctivos que puedan ser necesarios. Existen instalaciones en las que no se utilizan estas facilidades y en su lugar la acción alternativa es enviar a un técnico de soporte, para que aplique directamente en la estación de trabajo, los correctivos que puedan ser necesarios. 7. En caso de fallas que no son de la estación de trabajo o que no pueden ser corregidas por el técnico del centro de atención, se procede a escalar el reporte a otras instancias, como técnicos de soporte o analistas de sistemas, dejando registrado el problema en la base de datos, con el estatus de pendiente.

6.2.- Cierre del reporte Una de las tareas centrales de la disciplina es hacer el seguimiento de los reportes que están pendientes, de tal forma que ninguno pueda quedar desatendido. Una vez que una falla reportada ha sido resuelta, se deberá cambiar el estatus del reporte en la base de datos, de pendiente a resuelta. El supervisor del centro de atención se encargará de verificar con el usuario que los problemas que se han reportado como resueltos, lo haya sido a su entera satisfacción. En caso afirmativo, el supervisor cambiará el estatus en la base de datos, de resuelto a cerrado. En caso negativo, el supervisor acordará con los técnicos correspondientes las acciones que deben ser tomadas y reversará el estatus del reporte, de resuelta a pendiente con alta prioridad.

37

Capítulo II

38

Centro de atención

39

Capítulo II

6.3.- Manejo desde inicio hasta cierre Independientemente de que la solución de los problemas que le hayan sido reportados requiera la atención de otros departamentos y personal, el centro de atención debe ofrecer una primera línea de soporte para la solución de las fallas, interrupciones de servicio o solicitudes de servicio que puedan presentar los clientes y usuarios. Entre sus tareas específicas se incluyen: • • •

Registrar cada incidente o requerimiento y hacer seguimiento al progreso de su solución. Seguimiento de los requerimientos escalados. Cierre del incidente y confirmación con el cliente.

6.4.- Centro de información El centro de atención debe ser la principal fuente de información de los clientes y usuarios, informando sobre nuevos servicios y el lanzamiento de nuevas versiones para la corrección de errores. Este contacto directo con los clientes debe servir también para identificar nuevas oportunidades de servicio, evaluar las necesidades de los clientes y su grado de satisfacción con el servicio prestado. El centro de atención se encuentra en una situación inmejorable para ofrecer también información privilegiada a todos los procesos de gestión

40

Centro de atención

de los servicios TI. Para ello es imprescindible que se lleve un registro minucioso de toda la interacción con los usuarios y clientes.

6.5.- Actividades adicionales En algunas empresas, el centro de atención también es responsable de la relación con algunos proveedores de servicios y de productos de hardware y software, por lo que es fundamental que mantenga una estrecha relación con los representantes y responsables externos de su mantenimiento.

7.- Evaluación de la disciplina La mejor medida del éxito de un centro de atención es la satisfacción del cliente, aunque ésta, obviamente, no sea responsabilidad exclusiva del centro. Es importante establecer métricas simples y bien definidas que permitan medir y calificar el desempeño del centro de atención, tales como: • Tiempo promedio de respuesta a las solicitudes recibidas a través de los diferentes medios de comunicación (teléfono, correo electrónico, correo de voz, fax, etc.) • Porcentaje de incidentes que se cierran en primera línea de soporte. • Porcentaje de consultas respondidas en primera instancia. • Análisis estadísticos de los tiempos de resolución de incidentes organizados según su urgencia e impacto. • Número y porcentaje de llamadas escaladas a otras instancias de soporte. • Grado de satisfacción de usuarios y/o clientes, que puede determinarse mediante encuestas periódicas, que permitan cuantificar la percepción del usuario con respecto a los servicios recibidos.

41

Capítulo II

42

Capítulo III

Manejo de Incidentes

Capítulo III

Manejo de Incidentes Tabla de contenido 1.- ¿En qué consiste el manejo de incidentes? .................................45 1.1.Ventajas .............................................................................47 1.2.Barreras..............................................................................47 2.- Requerimientos...........................................................................48 3.- Clasificación de los incidentes ...................................................48 4.- Escalamiento y soporte...............................................................49 5.- Actividades .................................................................................50 5.1.Registro de incidentes ........................................................50 5.2.Clasificación de los incidentes...........................................51 5.3.Análisis, Resolución y Cierre de Incidentes ......................52 6.- Evaluación de la disciplina .........................................................53

44



1.- ¿En qué consiste el manejo de incidentes? Un incidente es cualquier interrupción no planeada de cualquier servicio de TI y la disciplina de manejo de incidentes busca restaurar ese servicio de la manera más rápida y eficaz posible. El manejo de incidentes guarda una estrecha relación con la disciplina de manejo de problemas, pero a diferencia de ésta, no se ocupa de analizar e identificar las causas que puedan haber causado un determinado incidente, sino que, como ya apuntáramos, centra su atención exclusivamente en restaurar el servicio. Es claro, sin embargo, que si bien son diferentes, guardan una estrecha interrelación.

45

Capítulo III

En líneas generales, los objetivos del manejo de incidentes son: • Detectar cualquiera alteración en los servicios TI. • Registrar y clasificar esas alteraciones. • Asignar el personal encargado de restaurar el servicio. Es importante destacar que el cumplimiento de las actividades de esta disciplina requiere un estrecho contacto con los usuarios, por lo que la coordinación con el centro de atención juega un papel esencial en su desarrollo.

Normalmente, el concepto de incidente se asocia con algún funcionamiento inadecuado de los componentes de hardware o software; sin embargo, en ITIL se define como un incidente a “Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”. Casi cualquier llamada que recibe el centro de atención puede clasificarse como un incidente, incluyendo las solicitudes de servicio tales como mudanza de equipos, solicitud de nuevas licencias, etc. 46


siempre que la solicitud corresponda a uno de los servicios que se consideren estándar de la organización. Cualquier cambio que deba ser aplicado en cualquier elemento de de la infraestructura de TI requiere la elaboración de una solicitud de cambio que deberá ser tratada según los procedimientos de la administración de cambios.

1.1.- Ventajas Las principales ventajas de una adecuada implementación de la disciplina de manejo de incidentes son: • Se mejora la productividad de los usuarios. • Se vela por el cumplimiento de los niveles de servicio acordados con los usuarios. • Se optimiza la utilización de los recursos disponibles. • Se dispone de una base de datos de incidentes precisa, con los incidentes relacionados a cada uno de los componentes de la infraestructura. • Se puede lograr una mayor satisfacción de los usuarios y clientes. Por el contrario, la carencia de un adecuado manejo de incidentes puede significar: • Un deterioro de los niveles de servicio. • •

•

Utilización ineficiente de los recursos. Pérdida de información valiosa información sobre las causas y efectos de los incidentes para poder mejorar la infraestructura de TI. Proliferación de clientes y usuarios insatisfechos por la mala y/o lenta atención de sus incidentes.

1.2.- Barreras Entre las principales barreras con que tropieza la implantación de una disciplina manejo de incidentes pueden citarse las siguientes: • No se siguen los procedimientos previstos. • Se resuelven los incidentes sin registrarlos adecuadamente. • Los incidentes se escalan innecesariamente. • No están bien definidos los niveles de calidad de servicio ni los productos soportados, lo que puede provocar que se atiendan

47

Capítulo III

incidentes que no corresponden a los servicios estándar o que no han sido acordados previamente con el cliente.

2.- Requerimientos El manejo de incidentes requiere de una infraestructura que facilite su correcta implementación. Entre los elementos necesarios cabe destacar los siguientes: • El sistema de registro de incidentes, para ser compartido con la disciplina de centro de atención. • Una base de conocimiento, que permita comparar los nuevos incidentes que se reportan, con incidentes ya resueltos en el pasado, con el fin de: Evitar transferir innecesariamente los incidentes que se reciban. Convertir el conocimiento –know how- de los técnicos en un activo duradero para la empresa. Poner directamente a disposición del cliente parte o la totalidad de estos conocimientos en forma de “preguntas frecuentes” –FAQs- en la intranet para los usuarios internos de la empresa o en la extranet para los clientes, con el fin de que en algunas oportunidades sea el propio usuario quien aplique el correctivo, sin necesidad de notificar el incidente. • Una base de datos del hardware y software instalado, que permita conocer todas las configuraciones actuales y el impacto que éstas puedan tener en la resolución del incidente.

3.- Clasificación de los incidentes Es frecuente que se presenten múltiples incidentes concurrentemente, por lo que es necesario determinar la prioridad para atender la resolución de los mismos y asignar los recursos para atender los incidentes de mayor prioridad. El nivel de prioridad debe basarse en dos parámetros esenciales: • Impacto El impacto de un incidente está determinado por la forma cómo éste afecta los procesos de negocio o por la cantidad de usuarios afectados. • Urgencia 48


La urgencia de un incidente depende del tiempo máximo de que el usuario o el cliente puede esperar para la resolución del incidente, sin que la operación de su área del negocio sufra consecuencias importantes. La urgencia también depende de los niveles de servicio que hayan sido acordados con el usuario o cliente. Para la clasificación de un incidente, además de los parámetros arriba citados, también se hace necesario tomar en cuenta factores como el tiempo de resolución esperado y los recursos necesarios para atender el incidente. Así pues, aunque en algunos casos no sean de mayor prioridad, los incidentes “sencillos” se tramitarán cuanto antes. Es conveniente establecer criterios claros para establecer, en primera instancia, la prioridad del incidente; el “diagrama de prioridades” que se muestra en la gráfica es un ejemplo de cómo pueden establecerse esos criterios.

4.- Escalamiento y soporte Es frecuente que el centro de atención no tenga la capacidad de resolver en primera instancia un incidente, por lo que debe recurrir a un especialista o a algún superior que pueda tomar decisiones que escapan de su responsabilidad. A este proceso se le denomina escalar un incidente. 49

Capítulo III

Básicamente hay dos formas de escalar incidentes: • Funcional: Se requiere el apoyo de un especialista de más alto nivel para atender el incidente. • Jerárquico: Se acude a un superior, de mayor autoridad, para tomar decisiones que escapan de las atribuciones del primer nivel, como por ejemplo, asignar más recursos para la atención de un incidente específico.

5.- Actividades Las actividades que se cumplen en el proceso de atención de incidentes son: 1. Registro de incidentes 2. Clasificación de los incidentes 3. Análisis, Resolución y Cierre de Incidentes

5.1.- Registro de incidentes La admisión y registro del incidente es el primer paso para una correcta gestión del mismo. Los incidentes pueden provenir de diversas fuentes tales como usuarios, de la gestión de aplicaciones, del mismo centro atención o de soporte técnico, entre otros. Inmediatamente debe realizarse el proceso de registro, pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevos incidentes demore indefinidamente el proceso de registro. En el proceso de registrar un incidente, se cumplen las siguientes tareas: • Al realizarse la admisión del incidente en el centro de atención debe evaluarse en primera instancia si el servicio está incluido en los acuerdos de servicio establecidos con el usuario o el cliente. En caso de que no fuese así, el requerimiento deberá referirse a una autoridad competente. • Debe comprobarse que el incidente no haya sido registrado, pues es común que varios usuarios notifiquen un mismo incidente. • Debe asignarse un número de referencia al incidente, que lo identificará tanto para los procesos internos, como para las comunicaciones con el usuario o cliente.

50


•

•

•

Se completará el registro inicial, introduciendo en la base de datos la información básica necesaria para la atención del incidente (hora, descripción del incidente, sistemas afectados...). Deberá incluirse cualquier información de apoyo que sea relevante para la resolución del incidente, que puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia base de datos de hardware y software. Se notificará el incidente a todos los usuarios que puedan resultar afectados por el incidente, con el fin de que conozcan cómo esta incidencia puede afectar su flujo normal de trabajo.

5.2.- Clasificación de los incidentes La clasificación de un incidente tiene como objetivo principal recopilar toda la información que pueda ser de utilidad para la resolución del mismo, para ello debe incluir las siguientes tareas: • Categorización: La categorización de un incidente, como su nombre lo indica, consiste en la asignación de una categoría, dependiendo de los servicios afectados o del grupo de trabajo responsable de su resolución. La categoría de un incidente permite identificar los servicios afectados por el incidente. • Asignación de prioridad: La asignación del nivel de prioridad, de acuerdo con el impacto y la urgencia y según los criterios que hayan sido preestablecidos. • Asignación de recursos: En los casos en que el centro de atención no puede resolver el incidente en primera instancia, se deberá transferir al grupo de soporte técnico que corresponda y deberá designarse el personal que deberá atenderlo -segundo nivel-. • Seguimiento: El supervisor del centro de atención hará seguimiento del progreso o estatus del incidente, así como del tiempo de respuesta esperado. Normalmente los estatus de un incidente pueden ser: registrado, en progreso, suspendido, escalado a nivel siguiente, resuelto y cerrado.

51

Capítulo III

El tiempo de resolución del incidente corresponderá a los acuerdos de servicio que se hayan establecidos con los usuarios o clientes y a la prioridad que se haya asignado.

5.3.- Análisis, Resolución y Cierre de Incidentes En primera instancia se examina el incidente con ayuda de la base de datos donde se acumulan y organizan las lecciones aprendidas –base de conocimiento-, para determinar si se puede identificar algún incidente ya resuelto y aplicar la solución ya conocida.

Si la resolución del incidente escapa a las posibilidades del centro de atención, éste lo transferirá a un segundo nivel, para su investigación por los expertos que se asignen. Si estos expertos logran atender el incidente se seguirán los procedimientos para escalar incidentes que se hayan preestablecido. Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que el personal involucrado en un incidente y su solución dispongan de información actualizada sobre el estatus del mismo -registrado, en progreso, suspendido, escalado a nivel siguiente, resuelto o cerrado-.

52


Existen casos en que para aplicar las medidas que permitan reanudar el servicio será necesario producir una solicitud de cambio, que normalmente corresponderá a un cambio urgente. Cuando se haya solucionado un incidente se deberá: • Cotejar con los usuarios que la solución ha sido satisfactoria. • •

Incorporar las lecciones aprendidas en la base de conocimientos. Cerrar el incidente -colocarlo en estatus cerrado-.

6.- Evaluación de la disciplina Para evaluar el desempeño de la disciplina de manejo de incidentes, será importante generar periódicamente diferentes reportes y generar información para otras disciplinas como: • Administración de Niveles de Servicio Será fundamental que usuarios y los clientes dispongan de información puntual sobre el cumplimiento de los niveles servicio acordados y de las medidas correctivas que deberán tomarse, en caso de incumplimiento. •

•

•

•

Seguimiento del desempeño del centro de servicio Para conocer el grado de satisfacción de los usuarios y clientes por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte. Optimización de la asignación de recursos Todos los administradores de servicios deben saber si los procedimientos para escalar incidentes se han cumplido adecuadamente y si se han evitado duplicidades en el proceso de atención de incidentes. Identificación de deficiencias en los procedimientos Sobre todo en sus etapas iniciales, los procedimientos podrían tener deficiencias que no les permitan adecuarse a la estructura de la organización o las necesidades de los usuarios o clientes, por lo que se deban tomar medidas corregirlos. Acumulación de Información Estadística La información que se acumula en el proceso de manejo de incidentes puede ser utilizada para que la gerencia de

53

Capítulo III

servicios de TI haga proyecciones sobre requerimientos de recursos, costos asociados al servicio, etc. Para la evaluación del desempeño de la disciplina será necesario establecer diferentes métricas, tomando en cuenta variables como las siguientes: • Número de incidentes por categorías y prioridades. • Tiempos de resolución clasificados de acuerdo al impacto y a la urgencia de los incidentes. • Porcentaje de incidentes, clasificados por impacto y prioridad, que han sido resueltos en primera instancia por el centro de atención. • Costos asociados a la disciplina. • Uso de los recursos disponibles en el centro de atención. • Grado de satisfacción de usuarios y/o clientes, que puede determinarse mediante encuestas periódicas, que permitan cuantificar la percepción del usuario con respecto a los servicios recibidos.

54

Capítulo IV

M a ne jo de Proble m a s

Capítulo IV

Manejo de problemas Tabla de contenido 1.1.1.1.2.2.2.1.2.2.2.3.3.4.-

56

¿En qué consiste el manejo de problemas? ...........................57 Ventajas .............................................................................58 Barreras..............................................................................59 Actividades.............................................................................59 Control de problemas.........................................................60 Control de errores ..............................................................63 Revisión de post implementación y cierre .........................64 Evaluación de la disciplina.....................................................64 Ejemplo ..................................................................................65

Manejo de problemas

Manejo de problemas

1.- ¿En qué consiste el manejo de problemas? Las funciones principales del manejo de problemas son: • Investigar las causas de cualquier alteración, real o potencial, del servicio de TI. • Determinar posibles soluciones a tales alteraciones. • Proponer las solicitudes de cambio (RFC) necesarias para asegurar la calidad de la implantación de las soluciones. • Realizar revisiones post implementación (PIR) para asegurar que los cambios han surtido los efectos buscados, sin crear problemas secundarios. El manejo de problemas puede ser: • Reactivo: Analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos. • Proactivo: Evalúa y hace seguimiento a la calidad de la infraestructura TI y analiza su configuración, con el objetivo de prevenir incidentes antes de que estos puedan ocurrir. Tal como se discutía en el capítulo de administración de incidentes, esa disciplina tiene como objetivo restablecer lo más rápidamente los servicios, sin contemplar las acciones que puedan ser necesarias para determinar las causas que hayan generado el incidente. Cuando algún tipo de incidente se convierte en recurrente o tiene un fuerte impacto en la infraestructura TI, la disciplina de manejo de problemas incluye las actividades necesarias para determinar las causas y encontrar las posibles soluciones. Para los efectos de la disciplina de manejo de problemas, es necesario diferenciar entre: •

Problema: Causa aun no identificada de una serie de incidentes o de un incidente aislado pero de importancia significativa. 57

Capítulo IV

•

Error conocido: Un problema pasa a ser un error conocido cuando se han determinado sus causas.

1.1.- Ventajas Los principales beneficios de un adecuado manejo de problemas son: • Cumplimiento de los niveles de servicio acordados con los usuarios. • Optimización de los recursos disponibles. • Mayor satisfacción general de usuarios y clientes. Recíprocamente, la carencia de un adecuado manejo de problemas puede significar: • Un deterioro de los niveles de servicio. • Utilización ineficiente de los recursos. • Repetición continua de fallas similares • Proliferación de clientes y usuarios insatisfechos por la repetición de fallas similares.

58

Manejo de problemas

1.2.- Barreras Entre las principales barreras con que tropieza la implantación de una disciplina manejo de problemas pueden citarse las siguientes: • No se siguen los procedimientos previstos. • Se posterga la adopción de soluciones. • •

Se resuelven los problemas sin registrarlos adecuadamente. Personal técnico insuficiente.

2.- Actividades

Las principales actividades del manejo de problemas son: 1. Control de Problemas: En esta actividad se registran y clasifican los problemas, para determinar sus causas y convertirlos en errores conocidos. 2. Control de Errores: En esta actividad se registran los errores conocidos y se proponen soluciones a los mismos mediante solicitudes de cambio que son procesadas de acuerdo con los procedimientos establecidos para la administración de cambios. 3. Revisión de postimplantación: En esta actividad se efectúa la revisión de los cambios implementados para corregir los errores conocidos, en conjunción con la disciplina de administración de cambios.

59

Capítulo IV

4.

Detección de problemas Opcionalmente, si la estructura de la organización lo ha establecido, en esta actividad se desarrolla un manejo de problemas proactivo, en conjunción con la disciplina de monitorización y control, que permita a detectar problemas antes de que estos se manifiesten y puedan causar un deterioro en la calidad del servicio.

2.1.- Control de problemas Tal como señalamos en el párrafo precedente, el principal objetivo de la actividad de control de problemas es lograr que estos se conviertan en errores conocidos para que en la actividad de control de errores puedan proponerse las soluciones correspondientes. El control de problemas, a su vez, se cumple en tres actividades: 1. Identificación y registro 2. Clasificación y asignación de recursos 3. Análisis y diagnóstico: error conocido 60

Manejo de problemas

2.1.1.- Identificación y registro Una de las tareas principales del manejo de problemas es identificar los mismos, para lo cual las principales fuentes de información son: • La base de datos de Incidentes: en principio cualquier incidente del que no se conocen sus causas y que se ha cerrado mediante algún tipo de solución temporal constituye potencialmente un problema. Sin embargo, antes de llevarlo a la categoría de problema se deberá de analizar si se trata de un incidente aislado y su impacto en la infraestructura de TI. • Análisis de la infraestructura TI: en conjunción con las disciplinas de administración de disponibilidad, de capacidad y de monitorización y control, el manejo de problemas analiza los diferentes procesos y determina en qué áreas se deben robustecer los sistemas y la infraestructura de TI, para evitar futuros problemas. • Deterioro de los Niveles de Servicio: un desempeño que se deteriora es una indicación de que existe algún problema, que aun no se ha manifestado en forma de incidente. Todas las áreas de organización de TI deben colaborar en el manejo de problemas, identificando problemas reales o potenciales e informando sobre cualquier síntoma que pueda indicar un deterioro en el servicio TI. El registro de problemas es bastante similar al registro de los incidentes; sin embargo, el énfasis no debe colocarse en los detalles específicos de los incidentes asociados, sino en su naturaleza y posible impacto. El registro de problemas debe incorporar información como: Causas del problema. Síntomas asociados. Soluciones temporales. Servicios involucrados. Niveles de urgencia, prioridad e impacto. Estado: activo, error conocido, cerrado. 2.1.2.- Clasificación y asignación de recursos La clasificación del problema debe tomar en cuenta desde las características generales de éste, tales como si se trata de un problema de hardware o de software, que áreas del negocio se ven afectadas y detalles 61

Capítulo IV

sobre los diferentes elementos de configuración involucrados en el mismo. Un factor esencial es la determinación de la prioridad del problema, que al igual que en el caso de los incidentes, se determina tanto a partir de la urgencia (demora aceptable para la solución del problema) como de su impacto (grado de deterioro de la calidad del servicio). Al igual que en la administración de incidentes la prioridad puede cambiar en el transcurso del proceso del problema, por ejemplo, cuando se encuentra alguna solución temporal al mismo, que reduce considerablemente su impacto, puede reducirse su prioridad. Una vez clasificado y de acuerdo con la prioridad de un problema, se deben de asignar los recursos necesarios para su solución. Estos recursos deben ser suficientes para asegurar que los problemas asociados sean tratados eficazmente y, de esa forma, minimizar el impacto en la infraestructura de TI. 2.1.3.- Análisis y diagnóstico: error conocido Los objetivos principales del proceso de análisis son: • Determinar las causas del problema. • Definir soluciones temporales a la administración de incidentes para minimizar el impacto del problema, hasta que se implementen los cambios necesarios que lo resolverán definitivamente. Es esencial tener en cuenta que no siempre el origen del problema es un error de hardware o software. Es frecuente que un problema pueda ser causado por: • Errores de procedimiento. • Documentación incorrecta. • Falta de coordinación entre diferentes áreas. Es también posible que la causa del problema sea un error o "bug" bien conocido en alguna de las aplicaciones instaladas, por lo que se hace necesario entrar en contacto con los equipos de desarrollo y mantenimiento de sistemas, en caso de aplicaciones desarrolladas "en la casa", o tramitar ante el grupo de soporte del proveedor o, en algunos casos, investigar en internet la información sobre errores conocidos que pueda ser utilizada para resolver el problema en cuestión. Como ya indicáramos, una vez determinadas las causas de un problema, éste se convierte en un error conocido y comienza a ser 62

Manejo de problemas

manejado por los procedimientos de control de errores, para su posterior procesamiento.

2.2.- Control de errores El proceso de control de errores incluye dos actividades: 1. Análisis de la solución 2. Aplicación de la solución El registro de los errores conocidos es de vital importancia para el inicio de estas actividades del manejo de problemas, con el fin de poder asociarle, siempre que sea posible, algún tipo de solución temporal que pueda mitigar el impacto de los incidentes asociados. 2.2.1.- Análisis de la solución Con el fin de evitar inconvenientes, el análisis de las soluciones debe incluir una evaluación de: • Posible impacto que la solución de un problema pueda tener sobre la infraestructura de TI. • Los costes asociados. • Sus consecuencias sobre los niveles de servicio. 2.2.2.- Aplicación de la solución Existen algunos casos, en los que dado el impacto que el problema tiene sobre la calidad del servicio, se deben emitir solicitudes de cambio de emergencia para su proceso urgente por parte de los responsables de la administración de cambios. En estos casos es importante que se evalúe si la solución temporal que se ha diseñado es lo suficientemente buena como para mantener unos niveles de calidad de servicio aceptables. Una vez determinada la solución óptima a un problema y antes de elevar una solicitud de cambio a la administración de cambios deben hacerse varias consideraciones: • ¿Es conveniente demorar la solución? Bien sea porque en el corto plazo se prevén cambios significativos en la infraestructura de TI o por el escaso impacto del problema en cuestión. • ¿Se justifica el costo de implantar la solución? En cualquier caso, se implemente o no la solución, toda la información sobre el error y su solución se deberá registrar en las bases de datos asociadas.

63

Capítulo IV

En caso de que se proceda con la implantación de la solución, se emitirá una solicitud de cambio y la implantación de la solución pasa a ser coordinada por la disciplina de administración de cambios.

2.3.- Revisión de post implementación y cierre Antes de dar el problema por resuelto y cambiar su estado a “cerrado” se debe analizar el resultado de la implementación de la solicitud de cambio procesada por administración de cambios. Si los resultados de este cambio son los deseados, se pueden cerrar todos los incidentes relacionados con este problema y se considera concluido el proceso.

3.- Evaluación de la disciplina Hemos podido observar que el objetivo central de la disciplina de manejo de problemas es mejorar el funcionamiento de la infraestructura TI; así pues, para evaluar su eficacia será imprescindible realizar un seguimiento continuo de los procesos relacionados y evaluar su desempeño. Un buen manejo de problemas debe traducirse en una: • Disminución en el número de incidentes • •

Mayor eficacia en la resolución de problemas. Una administración proactiva que permita identificar problemas potenciales antes de que estos se manifiesten o provoquen una degradación de la calidad del servicio de TI Un eficaz manejo de problemas requiere que las responsabilidades sobre cada disciplina y cada área de servicios estén claramente definidas. La elaboración de informes y resúmenes sobre las actividades de manejo de problemas cumplidas, permitirá que la gerencia de TI evalúe el rendimiento de la disciplina, así como también aportará información valiosa para otras áreas de servicio de TI. Entre los informes que pueden ser producidos periódicamente están: • Informes de rendimiento del manejo de problemas, que detallen la cantidad de errores resueltos, la eficacia de las soluciones propuestas y los tiempos de respuesta. • Informes de acciones de prevención, en los que se especifiquen las acciones ejercidas para la prevención de nuevos problemas

64

Manejo de problemas

•

•

Resultados de los análisis que se hayan realizado sobre la adecuación de la infraestructura de TI en relación con las necesidades de la empresa. Informes de calidad de los productos y servicios contratados, que puedan facilitar la evaluación de los proveedores.

4.- Ejemplo

65

Capítulo IV

66

Capítulo V

Adm inist ra c ión de Configura c ione s

Capítulo V

Administración de Configuraciones Tabla de contenido 1.- ¿En qué consiste la administración de configuraciones?............69 1.1.Ventajas .............................................................................70 1.2.Barreras..............................................................................70 2.- Terminología ..............................................................................71 2.1.Ítems de configuración (configuration item - CI) ..............71 2.2.Base de datos de configuraciones. .....................................72 2.3.Línea base de configuración (configuration baseline) .......72 2.4.Sistema de administración de configuraciones. .................72 2.5.Ambientes operacionales ...................................................73 3.- Proceso .......................................................................................75 3.1.Planificación ......................................................................76 3.2.Clasificación y Registro.....................................................77 3.3.Alcance ..............................................................................77 3.4.Nivel de detalle y Profundidad ..........................................78 3.5.Nomenclatura.....................................................................78 3.6.Control ...............................................................................79 3.7.Auditorías...........................................................................79 4.- Evaluación de la disciplina .........................................................80

68

Administración de configuraciones


1.- ¿En qué consiste la administración de configuraciones? Las funciones principales que cumple la administración de configuraciones son: • Mantener el control detallado de todos los componentes de la infraestructura TI, tanto de hardware como de software, almacenando esa información en una base de datos de configuración – inventario de hardware y software-. • Suministrar información actualizada sobre la configuración de la infraestructura de TI, para el cumplimiento de los diferentes procesos de administración de servicios que así lo requieren. Para poder administrar eficientemente la infraestructura informática, es fundamental conocer en detalle cuáles son sus componentes y sus interrelaciones; esa es la tarea central de la administración de configuraciones.

69

Capítulo V

La administración de configuraciones no es una labor sencilla, pues requiere una colaboración muy activa de todos los administradores de servicios de TI y en particular de los procesos de administración de cambios y versiones. Por tal razón, en muchas organizaciones medianas y pequeñas se prefiere combinar esas disciplinas, simplificando el proceso de control.

1.1.- Ventajas Los beneficios de una adecuada administración de configuraciones son múltiples, entre ellos: • Resolución más rápida de los problemas, que redunda en una mayor calidad de servicio. • Una administración de cambios más eficiente. •

Control de licencias. Se pueden identificar copias ilegales de software que pueden suponer un peligro para la infraestructura TI y el incumplimiento de las normas legales que podría repercutir negativamente en la organización.

•

Mejor nivel de seguridad, pues una base de datos de componentes actualizada ayuda a realizar un análisis de las vulnerabilidades en la infraestructura. Mayor rapidez en la restauración de servicios. Cuando se conocen todos los ítems de configuración y sus interrelaciones es mucho más sencillo recuperar la configuración de la infraestructura de producción en un menor tiempo.

•

1.2.- Barreras Las principales barreras que encuentra la implantación de la disciplina de administración de configuraciones son: • Desactualización de la base de datos de configuración, debido a que mantenerla actualizada requiere dedicación y prolijidad que no siempre el personal está motivado a cumplir. • Herramientas inadecuadas, es necesario disponer del software adecuado que facilite los procesos de manejo y actualización de la base de datos. •

70

Falta de coordinación con las disciplinas de administración de cambios y de versiones, que impide una correcta actualización de la base de datos.


•

Asignación de responsabilidades, debe haber una clara definición y asignación de responsabilidades, con el fin de garantizar que la base de datos de configuración se actualiza adecuadamente.

2.- Terminología A lo largo de este capítulo hemos utilizado diferentes conceptos con diferentes denominaciones, sin embargo, especialmente en administración de configuraciones, para poder desarrollar unos procedimientos consistentes y sin ambigüedades es imprescindible manejar una terminología clara y precisa, por lo que a continuación discutiremos los más importantes.

2.1.- Ítems de configuración (configuration item - CI) Es la denominación genérica que se le da a todos los componentes de los servicios de TI, como pudieran ser: •

Dispositivos de hardware como: PCs, impresoras, puntos de red, enrutadores, concentradores, etc. así como cada uno de sus componentes de hardware como tarjetas, teclados, lectores de CDs, etc.

•

Componentes de software como: los sistemas operativos, las aplicaciones, los programas que integran una aplicación, los drivers, los protocolos de red, etc. Documentación como: componentes escritos, planes, diseños, manuales, instructivos, acuerdos de niveles de servicio, contratos, etc.

•

71

Capítulo V

ITIL define ítem de configuración como: Cualquier activo, servicio, componente u otro elemento que se controla (o que será controlado) por la administración de configuraciones.

2.2.- Base de datos de configuraciones (configuration management data base - CMDB). La base de datos de configuraciones debe incluir: • Información detallada sobre cada ítem de configuración. •

Interrelaciones entre los diferentes ítems de configuración, como, por ejemplo, relaciones "padre-hijo" o interdependencias tanto lógicas como físicas (Ej.: la estación de trabajo está conectada al punto de red X que se conecta al concentrador Y) La base de datos de la administración de configuraciones no puede limitarse a una mera enumeración del inventario de componentes, sino que debe tener la capacidad de presentar una imagen global de la infraestructura TI.

2.3.- Línea base de configuración (configuration baseline) Una línea base de configuración es la definición de la estructura que debe tener un ítem, la cual ha sido formalmente acordada y establecida. Este concepto lo podemos asociar a la definición de los estándares que deben cumplir algunos ítems de configuración, como ocurre con los programas, los instructivos, los modelos de datos, etc. La línea base de configuración se utiliza en la disciplina de administración de cambios, para verificar que los nuevos ítems que pasan al ambiente de producción cumplan con los estándares.

2.4.- Sistema de administración de configuraciones (Configuration Management System). Es claro que la administración de configuraciones requiere el apoyo de un sistema de información que debe contar con facilidades para dar entrada a los ítem de configuración, mantener y actualizar la base de datos de configuración y para extraer la información que requieren los diferentes procesos de administración de servicios de TI. Uno de los grandes retos, al iniciar el desarrollo de las disciplinas de administración de servicios es el levantamiento del inventario de hardware y software. Afortunadamente, en el mercado pueden 72


encontrarse una gran cantidad de paquetes que automatizan gran parte de las funciones de recolección de datos y mantenimiento de la base de datos de configuraciones, algunos de estos paquetes disponen de facilidades para explorar algunos equipos conectados a la red -como las estaciones de trabajo, impresoras y servidores-, con el fin de identificar todos los dispositivos y componentes de software instalados y actualizar automáticamente el inventario. Algunos de estos paquetes también permiten identificar software ilegalmente instalado. Entre estos paquetes podemos citar: Discovery LOGINventory Everest Corporate Edition NetSupport DNA Users Ghost Alloy Network Inventory EMCO Network Inventory WinAudit Asset Tracker for Networks Steel Inventory Alchemy Network Inventory Computer Admin Lite Admin Express

2.5.-

Ambientes operacionales

Un ambiente operacional es un conjunto de componentes y recursos que se organizan separadamente para cumplir un propósito específico, como: • Ambiente de producción El ambiente de producción está conformado con todos los recursos y componentes destinados a procesar las operaciones y la información de la empresa. Es un ambiente que maneja los “datos reales” del negocio, al que sólo tienen acceso los usuarios, con las limitaciones que les imponen los perfiles de seguridad que les hayan sido asignados, de acuerdo con sus atribuciones y responsabilidades.

73

Capítulo V

•

•

74

Es norma general que el personal de desarrollo de sistemas no tenga acceso a este ambiente, con el fin de mantener una sana segregación de funciones. Ambiente de desarrollo El ambiente de desarrollo está conformado con todos los recursos y componentes destinados a desarrollar o modificar las diferentes aplicaciones para uso de la empresa. Es un ambiente que maneja datos ficticios que utiliza el personal de desarrollo y mantenimiento. El acceso a este ambiente tiene menos restricciones que el ambiente de producción. Ambiente de prueba El ambiente de prueba está conformado con todos los recursos y componentes destinados a realizar pruebas de sistema y de desempeño de las diferentes aplicaciones – nuevas o modificadas- para uso de la empresa. Es un ambiente con una estructura muy similar a la del ambiente de producción, pero en el que se manejan datos ficticios –datos de prueba-. El acceso a este ambiente tiene más restricciones que el ambiente de desarrollo, pero menos que el ambiente de producción. Solamente lo utilizan usuarios y personal de desarrollo, debidamente autorizados para cumplir procesos prueba específicamente planificados.


•

Ambiente de adiestramiento. En algunas empresas se utiliza un ambiente de adiestramiento, este ambiente está conformado con todos los recursos y componentes destinados necesarios para que los usuarios de un nuevo sistema puedan aprender a utilizar sus funciones en forma muy similar a como lo harán cuando el sistema pase a producción. Normalmente se utiliza para adiestrar a los usuarios para un nuevo sistema de largo alcance. Es un ambiente con una estructura muy similar a la del ambiente de producción, pero en el que también se manejan datos ficticios –datos de prueba-. El acceso a este ambiente tiene más restricciones que el ambiente de desarrollo, pero menos que el ambiente de producción. Solamente lo utilizan usuarios y personal de desarrollo, debidamente autorizados para cumplir los procesos de adiestramiento específicamente planificados. La separación de ambientes es un elemento fundamental de control interno, pues permite establecer controles estrictos sobre el uso de los componentes destinados a producción y el acceso a la información del negocio. En algunas empresas, en las que no se dispone de suficientes recursos, será imprescindible que, como mínimo, se establezca una separación estricta entre el ambiente de producción y todas las actividades de desarrollo y prueba. Es importante observar que los procesos de migración de componentes desde el ambiente de prueba al ambiente de producción, una vez que han pasado satisfactoriamente los procesos de prueba, se realizan bajo la supervisión de las disciplinas de administración de versiones y de cambios.

3.- Proceso Las principales actividades que se cumplen dentro del proceso de administración de configuraciones son: 1. Planificación: Determinar los objetivos y estrategias de la administración de configuraciones.

75

Capítulo V

2. Clasificación y registro: Los ítems de configuración (CI´s) deben registrarse de acuerdo a su línea base y nomenclatura que se hayan predefinido. 3. Seguimiento y control: Es necesario asegurar que la base de datos de la administración de configuración (CMDB) esté correctamente actualizada, por lo que es fundamental hacer un seguimiento que permita asegurar que cada una de las disciplinas relacionadas –administración de cambios y de versiones- registren y actualicen correcta y oportunamente la información de su competencia. 4. Realización de auditorías: Como es práctica normal en cualquier proceso de inventario, la administración de la configuración incluye la realización de auditorías que permitan cotejar la información registrada en la base de datos contra la configuración física real de la infraestructura TI de la organización. 5. Elaboración de informes: La Administración de configuraciones tiene como función primordial aportar información a otras disciplinas y para las diferentes áreas de la infraestructura de TI.

3.1.- Planificación Sin una base de datos de configuraciones es muy difícil que puedan administrarse satisfactoriamente los servicios de TI, por la sencilla razón de que no existiría un conocimiento detallado de lo que se está administrando. Por esta razón, puede decirse que la disciplina de administración de configuraciones es el corazón de la administración de servicios de TI. Las principales tareas que se cumplen dentro de la actividad de planificación son las siguientes: • Designar una persona responsable: una descentralización excesiva o dispersión de esta responsabilidad entre las diferentes unidades técnicas, puede generar descoordinación, con el riesgo de que la actualización de la base de datos se actualice en forma desigual. • Invertir en alguna herramienta de software adecuada a las actividades requeridas, pues no es posible cumplir con esta disciplina con métodos manuales. 76


•

Establecer claramente: El alcance y objetivos. El nivel de detalle. El proceso de implementación en orden de importancia o de acuerdo con los lineamientos dictados por la gerencia de TI.

•

Coordinar el proceso estrechamente con la administración de cambios, y la administración de versiones. Una planificación adecuada permitirá que la administración de configuraciones se desarrolle sin dificultades y permitirá desarrollar una base de datos robusta para apoyar el resto de los procesos.

3.2.- Clasificación y Registro Es claro que la principal tarea de la administración de configuraciones es mantener la base de datos de configuraciones, por ello es importante un trabajo de diseño que establezca criterios de clasificación y registro de los componentes, para llevar a cabo esta labor con éxito será importante que: • Los objetivos sean realistas: una excesiva profundidad o detalle puede sobrecargar de trabajo a la organización y causar, a la larga, que se abandonen estas responsabilidades. • La información sea suficiente: debe existir, por lo menos un registro de todos los sistemas y componentes críticos de la infraestructura TI.

3.3.- Alcance Al poner en marcha la disciplina de administración de configuraciones será importante establecer prioridades, determinando qué sistemas y componentes TI van a ser incluidos gradualmente en la base de datos de componentes. Debe tomarse en cuenta que al establecer el alcance: • Será esencial incluir todos los sistemas de hardware y software relacionados con los servicios críticos. • Será recomendable incorporar la documentación asociada a niveles de servicio y licencias. En general cualquier servicio o proceso debe ser incluido en la base de datos, pero debe hacerse en forma gradual; si se fijan unos objetivos demasiado ambiciosos podrían llevar a la frustración y al fracaso.

77

Capítulo V

3.4.- Nivel de detalle y Profundidad Una vez determinado el alcance de la base de datos de configuraciones es fundamental establecer el nivel de detalle necesario, para ello se deberá: • Determinar los atributos que describen cada tipo de ítem. • Determinar las relaciones lógicas y físicas que se registrarán para los diferentes ítems. • Ítems y subcomponentes que deberán ser registrados independientemente. Por ejemplo, si se decide incluir las estaciones de trabajo en la base de datos, debe considerarse incluir: • •

•

Atributos: fabricante, tipo, modelo, fecha de compra, procesador, memoria, sistema operativo, costo, etc. Relaciones: punto de red al cual está conectado, a qué usuario está asignada, dispositivos que tenga conectados como, teclado, monitor, impresoras, scanners, etc. Subcomponentes: tarjetas de red, discos duros, tarjetas gráficas, herramientas, paquetes de software y programas instalados.

3.5.- Nomenclatura Será de vital importancia establecer un sistema de codificación y clasificación para los diferentes ítems de configuración, con el fin de que el sistema pueda ser utilizado con facilidad: • La identificación de cada tipo de ítem debe ser única y fácil de interpretar: • •

•

78

El código debe ser utilizado consistentemente en todas las comunicaciones referidas a los ítems de configuración. Los códigos deben ser establecidos tanto para componentes de hardware, como también para documentación y componentes de software. Normalmente los ítems de hardware tienen un serial asignado por el proveedor, que deberá ser incluido en la base de datos, para ello no debe descartarse el uso de códigos de barra, con el fin de simplificar los procesos de registro en la base de datos de configuración.


3.6.- Control La administración de configuraciones debe estar puntualmente informada de todos los cambios y adquisiciones de componentes para mantener actualizada la base de datos. El registro de todos los componentes de hardware debe iniciarse desde la aprobación de su compra y debe mantenerse actualizado su estado en todo momento de su ciclo de vida. Asimismo, debe estar correctamente registrado todo el software "en producción". Las tareas de control deben centrarse en: • Asegurar que todos los componentes están registrados en la base de datos. • Monitorizar el estado de todos los componentes. • Actualizar las interrelaciones entre los ítems de configuración. • Informar sobre el estado de las licencias.

3.7.- Auditorías El objetivo de las auditorías es asegurar que la información registrada en la base de datos de configuraciones coincide con la estructura real de la infraestructura de TI. Normalmente, las auditorías deberán realizarse en forma rotativa, pues resultará demasiado engorroso auditar toda la infraestructura de una sola vez. Adicionalmente, el proceso de auditorías debe mantenerse con cierta constancia, a los fines de cubrir toda la infraestructura en un período razonable –un semestre o un año-. Dentro de lo posible, deberá dotarse el proceso de auditoría de herramientas automatizadas, como lectores de código de barras y programas que comparen la base de datos con los datos obtenidos en las revisiones físicas, con el fin de determinar faltantes, sobrantes e inexactitudes. También será importante que se realicen auditorías después de haberse procesado algún cambio significativo –reemplazo de aplicaciones o de equipos- y si existe la sospecha de que alguna parte de la información almacenada en la base de datos está o incompleta o es incorrecta. Las auditorías deben dedicar especial atención a aspectos tales como: • Uso adecuado de la nomenclatura en los registros de los ítems.

79

Capítulo V

•

•

Estatus de los ítems de configuración –instalado, almacenado, en mantenimiento, descontinuado, etc.correctamente registrado. Cumplimiento de los niveles de detalle establecidos para el registro de información sobre los ítems de configuración.

4.- Evaluación de la disciplina Para el funcionamiento correcto de la administración de configuraciones se requiere la colaboración de toda la organización TI, para mantener actualizada la información almacenada en la base de datos de configuración. Es importante producir informes periódicos que permitan evaluar el desempeño de la administración de configuraciones, conocer la consistencia de la base de datos de configuraciones y para aportar información para otras áreas de la administración de servicios de TI. Entre los reportes que podrían producirse, pueden estar: • Resultados de las auditorías realizadas, mostrando discrepancias entre la información almacenada en la base de datos y la configuración real. • Información sobre ítems que han estado involucrados en diferentes fallas. • Costos del proceso. • Sistemas de clasificación y nomenclatura utilizados. • •

80

Informes sobre ítems no autorizados y/o sin licencias. Información estadística y composición de la estructura TI.

Capítulo VI

Adm inist ra c ión de V e rsione s

Capítulo VI

Administración de versiones Tabla de contenido 1.1.1.1.2.2.2.1.2.2.2.3.2.4.2.5.3.3.1.3.2.3.3.4.5.6.-

82

¿En qué consiste la administración de versiones?..................83 Ventajas .............................................................................85 Barreras..............................................................................85 Consideraciones de tipo práctico............................................86 Tipos de versiones .............................................................86 Actualización y custodia de componentes .........................87 Versiones anteriores...........................................................88 Nomenclatura de versiones ................................................88 Estatus de una versión........................................................89 Actividades de administración de versiones ..........................89 Planificación ......................................................................90 Verificación de cumplimiento de estándares .....................91 Verificación de cumplimiento de pruebas .........................91 Implementación......................................................................93 Soporte inicial ........................................................................94 Evaluación de la disciplina.....................................................94

Administración de versiones


1.- ¿En qué consiste la administración de versiones? La administración de versiones es la disciplina que incluye las tareas de coordinación y control sobre el proceso de implementación de todo el software instalado en el ambiente de producción. Algunos autores prefieren incluir también el control del hardware instalado dentro de esta disciplina; sin embargo, dado que hardware y software son elementos tan diferentes no consideramos práctico que la administración de versiones se ocupe de los ítems de hardware. Por ejemplo, el software definitivo –instalado en producción- requiere que una copia de los programas ejecutables y sus correspondientes módulos fuente, sean custodiados bajo estrictos controles; sin embargo, no tiene ningún sentido plantear algo similar para el hardware instalado. Consideramos además, que la administración de cambios y de configuraciones ofrecen unos marcos procedimentales suficientemente amplios para el control y la administración de los ítems de hardware. Una versión –o release- es un conjunto de ítems de configuración que han sido probados y están listos para ser migrados al ambiente de producción. La administración de versiones es una disciplina que debe coordinarse e integrarse perfectamente con las disciplinas de administración de cambios y de configuraciones, con el fin de asegurar que toda la información relacionada con las nuevas versiones se actualice adecuadamente en la base de datos de configuraciones. La persona o el equipo responsable de la administración de versiones tiene como responsabilidad fundamentalísima la custodia de las librerías o bibliotecas de programas fuentes y ejecutables que han sido aceptados en el ambiente de producción, así como también, de las bibliotecas de documentación que deben acompañar dichos componentes. La disciplina de administración de cambios se encarga de aprobar y supervisar todo el proceso de cambio y la administración de versiones se encarga del proceso de migración al ambiente de producción de los ítems 83

Capítulo VI

de configuración nuevos o modificados; obviamente, ambas disciplinas tienen áreas comunes que deben ser tomadas en cuenta al desarrollar los procedimientos, para evitar duplicidad de funciones o choque de responsabilidades. Por esta razón, en algunas organizaciones las actividades de administración de versiones se incluyen dentro de la administración de cambios.

Entre los principales objetivos de la administración de versiones podemos señalar los siguientes: • Implementar las nuevas versiones de software en el ambiente de producción, una vez que se hayan realizado pruebas suficientemente rigurosas. • Asegurar que el proceso de cambio cumpla las especificaciones de la solicitud de cambio que lo originó. • Asegurar, en coordinación con la administración de cambios y de configuraciones, que todos los cambios se actualicen correctamente en la base de datos de configuraciones. • Archivar y custodiar tanto los programas fuente, como copias de los ejecutables en producción, así como de toda su documentación asociada, en la biblioteca de componentes en producción.

84


•

Mantener la custodia, dentro de los plazos que establezcan las políticas de la organización, de los ítems reemplazados –versiones anteriores-.

1.1.- Ventajas Entre las ventajas que pueden derivarse de una disciplina de administración de versiones implementada correctamente pueden señalarse: • Las nuevas versiones cumplen los objetivos que originaron su desarrollo. • Se reduce el número de incidentes que puedan ocasionarse por incompatibilidades con otro software o hardware instalados. • El proceso de pruebas que debe preceder la implantación, permite asegurar la calidad del software y hardware que se instala. • El correcto mantenimiento de la bibliotecas de componentes originales -fuentes, ejecutables, documentación, etc.- evita que se pierdan valiosos elementos de la infraestructura. • Se mantiene un control centralizado del software que pasa al ambiente de producción.

1.2.- Barreras Entre las principales barreras que encuentra la implantación de la disciplina de administración de versiones pueden señalarse las siguientes: • Resistencia a la centralización del proceso de cambio. • El personal y, en general, la organización TI no reconocen la autoridad del administrador de versiones, especialmente en lo relacionado a la custodia de los ítems instalados en el ambiente de producción. • No se realizan pruebas lo suficientemente rigurosas de las nuevas versiones, lo cual genera emergencias en el ambiente de producción y la permanente necesidad de hacer excepciones en el cumplimiento de los procedimientos, con el fin de poder modificar los componentes directamente en ese ambiente. • Hay resistencia a desarrollar planes de retorno o “backout", para deshacer cualquier cambio que se haya implementado en producción, pero que, por cualquier razón, no esté funcionando adecuadamente.

85

Capítulo VI

•

Carencia de herramientas de distribución de software, para la instalación de nuevas versiones que puedan requerir la instalación de uno o más componentes en diferentes servidores o en las estaciones de trabajo de los diferentes usuarios de una nueva versión.

2.- Consideraciones de tipo práctico Señalábamos al inicio, que una versión es un conjunto de ítems de configuración nuevos o modificados, que han sido probados y están listos para ser puestos en producción, indicábamos también, que las especificaciones funcionales y técnicas de una versión deben estar establecidas en la solicitud de cambio que la originó. En cierta forma, se puede afirmar que la administración de versiones es el último paso de los diferentes procesos de adquisición, desarrollo, mantenimiento e implantación de software, tanto software de aplicaciones para el apoyo del negocio, como software base, entendiendo como software base: los sistemas operativos, manejadores de bases de datos, compiladores, programas de utilidad, programas de automatización de oficinas, etc. Por ello, será importante establecer el conjunto de normas que deberán gobernar la implantación de nuevas versiones, con el fin de establecer unas sólidas metodologías de trabajo.

2.1.- Tipos de versiones De acuerdo con su magnitud o impacto en la infraestructura de TI, las versiones pueden clasificarse en: • Versiones mayores 86


Una versión mayor corresponde a la instalación de grandes piezas de software. Normalmente corresponde a un nuevo sistema operativo, aplicación o al reemplazo del software de apoyo a un número importante de operaciones del negocio. • Versiones menores Una versión menor corresponde a un grupo no muy grande de ítems de configuración, que complementan la capacidad de un elemento de software mayor o que cambian la funcionalidad de algún módulo de un sistema o corrigen varios errores conocidos. • Versiones de emergencia Una versión de emergencia corresponde a uno o varios ítems de configuración que reemplazan ítems en producción, para reparar un error conocido. Será muy importante que los procedimientos de administración de versiones tomen en cuenta los diferentes tipos de versiones, con el fin de asegurar su agilidad, Evitando que para una versión de emergencia priven las mismas condiciones que para una versión mayor, sin perder de vista los controles fundamentales.

2.2.- Actualización y custodia de componentes La administración de versiones debe establecer la forma cómo se mantendrán las diferentes librerías o bibliotecas de programas fuentes y ejecutables que quedan bajo la custodia del administrador de versiones. En el caso de las aplicaciones los componentes se almacenarán en bibliotecas propias de la instalación, cuyo acceso quedará restringido a los administradores de versiones únicamente; sin embargo, en el caso del software base y algunas aplicaciones adquiridas es preferible almacenar ordenadamente, en archivos de seguridad los ítems tal como fueron recibidos del proveedor. Hoy día, es usual recibir vía internet nuevas versiones y correcciones de errores conocidos o, simplemente, actualizaciones; por lo que es muy importante establecer procedimientos que aprovechen la gran flexibilidad que esta forma de trabajo ofrece, pero que, además, establezcan suficientes controles sobre su aplicación. Existen casos, como los antivirus, que se actualizan automáticamente, de forma continua. Si para estos componentes se puede tener la confianza de que el proveedor realiza una buena administración de versiones, no valdrá la pena invertir tiempo y energía para ponerlos bajo nuestra 87

Capítulo VI

administración de versiones. En estos casos, bastará con registrar el software en la base de datos de configuraciones y auditar periódicamente su proceso de actualización, para verificar que se está cumpliendo satisfactoriamente. También es frecuente que se autorice a un proveedor a que tenga acceso a nuestra infraestructura, con el fin de que directamente, desde sus oficinas, pueda instalar ítems nuevos o modificados. En estos casos tampoco valdrá la pena invertir tiempo y energía para ponerlos bajo nuestra administración de versiones, bastará con llevar un registro detallado de estos eventos de actualización y auditar periódicamente el proceso de actualización, para verificar que se está cumpliendo satisfactoriamente.

2.3.- Versiones anteriores En la administración de versiones es muy importante mantener una práctica ordenada para almacenar y custodiar las versiones que preceden a los componentes en producción –versiones anteriores-, con el fin de poder recuperar cualquier ítem, aunque haya transcurrido algún tiempo desde su reemplazo. Esta práctica resulta especialmente valiosa para los ítems de software, que a veces tienen alguna falla que ha pasado inadvertida en los procesos de prueba y que, tiempo después de haber sido instalados, causan una interrupción en el servicio o presentan un funcionamiento inadecuado.

2.4.- Nomenclatura de versiones Una práctica común es la de establecer una codificación que identifique unívocamente cada versión. Normalmente, se utiliza un sistema de aceptación muy generalizada, que consiste en denominar: • Versiones mayores: 1.0, 2.0, etc. • Versiones menores: 1.1, 1.2, 1.3, etc. • Versiones de emergencia: 1.1.1, 1.1.2, etc. Igualmente, los ítems de configuración que integran una versión, deberán asociar su nombre o código de identificación con la versión a la cual pertenecen. Cabe señalar que este esquema de denominación de versiones es apropiado para empresas productoras de software, en el caso de cualquier otra empresa, sólo será necesario identificar los ítems que conforman un sistema o una pieza grande de software e identificar las diferentes versiones a nivel componente. 88


2.5.- Estatus de una versión Las diferentes versiones cumplen un ciclo de vida, desde que se formula la solicitud de cambio que la origina, hasta que es reemplazada del ambiente de producción, por lo que hablamos de que una versión puede pasar por diferentes estatus: • Solicitada • En desarrollo • En prueba • En producción • Descontinuada Junto con la información pertinente de cada ítem de configuración, en la base de datos de configuraciones, será importante que se registre su estatus.

3.- Actividades de administración de versiones Para dar inicio a la disciplina de administración de versiones, será importante establecer el conjunto de normas y políticas que deberán gobernar los procedimientos de implantación de nuevas versiones, con el fin de establecer unas sólidas metodologías de trabajo.

89

Capítulo VI

Adicionalmente, deberán establecerse los procedimientos que deberán seguirse para cumplir las siguientes actividades, que conforman la disciplina: • Planificación • Verificación de cumplimiento de estándares • Verificación de cumplimiento de pruebas • Implementación • Soporte inicial

3.1.- Planificación Antes de instalar una nueva versión en producción se requiere formular varios planes, dependiendo del tipo de versión -mayor, menor o de emergencia-. Estos planes formarán parte del material que será revisará por la administración de cambios y deberán tomar en cuenta los siguientes aspectos: • Alcance, contenido, riesgos, responsabilidades y usuarios involucrados en la versión. • Estrategia para obtener la participación de todas las partes involucradas –unidades de soporte, analistas de sistemas, técnicos de bases de datos, usuarios, etc.• Planes de retorno –backout- para las situaciones de falla. Verificar que los planes de retorno o respaldo y de retorno o backout han sido convenientemente preparados y que son totalmente viables. • Establecer quién, cómo y cuándo tomará la decisión de aplicar los planes de retorno –en caso de ser necesario-, para minimizar el impacto negativo sobre el servicio. • ¿Qué se va a instalar? Establecer qué ítems de configuración están involucrados en la nueva versión. • ¿Quiénes son los usuarios? • ¿Dónde están de los usuarios? En el caso de distribuciones internacionales, ¿cuales consideraciones deben ser hechas? • ¿Cuáles son las principales dificultades que se prevén? • •

90

¿Cómo serán entregados los componentes de la nueva versión? ¿Cuál es el impacto que puede tener la instalación de la nueva versión en la continuidad y calidad de los servicios?


•

• •

Definir cuáles son los recursos humanos y técnicos necesarios para llevar a cabo la implementación de la nueva versión con éxito. Establecer quiénes serán los responsables directos en las diferentes etapas del proceso de migración. Verificar que se hayan desarrollado planes de comunicación y adiestramiento para que los usuarios participen y estén debidamente informados, con el fin de evitar que una nueva versión llegue como una sorpresa.

3.2.- Verificación de cumplimiento de estándares La administración de versiones constituye la “recta final” de los procesos de desarrollo y mantenimiento. En algunas oportunidades estos desarrollos se realizan "en casa" y en otras se realizan con la participación de proveedores externos. En ambos casos, la primera tarea de la administración de versiones será la de asegurar que el paquete o paquetes de software cumplan con las definiciones de línea base y estándares. En algunas empresas existe una unidad que cumple las funciones de aseguramiento de calidad, encargada de vigilar que durante todo el proceso de desarrollo se cumplan los estándares. Si ese fuera el caso, estas funciones estarán fuera del proceso de administración de versiones y únicamente se mantendrá la tarea de verificar que las sesiones de revisión de calidad se hayan cumplido satisfactoriamente. La disciplina de administración de versiones también incluirá las tareas correspondientes a la actualización de la base de datos de configuraciones.

3.3.- Verificación de cumplimiento de pruebas Una nueva versión, antes de pasar a producción, debe cumplir una serie de procesos de prueba, como los que se describen en los siguientes párrafos Normalmente, los procesos de prueba corresponden a las metodologías de desarrollo y mantenimiento que utiliza la empresa, por lo que no corresponden a las actividades de administración de versiones; sin embargo, dentro de esta disciplina debe incluirse la tarea de verificar que dichas pruebas se hayan cumplido satisfactoriamente. 3.3.1.- Prueba unitaria Una prueba unitaria es una prueba que se hace de un solo programa o de un módulo. El programador del módulo es responsable de realizar la prueba unitaria en el ambiente de desarrollo. 91

Capítulo VI

3.3.2.- Prueba de integración Una prueba de integración es la prueba que se hace de las interfaces que existen entre diversos componentes dentro de un módulo, con el fin de detectar cualquier problema de intercambio de datos, archivos o parámetros y asegurar que pueden ser ejecutados en el orden o secuencia requeridos. El analista del proyecto con ayuda de los restantes miembros del equipo de desarrollo o mantenimiento, realiza estas pruebas en el ambiente de prueba. 3.3.3.- Prueba Funcional El propósito de una Prueba Funcional es identificar las discrepancias que puedan existir entre un componente o sistema con sus especificaciones funcionales. Estas pruebas las realizan el representante funcional en el equipo de trabajo, junto con el analista del proyecto y la ayuda de los restantes miembros del equipo de desarrollo o mantenimiento. Una prueba funcional se lleva a cabo en el ambiente de prueba. 3.3.4.- Prueba de Sistema La Prueba de Sistema es el complemento de la prueba funcional, está dirigida a probar los aspectos técnicos del sistema para detectar discrepancias con respecto a sus objetivos de desempeño como tiempo de respuesta, cumplimiento de estándares. Estas pruebas las ejecuta el analista responsable del proyecto con la ayuda de los restantes miembros del equipo y la supervisión de personal de soporte técnico. Una prueba de sistema se lleva a cabo en el ambiente de prueba. 3.3.5.- Prueba de Aceptación Técnica Una Prueba de Aceptación Técnica es un proceso de prueba llevado a cabo por el personal técnico distinto del personal que desarrolló el sistema; en algunas empresas se cuenta con grupos dedicados realizar esta clase de pruebas para todos los sistemas que se desarrollan o modifican, antes de que los mismos pasen a producción. Sin embargo, para cumplir con esas tareas, la mayoría de las empresas prefiere organizar grupos de prueba ad-hoc con personal de operaciones y de soporte técnico. Normalmente, en una prueba de aceptación técnica se someten los sistemas a condiciones extremas, con el fin de asegurar que el sistema funcionará satisfactoriamente en cualquier caso.

92


4.- Implementación Una vez que se ha establecido la coordinación con el proceso de administración de cambios, se procede con la implantación en producción. Este proceso puede ser: • Completa • Parcial A su vez, una vez cumplidos los procesos de implantación, la administración de versiones debe asegurarse de que: • Se incluyan los programas fuente, la documentación y las copias de los programas ejecutables, en las bibliotecas correspondientes• La base de datos de configuración quede correctamente actualizada. • Se informe debidamente a la unidad de atención a los usuarios. 4.1.1.- Implementación completa Cuando se realiza instala una implantación completa, se instalan todos los ítems que componen la versión simultáneamente para todos los usuarios, en todas las localidades. Normalmente, para este tipo de implementaciones se establece un período de prueba final, denominado de aceptación funcional. Este período de prueba lo cumplen los usuarios, con el personal de soporte y el personal de operaciones, para evaluar que el sistema se desempeña adecuadamente trabajando bajo condiciones reales. Algunas veces estas pruebas pueden incluir el cumplimiento de paralelos. Probar un sistema nuevo en paralelo con el sistema vigente, implica la instalación total del sistema en el ambiente de producción, su ejecución con datos reales y la comparación de sus resultados con los que produce el sistema vigente. Una vez que estos procesos de aceptación se cumplen, el nuevo sistema pasa a ser el sistema oficial y se desinstalan todos los componentes que correspondan al sistema que se reemplaza. 4.1.2.- Implementación parcial Muchas veces se realiza lo que se denomina instalación piloto, para asegurar que el sistema se comporta adecuadamente en el ambiente de producción. También, si los usuarios se encuentran dispersos en localidades muy distantes y existen diferencias importantes de horario, se prefiere ir cubriendo grupos de usuarios separadamente. En estos casos, 93

Capítulo VI

los usuarios finales deben estar informados del calendario de instalación y la forma cómo podrían afectarse sus actividades diarias.

5.- Soporte inicial Normalmente, en el inicio de un nuevo servicio pueden haber errores que hayan pasado desapercibidos por los diferentes procesos de prueba, por lo que debe considerarse que las versiones que están cumpliendo el período de aceptación pudieran requerir la intervención de algún miembro del personal de desarrollo o del personal de soporte, para ello los procedimientos deben contemplar la posibilidad de otorgar autorizaciones temporales, para que estos técnicos puedan cumplir su cometido, con agilidad. Será muy importante para evaluar el desempeño de los equipos de desarrollo que, aunque estas tareas de soporte inicial se cumplan flexiblemente, queden bien registradas bajo las disciplinas de manejo de incidentes y de problemas.

6.- Evaluación de la disciplina Para evaluar el desempeño de la disciplina de administración de versiones será importante generar informes periódicos que ofrezcan una información precisa de las acciones cumplidas y presenten una métrica cubriendo aspectos como: • Número de nuevas versiones implantadas, por categoría • Número de procesos de retorno que se han tenido que realizar y razones que privaron para realizarlos. • Incidentes asociadas a nuevas versiones. • Uso de recursos en cada caso. • Existencia de versiones ilegales de software. • Adecuado registro de las nuevas versiones en la base de datos de configuración. • Incidentes provocados por un uso incorrecto de la nueva versión por parte de los usuarios. • Disponibilidad del servicio durante y después del proceso de implantación de la nueva versión.

94

Capítulo VII

Adm inist ra c ión de Ca m bios

Capítulo VII

Administración de cambios Tabla de contenido 1.- ¿En qué consiste la administración de cambios? ........................97 1.1.Ventajas .............................................................................98 1.2.Barreras..............................................................................98 2.- Elementos ...................................................................................99 3.- Roles ...........................................................................................99 4.- Actividades ...............................................................................100 4.1.Registrar...........................................................................101 4.2.Aceptación de la solicitud................................................102 4.3.Clasificación ....................................................................102 5.- Aprobación y Planificación ......................................................104 6.- Implementación ........................................................................105 7.- Evaluación ................................................................................106 8.- Evaluación de la disciplina .......................................................106

96

Administración de cambios


1.- ¿En qué consiste la administración de cambios? El cambio, dentro de una infraestructura de servicios, es algo constante; se instalan nuevas aplicaciones, nuevos equipos, nuevos puntos de red, nuevas estaciones de trabajo, nuevas versiones del software instalado, etc. Por esta razón es imperativo que todos esos cambios se realicen ordenadamente, sin que afecten el servicio de la plataforma TI, y que sean el resultado del trabajo en equipo, con la participación de todos los responsables, el personal de soporte requerido y los usuarios afectados por el cambio. ITIL define un cambio como la adición, modificación o eliminación de un servicio o componente autorizado, planificado o de soporte y su documentación relacionada . El principal objetivo de la Administración de cambios es evaluar y planificar el proceso de cambio para asegurar que se realice de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad de los servicios de TI. La administración de cambios debe trabajar para asegurar que los cambios: • Están justificados y debidamente sustentados. • Están convenientemente registrados, clasificados y documentados. • Han sido cuidadosamente probados en un ambiente de prueba. • Se llevan a cabo sin perjuicio de la calidad del servicio TI. • Se reflejen en la base de datos de componentes. • Están acompañados de un plan para deshacer el cambio – backout-, en caso de que el cambio pueda generar problemas en el servicio, por cualquier falla que pueda presentar.

97

Capítulo VII

•

Asegurar que en la instalación de un cambio participe todo el personal de soporte –analistas, técnicos de soporte, técnicos de red, técnicos de base de datos, etc.- y usuario necesarios para lograr una implementación exitosa.

1.1.- Ventajas La administración de cambios, por lo permanente y constante de los cambios, viene a ser una de las disciplinas medulares para poder asegurar la continuidad de los servicios. En general, podemos decir que su correcta aplicación puede brindar las siguientes ventajas: • • • • • •

Se reduce el número de incidentes y problemas que potencialmente un cambio puede generar. Se puede regresar a la situación anterior sin mayores dificultades, en caso de que el cambio no resulte exitoso. Se estimula el trabajo en equipo, al lograr la participación ordenada y planificada de técnicos y usuarios. Los cambios se asimilan más fácilmente. Se pueden evaluar los verdaderos costos asociados a un cambio. La base de datos de configuraciones se actualiza correctamente.

1.2.- Barreras La disciplina de administración de cambios tropieza con una serie de barreras como las que a continuación enumeramos: • No se acepta la autoridad del administrador de cambios. • •

•

•

98

Existe la tendencia a instalar cambios de manera independiente, sin mayor planificación. Existe tendencia a ignorar los procedimientos establecidos y, en particular, a evitar las tareas de actualización de la base de datos de configuraciones. Los encargados de la administración de cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organización, lo cual los incapacita para desarrollar correctamente su actividad. Los administradores de cambios no disponen de las herramientas adecuadas de software para hacer seguimiento y documentar adecuadamente el proceso.


•

Se implementan procedimientos demasiado rígidos, que dificultan los procesos de cambios medianos y menores, que constituyen la gran mayoría de los cambios.

2.- Elementos Los procedimientos de administración de cambios que se adopten deben definir los siguientes elementos: • Qué categorías de cambio existen, por ejemplo: mayor, mediano, menor. • Cómo se solicita un cambio. • Cómo se evalúa y categoriza un cambio. • Cómo se procesa un cambio. •

Cuáles son los niveles de aprobación de un cambio, dependiendo de su impacto y su categoría. • Criterios para aceptar, rechazar o posponer un cambio. Debe tenerse muy presente que el objetivo central de la disciplina de administración de cambios no es “evitar los cambios”. Tal actitud, sería absurda, pues la situación normal en cualquier departamento tecnología es la necesidad constante de implementar cambios. Podemos afirmar que, por el contrario, el objetivo central del procedimiento de control de cambios es evitar que los cambios se adopten sin orden ni concierto, asegurar que solamente se adopten los cambios que realmente requiere el negocio y estimular el trabajo en equipo.

3.- Roles En los procedimientos de administración de cambios participan varios personajes: 1. Proponente: Es cualquier persona que determina la necesidad de implementar un cambio y prepara una solicitud de cambio. 2. Administrador de cambios: Es la persona encargada de motorizar todos los procedimientos que conforman la administración de cambios, entre ellas: Procesar todas las solicitudes de cambio. Asegurar una adecuada evaluación del impacto que cada cambio pueda tener, antes de que el mismo sea aprobado. 99

Capítulo VII

3.

4.

5.

6.

7.

8.

Presidir las reuniones del comité de cambios. Técnico evaluador: Es cualquier persona que, dada su calificación, puede dar una opinión acerca de la viabilidad de un cambio o pueda determinar el impacto que dicho cambio tendrá. Comité de cambios –Change Advisory Board (CAB)-: La función del comité de control de cambios es estudiar cada solicitud de cambio y recomendar a la gerencia de TI su aprobación o rechazo. La dirección de este comité estará a cargo del administrador de cambios y lo integrarán las personas que designe la gerencia de tecnología de información, como pudieran ser técnicos de soporte, analistas de sistemas, usuarios, técnicos del centro de atención, etc. Parte afectada: Es el representante de una función, un departamento, un sistema o un proyecto sobre el cual un cambio pueda tener impacto, por lo que tiene particular interés en que el cambio se realice sin ningún trauma. Comité de cambios ampliado: Es el comité que integran los miembros del comité de control de cambios y las partes afectadas por un cambio en particular. Grupo implementador: Es el grupo de técnicos o unidad de la organización que llevará a cabo la implantación del cambio, con la ayuda de los grupos de soporte. Grupo de soporte: Es un grupo de técnicos designados por la jefatura de sus correspondientes departamentos –soporte técnico, sistemas, centro de atención, etc.- para apoyar y dar soporte al grupo implementador.

4.- Actividades La administración de cambios normalmente incluye actividades como las siguientes: • Monitorizar y dirigir todo el proceso de cambio. • •

100

Registrar, evaluar y aceptar o rechazar las solicitudes de cambios recibidas. Convocar reuniones del comité de cambios, excepto en el caso de cambios menores, para la aprobación de las solicitud de cambios.


•

Coordinar el desarrollo e implementación del cambio.

•

Evaluar los resultados del cambio y proceder a su cierre en caso de éxito.

4.1.- Registrar El primer paso del proceso de cambio es registrar las solicitudes de cambio. Estas solicitudes pueden venir de cualquier parte interesada: • Administración de problemas, disciplina encargada de proponer soluciones a errores conocidos, que, normalmente, requieren la aplicación de un cambio en la infraestructura de TI. •

Instalación de nuevos servicios, que requieren un cambio en el hardware o software de la infraestructura de TI. • Requerimientos de instalación o actualización para aplicaciones en producción o para el software base, generados de acuerdo con la disciplina de administración de versiones. • Cualquier empleado, cliente o proveedor puede sugerir mejoras en los servicios que pueden requerir cambios en la infraestructura. Una solicitud de cambio, deberá incluir como mínimo la siguiente información: • • •

Fecha de preparación. Número identificador de la solicitud de cambio. Descripción del cambio propuesto: Propósito -nuevo servicio, actualización, corrección de error conocido, solución de problema, etc. Ítems de configuración involucrados. Estimado de personal y recursos que deben participar en la implementación del cambio. Tiempo estimado. El registro de la solicitud de cambios se irá actualizando a medida que se vayan cumpliendo las diferentes tareas, con el fin de poder realizar un seguimiento detallado del proceso, desde su inicio hasta la evaluación final y su cierre definitivo. La información de registro debe ser actualizada durante todo el proceso y debe incluir información como la siguiente: 101

Capítulo VII

•

•

Estatus de la solicitud –registrado, aceptado, rechazado, discutido en comité, planificado, implementadoFecha de aceptación o rechazo de la solicitud de cambio. Evaluación del impacto del cambio en términos de servicios, aplicaciones, usuarios o componentes afectados. Calificación de la magnitud, prioridad y categoría del cambio

• • • • • • •

Planes de retorno o back out. Recursos asignados. Fecha de implementación. Plan de implementación. Resultados de la revisión post-implementación. Evaluación final. Fecha de cierre.

• •

4.2.- Aceptación de la solicitud Una vez que el administrador de cambios recibe una solicitud, determina quiénes, dentro de la organización, pueden evaluar la solicitud para determinar si consideran viable el cambio y el impacto que puede tener en los servicios y sus diferentes componentes. Una solicitud de cambio puede ser rechazada, si se considera que el cambio no es viable o no está justificado. La aceptación de una solicitud de cambio no implica que vaya a ser aprobada por el comité de cambios ni que vaya a ser implementado.

4.3.- Clasificación Una vez que el cambio solicitado ha sido evaluado, se evaluarán su prioridad, su impacto y los factores de riesgo que podrían amenazar el éxito del cambio. La prioridad que se asigne expresará la importancia que tiene una solicitud de cambio en relación con otras solicitud de cambios pendientes y permitirá establecer el orden en que se irán procesando e implantando los cambios. La experiencia ha enseñado que una buena forma de establecer los niveles de prioridad, puede ser la siguiente: • Baja: Es frecuente que se prefiera realizar los cambios de prioridad baja junto con otros cambios que guarden alguna relación. • 102

Normal:


•

•

Para los cambios de prioridad normal, debe buscarse el mejor momento, cuando ofrezca menor riesgo y no entorpezca la implantación de algún otro cambio de mayor prioridad. Alta: Un cambio de prioridad alta debe realizarse lo más pronto posible. Normalmente están asociados a solucionar problemas o errores conocidos, que están afectando el desempeño de la infraestructura de servicios. Urgente: Los cambios urgentes son aquellos que deben implementarse para resolver un problema que esté causando serias dificultades en el servicio; por lo regular, estos cambios no son de gran magnitud. Es frecuente que los cambios urgentes se procesen bajo el control de procedimientos especiales, que aseguren la implantación rápida del mismo.

Muchas veces los procedimientos de administración de cambios adoptan toda una diversidad de categorías, que poco ayudan a cumplir con los objetivos que persigue el procedimiento. Será recomendable adoptar una categorización sencilla de los impactos, como pudiera ser: cambios simples -que requieren poca participación del personal TI-, cambios medianos -que casi no tienen efecto sobre la calidad del servicio103

Capítulo VII

o complejos -que afectan un área importante del servicio de TI o que necesitan una gran cantidad de recursos-. En resumen, diremos que un cambio será categorizado de acuerdo con: Su prioridad -baja, normal, alta y urgente-. Su impacto -simple, mediano o complejo-. En general, los procedimientos de administración de cambios establecerán los diferentes caminos que deberán tomarse para llevar a cabo con éxito la implementación de las diferentes categorías de cambio.

5.- Aprobación y Planificación Por lo regular, cada cambio será discutido y evaluado por el comité de cambios; en algunos casos el comité tendrá autoridad para aprobarlo –por ejemplo, los cambios simples y medianos-, mientras que para los restantes –cambios complejos- deberá solicitar su aprobación de la gerencia de TI o del comité de sistema, en las empresas que existe ese tipo de comité. En el caso de tener que solicitar la autorización de la gerencia, el comité de cambios deberá presentar su recomendación. Para darle flexibilidad a los procedimientos, en muchas organizaciones los cambios simples no se llevan a la discusión del comité de cambios y son aprobados directamente por el administrador de cambios, una vez que revisa la evaluación del mismo y los planes de acción para implementarlo. El comité de cambios se reúne periódicamente analizar y aprobar o rechazar las solicitudes de cambios que estén pendientes y evaluar los planes de acción desarrollados para cada cambio; en particular el comité evaluará: • ¿Cuáles son los beneficios esperados del cambio propuesto? • ¿Está justificado el cambio, e acuerdo con ese costo? • ¿Cuáles son los riesgos asociados? • ¿Cuáles son las acciones de mitigación para esos riesgos, que se han incluido en el plan de acción? • ¿Se dispone de los recursos necesarios para realizar el cambio con éxito? • ¿Cuál será el impacto sobre la infraestructura y la calidad de los servicios TI? • 104

¿Permitirá el cambio mantener los niveles de seguridad?


• ¿Puede postergarse el cambio? ¿Hasta cuándo? Una vez que un cambio se aprueba debe evaluarse la oportunidad en que el cambio debe ser implementado. Para establecer la mejor oportunidad, dependiendo de la categoría del cambio, el comité de cambios preferirá convocar una reunión del comité de cambios ampliado – integrado por los miembros del comité de control de cambios más las partes afectadas por un cambio en particular-. En cualquier caso siempre deberá informarse formalmente tanto a los usuarios involucrados o afectados por el cambio, como al centro de atención, con el fin de que conozcan los eventos que podrían eventualmente generar problemas. La oportunidad del cambio permitirá concretar y detallar los cronogramas que deberá detallar el grupo implementador -responsable de llevar a cabo la implantación del cambio- y de comunicarlo a todos los involucrados.

6.- Implementación La administración de cambios no incluye las responsabilidades de implantación de los cambios, ya que dicha implantación será responsabilidad de alguna unidad técnica -de soporte o sistemas-, que hemos denominado el grupo implementador, con el apoyo del personal de diferentes unidades, que hemos denominado grupo de soporte. Muchos de los cambios serán implementados bajo el control de los procedimientos de administración de versiones. Sin embargo, especialmente para los cambios complejos o de alta prioridad, el administrador de cambios monitorizará el proceso de cambio para asegurar que se cumplen los cronogramas previstos y la adecuada asignación de recursos, tanto para el grupo implementador, como para el grupo de soporte. Es importante velar por una buena comunicación; al momento de implantarse el cambio; ningún usuario, proveedor o técnico del centro de atención debe ignorar que se está realizando un cambio. Será responsabilidad de la administración de cambios y del centro de atención mantener informados a los usuarios sobre los cambios y facilitar su aceptación: • • •

Escuchando sus sugerencias. Comunicando las ventajas asociadas. Aclarando dudas y brindando soporte cuando sea necesario.

105

Capítulo VII

•

Asegurando que los usuarios y clientes perciban todo cambio como mejora.

7.- Evaluación Antes de dar por concluido un proceso de cambio, será necesario realizar una evaluación que determine el valor y la verdadera contribución a la calidad del servicio y a la productividad de los usuarios. Al realizar esa evaluación, deberán considerarse aspectos como: • ¿Se cumplieron los objetivos previstos? • ¿En que medida hubo desviaciones con respecto a la planificación? • ¿Fue necesario utilizar los planes de retorno o back-out? ¿Por qué? • ¿Provocó el cambio algún problema o interrupción no prevista del servicio? • ¿Cuál ha sido la percepción de los usuarios en relación al cambio? Si la evaluación final determina que el proceso y los resultados han sido satisfactorios se procederá al cierre de la solicitud de cambio.

8.- Evaluación de la disciplina Para evaluar el desempeño de la disciplina de administración de cambios será importante generar informes periódicos que ofrezcan una información precisa de las acciones cumplidas y presenten una métrica cubriendo aspectos como: • Solicitudes de cambio recibidas. • Proporción de solicitudes aprobadas y rechazadas • Cantidad de cambios implementados, clasificados por impacto y prioridad. • Cantidad de cambios de emergencia realizados. • Porcentaje de cambios exitosos en primera instancia, segunda instancia, etc. • Numero de retornos o backouts detallando las razones de su aplicación. • Evaluaciones post-implementación. • Porcentajes de cambios cerrados sin incidencias posteriores. 106


•

Incidencias asociadas a los cambios realizados.

•

Número de reuniones del comité de cambios, indicando cantidad de asistentes, duración, cantidad de cambios evaluados por reunión, etc.

107

Capítulo VII

Esquema de la administración de cambios

108

Capítulo VIII

M onit oriza c ión y Cont rol

Capítulo VIII

Monitorización y control Tabla de contenido 1.- ¿En qué consiste monitorización y control? .............................111 1.1.Ventajas ...........................................................................113 1.2.Barreras............................................................................114 2.- Ciclo de monitorización............................................................114 3.- Terminología ............................................................................115 4.- Herramientas.............................................................................116 5.- Niveles de monitorización ........................................................117 6.- Formas de monitorización ........................................................118 7.- Implementación de la disciplina ...............................................119 8.- Evaluación de la disciplina .......................................................119

110

Monitorización y control


1.- ¿En qué consiste monitorización y control? De acuerdo con el diccionario de la Real Academia Española, monitorizar es la acción de “observar mediante aparatos especiales el curso de uno o varios parámetros fisiológicos o de otra naturaleza para detectar posibles anomalías”. En informática hemos adoptado el término, dándole un sentido similar, el de observar el comportamiento de los componentes de la infraestructura tecnológica, con el fin de detectar cualquier anomalía. Coincidiendo con la definición del DRAE, estas actividades de observación, normalmente se hacen mediante componentes de hardware y software especialmente diseñados para ello. Los problemas de desempeño de la infraestructura de TI pueden causar dos tipos de dificultades para el negocio: 1. Caídas de sistema (Hard Downtime), cuando los equipos fallan o se presentan problemas físicos que provocan que los usuarios no puedan continuar con su trabajo. 2. Bajo desempeño (Soft Downtime) de los sistemas que integran la red, los servidores las aplicaciones, los dispositivos de interconexión, los segmentos, enlaces, etc. que puede ser causado por múltiples factores, pero que afectan el trabajo de los usuarios, impidiendo que este pueda cumplirse con la dinámica requerida. Cuando ocurre una caída del sistema, se detienen las transacciones y se interrumpen los servicios al cliente, lo cual acarrea pérdidas a la empresa. Cuando se degradan los servicios, las consecuencias son menos catastróficas, sin embargo, la experiencia muestra que estos “Soft Downtime” son más costosos para las empresas, porque ocurren con mayor frecuencia. Las caídas de sistema pueden ser ocasionadas por una enorme variedad de factores, por lo que la tarea de identificar la raíz de los 111

Capítulo VIII

problemas normalmente es una tarea muy compleja. Como ejemplo podemos citar fallas que pueden presentar elementos como: servidores, cableado estructurado, equipos de red, aplicaciones, protocolos de comunicación, enlaces, PC’s, etc. Como causas de falla pueden citarse: fallas físicas, errores de configuración, errores de programación, ataques de virus, etc. Dado que esta diversidad de fallas causa pérdidas tanto tangibles, como intangibles –imagen, prestigio, etc.- a la empresa, resulta crucial poder contar con la capacidad de detectar las fallas desde la raíz, de la forma más rápida y precisa posible. Es decir, es necesario monitorizar y analizar el desempeño de los diferentes elementos de TI, para poder identificar dónde están los problemas y cuáles son sus causas. La disciplina de monitorización y control es la disciplina encargada de supervisar y controlar los componentes de la infraestructura, así como también de observar su funcionamiento para enviar alertas sobre las condiciones de salud -características que indican éxito o falla- de la infraestructura y, cuando sea posible, corregir automáticamente las fallas detectadas.

112


Dentro de la administración de servicios de TI, monitorización y control, junto con administración de configuraciones son las dos disciplinas que requieren mayor ayuda de herramientas adecuadas para su funcionamiento y que sin éstas son prácticamente imposibles de implementar. Lo usual para el cumplimiento de la disciplina es que el grupo de técnicos de monitorización, ubicados en un local acondicionado especialmente, dispongan de varios monitores que permiten visualizar la representación gráfica de diferentes nodos o secciones de la infraestructura. En estos monitores se pueden visualizar las diferentes situaciones que se van detectando, de acuerdo con los modelos de salud que se hayan definido. En un modelo de salud se establece la información que debe ser recolectada por los diferentes agentes o herramientas de monitoreo y cómo el sistema o los técnicos deben responder a los diferentes valores. Normalmente, las herramientas de monitorización ofrecen la facilidad de presentar gráficamente -utilizando indicadores con color verde o rojo- la situación de la infraestructura, para que los técnicos puedan determinar de un vistazo si hay un problema en alguno de los sistemas o de los componentes. La disciplina de monitorización y control produce como subproducto una gran cantidad de información de gran utilidad para ser utilizada por otras disciplinas, facilitando su cumplimiento, como es el caso de la administración de niveles de servicio y la administración de disponibilidad.

1.1.- Ventajas La implantación de la disciplina de monitorización y control puede brindar múltiples ventajas, entre las que cabe citar las siguientes: • Capacidad para anticipar algunos problemas en el servicio. •

• • •

Resolución más rápida de los problemas reales y potenciales de servicio, cuando se utilizan herramientas que permiten tomar acciones correctivas automatizadas. Soporte más dinámico a la ejecución de las operaciones del negocio. Disponibilidad de información sobre el funcionamiento de la infraestructura tecnológica. Mayor disponibilidad de los servicios. 113

Capítulo VIII

• • • •

Mejor comprensión de los componentes que, dentro de la infraestructura, son prioritarios para la entrega de servicios. Mayor satisfacción de los usuarios. Respuestas más rápidas y más eficaces a los incidentes. Reducción de la cantidad de incidentes por la aplicación de acciones preventivas.

1.2.- Barreras La disciplina de monitorización y control tropieza con una serie de barreras como las que a continuación enumeramos: • No se adoptan herramientas adecuadas. • No se adiestra debidamente al personal. •

•

• •

No se crea el ambiente de trabajo adecuado, para que el personal de monitorización pueda operar con comodidad y disponga de facilidades de comunicación. Si la capacidad de la infraestructura de TI es demasiado limitada, las exigencias de proceso y tiempo de respuesta de las herramientas de monitoreo podrían afectar el desempeño general. No se establecen vínculos ágiles con las restantes disciplinas. No se aprovecha la información que reúne el proceso de monitorización, para ser utilizada por las restantes disciplinas de servicio.

2.- Ciclo de monitorización

114


Tal como podemos observar en la figura, el ciclo de monitorización y control observa un proceso o una actividad o su resultado, comparando tales mediciones con una norma preestablecida o estándar, con el fin de determinar si el proceso se está cumpliendo dentro de los parámetros de calidad y desempeño. En caso de que el estándar no se esté cumpliendo, debe desencadenarse una acción correctiva que, dependiendo de la sofisticación de las herramientas y de la naturaleza del problema, puede ser una acción correctiva que se dispare automáticamente o la generación de un reporte de incidente, para que, de acuerdo con lo establecido por las disciplinas de manejo de incidentes y de problemas, se tomen las acciones necesarias.

3.- Terminología Con el fin de asegurar que los procedimientos se establezcan sin ambigüedades, es importante tener claras varias definiciones importantes para esta disciplina: 1. Servicio Un servicio es una función que se realiza para el negocio y que, por lo tanto, debe definirse desde ese punto de vista; por ejemplo, los servicios de correo electrónico y los de impresión pueden ser considerados como un servicio, independientemente del número de componentes o ítems de configuración que intervienen en su entrega. 2. Catálogo de servicios Los servicios que se prestan en una organización de TI, se registran en el catálogo de servicios, en este catálogo, creado y manejado por los administradores de monitorización y control, se incluye también un desglose de los componentes de la infraestructura que soporta la producción del servicio, denominados componentes del servicio. 3. Instrumental El instrumental lo integran las herramientas y los mecanismos que se utilizan para determinar el estado de un componente. No siempre es posible disponer de instrumentos para monitorizar la salud de algunos componentes, especialmente para muchos de los componentes de software. 4. Componentes de servicio Los componentes de servicio son ítems de configuración, cuya información se encuentra almacenada en la base de datos de 115

Capítulo VIII

componentes. Aquellos componentes de servicio para los que se dispone el instrumental necesario para determinar su salud, podrán ser observados continuamente, para determinar la salud total de un servicio. 5. Patrón de salud En un patrón de salud se definen las condiciones que permiten determinar que un servicio está funcionando en condiciones normales o presenta fallas. Estos patrones son indispensables para que los sistemas y el equipo humano de monitorización y control puedan discernir si un determinado servicio está funcionando satisfactoriamente.

4.- Herramientas Si bien todas las disciplinas de administración de servicios requieren herramientas que, con diversos grados de sofisticación, faciliten su proceso, en el caso de la disciplina de monitorización y control es de crucial importancia dotarla de herramientas robustas y de amplio alcance. Así pues, las herramientas que se seleccionen deberán tener características como las siguientes: 1Alta disponibilidad .Deben operar bajo ambientes de alta disponibilidad, como “clusters”, etc. y deben haber sido desarrolladas con facilidades que les permitan ofrecer una alta disponibilidad. 2Arquitectura compatible. Obviamente, las herramientas de monitorización y control deben ser compatibles con la infraestructura instalada. 3Adaptabilidad Las herramientas de monitorización y control deben tener la capacidad de operar en redes donde se combinan diferentes topologías. 4Agilidad de notificaciones Deben tener capacidad para notificar a los técnicos en las consolas de monitoreo y también para notificar a técnicos responsables de los servicios que presenten alguna condición, en la forma más rápida posible.

116


5-

6-

7-

8-

9-

10-

11-

12-

Presentación gráfica Deben tener capacidad para mostrar en forma simple, preferiblemente en forma gráfica, cualquier anomalía detectada en cualquiera de los componentes monitorizados. Autodescubrimiento Deben tener, en lo posible, la capacidad de identificar los cambios que se hagan en la infraestructura. De bajo impacto. Deben tener agentes de supervisión livianos, que causen un mínimo impacto en el desempeño de la infraestructura que se supervisa. Escalabilidad Deben tener la capacidad de crecer, a medida que crece la cantidad de objetos manejados y el número de acontecimientos simultáneos que debe procesar en un momento dado. Interoperabilidad. Deben satisfacer los requerimientos de interoperabilidad, integrándose con otras herramientas de administración de servicios Base de datos. Deben almacenar los datos del funcionamiento de la infraestructura, para ser utilizados por otras disciplinas de administración de servicios. Base de conocimiento. Deben ofrecer facilidades para almacenar los conocimientos que se vayan derivando de las experiencias, para uso de los técnicos de monitorización. Seguridad. Deben cumplir con requerimientos de seguridad, tal como niveles de acceso y autorizaciones basadas en roles.

5.- Niveles de monitorización Podemos distinguir dos niveles de monitorización: 1- El nivel interno El nivel interno de monitorización centra su atención en los componentes de la infraestructura, evaluando su correcto funcionamiento.

117

Capítulo VIII

2- El nivel externo El nivel externo de monitorización centra su atención en los servicios -como correo, impresión, base de datos, etc.independientemente de la multiplicidad de los componentes que intervienen en su producción. Un buen servicio de monitorización debe combinar ambos niveles, con el fin de poder establecer tanto la calidad de los servicios, como la adecuación de la infraestructura y sus componentes.

6.- Formas de monitorización 1-

2-

3-

4-

118

Existen varias formas de monitorizar una infraestructura de TI: Activa o pasiva La monitorización activa consiste en la interrogación que se hace sobre un dispositivo o un sistema. La monitorización pasiva es la que se hace utilizando un agente que envía señales o mensajes que permiten identificar diferentes situaciones en un dispositivo o sección de la infraestructura. Reactiva o preventiva En una monitorización reactiva, se diseña una o más acciones que deberán ser tomadas en caso de que se determine cierta condición. La monitorización preventiva consiste en analizar un conjunto de patrones de comportamiento que permiten predecir un problema. Este tipo de monitorización es más común en organizaciones maduras, en las que la disciplina de monitorización ha logrado acumular experiencias significativas. De medición continua o por excepción La medición continua corresponde a una medición en tiempo real para asegurar que el componente o el sistema que se monitorea están funcionando dentro de los estándares preestablecidos. La monitorización por excepción no realiza una medición, sino que descubre y reporta alguna excepción, como puede ser la terminación anormal de algún programa. Desempeño o resultado La monitorización de desempeño se centra en el funcionamiento de los componentes, mientras que la monitorización a los resultados se centra en la calidad del output producido. Cabe señalar que en ITIL se presta mayor atención a los procesos.


Para cada tipo de componente o servicio que se desee monitorizar siempre habrá la mejor combinación de tipos de monitorización, por lo que podemos afirmar que un buen servicio de monitorización debe combinar los diferentes tipos.

7.- Implementación de la disciplina Indudablemente, una de las disciplinas más difíciles de implementar y adaptar es la disciplina de monitorización y control. En cualquier organización, grande o pequeña, sólo será posible lograr resultados exitosos si su implementación se va haciendo gradualmente y para cada grupo de componentes y servicios que se vayan incorporando a la disciplina ir instalando herramientas, estableciendo procedimientos, adiestrando al personal y comunicando a toda la organización los progresos que se vayan haciendo. Así pues, para cada etapa será necesario cumplir pasos como los siguientes: • Determinar qué se va a monitorizar. • Determinar qué nivel de monitorización. • • • • •

Establecer qué formas de monitorización se combinarán. Establecer qué formas de monitorización pueden aplicarse Seleccionar las herramientas a utilizar. Desarrollar procedimientos. Adiestrar el personal de monitorización.

•

Adiestrar el personal de otros departamentos.

8.- Evaluación de la disciplina Si bien es importante evaluar el desempeño de cualquiera de las disciplinas de administración de servicios, en el caso de monitorización y control es fundamentalísimo evaluar su desempeño y la utilidad que presta a la organización. Con tal fin, pueden o deben producirse mediciones, métricas e indicadores clave, entendiendo estos conceptos de la siguiente forma: 1Mediciones Una medición se refiere a las técnicas para evaluar el alcance, la dimensión o la capacidad de algún ítem de configuración, con respecto a una norma.

119

Capítulo VIII

2-

3-

120

Métricas Una métrica es el conjunto de procedimientos que se cumplen para evaluar cuantitativamente con cierta periodicidad un proceso o un sistema, junto con los procedimientos para interpretar los resultados. Es decir, en una métrica se establece lo que se va a medir, la forma como se va a medir y la forma como se van a interpretar los resultados. Indicadores clave Un indicador clave corresponde a un nivel de desempeño o medición, establecido y acordado previamente, para calificar la efectividad de una organización o de un servicio.

Capítulo IX

Adm inist ra c ión de N ive le s de Se rvic io

Capítulo IX

Administración de niveles de servicio Tabla de contenido 1.- ¿En qué consiste la administración de niveles de servicio?......123 1.1.Ventajas ...........................................................................124 1.2.Barreras............................................................................125 2.- Terminología ............................................................................125 2.1.Proveedores, clientes y usuarios ......................................125 2.2.Catálogo de servicios - Service Catalog (SC)..................126 2.3.Acuerdo de nivel de servicio............................................127 2.4.Acuerdo de nivel operacional (OLA) ..............................127 2.5.Programa de calidad de servicio (SQP) ...........................128 3.- Creación del catálogo de servicios ...........................................128 4.- Proceso .....................................................................................130 4.1.Preparación ......................................................................130 4.2.Seguimiento .....................................................................131 4.3.Revisión continua ............................................................132 5.- Evaluación de la disciplina .......................................................132

122

Administración de niveles de servicio


1.- ¿En qué consiste la administración de niveles de servicio? Es frecuente presenciar discusiones sobre la calidad de un servicio, mientras unos opinan que es adecuada, otros opinan que no, que es de bajo nivel. Es muy difícil establecer quién tiene la razón si no existe, para ese servicio, un patrón que defina cuando es de calidad y cuando no lo es. Ese es el origen de los niveles de servicio, poder establecer los patrones de calidad para cada uno de los servicios que presta la organización de informática y tomar las acciones necesarias para asegurar que tales servicios se ajusten a ese patrón. Claro está, la idea anterior es un poco simplista, ya que la disciplina de administración de niveles de servicio es un poco más que eso, ya que esta disciplina debe velar por la calidad de los servicios TI, alineando tecnología con procesos de negocio, dentro de unos niveles de costo razonables. Para cumplir esos objetivos resulta imprescindible que la administración de niveles de servicio: • Conozca las necesidades de sus usuarios. • Establezca los rangos de costo que pueden acarrear los diferentes niveles de calidad –a mayor calidad mayor costo-. • Acordar con los usuarios los niveles de calidad requeridos para los servicios que reciben, dentro de rangos de costo razonables. • Monitorizar que la calidad de los servicios cumplen con los acuerdos establecidos. • Establecer planes de acción para mejorar en forma continua la calidad del servicio. Así pues podemos decir que la administración de niveles de servicio es el proceso por el cual se define, negocia y supervisa la calidad de los servicios TI. Para ello, la disciplina busca establecer compromisos 123

Capítulo IX

realistas entre las necesidades y expectativas del usuario o cliente y la posibilidad de satisfacerlas a un costo razonable. En líneas generales, podemos decir que la administración de niveles de servicio debe incluir actividades como las siguientes: • Documentar los servicios que ofrece TI. • • •

•

• •

Presentar los servicios en forma comprensible para el usuario. Centrar la atención en el usuario y sus procesos, no en la tecnología. Trabajar con el usuario para determinar niveles de calidad para los servicios que requiere, dentro de parámetros realistas y ajustados a sus necesidades reales. Establecer los indicadores claves de rendimiento del servicio TI, que permitan verificar si se cumplen los niveles de calidad acordados. Monitorizar la calidad de los servicios acordados, buscando en todo momento mejorarlos a un costo razonable. Elaborar los informes sobre la calidad del servicio y planes de mejora.

1.1.- Ventajas La adopción de la disciplina de administración de niveles de servicio, puede tener las siguientes ventajas: • Los servicios TI se ajustan para cumplir las necesidades de los usuarios. • • • • • •

124

Se simplifica la comunicación con los usuarios y se evitan los malentendidos sobre la calidad de los servicios requeridos. Se establecen objetivos claros y mesurables. Se establecen claramente las responsabilidades tanto de TI, como de los usuarios. Los usuarios toman conciencia y aceptan los niveles de calidad ofrecidos. El seguimiento permanente del servicio permite detectar debilidades y aspectos a mejorar. El personal del centro de atención dispone de la documentación necesaria para llevar una relación fluida con usuarios, clientes y proveedores.


•

Los acuerdos de servicio, permiten que la gerencia de TI pueda calcular los costos y justificar sus presupuestos. • El esquema que aplica TI con sus usuarios, puede ser adoptado con sus proveedores, con el fin de asegurar una calidad creciente de sus servicios. Todo lo cual repercutirá en un mejor servicio y la consecuente satisfacción de usuarios y ejecutivos de la empresa.

1.2.- Barreras Una de las disciplinas más difíciles de adoptar es la administración de niveles de servicio, pues tropieza con innumerables barreras, como las que citamos a continuación: y No existe un verdadero compromiso con la calidad de los servicios ofrecidos por TI. y No se alinean adecuadamente los servicios TI con los procesos del negocio. y No existe una buena comunicación con los usuarios por lo que los acuerdos de niveles de servicios no expresan las necesidades reales. y Los acuerdos de niveles de servicio están basados más en deseos y expectativas del cliente que en las capacidades reales que la infraestructura TI permite ofrecer. y Los acuerdos de servicio incluyen demasiados detalles técnicos, lo cual impide que los usuarios se identifiquen con ellos. y No se asigna suficiente personal calificado a la administración de niveles de servicio. y Por fallas de comunicación, algunos usuarios desconocen las características de los acuerdos. y No se monitoriza adecuada y consistentemente el cumplimiento de los niveles de servicio, lo cual minimiza el valor de la disciplina y dificulta la posibilidad de mejorar la calidad del servicio.

2.- Terminología 2.1.- Proveedores, clientes y usuarios Cliente es una empresa u organismo que contrata los servicios de TI. Los usuarios son las personas que utilizan los servicios de TI para el cumplimiento de sus funciones.

125

Capítulo IX

Proveedor es una empresa u organismo que presta los servicios que requiere un cliente.

2.2.- Catálogo de servicios - Service Catalog (SC) El catálogo de servicios es una herramienta que contribuye al conocimiento y comprensión de los procesos de TI y resulta de enorme ayuda para establecer una comunicación clara con clientes y usuarios. Un catálogo de servicios debe incluir: y Descripción de los servicios ofrecidos en forma comprensible para los clientes y personal no especializado. y Una guía para orientar a los usuarios y clientes, facilitando su uso. y Los niveles de servicio asociados con cada uno de los servicios ofrecidos. Los catálogos de servicio deben estar disponibles para ser consultados por cualquier técnico de TI y especialmente por los del centro de atención. Normalmente, se facilitará su acceso, publicándolos en la intranet o en los archivos públicos de la red. Como ejemplo de los servicios que podrían estar en un catálogo de servicios TI podríamos citar los siguientes: Servicio de telefonía Servicio de fax Servicio de acceso externo Conexión inalámbrica Servicio de impresoras para grupos de usuarios Centro de reproducción Servicio de mensajería electrónica Servicio de envío de mensajes SMS Servicios de acceso a internet Servicios de intranet Servicio de videoconferencia Servicio de salvaguarda y restauración de datos Servicio de archivos públicos y privados en la red Servicio de administración de usuarios (nuevos y cambios) Servicios para las estaciones de trabajo: o Servicio de instalación, mantenimiento y renovación de equipamiento estándar 126


o o o

Servicio de instalación y mantenimiento de software base Servicio de adquisición de software especial Servicio de prevención, detección y eliminación de virus y malware

2.3.- Acuerdo de nivel de servicio - Service Level Agreement (SLA) Un acuerdo de nivel de servicio presenta en un lenguaje no técnico, fácilmente comprensible para el usuario, los detalles de los servicios que se le brindan. Su aceptación por ambas partes –función y TI- constituye el marco de referencia para la relación con el TI-usuario en todo lo que referente a los servicios acordados. En este tipo de acuerdos, normalmente se incluyen los aspectos más esenciales del servicio como su descripción, nivel de disponibilidad, niveles de calidad, tiempos de recuperación, etc. Los acuerdos de nivel de servicio pueden ser de dos tipos: • Basados en el servicio Un acuerdo de nivel de servicio basado en el servicio es un acuerdo genérico, que se aplica para todos los usuarios, como pueden ser los acuerdos de servicio para el correo electrónico o los servicios de telefonía. • Basados en el usuario Un acuerdo de nivel de servicio basado en el usuario, como su nombre lo indica, es un acuerdo que se establece para un grupo específico de usuarios, tomando en cuenta sus necesidades específicas, como puede ser un servicio de información o el servicio de una aplicación particular.

2.4.- Acuerdo de nivel operacional - Operational Level Agreement (OLA) Un acuerdo de nivel operacional es la contrapartida del acuerdo de nivel de servicio; es un documento interno de la organización TI en el que se establecen las responsabilidades y los compromisos que adquiere cada unidad dentro de TI, con el fin de asegurar el cumplimiento de los niveles de servicio acordados con los usuarios.

127

Capítulo IX

2.5.- Programa de calidad de servicio - Service Quality Program (SQP) Un programa de calidad de servicio complementa los aspectos establecidos en los acuerdos de niveles de servicio y en los acuerdos de niveles operacionales, con el fin de establecer cuáles son los aspectos que deben ser monitorizados para que dichos acuerdos se cumplan cabalmente. Así pues, en un programa de calidad de servicio se incluye toda la información necesaria para administrar eficientemente los niveles de calidad de cada servicio en particular, como por ejemplo: • Objetivos de cada servicio • Estimación de recursos • Indicadores clave de rendimiento •

Procedimientos de monitorización

3.- Creación del catálogo de servicios Una de las tareas importantes para poder darle viabilidad a varias disciplinas de administración de servicios y en especial a la administración de niveles de servicio, es la creación del catálogo de servicios. Para su creación deben cumplirse varios pasos como los siguientes: 1. Identificación de servicios TI Entenderemos por servicio de TI el conjunto de capacidades tecnológicas y/o profesionales que por sus características son percibidas por el usuario como un todo, utilizado para dar soporte a sus operaciones, como son los servicios de impresión, correo, etc. Para identificar los servicios, se deberán revisar los diferentes procesos que cumplen los usuarios e ir identificando los diferentes elementos tecnológicos que apoyan su realización. De esta forma se desarrollará una definición de servicios hecha desde la perspectiva del negocio y no desde un punto de vista técnico. 2. Caracterización de los servicios de TI Desarrollar una descripción formal y completa de los servicios de TI, incluyendo elementos como los siguientes: • Nombre del servicio • Responsable del servicio en TI 128


•

Procesos y usuarios del servicio

• •

Servicios de TI relacionados Especificaciones del servicio de TI, incluyendo: Descripción del servicio - narrativo Elementos o componentes tecnológicos que intervienen Horario Criticidad Nivel de servicio requerido 3. Definición de métricas Establecer las mediciones que se deben o pueden aplicar, para establecer los niveles de calidad del servicio: • Disponibilidad • Capacidad actual y potencial de crecimiento con la infraestructura actual •

Calidad o percepción del usuario sobre la calidad del servicio. 4. Definición de interrelaciones Desarrollar la especificación de los ítems de configuración u otros servicios TI que participan en la producción de cada servicio. Esta información, será crucial para poder evaluar los recursos necesarios para ofrecer cada servicio con el nivel de calidad necesario o, si fuese necesario contratar servicios de outsourcing, permitirá establecer las bases de contratación. Cumpliendo los pasos arriba señalados, podrán identificar los servicios de TI, se podrán establecer cuáles son sus aspectos y componentes más relevantes y se podrán definir métricas específicas, útiles para cuantificar y valorar cada servicio. La elaboración del catálogo de servicios puede resultar una tarea compleja pues es necesario alinear muchos aspectos técnicos con políticas del negocio, pero es un documento cuya importancia no puede exagerarse, ya que: • • •

Delimita las funciones y compromisos de la organización TI Evita malentendidos entre los diferentes actores implicados en la prestación de servicios Sirve de base para el desarrollo de la administración financiera 129

Capítulo IX

•

Sirve de guía para el personal del centro de atención

4.- Proceso Las principales actividades que conforman la disciplina de administración de niveles de servicio pueden resumirse como: • Preparación • Seguimiento •

Revisión continua

4.1.- Preparación Las actividades de preparación de la administración de niveles de servicio requieren la participación y el compromiso de toda la organización TI, así como también la colaboración activa de los usuarios de los servicios TI. El proceso de preparación incluye todas las tareas para desarrollar: • Catálogo de servicios • • 130

Requerimientos de nivel de servicios Acuerdos de niveles de servicios


•

Acuerdos de nivel operacional

• Programa de calidad de servicio Es frecuente que, aunque el catálogo de servicios sea detallado y completo, la complejidad de los servicios ofrecidos requiera un proceso de negociación con el cliente, que, en definitiva, permita depurar la definición de requerimientos y acuerdos de niveles de servicio. En primer término, los resultados de esta negociación permitirán clarificar los requerimientos de nivel de servicio, estableciendo las necesidades del usuario en los siguientes términos: • Descripción y características del servicio • Disponibilidad y continuidad requerida • Nivel de calidad o forma de calificar el nivel de calidad A su vez, la información de requerimientos permitirá desarrollar los acuerdos de niveles de servicio y de niveles operacionales, estableciendo, como paso previo: • La descripción del servicio con todos los detalles técnicos necesarios sobre cómo se presta –o prestará- el servicio. • Cuáles podrían ser los indicadores de calidad del servicio • Quiénes son los responsables técnicos En función de los requerimientos de servicio y la información desarrollada se puede elaborar un plan de acción que permita establecer metas claras basadas en los indicadores de calidad, asignar los recursos de la organización TI y asegurar que los niveles de calidad comprometidos se adaptan a las necesidades de los clientes y a las capacidades de la organización. En los casos en los que se determine que los recursos existentes no son suficientes o se considere oportuno tercerizar parte de los servicios, el plan de calidad de servicio servirá de documento base para negociar los contratos con proveedores externos. La fase de planificación concluye con la aceptación de los acuerdos de servicio y su puesta en vigor para la prestación del servicio de TI.

4.2.- Seguimiento Una vez establecidos los acuerdos de servicio, será necesario verificar que día a día se cumplen, determinar las causas de cualquier desviación y establecer las acciones para mejorar continuamente la calidad del servicio. Puede afirmarse que el proceso de monitorización o seguimiento 131

Capítulo IX

de los niveles de servicio es imprescindible si se desea mejorar la calidad del servicio ofrecido, su rentabilidad y la satisfacción de los usuarios. El seguimiento de los niveles de servicio requiere una constante monitorización sobre el cumplimiento de los procedimientos, de los parámetros de medición establecidos y de la percepción de los usuarios. Para cumplir esta tarea de manera eficiente es necesario haber alcanzado un punto de madurez en las disciplinas de administración de servicios que facilite la integración perfecta entre las disciplinas de monitorización y control, administración de disponibilidad, administración de la capacidad, centro de atención, manejo de incidentes, manejo de problemas, administración de cambios y administración de la configuración.

4.3.- Revisión continua La administración de niveles de servicio debe diseñarse como un proceso continuo que incluye también la continua revisión de los servicios ofrecidos y los niveles acordados. Esta revisión debe realizarse con base en las experiencias, los acuerdos vigentes y la evolución que tengan la infraestructura y el catálogo de servicios. El proceso de revisión no debe limitarse a aquellos acuerdos de servicio que por una razón u otra no han sido cumplidos, sino que debe tener un amplio alcance, siempre con la meta de mejorar continuamente la calidad del servicio, tomando en cuenta aspectos como: • Problemas del servicio TI y sus posibles causas • Nuevas necesidades del cliente • Avances tecnológicos • • •

Experiencias en el cumplimiento de los niveles de servicio Evaluación de los costos reales del servicio Implicaciones de una degradación de la calidad del servicio en la estructura organizativa del cliente • Percepción de los usuarios sobre la calidad de servicio El proceso de revisión permitirá que se lleven a cabo nuevas negociaciones y se renueven los acuerdos de servicio.

5.- Evaluación de la disciplina Es claro que el objetivo de la administración de niveles de servicio no es otro que el de mejorar la calidad del servicio y la satisfacción del cliente; tal propósito requiere una continua revisión de los 132


procedimientos, para lo cual será importante poder contar con información y reportes como se señala a continuación: •

•

•

•

Indicadores de desempeño como: Avance de la disciplina, indicando el porcentaje de servicios amparados bajo acuerdos de niveles de servicio Porcentaje de incumplimiento de los acuerdos de niveles de servicio clasificados por su impacto en la operación de los usuarios Encuestas de satisfacción del cliente. Informes estadísticos de desempeño en los que se detalle el nivel de cumplimiento de los acuerdos, los costos asociados al proceso, etc. Informes de periódicos de seguimiento, especificando las acciones de seguimiento que se realizan, sus resultados y el grado de satisfacción de los clientes Planes de mejora en los que se especifiquen tanto medidas correctivas a las fallas detectadas, como propuestas de mejora basadas en la experiencia o en los avances que se introduzcan en la plataforma tecnológica.

133

Capítulo IX

134

Capítulo X

Adm inist ra c ión Fina nc ie ra de T I

Capítulo X

Administración Financiera de TI Tabla de contenido 1.- ¿En qué consiste la administración financiera de TI?...............137 1.1.Ventajas ...........................................................................138 1.2.Barreras............................................................................138 2.- Terminología ............................................................................138 2.1.Costos y gastos.................................................................139 2.2.Depreciación y amortización ...........................................141 3.- Planificación .............................................................................142 3.1.Catálogo de servicios .......................................................143 3.2.Costeo de servicios ..........................................................144 3.3.Proyectos..........................................................................145 3.4.Costeo de proyectos .........................................................145 4.- Elaboración del presupuesto .....................................................146 5.- Contabilidad .............................................................................147 6.- Actividades de la administración financiera de TI ...................148 7.- Evaluación de la disciplina .......................................................150

136

Administración financiera de TI

Administración Financiera de TI

1.- ¿En qué consiste la administración financiera de los servicios de TI? A pesar de que casi todas las empresas y organizaciones utilizan las tecnologías de la información para apoyar prácticamente todos sus procesos de negocio, es muy común que no exista una conciencia real de los costos de esta tecnología y de los servicios que presta; esto hace que se desperdicien recursos o que no se presupuesten correctamente los gastos asociados. El propósito de la administración financiera de los servicios de TI es evaluar y controlar los gastos y costos que acarrean los servicios de TI y, dentro de lo posible, poder informar a la gerencia y a los usuarios de los costos asociados a cada uno de los servicios que reciben. En algunas empresas la administración financiera se limita a contabilizar y controlar los gastos y desembolsos de TI, mientras que en otras se busca determinar los costos de los diferentes servicios y la alícuota de los costos que le corresponde a cada una de las unidades del negocio, por concepto de los servicios de TI que reciben. Esta última práctica, es uno de los objetivos más importantes de la administración financiera de los servicios de TI, ya que ello permite que las unidades del negocio y los usuarios tomen conciencia del costo de los servicios, para que, como consecuencia, los controlen y aprovechen juiciosamente. Adicionalmente, una clara conciencia de costos permitirá que la función de TI pueda ajustar la calidad de sus servicios, dentro de parámetros de eficiencia. Como ya hemos señalado, la administración financiera de los servicios de informática tiene como objetivo central administrar de manera eficaz y rentable los servicios y la organización TI, permitiendo que esa organización funcione como una unidad de negocio, en la que sea posible evaluar su desempeño de manera transparente. Normalmente, en cualquier empresa, mientras mayor es la calidad de los servicios de TI, mayor es su costo, por lo que la administración 137

Capítulo X

financiera ayuda a establecer parámetros que permitan contrastar los costos con las necesidades de los usuarios y del negocio, con el fin de optimizar la razón calidad / costo. Tales propósitos pueden lograrse: • Evaluando los costos y gastos reales asociados a cada uno de los servicios. • Proporcionando a la organización TI toda la información exacta para la toma de decisiones. • Asesorando a usuarios y clientes sobre el valor añadido que proporcionan los servicios TI que reciben. • Evaluando el retorno de las inversiones TI.

1.1.- Ventajas La implantación de una adecuada administración financiera de los servicios de informática ofrece ventajas como las siguientes: • Pueden optimizarse los costos de los servicios • Puede mejorarse la rentabilidad de los servicios • La organización TI puede planificar mejor sus inversiones • Los servicios TI se utilizan con mayor eficiencia

1.2.- Barreras En general, las principales barreras que encuentra la implementación de la administración financiera de los servicios de TI son: • No es fácil encontrar personal que esté familiarizado tanto con los servicios TI como con aspectos financieros y/o contables. • No es sencillo determinar costos por servicio, pues existen muchos componentes de la infraestructura que son comunes a varios servicios. • Existen múltiple costos ocultos o difíciles de valorar. •

Es difícil lograr el compromiso de toda la organización TI con el proceso de administración.

2.- Terminología Para comprender los aspectos relacionados con la administración financiera es importante que revisemos, como primer paso, la terminología contable y presupuestaria relacionada.

138


2.1.- Costos y gastos En general diremos que costo es la suma de esfuerzos y recursos que se han invertido para producir algo. La contabilidad de costos consiste en una serie de procedimientos que tienen como propósito determinar el costo de un producto o un servicio y de los distintos elementos que se requieren para su producción. Es oportuno observar que entre costo y gasto, aunque puedan parecernos sinónimos, existen pequeñas diferencias de concepto. Por lo general un costo puede identificarse con un producto, servicio o ingreso; por ejemplo, en el caso de una aplicación los recursos invertidos para cubrir los sueldos de los programadores que han trabajado en su desarrollo se identifican claramente como componente del producto final. Hay una correspondencia clara entre un servicio o producto y los recursos requeridos para su producción. Con los gastos no ocurre lo mismo, un gasto es un sacrificio económico que se realiza para adquirir un bien o servicio requerido por la operación normal de la organización, pero que no puede identificarse con ningún servicio o producto en particular. En el giro normal de un negocio es imprescindible realizar gastos, ya que de otra forma este no podría funcionar, tal es el caso de los alquileres, de los servicios de electricidad, de los sueldos y salarios de los empleados administrativos, etc. Los gastos, normalmente afectan los resultados financieros de una empresa y se reflejan en su estado de ganancias y pérdidas. Si se desea determinar el costo real de los servicios que la organización TI produce, será necesario hilar fino, para identificar los gastos y hacer una distribución de éstos, de acuerdo a algún criterio que exprese la cantidad de gasto que debe atribuirse a cada servicio TI. En cualquier empresa, podemos encontrar una enorme variedad de rubros –conceptos- de costos y gastos que conforman el costo de los servicios de TI, entre ellos podemos citar: • Alquiler de equipos de computación • Mantenimiento de equipos de computación • Depreciación de equipos de computación • Costo de licencias de software • Alquiler de equipos de telecomunicaciones • •

Depreciación de equipos de telecomunicaciones Mantenimiento de equipos de telecomunicaciones 139

Capítulo X

•

Servicios de comunicación

• • • • • •

Gastos de personal Viáticos Servicios profesionales Servicios de outsourcing Alquiler de oficinas y locales Depreciación de mobiliario y equipos de oficina

• Repuestos • Servicios de capacitación y adiestramiento • Libros, revistas y suscripciones Desde el punto de vista de los servicios de TI, estos costos pueden ser de varias categorías: • Costos directos: Son los costos que se pueden relacionar específica y exclusivamente con un producto o servicio, como por ejemplo, cuando intentamos determinar el costo del servicio de internet, el costo de los servidores que están dedicados únicamente a soportar este servicio, constituyen un costo directo. Esto es hay una relación clara entre el rubro de costo y el servicio. • Costos indirectos: Son aquellos rubros que no son específicos o exclusivos de un servicio, como por ejemplo, cuando queremos calcular el costo de los servicios de una aplicación, podemos observar que esa aplicación comparte los servicios del servidor de bases de datos, del servidor de aplicaciones y los servicios de conexión a la red. Se hace, en estos casos, necesario establecer la “proporción” que de cada uno de esos servicios utiliza la aplicación. La determinación de estos costos es un poco más difícil, por lo general, se prorratean entre los diferentes servicios y productos que los utilizan. La dificultad estriba en que no siempre es clara la forma como se debe determinar la proporción de uso. Desde el punto de vista de su asociación con el funcionamiento de los servicios de TI, estos costos pueden ser de varias categorías:

140


•

•

Costos de operación En la lista de rubros de costo que mostramos, podemos observar que hay costos o gastos que están asociados al funcionamiento diario, como son los servicios de mantenimiento; estos costos se denominan costos de operación. Costos de capital Existen otros rubros de costo, como es la depreciación de los equipos o de las inversiones hechas para acondicionar los locales para los equipos, que se denominan costos de capital.

2.2.- Depreciación y amortización En contabilidad, el término depreciación es una rebaja o deducción que se le hace anualmente al valor de una propiedad, mueble o equipo, en razón de su desgaste. Por ejemplo, sabemos que un servidor puede tener una vida útil de unos cinco años y que después de ese período deberá ser reemplazado por un nuevo servidor con tecnología actualizada. Así pues, si para adquirir el servidor la empresa tuvo que desembolsar diez mil dólares -USA $ 10.000- podemos decir que cada año el servidor debe depreciarse en 2.000 dólares -10.000 entre 5 años-. Esto es, anualmente debe imputarse a los servicios que utilizan este servidor un monto de USA dólares 2.000. La depreciación en contabilidad permite determinar el valor real de las inversiones que hace una empresa, estableciendo la disminución que periódicamente sufre su potencial de servicio. Simultáneamente, la depreciación permite establecer el costo real que corresponde a los servicios de cada período. Para los contadores, la depreciación es la forma de asignar o atribuir el costo de las inversiones a los diferentes ejercicios en los que se hace uso o se disfruta de los activos adquiridos con esas inversiones. Los activos se deprecian basándose en diferentes criterios económicos: considerando el período de tiempo en el que serán utilizados para la actividad productiva –vida útil-, o considerando su utilización efectiva en dicha actividad –por ejemplo, por cada unidad producida-. La depreciación es, pues, una deducción anual que se hace al valor contable de las propiedades y los equipos, proporcional a su valor original. Al final de su vida útil, el valor contable de esas propiedades o equipos será cero.

141

Capítulo X

Un concepto parecido al de depreciación es el concepto de amortización, con la diferencia que la amortización no corresponde a ningún activo tangible, sino que corresponde a un gasto que realiza la empresa para cubrir varios ejercicios, como pudiera ser una prima de seguro o un alquiler que se pague adelantadamente. La alícuota de ese gasto que se imputa a cada ejercicio, se denomina amortización.

3.- Planificación La administración financiera se cumple en dos grandes ciclos o tiempos diferentes, uno corresponde a la elaboración del presupuesto, que constituye la expresión monetaria de los planes operativos de la unidad de TI. El otro, corresponde al ciclo de control, en el cual se lleva el cómputo de los gastos y costos reales.

La elaboración de los presupuestos requiere unos insumos fundamentales, que son los planes estratégico y operativo de TI. • Planes Estratégicos En general, los planes estratégicos de la empresa son planes cuyo horizonte es el largo plazo, entre 3 y 10 años, en los que se establecen los objetivos y lineamientos generales para la definición de los demás planes -tácticos y operativos-. Normalmente, los planes estratégicos son diseñados por los ejecutivos de mayor nivel dentro de la jerarquía de la empresa y su propósito es establecer la dirección que deberán seguir todas las actividades del negocio en los próximos años, para alcanzar los objetivos que se han propuesto. • Planes Estratégicos de TI Un plan estratégico de TI, corresponde al grupo de los planes tácticos que se desarrollan en la empresa; estos planes son más 142


específicos, normalmente definen el marco de actuación particular de un área del negocio, una división o un departamento y su horizonte es menor, entre 1 y 3 años. Los planes tácticos, como el PETI –plan estratégico de tecnología de información-, deben estar alineados y subordinados al plan estratégico de la empresa. Los ejecutivos del área son los encargados de definir los planes tácticos, con el fin de darle viabilidad a los objetivos estratégicos de la empresa, dentro del ámbito de su competencia o área del negocio. • Planes Operativos Los planes operativos son planes cuyo horizonte es el corto plazo, 1 año, que se formulan dentro de los parámetros establecidos por los planes táctico y estratégico. Tienen como función formular y asignar proyectos y actividades detalladas, que deberán ser ejecutadas por el nivel operativo del negocio. Normalmente, cada unidad organizativa formula sus planes operativos y este plan constituye la base para cuantificar y justificar sus requerimientos de recursos o presupuesto. En TI, la elaboración de presupuestos tiene como objetivos principales: • Planificar los gastos e inversiones de TI, para cumplir con las metas, compromisos y proyectos establecidos en el plan operativo de TI. • Analizar los requerimientos de flujo de caja, para asegurar que los servicios y los proyectos TI estarán financiados convenientemente. • Establecer los elementos que permitirán evaluar el desempeño de la organización TI. El presupuesto de una organización TI se construye sobre la base de dos componentes centrales, que se ajustan a los planes operativos: el catálogo de servicios y los proyectos que han sido propuestos para el período que se planifica.

3.1.- Catálogo de servicios El catálogo de servicios, como se discutió en el capítulo correspondiente a la administración de niveles de servicio, constituye el

143

Capítulo X

compendio de los servicios que produce TI para sus usuarios, en el que se incluye: y Descripción de los servicios ofrecidos en forma comprensible para los clientes y personal no especializado. y Una guía para orientar a los usuarios, facilitando su uso. y Los niveles de servicio asociados con cada uno de los servicios ofrecidos. Para la administración financiera de TI, el catálogo de servicios permitirá establecer los centros en los que se acumularán y distribuirán los costos y gastos de TI, de acuerdo con los criterios que se adopten para establecer la proporción que de cada rubro utiliza el servicio.

3.2.- Costeo de servicios Ciertamente, la determinación del costo de los servicios no es una tarea simple, pues existen muchos componentes de hardware, software y recursos, como el personal técnico, que intervienen en varios servicios y no siempre resulta clara la forma de establecer la proporción que debe atribuírsele a cada servicio. Por ejemplo, si queremos valorar los servicios de impresión, nos daremos cuenta que existen costos directos, perfectamente identificables, como son el costo de las impresoras –depreciación o alquiler-, el costo de los servidores de impresión –en caso de que existan servidores dedicados exclusivamente a los servicios de impresión-, los servicios de mantenimiento técnico de esos dos componentes –servidores e impresoras-, los gastos de cintas o de tonner, el consumo de papel, etc.; sin embargo, existen costos que no son tan fáciles de atribuir como son el uso de los componentes de la red y el personal técnico del centro de atención, que procesa los incidentes que se reportan cuando falla alguna impresora. Si quisiéramos tener un costo real de esos servicios, calculado al céntimo, deberíamos considerar otros elementos, como por ejemplo la parte proporcional del costo del local donde se hospedan los servidores de impresión, la electricidad que consumen tanto servidores de impresión como impresoras, los sueldos del personal de soporte que mantienen esos servidores en correcto funcionamiento, los administradores de TI que, entre muchas cosas, coordinan actividades para que esos servicios de impresión operen correctamente y dispongan de suministros. Es fácil comprender lo importante que será establecer límites a la complejidad que puede representar la valoración de los diferentes 144


servicios, ya que, de lo contrario, puede convertirse en “el cuento de nunca acabar” y hacer que todo el proceso de administración financiera de los servicios de TI resulte inviable. En líneas generales, la valoración de servicios debe determinar el costo de los servicios hasta un nivel que la empresa considere realista, con el fin de que ejecutivos y usuarios puedan tener una visión razonable de la magnitud de tales costos.

3.3.- Proyectos Junto con el catálogo de servicios, las carteras de proyectos de desarrollo o mantenimiento de la infraestructura tecnológica y de sistemas constituyen el universo de los costos de TI. Los proyectos son actividades grandes o pequeñas, que se cumplen una sola vez, con un propósito específico, como puede ser: desarrollar una aplicación, diseñar y cablear un segmento de red, etc. Es común que, para los proyectos, se acumulen los costos correspondientes a los recursos que participan en su desarrollo y, posteriormente, se amortice el total en varios períodos, durante el tiempo que se estime se utilizará el producto o servicio –vida útil- que resulte del proyecto. Para efectos del cálculo del presupuesto, las carteras de proyectos permitirán establecer los centros en los que se acumularán los costos y gastos de TI, de acuerdo con los recursos necesarios para asegurar su cumplimiento.

3.4.- Costeo de proyectos La determinación del costo exacto de un proyecto tampoco es una tarea simple, pues existen muchos componentes de hardware, software y recursos que se utilizan para varios proyectos simultáneamente –ej. los servidores de prueba- y no existe una forma simple para establecer la proporción que debe atribuírsele a cada proyecto. Si, a título de ejemplo, deseamos establecer el costo de un proyecto de desarrollo de sistemas, deberemos considerar diversos elementos, como el costo del personal de desarrollo -analistas y programadores-, el costo de las estaciones de trabajo que utilizan, el costo de las licencias del lenguaje o software utilizado para desarrollar los programas, etc. Al igual que con los servicios, si quisiéramos hilar fino, deberemos considerar la parte proporcional del costo de los ambientes de desarrollo y prueba, del local donde programadores y analistas operan, de los 145

Capítulo X

sueldos del personal de soporte que brindan apoyo al proyecto, de los administradores de TI, etc. También para los proyectos, es fácil comprender lo importante que será establecer límites a la complejidad que puede representar el costeo exacto de cada proyecto, ya que, de lo contrario, al igual que el costeo de servicios, puede convertirse en “el cuento de nunca acabar” y hacer que todo el proceso de administración financiera de los servicios de TI resulte inviable. Así pues, el costeo de proyectos debe determinar el costo de los proyectos hasta un nivel que la empresa considere realista, con el fin de que ejecutivos y usuarios puedan tener una visión razonable de la magnitud de tales costos.

4.- Elaboración del presupuesto Un presupuesto puede definirse como la cuantificación monetaria de los resultados previstos para un plan, un proyecto o una estrategia. A diferencia de la contabilidad, los presupuestos están orientados hacia el futuro y no hacia el pasado. Presupuestar es la actividad de hacer un cálculo anticipado del costo, de los gastos y de los ingresos de un negocio; normalmente, los presupuestos se realizan con base en el conocimiento acumulado que la organización tiene acerca de sus actividades, de los cambios y pronósticos sobre cantidades y precios.

146


El presupuesto es una herramienta que permite anticipar el comportamiento de indicadores económicos y sus relaciones con los diferentes aspectos administrativos, contables y financieros de la empresa. Debe distinguirse entre un presupuesto analítico -que es la proyección de los resultados contables de una unidad o de la empresa-, un presupuesto de erogaciones o desembolsos de capital -que establece con anticipación los requerimientos de recursos financiero que la organización necesita para desarrollar sus operaciones- y un presupuesto financiero –que incluye los gastos e ingresos que afectarán la posición de la tesorería de la empresa-. Una vez establecido y aprobado un presupuesto, comienza el ciclo de control presupuestario, que consiste en comparar lo que realmente se está haciendo con los datos presupuestados, para conocer o prever las desviaciones, analizar las causas y remediar las diferencias. La importancia de los presupuestos reside en que: 1. Permiten planear los resultados de la organización 2. Facilitan que los miembros de la organización puedan cuantificar en términos financieros los diversos componentes de su plan operativo 3. Sirven como medios de comunicación entre diferentes unidades 4. Permiten controlar el manejo de ingresos y egresos de la organización 5. Por medio del control presupuestario se asegura el cumplimiento del plan de operaciones 6. Permiten coordinar y relacionar las actividades de la organización.

5.- Contabilidad En una empresa, la contabilidad asociada a los servicios TI sigue patrones similares a la contabilidad asociada a otros servicios o departamentos, por lo que, dada la complejidad de las interrelaciones entre los componentes humanos y tecnológicos de TI, muchas veces la información que suministra el sistema de contabilidad no tiene el grado de desagregación necesario para poder analizar los cosos reales de los servicios y los proyectos. Se hace, pues, necesario utilizar los sistemas contables como fuentes de datos -especialmente los subsistemas de personal, nómina de pagos, compras, cuentas por pagar y activos fijos- y mantener una base de datos o datamart con la información de los sistemas mencionados. 147

Capítulo X

De esta forma, con la finalidad de actualizar la base de datos o datamart de administración financiera de TI, de acuerdo a la periodicidad que se establezca, las herramientas de extracción que se implementen deberán importar los datos de los sistemas contables, para después desagregarlos y/o resumirlos, combinándolos en la forma requerida para adaptarse a los requerimientos de análisis de costos de TI.

Tal como ya habíamos señalado, es esencial que el proceso de análisis de los datos contables no tenga como alcance un excesivo de detalle que lo complique más allá de lo razonable. Las actividades de análisis de datos contables deben facilitar: • La evaluación de los costos reales para su comparación con los presupuestados • • •

La toma de decisiones de negocio basadas en los costos de los servicios La evaluación de la eficiencia financiera de cada uno de los servicios TI Cargar a los usuarios adecuadamente los servicios TI, si se utiliza tal práctica

6.- Actividades de la administración financiera de TI Las principales actividades de la administración financiera de TI son las siguientes: 1. Elaboración de presupuesto: 148


1.1. Determinar los requerimientos de recursos para mantener en funcionamiento los servicios definidos en el catálogo: Hardware – alquileres y adquisiciones Accesorios, suministros y repuestos Alquileres de oficinas Licencias de software – adicionales y renovaciones Servicios de telecomunicaciones Personal de soporte Personal de operación Gastos de adiestramiento del personal Servicios profesionales Servicios de outsourcing Gastos de publicaciones 1.2. Determinar los requerimientos de recursos para cumplir los proyectos definidos en el plan operativo: Hardware – alquileres y adquisiciones Accesorios, suministros y repuestos Alquiler de oficinas Licencias de software – nuevas y renovaciones Servicios de telecomunicaciones Personal para el desarrollo del proyecto Personal de soporte Gastos de adiestramiento del personal Servicios profesionales Porción a utilizar de los servicios del catálogo –Ej. base de datos, ambiente de desarrollo, ambiente de prueba Servicios de outsourcing 1.3. Proyectar los flujos de caja de acuerdo a las fechas en que se requieren los recursos para servicios y proyectos 1.4. Proyectar la distribución de costos de servicios y proyectos por unidad usuaria o funcional 2. Preparación del control contable 2.1. Diseñar las estructuras de datos o datamart de TI 149

Capítulo X

2.2. Analizar las operaciones contables relacionadas con los servicios y los proyectos de TI - personal, nómina de pagos, compras, cuentas por pagar, activos fijos, etc. 2.3. Determinar la información que debe ser extraída de los sistemas contables 2.4. Establecer la forma que esa información debe ser desagregada e incluida en el datamart 2.5. Cargar el presupuesto aprobado de servicios y proyectos en el datamart 3. Control contable periódico 3.1. Realizar la actualización del datamart 3.2. Preparar reportes de inconsistencias detectadas en la data extraída 3.3. Realizar el análisis de costos reales vs. presupuestados 3.4. Preparar reportes gerenciales 3.5. Preparar reportes de excepción 3.6. Realizar la distribución de costos de servicios y proyectos, por función o grupos de usuarios Es importante observar que en aquellas organizaciones que facturan sus servicios a sus clientes, la administración financiera incluye una actividad adicional, que es la fijación de precios, la cual incluye las tareas de: Elaboración de una política de fijación de precios Establecimiento de tarifas por los servicios prestados o productos ofrecidos

7.- Evaluación de la disciplina Para poder evaluar la función de administración financiera se hace necesario calificar algunas características como las siguientes: • ¿Está comprometida la organización con la disciplina de administración financiera? • ¿Conoce la organización los costos reales de los servicios TI? • ¿Conoce la organización los costos reales de los proyectos TI? • ¿Colaboran los responsables de los otros procesos TI con la administración financiera?

150


•

•

¿Opera la organización TI como una verdadera unidad de negocio? ¿Los gastos TI están correctamente planificados y presupuestados? ¿Se cumple una cuantificación razonable para cada servicio?

• •

¿Se cumple una cuantificación razonable para cada proyecto? ¿Se analiza la eficiencia de cada uno de los servicios TI?

•

151

Capítulo X

152

Capítulo XI

Adm inist ra c ión de la Ca pa c ida d

Capítulo XI

Administración de la capacidad Tabla de contenido 1.- ¿Qué es administración de la capacidad? .................................155 1.1.Ventajas ...........................................................................157 1.2.Barreras............................................................................157 2.- Actividades ...............................................................................158 2.1.Plan de Capacidad............................................................159 2.2.Estimación .......................................................................160 2.3.Asignación de recursos ....................................................160 2.4.Monitorización.................................................................161 3.- Administración de la demanda .................................................161 4.- Evaluación de la disciplina .......................................................162

154

Administración de la capacidad


1.- ¿Qué es administración de la capacidad? La administración de la capacidad es la disciplina encargada de asegurar que todos los servicios de TI estén soportados por una infraestructura tecnológica con capacidades acordes con las necesidades de la empresa, dentro de costos razonables. En sus orígenes, la administración de capacidad se denominaba administración de espacio en discos, pues ese era el recurso más crítico para el funcionamiento de los servicios de TI; con el tiempo, el concepto se ha ido extendiendo, para adaptarse a las nuevas tecnologías, su flexibilidad y sus capacidades de crecimiento. Cuando no se establecen normas y procedimientos de administración de capacidades, existe la tendencia a desaprovechar los recursos disponibles y, peor aun, a realizar inversiones que realmente no son necesarias. También es posible que la ausencia de una buena administración de capacidades impida que una organización de TI prevea sus requerimientos de recursos y caiga en una situación de congestionamiento, que afecte la calidad y la continuidad de los servicios. Las principales funciones de la administración de la capacidad pueden resumirse de la siguiente forma: • Asegurar que se cubren las necesidades de capacidad TI tanto presentes, como futuras • Controlar el desempeño de la infraestructura TI •

Desarrollar planes de crecimiento requeridos para cumplir con los niveles de servicio acordados con los usuarios • Analizar y armonizar el uso de los recursos de TI –memoria, discos, canales de comunicación, etc.El objetivo central de la administración de la capacidad es asegurar que los servicios de TI dispongan de suficientes recursos tecnológicos para poder brindar sus servicios en forma eficiente, dentro de un esquema razonable de costos, para ello, esta disciplina deberá: 155

Capítulo XI

• •

•

•

•

Analizar el desempeño de la infraestructura instalada, para asegurar un uso racional de la capacidad existente Administrar los nuevos requerimientos de servicios –como puede ser un nuevo sistema- dotándolos de recursos adecuados, sin perjudicar los niveles de servicio de los servicios existentes Proyectar las capacidades necesarias para mantener la calidad de los servicios, alineándolos a los procesos de negocio y sus necesidades reales Participar en el desarrollo de los planes y acuerdos de niveles de servicio, con el fin de dotar los servicios con las capacidades necesarias Evaluar la tecnología que ofrece el mercado, con el fin de establecer alternativas de crecimiento

La administración de la capacidad intenta evitar las situaciones inconvenientes, como son invertir en tecnología, por encima de las necesidades reales o, en el extremo opuesto, mantener la infraestructura con una capacidad por debajo de esas necesidades. Es común observar esas situaciones y, a veces, pueden observarse dentro de una misma empresa, en la que se privilegian ciertos servicios, 156


dotándolos exageradamente de recursos tecnológicos, y se subestiman otros. Decíamos que ambos escenarios son habituales, ya que a menudo se pueden encontrar conviviendo en una misma organización tecnología innecesaria, adquirida porque ha deslumbrado a directivos o técnicos de informática, junto con equipos y servicios a los que podría mejorar su desempeño y productividad.

1.1.- Ventajas La implementación de la disciplina de administración de capacidades puede brindar una serie de ventajas, como las siguientes: • Se optimizan el desempeño de los recursos informáticos. • Se asegura que la capacidad necesaria estará disponible para atender los diferentes servicios en el momento en que sea requerida. • Se evitan gastos innecesarios producidos por compras no justificadas adecuadamente • Se planifica el crecimiento de la infraestructura de acuerdo con las necesidades reales de los servicios • Se reducen de los gastos de mantenimiento y de administración asociados a equipos y aplicaciones obsoletos o innecesarios Como conjunto, los procedimientos de administración de capacidades permitirán armonizar el desarrollo de la infraestructura de TI y los requerimientos de servicios, con la consiguiente reducción de costos y optimización del desempeño.

1.2.- Barreras La implementación de la disciplina de administración de la capacidad normalmente tropieza con muchas dificultades, entre las cuales podemos distinguir las siguientes: • • • •

No se dispone de suficiente información para proyectar una planificación realista de las capacidades Se crean expectativas exageradas en cuanto a los ahorros y mejoras del desempeño Ausencia de compromiso suficiente por parte de la dirección Insuficientes recursos para realizar una correcta medición del desempeño

157

Capítulo XI

•

Plataformas muy descentralizadas o muy complejas, en las que resulta difícil realizar una buena recopilación de datos

2.- Actividades Las actividades de la administración de las capacidades pueden ser de dos formas: •

Reactivas Monitorización Medición • Proactivas Predicción de requerimientos futuros Predicción de tendencias El proceso de administración de la capacidad incluye tres subprocesos, encargados de analizar las capacidades de TI desde diferentes puntos de vista:

158

•

Administración de la capacidad para el negocio Centra su atención en las necesidades actuales y futuras de los usuarios y clientes. Dentro de este subproceso se cumplen varias actividades importantes como son: Soporte al desarrollo de acuerdos de servicio Cuando se desarrolla un acuerdo de niveles de servicio, la administración de capacidades debe colaborar, asegurando la viabilidad de los acuerdos que se suscriben y proponiendo mediciones de desempeño adecuadas. Soporte al diseño o modificación de servicios La administración de capacidades también debe estar presente en la definición de nuevos servicios o en la modificación de servicios existentes, con el fin de asegurar que los recursos necesarios para soportarlos estarán disponibles.

•

Administración de la capacidad del servicio Analiza el desempeño de los servicios TI con el objetivo de asegurar el cumplimiento de los niveles de servicio acordados.


•

Administración de la capacidad de componentes Analiza tanto el desempeño global de la infraestructura TI, como de sus componentes y proyecta las tendencias para asegurar que se dispondrá de recursos suficientes.

2.1.- Plan de Capacidad Un plan de capacidad incluye: • La información relativa a la capacidad de la infraestructura TI • Las proyecciones de necesidades futuras, con base en los acuerdos existentes y al crecimiento de volúmenes • Los cambios necesarios para renovar la capacidad TI con nuevas tecnologías Adicionalmente, un plan de capacidad también debe incluir la información sobre los costos de la capacidad actual y proyectada, necesaria para que la gerencia de TI tomar decisiones.

159

Capítulo XI

2.2.- Estimación En la medida que las instalaciones se hacen más complejas, resulta mucho más complicado administrar las capacidades y escoger los caminos para el crecimiento de la infraestructura de TI. Es necesario evaluar alternativas y los costos asociados a cada alternativa, para lo cual pueden seguirse varios métodos: • Analizar tendencias para evaluar los volúmenes de trabajo que se esperan y poder estimar los aumentos de capacidad necesarios. • Modelar y simular diferentes escenarios, con el fin de “observar” el impacto de los volúmenes previstos y poder tomar las previsiones para el crecimiento de la infraestructura informática. • Realizar benchmarks con configuraciones reales, con el fin de asegurar que las nuevas capacidades que se adquieran responderán adecuadamente a las necesidades futuras. Normalmente, los benchmarks se llevan a cabo con facilidades que ofrecen los proveedores.

2.3.- Asignación de recursos Una de las actividades esenciales de la administración de la capacidad es la asignación de recursos de hardware, software y personal a cada uno de los servicios y sistemas. Ello requiere que se cuente con información confiable sobre: • Los niveles de servicio acordados y previstos • Impacto del servicio o del sistema en los procesos de negocio del cliente • Impacto del servicio o del sistema en la capacidad instalada • Márgenes disponibilidad • Costo los equipos de hardware y otros recursos TI necesarios para operar los nuevos servicios o sistemas Es frecuente que no se tomen en cuenta todos los aspectos relativos a la evaluación de magnitudes de un nuevo servicio o sistema, por lo que se puede subestimar el impacto o, por el contrario, sobreestimar el poder de cómputo de la infraestructura actual, creando situaciones de inestabilidad, al pretender lograr desempeños que sobrepasen la capacidad real.

160


2.4.- Monitorización La administración de la capacidad es un proceso continuo e iterativo que monitoriza, analiza y evalúa el desempeño y la capacidad de la infraestructura de TI; con esos datos analiza las posibilidades de mejorar la calidad de los servicios, bien sea por la vía de la optimización del manejo de los recursos o de la ampliación de la base instalada. Siempre, manteniendo en perspectiva que el objetivo central es asegurar que el desempeño de la infraestructura informática cumpla con los niveles de servicio acordados.

3.- Administración de la demanda Dentro de la disciplina de administración de capacidades, la actividad de administración de la demanda tiene como objetivo la optimizar y racionalizar el uso de los recursos TI. Es una actividad de gran importancia, especialmente, cuando se observa una degradación del servicio por aumentos no previstos de la demanda o interrupciones intermitentes del servicio por fallas en el hardware o software.

161

Capítulo XI

La administración de demanda en estos casos incluye las acciones necesarias para redistribuir recursos, con el fin de asegurar que los servicios críticos no se vean afectados o sufran el menor impacto posible. También, para el mediano y largo plazo, la administración de la demanda busca identificar los puntos débiles de la infraestructura, con el fin de robustecer su capacidad. Una correcta monitorización de la capacidad permite reconocer las debilidades de la infraestructura TI y los cuellos de botella, con el fin de determinar si es posible una redistribución de recursos o se requerirá un incremento de la capacidad instalada. Por ejemplo, una incorrecta distribución de tareas puede causar que la capacidad de los servicios de impresión se degrade durante ciertas horas de oficina, a causa de la elaboración concurrente de largos trabajos de impresión, como nóminas de pago, estados de cuenta de clientes, balances, etc. Si la producción de esos reportes compite por los mismos recursos para la elaboración de los documentos de oficina normales, es posible que se observen demoras -inexplicables para el usuario- en la impresión de los documentos. Una adecuada asignación de recursos, prioridades y horarios permitirá que todos esos requerimientos de impresión puedan “convivir” satisfactoriamente sin “tropezar” unos con otros. La administración de la capacidad también debe evaluar con base en las mediciones, proyecciones, experiencias y tendencias del mercado, cuándo la acción de añadir más capacidad puede ser más rentable que la búsqueda de correctivos, tomando en cuenta que los correctivos también implican un costo, ya que para implementar esos correctivos se requerirá la intervención del personal de soporte. En términos de la sabiduría popular, es necesario evitar las situaciones en que “sale más cara la mecha que el candil”.

4.- Evaluación de la disciplina Para la adecuada evaluación de la disciplina de administración de capacidades, es necesario elaborar informes para la gerencia, que periódicamente le permitan evaluar su desempeño, entre ellos podemos mencionar: • Niveles de utilización de recursos • Incrementos de volúmenes o de demanda no planificados • 162

Análisis de tendencias en la utilización de recursos


•

Métricas establecidas para el evaluar la capacidad y el desempeño

• • •

Proyecciones de las necesidades de capacidad Análisis de costos asociados a las capacidades Cumplimiento de los acuerdos de servicio

163

Capítulo XI

164

Capítulo XII

Cont inuida d de los Se rvic ios de T I

Capítulo XII

Continuidad de los servicios de TI Tabla de contenido 1.- ¿Qué es administración de la continuidad? ..............................167 1.1.Ventajas ...........................................................................169 1.2.Barreras............................................................................169 2.- El plan de continuidad del negocio - (BCP) .............................170 3.- Terminología ............................................................................172 4.- Preparación ...............................................................................173 4.1.Evaluación de riesgos ......................................................173 4.2.Identificar procesos críticos .............................................173 4.3.Selección de estrategias de recuperación .........................174 5.- Alcance de la continuidad de servicios.....................................175 6.- Organización y planificación....................................................177 6.1.Plan de mitigación de riesgos ..........................................177 6.2.Plan de manejo de emergencias .......................................177 6.3.Plan de recuperación ........................................................178 7.- Continuidad de servicios en el día a día ...................................178 7.1.Adiestramiento.................................................................179 7.2.Actualización ...................................................................179 8.- Evaluación de la disciplina .......................................................180

166

Continuidad de los servicios de TI


1.- ¿Qué es administración de la continuidad? La administración de la continuidad de los servicios de TI -IT Service Continuity Management- se encarga de prevenir y proteger a la empresa de los efectos que pudiera tener una interrupción de los servicios de TI, bien sea que haya sido ocasionada por alguna falla técnica o por causas naturales, o que haya sido provocada, voluntaria o involuntariamente, por alguna persona. La administración de la continuidad de los servicios de TI debe combinar equilibradamente procedimientos: • Preventivos: Medidas y procedimientos que buscan eliminar o mitigar los riesgos de interrupción y sus posibles efectos. • Reactivos: Procedimientos cuyo propósito es reanudar el servicio tan pronto como sea posible después de cualquier interrupción. No cabe duda que las políticas y procedimientos destinados a prevenir y limitar los efectos de un desastre son preferibles a las políticas para reaccionar frente a tales eventos, sin embargo la experiencia demuestra que debe disponerse de una juiciosa combinación de medidas. Los objetivos principales de la administración de la continuidad de los servicios pueden resumirse como: • Asegurar la pronta recuperación de los servicios críticos de TI después de cualquier desastre. •

Establecer políticas, tomar medidas y desarrollar procedimientos para evitar, dentro de lo posible, las consecuencias de cualquier desastre natural -como terremoto-, evento accidental -como incendio- o actos de terrorismo –como explosivos-. La administración de la continuidad de los servicios de TI requiere de una labor de “evangelización” a todo lo largo de la organización, pues es 167

Capítulo XII

difícil de justificar, es costosa y sus beneficios sólo se perciben a largo plazo. Implementar la administración de la continuidad de los servicios de TI equivale a la contratar un seguro, ya que cuesta dinero y parece inútil mientras no ocurre ninguna eventualidad; sin embargo, resulta sumamente valioso frente a cualquier contingencia. La administración de la continuidad de TI no puede concebirse como una disciplina exclusiva de TI, sino que debe formar parte de la disciplina de continuidad del negocio y debe estar en perfecta coordinación con esa disciplina. Obsérvese, que no tendría ningún sentido que se hagan esfuerzos para que un sistema de entrada de órdenes esté funcionando y disponible bajo cualquier condición, si no se toman las medidas para que el personal de atención al cliente esté listo para operarlo, aunque sea prestando un nivel mínimo de atención.

Existe una diferencia entre desastres tales como terremotos, incendios, inundaciones, etc. y desastres informáticos, tales como los que generan las fallas de equipos, de software, los virus o los ataques de hackers. Para ambos tipos de eventualidades, la disciplina de administración de la continuidad de los servicios debe incluir los procedimientos para mantener el negocio en funcionamiento. Sin embargo, en el último caso – falla informática- además de buscar la restauración del servicio TI con

168


prontitud, se deben prever las consecuencias en el funcionamiento del negocio ya que: • • •

Sólo se afectan los servicios TI, pero pueden paralizar toda la organización. Son más previsibles y más comunes. La percepción del cliente es diferente, pues los desastres naturales se aceptan con resignación y no se asocian a una actitud negligente de los técnicos de TI.

1.1.- Ventajas La implementación adecuada de la disciplina de administración de la continuidad de los servicios de TI tiene una gran cantidad de ventajas, entre las cuales cabe destacar las siguientes: • Se manejan y se mitigan los riesgos. • Se reducen los periodos de interrupción no planificados del servicio de TI. • Se fortalece la confianza en la calidad del servicio, por parte de usuarios y clientes. •

Se constituye en el apoyo indispensable que requiere el proceso continuidad de las operaciones del negocio.

1.2.- Barreras La implementación de la disciplina de administración de la continuidad de los servicios de TI es una tarea compleja y laboriosa y, además, normalmente tropieza con diferentes obstáculos como los siguientes: • Hay resistencia a realizar inversiones que no van a tener una rentabilidad inmediata, por lo que no se presupuestan ni asignan suficientes recursos. • No existe un compromiso dentro de la organización a cumplir con las tareas y actividades que requiere la disciplina, por lo que continuamente se demoran los planes, para atender otras tareas de mayor prioridad. • No se actualizan los procedimientos y guías cada vez que se realiza un cambio en la plataforma de servicios de TI. • No se cumple con un análisis completo de riesgos y se dejan de lado amenazas y vulnerabilidades importantes.

169

Capítulo XII

•

•

No se prepara convenientemente el personal, ni se realizan simulacros que permitan que toda la organización esté familiarizada con los procedimientos a seguir en caso de presentarse cualquier contingencia que interrumpa los servicios. Falta de coordinación con los planes de continuidad del negocio Business Continuity Plan (BCP)-.

2.- El plan de continuidad del negocio - (BCP) Es importante conocer un poco la terminología y los temas más relevantes de los planes de continuidad del negocio, con el fin de entender el contexto en el que se debe desarrollar la disciplina de administración de la continuidad de los servicios de TI: • Plan de recuperación de desastres - Disaster Recovery Plan (DRP) El plan de recuperación de desastres centra su atención en la recuperación de los servicios de TI y sus recursos, para aquellos casos en los que algún evento ocasione una interrupción significativa en su funcionamiento; por ejemplo, explosión, falla prolongada de electricidad, incendio, inundación, terremoto, etc. • Plan de continuidad de operaciones - Continuity of Operations Plan (COOP) El plan de continuidad de operaciones incluye las guías y procedimientos para la recuperación de los procesos críticos y estratégicos de una empresa. Si bien el plan de continuidad del negocio es la integración todos los planes de recuperación, es frecuente que al plan de continuidad de operaciones se le de esa denominación –BCP-.

170


•

Plan de contingencia - Contingency Plan (CP) El plan de contingencia centra su atención en la recuperación de los servicios y recursos de TI después de una falla, independientemente de su magnitud, mayor o menor. Establece procedimientos y lineamientos para la recuperación de equipos y servicios, así como también para las áreas de la empresa que puedan resultar afectadas.

•

Plan de reanudación del negocio - Business Resumption Plan (BRP) El plan de reanudación del negocio centra su atención en la reanudación de los procesos del negocio que resulten afectados por una falla en los servicios de TI. Focaliza su atención en establecer los procedimientos y guías de trabajo para el funcionamiento de las áreas del negocio en situación de contingencia. Plan de respuesta a emergencias - Emergency Response Plan El objetivo del plan de respuesta a emergencias es brindar protección a los empleados, al público, el ambiente y los activos de la empresa. En última instancia, busca poner bajo control cualquier situación de crisis de manera inmediata.

•

171

Capítulo XII

Cada una de estas disciplinas se centran en la protección de aspectos específicos de la organización, integrándose entre si, para poder proteger el personal y todas las áreas críticas de la organización. El plan de continuidad del negocio es el concepto que integra el alcance y los objetivos de todas estas disciplinas.

3.- Terminología Dentro de las diferentes disciplinas arriba descritas, se manejan varios términos de importancia, como son: • Objetivo de tiempo de recuperación -Recovery Time Objetive (RTO) El objetivo de tiempo de recuperación es un resultado fundamental del análisis de impacto –Business Impact Análisis (BIA)-, que establece el intervalo de tiempo en el cual un servicio, proceso o actividad crítica de la empresa debe ser recuperado. En términos del Instituto de Continuidad del Negocio -Business Continuity Institute (BCI)- es “el período de tiempo en el que un proceso puede estar inoperativo”. •

•

172

Centro de operaciones alternas del negocio –COANEl centro de operaciones alternas del negocio es el local escogido por la empresa para cumplir con sus operaciones en caso de que, por cualquier motivo, no pueda tenerse acceso a las oficinas de la empresa. Normalmente el centro alterno debe ubicarse en una localidad que no esté cercana a las oficinas regulares, previendo los estragos que un terremoto o motín político pudiera generar. En él se deberá disponer de los recursos necesarios para hacer funcionar el negocio, aunque sea en una mínima versión: mobiliario, suministros, equipos, teléfonos, etc. Centro Alterno de Operaciones de Tecnología -CAOTEl centro alterno de operaciones de tecnología es el local escogido por la empresa para operar los servicios de TI en caso de que, por cualquier motivo, no pueda tenerse acceso a las instalaciones normales. Es muy frecuente que el CAOT se ubique en un centro de procesamiento contratado, ya que en el mercado existen varios excelentes proveedores de servicios de recuperación y soporte.


4.- Preparación La preparación de la disciplina de administración de la continuidad de operaciones requiere el cumplimiento de varias actividades bastante complejas y laboriosas, como son: • Revisar los procesos del negocio y evaluar los riesgos • Identificar procesos críticos y analizar el impacto que sufrirán esos procesos si faltan los servicios de TI • Seleccionar las estrategias de recuperación

4.1.- Evaluación de riesgos Las actividades de evaluación de riesgos en los diferentes procesos del negocio determinan las amenazas de un desastre, pormenorizan las vulnerabilidades existentes, permiten visualizar los posibles impactos de los diferentes eventos de desastre e identifican los controles necesarios para prevenir o mitigar los riesgos de cada evento. Al realizar una evaluación de riesgos se desarrolla un informe de riesgos y controles que establece recomendaciones y plan de acciones para controlar y mitigar los riesgos que pudiesen alterar el normal desempeño del negocio Para la elaboración de este informe es necesario: • Revisar los procesos del negocio y sus dependencias de los servicios de TI • Identificar los puntos más vulnerables • Analizar las posibles amenazas sobre estos procesos y estimar su probabilidad Gracias a los resultados de este análisis detallado, se dispondrá de información suficiente para proponer diferentes medidas de prevención y recuperación que se adapten a las necesidades reales del negocio. La prevención frente a riesgos genéricos y poco probables puede ser muy costosa y difícil de justificar, sin embargo, las medidas preventivas o de recuperación frente a riesgos específicos pueden resultar sencillas, de rápida implementación y relativamente económicas.

4.2.- Identificar procesos críticos Al identificar los procesos críticos, que contribuyen más a la misión de la empresa –mission critical-, se analiza en detalle el impacto que podría tener cualquier evento que impidiera su correcto funcionamiento y las pérdidas potenciales que podría acarrear esa interrupción. 173

Capítulo XII

Como resultado, se desarrolla el informe de análisis de impacto – Business Impact Análisis (BIA)- en el cual se identifican las áreas del negocio que son críticas, así como la magnitud de los impactos potenciales, tanto operativos como financieros, de una interrupción en su funcionamiento: Pérdida de rentabilidad Pérdida de participación de mercado Mala imagen Otros efectos

4.3.- Selección de estrategias de recuperación Para establecer los planes de recuperación es necesario establecer el tipo de recuperación que puede adoptarse para cada área del negocio, en relación con la criticidad y las necesidades de recuperación que tenga el área. En general, los tipos de recuperación que pueden adoptarse son: • Manual Procedimientos manuales o semi manuales para llevar a cabo las tareas del área, como por ejemplo, para autorizar compras de los clientes, disponer de un listado de saldos y registrar los pedidos en una hoja de EXCEL. Una vez que se recupere la operación normal, se transferirán al sistema los pedidos registrados en EXCEL. • Recuperación gradual –cold standbyEl método de recuperación gradual consiste en poner a disposición del negocio las facilidades de oficina y de servicios de TI, en el COAN y CAOT, en forma gradual, con varios días de espera –hasta 4 días o más-. • Recuperación intermedia –warm standby El método de recuperación intermedia consiste en recuperar las operaciones en la localidad de contingencia –COAN y COATdentro de un plazo de 2 ó 3 días. Muchas veces los locales para llevar a cabo la recuperación de las operaciones son facilidades que se comparte con otras empresas. •

174

Recuperación rápida – hot standbyEl método de recuperación rápida busca recuperar las operaciones de los servicios más importantes, dentro de un plazo de 24 horas. Normalmente para este método, el CAOT asume la


modalidad de local “sombra”, en el que se dispone de los equipos necesarios y se pueden poner a funcionar con cierta rapidez, con una pequeña pérdida de información. • Recuperación inmediata –también hot standbyEs un método que se utiliza para los procesos más críticos y requiere un local de contingencia –CAOT- en el que se encuentren instalados equipos “espejo”, que permiten reanudar operaciones en cuestión de minutos, sin pérdida de información. Excepto para el método de recuperación manual, todos los restantes métodos requieren la elaboración de copias de bases de datos y librerías de software, que servirán como punto de arranque de los servicios y las operaciones. En el caso de la recuperación inmediata, estas copias de respaldo se actualizan con cada operación que se registra, utilizando las nuevas tecnologías de arreglos de discos que permiten replicar instantáneamente cualquier operación en discos “espejo” ubicados en localidades distantes. Para los otros métodos de recuperación, normalmente se elaboran copias de respaldo con la periodicidad requerida -diaria o semanal- que se almacenan en una localidad segura. Es bueno observar que, para estos métodos, la información de las operaciones que se ejecuten entre la última toma de respaldo y el momento en que ocurra un desastre, será información que no está respaldada y que, en algún momento u otro, habrá que incluir en los sistemas, a riesgo de tener unas bases de datos inexactas. Por lo arriba señalado, algunos especialistas establecen que el objetivo de tiempo de recuperación –RTO- para un área del negocio debe estar dado por la cantidad de información que el área puede perder.

5.- Alcance de la continuidad de servicios Uno de los pasos iniciales para desarrollar la disciplina de administración de la continuidad del servicio debe ser establecer claramente sus objetivos generales, su alcance y el compromiso de la organización TI. También la dirección de la empresa debe demostrar su compromiso con el proceso, pues la implantación de la administración de la continuidad de servicios de TI puede resultar compleja y costosa sin una visible contraprestación o un retorno de inversión.

175

Capítulo XII

El énfasis de los alcances de la administración de la continuidad del servicio debe ser puesto en las prioridades del negocio; esto es, una vez establecidas cuáles son las áreas críticas y los servicios de TI que apoyan su funcionamiento, desarrollar los planes de continuidad y, una vez que las áreas más críticas se hayan asegurado, se pueden ir incluyendo paulatinamente otras áreas de menor prioridad.

Así pues, deben evitarse enfoques demasiado ambiciosos y establecer alcances realistas para la administración de la continuidad de servicios de TI en función de: • Los servicios estratégicos de TI –requeridos por las áreas prioritarias del negocio-. • Los planes generales de continuidad del negocio. • La historia de interrupciones graves de los servicios TI. • Las expectativas de negocio. • La disponibilidad de recursos. La administración de la continuidad del servicio estará destinada a fracasar si no se destinan suficientes recursos, tanto técnicos, como equipos –hardware y software-. Será importante recordar que una buena cantidad del esfuerzo de desarrollo de la disciplina debe destinarse al adiestramiento del personal, con el fin de que, en momentos de crisis, conozca las responsabilidades que deberá asumir y las tareas que deberán ser cumplidas.

176


6.- Organización y planificación Una vez determinado el alcance que habrá de dársele a la administración de la continuidad de servicios de TI, analizados los riesgos y vulnerabilidades y definidas unas estrategias de prevención y recuperación es necesario asignar y organizar los recursos necesarios. Con ese objetivo la administración de la continuidad del servicio debe elaborar una serie de documentos entre los que se incluyen: • Plan de mitigación de riesgos • Plan de manejo de emergencias •

Plan de recuperación

6.1.- Plan de mitigación de riesgos Un plan de mitigación de riesgos tiene como objetivo principal evitar o minimizar el impacto de un desastre en la infraestructura TI. Entre las medidas se incluyen en este tipo de planes, pueden encontrarse las siguientes: • Utilización de sistemas alternos de suministro eléctrico –plantas eléctricas alternas• • • •

Uso de unidades de electricidad ininterrumpibles Uninterruptible Power Supply (UPS´s)– Políticas de respaldo y custodia para los archivos y las bases datos. Duplicación de elementos críticos, como switches, canales comunicación, etc. Utilización de sistemas de seguridad pasivos, como cajas seguridad

– de de de

6.2.- Plan de manejo de emergencias Las crisis suelen provocar reacciones de pánico, que pueden ser contraproducentes que, en algunos casos, pueden causar mayores daños que el incidente que las haya podido causar. Por ello es imprescindible que estén claramente definidas las responsabilidades y funciones del personal en caso de alguna situación de emergencia, así como también deben estar definidas las guías de actuación correspondientes. En principio los planes de manejo de emergencias deben tomar en cuenta aspectos tales como: • Evaluación del impacto de la contingencia en la infraestructura TI 177

Capítulo XII

•

Asignación de funciones de emergencia al personal de servicio TI

•

Comunicación a los usuarios y clientes en caso de una grave interrupción o degradación del servicio Procedimientos de contacto y colaboración con los proveedores involucrados Guías y protocolos para la puesta en marcha del plan de recuperación correspondiente

• •

6.3.- Plan de recuperación Cuando una interrupción del servicio es un hecho inevitable, es el momento de poner en marcha los procedimientos de recuperación. Para ello, el plan de recuperación debe incluir todo lo necesario para: • Reorganizar al personal involucrado • Reestablecer los sistemas de hardware y software necesarios • Recuperar los datos y reiniciar el servicio TI Los procedimientos de recuperación pueden depender de la importancia de la contingencia y de la opción de recuperación asociada – cold, warm o hot stand-by-, pero en general deben detallar: • • • • •

Asignación de personal y recursos Instalaciones y hardware alternativos Planes de seguridad que garanticen la integridad de los datos Procedimientos de recuperación de datos Acuerdos de colaboración con otras organizaciones

• Protocolos de comunicación con los clientes Cuando se tiene que poner en marcha un plan de recuperación, no oportunidad para la improvisación, cualquier decisión puede tener graves consecuencias tanto en la percepción que los usuarios tengan del personal de TI, como en los costos asociados al proceso.

7.- Continuidad de servicios en el día a día Una vez establecidas las políticas, estrategias y planes de prevención y recuperación es indispensable que estos no queden en carpetas “llevando polvo”, es necesario que la organización TI esté perfectamente preparada para su correcta implementación. Ello dependerá de dos factores clave, la adecuada preparación del personal y la continua adecuación a las necesidades reales del negocio, a medida que evolucione la infraestructura de TI y los procesos del negocio. 178


Uno de los factores clave para el éxito de la administración de la continuidad del servicio es mantener un interés permanente en la disciplina, ya que si el interés decayera, después de tener varios periodos en los que la prevención y la buena suerte hayan impedido que se presenten interrupciones graves, en el momento menos pensado podría presentarse alguna dificultad grave y no estar en condiciones de reaccionar adecuadamente frente a ella. Es imprescindible llevar controles rigurosos que impidan que la inversión y compromiso inicial se diluyan o que la administración de la continuidad de servicios de TI no se mantenga al nivel adecuado para enfrentar cualquier situación. En todo momento, la administración de la continuidad de servicios de TI debe garantizar: • La puesta en marcha de los planes preestablecidos. • • •

La supervisión de los mismos. La coordinación con la administración de la continuidad del negocio. La asignación de recursos necesarios.

7.1.- Adiestramiento Es inútil disponer de unos planes de prevención y recuperación concienzudamente preparados, si las personas que deberán ponerlos en práctica no están familiarizadas con los mismos. Es indispensable que la administración de la continuidad de servicios de TI prepare al personal: • • •

Dando a conocer los planes de prevención y recuperación Ofreciendo adiestramiento en el uso de los diferentes procedimientos de prevención y recuperación. Realizando periódicamente simulacros de diferentes tipos de desastres, con el fin de asegurar la capacitación del personal involucrado.

7.2.- Actualización Tanto las políticas, estrategias y planes han de ser actualizados periódicamente para asegurar que responden a los requisitos de la organización en su conjunto. Cualquier cambio en la infraestructura TI o en los planes de negocio puede requerir de una profunda revisión de los planes en vigor y una consecuente auditoría que evalúe su adecuación a la nueva situación.

179

Capítulo XII

En ocasiones en que el dinamismo del negocio y los servicios TI lo haga recomendable, estos procesos de actualización y auditoria pueden establecerse de forma periódica. La Gestión de Cambios juega un papel esencial en asegurar que los planes de recuperación y prevención estén actualizados manteniendo informada a la administración de la continuidad de servicios de TI de los cambios realizados o previstos.

8.- Evaluación de la disciplina La administración de la continuidad del servicio debe elaborar periódicamente informes sobre su gestión que muestren información relevante para el resto de la organización TI. Estos informes deben incluir: • Análisis sobre nuevos riesgos y evaluación de su impacto. • Evaluación de los simulacros de desastre realizados. • Actividades de prevención y recuperación realizadas. • Costes asociados a los planes de prevención y recuperación. •

180

Preparación y capacitación del personal TI respecto a los planes y procedimientos de prevención y recuperación.

Capítulo XIII

Adm inist ra c ión de la Disponibilida d

Capítulo XIII

Administración de la disponibilidad Tabla de contenido 1.- ¿Qué es administración de la disponibilidad? ..........................183 1.1.Cálculo de la disponibilidad.............................................185 1.2.Ventajas ...........................................................................185 1.3.Barreras............................................................................186 2.- Requerimientos de disponibilidad ............................................186 3.- Plan de disponibilidad ..............................................................187 4.- Monitorización de la disponibilidad .........................................187 5.- Mediciones ...............................................................................189 6.- Evaluación de la disciplina .......................................................189

182

Administración de la disponibilidad


1.- ¿Qué es administración de la disponibilidad? Cuando hemos ido diez veces a una máquina de cajero y sólo hemos logrado obtener el dinero solicitado en ocho oportunidades, decimos que esa máquina de cajero ha estado disponible para nosotros un 80 %, o que ese cajero automático tiene una disponibilidad del 80 %. En la vida de los negocios modernos, dada la alta dependencia de la tecnología de información, se espera que esa tecnología ofrezca una disponibilidad del 100% durante los siete días de la semana. Sabemos que la disponibilidad de una determinada infraestructura de TI depende de muchos factores, del correcto diseño de los servicios, de la confiabilidad de los componentes que la integran, de su adecuado mantenimiento, etc. Es fácil comprender, por lo tanto, que un nivel de disponibilidad de 100 % es prácticamente imposible de alcanzar, pues siempre puede haber algún componente de la infraestructura que puede fallar y que, en mayor o menor grado, puede afectar la disponibilidad del servicio. Con estas ideas en mente, podemos decir que la administración de la disponibilidad busca optimizar los niveles de disponibilidad de los servicios de TI, de tal forma que estos funcionen correctamente, atendiendo las necesidades de los usuarios, dentro de parámetros de costo razonables y cumpliendo los acuerdos de servicio que se hayan establecido con usuarios o clientes. Para cumplir con tales propósitos, la administración de la disponibilidad deberá: • Realizar acciones de seguimiento • Conocer los compromisos establecidos en los acuerdos de niveles de servicio o, si no existen estos acuerdos, determinar los requerimientos de disponibilidad de los usuarios, trabajando en estrecha relación con estos.

183

Capítulo XIII

•

•

Hacer seguimiento a los niveles de disponibilidad que realmente ofrecen los servicios de TI. • Evaluar la disponibilidad de los nuevos servicios o las modificaciones hechas a los servicios existentes. • Utilizar la información recabada por la disciplina de monitorización y control, con el fin de cuantificar la disponibilidad de los servicios TI. • Elaborar informes de seguimiento sobre disponibilidad, confiabilidad, matenibilidad y cumplimiento de acuerdos de servicio. Realizar acciones preventivas • • • •

184

Evaluar riesgos y recomendar la implementación de acciones de mitigación. Participar en el diseño de nuevos servicios o modificaciones de los servicios existentes. Establecer criterios de diseño para disponibilidad Proponer planes de acción para mejorar la infraestructura de servicios TI, con la finalidad de mejorar los niveles de disponibilidad.


Para desarrollar los procedimientos de administración de la disponibilidad en forma correcta, se debe mantener en perspectiva las siguientes consideraciones: • La disponibilidad de los servicios es uno de los elementos más importantes para mantener alta la satisfacción de los usuarios. • En el caso de fallas una rápida restauración de los servicios puede ayudar a mantener los niveles de satisfacción de los usuarios. • La disponibilidad de un servicio dependerá del grado de disponibilidad del componente más débil en la cadena de componentes que participan en la prestación del servicio.

1.1.- Cálculo de la disponibilidad Normalmente, la disponibilidad se calcula como un porcentaje, de la siguiente manera:

Disponibilidad = ((TAS – TTI) / TAS) X 100 En donde: TAS es el tiempo acordado de servicio, esto es, el tiempo que el servicio debe estar disponible y TTI es el tiempo total de interrupción del servicio durante los períodos en que debió estar disponible. Supongamos que un servicio requiere una disponibilidad de 24 horas diarias durante los 7 días de la semana, esto es debe estar disponible 720 horas mensuales (TAS). Si este servicio se ha interrumpido, por las razones que sean, por un total de 10 horas (TTI), entonces la disponibilidad real habrá sido de 98,6 %:

Disponibilidad = ((720 – 10) / 720) X 100 = 98,6 % 1.2.- Ventajas La implementación de la disciplina de administración de la disponibilidad de los servicios de TI puede brindar una serie de ventajas, como las siguientes: • •

Los usuarios reciben los servicios de TI oportunamente, cuando los requieren. Los usuarios reciben un servicio con un nivel de calidad acorde con sus necesidades. 185

Capítulo XIII

• •

Pueden optimizarse los costos asociados a un alto nivel de disponibilidad. Se pueden mejorar paulatinamente los niveles de disponibilidad.

1.3.- Barreras La implementación de la disciplina de administración de la disponibilidad de los servicios de TI normalmente tropieza con algunas dificultades, entre las cuales podemos distinguir las siguientes: • No existe compromiso con la disciplina dentro de la organización TI. • No se hace un adecuado seguimiento de la disponibilidad de los servicios. • No se dispone de las herramientas ni del personal adiestrado. • Los objetivos de disponibilidad no están debidamente ajustados a las necesidades del negocio. • Falta de coordinación con otras disciplinas, como monitorización y control, etc.

2.- Requerimientos de disponibilidad Es lógico pensar que, para poder establecer acuerdos de servicio con los usuarios y clientes, es necesario tener, por un lado, una idea bastante precisa de los niveles de disponibilidad de los servicios y, por el otro, de los requerimientos que en esta materia tengan los usuarios. En especial, será necesario cuantificar los niveles de disponibilidad que requieren los usuarios, para poder establecer hasta que punto pueden ser satisfechos esos requerimientos, con la infraestructura actual. Es posible que algunos usuarios soliciten una disponibilidad de 100 % 7 días a la semana, 24 horas diarias. Sin embargo, tal tipo de disponibilidad debe sopesarse con respecto a los costos en que habría que incurrir, para alcanzar esos niveles de perfección. Por tales razones, al negociar los niveles de servicio, hay que mantener en perspectiva que la disponibilidad propuesta debe determinarse armonizando las necesidades reales del negocio y las posibilidades reales de la organización TI. Es posible que la falta de un determinado servicio por ciertos períodos represente sólo un pequeño inconveniente, mientras que la certeza de un servicio prácticamente continuo y sin interrupciones puede requerir la

186


replicación de equipos y sistemas, así como otras medidas costosas que no van a contribuir a la rentabilidad del negocio. Así pues, es fundamental que la administración de la disponibilidad: • Identifique las actividades clave del negocio. • Cuantifique los intervalos de interrupción aceptables para los diferentes servicios, de acuerdo con el impacto que tales interrupciones puedan tener sobre la buena marcha del negocio. • Determine los niveles de disponibilidad que deben tener los servicios TI. • •

Establezca las brechas entre los requerimientos reales del negocio y el nivel de disponibilidad que TI puede cumplir. Establezca planes de acción para alcanzar los niveles de disponibilidad requeridos.

3.- Plan de disponibilidad Tal como discutíamos en la sección anterior, una adecuada planificación permitirá establecer unos niveles de disponibilidad ajustados tanto a las necesidades reales del negocio, como a las capacidades de la organización e infraestructura de TI. El documento en el que se recogen los objetivos de disponibilidad y las acciones necesarias para su cumplimiento es el plan de disponibilidad. Este plan debe precisar: • La situación actual de disponibilidad de los servicios TI. • Herramientas que deben ser añadidas para la monitorización de la disponibilidad. • Métodos y técnicas de análisis a utilizar. • Definiciones relevantes y precisas de las métricas a utilizar. • Planes de mejora de la disponibilidad. • Expectativas futuras de disponibilidad. Este plan que debe actualizarse periódicamente, además de establecer los requerimientos de disponibilidad, debe contener todos los cambios necesarios para satisfacer tales requerimientos.

4.- Monitorización de la disponibilidad Los trabajos de monitorización de la disponibilidad de los servicios de TI deben incluir la consideración de un conjunto de variables, que 187

Capítulo XIII

permiten tener una clara visión de las diferentes fases del “ciclo de vida de la interrupción de los servicios”, con el fin de afinar los compromisos que, en materia de niveles de disponibilidad, la organización TI puede adquirir. Desde el momento en que se presenta una interrupción de servicio hasta su restitución, un incidente pasa por distintas etapas que deben ser cuantificadas de la siguiente forma: 1. Tiempo de detección: es el tiempo que transcurre desde que ocurre una falla hasta que la organización TI toma conocimiento de la misma. 2. Tiempo de respuesta: es el tiempo que transcurre desde la detección del problema hasta que se realiza un diagnóstico del mismo. 3. Tiempo de reparación/recuperación: periodo de tiempo utilizado para reparar la falla o encontrar alguna solución temporal que permita poner operativo el servicio.

Análogamente, la administración de la disponibilidad debe publicar informes sobre la disponibilidad de los servicios que incluyan factores como los siguientes: • Tiempo Medio de Parada (Downtime): que es el tiempo promedio de duración de las interrupciones de servicio, incluyendo el tiempo de detección, respuesta y resolución. • Tiempo Medio entre Fallas (Uptime): es el promedio de duración de los intervalos en los que el servicio ha esta do disponible sin interrupciones. •

188

Tiempo Medio entre Incidentes: es el tiempo promedio que transcurre entre incidentes, que es la suma del tiempo medio de parada y el tiempo medio entre fallas. El tiempo medio entre


incidentes es una buena medida de la confiabilidad de un servicio o de un componente en particular.

5.- Mediciones La administración de la disponibilidad debe realizar un conjunto de mediciones que permitan comprender la importancia de los factores que intervienen en la disponibilidad del servicio, lo cual permitirá prever el los recursos que deberán asignarse para mejorar, prevenir y mantener la infraestructura, así como elaborar planes de mejora a partir del análisis de dichas mediciones. Entre estas podemos citar las siguientes: 1. Análisis del impacto de la falla de un componente (CFIA Component Failure Impact Análisis) Este análisis permite identificar el impacto que tiene cada ítem de configuración en la disponibilidad de los servicios TI en los que interviene. 2. Análisis del árbol de fallas (FTA - Failure Tree Análisis) Este análisis busca establecer la forma cómo se “propagan” las fallas a través de la infraestructura TI, con el fin de comprender mejor las vulnerabilidades del servicio. 3. Análisis y manejo de riesgos (RAMM - Risk Analysis and Management Method) El objetivo de este análisis es identificar los riesgos y vulnerabilidades a los que se halla expuesta la infraestructura TI, con el objetivo de adoptar acciones de mitigación, que permitan reducir el riesgo o que permitan recuperar rápidamente el servicio en caso de cualquier interrupción. 4. Análisis de las interrupciones de servicio (SOA - Service Outage Análisis) Este análisis tiene como propósito complementar las acciones de administración de problemas, con el fin de proponer soluciones a los problemas que han causado o pueden causar interrupciones de servicio.

6.- Evaluación de la disciplina El objetivo de la administración de la disponibilidad es mejorar la calidad del servicio y la satisfacción del cliente, por lo que se requiere disponer de información y reportes como los que se señalan a continuación: 189

Capítulo XIII

•

Técnicas y métodos utilizados para la prevención y el análisis de fallas. • Cumplimiento de los acuerdos de servicio en relación con la disponibilidad y confiabilidad de los servicios. • Información estadística sobre: Tiempos de detección y respuesta a los fallas. Tiempos de reparación y recuperación del servicio. Tiempo medio de servicio entre fallas. Disponibilidad real de los diferentes servicios. Es lógico que, para darle sentido a la información, sea necesario establecer comparaciones entre lo ocurrido en la realidad y la situación deseable o establecida en los acuerdos de servicio.

190

Capítulo XIV

Se gurida d de la I nform a c ión

Capítulo XIV

Seguridad de la información Tabla de contenido 1.- ¿En qué consiste la administración de seguridad?....................193 1.1.Ventajas ...........................................................................194 1.2.Barreras............................................................................195 2.- La seguridad en el nivel de la empresa.....................................195 3.- Actividades ...............................................................................197 4.- Políticas de seguridad ..............................................................198 5.- El plan de seguridad .................................................................198 6.- Cumplimiento de la normativa de seguridad ............................199 7.- Evaluación y mantenimiento ....................................................200 8.- Evaluación de la disciplina .......................................................201

192

Seguridad de la información


1.- ¿En qué consiste la administración de seguridad de la información? La administración de seguridad de la información tiene como propósito alinear la seguridad de TI con la seguridad de la empresa y velar para que la seguridad de la información se maneje adecuadamente en todos los servicios de TI. Una adecuada administración de la seguridad de la información permitirá asegurar que la información que se almacena y maneja con la infraestructura de TI: • Está debidamente protegida de su uso por parte de personas no autorizadas –confidencialidad-. • Está debidamente protegida de cambios que intenten hacer personas no autorizadas –integridad-. Podemos decir que los principales objetivos de la administración de seguridad son: •

Diseñar una política de seguridad alineada con las políticas de seguridad y necesidades de la empresa. • Asegurar el cumplimiento de las políticas de seguridad acordadas. • Mitigar los riesgos de seguridad que puedan amenazar la continuidad del servicio o la confidencialidad e integridad de la información. Será fundamental comprender que la administración de la seguridad no es únicamente responsabilidad de los técnicos de seguridad de TI, sino que es una responsabilidad de toda la empresa. Siempre se cita, como ejemplo, el caso de aquellas empresas en las que todos los servicios de TI están rodeados de las más rigurosas normas de seguridad, mientras que los reportes que imprimen los usuarios, circulan libremente o descansan sobre los escritorios sin que nadie vele por su confidencialidad. Por esto, no dejamos de enfatizar que la seguridad de la información que maneja y 193

Capítulo XIV

procesa TI y la seguridad de la empresa deben estar perfectamente alineadas. Es importante mantener en perspectiva que la seguridad también debe establecerse en función de las necesidades del negocio. Si se cae en el error de establecer la seguridad como una prioridad por sí misma, se limitarán las oportunidades que ofrecen las capacidades de computación y telecomunicaciones para realizar un intercambios de información con los diferentes asociados de negocio, con los que se comparten procesos, como son los clientes -a los que se les da acceso vía Web para realizar transacciones- y los proveedores –con los que se comparten procesos para ordenar bienes o servicios y para cancelar cuentas por pagar-. La administración de la seguridad debe tomar en cuenta las características del negocio y los servicios que presta la organización TI, para establecer normas, procedimientos y protocolos de seguridad, que aseguren que la información esté debidamente resguardada, pero accesible cuando se necesita, para aquellos usuarios debidamente autorizados. Una vez establecidos los requerimientos de seguridad del negocio, la administración de la seguridad en TI debe supervisar que tales requerimientos estén contemplados dentro de cualquier acuerdo de servicio que se establezca con los usuarios y, además, debe garantizar su cumplimiento. La administración de la seguridad debe asimismo, identificar los riesgos a los que está expuesta la infraestructura TI, con el fin de proponer medidas que los mitiguen o eliminen. Esto es, será también importante para la administración de seguridad de información, que esta sea proactiva y evalúe permanentemente los riesgos de seguridad que pueden ir surgiendo a medida que los sistemas y la infraestructura tecnológica vayan evolucionando.

1.1.- Ventajas Entre las principales ventajas que aporta una adecuada implantación de la disciplina de administración de seguridad de la información, pueden citarse los siguientes: • Se preserva la integridad de los datos. • Se preserva la confidencialidad de los datos y la privacidad de clientes y usuarios. • Se cumple la normativa de la empresa relacionada con la seguridad de información. 194


• •

Se evitan interrupciones del servicio causadas por virus, ataques de hackers, etc. Mejora la percepción y confianza de los usuarios y clientes en cuanto a la calidad del servicio.

1.2.- Barreras La implementación de la disciplina de seguridad de la información tropieza con barreras como las siguientes: • No existen políticas de seguridad en el nivel de la empresa. • No existe el suficiente compromiso de todos los miembros de la organización TI con la seguridad. •

• • •

No se dispone de las herramientas necesarias para monitorizar y garantizar la seguridad del servicio –como software de seguridad, antivirus, hardware de seguridad como firewalls, etc.Se establecen políticas de seguridad excesivamente restrictivas que afectan la buena marcha de las operaciones. El personal no recibe una formación adecuada para aplicar correctamente los procedimientos de la disciplina. No se realiza una minuciosa identificación y evaluación de riesgos.

2.- La seguridad en el nivel de la empresa Señalábamos en párrafos anteriores que la administración de seguridad de la información no es sólo un problema de TI, sino que la disciplina debe formar parte de la estrategia y normativa que se hayan establecido en el nivel de la empresa. En tal sentido, como mínimo, en el nivel de la empresa se deben haber establecido: 1. Categorías Cada empresa, de acuerdo con las características de sus operaciones, establece diferentes categorías en la confidencialidad de su información; a título de ejemplo podemos citar los siguientes niveles: • Estrictamente confidencial • Confidencial • Sólo para uso interno • Público 195

Capítulo XIV

2. Criterios de categorización Los criterios de categorización, permiten establecer cuando un documento, reporte, memorando, plano, registro de base de datos, etc. es estrictamente confidencial, confidencial, sólo para uso interno o público. Las empresas acostumbran a identificar en forma visible la categoría de seguridad de cada documento. Así, por ejemplo, veremos memorandos en los que aparecen claramente visibles las palabras “confidencial” o “sólo uso interno”; análogamente, las aplicaciones hacen una indicación similar en los reportes que imprimen. 3. Procedimientos Los procedimientos establecen qué normas deben cumplirse para proteger la información, de acuerdo con su categoría. Así mismo, establecen qué funcionarios, de acuerdo con su nivel, pueden tener acceso a información clasificada como estrictamente confidencial o confidencial. Adicionalmente, los procedimientos también establecen las responsabilidades que cada funcionario tiene sobre la información a la que accede y los pasos que deberán darse para cumplir con la normativa al utilizar la información 4. Funcionarios de seguridad por área funcional Una vez que en el nivel de la empresa se establecen normas y procedimientos de seguridad, normalmente, se establecen las funciones del coordinador de seguridad de cada área del negocio, quien será responsable de velar por la adecuada clasificación de los documentos e información del área, de verificar que los procedimientos de seguridad son viables para su área y de velar por su cumplimiento. Es costumbre que este rol opere en estrecho contacto con el administrador de seguridad en TI, ya que tendrá como responsabilidad autorizar o revocar los niveles de acceso que se otorguen a los funcionarios de su área, con el fin de poder tener acceso a servicios y aplicaciones, de acuerdo con sus responsabilidades.

196


3.- Actividades La administración de la seguridad esta estrechamente relacionada con todas las disciplinas de administración y todos los procesos de TI, por lo que para resultar exitosa requiere el concurso y la colaboración de toda la organización. Para que esa colaboración sea eficaz es necesario que la administración de la seguridad: • Establezca una clara y definida política de seguridad que sirva de guía a todos los otros procesos. • Elabore un plan de seguridad que incluya los niveles de seguridad adecuados tanto en los servicios prestados a los clientes como en los acuerdos de servicio firmados con proveedores internos y externos. • Implemente el plan de seguridad. • Monitorice y evalúe el cumplimiento de dicho plan. • •

Supervise proactivamente los niveles de seguridad analizando tendencias, nuevos riesgos y vulnerabilidades. Realice periódicamente auditorías de seguridad.

197

Capítulo XIV

4.- Políticas de seguridad Es imprescindible disponer de un marco general que establezca los criterios para todas las disciplinas y procesos de TI. En especial, la política de seguridad debe establecer: • La relación con las políticas y normas de seguridad de la empresa. • La coordinación con las otras disciplinas de administración de servicios de TI. • La coordinación con los funcionarios responsables de la seguridad de información en las áreas funcionales. • • • •

La estructura organizativa y los responsables del proceso de administración de la seguridad. Los recursos necesarios: software, hardware y personal. Los programas de divulgación y formación. Los procedimientos de análisis de riesgos.

• • •

El nivel de monitorización de la seguridad. Los informes que deben ser generados periódicamente. Las auditorías externas e internas de seguridad.

5.- El plan de seguridad El objetivo del plan de seguridad es fijar los niveles de seguridad que deben ser incluidos como parte de los acuerdos de servicio que se establecen con los usuarios y en el nivel operacional. El plan debe ser desarrollado conjuntamente con la administración de niveles de servicio, responsable en última instancia de la calidad del servicio prestado a los clientes, así como también de la calidad de los servicios que recibe la organización TI de los proveedores externos. El plan de seguridad debe diseñarse para ofrecer un servicio a los usuarios mejor y más seguro, nunca como un obstáculo para el desenvolvimiento de las actividades del negocio: • Debe ser coherente Los procedimientos de seguridad deben ser coherentes en todas las fases del servicio de TI y para todos los niveles de la organización. Deben tomar en cuenta que "una cadena es tan resistente como el más débil de sus eslabones", por lo que carece de sentido, por ejemplo, establecer estrictas normas de acceso si en las aplicaciones se mantienen vulnerabilidades por un uso 198


inadecuado de las facilidades de seguridad que ofrecen los manejadores de bases de datos utilizados en la empresa. •

Indicadores Clave Siempre que sea posible deben definirse métricas e indicadores clave que permitan evaluar los niveles de seguridad y el cumplimiento de las normas.

6.- Cumplimiento de la normativa de seguridad La administración de seguridad de la información es responsable de motorizar y coordinar la implementación de los procedimientos y las medidas de seguridad establecidas en el plan de seguridad. El administrador de la seguridad debe velar por que: • El personal conozca y acepte las normas de seguridad establecidas y sus responsabilidades. • Exista una aceptación formal, asegurando que los empleados firmen acuerdos de confidencialidad acordes con su cargo y responsabilidades. • Se está impartiendo al personal una formación adecuada. • Se está comunicando adecuadamente la normativa y las consecuencias de las infracciones. Al establecerse la disciplina de administración de la seguridad de la información, se deben: • Asignar los recursos necesarios. • • • • •

Instalar y mantener las herramientas de hardware y software necesarias para garantizar la seguridad. Documentar adecuadamente toda la normativa, los procedimientos e instructivos. Establecer las políticas y procedimientos de acceso a la información. Establecer acuerdos con el centro de atención en relación con el manejo de incidentes relacionados con la seguridad. Establecer acuerdos con la administración de cambios y de versiones, con el fin de asegurar que no se introduzcan vulnerabilidades en las aplicaciones que pasan al ambiente de producción.

199

Capítulo XIV

•

Establecer acuerdos con la administración de la continuidad de los servicios, para asegurar que, bajo ninguna circunstancia, peligra la integridad o la confidencialidad de los datos. • Establecer procedimientos e implementar herramientas que permitan monitorizar las redes y los servicios para detectar intrusiones y ataques. Es necesario que tanto la gerencia de TI, como todos los niveles ejecutivos de la empresa otorguen suficiente autoridad a los administradores y se establezcan medidas disciplinarias que deben ser aplicadas cuando los empleados o cualquier otro personal relacionado con los servicios de TI no cumpla con la normativa de seguridad.

7.- Evaluación y mantenimiento Normalmente las empresas practican evaluaciones en forma continua mediante auditorías de seguridad externas e internas, realizadas por personal independiente de la administración de la seguridad. El propósito de estas evaluaciones y auditorias deben calificar el nivel de seguridad y proponer mejoras que permitan perfeccionar los procedimientos y las normas de seguridad. Además de las evaluaciones periódicas, cada incidente relacionado con seguridad deberá investigarse, con el propósito de tomar las medidas correctivas necesarias para evitar su repetición. La administración de la seguridad debe concebirse como un proceso en continuo perfeccionamiento, por lo que tanto la normativa, como el plan de seguridad deben actualizarse constantemente, al igual que debe renovarse y mejorarse, en forma continua, el conjunto de herramientas de hardware y software implementadas. No existe nada tan vulnerable como una seguridad basada en medidas obsoletas. Será fundamental que la administración de la seguridad maneje información actualizada sobre nuevos riesgos frente a virus, software espía, malware y ataques de hackers, con el fin de adoptar las medidas necesarias para actualizar hardware y software, sin dejar a un lado los aspectos de comunicación y formación.

200


8.- Evaluación de la disciplina Al igual que para todas las disciplinas de administración de servicios de TI, para la administración de la seguridad debe realizarse un riguroso control que asegure el cumplimiento de sus objetivos: • Acceso eficiente a la información por el personal autorizado. • Disminución del número de incidentes relacionados con seguridad. • Identificación proactiva de vulnerabilidades, antes de que estas puedan provocar un incidente de seguridad. La producción periódica de informes permitirá que la gerencia de TI evalúe el desempeño de la administración de la seguridad de la información y aportará información valiosa a otras áreas de TI. Entre los reportes más importantes a producir, podemos citar: Entre la documentación generada cabría destacar: • Relación de incidentes relacionados con seguridad clasificados por su impacto sobre la calidad de los servicios. • Relación del cumplimiento de los programas de formación y evaluación de sus resultados. • Identificación de nuevos riesgos y vulnerabilidades que enfrenta la infraestructura TI. • Resultados de auditorías de seguridad. • •

Informes sobre el grado de implementación y cumplimiento de los planes de seguridad establecidos. Informes sobre el cumplimiento de los acuerdos de servicio y acuerdos operacionales, en lo relacionado a la seguridad de la información.

201

Capítulo XIV

202

Capítulo XV

M e dic ión

Capítulo XIV

Medición Tabla de contenido 1.¿En qué consiste la medición de los servicios de TI?............205 1.1.- ¿Por qué medir? .................................................................206 1.2.- ¿Qué debemos medir?........................................................207 1.3.- ¿Quiénes participan en la medición? .................................207 1.4.- Criterios para definir indicadores ......................................207 1.5.- Interpretación de indicadores.............................................208 2.Uso de los indicadores ...........................................................209 3.Algunos indicadores o mediciones ........................................211

204


Medición

1.- ¿En qué consiste la medición de los servicios de tecnología de información? La gerencia de los servicios TI constituye un eslabón adicional en la cadena de valor de una organización de TI, lo que le permite dejar de ser sólo un proveedor de tecnología, para convertirse en un proveedor de servicios de para el negocio. Esto significa que una adecuada gestión de los servicios de TI aporta valores adicionales como son: •

Atención de las necesidades del negocio mediante de servicios integrales. • Alineación de los servicios TI con el negocio. • Compromiso con el negocio a través de acuerdos de niveles de servicio. • Propuestas proactivas para mejorar los servicios. Sin embargo, para que estos servicios de TI puedan alinearse realmente con el negocio, debe disponerse de indicadores que permitan calibrar el grado de alineación y el nivel de calidad de los servicios. Es importante señalar que, si bien el uso de un buen conjunto de indicadores permite controlar la organización TI y orientar los servicios hacia niveles de calidad creciente; no es menos cierto, que un conjunto de indicadores mal concebidos sólo contribuirán a crear burocracia y restarle iniciativa a la organización. También es importante puntualizar que las mediciones no son niveles de servicio, pues no involucran ningún tipo de acuerdo o negociación y sólo buscan reflejar objetivamente una situación. En el desarrollo de una métrica es necesario responder a las preguntas claves: • ¿Qué debemos medir? • ¿Quiénes participarán en la medición? •

¿Qué indicadores se requieren? 205

Capítulo XIV

1.1.- ¿Por qué medir? En general, se mide para conocer o calificar una realidad y poder tomar decisiones destinadas a modificar su comportamiento. Desde el punto de vista de la alineación de TI al negocio, se mide para mejorar los servicios, ya que dicha mejora se traducirá en satisfacción de los usuarios y en operaciones más eficaces y eficientes. También se mide para controlar la infraestructura tecnológica, que es la base fundamental para proporcionar los servicios que requiere el negocio.

Así pues podemos afirmar que la medición en la gerencia de servicios de TI cumple funciones diversas: • Evaluación del grado de alineación de TI con las necesidades y objetivos del negocio • Evaluación del nivel de soporte a los usuarios • Control gerencial, tanto de la organización TI, como de las áreas medulares del negocio

206


•

•

Información para los entes interesados como: usuarios, gerentes, empleados, comité de sistemas1, comité de dirección, autoridades externas, etc. Comparación de la gestión de servicios de TI con otras organizaciones, estándares y “mejores prácticas”

1.2.- ¿Qué debemos medir? Indudablemente, la medición debe hacerse sobre los servicios del catálogo, ya que los servicios incluidos en ese catálogo constituyen la mejor forma de establecer una comunicación inteligente entre los usuarios y la organización de TI. Sin embargo, para poder medir los servicios tenemos que hacer mediciones sobre los componentes que los soportan, sobre los procesos que administran dicha tecnología y sobre los equipos de trabajo que los soportan. Con toda esa información, por agregación, se generan indicadores que califican el servicio, que en definitiva son los que necesitamos para asegurar que la gestión está alineada con los intereses del negocio.

1.3.- ¿Quiénes participan en la medición? Para establecer un verdadero sistema de medición, deberemos contar con la participación de los diferentes niveles de la organización: responsables de servicio, gestores de proceso, responsables de departamentos y personal técnico. Cada uno de ellos deberá participar en la definición y posterior publicación periódica de los indicadores de su ámbito de competencia.

1.4.- Criterios para definir indicadores Los datos requeridos para calcular un indicador o, en general, para alimentar una métrica deben poderse recopilar en forma sencilla, pues de lo contrario se arriesga a imponer una considerable carga de trabajo a la organización, que puede acarrear que se descuide la atención de los servicios en aras de poder medirlos, lo cual sería un verdadero contrasentido. 1

Muchas empresas utilizan la figura del comité de sistemas o comité directivo, integrado por los ejecutivos más importantes del negocio y de informática. Todos los planes de TI se presentan al comité de sistemas, con el fin de obtener su aprobación. Esta aprobación, dada la estructura del comité, representa un acuerdo entre las áreas del negocio e informática, para desarrollar los sistemas de información y los servicios en términos de requerimientos, recursos y calendarios.. 207

Capítulo XIV

Existen ciertos criterios que la experiencia ha creado, como SMART (specific, measurable, achievable, realistic, timely), que nos dice que los indicadores deben ser específicos, mesurables, viables, realistas y oportunos. Todos estos criterios, como conjunto, nos aconsejan que en el desarrollo de mediciones se mantenga en perspectiva que las mediciones deben ser: • Significativas, deben ayudar realmente a calificar un servicio. • Corresponder a un solo proceso o a parte de uno, ya que de lo contrario será difícil establecer responsabilidades. • Viable, es decir, de nada vale pensar en mediciones para las cuales no se dispone del instrumental adecuado para tomar la medición. Por ejemplo, si no disponemos de un ACD, no podemos medir qué porcentaje de llamadas al centro de atención son abandonadas por los usuarios. • Oportuna, pues de nada nos sirve, por ejemplo, el promedio de llamadas recibidas en el centro de atención hace un año, necesitamos conocer la carga actual.

1.5.- Interpretación de indicadores Además de establecer los datos que deberán utilizarse para el cálculo de un indicador y su periodicidad, será fundamental establecer: • El significado del indicador, ¿qué nos dice?, ¿para qué nos sirve? •

Los rangos de valores, para establecer cuándo un valor nos indica que el proceso está bien o cuándo está mal. Normalmente se establecen: • Los valores posibles • Los valores normales, que indican que el proceso se desempeña en forma normal • Los valores de alerta, que indican que el proceso está cercano a una situación de problema • Los valores que indican que el proceso experimenta algún problema • El valor meta, que es el valor que la gerencia espera alcanzar en una próxima evaluación, como consecuencia de las decisiones y acciones tomadas.

208


2.- Uso de los indicadores Es obvio que las mediciones las realizamos para calibrar algún proceso y tomar las acciones que permitan corregir una situación inconveniente o mejorar un proceso en forma continua. El método más popular para crear una situación de mejora continuada es el PDCA, conocido también como el "círculo de Deming" -por Edwards Deming-. Se trata de un método de mejora continua de la calidad de los procesos que integra cuatro pasos, originalmente diseñado por Walter Shewhart -conocido como el padre del control estadístico de la calidad-. Este método, que muchos denominan “espiral de mejora continua” ha sido adoptado por las normas ISO. PDCA es el acrónimo de “Plan, Do, Check, Act” -Planificar, Hacer, Verificar, Actuar-. Su adopción permite que las organizaciones adquieran la disciplina de planificar una acción, tomarla, revisar su cumplimiento y sus resultados y actuar según lo que se ha aprendido. PLAN - Planificar, establecer los planes 1. Identificar el proceso que se quiere mejorar 2. Recopilar datos para profundizar en el conocimiento del proceso 3. Analizar e interpretar los datos 4. Establecer los objetivos de mejora 5. Especificar los resultados esperados 6. Definir las acciones necesarias para conseguir los objetivos de mejora DO - Llevar a cabo los planes 7. Ejecutar las acciones definidas en el paso anterior. 8. Documentar las acciones realizadas. CHECK - Verificar si los resultados concuerdan con los planes 9. Pasado un periodo de tiempo previsto de antemano, volver a recopilar datos de control y a analizarlos, comparándolos con los objetivos y especificaciones iniciales, para evaluar si se ha producido la mejora esperada. 10. Documentar las conclusiones. ACT - Actuar para corregir los problemas identificados 209

Capítulo XIV

11. Si fuese necesario, modificar los procesos según las conclusiones del paso anterior. 12. Aplicar nuevas mejoras, si se han detectado en el paso anterior. 13. Documentar el proceso

210


3.- Algunos indicadores o mediciones A continuación presentamos algunos indicadores que pueden ser adoptados para calibrar los servicios de TI. 1Número de usuarios servidos por técnico 2Número de empleados cumpliendo actividades TI 3Número de técnicos TI para desarrollar y manejar las relaciones con usuarios 4Número de técnicos TI para manejar el negocio de TI 5Número de técnicos TI para manejar riesgos 6Número de técnicos TI para desarrollar y mantener soluciones 7Número de técnicos TI para implementar soluciones 8Número de técnicos TI para dar soporte a soluciones 9Número de técnicos de proveedores externos 10- Número de técnicos para dar soporte a la arquitectura de información 11- Número de técnicos para manejar recursos de información 12- Número de técnicos cumpliendo el rol de arquitectos TI 13- Tiempo promedio para alcanzar el punto de equilibrio (break even) para nuevos servicios de TI 14- Tiempo promedio de puesta en operación de nuevos servicios o mejorados por nivel de inversión 15- Total presupuesto TI por empleado 16- Porcentaje de cambio en el presupuesto de TI para el próximo año 17- Porcentaje de presupuesto TI usado para operar versus usado para crecimiento 18- Distribución de gastos operativos de TI versus presupuesto de capital 19- Distribución de presupuesto operativo para hardware, software, personal, proveedores externos de servicios, redes/telecomunicaciones, facilidades, y otros 20- Distribución de presupuesto TI operativo relacionado con software

211

Capítulo XIV

212223-

24252627282930313233343536373839404142-

212

Distribución de presupuesto TI operativo relacionado con personal Distribución de presupuesto TI operativo relacionado con redes/telecomunicaciones Distribución de presupuesto TI de capital relacionado con equipos de computación, de almacenamiento, software, red/telecomunicaciones, proveedores externos de servicios y otros Distribución de presupuesto de capital relacionado con equipos de computación y de almacenamiento Distribución geográfica de usuarios TI Distribución geográfica de técnicos TI Porcentaje de elementos de información con custodios asignados Número de proyectos de desarrollo cumplidos Número de proyectos en ejecución Número de proyectos en backlog Porcentaje de proyectos entregados a tiempo o antes Porcentaje de proyectos entregados por debajo de lo presupuestado Porcentaje de funcionalidad ofrecida al inicio realmente entregada Tiempo promedio para atender a problemas de alta prioridad Tiempo promedio para resolver problemas de alta prioridad Tiempo promedio para atender a problemas de mediana prioridad Tiempo promedio para resolver problemas de mediana prioridad Tiempo promedio para atender a problemas de baja prioridad Tiempo promedio para resolver problemas de baja prioridad Número de correcciones realizadas que requirieron retrabajo Tiempo promedio para atender requerimientos de información, por categoría Tiempo promedio para desarrollar un plan estratégico de TI para un área del negocio


43444546474849-

Horizonte de planificación Tiempo promedio para atender un requerimiento del negocio con soluciones de TI relevantes, por nivel de costo Cantidad de suspensiones de servicio no planificadas ocasionadas por cambios realizados Cantidad de suspensiones de servicio no planificadas ocasionadas por implementación de versiones Tiempo promedio para implementar un cambio en el ambiente de producción Tiempo promedio para implementar una nueva versión en el ambiente de producción Tiempo promedio para resolver una interrupción de servicio

213

Anexo I I m pla nt a c ión de la s Disc iplina s de Adm inist ra c ión de Se rvic ios de T I

Una vez que se toma la decisión de incorporar las disciplinas de administración de servicios en una organización de TI, no puede esperarse una implementación instantánea, sino todo lo contrario, la implementación tiene que ser paulatina, bien planificada y con expectativas realistas para cada paso. Para comenzar, es importante tomar conciencia de que la inserción de las disciplinas van a significar cambios importantes en la organización y, como normalmente ocurre con cualquier cambio, van a ser recibidos con resistencia. Cada disciplina va a representar un cambio cultural que habrá que manejar con decisión, pero realizando todos los esfuerzos que sean necesarios para que todo el personal técnico y de gerencia comprenda y acepte esos cambios. Una campaña de charlas, folletos y cursos será imprescindible para dar inicio a la implementación de las disciplinas y, posteriormente, para implementar cada disciplina en particular, habrá que cumplir tareas similares, pero específicas para cada disciplina. Ninguna disciplina debería ser puesta en funcionamiento sin estar dotada de procedimientos escritos, perfectamente definidos y discutidos previamente con personas claves dentro de la organización TI y de las áreas funcionales. Para su implementación, podrían cubrirse diferentes fases como las siguientes: Fase I.Inicialmente, las disciplinas que dada su importancia debieran ser implementadas son: 1. Administración de la seguridad de información 2. Administración de la configuración 3. Administración de cambios 4. Administración de la continuidad de los servicios TI Fase II.- En una segunda fase deberían implementarse las disciplinas de: 213

5. Centro de atención 6. Manejo de incidentes 7. Manejo de problemas Fase III.- En una tercera fase debería implementarse la disciplina de: 8. Administración de versiones Fase IV.- En una cuarta fase debería implementarse la disciplina de: 9. Monitorización y control Fase V.- En la quinta fase debería implementarse la disciplina de: 10. Administración de la disponibilidad 11. Administración de la capacidad 12. Administración de niveles de servicio – Catálogo de servicios 13. Administración financiera de los servicios TI Fase VI.- En la fase final completarse el proyecto implementando las disciplinas de: 14. Administración de niveles de servicio Para cada fase y cada disciplina, al preparar los planes de trabajo, será fundamental cumplir un proceso de evaluación y selección de herramientas. Claro está, que si se selecciona una herramienta de gran alcance como son Tívoli o Unicenter, sólo será necesario para cada disciplina, revisar la forma como los módulos correspondientes serán utilizados. Cada disciplina, a su vez, debe implementarse por etapas, ya que es poco probable que de un solo golpe pueda cubrirse el alcance completo para cada disciplina. A título de ejemplos veamos la forma como podemos definir las etapas para la disciplina de administración de la seguridad de información: 1. Asignación de responsables para la administración de la disciplina. 2. Creación de responsables de seguridad en cada una de las áreas del negocio (coordinador funcional de seguridad). 3. Establecer procedimientos para la cooperación entre el administrador de seguridad, los coordinadores de seguridad por área del negocio y el administrador de la red, con el fin coordinar la creación de nuevos usuarios, cambio de niveles de autoridad y 214

manejo de suspensiones de servicio temporales, por vacaciones, o definitivos. 4. Asegurar el uso adecuado de los elementos de seguridad para tener acceso a la red. 5. Desarrollar la normativa sobre actualización y cambios periódicos y forzosos de claves. 6. Revisión de la estructura física de la red destinada a robustecer la estructura de seguridad, como pueden ser la creación de zonas desmilitarizadas de alta seguridad - separando los ambientes de internet, extranet, intranet y ambientes de base de datos- y la creación de virtuales para agrupar y aislar usuarios. 7. Implantación de normativa relativa a la seguridad de acceso a las bases de datos, utilizando las facilidades del manejador, eliminando prácticas inadecuadas como utilizar un usuario único de base de datos por cada aplicación y pretender que, en el nivel de la aplicación, puede manejarse mejor la seguridad. Este tipo de práctica, muy generalizada por cierto, crea brechas de seguridad importantes, ya que cualquier persona que conozca ese único código de usuario, puede tener acceso a la base de datos y modificar la información sin estar autorizado para ello. 8. Desarrollar la normativa de manejo de seguridad en las aplicaciones y comenzar a hacer los ajustes necesarios para que todas las aplicaciones se adapten a la nueva normativa. 9. Contratar servicios de auditorías externas a la seguridad de la red e implementar recomendaciones dirigidas a robustecer los procedimientos. En líneas generales, para cada disciplina deberán cumplirse actividades como las siguientes: 1) Definir el alcance para la disciplina 2) Definir las etapas que serán cubiertas y el alcance para cada etapa 3) Diseñar el modelo de funcionamiento deseado –utilizando DFD´s, Diagramas de Actividad, Diagramas de Use Case o cualquier otra herramienta4) Evaluar herramientas –si es necesario5) Seleccionar herramienta –si es necesario6) Hacer ajustes en el modelo de funcionamiento, según sea necesario para adaptarlo a la forma de operar de la herramienta seleccionada 215

7) Cumplir tareas de desarrollo y ajuste a) Probar la herramienta en ambiente de desarrollo, seleccionar opciones y ajustar parámetros según sea necesario b) Desarrollar procedimientos c) Probar herramientas y procedimientos en ambiente de prueba 8) Desarrollar planes de acción a) De adiestramiento b) De comunicación a TI y a la empresa c) Para implementar la herramienta en producción d) Para poner en vigor la disciplina 9) Implementar la disciplina cumpliendo los planes de acción trazados 10) Desarrollar plan de trabajo a mediano y largo plazo para cumplir las restantes etapas definidas en el paso 3 11) Evaluar resultados de la etapa y plantear plan de mejoras

216

Anexo II

COBI T Proc e sos de T I I - PLANIFICACIÓN Y ORGANIZACIÓN 1. Definición de un plan estratégico de TI 2. Definición de la arquitectura de Información 3. Determinación de la dirección tecnológica 4. Definición de la organización y de las relaciones de TI 5. Manejo de la Inversión en TI 6. Comunicación de la dirección y expectativas de la gerencia 7. Administración de recursos humanos 8. Asegurar el cumplimiento de requerimientos externos 9. Evaluación de Riesgos 10. Administración de proyectos 11. Administración de calidad

II - ADQUISICIÓN E IMPLEMENTACIÓN 1. 2. 3. 4. 5. 6.

Identificación de soluciones Adquisición y mantenimiento de software de aplicaciones Adquisición y mantenimiento de arquitectura de tecnología Desarrollo y mantenimiento de procedimientos Instalación y acreditación de sistemas Administración de cambios

III - ENTREGA DE SERVICIOS Y SOPORTE 1. 2. 3. 4. 5. 6.

Definición de niveles de servicio Administración de servicios prestados por terceros Administración de desempeño y capacidad Aseguramiento de servicio continuo Asegurar la seguridad de los sistemas Identificación y atribución de costos 217

7. Educación y entrenamiento de usuarios 8. Apoyo y asistencia a los clientes de TI 9. Administración de la configuración 10. Manejo de problemas e incidentes 11. Administración de datos 12. Administración de instalaciones 13. Administración de operaciones

IV - SEGUIMIENTO 1. 2. 3. 4.

Monitorización del proceso Evaluar adecuación a normas de control interno Obtención de evaluación independiente Proveer auditoría independiente

218

Anexo III

COBI T Re la c ione s de los Obje t ivos de Cont rol Dom inios, Proc e sos y Obje t ivos de Cont rol En COBIT se define control como: El conjunto de políticas, procedimientos, prácticas y estructuras organizativas diseñadas para crear una seguridad razonable de que se lograrán los objetivos del negocio y de que se toman acciones para detectar, prevenir o corregir los efectos de eventos indeseables. Análogamente, objetivo de control se define como: Una declaración del resultado deseado o propósito a ser alcanzado, implementando procedimientos de control en alguna actividad particular. A continuación se listan los objetivos de control que establece COBIT, relacionados con los procesos de TI.

I - PLANIFICACIÓN Y ORGANIZACIÓN 1. Definición de un plan estratégico de TI OC-1.1.

TI como parte del plan de la organización a corto y largo plazo

OC-1.2.

Plan a largo plazo de TI

OC-1.3.

Plan a largo plazo de TI - enfoque y estructura

OC-1.4.

Cambios al plan a largo plazo de TI

OC-1.5.

Planificación a corto plazo para la función de TI

OC-1.6.

Evaluación de sistemas existentes

2. Definición de la arquitectura de Información 219

OC-2.1.

Modelo de la arquitectura de información

OC-2.2.

Diccionario de datos y reglas de sintaxis de los datos de la corporación

OC-2.3.

Esquema de clasificación de datos

OC-2.4.

Niveles de seguridad

3. Determinación de la dirección tecnológica OC-3.1.

Planificación de la infraestructura tecnológica

OC-3.2.

Monitorización de tendencias futuras y regulaciones

OC-3.3.

Contingencias en la infraestructura tecnológica

OC-3.4.

Planes de adquisición de hardware y software

OC-3.5.

Estándares de tecnología

4. Definición de la organización y de las relaciones de TI

220

OC-4.1.

Comité de planificación o dirección de la función de TI

OC-4.2.

Ubicación de los TI en la organización

OC-4.3.

Revisión de logros organizacionales

OC-4.4.

Funciones y responsabilidades

OC-4.5.

Responsabilidad de la función de aseguramiento de calidad

OC-4.6.

Responsabilidad de la función de seguridad lógica y física

OC-4.7.

Propiedad y custodia

OC-4.8.

Propiedad de datos y sistemas

OC-4.9.

Supervisión

OC-4.10.

Segregación de funciones

OC-4.11.

Asignación de personal para TI

OC-4.12.

Descripción de puestos para el personal de la función de TI

OC-4.13.

Personal clave de TI

OC-4.14.

Procedimientos para personal contratado

OC-4.15.

Relaciones

5. Manejo de la Inversión en TI OC-5.1.

Presupuesto operativo anual para la función de servicio de información

OC-5.2.

Monitorización de costo - beneficio

OC-5.3.

Justificación de costo - beneficio

6. Comunicación de la dirección y expectativas de la gerencia OC-6.1.

Ambiente positivo de control de la información

OC-6.2.

Responsabilidad de la gerencia en cuanto a políticas

OC-6.3.

Comunicación de las políticas de la organización

OC-6.4.

Recursos para la implementación de políticas

OC-6.5.

Mantenimiento de políticas

OC-6.6.

Cumplimiento de políticas, procedimientos y estándares

OC-6.7.

Compromiso con la calidad

OC-6.8.

Política sobre el marco de referencia para la seguridad y el control interno

OC-6.9.

Derechos de propiedad intelectual

OC-6.10.

Políticas específicas

OC-6.11.

Comunicación para estimular la conciencia de seguridad en TI

7. Administración de recursos humanos OC-7.1.

Reclutamiento y promoción de personal

OC-7.2.

Personal calificado

OC-7.3.

Entrenamiento de personal

OC-7.4.

Entrenamiento cruzado para desarrollar personal de respaldo

OC-7.5.

Procedimientos de evaluación de antecedentes del personal

OC-7.6.

Evaluación de desempeño de los empleados 221

OC-7.7.

Cambios de puesto y despidos

8. Asegurar el cumplimiento de requerimientos externos OC-8.1.

Revisión de requerimientos externos

OC-8.2.

Prácticas y procedimientos para el cumplimiento de requerimientos externos

OC-8.3.

Cumplimiento con regulaciones de seguridad y ergonomía

OC-8.4.

Privacidad, propiedad intelectual y flujo de datos

OC-8.5.

Comercio electrónico

OC-8.6.

Cumplimiento con contratos de seguros

9. Evaluación de Riesgos OC-9.1.

Evaluación de riesgos del negocio

OC-9.2.

Enfoque de la evaluación de riesgos

OC-9.3.

Identificación de riesgos

OC-9.4.

Medición de riesgos

OC-9.5.

Plan de acción contra riesgos

OC-9.6.

Aceptación de riesgos

OC-9.7.

Selección de medidas preventivas

OC-9.8.

Compromiso con la evaluación de riesgos

10. Administración de proyectos

222

OC-10.1.

Marco de acción para la administración de proyectos

OC-10.2.

Participación de los departamentos usuarios en la iniciación de proyectos

OC-10.3.

Miembros y responsabilidades del equipo del proyecto

OC-10.4.

Definición del proyecto

OC-10.5.

Aprobación del proyecto

OC-10.6.

Aprobación de las fases del proyecto

OC-10.7.

Plan maestro del proyecto

OC-10.8.

Plan de aseguramiento de la calidad de sistemas

OC-10.9.

Planificación de métodos de aseguramiento de calidad

OC-10.10. Administración formal de riesgos de proyectos OC-10.11. Plan de prueba OC-10.12. Plan de entrenamiento OC-10.13. Plan de revisión post implementación 11. Administración de calidad OC-11.1.

Plan general de calidad

OC-11.2.

Enfoque de aseguramiento de calidad

OC-11.3.

Planificación de aseguramiento de calidad

OC-11.4.

Revisión de aseguramiento de calidad sobre el cumplimiento de estándares y procedimientos

OC-11.5.

Metodología del ciclo de desarrollo de sistemas

OC-11.6.

Metodología del ciclo de desarrollo de sistemas para realizar cambios mayores a la tecnología actual

OC-11.7.

Actualización de la metodología del ciclo de desarrollo de sistemas

OC-11.8.

Coordinación y comunicación

OC-11.9.

Marco de referencia para la adquisición y mantenimiento de la infraestructura de tecnología

OC-11.10. Relaciones con terceras partes como implementadores OC-11.11. Estándares para la documentación de programas OC-11.12. Estándares para pruebas de programas OC-11.13. Estándares para pruebas de sistemas OC-11.14. Pruebas piloto/en paralelo OC-11.15. Documentación de las pruebas de sistemas OC-11.16. Evaluación de aseguramiento de la calidad sobre el cumplimiento de estándares de desarrollo

223

OC-11.17. Revisión de aseguramiento de calidad sobre el logro de los objetivos de TI OC-11.18. Métricas de calidad OC-11.19. Reportes de revisiones de aseguramiento de calidad

II - ADQUISICIÓN E IMPLEMENTACIÓN 1. Identificación de soluciones OC-1.1.

Definición de requerimientos de información

OC-1.2.

Formulación de acciones alternativas

OC-1.3.

Formulación de estrategias de adquisición.

OC-1.4.

Requerimientos de servicios de terceros

OC-1.5.

Estudio de factibilidad tecnológica

OC-1.6.

Estudio de factibilidad económica

OC-1.7.

Arquitectura de información

OC-1.8.

Reporte de análisis de riesgos

OC-1.9.

Controles de seguridad económica

OC-1.10.

Diseño de huellas de auditoría

OC-1.11.

Ergonomía

OC-1.12.

Selección de software de sistemas

OC-1.13.

Control del proceso de adquisición

OC-1.14.

Adquisición de productos de software

OC-1.15.

Mantenimiento de software de terceras partes

OC-1.16.

Contratos de programación de aplicaciones

OC-1.17.

Aceptación de facilidades

OC-1.18.

Aceptación de tecnología

2. Adquisición y mantenimiento de software de aplicaciones OC-2.1. 224

Métodos de diseño

OC-2.2.

Cambios significativos a sistemas actuales

OC-2.3.

Aprobación del diseño

OC-2.4.

Definición y documentación de requerimientos de archivos

OC-2.5.

Especificaciones de programas

OC-2.6.

Diseño para la recopilación de datos fuente

OC-2.7.

Definición y documentación de requerimientos de entrada de datos

OC-2.8.

Definición de interfases

OC-2.9.

Interfases usuario-máquina

OC-2.10.

Definición y documentación de requerimientos de procesamiento

OC-2.11.

Definición y documentación de requerimientos de salidas de datos

OC-2.12.

Controlabilidad

OC-2.13.

Disponibilidad como factor clave de diseño

OC-2.14.

Medidas de protección de la integridad de TI en programas de aplicaciones

OC-2.15.

Pruebas de software de aplicación

OC-2.16.

Materiales de consulta y soporte para usuario

OC-2.17.

Reevaluación del diseño del sistema

3. Adquisición y mantenimiento de arquitectura de tecnología OC-3.1.

Evaluación de nuevo hardware y software

OC-3.2.

Mantenimiento preventivo para hardware

OC-3.3.

Seguridad del software del sistema

OC-3.4.

Instalación del software del sistema

OC-3.5.

Mantenimiento del software del sistema

OC-3.6.

Controles para cambios del software del sistema

OC-3.7.

Utilización y seguimiento de los programas utilitarios 225

4. Desarrollo y mantenimiento de procedimientos OC-4.1.

Requerimientos operativos y niveles de servicio

OC-4.2.

Manual de procedimientos para usuarios

OC-4.3.

Manual de operaciones

OC-4.4.

Material de entrenamiento

5. Instalación y acreditación de sistemas OC-5.1.

Entrenamiento

OC-5.2.

Desempeño y magnitud del software de aplicación

OC-5.3.

Plan de implementación

OC-5.4.

Conversión del sistema

OC-5.5.

Conversión de datos

OC-5.6.

Estrategias y planes de prueba

OC-5.7.

Pruebas de cambios

OC-5.8.

Criterios de desempeño de pruebas en paralelo/piloto

OC-5.9.

Prueba de aceptación final

OC-5.10.

Pruebas de seguridad y acreditación

OC-5.11.

Prueba operacional

OC-5.12.

Migración a producción

OC-5.13.

Evaluación del cumplimiento de requerimientos del usuario

OC-5.14.

Revisión gerencial post - implementación

6. Administración de cambios

226

OC-6.1.

Inicio y control de solicitudes de cambio

OC-6.2.

Evaluación de impacto

OC-6.3.

Control de cambios

OC-6.4.

Cambios de emergencia

OC-6.5.

Documentación y procedimientos

OC-6.6.

Mantenimiento autorizado

OC-6.7.

Política de implementación de software

OC-6.8.

Distribución de software

III - ENTREGA DE SERVICIOS Y SOPORTE 1. Definición de niveles de servicio OC-1.1.

Marco de referencia para los acuerdos de nivel de servicio

OC-1.2.

Aspectos sobre los acuerdos de nivel de servicio

OC-1.3.

Procedimientos de ejecución

OC-1.4.

Monitorización y reporte

OC-1.5.

Revisión de acuerdos y convenios de niveles de servicio

OC-1.6.

Elementos sujetos a cargo

OC-1.7.

Programa de mejoramiento del servicio

2. Administración de servicios prestados por terceros OC-2.1.

Interfaces con proveedores

OC-2.2.

Relaciones con dueños

OC-2.3.

Contratos con terceros

OC-2.4.

Calificación de terceros

OC-2.5.

Contratos de outsourcing

OC-2.6.

Continuidad de servicios

OC-2.7.

Relaciones de seguridad

OC-2.8.

Monitorización

3. Administración de desempeño y capacidad OC-3.1.

Requerimientos de disponibilidad y desempeño

OC-3.2.

Plan de disponibilidad

OC-3.3.

Monitorización y reporte

OC-3.4.

Herramientas de modelaje

OC-3.5.

Manejo de desempeño proactivo 227

OC-3.6.

Pronóstico de cargas de trabajo

OC-3.7.

Administración de capacidad de recursos

OC-3.8.

Disponibilidad de Recursos

OC-3.9.

Calendarios de utilización de recursos

4. Aseguramiento de servicio continuo OC-4.1.

Marco de referencia de continuidad de TI

OC-4.2.

Estrategia y filosofía de continuidad de TI

OC-4.3.

Contenido del plan de continuidad de TI

OC-4.4.

Minimización de requerimientos de continuidad de TI

OC-4.5.

Mantenimiento del plan de continuidad de TI

OC-4.6.

Pruebas del plan de continuidad de TI

OC-4.7.

Capacitación sobre el plan de continuidad de TI

OC-4.8.

Distribución del plan de continuidad de TI

OC-4.9.

Procedimientos de procesamiento alternativo para departamentos usuarios

OC-4.10.

Recursos críticos de TI

OC-4.11.

Centro de cómputo y hardware de respaldo

OC-4.12.

Almacenamiento de respaldos fuera de las oficinas

OC-4.13.

Procedimientos de retorna de un plan de continuidad de TI

5. Asegurar la seguridad de los sistemas

228

OC-5.1.

Administrar medidas de seguridad

OC-5.2.

Identificación, autenticación y acceso

OC-5.3.

Seguridad de acceso a datos en línea

OC-5.4.

Administración de cuentas de usuario

OC-5.5.

Revisión gerencial de cuentas de usuario

OC-5.6.

Control hecho por los usuarios sobre las cuentas de usuario

OC-5.7.

Vigilancia de la seguridad

OC-5.8.

Clasificación de datos

OC-5.9.

Administración centralizada de identificación y derechos de acceso

OC-5.10.

Reportes de violaciones y de actividades de seguridad

OC-5.11.

Manejo de incidentes

OC-5.12.

Reacreditación

OC-5.13.

Confianza en contrapartes

OC-5.14.

Autorización de transacciones

OC-5.15.

No rechazo

OC-5.16.

Sendero seguro

OC-5.17.

Protección de funciones de seguridad

OC-5.18.

Administración de llaves criptográficas

OC-5.19.

Prevención, detección y corrección de software "malicioso"

OC-5.20.

Arquitecturas de firewalls y conexión a redes públicas

OC-5.21.

Protección de valores electrónicos

6. Identificación y atribución de costos OC-6.1.

Elementos sujetos a cargo

OC-6.2.

Procedimientos de costeo

OC-6.3.

Procedimientos de cargo y facturación a usuarios

7. Educación y entrenamiento de usuarios OC-7.1.

Identificación de necesidades de entrenamiento

OC-7.2.

Organización de entrenamiento

OC-7.3.

Entrenamiento sobre principios y conciencia de seguridad

8. Apoyo y asistencia a los clientes de TI OC-8.1.

Escritorio de ayuda

OC-8.2.

Registro de llamadas del usuario 229

OC-8.3.

Escalamiento de consultas de clientes

OC-8.4.

Monitorización de atención a clientes y cierre de llamadas

OC-8.5.

Análisis y reporte de tendencias

9. Administración de la configuración OC-9.1.

Registro de la configuración

OC-9.2.

Definiciones de base (estándares) de los ítems de configuración

OC-9.3.

Registro de estatus

OC-9.4.

Control de configuraciones

OC-9.5.

Software no autorizado

OC-9.6.

Almacenamiento de software

OC-9.7.

Procedimientos de administración de configuraciones

OC-9.8.

Responsabilidades en relación al software

10. Manejo de problemas e incidentes OC-10.1.

Sistema de administración de problemas

OC-10.2.

Escalamiento de problemas

OC-10.3.

Seguimiento de problemas y huellas de auditoría

OC-10.4.

Autorizaciones de acceso de emergencia y temporales

OC-10.5.

Prioridades de atención a emergencias

11. Administración de datos

230

OC-11.1.

Procedimientos de preparación de datos

OC-11.2.

Procedimientos de autorización de documentos fuente

OC-11.3.

Recopilación de datos desde documentos fuente

OC-11.4.

Manejo de errores de documentos fuente

OC-11.5.

Retención de documentos fuente

OC-11.6.

Procedimientos de autorización de entrada de datos

OC-11.7.

Chequeos de exactitud, suficiencia y autorización

OC-11.8.

Manejo de errores en la entrada de datos

OC-11.9.

Integridad de procesamiento de datos

OC-11.10. Validación y edición en el procesamiento de datos OC-11.11. Manejo de errores en el procesamiento de datos OC-11.12. Manejo y retención de salidas OC-11.13. Distribución de salidas OC-11.14. Balanceo y conciliación de datos de salida OC-11.15. Revisión de salidas y manejo de errores OC-11.16. Provisiones de seguridad para reportes de salida OC-11.17. Protección de información sensible durante transmisión y transporte OC-11.18. Protección de información crítica a de los servicios de TI OC-11.19. Administración de almacenamiento OC-11.20. Períodos de retención y términos de almacenamiento OC-11.21. Sistema de administración de almacenamiento OC-11.22. Responsabilidades de la administración de los medios de almacenamiento OC-11.23. Respaldo y restauración OC-11.24. Jobs de Respaldo OC-11.25. Almacenamiento de respaldo OC-11.26. Archivos históricos OC-11.27. Protección de mensajes sensitivos OC-11.28. Autenticación e integridad OC-11.29. Integridad de transacciones electrónicas OC-11.30. Mantenimiento continuo de la integridad de los datos almacenados 12. Administración de instalaciones OC-12.1.

Seguridad física 231

OC-12.2.

Discreción de las instalaciones de TI

OC-12.3.

Escolta de visitantes

OC-12.4.

Salud y seguridad del personal

OC-12.5.

Protección contra factores ambientales

OC-12.6.

Suministro ininterrumpible de energía (UPS)

13. Administración de operaciones OC-13.1.

Manual de procedimientos de operación e instrucciones

OC-13.2.

Documentación de procesos de inicio y otras operaciones

OC-13.3.

Calendarios de trabajos

OC-13.4.

Desviaciones de los calendarios de trabajos

OC-13.5.

Continuidad de procesamiento

OC-13.6.

Bitácoras de operación

OC-13.7.

Salvaguarda de formas especiales y de dispositivos de salida

OC-13.8.

Operaciones remotas

IV - SEGUIMIENTO 1. Monitorización del proceso OC-1.1.

Recolección de datos de monitorización

OC-1.2.

Evaluación de desempeño

OC-1.3.

Evaluación de la satisfacción de clientes

OC-1.4.

Reportes gerenciales

2. Evaluar adecuación a normas de control interno

232

OC-2.1.

Seguimiento del cumplimiento del control interno

OC-2.2.

Cumplimiento oportuno del control interno

OC-2.3.

Reporte sobre el nivel de control Interno

OC-2.4.

Seguridad de operación y aseguramiento de control interno

3. Obtención de evaluación independiente OC-3.1.

Certificación/acreditación independiente del control y la seguridad de los servicios de TI

OC-3.2.

Certificación/acreditación independiente del control y la seguridad de los proveedores externos de servicios

OC-3.3.

Evaluación independiente de la efectividad

OC-3.4.

Evaluación independiente de la efectividad de proveedores externos de servicios

OC-3.5.

Aseguramiento independiente del cumplimiento de leyes, requerimientos regulatorios y compromisos contractuales

OC-3.6.

Aseguramiento independiente del cumplimiento de leyes, requerimientos regulatorios y compromisos contractuales por parte de los proveedores externos de servicios

OC-3.7.

Competencia de la función de aseguramiento independiente

OC-3.8.

Participación proactiva de auditoría

4. Proveer auditoría independiente OC-4.1.

Esquemas de auditoría

OC-4.2.

Independencia

OC-4.3.

Ética y estándares profesionales

OC-4.4.

Competencia

OC-4.5.

Planificación

OC-4.6.

Desempeño del trabajo de auditoría

OC-4.7.

Reportes de auditoría

OC-4.8.

Actividades de seguimiento

233

234

Bibliogra fía K. Brand & H. Boonen (2008). IT Governance CobiT 4.1 - A Management Guide 3rd Edition. Van Haren Publishing. Holanda. COBIT® - Publicaciones del COBIT Steering Committee y del IT Governance Institute James W. Cortada (1998). Best Practices in Information Technology. Prentice Hall PTR. Van Haren Publishing. Estados Unidos. B. Johnson & J. Higgin (2007). ITIL and the Software Lifecycle: Practical Strategy and Design Principles. Van Haren Publishing. Holanda. Info Tech Research Group (2005). Building a comprehensive Disaster Recovery Plan. Canadá. Harris Kern, Rich Schiesser, Mayra Muniz (2005). IT Production Services Building Competitive Advantage. Harris Kern's Enterprise Computing Institute Series. Estados Unidos. Harris Kern and Kenneth Moskowitz (2005). Managing IT as an Investment: Partnering for Success. Harris Kern's Enterprise Computing Institute Series. Estados Unidos. itSMF International (2006). Metrics for IT Service Management. Van Haren Publishing. Estados Unidos. Larry Klosterboer (2008). Implementing ITIL Configuration Management. IBM Press. Estados Unidos

235

Alex Nghiem (2005). IT Web Services: A Roadmap for the Enterprise. Harris Kern's Enterprise Computing Institute Series. Estados Unidos. Floyd Piedad and Michael Hawkins (2005). High Availability: Design, Techniques and Processes. Harris Kern's Enterprise Computing Institute Series. Estados Unidos. Rich Schiesser (2005). IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures. Harris Kern's Enterprise Computing Institute Series. Estados Unidos. Randy A. Steinberg (2006). Measuring ITIL. Trafford Publishing. Canadá. Anthony F. Tardugno, Thomas R. DiPasquale and Robert E. Matthews (2005). IT Services: Costs, Metrics Benchmarking, & Marketing. Harris Kern's Enterprise Computing Institute Series. Estados Unidos. The Office of Goverment & Commerce - OGC (2007). ITIL 3 Lifecycle Core Library Service Strategy. The Stationery Office. Reino Unido. The Office of Goverment & Commerce - OGC (2007). The Official Introduction to the ITIL Service Lifecycle. The Stationery Office. Reino Unido. The Office of Goverment & Commerce - OGC (2007). ITIL 3 Lifecycle Publication Suite: Core Publications Collection. The Stationery Office. Reino Unido. The Office of Goverment & Commerce - OGC (2007). ITIL 3 Lifecycle Core Library Service Operation. The Stationery Office. Reino Unido.

236

Efraim Turban, James Wetherbe, Ephraim McLean, Dorothy Leidner (2007). Information Technology for Management: Transforming Organizations in the Digital Economy. Wiley, John & Sons, Incorporated. Estados Unidos. Jan Van Bon (2008). IT Service Management based on ITIL V3: A Pocket Guide. Van Haren Publishing. Holanda. Jan Van Bon (2007). Foundations of IT Service Management Based on ITIL V3. Van Haren Publishing. Holanda. Jan Van Bon (2007). IT Service Management: An Introduction Based on ISO 20000 & ITIL v3. Van Haren Publishing. Holanda. Gary S. Walker (2005). IT Problem Management. Harris Kern's Enterprise Computing Institute Series. Estados Unidos. Sitios Internet (Fuentes electrónicas): ITIL Site oficial: http://www.itilofficialsite.com/home/home.asp Site del Information Systems Audit and Control Association (ISACA): http://www.isaca.org/

237

238

Tecnología de Información Gerencia de Servicios (Basado en ITIL)

Recommend Documents