En mis últimos artículos me he centrado en analizar las tecnologías más interesantes para la gestión y la atención del cliente, y reflexionar sobre su uso desde una perspectiva racional y coherente, que sirviera para alinear y satisfacer las expectativas de la empresa y las del cliente. En esta ocasión me gustaría hacer una reflexión sobre la cultura, tan extendida, de buscar continuamente aplicaciones desarrolladas a medida, exactamente confeccionadas como definen los equipos que participan en los proyectos de implantación.
Esta forma de implantar y utilizar una aplicación dentro de nuestra empresa puede ser fantástica cuando pensamos en desarrollar algo muy específico que requiere pocos cambios y pocas integraciones con otras aplicaciones y/o productos de terceros. Sin embargo, esa forma de implantar y utilizar una aplicación tiene en su contra que oculta todas las bondades con las que dichas aplicaciones fueron originalmente diseñadas. Todas las aplicaciones estándar en Contact Centers, CRMs, BPMs, portales web, ERPs, pasarelas de pago, apps, etc. tanto en modo on-premise como en modo Cloud / SaaS, están pensadas para cubrir las necesidades y funcionalidades en un alto porcentaje de lo que puede requerir cualquier compañía, y tratan de reducir a algunos casos específicos aquellos donde se requiere desarrollos personalizados que cubran funcionalidades no propias del producto.
¿Qué es lo que encontramos en el día a día de los proyectos?
Desarrolladores para todo
Casi todas las aplicaciones suelen ofrecer pasarelas para integración con otras aplicaciones terceras y, además, los fabricantes han ofrecido lenguajes más estándar y pasarelas más abiertas para facilitar las integraciones.
Es el boom de conseguir un ejército de programadores en plantilla o subcontratarlo “de forma económica” a una proveedor para realizar desarrollos altamente complejos que no somos capaces de evolucionar, ni de integrarlos con el resto de servicios que la propia compañía demanda, a la velocidad con la que la transformación digital está exigiendo que nos pongamos al día.
Rechazo al cambio
Básicamente nadie se plantea que las cosas se hacen hoy de una forma concreta porque, o históricamente alguien las definió así debido a que años atrás era una buena forma de trabajar o porque no había otras alternativas a elegir.
¿Tenemos un botón similar pero que no hace exactamente lo mismo? pues entonces pido desarrollarlo a medida. ¿Tenemos estadísticas que contabilizan indicadores con una lógica X? pues nadie se plantea si puede ser mejor que como se hacía, y se crean estadísticas con fórmulas personalizadas. ¿Tenemos funcionalidades en el sistema antiguo que no sabemos si se utilizan y parece que tienen poca aportación? pues al migrar a un nuevo sistema, los creamos todos a medida, por si fuera necesario. ¿La disposición de la interfaz es diferente en el nuevo sistema? pues lo primero que debemos hacer es cambiar todo para que sea exactamente igual a como estaba en el sistema anterior…
Pantalla única
Este es el mayor esfuerzo de casi todas las compañías en los últimos años, consistente en integrar todas las aplicaciones que tenga la compañía en una sola pantalla o interfaz para que, desde ella, se pueda hacer todo. Dicho así cualquiera lo compraría, pero nadie valora que integrarlo es bastante complejo en la mayor parte de los casos, que las funcionalidades propias que ofrece el producto estándar posiblemente ya no existen porque habrá que desarrollarlas en esa pantalla única, que cada evolución o actualización de algunos de esos productos de forma individual afectará a esa pantalla única, o que si buscamos que la información trabaje en tiempo real entre todos los sistemas es posible que tengamos diferentes limitaciones.
Proyectos indefinidos en el tiempo
Con tanta integración compleja entre todos los sistemas lo que sucede en la mayor parte de las ocasiones es que cualquier cambio que se desee realizar, por pequeño que sea, se convierte en un proyecto de larguísima duración ya que la dependencia entre todos los sistemas hace que se requiera una metodología estándar de ingeniería de software en lugar de buscar una metodología ágil de implementación. Además, en muchas ocasiones, no se pueden añadir cambios en cualquier momento, y esto requiere procesos de gestión del cambio y pases a producción preestablecidos a lo largo del año donde se aplican múltiples cambios.
¿Qué conclusiones se pueden obtener de las reflexiones anteriores?
Cada compañía y necesidad es un mundo para decidir cuál es el camino que se debe tomar sobre el nivel de integración y personalización de las aplicaciones que utilice, pero lo que sí sería más sano es que se valorasen más las funcionalidades y procesos estándar de las aplicaciones puesto que, en muchas ocasiones, cambiar la forma de trabajar de las personas no es tan difícil si las herramientas que tienen que utilizar les ayudan en su día a día.
Las aplicaciones evolucionan y, generalmente, es debido a que el mercado está demandando necesidades nuevas que hacen que los procesos antiguos, que llevan muchos años haciéndose de una única forma, se deban revisar y adaptar para mejorar.
Echo en falta que los fabricantes pongan a disposición de los clientes buzones de sugerencias o ideas de mejoras de las aplicaciones que realmente funcionen. Quiero decir con esto que no sirve de nada crear entradas en los foros de ideas si no existe una respuesta indicando si se incluye o no esa mejora en alguna versión próxima, o indicando el por qué no se puede implementar.
Puede parecer una reflexión un poco pesimista pero me gustaría que nadie pierda la esperanza de que los desarrollos son útiles y necesarios: todo en su justa medida.
