martes, 13 de enero de 2009

Estrategias IT en 2009

2009... uhhhh! el apocalipsis de la economía, el esperpento de los maestros de la usura. Por supuesto que hay gente honesta pero para los otros, los del lado oscuro "ellos se lo han perdido". En fin que no me enrollo; CRISIS.

Y en medio de esta coyuntura nada propicia los profesionales IT nos preguntamos cómo ejecutar con éxito nuestros proyectos en este escenario. Antes de la crisis ya era difícil culminar aquello que se planteaba por diversos problemas como mala gestión de expectativas, mala comunicación, falta de presupuesto, etc. Más o menos un 65% de los proyectos IT fracasan según ZDNet. Tengamos también en cuenta que el Outsourcing es en sí mismo un gran proyecto del que nacen y al que se agregan proyectos y que, en estos momentos, el Outsourcing  es una gran oportunidad siempre y cuando se provea desde las manos adecuadas (De esto ya hablaré en otro post). En cualquier caso estos son los puntos a tener en cuenta para poder plantear con éxito nuestras soluciones:

1.Meet business needs. Esto significa "Satisfacer las necesidades del negocio". Cada proyecto IT debe satisfacer una demanda del negocio, si no corre el riesgo de convertirse en un esfuerzo y un gasto inútil. La mala comunicación entre las áreas de negocio y la IT complica este simple concepto dentro de muchas organizaciones. Si el negocio critica a su equipo de TI y la comunicación falla es entonces cuando tenemos un problema. El aislamiento lleva al fracaso, y el debate (a veces duro) conduce al éxito. Establecer vías de comunicación y participación en ambas partes; IT y negocio es imprescindible. Para ello existen modelos de governance y buenas prácticas sobre las que hablaré en otros posts. La priorización es un elemento importante siempre pero especialmente en tiempos de crisis. 

2. Innovar; La buena comunicación entre negocio e IT activa una serie de sinergias y espirales positivas tales como el flujo de ideas y libertad creativa. Cuando existe "confianza" y comunicación entre grupos la gente se siente cómoda y el concepto stakeholder cobra luz. De tal modo que cada cual sin miedo a errar comentará su visión, posibles ideas y soluciones a problemas concretos. Por otro lado la capacidad de adaptación es fundamental para la supervivencia, especialmente cuando la economía no va bien. Recordemos que vivimos en un mundo en constante cambio social, económico y tecnológico. Por tanto Innovación y Adaptabilidad son elementos de éxito. Tres son los elementos clave para hacer útiles estos conceptos: la cultura del cambio continuo, la capacidad de autocrítica y asumir errores. En este punto es también muy importante estar al día en las últimas soluciones y productos ya que la innovación no sólo debe ir orientada al rendimiento y funcionalidad sino a la reducción de costes como argumento de venta interna y externa.

3. Ser honesto;  La negación es una de las principales causas de fracaso. Me explico; las organizaciones cuanto más grandes  más complejas y si la gestión es débil, fragmentada, opaca, mal orientada y demasiado verticalizada es entonces muy difícil conocer las verdaderas capacidades, puntos fuertes y débiles dentro de una organización, un área, sección, etc. El cambio es imposible si un equipo no conoce y  reconoce sus limitaciones. Es buena práctica en la gestión de proyectos identificar los factores de riesgo y los limitadores. Por tanto el ejercicio de autoevaluación es difícil y son pocas las organizaciones que lo hacen bien. Recordemos el Dónde estamos, Dónde queremos llegar y qué necesitamos para llegar. Ante todo buenas prácticas.

4. Gestión de Proveedores. En prácticamente todo proyecto IT hay terceras partes implicadas. Y cuando tenemos varios terceros es entonces cuando surgen fricciones, conflictos y se complica la gestión. Muchos son los casos en los que la gestión de terceros en cualquier fase de un proyecto o prestación de servicio genera hacia el cliente ruido, descontento, incumplimientos, etc.  Por tanto es muy importante prestar atención a esas relaciones y formalizar el modelo de relación cuando sea posible vía contrato y gestión de niveles de servicio, etc. Alineando a los proveedores hacia el compromiso y el objetivo. Es aquí donde el talento y los modelos de gobierno y gestión de servicio pueden facilitar el éxito.

