Scrum en organizaciones Lean: más madera para el Product Owner!

Dentro de mi viaje particular al Nirvana del Flow, esta semana he tenido un momento importante. Facilitando un evento Kaizen para el equipo de almacén de un cliente, intentando corregir unos “problemillas” que había con unos bultos que se traspapelaban por el camino hemos seguido todos los pasos de rigor: plantear el problema, hacer un VSM, identificar oportunidades de mejora, análisis de causas etc etc.

Lo de siempre en el mundo Lean, siempre tan interesante gracias a la participación de todos. Aparte de todo lo que aprendí del mundo de los almacenes y la logística, que es impresionante, pude vivir (otra vez!) la excitación que te genera ver que el equipo Kaizen no se enfoca en las guerras personales y empieza a trabajar de manera creativa en comprender el problema y plantear contramedidas, siempre de manera transversal y cross-departamental. ¡Es alucinante!

Pero por el camino empecé a notar que la cosa se podía complicar. En seguida aparecieron propuestas de pequeños cambios en el proceso, pequeñas modificaciones en la operativa (con el consiguiente problema de Gestión del Cambio con el personal y sus diferentes turnos) y el nacimiento de nuevas necesidades de información, controles y sistemas de información.

¿Quien dijo que los procesos industriales son más fáciles de gestionar porque están estandarizados?

Este proceso que estábamos analizando es fácil de comprender, pero la cantidad de casuísticas que tiene es impresionante y ahí aparecía una de las lecciones importantes del Kaizen… recuerdas? “Kaizen … yo me flagelo y hago un sacrificio por el bien común”.

Para conseguir un proceso más homogéneo y sin tantas excepciones y casos especiales todos deben hacer pequeñas concesiones para conseguir optimizar el proceso de forma global en lugar de perseguir las optimizaciones locales e independientes para cada uno de los interesados. En este caso, el equipo de almacén se ve afectado por los requisitos, limitaciones o presiones impuestas en el proceso aguas arriba (por ejemplo, presiones en la planificación establecidas dos o tres eslabones antes de llegar a la preparacion de un pallet que debe ser expedido).

Y ahora vamos a pensar un poco más allá; este post no pretendía ser una explicación sobre una sesión de Kaizen. ¿Te imaginas una empresa en la que los diferentes equipos hacen sesiones de Kaizen para ir mejorando poco a poco los procesos de negocio? En el almacén, en compras, en logísticas, en pedidos… en todas partes gente haciendo pequeñas modificaciones y pequeñas mejoras sobre los procesos, haciendo que la empresa lentamente vaya evolucionando a mejores cotas de calidad, eficiencia y valor para el cliente. ¿Mola, no?

¿Y dónde están los informáticos?

¡Esa es la reflexión clave! Si los procesos evolucionan continuamente, informática debe ser capaz de soportar esas modificaciones de forma continua, debe facilitar la adaptación permanente de los sistemas de información a las necesidades y a los cambios provocados por la mejora contínua del negocio.

Es lo que hacemos siempre, no? Desde luego, no me cabe la menor duda de que siempre estamos intentando mantener un ritmo decente de modificaciones/evoluciones a nuestros sistemas de información, pero en un entorno Lean donde la evolución y el cambio son constantes el nivel de exigencia es mucho mayor.

¿Y cómo respondemos en informática a esta situación de elevada demanda de pequeños cambios sobre los mismos sistemas de información?

Con equipos especializados en esos sistemas de información, focalizados en el proceso, orientados a la ejecución de tareas que finalizan con un incremento de producto totalmente funcional.. respondemos a las células de producción con células de producción. Los equipos ágiles son especialmente necesarios en estos entornos donde no dar respuesta incremental a estas demandas significa frenar la mejora de los procesos de negocio.

Por eso es tan y tan importante provocar la transformación ágil en los entornos Lean para hacer que flujo, valor y calidad vayan de la mano en todos los sentidos. Y cuando tengas en marcha equipos ágiles, si usas Scrum por favor, asegúrate de que al menos el Product Owner asiste a las sesiones Kaizen de su cliente.

Ni te imaginas el aprendizaje y la cantidad de información y de ideas enriquecedoras que el equipo de desarrollo se va a llevar de esas sesiones: es ver a tus usuarios tratando de resolver sus problemas utilizando tus herramientas.

Postdata: en este evento Kaizen que estoy facilitando está presente la Product Owner y varias personas del equipo de desarrollo… está siendo una experiencia super enriquecedora para todos!

La primera paga extra

Corría el año 1983 y yo entraba en el instituto con la cabeza llena de ideas y sobre todo con una pasión que me había acompañado desde que tengo memoria: la biología. Desde que tengo recuerdos, yo iba a ser biólogo, a ser posible entomólogo o herpetólogo, y mi mayor héroe era Gerald Durrell, que se había criado de una manera muy parecida a mi, en una isla y rodeado de bichos (para muestra, un botón: el libro “Bichos y demás parientes”).

Una vez en el instituto conocí a Víctor, quien se convertiría en uno de aquellos amigos “para toda la vida” y que compartía conmigo un montón de aficiones e intereses, como la música y las matemáticas (pero no la biología). Víctor tenía una calculadora HP de aquellas que se programaban en notación polaca inversa y eso era la bomba! No había nada más entretenido que pensar en cómo hacer que la calculadora aquella nos ayudara con los problemas de trigonometría. A mitad de curso yo ya pensaba que después de hacer biología me gustaría aprender algo de informática.

Más adelante, Víctor me presentó a un amigo suyo que estudiaba FP y que tenía una calculadora programable que se programaba en Basic, una Casio PB-100

No me lo podía creer! Aquello era la bomba! *Necesitaba* una..! Me la prestó un fin de semana y creo que no hice otra cosa durante esos dias que programar y programar… había que ver qué era capaz de hacer esa maravilla.. ¿multiplicar determinantes? ¿hacer integrales definidas? ¿calcular fórmulas químicas?

Unos años antes, en 1976, había desembarcado en Gran Canaria un equipo de El Corte Inglés con la misión de construir el primer centro de los grandes almacenes en la isla. Escogieron para construirlo justamente el solar que había al lado de mi casa, allí donde los chiquillos del barrio jugábamos a futbol o practicábamos tiro al blanco con piedras y latas vacías. En 1977 inauguraron por todo lo alto el local con bendiciones del párroco de la Iglesia del Pino incluidas!

Así que para los años de instituto yo ya era un asiduo a pasar el tiempo libre echando un vistazo en los escaparates de El Corte Inglés; hasta que un día los chicos de ECI pusieron a la venta una “cosa rara”: un ordenador personal (??) que se conectaba a la televisión y se podía programar: un Sinclair ZX-81. Yo inmediatamente me llevé a mi padre a ver aquello y a decirle que me encantaría tener una cosa de esas, pero la respuesta de mi padre fue tajante: “Eso es una porquería. El día que tengan un ordenador de verdad, te compro uno."

¡¡Un ordenador de verdad!! Y el maravilloso ZX que tenía delante qué era?? Pues a ojos de mi padre, el ZX-81 debía ser poco más que una calculadora programable o incluso menos! Así que hubo que esperar. Pero mientras esperaba yo iba casi cada día a mirar aquel aparato, luego vinieron otros: el Spectrum, el Casio portable, los diferentes fabricantes y modelos de MSX, el Vic-20, el Commodore 64...

Pasaron al menos dos o tres años en los que yo invertía gran parte de mi tiempo libre en ir a la Planta 4 de El Corte Inglés a toquetear ordenadores; todo lo que aprendía en el instituto lo intentaba aplicar así que “inventé” las curvas de lissajous (luego descubrí que ya estaban inventadas), implementé los algoritmos para multiplicar determinantes, descubrí que si pintas una gráfica en la que la X se mueve según un sin(t) y la Y se mueve segun cos(t) obtienes una circunferencia (si y solo si las dos variables están debidamente sincronizadas) y luego cuando en el instituto me explicaron las coordenadas polares me resultó obvio: ¡ya lo había descubierto en El Corte Inglés!

