📘Consumo de Datos
Definición de Consumo de Datos
Una de las confusiones más comunes al aprender la arquitectura de SAP SuccessFactors es imaginar que Employee Central "envía" o "empuja" datos hacia los demás módulos, como si estuviera constantemente repartiendo información. La realidad es más elegante y más eficiente: EC actúa como un repositorio central, la única fuente de verdad de los datos maestros del empleado, y son los demás módulos los que consumen esa información cuando la necesitan para ejecutar sus propios procesos. Es decir, el flujo no es "EC envía", sino "los módulos leen de EC". Payroll no redefine quién es el empleado ni cuál es su puesto: cuando necesita calcular la nómina, toma esos datos desde EC y los usa como entrada. Compensation lee el salario actual desde EC para proponer un aumento y, una vez aprobado, escribe el nuevo valor de vuelta en EC. Learning consulta el rol de la persona para recomendar cursos. Performance lee el manager y la posición para asignar objetivos. Este patrón de consumo tiene consecuencias de diseño muy concretas. Como EC es el dueño del dato maestro y los demás son consumidores, ningún módulo debe mantener su propia versión "maestra" de la identidad del empleado: eso evita el problema histórico de RRHH, que es la fragmentación de datos, donde nómina dice una cosa, performance otra y reporting una tercera. El consumo se realiza mediante APIs seguras —principalmente OData y la Compound Employee API— que permiten a cada módulo pedirle a EC exactamente los datos que necesita, en el momento en que los necesita. Entender esta dirección del flujo es lo que evita errores graves de arquitectura. El anti-patrón más peligroso es permitir que un módulo aguas abajo modifique localmente un dato que nació en EC —por ejemplo, ajustar un salario directamente en el sistema de nómina sin pasar por EC—, porque eso genera divergencia: dos fuentes que dicen valores distintos y nadie sabe cuál es la verdadera. La regla es clara: todo cambio se origina en EC y se replica hacia afuera, nunca al revés. Para el consultor, pensar en términos de "quién consume qué de EC" es la base para diseñar integraciones sanas: primero se define qué datos necesita cada módulo, después con qué mecanismo los va a leer, y siempre se preserva a EC como el punto único de custodia y modificación. Este modelo de consumo, y no de empuje indiscriminado, es lo que mantiene coherente a todo el ecosistema HXM.
Disponibilidad Laboral: FullTime 