5. Asegurarse el apoyo de la Dirección. Muchas iniciativas de IT deben cruzar fronteras políticas dentro de una organización. Por eso en muchas ocasiones conseguir consenso entre los interesados (stakeholders) es difícil. Dado que los problemas surgirán a lo largo de la vida de un proyecto de manera inevitable el ser patrocinado por la dirección es un factor crítico de éxito en todos los grandes proyectos. Hay que asegurarse que la dirección conoce los objetivos, su papel con respecto al proyecto y que se compromete a una participación activa. Por contra cuando la dirección no apoya ni se compromete con un proyecto es muy difícil cumplir las expectativas. Por supuesto que el factor comunicación es esencial para asegurarse apoyos y a veces es difícil hacer tangible algo ajeno a la operación del negocio, aunque indirectamente los proyectos IT no pretenden otra cosa sino la de mejorar la eficiencia y productividad de la empresa y sus empleados. Por tanto hablar en términos de coste y plazos es, en mi opinión, una aproximación entendible y que asegure apoyos.

Estos cinco puntos abarcan las relaciones entre la TI y su entorno incluyendo a interlocutores internos y externos. El factor cultural es esencial para una mayor eficiencia y calidad en los proyectos y servicios IT y es, por tanto, un elemento esencial en momentos de crisis. Ya que las no crisis mimetizan ineficiencias e ingerencias. Los buenos emergen en los malos tiempos. Desde mi punto de vista los intangibles son tan importantes como los tangibles. Sobre todo si se quiere llevar a cabo una buena gestión de extremo a extremo y si se quiere consolidar el valor de los proyectos y servicios IT. Finalmente recordad que vivimos de lo que vivimos y el estar al día de las últimas tecnologías y soluciones en este mundo IT es un requisito esencial.

Lo dicho, suerte en el 2009 y recordad que todo lo malo trae algo bueno.

B.

viernes, 20 de junio de 2008

¿Cuál es el Sistema Operativo más seguro?

Ser o no ser... o lo que es peor; dejar de ser. Eterna pregunta en el último decenio, ¿Verdad?. Y es que cuándo no tomando el café en los rellanos de la oficina hemos contemplado verdaderas luchas entre los pingüinillos y los winderos discutiendo si esto rinde más, o rinde menos. Es más o menos caro. O la eterna afirmación de que Linux es más seguro que Windows.

Cometemos el error siempre de quedarnos en lo genérico, en el ruido mediático y, a veces, en la ignorancia convenida. Es como cuando siendo niño afirmábamos que nuestro padre era el más fuerte y nuestro tío policía. Este breve post os dará un punto de vista más allá de lo técnico.

Basándome en mi experiencia desde técnico a ingeniero de sistemas y posteriormente como Director de Sistemas he aprendido que el ciclo de vida de los sistemas es muy similar a lo que nos sucede en la vida real. Quiero decir que la experiencias son extrapolables y me explico. Si percibes que estás en peligro la tendencia natural es protegerte y tomar medidas que te permitan estar seguro. Y si en cualquier caso eres atacado e incluso consiguen de algún modo afectar la integridad de tus sistemas (sean sistemas servidor, comunicaciones, etc) serás capaz de reaccionar más rápido y de un modo más preciso al problema de seguridad. Evitando por tanto el desastre, la mala imágen, el enfado del usuario, el sobrecoste, las horas de tu gente y tú mismo arreglando el descosido.

Yo no quiero decir que el sistema A sea más seguro que el B. Pero creo que todos estamos de acuerdo en que los sistemas de Microsoft son el objetivo principal de la mayoría de los hackers.

Cabe también tener en cuenta que en la actualidad las técnicas de hacking no se basan en un ataque directo al sistema, sino que se aprovechan de vulnerabilidades en software cliente, software de terceros. Incluso muchas de las técnicas realmente no aprovechan realmente ninguna vulnerabilidad y más cuando el usuario instala algo y ni se entera de lo que pasa por detrás.

Por tanto la seguridad es relativa, y por supuesto la seguridad no es lo mismo en un entorno cliente que en un entorno servidor. Y es tan relativa como lo que voy a afirmar a continuación: "Los problemas en seguridad no son aquellas vulnerabilidades conocidas, sino aquellas que no conocemos o nunca conoceremos". Yo que he trabajado como responsable de seguridad en áreas concretas siempre he mantenido que hay que cubrirse de todo lo conocido y a la hora de diseñar un servicio comenzar de cerrado e ir abriendo cuando sea estrictamente necesario manteniendo siempre la trazabilidad a través de la gestión de cambios.

