Búsqueda


Mostrando entradas con la etiqueta Productos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Productos. Mostrar todas las entradas

16 de octubre de 2015

La minería de procesos en acción

Hacía mucho tiempo que tenía ganas de hacer esto. Un pequeño vídeo que demostrara las capacidades de la minería de procesos de tal forma que te pudieras hacer una idea más clara de lo que se puede llegar a conseguir con este tipo de herramientas.

La semana pasada organizamos en G2 el evento Business Process Transformation, donde explicamos varias técnicas que nos permiten facilitar la mejora continua y la transformación de los procesos de negocio, y entre ellas hablamos de la minería de procesos. Un “problemilla” técnico deslució mucho una demo en la que tenía puestas muchas ilusiones así que he aprovechado un rato que tenía disponible para preparar este video. No soy un profesional de la edición, así que ha quedado como ha quedado… pero estoy seguro de que te activará las neuronas y te dejará imaginando cómo podrías aplicar este tipo de ideas en tus procesos.

Sólo una pista a tener en cuenta: cuando hablamos de “proceso” hablamos de “cosas que cambian en el tiempo”… así que podemos aplicar estas técnicas para analizar la evolución en el tiempo de cualquier concepto. Por ejemplo, mi compañero Jorge hizo una extracción de datos de LinkedIN para representar el mapa de cuáles son los caminos más exitosos para que una persona se convierta en CIO. Mi amigo Mariano quiere utilizarlo pasa estudiar el comportamiento de los alumnos en los MOOC de la Generalitat y yo lo he utilizado para estudiar el proceso de conformación de facturas o el factor de rotación de personal de un outsourcer del que no se mucho más que el rastro que dejan sus operadores en mis herramientas de gestión.

Abre tu mente, imagina cómo podrías utilizarlo y ponte en contacto con nosotros en http://www.gedos.es si quieres un piloto o una prueba con tus propios datos. ¡Aprender es gratis!

29 de julio de 2009

Acelerando el ciclo de diseño de servicios

Los chicos de JustInMind han publicado una nueva versión de su producto JustinMind Prototyper. Es una aplicación que, desde que la conozco, me llama poderosamente la atención, porque pienso que es una herramienta justinmindmuy importante para acelerar los ciclos de diseño y desarrollo, al tiempo que reduce de una manera considerable los riesgos de rechazo que podamos tener en el momento de la validación o de la entrega de las aplicaciones desarrolladas “en casa”.

Lo importante de JP no es sólo que nos permite hacer maquetas que le podemos presentar al cliente antes de comenzar a desarrollar (lo que tantas y tantas veces hemos visto hacer con imágenes o con diseños en powerpoint “que lo aguanta todo”), sino que además incorpora todos los mecanismos que nos van a permitir realizar hacer una maqueta funcional (osea, que funciona) y que el propio cliente (o sus Key Users) pueden probar, validar y comentar, al tiempo que facilita el flujo de revisión y aprobación por parte del cliente de cada una de las secciones de la maqueta.

La gran ventaja de esto: movemos la validación de usuario a una etapa anterior al desarrollo lo que reduce considerablemente el riesgo.

Si en tu casa desarrollas software, es un indispensable para al menos evaluarlo (te puedes bajar una versión de trial y el runtime es gratuito): mejor servicio al cliente (que puede “tocar” su aplicación antes de que la desarrolles), menores ciclos en el desarrollo (ya que el equipo de desarrollo “ve” lo que tiene que construir), menores ciclos de aceptación (ya que el cliente obtiene exactamente lo que vió en la maqueta) y menor riesgo de rechazo (de clientes, que han participado en el diseño, y de usuarios, que pueden haber incluso recibido  una primera formación utilizando la maqueta).

29 de agosto de 2008

British Airways con viento de cola

Hoy he leído un artículo del CIO Update que hablaba sobre un caso de estudio de aplicación de Lean IT en British Airways. Me ha llamado la atención por varios motivos; el primero, porque en el evento de Abril del itSMF-NL tuve la ocasión de conocer a Ian Clayton que dio varias conferencias sobre modelos basados en Lean Manufacturing aplicados a ITIL, en lo que él llamaba Lean ITIL.

Otro de los aspectos interesantes de este post es la propuesta y la interpretación que aparece entre líneas del concepto tradicional de "las 3 P". Las 3P del mundo itilero son People, Process, Products (en mis tiempos se decía People, Process, Technology, pero entonces no se podía dar "la regla de las 3P" a los alumnos de Foundations, así que algún profesor espabilado cambió el concepto a las 3P y desde entonces ha proliferado).

Esta gente de BA ahora utiliza una ampliación de ese concepto: las 3PI, donde entran Proposition, Process, People and Single IT Solution:

  • Proposition: Para cada una de las iniciativas o propuestas que se lleven a cabo dentro de IT, se analizará cada propuesta frente a las demás, estudiando el valor que aporta cada una.
  • Process: Se entenderá el proceso de negocio extremo a extremo y no la pobre interpretación del mismo que puede hacer IT sobre los puntos en los que IT participa.
  • People: Se tendrá en cuenta la usabilidad (tanto para el personal propio como para el usuario/cliente final -- no olvidemos que es British Airways)
  • ... y finalmente la Tecnología

Es muy interesante, porque entre otras cosas y tal y como dice el artículo, si lo pensamos bien, esto significa que las TIC son únicamente el 25% de cualquier iniciativa. No tiene por que ser matemático, pero como imagen es perfecta y me gusta: Valor, Proceso, Personas y entonces después miramos cómo metemos la Tecnología en todo esto.

