The plan of record
The plan of record is the single, versioned set of numbers — line plan, assortment, buy, purchase orders, WIP and in-season position — that every function reads and changes through one controlled path. It is one object, not a file per team: merchandising, planning, buying, production and allocation each write their own part of it, and a change anywhere is a new version of the same plan rather than a new copy of it. A brand either has a plan of record, or it has several plans, each accurate to its owner and none of them authoritative.
This essay is the keystone of a series. The apparel data model describes the structure a season’s numbers live in; the handoff problem describes what happens when those numbers move between functions; the operating cadence describes what happens when they move between clocks. All three assume there is one set of numbers to move. This one is about that set — what it must hold, who may change it, how it is versioned, and why it is the concept that separates an operating system from a stack of tools.
- The plan of record is the single, versioned set of numbers — line plan, assortment, buy, purchase orders, WIP and in-season position — that every function reads and changes through one controlled path.
- Copies drift by mechanism, not negligence: export-and-edit gives each function a private version, each version stays accurate to its owner, and the reconciliation meeting inherits the question of which file is right.
- Each decision has one pen. Merchandising writes the line, planning writes depth and open-to-buy, buying writes the purchase order, allocation writes the door split — and every other function reads.
- A plan of record is versioned rather than copied: an approved version for what was signed off, a change history for who moved what from which value, and an approval wherever a locked number changes.
- ERP remains the system of record for transactions and PLM for product. The plan of record holds the decisions between them — and gives the working delivery date a home it has nowhere else.
- A merchandising operating system is defined by having one plan of record, not by its module count, and the rule holds across all ten range-planned verticals with a different unit of the plan in each.
Six layers, one plan
The plan of record is not a new document. Its layers are numbers a planning organization already produces; what makes them a record rather than a collection is that each layer is derived from the one above it and read by the one below, on one structure, with one version current at a time. The six layers follow the season from the commitment of intent, through the commitment of cash, to the position the season is actually in.
Option count by category and delivery, price architecture, carryover against newness, and the sales and margin targets the range is built to deliver. The layer that says what the range is before anything is bought — and the one every later layer inherits its structure from.
The style-colors adopted into the range, placed by channel, door cluster and delivery. The layer where intent becomes a list: which style-color exists, where it will sell, and which role it plays — margin engine, traffic driver, price anchor.
Units by style-color, the size curve beneath them, the delivery phasing, and the open-to-buy each buy consumes by month. The layer that commits cash in principle — the number every vendor conversation starts from.
The orders as placed and as amended: quantity by size, cost, ship date and vendor. ERP owns the order itself; the plan of record carries what the order committed, so open-to-buy nets it and the receipt plan follows it.
The working state of each order between placement and receipt — the date the factory will actually ship, the approvals still open, the quantity at risk. The layer with no natural owner in a disconnected stack, and the one allocation depends on before goods land.
Sales, receipts and stock by style-color against plan at the same week of life, with the forward cover and remaining open-to-buy that follow. The layer the trade meeting reads — and the one every chase, cancel and markdown writes back into.
Two boundaries keep the definition useful. First, the plan of record is not the system of record for everything: a purchase order is created and owned in ERP, a style in PLM, a sale in the commerce platform or the POS. The plan of record holds the commercial decision each of those objects carries — the buy behind the order, the depth behind the style, the forecast the sale is read against. Second, a scenario is not the plan of record. A planning organization should run as many scenarios as a decision needs; the plan of record is the one version the business has agreed to execute against, and a scenario becomes part of it only by being approved into it.
- Definition — Plan of record
- The plan of record is the single, versioned set of numbers — line plan, assortment, buy, purchase orders, WIP and in-season position — that every function in an apparel company reads and changes through one controlled path. Each decision in it has one owner who may write it while every other function reads it, and the in-season position is written by sales and receipts rather than by a person; every committed change creates a new version with a recorded author, time and prior value; and a number locked at one stage moves only through an approval. It holds the commercial decisions between the system of record for product (PLM) and the system of record for transactions (ERP), and a stack of tools becomes an operating system when it keeps one plan of record instead of a copy per function.
- Used by: Merchandising, planning, buying, production, allocation, finance and technology leaders deciding which numbers the business executes against and who may change them
- Related: Apparel data model, handoff, operating cadence, decision rights, system of record, planning grain, open-to-buy, apparel operating system
Export, edit, reconcile: how one plan becomes four
Nobody sets out to run a season on four versions of the buy. The versions arrive by a mechanism that is reasonable at every step. The buy is agreed and exported so buying can work the vendor conversation in its own tracker. It is exported again so planning can net it against open-to-buy, and again so allocation can build door plans ahead of receipt. Each export is a copy, and each copy is edited by the function that owns it, for reasons that are correct inside that function. From the moment of export the copies are no longer the plan; they are the plan as of Monday, plus whatever each owner has decided since.
Take an illustrative style-color, not drawn from any brand, bought at 1,200 units. On Monday the buy is exported to three places. By Friday, buying has cut the purchase order to 1,000 units against a fabric shortfall at the mill — the right call, entered in the PO tracker. Planning, not copied on the vendor email, still consumes 1,200 units against open-to-buy; at an illustrative landed cost of 12.00, that is 14,400 of open-to-buy shown as committed against 12,000 actually on order, so 2,400 of spendable money looks spent. Allocation has built door plans for 1,200 units at 30 units across 40 doors; 1,000 units arriving means 25 per door, or 30 per door across 33 doors with 10 units left over. Three files, two quantities, and not one of them contains an error.
The reconciliation meeting is the organization’s response, and it is structurally a losing one. When it is scheduled against the calendar rather than against the decision, it lands after the chase, the cut or the allocation it should have informed. It opens by establishing which version of the number each attendee brought. And because every copy is defensible, the meeting cannot settle the difference by finding the mistake — there is no mistake to find. It settles it by authority: whoever is most senior, or most certain, names the number, and the other files are corrected by hand until the next export starts the drift again.
This is the “which file is right” problem, and the question is malformed. Every file is right about the decision its owner made; none is right about the season, because the season is the combination of all of them and no file holds the combination. The handoff problem names the mechanisms at work — translation, latency and ownership ambiguity — and the operating cadence adds the clock each copy was refreshed on. The plan of record removes the malformed question by removing the copies: buying’s cut is an amendment to the one buy, which planning’s open-to-buy nets and allocation’s door plan reads, in the same moment and without an export.
What the plan of record holds at each stage, and who holds the pen
A plan of record needs two rules for every layer: what it must hold by the time the stage closes, and who may write it. Holding is a completeness question — a buy that has units but no size curve is not ready to become a purchase order. Writing is an authority question, and it has exactly one answer per field. Everyone reads the whole plan; one owner writes each part of it. The table uses the owners the decision rights map assigns, and extends it to the assortment and the working delivery date, because the pen is simply a decision right expressed as write access to the record.
| Stage | What the plan of record must hold | Who holds the pen | What may change after lock, and how |
|---|---|---|---|
| Line plan | Option count by category and delivery, price architecture, the carryover list, and the sales and margin targets inherited read-only from the MFP | Merchandising | Option count and carryover move at line review, as a new version with the change recorded; the targets are read-only here and move only on the annual clock |
| Assortment | Adopted style-colors by channel, door cluster and delivery, each with its role in the range | Merchandising, with planning consulted on channel placement | Adds and drops after lock pass through an approval that shows the open-to-buy and depth they consume |
| Buy | Units by style-color, size curve, delivery phasing, open-to-buy consumed by month, channel split | Planning for depth, size curve, open-to-buy and channel split; merchandising for delivery phasing | After buy approval, depth and curve changes are proposed and approved by planning until placement; after placement a change is a purchase order amendment, not a buy edit |
| Purchase orders | The committed quantity by size, cost and ship date per vendor, netted against open-to-buy | Buying — placement and every amendment | Amendments are written once, by buying, and re-phase the receipt plan in the same change; ERP remains the record of the order itself |
| WIP | The working ship date, open approvals and quantity at risk for each order in production | Buying, as the amendment owner, with production and sourcing supplying the working date | The working date moves as the factory reports; a move past a threshold agreed before the season becomes an amendment and re-phases receipts |
| In-season position | Sales, receipts and stock against plan at week of life, forward cover, remaining open-to-buy | Written by transactions, not by a person; chase is merchandising, the markdown trigger is planning, the allocation split is allocation | Actions from the trade meeting are written into the plan as dated, owned changes — chase, cancel, markdown, re-allocation |
- What the plan of record must hold
- Option count by category and delivery, price architecture, the carryover list, and the sales and margin targets inherited read-only from the MFP
- Who holds the pen
- Merchandising
- What may change after lock, and how
- Option count and carryover move at line review, as a new version with the change recorded; the targets are read-only here and move only on the annual clock
- What the plan of record must hold
- Adopted style-colors by channel, door cluster and delivery, each with its role in the range
- Who holds the pen
- Merchandising, with planning consulted on channel placement
- What may change after lock, and how
- Adds and drops after lock pass through an approval that shows the open-to-buy and depth they consume
- What the plan of record must hold
- Units by style-color, size curve, delivery phasing, open-to-buy consumed by month, channel split
- Who holds the pen
- Planning for depth, size curve, open-to-buy and channel split; merchandising for delivery phasing
- What may change after lock, and how
- After buy approval, depth and curve changes are proposed and approved by planning until placement; after placement a change is a purchase order amendment, not a buy edit
- What the plan of record must hold
- The committed quantity by size, cost and ship date per vendor, netted against open-to-buy
- Who holds the pen
- Buying — placement and every amendment
- What may change after lock, and how
- Amendments are written once, by buying, and re-phase the receipt plan in the same change; ERP remains the record of the order itself
- What the plan of record must hold
- The working ship date, open approvals and quantity at risk for each order in production
- Who holds the pen
- Buying, as the amendment owner, with production and sourcing supplying the working date
- What may change after lock, and how
- The working date moves as the factory reports; a move past a threshold agreed before the season becomes an amendment and re-phases receipts
- What the plan of record must hold
- Sales, receipts and stock against plan at week of life, forward cover, remaining open-to-buy
- Who holds the pen
- Written by transactions, not by a person; chase is merchandising, the markdown trigger is planning, the allocation split is allocation
- What may change after lock, and how
- Actions from the trade meeting are written into the plan as dated, owned changes — chase, cancel, markdown, re-allocation
Two things in the table do more work than they appear to. The pen moves as the season moves: planning writes a style-color’s depth, and the moment the buy is placed that quantity belongs to buying, because a placed number is a commitment to a vendor, and only the person who made the commitment may change it. A plan of record makes that transfer a change of write access on the record rather than a document handed across a desk. And the in-season position has no human pen at all. Sales and receipts write it; what people write into it are decisions — the chase, the cancel, the markdown — each of which the decision rights map assigns to one owner and the operating cadence assigns to one clock.
The lock is the other half. A layer its owner can edit at any time is a draft, not a record. Each stage closes with a lock — the line adopted, the buy approved, the order placed — after which the layer still changes, because seasons do, but it changes by a different path: a proposed change, visible to every function that reads the layer, approved by the owner of the number it moves. The lock does not slow an owner down before the stage closes. It makes a change after close visible, which is what every downstream function needs and what an emailed workbook cannot provide. Which level of the hierarchy each locked number sits at is the question the planning grain answers.
Versioning, change history and approvals
Versioning is what makes a plan of record possible without making it rigid. A file-based plan has two options when something changes: overwrite the number and lose what it was, or save a copy and start the drift. A versioned plan does neither — every committed change creates a new version of the same plan, so the current number and every prior number coexist in one place, attached to the same style-color, the same delivery and the same channel. “What did we approve?” and “what are we executing now?” have different answers, and both can be answered without opening an archive folder.
Three kinds of version carry the weight. The approved version is what the business signed off at each stage close — the adopted line, the approved buy — and it is the baseline every later number is measured against; a season-end hindsight compares against it rather than against the latest reforecast. The working version is the plan as it stands this week, after every amendment, chase and cancel. The scenario is a candidate version: a what-if on depth, phasing or a markdown path that any function may build and none may execute until it is approved into the working version. Keeping the three apart is what lets a planner model aggressively without the model leaking into a purchase order.
Change history is the version trail at field level: who changed the number, when, from which value to which, and — the field a spreadsheet has no place for — why. The why is what the post-season review needs. The illustrative buy above going from 1,200 to 1,000 units is an unexplained variance on a report; the same change carrying “fabric shortfall at the mill, substitute offered at a later ship date, declined” is a decision the brand can learn from. History turns a variance into a decision with an owner, which is the only form in which a season can be hindsighted rather than retold.
Approvals are the controlled path itself. A change inside an owner’s authority is written directly and recorded; a change that moves a locked number, or crosses a threshold agreed before the season, is proposed and approved. The thresholds are the ones the operating cadence sets per clock — the markdown depth the trade meeting may take without the seasonal owner, the receipt slip the monthly forum may absorb, the variance the season may carry before the annual number is re-set. An approval step earns its delay only where the change consumes something another owner is accountable for: open-to-buy, margin, a vendor commitment, a floor set. Everywhere else it is friction, and friction is how copies start again.
Score how far your season is from one plan of record
Everything above can be checked against your own season. The operating model assessment scores six seams from 1, disconnected, to 4, connected — among them whether teams work from one shared version of the season or many copies, and whether open-to-buy stays aligned with the assortment and the actual buy. The assessment page is complete without a download.
The workbook is the same assessment in Excel, for scoring with the teams on either side of each handoff: a column for the evidence behind each score and an owner per dimension, the total out of 24 with its band, and your two lowest dimensions carried into a plan with owners and dates. It is a directional diagnostic, not a benchmark against other brands.
The plan of record beside ERP and PLM
An apparel stack already has systems of record, and the plan of record does not compete with them. PLM is the system of record for product; ERP is the system of record for transactions. Each is authoritative for its own objects, and the system of record matrix assigns those objects one by one. What neither holds is the set of commercial decisions that connects them — how many options the line carries, how deep each style-color is bought, how the buy is phased, and where the season stands against all of it. That is the gap the plan of record fills, and the direction of flow at each boundary is what keeps it from becoming a third writer on someone else’s object.
| Record | Authoritative for | What the plan of record reads from it | What the plan of record sends to it |
|---|---|---|---|
| PLM | The style, colorway, bill of material, size scale, target and quoted cost, development calendar | The styles that exist, the sizes each can run in, the costs the margin plan is built on | The option count and adopted style-colors the line commits development to |
| ERP | The purchase order, landed cost, invoice, company inventory position, wholesale account | Commitments as placed, confirmed dates, receipts, realized landed cost | The proposed buy by style-color and size, which becomes a purchase order when ERP creates it |
| Commerce platform, POS and WMS | The sales transaction, physical stock movement, stock by location | Sales, returns and stock by location for the in-season position | The allocation and replenishment decisions that tell stock where to go |
| The plan of record | The line plan, assortment, buy, open-to-buy, size curve, delivery phasing and the working delivery date | Everything above, read-only | Decisions, each written once by its owner |
- Authoritative for
- The style, colorway, bill of material, size scale, target and quoted cost, development calendar
- What the plan of record reads from it
- The styles that exist, the sizes each can run in, the costs the margin plan is built on
- What the plan of record sends to it
- The option count and adopted style-colors the line commits development to
- Authoritative for
- The purchase order, landed cost, invoice, company inventory position, wholesale account
- What the plan of record reads from it
- Commitments as placed, confirmed dates, receipts, realized landed cost
- What the plan of record sends to it
- The proposed buy by style-color and size, which becomes a purchase order when ERP creates it
- Authoritative for
- The sales transaction, physical stock movement, stock by location
- What the plan of record reads from it
- Sales, returns and stock by location for the in-season position
- What the plan of record sends to it
- The allocation and replenishment decisions that tell stock where to go
- Authoritative for
- The line plan, assortment, buy, open-to-buy, size curve, delivery phasing and the working delivery date
- What the plan of record reads from it
- Everything above, read-only
- What the plan of record sends to it
- Decisions, each written once by its owner
The purchase order is where the boundary is tested, because it is the one object both sides touch. Planning proposes the buy; ERP creates and owns the order; what returns is not an edited buy but a commitment and a confirmed date — ERP’s objects, which the plan of record reads so that open-to-buy nets what is on order. The failure to avoid runs in both directions: the plan accepting edits to an order’s quantity that never reach ERP, or ERP amendments that never reach the plan. Either one gives the order two writers, and an object with two writers has no system of record — the rule the matrix is built on applies to the plan of record as strictly as to anything else.
One object has no occupant in a disconnected stack at all: the working delivery date. ERP holds the date the order promised and the factory holds the date it will ship; the current best estimate lives in vendor email while the plan phases receipts against a date that stopped being true. The plan of record is the natural home for it, because it is a planning object — its consumers are the receipt plan, open-to-buy phasing and allocation — and where that date lives is a direct test of whether a stack has a plan of record or a set of reports about one.
What a merchandising operating system means in these terms
“Apparel operating system” and “merchandising operating system” are easy to read as names for a larger software bundle. In the terms of this essay they mean something narrower and more useful. A merchandising operating system is a stack in which the plan of record exists — one versioned set of numbers from line plan to in-season position, read by every function, written through one controlled path — with PLM and ERP connected to it rather than duplicated inside it. A stack of tools, however capable each tool is, is a set of systems that each hold part of the plan and exchange copies of it.
The distinction is observable, which is what makes it worth drawing. Five questions separate the two in an afternoon. Can anyone state the current buy for a style-color, by size, without opening two files? When buying amends a purchase order, does open-to-buy change without anyone retyping it? Can the approved line and the working line be compared at style-color level? Is there a record of who moved a number, when, and from which value? Is there exactly one path by which a locked number changes? A stack that answers yes to all five has a plan of record. A stack that answers no to any of them pays for the gap in reconciliation time, late decisions and the meeting that establishes which number is real — the cost of disconnected apparel workflows.
It is also why an operating system is not measured by how many modules it carries. A suite with a planning module, a buying module and an allocation module that exchange files between them has three plans. A narrower system that holds one plan of record across the same stages has one. The definition on the apparel operating system pillar — one shared product record and plan across every stage — is the same claim made from the product side; the plan of record is the claim made from the numbers.
How the plan of record holds across verticals
Apparel is the flagship case, and its plan carries every layer — style-color by size by delivery by channel — with each layer still changing after lock. The definition does not depend on apparel. What changes by vertical is the unit of the plan and the layer that moves after lock; the rule that one versioned set of numbers is read by every function and changed through one path holds across apparel, footwear, accessories, home and furniture, outdoor, sporting goods, beauty and wellness, toys and games, baby and juvenile, and jewelry and watches.
Apparel
The unit of the plan is the style-color by size, delivery and channel; kidswear plans on the same structure with an age-based size scale. After lock, the size curve and delivery phasing keep moving: purchase order amendments slip ship dates and re-phase receipts, chases and cancels change depth on the styles the season is reading, and the channel split shifts when wholesale bookings land against a DTC forecast. Each of those is a layer another function reads.
Footwear
The unit is the style-color by size run and width, counted in pairs. Prebooks commit pairs before the season is readable, so the buy locks early, and what moves after lock is prebook conversion into orders, the width mix, and the fill of each size run as receipts arrive. A broken size run is a WIP problem and an in-season problem at once: the plan has to show which sizes are short on order before an allocation spreads the gap across doors.
Accessories and bags
The unit is the style-colorway, and bags and small leather goods carry no size curve at all. Fashion colorways carry the seasonal bet while hero colors and the evergreen core carry replenishment, so one structure holds two rhythms. After lock, colorway mix moves against material already committed, because leather, hardware and trim are bought in lots ahead of the finished-goods buy, and attach rate read in-season changes the core depth the plan must net against those lots.
Home and furniture
The unit is the item by option — fabric, finish, configuration — bought in container quantities against a landed cost. Ocean lead times stretch the WIP layer across months, so after lock it is receipt timing and landed cost that move: a container misses a sailing, freight moves the cost the margin plan assumed, a consolidation changes which options arrive together. Special orders sit beside stocked items, and the plan must keep them apart so a special order never consumes stocked open-to-buy.
Outdoor
The unit is mixed within one line plan: soft goods by style-color and size, hard goods by model and spec. Model years set when hard goods change, dealer prebooks commit units ahead of the season, and counter-seasonal categories — snow against summer — keep two seasons open at once. After lock, prebook conversion and technical-material lead times move the plan, while MAP bounds how far a markdown decision can move price in the dealer channel.
Sporting goods
The unit is the model-year SKU for hardgoods and the style-color by size for softgoods, planned against team and season demand. Dealer prebooks and team orders commit quantities before the season opens, and the model-year changeover decides when carryover becomes closeout. After lock, the purchase order layer takes the movement: spec refreshes, team-order revisions and the timing of the model-year cut all amend orders the plan has already netted, and each amendment must re-phase receipts in the same change.
Beauty and wellness
The unit is the shade within a franchise — the beauty analogue of a size — alongside launches, testers and gift-with-purchase units that draw on the same budget. PAO and shelf life put a date on depth: a buy too deep for its dating can end as a write-off rather than a markdown. After lock, launch quantities and shade-level depth on core replenishment move, and where a brand sells through retailers, retailer POS writes the in-season position, so the plan must read shade-level sell-through by door.
Toys and games
The unit is the item by retailer commitment, planned against Q4 concentration, with licensed windows fixing when a property can sell at all. Safety standards gate the WIP layer: an item that has not passed testing does not ship, whatever the order says. After lock, the retailer commitment itself moves — revised quantities and dates against a Q4 that cannot move — so the plan must carry commitment, order and test status on one item, and re-plan receipts before the retailer’s window closes.
Baby and juvenile
The unit is the hard-goods model by model year — car seats, strollers, nursery furniture — with registry demand signalling ahead of the purchase. Safety standards and recalls put a stop condition on the plan: a recall or a standards change can stop a model mid-season, and every open order, in-transit unit and allocation against it must be visible at once, while certification, lot and serial traceability stay in the ERP and quality systems. After lock, the model-year changeover moves the plan, because the new model’s landing date decides how much outgoing stock the plan still needs.
Jewelry and watches
The unit is the piece, and in higher-value categories inventory is tracked piece by piece rather than as a quantity. Metal cost moves feed straight into planned margin, memo and consignment place inventory in locations the brand does not own, and where velocity is low, one piece in the wrong store is a material share of a style’s position. After lock, cost and location move: a metal move re-prices open orders, and memo placements and returns change the position without a sale.
The unit changes; the rule does not. Wherever one function moves a layer and another reads it stale, the damage has the same shape, and the plan of record removes it the same way. The vertical treatments live on the flagship: apparel, footwear, accessories and bags, home and furniture, outdoor, sporting goods, beauty and wellness, toys and games, baby and juvenile, and jewelry and watches. When you cannot chase takes up the categories where a long lead time or a fixed retailer window leaves the in-season layer no chase to pull.
Why the plan of record is the keystone
Read back through the series and the plan of record is the object each essay was describing from one side. The data model is its structure: the hierarchy and grain its numbers live at. The handoff problem is what happens to it between functions when it exists as copies. The operating cadence is what happens to it between clocks, and the decision rights map and the planning grain say who may change each number and at what level. Without a plan of record each of those is a discipline someone has to remember; with one, each becomes a property of the record — the grain is the structure, the handoff is a state change, the freeze is write access, and the owner is the pen.
What the record does not settle is worth saying plainly. It does not choose the owner of each layer; that is an operating-model decision, and a plan of record with two people holding the pen to the buy has two writers however good the software is. It does not set the lock points or the approval thresholds; people set them, before the season, and revisit them when a new channel or a new vertical changes the inputs. And it does not supply restraint. A plan of record breaks when someone with write access changes a locked number directly because that is easier than asking. The record makes it visible, with a name and a time. It cannot make it unthinkable.
The practical starting point is the layer with the most copies in your own stack, so count them. Where the buy lives in four files, start there: make one version authoritative, make every other a read-only view of it, and route every change through its owner. The operating model assessment shows where a brand stands, and the implementation playbook sequences the move one seam at a time. The plan of record is the destination both describe.
- Start the series — the apparel data model →
- See the plan move between functions — the handoff problem →
- See the plan move between clocks — the operating cadence →
- See who holds the pen for each decision — the decision rights map →
- See which system owns each object — the system of record matrix →
- See the level each locked number sits at — the planning grain →
- Read the apparel operating system definition and pillar →
- Sequence the move onto one record — the implementation playbook →
Frequently asked questions
- What is a plan of record in apparel planning?
- The plan of record is the single, versioned set of numbers — line plan, assortment, buy, purchase orders, WIP and in-season position — that every function in an apparel company reads and changes through one controlled path. Each decision in it has one owner who may write it while every other function reads it, and the in-season position is written by sales and receipts rather than by a person; every committed change creates a new version with a recorded author, time and prior value, and a locked number moves only through an approval. It is one object rather than a file per team, which is what lets merchandising, planning, buying and allocation work on the same season instead of on copies of it.
- Why do copies of the merchandise plan drift apart?
- Because export-and-edit is reasonable at every step. The buy is exported so buying can work the vendors, again so planning can net open-to-buy, and again so allocation can build door plans, and each copy is then edited by its owner for reasons that are correct inside that function. From the moment of export no copy is the plan; each is the plan as of the export plus its owner’s later decisions. The reconciliation meeting then tries to establish which file is right, but every file is right about its own decision and none of them holds the season.
- Who should hold the pen on each layer of the plan?
- One owner per decision, taken from the decision rights for that stage. Merchandising writes the line plan, the assortment and delivery phasing; planning writes depth, the size curve, open-to-buy and the channel split; buying writes purchase order placement and every amendment; allocation writes the door split. Everyone reads the whole plan. The pen moves as the season moves — once a buy is placed, its quantity belongs to buying, because a placed number is a vendor commitment and only the person who made the commitment may change it.
- How are versioning and approvals different from saving copies?
- A saved copy is a second plan that starts drifting the moment it exists. A version is a new state of the same plan, attached to the same style-color, delivery and channel, with the prior state kept beside it. A plan of record carries three kinds: the approved version signed off at each stage close, the working version after every amendment, and scenarios that anyone may build but nobody may execute until they are approved into the working version. Approvals are the controlled path for changes that move a locked number or cross a threshold agreed before the season.
- How does a plan of record relate to ERP and PLM?
- PLM remains the system of record for product — the style, colorway, bill of material, size scale and target cost. ERP remains the system of record for transactions — the purchase order, landed cost and the company inventory position. The plan of record holds the commercial decisions between them: the line plan, assortment, buy, open-to-buy, size curve, delivery phasing and the working delivery date. It reads PLM and ERP objects rather than editing them, and it proposes the buy that ERP turns into an order, so no object ends up with two writers.
- What makes a merchandising operating system different from a stack of tools?
- A merchandising operating system is a stack in which one plan of record exists — read by every function, changed through one controlled path, with PLM and ERP connected to it rather than duplicated inside it. A stack of tools holds the plan in parts and exchanges copies of it. Five questions tell the two apart: can anyone state the current buy by size without opening two files; does a purchase order amendment change open-to-buy without retyping; can the approved and working plans be compared at style-color level; is there a record of who moved each number; and is there exactly one path by which a locked number changes.
See line planning, assortment planning, buy planning, sizing, PO and WIP tracking and allocation on one shared data model in RetailNorthstar.