Technology Migration Plan for a Workforce Function

From WFM Labs

Part of the Planning Week chain · previous: Enterprise Interconnection Plan · next: The Definitions Register Technology migration plan for a workforce function is the plan by which a workforce planning function moves from a set of tools, each bought for a good reason and each carrying its own definitions, to an ecosystem of the same tools on one data core reading one set of definitions. It matters because a recurring state between maturity Level 3 (Progressive) and Level 4 (Advanced) is not the absence of components but their presence without interconnection, and a plan that lists purchases without a build order reproduces that state at greater expense. The page produces the technology component cards (T6, IDs TC-nnn), the dated build order, the integration-by-when table and the sub-plan shells (SP) for its four chapters, and is worked in a session with Wiki:Packs/Technology Plan (CP-WFM-016).

The page is walked on Day 3 afternoon as the fifth pillar of the instantiated GRPI-T frame, and its six chapters follow it: The Definitions Register, Migrating a Book of Business, Placement Engine Build Path, Launching an Analytics Notebook Platform, Expanding Intraday Automation and Systems Administration for WFM Platforms. The block takes no decision of its own; the build order is presented as settled, and what the block produces feeds the first-books decision (D-13) and the owners decision (D-14) on Day 4 morning.

From tools to an ecosystem

Technology Journey from Level 2 to Level 5 describes the five components of a mature workforce ecosystem and the level at which each becomes standard; WFM Ecosystem Architecture is the reference architecture for the destination, and WFM Data Infrastructure and Integration Architecture carries the integration patterns and latencies. None of that is restated here. What a planning week adds is the plan: which components the function has today, by category; which it lacks; in what order the gaps close; and by when each reads the shared definitions rather than its own.

Three conventions govern the plan. Every box on the map is a category, not a product: the plan names the long-term capacity engine, the short-term WFM engine, intraday automation, the reporting platform and the Python analytics platform, and never a vendor; product names belong in an annex, so that the architecture stops depending on which product survives a contract cycle. Second, the long-range horizon has two arms that are routinely conflated: a system of record that stores budget, forecast and actuals and iterates with finance on a fixed step of a monthly cycle, the sales-and-operations-planning lineage,[1] and a simulation engine that calculates and stores nothing, in the sense the simulation literature gives the word: a model run to produce a distribution and a sensitivity, not a record.[2] A function that buys them as one product, or expects one to do the other's job, has one of the failure modes the journey page names. Third, the data core and the definitions are the function's, and every platform is configured to them: the platform executes the ontology and never defines it, the rule Standardize Before You Automate gives as its first standardization. The enterprise-architecture literature makes the general form of the point: which processes must be identical across units and which data must be shared is a choice to be made deliberately, not inherited from whichever unit's system arrived first.[3]

The component map by horizon

The map lists every component by the planning horizon it serves. A node is a place work can sit: a hub (in-country depth), a service center (badged arbitrage at scale), a partner (speed, market access, flex), or automated. The map is node-agnostic; the same components serve work at every node.