Uno de los factores importantes para una buena gestión de la seguridad es lograr coordinación e integración de las distintas capas ya que la complejidad es proporcional a las siguientes capas: Física, HW, SW, Apps, SVCs, Red, etc.... por tanto es necesariamente estricto tratar de integrar estas capas en la gestión de la seguridad. No vamos a ponernos ahora a hablar de sistmas de seguridad, IDS, correlación de eventos, health-checking, etc. pero se debe valorar su uso, sobr todo en infraestructuras extensas y complejas.

Por otro lado es muy difícil convencer a un CFO de la justificación de esos costes invisibles e intangibles (intangibles hasta que sucede algo). Por eso es bueno y necesario mantener un enfoque al servicio y al negocio a la hora de gestionar la IT en este y otros ámbitos. Comunicar bien en los Comités de Dirección es esencial para logra el apoyo del CEO y de las otras áreas. Por otro lado el coste de gestión de la seguridad desde mi punto de vista debería incluirse en el coste de operación como uno más. Eso sí capitalizándolo cuando sea necesario.

Por tanto, para mi, el sistema más seguro es aquel gestionado por las personas adecuadas. Muchas empresas descuidan la cualificación del personal por el coste y hay cosas que no se aprenden, hay cosas que merecen el precio que tienen. La propiedad/responsabilidad de lo que se tiene entre manos, el conocimiento, la actitud y automotivación son esenciales para una buena gestión diaria de la seguridad.

Saludos en este viernes soleado (casi es verano).

miércoles, 18 de junio de 2008

Reinos de Taifas

Durante el apogeo de los reinos de taifas (siglo XI y después a mediados ...).... Como diríamos vulgarmente y pecando de inocentes: "¡Vamos no me jodas!"

Y me explico, en este mundo de la consultoría y de los servicios IT tan competitivo, tan trillado, donde muchas veces se subastan los servicios, donde más allá de las propuestas de valor sólo cuenta el coste más bajo, donde te encuentras RFPs que ya marcan un precio de yo te pago no más que... donde el riesgo muchas veces es superior al márgen, etc. Y resulta que las empresas (incluso tu empresa y no te espantes que pecarás de inocente) ya no son empresas, son miniempresas concubinadas bajo yo que sé acuerdos e incestuosas; porque siendo de la misma familia se joden unas áreas a las otras. (Y perdonad la expresión). Y así es. Existe una oportunidad para plantear una solución a un cliente (nuevo o para renovación; renovación en este ejemplo) se acuerda que para renovar es necesario garantizar una reducción de costes digamos de un 20% y bueno engagement y a mover recursos.

De lo obvio surjen las iniciativas clásicas en los tiempos en los que nos movemos. Teniendo en cuenta los costes de los servicios: Service Desk, continuity y recovery, Gestión, etc. Otros como Hardware, Software y Licencias, Costes de CPD, Costes de Almacenamiento y Backup, Las líneas, Costes de los distintos centros de solución que si el de SAP, que si el centro de operación.... etc. Surgen soluciones a priori aplicables virtualización, nos quitamos a la gente de SAP y lo hacemos en local, nos quitamos a la gente de nivel 1 (operación) y nos lo traemos, si virtualizamos los servicios de continuidad y recovery que nos da fulanito no nos hacen falta, si consolidamos el espacio de CPD no nos hacen falta estos "n" metros, etc.

Y claro los Taifas que lejos de ser aquellos que pagaban impuestos para existir sino que para existir te cobran y mucho para lo que te dan, de repente, tienen voz. esa que buscaste cuando la cagaban y tenías que dar la cara ante el cliente. Cómo que vais a quitar este nuestro gran servicio del contrato, que tenía mucho márgen, que tenemos que cuidar de ese dinero, esto hay que escalarlo.... Tela compañeros!. Eso es tener visión lateral, eso es tener visión de empresa si señor.

Lo que os digo, conseguiremos ese 20% de reducción de costes, renovar el contrato, mantener el márgen y crecer en ese cliente. Pero recordad que el enemigo y la resistencia siempre empiezan por dentro. Y más cuánto más grande sea la empresa. Y más cuánto más eficiente e innovador necesites ser. Parece ser que ese 30% de budas, aquellos los de las jaulas de oro, no se conforman sólo con tener más y sentirse más a costa de los demás, sino que crean reinos inservibles, "taj mahales" huecos, solapas llenas de medallas ajenas, y luego cuando los que tiran del carro y les pagan el sueldo tratan de hacer funcionar las cosas les ponen la zancadilla.

Menos mal que algunos los tenemos bien granados y no pasamos tanto tiempos apoltronados en el sillón y sabemos saltar para evitar las trampas. Es mi día de la vulgaridad si, pero qué razón tengo.

