Southern ITIL

Implantar ITIL va de implantar procesos, no de implantar (más) herramientas de gestión

Joaquin Bañez — Mon, 21 Dec 2009 08:44:00 +0000

Contratar una consultoría de assessment e implantación de ITIL cuesta un dineral, pero es un producto que, en esta época de crisis, se vende bien. Muchas empresas se han tenido que subir a la movida de ITIL porque algunos directivos creen ver la posibilidad de suturar, al menos parcialmente, la sangrante herida que el departamento de informática supone a la organización. Otros, como algunas administraciones públicas, se han tenido que subir al carro por motivos legales y de convergencia con la Unión Europea.

Si no existe cierto entusiasmo por abrazar ITIL, todo son pegas: los directores de Informática leen la mini-guía de introducción a ITIL y quizás asistan a un par de seminarios donde obtienen una visión general de la gestión por procesos, de cómo los define ITIL y a qué están orientados, y algunos casos de éxito de implantación de ITIL en organizaciones…

De estos seminarios salen con 2 ideas muy claras:

Necesitamos una herramienta para “gestionar ITIL”: y esto se vuelve una obsesión y alcanza una prioridad tan alta elegir esa herramienta que acaba convirtiendose en el foco del proyecto de implantación de ITIL, desplazando el objetivo principal que es… pues empezar a gestionar las TI según las mejores prácticas de ITIL.
Lo de ITIL es muy bonito, si el mundo fuera perfecto, pero tendremos que cambiar algunos procesos porque no se adaptan a lo que nosotros hacemos: hay que tener valor para decir que ITIL, aceptado mundialmente como conjunto de mejores prácticas, no es bueno para nosotros. Vaya, que mejor cambiar ITIL que cambiar cómo funcionan las cosas en nuestra empresa.

Hoy, trataremos la primera perversión que arruina cualquier proyecto de implantación de ITIL.

1. Elegir qué software comprarán para gestionar las incidencias, los cambios y los problemas constituye una obsesión: se estudian soluciones variopintas que incluyen el desarollo ad hoc y otras locuras. La herramienta se convierte en el factor restrictivo del alcance de la implantación. La ambición de generar el cambio en el modelo de gestión TI de la organización es tan grande… como la herramienta permita, según ellos.

Casi todas las empresas tienen una aplicación para la gestión de incidencias, y seguramente esa ya vale. Para el resto de procesos, según el tamaño de la organización y los procesos que desplieguen, quizás no requieran nada aparte de aplicaciones ofimáticas. En cualquier caso, hay que resaltar que ITIL no contaba con un esquema de software hasta el 1 de diciembre de 2009, y lo lanzó como piloto. Es posible que en breve haya un aluvión de herramientas certificadas ITIL Process Compliant; para elegir una, en tal caso, habrá que olvidar si sirve para “gestionar ITIL”, la OGC certifica que sirve. Habrá que seguir los preceptos que se seguirían para cualquier otra compra: precio, flexibilidad, facilidad de uso y administración, robustez, integración con otras herramientas, opciones de entrega de la aplicación…

Pero es más: justo en una etapa de crisis económica, ¿por qué no ahorrar unos dineros en la implantación de ITIL recortando en la elección de las herramientas? Puestos a ser frugales, y suponiendo el caso más habitual (la empresa cuenta con una herramienta de gestión de incidencias y un sistema PIM o una intranet), el set de software necesario para implantar ITIL consistiría en:

Esa herramienta de que ya disponen para gestionar incidencias. De forma ideal, debería poder modificarse para adaptar las clasificaciones al Catálogo de Servicios
Una intranet o un sistema PIM con calendario y mensajería: para informar a los integrantes de la organización sobre los cambios planificados, impacto sobre servicios, paradas programadas, etc. Google Calendar es ideal. Hasta envía SMS gratis para avisar de los eventos planificados.
Google Docs: tiene un procesador de textos que admite plantillas: suficiente para redactar las peticiones de cambio. Una vez redactadas, se envían al CAB para revisión y aprobación. Tambien sirve para la gestión de problemas, que se beneficia de las hojas de cálculo de Google Docs, por ejemplo, para hacer mapas de causa raíz . Desde luego, para gestionar el Catálogo de Servicios, es suficiente una hoja de cálculo.

