Twitter ProactivaNET LinkedIn ProactivaNET Vimeo ProactivaNET RSS ProactivaNET Facebook ProactivaNET Youtube ProactivaNET Google+ ProactivaNET

ProactivaNET Blog

Visita el blog de referencia en el mundo de TI, ITSM, ITIL y descubre como aplicar las mejores prácticas a tu organización

En él podrás ver casos de éxito, artículos de opinión, eventos del sector y hasta un glosario de términos ITIL que te ayudarán a ver desde una perspectiva práctica como mejorar la gestión de servicios de TI

21 Ene

ITSM y la alineación entre TI y negocio

M

En los últimos años los CIO han escuchado constantemente que debían alinear TI con el negocio y ahora incluso se dice que ya no se debe alinear, sino que se debe integrar con el negocio. ¿Puede ayudarnos la Gestión de Servicios de TI a conseguir este objetivo?

Tradicionalmente los departamentos de TI no han sido considerados como un recurso de la empresa para generar valor al negocio sino más bien como un área de actividad necesaria para el funcionamiento del mismo modo que, por ejemplo, el departamento de contabilidad.

 Hace ya tiempo se comprobó que las TI pueden modificar sustancialmente la organización y aportar ventajas competitivas que reviertan en mejoras notables para el negocio (automatización de procesos, reducción de costes, nuevas oportunidades de negocio, etc.). Desde entonces se insistió en que TI debía alinearse con el negocio, lo que significaba comprender las necesidades del mismo y trabajar de manera coordinada.

Más recientemente, se ha sugerido que el concepto de alinear TI y negocio es contraproducente, porque transmite la idea de algo ajeno al mismo y que participa “desde fuera”. El cambio de terminología que se propone no tiene más objetivo que evidenciar que TI forma parte del negocio, del mismo modo que lo hace el departamento de producción de una fábrica o el departamento comercial de cualquier empresa.

¿Cómo podemos garantizar que TI conoce los objetivos de negocio de manera que se integre y que todas sus actividades están asociadas a objetivos de negocio? Como TI es un departamento cuya misión fundamental es proveer servicios al resto de departamentos de la organización, lo que debemos conseguir es que los servicios que preste tengan una relación clara con los objetivos de negocio. Esta actividad puede realizarse desde los procesos de Gestión del Catálogo de Servicios y Gestión de la Cartera de Servicios.

Si implantamos estos procesos en nuestra organización de manera rigurosa, deberemos analizar todos los aspectos para cada servicio ofrecido, y siendo uno de ellos el que nos interesa ahora: ¿cuáles son los procesos de negocio que son soportados por cada servicio? Si respondemos a esta pregunta podremos relacionar los procesos de negocio con los servicios que proporciona TI y cerraremos el círculo al relacionar los objetivos de negocio de alto nivel con los objetivos de TI más específicos.

José Luis Fernández
Leer más
9 Ene

Motivos para tener una CMBD

tenerunacmbd¿Pretendes implantar procesos ITIL y te estás preguntando para qué sirve una CMDB? Antes de plantearnos implantar una CMDB deberíamos reflexionar sobre sus ventajas y el valor que realmente nos aporta. En este artículo te explicamos cuál es su verdadera transcendencia.

ITIL propone un buen número de procesos para estructurar las distintas actividades que sustentan la prestación y gestión de servicios de TI de calidad. Uno de los procesos, Gestión de la Configuración y Activos del Servicio (SACM), incluye explícitamente el concepto de CMDB, tan de moda hoy en día.

Pero, antes de entrar en materia, debemos definir qué es una CMDB, algo que va más alla de un simple inventario de tecnología. Se trata de un repositorio de información a partir del cual se modela toda la prestación y gestión de servicios de TI, en el que se guarda tanto información tecnológica como de negocio. Por ejemplo incorpora cuáles son los servidores que utilizamos, qué servicios sustentan dichos servidores y cuáles son las relaciones con otros elementos clave, como los procedimientos de trabajo o acuerdos de nivel de servicio.

Una CMDB, como cualquier otro repositorio de información, sólo aporta valor cuando se consulta, en cambio, el coste de tener y mantener nuestra CMDB estará presente desde el primer momento. Por lo tanto, el primer consejo que podemos dar es que la CMDB y el proceso de Gestión de la Configuración y Activos del Servicio no deben ser el primer proceso a implantar, precisamente porque la CMDB aporta valor cuando se consulta desde las actividades propias de otros procesos:

  • Desde Gestión de Incidencias, para trazar los elementos relacionados con los que muestra el síntoma de un fallo, pudiendo averiguar dónde se encuentra para proponer una solución alternativa.
  • Desde Gestión de Problemas, para analizar con detalle los elementos relacionados con los activos que muestran fallos recurrentes e identificar aquellos activos que verdaderamente son la causa raíz.
  • Desde Gestión de Cambios, para analizar el impacto de las modificaciones en la infraestructura utilizada para prestar servicios.