Saludos.

martes, 17 de junio de 2008

Presentación

Hola,

Tras las primeras parrafadas de ITIL, ISO y "quién hace qué..." escritas un poco en modo isla me presento. Mi nombre es tan peculiar como el que véis, quizá haya gente que lea este blog y me reconozca (para bien o para mal :P) Mi recorrido profesional comenzó állá por el año 97 y en estos algo más de 10 años he pasado desde técnico a director de sistemas, realizando tareas desde técnico, administrador, consultor, ingeniero y jefe de proyectos. Actualmente trabajo como "process manager" en temas de ITSM, aunque aparte realizo otras tareas de apoyo en programas de mejora, desarrollo de catálogos de servicios, etc. Es decir las tareas propias transformación y delivery desde la parte de governance.

En estos momentos estoy asociado a un cliente importante en el que existen, y se siguen abriendo a diario, proyectos interesantes desde el punto de vista técnico, de procesos y que requieren de una visión estratégica y táctica adecuadas. Además es un cliente en el que existen muchas áreas de mejora y es un cliente perfecto para poder asentar un modelo de governance y procesos (que ya existen)madurable a medio plazo. El cliente es un contribuidor activo y eso es importantísimo. Ya comentaremos en otros posts casos concretos y cómo el factor humano (actitud, modelo de relación, etc) es esencial para obtener un caso de éxtio.

Lo dicho aquí está este blog en el que hablaré desde cosas generales referentes a la IT o las emrpesas ques e dedican a ello hasta para qué sirven los procesos, cómo aproximarse a los mismos y cómo desarrollar un plan de proyecto para la implantación de procesos concretos u otros sobre cómo desarrollar soluciones o evoluciones de infraestructuras y herramientas; qué hay, para qué sirve y cómo se puede implementar.

Trataré de escribir de vez en cuando y cualquier cosa que necesitéis no lo dudéis aquí tenéis un compañero.

Saludos.

lunes, 16 de junio de 2008

¿Quién hace qué en los procesos ITSM?

Una de los problemas más frecuentes a la hora de implementar modelos como ITIL en las organizaciones es aclarar quién hace cada cosa. Máxime cuando la organización interna del departamento IT suele ser funcional y no por procesos, y exceptuando las grandes corporaciones ni siquiera esa división funcional suele ser completa y se tiende a que todos hagan un poco de todo. Este post no pretende ser un mapeo entre áreas funcionales y procesos de ITIL, pero al menos sí una breve reflexión sobre los distintos perfiles que podrían integrarse en cada uno de los procesos de la gestión de servicios IT.
SERVICE DESK: Si empezamos por el service-desk, podemos ver que entre sus funciones están las del clásico call-center, de gestión de incidencias y peticiones, pero también aparecen funciones de soporte técnico (resolución de incidencias) e incluso de interrelación con el cliente a nivel de negocio. Por tanto, este service-desk debería tener gente que no sólo cubriera un perfil de operación básica, sino que sería interesante que hubiese perfiles técnicos algo más elevados e incluso deberían existir personas con cierto perfil comercial, dado que se busca un punto único de contacto con el cliente.
GESTIÓN DE INCIDENCIAS: La gestión de incidentes, desde el punto de vista de una resolución rápida de los mismos, debería estar compuesta por perfiles técnicos de nivel medio o alto, a ser posible interdisciplinares, para facilitar el "pensamiento lateral".
GESTIÓN DE PROBLEMAS: Si pensamos en la gestión de problemas, desde el punto de vista no sólo de la resolución de las causas de los incidentes sino también del de las funciones preventivas, parece necesario contar con un perfil especialista y con gran profundidad en el conocimiento de la infraestructura IT, un perfil técnico de nivel alto. Y a poder ser con buena capacidad de redacción, de cara a los errores conocidos.
GESTIÓN DE CAMBIOS: Para la gestión de cambios me parece muy útil con contar con perfiles de gestión, sobre todo desde el punto de vista de la gestión de proyectos, ya que su función será la de supervisar y controlar todos los cambios relacionados con los servicios IT.
GESTIÓN DE VERSIONES: Para la gestión de versiones son más convenientes perfiles no tan especialistas en gestión pero que conjuguen la gestión de proyectos con los conocimientos técnicos en general y a nivel de desarrollo software en particular, ya que esta suele ser la principal aplicación práctica de este proceso.
GESTIÓN DE LA CONFIGURACIÓN: La gestión de la configuración debería tener dos perfiles complementarios. El primero podría ser un perfil técnico de bajo nivel, encargado de mantener al día la CMDB, pero creo que se debería conjugar con un perfil más elevado, con capacidad para abstraerse de los CIs de bajo nivel y aportar una visión más "de negocio" en relación a los posibles reportes del proceso.
GESTIÓN DE SLAs: El proceso de gestión de niveles de servicio también debería estar compuesto por perfiles tanto técnicos como comerciales de alto nivel, e incluso sería interesante la participación de perfiles con conocimiento sobre los procesos de compras de cara a la gestión de los UCs (contratos de soporte). Al fin y al cabo, la negociación de los SLAs y SLRs se desarrolla en este proceso.
GESTIÓN FINANCIERA: La gestión financiera debería estar desarrollada por perfiles con conocimientos tanto técnicos como económicos (a partes iguales), y con capacidad de gestión y mano izquierda en la práctica.
GESITÓN DE LA CAPACIDAD: La gestión de la capacidad debería estar desarrollada por perfiles técnicos de bajo y alto nivel, para poder llevar a cabo tanto las tareas de monitorización como las tareas de ajuste y sobre todo planificación de la capacidad.
GESTIÓN DE LA DISPONIBILIDAD: Para la gestión de la disponibilidad la situación es similar al caso anterior. Los perfiles de bajo nivel deberían ser los encargados de las funciones de monitorización y seguimiento, mientras que los perfiles de alto nivel se deberían encargar del Plan de Disponibilidad y, sobre todo, de la identificación y aseguramiento (en la medida de lo posible) de las funciones vitales de negocio.
GESTIÓN DE LA CONTINUIDAD: Y por último, la gestión de la continuidad. En este caso, el perfil será multidisciplinar y multinivel, ya que la exigencia va desde el análisis de riesgos y la planificación hasta la implementación de las soluciones técnicas de continuidad y recuperación.

