• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

complejidad

Management 3.0 – ¿Por qué surge?

El pasado sábado 2 de junio tuve la suerte de participar en el evento AgilityTRes60, al que asistí tanto de oyente como de facilitador de una sesión de introducción a Management 3.0.

También estuve hablando sobre Management 3.0 los días 30 y 31 de mayo. En este caso, se trataba de una de las formaciones oficiales de 2 días que impartimos desde Jerónimo Palacios & Associates (Management 3.0 Two-Day Workshop).

¿Sabéis qué comparten principalmente ambas sesiones? Que pretendo asentar muy bien las bases, intentando que los asistentes entiendan:

  1. Por qué utilizar nuevos modelos de gestión y liderazgo
  2. Qué es Management 3.0
  3. Cómo bajamos la teoría a la práctica 

En este artículo os voy a hablar del por qué. Más adelante publicaré otros hablando de qué es Management 3.0 y cómo lo aterrizamos.

¿Por qué Management 3.0?

¿Cuántas veces el ser humano suele hacer algo porque está de moda? ¿Cuántas veces lo ejecuta de forma mecánica sin entender sus pilares y sobre qué se fundamentan?

Tanto cuando estoy haciendo co-training con Jero en algunas de nuestras formaciones, como cuando estoy trabajando con el resto de mis compañeros apoyando a nuestros clientes en sus procesos de transformación, me doy cuenta que la respuesta a las dos preguntas anteriores es “bastantes más veces de las que me gustaría”. Esto en gran parte se encuentra ligado al concepto de culto del cargamento del que ya hemos hablado en varias ocasiones.

Es por ello que siempre hago mucho hincapié y dedico muchas horas en entender yo primero, y ayudar a otros a entender más tarde, las razones por las que queremos introducir un cambio. En este caso cambio el enfoque de la pregunta de un “¿por qué?” a un “¿para qué?”.

En lo que respecta a Management 3.0, ¿por qué recibe este nombre? Esta pregunta es la que nos permite hablar de su nacimiento, del motivo por el cual surge este concepto. La razón es bastante simple. Hay dos versiones de management anteriores, la 1.0 y la 2.0. Vamos a ver por encima qué implican estos predecesores.  

Management 1.0 – Las jerarquías

En la Primera Revolución Industrial ya se hablaba de producción en serie, cadena o masa. Estos términos alcanzaron su máximo esplendor tanto con Frederick W. Taylor, a través del Taylorismo, como con Henry Ford, a través del Fordismo.

Estos procesos de producción y la mayor parte de los marcos de gestión son desarrollados por ingenieros, caracterizándose por:

  • Gestionar la empresa como si se tratase de una máquina.
  • Especializar a los trabajadores.
  • Poner foco en la productividad.
  • Cronometrar el tiempo de las tareas.
  • Pagar incentivos por productividad/rendimiento.
  • Secuencializar el trabajo.
  • Introducir managers que se encargaban de la supervisión, organización y dirección del trabajo.

Además, se basan en:

  • Realizar un diseño por adelantado.
  • Planificar de forma descendiente.
  • Crear estructuras y procesos basados en orden y control.

Si pensamos detenidamente en los 10 puntos anteriores, diría que la clave está en la palabra “máquina”. Es entonces cuando todo tiene sentido, pues estos procesos funcionan bien cuando hablamos de máquinas, cuando nos referimos a cómo funcionan y el tipo de tareas que éstas realizan: tareas predecibles y repetibles.

El problema viene cuando hablamos de creatividad, innovación, conflictos, comportamientos, redes y relaciones, complejidad, seres humanos… Aquí, las reglas aplicadas a las máquinas se quedan excesivamente simples y no sirven para gestionar estos entornos.

Estos modelos a los que nos referimos bajo el concepto de Management 1.0, son probablemente los estilos de gestión más extendidos a día de hoy.

Management 2.0 – Las modas

Algunas personas se han dado cuenta que Management 1.0 no funciona bien out-of-the-box y que hay que introducir cambios. Surge Management 2.0.

