No todas las empresas necesitan ponerse al día

Hay empresas que saben qué necesitan mejorar y pueden comprar la herramienta adecuada, pero no tienen el equipo necesario para incorporarla.

No siempre es un problema de presupuesto. Tampoco de voluntad. Entre la herramienta y la operación hay una distancia llena de datos que no encajan, aplicaciones construidas en momentos distintos, decisiones que nadie ha escrito, excepciones que solo conocen algunas personas y procesos que funcionan porque alguien sabe dónde mirar cuando algo se desvía.

Monreal & Meadow trabaja precisamente en esa distancia. Formamos un equipo modular alrededor de un resultado concreto y reunimos las capacidades de negocio, operaciones y tecnología que la empresa no tiene internamente. Partimos de los sistemas que ya existen, construimos la conexión con la nueva herramienta y preparamos a la organización para gobernar el resultado.

El beneficio no es sumar personas durante un proyecto. Es incorporar ahora una capacidad que todavía no existe dentro de la empresa y conservarla cuando el equipo se retira, sin contratar de entrada una estructura tecnológica completa, sustituir todo lo que funciona ni ceder el control a un proveedor.

La respuesta habitual es que la empresa debe ponerse al día. Migrar sus sistemas, ordenar todos los datos, documentar los procesos, contratar un departamento tecnológico y construir primero la base que nunca tuvo. Después, cuando termine esa transformación, ya podrá adoptar la herramienta nueva.

El planteamiento parece razonable. También puede convertir el punto de partida en una condena: como la empresa no tiene capacidad para modernizarse, debe modernizarse antes de poder adquirir capacidad.

Nuestro planteamiento cambia el orden. En lugar de reproducir una por una todas las etapas que le faltan, la empresa incorpora las capacidades necesarias para una misión concreta y avanza desde el punto en el que se encuentra.

No es una forma de saltarse el trabajo. Es una forma distinta de recorrerlo.

India no necesitó desplegar primero una línea fija para cada móvil

El concepto de leapfrogging se utiliza para describir un salto entre generaciones tecnológicas: adoptar una infraestructura nueva sin extender antes, en la misma escala, la generación anterior. La Unión Internacional de Telecomunicaciones ha utilizado precisamente la expansión del móvil frente a la línea fija como ejemplo de este patrón: World Information Society Report 2007.

La telefonía en India ofrece una imagen especialmente clara. Según las estadísticas de su Departamento de Telecomunicaciones, en 2001 el país tenía 3,58 millones de suscripciones móviles y 32,70 millones de líneas fijas. En 2010, las suscripciones móviles habían alcanzado los 584,32 millones, mientras las líneas fijas se situaban en 36,96 millones. El gran aumento de las suscripciones no llegó después de construir una red fija equivalente. Ocurrió sobre la tecnología móvil: Telecom Statistics India — 2025.

Sería un error contar esta historia como si bastara con repartir teléfonos. India no se saltó la necesidad de infraestructura, inversión, operación ni reglas. Su política nacional de telecomunicaciones de 1999 ya relacionaba la expansión del acceso con la participación privada, la competencia, la reducción de tarifas, los avances tecnológicos y nuevas categorías de licencias: New Telecom Policy, 1999.

El móvil permitió evitar una etapa, pero exigió construir las condiciones de la siguiente.

Ahí está la parte útil de la analogía. Saltar no significa ignorar lo que falta. Significa distinguir qué etapas ya no son necesarias y qué capacidades siguen siendo imprescindibles.

Comprar acceso no es incorporar capacidad

La misma diferencia aparece dentro de una empresa. Contratar una plataforma en la nube, activar una licencia de inteligencia artificial o comprar un nuevo sistema de gestión da acceso a una tecnología. No garantiza que la organización pueda utilizarla para trabajar de otra manera.

Para eso necesita reconocer qué problema puede resolver, conectarla con información fiable, adaptarla a sus reglas, decidir quién responde de sus resultados y aprender a operar cuando aparece una excepción. Necesita, en definitiva, absorber una capacidad externa y convertirla en parte de su funcionamiento.

La investigación sobre innovación en pequeñas empresas lleva tiempo señalando esta dificultad. Un estudio basado en más de 1.500 propietarios de pequeñas empresas trataba la capacidad de absorber y gestionar conocimiento como una condición previa para adoptar innovaciones y crecer: Open University — Absorptive capacity, knowledge management and innovation in entrepreneurial small firms.

La observación parece abstracta hasta que llega una herramienta nueva a una empresa donde nadie puede evaluarla, integrarla ni acompañar a quienes tendrán que usarla. La tecnología está disponible. La capacidad para incorporarla, no.

Un equipo modular construye desde los dos lados

Un equipo modular sirve para cerrar esa distancia. No es una bolsa de horas ni un grupo de especialistas que recibe requisitos, entrega software y desaparece. Se forma alrededor de un resultado y combina únicamente las capacidades necesarias para alcanzarlo: conocimiento operativo, diseño de procesos, datos, integración, software o adopción, según el problema.

Debe poder trabajar desde los dos lados. Desde la tecnología, para saber qué es posible y construirlo con rigor. Desde la operación, para entender qué información existe, qué reglas deben respetarse, dónde se concentra el riesgo y qué tendría que cambiar para que la nueva solución se utilizara de verdad.

Esa doble pertenencia importa. Si el equipo solo entiende la herramienta, intentará que la empresa se adapte a ella. Si solo entiende la operación, puede limitarse a digitalizar la forma actual de trabajar, incluidos sus problemas. El módulo tiene que preservar lo que aporta valor y cuestionar lo que solo existe por inercia.

