El Consejo General de Educación es el organismo rector del sistema educativo de la provincia de Entre Ríos. El sistema es interno del organismo y cubre prácticamente todos los expedientes que ingresan al Consejo vinculados a los procesos de liquidaciones.
Un circuito administrativo que vivía en papel y en la memoria de la gente, convertido en un workflow explícito: máquina de estados, autorización propia y parametrización de lo que realmente cambiaba. Miles de expedientes, más de 10 áreas y alrededor de 60 personas, sobre PHP 7 y SQL Server, sin poder incorporar una sola librería externa.
Antes de la digitalización el circuito dependía del papel y del conocimiento informal de quienes participaban en cada proceso. Saber dónde estaba un expediente, quién lo tenía y qué había pasado con él exigía preguntar.
Las excepciones y los casos particulares no estaban escritos en ninguna parte: vivían en la cabeza de las personas que los habían visto antes. Cuando esa persona no estaba, el expediente se frenaba.
Los expedientes podían quedar en estados incorrectos o trabados, y controlar las responsabilidades entre áreas era difícil.
Las reglas, los contratos y los permisos cambiaban seguido, así que un circuito rígido se rompía apenas cambiaba la operación real.
01
El estado actual determina en qué etapa y en qué área está el expediente, y qué operaciones se pueden hacer sobre él. Varios flags booleanos sueltos permiten combinaciones que no existen en el circuito real, y son justamente esas combinaciones las que dejan expedientes trabados.
Trade-off: Más complejidad inicial: hay que modelar con cuidado cada transición y cada excepción antes de escribir código. A cambio, el workflow queda consistente y controlado.
02
Los permisos generales de SAGE no distinguían lo que el circuito de liquidaciones necesitaba: que ciertos responsables y jefaturas pudieran consultar o modificar decisiones de otros usuarios, y que el resto tuviera un alcance más acotado. Como los roles cambiaban con frecuencia, la administración se hace desde un dashboard y no tocando la base de datos a mano.
Trade-off: Una segunda capa de autorización que hay que mantener y mantener coherente con la primera. El beneficio es independencia respecto de SAGE y poder adaptar los permisos del módulo al ritmo al que cambian de verdad.
03
Las áreas, las responsabilidades y los permisos cambiaban con la operación, y cada cambio no podía significar un despliegue. La parametrización apunta a eso: áreas, roles y permisos, y comportamiento del circuito.
Trade-off: Más esfuerzo inicial y más validaciones que escribir. El riesgo del otro extremo —parametrizar todo— es terminar con lógica dinámica difícil de leer y de mantener, así que la línea se trazó en lo que efectivamente cambiaba.
El expediente es la entidad central y su estado gobierna el circuito: en qué etapa está, en qué área, y qué operaciones habilita. Sobre eso corren dos capas de autorización —la general de SAGE y la propia del módulo de liquidaciones, administrable desde un dashboard— y una capa de parametrización de áreas, roles y comportamiento del circuito. Backend en PHP 7 sobre Apache, acceso a SQL Server vía PDO/ODBC, y frontend en JavaScript con jQuery y AJAX sobre Bootstrap.