Sin embargo, si implanto los procesos de manera progresiva y el primero es Gestión de la Configuración y Activos del Servicio, no obtendré ningún beneficio porque no tendré ningún proceso desde el que se consuma la información, pero ya estaré soportando el coste de implantación y mantenimiento de la CMDB desde el primer momento. Por este motivo, es mejor empezar por otro proceso y dejar la CMDB para más adelante.

Casi da igual qué proceso implantemos antes que Gestión de la Configuración y Activos del Servicio, porque todos los procesos se aprovechan de la CMDB. Así que implantemos primero uno o dos procesos (por ejemplo Gestión de Incidencias y Gestión de Peticiones) y después Gestión de la Configuración y Activos del Servicio con su CMDB.

Eso sí, cuando implantemos nuestra CMDB debemos estar listos para implantar a la par Gestión de Cambios, pero eso lo trataremos en otro artículo.

José Luis Fernández Piñero

Leer más
26 Dic

¿Métricas? Porqué y para qué

Todos conocemos la máxima que dice que no se puede mejorar lo que no se conoce y no se conoce lo que no se mide. Sin embargo, esta idea tan sencilla -a la par que importante-, no siempre se aplica. Una organización que presta servicios de TI lleva a cabo sus actividades mediante la operación de muchos procesos dentro de los marcos de prácticas ITSM Software.

Sin embargo, muchas organizaciones de TI operan sin ningún control sobre sus actividades o, lo que es peor, controlan aspectos irrelevantes o secundarios. Si  lo desconocido no se puede medir y no es posible mejorar lo que resulta desconocido, entonces nuestro enfoque ha de partir siempre de esta premisa a la hora de implantar cualquier sistema de medición sobre la gestión de servicios de TI. La propia frase enuncia el motivo para medir: no puedes mejorar lo que no conoces. Es decir, necesitamos datos e información para poder aplicar acciones que conduzcan a mejoras y que estén basadas en datos ciertos y no en opiniones o intuiciones. Consideremos, por ejemplo,  esta situación de crisis donde aumentar la productividad y reducir costes innecesarios es fundamental:

  • ¿Sabríamos decir cuál es el coste de la prestación de cada uno de nuestros servicios?
  • Si tenemos varios clientes: ¿Sabríamos decir cuánto nos cuesta cada uno de ellos para poder segmentarlos por rentabilidad?
  • Si hemos implantado el proceso de Gestión de Problemas: ¿Sabríamos cuantificar el efecto que ha tenido sobre la Gestión de Incidencias?

Medir no es el fin, es el medio para tener información a través de una herramienta que nos permita emprender acciones de mejora eficaces. Si no vamos a emprender acciones de mejora, entonces no deberíamos perder el tiempo en medir.

Medir encaja perfectamente en el ciclo de mejora de Deming, el conocido PDCA: P (plan) – D (do) – C (check) – A (act). Medir está dentro de la fase de control (check), pero esta fase no tiene sentido si no va seguida de acciones (act). Por lo tanto, debemos comprender que medir es la manera de conocer cómo operamos nuestros procesos de gestión de servicios de TI, para identificar cómo los podemos mejorar.

Para mejorar es algo muy ambicioso si no se acota, la mejora debe estar relacionada con los objetivos de negocio planteados. Si el objetivo es, por ejemplo, reducir costes, ¿qué sentido tiene que se mida los plazos de respuesta a los clientes? Quizás esté dispuesto a emprender acciones para mejorar los plazos de respuesta, pero entonces no estaré alineando la operativa con las líneas estratégicas establecidas.

Por lo tanto, asumamos que debemos identificar los objetivos de negocio e identificar qué debemos medir para poder emprender acciones de mejora alineadas con los objetivos. Cualquier consideración sobre métricas fuera de este planteamiento es, a priori, completamente prescindible por el coste adicional que aporta sin retorno alguno respecto a los objetivos de negocio.

José Luis Fernández Piñero
Leer más
14 Dic

Estrategias para identificar problemas II

estrategiasparaidentificarprobleamasDentro del marco ITSM Software la Gestión de Problemas es un aspecto fundamental. Identificar correctamente los problemas que se van a gestionar en busca de mejoras perceptibles en la calidad de la prestación de servicios es crítico.

En un artículo anterior explicamos cómo identificar los problemas cuya solución sería más eficaz para mejorar la Gestión de Incidencias. Otro proceso susceptible de mejora es la gestión de cambios ¿Cómo podemos priorizar los problemas para gestionar antes aquellos cuya solución tiene un mayor ROI?

Para mejorar la Gestión de Cambios.

a) Definir una lista de comprobación (checklist) que se aplicará de manera sistemática en todos los cambios cuando se cierren. Lo ideal es que tenga la forma de preguntas con respuesta sí/no (tal vez debamos tener distintas checklist en función del tipo de cambio). b) Revisar periódicamente los cambios agrupándolos por las respuestas a cada pregunta de la checklist para poder identificar aquellos que sugieren una oportunidad de mejora. Por ejemplo, el porcentaje de cambios tiene respuesta “sí” a las preguntas ¿la planificación fue adecuada? o ¿las pruebas fueron suficientes? c) Aplicar el principio de Pareto sobre los datos de b) para identificar las áreas de mejora (por ejemplo la planificación de las actividades o los recursos dedicados a pruebas)

