Bienvenido/a a ITILv3.ES

  

  El punto de encuentro para la difusión

  de las Mejores Prácticas para la

  Gestión de Servicios de TI

Es Noticia

Magic Quadrant for IT Service Support Management Tools

Gartner ha publicado recientemente, en su célebre formato de Cuadrante Mágico, su  clasificación de los diferentes players del mundo de las herramientas ITSM.
 
Según sus criterios de visión de la compañía y capacidad de ejecución, y enfocado en concreto hacía las herramientas de gestión de los procesos de Soporte al Servicio, el estudio destaca en primer lugar el liderazgo de BMC con su suite BMC Remedy ITSM seguida de cerca por ServiceNow, fabricantes de la solución del mismo nombre que ha contado con el  mayor crecimiento relativo en cuota de mercado  en los últimos años.
 
El resto de herramientas evaluadas son Assyst de Axios, CA Service Desk Manager, Cherwell Service Management, FrontRange ITSM Enterprise Edition, Easyvista, Supportworks ITSM Enterprise de Hornbill, HP Service Manager, IBM SmartCloud Control Desk y LANDesk Service Desk.
 
Podéis revisar este interesante report directamente en la web de Gartner:
 

ITIL-as-a-service guay del paraguay

Pues sí, habéis leído bien.

Un paso más en el mundo de la inescrutable imaginación marketiniana. El ITIL-as-a-service, enfoque acuñado por la empresa de software ITSM Sunview que para ello, ha introducido el software ChangeGear 5.0 con “workflows” ITIL pre-establecidos para disfrutar desde la nube.

Así que ya veis, hemos cerrado el círculo, ya tenemos a ITIL como servicio. Endogamia tecnológica. El marco de trabajo para la gestión de servicios TI convertido es un servicio.
Ups!, pero un servicio debería ser gestionado. No hay problema. En próximas entradas os presentaré una propuesta de ITITIL®, el marco de trabajo para la gestión del servicio que gestiona los servicios IT.

Para aquellos que estéis interesados, encontraréis más información en su web corporativa:

http://sunviewsoftware.com/solutions/itil.aspx

ITIL® para Androides

Hola de nuevo, apreciados lectores de ITILv3.ES.
Los tiempos cambian, y las formas de acceder a la información, y sus formas de gestión, cambian con los tiempos. Y me diréis que acabo de descubrir la sopa de ajo, pero no pasará demasiado tiempo antes de ver las primeras aplicaciones profesionales de movilidad para el soporte a la gestión de ciertos procesos ITIL®.
Seguramente también viviremos la incursión del concepto de Service Desk móvil, como estructura evolutiva de  un Virtual Service Desk, donde más allá de tener el personal distribuido por el globo, sus agentes trabajarán desde terminales móviles desde cualquier lugar del mundo.

Pero hasta que llega todo ello, de momento nos conformaremos con dar un paseo por los principales desarrollos disponibles para Android en el mundo ITIL®, la mayoría de los cuales están destinados a la consulta de material, formación y preparación para las distintas certificaciones.

Y qué destacaría. Pues de momento no demasiado. Podéis llevar siempre con vosotros el Glosario y Acrónimos de rigor:

https://play.google.com/store/apps/details?id=com.itilglossary&feature=more_from_developer#?t=W251bGwsMSwxLDEwMiwiY29tLml0aWxnbG9zc2FyeSJd

O ir practicando preguntas de examen de Foundation en el "travel time":

https://play.google.com/store/apps/details?id=com.examprepitilfoundation&feature=search_result

Eso sí, si vais en tren o tenéis chófer. Si conducís, mirad siempre al frente.

ITIL® en una sola página

Ya tenemos una nueva versión del documento ITIL® on a page, que gentilmente comparten con la comunidad nuestros amigos de itiltrainingzone.
Aunque con menor destreza de la habitual en ellos (a mí personalmente me gustaron más versiones anteriores por ser más completas), se enumeran para cada una de las fases del Ciclo de Vida de los Servicios, los objetivos, conceptos clave, procesos, modelos y los documentos u outputs asociados, obviamente todo ello actualizado ya según los cambios de la 2011.