Habría más ejemplos de empleo de herramientas gratis, seguras y confiables que resolverían esa fase de elección de software. En cualquier caso, es algo inconsciente confiar la implantación de procesos de ITIL, que introducen cambios en la forma de actuar de personas y la forma de comunicarse entre ellas, a un producto software. No es de recibo que una implantación de ITIL fracase porque no hay consenso sobre qué herramienta comprar o, aún peor, porque la compra descalabra el presupuesto asignado a un proyecto mucho más ambicioso que la implantación de una herramienta software: el cambio organizacional que ITIL introduce.

Mañana hablaremos de la soberbia o, dicho de otro modo, de lo de “tendremos que cambiar algunos procesos porque no se adaptan a la forma en que nosotros hacemos las cosas”…

No esperes a tener tu Catálogo de Servicios cerrado: eso nunca va a pasar (si lo haces bien…)

Joaquin Bañez — Thu, 10 Dec 2009 12:46:00 +0000

Revisando peticiones de cambio que había que presentar al CAB semanal, he comentado con mi supervisor 2 de ellas en las que no estaba consignado el servicio afectado; en realidad, sí que constaba algo en el apartado “Servicio afectado”, pero no era un servicio recogido en el Catálogo de Servicios.

Mi jefe no ha querido sustituir lo que había en el campo “Servicio afectado” por alguno de los servicios que constan en el Catálogo porque “el catálogo de servicios aún no está cerrado”. Creía que quería decirme que el Catálogo de Servicios actual es un borrador y no está aún validado, pero no: quería decirme que el Catálogo de Servicios aún no está grabado en piedra, por así decirlo. Eso entiende por “cerrado”. Pues tengo que comentarle que, si hacemos las cosas como Dios manda, eso no va a pasar…

Leer más…

El Catálogo de Servicios no parece un concepto asequible pero quizás porque su utilidad no está tan bien definida como requeriría. O quizás, como yo lo veo, lo que está poco instaurado es el punto de vista con el que mirar al Catálogo de Servicios; es una herramienta que se crea desde la orientación al cliente, que es el punto débil de muchos proveedores de servicios, sean internos, externos, outsourcings, cosourcings o cualquier combinación.

“Orientación al cliente” es algo más que el servilismo que algunos practican o aceptar cualquier petición del cliente por descabellada que sea o por lejos que caiga del ámbito del contrato, de la oferta, del pliego y de todo lo acordado: orientación al cliente es querer ofrecer de forma más ajustada en cuanto a requerimientos de funcionalidad, económicos, de utilidad y de disponibilidad lo que el cliente necesita y que nos ha comprado. El Catálogo de Servicios ha de reflejar esta orientación al cliente; el ejemplo más claro de qué quiere decir esto lo he encontrado en esta entrada en el blog de Joseba Enjuto. En inglés aún lo dicen mejor usando “customer focus”, que puede traducirse como “concentración en el cliente”.

Esta orientación a cliente unido a la naturaleza propia de un mundo en constante cambio requiere que el Catálogo de Servicios sea algo orgánico, dinámico y flexible. El Catálogo de Servicios no se graba en piedra como los 10 Mandamientos; ITIL v3 recoge esto de forma magistral (convirtiendose, para mí, en el mayor acierto de la revisión de ITIL) colocando la Gestión del Catálogo de Servicios dentro de la fase “Estrategia del Servicio” como eje alrededor del cual gira todo el Ciclo de Vida del Servicio, como auténtico rotor.

Y a continuación, alguien que lo explica mucho mejor que yo (pero en inglés).

Calendario compacto 2010: útil como pocos

Joaquin Bañez — Thu, 03 Dec 2009 07:21:00 +0000

Jeroen Sangers, autor de El Canasto, publica desde 2007 la plantilla de calendario anual compacto en hoja de cálculo; ya está disponible la de 2010 en múltiples variantes regionales (con sus festivos correspondientes) e idiomas. Una descarga muy recomendable.

Esta plantilla permite tener a la vista todo el año en una sola hoja sin tener que hojear alante y atrás, y deja mucho espacio libre para notas a la derecha, por lo que en un solo folio es fácil tener, a grandes rasgos, la planificación de todo el año (bienaventurado el que pueda decir que tiene planificado todo el año antes de que empiece).

Aún así, tambien es práctico para los que vivimos a salto de mata y casi nos matan los proyectos que saltan por sorpresa…

