Remedy-force.com: ¿Puede ITIL ser online?

Siempre he pensado que hay muchas similitudes entre el CRM y un Service Desk si miras a los usuarios como “clientes”, de modo que el paso de seguir a Salesforce.com con una herramienta de Service Desk era previsible.

Que se haga con una alianza entre BMC y Salesforce es sin duda una noticia positiva para la idea. Son dos claros líderes y Salesforce tiene el conocimiento de poner herramientas online. Eso les debería salvar al menos los problemas derivados de saber dar un servicio así.

Como “herramienta” su éxito dependerá del precio, porque no dudo del servicio será razonablemente bueno, pero mientras Salesforce compite en un entorno con productos de costes elevados de compra e implantación y es una herramienta donde una aplicación online tiene muchas ventajas (fuerzas de venta que se conectan desde fuera de la oficina) no veo tan claro que esas mismas ventajas sean relevantes en una aplicación de Service Desk. BMC además ya vendía buenos productos “entry-level” a un coste muy competitivo.

Por otra parte, si pensamos en un enfoque ITIL un service desk aislado no tiene sentido, ¿dónde está mi CMDB? ¿como controlo mi configuración o el estado de los servicios?. Si el paso únicamente pretende alojar parte del sistema en remoto (un hosting) y un cobro por uso tendrá clientes a los que les sea interesante pero no será algo revolucionario. Desde luego no creo que un enfoque ITIL facilite que una parte de las herramientas sea en modo “online” externo y parte en local, la integración es un aspecto fundamental, y no creo que se pueda usar en modo externo una consola de gestión del servicio o una CMDB. Es más fácil externalizar las infraestructuras de informática completas a alguien como IBM, Indra, T-Systems o Accenture y que ellos controlen la gestión con sus propias herramientas.

No tengo claro el camino de esta nueva propuesta, sobre todo si la propia BMC compite consigo misma (como es habitual en estos casos) y acaba propiciando que su propio canal de ventas luche contra esta propuesta.

Puede que se quede en una iniciativa al calor de las modas de “cloud computing”.

Hay que redefinir la gestión de IT

 

Apple iPad

 

Como se indica en este artículo es preciso redefinir gran parte de la gestión de IT en relación con los dispositivos.

Gran parte de los modelos de ITIL han sido definidos hace mucho tiempo, y es cierto que las actuales herramientas están pensadas mucho más para entornos “desktop” con sistemas operativos y aplicaciones instaladas mucho más que orientadas a servicios “cloud” . Tomo un fragmento del artículo:

there were no PCs or cell phones when the service desk model was written. In early 80’s there were only terminals, today we have smart phones, iPads

La problemática de gran parte de los modelos actuales es que no tienen modo de incluir fácilmente dispositivos portátiles o simplemente las actuales unidades de almacenamiento USB de gran capacidad.

¿Cómo se controla que se almacena o donde se usan “llaves USB”? Los sistemas de control de estos componentes son complejos, mal integrados y poco útiles. Prohibirlos hoy es inviable, si añadimos los dispositivos portátiles de conexión 3g (digamos “modem USB”) el control de que redes se conectan es inviable.

El comportamiento habitual en las empresas es olvidarse de este tipo de sistemas, dar un soporte reducido o considerarlos equipos secundarios, pero pronto serán equipos fundamentales. ¿Necesitan los ejecutivos un portátil o un PC? La realidad es que un iPad puede serles mucho más útil con aplicaciones basadas en web y conexión 3G segura.

Evidentemente no es un tema “prioritario” hoy, dado que existen problemas mucho más urgentes, pero para los proveedores de tecnología (IBM, BMC, HP) es una urgencia aún no resuelta, cuando las compañías comiencen a demandar herramientas deberán tener algo que proponer y que sea estable y potente.

Visto de otro modo, los que se lancen a desarrollar herramientas que solucionen esta problemática tienen una gran oportunidad de negocio, o de vender esa tecnología a uno de los grandes cuando estos (que acostumbran a dormirse en los laureles y comprar) se den cuanta de que ya hay una alta demanda.