Podéis descargarlo desde el siguiente enlace:

http://www.itiltrainingzone.com/images/stories/pdfs/ITILonapage.pdf

ITIL® Foundation Handbook edición 2011

En este inicio de mes, tengo el placer de anunciaros, la publicación por parte de TSO y con autoría itSMF UK del ITIL Foundation Handbook (edición 2011) ISBN 9780113313495, en la cual he tenido la oportunidad de participar como revisor de la misma para itSMF UK. 
La publicación, actualizada en consonancia con la versión ITIL 2011 y aprobada por APM Group, el acreditador ITIL, es una guía de referencia rápida diseñada para ayudar a los estudiantes a prepararse para la correspondiente certificación ITIL Foundation. También pretende ser una fuente de consulta para los profesionales del sector.

Contiene un capítulo sobre cada una de las fases del ciclo de vida de los servicios: estrategia, diseño, transición, operación y mejora continua.

La publicación pretende alcanzar el éxito obtenido por la edición anterior que vendió más de 123.000 copias en todo el mundo.

Colin Rudd, Presidente de itSMF UK y uno de los co-autores de la revisión, ha señalado: "Estoy encantado de que el Comité de Publicaciones de itSMF UK haya sido una componente clave de este importante proyecto para alinear la publicación con ITIL 2011. El ITIL Foundation Handbook es un compañero indispensable para la certificación ITIL Foundation y es especialmente popular entre los organismos de formación con los que trato regularmente".

Mind Maps ITIL 2011

Nuestros amigos de ITIL Training Zone acaban de publicar un resumen en formato “mind map” de la actualización de ITIL 2011.
Echadle un vistazo. Vale la pena. Son muy útiles como material de consulta o referencia.
Los podéis descargar en formato pdf a través del siguiente enlace:

ITIL v4, ¿que viene después?


Interesante webcast el que nos proponen para mañana Miércoles 20 de Julio desde uno de los grupos de ITSM de linkedin con 3 ponentes de excepción, Vernon Lloyd de FoxIT y autor de referencia en el mundo ITIL, Stephen Mann analista de Forrester y Lisa Perri, Senior Manager de VMware.

En él se tratarán los aspectos fundamentales del refreshment de la v3 que recientemente ha visto la luz, así como elementos adicionales s a tener en cuenta en futuras implementaciones ITSM.

Podéis conectaros en directo mañana a las 14:00 h, hora peninsular en España, y está organizado por BrightTALK™:

“ITIL v4? What’s Next?”
Live 20th July 1pm BST, or afterwards on demand
Attend here: http://www.brighttalk.com/r/msz 

El Último Proceso de ITIL®: Gestión de Situaciones Críticas

Aunque en la versión 3 de ITIL® se citan los aspectos fundamentales del proceso de Gestión de Situaciones Críticas o Gestión de Crisis, por la particularidad, importancia, y por desgracia, frecuencia que muchas organizaciones deben operar en este modo, quizás merezca por sí mismo cierto protagonismo, un proceso separado, un apéndice, o por lo menos, este humilde artículo de ITILismo de investigación.

Damas y caballeros, con tod@s ustedes, el último proceso de ITIL®, Gestión de Situaciones Críticas.

Para documentar mínimamente nuestro proyecto de proceso ITIL®, vamos a hacer el ejercicio de encuadrarlo dentro de una de las fases del Ciclo de Vida de los Servicios para después definir el Goal, Scope, Activities, Inputs, Outputs y Roles asociados.

Pero antes, y para que el proceso esté alineado con nuestro marco de trabajo, vamos a hacer un repaso rápido a las referencias que se hacen a la Gestión de Situaciones Críticas en las cinco publicaciones de la versión 3 de ITIL®.

Así que, manos a la obra.

Paso 1: ¿Qué dice ITIL® sobre la Gestión de Situaciones Críticas?