Components by horizon, as categories. "Lights at" is the level at which the component is standard. For the five components Technology Journey from Level 2 to Level 5 covers — planning core, intraday automation, plan of record with simulation engine, notebooks, capability record — the level is that page's; for the rest it is this plan's reading, stated here and open to challenge. A component may be in use earlier.
Horizon Component (category) What it does System of record for Lights at
12–36 months Long-term capacity engine (the planning system of record) Budget, forecast and actuals in one structure; iterates with finance; holds the headcount plan; stores and reconciles The plan of record; the headcount perimeter Level 4 as one core; in use from Level 2
12–36 months Simulation engine What-if and sensitivity; queue and shrinkage models; network and site design; calculates, stores nothing Nothing, by design Level 4
Annual and quarterly Capacity and headcount plan Hiring and attrition; skill and site allocation; agreed with finance; refreshed on the monthly Capacity Planning Cycle The signed plan version Level 3
Weekly and daily Short-term WFM engine (forecasting and scheduling; the WFM platform of record) Volume, handle time and shrinkage by interval; shift construction; adherence; publishes the schedule of record The schedule of record; activity states; skills and pools as configured Level 2; on the core at Level 4
Intraday Intraday automation Trigger, notify, offer, action; real-time reallocation of supply; writes actions, not only alerts The rule log and the action record Level 3
Real time Capability layer (the ontology; a platform later) Who can do what: eligibility, proficiency, entitlement; routes supply, not demand The capability record Record at Level 4 on the journey page; this plan writes the ontology on paper from Level 2–3; platform at Level 5
Real time Quality platform Interaction recording; automated scoring; effort, resolution, sentiment; capability evidence flows up Quality scores on one instrument version Level 3
Real time Contact platform (the ACD) Queues, skills and agent state; routes contacts; static skill profiles, limited attribute depth Agent state; the routing configuration Level 2
Data and insight Data core Plan, forecast, schedule, adherence, interaction, quality and outcome data; one history on one set of definitions Every definition's lineage In progress from Level 2; complete at Level 4
Data and insight Reporting platform Scorecards; self-service exploration on governed metrics; describes and explains what happened Nothing; it reads Level 2 to 3
Data and insight Python analytics platform (the reporting platform's notebook component) Notebook-based modeling: elasticity, attribution, capability scoring, the pricing of placement cases Nothing; it reads ledgers and writes dispatches Level 4
Cross-cutting The agent layer Specialist agent teams under a coordinator with a human gate at every plan-changing transition; ledgers, not sheets The ledgers it writes Level 3 as assistants; Level 4 as the automation layer

Where placement is on the map. The placement function is the concept: work sits where objectives and constraints say, at every horizon; the placement engine is the machinery. On the map, placement lives in three boxes at three horizons (the simulation engine designs the network; the capacity plan allocates skills and sites; the capability layer routes supply in real time) and is named in none. The plan draws the engine as a band across the three, with the gate, the six-test, five-outcome check a placement question runs through, as its interface; Placement Engine Build Path builds it.

The build order, settled

Three orderings compete in most functions: prioritize the capability layer over simulation; light simulation before attribute routing; or build definitions first and everything else on them. They agree once one word is settled: the first item of the capability layer is the ontology on paper, delivered inside the definitions program, not a platform. On that reading the three orders are one, and the planning week presents it as settled rather than debated.

The four-step build order. Quarters in the last column are the worked example's, never an estate's.
Step Build Why here Example quarter
1 The definitions register with the capability ontology on paper: the six core definitions with ramp, and who-can-do-what as an attribute dictionary Every later component reads them; the migration of any book cannot land without them (Platform Migration as a Definitional Forcing Function) Q2–Q3 2026
2 The plan of record on one core: the long-term capacity engine as the system of record, iterating with finance The spreadsheet is where the reconciliation argument with finance lives; the plan of record ends it Q4 2026–Q1 2027
3 Simulation and notebooks together: the simulation engine and the Python analytics platform, which share the analysts The engine prices the placement cases, the ramp curve and the outage effect; the notebooks are where those models are built Q2–Q3 2027
4 The capability layer as a platform, inside intraday automation, hooked to routing Only after the ontology has run by hand in the gate for two quarters, so that what is bought executes the function's attributes rather than supplying its own 2028

The rule beneath the order is exhaust the core before buying a tool. The measurement layer of any engine is what a platform bids for; the decision layer is never delegated (Placement Engine Architecture). A function that buys the fourth step first has bought a skills matrix and called it a capability record; one that buys the third before the second has a simulator with no plan to simulate against. The ordering is not a preference for building over buying; it is the sequence in which each purchase has something to read.

Two consequences follow for the function's own build. The Python analytics platform is not a fourth platform to procure: it is the notebook component the reporting platform already carries, launched under governance (Launching an Analytics Notebook Platform). And the short-term WFM engine is not migrated in place: a fresh instance configured to the function's standard holds the method once the standardization seat has finished migrating the largest book and the transitional arrangement ends (Systems Administration for WFM Platforms).

The integration-by-when table

The plan's third artifact turns the build order into dated interfaces: one row per technical crossing, the date by which it reads the shared definitions, and the build-order step, register entry or prior integration it depends on. The Enterprise Interconnection Plan carries the interface register with owners on both sides; the table's columns, its nine generic rows in dependency order and the file-first rule at every boundary are carried in the integration-by-when.md block of Wiki:Packs/Technology Plan, where the working session fills it for the estate. Every date is a proposal until the platform programs' own schedules confirm it.

Worked example

The function of the series example, roughly 40–50 planners [E] serving about a dozen books across voice, chat and email with in-house and partner teams, two instances of the short-term WFM engine and one partner-held scheduling team, sits at Level 2 (Foundational) as a band, not a point [A]. On Day 3 afternoon, Wednesday 22 April 2026, the room fills eleven component cards. TC-001, the short-term WFM engine: two instances today [A], one book migrating, system of record for the schedule. TC-003, the long-term capacity engine: the plan of record not yet on one core [A], the reconciliation with finance in spreadsheets. TC-005, the Python analytics platform: not in place [A], the reporting platform's notebook component named as its home. TC-008, the capability layer: ontology on paper from the front-load, platform not before 2028. The room writes the Technology headline in one sentence: the same tools on one core reading one set of definitions; the ontology on paper before any platform. Four sub-plan shells are opened, SP-001 (engine) to SP-004 (administration), each with an owner as a seat, and the build order's first step is placed in the first-quarter front-load that runs to Tuesday 30 June 2026. Nothing on the cards is a decision; on Day 4 morning D-13 chooses a clean book, not the migrating one, for the fresh instance, and the migrating book for the agent pilot.

The artifact this page produces

The technology component card (T6), one row per component, plus the build-order table, the integration-by-when table and one sub-plan shell (SP) per chapter. One filled example row:

ID Component (category) Horizon What it does System of record for Definitions it must read State today Lights at Product (annex only) Integration and date Program
TC-001 Short-term WFM engine Weekly and daily Forecasting and scheduling; publishes the schedule of record Schedule of record; activity states; skills and pools Contact (CON-01); handle time (AHT-01); shrinkage (SHR-01); the activity-code dictionary Two instances [A]; one book migrating Level 2; on the core at Level 4 (annex) Forecast file adapter on one book, Tue 30 Jun 2026 (with the front-load); fresh instance live for its first book, Q2 2027 (proposal) PG-005 (the fresh instance; Function and Program Charters)

Produced in a working session with Wiki:Packs/Technology Plan (CP-WFM-016); the filled set is part of blueprint v0.1.

What would change this

The build order rests on one claim: that definitions and the ontology on paper are what every later component reads, so that a component bought before them has nothing to read. The observation that would overturn it is a function that bought the capability platform or the simulation engine first, on a vendor's definitions, and produced comparable cross-node numbers from it without a later definitions program. If that function exists, the ordering is a preference rather than a dependency, and the plan should present the four steps as parallel programs with one owner each rather than as a sequence.

How this connects

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. This page uses the WFM Labs Maturity Model™'s Levels 1–5. The plan is written at Level 2 and describes the route to Level 4: step one is Level 2 to Level 3 work done by hand; steps two and three are what Level 4 adds; step four is the Level 5 component, built first as an ontology because the record is needed at Level 4 before the engine is.

See Also

References

  1. ↑ Ling, R. C., & Goddard, W. E. (1988). Orchestrating Success: Improve Control of the Business with Sales & Operations Planning. Essex Junction, VT: Oliver Wight Ltd. Publications. ISBN 978-0-939246-11-3.
  2. ↑ Law, A. M. (2015). Simulation Modeling and Analysis (5th ed.). McGraw-Hill Education. ISBN 978-0-07-340132-4.
  3. ↑ Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press, ch. 2. ISBN 978-1-59139-839-4.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Technology_Migration_Plan_for_a_Workforce_Function&oldid=4736"