La imagen ha sido tomada de El Canasto.

Anunciada la Certificación ITIL V3 Master

Joaquin Bañez — Wed, 02 Dec 2009 11:27:00 +0000

La OGC ha anunciado hoy el lanzamiento de la Certificación Oficial ITIL V3 Master.

¡ITIL te busca!

Joaquin Bañez — Wed, 18 Nov 2009 11:49:00 +0000

Cuando se lanzó ITIL V3 en junio de 2007, la OGC anunció el establecimiento de un programa cíclico de actualización y mejora de los libros de soporte, para tener en cuenta los últimos avances en mejores prácticas de Gestión de Servicios TI.

Ahora, la OGC y la Stationery Office (la editora de las publicaciones de la OGC) están reclutando colaboradores para actualizar las publicaciones principales (los 5 libros del Ciclo de Vida del Servicio y el de “Introducción al Ciclo de Vida del Servicio ITIL”). Los colaboradores se dividirán en dos categorías: autores y revisores.

Aquí se puede consultar el anuncio ofical. No queda del todo claro qué se obtiene a cambio, aparte del prestigio de aparecer en los créditos de los libros. Bueno, realmente, sólo eso sería más que suficiente para mí… aunque quizás podrían tambien regalar una invitación todo-incluido al próximo congreso del ITSMF… valdría la pena el esfuerzo (y podrían pensar en un destino exótico para el próximo, que Barcelona no me resulta precisamente atractiva -vivo ahí).

¿Qué te parece? ¿Te gustaría participar en la revisión de ITIL? ¿Te parece que esta campaña pública de reclutamiento es un buen paso para ampliar el alcance de ITIL e incorporar las nuevas tendencias (y, sobretodo, las nuevas realidades) a sus guías? Por favor, ¡comparte tus ideas en los comentarios!

Catálogo de Servicios: zombie-killer

Joaquin Bañez — Tue, 03 Nov 2009 19:49:00 +0000

Leo en CA Service Management blog una entrada de Dave Wilt bastante divertida en la que resalta lo importante que es la gestión continuada del Catálogo de Servicios y la necesidad de mantenerlos siempre actualizado, para evitar la aparición de lo que Dave Wilt llama “zombis” en nuestras organizaciones: esos activos o CIs que no se necesitan, que no son útiles, que no forman parte de ningún servicio pero que vagan por nuestros CPDs. Según la definición que hace Dave Wilt de “zombi” en una organización:”

¿Dónde están los zombis en tu compañía? ¿Qué te parecen esas máquinas virtuales que se crearon y se entregaron rápidamente pero que ya no se usan ni son necesarias? Sitios de SharePoint? Carpetas compartidas, páginas intranet, software de escritorio? Cuentas de usuario? Qué hay sobre ciertos servicios TI completos?

Dave Wilt presenta el Catálogo de Servicios como un arma poderosa para luchar contra los zombis, usando un acercamiento de ciclo cerrado a la provisión de servicios apoyandose en el catálogo de servicios. Uno de los puntos en los que más insiste es la “transparencia de costes”, es decir: exista o no un modelo formal de imputación de costes por provisión de servicios TI en la organización, los usuarios que soliciten un servicio (y sus jefes) deben ser informados del coste que entregar ese servicio tiene, desde la entrega y durante el tiempo que se mantenga activo. Quizás es difícil para muchos departamentos TI que apenas empiezan a componer su primer Catálogo de Servicios ponerse a pensar en implantar un proceso de Gestión Financiera, pero en mi opinión, a diferencia de la jerga técnica, el dinero es un idioma universal que cualquier miembro de la compañía entenderá.

Nadie quiere resultar caro; nadie quiere que su departamento aparezca en la lista de Grandes Derrochones de su empresa; así que es bueno informar a un usuario de cuanto cuesta crear y mantener una máquina virtual cuando te diga que le vendría bien que le “crearas 3 o 4“. No quiero decir que Informática deba usar las facturas para ahuyentar a los pedigüeños, pero debe colaborar para que todo el mundo tome consciencia de lo que están pidiendo y quizás se piensen mejor si realmente necesitan tanto y tan grande.

Merece la pena leer el artículo completo de Dave Wilt, caso que alguien necesite alguna razón más para convencerse de que la Gestión del Catálogo de Servicios es la piedra angular de una gestión de Servicios TI sana.