¿Se acuerdan de aquel Whitepaper de HP mítico llamado A fool with a tool is still a fool ?

14 de abril de 2008

Integrar las herramientas

Como veíamos en el artículo anterior de esta serie, hay una serie de condiciones que pueden justificar la unificación de herramientas:

  • Actividades externalizadas "autocontenidas"
  • Equipos de trabajo monocliente
  • Posición de fuerza de negociación con los proveedores

Pero hay muchos casos en los que no se dan las condiciones necesarias como para poder unificar las herramientas: los proveedores de servicios utilizan las economías de escala para reducir sus costes y obtener los beneficios que justifican estas líneas de negocio, y eso en el sector servicios se consigue garantizando la ocupación del 100% de la carga de trabajo en actividades que reporten beneficios a la compañía.

Esta situación nos lleva directamente a que, para hacer rentable un equipo de trabajo, el outsourcer tiene principalmente dos opciones:

  • Conseguir un contrato que le permita facturar el 100% de la ocupación del personal al mismo cliente (lo que nos lleva a la situación de equipos monocliente)
  • Conseguir múltiples contratos con diferentes clientes y ocupar al equipo en actividades multicliente.

Esta segunda opción es la que nos encontraremos en la gran mayoría de situaciones, donde un grupo de trabajo (operadores, administradores, desarrolladores, etc) dedica su actividad a diferentes clientes, aprovechando de esta manera "los tiempos muertos" y permitiendo hacer una aproximación al mercado de menor coste (por cliente) pero de mayor beneficio (global).

Así, rompemos la premisa que nos permite unificar herramientas y vemos que la aproximación de integración de herramientas comienza a cobrar fuerza, pero es una vía llena de obstáculos y dificultades.

Para poder llevar con éxito un proceso de integración de este estilo, es recomendable seguir una aproximación más o menos metodológica al proyecto:

  1. Definir lo más detalladamente posible los resultados esperados de la integración.
  2. Diseñar / Modificar el modelo de procesos (integrados) para asegurar que pueda producir el conjunto de resultados esperados.
  3. Construir el meta-modelo de datos, sabiendo qué datos deben fluir, cuándo y con qué mapeos de información.
  4. Escoger la herramienta que nos permitirá hacer todo esto.
  5. Implementar una maqueta / piloto que nos permita refinar todo lo diseñado en los pasos anteriores
  6. Implementar la integración
  7. Diseñar / Modificar los procedimientos operativos, para asegurar que permiten generar los resultados esperados y que se adaptan a los nuevos requerimientos generados por el proceso de integración.
  8. Paso a Producción
  9. Matenimiento in-eternum de la integración

Si llegas con éxito al punto 8, las cosas habrán cambiado de una forma drástica en la forma de trabajar. A partir de ese momento, ocurre que la integración comienza a desvelar toda una serie de situaciones que antes no se notaban: las <n> compañías ahora están atadas por un vínculo que no tiene sentido común ni creatividad y que "canta" los errores que se producen.

quantum-marker-art-bgAsí, cualquier variación en los datos que están incluidos en el meta-modelo significa que se debe adaptar la integración (por ejemplo, una modificación en las categorías de la organización 1 implica que se debe decidir a nivel de integración qué queremos hacer con esa categoría en la organización 2); otro ejemplo es que algunos de los cambios que se produzcan en las operativas de cualquiera de estas organizaciones puede afectar seriamente a la integración (ya que tenemos definido en qué momento se traspasa la información, sea por el mecanismo que sea).

En este momento, es muy fácil que la integración se vea como un obstáculo a la evolución de todas las organizaciones participantes del sistema: pero en realidad lo que ocurre es que antes de la integración cada entidad iba por libre, con intercambios de información nulos o mínimos, en un conjunto de sistemas independientes que evolucionaban cada uno como quería y, desde el momento en que los hemos unido con una cuerda, los sistemas ya no son independientes y deben "tenerse en cuenta" unos a otros.

Por lo tanto, hay un par de factores que son especialmente sensibles y que deben ser analizados con cuidado antes de lanzarse a una aventura como esta:

  1. ¿Vale la pena? Es decir, los beneficios que vamos a obtener una vez analizado el punto (1) de nuestra aproximación metodológica son superiores al esfuerzo y costes que vamos a incurrir? Quizás no es únicamente una cuestión de coste/beneficio sino de necesidad / ley /cumplimiento.
  2. ¿Tengo un circuito de cambios maduro, que me garantice que no vamos a romper la integración continuamente por modificaciones no controladas?
  3. Para garantizar la agilidad, ¿la herramienta escogida me acompaña?

Por último, y como consejo aprendido en las trincheras, a polvo, sudor y hierro (como el Cid): KISS Hazlo simple, no compliques en exceso el nivel de detalle con el que quieres intercambiar información porque en el extremo de esa complicación está el modelo de herramientas unificadas. Todo en su justa medida.

8 de abril de 2008

Unificar las herramientas

Una de las posibles opciones que aparecían como ganadoras en la encuesta que comentábamos en el post anterior es la de unificar.

La idea que hay detrás de unificar las herramientas es simple de explicar, pero bastante difícil de conseguir: la organización diseña sus procesos, implanta una herramienta que los soporte y consigue que sus proveedores utilicen esta herramienta para el seguimiento de todas las actividades dentro de los procesos establecidos.