Itil y Cloud Computing

 

itil v3 cms

 

Una reflexión muy interesante sobre el impacto de las tecnologías “cloud” en la gestión de IT bajo ITIL (ITSM).

Estoy de acuerdo en el foco del artículo, el uso de Cloud Computing modifica algunos temas de gestión y cambia la relevancia entre ellos (en el día a día) como por ejemplo la gestión de la capacidad (¿no es infinita la capacidad ahora?).

Pero tal como dice el artículo no es cierto que ITIL o ITSM pierda su importancia o se pueda prescindir de la gestión. Aunque ciertos procesos sean más “de caja negra” y no tengamos acceso a los detalles su gestión es igual de relevante que lo era antes.

En mi opinión uno de los puntos débiles del cloud computing es precisamente el tema de la gestión de los procesos IT, ¿es nuestro proveedor cuidadoso en el modo en que nosotros lo seríamos?, ¿son los niveles de servicio y tiempos de respuesta en cada proceso los que necesitamos?, ¿qué ocurre si algo no funciona?.

El cloud computing es potencialmente de menor coste a mejor servicio (el mismo enfoque que ocurre en el outsourcing) pero eso no quiere decir que necesitemos ese nivel de servicio (podríamos estar sobrepagando) o que sea suficiente. La salida de servicios en la nube es compleja, no es sencillo construir nuevos sistemas en nuestras ubicaciones y no hay dos servicios equivalentes.

“CMDB is dead”

Ya he escrito en otras ocasiones sobre críticas a la implementación de la CMDB dentro delos proyectos ITIL en las empresas, de nuevo me he encontrado otras opinión interesante sobre este tema.

En este caso es ciertamente ácida, cito algunas de las frases más jugosas:

  • Most small orgs and companies just dont need it. Its honestly only useful when you breach some amount of scale.
  • ITIL definition of what should be in a CMDB has been effectively unachievable because of the costs associated
  • it doesnt. Really, it never has. And even with the highest priced tools on the market today never will. At best its an audit-against tool that you can see

Estoy de acuerdo en que algunas herramientas de CMDB no son más que inventarios de activos, pero es que eso ya no es poco para muchos clientes. También en que las empresas de pequeño tamaño no son capaces de recuperar las inversiones y costes de administración necesarios para mantener una CMDB. Por ello también estoy de acuerdo en que “cierto concepto de CMDB” está muerto y no hay temor de que resucite. Voy a explicar a que me refiero con algún ejemplo práctico, vuelvo a algo que ya he dicho en otros momentos, todo proyecto IT debe perseguir un objetivo concreto y un beneficio empresarial esperado.

Yo he visto de cerca implantaciones erróneas de CMDB (fracasadas sería más adecuado) y en mi opinión casi siempre el problema es que en algunos casos se persigue el objetivo de ser “ITIL Compliance” en lugar de conocer el objetivo tangible que perseguimos (reducir los errores en cambios del actual X a un deseado Y, mejorar la gestión de incidencias y el nivel de servicio obtenido, mejorar el proceso de despliegue en costes y eficacia). No tiene sentido aplicar modelos de gestión simplemente porque nos dicen que son mejores sin cuantificar los beneficios o saber que problema concreto perseguimos resolver. Creo que hay que considerar ITIL como lo que es, una guía de posibles caminos de mejora y procesos a considerar, creer que es la palabra revelada es un peligro, la gestión de la capacidad (por ejemplo) es algo apasionante para ciertas organizaciones y un proceso innecesario para otras.

Incluso en este enlace nos indican que es Gartner quien dice que la implantación de ITIL está siendo fallida.

