Cuándo es el momento de dejar las hojas de cálculo, cómo calcular el presupuesto, cómo diseñar el modelo de datos y cómo migrar sin parar la empresa durante un mes. Una guía completa de todo el proceso, desde la primera idea hasta el primer mes de funcionamiento.
La mayoría de las empresas no empiezan a buscar un sistema propio porque quieran un software nuevo. Empiezan porque algo se ha perdido dos veces, alguien se ha olvidado de facturar, o nadie sabe responder cuánto se ha ganado en un encargo.
Esta guía recorre todo el proceso, desde esa primera insatisfacción hasta el primer mes de funcionamiento real. Cada capítulo resume lo esencial y enlaza con un artículo detallado si quiere profundizar en el tema.
1. Cómo saber que ha llegado el momento
Hay cuatro señales bastante fiables. Con dos de ellas basta:
La hoja de cálculo tiene más de un editor. En el momento en que dos personas escriben en el mismo archivo, empieza el problema de saber cuál es la versión vigente. Eso no se resuelve con disciplina.
Los datos existen en varios sitios y no cuadran. El cliente está en el CRM, su encargo en el gestor de proyectos, las horas en una hoja de cálculo, la factura en la contabilidad. Cualquier pregunta que cruce la frontera entre ellos tarda medio día en responderse.
Algo se ha quedado en el aire. Una factura olvidada, un plazo incumplido, una promesa a un cliente que no se cumplió. Una vez es casualidad; la segunda es un fallo del sistema.
Si una persona se fuera, la empresa perdería la visión de conjunto. Cuando el proceso vive en la cabeza de alguien y no en un sistema, es un riesgo que crece con el tamaño de la empresa.
En detalle: Cuándo una hoja de Excel deja de bastar y Cuánto le cuestan a una empresa las herramientas dispersas.
2. Por qué en realidad tiene tres sistemas
Casi nadie elige de verdad un stack fragmentado. Se va acumulando: el CRM llegó con el segundo comercial, el gestor de proyectos con la primera realización grande, la hoja de cálculo para el dinero porque ninguno de los dos sabía calcular el margen.
Cada uno de esos pasos fue correcto en su momento. El problema es la suma - y sobre todo el trabajo que surge en las fronteras entre ellos. Volver a escribir, buscar información, cuadrar cuentas cada mes. Nada de eso aparece en ninguna factura.
Nadie lo eligió. Se fue acumulando.
Cada herramienta resolvió un problema y creó una frontera. El trabajo que surge en esas fronteras no se ve en ningún sitio.
En detalle: CRM, ERP, gestor de proyectos: por qué acabó con tres sistemas que no se hablan.
3. Cuatro caminos y su coste real
Una vez tomada la decisión, llega la pregunta de cuánto cuesta. Hay cuatro caminos:
| Camino | Coste inicial | Quién hace los cambios | Riesgo principal |
|---|---|---|---|
| Software estándar | Bajo | Nadie (no es posible) | El proceso se dobla a la herramienta |
| Desarrollo a medida | Muy alto | El proveedor | Dependencia del proveedor |
| Freelance + IA | Medio | Una sola persona | Dependencia de esa persona |
| Plataforma no-code | Muy bajo | Cualquiera del equipo | Dependencia de la plataforma |
Lo importante no es fijarse en la primera factura, sino en el total a tres años. El precio inicial es el que le dicen; los años dos y tres son los que deciden.
En el presupuesto también entran partidas que nunca aparecen en la oferta: la puesta en marcha y la formación, los cambios (no como un «por si acaso», sino como una certeza), el mantenimiento, y el riesgo de que se vaya la persona que conoce el sistema.
En detalle: Cuánto cuesta una aplicación a medida en 2026.
4. Diseñar el modelo de datos: la única parte que no se puede hacer con prisas
Aquí se decide si el sistema seguirá siendo útil dentro de dos años. No es trabajo técnico, es trabajo sobre su proceso.
Empiece por las entidades. Anote los sustantivos que usa en la empresa: cliente, encargo, presupuesto, factura, técnico, parte de trabajo, documento. Esas serán sus bases de datos.
Defina las relaciones. Un cliente tiene varios encargos. Un encargo tiene un presupuesto y varios partes de trabajo. Una factura pertenece a un encargo. Este paso es el que más malentendidos del equipo saca a la luz - a menudo resulta que dos personas entendían dos cosas distintas por «encargo».
Deje el modelo más pequeño de lo que le gustaría. El error clásico es diseñar quince bases de datos de antemano. Empiece con tres que cubran el flujo principal y añada según lo que se demuestre necesario.
Póngalo a prueba con una pregunta. Un buen modelo se reconoce porque el equipo puede dar con él el siguiente paso - emitir una factura, enviar un acta, calcular un margen. No porque tenga todas las columnas.
En detalle: Un modelo de datos que crece con el equipo.
5. Quién ve qué
Los permisos a menudo se dejan para más adelante, y es un error - tienen que cumplirse en cada vista, cada exportación y cada correo que envíe el sistema.
Basta con responder de antemano a tres preguntas:
- ¿Quién debe ver los campos sensibles (precios, márgenes, datos personales)?
- ¿Quién solo debe leer y quién también editar?
- ¿Qué, si acaso algo, debe ser visible fuera de la empresa?
Las respuestas se traducen en una estructura de roles que configura una vez y que se aplica en todas partes. Distinga entre dos cosas: ocultar una columna resuelve «qué ve dentro de un registro», restringir el acceso a la base de datos resuelve «a qué registros llega siquiera».
En detalle: Permisos de acceso y visibilidad de los datos.
6. La migración sin un gran salto al vacío
Nadie puede apagar tres sistemas de golpe un lunes. El procedimiento que funciona tiene tres fases:
Fase 1 - una sola frontera. Encuentre el punto que más duele (normalmente ventas ↔ realización, o realización ↔ dinero) y construya una base común solo para eso. Clientes y encargos en un mismo sitio.
Fase 2 - conectar lo que le corresponde. Partes de trabajo, documentos, comunicación. En esta fase la mayoría de las empresas descubre que ya no necesita la mitad de sus hojas de cálculo.
Fase 3 - apagar lo antiguo. No antes de unas semanas funcionando en paralelo. Marque primero la hoja de cálculo antigua como no editable, y solo después archívela.
Qué no trasladar: todo el historial. El último año suele bastar; el resto solo ensucia las vistas.
En detalle: Migrar desde Excel o Notion.
7. Las automatizaciones, al final
La tentación habitual es activar las automatizaciones desde el primer día. Es mejor esperar a que el sistema lleve unas semanas funcionando - solo entonces sabe qué pasos se repiten de verdad.
Las primeras automatizaciones que casi siempre merecen la pena:
- vigilar los encargos que están terminados y no tienen factura,
- un recordatorio del plazo unos días antes,
- un aviso por falta de parte de trabajo al final de la semana,
- crear un registro automáticamente a partir de una solicitud entrante.
En detalle: Automatización en Apexloop: guía completa para empezar y Automatización de procesos empresariales.
8. El primer mes de funcionamiento
Qué esperar de forma realista:
Semana 1. La gente se queja de que en Excel era más rápido. Es verdad - para una sola persona. Aguante.
Semanas 2-3. Aparecen las primeras peticiones de cambios. Es una buena señal, no una mala: significa que están usando el sistema. Haga los ajustes sobre la marcha y con rapidez.
Semana 4. Llega el primer momento en que alguien encuentra una respuesta que antes le habría costado media hora buscar. A partir de ahí suele cambiar la dinámica.
Qué medir: no la satisfacción, sino si al margen del sistema sigue apareciendo alguna hoja de cálculo. Si es así, algo le falta al sistema - y esa hoja de cálculo es la pista exacta de qué.
Preguntas frecuentes sobre la implantación de un sistema de empresa
¿Cuánto dura toda la migración?
La primera frontera suele resolverse en días, hasta dos semanas. La migración completa en una empresa de veinte personas suele llevar de uno a tres meses - no porque lo técnico tarde tanto, sino porque la gente se va adaptando poco a poco.
¿Quién debería encargarse de esto dentro de la empresa?
Una o dos personas como «administradores del espacio de trabajo», normalmente alguien de operaciones o administración que entienda el proceso. No necesariamente la persona más técnica, sino la que mejor sabe cómo funciona el trabajo en realidad.
¿Y si resulta que hemos diseñado mal el modelo?
Pasa casi siempre y no tiene nada de malo. En una plataforma no-code, los campos, los estados y las relaciones se cambian en pleno funcionamiento. En una aplicación desarrollada a medida, cambiar el modelo de datos es una tarea para un desarrollador - y precisamente por eso esta característica pesa más que cualquier función de una lista.
¿Tenemos que abandonar nuestro programa de contabilidad?
No. La contabilidad tiene sus propias obligaciones legales y normalmente se queda donde está. Unificar tiene sentido para los datos operativos: clientes, encargos, plazos, partes de trabajo, documentos.
¿Cómo convencemos a un equipo que no quiere cambiar nada?
Lo mejor es que lo primero que resuelva el nuevo sistema sea algo que les molesta de verdad. No los informes para el propietario, sino el fin de tener que buscar información o el fin de copiar datos a mano. El resto llega solo.