La principal ventaja que nos da esta aproximación es que toda la información relativa a las actividades de un proceso queda almacenada en un único sitio, con lo que la complejidad del seguimiento, monitorización, extracción de métricas y reporting se reduce considerablemente.

A priori, y desde el punto de vista de la organización que externaliza, todo parece perfecto pero... es en el interior de esta herramienta única donde comienzan a aparecer las dificultades.

El primer punto complicado es conseguir convencer a mis proveedores de que deben utilizar mi herramienta y seguir mis pautas de trabajo: si lo tengo resuelto por contrato (es decir, tuve en cuenta esta situación en el momento de firmar el acuerdo de externalización), posiblemente será mucho más sencillo; pero si ya tengo al proveedor en casa y he de cambiar su forma de trabajo, la cosa puede ser administrativamente complicada.

Una vez que lo haya conseguido, me encontraré con la segunda parte complicada: cuando uno externaliza una parte de las actividades de TI, quiere olvidarse de la gestión operativa del día a día, de la contratación de nuevo personal, de su formación... uno compra "un servicio", porque de lo contrario, lo que haría es contratar personal. Pero en esta herramienta debo mantener, por ejemplo, los grupos de trabajo a los que se escalan las incidencias, las cuentas de cada uno de estos usuarios y estar informado de los movimientos que se realizan en el personal para que se mantengan en la aplicación.

Vamos a poner un par de ejemplos especialmente dolorosos:

¿Podremos entrar en la herramienta todas aquellas personas que van a participar en la provisión de una nueva línea de comunicaciones, para poder ir asignando la petición de uno a otro técnico y de uno a otro grupo de trabajo?

¿Podremos tener en la herramienta las cuentas de usuario de todos los programadores hindúes que participarán en el mantenimiento evolutivo de mi SAP, y de los jefes de proyecto y coordinadores?

Así, cuando los equipos de trabajo que me prestan los servicios están trabajando "en mi casa" o son lo suficientemente reducidos y estables como para que los podamos mantener correctamente, puede ser que la unificación de herramientas sirva como alternativa para algunos tipos de procesos, pero no para todos.

El tercer punto de fricción lo vamos a encontrar cuando los diferentes proveedores que van a trabajar con mi herramienta quieran tener diferentes formas de trabajar. Aquí se puede armar un lío de consideración, así que la única solución posible es mano dura y firmeza: soy yo quien define los procesos, y por lo tanto soy yo quien define la manera de trabajar. Porque si no lo hacemos así, tendremos que parametrizar (configurar, diseñar o lo que sea) la herramienta para múltiples modelos de procesos, con lo que terminaré con 10 herramientas metidas en una sola y además administrándola yo!!

Por último, está el aspecto económico de la cuestión (que debe ser consensuado en el momento de la contratación de los servicios): ¿Quién paga las licencias de usuario?

En definitiva, y como conclusión: desde mi punto de vista, la unificación de herramientas es un modelo que sirve cuando las actividades externalizadas están "autocontenidas" y los equipos de trabajo que nos prestan el servicio son monocliente, como por ejemplo cuando externalizo la atención telefónica y un equipo de personas presta este servicio únicamente a mi organización.

Es en estos casos en los que se puede definir una única manera de trabajar (porque no habrá conflicto con las maneras de trabajar de otros clientes que utilicen al mismo equipo), una única herramienta (porque tampoco tendremos a un equipo de gente trabajando con tantas herramientas como clientes) y porque podremos realizar una administración centralizada de esta herramienta.

7 de abril de 2008

Integrar, unificar o ninguna de las anteriores

Cada vez más nos encontramos en que los Departamentos de TI no trabajan de una forma independiente o aislados del mundo exterior; el concepto de "People, Process & Technology" ha evolucionado y ahora se debe hablar casi que obligatoriamente de People, Process, Technology & Partners y es muy frecuente (cotidiana, más bien) la externalización de parte de los procesos o actividades dentro del área TIC en contratos con terceras partes.

De igual manera, es cada vez menos habitual encontrar compañías que tengan acuerdos de carácter exclusivo y que trabajen únicamente con un único proveedor, por lo que es fácil que lleguemos a encontrar tres o más proveedores diferentes dando distintos tipos de servicios (ya sean profesionales o servicios TIC).

Así, ¿quién no ha visto un Departamento TIC con parte del soporte (aunque sea el tercer nivel) contratado con un tercero, a la vez que dispone de un servicio de Hosting por parte de otro proveedor diferente, el desarrollo del ERP contratado con otro y el desarrollo de las páginas Web en un cuarto?

Es normal que contratemos en el exterior aquello que necesitamos, y además lo contratemos a diferentes empresas en función de los parámetros de compra que tengamos (especialización, homologación de proveedores, precio, etc); pero en un entorno organizado por procesos (y recordemos que los procesos son cross-funcionales) esta contratación en el exterior puede complicar realmente las cosas.

¿Cómo puedo realizar una correcta gestión del cambio cuando tengo el proveedor de hosting y el de desarrollo en diferentes compañías? ¿Como puedo hacer un correcto seguimiento (y medición) de estas actividades? ¿Cómo le escala mi proveedor de ServiceDesk una incidencia al proveedor de aplicaciones en modo ASP de Noruega?