Los motivos de estos problemas en mi opinión son:

  • Que los fabricantes están intentando vender una misma solución para todos los problemas (las aplicaciones de gestión).
  • Que el concepto de CMDB es exageradamente amplio. Y eso obliga a las herramientas.
  • Que se quiere automatizar primero en lugar de estandarizar, ¿porqué no un estándar de identificación (similar a SMNP) y que los sistemas proporcionen la información a la CMDB en XML? No tiene sentido pretender inventariar los dispositivos desde fuera, los modelos antiguos tiene sentido pero no costaría nada que los nuevos sistemas se autoidentifiquen.
  • Que la CMDB se convierte en un fin y no en un medio.
  • La estimación de las inversiones es imprecisa, pero la estimación del coste de gestión es terriblemente optimista.
  • Sobre todo y principal no definir objetivos.

Sigo pensando que los proyectos de implantación de CMDB tienen validez en muchos entornos, probablemente lo mejor para no hacer inversiones inútiles es comenzar el proyecto por un proyecto de inventario de activos (que tiene muchos beneficios y muy rápidos, suelen pagarse solos en menos de un año) y cuando ya dispones de un inventario de activos considerar las ventajas de avanzar a la CMDB.

Una CMDB correctamente dimensionada en alcance y amplitud es una herramienta muy útil para una adecuada gestión de cambios y la mejora de la disponibilidad de los servicios, y en grandes corporaciones son dos procesos críticos. Sin ir más lejos, hace unas semanas uno de mis clientes tuvo ocho aplicaciones de negocio utilizadas por cientos de usuarios caídas por una mala planificación de los cambios y una gestión incompleta de las relaciones entre los sistemas. No es que una CMDB lo hubiera evitado, pero disponer de la información adecuada (que no es trivial encontrar allí) si lo habría hecho.

Curva de Gartner

Por finalizar, no creo que la CMDB esté muerta, pero desde luego ha pasado su momento de tecnología “hype” sobrevalorándola, puede que ahora pasado este pico inicial comencemos a aplicar adecuadamente un concepto y una herramienta que tiene mucho que aportar. Recordemos la famosa curva de Gartner sobre la evolución de las tecnologías.

Cazando el problema con la solución

La tecnología es adictiva, las personas y las empresas somos adictos, hemos visto tantas veces como la tecnología ha mejorado nuestras vidas que introducimos más y más tecnología de modo adictivo en nuestras vidas, personalmente es muy obvio, compramos nuevos productos que son “tendencia” como el iPad, el iPhone, la Blackberry, un portátil en vez de un PC de sobremesa, el último móvil, la última televisión de gran definición.

Las empresas se portan como las personas porque las componen personas, igual que las personas compramos un nuevo móvil con una tecnología novedosa las empresas adquieren tecnología porque es novedad. Las “olas tecnológicas” nos llaman.

Este artículo tiene un frase que me parece adecuada:

It seemed like they wanted to play with the technology / tools that they had already bought, and were hunting for problems with a solution in hand. While on the other side of the fence, call it business operations, there were problems screaming out for solutions.

“Ir a la búsqueda de un problema con la solución en la mano.” Este tipo de actitudes son comunes, se ven en tecnologías “de moda” con mucha asiduidad, como ejemplos podemos tener BPM, ITIL, SOA, ERP (en su día).

La moda es tener una tecnología, así que tu empresa la compra y después busca para que le vale, es una actitud de “laboratorio tecnológico” que algunas empresas han conseguido implantar con éxito, buscan nuevas ventajas en la tecnología y las aplican a su negocio. Pero esta actitud requiere:

  1. Saber que estas experimentando y corriendo riesgos.
  2. Ser muy flexible para aplicar las nuevas posibles ventajas competitivas.

Pero no es un comportamiento fácil de seguir con éxito, sobre todo los que no saben que experimentan (y se enfadan cuando las ventajas no aparecen por si solas) o los que carecen de flexibilidad en su modelo de negocio para aplicar las posibles ventajas.

Hay muchos casos de empresas que adquieren “tecnología” sin saber para que, o que problema quieren solucionar. Es en parte culpa de los analistas que afirman cosas como “un CRM mejora sus ventas”, “un sistema de compras rebaja los costes” o “un cuadro de mando permite a la dirección mejorar el control de la compañía”. Y todo ello puede ser cierto pero solo en los casos que las empresas aplicaron esa tecnología del modo adecuado.

