Interrogating the model, not the demonstration

What is actually on the market

You cannot judge a planning system by watching somebody demonstrate it. A demonstration runs on tidy invented data. Nothing has been reorganised, no shop opened halfway through a year, and the calendar behaves itself. This lesson replaces the demonstration with questions, which turn out to be about your own records. It also replaces it with rehearsals: you break your test data on purpose, before anybody can be hurt by it.

Start with capabilities, not products. Where one capability ends and the next begins differs by vendor. Several usually arrive bundled together, and the bundling changes every year. What does not change is that a retailer needs these jobs done, and needs to know which system does each one.

The row that catches people is the last one in the first table. Reporting owns no number. A reporting tool that appears to disagree with the planning system is never disagreeing about a fact. It is applying a different hierarchy version, a different calendar alignment or a different definition of comparable. Chasing the difference inside the reporting tool is chasing it in the one place it cannot be.

Thirteen questions, and every answer is about your data

A demonstration runs on the vendor's data. That data has one hierarchy, no restatements, no store openings and a clean calendar. Yours has none of those properties.

So take these to any vendor, in this order, and write the answers down.

1. What grain does each measure store at, and can I set it per measure? A system that holds everything at one grain is either wasting storage or losing detail, and you will find out which in year two.
2. Can the product hierarchy be effective-dated? That is: can the system hold that Padded belonged to Coats until a date, and to Padded after it?
3. If I move a subclass to a new parent, can I still see last year both ways? As it was reported then, and as it would be reported under today's tree. If only one, which, and can I choose?
4. Where does a size curve live, and at what product and location level can I hold it? Ask for the finest level. Then ask what happens when a subclass has too little history to support it.
5. Where does the store share live, and how is it worked out for a store with a partial year?
6. What are the mandatory fields on a store, and is an opening date one of them? If it is optional, what does the system assume when it is blank?
7. How is like-for-like defined, can I see the definition, and can I change it? Ask specifically how it treats a store that opened mid-period, a store that closed, and a store shut for a refit.
8. What calendar do you support, and what happens in a 53-week year? Ask which week last year is lined up with week 1 this year, and who decides.
9. When intake moves a week, what moves with it? The open-to-buy should. Ask to see it.
10. What is the audit trail on a plan number? Who changed it, from what, when, and can I read that back a year later.
11. How does a plan reconcile to the ledger, at what level, and how often? If the answer is "at department level", ask what would have caught a class moving to a new parent.
12. What can two people do at once? Working at the same time is the thing a spreadsheet cannot do, and the thing that is never demonstrated.
13. What happens when a hierarchy changes? What has to be recomputed, and does the system tell me? This is question 2 asked from the other end. It is the one that separates a system that models time from one that only stores it.

Four tests, drawn from four real faults

A migration test plan is not a list of screens to click. It is the list of things that have gone wrong for other people, rehearsed on purpose in your own data before it matters.

Test one, the leaf tie-out. The leaf is the lowest level in a hierarchy. Reconcile last year to the ledger at every subclass, region and week. Merrowby's plan is 780 cells. That is a morning's work, and it is the whole of the difference between the sign-off that passed and one that would have caught fault one. A tie-out at department level tests addition. A tie-out at the leaf tests the migration.

Test two, the restatement test. Move one subclass to a new parent in the test system, on purpose. Then ask for last year, at class level, both ways. Three outcomes are acceptable. It gives you both and labels them. It gives you one and tells you which. Or it gives you one and you have written down which. The unacceptable outcome is the one Merrowby had: it gives you one, silently, and nobody in the building can say which.

Test three, the location test. Open a shop mid-season in the test data, close another, and shut a third for three weeks. Then check three separate things, because they fail separately. That like-for-like excludes all three correctly. That each store's weekly rate is worked out over the weeks it actually traded. And that the allocation share for the new shop is not built from a history it does not have.

Test four, the profile test. Change one subclass's size curve and prove the other subclass's did not move. Then change the class's and prove that both subclasses did. This sounds trivial. It is the test that finds a system holding your curves one level above where you think they are.

Add a fifth if your comparison window crosses one. Run a year-on-year report over a 53-week year and see, without being told, which week the system lined up with which.

Who owns the hierarchy

After go-live, every fault in lesson 2 becomes a governance question rather than a project question. Four things need a named owner, a change window and a restatement rule.

The last row closes the loop from lesson 1. A profile is data with a shelf life. Give every one of them a computed-on date and a hierarchy version. Put the list somewhere a person can read it. Then a class moving to a new parent stops being a silent event.

The honest case for the spreadsheet

A course that only argued one way would be selling something.

What a spreadsheet does better, genuinely:

• The model is visible. A planner can read the formula in the cell. In a system, the same logic is a setting three menus deep that four people know about. The day one of them leaves, the business owns behaviour nobody can explain.
• It is instant to change. That makes it the right tool for a question nobody has asked before, and every good season contains one.
• It costs nothing to try a shape before you commit to it. Model the new hierarchy in a spreadsheet first. It is cheaper to find out there that you needed a Padded class.

Where it stops, and it stops hard:

• It enforces no grain. A cell holds whatever is typed in it. So a subclass row and a class row can sit in the same column with nothing to say they are different levels.
• It keeps no history of who changed what. A number that moved between Tuesday and Thursday has no author.
• It cannot be read by two people at once without a convention that nobody follows past week 4.
• It never refuses. This is the real one. A planning system rejects a plan at the wrong grain. A spreadsheet accepts it, sums it, formats it and prints it. Every fault in lesson 2 began as a number that a spreadsheet was perfectly happy with.

The end state most retailers actually want is both. The system as the record of the plan, and a spreadsheet beside it for the question that has not been asked before. What must never happen is the reverse: the real plan living on a laptop while the system holds a copy that is updated when somebody remembers.

Act as a retail systems buyer who has been through a bad migration and is not going through another. Turn my own data model into a question set and a test script, so a demonstration is run on my problems rather than the vendor's data. My model: product hierarchy [PASTE, LEVEL BY LEVEL], location hierarchy [PASTE], calendar [WHAT IT IS], measures and the grain each is held at [PASTE]. My history of change: hierarchy changes in the last three seasons [LIST], stores opened, closed or refitted [LIST WITH DATES], calendar changes including any 53-week year [LIST]. What I plan to do next: [ANY RESTRUCTURE, NEW COUNTRY, NEW CHANNEL, GRADE REDESIGN]. Do the following. First, give me a question list in the order I should ask it, covering at minimum: the grain each measure is stored at and whether I can set it per measure; whether the hierarchy can be effective-dated; whether last year can be shown both as reported then and as it would be under today's tree; the level at which size curves and store shares are held; whether an opening date is a mandatory field and what a blank one means; how like-for-like is defined and whether I can see and change the definition; what happens in a 53-week year; what moves when intake moves a week; the audit trail on a plan number; the level at which the plan reconciles to the ledger; and what two people can do at once. For each question, tell me what a good answer sounds like, what a bad answer sounds like, and what a dangerous answer sounds like. Second, write me a test script the vendor must run in front of me on MY data, containing at least: a leaf-level tie-out of last year to my ledger; a deliberate move of one subclass to a new parent, followed by a request for last year both ways; a mid-season store opening followed by a like-for-like and an allocation share; and a change to one subclass's size curve to prove another's did not move. Third, tell me which of my planned changes each test protects me from. Fourth, list the things I should write into the contract or the configuration record because the system will not enforce them: who owns each hierarchy, when it may change, and what must be recomputed when it does. Do not name or rank any product, and do not tell me what other retailers do. If a question does not apply to my model, drop it and say why.