Por Thomas Cohen, fundador de Maestro
Renovar un software de gestión: prepara los datos y el cambio
¿Cuándo conviene rehacer una aplicación de gestión? Qué significa, qué señales comprobar y cómo elegir entre reparar, comprar o reconstruir sin perder los datos.
Rehacer una aplicación de gestión significa sustituir o reconstruir todo o parte de un sistema de trabajo, conservando los datos y las reglas que necesita la actividad. No consiste solo en cambiar sus pantallas. En nuestro ejemplo, dos compañeros copian cada viernes los pedidos del programa antiguo en una hoja de cálculo para organizar las instalaciones. La nueva herramienta debe eliminar esa tarea, pero también conservar los anticipos, respetar los descuentos y mantener las citas ya prometidas.
Esta guía sigue a un taller ficticio que vende e instala muebles a medida. Nadia organiza las instalaciones, Karim dirige el taller y Lucie controla los pagos. Sus nombres, expedientes e importes son inventados para explicar el método. Puedes adaptar su recorrido a un despacho, una asociación o una pequeña empresa, sustituyendo los ejemplos por tus propias situaciones.
1. ¿Cuándo conviene rehacer una aplicación de gestión?
Plantea una renovación cuando unas limitaciones comprobadas impidan un trabajo esencial y ni una reparación ni un producto existente resuelvan adecuadamente la necesidad. La antigüedad del programa, unas pantallas anticuadas o las ganas de usar IA no bastan para decidir. Lo importante es conservar las reglas del negocio, trasladar los datos sin perder su significado y seguir trabajando durante el cambio. En nuestro taller ficticio, la planificación del viernes revela un problema; todavía no demuestra que haya que reconstruirlo todo.
Durante varias jornadas representativas, anota cada bloqueo: la tarea, la persona afectada, la solución provisional y sus consecuencias. «Programa lento» se convierte en «Nadia espera a que se abra el expediente antes de confirmar una fecha al cliente». Añade lo que funciona bien. Debes proteger esas ventajas, aunque parezcan normales.
- Una exportación ha dejado de funcionar: reproduce el fallo en una copia y pide un presupuesto de reparación antes de plantear una renovación.
- Falta una función: prueba un producto existente con el mismo caso y compara sus límites, su coste y las opciones para recuperar los datos.
- Una regla esencial del negocio sigue siendo imposible: aísla ese proceso y valora reconstruir solo esa parte.
- Ya nadie sabe mantener el programa: encarga una revisión de los accesos, las copias de seguridad y las dependencias antes de elegir entre una recuperación técnica y una sustitución.
Para cada opción, anota el problema observado, la prueba, el coste por confirmar y la persona que da su aprobación. Karim necesita mover una instalación por el retraso de un proveedor: prueba el mismo caso con una reparación, un producto existente y un primer proceso reconstruido. Si se elige reconstruir, escribe qué limitación concreta lo justifica y qué seguirá en el programa antiguo. Esa decisión será el punto de partida del documento de requisitos.
2. Reúne lo que la empresa ya sabe
Empieza la revisión con las personas que usan la herramienta, no solo con quien la compró. Pide a Nadia que te muestre su última mañana complicada, a Lucie una factura corregida y a Karim un pedido poco habitual. Observa el recorrido completo, incluidas las llamadas, los papeles y los archivos que rodean al programa.
Reúne los accesos disponibles, los contratos, una exportación de prueba, los modelos de documentos y los datos de contacto de quien mantiene la aplicación. Comprueba qué tienes realmente: un instalador, el código fuente, una copia de seguridad y un archivo de datos sirven para cosas distintas. Una persona competente debe confirmar qué permite restaurar y ejecutar la aplicación.
Crea una carpeta de referencia fechada, con una copia protegida de los elementos necesarios. Para las conversaciones y las pruebas, utiliza ejemplos ficticios o preparados para no exponer a personas siempre que sea posible. Una captura sin el nombre puede seguir mostrando una dirección o una nota confidencial.
- Herramienta externa (ejemplo ficticio): el programa contable al que se importan las facturas del taller.
- Intercambio: un archivo de facturas y abonos, con sus referencias, fechas e importes, exportado desde el programa de gestión e importado después al programa contable.
- Frecuencia o desencadenante: al final de cada mes, después de que Lucie valide el archivo.
- Responsable: Lucie prepara la exportación; el contable confirma el formato requerido y comprueba la importación.
- Resultado esperado de la prueba: importar tres facturas y un abono ficticios en un entorno de prueba, encontrar las cuatro referencias con los mismos importes y comprobar que una segunda importación del mismo archivo no crea duplicados.
- Anota también las incógnitas. «No sabemos dónde se guardan los archivos adjuntos» es una pregunta que hay que resolver. Ocultarla detrás de una maqueta convincente solo convierte una incertidumbre visible en una sorpresa desagradable más adelante.
3. Recupera las reglas ocultas y las excepciones
Las pantallas cuentan solo una parte del trabajo. En el taller, un pedido naranja significa que el proveedor no ha confirmado la entrega. Ese significado no está escrito en ninguna parte. Recrearlo como un simple color haría perder la decisión asociada: Nadia debe llamar antes de fijar la instalación.
Para cada regla, anota la situación inicial, la acción permitida y el resultado esperado. Por ejemplo: «Si la entrega no está confirmada, Nadia puede proponer una fecha provisional; la herramienta debe distinguirla de una cita confirmada». Añade el nombre de quien decide cuando haya dudas.
Casos que conviene pedir que te expliquen
- Un pedido cancelado después de pagar un anticipo.
- Dos clientes con el mismo nombre y direcciones diferentes.
- Una instalación aplazada cuando el cliente ya ha recibido un mensaje.
- Un descuento solicitado por alguien que no puede autorizarlo.
- Un archivo adjunto desaparecido o un expediente incompleto entregado por un antiguo compañero.
Estos ejemplos forman tu cuaderno de comprobaciones. Conserva la respuesta validada y el motivo de la decisión, no solo una captura. Una IA puede proponer una interpretación de los archivos accesibles; los usuarios deben confirmar que describe su trabajo. La guía de requisitos sin lenguaje técnico ayuda a reunir estas decisiones en un documento legible.
4. Elige una primera parte que puedas comprobar
El taller empieza con una planificación de solo lectura alimentada con una copia de los pedidos. Todavía no modifica la facturación ni los mensajes enviados a los clientes. Este alcance permite comprobar las fechas y los expedientes con Nadia antes de autorizar una acción que comprometa a la empresa.
Describe el resultado observable: Nadia encuentra las instalaciones de una semana, abre el pedido correcto y distingue las fechas provisionales. Especifica también lo que queda fuera: cobros, pedidos a proveedores y envío automático de mensajes. Estas exclusiones evitan que la primera prueba se convierta discretamente en una sustitución completa.
Prepara un pequeño conjunto de expedientes representativos: un caso habitual, un aplazamiento, una cancelación y un dato que falta. Haz construir ese recorrido y pruébalo personalmente. Una pantalla llena de datos plausibles no demuestra que se hayan trasladado los pedidos correctos.
5. Prepara el traslado de datos, campo por campo
Una migración empieza con una correspondencia clara entre la herramienta antigua y la nueva. Para cada dato, anota su ubicación de origen, su destino y la transformación prevista. El número de pedido debe seguir siendo una referencia estable, aunque el nuevo programa asigne sus propios identificadores.
En nuestro ejemplo, la columna «Fecha montaje» se convierte en «Fecha de instalación». Una celda vacía significa «fecha pendiente», nunca «hoy». El importe «1 200,50» debe conservar su significado numérico. El código del cliente debe seguir vinculado a la persona correcta, aunque dos clientes se apelliden Martin.
Prepara el tratamiento de duplicados y expedientes rechazados. No dejes que una importación ignore silenciosamente las filas problemáticas. Lucie debe disponer de una lista de pedidos no trasladados, con un motivo comprensible y la persona encargada de decidir. Algunas correcciones podrán hacerse sobre una copia; el original se conserva.
Los archivos adjuntos y los historiales necesitan su propia comprobación. Encontrar el nombre de un PDF no significa que se pueda acceder a su contenido. Elige un pedido, abre el documento, verifica el cliente y localiza el anticipo y el cambio de fecha asociados. Compara también las cantidades de expedientes y los totales pertinentes.
Utiliza la ficha gratuita para preparar una importación de Excel para documentar las correspondencias, aunque los datos procedan de otro programa. La guía de migración de datos detalla la limpieza y las pruebas. Pide a la persona responsable de tus datos que valide el traslado antes de sustituir la base utilizada a diario.
6. Define quién puede ver y modificar cada cosa
Trasladar todas las cuentas con todos los permisos sería fácil de pedir y difícil de justificar. Nadia necesita organizar las instalaciones; eso no le da automáticamente acceso a la información reservada a Lucie. Escribe los permisos por acción: consultar, crear, modificar, eliminar, exportar y administrar.
Prueba con cuentas de ensayo distintas y operativas. Ocultar un botón no basta: pide que se compruebe que la acción sigue denegada al intentar acceder al expediente de otra forma. Revisa también exportaciones, archivos adjuntos y enlaces compartidos. La misma restricción debe acompañar a la información en esos recorridos.
Antes de entregar archivos a un asistente de IA, confirma qué se puede transmitir, a qué proveedor y en qué condiciones. Tener el proyecto guardado en un Mac no significa que los intercambios con el asistente permanezcan en ese Mac. Para las obligaciones propias de tus datos y tu profesión, pide que una persona competente valide las decisiones.
7. Organiza una prueba parecida al trabajo real
Una vez validada la consulta, el taller prueba los cambios de fecha con expedientes de ensayo. Prepara una sesión con los futuros usuarios. Dales una tarea y un resultado que alcanzar sin mostrarles cada clic. Nadia debe encontrar el pedido de un cliente que llama, mover una instalación ficticia y explicar qué ha cambiado. Observa dónde duda y qué información busca fuera de la herramienta.
Para cada prueba, conserva el expediente utilizado, el resultado esperado, el observado y el nombre de quien comprueba. «Funciona» no permite repetir una verificación después de corregir algo. «El pedido A-104 aparece el martes con una fecha provisional» ofrece una comparación precisa.
Clasifica los comentarios según sus consecuencias. Una información financiera incorrecta bloquea el cambio. Un texto ambiguo debe corregirse si provoca una mala decisión. Una preferencia estética puede esperar si no dificulta el trabajo. Esta conversación corresponde a los usuarios y al responsable del proyecto, no al agente que ha creado la pantalla.
Repite las pruebas afectadas después de cada corrección y, después, un recorrido completo. Corregir el cambio de fecha de una instalación puede afectar a un total o a una exportación. Pide al proveedor o a quien mantiene el código que añada las comprobaciones técnicas adecuadas; tu prueba del trabajo real las complementa.
8. Mantén ambos programas sin crear dos versiones de la realidad
Durante la primera prueba del taller, el programa antiguo sigue siendo la referencia para los pedidos. La nueva planificación consulta una copia fechada. Todo el equipo sabe dónde introducir los cambios y cuándo se preparó esa copia. Esta organización sencilla evita confundir una vista de prueba con la planificación oficial.
Sustituir progresivamente algunas funciones puede reducir el alcance de un cambio. Microsoft describe este enfoque en su documentación sobre sustitución gradual de sistemas, incluidas las limitaciones de coexistencia. Hay que comprobar si encaja con tu programa; no se aplica automáticamente.
Cuando la nueva herramienta empiece a recibir datos, escribe qué sistema es la referencia para cada información. Si Nadia cambia una fecha en el nuevo programa, ¿cómo la recibe Lucie? Cualquier sincronización necesaria debe construirse, comprobarse y mantenerse. Pedir al equipo que copie cambios indefinidamente oculta su coste sin resolver el riesgo de diferencias.
Fija una duración y una condición de finalización para esta transición. Cada día de prueba, una persona compara los cambios esperados con los recibidos. Mientras haya una diferencia sin explicar, no elimines la vía que permite retomar el trabajo.
9. Prevé la autorización, la interrupción y la vuelta atrás
El cambio debe depender de criterios escritos. Decide quién puede autorizarlo, quién puede detenerlo y cómo informar al equipo. Reserva un momento compatible con tu actividad y con la disponibilidad de alguien capaz de intervenir. Cambiar un viernes por la noche no es prudente si nadie puede ayudar al día siguiente.
- Los expedientes y documentos necesarios se han recuperado y comprobado.
- Los importes y las reglas críticas producen los resultados esperados.
- Se han verificado los accesos con cuentas diferentes.
- Los usuarios saben dónde trabajar y a quién comunicar un problema.
- Se ha ensayado la vuelta atrás, incluida la recuperación de los datos nuevos.
En nuestro ensayo ficticio, el pedido A-109 se crea después del traslado inicial. La vuelta al programa antiguo debe recuperarlo con sus archivos adjuntos y su anticipo, sin generar un duplicado. Conserva un registro de los identificadores y las acciones realizadas. La misma cuestión se plantea para un pedido modificado o cancelado durante la prueba.
La autoridad francesa de protección de datos, la CNIL, recomienda probar la restauración de las copias de seguridad. Abre de verdad los expedientes restaurados durante el ensayo. Si los datos nuevos no pueden recuperarse correctamente, la vuelta atrás no está lista: corrige el proceso antes del cambio.
10. Presupuesta los resultados entregables y el tiempo del equipo
Pide un presupuesto dividido en revisión inicial, primer recorrido, traslado de datos, comprobaciones, puesta en marcha y mantenimiento. Asocia el precio de cada etapa con un resultado que puedas examinar. Un pago ligado a «desarrollo terminado» sigue siendo ambiguo si nadie ha definido qué incluye.
Este cálculo es puramente ficticio y no representa un precio de mercado, con importes supuestos sin impuestos: 700 € para la revisión inicial, 1 800 € para la primera planificación, 900 € para preparar y ensayar la importación y 600 € para acompañar la puesta en marcha. Son 4 000 € de servicios, a los que se añaden el tiempo interno y los gastos recurrentes realmente previstos.
En esta simulación, el taller también reserva 1 000 € para las incógnitas autorizadas durante el trabajo. Esa reserva no se convierte en una cantidad que deba gastarse automáticamente. Si los archivos adjuntos requieren un tratamiento adicional, pide una explicación, un precio y una decisión antes de continuar.
Cuenta las horas de Nadia y Lucie dedicadas a entrevistas, pruebas y formación. Añade los costes del programa antiguo durante la transición, los servicios del nuevo, la IA y las posibles copias de seguridad. La guía del presupuesto de una aplicación ayuda a separar estas partidas y comparar propuestas con el mismo alcance.
11. Prepara la entrega y el mantenimiento
Antes de cerrar el proyecto, pide que una persona que no haya asistido a todas las conversaciones se haga cargo de la documentación. ¿Puede encontrar la última versión, ejecutar la aplicación, restaurar los datos y entender las decisiones importantes? Cualquier respuesta que dependa únicamente de la memoria del constructor debe quedar escrita.
Conserva los contactos de los responsables, las instrucciones de funcionamiento, los accesos en un lugar adecuado, las dependencias utilizadas y las condiciones de mantenimiento. Precisa quién corrige una avería, quién sigue las actualizaciones y quién autoriza una mejora. Tener los archivos no organiza estas responsabilidades por ti.
Decide también qué ocurrirá con el programa antiguo: consulta temporal, archivo y retirada cuando se cumplan las condiciones acordadas. Los plazos de conservación deben fijarse según tus obligaciones, no inventarlos un agente. Antes de eliminar nada, comprueba que las personas autorizadas puedan seguir accediendo a los datos y justificantes necesarios.
12. Utiliza Maestro con un documento de partida claro
Maestro puede ayudar a organizar la descripción de la necesidad, los documentos y la construcción por etapas. Las decisiones del negocio y la verificación del cambio siguen siendo responsabilidad tuya, junto con las personas competentes en datos y aspectos técnicos. Expón las incógnitas: el equipo de IA no puede adivinar una regla guardada únicamente en la cabeza de un compañero.
Empieza con la plantilla gratuita de requisitos. Escribe el problema actual, las reglas que hay que conservar, el primer recorrido y los nombres de quienes validarán el resultado. Añade ejemplos preparados para la prueba y una lista de preguntas abiertas. Este documento seguirá siendo útil elijas la herramienta que elijas.
Para descubrir el producto, consulta el recorrido de Maestro para proyectos existentes. A 23 de septiembre de 2026, la beta por invitación está disponible en Mac; la aplicación es gratuita durante la beta y el uso de IA lo factura por separado el proveedor elegido. No necesitas esperar a la invitación para preparar tu documentación.
La siguiente decisión del taller es concreta: comprobar que una planificación de consulta encuentra los pedidos y las fechas correctos. Si la prueba falla, Nadia sabe qué debe corregirse. Si funciona, el equipo tiene una base para autorizar la siguiente etapa, con sus comprobaciones y su presupuesto.