También es culpa de los fabricantes de la tecnología, buscando cerrar la venta sugieren al cliente que lo compre y comience a usarlo esperando que los resultados aparezcan solos.

No se trata del dicho “No pongan el carro delante de los bueyes”, realmente es saber que poniendo los bueyes tirando del carro no hará que el carro llegue a su destino por si solo.

No eludo la culpa de los proveedores de servicios, somos a veces cooperantes necesarios. Pero sobre todo la culpa es de las empresas que adquieren la tecnología, como la dirección no es capaz de impulsar cambios o mejoras en sus organizaciones pretende que introducir la tecnología sirva de catalizador.

La tecnología puede ayudar, pero es solo una herramienta, ni una condición, ni un catalizador, ni un impulsor del cambio, el cambio nace la dirección de la empresa pero no surge por si solo.

La detección de problemas es la joya oculta de ITIL

itil v3 cms

Es sorprendente que las implantaciones de ITIL (o pseudo-ITIL, como son muchas veces los service desk que se implantan como herramientas y no como procesos de gestión) dejan a un lado posiblemente la joya que mejor puede potenciar su departamento de TI, que para mi es la gestión de problemas con mucha claridad.

Si pensamos en ITIL v3 (aunque a mi me gusta más la definición de ITIL v2 que es mucho más sencilla) los procesos son:

  • Procesos ITIL de Estrategia del Servicio: Gestión Financiera, Generación de la Estrategia, Gestión de la Demanda, Gestión de la Cartera de Servicios (SPM)
  • Procesos ITIL de Diseño del Servicio: Gestión del Catálogo de Servicios, Gestión del Nivel de Servicio (SLM), Gestión de la Capacidad, Gestión de la Disponibilidad, Gestión de la Continuidad del Servicio TI (ITSCM), Gestión de la Seguridad de la Información, Gestión de Suministradores
  • Procesos ITIL de Transición del Servicio: Planificación y Soporte de la Transición, Gestión de Cambios, Gestión de Configuración y Activos del Servicio SACM, Gestión de Entregas y Despliegues, Validación y pruebas del servicio, Evaluación, Gestión del Conocimiento
  • Procesos ITIL de Operación del Servicio: Gestión de Eventos, Gestión de Incidencias, Gestión de Peticiones, Gestión de Problemas, Gestión de Accesos.
  • Service Desk (Centro de Servicio al Usuario) (Función), Gestión Técnica (Función), Gestión de la Operación de TI (Función), Gestión de Aplicaciones (Función).
  • Procesos de Mejora Continua: Medición del Servicio, Proceso de mejora de CSI, Informes de Servicio

Las compañías suelen enfocarse en la gestión de incidencias, la gestión de activos, de capacidad, seguridad, continuidad, cambios. Todos estos procesos son importantes, pero posiblemente gestión de problemas es el proceso que más rápidamente puede mejorar al departamento de TI y con menos coste comparativamente. ¿Porqué? Porque es el proceso que en más ocasiones se hace rematadamente mal en las compañías e incluso llega a no gestionarse.

Hay implantaciones de Service Desk que no contemplan la gestión de problemas y tratan los problemas como incidencias abiertas, lo que es un error de base, porque de ese modo no tratan bien ni las incidencias ni los problemas, los objetivos de ambos procesos son absolutamente dispares igual que su realización. Además el proceso de gestión de problemas tiene una gran ventaja, no es imprescindible utilizar herramientas para hacerlo, si hay un proceso que se puede hacer con papel y bolígrafo en ITIL es este. Es recomendable disponer de una herramienta, pero no imprescindible, lo que nos quita una barrera de entrada.