Llegué a conocer a los dependientes y ganamos tanta confianza que cuando un “adulto” entraba preguntando por un ordenador para comprarle a su hijo, lo redirigían a mí para que le explicara para qué podría usar el ordenador su criatura.

Y un buen día llegué yo a la cuarta planta y uno de los chicos me dijo “Mira: ha llegado esto; a ver qué puedes hacer con él”… y allí estaba… flamantemente nuevo, un Amstrad CPC 464 con sus 64Kb de RAM y lo que era más alucinante, su monitor de súper alta resolución que podía darte 320x200 en cuatro colores!!

No me lo podía creer, aquello era un pedazo de ordenador; seguro que sería lo que mi padre llamaba “un ordenador de verdad”. Así que lo llevé a verlo y … no!, seguía siendo un juguete; así que tocó seguir aprendiendo, programando y casi que trabajando en El Corte Inglés.

Para acortar un poco la historia, cuando Amstrad presentó el CPC-6128 ya en el año 1985, aquello ya se pareció a “un ordenador de verdad”, así que mi padre hizo un tremendo esfuerzo (que lógicamente ocultó y del cual yo no fui nunca consciente) y me compró el aparato. Ya con él en casa, me conseguí un manual de programación en ensamblador y de llamadas al sistema (fuera lo que fuera aquello) y escribí mi primer juego en ensamblador (una variante de Tron, película que me había dejado encandilado por aquella época)

El resto ya vino rodado; un día estaba en El Corte Inglés y llegó un señor a preguntar quién podría hacer un programa para llevar el control de los gastos de la flota de ambulancias de la Cruz Roja y el dependiente me señaló a mí. Fueron mis primeras 10.000 pesetas ganadas honradamente programando; luego alguien de Indescomp buscaba a un programador que pudiera hacer las traducciones del software educativo al castellano y comencé a trabajar para ellos: me daban los diskettes del software en inglés y con una herramienta muy parecida a las PC-Tools, yo traducía aquello al castellano con un editor hexadecimal. Ahora mirándolo en la distancia me parece que la cosa no debía ser muy legal, pero yo estaba convencido de que si, porque ellos eran “la casa madre”.

Ya para esa época había abandonado la idea de estudiar Biología (bueno, en realidad decía que estudiaría Biología después de Informática; que la Informática sería para comer y la Biología para gozar), así que cuando estaba en 3º de BUP me compré una calculadora Casio FX-850P que me acompañó durante todos mis años de facultad y que aún tengo en mi poder en perfecto estado. Entré en la Facultad de Informática de la ULPGC y empecé a jugar en una liga más importante, así que vendí el CPC-6128 y me compré mi primer PC, un Amstrad PC1512 que fué rápidamente substituido por un Inves 80286 (También de El Corte Inglés!).

Así que cuando la semana pasada ví en la tele la publicidad de El Corte Inglés titulada “La primera paga extra” me emocioné mucho… parecía como si alguien de ECI hubiera entrado en la agencia de publicidad a pedir un spot emotivo y hubiera contado mi historia; el chaval baja las escaleras feliz por haberse comprado su primer iPad y yo comencé a construir mi futuro gracias a aquel Amstrad y al buen criterio de mi padre que no quiso comprarme un “ordenador de juguete” sino que decidió que había llegado el momento de hacer el gran esfuerzo familiar cuando vio que aquello realmente me interesaba.

33 años después, GRACIAS.

Gracias a mis padres, por el pedazo de esfuerzo que sé que tuvieron que hacer.
Gracias a mi familia, por el apoyo que siempre me han mostrado.
Gracias a mis amigos, por darme el empujón que me cambió la vida.
Y Gracias al equipo de El Corte Inglés que trabajaba en la Planta 4 del centro de Mesa y Lopez 15 porque podrían haberme echado o haberme dicho “niño, no toques los ordenadores que son muy caros”, pero sin embargo me dejaron hacer durante los 3 ó 4 años que estuve yendo hasta que entré en la Universidad y me facilitaron el acceso a algo que no me podía permitir fácilmente.

Acordando niveles de delegación

