La brecha digital invisible (Parte 3): Soluciones basadas en la ciencia para erradicar el analfabetismo tecnológico

Está claro que detectar y diagnosticar el analfabetismo técnico en jóvenes y la resistencia al cambio en veteranos sirve de poco sin un plan de acción real. La ciencia y la psicología del aprendizaje nos ofrecen marcos claros para solucionar esta situación, alejándonos de la típica formación corporativa que ha demostrado no funcionar.

El antídoto al consumo pasivo: introducir fricción técnica

Con los más jóvenes, el problema documentado por evaluaciones internacionales como el PIAAC de la OCDE es su baja capacidad para la «resolución de problemas en entornos ricos en tecnología». Para combatir esa intolerancia a la fricción de la que hablábamos, debemos obligarles a trastear con la configuración, sustituyendo el consumo pasivo por pequeños retos técnicos que revelen la lógica de los sistemas.

El Modelo de Aceptación Tecnológica (en inglés Technology Acceptance Model, o TAM de Davis) demuestra empíricamente que la adopción depende de dos factores: la «utilidad percibida» y la «facilidad de uso». Si a un cocinero no le demostramos en cinco minutos que la nueva app de trazabilidad y alérgenos le ahorrará una hora de engorroso papeleo manual, su cerebro la rechazará instintivamente.

Diagrama del Modelo de Aceptación Tecnológica (TAM) de Davis
Fuente: SciELO Colombia

El cerebro veterano exige utilidad inmediata, no manuales

Para las generaciones mayores, debemos aplicar principios de andragogía (el aprendizaje en adultos) en lugar de pedagogía tradicional. Los estudios sobre neuroplasticidad confirman que el adulto aprende resolviendo problemas inmediatos en su día a día, no tragándose un manual de usuario de 50 páginas descontextualizado de su puesto.

Nuestra responsabilidad en IT y Dirección: interfaces usables y mentoring inverso

Desde el departamento de sistemas tenemos gran parte de la culpa, y referentes como el Nielsen Norman Group han medido exhaustivamente cómo el mal diseño del software interno dinamita la moral. Necesitamos exigir y desplegar herramientas corporativas que imiten los patrones de diseño (UX/UI) de las aplicaciones móviles de consumo masivo que todos ya saben usar fuera del trabajo.

Otra estrategia validada en entornos organizacionales es el mentoring inverso cruzado. Funciona emparejando a perfiles jóvenes, que aportan agilidad mecánica e intuición táctil, con perfiles veteranos que dominan a la perfección la lógica del proceso de negocio que el software intenta replicar.

Perfil Joven (Transferencia técnica) Perfil Veterano (Contexto operativo)
Agilidad mecánica e intuición táctil con interfaces. Dominio del flujo de negocio que el software replica.
Familiaridad inmediata con patrones UX modernos. Detección de excepciones y casuísticas reales.
Tolerancia a cambios continuos de versión. Comprensión del impacto del dato en producción.
Cuadro 1. Transferencia bidireccional en dinámicas de mentoring inverso para implantaciones de software.

Erradicar para siempre la excusa del «yo de ordenadores no sé» exige pedagogía activa, diseño centrado en el usuario y, sobre todo, propósito. La alfabetización técnica ha pasado de ser un extra a convertirse en un pilar esencial para el negocio.

Migración de ERP: por qué el cambio cultural importa más que el software

El sonado fracaso de Lidl con SAP que rescatan en Teknoplof nos recuerda una verdad incómoda: implantar un sistema de gestión nunca es un mero proyecto técnico.

Supone un reto directivo de primer nivel donde responsables de departamento, usuarios clave y desarrolladores -con acompañamiento de consultoras externas en función del caso- deben remar en la misma dirección desde el día cero.

Si la organización no acompaña el proceso con una gestión activa del cambio cultural, los sobrecostes presupuestarios se disparan hasta convertir el despliegue en un desastre total.

Fracaso de implantación de ERP y resistencia al cambio en la oficina
Frustración generada por IA

El mayor error suele residir en empeñarse en reproducir los flujos viciados bajo la premisa del

"es que aquí siempre se ha hecho así"