Todos los demás procesos ITIL se realizan en los departamentos de modo más o menos visible, mejor o peor y con un coste más elevado o más óptimo, la gestión de la capacidad es un proceso que puede ser gestionado de modo informal en muchas compañías donde la tecnología es tan “commodity” que adquirir nuevos sistemas o ampliarlos es una decisión sencilla.

La gestión de problemas es evitar los fallos reiterados que tanto penalizan a la imagen del departamento de TI, todo el mundo comprende que las cosas fallan alguna vez, la gente se desespera cuando falla siempre lo mismo día tras día.

Los resultados son tan visibles como mágicos, para los usuarios “las cosas comienzan a funcionar”, mientras que el usuario no percibe una mejora de servicio como reducir el tiempo de resolución de incidencias de 20 minutos a 10 minutos, o mejorar el ratio de resolución de la primera llamada de un 50% a un 75% conseguir eliminar los problemas subyacentes del servicio causa un efecto directo en la imagen de TI, la satisfacción del usuario y la mejora de la disponibilidad y servicio.

Para una adecuada Gestión de Problemas necesita un Service Desk o un Helpdesk, y una razonable gestión de incidencias, tampoco hace daño algo parecido a una CMDB o un catalogo de servicios pero no es preciso ser muy exigente en estos temas, los beneficios se puede obtener igualmente (aunque reducidos, pero ligeramente). Si quiere comenzar a implantar ITIL de algún modo, este es la mejor vía, la de menos inversión y la de más retorno, después de ello tendrá más credibilidad para afrontar el resto de procesos que pueda necesitar.

El mito de medir para gestionar