A medida que han ido pasando los años y he ido madurando como profesional, más le he ido encontrando sentido a todo el discurso de Paul Wilkinson quien, desde que yo conozco esto de la Gestión de Servicios, ha sido monotemático: lo importante son las personas [y desde 2004 que sigo oyendo el eco de sus palabras "las personas, las personas, …”]

Asi que me centré en las personas, en su trabajo, en su forma de entender lo que debían hacer y en su forma de aprender; y eso me llevó a pensar en asuntos como la motivación, la implicación y la asunción de responsabilidades, al tiempo que me llevaba a investigar mejores maneras de enseñar a las personas lo que deben saber para hacer su trabajo.

Yo lo que necesito es que ellos tomen las decisiones sin que yo tenga que entrar al micromanagement, dijo el CIO.

Recientemente, haciendo un trabajo con un cliente, llegamos al momento en el que se debían repartir las responsabilidades sobre un determinado conjunto de actividades, así que sacamos nuestra matriz RACI y comenzamos a repartir letras a diestro y siniestro, en una reunión con los implicados para que tuvieran voz y voto sobre este reparto. De repente llegamos a un momento en que el CIO dijo algo así como “pero yo lo que necesito es que ellos tomen las decisiones sin que yo tenga que entrar al micromanagement” y vimos claramente que nos faltaba algo.No es lo mismo una tarea que una decisión.

Menos mal que uno es un hombre de recursos y que en G2 siempre estamos aprendiendo cosas nuevas “para cuando hagan falta”, así que tiré de agenda y concreté una siguiente fecha para hacer un taller de “Póker de Delegación”, práctica que aprendí en las clases de Management 3.0 de las manos de Gabri Prat, Angel Medinilla y Angel Diaz-Maroto.

La idea que subyace detrás de este taller es identificar el conjunto de decisiones que se deben tomar en un determinado ámbito de actuación (dentro de un proceso, dentro de una metodología, durante la ejecución de un proyecto, etc) y llegar con la dirección a un acuerdo al respecto del modelo de delegación que vamos a utilizar para cada una de ellas. A modo de ejemplo, podríamos acordar que la decisión sobre si realizar o no gastos no presupuestados y con un importe superior a 2.000 € será tomada por la dirección consultando opinión a la persona que solicita el gasto, pero la decisión sobre qué miembro del equipo debe realizar las guardias se deja al equipo sin necesidad de aportar más explicaciones. Desde la orden impuesta y sin derecho a réplica hasta la delegación absoluta de una decision hay todo un continuo de posibles modelos, que el juego de Póker de Delegación establece en siete niveles.

Llegar a este tipo de acuerdos es de gran utilidad para un equipo de trabajo: nos ayuda a poner claras las reglas del juego, a saber cuándo tengo que pedir permiso y cuándo no, a visualizar claramente cuál es el terreno de juego y a reducir el tiempo necesario y el desgaste asociado a las reuniones. Un gran invento!!

Fue un taller fantástico, discutimos los puntos de decisión y el grado de delegación que quería el equipo y el que quería el responsable y nos encontramos en casos en los que el responsable queria dar más “correa” de la que el equipo quería asumir, y casos en los que el propio equipo pedía más y mientras ellos jugaban a tomar decisiones yo los observaba y sonreía porque estaba viendo a un equipo hacerse mayor.

Ahora ellos tienen un terreno de juego delimitado, que les indica para las 10 ó 12 decisiones más habituales que deben tomar en el desempeño de sus tareas cuál es el modelo de delegación que han acordado. Y si quieren cambiar ese modelo, como ahora está objetivado, sólo tienen que volver a jugar una partida a las cartas.

… y no hay mucho más que decir…

1. Crear constancia en la mejora de productos y servicios, con el objetivo de ser competitivo y mantenerse en el negocio, además proporcionar puestos de trabajo.
   
2. Adoptar una nueva filosofía de cooperación en la cual todos se benefician, y ponerla en práctica enseñándola a los empleados, clientes y proveedores.
   
3. Desistir de la dependencia en la inspección en masa para lograr calidad. En lugar de esto, mejorar el proceso e incluir calidad en el producto desde el comienzo.
   
4. Terminar con la práctica de comprar a los más bajos precios. En lugar de esto, minimizar el costo total en el largo plazo. Buscar tener un solo proveedor para cada ítem, basándose en una relación de largo plazo de lealtad y confianza.
   
5. Mejorar constantemente y por siempre los sistemas de producción, servicio y planeamiento de cualquier actividad. Esto va a mejorar la calidad y la productividad, bajando los costos constantemente.
   
6. Establecer entrenamiento dentro del trabajo (capacitación).
   
7. Establecer líderes, reconociendo sus diferentes habilidades, capacidades y aspiraciones. El objetivo de la supervisión debería ser ayudar a la gente, máquinas y dispositivos a realizar su trabajo.
   
8. Eliminar el miedo y construir confianza, de esta manera todos podrán trabajar más eficientemente.
   
9. Borrar las barreras entre los departamentos. Abolir la competición y construir un sistema de cooperación basado en el mutuo beneficio que abarque toda la organización.
   
10. Eliminar eslóganes, exhortaciones y metas pidiendo cero defectos o nuevos niveles de productividad. Estas exhortaciones solo crean relaciones de rivalidad, la principal causa de la baja calidad y la baja productividad reside en el sistema y este va más allá del poder de la fuerza de trabajo.
    
11. Eliminar cuotas numéricas y la gestión por objetivos.
    
12. Remover barreras para apreciar la mano de obra y los elementos que privan a la gente de la alegría en su trabajo. Esto incluye eliminar las evaluaciones anuales o el sistema de méritos que da rangos a la gente y crean competición y conflictos.
    
13. Instituir un programa vigoroso de educación y auto mejora.
    
14. Poner a todos en la compañía a trabajar para llevar a cabo la transformación. La transformación es trabajo de todos.
    

William Edwards Deming, 1986

Lean-IT reloaded

Una certificación vale tanto como las empresas (u otras organizaciones) la exijan, y las empresas la exigirán cuando entiendan su significado y contenidos y cuando vean que un profesional certificado realmente domina la materia de la certificacion.

Por esta razón, el mercado de la formación y las certificaciones profesionales necesita un poco de orden y de estabilidad, para asegurar que no existe un abanico enorme de certificaciones procedentes de diferentes institutos u organismos certificadores sobre las mismas temáticas; si con dos o tres esquemas de certificación profesional sobre Gestión de Servicios o sobre Gestión de Proyectos ya hay dudas al respecto de cuál escoger, imaginemos qué pasa cuando para una misma temática puedes encontrar hasta cuatro o cinco esquemas de certificación diferentes: el mercado se fragmenta, pierde prestigio, los alumnos pierden el interés y ninguno de los esquemas consigue la masa crítica necesaria como para que sea “un estándard de facto reconocido en el sector”.

Esta era la situación en la que se encontraba Lean-IT hasta Marzo de este año: había un gran incremento en la demanda de formación en los conceptos de Lean-IT, pero nadie había definido exactamente qué era. Había un gran interés en certificar al personal en Lean-IT, pero nadie sabía exactamente qué esquema de certificación seguir… cuál será mejor, el Lean-IT Foundations de EXIN o el de APMG? Valdrá la pena el de Quint? Nadie sabía exactamente a qué atenerse, y no podías descartar a ninguno porque todos los players del mercado eran grandes pesos pesados en la industria de la certificación profesional. La situación era complicada y corríamos el peligro de que la cuerda se rompiese.

En un alarde de profesionalidad, en Marzo de 2015 se presentó a nivel mundial la Lean IT Association (http://www.leanitassociation.org ), una organización sin ánimo de lucro formada por tres de los grandes organismos de certificación (EXIN, APMG y PeopleCert) y tres de los grandes en formación (ITpreneurs, Pink Elephant y Quint Wellington Redwood) cuyo principal objetivo es proporcionar una visión homogénea sobre Lean-IT, sus materiales de formación y su esquema de certificación para profesionales.

Un pequeño paso para un hombre...
pero un gran paso para la humanidad.

Al poco tiempo de su creación, la LITA presentaba al mundo su esquema de certificación basado en tres niveles (Fundamentos, Practitioners y Profesional) con cinco certificados orientados a capacitar y a acreditar a los profesionales en las diferentes áreas de trabajo en las que se orienta la aplicación de los principios del Lean Thinking al desarrollo y gestión de los servicios IT.

El nivel de fundamentos ya está definido, con syllabus, temario y exámenes de certificacion y la verdad es que es muy bueno: el alumno se lleva una visión global de los principios del Lean Thinking y su aplicacion en todas las áreas de IT, sirviendo de enlace hacia las futuras certificaciones en IT4IT o hacia las certificaciones en metodologías ágiles.

G2 es Accredited Examination Center y Accredited Training Provider con EXIN y por lo tanto tenemos la capacidad de realizar los examenes de certificación también en el nuevo esquema Lean-IT de la LITA y ya hemos comenzado los primeros cursos de Fundamentos en la UPC Tech Talent School dentro del programa de formación Agile IT Management.

¡Bienvenidos!

BPIC 2014 Student Challenge

¿Tienes la impresión de que la minería de procesos es una de las cosas más interesantes que has aprendido en tus estudios este año? ¿Estás pensando en hacer un proyecto de final de carrera o de fin de master centrado en la temática de la minería de procesos? ¿Te ves a ti mismo como analista de procesos en una gran compañía o trabajando como consultor en mejora de procesos una vez que termines tus estudios? Si es así, entonces el BPIC 2014 Student Challenge es el reto y la oportunidad que estabas buscando.

Cada año, el BPI Challenge agrupa a los mejores profesionales de minería de procesos e investigadores de todo el mundo en una actividad que les permite comparar sus habilidades y perspectivas en el análisis de procesos. Esta competición pública se basa en un conjunto de datos extraído de una aplicación del mundo real, proporcionada por una gran compañía que se plantea cuestiones relevantes al respecto del funcionamiento de sus procesos; no estamos hablando de un ejercicio teórico… esto es la vida real!

La invitación está abierta, todo el mundo será bienvenido. Puedes consultar los resultados de años anteriores 2013 y 2012 para hacerte una idea de cómo funciona y qué resultados son los que se han obtenido en las otras ediciones del campeonato.

Este año, por primera vez, se organiza además un campeonato de estudiantes. Como estudiante, esto significa que, mientras que estás analizando los mismos datos reales que los equipos de profesionales e investigadores, tu entrega se juzgará en un track especial y se comparará únicamente con los trabajos presentados por otros estudiantes, lo que hace la liga más justa.

El programa de mentores

Pero aún hay más: Gracias al programa de mentores, puedes conseguir acceso exclusivo y soporte de algunos de los profesionales más experimentados en el sector de la minería de procesos (algunos de los cuales también se presentarán al concurso en el track principal):

Fluxicon organiza un programa de mentores en el cual cada equipo de estudiantes se emparejará con un profesional con experiencia en la minería de procesos que se prestará su apoyo para preparar el trabajo a presentar. Comprobarás por ti mismo que para redactar las conclusiones finales de tu estudio es fundamental tener conocimiento del área analizada y un buen conocimiento del proceso a estudiar, y tu mentor será el encargado de ayudarte en este terreno si de repente te encuentras encallado.

Tienes de plazo hasta el 31 de Mayo para solicitar tu emparejamiento con un mentor, y esto se va a hacer en modo FIFO: el primero en llegar será el primero en ser emparejado, así que no lo dudes, date prisa y consigue tu mentor ahora mismo en este enlace:

https://fluxicon.wufoo.com/forms/mentorship-program-bpi-challenge-2014/

El equipo de Fluxicon intentará emparejarte con un mentor de tu zona geográfica o al menos de tu mismo idioma. Esto debería facilitar la comunicación y ¡quien sabe! quizás os podéis conocer en persona! Pero no pierdas el tiempo, porque hay un número muy limitado de mentores disponibles para esta edición del BPIC.

¿por qué deberías participar?

¿Estás listo para montar tu equipo? Aquí te dejamos algunas ideas de por qué creemos que deberías participar:

• Perfeccionar tus habilidades: Los data scientists son una de las profesiones más buscadas en estos momentos. Comienza pronto a desarrollar tus habilidades como analista, añade algunas medallas importantes a tu currículum y ábrete las puertas a un nuevo conjunto de oportunidades laborales.
• Construye relaciones: Tener un tutor te facilitará presentar un mejor trabajo a concurso, pero por encima de esto, seguro que aprenderás una o dos cosas valiosas de tu mentor, quizás aparte de los contenidos del campeonato en sí mismo.
• Porque mola: La minería de procesos es una de las técnicas de análisis de datos más interesantes hoy por hoy. Está basada en datos y al mismo tiempo es visual. Además, con el BPIC 2014 tendrás la oportunidad de bucear en datos reales y ganar una visión única de cómo funciona un proyecto de minería de procesos en el mundo real.
• Ops! También hay premios! El equipo ganador obtendrá un iPad esponsorizado por la Universidad de Tecnología de Eindhoven.  También, para uno de los miembros del mejor equipo holandés el grupo de interés especial en minería de procesos de la asociación holandesa de industria patrocinará el viaje a Halifa, Israel, para la ceremonia de entrega de premios durante el congreso BPM 2014.

Recomendamos equipos de dos a cuatro personas. Pos supuesto, puedes participar en solitario, pero pensamos que hacerlo en equipo será mucho más divertido.

detalles de participación

Fecha Límite: 12 de Julio de 2014, 23:59 CET

Dónde: https://www.easychair.org/conferences/?conf=bpic2014

Tu proyecto debe contener un informe en PDF de 30 páginas como máximo incluyendo imágenes y tablas, utilizando el formato  LNCS/LNBIP especificado por Springer (y del que existen plantillas Word y LaTeX). Se pueden añadir apéndices, pero deben incorporar únicamente información que sea de apoyo al texto principal.

Puedes conseguir más información en la web del BPI Challenge.

AYUDANOS A CORRER LA VOZ!

Si no eres estudiante, pero conoces a estudiantes que se puedan querer presentar, o conoces a alguien que a su vez conozca estudiantes… ayudanos a correr la voz y a hacer que esta edición del BPIC 2014 sea especial!

Gracias!

The BPIC 2014 Student Challenge is supported by the Rabobank, Fluxicon, Eindhoven University of Technology, the IEEE Task Force for Process Mining, and the SIG Process Mining of the Ngi-NGN.

 

POSTDATA

Este texto es una traducción más o menos libre del texto original publicado en el blog de Fluxicon.

Este año, el equipo de Fluxicon ha contado con nosotros (G2) para actuar como mentores para estudiantes hispanohablantes… así que espero que te presentes y podamos jugar juntos!!

Los datos que se analizarán provienen de una implantación de HP Service Manager 9.X en Rabobank, por lo que podremos analizar información de procesos ITIL® de Incidencias y Cambios en un entorno real del sector bancario… qué más se puede pedir? :-)

¡¡Te esperamos!!

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.

¿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!

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.

¿Un cliente satisfecho?

Imagina que vas a un hotel. Llegas y la atención en recepción es impecable, te atienden rápido, te informan de los servicios y te dan tu habitación justo como tú la querías: cama doble, vistas a la ciudad, silenciosa…  Entras en la habitación y está todo como debe y justo cuando te sientas en la cama, ¡Una pata de la cama se parte y la cama cae al suelo!

Llamas a recepción, en un par de minutos llega el chico de mantenimiento y en poco tiempo te han sustituido la cama (para no hacerte cambiar de habitación; ya habías desmontado la maleta). Se disculpan efusivamente por el inconveniente y te invitan a cenar al restaurant del hotel para compensarte por el mal rato. Al poco rato, alguien te llama para preguntarte si el problemilla se ha solucionado y saber si te han atendido correctamente. Les das 5 sobre 5 puntos en la encuesta de satisfacción.

A la mañana siguiente, cuando te vas a ir, te quedas con el tirador de la puerta en la mano; tienes que bajar a desayunar, así que vuelves a llamar a recepción pidiendo ayuda. Casi antes de colgar se presenta otro chico de mantenimiento que repara la situación en menos de un minuto, se disculpa y te da un cupón de descuento del 50% para la próxima visita que hagas a la ciudad.

Cuando estás haciendo el check-out, el recepcionista te pregunta amablemente si el incidente de la puerta se resolvió adecuadamente y tú lo vuelves a puntuar con 5 sobre 5, ya que se resolvió rápido, te trataron bien y te compensaron por la espera.

Según sales por la puerta, coges el cupón de descuento, lo rompes en 8 pedazos y lo tiras a la papelera mientras piensas “no vuelvo a pisar este antro nunca más”.

Pero ojo! las encuestas te dan por cliente muy satisfecho, ya que has puntuado dos veces con 5 sobre 5, siempre que has tenido un problema te han atendido excepcionalmente bien y todo ha sido muy rápido; ¡Que viva el SLA!

¿Te suena este tipo de situaciones? ¿Lo has vivido, o quizás lo estás potenciando e tu organización?

Lo lamentable es que esta forma de medir la satisfacción del cliente es una Best-Practice en el mundo del ServiceDesk, y deberíamos pararla inmediatamente. Deberíamos dejar de preguntar si la atención (puntual, por incidente) ha sido buena y comenzar a preguntar por el servicio.

¿Cómo haremos las encuestas el día que seamos tan pero que tan buenos, que no tengamos incidencias? ¿A quién le preguntaremos?

Como mínimo, como dice Charlie Betz ( twitter @CharlesTBetz), deberíamos tener una alerta al respecto, algo como un “Repeat Caller Incident” que nos permita saber que un cliente está sufriendo repetidas incidencias, aunque sean de diferente tipo, durante su encuentro con el servicio y de esa forma hacer lo posible por retenerlo (y medir la aparición de este tipo de situaciones para poder gestionar esta situación de manera global)

El servicio no es el soporte.. el soporte es una característica que ponemos cuando el servicio no es perfecto; debemos poner foco en medir (evaluar, analizar, reportar y mejorar) la calidad del servicio.

Esta entrada es una traducción adaptada y reflexionada de un comentario de Aale Roos (twitter @Aalem) en el grupo de Facebook Back2ITSM.

Conectando el taller con la fábrica

Este fin de semana salí con la familia a comer al campo, junto con otras cuatro familias del colegio de las niñas; dimos un fantástico paseo por el campo, hicimos un poco de Geocaching y al final fuimos a comer un poquito de carne a la brasa… un día agradable y entretenido en que la familia se lo pasó de perlas y yo desconecté un mucho de la tensión del día a día del trabajo.

A la hora de comer dejamos fluir la conversación entre temas de todo tipo: los “padres” hablamos de futbol, de la crisis, del tiempo… Delante de mí en la mesa estaban sentados Fernando (que se dedica a la inyección de plásticos en una fábrica) y Luis (mecánico, con su taller de barrio donde repara todo lo que se le ponga en las manos); en un momento en que estábamos hablando del taller, de repente yo le hice una pregunta a Luis:

--Oye Luis, dime una cosa: los Toyota, ¿qué, son buenos?

Luis comenzó a asentir con la cabeza, pero antes de que le diera tiempo a decir nada, Fernando (que tiene un Toyota) me dijo:

-- Yo soy socio de la OCU y tengo un informe que dice que los Toyota son los coches que menos averías tienen de todos. Por eso me compré uno. Son buenísimos!

-- Y que lo digas! – dijo Luis – son un coche que se estropea muy poco, pero además, es que se nota que están bien hechos. Las piezas que más se rompen, son accesibles y se sustituyen con facilidad. En un Seat o en un Renault te las ves negro para cambiarlas, pero en un Toyota están ahí, fáciles de acceder, con espacio… una gozada!

-- Hmmm… Interesante… – Yo movía la cabeza interesado…

-- Y otra cosa que tienen – siguió Luis – es que están bien diseñados. A veces ves un coche por dentro y piensas “El tipo que diseño esto, no ha arreglado un motor en su vida”. Por ejemplo, los Seat tienen muchísimos problemas eléctricos. ¿Sabes por qué? Porque ponen las piezas donde no deben: hay sensores que están cerca del radiador, o cables que pasan por donde el motor más se calienta… y con el tiempo se estropean. En un Toyota lo ves, y no pasa así: todo está donde debe estar.

-- Ah! - Dije yo – Eso es porque tienen un enlace directo desde el taller hacia el ingeniero para mejorar los diseños continuamente!

Y Luis me terminó de rematar:

Y no sólo eso! Además, cuando se produce una avería los mecánicos se preguntan ¿por que? y no una sino varias veces! Imagínate que me vienes con tu coche con una avería: se ha roto algo y yo te cambio la pieza.. si no me pregunto por qué se ha roto, a los pocos meses vendrás de nuevo a que te arregle la misma avería y encima te cabrearás conmigo porque no te lo he hecho bien.

Hace años hice un curso de Toyota y ahí nos decían que hay que preguntarse por qué pasan las averías y así resolverlas para siempre. Y si es un tema de diseño, podemos decírselo para que arreglen el diseño. Eso no lo tienen las otras marcas!

Imagínate cómo se me quedó el cuerpo.. que Luis, el mecánico de barrio que me arregla el Skoda un día y arregla un Tuareg al otro, dándome clases de Lean! Que gustazo!

Y claro… inmediatamente viene la aplicación en el mundo Lean Service Management: tienes conectado el taller con la fábrica en tu casa? Se enteran los equipos de Arquitectura y de Desarrollo de las causas de las incidencias? Hacen algo con ello?

Si.. ya se… ITIL también habla de Incidencias, Problemas y Cambios, así que podemos usar ese vocabulario también: ¿Tienes Gestión de Problemas en tu casa? Si quieres salir en el informe de la OCU como “Best-In-Class Service Delivery”, ya tardas…

PD: El hecho de tener muy pocas averías, hace que el Toyota tenga un coste de propiedad reducido. Además, hace que el coste de la garantía (para el fabricante) sea menor, y que el coste de mantener una red de talleres gigante y sobredimensionada sea eliminado.

¡Ser bueno es más barato!

Entrevista a un bloguero

Dentro de la iniciativa que ha tenido el itSMF España de conocer a las personas que hay detrás de los blogs y cuentas de twitter más importantes del sector de las Tecnologías de la Información, se ha iniciado una ronda de entrevistas que se publican en el canal de televisión que esta organización tiene en GlobbTV.

El objetivo de estas entrevistas es mostrar que tras estos blogs hay personas, con sus opiniones, sus ideas y sobre todo con “cara y ojos”, de carne y hueso y por eso nos ayudan a “desvirtualizar” a sus autores con entrevistas en video en un formato ligero, entretenido y sobre todo informal.

He tenido el placer de participar (y el honor de ser de los primeros) en esta actividad del itSMF y después de entrenarme un poquito con el software utilizado para la grabación, pudimos registrar esta entrevista que hoy les dejo aquí. Si quieres conocer un poco más de qué se cocina en este blog, de cómo se preparan las entradas o de cuáles son los temas que más nos llaman la atención, sólo tienes que echarle un ojo a la entrevista.

¡¡Espero tu opinión, tus retweets, tus “me gusta” en facebook!!

Crónica de una reparación

Se ve que estos meses son de fallar las cosas, así que esta vez traigo un ejemplo que, si bien es poco importante, me pareció interesante como caso de estudio de cosas que se pueden mejorar en un servicio de atención al cliente.

Antes que nada, no se vayan a pensar que soy un quejica que protesta por cualquier frivolidad: el caso, insisto, no es algo grave ni especialmente molestoso; sólo sirve para analizar un poco el proceso de atención al cliente.

El asunto es que a finales de Agosto se rompió el teléfono fijo de casa. Lo habían traído los Reyes estas navidades pasadas y estaba en garantía, de modo que allá que partimos al centro comercial donde lo habíamos comprado con la esperanza de que nos lo cambiaran por otro.

Aquí aparece el primer mensaje del caso de estudio: vamos a la tienda a realizar una Petición de Servicio porque un aparato se ha roto… ese es el tipo de Demanda más dañino con el que nos podemos encontrar, porque el Centro de Atención al Cliente tendrá que trabajar para algo que no le aporta valor a la organización y sólo me aporta valor a mi porque se ha roto. Se llama Demanda Fallo (Failure Demand) y es algo a evitar a toda costa.

Pregunta: ¿Cuánto invierte tu organización en Demanda Fallo? ¿Se podría evitar? ¿Estaría mejor invertido ese dinero en otro tipo de actividades? [ ¿Cuánto dedicas a mantenimiento correctivo y a gestión de incidencias? ]

Ya habíamos tenido contacto con el Centro de Atención al Cliente de esta tienda, así que sabíamos que nos tocaría aguantar un buen rato de cola… un buen rato, sí, pero… ¿1,5 horas? Así fue… llegamos, pillamos el número del Turn-O-Matic y esperamos… las niñas aburridas, el calor, el ruido… nos leímos el catálogo de ofertas, dimos un paseo por la tienda, esperamos en la calle, esperamos en el CAC… hasta que nos tocó el turno!

Aquí tenemos otro aspecto interesante relacionado con aquellos principios de Lean: 1,5 horas de espera para contactar con un CAC es algo exagerado. El mostrador del CAC tenía 4 terminales, pero sólo había una muchacha atendiendo. Siempre hay unas colas terribles en este lugar, lo que demuestra que el foco está puesto en la venta (asesores, cajeras, de todo! No falta personal en la zona de ventas!)

Después de la espera, la muchacha que nos atendió tomó nota de mis datos y me dijo que enviarían el teléfono a reparar, me pidió la dirección de email y el número de móvil. Me dijo que contara 30 días y que me avisarían para pasar a buscarlo. Firmé el comprobante (en el que decía que lo había entregado todo con el embalaje original) y me fui con la familia a que nos diera el aire en otro sitio.

30 días sin teléfono! No está mal en los tiempos modernos! Aquí no había SLA ni nada parecido, pero en otras ocasiones (un DVD roto, un TDT sin mando… nada importante) ya nos habían dicho siempre que 30 días.

En casa teníamos plan de contingencias: mi mujer, que es súper ordenada y lo guarda todo, tenía el teléfono antiguo; le fallaba el display pero podíamos llamar, así que podíamos esperar 30 días sin mayores problemas.

No habría pasado nada ni yo hubiera escrito esta entrada si no hubiera sido porque un buen día, una semana después de toda esta historia, me llegó un SMS a mi móvil (sin número de origen) que decía literalmente

LE ROGAMOS TRAIGA LOS ACCESORIOS DEL PRODUCTO DEPOSITADO EN NUESTRAS DEPENDENCIAS.

¿Mande? Yo entregué todos los accesorios! Y tengo un comprobante que así lo dice, pero.. el SMS no tenía número, no me habían enviado un mail así que no podía responder… y yo pensaba ¿Otra hora de espera para nada? y ya me iba calentando yo solito…

Total, que cuando llegué a casa llamé por teléfono al sitio en cuestión, a ver si podía aclarar qué accesorio les faltaba… riiing, riiing y me contesta una de esas máquinas odiosas que te preguntan 7 cosas (por ejemplo, me preguntaba 2 veces en qué idioma quería que me atendiera) para al final llegar a que me pedía un número de expediente y me respondía (a la tercera o cuarta, cuando torpe de mi conseguí atinar con el número que me estaba pidiendo) que tenía que pasar por el Centro del Atención al Cliente.

Luego me fui a la web, donde después de mucho buscar encontré un sitio donde si entrabas un número y los apellidos me dijo… ¡Que el aparato estaba listo para su recogida!

Una lección más: cada interacción con el cliente, ya sea humana o mecanizada se convierte en lo que llamamos un momento de la verdad. El servicio de atención se la juega en cada uno de esos momentos y se puede romper toda una buena imagen de atención con un momento de la verdad mal diseñado [un SMS que no me permite responder] o mal ejecutado [una máquina que no me permite interactuar]

Así… ¿qué querían estos señores, que llevara accesorios o que recogiera mi teléfono? Sea como sea, estaba condenado a ir de nuevo a la fatídica tienda… cogí a la familia, otra vez, y nos fuimos al centro comercial.

Entro en el CAC, me voy directo al Turn-O-Matic, cojo mi número y miro al indicador luminoso… que estaba apagado! Miro a mi alrededor y no veo nada que me indique por qué numero van, así que le pregunto a la chica (la misma de la otra vez) y me dice “No, es que está roto.. tiene que pedir la tanda”…

¡Qué graciosa! ¡La tanda, como en la pescadería! Así que pregunto “Quién es última?” y me responden 2 o 3 a la vez… ¡Ya la hemos liado! Mientras nos ponemos de acuerdo han entrado por lo menos 3 personas más al CAC que han ido a coger su numero y no se han dado cuenta de la movida… madre mía la que se está montando!!

Bueno, ahora que la cosa va por tanda no me puedo mover de allí, así que la espera se hace eterna. Unos 40 minutos más tarde me toca el turno y le digo a la chica que me había llegado un SMS diciendo que tenía que entregar accesorios, pero que los accesorios ya los había entregado todos…

“Ah, si..” – Me dijo – “Eso te lo envían cuando te van a hacer una sustitución del aparato; déjame que mire el expediente… a ver… si, aquí está: no tiene reparación, pero como no hay en stock, te haré un vale por el importe del teléfono” y me hizo una tarjeta por unos 40€ que es lo que costaba el maldito aparato…

Aquí podemos ver otra de las “alegrías” del caso: el momento de la verdad estaba tan mal diseñado que enviaba mensajes falsos al cliente! Precisamente el mensaje que me hizo poner de mal humor. Y por si fuera poco, es error habitual que los empleados conocen y les parece tan normal que nadie lo ha resuelto.

Finalmente, me ahorro de discutir con la señorita al respecto de si cuando yo pagué utilicé dinero de verdad o si les pagué con un vale; así que recojo la tarjeta-vale, me voy a la tienda y me compro un teléfono de la misma marca, mejor, más moderno y más barato.. cosas de la tecnología.

Podemos aplicar las ideas de Lean para analizar este caso, más allá de los comentarios que he ido intercalando:

1. El concepto de PathWay nos podría ayudar aquí: habilitar “rutas” especiales para actividades especiales... por ejemplo, una cola para entregar material y otra cola para recogerlo, ya que el procedimiento de entregar el material es mucho más lento que el de recogerlo.
2. El concepto de derroche en forma de tiempos de espera innecesarios, colas, movimiento de materiales (si realmente se llevaron el teléfono a un centro de reparaciones, el gasto fue importante!). ¿Qué tal si se decide que aparatos de menos de 100€ que no funcionen y lo que no funcione no sea una pieza móvil directamente se reembolsan? (Y si después resulta que si que funcionaba o tenía fácil reparación, lo vendes en un outlet tipo cash-converters)
3. El concepto, ¡cómo no! de momento de la verdad: esa máquina de enviar SMS hay que utilizarla lo menos posible: si el cliente ha proporcionado una dirección de email, se le debe enviar un mail para que la comunicación sea bidireccíonal. Y por supuesto, enviando los mensajes correctos! Por otra parte, cuando el Turn-O-Matic no funcione, pon un cartel que así lo indique, que ya nos organizaremos como en la pescadería.
4. El concepto de Actividad de Valor Añadido y Actividad de No Valor Añadido (VA y NVA): si representásemos el mapa de flujo de valor para esta transacción, veríamos que, a grosso modo, hay unas 200 horas de NVA frente a 10 minutos de VA… un ratio de aportación de valor al consumidor del 0,083% (!!!!)
5. El concepto de reducción de las esperas: ¿qué tal si paralelizamos y ponemos a 4 personas a atender en los momentos en los que haya picos de trabajo? Si, ya se que esto de la atención al cliente no aporta ventas pero así como vamos ahora, a)Algunos no vuelven a comprar b)Las extensiones de garantía esas que ofrecen no se deben vender mucho.
6. Walk the Gemba: Womack lo ha defendido en prácticamente todos sus libros; la verdadera gestión se debe ejercer desde el conocimiento de lo que ocurre en el lugar donde se encuentra la verdad (Gemba), osea, donde se trabaja; el director se pasa habitualmente por el CAC? Seguramente no… seguramente no lo utiliza cuando se le rompe uno de sus gadgets, y por lo tanto tienen que ser los clientes los que te hagan ver cómo funciona, visto desde fuera, la atención al cliente.