La lista c) nos dará una idea de qué debemos cambiar a la hora de la gestión de cambios para que estos sean más efectivos. Este es, por tanto, el “input” para generar registros de problemas cuya resolución mejore la realización de cambios de manera efectiva. Como se puede apreciar, que la checklist sea adecuada es la clave del éxito de este método.

¿Cómo podemos elaborar la checklist para que sea efectiva? La respuesta es sencilla: busquemos los cambios cuya realización ha provocado incidencias. Veamos un ejemplo:

Supongamos que tenemos un cambio en el que había que migrar una aplicación de un servidor a otro. Se realiza la migración y la aplicación ya está funcionando en el nuevo servidor. Sin embargo, una semana después de realizar el cambio se empiezan a generar incidencias donde hay usuarios que reportan que una aplicación que leía información de la que fue migrada, ahora muestra un mensaje de error. Las incidencias están provocadas por una dependencia entre las dos aplicaciones que no se conocía o no se tuvo en cuenta.

Si trazamos el cambio con las incidencia que provocó y hacemos lo mismo con cada cambio que provoque incidencias, tendremos un buen punto de partida para identificar las preguntas y saber lo que debe contener la checklist. En este caso podrían ser:

  • ¿El análisis del impacto fue efectivo?
  • ¿Si el análisis del impacto no fue efectivo, se debe a que la CMDB no representaba todas las relaciones entre los activos?

De esta manera hemos visto cómo definir una checklist que utilizaremos para identificar las oportunidades de mejora en los cambios que podremos abordar mediante la Gestión de Problemas.

José Luis Fernández Piñero

Leer más
3 Dic

Qué difícil resulta definir el Catálogo de Servicios I

91156429_20-Qué difícil resulta definir el Catálogo de Servicios… Cuántos responsables de TI y de cuántas organizaciones habrán dicho estas palabras. Cuando las organizaciones comienzan la implantación de los procesos recomendados por ITIL, siempre surgen dificultades para identificar los servicios que prestan y “construir” un documento que los reúna. A este documento y, de manera muy simplificada, se le podría llamar Catálogo de Servicios.

Esta dificultad es especialmente relevante en los departamentos de TI que tienen como clientes al resto departamentos de la organización, porque normalmente existe la creencia de que el departamento de TI está ahí “para todo lo que necesiten”. En realidad esta es una falsa creencia contra la que luchar, porque el departamento de TI está para atender las necesidades de TI de la organización, considerando una serie de acuerdos, más o menos formales con el resto de los departamentos. Del mismo modo que un empleado cualquiera no puede pedir a un miembro del departamento jurídico que le ayude con sus dificultades legales, un miembro de cualquier departamento no puede esperar que el departamento de TI le solucione cualquier necesidad.

Es importante resaltar que, el hecho de que alguien del departamento jurídico no atienda nuestra consulta particular sobre una cuestión legal, tal vez no se debe a que ésta sea una consulta particular sino a que se encuentra fuera de las responsabilidades asociadas a ese departamento. Es más, podría darse el caso que, un departamento jurídico tuviese como responsabilidad atender también consultas legales a título particular de los empleados de la organización, por ejemplo, a modo de beneficio social para el personal. En este caso, la persona del departamento jurídico sí que debería atender esa consulta. Por lo tanto, la diferencia estriba en si esa petición que se hace a un empleado o a un departamento se encuentra o no dentro de sus responsabilidades. Aclarado esto, en un próximo artículo trataremos las razones por las cuales resulta tan difícil definir las responsabilidades del departamento de TI.

José Luis Fernández Piñero

Leer más
16 Ene

De cómo perder 3.000 euros por empleado y año

perder_tresmil_eurosQue la productividad global de nuestras organizaciones depende en gran medida de la plataforma tecnológica que tenemos a nuestro alcance, ya no es ningún misterio ni ninguna notica de interés. Sin embargo, lo que sí resulta interesante es analizar cómo nos afecta y, sobre todo, cuánto cuesta el “no mantenimiento” de esa infraestructura.

Medir el retorno de la inversión (ROI) en los procesos internos de mantenimiento informático de nuestras infraestructuras tecnológicas es complicado, realmente complicado, pero -con un poco de esfuerzo-, sí se pueden obtener algunas aproximaciones interesantes, como la publicada por techweek.es

