Systems Administration for WFM Platforms

From WFM Labs

Part of the Planning Week chain · previous: Expanding Intraday Automation · next: AI Agent Program for a Resource Optimization Center Systems administration for WFM platforms is the method by which a workforce planning function holds the configuration of its platforms (the short-term WFM engine above all, and intraday automation and the long-term capacity engine beside it) to its own standard, so that the platform executes the function's definitions rather than supplying its own. It matters because a platform's configuration is where definitions become real: an activity code, a skill, a pool or a lock date configured differently on two instances is two definitions in circulation whatever the register says, and the consolidation of a function assembled from several heritages is not complete until one configuration holds. The page produces the administration sub-plan shell (SP-004) and is worked in a session with Wiki:Packs/Technology Plan (CP-WFM-016).

The page is walked on Day 3 afternoon as the last chapter of Technology Migration Plan for a Workforce Function, ten minutes. It describes a function as method, not a team: the administration may be staffed centrally, distributed to the planning seats, or partly held by the platform's vendor, and the method is the same in each case.

Configuration to the standard

The Standard a function issues (Anatomy of a ROC Standard) carries a toolset section that is platform-neutral, with products in an annex. The administration method is that section made real: nothing is configured that is not in the Standard. Three objects carry most of the weight.

Object What "one" means Where the definition lives What breaks when there are two
One activity-code set Every activity type carries identical attributes across the estate: whether it is paid, whether it counts as available, which shrinkage category it belongs to Activity-Code Consistency; the shrinkage entry of The Definitions Register Cross-node shrinkage and occupancy are not comparable; a report that spans two instances is reporting two things
One skill and pool dictionary One skill taxonomy with a mapping from each heritage's; pools indexed on work attributes, not reporting lines The register's capability ontology; the object inventory of Platform Migration as a Definitional Forcing Function Fungibility across the estate fails; the placement engine's supply cards describe pools that do not exist on the platform
One lock calendar One forecast-lock and schedule-publication calendar with partner lead times, published a year ahead with an owner Forecast Lock Process; the capacity cycle's pencils-down date Two books lock on two clocks; a partner receives two versions of the same week

The administration method holds these three as configuration under change control, and treats every other setting (shift templates, adherence tolerances, bid rules) as derived from the Standard's process sections rather than as the administrator's discretion. The data-management literature places objects of this kind under stewardship: defined once, owned, versioned and referenced.[1]

The change-control board owns configuration

Configuration changes on a WFM platform are method changes wearing a technical coat. A new activity code changes what shrinkage means; a new skill changes what a pool can do; a moved lock date changes what a partner was promised. The method therefore places ownership of configuration with the change-control board, one of the four forums Decision Rights by Planning Horizon establishes, and not with the administrator or the platform's vendor. The administrator proposes and executes; the board decides; the record is kept.

The board's log is a change register in the ordinary sense the service-management literature gives it: every change with its requester, its assessment, its authorization, its schedule and its outcome, so that a configuration can be traced to the decision that produced it and a defect to the change that introduced it.[2] Two classes of change carry their own rules. A routing or allocation change that touches a partner node follows Vendor Change Control for Routing, whose form, contract mechanisms and confirmation the board applies. And the migration schedule of any book is a board item, per Migrating a Book of Business, because a phase date is the largest single configuration change in most quarters.

The release calendar as an interface with IT

The platform's vendor releases on its own cycle; the enterprise's technology function has change windows and freeze periods of its own; the planning function has lock dates and peak seasons on which nothing may move. The three calendars collide unless one interface holds them together. The method makes the release calendar a named interface in the Enterprise Interconnection Plan's register, with an owner on each side and a cadence: the technology function publishes releases and windows; the planning function publishes locks and freezes; the collision calendar (Forecast Collision Calendar) records both, so that a vendor release does not land in the week a book locks or a phase migrates. The discipline is the software-delivery literature's: releases are scheduled, rehearsed and reversible, and a release without a rollback is not a release.[3] What the planning function adds is the freeze: a release that changes a definition-bearing object is a board item like any other, and a release in a freeze window is declined with its price recorded.

Instance strategy

A function with more than one instance of the short-term WFM engine, each carrying an inherited configuration, faces one decision: reconcile the configurations in place, or build a fresh instance to the Standard and move books onto it. The method prefers the fresh instance, for three reasons, and states them as inference rather than as a rule that binds every estate.

First, the migration of any book between instances cannot be executed without shared definitions of gates, skills and pools (Platform Migration as a Definitional Forcing Function), and building the instance to the Standard is how those definitions become real: the instance's data dictionary is the register, not the other way around. Second, activity types must carry identical attributes across the estate before any cross-node report is reliable, and several inherited configurations cannot be reconciled in place without becoming, in effect, a fresh configuration anyway. Third, the fresh instance is what stops re-fragmentation once the standardization seat has finished migrating the largest book and the transitional arrangement ends: a portfolio can staff schedulers on it, and the method cannot be changed without the board.

