La planilla dejó de ser una herramienta cuando varias personas empezaron a editarla, copiarla y enviar versiones por correo. Desde ese punto, cómo reemplazar planillas operativas no consiste en pasar columnas a una pantalla más bonita. Consiste en definir qué dato manda, quién puede cambiarlo y qué ocurre después de cada cambio.
El problema suele aparecer tarde. Un pedido se marca como entregado en una pestaña, pero sigue pendiente en otra. Un encargado modifica una fórmula sin saber que alimenta un reporte. Alguien borra una fila y nadie puede reconstruir qué pasó. La operación sigue funcionando porque el equipo conoce los atajos, pero depende de memoria, mensajes y revisiones manuales.
Un sistema a medida no corrige ese problema por poner una base de datos detrás. Lo corrige cuando representa el proceso real, elimina duplicaciones y deja trazabilidad donde antes había interpretación.
Antes de reemplazar planillas operativas, mida el proceso
No conviene empezar por la interfaz. Una planilla normalmente mezcla tres cosas: datos permanentes, trabajo diario y reportes. Clientes, productos y proveedores son datos permanentes. Estados de pedidos, asignaciones y fechas comprometidas corresponden al trabajo diario. Los totales mensuales y las alertas son reportes.
Separarlos cambia la conversación. Si un dato se repite en cinco pestañas, no necesita cinco lugares de edición. Debe existir una fuente única. Si un total requiere copiar y pegar información cada viernes, el sistema debe calcularlo desde los registros operativos. Si una persona aprueba excepciones, esa aprobación debe quedar registrada con fecha y responsable.
En esta etapa conviene documentar un caso completo, desde que entra hasta que termina. Por ejemplo: llega una solicitud, alguien revisa antecedentes, se asigna a un responsable, se ejecuta una tarea, se registra una incidencia y se cierra. Anote qué datos entran, qué decisión toma cada persona y qué condición cambia el estado.
No hace falta dibujar un mapa complejo. Hace falta resolver ambigüedades. “Pendiente” puede significar que falta información, que nadie lo tomó o que está esperando aprobación. Esos estados no son equivalentes. Si el sistema los trata igual, seguirá ocultando trabajo detenido.
Detecte las reglas que viven en la cabeza del equipo
Las fórmulas son visibles. Las reglas informales no. Frases como “a ese cliente hay que avisarle antes”, “esto se cierra solo con respaldo” o “si pasa tal monto lo revisa administración” suelen sostener el proceso más que una celda de Excel.
Esas reglas deben convertirse en permisos, validaciones o pasos de aprobación. De lo contrario, el equipo tendrá un sistema nuevo y continuará usando WhatsApp para decidir lo importante. El resultado es doble registro y menos confianza en la información.
También hay que distinguir entre una excepción real y una falla de diseño. Si un caso ocurre una vez al mes, puede requerir un campo de observación y revisión manual. Si ocurre todos los días, forma parte del flujo y debe modelarse.
Defina el alcance que libera trabajo primero
Reemplazar toda la planilla de una vez parece ordenado, pero suele aumentar el riesgo. Un desarrollo útil parte por el tramo donde se pierde más tiempo o se cometen errores que afectan dinero, plazos o relación con clientes.
Para una operación de despacho, ese tramo puede ser la asignación y confirmación de entregas. Para una empresa de servicios, puede ser el ingreso de solicitudes y su aprobación. Para un equipo comercial, puede ser el seguimiento posterior a una cotización. El sistema inicial debe cubrir ese recorrido completo, aunque deje reportes secundarios para una segunda etapa.
El criterio no es cuántas pestañas desaparecen. El criterio es qué dependencia manual deja de existir. Si el encargado ya no tiene que consolidar archivos antes de tomar una decisión, el cambio produce valor. Si la nueva aplicación obliga a copiar los mismos datos que antes, solo cambió el lugar del problema.
Hay casos en que no conviene reemplazar una planilla. Un análisis financiero puntual, una simulación que cambia cada semana o una lista de trabajo personal puede seguir en una hoja de cálculo. La señal para construir un sistema aparece cuando existe colaboración, reglas repetibles, historial necesario y un proceso que debe sobrevivir a la ausencia de una persona.
Diseñe una fuente de datos y reglas visibles
La base de datos debe guardar entidades claras: clientes, solicitudes, tareas, documentos, responsables y estados. Cada registro necesita un identificador, fechas relevantes y relaciones explícitas. Así, una solicitud no queda descrita en una celda de texto junto con el nombre del cliente y el teléfono de contacto.
Este diseño permite que cada dato se actualice una vez y se use en distintos lugares. El panel muestra trabajo pendiente. Un reporte muestra tiempos por etapa. Una persona con permiso ve documentos asociados. Todos consultan el mismo registro.
Los permisos importan desde el inicio. No todos deben ver ni editar todo. Un operador puede actualizar el avance de una tarea sin modificar condiciones comerciales. Un supervisor puede aprobar un cierre. Administración puede acceder a información sensible. Cuando estos límites se dejan para después, la aplicación termina compartiendo usuarios o entregando acceso excesivo.
También necesita historial. No basta con saber el estado actual. En operaciones con reclamos, pagos, aprobaciones o entregas, importa saber quién cambió un dato, cuándo lo hizo y qué valor tenía antes. Ese registro reduce discusiones y permite revisar errores sin reconstruir conversaciones.
La automatización debe seguir una decisión de negocio
Enviar una notificación, crear una tarea o bloquear un cambio son automatizaciones útiles cuando responden a una regla conocida. Automatizar un proceso confuso solo hace que el error ocurra más rápido.
Primero se define la condición: “si una solicitud lleva dos días sin responsable, debe aparecer en la cola del supervisor”. Después se implementa la alerta. La tecnología queda al servicio de una decisión verificable.
En TevDev Studio, esa lógica se construye desde cero y queda en una base de datos controlada por el negocio. La interfaz importa porque el equipo la usa cada día, pero la pieza crítica es que los datos, permisos e integraciones respondan al proceso acordado.
Migre sin detener la operación
Una migración ordenada rara vez consiste en importar todo el archivo histórico. Las planillas acumulan filas duplicadas, campos sin uso, códigos inconsistentes y datos que nadie consulta. Llevar ese material al sistema nuevo aumenta el trabajo y conserva errores.
Conviene clasificar la información en tres grupos: datos activos necesarios para operar, historial que debe consultarse y archivos que basta con archivar. Los datos activos se limpian e importan. El historial se puede cargar en una vista separada o mantener disponible como respaldo. Lo archivado no debe dictar el diseño del sistema.
Antes de abrir el acceso a todo el equipo, pruebe casos reales con quienes ejecutan el proceso. No una demostración ideal. Use solicitudes incompletas, cambios de responsable, anulaciones, excepciones y registros que llegaron por canales distintos. Ahí aparecen campos faltantes y validaciones mal definidas.
Durante algunos días puede existir operación paralela, pero con una regla clara: definir cuál sistema es la fuente oficial para cada etapa. Mantener ambos como fuentes completas durante meses garantiza diferencias. La planilla debe pasar de herramienta operativa a respaldo, y luego a archivo.
La capacitación también debe ser concreta. Una persona no necesita entender la arquitectura del sistema. Necesita saber qué registra, qué puede editar, dónde encuentra sus pendientes y qué hacer cuando un caso no encaja. Una guía breve por rol suele servir más que un manual extenso.
Deje resuelta la operación del sistema
Un sistema interno también requiere operación técnica. Si guarda información crítica, necesita copias de respaldo, acceso con autenticación, monitoreo y un responsable para incidentes. Dejar estos puntos para “cuando haya tiempo” recrea la dependencia que se buscaba eliminar.
La infraestructura debe estar documentada: dónde está alojado el sistema, quién controla el dominio, cómo se recupera una copia y quién administra los accesos. El negocio debe poder responder estas preguntas sin buscar una contraseña en un chat antiguo.
Cuando cambia el proceso, el sistema también debe poder cambiar. Por eso conviene construir una primera versión acotada, observar su uso y ajustar con evidencia. Agregar campos, reportes o una integración tiene sentido cuando resuelve una fricción observada, no porque una planilla antigua tenía veinte pestañas.
La señal de que el reemplazo funcionó no es que desapareció Excel. Es que una persona puede ver el estado real de la operación sin pedir archivos, que las decisiones dejan registro y que el proceso sigue avanzando aunque quien lo administraba esté de vacaciones.