Esta es una propuesta al vuelo de un mapeo entre los procesos de ITIL y los posibles perfiles que puedan existir en un departamento IT.

jueves, 14 de febrero de 2008

ISO/IEC 20000

Tabla de contenidos:


1 ISO/IEC 20000 SERIES

2 Certificación

3 Referencias

4 Enlaces externos


ISO/IEC 20000 SERIES

La serie ISO/IEC 20000 - Service Management normalizada y publicada por las organizaciones ISO (International Organization for Standardization) e IEC (International Electrotechnical Commission) el 14 de Diciembre de 2005, es el estándar reconocido internacionálmente en gestión de servicios de TI (Tecnologías de la Información). La serie 20000 proviene de la adopción de la serie BS 15000 desarrollada por la entidad de normalización y certificación británica BSI - British
Standard Institute




El estándar se organiza en dos partes:


Parte 1: ISO/IEC 20000-1:2005 - Especificación. (Preparada por BSI como BS 15000-1)

Parte 2: ISO/IEC 20000-2:2005 - Código de Prácticas. (Preparada por BSI como BS 15000-2)

La primera parte (Especificación) define los requerimientos (217) necesarios para realizar una entrega de servicios de TI alineados con las necesidades del negocio, con calidad y valor añadidopara los clientes, asegurando una optimización de los costes y garantizando la seguridad de la entrega en todo momento. El cumplimiento de esta parte, garantiza además, que se está realizando un ciclo de mejora contínuo en la gestión de servicios de TI. La especificación suponeun completo sistema de gestión (organizado según ISO 9001) basado en procesos de gestión de servicio, políticas, objetivos y controles. El marco de procesos diseñado se organiza en base a los siguientes bloques:


Grupo de procesos de Provisión del Servicio.

Grupo de procesos de Control.

Grupo de procesos de Entrega.

Grupo de procesos de Resolución.

Grupo de procesos de Relaciones.



La segunda parte (Código de Prácticas) representa el conjunto de mejores prácticas adoptadas y aceptadas por la industria en materia de Gestión de Servicio de TI. Está basada en el estándar "de facto" ITIL (Biblioteca de Infraestructura de TI) y sirve como guía y soporte en el establecimiento de acciones de mejora en el servicio o preparación de auditorías contra el estándar ISO/IEC 20000-1:2005.



Certificación