Bueno.. insisto, este ladrillo es más un ejercicio de análisis que una queja… y quien sabe! Igual los chicos de esa tienda lo leen alguna vez, les sirve de “consultoría gratuita” y la próxima vez que se me rompa alguno de sus productos me llevo una sorpresa tan grata como la del post anterior.

¿Evolución o Revolución?

Uno de los planteamientos que más habitualmente nos encontramos en G2 cuando desarrollamos un Plan Director es la duda que se plantea la organización al respecto del tipo de cambio que se debe impulsar.

¿Qué hacemos? – Nos preguntan – ¿Evolución o Revolución?

Normalmente, las empresas tienen muy en cuenta aquellos grandes (enormes) proyectos de “transformación” en los que realmente se lleva adelante una revolución y se cambian aspectos de la organización considerables. Es el gran cambio, en el que se invierten grandes sumas de dinero y, sobre todo y desde mi humilde punto de vista, el que es más o menos fácil de iniciar/provocar/aprobar/ejecutar simplemente porque es una gran pelota a la que todo el mundo le va a prestar atención, ya sea por involucración, ya sea por implicación o ya sea por compromiso [te acuerdas del desayuno de huevos con jamón y la reacción de la gallina y del cerdo?]

¿Y qué pasa entre revolución y revolución?