Obviamente, no hay demasiadas alternativas: por una parte está la correcta coordinación y control de todo esto (que desde mi punto de vista debe ser ejecutado en un 99% de los casos por personal propio de la empresa en cuestión: es decir, se puede externalizar/subcontratar la ejecución de las tareas pero no la gestión y gobierno, salvo excepciones muy, pero que muy contadas), por otra parte está el tener en cuenta esta característica de "multiempresa" en el diseño de los procesos y, por último, está la esencial toma de decisión al respecto de qué pasa con las herramientas que nos van a permitir articular o implementar nuestros procesos.

Este último punto es el que provocó a principios de año la realización de una pequeña encuesta que se publicó en este blog y cuyos resultados aún se pueden encontrar al final de la barra de la derecha.

Vaya por delante que los resultados de la encuesta no sirven nada más que para saciar nuestra curiosidad, porque con 19 votos y además de respuesta múltiple no vamos a ningún sitio, pero...

  1. El 42% dijo que integraría las herramientas propias con las del proveedor
  2. Otro 42% optó por la unificación: una única herramienta (mía) y que los proveedores la usen.

Y aquí es donde nace el título de este post... integro, unifico o ninguna de las anteriores (que son las otras diferentes opciones que hay en la encuesta).

15 de febrero de 2008

Microsoft se lo toma con calma

Estaba previsto para este año: Microsoft debía entrar con fuerza (yo esperaba que entrase con esa fuerza habitual de Microsoft cuando se trata de hacerse un hueco en un mercado nuevo) en el mercado de las herramientas "ITIL Compliant", pero ayer pude ver en uno de sus blogs que hace una semana anunciaban un retraso en la presentación del nuevo producto MS System Center Service Manager.

Y este retraso no es "un ligero retraso": anuncian que no se presentará hasta la primera mitad del 2010.

Era un producto que ya estaba en betas y que se había puesto a disposición de los partners para su evaluación, así que no podían faltar dos años para su presentación. ¿Qué ha pasado?

Microsoft presenta en las FAQs de este anuncio una serie de explicaciones para este retraso, principalmente basado en las necesidades de rendimiento y escalabilidad del producto... y eso da que pensar.

¿Rendimiento y Escalabilidad?

Opción 1: el producto estaba mal diseñado / mal implementado / mal construido y se han dado cuenta en la fase de betas. Hay que volver a hacerlo, reconstruirlo completamente y para eso necesitan dos años.

Opción 2: El producto era adecuado, pero para SMB. Durante este tiempo han pensado que tienen tecnología/conocimientos/capacidad para hacer entrar su producto en los grandes clientes y es necesario soportar miles de "tickets" (ya sean ServiceCalls, RFC o lo que sea) al mes y millones de CIs en la CMDB y para eso se necesita rendimiento y escalabilidad.

Opción 3: Le van a dar la vuelta y nos van a sorprender con algo totalmente diferente... integrando procesos de ServiceDelivery, o integrando EPM y montando una solución espectacular para la Gestión de la Demanda y Portfolio de Proyectos, o cualquiera sabe qué maravilla que se le pueda ocurrir a los chicos de Redmond.

Sea como sea, el cambio será obligatoriamente importante (en 2 años esta gente puede hacer mucho!) y Microsoft no entrará en este mercado este año y eso permitirá que HP pueda presentar su HP Service Manager sin competencia adicional.

19 de octubre de 2007

8 de octubre de 2007

El día que HP perdió la pelota

Lo había dicho Jorge Fernandez en su blog, que Business Objects estaba en venta. Y para mí, la mejor opción era que HP hiciera una jugada maestra colocándose en el sector del Business Intelligence, dando más ancho de banda a la posición de NeoView y además nutriera toda la parte de HP Software con unas herramientas de reporting, dashboard y cuadros de mando "de película".

Pero hoy BO ha publicado la noticia: el comprador es SAP (¡Quién lo iba a decir!).

sap_announcement

La verdad es que los chicos de Palo Alto cada día te sorprenden más.

5 de octubre de 2007

El Motor de Búsqueda Personalizado

Una de las grandes novedades que ha presentado Google últimamente ha sido la posibilidad de crear motores de búsqueda personalizados (CSE o Custom Search Engine). Utilizando este nuevo juguete, te puedes montar un motor de búsqueda tan potente como Google, pero focalizado a las áreas de interés que tú quieras.

Desde luego, esto a primera vista no parece demasiado interesante, pero a la que le des dos vueltas, verás lo útil que puede llegar a ser.

Para empezar, he montado un CSE orientado a los contenidos que se ven habitualmente en este site: ITIL, ITSM, IT Governance, y otros conceptos similares, de tal forma que si haces una búsqueda de Proyecto de Implantación en Google estándard, obtienes algo así como esto:

google_std

mientras que si buscas en la barra de búsquedas de Gobierno de las TIC (justo encima del primer post), los resultados son estos otros:

google_cse

Como puedes ver, los resultados están totalmente orientados a los contenidos habituales que te encuentras por aquí, lo que ahorra bastantes páginas de resultados poco afinados en una búsqueda habitual en Google.

La segunda característica interesante de estas CSE, es que se puede refinar la búsqueda según una serie de parámetros preestablecidos, que se encuentra justo en la parte superior de los resultados. De esta forma, si clickamos sobre el enlace de "Presentaciones" el resultado es aún más concreto:

google_refine 

de tal forma que todos los resultados obtenidos son presentaciones en formato PPT.

¿Qué más se puede pedir?

Pues sólamente que no tengas que venir hasta Gobierno de las TIC a buscar la barra de búsquedas, sino que la puedas integrar directamente en tu navegador.