La aparición de la serie ISO/IEC 20000, ha supuesto el primer sistema de gestión en servicio deTI certificable bajo norma reconocida a nivel mundial. Hasta ahora, las organizaciones podían optar por aplicar el conjunto de mejoras prácticas dictadas por ITIL (completadas por otros estándares como CMMI o CoBIT) o certificar su gestión contra el estándar local británico BS 15000. La parte 1 de la serie, ISO/IEC 20000-1:2005 representa el estándar certificable. En Febrero de 2006, AENOR (organización delegada en España de ISO/IEC) inició el mecanismo de adopción y conversión de la norma ISO/IEC 20000 a norma UNE. El viernes 23 de Junio de 2006, la organización itSMF ([1]) hace entrega a AENOR de la versión traducida de la norma. En el BOE del 25 de julio de 2007 ambas partes se ratificaron como normas españolas con las siguientes referencias:

UNE-ISO/IEC 20000-1:2007 Tecnología de la información. Gestión del servicio.

Parte 1: Especificaciones (ISO/IEC 20000-1:2005).

UNE-ISO/IEC 20000-2:2007 Tecnología de la información. Gestión del servicio.

Parte 2: Código de buenas prácticas (ISO 20000-2:2005).

Estas normas pueden adquirirse a través del portal web de AENOR. Cualquier entidad puede solicitar la certificación respecto a esas normas.


Referencias


ISO/IEC 20000-1, Information technology
- Service management - Part 1: Specification.

ISO/IEC 20000-2, Information technology
- Service management - Part 2: Code of
practice.

ISO/IEC 27001:2005 Information technology
- Security techniques - Information security management systems - Requirements.

ISO 9001:2000, Quality management
systems - Requirements.


Enlaces externos


Compra de estándares
ISO - International Organization for Standardization.

AENOR -
Asociación Española de Normalización y Certificación.

CASEWISE
- The easy way to become standardized in ISO 20000 and adopt ITIL

BSI - British Standard Institute.

itSMF - Information Technology Service Management Forum.

itSMF España

OGC - Office of Goberment Commerce.

ITIL - IT Infrastructure Library.

CMMI - Capability Maturity Model Integration.

CoBIT - Control Objectives for Information and related Technology.

ISO 20000 Certificación Registro - Organizaciones certificadas.

ITGI - IT Governance Institute.

lunes, 28 de enero de 2008

Information Technology Infrastructure Library

La Information Technology Infrastructure Library (‘Biblioteca de Infraestructura de Tecnologías de Información’), frecuentemente abreviada ITIL, es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. ITIL resume un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir de guía para que abarque toda infraestructura, desarrollo y operaciones de TI.



Tabla de contenidos




Aunque se desarrolló durante los años 1980, ITIL no fue ampliamente adoptada hasta mediados de los años 1990. Si es una certificación. ITIL se considera a menudo junto con otros marcos de trabajo de mejores prácticas como la Information Services Procurement Library (ISPL, ‘Biblioteca de adquisición de servicios de información’), la Application Services Library (ASL, ‘Biblioteca de servicios de aplicativos’), el método de desarrollo de sistemas dinámicos (DSDM, Dynamic Systems Development Method), el Modelo de Capacidad y Madurez (CMM/CMMI) y a menudo se relaciona con la gobernanza de tecnologías de la información mediante COBIT (Control Objectives for Information and related Technology).


El concepto de gestión de servicios de TI, aunque relacionado con ITIL, no es idéntico: ITIL contiene una sección específicamente titulada «Gestión de Servicios de TI» (la combinación de los volúmenes de Servicio de Soporte y Prestación de Servicios, que son un ejemplo específico de un marco ITSM), pero sin embargo es importante señalar que existen otros marcos parecidos. La Gestión de Servicio ITIL está actualmente integrado en el estándar ISO 20000 (anterior BS 15000).


ITIL se construye en torno a una vista basada en proceso-modelo del control y gestión de las operaciones a menudo atribuida a W. Edwards Deming. Las recomendaciones de ITIL fueron desarrolladas en los años 1980 por la Central Computer and Telecommunications Agency (CCTA) del gobierno británico como respuesta a la creciente dependencia de las tecnologías de la información y al reconocimiento de que sin prácticas estándar, los contratos de las agencias estatales y del sector privado creaban independientemente sus propias prácticas de gestión de TI y duplicaban esfuerzos dentro de sus proyectos TIC, lo que resultaba en errores comunes y mayores costes.


ITIL fue publicado como un conjunto de libros, cada uno dedicado a un área específica dentro de la Gestión de TI. Los nombres ITIL e IT Infrastructure Library (‘Biblioteca de infraestructura de TI’) son marcas registradas de la Office of Government Commerce (‘Oficina de comercio gubernamental’, OGC), que es una división del Ministerio de Hacienda del Reino Unido.


