Enterprise Interconnection Plan

From WFM Labs

Part of the Planning Week chain · previous: Process Standardization Lifecycle · next: Technology Migration Plan for a Workforce Function An enterprise interconnection plan is the artifact by which a workforce function writes down how it is wired to the rest of the enterprise: a scope table; an interface register with an owner on both sides of every row; one intake door as the single entry for any ask; an interim protocol that runs the placement function by hand until an engine does; and the continuity wire specified as a trigger and a product. Interconnected Workforce Management establishes the register as a concept with its five fields; this page is the plan a room produces from it in one morning, with owners. The page produces the interface card (T5, identifiers I-nnn), the scope table and the intake door card, and is worked in a session with Wiki:Packs/GRPI-T Instantiation (CP-WFM-013) for the cards and Wiki:Packs/Executive Issue Register (CP-OPS-002) for the door.

The plan as an artifact

The fourth pillar of the GRPI-T frame is read as two words. Interpersonal is how the function relates to the people it plans for and the leaders and finance partners it serves; Interconnected is whether each flow between the function and finance, human resources, talent acquisition, technology, commercial, product, training, quality, the delivery partners and operations is owned, timed and defined. Friction between a planning function and finance or recruiting is mostly an interface with no owner, no cadence or no shared definition, and the remedy is a designed interface rather than a better relationship. Organization theory names the dependency, and Interconnected Workforce Management carries it: a workforce function's interfaces are almost all reciprocal, the most expensive kind to coordinate.

A register is a description; a plan is a register with owners, a date on which each row was agreed, and a state-today column. The difference is the work of Day 3 morning.

The scope table

The scope table is agreed before any owner is named, because a row cannot be owned until the room agrees the function is on the hook for it. Its rule: the function owns method; the node owners own decisions; the peers are wired, not owned; and what is out of scope is said, not left to be inferred.

What Note
In scope for the function forecast and schedule; real-time automation and incident management; work placement (the engine, the gate, the registers, the counterfactual record); the instrument and the comparison key across nodes; the methodology for every calculation the function catalog on Process Shells for a Workforce Standard is this list as functions
Wired, not owned finance, human resources, talent acquisition, technology, continuity and crisis, commercial, product, training, quality, the delivery partners; and long-range capacity planning where it is held in another organization the interface register below; each row has an owner on both sides, a cadence and a shared definition
Owned by operations every placement decision; the daily performance of the delivery partners for their node the first rule on Decision Rights by Planning Horizon
Out of scope the in-house nodes' own operating model; the commercial pen on partner contracts (procurement, with the function's input); continuity and crisis management as functions (leaving, with the wire) stated explicitly; an implicit boundary is read as claiming everything

The interface register with owners on both sides

Each row carries the concept page's five fields (flows in, flows out, cadence on the other department's clock, shared definition, failure when unowned) and the plan adds four: an owner on the function's side, an owner on their side, the state today and the date agreed. Owners are seats (a director-graded or manager-graded post with its scope and its sunset condition), never names, on both sides. The plan's rows are the concept page's nine, plus two the worked estate needed (product, because a product decision such as a channel timeout is a demand decision the function never sees coming; the continuity wire, because continuity and crisis leave the function and something must connect them), plus one row that exists only when a planning horizon is held outside the function. That makes eleven peer interfaces and one horizon interface. Operations, the customer of everything the function produces, is the register's first row; it appears in the scope table under what operations owns rather than under what the function wires, because the function owes it products and not a cadence.

Three things make an interface exist rather than merely happen: an owner on each side, in both role descriptions; a cadence on a clock the other department already keeps; and a shared definition, which is why definitional work is interconnection done in advance. The cadence column follows the sales-and-operations-planning cadence discipline Interconnected Workforce Management records, and the reason an unowned interface is expensive rather than merely untidy is the delay argument ROC Organization Models makes about the recruiting, training and attrition loops. The plan's contribution is the other three columns: who owns the row on each side, what state it is in today, and the date the room agreed it.

Which rows bind, and are owned in the room

