Antes de rehacer todo de cero entender el funcionamiento del negocio

Resumen del caso

D. es una empresa aragonesa de cumplimiento normativo, con casi veinte años de historia, cerca de mil clientes y una herramienta propia desarrollada durante dieciséis años.

La dirección creía que la solución era tecnológica, ya fuera con IA, integraciones o empezando de cero; Marenza analizó cómo funcionaba realmente la empresa, recomendó conservar la herramienta y definió requerimientos concretos para mejorarla.

01

Qué necesitaba resolver la empresa

D. nació ofreciendo protección de datos a pequeñas empresas y fue ampliando su cartera: compliance penal, planes de igualdad, protocolos de acoso, servicios de DPO y una rama legal. Trabaja con suscripción anual que incluye documentación, mantenimiento normativo y atención personalizada, y muchos clientes llevan más de diez años. Su rasgo distintivo es una herramienta propia que gestiona clientes, genera documentación legal personalizada, envía comunicaciones y ofrece a cada cliente un área privada.

El negocio funcionaba, pero algo no escalaba. Las tareas circulaban en audios de mensajería, los presupuestos enviados quedaban sin seguimiento, la documentación no siempre llegaba a tiempo y el responsable técnico dedicaba casi todo su tiempo a mantener la herramienta, en lugar de a los servicios de ciberseguridad donde más valor aporta. La dirección quería crecer con un equipo comercial, y hacerlo sobre esa base habría amplificado los problemas.

La hipótesis inicial era tecnológica: agentes de IA, automatizaciones avanzadas, integración con plataformas externas o empezar de cero con una empresa especializada. La dirección mantuvo conversaciones en paralelo con varias empresas de IA, una consultora comercial y una plataforma legal de gestión documental, sin saber con cuál avanzar.

02

Entender cómo trabaja realmente la empresa

El proyecto empezó con una pregunta previa a cualquier herramienta: ¿cómo trabaja hoy D.? Se recorrió la herramienta existente y los flujos reales de trabajo.

Apareció una tecnología propia más sólida de lo que la propia empresa percibía, junto a una ausencia total de procesos documentados: sin estados ni responsables visibles en las tareas, sin seguimiento de presupuestos y con toda la lógica de la aplicación en la cabeza de una sola persona. Eso impedía que alguien más pudiera mantenerla, mejorarla o incorporarse a trabajar con ella.

03

Qué se decidió

No empezar de cero

Una de las decisiones más importantes fue conservar la herramienta propia. Acumulaba dieciséis años de lógica de negocio, todas las plantillas documentales, un área de cliente adaptada a la operativa y el histórico completo. Sustituirla suponía un coste enorme y el riesgo de perder funcionalidad que ningún sistema estándar ofrecería para un negocio tan específico.

En su lugar se propuso un enfoque en tres fases:

Documentar el ciclo completo de cada servicio

Se mapeó con el responsable técnico y la responsable de operativa el recorrido de cada servicio, desde que entra un cliente potencial hasta que se envía el primer documento, se firma, se factura y se mantiene en el tiempo. Para cada producto se anotaron los pasos, los documentos generados, quién hace qué y qué es automático o manual.

El ejercicio parece burocrático, pero resultó lo más valioso del proyecto: ahora el equipo tenía por escrito cómo funciona su propio negocio.

Probar antes de integrar: un tablero Kanban

Para resolver las tareas perdidas en mensajes de voz se propuso un tablero Kanban provisional. No buscaba ser la solución definitiva, sino un banco de pruebas: el equipo aprende a gestionar tareas de forma visible, descubre qué estados necesita y, cuando lo tiene claro, el desarrollador puede replicarlo dentro de la propia herramienta.

04

Resultados