En muchos ámbitos profesionales se pueden encontrar acrónimos y abreviaturas que son útiles en los Sistemas de Gestión, como las 4P del marketing. ¿Conoce 5W1H? Seguro que le resultará útil.

Continuamos en este artículo comentando acrónimos que pueden ser útiles como recurso fácil para recordar aspectos clave (si quiere, puede consultar la entrada de la semana pasada)

Leer más

En muchos ámbitos profesionales se pueden encontrar acrónimos y abreviaturas que son útiles, como las 4P del marketing. ¿Conoce 4M1E? Seguro que le resultará útil para aplicarlo a los Sistemas de Gestión.

Leer más

Aunque la Gestión de Servicios de TI, amparadas por ITIL o ISO 20000, son prácticas conocidas y reconocidas en el sector existen muchas organizaciones que se resisten a implantarlas. Sin duda hay mucho camino por recorrer y muchas oportunidades para mejorar la calidad de los servicios y la productividad de las organizaciones.

España es un país de PyME (en general más P que M), donde el 99,3% tiene menos de 50 empleados. Si nos centramos en el sector relacionado con TI, ver capítulo 10 del informe sobre implantación de las TIC en las PyME, podemos observar que hablamos de un número importante de empresas (unas 26.000 dedicadas a la programación, consultoría y otras actividades relacionadas).

Leer más

Esta métrica nos da una aproximación de cómo de fácil o de complejo es restaurar de nuevo un servicio tras una incidencia que afecte a su disponibilidad. Obviamente es importante contar con sistemas estables que tengan pocas caídas de servicio, y que ofrezcan una elevada tasa de disponiblidad, pero es igualmente importante contar con sistemas que, cuando se caigan, sean sencillos de recuperar.

Llevado al extremo, pensemos un sistema que solo se cae una vez al mes, pero cuya restauración requiere de 8 horas; si lo comparamos con un sistema que se cae una vez a la semana, pero cuya restauración lleva apenas 1 hora… ¿cuál dispone finalmente de mejor tasa de disponibilidad?. Además, el tiempo de restauración no afecta directamente a la disponibilidad del sistema, si no que también podría tener una derivada importante en el perfil de los técnicos implicados en su restauración: si se tarda mucho, quizá es que sea un sistema complejo, y si es así, quizá se requieran técnicos demasiado especializados, caros y difíciles de encontrar. Moraleja: es importante contar con sistemas de alta fiabilidad, pero nunca olvidemos que nos guste o no, las caídas de servicio ocurrirán tarde o temprano, y seguro que querremos que su restauración sea lo más rápida y sencilla posible.

Jandro Castro

Leer más

No confundir con el tiempo entre incidencias (MTBSI). El MTBF mide el tiempo de servicio ininterrumpido, desde que el servicio entra en servicio desde la restauración de la última incidencia, hasta que vuelve a caerse.

Leer más

Cuando se analizan las inversiones en tecnología, en muchas ocasiones se comete el error de tener en cuenta tan solo el coste de compra o licenciamiento, o como mucho también se tiene en cuenta el coste de implantación, pero rara vez se analiza realmente el coste total de la propiedad. Este TCO deberá tener en cuenta todos (todos) los gastos incurridos a lo largo de todo (todo) el ciclo de vida del activo (o sistema, o lo que se esté comprando). Además de conocer cuánto cuesta comprarlo/alquilarlo e instalarlo, ¿cuánto costará su mantenimiento posterior? ¿y cuánto esfuerzo vamos a tener que dedicarle por parte del departamento de TI (horas = dinero)? ¿y cuánto vamos a gastar en formación, tanto de técnicos como de usuarios? ¿y si es un sistema hardware, cuánta energía eléctrica va a consumir? ¿y se requiere pagar algún servicio extra como un seguro, ubicación física, impuesto,…? Un ejemplo extremo de cálculo de TCO lo tenemos con la implantación de sistemas open source, en donde el coste de las licencias muchas veces es cero, pero aparecen otros muchos costes (implantación, formación, desarrollos y mantenimiento de los mismos para adaptar el producto, costes y horas para darle soporte al sistema,…) En resumen: el coste total de la propiedad debe ser capaz de tener en cuenta todos (todos) los costes directos e indirectos vinculados a todo (todo) el ciclo de vida del sistema que se esté comprando.

 

