Tu app interna para empleados: necesidad y costes

Tu app interna para empleados: necesidad y costes

Si vuestro equipo copia datos del correo al ERP, consulta instrucciones dispersas y envía fotografías de incidencias por mensajería, una app interna para empleados puede parecer la solución evidente. Sin embargo, reunir esos problemas en una pantalla no elimina por sí solo la duplicidad ni los errores. Antes de encargar desarrollo, necesitáis identificar dónde se interrumpe el proceso, qué información falta y quién tiene que actuar para que el trabajo avance.

En Fundy planteamos esta decisión desde la operativa: qué debe poder hacer cada persona, desde qué dispositivo y bajo qué condiciones. Una herramienta para personal de oficina no tiene las mismas exigencias que otra para técnicos que trabajan sin cobertura. Esa diferencia determina si basta una web bien hecha, si compensa una aplicación instalada y qué obligaciones de mantenimiento asumirá la empresa después del lanzamiento.

La pregunta previa: ¿app o web bien hecha?

Cuándo hace falta app nativa de verdad

El desarrollo nativo tiene sentido cuando el trabajo depende de capacidades del dispositivo que una solución web no puede ofrecer con la fiabilidad requerida. No basta con querer un icono en la pantalla de inicio: una aplicación web progresiva, o PWA, también puede instalarse en determinados entornos y ofrecer acceso directo, almacenamiento local y algunas funciones sin conexión. Su alcance depende del navegador, del sistema operativo y de cómo se implemente.

La decisión debe apoyarse en una prueba del proceso más exigente sobre los dispositivos que utilizará el equipo. Si el personal necesita registrar una intervención en un almacén sin cobertura, el prototipo debe probarse allí, no únicamente con la conexión de la oficina.

Estos requisitos justifican evaluar una aplicación instalada con integración nativa:

• Trabajo prolongado sin conexión, con registros, fotografías y operaciones pendientes que deben conservarse y sincronizarse. Una web también puede cubrir parte de este escenario, pero hay que comprobar sus límites de almacenamiento y ejecución.
• Si utilizáis lectores industriales, dispositivos Bluetooth o accesorios específicos, verificad qué interfaces y SDK proporciona el fabricante y en qué plataformas funcionan.
• La ejecución en segundo plano puede ser necesaria para determinadas tareas. El desarrollo nativo ofrece más posibilidades, aunque Android e iOS mantienen restricciones de batería, permisos y actividad que debéis contemplar.
• Equipos corporativos administrados mediante MDM pueden requerir distribución controlada, configuración remota y políticas de acceso que condicionen la arquitectura.
• Cuando una interacción repetida depende intensamente de la cámara, de sensores o de funciones del sistema, una integración específica puede mejorar la experiencia y reducir pasos.

Ninguno de estos puntos obliga automáticamente a mantener dos desarrollos independientes. Una solución multiplataforma puede compartir parte del código e incorporar módulos nativos donde haga falta. La comparación útil no es solo entre tecnologías, sino entre cobertura funcional, dependencias, capacidad del equipo para mantenerlas y esfuerzo de actualización.

Para aprobar vacaciones, consultar documentación, revisar indicadores o tramitar solicitudes con conexión, una web adaptable al móvil merece ser la primera alternativa que evaluéis. Permite acceder también desde el ordenador y desplegar cambios sin distribuir una nueva versión del cliente mediante una tienda de aplicaciones. Esto no elimina las pruebas de compatibilidad, pero simplifica una parte del ciclo de publicación.

No encarguéis una aplicación instalada si una web resuelve el proceso con menos componentes que mantener. La comodidad debe medirse completando tareas reales: localizar una orden, adjuntar una evidencia, corregir un dato y enviarlo. El formato elegido importa menos que la ausencia de obstáculos en esas acciones.

Antes de decidir, documentad un recorrido completo. Por ejemplo: un técnico recibe una orden, consulta instrucciones, registra materiales y cierra el parte. Para cada paso, anotad el origen de la información, los permisos necesarios, la conectividad disponible y el destino del dato. Si el cierre exige que otra persona vuelva a teclearlo en el ERP, todavía no habéis resuelto el problema de fondo.

En ese punto, el software a medida para empresas aporta valor cuando conecta requisitos propios de vuestra operativa que las herramientas disponibles no cubren de forma adecuada. No se trata de rehacer funciones comunes, sino de resolver los pasos e integraciones que impiden trabajar con continuidad.

El presupuesto inicial debe separar la interfaz, la lógica de negocio y las integraciones. Una pantalla sencilla puede esconder reglas complejas: quién puede aprobar una solicitud, qué ocurre si cambia el responsable y cómo se impide registrar dos veces la misma operación. Si todo aparece agrupado bajo una única partida de desarrollo, será difícil comparar propuestas y entender qué incluye cada una.

También conviene distinguir una consulta de datos de una integración bidireccional. Mostrar órdenes del ERP no equivale a actualizar su estado, imputar materiales y recuperar errores. Para escribir en sistemas centrales hacen falta validaciones, autenticación, trazabilidad y mecanismos de reintento. Además, debéis conocer las condiciones de acceso a sus API, incluidos límites técnicos y posibles licencias.

