Una Persona, Un Registro: Cómo un Departamento Reemplazado Rompió los Silos con un CRM Unificado

Una adolescente se une a un programa juvenil. Unos años después, se inscribe en un programa universitario y más tarde se convierte en donante. Para la organización, esta es una relación larga. Para sus bases de datos, ella era tres personas distintas.

Esta era la realidad en la Unión Ortodoxa, una organización sin fines de lucro que maneja muchos programas bajo un mismo techo.

La organización 

Los programas de la Unión Ortodoxa incluyen:

• NCSY para adolescentes

• JLIC en campus universitarios

• Yachad para personas con discapacidades

• el Impact Accelerator para otras organizaciones sin fines de lucro

• campañas de defensa

• programas en Israel, entre otros

Con el paso de los años, cada departamento construyó su propio sistema, por lo que la misma persona podía estar almacenada en varias bases de datos y nadie tenía la imagen completa.

Por qué los sistemas separados dejaron de funcionar

• No hay imagen completa. Los registros estaban duplicados en varios departamentos, por lo que nadie podía ver el historial completo de una persona con la organización.

• Sistemas heredados por todas partes. MARS, la API de Yachad, la plataforma Impact Accelerator y una app separada para verificación de antecedentes, cada uno contenía años de datos y flujos de trabajo diarios.

• Datos sensibles en juego. Combinar registros significaba que una base de datos tendría detalles médicos para programas juveniles e inclusión. Cada departamento aún debía ver solo sus propios registros.

• Demasiado trabajo manual. Las aprobaciones, confirmaciones, recordatorios y mensajes de agradecimiento se manejaban principalmente a mano.

La arquitectura: tres capas

En 2025-2026, la empresa de desarrollo SoftPro consolidó estos sistemas en una sola plataforma. Está organizada en tres capas:

1. Aplicación web para el personal. Los departamentos trabajan en sus propios espacios, con sus propias pantallas y reglas de acceso.

2. API. Impulsa la aplicación y contiene la lógica de negocio.

3. Widgets embebibles. Registro de eventos, pagos y solicitudes que se ejecutan en los sitios web públicos de la organización.

En el centro hay un registro para cada persona y hogar. Contiene toda su historia con la organización: programas, eventos, familia, donaciones y comunicaciones.

Seis decisiones de diseño que lo hicieron funcionar

• Registros compartidos, capas departamentales. Cada departamento añade sus propios datos encima de un registro común de persona y hogar. Se detectan y fusionan registros duplicados.

• Una migración característica por característica. Cada característica heredada fue mapeada a un nuevo lugar, los flujos de trabajo se reconstruyeron en el CRM y herramientas dedicadas de importación movieron los datos existentes.

• Privacidad en la capa de datos. El aislamiento departamental filtra todas las solicitudes automáticamente. Las reglas de acceso, seguimiento de consentimientos y auditorías fueron diseñadas con los requisitos HIPAA en mente.

• Módulos con límites claros. Cada departamento se desarrolló en la misma base de código al mismo tiempo. Cada área del departamento es un módulo separado, verificado automáticamente en cada cambio, por lo que trabajar en uno es mucho menos probable que rompa otro.

• Widgets para el público. Un pequeño fragmento incrusta un widget en cualquier sitio web. El inicio de sesión es sin contraseña a través de un enlace enviado por correo electrónico, y los registros y pagos van directamente al CRM.

• Automatización basada en eventos. Un nuevo registro, pago u otro cambio desencadena flujos de trabajo ya preparados para aprobaciones, confirmaciones, recordatorios y mensajes de agradecimiento.

Pila tecnológica

• Backend: Node.js, Express, oRPC, Zod

• Frontend: Vue 3, TypeScript, Tailwind CSS, shadcn-vue, TanStack Query, TanStack Table, Storybook

• Datos: PostgreSQL (Amazon Aurora), Prisma ORM, ClickHouse

• Widgets: Componentes Web (Vue)

• Autenticación: Okta, Amazon Cognito

• IA: Amazon Bedrock (Claude), Google Gemini

• Nube y entrega: AWS, Docker, Kubernetes, Helm, GitHub Actions

• Integraciones: SendGrid, Amazon SES, Zoom, JotForm, Checkr, Congress.gov, la pasarela de pago de la organización

Estado del proyecto

• Sistemas reemplazados. El CRM reemplaza MARS, la API Yachad, la plataforma Impact Accelerator y una aplicación independiente de verificación de antecedentes.

• Escala. La plataforma incluye más de 40 módulos de funciones que abarcan juventud, campus, inclusión, Israel, defensa, eventos, recaudación de fondos, pagos, personal y voluntarios. Estos funcionan con más de 480 tablas de bases de datos, más de 40 áreas de API y más de 70 flujos de trabajo automatizados.

• Widgets públicos. Los widgets para registro de eventos, pagos, campañas de defensa y solicitudes de asesores están listos para incrustar.

• Privacidad incorporada. El aislamiento departamental se aplica a cada solicitud, junto con el seguimiento del consentimiento y las auditorías.

• Plan de implementación. Los departamentos se ponen en marcha uno a la vez, cada uno probado primero por un pequeño grupo de usuarios reales. El despliegue completo está planeado para finales de 2026.

Lecciones para organizaciones multiprograma

El caso de OU demuestra que reunir datos y mantener departamentos independientes puede funcionar en un sistema. La clave es diseñar para ambos desde el principio: un registro central compartido, aislamiento en la capa de datos y código modular. Las organizaciones que planean un movimiento similar pueden hablar con el equipo de SoftPro sobre cómo abordarlo.

Conclusión

La Unión Ortodoxa pasó de muchos sistemas desconectados a una plataforma donde cada persona tiene un registro y cada departamento ve solo lo que debe. Los flujos de trabajo heredados se han reconstruido, los sitios web públicos alimentan datos directamente al CRM y los mensajes rutinarios se ejecutan por sí mismos. Los departamentos están siendo trasladados uno a uno antes de un lanzamiento completo previsto para finales de 2026.