Cuando surge la posibilidad de digitalizar un servicio, una de las primeras decisiones suele ser buscar herramientas. Se comparan plataformas, se piden demostraciones, aparecen funcionalidades interesantes y empiezan a llegar presupuestos.
Es comprensible, porque es la parte más visible del proyecto, pero también puede llevarnos a elegir una solución antes de haber definido bien el problema.
Esto ocurre en ámbitos muy diferentes. Puede ser un ayuntamiento que quiere mejorar la gestión de sus actividades, una instalación deportiva que necesita organizar reservas y accesos, un evento que ha crecido o un espacio cultural que busca relacionarse de otra manera con sus visitantes.
En todos ellos merece la pena dedicar un poco de tiempo a ordenar el proyecto antes de decidir qué tecnología utilizar. No hace falta elaborar un documento de cincuenta páginas. En muchos casos, responder con cierta precisión a unas cuantas preguntas evita bastante trabajo después.
1. Empezar explicando qué queremos mejorar
“Queremos digitalizar la piscina” es una intención, pero todavía no define un proyecto.
¿Qué queremos mejorar exactamente?
Puede que el problema sean las colas que se forman en determinados horarios, que todavía se vendan entradas manualmente, que resulte difícil controlar los abonos, que no conozcamos la ocupación real o que el personal dedique demasiado tiempo a tareas administrativas.
Cada uno de esos problemas puede necesitar una solución diferente.
Por eso es útil intentar explicar la necesidad sin mencionar ninguna herramienta. En lugar de “necesitamos una aplicación para la piscina”, podríamos decir “queremos que los usuarios puedan comprar su entrada antes de llegar y reducir el trabajo de taquilla”.
La segunda frase nos permite valorar diferentes soluciones. La primera ya nos ha condicionado a utilizar una aplicación.
2. Mirar cómo funciona actualmente el servicio
Antes de cambiar un proceso conviene entenderlo.
Quién hace cada tarea, qué herramientas utiliza, qué información necesita, dónde aparecen los problemas y qué ocurre cuando algo se sale del funcionamiento habitual.
En este punto suelen aparecer detalles que inicialmente parecían poco importantes.
Quizá las reservas ya se realizan online, pero recepción tiene que comprobar los pagos manualmente. Puede que las inscripciones funcionen bien salvo cuando una actividad tiene plazas limitadas. O que el sistema de acceso sea suficiente durante todo el año pero genere problemas cuando se celebra un evento.
También merece la pena prestar atención a las soluciones improvisadas que se han ido incorporando con el tiempo. Excels, listados impresos, grupos de mensajería, formularios independientes o anotaciones manuales suelen indicar que existe una necesidad que las herramientas actuales no están resolviendo.
No significa que todo eso tenga que desaparecer. Un Excel puede ser perfectamente útil. Lo importante es entender por qué está ahí.
3. Hablar con quien utiliza el servicio y con quien lo gestiona
Un proyecto puede parecer muy sencillo visto desde un despacho y cambiar bastante cuando hablamos con las personas que trabajan diariamente con él.
El personal de una instalación sabe qué ocurre cuando un usuario pierde su identificación. La persona que gestiona las actividades conoce qué cambios de última hora son habituales. Quien organiza un evento sabe en qué momento empiezan a llegar las llamadas. Y recepción probablemente conozca las preguntas que se repiten todos los días.
También conviene observar el proceso desde el otro lado.
¿Cuántos pasos tiene que realizar el usuario? ¿Qué información se le pide? ¿Tiene que introducir los mismos datos varias veces? ¿Sabe qué tiene que hacer cuando algo no funciona como estaba previsto?
No todas las opiniones podrán convertirse en una funcionalidad y tampoco deberían hacerlo. El objetivo de esta fase es detectar problemas y situaciones reales antes de diseñar la solución.
4. Separar lo imprescindible de lo que estaría bien tener
Cuando empezamos a ver posibilidades tecnológicas es fácil que el proyecto crezca rápidamente.
Si podemos gestionar reservas, quizá también podamos incorporar notificaciones. Si tenemos usuarios identificados, podemos crear perfiles. Si existe una aplicación, podríamos añadir noticias, encuestas, promociones, estadísticas o contenidos personalizados.
Muchas de esas ideas pueden ser interesantes, pero incorporarlas todas desde el principio aumenta el coste, la complejidad y el tiempo necesario para poner en marcha el proyecto.
Una forma sencilla de evitarlo es separar las necesidades en tres grupos: aquello sin lo que el proyecto no tiene sentido, lo que mejoraría claramente el servicio y lo que podría incorporarse más adelante.
No hace falta que la primera versión resuelva todo lo que podríamos llegar a hacer algún día. Necesita resolver bien aquello por lo que hemos decidido ponerla en marcha.
5. Pensar también en las excepciones
Los procesos suelen diseñarse pensando en que todo funciona correctamente, pero una parte importante de la gestión diaria consiste precisamente en resolver lo que se sale de lo previsto.
¿Qué ocurre si alguien ha pagado pero no aparece en el listado? ¿Si un usuario no lleva el móvil? ¿Si tenemos que cancelar una actividad? ¿Si se pierde la conexión a internet? ¿Si una persona necesita modificar una inscripción? ¿Si el día del evento llegan muchas más personas a la misma hora de las que habíamos previsto?
No es posible anticipar todas las incidencias, pero sí las más habituales.
Una solución que funciona perfectamente en una demostración puede resultar incómoda cuando aparece el primer problema real. Por eso, cuando evaluamos una herramienta, además de preguntar qué permite hacer, conviene preguntar qué ocurre cuando algo no sale como debería.
6. Decidir qué información necesitamos realmente
La digitalización permite recoger muchos datos, pero acumular información no significa necesariamente conocer mejor un servicio.
Antes de empezar a registrar todo lo posible conviene decidir qué información nos ayudará realmente a gestionar.
En una instalación puede interesarnos conocer la ocupación por horarios. En un evento, la diferencia entre entradas vendidas y asistentes reales. En una actividad municipal, las plazas disponibles y la evolución de las inscripciones. En una experiencia turística, quizá nos interese saber qué espacios reciben más visitas.
La pregunta útil no es únicamente qué datos podemos obtener, sino qué decisión podremos tomar con ellos.
Además, recoger información implica responsabilidades. Los datos personales deben limitarse a aquellos que sean necesarios para prestar el servicio y gestionarse conforme a la normativa aplicable. Pedir información “por si acaso algún día nos sirve” rara vez es una buena política.
7. Pensar qué puede ocurrir después
Un proyecto puede empezar siendo pequeño y crecer si funciona.
Una instalación incorpora reservas y más adelante quiere gestionar accesos. Un municipio comienza digitalizando una piscina y después quiere utilizar parte del sistema en otras instalaciones. Un evento empieza con entradas y posteriormente necesita acreditaciones o diferentes zonas de acceso.
No necesitamos desarrollar desde el primer día todas esas posibilidades, pero sí merece la pena preguntarnos si la solución elegida permitirá crecer sin tener que empezar nuevamente desde cero.
Esto no significa comprar una plataforma enorme para cubrir necesidades que quizá nunca aparezcan. Significa evitar decisiones innecesariamente cerradas cuando sabemos que el proyecto puede evolucionar.
Entonces sí: buscar la tecnología
Después de responder a todo lo anterior estaremos en una posición bastante mejor para hablar de herramientas, proveedores y presupuestos.
Sabremos qué problema queremos resolver, cómo funciona actualmente el servicio, qué necesitan usuarios y gestores, cuáles son las funciones imprescindibles, qué situaciones excepcionales debemos contemplar y qué posibilidades de crecimiento queremos mantener abiertas.
Puede que necesitemos una plataforma completa o que descubramos que el problema se resuelve con algo mucho más sencillo. Ambas respuestas pueden ser correctas.
En hello matius! trabajamos precisamente de esta manera porque nuestras piezas permiten combinar diferentes capacidades según las necesidades del proyecto. Pero la decisión de utilizar una pieza, varias o incluso mantener determinadas herramientas que ya existen debería llegar después de entender cómo funciona el servicio.
Empezar por ahí puede parecer más lento que pedir directamente una demostración y comparar funcionalidades, pero normalmente ocurre lo contrario: cuanto mejor está definido un proyecto antes de elegir la tecnología, menos decisiones hay que corregir durante su puesta en marcha y más fácil resulta distinguir entre una funcionalidad que realmente necesitamos y otra que simplemente parecía interesante cuando la vimos.