Para poder atender a esta necesidad, tendrás que disponer de un navegador que soporte OpenSearch, como pueden ser FireFox 2.X o Internet Explorer 7 y utilizar el enlace que encontrarás justo en la barra de búsqueda, o aquí mismo
 

Al pulsar ese icono, se te preguntará si deseas agregar a GobTIC como motor de búsqueda y, en el momento de aceptar, ya podrás comenzar a utilizar las búsquedas directamente desde tu explorador, ya sea bajo Internet Explorer

IE7

o ya sea bajo Firefox 2.X

ffox

Por último, se pueden incorporar personas al equipo que se encarga de agregar entradas al buscador o de crear nuevos criterios de filtrado. Si quieres participar, sólo tienes que irte a la página principal del motor de búsquedas GobTIC e inscribirte.

 

24 de julio de 2007

HP y la CMDB Federada

Recuerdo que hace poco más de un año comencé este blog hablando de lo dificil que iba a ser ver implementado de una forma real y efectiva el concepto de FCMDB . Poco más tarde, escribía otro artículo buscando la base de estandarización que haría falta, y mencionaba como estandard emergente e interesante el DCML y me llamaba la atención que HP no estuviese en la lista de participantes del consorcio que estaba desarrollando este estándard.

Pasó un tiempo y HP compró Peregrine y entonces todos los rumores apuntaban a que la CMDB de HP sería la de Peregrine, porque el AssetCenter parecía ser "el producto estrella", pero entonces HP compró Mercury y los planes cambiaron: en el último HP Technology Briefing al que pude asistir, hace apenas un mes, se hicieron unas cuantas presentaciones muy interesantes sobre la uCMDB (Universal CMDB), producto que HP coloca en el centro de su estrategia de integración entre los diferentes "centers" y que implementa realmente el concepto de CMDB Federada (confieso que fui muy escéptico ante todo aquel que desde HP me hablaba de federación hasta que fui a Berlin y lo vi).

Pero en esas presentaciones pregunté por los estándares utilizados para modelar la CMDB y la respuesta fueron algunas siglas propietarias, el presentador no conocía ni de la existencia del DCML ni (¡sorprendentemente!) de la iniciativa conjunta entre los grandes fabricantes que se inició el año pasado (ver este post y relacionados).

Pero en realidad todo se estaba cocinando... salía aroma a FCMDB de la cocina de HP, pero los pinches no sabían qué estaba preparando el chef.

Hoy se ha dado la noticia y es fresquita: HP ha comprado OpsWare, uno de los esponsores de DCML, fabricantes de un producto llamado OpsWare OMDB (Operational Management Database) y líderes indiscutibles (junto a nLayers) en la automatización/descubrimiento de CPDs y BackEnd

Billboard-HP

Vamos, que HP está decidida a posicionarse en el mundo del descubrimiento (tienen ya 3 o 4 productos), de la automatización del cambio (perdón! de los cambios ;-) (para esto tienen tambien al menos 2 o 3) y de la CMDB (otros 3 o 4 productos en el portfolio).

De todas formas, siempre hay que escuchar todas las versiones de la historia, y aqui queda un enlace al artículo "HP buys my company Opsware for more than $1.6 billion in cash" en el blog de Marc Andreesen, uno de los fundadores de OpsWare y poseedor de un más que interesante curriculum.

Como yo decía, hace 1 año faltaban 4 ó 5 para ver una FCMDB en marcha y madura... ahora sólo faltan 3 ó 4.

26 de mayo de 2007

El misterio del "1.1.1 Deleted"

Como pueden haber notado, hace días que no escribo. Desde que me inscribí en el curso que te habilita para pasar el examen del ITIL Service Manager no he hecho otra cosa que estudiar, hacer deberes (como en los viejos tiempos del cole) y sacar trabajo atrasado (porque la gracia del curso son 80 horas de dedicación, además de lo que necesites para estudiar, y claro... ¡los clientes no esperan!)

Este examen requiere que hagas un esfuerzo especial: no sólo tienes que leerte y entender bien los libros Service Support y Service Delivery, sino que además tienes que estudiartelos y cuando te estudias bien en profundidad una cosa empiezas a encontrar detalles que hasta ahora habían pasado desapercibidos.

 

Uno de estos detalles es lo terriblemente mal estructurados que están los libros, pero esto es otra guerra que comentaremos en otra ocasión, como decía Michael Ende. El detalle que nos ocupa hoy es "El misterio del 1.1.1 Deleted".

Para aquellos que no dispongan del libro Service Support en castellano, pueden descargarse "el trailer" del sitio del itSMF España, y si nos vamos a la página 1 del libro, veremos que hay un capítulo

1.1 La Biblioteca de Infraestructuras de TI

y el primer subcapítulo es el misterioso

1.1.1 Deleted

¿Que es esto?

Recuerdo que cuando participé en la revisión esto no estaba (o al menos no recuerdo haberlo visto) y cuando vi por primera vez el extracto envié un mail diciendo que no estaba correcto (así como otras correcciones que pude ver en la muestra): las otras correcciones se arreglaron, pero el punto "1.1.1 Deleted" se mantuvo.

No le di más importancia, hasta que he tenido que estudiar los libros y a veces no entendía bien la traducción al castellano o quería estar bien seguro de que lo que estaba traducido era el espíritu original de lo que había en los libros ingleses y... me volvió a asaltar el "1.1.1 Deleted" maldito.

