Antes de construir nada en la consulta de Kolkata, le hice a Mala una pregunta que más tarde consideré la más importante de todo el proyecto: “¿La consulta ha usado alguna vez un programa?” Se rio un momento. Sí, dijo, una vez. Un pariente de la doctora les había instalado, hace unos años, un software gratis, como favor. Mala lo usó una semana. Después volvió a abrir la agenda de papel, y el programa no se volvió a abrir nunca más.
Le pregunté por qué. Lo pensó y enumeró, sin rencor, más bien como quien lee una previsión del tiempo. Hacían falta demasiados clics para crear una cita. Los rótulos estaban en un idioma que entendía, pero en el que no pensaba. En el viejo ordenador de la consulta iba lento. Y cuando se equivocaba al teclear, no sabía cómo deshacerlo sin borrar el registro entero. Después de tres momentos así, la agenda era más fácil.
No era mal software. Hasta donde pude juzgar, estaba bien hecho. Solo que se había construido para otra persona, no para Mala.
La verdad más importante, primero
Un software de consulta no tiene éxito cuando se compra. Tiene éxito cuando las personas que trabajan con él cada día, tres semanas después, lo prefieren a lo que tenían antes. Todo lo demás es decoración.
Suena banal, pero cambia toda la elección. Quien elige un software por la lista de funciones elige para la persona que firma el contrato, casi siempre la doctora o el dueño. Quien lo elige por su utilidad diaria elige para quien más lo usa, y esa es casi siempre la recepcionista. Si a la recepcionista no le gusta el software, la consulta tiene un problema, por buena que fuera la lista de funciones.
Por eso construí una lista de comprobación. Nació de la historia de Mala, de las consultas con las que he hablado desde entonces y de mis propios errores. Puedes usarla con cualquier software, también con el mío.
Doce pruebas que dicen más que cualquier lista de funciones
1. La prueba de la mañana de martes. Reproduce una mañana corriente de tu consulta con tareas reales: una llamada para cambiar una cita, una paciente nueva, una consulta, una factura. No con los datos de demostración del proveedor, sino con los tuyos. Si el resultado es fluido, vale más que cualquier presentación.
2. Primero, la recepcionista. No des la versión de prueba a ti mismo, sino a la persona que más la usará, y mide cuánto tarda en crear sola la primera cita. Cuenta los clics. Si lleva más de un minuto, es una señal de alerta.
3. La prueba del wifi. Apaga internet y mira qué pasa. En el software en la nube todo se detiene; en el local sigue funcionando. Ambas cosas pueden ser correctas, pero deberías saber qué ocurre en tu consulta antes de que pase por primera vez.
4. La prueba del ordenador viejo. Instala o abre el software en el ordenador más lento de la consulta, no en tu portátil nuevo. Muchos programas van de maravilla en un equipo caro y se arrastran en un ordenador de oficina antiguo.
5. La prueba del idioma. Lee los rótulos en voz alta. ¿Entienden tus empleados cada botón al instante o tienen que adivinar? Una interfaz en un idioma en el que se puede leer pero no pensar cuesta segundos cada día y, al final, aceptación.
6. La prueba del error. Comete un error a propósito: nombre equivocado, fecha equivocada, importe equivocado. ¿Cómo se sale de ahí? Un software en el que una errata se convierte en catástrofe lo usan personas nerviosas, y las personas nerviosas recurren al papel.
7. La prueba de la salida. Pregunta: ¿cómo consigo mis datos si quiero cambiar? ¿En qué formato, con qué esfuerzo, a qué precio? Quien no tiene una respuesta clara no te vende software, sino una dependencia.
8. La cuenta a cinco años. No calcules el precio del primer mes, sino cinco años: licencia, suscripción, formación, soporte, actualizaciones, equipos, copias de seguridad. En el software en la nube, multiplica la cuota mensual por profesionales, doce meses y cinco años. En el local, cuenta el trabajo que alguien debe hacer para las copias y las actualizaciones.
9. La prueba del soporte. Hazle a la empresa una pregunta real antes de comprar, y mide cuánto tarda la respuesta y si ayuda. El soporte antes de la compra es el mejor que tendrás jamás. Si ya es malo, después no mejorará.
10. ¿Dónde están los datos y quién los respalda? No es un detalle. En el software en la nube, los datos de tus pacientes están en servidores ajenos y la empresa los respalda. En el local, están contigo y tú los respaldas. Ambas cosas tienen consecuencias que conviene entender.
11. El tiempo de aprendizaje. ¿Puede una persona aprender lo básico en una tarde? Si un programa exige dos semanas de formación, en una consulta pequeña, donde nadie tiene dos semanas, nunca se implantará bien.
12. El funcionamiento en paralelo. Antes de comprar, prevé dos semanas en las que lleves el programa nuevo y el sistema antiguo a la vez. Cuesta esfuerzo, pero muestra si lo nuevo aguanta de verdad y te deja un camino de vuelta.
Señales de alerta en las que me fijo
De las conversaciones con consultas y de mi propia experiencia tengo una lista de cosas ante las que me pongo prudente.
Una demostración que solo funciona con datos perfectos. Los datos reales de una consulta son desordenados: nombres repetidos, teléfonos que faltan, notas manuscritas. Un programa que solo brilla en el mundo ordenado nunca ha visto una consulta real.
Ningún precio claro. Si para saber el precio tienes que hablar con un vendedor, rara vez es buena señal.
Ninguna función de exportación. Quien no quiere dejarte marchar suele tener un motivo.
Grandes promesas sobre inteligencia artificial. No estoy en contra de la IA, pero cuando un proveedor de gestión de consultas presume sobre todo de eso, me pregunto si lo básico está bien.
Y una empresa que no sabe responder a “¿qué no puede hacer el programa?”. Todo software tiene límites. Quien no puede nombrarlos, o no los conoce o no quiere nombrarlos.
Cómo implantar un programa sin que acabe en el cajón
Incluso un buen software puede fracasar si la implantación va mal. Lo vi con el viejo programa de Mala: nadie se lo explicó, nadie la acompañó, y tras el primer obstáculo la agenda era más fácil.
Empieza con una persona, no con todas. Una empleada curiosa se convierte en la experta y se lo enseña a las demás. Si todas tienen que empezar a la vez, todas fracasan a la vez.
Empieza con las tareas más sencillas. Crear citas, dar de alta pacientes. Las facturas y los resultados de laboratorio vienen después, cuando lo básico está asentado.
Pon una fecha. Quien deja el sistema antiguo funcionando sin plazo, se queda con dos sistemas para siempre. Di: a partir del día uno del mes solo vale el nuevo.
Y habla a las dos semanas con quienes trabajan con él, y pregunta qué estorba. No si les gusta. Sino qué molesta. Las respuestas son oro.
Por qué fracasan las implantaciones, y rara vez es culpa del software
Desde la historia de Mala he hablado con varias consultas sobre sus experiencias, y los patrones se repiten tan claramente que quiero escribirlos.
El patrón más frecuente: la decisión se toma arriba y el trabajo ocurre abajo. La titular ve una presentación convincente, firma, y la recepcionista recibe el lunes un programa nuevo que ni ha elegido ni ha probado. Su experiencia no cuenta, y lo nota. Hace lo que se le pide, pero no lucha por el programa, y en el primer obstáculo vuelve a lo que conoce.
El segundo patrón: el programa refleja un proceso que en esa consulta ni existe. Exige campos que nadie conoce y pasos que en la consulta se hacen de otro modo. Los empleados inventan rodeos, y desde ese momento trabajan junto al programa, no con él.
El tercer patrón: tras la implantación, nadie se ocupa. Hay preguntas sin respuesta, pequeñas molestias que se acumulan y ningún lugar donde escuchen. El software no se abandona, se olvida.
Ninguno de esos tres casos es un defecto del software. Son defectos del procedimiento, y se pueden evitar.
Preguntas que me hacen las consultas sobre la elección
¿Debo elegir un programa que lo haga todo? Más bien no. Un programa que lo hace todo suele tener muchos menús, y los menús son el enemigo de la recepcionista. Elige uno que haga lo que haces cada día con pocos clics y trate el resto como secundario.
¿Nube o local? Depende de la consulta, no del gusto. Si la red es fiable, los precios son asumibles y los datos pueden estar en el proveedor, la nube suele ser más cómoda. Si la red no es fiable o quieres conservar los datos contigo, hay mucho a favor de lo local. Haz para eso la prueba del wifi y la cuenta a cinco años.
¿Cuánto tiempo debo prever? Más de lo que piensas. Cuenta con dos a cuatro semanas desde la decisión hasta un día a día en el que el programa nuevo sea natural, y en ese tiempo prevé menos citas, no más.
¿Y si los empleados no quieren? Entonces escucha antes de convencer. Casi siempre hay un motivo concreto, y suele ser más pequeño de lo que piensas: un tamaño de letra, un botón en mal sitio, un paso de más. Si eliminas el motivo, la resistencia suele desaparecer con él.
Lo que le habría aconsejado a la doctora si no hubiera querido construir nada
A veces me preguntan qué le habría recomendado a la consulta de Kolkata si yo no hubiera construido algo. La respuesta sincera tiene tres partes.
Primero: probad antes a aprovechar mejor lo que ya tenéis. Gran parte de los problemas que vi se podía reducir ya con una sola lista de citas en lugar de dos y con una regla fija para las recetas, sin ningún software nuevo. Suena a esquivar, pero es la mejora más barata y rápida, y afina la mirada para saber qué se necesita de verdad.
Segundo: si queréis un programa, coged uno que ya funcione en vuestro mundo. Un producto que se usa desde hace años en consultas de vuestra zona, de vuestro idioma y de vuestras reglas fiscales es casi siempre más seguro que cualquier novedad. Si existe, suele ser mejor elección que mi programa.
Tercero: si estáis en un hueco donde no hay nada adecuado, construid en pequeño, con las personas que trabajarán con ello y con la disposición de tirar muchas cosas. Ese fue mi caso, y no fue el camino fácil.
El examen a mi propio programa
Sería deshonesto escribir una lista así y eximir a mi propio programa. Así que se la apliqué.
La prueba del wifi la supera ClinicPlusPlus, porque es un programa de escritorio que funciona sin internet. La prueba de la salida la supera en parte: los datos están en un único archivo de base de datos que se puede abrir con herramientas comunes, pero no hay una exportación hecha a un formato que otro programa de consultas leería. En las pruebas de idioma y de aprendizaje depende de la consulta que la interfaz encaje, y eso solo puedes comprobarlo tú.
En las copias de seguridad suspende: no hay copia automática, el archivo hay que copiarlo a mano. Y en la madurez también suspende: algunas pantallas todavía son prototipos, el inicio y los informes no están conectados en todas partes a los datos reales, y la factura conforme a la normativa fiscal de la India está prevista, pero no terminada.
Lo escribo porque sé cómo se siente cuando un proveedor solo menciona las pruebas aprobadas. Si aplicas la lista a mi programa y suspende, es una respuesta legítima. Dime entonces en qué punto, para que lo haga mejor.
Una última historia
Unas semanas después de la primera conversación le enseñé a Mala una versión temprana de mi programa. Se sentó delante, y yo no dije nada. Me había propuesto mirar en silencio los primeros cinco minutos.
Creó una cita, en aproximadamente un minuto, con una pequeña duda en un punto. Luego me miró y dijo: “Aquí no sé qué tengo que pulsar.” No dijo que fuera malo. Solo dijo dónde se atascaba.
Cambié ese punto esa misma noche. Ese es, creo, todo el secreto de un software que se usa: alguien mira dónde se atasca, lo rehace, y eso se repite las veces suficientes hasta que la gente deja de dudar.
Si estás eligiendo un software para tu consulta, te deseo una prueba de la mañana de martes, una recepcionista que diga con franqueza dónde se atasca y la paciencia de escucharla.
Esta entrada describe el estado del desarrollo en el momento de su publicación.