El funcionamiento sin conexión añade otro bloque de trabajo. Hay que decidir qué datos se descargan al móvil, durante cuánto tiempo se conservan y cómo se protegen. Si dos personas modifican una misma orden antes de sincronizar, el sistema necesita una regla de resolución: no basta con aceptar el último envío sin comprobar sus consecuencias.

Una operación pendiente debe mostrar su estado con claridad. El empleado necesita distinguir entre un parte guardado en su dispositivo y otro recibido por el servidor. La aplicación, por su parte, debe evitar duplicados si reenvía una petición después de un corte de red. Estas decisiones influyen tanto en el coste de construcción como en el soporte posterior.

El coste de mantenimiento se entiende mejor por responsabilidades que por un porcentaje del desarrollo. Sin conocer la arquitectura, los usuarios, las integraciones y el nivel de servicio requerido, dar una cuota cerrada sería ofrecer una cifra sin base. Pedid que la propuesta contemple, como mínimo, estos conceptos:

1. Infraestructura y consumo. Identificad alojamiento, base de datos, almacenamiento de archivos, copias de seguridad y servicios externos facturados por uso. Las fotografías y su retención pueden cambiar las necesidades de almacenamiento.
2. La compatibilidad requiere revisar versiones de sistemas operativos, navegadores, librerías y SDK. En aplicaciones distribuidas mediante tiendas, añadid la gestión de compilaciones, certificados y requisitos de publicación.
3. Seguridad y accesos: deben existir responsables para aplicar parches, retirar permisos, revisar dependencias y comprobar que las copias pueden restaurarse. Tener una copia no demuestra que la recuperación funcione.
4. Ante una incidencia, concretad quién recibe el aviso, en qué horario y con qué compromiso de respuesta. Corregir un fallo no es lo mismo que incorporar una nueva funcionalidad.
5. Las integraciones necesitan seguimiento propio. Un cambio en la autenticación o en el formato de datos del ERP puede exigir una adaptación aunque nadie haya modificado vuestra aplicación.
6. Reservad capacidad para evolución. Nuevos centros de trabajo, perfiles y reglas de aprobación cambian el producto; mezclarlos con mantenimiento correctivo dificulta controlar el presupuesto.

Para comparar ofertas, construid una previsión con el mismo alcance y horizonte temporal. Sumad implantación, servicios recurrentes, mantenimiento acordado y evoluciones previstas. Exigid que se indiquen las exclusiones y los supuestos de uso, porque una propuesta puede parecer más barata al dejar fuera la monitorización, el soporte o las actualizaciones de compatibilidad.

La propiedad y el acceso también forman parte del coste. La empresa debe conocer dónde están el repositorio, la documentación, las cuentas de distribución y las credenciales de infraestructura, con permisos adecuados para cada responsable. Si cambiar de proveedor obliga a reconstruir el producto por falta de acceso o documentación, existe una dependencia que debéis valorar antes de contratar.

Una herramienta interna necesita un responsable de producto dentro de la empresa, no solo un proveedor que programe. Esa persona prioriza mejoras, valida reglas y evita que cada departamento convierta la aplicación en un conjunto de excepciones. Sin este control, la deuda técnica crece con permisos improvisados, pantallas duplicadas y procesos que nadie se atreve a simplificar.

La seguridad debe acompañar al diseño de esos procesos. El acceso mediante identidad corporativa puede facilitar altas y bajas, pero los permisos han de comprobarse en el servidor: ocultar un botón no impide ejecutar una operación no autorizada. Si permitís móviles personales, definid qué información se almacena localmente y qué opciones reales existen para retirar el acceso o eliminar datos.

Cuando aparezcan funciones de ubicación, fotografías o registros de actividad, revisad su finalidad y necesidad antes de implementarlas. Una herramienta destinada a gestionar intervenciones no debería recoger información adicional sin justificación. El diseño debe contemplar protección de datos, información a las personas afectadas y obligaciones laborales aplicables.

Para validar la inversión, empezad por un proceso acotado y representativo. Medid cuánto tarda en completarse, cuántas veces exige volver a introducir información y qué incidencias generan consultas al equipo de soporte. Después, probad la solución con personas de distintos perfiles y dispositivos. No confundáis accesos a la aplicación con mejora operativa: abrirla muchas veces no demuestra que ayude a trabajar.

Antes de extenderla, verificad qué ocurre cuando caduca una sesión, falta cobertura, se interrumpe una subida o el sistema central rechaza un registro. Estas pruebas permiten detectar costes de soporte que una demostración sin errores no muestra. El despliegue necesita también instrucciones breves y un canal claro para comunicar problemas.

Si estáis valorando una herramienta interna, contactad con Fundy para plantear una consultoría de alcance técnico. Traed un proceso que hoy genere duplicidades, los dispositivos utilizados y los sistemas que deben intercambiar datos: podremos centrar la conversación en qué conviene validar antes de desarrollar y qué responsabilidades de mantenimiento deben quedar presupuestadas desde el principio.