Aquí es donde entra en juego la evolución. Evolucionar significa acumular cientos de pequeñas mejoras, ya sean individuales o sean de pequeños grupos, pero pequeños cambios (como decía el  Capità Enciam, “los pequeños cambios son poderosos!”).

Pues precisamente de eso, de los cambios pequeños pero constantes, es de lo que va el Kaizen, concepto Lean que va asociado a la forma de organizar la recogida, análisis y puesta en marcha de todas esas pequeñas iniciativas de mejora continua generadas por todos y cada uno de los trabajadores.

En el Kaizen aparecen un par de conceptos que son la clave de esta evolución organizacional:

1. La fuente de oportunidades de mejora es colectiva: todos los trabajadores participan aportando aquellas ideas que permitan mejorar aunque sea discretamente el trabajo… ¿Conoces esos sitios en los que la gente siempre se está quejando porque hay algún detalle del trabajo que se podría hacer mejor, de otra manera o más cómoda?. En un entorno Kaizen, cada una de estas pequeñas quejas es una oportunidad de mejora, se propone, se estudia y se corrige. En estos sitios, hay un indicador relativo al numero de mejoras x persona x año… en los entornos más comprometidos con la mejora continua nos podemos encontrar con indicadores del calibre de 60 o 70 propuestas de mejora por persona al año… de las cuales se implementan ratios rondando el 90%… ¿Te lo imaginas?
2. La mejora se implementa: tal y como comentaba en el párrafo anterior… Kaizen no es un buzón de sugerencias, es un sistema de mejora continua. Eso significa que no sólo se señalizan los problemas u oportunidades de mejora, sino que se plantean las soluciones, se discuten y se llevan a cabo. Eso significa que la organización evoluciona pero no sólo en el sentido de la eficiencia, o de la mejora hacia la entrega de valor al cliente/consumidor, sino que también mejora en términos de entorno de trabajo, de ambiente para el trabajador… en una organización Lean, la gente trabaja más a gusto.
3. La mejora se extiende: como comentaba en un artículo anterior, el acto del “pequeño cambio poderoso” no termina hasta que se ha extendido a todas las áreas susceptibles de utilizar la mejora. Esto significa que un técnico que implementa un pequeño script para mejorar un aspecto concreto de su trabajo, lo comparte, lo comunica hacia el resto de el/los equipos. A esta propagación de las mejoras se le llama Yokoten.