Las organizaciones que se gestionan con esta versión de management, reconocen principalmente las siguientes afirmaciones:

  • Las personas son el activo más importante.
  • Los managers tienen que convertirse en “servant leaders”, o lo que es lo mismo, líderes que den servicio a la organización (como siempre digo, no confundir “dar servicio” con “ser siervos” o “servidumbre”).  

Aunque las ideas anteriores suenan genial y resultan muy atractivas, seguimos encontrando grandes problemas en estas organizaciones. La explicación es sencilla: como solución al Management 1.0, lo que hemos hecho ha sido añadir una serie de complementos que se acoplan a la versión 1.0 out-of-the-box. Es por ello que, aunque sí se alivian los problemas, las estructuras, arquitecturas y jerarquías siguen siendo las mismas.

Me gusta destacar dos consecuencias que se producen al hacer un cambio de “look&feel” del Management 1.0 para tender hacia Management 2.0, que son:

  • A pesar de que los managers comprenden que la mejora de toda la organización no se logra simplemente a través de la suboptimización de sus partes, la gran mayoría prefiere mantenerse dentro de la jerarquía olvidando que las personas no suelen responder bien a modelos basados en orden y control con planificación descendiente.
  • Puesto que las estructuras, arquitecturas y jerarquías de la organización siguen siendo las mismas o prácticamente iguales, cuando la empresa o las personas que la conforman tienen un problema, una situación difícil, una crisis, tienden a hacer exactamente lo mismo que hacían inicialmente, vuelven a sus orígenes, aplicando reglas tradicionales del siglo XIX a situaciones complejas del siglo XXI.

Management 3.0 – La complejidad

Es un movimiento de innovación, liderazgo y gestión en el que se considera a las organizaciones como redes sociales complejas donde hay que gestionar los sistemas y no a las personas, encontrando juntos la forma más eficiente para que nuestra empresa logre sus objetivos, manteniendo la felicidad de sus trabajadores como una prioridad.

En próximos artículos trataré más detenidamente qué es Management 3.0 y cómo podemos aterrizar la teoría de forma práctica.

Resumen

A modo de resumen voy a hacer alusiones a la página de Management 3.0, ya que me gusta bastante cómo definen en pocas palabras cada una de las versiones de management que hemos visto:

  • 1.0: hacer lo incorrecto, tratando a las personas como engranajes de un sistema.
  • 2.0: hacer lo correcto de la manera incorrecta, con buenas intenciones, pero con iniciativas jerárquicas anticuadas de arriba hacia abajo.
  • 3.0: hacer lo correcto de manera correcta, implicando a todos en la mejora del sistema y fomentando el compromiso de los empleados.

Management 1.0 2.0 3.0

Nuestra formación

Si quieres formarte en Management 3.0, no dudes en consultar los próximos eventos en nuestra página o preguntarnos a través de la dirección de correo [email protected]. También puedes ver los comentarios de anteriores asistentes accediendo a este enlace. 

La convergencia de DevOps y Scrum

DevOps es un área de mi interés desde hace varios años. En Diciembre de 2014, en la CAS de Barcelona, di una charla en Inglés sobre la experiencia haciendo que DevOps fuera uno de los pilares de la agilidad en la DVLA -Una suerte de DGT británica-. Hace un año y medio también publiqué un artículo introductor al tema de DevOps y Scrum.

Tres años después, veo que DevOps y su convergencia con Scrum sigue sin arrancar. Me encuentro con profesionales de ambas áreas que en lugar de colaborar, tienden a ensanchar aún más sus diferencias. Los motivos que encuentro son: Resentimiento de la comunidad técnica hacia el éxito de Agile y Scrum, Incapacidad para entender que operaciones forma parte del proceso de desarrollo y un conflicto personas vs procesos.

Resentimiento en la comunidad de operaciones hacia el éxito de Agile y Scrum

A pesar de que ahora pensemos que hemos reinventado todo, la comunidad de operaciones lleva muchos años manteniendo a raya los sistemas críticos de organizaciones grandes y pequeñas.

