Decoupling Position Plans

1. Background

Position Plan and Position Instance

A position plan is generated by an upstream business system from a registration form. It says which position an employee is planned to hold during a time interval. It carries the position, organization, appointment type, reasonCode, and related data. It describes what is planned to happen.

A position instance is calculated by the master-data system from those plans. It represents the appointment state actually effective at a point in time. Downstream systems consume it, and organizational structures are derived from it.

The original flow was:

Business system
  -> create position plan
  -> send it to master data
  -> scheduled orchestration and activation
  -> generate position instance

State of the System

The notes describe seven upstream business systems, more than 80 reasonCode values, roughly ten data corrections per day, and no single owner for conflicts among business meanings. Business systems had absorbed some master-data responsibilities. Semantic boundaries and rules were scattered, making corrections expensive.

Goal of the Decoupling Work

The proposed direction was to make master data the sole center for position semantics and timeline orchestration. Business systems could then focus on their own workflows instead of maintaining complex appointment rules or understanding the entire timeline engine. This could also give them an opportunity to simplify historical code.

For master data, the goal was to unify meanings, redesign orchestration, improve the timeline and structure-derivation engines, and reduce long-term maintenance cost.

2. Overall Split

The design separated generation, where business events are interpreted, from orchestration, where position states are computed. Orchestration in turn contained a timeline engine and a structure-derivation engine.

3. Difficulty on the Generation Side

Because core HR operations and master data had separate responsibilities, each of the seven business systems needed to be understood on its own. Scenarios included hiring, leaving, transfers, promotions, and assignments.

Starting from a registration form, the team had to trace the complete business flow, identify where each field came from, clarify its meaning, and understand how a position plan was ultimately generated. The source notes say understanding one business flow fully could often take a day.

This work was necessary to draw semantic boundaries, decide which system owned which rule, design admission rules, and prepare for later consistency checks. It was the main source of complexity on the generation side.

4. Difficulty on the Orchestration Side

Timeline Engine

The timeline engine was responsible for opening and closing appointment intervals, resolving conflicts, simulating historical insertions, reversing a cancellation, and making the conflict matrix configurable.

A historical insertion requires recalculating plans after the insertion point, validating them again, and potentially updating derived records. A cancellation requires assessing its effect on later appointments, deciding whether future states remain valid, and sometimes triggering an alert or manual intervention. The underlying problem is continuous consistency along a timeline.

Structure-Derivation Engine

Once a position becomes effective, the system must handle multiple positions, identify the primary position, calculate proportions for multiple reporting lines, rebuild the primary reporting chain, and generate organizational relationships. In effect, it constructs a changing organization graph from time-based position results.

5. Organizational Difficulty

Coordinating the work could be harder than implementing the core logic. The notes estimated roughly half a month for the generation-side change in one business system, including development, integration testing, and tests, with coordination from master data. If several systems changed at different times, testing cost, risk, and inconsistent behavior would rise.

This was a master-data-led, cross-system change rather than an isolated service refactor.

6. Overall Assessment

The proposed work combined cross-system semantic governance, timeline-engine design, dynamic organizational graph derivation, and coordination across teams. The source classified it as an enterprise master-data governance project. This article describes the plan and complexity; it does not claim that the entire decoupling program was completed.