Hay expresiones que parecen llevar implícita una promesa. “Hecho a medida” es una de ellas.
En casi cualquier ámbito, desde un traje hasta un servicio profesional, tendemos a pensar que aquello que ha sido diseñado específicamente para nosotros será mejor: más cuidado, más completo y mejor adaptado.
Y es lógico que traslademos esa percepción también a la tecnología. Sin embargo, en el ámbito del software, lo más personalizado no siempre es lo que mejor funciona ni lo que más valor aporta a largo plazo.
Lo veo con frecuencia cuando hablamos con una organización que está buscando un LMS. La conversación suele empezar con preguntas sobre funcionalidades, usuarios o necesidades concretas. Pero, tarde o temprano, aparece una petición que parece casi inevitable:
«¿Y esto se puede personalizar?»
A veces la pregunta va un poco más allá.
«¿Podemos tener una funcionalidad específica?»
«¿Podemos cambiar este proceso?»
«¿Podemos hacer que funcione exactamente de esta manera?»
Estas preguntas son completamente comprensibles. Todos queremos que la tecnología se adapte a nuestra forma de trabajar. Pero conviene distinguir entre personalizar una plataforma y desarrollar una versión diferente para cada cliente.
Una solución SaaS puede ser flexible, configurable y capaz de adaptarse a distintos procesos, permisos, comunicaciones, integraciones o identidades visuales, manteniendo un núcleo común. Otra cosa es modificar ese núcleo con desarrollos exclusivos que después habrá que mantener y evolucionar de forma independiente.
Y es curioso, porque en muchas ocasiones la petición de desarrollar algo específico aparece incluso antes de empezar a utilizar la plataforma. Como si una solución estándar fuese, por definición, insuficiente. Como si una plataforma a medida tuviese que ser necesariamente superior. Y creo que merece la pena detenerse un momento a pensarlo.
Lo hecho a medida tiene muy buena prensa
Esa percepción también condiciona la forma en que planteamos un nuevo proyecto tecnológico. Antes incluso de empezar a utilizar una plataforma, es fácil construir una imagen muy precisa de todo lo que nos gustaría que hiciera y de cómo debería hacerlo.
Queremos que este proceso funcione de una determinada manera, que aparezca este botón, que los usuarios sigan exactamente este recorrido, que la interfaz tenga determinadas características o que una funcionalidad se comporte de forma diferente porque nuestra organización trabaja así. Y, técnicamente, muchas veces puede hacerse.
El problema es que un desarrollo a medida no termina cuando entra en funcionamiento. Ahí comienza una fase menos visible: su mantenimiento y evolución.
Cada actualización obliga a revisar las adaptaciones realizadas para comprobar que siguen funcionando correctamente ante los cambios tecnológicos. Esto requiere tiempo, recursos y conocimiento especializado. Cuanto mayor es el volumen de código propio, más exigente resulta su gestión a largo plazo, y aquello que al principio parecía una ventaja puede acabar generando una complejidad que no se había previsto.
Probar antes de construir
Antes de poner en marcha un nuevo proyecto, es habitual que una organización construya mentalmente su LMS perfecto. Imaginamos cómo deberían funcionar los procesos, qué recorrido seguirán los usuarios, qué informes necesitaremos o qué funcionalidades serán imprescindibles.
Sin embargo, esa plataforma ideal suele definirse antes de haber comprobado cómo se utilizará realmente, qué dificultades encontrará el equipo, qué demandarán los alumnos o qué datos serán verdaderamente útiles para gestionar y mejorar la formación. En ese momento no estamos diseñando a partir de la experiencia, sino de suposiciones que pueden ser razonables, pero que siguen siendo suposiciones.
Por eso, antes de convertir todas esas ideas en un desarrollo a medida, puede ser más sensato comenzar con una solución ya existente, configurarla para un proyecto concreto y ponerla a prueba mediante un piloto.
Esa primera experiencia permite entender cómo se utilizará realmente la plataforma, observar cómo responden los usuarios, ordenar prioridades y distinguir entre lo que parecía necesario y lo que realmente aporta valor.
Después quizá confirmemos que necesitamos avanzar hacia un desarrollo a medida, pero lo haremos con mucho más conocimiento. O quizá descubramos que una solución bastante más sencilla ya resuelve bien lo importante.
Lo estándar no tiene por qué ser básico
Esta es otra percepción que deberíamos revisar. Cuando hablamos de una solución SaaS sencilla de contratar, que no necesita instalación y tiene una cuota mensual asequible, algunas personas piensan que debe tratarse de una herramienta básica: limitada, pequeña o menos potente que una desarrollada específicamente para ellas.
Sin embargo, la realidad no siempre funciona así. Que una solución no necesite instalación o tenga un precio accesible no significa necesariamente que sea una herramienta básica.
De hecho, a menudo ocurre justo lo contrario.
Pensemos en algunos de los servicios digitales que utilizamos habitualmente. Microsoft 365, Canva y muchas otras herramientas funcionan bajo modelos de suscripción. No compramos un desarrollo diferente para cada empresa ni utilizamos una versión creada específicamente para nosotros. Utilizamos un producto común que evoluciona constantemente y, probablemente, esa sea una de sus mayores fortalezas.
El modelo SaaS parte precisamente de esa filosofía. Existe un mismo núcleo de producto para todos los clientes. Cuando se mejora una funcionalidad, cuando se corrige una incidencia, cuando se refuerza la seguridad o cuando se optimiza un proceso, esa evolución llega al conjunto de usuarios.
Eso cambia bastante las cosas, porque el software deja de evolucionar únicamente a partir de las necesidades de una única organización y empieza a hacerlo a partir de la experiencia acumulada de muchas.
El valor del conocimiento colectivo
Hay otra ventaja de este modelo que a veces pasa desapercibida. Una plataforma SaaS acumula conocimiento: un conocimiento colectivo que termina incorporándose al producto.
Cuando una misma plataforma es utilizada cada día por miles de organizaciones, administradores, docentes y cientos de miles de alumnos, el software se pone a prueba constantemente en situaciones reales.
Es decir, se utiliza de maneras diferentes, aparecen necesidades distintas y se detectan comportamientos que quizá el equipo de desarrollo nunca habría previsto. Y, a partir de esa experiencia, se corrigen errores, se optimizan procesos y surgen nuevas oportunidades de mejora.
Cada cliente utiliza la plataforma para su propio proyecto y, al mismo tiempo, contribuye indirectamente a que el producto evolucione.
Y creo que ahí existe una diferencia importante.
En una solución desarrollada exclusivamente para una organización, la evolución depende de sus necesidades, su presupuesto y su capacidad para seguir invirtiendo. En una solución SaaS, una mejora que resuelve un problema común puede incorporarse al producto y llegar al conjunto de clientes.
¿Cuándo tiene sentido elegir una solución a medida?
No existe una única respuesta. Hay organizaciones con procesos muy específicos, necesidades realmente singulares o modelos de negocio para los que una solución estándar simplemente no es suficiente.
Si sabemos exactamente qué necesitamos, lo hemos contrastado en un entorno real, entendemos por qué ninguna solución existente lo resuelve y estamos dispuestos a asumir el coste de desarrollarlo, mantenerlo y hacerlo evolucionar, probablemente tenga sentido hacerlo.
Pero antes de llegar a esa conclusión, quizá deberíamos preguntarnos si esa necesidad es realmente imprescindible. Porque, en ocasiones, pedimos que la tecnología reproduzca exactamente nuestros procesos actuales sin preguntarnos si esos procesos siguen siendo la mejor forma de trabajar.
Y quizá deberíamos invertir el razonamiento.
Primero habría que entender qué queremos conseguir. Después, comprobar si existe una plataforma que ya lo resuelva y, siempre que sea posible, probarla en un proyecto piloto. Solo cuando la experiencia confirme que ninguna solución disponible responde a esa necesidad tendría sentido plantearnos construir algo diferente.
Puede parecer una diferencia pequeña, pero cambia completamente la forma de abordar un proyecto tecnológico.
Empezar por la necesidad, no por la personalización
Después de años trabajando en este sector, cada vez tengo más claro que, al tomar decisiones tecnológicas, tendemos a pensar en lo que podríamos necesitar algún día en lugar de centrarnos en lo que realmente necesitamos hoy.
A veces descubriremos que una solución estándar es suficiente. Que no necesitamos crear un proceso completamente nuevo. Que ese botón concreto, esa modificación específica o esa funcionalidad desarrollada exclusivamente para nosotros no va a aportar tanto valor como pensábamos.
Otras veces no será así. Y habrá que buscar o construir una solución diferente.
La tecnología debería ayudarnos a avanzar, no convertirse en una preocupación constante. Al final, una plataforma de formación no genera valor por la cantidad de código personalizado que incorpora, sino por su capacidad para ayudar a las personas a aprender, facilitar el trabajo de quienes gestionan la formación y evolucionar con las necesidades de la organización.
En EvolMind creemos en el modelo SaaS por esa razón. No porque pensemos que las soluciones a medida sean siempre una mala elección, sino porque consideramos que, para muchas organizaciones, la tecnología no debería convertirse en un proyecto en sí misma.
La mejor solución no es la que nos permite cambiarlo todo. Es la que resuelve bien lo importante y nos permite concentrarnos en nuestro verdadero objetivo: mejorar la formación.