Se trata de profesionales muy especializados que han visto como el número de Agile Coaches, unos mejores y muchos peores, de pronto cobraba un protagonismo muy importante en las organizaciones que se habían encargado de mantener. Una pena. Y una fuente de frustración

Eso ha hecho que se crearan castas dentro de las propias organizaciones. Desarrollo tiene un papel muy importante mientras que operaciones siguen siendo los tipos del sótano que se encargan de seguir las instrucciones que mandan los de arriba. En ocasiones bajo las mismas restricciones presupuestarias.

Todo esto, unido a la baja calidad de muchos profesionales de Agile, muchos de los cuales no sólo carecen de conocimientos técnicos sino que los minusvaloran, ha creado una brecha todavía más grande entre las dos comunidades profesionales, haciendo que DevOps fuera casi un enemigo para Scrum. Y viceversa.

Incapacidad para entender que operaciones forma parte del proceso de desarrollo

Sorprendentemente, sigue existiendo una incapacidad para querer entender que en el ciclo de vida del desarrollo de Software, la programación pura y dura no suele suponer más de un 12% o un 15% del mismo. Ese software debe de ser diseñado, mantenido y puesto en producción, y a pesar de eso seguimos empeñados en que lo importante es programar, no tener productos terminados y usables por parte del cliente.

Cuando trabajamos usando Scrum, el objetivo no es el proceso, es el producto terminado. Los Sprint Reviews no son compuertas a la siguiente fase -operaciones-, sino que son herramientas para inspeccionar y adaptar nuestra táctica en función de la estrategia. Operaciones debe ser parte del Sprint y de los equipos Scrum. Dependiendo del contexto, puede que trabajen permanentemente dentro de un equipo o que vayan haciendo de consultores que están completamente disponibles para los equipos.

Conflicto personas vs procesos

Mientras que la tendencia en la comunidad ágil es hacia las personas, en la comunidad de operaciones es más hacia los procesos. Esta dicotomía es sólamente resultado de las diferencias que existen en el trabajo de ambas áreas. Mientras el trabajo en desarrollo esta más orientado a descubrir, el trabajo de operaciones está más orientado a ejecutar. Permíteme explicar eso. El desarrollo de Software es complejo, y continuamente tenemos que descubrir soluciones a problemas que no habíamos previsto. El trabajo de operaciones se enfoca en optimizar todo el proceso de puesta en producción y mantenimiento de ese software en producción. Mientras que la variabilidad es inherente al desarrollo y podemos obtener beneficios de la misma (por ejemplo, cuando descubrimos que optando por una librería en lugar de un diseño ad-hoc ganamos en rendimiento y mantenibilidad), la variabilidad es algo a evitar en operaciones. Hay que estandarizar el proceso.

Si además le unimos la baja calidad de algunos profesionales en Agile, eso provoca una desconexión total entre desarrollo y operaciones. DevOps tiene que orientarse a converger con Scrum, y es donde mejor resultado obtienen ámbos.

No todos los sabores funcionan en todas las organizaciones

¿Como resolvemos estos problemas? En primer lugar, adoptando una mentalidad crítica hacia Scrum y DevOps y luego entendiendo el contexto de la organización. No podemos cambiar organizaciones a martillazos, diciéndoles que lo que tienen que hacer es sustituir a todo su equipo de operaciones y dejar ese trabajo a los equipos de desarrollo. No es viable. No es una solución.

En lugar de eso, hay que intentar introducir una cultura que cierre las brechas que se explican más arriba para posteriormente ir mejorando nuestra capacidad de automatización. Un gran banco no puede, de la noche a la mañana, automatizarlo todo. Y es que eso no es DevOps. Es NoOps.

NoOps puede funcionar perfectamente en una pequeña startup, pero en el momento que hay que cumplir requisitos regulatorios, de negocio, seguridad, no es tan fácil automatizarlo todo. El reto está en volver a los orígenes, a la Agile Infraestructure que asentó las raíces de DevOps en sus comienzos. Muchos profesionales de operaciones insisten en que DevOps es automatización, cuando no lo es. Es mucho más.