En el libro de Estrategia del Servicio, empieza haciendo una reflexión interesante cuando habla de la gestión por objetivos. Estrategias, objetivos alineados y una gestión consistente hacia la consecución de los mismos, es la base de toda organización orientada a la gestión por objetivos. En este escenario, introduce un concepto a evitar, la gestión por crisis como la creencia de que una buena medida de la eficiencia de una organización es su habilidad para resolver problemas. Es el enfoque de dejar que sucedan las cosas para después gestionarlas reactivamente.

Es en Diseño del Servicio donde la versión 3 de ITIL® encaja, de manera muy frugal, el proceso de Gestión de Crisis, como subproceso de ITSCM. Lo define del siguiente modo:

Gestión de Crisis (IT Service Continuity Management): La Gestión de Crisis es el proceso responsable de la gestión de todas las implicaciones relacionadas con la Continuidad del Negocio. El equipo de Gestión de Crisis es responsable de cuestiones estratégicas tales como la gestión de relaciones con los medios de comunicación y la confianza de los accionistas, y decide cuando invocar los Planes de Continuidad de Negocio.

Como podéis observar, lo circunscribe únicamente a la gestión de las cuestiones estratégicas que aparecen alrededor de una crisis cuando se produce, con foco en temas de comunicación hacia el mundo exterior. 
En tercer lugar, en uno de los apéndices de Operación del Servicio, se dan ciertas pinceladas de lo que en la publicación llaman “Comunicaciones Relacionadas con las Emergencias”. De hecho, el primer parágrafo nos apoya en el noble objetivo de crear nuestro proceso exclusivo para la Gestión de Situaciones Críticas. Dice algo así:

Aunque ITIL® especifica cómo lidiar con situaciones urgentes y de alto impacto tales como desastres (Continuidad del Servicio) e incidencias graves (Gestión de Incidencias), los responsables de Operación del Servicio van a tener que tratar con diversos tipos de emergencias no cubiertas por estos procesos. Es importante destacar que no estamos ante un proceso separado, sino ante varios procesos y situaciones desde una perspectiva de comunicación.

El volumen Transición del Servicio y bajo el esmerado título “Cuando la velocidad es más importante que la precisión” describe:

Comprender las particularidades de una crisis, puede ser muy útil, sobre todo para entender, que las normas para la Gestión de Crisis son diferentes a las que rigen la Operación del Servicio en su día a día.

Sólo siendo conscientes de las dos primeras leyes de la Gestión de Crisis podemos ayudar a tranquilizar a los implicados que la situación es superable:

·         Regla 1: No entre en pánico

·         Regla 2: Un buen Gestor de Crisis toma decisiones al instante y actúa sobre ella (sobre la crisis). Si más tarde resulta que las decisiones han sido correctas tanto mejor, pero en una situación de crisis, la velocidad es a menudo más importante que la eficiencia

Paso 2: ¿Dónde lo ubicaríamos?

Ciertamente no es más que un “modo” de Gestión de Incidencias, que debería poder invocar (si es necesario) el Plan de Continuidad (si existe) para las partes de infraestructura afectadas. Tiene mucho de Gestión de Riesgos, tiene mucho de Comunicación y podría asimilarse a un proceso de Gestión de Excepciones de alta prioridad.

Teniendo en cuenta todo esto, nos decantaríamos por encajarlo en el framework de Operación del Servicio.

Paso 3: El Proceso

Bueno, y para finalizar, vamos a aproximarnos a lo que podría ser perfectamente un nuevo proceso ITIL® en su versión 4, a través de subrayar las ideas clave relativas al Objetivo, Alcance, Actividades, Inputs, Outputs y Roles del proceso de Gestión de Situaciones Críticas.

Objetivo

Aún pecando de simplistas, como objetivo del proceso, sugeriría una adaptación del Goal de Incident Management.

“The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained”

El propósito final es análogo, aún siendo el alcance, las actividades, y obviamente la prioridad de las situaciones, distinto/as.
Nótese también que ni todas las crisis son o provienen de incidencias, ni obviamente todas las incidencias son o se convierten en crisis.