Two rules govern the first book. It is a clean book, one already on the platform of record with the cleanest definitions, and not the book in the middle of a migration; the migrating book carries the migration's problems, and the instance should inherit none of them. And the instance is chartered as a program with an owner as a seat, a first-90-days list and its own dependencies (the register, the activity-code dictionary, the release calendar, the standards committee's first process documents), because a fresh instance treated as a task is configured in the gaps between other work and becomes a fifth configuration instead of the one.

Access, audit and retention

Three controls complete the method, and each is cited rather than restated. Access follows least privilege by seat: a configuration right is granted to a seat for a stated purpose and reviewed on a cadence, and the administrator's own rights are the most reviewed, not the least, the principle the security literature has held since its earliest statement.[4] Contact Center Security carries the WFM-specific controls, including that schedule data is personal data. Audit is the board's log joined to the platform's own configuration history, so that every change has both a decision and a technical record. Retention follows the tiers on WFM Data Governance and Quality (operational, analytical, compliance) for schedules, forecast versions and agent state events; the administration method adds only that configuration versions are retained for the life of the instance, because a configuration that cannot be reconstructed cannot be audited.

Moving further books onto the instance

After the first book, each further book moves by the runbook on Migrating a Book of Business: definitions first against the object inventory, the measurement model settled, delivered hours read, the move sized as a range, the phase gate, the change-control item, and files first at the boundary. The order of books is cleanest first, so that the instance's configuration is proven on books whose definitions it already holds, and the book in the middle of a migration last, once its own migration is stable. Each move is a board item; each produces a rejection log at the adapter, the list of objects whose definitions were not yet in the dictionary, which is the administration method's own backlog.

The administrator as the standard's custodian

The role the method needs is a custodian, not a configurer. The administrator holds the three objects, executes the board's decisions, keeps the release calendar with the technology function, runs the access review, and is the first person to notice that a proposed change is a method change in disguise. On the role cards of Role Cards for a Workforce Function the competency appears in every planning seat rather than in one job: a scheduler who does not know which activity code counts as available cannot read a shrinkage report. Where part of the administration is held by a vendor, the custody is contracted rather than staffed, and the board's authority over configuration is written into the agreement.

Worked example

The series example's function runs two instances of the short-term WFM engine [A], one for each of two heritages, with a third heritage's books planned by hand. On Day 3 afternoon, Wednesday 22 April 2026, the room opens SP-004 and chooses the fresh-instance strategy on the three reasons above. On Day 4 morning D-13 chooses a clean book for the instance, not the migrating corporate client book, and D-14 puts a seat against the program. The platform instance charter is the sixth of the six foundations in the front-load that runs to Tuesday 30 June 2026; by that date the configuration standard is written from the Standard's toolset section, activity-code dictionary v1 is issued against the register's shrinkage entry, and the release calendar is agreed with the technology function, dated Friday 29 May 2026 [A]. The first book is live on the instance in the example's Q2 2027 (proposal); the migrating book moves last, after its own next phase has passed the phase gate at the June cycle's lock, Tuesday 9 June 2026. The board's first log entry is the instance's own creation.

The artifact this page produces

The sub-plan shell (SP), one row for administration. One filled example row:

ID Sub-plan Owner (seat) First three deliverables Depends on (build-order step) Measure Quarter
SP-004 Administration The program seat for the fresh instance; the change-control board as configuration owner The configuration standard written from the Standard's toolset section (by Tue 30 Jun 2026); activity-code dictionary v1 and the release calendar agreed with the technology function (Fri 29 May 2026); the first clean book live on the instance (Q2 2027, proposal) Step 1 (the register as the instance's data dictionary); step 2 for the plan of record the instance feeds Method changes through the board (all of them); books on the instance by quarter; access reviews completed on cadence; adapter rejections closed Q2 2026 to Q3 2027 (the example's quarters)

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 page claims that inherited configurations cannot be reconciled in place without becoming a fresh configuration, and that a fresh instance built to the Standard with a clean first book is the faster route to one configuration. The observation that would overturn it is a multi-heritage estate that reconciled two or more instances' activity codes, skills and pools in place, under change control, and produced cross-node reports on one definition within a planning year, with no fresh instance. If that estate exists, the instance strategy is a choice between two workable routes and the page should present it as one.

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. One configuration under a change-control board is Level 2 work on the WFM Labs Maturity Model™, and the condition Level 3 presupposes, because intraday automation acting on two definitions of a state acts on a fiction. The fresh instance with the register as its data dictionary and file adapters at its boundary is the Level 4 form, the "one data core and one set of definitions" the technology journey names; the administration method does not change between levels, only the number of things it holds.

See Also

References

  1. ↑ DAMA International (2017). DAMA-DMBOK: Data Management Body of Knowledge (2nd ed.). Technics Publications. ISBN 978-1-63462-234-9.
  2. ↑ AXELOS (2019). ITIL Foundation: ITIL 4 Edition. The Stationery Office. ISBN 978-0-11-331607-6.
  3. ↑ Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley. ISBN 978-0-321-60191-9.
  4. ↑ Saltzer, J. H., & Schroeder, M. D. (1975). "The Protection of Information in Computer Systems". Proceedings of the IEEE 63(9), 1278–1308. doi:10.1109/PROC.1975.9939.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Systems_Administration_for_WFM_Platforms&oldid=4735"