Pero esta vez tenía los dos libros, así que me fui al inglés a ver qué ponía y esto es lo que han eliminado:

1.1.1 Public domain framework

From the beginning, ITIL has been publicly available. This means that any organisation can use the framework described by the CCTA in its numerous books. Because of this, the IT Infrastructure Library guidance has been used by such a disparate range of organisations, local and central government, energy, public utilities, retail, finance, and manufacturing. Very large organisations, very small organisations and everything in between have implemented ITIL processes.

ITIL no es más un marco de trabajo de dominio público. De hecho los cambios simplemente en la forma de comercializar ITIL a partir de la versión 3 y el proyecto CAR han demostrado que ahora ITIL es una poderosa fábrica de dinero para la OGC, y no ya algo "públicamente disponible".

Para mi, esto es un síntoma de algo que todavía tiene que venir.

PS:: ¿Alguien se ha comprado últimamente el libro en inglés del Service Support?

Si es así, en las últimas impresiones ¿Cómo aparece el punto 1.1.1 ?

5 de mayo de 2007

HP y la compra de Mercury

Bien saben las personas que leen este blog a menudo que no suelo entrar a hablar de productos ni de fabricantes, pero esta vez quiero explicar un poco mis percepciones sobre la ampliación en el portafolio de productos que ha hecho HP tras la compra de Mercury y su incorporación ya definitiva al menos en España.

Esta semana he tenido la oportunidad de asistir al HP Business Perspectives de este año; han sido tres días intensos de presentaciones, contactos, intercambio de cromos y alguna que otra copa. Durante estas sesiones he oido hablar de muchos productos, bundles y suites diferentes, pero los que realmente me han llamado la atención por la coherencia y alineación con mi actividad profesional de su discurso han sido los chicos de Mercury (bueno, los chicos de Mercury que ahora firman como HP, ¡claro!).

Estuve en una primera presentación en la que daban una visión "a vista de pájaro" de la solución de Project and Portfolio Management, donde se hizo una primera charla sobre IT Governance, pero al venir de un fabricante de software había cosas realmente curiosas más que nada por el hecho de "materializar" o "convertir en algo práctico" los conceptos teóricos (o académicos, como los llamaba el ponente) de Gobierno de las TIC.

Durante toda la charla y si lo unimos con la charla sobre los productos de testeo de software y pruebas de carga, se oyeron conceptos de COBIT, de CMMI, de Six Sigma y de ITIL, pero sin nombrar ninguno de los estándares y desde un punto de vista eminentemente práctico... me encantó, porque visto de esa manera no asustan a la audiencia con las toneladas de siglas que estamos acostumbrados a usar en este sector.

Después de esta introducción, planteaban un modelo tanto para la definición de las espectativas como para la presentación de resultados muy alineado con el modelo 3x3 presentado por Jan Van Bonn en las charlas que dió en el itSMF y que centraba el interés en juntar el concepto de "Alineación de las TIC con el Negocio" con la definición de objetivos estratégicos de la compañía y de las TIC (al más puro estilo COBIT) y con la ejecución o materialización de estos objetivos a través de un ciclo de Gestión de la Demanda y del ciclo de vida del Servicio con aroma a ITIL V.3

Luego hubo una poca de presentación de los productos y posicionamiento de los mismos en los cuadrantes del modelo anterior y creo que nos dejaron a todos con la ilusión y las ganas de ver mejor estos nuevos productos y comenzar a pensar en cómo se pueden aplicar para alegrarles la vida a nuestros clientes. Sinceramente, mientras los iba viendo iba pensando "ah! cómo le gustaría esto a XXX" o "eps! Esto es justo lo que necesita YYY".

Definitivamente, me parece que la compra de Mercury, si la consiguen integrar adecuadamente y conseguir un canal formado, serio y capaz de trasmitir el mensaje y no vender únicamente licencias sin trasfondo de conocimiento, ha sido la mejor decisión que ha tomado HP Software en los últimos años.

PS: Una de las cosas que me llamaron mucho la atención fue que cuando el ponente puso la slide con las definiciones "académicas" de IT Governance, las fuentes citadas fueron Gartner y Forrester, no ISACA ni ITGI.

¿Casualidad, o Marketing?

28 de marzo de 2007

Criterios de Selección de Herramientas (II)

Para continuar con la lista de criterios que nos deben guiar en la elección de una u otra herramienta para la implantación de procesos ITIL, vamos a centrarnos en algunos aspectos funcionales que debemos tener en cuenta.

Criterio Nº 6: Habilidades de reporting

Si miramos los diagramas que aparecen en los libros Service Support y Service Delivery como resumen del modelo, veremos que todos y cada uno de los procesos planteados genera una gran cantidad de informes, tanto de tipo operativo como de seguimiento y control y para la toma de decisiones. La herramienta que escojamos debe disponer de unas excelentes capacidades de reporting, de un entorno abierto que nos permita realizar el reporting desde nuestras plataformas o bien debe contar con productos y/o servicios de terceros que nos permitan obtener los informes que necesitemos ahora y en el futuro.

Criterio Nº 7: Procesos Soportados

Parece, una vez más, obvio ¿No? Bueno, pues resulta que la práctica totalidad de las herramientas que hay en el mercado sólo soportan los procesos de Service Support, y los de Service Delivery se quedan "en el aire".  De todas formas, no te dejes encandilar.. ¿Qué procesos vás a poner en marcha? ¿Qué procesos necesitas ahora y en los próximos 3 años? El resto es papel mojado.