Naming owners is work, not a vote, and a room cannot name twenty-four owners in a morning. Four rows bind, because a decision the week takes depends on them, and get owners on both sides in the room: finance (the headcount perimeter and the productive-hour denominator), talent acquisition (requisitions derived from the plan after clearing), product (the demand consequence of a release), and the delivery partners (work placed against a named justification on one instrument). The remaining rows are owned in the service pack, the workbook each function owner fills after the week, and the plan records them as owner: assigned in the service pack by with a date. Where long-range planning is held outside the function, its row is a fifth binding row.

Long-range capacity planning held in another organization

Long-range capacity planning may sit in another organization, most often beside the function that owns the annual operating plan, and the plan treats that as a first-class interface rather than an exception. Hardwired means the row is designed to the same five fields as any peer row, with three properties a peer row need not have. The object that crosses it is the plan of record: the long-range plan flows in as the constraint the function schedules against, and the mid-term forecast, the surplus-and-deficit view and delivered-hours actuals flow back as the next cycle's inputs. The cadence is the capacity cycle's own calendar, so the plan lands on a business-day milestone, not on request. The shared definitions are the three two organizations most often hold differently: the headcount perimeter, the productive-hour denominator, and ramp. The failure when unowned is two plans of record, one hired to and one scheduled to. The owner on the function's side is the portfolio planning seat per book; on their side, the seat that signs the long-range plan; the definitions register is co-signed by both, which is what decision D-12 on Day 4 asks for.

The intake door

Every ask enters through one door. Its six fields — the question in one sentence · the decision it feeds · who decides · when it is needed · what data exists · what done looks like — are the ones The Question Register and Knowledge Base specifies, and that page's routing is where this plan starts: it classes what arrives into five, a planning request, a performance question, a data pull, an event and a definitions question. This plan keeps four of the five, sends a definitions question to the same destination a data pull goes to (the definitions register and its queue) rather than routing it separately, and adds two routes of its own: a process-standard request, because the standardization lifecycle needs an entry, and a placement question, because a function that places work has nowhere else to receive one. The six routes below are therefore this chain's construction on that page's five, not a count the wiki already carries.

Route Goes to Returns
a planning request the capacity cycle, or the portfolio planning seat between cycles a plan or a scenario, with its assumption register
a performance question a row in the executive issue register; the hypothesis table; the 48-hour readout an answer-first card: a title sentence with its grade, what changed, the decision requested, the next date
a data pull the definitions register; the queue the number, with its definition cited
an event the event ledger (a go-live, an outage, a client win) an effect window on the forecast
a process-standard request the standards committee's queue a scheduled authoring slot, or a deferral with its reason
a placement question the gate (six tests, five outcomes) the one-page output with the counterfactual recorded; the placement forum signs or declines (The Placement Gate)