La palabra modular no significa que las personas sean intercambiables. Significa que la misión tiene una frontera comprensible, que la relación con el resto del sistema está diseñada y que la composición del equipo puede cambiar a medida que cambia el problema.

Entrar por una decisión, no por una transformación total

Imaginemos una empresa que tarda demasiado en preparar ofertas. Los datos del cliente están en un CRM sencillo, las tarifas viven en el sistema de gestión, algunas condiciones dependen de hojas de cálculo y la viabilidad técnica necesita el criterio de operaciones. Nadie diseñó el conjunto como un único flujo, pero el negocio ha aprendido a hacerlo funcionar.

Una transformación total intentaría sustituir varios sistemas, unificar todos los datos y normalizar el proceso completo antes de generar la primera oferta. Un equipo modular puede empezar de otra manera: seguir una oferta de principio a fin, identificar qué decisión produce la mayor espera, conectar solo la información necesaria y construir una intervención acotada alrededor de ese punto.

Quizá la solución lea documentación no estructurada, prepare una propuesta de requisitos y reúna los datos que operaciones necesita validar. Quizá solo haga visible una incoherencia antes de que la oferta llegue al siguiente equipo. La inteligencia artificial puede formar parte del módulo, pero no es su razón de ser. La razón es cambiar el flujo sin obligar a reemplazar de golpe todo lo que ya funciona.

Si la intervención mejora el tiempo total y reduce el retrabajo, puede ampliarse. Si no lo hace, debe poder retirarse sin haber puesto en riesgo el núcleo de la operación.

La modularidad convierte una transformación abstracta en una decisión delimitada y reversible.

Saltarse etapas no es saltarse el trabajo

Las herramientas actuales permiten construir una demostración con una rapidez extraordinaria. Esa velocidad puede crear una expectativa peligrosa: si el prototipo aparece en días, la empresa también debería cambiar en días.

No suele ser así.

La parte lenta consiste en descubrir por qué dos departamentos llaman de forma distinta al mismo dato, qué clientes necesitan una excepción, quién decide cuando una automatización duda, qué ocurre si falla una integración, cómo se comprueba un resultado y qué debe aprender el equipo interno antes de asumir el control.

Este trabajo obliga a revisar hojas de cálculo, observar decisiones, reconstruir reglas y aceptar que el proceso descrito no siempre coincide con el proceso real. También exige crear confianza entre personas que conocen el negocio pero no hablan el lenguaje de la tecnología y personas que dominan la tecnología pero todavía no entienden todos los matices del negocio.

Es difícil porque se está haciendo algo más importante que instalar una herramienta: se está traduciendo una organización.

La dificultad no justifica alargar el proyecto indefinidamente. Sí explica por qué el progreso no puede medirse únicamente por la velocidad del desarrollo. Un módulo puede estar técnicamente terminado y seguir completamente fuera de la empresa.

La transferencia empieza antes de la entrega

El riesgo más evidente de incorporar un equipo externo es sustituir una carencia por una dependencia. La empresa gana una herramienta, pero cada cambio, error o duda continúa necesitando a las mismas personas que la construyeron.

Por eso la transferencia no puede consistir en entregar documentación al final. Empieza cuando las personas de la empresa participan en las decisiones, entienden los criterios, prueban el sistema y aprenden qué hacer cuando el caso real no coincide con el previsto.

No necesitan convertirse en desarrolladores ni dominar cada pieza de la arquitectura. Necesitan poder gobernar la capacidad: saber qué resultado debe producir, reconocer cuándo se desvía, decidir qué puede modificarse y distinguir un caso ordinario de una excepción que requiere ayuda.

Un equipo modular no demuestra su valor cuando entra. Lo demuestra cuando puede salir.

Si el equipo se retira y todo deja de funcionar, no ha construido un módulo. Ha construido una dependencia.

La prueba no exige que la empresa sea autosuficiente en todo. Puede seguir necesitando soporte especializado, igual que utiliza asesoría fiscal, mantenimiento industrial o servicios jurídicos. La diferencia está en conservar el criterio y la capacidad de decisión, en lugar de delegar también la comprensión del sistema.

El punto de partida no tiene por qué decidir la trayectoria

Las empresas con pocos recursos tecnológicos suelen recibir dos propuestas igualmente difíciles de aplicar. Una consiste en comprar una herramienta estándar y esperar que la organización se adapte. La otra, en emprender una transformación completa que exige el tiempo, el dinero y los perfiles que precisamente no tienen.

Un equipo modular abre una tercera vía. Permite incorporar temporalmente una combinación de capacidades que la empresa no necesita —o no puede— mantener completa de forma permanente. Entra por un resultado concreto, trabaja con los sistemas y las personas que ya existen, construye una conexión con la nueva tecnología y deja dentro de la organización el criterio necesario para continuar.

Por eso en Monreal & Meadow no entendemos un equipo modular como un catálogo de perfiles. Es una forma de intervenir en una organización sin fingir que empieza de cero y sin convertir toda su historia tecnológica en una deuda que deba pagar antes de avanzar.

El caso de India no demuestra cómo debe modernizarse una empresa. Sí deja una idea poderosa: una limitación heredada no siempre obliga a recorrer el itinerario convencional. Es posible acceder a la siguiente generación si se construyen las condiciones que permiten incorporarla.

No todas las empresas necesitan ponerse al día.

Algunas necesitan un equipo que les permita saltar.

El salto merece la pena cuando, al terminar, la empresa ya puede sostenerlo.

Evidencias

No todas las empresas necesitan ponerse al día. Algunas necesitan saltar.