Alcance

En la definición de cualquier nuevo proceso que se precie, uno de los primeros asuntos que debemos resolver es definir el ámbito del mismo. Es muy importante que cada organización defina lo que es, para ella, una crisis, su crisis.
El que una situación se considere o no una crisis, será el disparador del proceso, con lo que la definición de crisis en nuestra compañía se convierte en un factor clave. Consecuentemente, mientras que la receta para la definición de crisis no es uniforme en todas las organizaciones, los ingredientes que intervienen son sustancialmente los mismos: riesgo, impacto, probabilidad, daños, pérdidas,…

Para ayudar en este cometido, pongamos sobre la mesa una definición generalista de crisis:

El punto de tiempo cuando se trata de decidir si cualquier asunto o curso de acción debe continuar, modificarse o darse por terminado; el momento decisivo, el punto de inflexión.

Según la R.A.E:

Situación de un asunto o proceso cuando está en duda la continuación, modificación o cese. Momento decisivo de un negocio grave y de consecuencias importantes. Situación dificultosa o complicada.

¿Cómo podemos traducir el concepto de crisis en un entorno TI?

Por ejemplo, y entre otros:

- Incumplimiento de contrato
- Interrupción o degradación significativa y no planificada de servicios con alto impacto en el negocio
- Cualquier cuestión con impacto significativo a negocio
- Aumento de la probabilidad de ocurrencia de un riesgo controlado, etc.

Hagamos el mismo ejercicio con la definición de riesgo:

Académicamente:

La posibilidad de sufrir daño o pérdida; peligro. Un factor, cosa, elemento o campo con peligro incierto, un peligro.

En nuestro medio ambiente, por ejemplo, y entre otros:

- La probabilidad de dañar el negocio en forma de pérdidas económicas
- La probabilidad de dañar la imagen de la compañía o de sus clientes en cualquier aspecto relacionado con el negocio
- La probabilidad de incumplimiento de cualquier acuerdo contractual, etc

Actividades

Las siguientes pudieran ser candidatas a actividades de nuestro nuevo proceso ITIL®:

Identificación de la crisis
…pero ¿esto es una crisis?
Definición de la situación
…o a veces lo más importante de una crisis es saber exactamente qué es lo que está pasando
Respuesta a la crisis
…o plan de acción
Liderazgo de la crisis
…o selección de un individuo y el equipo para hacer frente a la crisis
…y creación y tracking del Comité de Crisis
Organización de los recursos
…pero eso ya lo hacíamos ¿no?...
Administrar el flujo de información
…o comunicar, comunicar, comunicar…

Inputs

…algunos

Crisis
Plan de Continuidad
Plan de Riesgos

Outputs

…algunos

Plan de Acción
Plan de Comunicación
Informes de gestión y resolución de la crisis
  
Roles

…los básicos

Propietario del Proceso
Responsable de la Crisis
Comité de Crisis

¿Y qué esperar de todo esto?

Que las organizaciones tomen conciencia de la importancia de procesar la Gestión de Crisis, para que el retorno a la normalidad sea lo más rápido y eficiente posible.
Y es que hay dos cosas que no podemos dejar en manos del azar, nuestro destino, y la Gestión de una buena Crisis.

20 cosas acerca de ITIL

Der "ITIL Foundation"-PinImage by icanmakeit.de via Flickr Autor: Jose Antonio Trujillo, CIO Perú
Fuente: CIO Perú
Agradecemos a Franca Cavassa, Directora de CIO Perú la autorización para la publicación del presente artículo.




Embarcarse en un proyecto ITIL (Information Technology Infraestructure Library) es cosa seria. Es modificar costumbres (malas y buenas), instaurar procesos y, en general, hacer más sistemática la forma en que se desarrollan las cosas al interior de una organización.

 
No es sencillo. Las personas generalmente se resisten al cambio, es decir, a dejar de hacer las cosas tal y como las venían haciendo por mucho tiempo, y quizás con buenos resultados. ¿Por qué cambiar entonces? La respuesta es simple: porque las cosas se pueden hacer mejor. Y de esta convicción depende el éxito de los proyectos de ITIL. Depende -en gran medida- de las personas, de que los trabajadores operativos vean las bondades del cambio, pero que también sea evidente para la alta gerencia e incluso para el directorio.
 