If the requester cannot state the decision, the ask is a data pull. The register behind the door is the interface: the one place every department can see what was asked, what was answered, at what grade, and what is still open; the weekly report is derived from it rather than written (Executive Issue Register and Answer-First Reporting carry the record and the report; this page adds only the door's routing). Asks answered where they land are the ordinary state of a function whose relationships are personal and strong; the door is what those relationships become when designed.

The interim protocol

Until the engine runs, the placement function runs by hand on three rules: one intake (the door above, nothing by ping), a 48-hour readout (the question comes back as an answer-first card with its grade and counterfactual within two working days), and an acceptance gate (the owner signs or declines on the record). The protocol is the placeholder for the placement forum; when the forum sits monthly it becomes the forum's intake and readout rules between sittings. Where a placement question surfaces as a leader's escalation and is answered bilaterally, the protocol is what produces the record the escalation can be answered from.

The continuity wire

Continuity and crisis management leave the function, and what stays is a wire, specified as a trigger and a product. The wiki's existing pages place continuity inside the center: Integrated Global Resource Optimization Center houses it there so the crisis response runs on the same live picture of capacity, capability and constraint as the daily operation, and Role Evolution in the Resource Optimization Center follows the continuity and crisis roles in. This plan takes the other branch of the same argument — the roles leave and the products stay — and the choice between them is exactly what decision D-10 puts to the room; where the room decides the other way, the wire becomes a peer row and the register keeps every field.

The trigger: an incident of severity 1 or 2 notifies the continuity function with the standard incident record's fields, per Incident Management for Contact Centers. The products: the continuity plan's capacity assumptions come back to the capacity cycle annually, and the crisis re-plan and placement under duress are products the function makes and the continuity function consumes, on the live view the daily operation uses. Continuity practice requires the interfaces between a continuity management system and the functions it depends on to be defined and exercised;[1] the wire is that definition for the workforce function. The room must say whether the wire is a trigger and a product, an authority to move work, or both. The recommendation is a trigger and a product, never an authority, because the node owner keeps the decision even under duress.

The week takes sixteen decisions; this block takes two of them, D-09 (the scope table; the register with owners on both sides for the binding rows; the door as the single entry; the register as the interface; the weekly report derived) and D-10 (the wire). Where the continuity wire's authority is already settled above the function, the count is fifteen.

Worked example

The function is a workforce planning function formed from three heritages, roughly 40–50 planners [E], with in-house and partner teams, at Level 2 (Foundational) as a band [A]; its long-range planning sits with the analytics function. On Day 3 morning (Wed 22 Apr 2026) the room agrees the scope table and takes D-09: eleven peer rows and one horizon row; owners named on both sides for finance, talent acquisition, product, the delivery partners and the long-range planning row; the rest assigned in the service pack by Tue 30 Jun 2026. I-001, talent acquisition, is the first card written and is reproduced below. I-012, long-range planning, carries the plan of record as its object, the June cycle's BD+7 (Tue 9 Jun 2026) as its cadence, and its three shared definitions recorded as Open until the register signs them. D-10 is deferred with a date: the wire's authority to the sponsor's leader, Fri 1 May 2026, trigger-and-product recommended. The interim protocol starts Mon 27 Apr 2026 with the placement seat as its owner; the cards go to the validation circuit, closing Fri 8 May 2026.

The artifact this page produces

Interface card (T5), one card per interface. In the example row below the five concept fields (flows in, flows out, cadence, shared definition, failure when unowned) are carried from Interconnected Workforce Management's register row for the same interface; the four the plan adds — the owner on each side, the state today and the date agreed — are this page's. One filled example row:

ID Interface Owner, function side Owner, their side Flows in Flows out Cadence Shared definition Failure when unowned State today
I-001 Talent acquisition the portfolio planning seat (per book); the cycle calendar's owner the talent-acquisition lead's seat pipeline state; time to fill; the labor-market view requisitions with start dates from the plan after clearing; the skill profile per hire weekly pipeline; monthly batch after BD+7 time to fill and time to proficiency as separate quantities requisitions open before surpluses elsewhere are checked personal and undocumented; requisitions opened from urgency (Established)

The scope table and the intake door card (the six fields, the six routes as reconciled above, the protocol's three rules) are recorded on the same sheet. Produced in a working session with Wiki:Packs/GRPI-T Instantiation (CP-WFM-013) and Wiki:Packs/Executive Issue Register (CP-OPS-002); the filled set is part of blueprint v0.1.

What would change this

The page's central claim is that an interface exists only with an owner on both sides, a cadence on the other department's clock and a shared definition, and that a long-range planning horizon held elsewhere can work as such an interface rather than be absorbed. The first would be overturned by a function whose finance and recruiting rows, unowned for two annual cycles, show no duplicate headcount and no requisitions opened ahead of clearing; the register would then be documentation. The second would be overturned by a hardwired long-range row that, after two budget cycles with both owners, cadence and co-signed definitions, still produces two plans of record; the horizon would then have to sit inside the function.

How this connects

Maturity Model Position

At Level 2 the interfaces are personal and undocumented; the plan is how a function at Level 2 writes them down in a morning. At Level 3 the cadences are named; the binding rows with owners on both sides — four, or five where a planning horizon sits outside the function — are that state. At Level 4 the register is complete, which is what the service-pack assignments work toward. Four scales on this wiki use the word "level"; Planning Week for a Workforce Function states which is which. This page uses the maturity levels.

See Also

References

  1. ↑ International Organization for Standardization (2019). ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements. Geneva: ISO.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Enterprise_Interconnection_Plan&oldid=4727"