Un software estándar no debe doblegarse a caprichos operativos heredados cuando lo razonable es adaptar el negocio a las mejores prácticas del sector. Algunos ejemplos de esos caprichos operativos:

  • Sistemas de codificación manuales: Empeñarse en mantener referencias de artículos o cuentas contables «inteligentes» (donde cada dígito significa una familia, zona o subfamilia) diseñadas hace treinta años, en lugar de confiar en identificadores estándar combinados con atributos, categorías y filtros dinámicos.
  • Circuitos de aprobación sobredimensionados: Forzar al sistema a replicar flujos jerárquicos donde tres firmas distintas validan un pedido de compra menor, simplemente porque en papel siempre se pasaba por tres despachos, en vez de fijar umbrales automáticos de delegación.
  • El «informe de toda la vida»: Exigir desarrollos a medida para recrear al milímetro hojas de cálculo o listados antiguos en papel continuo, obligando a los consultores a programar consultas complejas en lugar de enseñar al equipo a explotar las vistas, tablas dinámicas y cuadros de mando nativos.
  • Gestión de inventario por ubicación fija: Exigir que un producto solo pueda guardarse físicamente en un hueco concreto del almacén porque «el operario ya sabe dónde está», rechazando la lógica del ERP de gestión caótica u optimizada por algoritmos de rotación y cercanía.

Vencer esa resistencia y atreverse a podar procesos obsoletos permite ganar agilidad operativa de forma inmediata. A corto, medio y largo plazo, simplificar la operativa ahorra miles de horas de mantenimiento, consultoría y desarrollos a medida innecesarios.

Riesgos directos de modificar el estándar

  • Deuda técnica y bloqueo ante actualizaciones: Cada línea de código personalizado aleja a la empresa de la rama principal del fabricante. Cuando llega una actualización de seguridad, un service pack o una versión mayor, los desarrollos a medida se rompen, encareciendo y retrasando enormemente el mantenimiento.
  • Dependencia crítica de consultoría: Los desarrollos ad-hoc convierten la solución en una caja negra conocida únicamente por el programador que la escribió. Si la consultora cambia de equipo o finaliza el contrato, la empresa queda atrapada con funciones que nadie más sabe mantener ni documentar.
  • Pérdida de rendimiento e inestabilidad: Las bases de datos y la arquitectura de un ERP comercial están optimizadas para sus flujos nativos. Las modificaciones forzadas suelen generar bloqueos de tablas, lentitud en las transacciones masivas e inconsistencias entre módulos (por ejemplo, entre almacén y contabilidad).
  • Multiplicación exponencial de costes y plazos: Desarrollar, probar y depurar funcionalidades a medida consume la mayor parte del presupuesto de horas de consultoría. Esto agota los recursos antes de llegar a fases clave como la formación y el acompañamiento a los usuarios.
  • Falsa ventaja competitiva: Rara vez un proceso administrativo interno viciado aporta valor real frente a la competencia. Adaptar la organización al estándar permite adoptar automáticamente las mejores prácticas probadas en miles de empresas del sector, liberando tiempo para innovar en lo que de verdad diferencia al negocio.

Al final, implantar un ERP no va de instalar un software nuevo sobre una empresa vieja, sino de tener la valentía directiva de repensar cómo trabajamos.

Si pagas millones por un sistema diseñado con las mejores prácticas del mercado para luego obligarlo a comportarse exactamente igual que tu Excel de hace quince años, el problema nunca fue la tecnología.

Optimización del Triaje de Tareas – Superar el Síndrome de la Prioridad Media por Defecto

La tendencia a catalogar cualquier incidencia con «prioridad media» satura irremediablemente la gestión del tiempo diario -algo muy valioso y que en los Departamentos de IT no sobra. No se dónde escuché que los españoles somos bastante tibios a la hora de rellenar cuestionarios. Y cuando los recursos son limitados, depender de la urgencia percibida por el usuario final paraliza la resolución de problemas verdaderamente estructurales.

Un sistema de triaje manual eficiente requiere sustituir esta etiqueta ambigua por preguntas directas sobre el impacto real del bloqueo. Evaluar cuántas personas están afectadas o si existe una alternativa temporal permite asignar el esfuerzo de forma puramente objetiva.

Aplicar métodos directos como la Matriz de Eisenhower durante la revisión diaria ayuda a discernir el ruido operativo de las tareas críticas. Procesar la bandeja de entrada en bloques de tiempo definidos resulta mucho más ágil que reaccionar continuamente a cada nueva petición

Matriz de Eisenhower en Asana
Fuente: Asana

Sin embargo, como acción inicial podemos limitar las opciones iniciales a «crítico» o «estándar» y así forzaremos una clarificación inmediata del contexto de la tarea. Esta pequeña simplificación reduce la fatiga de decisión y asegura el avance del trabajo sin necesidad de configurar flujos condicionales de software.