Este es un artículo subversivo basado en este artículo (“Great myths of ITIL #1: “You can’t manage what you can’t measure“) y ésta discusión en un grupo de LinkedIn. Y como es subversivo puede comenzar con un chiste.

Un hombre con un reloj siempre sabe que hora es pero un hombre con dos relojes nunca está seguro.

Hay un mito que hemos vendido los consultores (yo también he pecado) y es la frase “Lo que no se puede medir no se puede gestionar”. En teoría cuanta más información posees más precisa será la decisión que tomes, ¿alguien lo duda? es algo evidente, pero eso es cierto siempre que tengas tiempo infinito para analizar información y la información tenga coste cero. Pensemos en un examen de bachillerato, si en vez de proporcionar los diez datos que necesitas para resolver el problema te proporcionan cien datos (muchos de ellos redundantes o no relacionados) ¿es más fácil resolver el problema o más difícil? ¿es mejor la solución?

No siempre es mejor tener más información, necesitas más tiempo para analizar toda la información y si no dispones de ese tiempo y si seleccionas el conjunto de datos que no es el adecuado seguramente la solución propuesta será errónea. De modo que podemos afirmar que no siempre más información o más mediciones es más óptimo. Recuerdo que un profesor en la universidad de teoría de seguridad definió problema como algo “que debe ser resuelto en un tiempo finito” ya que si disponemos de tiempo infinito podemos esperar que se  resuelva solo en algún momento.

¿Podemos gestionar sin medir?

Gestionamos sin medir cada día, miles de cosas, continuamente, gestionamos por “sensaciones” que es lo mismo que decir que gestionamos en base a la experiencia, el cerebro humano no es numérico, no precisa un dato concreto para tomar decisiones.

Algunos ejemplos de decisiones que no se basan en mediciones son:

  • Hacer dieta, no hacemos dieta porque nuestro peso sobrepasa en un 15% el peso idóneo, hacemos dieta cuando “nos sentimos” gordos. No necesitas una bascula para saberlo, un espejo te vale, eso no es una medición y la decisión varía entre verano e invierno, o antes de la boda y después.
  • Ir al médico, nadie va al médico porque tiene el colesterol por encima de 120, el hierro bajo o una rotura fibrilar de 2,2 cm en el cuadriceps derecho. Vas al médico porque “te sientes mal”.
  • Elegir amigos, conoces dos personas en un viaje, y sin datos aparentes una de ellas y tú decidís que podéis ser amigos y continuais en contacto y con la otra no.
  • Conducir un vehículo, la frase “se cambia de marcha cuando lo pide el coche” es la primera discusión de todo aprendiz que afirma que a él “no le pide nada” y pretende mirar el cuentarevoluciones, pero ningún conductor experto cambia mirando el cuentarevoluciones, lo hacemos en base al sonido del motor, la necesidad de potencia en ese instante y el trazado de la vía, todo ello sin “mediciones” exactas.
  • Abrigarse, ¿alguien se viste en base a un termómetro? es evidente, nos abrigamos más o menos por “la sensación térmica” y no por el dato de temperatura.
  • Alimentarnos, una decisión como “hace 2h 15 minutos que ingerí 1.150 calorías y debo alimentarme de nuevo” es absurda, te alimentas porque tienes hambre.

Evidentemente, tomamos decisiones sin realizar medición de datos continuamente, ¿solo en nuestro entorno personal? Veamos ejemplos de decisiones laborales que no están basadas en mediciones, están basadas en la experiencia del gestor para decidir sin necesidad de medir:

  • Escoger a quién le encargas una tarea, un buen gestor conoce su equipo y “sabe” quién es la persona adecuada para un trabajo, a veces considera la carga de trabajo, la formación como factores secundarios, pero la decisión se hace sin parámetros medibles.
  • Elegir clientes objetivos, no me refiero a “análisis de mercado” como puede hacer para saber cuanta gente podría comprar Leche Pascual sin Lactosa donde si se cuantifican los clientes, hablo de empresas como la mía, compañías de servicios, empieza el año y escoges diez o veinte clientes objetivo, ¿porqué BBVA y no Popular? ¿porque Enagas y no Endesa? He visto intentos de tomar la decisión basada en la facturación de cada empresa, de su gasto en TI o del número de contactos que conoces dentro de cada compañía (¿tener 28 contactos es significativamente mejor que tener 12? ¿O realmente importa más la relevancia de los mismos?).  La elección la hace la dirección comercial basándose en su experiencia.
  • Escoger nuevas líneas de negocio, aunque tengamos el dato de “Gartner afirma que el mercado de BI crecerá un 18%” la decisión de invertir en capacitarte para dar servicios de BI se basará en un montón de “sensaciones” basadas en la experiencia del gestor que toma la decisión, en caso contrario todas las empresas harían lo mismo.
  • Decidir qué áreas de tu empresa necesitan mejoras, cuando una empresa quiere implantar mejoras no obtiene un dato indicador del desempeño de cada departamento para decidir que departamento debe ser modificado, un gestor que conoce su compañía “siente” donde está el problema. Habrá quien puede lanzar a cada departamento a realizar estudios de grado de mejora y coste de implantarla para realizar una comparación, pero no creo que sea la idea apropiada.
  • Escoger socios e incluso romper alianzas,es una decisión vital para una compañía y no se hace por motivos que sean cuantificables.

La utilidad de la medición es relativa

  1. Medir por si mismo no aporta nada. En segundo curso de mis estudios universitarios teníamos una asignatura llamara “Planificación y Explotación de Sistemas Informáticos”.  Cuando resolvimos el primer problema, obtuvimos como resultado que el sistema informático analizado daba como resultado 3.2 y diez segundos después mi compañero de pupitre preguntó “¿Es bueno o malo ese 3.2?” La respuesta del profesor fue que 3.2 por si solo no es bueno o malo, es solo el resultado.
  2. El problema de “la constante K de excel”. Todo sistema de medición en un momento determinado recurre a constantes para obtener un resultado a partir de datos sin relación entre sí. La satisfacción del cliente es la suma de veinte por la desviación media en días de la fecha de entrega de los proyectos menos quince por la cantidad de errores totales.

No pretendo decir que la medición de parámetros de desempeño sea inútil, es evidente que medir es importante y hay indicadores cuyo cálculo simplifica mucho el proceso de elección de ciertas decisiones. Pero ni todas las decisiones exigen medición, ni todas las mediciones son posibles.