En una empresa madura en el uso de Kaizen podemos estar hablando de estas 70 propuestas de mejora por persona por año, aunque en una empresa que comienza este indicador se puede posicionar perfectamente en 2 propuestas por persona/año. Eso nos demuestra, por una parte el largo camino que hay por recorrer, y por la otra la necesidad de inculcar el concepto de cultura de mejora y los beneficios inimaginables que se pueden obtener: de repente, la mejora no es cosa de unos “pocos innovadores” sino que se convierte en un comportamiento generalizado en la organización, lo que multiplica el número de cerebros pensantes que tienen ideas por aportar. En contrapartida, el entorno de trabajo se convierte en mucho más motivador simplemente porque las mejoras que propongo veo cómo se llevan adelante, cómo aportan a las personas que tengo a mi alrededor y lentamente (evolutivamente) la empresa avanza.

En definitiva, el poder de las cosas pequeñas pero numerosas… siempre queda oculto, pero desde niños nos lo van inculcando; para muestra, un botón

¿Proveedor o Partner?

Cuando era pequeño, las mañanas de los sábados se dedicaban inevitablemente a las compras semanales para la familia. Salíamos mi madre y yo, carrito de la compra en ristre, rumbo al supermercado y después de ahí al mercado central, a hacer la compra de la fruta y la verdura.

