← Volver a proyectos

Caso de estudio · Gestión RRHH

Un solo núcleo para los flujos de Recursos Humanos.

Las entradas operativas se normalizan en una misma arquitectura. Las aplicaciones consumen funciones y vistas controladas, no datos dispersos.

Dominio
Recursos Humanos
Productos
Web · escritorio · portal
Núcleo
Supabase · PostgreSQL
Controles
Roles · RLS · RPCs

Arquitectura operativa

Ecosistema de gestión de Recursos Humanos

Cada tarjeta representa una aplicación o un módulo conectado al núcleo de datos.

consulta y actualización consulta de solo lectura módulo dependiente
Legajo Digitalweb
  • personas
  • datos personales
  • datos laborales
  • banco de horas inicial
Supabase · HESMcore
  • Postgres
  • Auth y roles
  • RLS y RPC
  • migraciones

Núcleo compartido de datos y reglas de acceso.

App Suplenciasapk
  • suplencias
  • personas suplentes
  • vistas por jefatura
Gestión RRHHwindows
  • novedades administrativas
  • horas y permisos
  • consulta y exportación
Consulta de Horasportal
  • consulta individual
  • acceso acotado por RPC
  • sin escritura directa
Licencias médicasmódulo
Artículo 8 · imprevistosmódulo
Horas compensatoriasmódulo
Permisos de salidamódulo
Capacitaciónmódulo

Interacción: arrastrá nodos para reorganizar el mapa. Al pasar el cursor sobre una aplicación o módulo, se resaltan únicamente sus conexiones.

01 / El problema

El dato pierde valor cuando cada proceso trabaja por separado

Asistencia, licencias, horas y suplencias afectan a la misma persona, pero suelen vivir en planillas, mensajes o aplicaciones aisladas. Eso multiplica la carga manual y vuelve difícil explicar de dónde salió un saldo o quién modificó un registro.

El objetivo no fue sumar otra pantalla: fue ordenar el recorrido completo de la información y mantener una referencia consistente entre los distintos productos.

02 / Decisiones

La arquitectura sigue al proceso real

01

Un núcleo compartido

Los productos parten de entidades, validaciones y reglas comunes para evitar versiones contradictorias del mismo dato.

02

Acceso mínimo por canal

El backoffice, las aplicaciones operativas y el portal público no exponen la misma superficie ni los mismos permisos.

03

Reglas cerca de los datos

RLS, funciones y validaciones en PostgreSQL sostienen los límites aunque cambie la interfaz que consume la información.

04

Trazabilidad operativa

Estados, períodos e identidad permiten reconstruir qué ocurrió sin depender de conversaciones o archivos dispersos.

03 / Productos

Cuatro productos, un mismo dominio

El mapa resume cómo se relacionan. Cada implementación resuelve un momento distinto de la operación.

01

Sistema interno

Legajo Digital

Centraliza situación de revista, carrera, asistencia y banco inicial de horas con acceso por roles.

Next.js · React · TypeScript · SupabaseVer repositorio ↗
02

Operación de escritorio

HESM Gestión RRHH

Ordena la carga cotidiana de horas, francos y novedades, además de consultas y exportaciones.

Flutter · Dart · Riverpod · SupabaseVer repositorio ↗
03

Portal del agente

Consulta Horas

Separa la consulta pública del backoffice y expone únicamente la información necesaria de cada agente.

Cloudflare Pages · Workers · TurnstileVer repositorio ↗
04

Aplicación operativa

Suplencias Propuesta

Registra propuestas y coberturas con autenticación, permisos, validación de períodos y control de duplicados.

Flutter · Dart · PostgreSQL · SupabaseVer repositorio ↗

Resultado

Una arquitectura capaz de sumar nuevas interfaces sin volver a inventar identidad, permisos y reglas para cada una.
FlutterNext.jsSupabasePostgreSQLRLSCloudflare

¿Tenés un proceso disperso?

Podemos convertirlo en una primera etapa verificable.

Conversemos