El problema no es la herramienta, sino el sistema que la rodea

Muchas empresas ya conservan casi toda la información necesaria, pero no como un sistema. Compras mantiene composiciones y certificados; calidad custodia ensayos; operaciones conoce lotes y variantes; marketing publica características; posventa guarda manuales. Cuando cada área trabaja con una versión distinta, crear un pasaporte no es publicar información: es descubrir contradicciones. La primera oportunidad, por tanto, no es regulatoria. Es construir una fuente de producto que también reduzca consultas, errores y retrabajo.

La dirección no necesita dominar la tecnología que hay debajo. Sí necesita poder nombrar el proceso, sus estados, los datos que lo gobiernan y la persona que responde cuando aparece una excepción. Esa disciplina permite comparar tres alternativas legítimas: ajustar una herramienta existente, conectar varias piezas o desarrollar una capa propia. También permite decidir que todavía no merece la pena automatizar.

Cinco señales de que conviene ordenar el proceso

• Una misma referencia aparece con nombres o atributos distintos en ERP, web y documentación.
• Los certificados llegan por email y no quedan vinculados a producto, proveedor, lote y vigencia.
• Actualizar una ficha exige avisar manualmente a comercial, calidad, web y distribuidores.
• No existe un responsable claro para cada familia de datos.
• La empresa puede mostrar un documento, pero le cuesta reconstruir por qué era válido en una fecha concreta.

Una señal aislada no obliga a iniciar un proyecto. Varias señales repetidas indican que el coste no está solo en las horas: también está en las esperas, la falta de trazabilidad y la dependencia de memoria individual. El primer paso útil es observar una muestra real de trabajo, no diseñar desde una reunión idealizada.

Un modelo práctico para pasar del desorden a un sistema vivo

Definir el alcance real

Identifica familias afectadas, rol de la empresa y calendario sectorial. No todas las pymes ni todos los productos entran a la vez.

Crear un diccionario de producto

Acordar identificadores, variantes, unidades, atributos, documentos, vigencias y propietarios evita integrar ambigüedades.

Separar dato, documento y evidencia

Una característica comercial no se gobierna igual que un certificado o una declaración de conformidad.

Diseñar estados y validaciones

Borrador, pendiente, validado, publicado y retirado convierten archivos sueltos en un proceso controlable.

Preparar una salida interoperable

El registro contempla interfaz y API. Conviene conservar los datos en formatos recuperables y no depender de una única pantalla.

Este modelo no termina con la entrega. Los datos cambian, los proveedores actualizan funciones, aparecen excepciones y las personas aprenden a usar el sistema de otra manera. Por eso conviene asignar mantenimiento, revisar métricas y conservar una lista priorizada de mejoras. Un sistema vivo no es un proyecto sin fin; es un activo con responsable, criterio de cambio y ritmo asumible.

Qué conviene evitar en el primer proyecto

No conviene digitalizar de golpe todo el catálogo histórico ni contratar una plataforma antes de conocer los actos delegados aplicables. Tampoco es sensato presentar el DPP como un proyecto exclusivo de IT: calidad, compras, operaciones y producto deciden qué significa cada dato. Un piloto útil puede limitarse a una familia con variantes, dos proveedores y documentos reales. Si esa muestra no puede mantenerse durante tres meses sin tareas heroicas, ampliar el alcance solo ampliará el desorden.

También conviene acordar desde el inicio cómo se recuperan datos, configuraciones y documentación si cambia el proveedor. Esta salida ordenada no expresa desconfianza: protege la continuidad. La empresa debería saber qué posee, qué licencia, qué depende de terceros y cuánto trabajo exigiría volver a operar tras una incidencia o una transición.

Cómo plantear un MVP que enseñe algo

Un MVP útil contiene un recorrido completo, usuarios reales y un criterio de éxito. Puede cubrir una sede, una familia de producto, un tipo de solicitud o un grupo pequeño de clientes. Debe incluir el alta, las validaciones, la excepción y el cierre; si solo enseña la pantalla feliz, no prueba la operación. Durante unas semanas conviene medir qué pasos se omiten, qué campos generan dudas y dónde aparece trabajo paralelo.

Al terminar el piloto, la decisión no siempre es ampliar. Puede ser simplificar, integrar de otra forma o detener el desarrollo. Esa posibilidad filtra inversiones débiles y evita defender una solución solo porque ya se ha gastado tiempo en ella. La tecnología debe ganarse su sitio demostrando que reduce una fricción importante sin crear otra mayor.

Métricas que ayudan a dirigir, no solo a informar

• porcentaje de referencias con datos mínimos completos
• tiempo para publicar una modificación validada
• documentos caducados o sin propietario
• consultas internas sobre información ya disponible
• porcentaje de datos exportables sin tratamiento manual

Aplicación en 90 días

Durante las dos primeras semanas conviene observar casos reales y dibujar el recorrido actual con quienes lo ejecutan. El mapa debe incluir entradas, decisiones, esperas, excepciones, datos y evidencias. En las semanas siguientes se puede acordar un modelo mínimo, limpiar una muestra y configurar o construir el piloto. La última parte del periodo sirve para operar con usuarios reales, revisar incidencias y decidir qué queda fuera de la siguiente fase.

La dirección debería recibir tres conclusiones, no una demostración: qué fricción se ha reducido, qué dependencia nueva introduce la solución y qué inversión exige mantenerla durante doce meses. También necesita conocer los supuestos que todavía no se han probado. Esta conversación evita que una prueba técnica se confunda con un sistema listo para producción.

El responsable del proceso y el tecnológico deben compartir el gobierno. El primero decide reglas y prioridades; el segundo protege arquitectura, datos, accesos y continuidad. Cuando todo recae en uno de los dos, el proyecto suele quedar cojo: técnicamente correcto pero ajeno al trabajo, o muy adaptado al presente pero difícil de mantener.

Las métricas deben conducir a una acción. Si un indicador empeora, alguien necesita saber qué revisar: dato, regla, capacidad, proveedor o formación. Un panel sin responsables añade otra pantalla. Es preferible una revisión breve con pocas alertas fiables y decisiones registradas.

Cuándo no desarrollar software a medida

Si el catálogo es pequeño, estable y una herramienta existente resuelve identificadores, documentos y exportación, desarrollar software propio puede ser innecesario. La medida tiene sentido cuando hay reglas, integraciones, variantes o recorridos que el SaaS no cubre sin duplicar trabajo.

La decisión madura compara coste total, dependencia, capacidad de mantenimiento y velocidad de aprendizaje. A veces la mejor arquitectura es una herramienta estándar bien implantada. Otras veces es un backoffice pequeño que conecta sistemas existentes. El desarrollo es una consecuencia del diagnóstico, no el argumento comercial de partida.

La pregunta de dirección

Antes de pedir una propuesta, merece la pena formular una pregunta incómoda: si mañana falta la persona que hoy mantiene unido este proceso, ¿podemos seguir trabajando y explicar qué ha ocurrido? Si la respuesta es incierta, hay una necesidad de orden incluso aunque la solución final no sea una app.

En ReÁnima ayudamos a pymes a diagnosticar procesos, elegir una arquitectura proporcionada y mantener sistemas digitales que evolucionan con la operación. La conversación inicial puede centrarse en un recorrido concreto y en la decisión que hoy resulta difícil, sin asumir de antemano que haya que desarrollar.