Estas salidas siempre fueron motivo especial de alegría (nunca se sabe lo que vas a encontrar en el mercado!) y de aprendizaje, ya que mi madre siempre aprovechaba cualquier ocasión para enseñarme las cosas de la vida y el mercado era la fuente principal de lecciones sobre Relación con Proveedores.

Íbamos siempre a los mismos puestos, siguiendo siempre la misma ruta, y comprando siempre a las mismas tenderas, salvo que alguna no tuviese lo que buscábamos y en ese caso ellas mismas nos indicaban a qué puesto teníamos que ir (bueno, en realidad era la propia tendera la que decía “Manolo, vete al puesto de Josefa y pídele una calabaza. Que sea buena, que es para la Señora Bernardita”, y allá que iba el señor Manolo a buscarnos la mejor calabaza del mercado)

Era bastante habitual que volviésemos a casa, además de con el carrito lleno, con una caja de fruta remadura que no se podía vender y que nosotros convertíamos en mermelada o con unos cuantos calabacines que de puro feos no tenían salida, pero que convertidos en puré estaban exquisitos.

La clave está en comprar siempre en el mismo sitio, en tejer una relación de confianza con las señoras de los puestos para que te cuiden porque eres un buen cliente. Los que compran cada día en un sitio, buscando siempre el mejor precio, seguramente se ahorran unas pesetillas, pero no se llevarán el mejor género porque ese se guarda para la gente de confianza

Ni mi madre ni yo somos de madrugar, así que las visitas al mercado eran más bien tardías… pero siempre había buen género para la Señora Bernardita.

Cuando se establece una relación ventajosa entre un cliente y un proveedor, en la que el cliente trata con respeto y lealtad al proveedor y éste responde con implicación y valor añadido se están dando los primeros pasos para convertir a este proveedor en un Partner.

Partner es una palabra inglesa, que significa literalmente “an associate who works with others toward a common goal”, un asociado que trabaja con otros para conseguir (y aquí es donde viene lo bueno) lograr unos objetivos comunes. Los objetivos de un partner tienen que ser comunes a los de sus asociados, o no será un partner.

Así, es necesario que el proveedor vea en el cliente una relación de larga duración y que desee cuidarla (idea totalmente contraria a la “cultura del pelotazo” en la que si le puedo enchufar sea como sea el mega-proyecto al cliente ya soy feliz).

Esta relación de larga duración le dará al proveedor algo que es especialmente importante: conocimiento de su cliente. Cuando conoces a tu cliente, puedes precisamente dar esa pieza de valor añadido de la que hablábamos antes…. Amazon puede ser mi proveedor de libros, pero jamás (al menos por ahora) podrá ser mi “partner en asuntos de libros”, porque no me conoce, no sabe mis gustos y no puede escuchar mis opiniones al respecto (van por ese camino, pero aún les queda mucho!)

Sin embargo, el señor de la librería a la que siempre voy ya sabe qué libros me gustan y me puede sugerir “llévate este que me acaba de llegar que seguro que te gustará”; y esa sugerencia estará en línea con mis gustos literarios (confianza, valor añadido) y no será dada porque ese sea el libro que más margen le esté dando al librero ese mes (cultura del pelotazo).

Pero para que el proveedor pueda tener ese conocimiento y ese interés en fomentar la relación a largo plazo, le hace falta algo que tiene que aportar el cliente: lealtad y flexibilidad. La lealtad hace que “siempre vaya a comprar al mismo sitio” y la flexibilidad hace que no intente apretar al señor Manolo para que me ponga las naranjas al mismo precio que el más barato del mercado, porque el señor Manolo tiene que ganarse la vida.

Y aquí está el equilibrio necesario: el Partner tiene que poderse ganar la vida y el cliente tiene que permitírselo, al tiempo que vigila que no “se le suban los humos” y deje de ser interesante la relación.

CLIENTE	PARTNER
Respeto	Implicación
Lealtad	Conocimiento
Transparencia	Valor Añadido
Flexibilidad	No excesiva ambición
Confianza	Confianza

Y así, a través de este tipo de relación entre organizaciones, el cliente se beneficia de productos y servicios ofrecidos con un “extra” de valor añadido que es realmente importante (y más en estos tiempos que corren) y el partner se beneficia por tener clientes fieles que hacen de altavoz de sus excelencias.

Sobre las ventajas de la confianza y el conocimiento del cliente a la hora de proponer productos y servicios de alto valor añadido ya hablaremos en otra ocasión-

Por último, si quieres leer un poco más sobre el tema, te recomiendo los primeros capítulos de Universal Service Management Body of Knowledge (USMBOK), de Ian Clayton.

La Guerra de los Ingenieros Informáticos

Llevo ya varios días dándole vueltas a cuál es la postura adecuada ante el jaleo que se ha montado y se está montando alrededor del futuro de la titulación de Ingeniero Informático en España.

El tema es complicado, porque se mezclan varios conceptos y además, al ser algo que te toca de cerca, es fácil que la sangre se caliente y no demos tiempo suficiente a la cabeza a procesar. Así que he leído de varias fuentes, he esperado a ver la postura oficial de ATI y de los Colegios, y al final más o menos me he hecho una opinión.

Primero, voy a dar las fuentes de las que he leído:

1. http://www.huelgainformatica.es/ es el website que corrió como la pólvora por la red y que me pasaron varios de los colegas de profesión. Nada como una buena web revulsiva y un efecto viral para que la problemática de la titulación se conozca rápidamente.
2. http://www.coetic.org/ es la web del Colegio Oficial de Ingeniería Técnica de Catalunya
3. http://dafib.upc.edu/ es la web de la Delegación de Alumnos de la Facultad de Informática de Barcelona (FIB)
4. http://www.ati.es/article.php3?id_article=1077 es la posición oficial de la ATI al respecto
5. La Carta Abierta del Decano de la UPV, donde explica algunas posturas
6. Bolonia for Dummies, un website con FAQs sobre el asunto
7. Libro Blanco del Título de Grado en Ingeniería Informática

