1. Implementation plan and go-live readiness
Every finding is checked item by item against the pitfall rules and the WMS / LES go-live checklist: whether the plan says it, how far it goes, and who owns it. Each finding states three things: what the plan cannot yet claim, what to get from the supplier, and what counts as closed. The method notes give the rule number, what was looked at, the method used and what it cannot prove; the decision thresholds are not published.
A. Scope and contract
3 selectedA1×High riskExperience-based judgment · Pitfall L1
The charter has no assumptions section: every added requirement reopens the argument over whether it is a change
- Plan excerpt
- §1 Scope: implement per the attached feature list; duration 6 months; 1,240 person-days in total.
- Cannot be claimed yet
- That scope and duration are fixed. Response deadlines, signatories and data ownership are not written down as assumptions; once an assumption changes, nobody owns the extra person-days and time.
- Get from the supplier
- Add an assumptions section to the charter: the business side replies within an agreed number of working days, and no reply by the deadline counts as confirmation; the signatories and authorized persons; the business side is responsible for source data; out-of-scope requests go through change control. Have contract wording checked in the relevant jurisdiction.
- What counts as closed
- The section is in the charter and both parties have signed.
How this finding was found
- What was looked at
- §1 Scope and duration
- Method
- Checked against pitfall L1, the eight things to pin down at initiation: does the charter have assumptions, and does it have a change-control clause.
- Rule number
- SCP-01 Missing assumptions
- What it cannot prove
- It cannot prove the project will overrun; it only proves there is nothing to check against when a scope dispute arises.
A2!Medium riskExperience-based judgment · Pitfall L1
The 86 functions are not marked standard or custom: nobody can say how the 1,240 person-days were estimated
- Plan excerpt
- §1 Attached feature list: 86 items, 1,240 person-days in total.
- Cannot be claimed yet
- That the effort was broken down by function. Standard functions mostly cost configuration and implementation days; only custom ones consume development days. Without the marking, there is no footing for later change talks or effort checks.
- Get from the supplier
- Add a standard / custom column to every row of the feature list. For custom rows, attach the development manager's effort split by frontend, backend and interface, and enter them in the customization register.
- What counts as closed
- Every row is marked, and every custom item has a number, a requester and an effort split.
How this finding was found
- What was looked at
- Attached feature list (86 rows)
- Method
- Read row by row: is standard separated from custom, and does each custom row have its own effort basis.
- Rule number
- SCP-02 Standard/custom not marked
- What it cannot prove
- It cannot prove the estimate is too high; it only proves it cannot be checked today.
A3×High riskExperience-based judgment · Pitfall L2
ASRS scheduling is a black box, and the contract has no data return, no price for rule changes and no rule documentation
- Plan excerpt
- §1 ASRS scheduling is the equipment integrator's responsibility; WMS sends tasks down to the storage area.
- Cannot be claimed yet
- That after acceptance the factory can see location-level stock for itself and control the rules itself. Today WMS records only down to the area, the location-level book is in the integrator's hands, and neither how long a rule change takes nor what it costs is written anywhere.
- Get from the supplier
- Add three clauses to the contract: return of location-level stock and task status; lead time and charge for changing a rule; rule list, parameter tables and configuration documents delivered with the system.
- What counts as closed
- All three are in the contract or an addendum, and final payment is tied to them.
How this finding was found
- What was looked at
- The one sentence on system boundary in §1; the deliverables list in the draft contract
- Method
- Checked against pitfall L2, black box or white box: the three clauses a black-box solution must have in the contract before final payment, one by one.
- Rule number
- CTR-01 Three black-box clauses
- What it cannot prove
- It cannot prove the integrator will be uncooperative; it only proves the factory has no say after acceptance.
B. Blueprint and requirements
2 selectedB1×High riskExperience-based judgment · Pitfall L1b
The blueprint draws only 4 normal flows: not one cancellation, rollback or return
- Plan excerpt
- §2 Blueprint draft: 4 main flows, namely inbound, outbound, delivery and stocktake.
- Cannot be claimed yet
- That the blueprint is complete. Reverse flows come up only a few times a week, so nobody volunteers them during interviews; when they come up after go-live the system has no path, and the only option is asking IT to edit the data.
- Get from the supplier
- Add a chapter on reverse flows: receipt rollback, putaway cancellation, wave cancellation, short and over picks, return of over-shipments, purchase returns, task cancellation and equipment exceptions. Draw each one in the same format as the normal flows, down to the role.
- What counts as closed
- Every reverse flow has a diagram and roles, and goes through final review together with the main flows.
How this finding was found
- What was looked at
- Feature list and flow diagrams in the §2 blueprint draft
- Method
- Searched the feature list for cancel, rollback and return, then checked item by item against the pitfall L1b reverse-flow list.
- Rule number
- BLP-01 Reverse flows missing
- What it cannot prove
- It cannot prove these cases will happen; it only proves there is no path when they do.
B2!Medium riskExperience-based judgment · Pitfall L3
Requirement changes are "implemented after development assessment": the project manager is bypassed
- Plan excerpt
- §2 Requirement changes: raised by the business side, implemented after assessment by development.
- Cannot be claimed yet
- That effort and milestones are under control. Requests go straight to development with no assessment, no scheduling and no record; each looks small, but enough of them make the effort sheet wrong.
- Get from the supplier
- Every new request during development goes to the project manager first: accept or not, change or not, where it slots in, what it pushes out. Line-down emergencies may be fixed first and registered afterwards.
- What counts as closed
- The change process names the project manager as the entry point, and there is a request register.
How this finding was found
- What was looked at
- The one sentence on requirement changes in §2
- Method
- Checked against pitfall L3, requirements and effort: is the project manager the entry point, and is there an assessment and scheduling step.
- Rule number
- REQ-01 Request entry point
- What it cannot prove
- It cannot prove scope creep will happen; it only proves nobody stops it when it does.
C. Data preparation
2 selectedC1×High riskExperience-based judgment · Pitfall L6 / Checklist F1, F3, F5
"The customer supplies location master data on our template": the customer cannot fill in the 8 ASRS columns
- Plan excerpt
- §3 The customer supplies material and location master data on our template (one table).
- Cannot be claimed yet
- That location data will be collected in one round. Aisle, single or double depth, near and far end, linked locations, and putaway and picking route sequence come from the equipment layout drawings and the scheduler configuration; only the equipment supplier has them. The table comes back looking full, yet those columns are empty from top to bottom.
- Get from the supplier
- Split the table in two by who holds the information, a business table and an equipment table; settle the location coding rule first; when the tables come back, count the fill rate column by column.
- What counts as closed
- The equipment supplier provides the equipment table, it is merged with the business table by location code, and every wholly empty column is confirmed one by one.
How this finding was found
- What was looked at
- §3 Data preparation: one location table given to the customer to fill in
- Method
- Checked against pitfall L6 and checklist items F1, F3 and F5: who holds each field; flagged wherever the person filling in is not the source of the information.
- Rule number
- DAT-01 Field source
- What it cannot prove
- It cannot prove this customer is unable to fill it in; it only proves the template is not split by source.
C2×High riskExperience-based judgment · Pitfall L15
Item coding is "in progress", and the go-live date is already fixed
- Plan excerpt
- §3 Item coding: the customer's data-governance project is in progress and will finish before go-live.
- Cannot be claimed yet
- That the codes will be clean at go-live. "In progress" has no scope and no acceptance method; with the date fixed, code cleanup gets pushed past go-live, and it cannot be done after go-live.
- Get from the supplier
- Replace "in progress" with three checks: sample 100 materials at random, with zero cases of the same physical item named differently across purchasing, warehouse and production; reused old codes cleared out; unit-conversion rules entered in the system.
- What counts as closed
- The three check results are in before the go-live date is set.
How this finding was found
- What was looked at
- The one sentence on item coding in §3; the go-live date in §5
- Method
- Checked against pitfall L15, the three go-live questions: does coding have a checkable criterion, and was the date set before the check.
- Rule number
- DAT-02 Coding criterion
- What it cannot prove
- It cannot prove the codes are dirty today; it only proves nobody can tell today.
D. Interfaces, go-live and acceptance
3 selectedD1×High riskExperience-based judgment · Pitfall L13 / Checklist J3
"Standard ERP interface, 2 weeks of integration testing": no posting scenarios listed, reversals not mentioned
- Plan excerpt
- §4 WMS connects to the customer's ERP through the standard interface; integration testing takes 2 weeks.
- Cannot be claimed yet
- That 2 weeks is enough. ERP is the widest interface of all: purchase receipts and returns, transfers, material issues, stocktakes, line-side returns and more, a dozen-plus posting scenarios, each needing its reversal confirmed separately. Testing the forward posting but not the reversal is the number-one reason the books do not match after go-live.
- Get from the supplier
- A posting-scenario list, each type marked for whether it includes a reversal, used as the acceptance basis for completing integration testing.
- What counts as closed
- Every type of reversal has been run through integration testing once, with records.
How this finding was found
- What was looked at
- The one sentence in the §4 integration-test plan
- Method
- Checked against pitfall L13 and checklist item J3: are posting scenarios listed, and do they include reversals.
- Rule number
- ITF-01 Reversals
- What it cannot prove
- It cannot prove 2 weeks is too short; it only proves no scenarios are listed, so nobody can judge.
D2×High riskExperience-based judgment · Pitfall L15 / Checklist K1–K5, L2
"One-shot weekend cutover": no rollback conditions and no cutover prerequisites
- Plan excerpt
- §5 Go-live plan: one-shot cutover over a weekend.
- Cannot be claimed yet
- That a weekend cutover is safe. All five prerequisites must be met before cutting over: upstream and downstream systems go live together, the opening stocktake is done, purchasing and transfer data are in place, the work-order, quality and posting chains all run end to end, and automation equipment has passed integration testing.
- Get from the supplier
- Write down the rollback triggers, the rollback time window, and the point past which the only way is forward.
- What counts as closed
- The go-live plan contains the prerequisite checklist and a rollback plan, ticked off item by item one week before go-live.
How this finding was found
- What was looked at
- The cutover approach in the §5 go-live plan
- Method
- Checked against checklist items K1–K5 and L2: is each prerequisite written down, and do rollback conditions exist.
- Rule number
- GOL-01 Rollback
- What it cannot prove
- It cannot prove the cutover will fail; it only proves there is no way back if something goes wrong.
D3!Medium riskExperience-based judgment · Pitfall L17
Acceptance is "after 3 months of stable operation": none of the 5 measures has a threshold
- Plan excerpt
- §5 Acceptance: after the system has run stably for 3 months.
- Cannot be claimed yet
- That acceptance will go smoothly after 3 months. If thresholds are not set at initiation, at acceptance every party counts in the way that favours itself; issue closure rate and functional completion rate are argued over most.
- Get from the supplier
- Write thresholds for the 5 measures into the initiation document: document and delivery accuracy, system availability, outbound efficiency or cycle-time attainment, issue-list closure rate and functional completion rate, together with the definitions of what counts as an issue and what counts as a confirmed function.
- What counts as closed
- Thresholds and definitions are in the initiation document, signed by all three parties.
How this finding was found
- What was looked at
- The acceptance clause in §5
- Method
- Checked against pitfall L17, trial operation and acceptance: do the 5 measures have thresholds, and are the definitions written down.
- Rule number
- ACC-01 Acceptance thresholds
- What it cannot prove
- It cannot prove acceptance will drag on; it only proves there will be nothing to check against when the time comes.