En un estudio realizado por este medio, las pérdidas de producción por un mal funcionamiento de nuestro equipo informático se valoran (simplemente) en 1.500 euros por empleado y año. Pero el problema radica en el “simplemente”: realmente las pérdidas de productividad no son achacables sólo al PC que utilizas, habría que tener en cuenta sistemas comunes, tales como pérdidas de rendimiento en servidores, aplicaciones web corporativas, redes o conectividad. Los supuestos 1.500 euros salen de una estimación de pérdida de productividad de unas 83 horas/año, pero sumando sistemas comunes, se podrían duplicar fácilmente (redondeemos a 150 horas empleado/año). Según el estudio, se valora la hora/empleado aproximadamente a unos 20€/h (bastante poco por cierto), lo que multiplicado por las 150 horas se incrementa la cifra a unos 3.000 euros/año. ¡Tres mil euros por empleado y año! A partir de ahí, multiplica por el tamaño de tu empresa: ¿100 empleados? ¿500? ¿1.000?

Acciones para solucionar esto hay muchas y, en este caso, mejores prácticas como ITIL tienen mucho que aportar:

  • ¿Qué te parece una buena gestión de incidencias para minimizar su impacto, las horas de caída y reducir esas 150 horas a las mínimas posibles?
  • ¿Y un buen inventario de activos -adecuadamente actualizado y monitorizado-, para conocer qué tenemos y cómo lo tenemos?
  • ¿Si en el estudio se afirma que un PC pierde la mitad de su potencia al cabo de un año, dónde está la gestión de la capacidad para monitorizar esa pérdida?
  • ¿Y la gestión de la disponibilidad y los planes de contingencia para garantizar el correcto funcionamiento de los sistemas comunes?

De nuevo, hablar de ITIL no es sólo sinónimo de mejora de calidadservicios de mayor calidad, también es sinónimo de ahorro de costes y mejoras de productividad. A partir de aquí, tú decides qué camino prefieres: seguir como hasta ahora perdiendo 3.000 euros por empleado y año (en el mejor de los casos), o bien analizar otras alternativas de mejora que suponen una inversión (no gasto), para luego poder ahorrar mucho más.

Jandro Castro
Leer más
5 Ene

Optimizar sin que sobre personal es posible

despedidos

En muchas implantaciones de una herramienta que soporte los procesos ITSM para mejorar la prestación de servicios, el personal de TI ve peligrar su puesto de trabajo. Optimizar no implica recortar: es posible optimizar y crecer.

He participado en muchos proyectos de implantación de ProactivaNET como herramienta ITSM Software que soporta las mejores prácticas para que los procesos sugeridos por ITIL se realicen de una manera más eficiente. En muchos de estos proyectos el personal de TI que participa en la implantación ve peligrar su puesto de trabajo porque piensa que serán necesarios menos empleados si se optimiza la gestión de servicios de Ti.

Esta situación tiene dos inconvenientes. El más obvio es que si los participantes en la implantación tienen miedo a perder su puesto, tendrán una actitud reactiva a aceptar los cambios en la forma de trabajo y pondrán en peligro el éxito del proyecto de implantación de la herramienta ITSM. Otro inconveniente es que, si el director del departamento de TI quiere optimizar para recortar personal, no sólo los empleados tendrán motivos para esta actitud, sino que el posicionamiento del departamento en la empresa y su impacto en el negocio, se verán afectados y en lugar de ir a más se limitarán a mantenerse, lo que en el competitivo mercado globalizado es lo mismo que ir a menos.

Pongamos un ejemplo. Supongamos que de nuestros ingresos mensuales dedicamos el 20% a alimentación y que tras cambiar el supermercado donde habitualmente hacemos la compra conseguimos gastar tan sólo el 15%. ¿Qué hacemos con ese 5% que nos hemos ahorrado? ¿Hablamos con nuestra empresa para que nos baje el sueldo un 5%? ¡Por supuesto que no! Lo que hacemos es utilizar ese 5% para hacer cosas nuevas, por ejemplo contratar una conexión a internet de alta velocidad o televisión por cable.

Lo que sucede es que los recursos liberados por la optimización (ese 5%) deben verse como un aumento del presupuesto que nos permite hacer cosas nuevas. Supongamos que, tras implantar una herramienta ITSM Software y reorganizar los procesos y procedimientos de trabajo, necesitamos menos técnicos de soporte para hacer lo mismo. En esta situación no debo verlos como candidatos a ser despedidos, sino como si tuviese presupuesto para contratar un montón de personal nuevo, que además, no tienen los inconvenientes de las nuevas incorporaciones porque este personal ya está formado.

¿Qué podemos hacer con este personal que ahora está disponible? La solución es obvia: podemos ofrecer más servicios o mejorar los actuales. Por ejemplo:

  • Reasignar técnicos a primera línea de soporte para reducir los tiempos de primera respuesta.
  • Implantar nuevos procesos (por ejemplo Gestión de Problemas) ya que tengo técnicos disponibles para realizar las actividades correspondientes.
  • Ofrecer nuevos servicios, al disponer de técnicos para dedicar al proyecto de creación del nuevo servicio (por ejemplo desplegar una solución VPN corporativa).
  • Reforzar las tareas preventivas (por ejemplo los planes de contingencia)

