Saltar al contenido

El Consejo General de Educación es el organismo rector del sistema educativo de la provincia de Entre Ríos. El sistema es de alcance provincial: lo usa todo el personal escolar —docentes, directivos, administrativos y auxiliares—, no solo el personal del organismo.

Sistema de Carga y Validación de Certificados de Salario Familiar

Digitalización provincial de un trámite que vivía en papel: de 4 meses a 5 semanas de resolución promedio, con una campaña anual concentrada de 20.000 a 30.000 expedientes y cerca de 50.000 archivos, sobre un stack heredado y sin poder instalar una sola librería externa.

  • PHP 7
  • SQL Server
  • JavaScript
  • jQuery
  • AJAX
  • Bootstrap
Tiempo de resolución
4 meses → 5 semanas

Promedio del trámite, antes y después

Trámites por campaña
20.000–30.000

Campaña única anual de 3 a 4 meses

Archivos procesados
≈50.000

2 archivos y 2 etapas de validación por trámite

El problema

El trámite de salario familiar se hacía en papel. Cada establecimiento educativo mantenía sus propias planillas físicas, y la documentación viajaba hasta el área de Liquidaciones para ser validada a mano.

El volumen no es continuo: se concentra en una campaña única de tres a cuatro meses por año, con entre 20.000 y 30.000 trámites. Cada trámite lleva dos archivos y pasa por dos etapas de validación, así que la campaña mueve alrededor de 50.000 archivos en una ventana corta.

En papel no había forma de responder dos preguntas básicas: dónde está mi trámite, y quién validó qué. Sin trazabilidad, cada consulta era una búsqueda manual.

Restricciones

  • Stack heredado no negociable: PHP 7 y SQL Server. El organismo no iba a migrar por este proyecto.
  • Restricción técnica del organismo: no se podían instalar librerías externas. Todo lo que no viniera con PHP había que escribirlo.
  • Integración obligatoria con el SAGE, el sistema de administración de la gestión educativa provincial ya en uso.
  • Los usuarios finales son todo el personal escolar de la provincia, en su enorme mayoría sin formación técnica y con conectividad desigual.
  • El pico es estacional y no se puede diferir: si el sistema falla durante la campaña, el trámite no espera al año siguiente.

Decisiones

  1. 01

    Escribir la capa de seguridad de carga de archivos desde cero, en PHP nativo

    Subir archivos es la superficie de ataque más peligrosa de un sistema público: si se acepta cualquier cosa, el servidor termina ejecutando lo que le manden. Sin librerías disponibles, implementé validación de tipo real, saneamiento de nombres y control de acceso a la descarga, todo con las primitivas del lenguaje.

    Trade-off: Código propio de seguridad es código propio que hay que mantener y auditar, y no tiene detrás los años de escrutinio público de una librería establecida. Lo asumí porque la alternativa no era usar una librería, era no validar.

  2. 02

    Auditoría y trazabilidad dentro del modelo de datos, no como log adjunto

    En un trámite que afecta la liquidación de un sueldo, la pregunta “quién validó esto y cuándo” no es diagnóstico: es parte del expediente. Modelarlo en la base, y no en un archivo de log aparte, hace que la respuesta sea una consulta y no una investigación.

    Trade-off: Más escrituras por trámite y un esquema más pesado. A cambio, la trazabilidad no se puede perder ni rotar por accidente.

  3. 03

    Dos etapas de validación por trámite

    Separar la validación permite frenar un expediente incompleto antes de que llegue a liquidación, que es donde un error cuesta plata y retrabajo real.

    Trade-off: Un paso más para el usuario y el doble de archivos a procesar. El costo se paga en la campaña; el error, en el sueldo de alguien.

  4. 04

    Documentar en dos formatos: manual escrito y videos instructivos

    Escribí los manuales en PDF, pero para una audiencia de toda la provincia y sin formación técnica un documento no alcanza: hay gente que no lo va a abrir nunca. Dirigí además los videos instructivos, que muestran la pantalla real paso a paso y se difundieron para toda la comunidad educativa. No era elegir uno u otro: era cubrir a quien lee y a quien no.

    Trade-off: Dos materiales que mantener en lugar de uno. Si cambia la interfaz hay que rehacer los dos, y el video es el caro de rehacer. Para un sistema con una única campaña al año, el intercambio conviene.

Arquitectura

Backend en PHP 7 sobre SQL Server, con la base modelada alrededor del expediente y sus estados de validación. El frontend es JavaScript con jQuery y AJAX para que la carga y el seguimiento no exijan recargar la página en conexiones lentas. La capa de archivos está separada del resto: recibe, valida, sanea y recién entonces persiste, y toda descarga pasa por control de acceso en lugar de servirse directo del filesystem. Las consultas de seguimiento y los procesos de carga masiva están optimizados para el pico de campaña, que es cuando el sistema realmente se prueba.

Resultado

  • Redujo el tiempo promedio de resolución del trámite de 4 meses a 5 semanas.
  • Eliminó las planillas físicas en cada establecimiento educativo de la provincia.
  • Fue presentado en acto oficial en el salón de actos del Consejo General de Educación, en abril de 2024.
  • La nota de prensa oficial del organismo me identifica como programador y creador del sistema. Es el activo más verificable de mi perfil, porque no lo escribí yo.

Qué haría distinto hoy

  • Procesaría las validaciones fuera del request. Durante el pico de campaña, hacer todo el trabajo de forma síncrona convierte cada lentitud en una espera del usuario; una cola simple habría absorbido el pico sin tocar la experiencia.
  • Sacaría los archivos del filesystem de la aplicación. Almacenamiento aparte, con URLs firmadas de vida corta, reduce la superficie de ataque y hace que crecer no dependa del disco del servidor.
  • Escribiría tests automatizados sobre la capa de carga. Es el componente con más riesgo y el que más veces toqué a mano: es exactamente donde una suite de tests se paga sola.
  • La restricción de no poder usar librerías externas la planteé y la dejé documentada por escrito en su momento; nunca se levantó. Lo que cambiaría hoy no es haberla discutido, sino cómo: llevarla con un riesgo concreto y su costo estimado en lugar de un argumento técnico. En un organismo público una restricción se mueve cuando alguien puede firmar el riesgo, no cuando entiende el razonamiento.