Es por ello que las reuniones de ITIL se están multiplicando. Aprender de la experiencia de otros y de la de los expertos en la implementación de estos proyectos es vital si se desea llegar a buen puerto. Pink Elephant, la organización que por años se ha dedicado a difundir estas mejores prácticas, tuvo recientemente una reunión en Lima en la que se decidió a “romper los grandes mitos de ITIL” con la participación de un conjunto de expositores que mostraron sus experiencias en diversos campos.
 
De ellos rescatamos las presentaciones de dos viejos conocidos: José Manuel Flores, director general de Pink Elephant México, y George Spalding, vicepresidente de Pink Elephant. Cada uno de ellos expuso sobre 10 cosas importantes a considerar dentro del campo de ITIL, y lo que a continuación les presentamos es una breve reseña de sus discursos.
 
10 equivocaciones

Flores fue directamente al punto. De acuerdo a su experiencia como consultor se pueden establecer diez equivocaciones que las organizaciones generalmente comenten durante el primer año de la implementación de un proyecto ITIL. Quizás no sean todas, pero son las más representativas de acuerdo al representante mexicano.

La primera de ellas es no tener una visión de hacia donde queremos dirigirnos con un proyecto ITIL. Este primer error es fundamental y básico pues lo primero con lo que uno puede chocar es con la sensación generalizada de que “si todos estamos de acuerdo en como se hacen las cosas, ¿para qué cambiarlo?”. Flores señala que debe haber una visión clara de para qué se desea el proyecto; y si ésta no se tiene, hay que replanteársela.
 
El segundo error más común es pensar que no es necesario el apoyo de la alta dirección. No es suficiente con los mandos medios, “Nos hemos encontrado con empresas donde los proyectos nacen por una iniciativa de la gerencia media y deciden no involucrar a la alta dirección porque consideran que no van a tener tiempo para ella. Cuando no se tiene un patrocinador ejecutivo, el dinero y el tiempo de la gente no están asegurados y el proyecto se encuentra en peligro”, señala el ejecutivo.
 
Flores agrega que se requiere de la figura de un champion del proyecto en el directorio de la organización; es decir, de la persona que va a ser una especie de representante ante los directores cada vez que se soliciten recursos para el proyecto. Hay que tomar en cuenta que un directorio probablemente no entiende el tema, y que la forma de vender el proyecto es decirle a este órgano que se va a habilitar un proceso de negocio o la disponibilidad de un proceso de negocio.
 
El tercer error es considerar que no se necesita un caso de negocio. La realidad es que no se llega a ningún lado con una propuesta de ITIL, que no logre articular con claridad los beneficios para el negocio en la implementación del proceso. Por tanto, es necesario hacer un business case, crear una base de referencia (base line) y métricas para respaldar las evidencias de éxito.
 
La cuarta equivocación es considerar que no se va a necesitar una base de referencia (base line) al inicio y que es mejor dejarla para después de la implementación, para mostrar a la gerencia la madurez alcanzada por el proyecto.
 
Lo malo de cometer este error es que no se puede demostrar que se ha mejorado sino se sabe de dónde se partió. Además es bueno saber que le ‘duele’ al cliente para saber qué ‘medicina’ se le debe aplicar. Flores señaló -adicionalmente- que es necesario definir quick wins, es decir, ganancias rápidas. “Un proyecto de procesos que no presenta ganancias rápidas es un proyecto perdido, porque a los ojos de la alta dirección se lo va a ver como algo innecesario”, sostuvo Flores.
 
