E018 – Business Agility, la respuesta al cambio de las organizaciones
Realworld forma parte de Redcast, la red de podcasts del mundo digital.
Suscríbete en: Spotify | Apple Podcasts | Google Podcasts
Cuando hablamos de Business Agility, nos referimos a la capacidad de las organizaciones de adaptarse a nuevos contextos, de responder rápidamente a un cambio.
Comentábamos en el E011 ¿Qué es Agile y por qué clave en la Transformación Digital de una empresa? (que no es exactamente lo mismo), cómo los modelos de negocio se están transformando. Cómo la tecnología no sólo está trayendo nuevos modelos, sino que literalmente está poniendo patas arriba a sectores muy tradicionales, fuertemente establecidos…
En esta ocasión, tengo el placer de presentar a Jaume Jornet, Lean Kanban & Agile Coach.
Me gustaría que le expliques a la audiencia quién eres, qué haces y cómo has llegado ahí.
Complicado, muy difícil. Bueno quien soy, soy muchas cosas, soy padre y entiendo que la pregunta también me orientaba qué hago, a qué me dedico. Nos conocemos del ámbito Agile el de la comunidad y es lo que hago ayudo a organizaciones que quieren trabajar de una forma más ágil. Y, si a día de hoy puedo hacer lo que estoy haciendo, es gracias a todo lo que he estado aprendiendo de la comunidad Agile de Barcelona, de donde nos hemos conocido y donde seguimos participando.
¿Qué haces ahora? ¿A qué te dedicas tu día a día?
Mi día a día normalmente involucra ayudar a organizaciones. Ayudo a personas que trabajan en organizaciones que tener procesos más ágiles, y esto habría que enmarcarlo en que entendemos como ágil -porque cada organización será diferente que entienda cómo ágil- pero quieren de alguna manera mejorar su agilidad en el negocio.
¿Y cómo has llegado aquí? ¿Cuál es tu background y cómo empezaste? Tu eres un técnico, tienes un pasado turbio...
Sucio… (risas). Fue extraño como cómo he llegado aquí porque yo desarrollaba software durante muchos años. Los últimos años, muy grandes, que involucraban a mucha gente, y esto me hizo llegar a un momento en el que parte de mi trabajo ya no era únicamente desarrollar software sino también ayudar a personas que estábamos en equipos desarrollando software.
Eso me llevó a darme cuenta que no tenía ni idea de cómo tratar con personas, de cómo ayudarles y, buscando qué podría aprender o cómo podría mejorar para hacer esta parte, entré en contacto con las metodologías ágiles y fue el principio del fin. Cada vez leía más sobre Scrum, sobre motivación, sobre este tipo de cosas... Hasta que llegó un momento que se lo planteé a mi mujer y le dije: “Oye yo quiero dedicarme a esto”.
Me dijo: “Estás loco tú. Trabajar con personas, no sabes lo que es eso”. Dije: “Bueno, pero creo que puedo aprender”.
Y bueno, fue un cambio o fue un cambio grande, porque además involucraba un salto al vacío, dejar lo que sabes hacer, lo que has estado haciendo durante 15 años para empezar una profesión en los que tus años de experiencia son cero.
Yo he tenido la suerte de vivir gran parte de ese arco de evolución de Jaume y realmente es impresionante. O sea yo lo digo de forma muy sincera, Jaume está trabajando con grandes organizaciones. No sé si lo puedes decir con qué tipo de clientes trabajas.
Bueno, sí, normalmente con empresas grandes, bancos, empresas de seguros muy grandes, de manufacturing muy grandes, consultoras muy grandes. Afortunadamente, de lo que me siento más afortunado en los últimos años es que efectivamente estos clientes están ahí. Trabajo para estas grandes empresas pero eso, además, me ha permitido trabajar en contextos en los que muchas veces no trabajamos como fundaciones o oenegés que igual no se pueden permitir - no quiero decir no puedan permitírselo - pero sí que tienen cosas mejores a las dedicar sus recursos que contratar servicios de Agile Coach. Y el poder trabajar en unos entornos me ha permitido trabajar en otros que es donde me nutre más.
De qué hablamos cuando hablamos de Business Agility, agilidad de negocio. ¿A qué nos referimos con esto?
Cuando hablamos de business agility me gusta diferenciarlo porque muchas veces hablamos de Agile en general y, diferentes personas con diferentes percepciones y en diferentes momentos, entenderán Agile de formas muy diferentes. ¿Qué significa agile para ti en Runroom o qué puede significar allá para Zurich, para Seat? Seguramente sea muy diferente cuando hablamos de business agility y estamos hablando precisamente de cómo podemos dotar a la organización de agilidad en sus procesos de manera que puedan tener esa adaptabilidad para servir mejor a sus clientes, sea lo que sea lo que hacen para servir a sus clientes.
¿Pero cómo podemos tener una visión más holística? Ya no se trata tanto de "quiero mejorar en determinada área, quiero mejorar como funciona este determinado equipo, quiero mejorar cómo funciona este determinado proceso", es decir, ¿cómo la forma en la que estás trabajando está afectando al valor que aportas a tus clientes? ¿Qué es ese valor que esperan tus clientes y cómo podemos orientarnos totalmente y decidir cómo trabajar de una forma que maximice ese valor o que permita que ese valor llegue antes?
Ahí entra la parte de “qué es para ti ágil”.
Hablábamos fuera de micro, antes de empezar la entrevista, precisamente sobre el concepto fitness for purpose de David (Anderson), relacionándolo con qué significa agilidad de negocio.
Por esto es bueno David Anderson, que es el creador de Kanban, que escribió el libro de Kanban. Ha escrito un libro recientemente que se titula Fitness for purpose y él pone en este libro algo que ya, desde hace muchos años, utilizamos dentro de esta comunidad de Kanban: ver la organización como un conjunto de servicios y entender cuál es el propósito de cada uno de estos servicios. Por qué hacemos lo que hacemos. Por qué nuestros clientes deciden contratarnos a nosotros y no a otros. Qué valoran nuestros clientes.
Lo que buscamos es entender ese purpose, ese propósito y entonces crear la organización más fitness, no sabría cómo traducirlo al castellano, más adecuada a servir a ese propósito. Si ponemos un ejemplo lo entenderás muy bien. Tú puedes decir yo me dedico al mercado de hacer pizzas. Es totalmente diferente. Si yo soy una gran cadena, un Dominos Pizza, o si es pizza de autor. Lo que valoran mis clientes de mi es totalmente diferente. Y el tipo de organización, de estructuras y procesos que crearé para servir a un tipo de cliente o a otro serán totalmente diferentes.
No se trata de juzgar y decir cómo es El Bulli, es mucho mejor que la calidad que te pueda dar un MacDonalds. MacDonalds está optimizado para el propósito al que sirve, que es comida rápida que se pueda servir y El Bulli está optimizado para el propósito que sirve, que es cocina de vanguardia, etcétera. Fijaros que no son comparables entre ellos pero sí que de alguna manera necesitamos entender qué es lo que queremos conseguir para crear estructuras que nos permitan maximizar esto.
Me estaba ahora acordndo un poco de que, hace una década, nos centrabamos muchos en equipos. Nos centramos mucho en cómo trabajan nuestros equipos y teníamos una visión quizá endogámica. De alguna forma, ese cambio de perspectiva va un poco a subrayar el negocio y la entrega de valor a los clientes.
Lo que viene a decir de David Anderson con el fitness for purpose es que de lo que se trata es de adaptar la totalidad de la estructura de la compañía a esa entrega de valor.
Ya no se trata de hacer Scrum en nuestro departamento de IT. Es una visión mucho más amplia y mucho más de negocio. Yo siempre he dicho en este podcast que para mí la agilidad tenía que ver con esa capacidad de adaptación al mercado y con esa capacidad de respuesta de ser ágiles y ser rápidos en el sentido de poder ofrecer una respuesta ágil y rápida a una oportunidad de mercado o una necesidad de mercado.
Hay un concepto que a ti últimamente te escucho mucho hablar de él que es el tema del cost of delay, del coste de retraso. ¿Podrías introducir un poquito el concepto a la comunidad de “en el mundo real”?
Esto es una idea muy sencilla. Cost of delay no deja de ser la idea de que, sea lo que sea lo que haces, el producto que ofreces o el servicio que ofreces, hay una diferencia entre que tu cliente disponga de ese producto o de ese servicio este viernes o dentro de dos meses. Si no hay ninguna diferencia, si da igual que ese servicio esté disponible este viernes o dentro de dos meses, no hay cost of delay.
Pero sí hay cost of delay sí hay una diferencia. ¿Cuál es esa diferencia? ¿Cuál es el coste de llegar tarde? Y fijaros que es una perspectiva que nos sitúa mucho en la perspectiva del valor, entendiendo el valor no como algo estático. En estas grandes organizaciones que comentábamos antes, nosotros a veces nos encontramos con procesos tradicionales y largos que involucran a negocio, finanzas, legal... El otro día estaba con unas personas que me contaban cómo funciona su proceso de gestión de la demanda, cómo deciden los proyectos que van a trabajar el año siguiente. Son proyectos que después duran un año o un año y medio, y había un momento que decía: “espera, déjame que lo entienda, ¿me estáis diciendo que durante un año, de marzo a diciembre, trabajáis en decidir qué proyectos haréis en 2019?”. No se empezarán todos el 1 de enero de 2019. Pongamos que de media se empezarían en mitad de año y que estos proyectos duran un año. ¿En serio alguien se presenta en el comité de dirección diciendo “traigo aquí una idea de negocio que me parece que lo va a petar en 2021"? Porque de esto es de lo que estamos hablando cuando tenemos estos procesos tan largos.
Business Agility es dotar a la organización de agilidad en sus procesos de manera que puedan tener esa adaptabilidad para servir mejor a sus clientes.
¿Cuál es el cost of delay de esa idea de negocio?
¿Cuál es la diferencia entre poder tenerla ahora, a final de año, en el primer cuarto de 2019 o tenerla en 2021? Cada vez más los contextos en los que nos encontramos se ven más afectados por cost of delay. Ser capaz de cuantificarlo te pone en la mentalidad de entender qué es lo que provoca en una organización que tú tengas un determinado proceso o una determinada forma de trabajar que acaba haciendo que tus proyectos, cuando detectas una necesidad de tu cliente y te focaliza totalmente en ella, consigas satisfacerla dentro de un año. Hay una gran posibilidad de que, o el cliente haya cambiado de idea y ya no le aporte tanto valor, o de que otro agente de tu competencia la haya satisfecho.
El valor de lo que hacemos no es estático. No se puede decir "esta funcionalidad nos da un millón de euros". Esta funcionalidad nos da un millón de euros en este momento del tiempo.
Pero fijaros que todavía muchas organizaciones tenemos una visión muy estática. Nosotros nos encontramos con estos business case que tienen un número al final y un número estático que acaba diciendo “creeemos que esta idea de negocio, si la implementamos y la ponemos en el mercado, nos acabará repercutiendo en un millón de euros”. ¿Nos dará un millón de euros siempre o nos dará un millón de euros si la tenemos al final de año? ¿O medio millón si la tenemos a mitad de 2019 y cero si la tenemos al final de 2019?
El valor de lo que hacemos no es estático. No se puede decir "esta funcionalidad nos da un millón de euros". Esta funcionalidad nos da un millón de euros en este momento del tiempo. Tres meses después, este nivel de dinero. Tres meses después, este otro nivel de dinero.
Eso es business agility y eso es cost of delay.
Según tu experiencia, ¿qué implicaciones tiene ser consciente de esto? ¿Cómo se transforma una compañía para tomar decisiones desde el punto de vista del cost of delay y para aprovechar esas oportunidades de negocio de una forma mucho más efectiva? ¿Donde debe poner el foco?
Bueno, seguramente depende de cuál sea tu contexto, depende de cuál sea tu situación, pondrás el foco en las cosas. Antes mencionabas esos tres pilares que hablábamos de business agility - flujo colaboración y mejora continua -. Fijaros que son ideas muy sencillas, es decir, ¿cuál es el flujo de toda aportación de valor para intentar maximizarlo? Probablemente, para poder maximizarlo, tendrás que fomentar la colaboración entre distintas áreas.
Lo que encontramos dentro de estas grandes organizaciones es que muchos de los tiempos que provocan que yo no pueda servir a mis clientes a principios de 2019 sino que lo haga al final, son tiempos de espera y tiempos de traspaso entre distintas partes. Cuando intervienen legal, finanzas y operaciones para acabar entrando y creando IT.
Los tiempos no están tanto en cuánto tiempo dedican ellos a hacer su trabajo, sino cuánto tiempo está esperando un paso al otro. De manera que podemos maximizar cómo llegamos a ese valor no optimizando que IT trabaje más rápido o que legal haga el trabajo más rápido. Sino que, simplemente, entre que una parte ya ha acabado su trabajo y empieza el siguiente trabajo, pase el menor tiempo posible.
Minimizando los tiempos de espera, digamos. Me daba mucho miedo introducir el tema Flow. Me da la sensación de que hablar de Flow difícilmente traslada el conocimiento del concepto al receptor del mensaje.
Podríamos intentar explicar un caso real, un ejemplo real que haga que se pueda entender. Hace ya dos o tres años, un gran banco me contrató para poder ayudar a el área de canales, que son los que hacen la aplicación móvil, la web, etcétera.
En aquel momento el proyecto estrella era Instant Payments, el tema de poder hacer pagos de móvil a móvil. Ya algunas entidades bancarias lo tenían pero sólo dentro de su entidad bancaria. Todo esto venía de una iniciativa del Banco Central Europeo que dijo que “todos los bancos en Europa deberían tener esta capacidad” en 2018-2019, y el Banco Central de Crédito Español decidió adelantarse y decir “nosotros lo tendremos antes, lo tendremos en 2016 o 2017, junto a todos los bancos” y se establecieron dos momentos de salida, dos velocidades. Un grueso de bancos salía en una fecha y el otro salía cuatro meses después.
Todos los grandes bancos estaban en la primera fecha. Fijaros, si enlazamos con lo que decíamos antes del cost of delay, ¿cuál es el costo de no salir en la primera fecha? Aunque todo el mundo sabía que no llegaba a la primera fecha, nadie lo decía porque corría el riesgo de que te pusiesen en el segundo grupo. Y si yo soy una gran entidad financiera y no salgo en el primer grupo, ¿qué pasa con mis clientes que trabajan con distintas entidades financieras que suelen ser los más atractivos para mí?
Todos sabían que no llegaban a la primera fecha. Nadie lo decía. Uno de los grandes focos era ayuda al área de canales porque necesitan dentro de dos meses sacar este agreement.
Obviamente lo hacíamos, lo orientamos. Pero yo recuerdo una conversación en la que decía ”Ok. No sabemos si lo conseguiremos" y un poco también "qué cabrón el Banco de España porque al final daros sólo dos meses para hacer el proyecto de Instant Payment…”. Pero en realidad no eran dos meses. Al inicio teníamos 18 meses. De esos 18 meses primeros, tuvimos una serie de meses pensando qué áreas deberían participar aquí. Luego aquello se quedó parado hasta que operaciones hizo una licitación y se decidió cómo deberíamos contratar a los proveedores. Entonces, aquello entró dentro de unos procesos de compras que acabó quedando en crear una capacidad de equipos y ahora hemos llegado al momento en el que sólo tenemos dos meses.
Si tú mides todo lo que ha pasado desde esos 18 meses, lo que vas a observar es que seguramente el tiempo que realmente hemos estado trabajando en Instant Payments, comparativamente con el tiempo que algo se ha quedado en "dentro de un mes sabremos", "dentro de dos meses decidiremos"… Será mucho menor el tiempo del trabajo. ¿Por qué esto se produce? Porque seguramente tu organización está más orientada a optimizar cada una de las partes que no el flujo en total. No hemos pensado sobre cómo consigo que el proyecto de Instant Payments proceda lo más rápido posible.
Todo el trabajo que hace finanzas es muy eficiente en finanzas, las mesas de compras son muy eficientes haciendo la compra... Pero no me he molestado en ver cómo esas distintas piezas están encajando entre ellas y qué está provocando esos silos dentro de la organización, que lo que está provocando es 16 meses de retrasos para llegar al final a dos meses de algo que tiene un impacto económico, un cost of delay enorme.
Ahora Agile es una idea viejuna. Si lo piensas, no estamos hablando de algo que ha aparecido hace dos años, sino que el manifiesto es de 2001, estamos hablando de 18 años ya. Sin embargo, todavía se sigue percibiendo como algo nuevo.
Sí, yo supongo que hemos aprendido a resolver la complejidad de lo que representa escalar un negocio en cuanto a trabajar con miles de personas. Hemos pretendido modelar esa complejidad poniendo estructuras rígidas, procesos muy cerrados, burocracia muy pesada, precisamente para no tomar decisiones a la ligera y para al menos tener la sensación de control constante sobre todo lo que está sucediendo y, probablemente, incluso diría que eso en algún momento de la historia de los mercados funcionó. Pero de alguna manera hoy estamos en otro contexto, en un contexto súper cambiante, un contexto de tecnologías disruptivas constantemente. No sabemos qué va a pasar de aquí seis meses. No tenemos ni idea ni a nivel legislativo ni en ningún otro nivel. Entonces claro hemos aprendido a hacer las cosas de una determinada manera y hoy de alguna forma nos estamos dando cuenta de que eso quizá no es lo más efectivo desde el punto de vista de la entrega de valor o de la oportunidad de negocio.
Cuando comenzamos nuestras organizaciones eran momentos del tiempo diferente. Yo suelo decir que ahora Agile es una idea viejuna. Si lo piensas, no estamos hablando de algo que ha aparecido hace dos años, sino que el manifiesto es de 2001, estamos hablando de 18 años ya. Sin embargo, todavía se sigue percibiendo como algo nuevo. El motivo de esto es que no empezamos hace 18 años, Agile está llegando a estas grandes organizaciones, a estos sectores o saliendo de aire para llegar a una gran cantidad de sectores en los últimos cuatro o cinco años.
El motivo no es que seamos más guapos o mejores que otras metodologías, simplemente nos adaptamos más a los contextos actuales. Los contextos de hace diez años eran más estáticos. Los contextos actuales requieren de dotar a mi organización de capacidad para poder adaptarme dentro de esos periodos de tiempo y es lo que hace que cada vez más organizaciones quieran de alguna manera adoptar Agile o empiezan a pensar en esta agilidad empresarial porque tiene valor en el contexto actual. Porque cada vez más el cost of delay… Si yo evaluase o crease un marco económico de todas las cosas que me afectan desde el punto de vista de negocio encontraría que probablemente cost of delay es una de las variables que más afección. Tiene más afección si un proyecto se retrasa un mes, dos meses, tres meses desde el punto de vista de coste oportunidad, de imagen, de penetración de mercado, de muchas variables que tienen sentido para mí, que no si estoy gestionando los recursos de mi departamento de legal de una forma más eficiente o menos y tiene sentido.
Si lo piensas desde una forma muy simplista, siempre todo lo que hacemos debería aportar más valor que el coste que cuesta producirlo. Seguimos optimizando el lado del coste cuando el lado del valor cada vez más... Yo recuerdo un podcast en el que hablabas precisamente entre la diferencia entre el coste de producción y el valor, que cada vez eso está más alejado. Seguimos optimizando en el lado que es más estático, cuando eso es lo que provoca es penalización en el otro lado porque cada vez que penaliza en el tiempo penalizo en el valor que puedo aportar al cliente.
¿Eres partidario de medir entonces el cost of delay?
Muchísimo.
¿Es factible medir el cost of delay?
Desde una perspectiva determinista de saber directamente “mi cost of delay va a ser veinte mil quinientos euros a la semana” seguramente, no. Y todavía muchas personas tienen esa mentalidad. Pero es que el valor que encontramos también es mover esa mentalidad desde el punto determinista al punto estadista. Para mí el valor que aportan las organizaciones en muchos casos empezar a trabajar con cost of delay, no es simplemente tener esa medida - que no deja de ser una hipótesis, que no deja de ser un business case, un estudio de mercado - hay alguien que apuesta a que en el momento que pongamos esto en el mercado nos dará un millón de euros.
Pero fíjate que la toma de decisiones producida a raíz del cost of delay obliga a que toda la organización seamos conscientes de cuál es el propósito de mi organización, de cómo mido, por qué mis clientes me seleccionan. Si mañana tengo que tomar una decisión, tomaré una decisión sabiendo cómo eso va a afectar al retraso o no retraso de este proyecto y qué impacto tiene en el valor que perciben mis clientes. Alinear a toda la organización es lo que para mí realmente da un gran valor a empezar a trabajar con cost of delay. No es el número, me da igual que sean porque realmente si acabamos pensando “dará igual que sea un millón 800 mil que sea un millón 200…” Lo importante es que donde tengamos el foco, qué estamos utilizando para tomar nuestras decisiones.
Me lleva esta conversación a la conversación que tuve con Javier Gallardo en el último episodio, donde hablábamos de NPS, cuando hablamos de net promoter score. Y con Javier un poco al final la conclusión era que NPS puede ser muy útil no desde un punto de vista determinista, no desde un punto de vista del valor absoluto, de qué numerito te ha salido a ti porque no tienen la menor importancia final, porque es una métrica un poquito volátil. Si no que realmente, donde nos es útil es entender el porqué, el porqué de esa valoración, entender cuáles son los motivos y desde qué perspectivas nos están juzgando nuestros clientes y por qué nos recomendarían o no nos recomendarían. Ahí es donde realmente está la potencia. Desde un punto de vista de agilidad de negocio qué métricas debemos tener.
Bueno, aquellas que permitan medir el servicio que tu estás ofreciendo a tus clientes. Precisamente el porqué te valoran tus clientes, tus distintos clientes porque tendrás distintas motivaciones y qué es lo que les hace tomar la decisión de trabajar contigo o contratar tus productos, comprar tus productos y contratar sus servicios.
Yo hace poco me hacía mucha gracia pero me parecía curioso porque estaba viendo las noticias y salía una noticia sobre Rynair. Había tomado una decisión en la que decía que íbamos a tener que pagar por el equipaje en cabina pero que eso lo hacía por nuestro bien, por el bien de los usuarios que consumimos Rynair porque su métrica de tiempos de despegue, cuántas veces despego a la hora, se había reducido. Si antes estaba en el 96 o 98 por ciento que eran los estándares que ellos habían determinado que querían para ellos, había bajado hasta el 90 o incluso por debajo del 90. entonces habían tomado decisiones...
Bueno, ¿es realmente la métrica de que el vuelo despegue a la hora lo que valoran tus clientes? ¿O lo que valoran tus clientes es que el vuelo aterrice? Porque fíjate que tú puedes despegar tarde y aterrizar en hora, simplemente gastarás más combustible para ir más rápido. Es algo que obviamente no va a querer. Mi métrica de que el vuelo despegue en hora no deja de ser una “vanity metric”, bonita métrica, una métrica que utilizas simplemente para mirarte al espejo y hacerte sentir bien. Como una de las cosas que hago bien es despegar en hora, pues voy a reportar que despego 98 por ciento de veces en hora asumiendo que eso es algo que valoran mis clientes.
Si realmente te pusiste a pensar y tus clientes valoran más el llegar en hora, empieza a medir eso y mide esa diferencia entre llegar en horas y no llegar en hora qué supone para ti: dejan de contratarte y dejan de si siguen contratando pero están dispuestos a pagar un precio más pequeño. Fíjate que todo eso es lo que tienes que plantearte cuando intentas calcular el cost of delay. Enlazando con la pregunta anterior por qué es importante porque te hace pensar precisamente en cómo calculó esto, el número final da igual. El proceso de calcular esto me obliga a pensar en todas estas variables por qué me seleccionan clientes, cómo puedo medir de alguna manera qué impacto tiene, si mueve o no se mueve esta determinada métrica combinada con todas las demás. Porque fíjate que distintos clientes me contratarán por distintas razones. Hay muchas personas en un vuelo de Ryanair, que no tienen un propósito por el qué han escogido Ryanair.
Esa es la principal razón probablemente por la que en mi opinión personal Customer Experience es algo tan relevante. Tener una estrategia centrada en el cliente, en una estrategia Customer Centric pasa por precisamente preguntarle al cliente qué es realmente lo que tu valoras y cómo esperarías que sea ese servicio, esa experiencia y cómo es en realidad la que estamos teniendo. Al final para eso nos sirve una mentalidad basada en el journey y también basada en la propia experiencia de los clientes.
Volviendo un poco a cerrar, hablábamos de Flow, hablamos de colaboración y hablamos de aprendizaje y creo que estas dos últimas palabras son palabras clave también dentro del concepto de Business Agility. Explícanos alguna reflexión en este sentido.
El ejemplo que ponía antes de Instant Payments, de decir, cómo están colaborando las distintas partes de mi organización. Porque a veces - aquí igual tenemos que hacer un poco de autocrítica desde el mundo Agile, yo el primero - nos hemos centrado mucho en optimizar las distintas partes y hemos dicho “la manera de optimizar es reducir, desescalar tu organización, crear equipos auto organizados”, etcétera.
¿Cómo organizo un proceso bancario que va buscando Instant Payments? ¿Creo un equipo en el que haya una persona de finanzas y personas de legal? ¿O busco cómo estas distintas partes pueden colaborar entre ellas? ¿Cómo puedo dar autonomía en la toma de decisiones pero manteniendo el alineamiento en esos objetivos de negocio? Proveer estos marcos como el cost of delay me va a ayudar en el alineamiento y luego voy a dejar que sean ellos quienes mejoran y decidan cómo pueden mejorar esa colaboración en esa parte de aprendizaje. El concepto de mejora continua no significa nada más que decir sea lo que sea lo que estoy haciendo ahora o sea lo que sea el nivel de valor que puedo entregar a mis clientes cómo puedo conseguir que dentro de seis meses sea más, y que dentro de otros seis meses sea más. Cómo puedo estar constantemente buscando cómo optimizar. Por qué nunca vamos a llegar al estadio perfecto. Eso es lo que queremos crear en las organizaciones. No queremos crear en las organizaciones un proceso perfecto sino más bien la capacidad de pensar si ahora este es tu contexto y éste igual es tu proceso perfecto date cuenta. La misma reflexión que hacíamos antes de que los contextos hace cinco años eran diferentes dentro de cinco años volverán a ser diferentes.
La verdadera transformación es que tú seas capaz de adaptarse a los contextos, que tú tengas esta capacidad de aprender, de mejorar continuamente y de cambiar en base a lo que necesito ahora para poder servir mejor a mis clientes.
Si no tienes la capacidad interna para que tu gente repiense en su forma de trabajar, cuando dentro de cinco años se estarán encontrando en un contexto totalmente diferente, siempre o irás a remolque trabajando para contextos que ya no son los actuales o tendrás una dependencia externa de lo que tengo que hacer… y esto desgraciadamente no lo encontramos en estas grandes organizaciones que cuando llegamos decimos “bueno ahora sois vosotros los de Agile”. Pero hace dos años tuvimos aquí la transformación X y dos años antes habíamos sufrido la transformación. Lo que intenta entender es que precisamente lo que provoca esto es que cada vez que quieres adaptarte a un cambio en el contexto necesitas hacer la transformación.
La verdadera transformación es que tú seas capaz de adaptarse a los contextos, que tú tengas esta capacidad de aprender, de mejorar continuamente y de cambiar en base a lo que necesito ahora para poder servir mejor a mis clientes. Esa es la combinación. Entender el valor de tus clientes, crear marcos que permitan si el contexto actual, si es que ese valor va asociado al tiempo, mejorar ese tiempo, estructurar, colaborar dentro de las distintas áreas para poder estar constantemente reinventándose y mejorando.
Jaume, si alguien quiere tenerte cerca como lo puedes hacer cómo te pueden encontrar cuál es la mejor manera.
Yo creo que es fácil, que siempre ando por la comunidad, por los meetups. De hecho me encanta tomar café con la gente. Es habitual que alguien me contacte. Hacemos un café y hablamos. ¿Cómo es la mejor manera de contactarte? Por correo o por Twitter @jaumejornet y en LinkedIn. Yo creo que si vas a Google y pones “Jaume Jornet” te va a salir un jugador de fútbol de Segunda División así y seguramente yo por ahí.