Asociaciones Profesionales

Marlon Molina, el ser humano que usa las TIC, escribía hoy un post provocador al respecto de cómo las asociaciones profesionales están dando un giro en sus propuestas de valor para los asociados justamente debido a que se pierden miembros y se pierden patrocinios.

Este post es mi respuesta a esa entrada de Marlon, así que si te interesa el tema de las asociaciones profesionales y quieres seguir leyendo esto, lo primero que debes hacer es leer De asociaciones profesionales a empresas low-cost. Aquí te espero.

¿Ya estás de vuelta?  Bueno, pues aquí está mi respuesta (que la habrás visto también como comentarios en el blog de Marlon, pero aquí es más cómoda de leer ;-)

En general, el sector ITSM me conoce por mi pertenencia a itSMF, pero también son miembro de ATI, ISACA, FIB Alumni y posiblemente alguna otra, así que tengo algo de experiencia en asociacionismo.

En mi opinión, es importante el planteamiento de si una asociación vive "DE" sus miembros o vive "PARA" sus miembros... y por supuesto, si vive "POR" sus miembros.

Así, hay asociaciones que viven PARA sus miembros: se financian por mecanismos alternativos y toda la actividad está orientada a aportarle valor (sea eso lo que sea, dentro de los principios de la asociación) a sus miembros. De esta forma, la asociación busca canales de financiación “alternativos” como pueda ser la venta de libros o las subvenciones (ambos ejemplos sacados literalmente de tu post, sin entrar a discutir si son o no adecuados).

Hay otras asociaciones que viven DE sus miembros, y por lo tanto viven de lo que sus miembros les pagan en concepto de membresía. En este caso, las asociaciones se convierten rápidamente en “clubs privados” porque es preciso aportar un valor acorde a la membresía que se paga y sobre todo es preciso diferenciar al “socio” del “no socio”, que para eso paga.

Dejaremos el tema de las que viven POR sus miembros, porque eso nos lleva a la discusión de los tipos de miembros, tipologías de actividades, etc… que no es lo que nos ocupa en este momento.

Volviendo al asunto de las asociaciones que viven DE sus miembros, aquí hay que abrir el abanico un poco: ¿Qué miembros tienes? ¿Qué tipos de miembros tienes?

Por ejemplo, asociaciones como ISACA tienen membresías individuales: una empresa no es socia de ISACA, lo son los profesionales que trabajan en ella. Otras asociaciones como ATI permiten miembros individuales y “socios institucionales” y finalmente hay otras que viven de… viven de… hummm, como decirlo? Si, de sus miembros, pero de una forma especial: viven de “patrocinadores”. Estas son las asociaciones que se financian gracias a que hay compañías interesadas en llegar con su mensaje a esa gran comunidad de miembros y “venden” el acceso a la comunidad.

En este último tipo de asociaciones la cosa es complicada porque hay que mantener un equilibrio entre conseguir una gran cantidad de miembros gracias a que les ofreces algo interesante y conseguir estos patrocinios gracias a que tienes un conjunto de miembros atractivos.

Sea como sea, llegamos a la conclusión de que la esencia de una asociación son sus miembros… sin miembros no hay nada, independientemente de cómo te financies.

Y a los miembros hay que darles algo que les interese: contenidos, charlas, videos, libros, foros, discusiones, congresos, formación… aquello que aporte valor al socio y esté dentro del ámbito de actuación de la asociación (¿te acuerdas? la misión y visión de la asociación… el para qué estamos aquí y qué le aportamos a la Sociedad). Pero debes tener claro cómo aportas valor al socio, cómo te financias, cuáles son tus principios y qué combinaciones de todo esto anterior no son buenas.

Por ejemplo:  aportar valor al socio dando formación y esperar a financiarte mediante patrocinios de empresas de formación es incompatible.

Por ejemplo: Aportar valor al socio dando formación y financiarte cobrando por esa formación con descuento para el socio y pagarle al profesor, que a su vez es un socio… puede funcionar (pero no esperes nada de las empresas de formación).

Por ejemplo: Aportar valor al socio generando contenidos y manteniendo foros de discusión animados y financiarte mediante patrocinios puede funcionar, mientras no pierdas miembros. En este caso, la moneda de cambio es la cantidad de miembros, por lo que cuantos más, mejor: no cobres membresía y vive de tus patrocinios.

En fin… que hay diferentes modelos que se estructuran sobre el triangulo CLIENTE/SERVICIO/ORGANIZACION que tantas veces hemos visto como modelo de alineación…