La quinta equivocación es considerar que este no es proyecto estratégico. Al hacerlo se implementa como si fuera una actividad más, y eso incita a que no se formalice el proyecto ni se estime los recursos necesarios. Esto, a la larga, trae como consecuencia que los recursos se estresen al límite de su capacidad de trabajo. “No se trata de quién esté disponible, sino que se necesita gente con habilidades y motivación para hacer que el proyecto sea un éxito”, asegura.
 
La equivocación seis consiste en pensar que no se requiere de una estrategia de comunicación. Flores enfatizó que un elemento fundamental para el éxito es desarrollar una estrategia y un plan de comunicaciones. Y para ello se deben utilizar todos los elementos que se tengan a mano (mouse pads, salvapantallas, tazas, videos, sitio web corporativo, etc.). Además es bueno y recomendable involucrar a las áreas de recursos humanos y márketing en este esfuerzo.
 
La sétima equivocación es considerar que no se necesita de una estrategia general. Al contrario, se requiere de una estrategia general que defina elementos comunes a todas las instancias involucradas en el cambio. Es bueno contar aquí con una estructura de documentación para el proceso que abarque hasta cuatro niveles: política; procesos, roles y medidas; instrucciones de trabajo; y formularios, registros y documentos.
 
El octavo error es pensar que la implementación no va a durar mucho tiempo. “Hemos visto organizaciones donde los proveedores les han dicho que iban a implementar todo en uno o dos meses. Hay otros que les venden el software con plantillas y señalan que pueden implementar todo en 20 días. La realidad es que esto no funciona así”, sostiene Flores.
 
Primero se debe definir un proceso acorde con lo que va a traer beneficios para la organización y con la estrategia que se definió, y luego se puede escoger la herramienta. Como señala Flores, todo lo que dicen los libros no necesariamente se aplica en la organización. Este es otro error garrafal de los consultores.
 
El penúltimo error que se comente es no considerar los alcances del proyecto. Se tiene que administrar el proyecto y las expectativas que éste genera. Y aquí es necesario tener cuidado al pensar que en el alcance todo está interrelacionado, y que por tanto no se puede cambiar nada.
 
Finalmente, la última equivocación es no esperar una resistencia importante al proyecto. No hay que subestimar los factores relacionados con el personal, sobre todo si se toma en cuenta que las personas racionalizan el cambio primero a nivel emocional y después a nivel lógico. De hecho, hay que esperar la resistencia al cambio y utilizar una metodología de administración del cambio.
 
Lo que quieren escuchar

George Spalding fue el siguiente expositor del evento. Para no quedarse atrás Spalding también confeccionó una lista de 10 cosas que se deben de tomar en cuenta en los proyectos de ITIL. En esta ocasión lo que ofreció fueron las “10 cosas que al CEO o CFO les gustaría escuchar”, una serie de frases que esconden algunas enseñanzas sobre el trabajo de TI en las organizaciones.
 
La primera frase es “tengo una visión estratégica sobre la forma en que TI se integra exitosamente con el negocio”. Spalding, con su característico buen humor, señaló que generalmente en las reuniones se cuenta con una sesión a la que se denomina la “Sesión de Alineamiento de TI con los negocios”, lo cual indica que TI ha crecido separada de los negocios. Pero en la actualidad todas las empresas tienen procesos de negocios que involucran tecnología, de hecho, se encuentran en su core.
 
“Pero la pregunta es ¿nos vemos en el core de los negocios? ¿El negocio nos ve en el core?”, se preguntó Spalding. Algunas veces. Y quizás eso significa que ambos tienen visiones diferentes del mundo, y por eso es que se necesita estos ‘alineamientos’. En realidad, lo que se necesita es que TI se encuentre integrada dentro del negocio, y esto no es opcional. Lo extraño es que esto es algo que solo se pide a TI. ¿Alguna vez se ha escuchado del alineamiento del departamento de finanzas? ¿Márketing? Todos ellos se ven como parte del negocio, pero TI se ve a sí misma, debido a la forma en que se desarrolló, como algo externo al negocio.
 