Jandro Castro

Leer más

     

Gestionar la disponibilidad no es sólo implementar una “simple” monitorización, y entran en juego muchos más factores, y muchas relaciones con otros procesos: relación de la indisponibilidad con las incidencias, histórico de indisponibilidades, relación de caídas de servicio con los SLAs, niveles de cumplimiento de SLAs en cuanto a disponibilidad se refiere, integración de eventos derivados de la monitorización dentro de la CMDB para ser capaz de propagar la indisponibilidad de la infraestructura hacia la indisponibilidad de los servicios. La Gestión de la Disponibilidad tiene muchas ramificaciones hacia otros muchos procesos y sistemas, y toda esta información combinada requiere de un sistema de gestión, que es precisamente el AMIS. De manera ideal, el AMIS debería estar integrado con el resto de sistemas de gestión de servicio, conviviendo con el SKMS, con el CMS / CMDB, con la base de datos de incidencias y errores conocidos, por supuesto integrado con la CDB. Esta integración hará que las fronteras de cada uno de los sistemas se difuminen, no estando claro dónde termina uno y dónde termina otro, pero generando un sistema de información global e integrado que maximice el valor generado por el departamento de TI.

Jandro Castro

  Leer más

El SKMS es mucho más que una simple base de datos de conocimiento en donde ir registrando FAQs o tópicos. Cierto es que la base de datos de conocimiento es una parte importante, pero hay muchas más fuentes de información que deben estar integradas en el SKMS, como por ejemplo, el catálogo de servicios o el CMS (con su correspondiente CMDB). ¿Acaso los dos elementos anteriores no son una gran fuente de conocimiento? A mayores, la propia base de datos de incidencias, de problemas, de errores conocidos, son todos elementos que albergan gran cantidad de información y conocimiento que debería ser integrado dentro del SKMS. En definitiva, el SKMS deberá “reunir” todas aquellas herramientas de la organización que se identifiquen como una fuente de información relevante, y conseguir articular todo ese conocimiento para que pueda ser consultado y consumido de una manera sencilla (acumular información sin ordenar no genera ningún valor, ya que se perderá tiempo en buscar algo que muchas veces no se logrará encontrar). Jandro Castro   Leer más

Herramienta fundamental (aunque no única), del proceso de Gestión de Configuración y Activos del Servicio. En muchas organizaciones se convierte en todo un rompedero de cabeza, y es vista como una de las partes más difíciles de implantar y mantener de todo el sistema de gestión de servicios TI.

Esto no debería ser así, y aquí van algunos consejos para una implantación “no dolorosa”:

(1) partir de una buena definición del catálogo de servicios de la organización;

(2) identificar y relacionar los elementos de la infraestructura que se usan para la prestación del servicio, sin preocuparse en un primer momento de la parte consumidora;

(3) en la medida de lo posible, ayudarse de herramientas de autodescubrimiento para identificar los CIs tecnológicos;

(4) no todo lo que está en el inventario de activos tiene por qué estar en la CMDB;

(5) entender la construcción de la CMDB como un proceso iterativo, en la que la primera versión tendrá poco nivel de detalle, y en fases posteriores se irá profundizando en el modelado de aquellos servicios que lo requieran;

(6) no todos los servicios tienen que tener un modelado en la CMDB con el mismo nivel de detalle;

(7) guardar solo información que realmente sea de interés, nunca guardar por guardar.

Jandro Castro

  Leer más

Decían en un anuncio publicitario que la potencia sin control no tiene sentido, y algo parecido ocurre en las TI: la infraestructura y los recursos disponibles deben ser una justificación clara y objetiva. Y como no podía ser de otra manera, la justificación debe venir de mano del negocio, analizando la demanda real, tanto actual como a futuro. ¿Que demanda real de los servicios tenemos ahora? ¿Tenemos una capacidad razonable, sin quedarnos cortos pero ni tampoco pasarnos en exceso de largo para cubrir esa necesidad? Y aun teniendo la papeleta resuelta ahora, ¿que previsión hay a futuro, cuales son los planes del negocio para los próximos meses? ¿Podemos seguir así, o debemos plantearnos hacer ajustes para seguir el ritmo del negocio?