En abril de 2001 la CCTA fue integrada en la OGC, desapareciendo como organización separada. [1]


En diciembre de 2005, la OGC emitió un aviso de una actualización a ITIL[2] , conocida comúnmente como ITIL v3, que está planificada para ser publicada a finales de 2006. Se espera que la publicación de ITIL versión 3 incluya cinco libros principales, concretamente: Diseño de Servicios de TI, Introducción de los Servicios de TI, Operación de los Servicios de TI, Mejora de los Servicios de TI y Estrategias de los Servicios de TI, consolidando buena parte de las prácticas actuales de la versión 2 en torno al Ciclo de Vida de los Servicios.


Uno de los principales beneficios propugnado por los defensores de ITIL dentro de la comunidad de TI es que proporciona un vocabulario común, consistente en un glosario de término precisamente definidos y ampliamente aceptados. Un nuevo glosario ampliado ha sido desarrollado como entregable clave de ITIL versión 3.

Certificación

Los particulares pueden conseguir varias certificaciones oficiales ITIL. Los estándares de calificación ITIL son gestionados por la ITIL Certification Management Board (ICMB) que agrupa a la OGC, a itSMF International y a los dos Institutos Examinadores existentes: EXIN (con sede en los Países Bajos) e ISEB (con sede en el Reino Unido).

Existen tres niveles de certificación ITIL para profesionales:


a) Foundation Certificate (Certificado Básico): acredita un conocimiento básico de ITIL en gestión de servicios de tecnologías de la información y la comprensión de la terminología propia de ITIL. Está destinado a aquellas personas que deseen conocer las buenas prácticas especificadas en ITIL.


b) Practitioner's Certificate (Certificado de Responsable): destinado a quienes tienen responsabilidad en el diseño de procesos de administración de departamentos de tecnologías de la información y en la planificación de las actividades asociadas a los procesos.


c) Manager's Certificate (Certificado de Director): garantiza que quien lo posee dispone de profundos conocimientos en todas las materias relacionadas con la administración de departamentos de tecnologías de la información, y lo habilita para dirigir la implantación de soluciones basadas en ITIL.


No es posible certificar una organización o sistema de gestión como «conforme a ITIL», pero una organización que haya implementado las guías de ITIL sobre Gestión de los Servicios de TI puede lograr certificarse bajo la ISO/IEC 20000.


La versión 3 de ITIL, que aparece en junio de 2007, cambia ligeramente el esquema de Certificaciones, existiendo certificaciones puente, se definen 3 niveles:


a)Basic Level (Equivalente a ITIL Foundation en v2)


b)Management and Capability Level (Equivalente a los niveles Practitioner y Manager en ITIL v2)


c)Advanced Level (nuevo en v3)



Historia y precursores de ITIL


Lo que actualmente se conoce como ITIL versión 1, desarrollada bajo el auspicio de la CCTA, se tituló Government Information Technology Infrastructure Method (‘Método de Infraestructura de la Tecnología de Información del Gobierno’, GITM) y durante varios años terminó expandiéndose hasta unos 31 libros dentro de un proyecto inicialmente dirigido por Peter Skinner y John Stewart. Las publicaciones fueron retituladas principalmente como resultado del deseo (por Roy Dibble de la CCTA) de que fueran vistas como una guía y no como un método formal, y como resultado del creciente interés que había fuera del gobierno británico.


Muchos de los conceptos principales de gestión de servicios no surgieron dentro del proyecto inicial de la CCTA para desarrollar ITIL. IBM afirma que sus Yellow Books (A Management System for the Information Business, ‘Un sistema de gestión para el negocio de la información’)[3] [4] fueron precursores claves. Según IBM:



A principios de los años 1980, IBM documentó los conceptos originales de Gestión de Sistemas en una serie de cuatro volúmenes titulada A Management System for Information Systems (sic). Estos ampliamente aceptados yellow books [...] fueron aportaciones claves para el conjunto originales de libros de ITIL.[5] [6]



Otras publicaciones de IBM y comentarios de los autores de ITIL aclaran que los yellow books fueron cruciales para el desarrollo del Servicio de Soporte pero que el volumen de Entrega de Servicios no tomó prestado de ellos hasta tales extremos.



Críticas a ITIL


ITIL ha recibido críticas de varios frentes. Entre ellas:



  • El hecho de que muchos defensores de ITIL parecen creer que es un marco holístico y completo para el gobierno de TI.

  • Su tendencia a convertirla en una religión.


Como señala Jan van Bon (autor y editor de muchas publicaciones de Gestión de Servicios de TI):