Si quieres leer más sobre la convergencia de DevOps y Scrum, te recomiendo que eches un vistazo al whitepaper que hemos publicado conjuntamente con el DevOps Institute en Scrum.org

No tienes ni idea de lo que es la transformación digital

Martes por la mañana. París. Estoy en una llamada con un cliente y uno de sus proveedores, que le habla de las maravillas de la transformación digital. Después de escuchar muchas obviedades y mentiras, llega mi turno de palabra. Le digo: “Perdona, pero no tienes ni idea de lo que es la transformación digital”.

La transformación digital no existe

Muchos promueven la transformación digital como un concepto nuevo, pero no tiene nada de nuevo. Lo que está ocurriendo ahora no es sino una nueva vuelta de tuerca al proceso que comenzó con la revolución industrial, que ha metido una nueva marcha gracias a Internet.

¿Pero esto no pasó ya en los 2000? No, en los albores de internet lo utilizábamos de la misma manera que utilizábamos la radio, la televisión o los periódicos. Incluso las bibliotecas todavía ofrecen mejor información en muchos casos que Google.

La transformación digital va a hacer que te quedes en el paro

Déjame explicarte como funciona esto. Gracias al avance del machine learning y la automatización a todos los niveles, y hay miles de puestos de trabajo que están potencialmente obsoletos. ¿Gestor de fondos de inversión? Obsoleto ¿Experto en social media? Obsoleto ¿Conductor de vehículos de cualquier tipo? Obsoleto. Sólo queda esperar a que toda la tecnología que ya existe se vaya extendiendo por el mercado de trabajo para que empecemos a ver gente irse al paro. Y no estamos haciendo nada para prevenirlo.

Por tanto, si alguien te vende que el social media es transformación digital, no sabe de lo que está hablando. Puede que el social media sea parte de una estrategia automatizada de toma de decisiones sobre un producto, pero en sí mismo no deja de ser lo mismo que comprar un servidor en la era de la nube. ¿Adivinas?. Sí, obsoleto.

El problema de la automatización es que las máquinas no saben resolver determinados problemas

Niels Pflaeging, amigo y autor del libro Organize for Complexity, lo explica con esta imagen y una analogía: Los dominios rojos y los dominios azules. Todo lo que está en la parte azul es aquello en lo que puede existir automatización, donde las máquinas son mejores que las personas. Sin embargo, el dominio rojo indica todo en lo que los humanos todavía seguimos siendo mejores.

Niels Pflegling Domains complexity

Lo que quiere decir esto, es que cada vez más el futuro del trabajo está asociado a los dominios de la complejidad y las tareas más repetitivas y fáciles estarán hechas por máquinas capaces de aprender.

Ni Machine Learning ni Big Data, lo importante es el ¿Por qué?

Hoy en día cualquiera se pone la palabras Big Data o Machine Learning en la boca y se lanza a embaucar clientes incautos que están deseando de hacer algo. Clientes que leen la revista CIO y se encuentran en una situación en la cual el mercado hace cosas pero ellos son incapaces de saber ni como ni cuando.

Los mismos clientes que años atrás decidieron hacer el outsourcing de toda su capacidad de desarrollo porque el mismo embaucador con traje y corbata se lo dijo. Los mismos que decidieron que invertir en automatizar operaciones tenía mucho riesgo y que era mejor dejarlas en manos de equipos de expertos traídos por la consultora líder en el sector del momento.

Big Data, Machine Learning, Agile, Design Thinking. Todos estos pueden ayudarte si tienes una visión clara de donde se encuentra tu compañía en el mercado y quieres ser competitivo. Si no la tienes, te sugiero que inviertas en contratar gente lo suficientemente buena como para suplir esa carencia.

Lo único que te va a importar son las personas

¿Quieres transformar tu compañía? Empieza por el management y por las personas que las forman. Probablemente tengas que despedir a gran parte de tus mandos intermedios, o se vayan ellos. Tendrás que aprender a crear equipos de alto rendimiento que se auto-organicen y sean capaces de responder a las necesidades del mercado como comandos altamente preparados.

