En esta nota (9 secciones)
Casi ninguna empresa arranca con un sistema. Arranca con una planilla, y la planilla funciona. Ese es el punto que se suele pasar por alto en esta discusión: Excel no es un error que haya que corregir, es una herramienta que resolvió el problema durante años y por eso sigue ahí.
El problema aparece después, y no aparece de golpe. Aparece como una acumulación de fricciones que cada una por separado no justifica nada.
Las señales que sí importan
Hay una diferencia entre "la planilla es incómoda" y "la planilla ya no da". Estas son las señales del segundo grupo.
Alguien dedica horas a consolidar. Si una persona pasa la mañana del lunes juntando la planilla de ventas, la de stock y la del banco para armar un número, eso no es administración: es un sistema hecho a mano. El costo ya lo estás pagando, sólo que en sueldo en vez de en software.
Hay más de una versión de la verdad. `stock_final_v3_OK.xlsx`, la copia que tiene el vendedor en su notebook, la que está en el drive compartido. Cuando dos personas contestan distinto a la misma pregunta, el dato dejó de ser confiable, y un dato no confiable no se usa para decidir.
El proceso depende de que alguien se acuerde. Avisar al depósito, mandar el remito, cargar el pago. Nada de eso está escrito en ningún lado: está en la cabeza de una persona. Ese es el riesgo más caro y el más invisible, porque no se nota hasta que esa persona se toma vacaciones.
No podés dar acceso sin dar todo. Querés que un vendedor vea sus clientes pero no la lista de costos. En una planilla eso no existe: o tiene el archivo o no lo tiene.
El error de tipeo llega al cliente. Una celda mal copiada que termina en una factura, un remito con la cantidad equivocada. En una planilla no hay nada que valide nada.
Ninguna de estas señales sola justifica un desarrollo. Tres o más juntas, sí: cada una está costando plata todos los meses y ninguna se va a arreglar sola.
Las señales que NO justifican el salto
Vale la pena decir esto también, porque hay razones que suenan bien y no alcanzan.
- "Queda poco profesional." Si el cliente nunca ve la planilla, esto no es un motivo. Es estética interna.
- "Todo el mundo tiene un sistema." El sistema de otro está resolviendo el problema de otro.
- "Nos lo recomendó el contador." Puede tener razón, pero preguntá para qué. Si es sólo para la carga contable, quizás lo que necesitás es una integración, no un sistema.
- "Es lento." Antes de desarrollar, fijate si el problema es la planilla o el proceso. Un proceso malo digitalizado sigue siendo un proceso malo, sólo que ahora cuesta USD 12.000.
Ese último punto es el más importante de todos. Un sistema no ordena una operación desordenada. La congela. Si hoy nadie sabe cuál es el circuito de aprobación de un descuento, el software no lo va a inventar: te va a obligar a definirlo, y esa definición es trabajo tuyo, no del proveedor.
Qué se gana y qué se pierde
Se gana lo obvio: un solo dato, permisos por rol, validaciones que evitan el error de carga, historial de quién hizo qué, y la posibilidad de que dos personas trabajen al mismo tiempo sin pisarse.
Se pierde algo que casi nadie menciona en la reunión de venta: flexibilidad inmediata. En Excel, cuando necesitás una columna nueva, la agregás vos en treinta segundos. En un sistema, esa columna es un pedido, una estimación y un deploy.
Ese cambio es real y conviene entenderlo antes de firmar. La planilla es infinitamente maleable y por eso es un desastre a escala. El sistema es rígido y por eso es confiable. Estás cambiando una cosa por la otra a propósito.
La consecuencia práctica: dejá afuera del sistema lo que todavía está cambiando. Un análisis exploratorio, un cálculo que cambia cada trimestre, un tablero que estás probando. Eso sigue en la planilla, y está bien que siga.
Los tres caminos, sin romanticismo
Ordenar la planilla
Suena a no hacer nada, pero es la respuesta correcta más seguido de lo que parece. Una planilla en Google Sheets, con validación de datos, permisos por hoja, y un par de automatizaciones, resuelve buena parte de los casos de una empresa chica.
Cuándo alcanza: menos de cinco personas cargando datos, un solo proceso principal, sin necesidad de dar acceso afuera.
Costo: horas propias.
Techo: bajo, y se choca rápido cuando entra una segunda persona a cargar en simultáneo.
Un producto enlatado
Un ERP o un sistema de rubro que ya existe. Lo instalás, lo configurás, empezás el mes que viene.
Cuándo alcanza: tu operación se parece a la de todos los demás en tu rubro. Facturás, controlás stock, seguís cuentas corrientes, y nada de eso tiene una vuelta rara.
Costo: suscripción mensual por usuario, más implementación.
Techo: la personalización. Todo lo que el producto no contempla, o lo hacés por afuera o cambiás tu proceso.
Desarrollo a medida
Cuándo corresponde: cuando lo que te diferencia está justamente en el proceso que ningún enlatado contempla. Una lógica de precios propia, un circuito de aprobación particular, una integración con un cliente grande que te la exige de una forma específica.
Costo: entre USD 3.000 y 8.000 para algo acotado, USD 8.000 y 25.000 para un sistema de gestión completo de pyme.
Techo: alto, pero tenés que mantenerlo vos.
La pregunta que ordena la decisión no es cuál es mejor. Es: ¿lo que hacés distinto está en el proceso, o sólo en cómo lo hacés? Si tu diferencial es la atención, la marca o el precio, y el proceso administrativo es estándar, andá a un enlatado. Si tu diferencial vive dentro del proceso, el enlatado te lo va a aplanar.
Cómo hacer el salto sin frenar la operación
El error más común no es elegir mal la herramienta. Es intentar migrar todo de una.
Empezá por un proceso, no por la empresa. Elegí el que más duele —el que consume las horas del lunes— y hacé sólo ese. Un sistema que resuelve bien una cosa se usa. Uno que resuelve mal seis, no.
Convivan un tiempo. Durante uno o dos meses el sistema y la planilla van a correr en paralelo. Es trabajo doble y es incómodo, y es la única forma de descubrir los casos que nadie contó sin arriesgar la operación.
La migración de datos es un proyecto aparte. Los datos históricos de una planilla están sucios: nombres escritos de tres formas, fechas como texto, filas duplicadas. Limpiar eso lleva tiempo y no es opcional, porque un sistema nuevo con datos malos nace desconfiado.
Una decisión que conviene tomar temprano: cuánta historia migrás. Casi siempre alcanza con los saldos actuales y el último año. Traer ocho años de movimientos multiplica el costo de la migración y casi nadie los consulta después.
Definí el circuito antes de que lo defina el software. Sentate con quien hace el trabajo y escribí los pasos, incluidas las excepciones. Esa hora de conversación vale más para el resultado que cualquier decisión técnica que venga después.
En resumen
La planilla no se cambia porque esté mal. Se cambia cuando el costo de sostenerla —horas de consolidación, errores que llegan al cliente, decisiones tomadas sobre datos que nadie garantiza— supera al costo de reemplazarla.
Si ese costo todavía no lo podés estimar en horas y en plata, es probable que sea temprano. Y si lo podés estimar y te da alto, ya sabés qué sigue.