Criterio Nº 8: Roadmap

Exige de tu fabricante el roadmap de la aplicación. Exige conocer cuál es el plan de presentación de versiones, cada cuánto se publican actualizaciones, parches, servicepacks y cosas por el estilo y exige conocer cuáles son los planes que tiene reservados el fabricante para el producto que quieres comprar. ¿Por que? Porque un producto sin roadmap está muerto, y tu quieres esto por muchos años.

Criterio Nº 9: Flexibilidad VS. Plazos de Implantación

Las herramientas más flexibles, adaptables y parametrizables son las que a la larga acaban adaptándose mejor a los requerimientos del proceso; pero esto es una trampa oculta terrible: cuanto más flexible, más le pedimos a la parametrización, más "adaptamos la herramienta a nuestras necesidades" y cada vez se hace más y más complicado de mantener.

Si tienes plazos ajustados de puesta en marcha, es mejor una herramienta parametrizable, pero no tanto. Si tienes tiempo y dinero, entonces la opción puede ser una de estas herramientas que yo llamo "un compilador de lujo".

Criterio Nº 10: Motor de búsqueda

Evidentemente, el documentar cada uno de los pasos que se dan para resolver una incidencia, investigar un problema o gestionar un cambio proporciona un cierto ROI si luego lo podemos explotar. Necesitamos poder "bucear" entre los miles de incidencias, problemas, cambios, CIs...

Bueno, hasta aquí esta pequeña introducción al respecto de los criterios de selección de herramientas. Durante el verano pasado inicié un proyecto para generar una hoja de toma y ponderación de requerimientos para una herramienta, pero dado el escaso éxito que tuvo al final ha quedado un poco abandonado.

Este proyecto se llamó MEHGEST , y tiene su propio blog con todas las explicaciones al respecto de los criterios que llegué a documentar.

Si alguien quiere participar en este proyecto, ahi queda la invitación.

20 de marzo de 2007

Criterios de Selección de Herramientas (I)

En el post anterior hablábamos sobre las principales herramientas del mercado, pero para poder escoger correctamente la herramienta que mejor se ajuste a nuestras necesidades debemos tener en cuenta toda una serie de factores que nos influenciarán en nuestra decisión.

Espero poder explicar algunos de estos criterios, de tal forma que cuando tengas que escoger entre el fabricante X o el fabricante Y y la herramienta A o la B no lo hagas porque el vendedor te ha invitado a comer o porque aquella es más bonita.

Criterio Nº 1: La herramienta debe cumplir al menos un 80% de los requisitos técnicos y funcionales que nos hayamos planteado

Parece obvio, ¿no? pero no lo es tanto. Detrás de esta afirmación está el concepto de la RFP y de un trabajo previo a la selección de la herramienta que debe establecer qué queremos hacer con ella, para qué la queremos usar y qué requerimientos le vamos a hacer a los diferentes fabricantes para saber si su herramienta se corresponde o no con lo que nosotros queremos. Muy habitualmente me he encontrado con que este trabajo previo no se había hecho y por lo tanto la aproximación a los proveedores era "¿Qué se puede hacer con tu herramienta?" en lugar de "¿Tu herramienta hace esto que yo necesito?".

Cuando la aproximación a un proveedor es del primer tipo, le estamos dando el terreno abonado para que nos vendan la moto más grande del universo, porque "Con mi herramienta se puede hacer tooooodo lo que tu quieras".

Criterio Nº 2: Debe cumplir con todos los requisitos obligatorios.

Bueno, aquí nos encontramos con una segunda derivada de la aproximación por RFP: Además de haber definido claramente qué es lo que espero de la herramienta, además debo haber definido exactamente cuáles de estos requerimientos son obligatorios (indispensables) y cuáles no lo son.

Criterio Nº 3: Nivel de customización necesario.

Cualquiera que diga que su herramienta "se instala y la empiezas a usar directamente" no ha entendido claramente tu problemática. Evidentemente, la herramienta que hayas escogido traerá una configuración out-of-the-box y posiblemente sea la adecuada para realizar un piloto, pero sería cosa de magia que se adaptara perfectamente a tus necesidades... a las tuyas, a las del cliente de al lado y a las del tío de Nueva Zelanda.

Las herramientas hay que customizarlas. Todas. O si no, es que no se pueden customizar.

Criterio Nº 4: Debe entrar en presupuesto

Lógico, ¿no? Pero no debemos olvidar todas esas "partidas ocultas" que luego nos encontraremos: servicios de instalacion, de parametrizacion, de mantenimiento evolutivo, de soporte, de actualizaciones, contratos de mantenimiento, licencias, escalado de licencias, etc.

Criterio Nº 5: Seguridad e Integridad

En esta herramienta vamos a mantener mucha información y mucha de ella es sensible (sobre todo si vamos a implementar, por ejemplo, procesos de Gestión Financiera). Debemos poder garantizar la confidencialidad de esta información.

¿Estás en un entorno multiproveedor? Piensa en las políticas de seguridad que envuelven todo esto y piensa en cómo se van a aplicar sobre este nuevo sistema.

Por otra parte, las relaciones entre todos los elementos se iran cruzando y complicando con el tiempo: debemos poder garantizar la integridad de todos los datos, incluyendo la integridad referencial a lo largo del tiempo.

17 de marzo de 2007

Herramientas