Hay que tener en cuenta que una capacidad no ajustada a las necesidades del negocio (tanto por exceso como por defecto) siempre sale cara:

1. Por defecto, porque corremos riesgo de ofrecer un servicio de pobre calidad que no cubra las expectativas de los clientes, y que por lo tanto dejen de serlo en busca de otro proveedor.
2. Por exceso, porque hemos realizado una inversión en adquirir una infraestructura que realmente no necesitamos, y que además casi seguro nos sale más cara de mantener y operar que una con menor capacidad, pero que igualmente cubría las necesidades del negocio.

Lograr que la balanza encuentre un punto de equilibrio ahora, garantizando que dicho equilibrio también se mantendrá en el futuro no siempre resulta sencillo, pero sin duda será totalmente imposible sin contar con una comunicación fluida con el negocio. Jandro Castro Leer más

El punto único de rotura es como una bomba de relojería en nuestra infraestructura, que tarde o temprano acabará explotando, pero nadie sabe cuando, y pocos se atreven a tratar de solucionar. Al menos, si no tenemos recursos o capacidad para eliminar “el punto peligroso”, lo suyo, seria documentarlo convenientemente (quizá como un error conocido en la gestión de problemas) para que todos los posibles impactados estén al tanto de la circunstancia, y disponer de un plan por si vienen mal dadas (una solución temporal al error conocido, o incluso, un plan de continuidad si el impacto en el negocio es realmente grave).

La CMDB puede ser una herramienta fundamental a la hora de encontrar y analizar el impacto real de estos SPOFs. Detectar CIs no redundados relacionados con servicios críticos, o CIs únicos relacionados con un elevado número de servicios puede ser un punto de partida estupendo en la detección de estas bombas escondidas. Contar con un análisis de impacto en el negocio puede resultar de gran ayuda a la hora de conseguir los recursos necesarios para eliminar ese SPOF.

En estos casos realizar un BIA sobre un elemento que termine en la prestación del servicio, en lugar de hacerlo sobre el propio servicio, puede resultar una actividad de lo más interesante. Pero no todos los SPOF tienen por qué ser obligatoriamente tecnológicos: ¿un conocimiento clave no compartido que este en la cabeza de un solo técnico no podría ser igual de peligroso que la caída de un servidor clave? ¿y contar con una gran dependencia de un único proveedor externo para la operación y mantenimiento de un servicio crítico? No escondas los SPOF debajo de la alfombra, al contrario, buscalos y documentalos, trata de eliminarlos justificando por que debe hacerse, y si esto no fuese posible, al menos ten preparado el mejor plan B posible…

Jandro Castro

Leer más

La existencia del plan debería ir siempre de manera muy ligada a los distintos SLAs que tengamos acordados con los clientes de nuestros servicios. El coste de la disponibilidad se dispara exponencialmente conforme aumentamos su %, con lo que debe estar perfectamente alineado con las necesidades y expectativas de los clientes, dentro de un marco económico razonable. Guste o no, la disponibilidad es cara, con lo que se debe revisar muy bien cuales son los niveles reales necesarios.

Pasar de una disponibilidad del 98% a una del 99.5%, o disminuirla hasta un 95% puede tener una repercusión económica realmente notable. ¿Realmente el negocio requiere porcentajes de disponibilidad tan altos? Realizar un análisis de impacto en el negocio (BIA), de manera conjunta y coordinada con la gestión de la continuidad puede aportar información tremendamente valiosa a la hora de establecer los niveles de disponibilidad realmente necesarios.

Sirva de ejemplo el servicio de correo electrónico, para el que con mucha frecuencia se le exige disponibilidad cercana al 100% (porcentaje terriblemente caro si debemos ofrecerle con infraestructura propia): ¿realmente nuestro negocio no es capaz de “sobrevivir sin una caída de servicio de un par de horas al mes? ¿realmente se para la organización?