Las grandes preguntas que debe hacerse TODA ASOCIACION en este sentido son:

1. ¿Qué socios quiero tener?
2. ¿Cómo le voy a aportar valor?
3. ¿Como me voy a financiar?

Y luego ser consecuente y no improvisar sobre esto.

¿Qué opinas? Como socio, como miembro activo, como patrocinador… deja tus comentarios en el blog de Marlon y allí seguimos con la discusión.

El servicio TI

Hace unos cuantos días que en un foro del underground ITSM se está discutiendo al respecto de la definición del concepto de Servicio TI. Parece mentira que a estas alturas tengamos estas discusiones, pero la verdad es que eso de “un medio de  darle valor al cliente, bla bla bla” lo ha hecho un poco difícil, al tiempo que “un sistema de información que soporta un proceso de negocio” era demasiado simple.

La discusión viene de lejos… si bien en este caso todo empezó por esta entrada de blog que escribió Aale Ross ( http://pohjoisviitta.fi/itsm-from-the-top-of-the-world/improving-itil-3-forget-the-service-lifecycle/ ) también han salido a relucir otras discusiones como esta ( http://www.itskeptic.org/what-service) o esta otra mucho más reciente (http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=276434337&gid=68677&goback=.nmp_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1#commentID_null )

Esto no hace más que demostrar que la comunidad de Gestión de Servicios TI no se acaba de poner de acuerdo al respecto de lo que es un servicio TI.

Ya me iba a casa, incluso tenía el PC apagado! pero de repente se me encendió una idea que no quería dejar de compartir aquí. ¿Y si lo miramos desde otro punto de vista?

En castellano la palabra “servicio” tiene otras acepciones… ¿No? Pero no es a eso a lo que yo me refiero. ¿Quien puso el WC ahí? ¿Quién lo mantiene?

Si pensamos como usuarios, la definición del servicio está clara… y las expectativas también: espero que funcione, que desagüe, que no huela mal, que esté limpio… características del servicio.

Si le preguntamos al departamento de mantenimiento de edificios qué servicios ofrece al respecto de los lavabos, seguramente me dirá que “limpieza”, “desinfección”, “provisión de fungibles”… es decir nada de lo que yo como usuario entiendo como servicio.

Lo que ellos hacen son actividades orientadas a asegurar que el WC está y se comporta como yo (usuario) espero: lo limpian, lo desinfectan, lo mantienen en correcto funcionamiento… se preocupan de que el WC entregue UTILIDAD y GARANTIA, pero es servicio NO ES EN SI MISMO el trabajo de asegurar la utilidad y la garantía.

En Informática nos pasa lo mismo: nos empeñamos en decir que nuestros servicios son “el mantenimiento de aplicaciones” o “la administración de sistemas”, cuando en realidad eso son actividades que hacemos para asegurar que los sistemas de información entregan utilidad y garantía.

Siguiendo por esta línea, me quedo con la definición de servicio IT que llevo utilizando mucho tiempo: un sistema de información gestionado (osea, con todas esas actividades realizadas por personas a su alrededor orientadas a asegurar que se entrega la utilidad y la garantía).

Un sistema de información, no una aplicación.

Con visión de usuario. Outside-In.

Standard, Case y los procesos estructurados

En Diciembre del 2012 Rob England presentó en el congreso TFT12 una aproximación bastante novedosa a cómo enfocamos los procesos en ITSM. Esta nueva aproximación recibió el nombre de Plus! Standard+Case a falta de encontrar un nombre mejor que transmitiera el significado y además fuera lo suficientemente “pegadizo” para convertirse en el hit del verano ITSM.

Tuvo buena acogida y en Mayo de 2013 se presentaba el libro en el que Rob describía con pelos y señales esta nueva aproximación Plus! the Standard+case Approach: See Service Response in a New Light ;  luego, en Junio de 2013 durante el congreso TFT13 Rob presentó de nuevo su visión (esta vez con mayor profundidad y mejor estructura).

El modelo S+C plantea una realidad en la que podemos encontrar dos tipos complementarios de procesos: los que tienen una forma completamente estructurada y los que no.

Aquellos que tienen una forma estructurada son los procesos que cumplen a rajatabla la definición que encontramos en todos los libros:

 

un proceso es una serie estructurada de acciones que buscan cumplir un objetivo concreto, con [ blah blah blah …]

 

En fin, si eres lector de este blog seguro que ya te suena esta definición… Los procesos de este tipo se predefinen, son una serie estructurada de acciones y por lo tanto las actividades tienen estructura, tienen un orden predefinido.

El ejemplo ITSM que mejor encaja en esta definición es un cambio estándar. Según la definición que podemos encontrar en los libros de ITIL®

(ITIL Service Transition) A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction – for example, a password reset or provision of standard equipment to a new employee. Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request. See also change model.

Para este tipo de proceso podemos predefinir las actividades, los recursos necesarios, los niveles de aprobación, el presupuesto y el tiempo de ejecución, porque son completamente predecibles. Este es el tipo de proceso que encaja a la perfección con los conceptos de industrialización, reducción de la variación y con la aplicación de métodos industriales como Six Sigma.

Así, si utilizamos el ejemplo de la provisión de un equipo estándar para un nuevo empleado nos podemos hacer a la idea de que podemos comprometernos en plazos y en costes, podemos hacer una estimación de los recursos y perfiles que necesitaremos y podemos tener predefinidos los procedimientos a utilizar para cada tipo de equipo estándar o perfil de empleado a satisfacer.

De hecho, incluso podemos plantearnos analizar el tiempo medio de entrega, pensar en la desviación estándar de este tiempo de entrega y utilizar mecanismos como el VSM o DMAIC para reducir esta desviación estándar aportando estabilidad al proceso de entrega.

…y por el otro lado están los procesos que no son tan estructurados, aquellos en los que no podemos definir las actividades con anterioridad porque son un tipo de proceso en el que cada actividad proporciona un conjunto de información que influye en cuál será la siguiente actividad de que ejecute en el proceso. Así, un médico avanza en el diagnóstico de un paciente a medida que va obteniendo resultados de las diferentes pruebas que realiza y decide la siguiente prueba en función de su conocimiento y del resultado de las pruebas anteriores. Igualmente, un investigador avanza en la resolución de un crimen realizando pruebas e indagaciones que alimentan el conjunto de información de la que dispone hasta llegar a una conclusión… pero al iniciar el caso, ni el médico ni el investigador sabían a ciencia cierta cuál era el camino que seguirían.

En el mundo de la gestión de procesos de negocio (BPM) a este tipo de situación se le denomina Case Management y uno de sus aspectos fundamentales es que no podemos predeterminar el conjunto de actividades que se llevarán a cabo y por lo tanto no podemos predecir con exactitud los recursos, perfiles, plazos o costes en los que incurriremos. Esta naturaleza impredecible de los casos hace que no podamos (o no debamos) utilizar mecanismos industriales como Lean o Six Sigma para su control precisamente porque no están estandarizados. De hecho, Taiichi Ohno decía

 

When there is no standard, there is no Kaizen

 

 

Entonces, para gestionar adecuadamente el mundo de los casos, lo que necesitamos son políticas, orientación para que el profesional que está llevando adelante un caso sepa cuánto tiempo, recursos, presupuesto, perfiles puede utilizar para avanzar en su ejecución. Pongámonos en situación imaginando que tenemos una de esas incidencias complicadas que no sabemos cómo resolver (es decir, con la información de la que disponemos en el momento cero más nuestro conocimiento, no sabemos hacia dónde ir). En esta situación no podemos aspirar a que los tiempos objetivo de resolución se cumplan, o que el coste por incidencia sea inferior a XX€. En realidad, lo que ocurrirá es que se irán realizando pruebas o consultando con otras fuentes de información más elaboradas (escalado a N2 o N3) hasta que lleguemos a una conclusión. Bajo este paradigma, ¿en qué momento debemos parar?

Podríamos derivar todo el hilo de la historia hacia aspectos teóricos de si la gestión de incidencias o la gestión de problemas, que si los workarounds y los SLA… pero lo cierto es que en realidad lo que pasa es que no tenemos ni pajotera idea de cuándo podremos tener la cosa resuelta, de la misma manera en que cuando se presenta un caso difícil un médico no sabe cuándo tendrá el diagnóstico… hasta que no dé con el bicho, no habrá diagnóstico (recuerdo a mis padres haciendo biotipificaciones y antibiogramas como pieza fundamental del diagnóstico y cura de un paciente) y por eso en este tipo de casos nos debemos regir por políticas que establezcan qué tipo y cantidad de recursos está la compañía dispuesta a invertir/utilizar para la resolución del caso.

Desde el momento en que Rob comenzó a hablar de esto supe que tendría éxito. No está diciendo nada que no supiéramos anteriormente con respecto a procesos estructurados o no estructurados, pero lo que sí que es importante y tiene que cambiar cómo nos enfrentamos a la realidad del día a día de la Gestión de Servicios es que, siendo conscientes de que existen estos dos mundos, debemos aplicar diferentes métodos para su gestión:

• Podemos trabajar con SLAs de tiempo y predicciones de coste en el mundo Standard y debemos trabajar con políticas y marcos de referencia que limiten el numero de recursos a invertir en el mundo Case.
• Los perfiles a asignar en el mundo Standard son totalmente diferentes a los que debemos emplear en el mundo Case, y de hecho cada persona puede sentirse más o menos cómoda trabajando en el mundo Standard o en el mundo Case en función de sus aptitudes o su carácter.
• Las herramientas a utilizar son diferentes, o al menos deben poder contemplar realidades standard (de flujo predefinido)  y realidades case (de flujo abierto, bayesiano)
• Los indicadores son radicalmente diferentes: cuando buscaremos medias y desviaciones estándar en el mundo Standard, buscaremos ratios de utilización de recursos y grados de documentación (para facilitar “la estandarización del caso”)

La clave de Standard+Case no se encuentra en la definición o no de procesos estructurados… eso ya lo sabíamos.

Lo esencial que nos cuenta este libro es que debemos tener una serie de patrones que nos ayuden a movernos en los dos entornos.

¿Has pensado ya en cómo articularás tu próximo contrato de outsourcing?

¿Qué tal se te da el multitasking?

Ya sabemos que multitaskear es bastante malo para la salud mental, para tu rendimiento y para la calidad de los resultados del trabajo… pero también sabemos que hay un mito alrededor de que los hombres no sabemos hacer más de una cosa a la vez…

Quieres comprobar si el mito es cierto? Aquí te dejo un experimento que te demostrará qué tal se te da esto, cómo te comparas con la media y, sobre todo, que desvelará el secreto de si el género afecta o no a la capacidad de multitaskear…

Created by http://Open-Site.org

El punto débil de DevOps

Hace algún tiempo leí el libro The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, una novela muy inspiradora al respecto del uso de las técnicas Lean en el mundo de las operaciones IT y su fuerte relación con el mundo del desarrollo y DevOps. Como novela es entretenida, explica y ejemplifica los conceptos fundamentales y es un cuento de hadas, donde todo va de acuerdo a lo que el guionista ha pensado y desemboca en un fantástico final feliz. Desde luego, no creo que sea necesario recordarles a los lectores que lo que pasa en esos mundos imaginarios no siempre se parece a la realidad y al contrario que en el mundo de Fantasía, a este otro lado a veces las cosas no son tan maravillosas. (Nadie piensa que los lobos hablan después de leer Caperucita, verdad??)

En un momento del libro, el protagonista está reflexionando al respecto de cómo acelerar el ritmo de pasos a producción en el equipo de desarrollo (se han puesto el objetivo de conseguir diez –si, 10- despliegues al día) justamente para seguir los consejos que daba el equipo de Flickr en su conferencia de 2009. Parte de esa reflexión le lleva a decir la frase

 

Until code is in production, no value is actually beign generated, because it is merely WIP stuck in the system

o sea… hasta que el código no está en producción no se está generando realmente valor porque es únicamente WIP atascado en el sistema

Claro, el paralelismo con el libro de Service Operations de ITIL® y el sentido de que no es hasta este momento cuando realmente se entrega valor al usuario del servicio es directo… pero mi reflexión posterior me llevó un poco más adelante: recordé aquel post que había escrito al respecto de que en realidad el valor de un servicio no es como dice ITIL® el equivalente a Utilidad x Garantía, sino que debemos incorporarle un factor más: el uso.

Así, pues, y siguiendo con la reflexión, tanto da que seamos capaces de hacer 1, 10 ó 100 despliegues al día, que si el usuario no es consciente de lo que pasamos a producción y no es capaz de usar las nuevas funcionalidades que estamos incorporando, en realidad IT habrá generado su parte de valor pero si damos un paso atrás e intentamos encontrar dónde está el valor aportado/generado por el negocio no lo encontraremos: así, mi propuesta de modificación a la frase es

Until code is properly USED to GENERATE the EXPECTED VALUE, it still will be WIP stuck at any other point of the system

o sea.. hasta que el codigo no sea USADO de forma adecuada para GENERAR el VALOR ESPERADO, seguirá siendo WIP atascado en cualquier otra parte del sistema.

Intenté contactar con Gene Kim, el autor del libro, a ver qué opinaba del tema, pero es un hombre ocupado y no he conseguido llamar su atención… pero sí que hubo otra persona que dio su punto de vista: Byron Miller opinó al respecto diciendo que en el fondo todo lo relacionado con formación, cambios culturales y modificación de procesos debe ser también considerado WIP.

Vamos a ver si soy capaz de explicar hasta qué punto es importante esto: dentro de las metodologías ágiles (Scrum, XP, etc.) hay un aspecto que es fundamental y es lo que llaman la definición de “HECHO”. Sin esta definición no funciona nada… y es algo que está aquí para arreglar gran parte de los problemas que tenemos en las TIC.

Es necesario que todo el equipo que participa en la cadena de valor del servicio llegue a un consenso al respecto de qué significa decir que una petición del cliente esté HECHA. Históricamente, cada uno de los diferentes silos que participan en la entrega de esta petición ha interpretado como HECHO el momento en que lo da por terminado (según su visión especializada de las cosas) y lo pasa al siguiente elemento en la cadena. Así, el analista da por hecho el análisis cuando lo pasa a desarrollo, el desarrollador da por hecho el código cuando lo pasa a QA Testing y toda la división de desarrollo da por hecho el programa cuando lo entrega a producción.

Pero la cosa no debe de ser así. Todo el equipo, completo, debe tener una definición común de hecho. ¿Cuándo está hecho el evolutivo? ¿Cuando entrego a Ops? ¿Cuando lo despliego? ¿o cuando he conseguido que los usuarios lo usen adecuadamente?

Desde el punto de vista del negocio, claramente el evolutivo está hecho cuando entrega el valor prometido y eso sólo se hace mediante el USO, por lo tanto HECHO incluye también la formación, el cambio cultural, la modificación de los procesos de negocio, etc etc etc.

Así que, desde luego, todo ese aspecto soft de la entrega de servicios forma parte del WIP.

Ahora vamos a darle otra vuelta de tuerca a todo esto. Si pensamos en la teoría de las limitaciones, la propuesta de Goldratt dice en parte que dado un sistema, siempre existirá un cuello de botella. Es más, resulta que cualquier mejora que pretendamos aplicar al sistema debe de ser directamente sobre el cuello de botella, ya que si actuamos antes el resultado será un atasco monumental a la entrada del cuello de botella; y si actuamos después nos encontraremos con que no servirá de gran cosa puesto que será la limitación actual del sistema la que no esté entregando suficiente “ritmo” a las piezas que se encuentran detrás de ella. Así, cualquier mejora introducida en el sistema si no es en el cuello de botella, o bien no tiene efecto o bien contribuye a empeorar el rendimiento global del sistema.

Ufff… esto es complicado, pero va cogiendo sentido!

¿Qué pasa cuando agilizamos el desarrollo y no agilizamos los pasos a producción? Pues que se produce un atasco monumental en los PaP, y eso provoca… que la gestión de cambios es “el malo”, el que no deja pasar las cosas a producción, el que es un freno para la organización. Y qué pasa cuando agilizamos también el paso a producción? Que nadie se explica cómo puede ser que no se usen las nuevas funcionalidades de las aplicaciones y que cuando se usan el equipo de soporte y apoyo funcional no da abasto (hemos movido el atasco a otro sitio).

Si juntamos una definición de HECHO con visión completa, en la que el evolutivo está hecho cuando se está usando y está generando valor a la organización, con la “prisa” por adoptar metodologías DevOps que nos permitan hacer diez despliegues al día, nos encontraremos con que ahora el cuello de botella es el usuario, que no es capaz de absorber tanto cambio de forma continuada o la organización no permite que el usuario dedique el tiempo necesario a formación para ser capaz de absorber los diez despliegues al día.

En mi opinión, el ejemplo más claro de esta situación es el mundo de las Apps, en las que se despliegan (no 10 veces al día, pero hay algunos que despliegan al menos una vez al mes) nuevas funcionalidades que son documentadas en un pequeño “Read-Me” o similar que nadie se lee. El resultado? Pilas de nuevas funcionalidades que nadie usa… waste por todas partes porque no se está entregando valor con ese código desplegado, pero un equipo de desarrollo orgulloso de haber conseguido los hitos previstos.

De esa forma, todo vuelve a girar alrededor del “activo más importante de las empresas”: las personas. Las personas son la pieza sobre la que no tenemos capacidad de automatización y por lo tanto será el elemento que siempre será nuestro cuello de botella y sobre el que debemos trabajar en primera instancia, porque de lo contrario lo único que estaremos haciendo será cambiar el atasco de sitio (práctica muy habitual en las organizaciones estructuradas por silos, donde no hay una visión de conjunto: “yo ya he hecho mi parte… el resto no es cosa mía” y donde, además, se ponen objetivos por cumplimientos parciales)

En fin, todo esto ha sido una reflexión provocada por un párrafo en una novela… así que es probable que esté profundamente equivocado. ¿Tienes experiencias al respecto? ¿Trabajas en una empresa DevOps y nos quieres contar cómo transmites todo el cambio a la comunidad de usuarios?

¡Usa los comentarios, por favor!

Postdata: Ops! Por cierto… si somos capaces de hacer diez despliegues al día de correctivos, adelante!!! La comunidad de usuarios y los equipos de soporte lo están deseando! Es decir, todo este discurso es válido cuando el cuello de botella es el usuario por su ritmo de adoptar/asimilar/aprender las nuevas funcionalidades que estamos desplegando. Pero si hablamos de demanda fallo, el discurso es completamente distinto!

Consumada la venta de ITIL

Es curioso cómo son las cosas… hay días en que parece que los astros se alineen para dar esas coincidencias extrañas que pasan sólo muy de vez en cuando. Esta mañana he estado repasando un poco la línea temporal sobre historia de ITSM que tengo para mis clases y me di cuenta que una de las últimas entradas era la publicación del concurso para formar una joint-venture que impulsara las best-practices del gobierno británico (ITIL, MoV, Prince, etc..). Como no había tenido novedades al respecto y el tema había levantado bastante debate entre los profesionales del sector, me puse a buscar a ver si había algo de información al respecto del resultado, pero no encontré nada.

Luego, después de comer miré el correo y zas! ahí estaba la notificación de que se había publicado la nota de prensa con el resultado de esta aventura: la formación de una Joint-Venture con una empresa que yo no conocía de nada: Capita PLC

Esta Joint-Venture tiene aspectos muy curiosos. Empezamos leyendo la composición: 51% Capita, 49% Cabinet Office (o gobierno británico o su majestad la reina… los actuales dueños, vamos). Cuando salió la noticia del concurso hubo mucha discusion al respecto de si una JV sería vender ITIL® o no… para mi ahora está claro: si te asocias con alguien y ese alguien tiene más del 50% del asunto, lo has vendido. A partir de ahora, en las decisiones importantes, quien manda es Capita, no la Cabinet Office.

Otro aspecto interesante son los matices de la nota de prensa del gobierno británico:

Capita plc will own a 51% share of the new company. It will bring commercial expertise and enable investment needed to develop the products and break into new international markets. The government will retain 49% to ensure taxpayers benefit as the business grows.

Ojo, que no dice que se quedan el 49% para asegurar el buen crecimiento de los estándares ni la calidad de los mismos ni nada por el estilo… se quedan el 49% para asegurarse el beneficio. Y punto. A lo largo de toda la noticia se habla constantemente de los beneficios económicos y de las grandes perspectivas de comercialización que tienen los productos. Si alguna vez hubo alguna posibilidad de que ITIL® pasara a formar parte de la cultura general en forma de material libre, ya nos podemos olvidar… y eso significa también que la cultura de compartir y enriquecer los contenidos de las Best Practices de una manera similar a las comunidades open source desaparecerá rápidamente.

Y todo esto para qué? ¿A qué se dedicará la nueva empresa?

The new company will accredit exam institutes and training organisations to run exams and courses. It will act as an exam institute itself for the Project and Programme Management portfolio, including PRINCE2® products. Professionals using the qualifications will benefit too.

Asi que quedará como ente acreditador para los institutos examinadores y empresas de formación… ¿Qué pasará con APMG? En su página web apenas si hay una pequeña mención al tema… como si lo dijeran con la boca chica. Ellos hicieron ya un movimiento con ISACA que les puede salvar el trasero al menos en lo que a ITIL se refiere: están en el negocio de las certificaciones de COBIT 5, y eso puede ser muy grande si lo saben mover bien.

Y EXIN también ha movido ficha, anunciando en su pagina web la noticia e incluyendo un comentario esperanzador al respecto de que CAPITA respetará el ecosistema actual. De todas formas, tanto APMG como EXIN tienen sus salvavidas particulares en caso de que a estos británicos se les vaya la pinza.

¡Qué curioso es este mundillo!

Te puede interesar mirar atrás:

El futuro de ITIL (Noviembre de 2006)

La vuelta al cole (Septiembre de 2006)