Gestión de Problemas: tus clientes se merecen una explicación (razonable)

Joaquin Bañez — Tue, 22 Sep 2009 20:54:00 +0000

Leo en The Opposite of Luck una entrada sobre un informe de análisis forense realizado para determinar la causa raíz de un incidente producido en el Complejo Tecnológico Fisher Plaza de Seattle y que dejó KO las webs de varios clientes alojadas allí.

El informe completo (en inglés) puede leerse aquí.

Como los chicos de The Opposite of Luck, aplaudo la transparencia con la que Fisher Plaza ha manejado este incidente, sobretodo como deferencia a sus clientes, que realmente merecen una explicación; al fin y al cabo, Fisher Plaza provee servicios de housing y hosting, ese es su negocio: el cliente tiene derecho a saber por qué ese servicio ha fallado de forma tan catastrófica.

De igual forma, tus usuarios tambien se merecen una explicación cuando un servicio IT de los que prestas se cae; no tienes que redactar un informe de 12 páginas para cada problema que analices, pero lo que es inaceptable es encogerse de hombros y decirle: “estas cosas pasan…”.

Cambios urgentes: WTF???

Joaquin Bañez — Mon, 21 Sep 2009 09:36:00 +0000

Perdonad si soy ordinario, pero es que han pasado muchas cosas idiotas en mi oficina últimamente: por fin hemos inaugurado nuestra herramienta de Service desk, después de 9 meses de diseño y rediseño (el tiempo medio de implantación en otros clientes de 1 a 2 meses). Aunque inicialmente la ventaja de esta aplicación es que es ITIL compliant por lo que ayudaría a la adopción de procesos ITIL, el jefe del departamento ha decidido, ehrm, redefinir algunos conceptos de ITIL, especialmente algunos relacionados con la gestión de cambios y de SLAs.

Para empezar, ha creado un nuevo tipo de cambio: el Cambio Urgente. No tiene nada que ver con las emergencias, sino con la urgencia. ¿Qué es un cambio urgente? Un cambio que debe ejecutarse lo antes posible. Pero no a causa de una emergencia. Por ejemplo: un project manager quiere desplegar una nueva versión de su aplicación “Tal”, y lo quiere ahora. Esta nueva versión no resuelve un problema grave de la versión previa ni añade una funcionalidad o un requisito que el negocio necesita por imperativos legales o de cualquier otro tipo ni por cualquier otra razón que se te pueda ocurrir para elevar un cambio de emergencia porque, y este es el problema, no es una emergencia. Generalmente, se tratará de una fecha de entrega demasiado cercana y un project manager poco inclinado a asumir la responsabilidad del retraso de la entrega (para qué asumir la culpa cuando tienes a los de Sistemas y su gestión de cambios que “no desplegarán hasta la semana que viene porque nuestra petición ya no entra en el CAB”).

Donde yo veo una ardua resistencia a seguir el dictado que un marco de buenas prácticas da, mi jefe y sus colegas creen que han tenido una idea genial porque con los cambios urgentes pueden demostrar que están orientados al cliente. Y una mierda. Es pura cabezonería.

Y además, ¿qué narices? ¿¡¿De todos los libros de ITIL desde v1 hasta v3, dónde leches han leído ellos ese invento de los “Cambios Urgentes”?!?

Cómo sobreponerse a la aplastante inercia de la realidad en 4 pasos: paso 2

Joaquin Bañez — Wed, 02 Sep 2009 09:58:00 +0000

El paso 1 trataba sobre crear el contexto para el cambio, prepararse para que el cambio ocurra definiendo qué debe cambiar y por qué. El paso 2 trata de determinar a quién le importa realmente (o debería importarle) el cambio y por qué. En muchas conversaciones con compañeros en varias empresas en las que he trabajado, existe un “ellos” difuso y étereo involucrado (a veces incluso un “ellos” explicito y concreto): los procesos no pueden cambiarse porque “ellos” no nos dejarán, o porque alguien que ocupa un puesto determinado de mando no permitirá que el cambio se ejecute. En el paso 2 hace falta establecer un enlace entre el comportamiento (“qué”), la razón por la que debe cambiar (“por qué”) y quién necesita entender que el cambio es necesario. Así de simple… aunque si realmente fuera tan simple, no habría ninguna inercia a la que sobreponerse, ¿no?

Leer más…

Los mecanismos alrededor de esa cuestión incluye hacer llegar la información correcta la persona indicada en el momento preciso, que es lo que determinamos que debía cambiarse en el paso 1 y las razones por las que debe cambiar. Sin contexto, sin razones sólidas y concretas, nadie sensato querrá cambiar nada, porque apoyandolo en justificaciones débiles esos deseos de cambio pueden ser considerados un capricho. Por eso mismo, con contexto, nadie sensato se opondrá a cambiar. En casi todas las empresas en las que he trabajado, mis compañeros culpabande la inercia corporativa a la poca voluntad de cambio de la Dirección, cuando el problema a menudo era que no se había tenido en cuenta a la persona adecuada para crear el contexto, o que la información precisa no se había entregado a la persona que la necesitaba. Y además, no sólo se trata de hacer llegar esa información a la gente adecauda, sino asegurarse de que esa gente tiene intención (o se les puede convencer de que lo hagan) de usarla. En un artículo de Gartner (Use a ‘Friendly’ Approach to Organizational Change and Application Process Improvement”), sugieren trabajar primero con los amigos porque eso ayudará a que el consumidor de la información se incline a usarla, así que conviene no desperdiciar la oportunidad de predicar al respecto si una conversación frente a la máquina del café deriva en el rollo de “necesitamos un cambio…”.

Crear diagramas del contexto y hacer análisis RACI (Responsible, Accountable, Consulted and Informed) son puntos clave, y algunos pasos podrían ser:

Primero: considerar el proceso en cuestión
después, considerar al consumidor del proceso y cómo evaluará los resultados
finalmente, considerar al proveedor del proceso y cómo evaluará los resultados; aquí se puede incluir a los consumidores directos y a los proveedores (y sus jefes)

Esto es básico: es crucial llegar a la mayor parte de altos directivos (aunque en otros casos el objetivo del cambio serán los cargos intermedios). A veces ocurre que las personas que ejecutan un proceso y sus jefes reconocen el contexto para el cambio, pero la necesidad de cambio no se ha mostrado de manera explícita a los que pueden (y deben) dirigir el cambio. En cualquier caso, en este punto sólo hablamos de la persona que debe aprobar o dirigir el cambio, sea cual sea su cargo.

En el paso 3, si se ha conseguido la atención de los que deben dirigir el cambio (y como es muy mala idea escalar un problema sin acompañarlo de una solución), se debería definir de manera precisa qué hay que cambiar (y no vale decir simplemente “los procesos”…).

Cómo sobreponerse a la aplastante inercia de la realidad en 4 pasos: paso 1

Joaquin Bañez — Tue, 07 Jul 2009 07:15:00 +0000

Cuando un cliente contrata a una compañía como la mía un servicio de outsourcing de su departamento TI, siempre llegan con preguntas sin contestar o problemas que necesitan resolver, raramente piden que mantengamos las cosas exactamente como están alegando que su organización y sus procesos funcionan perfectamente. Después de todo, cada organización tiene puntos dolorosos y casi todos los jefes y directivos intentan mejorar sus organizaciones…

Seguir leyendo…

En el curso de la relación con el cliente, sugerimos cambios que pueden usar para mejorar la forma en la que hacen ciertas cosas, para mejorar los problemas reportados; y es entonces cuando nos despliegan el abanico de tópicos y excusas que incluye:

“Las cosas no funcionan así aquí”
“Intentamos algo parecido hace unos años, pero no funcionó…”
“La realidad aquí es que…”

“Realidad”… la realidad, basicamente, define “lo que es”, o al menos, la forma en la que se percibe que es, pero, abstrayendonos, la realidad es una combinación de políticas y procesos escritos y de patrones de conducta implícitos, que no están escritos, pero que definen la forma en la que la organización piensa y actúa, lo que podríamos llamar modelos mentales. La realidad es real, y con la realidad viene la inercia, que es la tendencia de una organización a continuar como está. El cambio es difícil a todos los niveles, tambien a nivel personal, y la inercia de la organización puede pisotear muchas ideas nuevas.

Cómo sobreponerse a la aplastante inercia de la realidad? Empecemos por el paso 1.

Paso 1: define la realidad, qué va mal y cómo puedes demostrarlo

Muchos procesos de cambio comienzan definiendo “lo que es”, o sea: la situación actual, como en la Mejora Continua del Servicio de ITIL, en el que el primer paso sería contestar a la pregunta “¿dónde estamos ahora?”. Estos marcos de trabajo empiezan midiendo el desempeño de la organización de forma que les permita compararlo después en una escala de rendimiento, y poder realizar un gap analysis para evaluar la distancia entre el “donde estamos” y el “dónde queremos estar”. Se definen y se usan indicadores clave de desempeño (KPI) que determinen qué hay que mejorar y evaluar después la mejor forma para cambiarlo, o detectar proactivamente cuando el rendimiento de un proceso empieza a degradarse.

En cualquier caso, estos procesos verticales proactivos están implantados en organizaciones que son ya mucho más maduras que sus competidores y que están al tanto de la necesidad de seguir madurando. El contexto para el cambio ya existe en ellas y aprovechan la ventaja competitiva que les brinda la situación; ¿qué pasa con la mayoría de organizaciones (españolas o no)? El contexto para el cambio no existe en ellas y la necesidad de cambio sólo surge como reacción a un disgusto, que puede ser un gran cliente cancelando su contrato o el fracaso de un proyecto plurianual y multimillonario… o cuando un partner le dice a la organización que debe ser mejor “o si no…”.

El contexto para el cambio es crucial, pero muchas organizaciones no lo crearán porque no tienen KPIs o marcos de trabajo que les proporcionen mediciones, porque existe una gran diferencia entre “lo que es” y “lo que está mal”; esta diferencia se debe mostrar y explicar muy claramente a la Dirección, y la única manerla de hacerlo es en su lenguaje, con mediciones y con cifras; si no las hay, el gap analysis quizás sea útil. Y si no existe nada de nada a lo que agarrarse… siempre se puede apuntar a los puntos dolorosos (temor a catastrofes, quejas de clientes, perdida de contratos, ridículo público, escándalo en la prensa, mala imagen de la compañía…).

Existe otro factor común en estas organizaciones: las cosas se hacen de cierta manera pero nadie sabe ciertamente por qué ni desde cuándo, e intentar cambiar eso te puede volver loco; intentar cambiar comportamientos implícitos, no escritos, los que están fundamentados en el “aquí lo hacemos así” es, de lejos, mucho más difícil que cambiar procesos explícitos (es decir: escritos). Así que poner por escrito cómo se hacen las cosas, aunque se hagan mal, es el primer paso para intentar cambiarlo. Esto forzará la revisión de los procedimientos y procesos empleados en la empresa y conducirá a la reflexión sobre ellos a los agentes implicados. Este paso, desde luego, suele generar rechazo por parte de los que ejecutan esos procesos porque se sienten fiscalizados, interrogados sobre su trabajo y su desempeño. Y están en lo cierto, pero el objetivo no es condenarles, simplemente dejar claro qué se está haciendo mal y crear la ocasión para mejorarlo.

Así, los pasos cruciales para crear el contexto para el cambio requieren correlacionar los resultados actuales con el comportamiento, y el comportamiento con la causa. Resumiendo:

evangeliza y muestra los datos del desempeño actual de la organización como si fueran los 7 pecados capitales; puedes dar el empujoncito que necesitan a los que ya piensan dentro de la organización que es el momento del cambio; si la organización es del mundo TI, sin duda, hazte apóstol de ITIL y confía en su reputación -es merecida.
pon por escrito los procesos tal y como se ejecutan a día de hoy; eso obligará a los agentes implicados a revisar cómo se están haciendo las cosas y contemplar la realidad tal cual es; sin duda, eso les llevará a desear el cambio
asusta a la Dirección; muestrales a dónde puede conducirles la falta de madurez de la organización; hablales de catastrofes destruyendo el centro de datos y parando el negocio durante semanas (no sólo terremotos o atentados terroristas: una tubería rota sobre el techo del CPD ya es una catástrofe); hablales de salir haciendo el ridículo en “5 Días”, de clientes eligiendo a otro proveedor; especialmente, de esos clientes fieles durante años que finalmente deciden no renovar su contrato…

Muy pronto aquí, el paso 2: a quién le preocupa (o debería preocuparle) el cambio y por qué.