Al final, lo que ocurre es que el Tratado de Bolonia ha puesto en relevancia algo que venía ocurriendo de lejos: la profesión de Ingeniero Informático (que no de Informático... eso es lo primero) está ligeramente desprestigiada y se le ha hecho un trato de agravio comparativo en relación a otras ingenierías; pero como los IIII, o sea, I4 (Ingenieros Informáticos) no somos un colectivo especialmente social, gregario y luchador por nuestros intereses sociales, no hemos hecho nada.

...Y nada quiere decir que cuando se ha hablado de Colegio, hemos dicho que no queríamos que nadie nos "chupara la sangre" (se ha demostrado con las bajísimas tasas de "colegiación") al mismo tiempo que decíamos aquello de "es que estamos hartos de que haya tantísimo intrusismo profesional".

El núcleo de la discusión son dos palabras que hay que mirarse con cuidado y un problema filosófico que hay que resolver. Las dos palabras son COMPETENCIAS y ATRIBUCIONES

Las COMPETENCIAS tienen que ver con los contenidos de la carrera, con aquellos conocimientos que los I4 deben tener para ejercer su profesión de manera competente y esto es la base para regular con planes de estudio ya que establece los contenidos mínimos de la titulación. En la situación actual, la Ingeniería Informática es una de las carreras que no tiene definida la ficha de competencias y por lo tanto queda a voluntad de cada universidad el decidir los contenidos que se enseñan.

Esta situación puede parecer que beneficia a las Universidades, que podrán desarrollar productos diferenciados de la competencia, pero también ocurre que a la larga no creo que beneficie a la profesión ya que no habrá un concepto claro y más o menos unificado de qué significa el título. Es decir, cuando el mercado busque a un profesional que deba cumplir las características A, B y C y un II se presente con su título obtenido en la UPC , en la ULPGC o en la ULDCDSA  los títulos no serán comparables ya que cada uno será "de su padre y de su madre".

A la larga, y teniendo en cuenta además una situación de globalización y de homogeneización de otras ingenierías a nivel europeo, ¿qué pedirá el mercado laboral? Además de buenos profesionales, se sentirá más cómodo con títulos con contenidos estandarizados (aquellos que tienen ficha de competencias a nivel paneuropeo) o con títulos de fama reconocida (provenientes de Universidades con reconocimiento global -- nadie rechaza un título del MIT, aun sin conocer los planes de estudio, no? )

Las ATRIBUCIONES tienen que ver con actividades reguladas por Ley que hacen que, para realizarlas, sea obligatorio disponer de una titulación especial (por ejemplo, un Médico puede recetar antibióticos, pero un Físico no). En mi opinión, estas atribuciones no pueden salir de las Universidades, sino que deben ser los órganos legisladores quienes las atribuyan en función de lo que vaya necesitando la legislación vigente y lo que vaya reclamando la sociedad.

En estos momentos no existe ninguna actividad regulada en el mundo de la Informática (al menos que yo sepa), pero un ejemplo clarísimo de este tipo de actividad que si debería estar regulada es la auditoría de LOPD, donde la ley crea la necesidad de auditoría, explicita la figura del auditor y sin embargo no explicita quién y bajo qué supuestos puede realizar esta auditoría. El resultado de esta situación es bien conocido: todo Dios está haciendo auditorías de LOPD, sabiendo o sin saber, y además ISACA está intentando que la certificación CISA sea la necesaria para poder realizar estas auditorías. ¿No sería mucho más coherente (que no mejor) que fuera una certificación propuesta por el Colegio (inexistente?) ?

Por último, está el tema del PROBLEMA FILOSOFICO que comentaba al principio: creo que es muy importante tener en cuenta que la provisión de servicios Informáticos se nutre de un conjunto muy variado de titulaciones (a parte de las que no son explicitamente de informática y se pueden considerar como intrusismo profesional). Al igual que en la provisión de servicios de salud intervienen médicos, enfermeras, celadores, farmacéuticos... en la provisión de servicios TIC intervienen I4 , Ciclos Formativos, Telecos, etc.

Así, la duda filosófica que hay que resolver para zanjar este asunto es, ante todo, ¿qué es y para qué sirve un II ? Parece una tontería, así escrito; pero en las últimas dos semanas he recibido un par de inputs que refuerzan esta pregunta: 

por una parte, en una reunión en la que se comentaba la idoneidad de incorporar contenidos sobre la Gestión de Servicios TIC en los temarios de las universidades, ante mi afirmación de esto es importante si queremos que las Universidades formen a los profesionales que necesitarán mañana la sociedad y las empresas la respuesta fue: es que lo que no está claro es si las Universidades deben formar a los profesionales del mañana o a los investigadores del mañana

¡¡La Leche!! Si eso no está claro, todo lo demás se tambalea! Y además, eso explica lo alejado del mundo real que está un recién licenciado, no?

El segundo input fue el desayuno de trabajo que organizó la ATI y el FOBSIC para la presentación del informe "Los profesionales TIC en Catalunya, La visión empresarial de las necesidades a corto plazo", donde una de las afirmaciones que se hicieron fue que las empresas en realidad querían contratar titulaciones de FP (Ciclos Formativos), pero que en realidad había tal cantidad de Ingenieros, que acababan contratando ingenieros al mismo precio.

Esta problemática se podría mitigar aunque fuera ligeramente con el uso correcto (y divulgado) de esas fichas de competencias, de tal manera que las empresas supieran qué es un II y qué es un FP y los futuros alumnos supieran exactamente para qué se les va a capacitar en la elección de carrera de estudios que hagan.

Como CONCLUSION, creo que es necesario apoyar la definición de las competencias, que es importantísimo establecer claramente las competencias núcleo de la Ingeniería Informática y que esto no excluye que aparezcan competencias (conocimientos) propias de las Ingenierías Informáticas en otras carreras.

Al mismo tiempo, creo que los cuerpos legisladores deben regular alguna que otra parte de la profesión (como el ejemplo de auditor LOPD y quizás el de perito y alguno más que ahora no se me ocurre), pero no es algo que me quite especialmente el sueño.

Y, en definitiva, esa es mi opinión al respecto. ¿Huelga? No lo se... no hay suficiente unidad en el colectivo como para que yo crea que va a tener algún éxito. Además, una huelga de informáticos es algo sin precedentes y que es un arma lo suficientemente potente como para tener que tener muy pero que muy mucho cuidado en usarla... no se puede dar una respuesta desmesurada.

Ahora bien, manis? las que haga falta. en Barcelona está convocada ¿Y en tu ciudad?

 POSTDATA: No se dónde lo leí, pero en algún sitio decía que la II no tenía competencias definidas porque algún estamento había determinado que la Informática es una materia horizontal, utilizada en todas las ingenierías... Eso me puso de muy, pero que de muy mal humor porque es de una simpleza tan grande que no me lo podía creer.

En todas las casas del país hay un botiquín y posiblemente el 90% de los adultos nos automedicamos, pero no por ello la medicina es una materia horizontal ni la automedicación es buena. En todas las carreras se estudia Matemáticas, pero no por ello es una materia horizontal. Para sintonizar el TDT no necesito ser un Telecos, pero para diseñar la red de transmisión y su cobertura posiblemente si.

Señores... los Ingenieros Informáticos no sólo arreglan el PC del vecino cuando se estropea: también diseñamos el sistema de información del Servicio Nacional de Salud o los servicios de apoyo a la navegación de AENA y si eso se para, hay vidas en juego. Exactamente igual que cuando un arquitecto diseña un edificio.

¿En qué otra ingeniería caben las competencias de Arquitectura Tecnológica, SOA, Calidad del Software, Seguridad de la Información o Gestión de Servicios? ¿En la de Física, Matemáticas, Telecos? ¿O en la carrera de Derecho? [porque todos usan un PC para su trabajo... y mi primo hizo un cursillo en CCC]

La Informática es algo más que el Word y el Excel.

Perdón por el ladrillo.

[Imagen por Michael Connors en Morguefile]