La gente que tienes ahora pasará por un proceso doloroso. Tú pasaras por un proceso doloroso, pero al final, conseguirás que tu compañía aguante en un mercado digital. Al final del proceso, habréis visto como se ven las cosas al otro lado de la puerta.

Porque las transformación digital no va de tecnología. Sino de personas.

Management en el dominio de lo complejo

El dominio de lo complejo ocupa la parte central de la matriz de Stacey y supone su área más amplia. Éste dominio se puede resumir en: Desconocemos más de lo que conocemos y no podemos controlar las variables. El enfoque adecuado de management en este dominio es el de Probar – Percibir – Responder, o lo que es lo mismo, aplicar un sistema de control empírico, que nos permita evaluar soluciones conforme aprendemos sobre el sistema.

decisiones en entornos complejos
La zona de lo complejo es la que abarca el área 4

Management en el dominio de lo complejo: Características

En entornos complejos lo que desconocemos es mucho mayor que lo que conocemos, y además no sabemos que desconocemosMás impredicibilidad que precibidilidad: En los entornos complejos, podemos predecir un pequeño rango de situaciones, pero las variables son generalmente tantas y tan desconocidas que es imposible tenerlas todas en cuenta, además de que puede ser tan costoso como el propio proyecto en sí. Los consultores frecuentemente hacen una comparación entre el desarrollo de Software y los procesos Industriales, y no podrían estar más equivocados. El desarrollo de software sólo podría asemejarse a crear un producto industrial cada vez, y nunca repetirlo más. Siguiendo con nuestro ejemplo, imagina que además de tener tuercas, tornillos y arandelas, ahora además tenemos billetes de 50€, un cerdo vivo y determinados bolígrafos que producen descargas eléctricas aleatoriamente. Además, las cajas donde tenemos que ponerlos desaparecen, no hay suficientes y el comercial espera que tu clasificación sirva para traducir el Quijote de Cervantes al Hebreo Antiguo.

Respuestas emergentes: Poco de lo que hemos hecho hasta ahora sirve en este entorno. En primer lugar, hay que empezar a responder preguntas: ¿Qué estamos haciendo? ¿Para qué? ¿De qué recursos dispongo? ¿De cuanto tiempo?. Las respuestas emergentes son necesarias para poder navegar este proceso tortuoso. Además hay que dar completa responsabilidad a la persona que produce esas respuestas, cuando no se hace, se cae en situaciones que llevan a comités, informes y reuniones interminables que provocan la lenta paralización de la organización.

Muchas ideas que compiten con otras: En este entorno, donde los inputs no son predecibles y los outputs no son claros, las ideas compiten y es un caldo de cultivo perfecto para crear un clima de crispación y frustración personal. Tener claro quien debe de decidir qué debe ser la prioridad, relegando el cómo hacerlo a una segunda prioridad. Las ideas son necesarias para poder encontrar las mejores soluciones a casos únicos.

Management en entornos complejos
El área de trabajo es la que dicta cual es el trabajo del manager

Trabajo del líder

Crear entornos que inviten a la acción: En entornos complejos, el tiempo es oro, y a pesar de no poder predecir qué hacer, es necesario tomar acción y ser proactivo ante situaciones difusas y poco claras. La habilidad del líder para crear un entorno donde las personas de la organización se sientan cómodas tomando decisiones y poniéndolas en marcha es vital para el éxito en estos entornos

Servant-Leadership es un anglicismo que describe un tipo de liderazgo ejercido desde el servicio a otrosServant Leadership: El liderazgo desde la actitud de servicio es clave para conseguir resultados en estos entornos. Los líderes deben de proporcionar herramientas a aquellos que conviven con el problema y generan ideas sobre cómo resolverlo para así optimizar los resultados. Aunque es común que mucha gente confunda el liderazgo desde una actitud de servicio con el servilismo, no son lo mismo. En el primer caso, los líderes dan poder y motivan a sus seguidores, mientras que en el segundo, se limitan a proporcionar todo lo que éstos quieren.

