Harlow and Vane: Twelve spreadsheets and a cloud proposal
Harlow and Vane operates 140 fashion stores plus an online channel. Its on-premise ERP was heavily customised in 2011 and is supported by a single external contractor who is now semi-retired. Store managers maintain 12 recurring spreadsheets that reconcile stock, sales and promotions outside the system; three of them feed directly into the board pack. Month-end close takes 14 days. Stock accuracy is 92% against a 98% target, and last quarter's stock write-off was 2.3 million pounds. The IT director proposes a 2.1 million pound, three-year migration to a cloud ERP with standard processes, which would eliminate most of the spreadsheets. The finance director is sceptical, noting that the last two system projects overran, and that the business has no documented data definitions and no named owner for product or supplier records.
1. Explain why the spreadsheet population is a symptom rather than a cause, and what risks it creates.
Read the worked answer
Diagnosis. Twelve recurring spreadsheets with three feeding the board pack is not evidence of sloppy habits; it is evidence that the ERP cannot answer the questions the business actually asks. A system customised 15 years ago encodes 2011 processes. Where the system cannot produce a trusted number, capable people build their own. The spreadsheets are the organisation solving a problem the system creates.
Risks this creates:
- Key-person and continuity risk. One semi-retired contractor understands the system, and each spreadsheet has an unrecorded author. Both can walk out.
- Integrity risk. No version control or audit trail; a formula change in a board-pack file is invisible and unchallenged. Three uncontrolled files are feeding decisions on stock and margin.
- Inconsistency. Different spreadsheets will use different definitions of a sale, a return or a promotion, so the board may be reconciling numbers that are not comparable.
- Data protection. Store-level files with staff or customer data outside controlled systems is a compliance exposure.
- Cost and inertia. The 14-day close and 2.3 million pounds of write-off are where the workaround becomes expensive, and the effort spent maintaining it is effort not spent fixing the cause.
Implication. Removing the spreadsheets without removing the need is not a fix.
2. Evaluate the cloud ERP proposal, identifying what must happen before and alongside the migration.
Read the worked answer
Case for. Standard processes reduce customisation, which is where the current cost and rigidity come from. A subscription model replaces capital spend with operating cost, removes the single-contractor dependency, embeds controls and audit trails, scales with the online channel, and creates a route to a faster close.
Case against, and it is strong. The 2.1 million pounds is the visible cost; migration, data cleansing, parallel running, training and the productivity dip are not in it. Exit costs and vendor lock-in are real for a subscription model holding product and supplier master data. The last two projects overran, which is evidence about delivery capability, not about cloud.
The central judgement: this is a data and process problem being solved with technology. With no data definitions and no named owners, a new system will generate the same wrong stock figure faster, and users will rebuild the spreadsheets inside a month.
Preconditions:
- Define and cleanse product and supplier master data, with named owners and stewards accountable for quality.
- Map current processes and decide deliberately which are genuinely differentiating and which should be standardised.
- Establish a baseline for stock accuracy, close days and write-off so benefits can be measured.
- Appoint a project board with finance, not just IT, accountable, and phase the migration (finance and stock first, promotions later).
- Contract explicitly for exit, data extraction and service levels.
Verdict. Approve in principle, conditional on the data and process work being completed and funded first.
3. The finance director asks whether the 12 spreadsheets should simply be banned. Advise.
Read the worked answer
Do not ban them outright. A ban removes a control without replacing the need it serves. The plausible response is that managers move the files to personal cloud storage or email, where the business can see them even less. That converts a visible risk into an invisible one, and worsens the data protection position.
Do this instead, in sequence:
- Inventory and classify. List every recurring file, its author, its purpose, its users and whether it touches personal data. This is cheap and will reveal that several files duplicate each other.
- Distinguish need from habit. Some files exist because the system genuinely cannot do the job; those must be retained and controlled until functionality is delivered. Others are habit and can go now.
- Control what remains. A short spreadsheet policy: named owner, version control, restricted access, no personal data, documented logic, and review before the file feeds the board pack. Three files becoming properly controlled is a realistic win.
- Retire on delivery, not on decree. Each file gets a date tied to a system capability, so the ban happens as the alternative arrives.
The point to make to the CFO. The spreadsheets are a symptom of an unmet information need. The right measure of progress is a falling count of files with a named owner and a retirement date, not a compliance edict that drives them underground.