Jandro Castro

Leer más

Al igual que ocurría en el caso de los CABs, puede que no siempre tenga los mismos integrantes en función del tipo de cambio a implementar, si bien resulta de interés que determinadas personas clave estén presentes en todos ellos para darle continuidad y coherencia al proceso de Gestión de Cambios. El ECAB será el encargado de autorizar los cambios de emergencia, con lo que deberá ser lo suficientemente ágil para dar respuestas en los plazos de tiempo (cortos) requeridos. Esta agilidad implicará que típicamente los ECABs tengan un número de miembros reducido, facilitando así la toma de decisiones (este aspecto es un arma de doble filo, ya que el consenso suele ser más fácil cuando el número de personas implicadas es menor, pero a la vez, el riesgo de equivocación aumenta, al contar con menos “cabezas pensantes”). Buscar el balance entre agilidad de respuesta y control de riesgos es uno de los aspectos más complicados de conseguir en la gestión de cambios de emergencia, por lo que los integrantes de los ECABs deberán ser técnicos/usuarios con grandes conocimientos sobre los sistemas implicados en el cambio.

Jandro Castro

Leer más

A la hora de constituir el CAB (o los CABs) de nuestra organización, debemos tener en cuenta que no siempre las mismas personas son las más adecuadas para decidir según qué cambios: por ejemplo, para cambios referentes al core de comunicaciones nos interesará contar con determinados perfiles técnicos o incluso con proveedores externos que nos asesores, pero para realizar otros cambios sobre aplicativos de gestión internos, los involucrados podrían ser otros.

Esto denota la circunstancia de que podríamos necesitar la definición de varios CABs, no solo uno, en cuyo caso sí debería darse cierta continuidad entre ellos, haciendo que personas clave participen en todos ellos. Además, no hay que caer en la equivocación de que todos los integrantes del CAB son personal de TI, ya que se debería contar con la participación de los dueños de los servicios impactados, o incluso con la colaboración de los usuarios que usan mayoritariamente el servicio (un cambio en el CRM podría ser técnicamente viable desde el punto de vista técnico, pero muy poco apropiado desde el punto de vista comercial al publicar información sensible a personas que no deberían tener acceso a la misma; de igual manera, un cambio en el sistema de RRHH debería ser validado por los usuarios de dicho sistema, tanto en la funcionalidad como en las fechas más adecuadas para su despliegue).

Por último, también debe tenerse en cuenta que el CAB no solo debería centrarse en la evaluación y autorización de cambios, sino que también debería realizar revisiones sobre los cambios estándar que han sido realizados (aunque este tipo de cambios no requieran de autorización previa, no implica que no deban ser controlados por el CAB y el proceso de Gestión de Cambios).

Jandro Castro

  Leer más

Las paradas programadas del servicio deberían tenerse siempre en cuenta durante las negociaciones para establecer los niveles de servicio (SLAs), así como para el cálculo de los niveles reales de disponibilidad del servicio. Deberán establecerse y pactarse ventanas temporales en las que poder realizar paradas programadas para realizar cambios, actividades de mantenimiento que no puedan realizarse con el servicio en ejecución, actualizaciones de componentes que formen parte fundamental en la cadena de prestación del servicio,… Estas ventanas deberán ubicarse siempre en franjas horarias en las que el impacto al negocio sea el menor posible, siempre y cuando el coste de realizar los cambios en esa franja horaria tenga un coste razonable (para servicios no críticos, quizá no sea necesario incurrir en el sobrecoste de realizar cambios de madrugada, y puedan realizarse en otros “horarios más económicos”). Además del horario de las intervenciones, puede que también sea necesario limitar el número máximo de las mismas en un periodo de tiempo: por ejemplo, que hayamos pactado que las ventanas horarias para el mantenimiento del servicio sea de 2:00 a 3:00 AM, no implica que todas las madrugadas se pueda parar el servicio para hacer correcciones.

Leer más