Limitaciones del software enlatado: dudas antes de renovar
Las limitaciones del software enlatado no suelen verse en la demostración comercial: aparecen después, cuando el negocio necesita algo que el producto no contempla y la respuesta del proveedor es una lista de espera. Conviene revisarlas antes de renovar una suscripción o sumar módulos.
Un software enlatado, también llamado comercial o empaquetado, es un producto ya desarrollado que se vende a muchos clientes, con funciones pensadas para necesidades comunes. Para tareas estándar rinde bien. Los problemas empiezan cuando la empresa tiene que cambiar sus procesos para encajar en la herramienta, y estas preguntas ayudan a medir hasta dónde llega ese costo.
¿Cuáles son las limitaciones del software enlatado más comunes?
Son cuatro:
- poca personalización, que obliga a cambiar procesos internos para que encajen en la herramienta;
- costos ocultos en licencias, renovaciones y complementos que se acumulan con los años;
- integración limitada cuando no hay conectores o APIs compatibles con los sistemas existentes;
- dependencia de la hoja de ruta del fabricante, que decide la evolución del producto según sus prioridades comerciales.
Las cuatro vienen del mismo lugar: un producto que tiene que servirles a empresas muy distintas.
¿Por qué personalizarlo sale cada vez más caro?
Porque cada cambio al estándar hay que sostenerlo en cada versión nueva. Lo explica la propia SAP en su curso de implementación de SAP S/4HANA Cloud Private Edition: en los talleres de fit-to-standard se les recuerda a los expertos de cada área del cliente que cualquier cambio al proceso estándar genera más trabajo de mantenimiento con las futuras actualizaciones, y por eso solo se relevan los requisitos críticos.
Un campo adicional en la ficha de cliente o una regla de aprobación distinta parecen cambios menores, pero cada versión nueva obliga a revisar que sigan funcionando. En la práctica, la empresa queda frente a dos costos: mantener sus ajustes en cada actualización o resignarlos y trabajar como el producto propone. Conviene preguntarle al proveedor, antes de firmar, quién paga la revisión de esos ajustes en cada actualización.
¿Cuánto pesa la licencia por usuario cuando la empresa crece?
En el modelo SaaS comercial cada usuario nuevo suma costo mensual, así que el gasto crece al ritmo del equipo. Con un desarrollo propio se puede pasar de 10 a 10.000 usuarios sin pagar licencias de terceros, aunque el soporte, la seguridad y la infraestructura siguen costando.
La cuenta completa suma renovaciones, módulos adicionales y las horas que el equipo dedica a tareas manuales. Un desglose de los costos del software enlatado frente al desarrollo a medida ayuda a ordenar esa comparación con los números de tu empresa.
¿Quién decide qué funciones llegan y cuándo?
El fabricante. La evolución de una herramienta comercial depende de sus decisiones comerciales, y el código y la tecnología le pertenecen. Si tu empresa necesita un cambio que no está en la hoja de ruta, puede pedirlo, pero no puede priorizarlo.
Para procesos comunes rara vez molesta, porque lo que pide tu empresa suelen pedirlo también otros clientes. Para un proceso particular, la espera puede no terminar nunca.
¿Qué pasa con la integración con los sistemas que ya existen?
Depende de los conectores que ofrezca el producto. Si no hay APIs compatibles con el ERP, el CRM o las bases de datos que la empresa ya usa, integrarlo se vuelve difícil y puede terminar en exportaciones manuales de archivos. Cada exportación es una tarea que alguien tiene que acordarse de hacer, y un dato cargado dos veces puede quedar distinto en cada sistema.
Un desarrollo a medida se conecta con esos sistemas a través de APIs hechas para ese negocio, y es una de sus ventajas más claras frente al enlatado.
¿Cuándo las limitaciones del software enlatado justifican un desarrollo propio?
Cuando afectan un proceso que diferencia a la empresa o cuando las herramientas actuales ya limitan la operación. Si el proceso es común, suele convenir convivir con las limitaciones y aprovechar la rapidez del estándar. Una forma de detectar el caso es mirar dónde se concentran los reclamos internos: si casi todos apuntan al mismo proceso, ahí está la discusión.
Antes de dar el paso hay que mirar el otro lado: más inversión inicial, meses de desarrollo y pruebas, y un socio tecnológico capaz de dar soporte continuo. Si ese socio no está, el desarrollo propio cambia una dependencia por otra.