Hay mucha confusión sobre ITIL, procedente de todo tipo de malentendidos sobre su naturaleza. ITIL, como afirma la OGC, un conjunto de buenas prácticas. La OGC no afirma que dichas mejoras prácticas describan procesos puros, ni tampoco que ITIL sea un marco diseñado como un modelo coherente. Eso es lo que la mayoría de sus usuarios hacen de ella, probablemente porque tienen una gran necesidad de dicho modelo...[7]



El columnista CIO Magazine Dean Meyer también ha expuesto algunos puntos de vista cautelosos sobre ITIL[8] , incluyendo cinco trampas típicas tales como «convertirse en esclavo de definiciones desactualizadas» y «dejar que ITIL se convierta en religión». Como Meyer señala, ITIL «no describe el abanico completo de procesos necesarios para ser líderes. Se centra en [...] gestionar servicios actuales.»


La calidad de los volúmenes de la biblioteca se considera desigual. Por ejemplo, van Herwaarden y Grift señalan que «la consistencia que caracterizaba los procesos de soporte al servicio [...] se pierde en gran medida en los libros de entrega de servicio.»[9]



Visión general de la biblioteca


La biblioteca de infraestructura de TI (ITIL) toma este nombre por tener su origen en un conjunto de libros, cada uno dedicado a una práctica específica dentro de la gestión de TI. Tras la publicación inicial de estos libros, su número creció rápidamente (dentro la versión 1) hasta unos 30 libros. Para hacer a ITIL más accesible (y menos costosa) a aquellos que deseen explorarla, uno de los objetivos del proyecto de actualización ITIL versión 2 fue agrupar los libros según unos conjuntos lógicos destinados a tratar los procesos de administración que cada uno cubre. De esta forma, diversos aspectos de los sistemas de TIC, de las aplicaciones y del servicio se presentan en conjuntos temáticos. Actualmente existe la nueva versión ITIL v3 que fue publicada en mayo de 2007.


Aunque el tema de Gestión de Servicios (Soporte al Servicio y Entrega de Servicios) es el más ampliamente difundido e implementado, el conjunto de mejores prácticas ITIL provee un conjunto completo de prácticas que abarca no sólo los procesos y requerimientos técnicos y operacionales, sino que se relaciona con la gestión estratégica, la gestión de operaciones y la gestión financiera de una organización moderna.


Los ocho libros de ITIL y sus temas son:



Gestión de Servicios de TI

1. Provisión de Servicios

2. Soporte al Servicio



Otras guías operativas

3. Gestión de la infraestructura de TI

4. Gestión de la seguridad

5. Perspectiva de negocio

6. Gestión de aplicaciones

7. Gestión de activos de software




Para asistir en la implementación de prácticas ITIL, se publicó un libro adicional con guías de implementación (principalmente de la Gestión de Servicios):





8. Planeando implementar la Gestión de Servicios




Adicional a los ocho libros originales, más recientemente se añadió una guía con recomendaciones para departamentos de TIC más pequeños:





9. Implementación de ITIL a pequeña escala




Notas



  1. Office of Government Commerce (Reino Unido). CCTA y OGC. Recuperado el 5 de mayo de 2005.

  2. Office of Government Commerce. ITIL Refresh Statement. Recuperada el 13 de febrero de 2006.

  3. IBM (1980), A Management System for the Information Business, White Plains, Nueva York: IBM.

  4. Van Schaik, E. A. (1985). A Management system for the Information Business. Englewood Cliffs, NJ, Prentice-Hall, Inc. ISBN 0-13-549965-8

  5. IBM Global Services (2003). IBM and the IT Infrastructure Library (PDF). Consultado el 2006-05-31.

  6. IBM Global Services (2003). IBM's commitment to ITIL (HTML). Consultado el 2006-06-08.

  7. (2002), van Bon, J., The guide to IT service management, Addison Wesley. ISBN 0-201-73792-2.

  8. Meyer, Dean, 2005. «Beneath the Buzz: ITIL», CIO Magazine, 31 de marzo de 2005

  9. Van Herwaarden, H. y F. Grift (2002). "IPW(tm) and the IPW Stadia Model(tm) (IPWSM)". The guide to IT service management. J. Van Bon. Londres, Addison-Wesley: 97-115.


Enlaces externos



Esta mayor adopción y conocimiento ha llevado a varios estándares, incluyendo ISO/IEC 20000, que es una norma internacional cubriendo los elementos de gestión de servicios de TI de ITIL