Desde que comencé a escribir en este blog hace ya casi un año, me puse el firme objetivo de ser lo más agnóstico posible en lo referente a tecnología, intentando no dar ni una sola opinión sobre productos para que este blog no se convirtiera en una actividad de márketing ni de mi empresa ni de ningún fabricante.

Pero claro, mantenerse al margen es bien difícil porque la Tecnología es parte importante de mi vida, de las TIC y uno de los famosos "tres pilares de ITIL ", ¿no?

La semana pasada me llegó un mail de Juan Martínez en el que me planteaba la siguiente consulta:

Llevo poco tiempo dentro de este mundo y ando investigando actualmente herramientas que den soporte a ITIL en concreto al proceso de Gestion de incidencias y Service Desk para realizar una comparativa de que oferece cada una. Actualmente solo conozco y he encontrado informacion sobre Remedy ITSM 7.0. Quiza sea un poco descarado por pedirte ayuda pero como te comento ando un poco perdido.¿Podrias echarme una mano?

Podría escribir un post gigantesco contandote las maravillas de algunas de las herramientas que conozco, pero en lugar de eso lo que vamos a hacer es darte una lista de las que más me he encontrado "en el campo" y, sobre todo, una lista de las cosas importantes que se deben tener en cuenta a la hora de escoger la herramienta.

Herramientas Más Comunes

Remedy : Una de las más extendidas entre los grandes clientes, ha tenido una historia curiosa, ya que es una de esas herramientas que han ido pasando de mano en mano. Extremadamente flexible, yo siempre la he definido como "un compilador de lujo para ITSM" ya que puedes hacer con ella prácticamente lo que quieras.

HP OV Service Desk: Una de las más cómodas herramientas que ha desarrollado HP, pero que ahora ha caido en desgracia por la entrada en escena de Service Center. Muy fácil de parametrizar y muy potente, un verdadero lujo.

Service Center: Descrito por un colega como "una caja de tornillos", es también una de esas herramientas extremadamente flexibles que te permitirán hacer prácticamente lo que quieras. Ahora es propiedad de HP.

Service Desk Plus: Bueno, en realidad este producto juega en una liga totalmente diferente a los anteriores, pero lo he visto en varias empresas. Simple, barato y poco adaptable, cubre las necesidades básicas de un ServiceDesk y puede servir como vía de entrada.

System Center Service Desk: Esta aún no ha salido, pero estoy seguro de que dará mucho de que hablar porque Microsoft si algo sabe hacer bien es ruido y publicidad. Por lo  pronto las presentaciones que he visto son interesantes.

Bueno, estas son las que yo me he encontrado más habitualmente en el sector en el que me muevo profesionalmente, pero seguro que otros han visto/usado/evaluado muchas más.

Puedes encontrar un listado de herramientas en estas dos ubicaciones:

Pink Verify, donde la gente de Pink Elephant pasa unos checklists públicos a los productos y establecen el nivel de adecuación (no certificación ni compatibilidad) a ITIL de cada uno.

ITSM Portal Tool Selector, donde podrás encontrar multitud de herramientas y sus características.

Siguiente entrega: criterios para seleccionar herramientas.

9 de agosto de 2006

MEHGEST cobra vida propia

A la vista de la situación en que la documentación de MEHGEST iba creciendo y creciendo y me iba copando el blog de Gobierno TIC, he pensado que lo mejor sería que MEHGEST tuviera su propio espacio y viviera una vida independiente pero seguida de cerca.

Es por esta razón hoy ha celebrado la inauguración de su nuevo entorno, y a partir de ahora, toda la información relativa a MEHGEST la podrán encontrar en http://mehgest.blogspot.com

¡¡Buena Suerte y Larga Vida!!

4 de agosto de 2006

El nacimiento de MEHGEST



A la vuelta de vacaciones habrá que plantearse nuevos retos, nuevos proyectos y posiblemente nuevos presupuestos para el siguiente año. Algunos de estos nuevos retos incluirán el pensar seriamente en escoger una herramienta adecuada para implantar una buena gestión de servicios, y uno nunca sabe por dónde empezar; así que si el tiempo lo permite empezaremos con una serie de consejos para tener al menos unos criterios válidos para escoger una de las muchas herramientas que propone el mercado (o decidirse a desarrollar una herramienta propia que se adapte a lo que queremos).

Para poder escribir este post con “cara y ojos”, primero pensé que debía hacer un índice de todos aquellos requisitos o características que se deben mirar en una herramienta, listarlos y luego ir desarrollando cada uno de los temas en sucesivos posts, pero a medida que iba haciendo la lista se fue haciendo más y más grande, así que me emocioné, cambié del Word al Excel, y casi sin darme cuenta me he montado la primera versión de la Matriz de Evaluación de Herramientas de Gestión de Servicios TIC (MEHGEST).

El trabajo que queda por hacer ahora se “reduce” a puntos como pueden ser:

  • Explicar detalladamente qué significa cada uno de los criterios de evaluación que aparecen.
  • Ampliar la herramienta con los criterios generales que cada uno de los lectores o usuarios propongan
  • Ampliar la herramienta con una pestaña por cada proceso (con criterios específicos para el proceso)

Por lo pronto, MEHGEST queda a disposición del público bajo una licencia Common Rights de tal forma que puedes usarla y modificarla siempre y cuando compartas las modificaciones y cites la fuente.

Espero comentarios sobre su uso y cualquier tipo de sugerencia al respecto, pero has de saber que no soy ningún experto en Excel y no implementaré grandes virguerias porque no se me da.