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)

3 deseos de Navidad para el sector

Estamos a finales de año, y proliferan los posts sobre las predicciones para el año 2013. Dado el ratio de acierto, este año he preferido pensar en deseos para el 2013 y me gustaría compartirlos con ustedes… quien sabe! Igual se me cumplen (este año me he portado muy bien, Santa!) y es el inicio de una época mejor que la que estamos viviendo. Así que sin más prolegómenos, allá van los tres deseos:

1.- Extensión de Lean en la Administración Pública: Todos los que hablan sobre la crisis dicen que debemos recortar gastos y aligerar las AAPP. Yo no se mucho de economía, pero sí que se de reducir gastos: se llama eficiencia. Y la mejor manera de conseguir eficiencia (sin perder en eficacia, que es lo que nos está pasando en estos momentos) es conseguir que las ideas y principios del pensamiento Lean se extiendan, se comprendan y se vayan aplicando lentamente. Un entorno con transparencia, con sentido común, con visión de conjunto y sin derroche nos permitiría tener una administración pública que le costaste por lo menos un 60% menos al contribuyente sin perder calidad de servicio. ¿No queremos mantener el estado del bienestar? ¡Pues lo que tenemos que hacer es no derrochar ni un céntimo del ciudadano! Olvidemos la tecnocracia, dejemos de gastar millones de euros en aplicaciones y sistemas que automatizan el derroche y hagamos un esfuerzo por volver a los orígenes, comprender (aprender a ver) los procesos, identificar lo que sobre, limpiar, depurar, y después hablamos de automatizar. Hace casi un año el Estado de Washington emitió una orden para que las agencias estatales adoptaran estrategias Lean… ¡¡ Cómo me gustaría ver algo así aquí!!

2.- Que se rompa el modelo de la pirámide: Este modelo de la pirámide (a falta de un nombre mejor) es una figura literaria que yo utilizo para visualizar un gran problema existente en las organizaciones: cuanto más arriba en la jerarquía está una persona, más importantes son las decisiones que tiene que tomar. Cuanto más arriba, más dinero en juego, más personas afectadas, a más largo plazo son las decisiones… Pues si es así, por qué razón cuanto más arriba se está menos atención, tiempo y reflexión se dedica a tomar estas decisiones? Un CFO, un CEO, un CIO no es un superhombre con una inteligencia diez veces superior a la media… le tiene que dedicar a las cosas un tiempo razonable, parecido al que le tendrías que dedicar tú o que le tendría que dedicar yo.

Estar “trasteando” con el móvil o con la tablet durante las reuniones en las que se está tratando de proporcionarle la información necesaria para que tome una decisión con criterio, llegar tarde o no llegar a las reuniones (diciéndole a su segundo “ve tu a la reunión y luego me haces un resumen”) o pretender decidir cosas que afectan a cientos de trabajadores en base a lo que me puedas explicar en 5 minutos tomando un café entre reunión y reunión es una terrible falta de respeto hacia los trabajadores y sobre todo hacia la organización que sufrirá las decisiones tomadas a la ligera.

Desearía que a partir del año 2013 los directivos sean conscientes de la importancia que tienen sus decisiones, que dediquen el tiempo necesario para meditar, reflexionar y decidir y que, para que esto sea viable, el “span de responsabilidad” sea el adecuado.

3.- Que tengamos cuidadito con el cloud: Todas las predicciones apuntan a que hay nubarrones grandes en el horizonte del 2013. El hype del cloud computing viene pegando con fuerza, pero son cada vez más los CIOs que, una vez comprado el modelo en cloud, se topan de morros con la realidad: ¡¡Se nos ha olvidado pensar cómo vamos a gestionar esto!!. De repente tu proveedor es un proveedor industrializado, que obtiene su beneficio de la producción en masa y de las economías de escala… ¿que quieres personalizar el qué??? ¿Que te tenga en cuenta en las paradas planificadas? ¿Que te avise antes de los upgrades y los haga cuando a ti te venga bien según tu ciclo de negocio?  ¡¡No me haga usted reir, por favor, señor cliente, que me duele una costilla!!

Asi que por favor, piensa antes de tirarte a la piscina! No todo es mover las cosas de inversión a gasto ni ganar en flexibilidad. Tu les das servicios TIC a tus clientes, a quienes les importa un pepino si la cosa es cloud o no. Y con esto no quiero decir que sea un anti-cloud y que no me guste… lo que quiero decir es que las cosas hay que pensarlas un pelin. Vamos, que si se me cumple el deseo 2, el tres va de regalo!

Feliz Navidad a todos, y si quieres dejar tus deseos en los comentarios, se los paso a Papa Noel todos juntos!

PS:: El diseño de la camiseta es propiedad de GamesAjare.

El TFT12 ya está aquí!

Han pasado varios meses desde que comenzara esta gran aventura que ha supuesto la organización del congreso global TFT12, Tomorrows IT Service Future Today. En el momento de escribir estas letras, quedan menos de siete horas para que comience el espectáculo, cuando den las 08:00am en Sydney, Australia y comience el día 5 de Diciembre al otro lado del mundo. A partir de ese momento, tendremos 24 horas de conferencias sobre ITSM con 24 ponentes de todo el mundo explicándonos qué nos depara el futuro en este sector tan agitado; pero lo novedoso no es sólo que sean 24 ponentes hablando durante 24 horas… este congreso es novedoso en todos y cada uno de los aspectos, desde la selección de conferenciantes por crowdsourcing hasta la difusión en directo y en diferido mediante Google Hangout.

Te dejo aquí algunas pistas que te ayudarán a consumir el conocimiento aportado durante todo este tiempo:

1. Consulta el programa del evento, escoge qué conferencias quieres ver en directo.
2. Haz un RSVP del evento en las redes sociales que utilices, para saber con quiénes te encontrarás y con quién podrás compartir comentarios, impresiones e ideas. Hay eventos creados en Facebook, Gooogle+ y LinkedIN
3. Atiende en vivo y en directo a las conferencias que serán emitidas en streaming por Youtube.
4. Descárgate las presentaciones a medida que se vayan produciendo.
5. A partir del 10 de Diciembre, podrás escuchar y descárgate el audio de las conferencias desde SoundCloud
6. Revisa la lista de ponentes y sus biografías en el tablón de Pinterest.
7. Subscríbete aquí para que te lleguen directamente a tu Evernote o a tu Kindle las presentaciones de forma automática a medida que se vayan produciendo.
8. Añade comentarios tanto sobre lo ponentes como sobre las ponencias en Slideshare y Pinterest.
9. Utiliza el hashtag #TFT12 para cualquier comentario que hagas en las redes sociales.
10. Inscríbete ya! La lista de ponencias para el TFT13 ya está abierta!

Habías visto alguna vez un congreso más 2.0 que este? Estamos haciendo historia y tú puedes ser parte de ella. Espero verte entre los asistentes. Mi conferencia es el día 5 a las 14:00 hora canaria (GMT) y una hora más en la Península (15:00 CET) y versará sobre RBSM – Risk Based Service Management.