Generar ideas: Otro aspecto fundamental del líder en estas situaciones es la generación de ideas que pueden (o no) servir de base a los seguidores para poner en marcha y favorecer una resolución de las situaciones complejas. Siguiendo con nuestro ejemplo, el jefe de taller puede marcar una visión (Facilitar la categorización de objetos) y somos nosotros quienes tenemos que intentar lidiar con cómo hacerlo de manera más efectiva.

Otros artículos de Management en la serie la complejidad del desarrollo de software:

  1. Management en el dominio simple
  2. Management en el dominio de lo complicado
  3. Puedes comprobar y aprender estos estilos de Management con el juego de Cynefin con LEGO®

Management en el dominio de lo complicado

El dominio de lo complicado es aquel donde o la falta de acuerdo sobre lo que se espera o la duda sobre lo que viene aumentan. Este es un dominio muy habitual en entornos de producción, donde existen una serie de variables complejas que se minimizan y se miden para evitar interferencias. El enfoque más habitual es el de Percibir (ver lo que viene), analizar (investigar o analizar usando conocimiento experto) y responder (tomar una decisión en base a lo que conocemos). Veamos las características y el trabajo de management del líder en este caso.

decisiones en entornos complejos
La zona de lo complicado es la que compende las áreas 2 y 3

Management en el dominio de lo complicado: Características

Podemos predecir más de lo que no podemos: En estos entornos, las tareas sigue siendo relativamente estables y predecibles. Siguiendo con nuestro ejemplo anterior de los tornillos y las tuercas, podemos encontrarnos que, en múltiples ocasiones, hay otro tipo de objetos que no pertenecen ni a la categoría tornillos ni a la de tuercas. Arandelas unas veces, cáncamos otras. Podemos predecir que normalmente tendremos lo que esperamos, pero hay ocasiones en las que esas predicciones no funcionan.

La gestión basada en hechos es la característica fundamental del dominio de lo complicado.Management basado en hechos: El management basado en hechos sigue siendo constante en este dominio. Al tener nuevas variables, tenemos que analizarlas y tenerlas en cuenta para poder continuar con la tarea, o esta se detendrá. Si tenemos más objetos que antes no conocíamos, su aparición debe de ser tenida en cuenta para poder aplicar medidas y adaptar el proceso

Los expertos ayudan a corregir las desviaciones: El uso de expertos en estas tareas -normalmente un manager o un especialista- ayudan a entender y tomar decisiones sobre lo que hay que hacer y cómo modificar los procesos para dar cabida a estas nuevas variables. Si nos encontramos clasificando tornillos o tuercas y encontramos arandelas, la mejor decisión es acudir a nuestro jefe y preguntarle cual es el proceso a seguir.

Management en el dominio simple
El entorno dicta cual es el trabajo del líder

Trabajo de los líderes

Uso de expertos para entender lo que ocurre: El uso de un experto en el caso que nos ocupa, por ejemplo de un jefe de taller, arrojará respuestas sobre por qué hay nuevos objetos mezclados con aquellos que esperábamos y cómo podemos solucionar lo que necesitamos. El uso de expertos externos ayudará a comprender cual es la mejor manera de actuar en este sentido.

El uso de métricas para entender lo que ocurre es necesario en el entorno de lo complicado.Uso de métricas para ganar control: En entornos complicados, el uso de métricas, cuadros de mando y reportes es necesario para entender qué está pasando y cuales son las medidas necesarias para poner freno a desviaciones y mejorar la productividad. Una vez entendidos los datos, estos se ponen en comparación con lo que se espera para así tener un mayor control de la situación. El jefe de taller, en nuestro caso, puede tener un control de cuantos objetos que no son tuercas y tornillos pasan por el proceso de categorización para tener un control de problemas en la producción

Ordeno y mando: En este dominio, de nuevo, el estilo de Management que más se adapta a la situación es el mantener un control férreo sobre lo que ocurre y dividir el trabajo entre pensadores y ejecutores. Proveer de capacidad de decisión sobre lo que hacer en caso de encontrar un objeto no esperado no es sino una forma de añadir complejidad al sistema, ya que cada trabajador puede tomar una decisión distinta.

  • « Ir a la página anterior
  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad