23/06/2022 José Luis Gutiérrez Sequera

Regional Access Manager en Laboratorios Servier. Exdirectivo sanitario.

Hace unos días desayunaba frente a una excelente columna de Joan Escarabill (neumólogo del Clinic de Barcelona) para el blog Avances en Gestión Clínica, cuyo título rezaba así:

¿Cómo puede ser que las cosas bien hechas a veces no funcionen? En referencia a los procesos de mejora organizativa en el ámbito sanitario.

Escarabill argumentaba textualmente: “tal vez los buenos proyectos no se implementan bien porque no hemos pensado en dos cosas: las necesidades reales de las personas que los han de recibir y la carga que supone aplicar las propuestas (tanto desde el punto de vista individual como colectivo)”.

Si no queremos contradecir a Joan en sus afirmaciones -y no queremos- y tampoco asegurar que cuando proponemos mejoras organizativas no tenemos en cuenta algo tan esencial como las necesidades reales de las personas, el único camino posible sería deducir que a veces creemos conocer lo que la gente quiere y necesita, entregándonos a la suficiencia de que no hace falta preguntarlo.

Respecto a lo segundo, la cosa de los costes, posiblemente tengamos tan asumido y descontado el fenómeno de la resistencia al cambio, que tal vez elijamos no rascar demasiado, bajo el refugio de que todo se debe a ese concepto elevado a comodín de todas las excusas, simplificador mayúsculo, que enunciamos cotidianamente como “zona de confort”.

Pero vamos, que todo son suposiciones. No obstante, cuando hablamos de proyectos que no salen bien por no haber evaluado necesidades y costes de sus destinatarios, estamos hablando de aceptabilidad, o de algo parecido y que por ahí llaman desirability, un concepto que no siempre elevamos a cabeza de carrera cuando acometemos innovaciones organizativas. Lo anterior me lleva a descomprimir algunos archivos mentales de mi pasado como directivo hospitalario, y a rescatar errores propios y ajenos relacionados con la aceptabilidad que he ido observando en esto de impulsar innovación organizativa y que a la postre han tenido impacto en el éxito del proyecto.

Por otro lado, buscando inspiración sobre metodologías que puedan ayudar en esta historia que os cuento, me he topado recientemente con el Método Lean Startup, en forma de libro homónimo escrito por un tal Eric Ries, emprendedor, bloguero y escritor de éxito y que ha vendido más de un millón de ejemplares. Por algo será. Cierto es que se trata de una metodología pensada para el desarrollo de nuevos productos comerciales o de modelos de negocio innovadores, pero una vez que uno bucea en ella encuentra claves interesantes que pueden inspirar buenas prácticas para el desarrollo de los proyectos de innovación organizativa hospitalaria, y que pueden ser de mucha ayuda en la búsqueda de la aceptabilidad.

¿Cuáles podrían ser los errores más relevantes?

Puestos a analizar los errores a los que me refería anteriormente, os dejo aquí algunos de los que me parecen más relevantes, convenientemente pasados por la batidora del método de Eric Ries.

1. Enfocarse en la solución y no en el problema. Esto va de enfocarse en el diseño de una solución innovadora y cool, más que en una exhaustiva cuantificación y conceptualización del problema a resolver. En otras palabras, estar tan enamorado de tu idea o proyecto que casi olvidas a qué problema venía a dar respuesta.

2. Basar el análisis del problema en sensaciones y no en datos. Se trata de describir y conceptualizar el problema en base a un relato de sensaciones versus un relato basado en datos objetivos. Más tarde o más temprano, el proyecto tocará tierra y tendrá que confrontar su relato con el de quienes no quieren cambiar. Dos relatos basados en sensaciones están condenados a no entenderse. La única solución es que al menos uno de los dos esté basado en datos. Ya sabéis. Lo del tío Deming: “In God we trust. Anyone else please bring data”.

3. Construir sobre asunciones en lugar de hipótesis a validar. Muchos de nuestros razonamientos sobre un determinado problema organizativo, no son verdades, sino hipótesis. Es un error frecuente describir y conceptualizar el problema en base a asunciones y no en base a hipótesis contrastables, que por su propia naturaleza requieren validación. Se parece al anterior, pero ojo, no es lo mismo. A veces se formulan hipótesis olvidando que era necesario validarlas, y esta validación nos puede sorprender desprevenidos cuando el proyecto ya ha iniciado su implantación masiva y las barreras de salida son tan elevadas que no queda otra que seguir adelante. Es entonces cuando tu fantástica idea se convierte en un elefante atravesando un mercadillo.

4. No tener en cuenta cómo se está resolviendo el problema actualmente. Como decían en Jurassic Park, “la vida se abre camino”. La gente busca soluciones a sus problemas si estos son realmente importantes. Con frecuencia se plantean desde arriba soluciones innovadoras a problemas que pueden ser muy relevantes, sin haber explorado previamente las alternativas de solución existentes en el ecosistema, la mayoría de las cuales no son tan visibles por ser individuales y voluntaristas, olvidando evaluar qué resultado están dando. A menudo, si no atendemos este aspecto, es posible que la solución ofrecida no mejore la existente. El ejemplo típico son las mejoras en los sistemas de información que entran a competir con eso tan querido por todos, y que responde al nombre de “mi Excel”. Demasiadas veces, “mi Excel” me responde más preguntas que el sistema de información oficial, pero nadie me preguntó cómo lo estaba haciendo para poder desarrollar una opción corporativa que mejorase lo que yo ya tenía.

5. Infraponderar los costes de adquisición individuales y de equipo. No hablamos de los costes para el hospital, que rara vez se nos olvida calcular, porque tocará defenderlos ante quien nos tiene que financiar. Hablamos de los costes para los profesionales y los pacientes. Dichos costes, a la postre, son la gasolina que alimenta la resistencia al cambio. A modo de ejemplo, citamos algunos costes de adquisición para profesionales derivados de cambios organizativos sustanciales:

1. Económicos (riesgo percibido de posible merma en las retribuciones variables)
2. Nuevos riesgos laborales ligados al proyecto
3. Cambios en el tiempo o secuencia de actividad efectiva y descanso
4. Cambios en la estructura de la agenda
5. Cambios en el equipo directo de trabajo
6. Cambios en la conciliación (horarios y/o turnos)
7. Riesgo percibido de pérdida de parcelas de poder de decisión
8. Cambio de entorno físico
9. Nuevos compromisos que tengo que adquirir
10. Nuevas competencias o habilidades necesarias para el nuevo escenario
11. Riesgo implícito de ser el primero en implantarlo…

Y un largo etcétera que además en muchos casos es muy subjetivo y afecta de manera desigual a diferentes personas, pero que si lo infraponderamos, puede acabar tumbando el más brillante de los proyectos. No podemos implantar un proyecto sin tener en cuenta las cosas que son importantes para quienes lo van a ejecutar.

6. La Pizarra lo aguanta todo. Demasiadas veces, todo el proceso, desde la idea inicial hasta el último tornillo del proyecto terminado y listo para implantarse se llevan a cabo en la pizarra de un despacho, sin el debido testeo de las hipótesis con las personas adecuadas y sobre el terreno real.

¿En qué consistiría la Arqueología de Proyectos Hospitalarios?

Cualquiera que haya ejercido funciones directivas en más de un hospital, puede hacer un ejercicio que recomiendo practicar y que llamo Arqueología de Proyectos Hospitalarios, consistente en pasar por centros donde formaste parte de la dirección en algún momento, y comprobar el estado actual de proyectos de “supuesta mejora” organizativa que se impulsaron mientras tú estabas allí. Los hallazgos a veces resultan reveladores, y podríamos clasificarlos en cuatro tipos:

• Proyectos Catedral: Siguen tal cual se implantaron, son proyectos de éxito y perduran “abiertos al culto”.
• Proyectos Castillo (ahora Parador): Han sido tuneados adecuadamente, y siguen en uso aunque ya casi no se parecen a su funcionalidad original.
• Proyectos Muralla: No se conservan completamente, quedan restos integrados en el entorno que son visibles a simple vista pero prácticamente afuncionales.
• Proyectos Catacumba: Hay que excavar con un equipo internacional de arqueólogos para encontrar vestigios. Han desaparecido de la realidad cotidiana.

Ante semejantes hallazgos arqueológicos, uno no puede evitar preguntarse qué variables determinan que un proyecto de mejora organizativa hospitalaria acabe siendo catedral o termine a varios metros bajo tierra. Haciendo estadística de salón en mi cabeza, y que Pearson me perdone, la verdad es que observo que el estado actual de un proyecto no correlaciona demasiado bien con el hecho de que el problema a resolver fuese más o menos importante en el momento de su diseño. Tampoco hay una buena relación entre el estado actual y el hecho de que aportase una mejor solución, ni con que hubiese más o menos resistencia a su implantación. La única variable que sale significativa en mi R de Reflexión es que el proceso de diseño e implantación se llevase a cabo de la manera adecuada.

¿Qué se deriva de los proyectos que se trasladan de un hospital a otro?

Esto explica por qué resulta tan difícil evitar el fracaso de los proyectos que se copian y pegan de un hospital a otro. Los éxitos en esta práctica del copypaste sin anestesia -que podría merecer un capítulo aparte- se cuentan con los dedos de la mano. Esto podemos observarlo fácilmente en tres fenómenos que se dan con frecuencia en el ecosistema hospitalario:

• Fenómeno Trasplante: Un gerente se cambia de hospital e intenta implantar en su nuevo destino proyectos que han sido un éxito en su hospital anterior.
• Fenómeno Contagio: Se intenta implantar en un hospital un proyecto de éxito del hospital vecino.
• Fenómeno Panspermia: Un gerente de hospital es nombrado director general o gerente del servicio autonómico de salud e intenta diseminar en todos los hospitales del sistema proyectos que le funcionaron en el suyo.

En los tres casos, el camino está lleno de cadáveres de proyectos que venían avalados por una historia de éxito, pero que no corrieron la misma suerte en su traslado a otros escenarios, por una sencilla razón: Se implantaron en el nuevo “huésped” saltándose todas las fases iniciales, asumiendo que ya lo sabíamos todo, que teníamos un modelo que funcionaría sin mucho esfuerzo y que podíamos incrustarlo a martillo en los demás hospitales a partir de la experiencia previa. En otras palabras, dábamos por hecho que la aceptabilidad estaba garantizada.

La realidad es que la historia de la gestión hospitalaria está llena de buenísimos proyectos que fracasaron por culpa de una inadecuada metodología en su desarrollo. Tampoco faltan ejemplos de aquellos que jamás deberían haberse implantado, pero la validación de las hipótesis llegó  demasiado tarde,  con demasiados recursos, tiempo y energía invertidos, y no quedó otra que tirar hacia delante. ¿Nunca has visto un elefante en un hospital? Yo sí.

Pero vayamos al lío Lean Startup y cómo nos puede ayudar a evitar los fracasos estrepitosos que todos hemos experimentado al intentar la innovación organizativa. Esta metodología se basa fundamentalmente en evitar aquello de la “parálisis por el análisis”. Básicamente es pasar de pesadísimos y ásperos procesos de diseño con grupos de trabajo insufribles, donde no damos un solo paso hasta que el proyecto está perfectamente terminado y empaquetado, a empezar a pilotar rápida, ágil y precozmente, eso sí, con una capacidad igualmente ágil de evaluar, aprender, corregir, mejorar, y en su caso, abortar la misión en cuanto se evidencia que no funciona y no podemos corregirla lo suficiente a un coste razonable. Con todo ello nos ahorramos una gran inversión de tiempo, recursos, energías, y una buena dosis de frustración.

Eso sí. Que lo hagamos rápido y lo saquemos al terreno precozmente, no significa que lo hagamos de manera chapucera. Se trata de tener en cuenta lo que importa y no tener en cuenta lo que no, y poner en marcha la primera versión lo antes posible, sabiendo que la última versión tal vez no se parezca mucho a la idea original que tenías en tu maravillosa cabeza. Por cierto, voy advirtiendo que el método Lean Startup requiere elevadísimas dosis de humildad. Que nadie diga que no estaba avisado.

Una de las subfilosofías que subyacen en el Lean Startup es la conocida como “Fail Fast”, que podríamos traducir como “si vas mal, date cuenta lo antes posible”. Esto puede contrastar con nuestra mentalidad clínica del “Zero Fail”. Pero no hablamos de testear con Lean Startup nuevas técnicas de cirugía cardiaca, sino de mejoras organizativas ante problemas que ya están suponiendo una merma en la calidad de los servicios. Que nadie se asuste.

¿Qué diferencias hay entre EL MÉTODO TRADICIONAL y EL MÉTODO LEAN STARTUP?

DIFERENCIAS ENTRE EL MÉTODO TRADICIONAL Y EL MÉTODO LEAN STARTUP

Adaptación para innovación organizativa hospitalaria

(Fail Fast, Fail Cheap, Fail Happy es el título de un libro sobre Lean Startup de la autora Sonia Lin, de 2014, pero sigue vigente)

De forma muy esquemática, podríamos resumir así las aportaciones del Lean Startup al diseño, desarrollo e implantación de proyectos de innovación organizativa hospitalaria, a modo de secuencia de actuación:

1. El Problema. Conceptualización y cuantificación sin entrar en causas ni en soluciones. Basado en datos. Formulación de hipótesis concretas. De esto ya hemos hablado.

2. Análisis de las alternativas actuales de solución. ¿Cómo lo está resolviendo la gente? Buscar mejorar lo actual. También lo hemos comentado más arriba.

3. Propuesta de solución innovadora (Borrador. Siempre borrador). Aquí es importante tener muy claro que tu idea inicial va a sufrir muchos cambios. Por eso no hay que emplear mucho tiempo ni recursos en perfilarla demasiado. Hay que lanzar la primera propuesta viable y evaluar su acogida. Si se ha creado un grupo de trabajo, hackear la secuencia habitual de reuniones para facilitar la precocidad del proceso. Por ejemplo, reuniones cortas y frecuentes mejor que largas y una vez al mes. Acortamos sustancialmente el tiempo de diseño, y la efectividad de las reuniones se multiplica.

4. Previsión de costes para el usuario. (Los que hemos visto anteriormente, y otra lista similar en el caso de pacientes).

5. Validación de hipótesis y de la propuesta de solución mediante entrevistas con profesionales y pacientes. Aquí si debemos detenernos un poco, porque en este escenario se empezarán a validar nuestras hipótesis. Para ello es clave hacer una buena segmentación por perfiles y por actitudes previas.

• a) Segmentación por perfiles. Ojo con el sesgo de selección. Por ejemplo, podemos validar la idea solo con médicos y tener un feedback fantástico, y olvidarnos de preguntar, por ejemplo, a los celadores, en un proyecto donde son ellos los que asumen mayor coste de adquisición. Puedes tener a todos los jefes de servicio in love con el proyecto, y que te lo acabe tumbando no haber pulsado la opinión de un colectivo del que se requería mucha implicación y cuya aceptabilidad puede resultar clave para el éxito.
• b)Segmentación por actitudes: Validar las hipótesis solo con quien siempre colabora y está abierto al cambio puede darnos igualmente falsos positivos. Igual al contrario. Los falsos negativos pueden hacer que frenemos muchos proyectos interesantes.

6. Tras estos pasos, que pueden realizarse de manera muy ágil, decidimos si abortamos misión, o por el contrario introducimos las mejoras detectadas y pasamos rápidamente al pilotaje.

7. Algunas recomendaciones Lean Startup:

1. Pilotar en varios segmentos (no solo en entornos amables)
2. Pilotajes rápidos (semanas, no meses)
3. Incorporación rápida y ágil de mejoras dentro del pilotaje. No esperar. (identificación de pivotes)
4. Pasar rápidamente al escalado

8. ESCALAR RÁPIDAMENTE. Una vez que el pilotaje ha evidenciado que tenemos un proyecto depurado y que “tracciona” bien con los protagonistas en términos de aceptabilidad, no hay motivo alguno para planificar una implantación demasiado progresiva. Siguiendo la filosofía Lean Startup, el proyecto puede escalarse hasta su ámbito completo de desarrollo.

¿Qué recomendaciones habría que tener en cuenta?

Como últimas recomendaciones a tener en cuenta, algunos consejos a modo de propina:

• Mucha humildad. Hay que saber dar marcha atrás. Siempre es mejor darse cuenta de que algo no funciona cuando no hemos invertido muchos recursos, y sobre todo, muchos meses de trabajo.  Es la ventaja de este método.

• Vacunarse continuamente contra el sesgo de confirmación. Podemos tener tendencia a visualizar solo aquellos insights que nos confirman nuestras hipótesis, infraponderando los que nos señalan en otra dirección.

• Aislarse del sesgo de derechos de autor. Sabemos que estabas muy orgulloso de tu idea original, pero debes estar abierto a modificarla a cambio de sacar adelante el proyecto. Atrincherarse en lo de “en mi cabeza era genial”, además de ser anti-lean, te convierte a ti mismo en resistente al cambio. Analiza también tus propios costes. A qué cosas estás dispuesto a renunciar para sacar adelante la mejora y solucionar el problema del que partías.

• Y por último, ojo al doping de autoridad. Es importante saber medir en todo momento si el crecimiento y por tanto el éxito en la implantación de un proyecto de innovación organizativa se debe a la aceptabilidad natural del propio proyecto o está dopado por una inyección de ejercicio de autoridad del tipo “esto viene de arriba y hay que hacerlo”. Esto puede confundirnos.

A modo de conclusión, debemos ser conscientes de que aplicando esta metodología muchos proyectos de innovación organizativa se nos caerán antes de haber llenado la primera pizarra sin ni siquiera haberlos compartido con nadie. A cambio, nos habremos ahorrado mucha energía y sobre todo muchas frustraciones. Otros se caerán más adelante, con la misma consecuencia. Y lo que es más importante, la mayoría de los que lleguen al final se parecerán muy poco a lo que tenías en la cabeza.

Pero… ¿quieres catedrales o catacumbas? Tú mismo.

Nota: Lo recogido en el presente artículo refleja estrictamente mi visión personal y no representa la opinión de ninguna organización.