Lo probamos hasta que tuvimos un problema (cinco, en realidad)

Antes de que un tablero de control empiece a operar en el día a día de un estudio, hay una etapa que no se ve: correr el circuito de punta a punta, con datos reales de clientes y servicios, tal como ocurriría en una semana de vencimientos.

Eso hicimos. Tomamos la estructura operativa de un estudio y recreamos un período mensual completo: los vencimientos del mes se generan según las reglas del calendario fiscal y la terminación de cada CUIT, cada tarea aparece en la agenda de su responsable, el trabajo se marca como presentado, la documentación queda archivada en la carpeta del período. Todo el circuito, paso por paso, mirando qué pasa en cada punto.

No lo hicimos para armar un informe que no lleva a nada. Lo hicimos para forzar el sistema y encontrar los errores nosotros, antes de que los encuentre un estudio trabajando.

Los cinco problemas que aparecieron

Cinco, en una misma jornada. Contados en el idioma del trabajo diario, no en el técnico:

1. Vencimientos de años anteriores en el mes en curso. Al generar el período, el calendario de reglas fiscales se leía completo, sin filtrar por año, así que reglas de ejercicios ya cerrados seguían produciendo vencimientos del mes. En la operación diaria, alguien del equipo se hubiera encontrado en su agenda con un vencimiento que no correspondía, y hubiera perdido tiempo de control verificando algo ya resuelto.
2. La carpeta del período no se creaba. Cada período tiene su carpeta, ordenada por cliente, servicio, año y mes, donde va toda la documentación de ese mes. Un paso anterior la dejaba marcada como si ya existiera, así que el paso que la crea nunca llegaba a ejecutarse. La documentación del período iba a quedar sin su lugar, suelta o guardada donde no corresponde.
3. Documentación archivada en una ruta sin año. La carpeta se creaba, pero le faltaba el año: quedaba en /07 en lugar de /2026/07. El archivo existía y estaba a resguardo, pero encontrarlo meses después, ante un pedido de información, hubiera obligado a buscarlo a mano. El documento existe, pero para el que lo necesita es como si no existiera.
4. Trabajo presentado que seguía figurando como pendiente. El último paso del circuito, el que deja registrado el cierre, esperaba un estado que en el sistema no existía, así que no se ejecutaba nunca. Para quien coordina, la tarea seguía apareciendo pendiente aunque estuviera hecha. Y a diferencia de un error visible, este no avisa: todo parece en orden hasta que alguien pregunta por qué nada figura cerrado.
5. El cierre que empezaba y no terminaba. Corregido lo anterior, apareció el quinto: ese mismo paso no lograba abrir el documento que el responsable había adjuntado desde su tablero de tareas, porque la dirección del archivo le llegaba incompleta. El cierre arrancaba y quedaba a medias, sin dejar registrado quién había terminado el trabajo ni cuándo.

Los cinco se corrigieron ese mismo día. Después volvimos a recorrer el circuito completo, de punta a punta, hasta que cerró sin que nadie tuviera que intervenir.

Por qué te contamos esto

Porque un problema encontrado en una prueba cuesta una corrección. El mismo problema encontrado en tu operación cuesta una fecha pasada, un documento que no aparece, una tarea que nadie vio. La diferencia no es el problema: es dónde se encuentra.

Y porque hay algo que este proceso muestra mejor que cualquier presentación:

La certeza no se promete, se fabrica.

Se fabrica probando, encontrando los problemas y corrigiéndolos antes de entrar. Cuando alguien te ofrece un programa para tu estudio, la pregunta no es solo qué hace. Es quién lo hizo funcionar de punta a punta antes de dártelo, y qué encontró cuando lo hizo.

De dónde viene la fricción: el dato que solo informa

El desorden operativo rara vez viene de una falta de cuidado del equipo. Viene de que la información es estática. Cuando el estudio depende de que cada persona actualice a mano una celda para avisar que terminó, el margen de error es alto, y el profesional termina revisando para confiar. Eso consume horas caras en control administrativo.

Con diez clientes, los vencimientos se llevan de memoria. Con cien CUITs bajo gestión, esa estructura cruje y la fricción se vuelve constante.

El cambio no es sumar una herramienta que obligue al equipo a aprender todo de nuevo. Es que el dato deje de ser un registro y pase a disparar lo que viene después:

• Cuando el responsable guarda la documentación de una presentación, el tablero cambia de estado solo, y queda registrado quién la terminó y cuándo.
• Si ARCA (ex AFIP) publica una prórroga sobre la fecha, las agendas del equipo se reacomodan en cadena, sin reprogramar tarea por tarea.
• Todo esto corre sobre el entorno de Microsoft que el estudio ya usa y ya paga. No es una plataforma nueva: es la infraestructura que ya está, sosteniendo la operación completa, con los datos bajo control del estudio.

Cada punto donde el circuito sigue porque una persona se acordó, avisó o revisó es un lugar donde puede cortarse un día cualquiera, sin avisar. Nosotros encontramos cinco en el nuestro, probando. Saber dónde están los tuyos ya es la mitad del trabajo.

Si querés ver cómo trabajamos este proceso en un estudio, la conversación inicial no tiene costo: roadtobiz.com/demo.