En definitiva, una optimización debe ser vista como una oportunidad para ampliar lo que estamos haciendo y no para reducir lo que se tiene. Así el departamento de TI podrá cumplir mejor su misión: aportar valor al negocio y mejorar su papel dentro de la organización.

José Luis Fernández Piñero

Leer más
10 Dic

Estrategias para identificar problemas I

identificando problemasDentro del marco ITSM Software la Gestión de Problemas es un aspecto fundamental. Identificar correctamente los problemas que se van a gestionar en busca de mejoras perceptibles en la calidad de la prestación de servicios es crítico.

Cuando una organización quiere utilizar el proceso de Gestión de Problemas para avanzar en la mejora continua, debe asumir que siempre es posible identificar muchos problemas sobre los que actuar en busca de una optimización. Sin embargo, los recursos disponibles son escasos y, por tanto, es muy importante priorizar los problemas para abordarlos de manera que se obtenga el mayor impacto con el menor coste.

¿Cómo podemos priorizar los problemas para gestionar antes aquellos cuya solución tiene un mayor ROI?

Para mejorar la Gestión de Incidencias:

a) Hacer una lista de los servicios con mayor número de incidencias. b) Hacer una lista de los servicios en los que se emplean más recursos para solucionar incidencias (por ejemplo, horas de técnicos de soporte). c) Aplicar el principio de Pareto en las listas anteriores (a y b), para quedarnos con un subconjunto de servicios “mejorables”.

La lista a) nos dará una idea de qué servicios -en los que se aplique la Gestión de Problemas-, tendrán un mayor impacto de cara a los usuarios finales, ya que podremos minimizar sus molestias e interrupciones en el día a día.

La lista b) nos dará una idea de qué servicios -en los que se aplique la Gestión de Problemas-, tendrán un mayor impacto de cara al propio departamento de TI ya que podremos reducir los costes.

Limitándonos a los servicios de la lista c, analizaremos las incidencias asociadas para identificar puntos en común. Una herramienta muy útil es hacer una exportación de todos los datos de las incidencias (usuario notificador, CIs afectados, fecha de creación, etc.) y analizarlos usando tablas dinámicas de Excel. Esto permitirá identificar factores en común (por ejemplo qué aplicación corporativa provoca más incidencias). Con la información anterior crearemos conjuntos de incidencias asociados a un problema relacionado con ese factor en común. El orden en el que abordaremos los problemas será:

  • Si queremos mejorar la percepción del usuario elegiremos los problemas con más incidencias asociadas.
  • Si queremos mejorar la productividad del departamento de TI elegiremos los problemas con mayor coste de resolución asociado a sus incidencias (por ejemplo la suma de las horas empleadas por los técnicos).

En el próximo artículo explicaremos cómo identificar los problemas que mejorarán la realización de cambios.

José Luis Fernández Piñero

Leer más
29 Nov

Una de tantas posibles clasificaciones para ITSM Software

La gestión de servicios de TI es una disciplina que en los últimos años ha logrado alcanzar altos grados de madurez, tanto a nivel interno en los departamentos de TI, como en las empresas consultoras proveedoras de servicios a terceros. El grado de madurez es tal que ya no basta con implantar procesos, sino que se ha hecho imprescindible la necesidad de maximizar la eficiencia con la implantación de procesos eficientes que garanticen la productividad y potencien el valor generado por nuestro negocio.

En la implementación de procesos de gestión de servicios de TI nos vemos prácticamente obligados a contar con el apoyo de herramientas software, ya que sin ellas sería imposible hacerlo de manera eficiente. Afortunadamente y a día de hoy, la amplia oferta disponible en el mercado ofrece una madurez y calidad a la altura de lo esperado. Esta oferta prácticamente garantiza que encontraremos una herramienta que se ajuste a nuestras necesidades, pero a la vez complica un poco más la elección, ya que tendremos que elegir entre una gran cantidad de alternativas.

Para ayudar a la búsqueda de nuestra “herramienta perfecta”, trataremos de hacer una primera clasificación de los distintos tipos de software que nos encontraremos en el mercado. Criterios para clasificarlo hay muchos, pero en esta ocasión utilizaremos algo tan sencillo como el tamaño, aunque sea difícil de aplicar para el software. Conforme a esto, podemos clasificar el ITSM software en tres grandes grupos:

1. Herramientas de tamaño pequeño, incluso open-source, con soporte para un pequeño número de procesos, costes económicos muy reducidos y esfuerzo de implantación relativamente bajo. Puede ser un buen punto de partida para implantar este tipo de herramientas, aunque su validez podría ser temporal o relativamente corta, al no ser capaces de asumir nuevos procesos o llegar a madurez importante en los mismos. Pero dado su pequeño tamaño y bajo coste, la gran mayoría de ellas carecen de certificaciones oficiales que garanticen su alineación con ITIL.