La segunda frase de Spalding es: “He desarrollado un framework de medición así que podemos ver como le está yendo a TI”. Uno en realidad debería medir todo lo que pueda, ya que son las mediciones las que proporcionan una línea base para poder realizar las modificaciones necesarias.
 
Lo primero que uno puede hacer es imaginar qué puede medir, y en un segundo paso determinar qué puede medir en realidad; ya que algunas de las cosas que se quieren medir, en realidad no se van a poder hacerlo. Por ejemplo, el uptime de un servicio como el correo electrónico. Uno puede medir los componentes pero si un usuario no tiene acceso al correo, para él el uptime es cero -a pesar de las cifras que uno pueda tener. La escena cambia si ese usuario es el CEO, por su puesto. Entonces uno no mide todo, sino solo aquello que es significativo, y por significativo podemos entender aquello que nos pueda producir algún cambio.
 
La tercera frase del expositor fue: “No se preocupen, tengo todo bajo control”. ¿Sabe qué componentes tiene en su infraestructura? Si puede responder que sí entonces responda lo siguiente: ¿sabe dónde se encuentran todos esos componentes? ¿Sabe con qué otros componentes se conectan? ¿Qué relación tienen con los procesos o los servicios? Seguramente que no. Pero Spalding advierte: su jefe sí le va a creer que tiene todo bajo control.
 
En realidad uno no tiene nada bajo control, sino solo un poco de personas que lo pueden ayudar.
 
La cuarta frase: “El próximo año TI costará menos? liberando dinero para proyectos de valor añadido”. Cuando se habla de dinero en TI, se puede apreciar que antes el hardware solía ser la parte cara de TI, pero ya no lo es. El hardware es cada vez mas barato. Mientras la mano de obra y de soporte ha subido exorbitantemente. Y se inventaron los blades y la virtualización, todo enfocado en el hardware, y luego se inventó la nube que es muy barata. Y sin embargo, la parte del presupuesto que se destina a ‘mantener prendidas las luces’ significa un 70% del total.
 
Esta parte del presupuesto se destina entonces a algo que se ha convertido en ‘invisible’, nadie sabe donde se encuentra. Y son más bien las funcionalidades, las partes más visibles para el resto de la organización, las que se llevan un porcentaje más pequeño del presupuesto.
 
“Creo que TI es el cliente del outsourcing no su competidor”, señaló Spalding, refiriéndose que ante las posibilidades de hacer outsourcing para resolver las necesidades de la compañía, el departamento de TI debe comportarse como la parte de la firma que se va a encargar del outsourcing y no a sufrir por él. TI, desde esta perspectiva, debe ser el único proveedor de servicios para la organización.
 
A la mitad de su presentación Spalding lanzó su quinta frase: “nuestros costos están bajando. Nuestro uptime” está subiendo. Esto significa mayor productividad de nuestro personal actual.
 
¿Cuándo ocurren los incidentes? Generalmente los lunes. ¿Cuándo se realizan los cambios a los sistemas? Los fines de semana. ¿Se ve la relación? Entonces es momento de arreglar la administración que se realiza de los cambios. “Hacemos mal las cosas”, sentenció Spalding. La solución es tener el control absoluto de todos los cambios en el ambiente de producción.
 
La sexta frase es de antología: “Los proyectos de TI se están llevando a cabo dentro de los plazos, dentro del presupuesto y superando las especificaciones de calidad”.
 
“Si creen en esto les digo que tengo un puente en Nueva York que me gustaría venderles”, bromeó Spalding. Lamentablemente, las estadísticas sobre el éxito de los proyectos, siguen siendo las mismas que hace diez años: el 33% tienen éxito, el 67% fallan. Y por falla se debe entender que cuestan más de lo que suponía que debían costar, o se requirió de mayores plazos a los supuestos, o no hace lo que se suponía que debía hacer desde un inicio, o una combinación de estos tres casos.
 