2. Herramientas de gran tamaño (“Big Boys”), con soporte para muchos procesos, pero con coste muy elevado y mucha complejidad para la puesta en marcha. Cuidado con este tipo de herramientas, ya que sobre el papel ofrecen mucha funcionalidad, pero en la práctica, al ser tan complejas de implantar, sólo se podrá sacar partido un pequeño porcentaje de sus características (mucha potencia, pero muchas veces totalmente desaprovechada). Aunque sí están alineadas con ITIL, muchas de ellas carecen de certificaciones oficiales (aunque se presuponen).

3. Herramientas de tamaño medio (no por ser las últimas menos importantes), con costes y sencillez de implantación parecidas a las de tamaño pequeño -pero cada vez más-, con una funcionalidad parecida a las grandes. Su principal ventaja es la importante relación funcionalidad – sencillez que ofrecen y que, a pesar de que hacen un poco menos que las grandes, seremos capaces de sacarles partido al 100%,  debido a su sencillez y amigabilidad. Para garantizar su alineación a las mejores prácticas ITIL, conviene garantizar que cuentan con certificaciones PinkVERIFY y/o ISS de APMG.

A partir de aquí, queda de mano de cada organización buscar su propia alternativa:

  • ¿Herramienta pequeña y de bajo coste, pero que quizá no cumpla nuestras expectativas a corto o medio plazo?
  • ¿Herramienta de gran tamaño y elevado coste, con mucha funcionalidad, pero a la cuál quizá no logremos sacarle partido más que al 20% de su potencia?
  • ¿Herramienta intermedia entre una y otra, con funcionalidad muy parecida a las grandes, a la que podremos sacarle partido al 100%, con costes parecidos a las de las pequeñas?

Cada uno deberá sacar sus propias conclusiones, aunque yo lo tendría muy claro.

Jandro Castro

Leer más
14 Ene

Software libre y gratis no es lo mismo

C

En los tiempos que corren, los proyectos de inversión en nuevos productos software son analizados con lupa, pero muchas veces la lupa no ofrece una visión clara de la situación y se acaban confundiendo términos. Software libre y software gratuito no tienen por qué ser obligatoriamente sinónimos y, en muchas ocasiones, este tipo de software libre puede acabar saliendo mucho más caro que la compra de licencias comerciales.

Dicen que hay crisis o, eso se escribe en los periódicos, y ahora la fiebre de no gastar en nada y hacer más con menos lo inunda todo, incluyendo los departamentos de TI. ¿Comprar licencias de ITSM Software cuando hay opciones libres! ¿Estás loco? ¡Por qué gastar cuando hay cosas gratis! Tristemente, este razonamiento está presente en la adquisición de software para muchos proyectos, pero no se debería lanzar tal afirmación tan a la ligera. Poner en marcha un software (en nuestro caso un software específico para ITSM) no implica sólo la compra (esa es sólo una parte), hay que instalar, parametrizar, adaptar, poner en marcha y formar a técnicos y usuarios; pero, sobre todo, mantener el sistema para el futuro, garantizando su estabilidad y disponibilidad, con las consiguientes actualizaciones a las que se verá afectado a lo largo de su ciclo de vida. Con este planteamiento, podemos decir que la “adquisición” es sólo el primer eslabón de una larga cadena.

Apostar por software libre puede estar muy bien (en ningún momento decimos lo contrario), pero debemos analizar todos los factores, no sólo en coste de las licencias:

Integrado vs. integrable. Muchas herramientas de software libre se preocupan sólo de cubrir un pequeño espectro de nuestras necesidades y tendremos que buscar la integración de varias piezas para cubrir el 100%. Sin embargo, algo que pueda llegar a integrarse con otra cosa no es lo mismo que un único ente en el que todo ya está integrado. Tendremos que analizar quién va a hacer la integración y cuánto cuesta hacerla, pero ¿Cuál es la potencia real que dará la integración? ¿Qué riesgos corremos? ¿Quién lo va a mantener a futuro? ¿Cómo afecta a la actualización de cada una de las partes?

Analizar los riesgos. Es uno de los puntos más importantes a tener en cuenta, analizar bien los riesgos a los que nos enfrentamos integrando varias herramientas de software libre para que funcionen como un todo. Si las cosas van bien, estupendo, pero ¿y si van mal?

Adaptaciones open source. Aunque no sean lo mismo, muchas veces se confunden las soluciones open source con el software libre, y la capacidad de poder “tocar el código” acaba siendo un factor determinante en la decisión. Y puede que efectivamente lo sea, pero la cuestión es cómo vamos a migrar esas adaptaciones de código a las nuevas versiones del software. ¿Quién las va a hacer? ¿Tenemos capacidad humana y económica de mantenerlas en el tiempo? ¿Realmente merece la pena invertir en ello o sería mejor dedicar esfuerzos a otros factores clave de nuestro negocio?

Mantenimiento en el futuro. Muchas herramientas de software libre (no todas, pero sí muchas), no cuentan con servicios de soporte para resolver incidencias y para actualizaciones futuras, con lo que esas actividades tienen que ser asumidas por el propio departamento de TI con su correspondiente esfuerzo y riesgo.

Supongo que habrá muchos más factores a tener en cuenta, pero simplemente con los anteriores, si traducimos el esfuerzo en horas y costes económicos, aún sin analizar los riesgos a los que nos enfrentamos, sirve para ilustrar que software libre y gratis no significa lo mismo. Si has tenido en cuenta todos los factores anteriores, y resulta que la solución de software libre presenta un mejor análisis global que adquirir una solución comercial: enhorabuena y adelante, no lo pienses más. Sin embargo, si no has tenido en cuenta todos los factores anteriores, aún estás a tiempo de volver a revisar tu decisión, porque quizá el análisis no haya sido todo lo preciso que tu negocio necesita.

Jandro Castro
Leer más
2 Ene

Implantar procesos ITSM no afecta sólo a TI

atrabajarenequipoMuchos departamentos de TI fracasan al implantar procesos con ITSM Software y prácticas para la Gestión de Servicios de TI. ¿Por qué este tipo de proyectos son más complejos?

Los departamentos de TI intentan mejorar la forma en la que prestan servicios de TI al resto de la organización porque no consiguen completarlos exitosamente. Esta voluntad de mejora no se ve acompañada de resultados porque cometen el error de intentar repetir éxitos pasados. Parece una paradoja pero no lo es. Los departamentos de TI tienen éxito en muchos y muy complejos proyectos, pero éstos suelen tener una componente mayoritariamente tecnológica, terreno en el que los miembros del departamento se encuentran cómodos. Sin embargo, la implantación de los procesos ITSM Software no tiene una gran componente tecnológica, más bien es una cuestión de gestión, definición de procedimientos, asignación de responsabilidades e interacción con otras partes de la organización.

Quizás el departamento de TI pueda planificar y ejecutar una migración de Windows XP a Windows 7 sin tener muy en cuenta al resto de los departamentos, pero no tiene sentido definir el Catálogo de Servicios o acordar unos niveles de servicio sin que participe el resto de la organización. Para garantizar el éxito en la implantación de procesos y prácticas ITSM se debería tener previsto:

• Identificar todos los stakeholders (participantes), especialmente aquellos que son ajenos a la gestión de servicios de TI.

• Definir las responsabilidades y tareas que deberá asumir cada participante en el proyecto, incluyendo los stakeholders.

• Involucrar a los stakeholders para que asuman su compromiso con el proyecto

El punto más conflictivo es el último, precisamente porque no depende de TI. Es decir que, TI puede identificar los stakeholders y tener muy claro cómo deben participar en el proyecto, pero si no conseguimos su compromiso y colaboración, el proyecto no avanzará. Como muchos stakeholders son departamentos ajenos a TI, nos encontramos con una situación complicada, ya que el director de TI no tendrá suficiente peso como para poder imponerse sobre los demás departamentos, por lo que sólo hay dos opciones:

• “Venderles” la idea y los beneficios que obtendrán para que se involucren por voluntad propia.

• Obtener el respaldo de la dirección general para que establezca la obligatoriedad de participar.

En la práctica lo ideal sería una mezcla de ambos métodos (motivación y obligación), ya que sin el respaldo de la dirección la participación de los stakeholders se verá condicionada sólo a su disponibilidad y buena voluntad, y si nos limitamos a obligarles a participar, lo harán de mala gana y serán sumamente reactivos. Hay que tener en cuenta que las personas siempre son la Iclave del éxito de los proyectos, pero no siempre forman parte de nuestro propio equipo.

José Luis Fernández Piñero
Leer más
18 Dic

Lo queramos o no: ya estamos en la era post PC

viejopcversustablet

¿Hace cuánto que no lees una noticia en la prensa acerca del lanzamiento de “algo” relacionado con un PC? Probablemente mucho. Pero, sin embargo, rara es la semana en la que los medios no recogen varias noticias sobre los avances en las nuevas tablets de unos y otros fabricantes. Hasta los periódicos de interés general y muchos periódicos económicos siguen de cerca la evolución de estos dispositivos

No hay otra -nos guste o no-, las tablets han llegado para quedarse y resulta evidente que son ya presente y futuro, mientras la era PC va quedándose atrás poco a poco. Obviamente los PCs seguirán existiendo en nuestra vida y probablemente seguiremos usándolos muchos años, pero no hay duda que los tiempos han cambiado.

No me imagino a un desarrollador de TI que prepara un inventario de hardware o a un arquitecto, trabajando con una tablet, pero sí a muchos otros profesionales con estos dispositivos conectados a una docking como si de un PC convencional se tratase, con su teclado, ratón y pantalla.

Y si aún crees que toda esta moda es simplemente una estrategia de marketing, no tienes más que salir a la calle o venirte conmigo ahora mismo a la T1 del aeropuerto de Madrid. ¿Cuántos tablets ves en este momento a tu alrededor? ¿Muchas? ¿Y cuántos portátiles hay a la vista? Sólo uno: el mío con el que estoy escribiendo este post. 🙁

Jandro Castro

Leer más
5 Dic