Ese es un record muy pobre para los proyectos de TI, y no ha mejorado en diez años. A pesar de todas las metodologías de administración de procesos y certificaciones no se hace bien, y ciertamente no siempre es culpa de la gente de TI, pero la verdad es que los proyectos no se hacen bien. “Y no estoy seguro de la razón”, sostuvo Spalding. Pero una buena pista es que si se culpa a otra persona por el error, también se debe recordar que cuando esa persona realizaba la acción que iba a estropear el proyecto, todos los demás se quedaron callados. Y el proyecto falla.
 
La siguiente frase tiene que ver con una falsa sensación de mejora: “Los llamados por incidentes a la Mesa de Servicio han bajado, pero las solicitudes de servicio han subido. Esto significa que como las cosas se descomponen menos los usuarios están encontrando nuevas formas de usar sus sistemas”.
 
La extensa frase tiene más de una explicación. Una es que los llamados a la Mesa de Servicios han bajado porque el servicio es tan malo que todos han dejado de llamar. El otro tiene que ver con una de las medidas más utilizadas en la evaluación de una mesa de ayuda: la resolución del problema a la primera llamada. Tener una alta tasa de resolución de incidentes en la primera llamada se logra gracias a que hay una alta tasa de incidentes repetidos. La mesa de ayuda repara el mismo incidente una y otra vez, y cuando se hace eso se logra una alta tasa de resoluciones a la primera llamada. Pero si se le pregunta a la Mesa de Ayuda de dónde provienen los incidentes lo más probable es que no tengan la menor idea.
 
La solución es llegar a la raíz del problema y eliminarla. Esto no solo reduce el número de incidentes sino también el número de incidentes repetidos, lo que ocasiona que la mesa de ayuda enfrente incidentes nuevos. El tiempo de resolución de los incidentes sube y la resolución a la primera llamada cae. Así que uno repara la raíz de los incidentes, pero puede ser penalizado porque su tasa de incidentes resueltos a la primera llamada se desploma.
 
“Las únicas personas felices con todo esto son los clientes”, bromeó nuevamente Spalding.
 
La siguiente frase fue sacada de un caso real: “Detengamos todo y volvamos a hacer los procesos para poder pasar la auditoría”.
 
Spalding fue a una compañía y pidió que le mostraran el proceso de cambios. “¿Cuál?”, le preguntaron. “¿Cuántos tienen?” “Solo dos. El verdadero, y el que creamos para los malditos auditores” “¿Son el mismo?” “No, no hubiéramos podido pasar la auditoría con el verdadero”
 
“Es una historia real. Pero la moraleja es que los auditores no deben de ser llamados al final del diseño de un proceso sino desde el inicio para que ellos puedan garantizar que es auditable, medible y que podrán revisarlo también luego”, sostuvo el expositor.
 
La penúltima frase: “Nuestra gente de seguridad ha dejado de hacer las cosas por su cuenta y ahora están usando un estándar de seguridad TI de nivel mundial”.
 
Las personas de seguridad siempre buscan un framework que les de una ruta para responder a la eterna pregunta: ¿Cuán seguros quieren ser? Uno puede estar completamente seguro, pero lo mejor es utilizar los entornos de seguridad que ofrecen los estándares como los ISO.
 
La frase final fue: “Estamos realizando más cambios que nunca, pero con menos impacto negativo”.
 
Esto permite que TI sea más responsable con las solicitudes del negocio. Algunos consideran que TI debe escuchar al negocio y luego hacer lo que le piden porque el cliente siempre tiene la razón. “Pero eso no es cierto”, sostuvo. Los usuarios esperan que se les brinden los servicios que piden, pero que todo lo demás siga funcionando bien. Ellos no van a pedir algo que ponga en peligro la infraestructura porque no saben lo que están pidiendo. TI les debe decir a los usuarios que esa pequeña cosita que piden puede poner en problemas a toda la infraestructura.

Enhanced by Zemanta

Creative Commons License
ITILv3.ES is licensed under a Creative Commons Reconocimiento 3.0 España License.
Based on a work at www.itilv3.es.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce and is Registered in the U.S. Patent and Trademark Office.