Qué difícil resulta definir el Catálogo de Servicios II

91156634_20

En un artículo anterior explicábamos, cómo los departamentos de TI de una organización esperan realizar una serie de servicios para del resto de los departamentos de la empresa, bajo un marco de responsabilidades acordadas y asumidas más o menos formalmente. Ese marco formal es el Catálogo de Servicios, donde se explicitan los servicios que la organización de TI presta a sus clientes.

La dificultad para definir el Catálogo de Servicios en muchas organizaciones de TI se encuentra en que éstas han asumido que ellos hacen lo que se les pida. Pero aunque este enfoque pueda parecer el más adecuado para el conjunto de la empresa, nunca lo es en realidad.

Pensemos en el ejemplo habitual de una organización de TI que sea el departamento de TI de una empresa y los clientes el resto de los departamentos. En este contexto nunca no se debe infravalorar la importancia que tiene el papel del Catálogo de Servicios, ya que en él viene reflejado todo lo que se debe hacer, y por lo tanto, también lo que no debe hacer. Es decir, que quien contacte con el departamento de TI para solicitar algo fuera del Catálogo de Servicios debe asumir y comprender que posiblemente no se va a atender su petición. El departamento de TI tiene un presupuesto y debe tener unos objetivos concretos y específicos y, por supuesto, estos objetivos deben estar alineados con los objetivos de la organización.

Por ello, los servicios que el departamento de TI incluye en el Catálogo de Servicios deben ser aquellos que permitan el cumplimiento de los objetivos de TI y de la organización, pero asumiendo que la prestación de estos servicios tiene un coste que debe cubrir el presupuesto disponible.

Debemos, por tanto, comenzar a pensar en criterios más complejos antes de asumir que el departamento de TI deba prestar un determinado servicio. Preguntémonos:

  • Si el presupuesto de TI es suficiente para la prestación de determinado servicio.
  • Si no lo es y el resto de los departamentos exigie ese servicio; ¿estarían ellos dispuestos a asumir todo o una parte importante del coste?
  • Si prestar ese servicio está alineado con los objetivos de TI y con los de la organización en su conjunto.
  • Si prestar ese servicio interacciona en los demás servicios ya prestados.

Si empezamos a considerar estos aspectos y explicamos al resto de la organización por qué es importante tenerlos en cuenta, será más fácil definir un Catálogo de Servicios realista y eficaz.

José Luis Fernández Piñero

Leer más
26 Nov

CMBD: Alcance

Hasta dónde hay que meter información es uno de los aspectos más importantes a tener en cuenta a la hora de definir una CMDB:  el alcance o, lo que es lo mismo, los activos de relevancia que va a contener. El alcance se aplica no sólo a la cantidad de servicios que debemos modelar en ella sino hasta qué tipos de elementos hay que dar de alta para ser capaces de modelar dichos servicios.

El otro día comentábamos que lo ideal sería comenzar con un alcance pequeño, por ejemplo, seleccionando un par de servicios especialmente importantes o que estén dando problemas. Una vez elegidos estos servicios iniciales, deberemos definir cuáles serán los elementos (tecnológicos o no) que formarán parte de la prestación de dichos servicios. Obviamente, deberemos diferenciar entre los activos tecnológicos relevantes para el servicio y aquellos que son irrelevantes. En este punto es importante destacar que una CMDB no es un inventario de activos, sino que deberemos llevar a ella única y exclusivamente aquellos activos verdaderamente relevantes para la prestación del servicio. Por ejemplo para la gestión de servicios de impresión de planos podríamos llevar a ella los siguientes activos tecnológicos:
  1. Los servidores que comparten las impresoras.
  2. Los operativos de dichos servidores para garantizar que disponemos de los drivers oportunos.
  3. Las impresoras.
  4. Los drivers que debemos instalar en los servidores para compartir las impresoras.

Hasta aquí es suficiente. Seguramente podríamos incorporar mucha más información (como el hardware de los servidores). Pero… ¿Te has parado a pensar si es realmente relevante toda esa información para modelar el servicio de impresión? ¡Rotundamente No! Como ejemplo de activo no tecnológico podríamos añadir los manualea la CMBD los de uso de las impresoras de este servicio, pero para una fase inicial es suficiente. Más tarde y, en función de las necesidades, podrían agregarse otros activos tecnológicos y no tecnológicos interesantes que, de alguna forma, pudieran apoyar un análisis de impacto, tanto de un cambio como de la gestión de la capacidad. ¿Pero si aún no vamos a implementar esos procesos, para qué complicarnos la vida en exceso cuando aún queda tanto por hacer?

Alejandro Rayón
Leer más

© 2000-2017 ProactivaNET es un producto de Espiral MS

ESPAÑA · Equipo I+D+i. Espacio Tecnológico Molinón

Tel. (0034) 985 099 215

comercial@proactivanet.com

itil pink verify ITSMF España>
</p>		
</div></div></section>
			
		</div>
	</div>
	
	
		<div id=