08 · Implementation & go-live · Observation window
Problems on the first night: sort first, then act
Launch support watches the observation window after the gate opens: on site, able to stop a path, does not edit the database. Day-to-day tickets are not on this page.
- Open the gate On site. Support stands next to the first live document and records the document number.
- Every hour Sort. A defect stops the path. A miss calls the trainer. A change goes on the list.
- Handover Write it down. Open problems, who is chasing them, and whether they affect the next shift.
Launch support owns order in the observation window
In the first days after the gate opens, problems arrive in a pile. What marks launch support is being on site, findable, and not editing production data directly. He collects document numbers, screenshots, the operator, and the time, and handles them from the gate checklist: a defect first stops the path or switches to a verified bypass, and the bypass must be agreed by the delivery manager; a miss calls the trainer on the spot; a new wish is noted, code is not changed. Full ticket triage — numbering, close verification, no promises in the group — goes to technical support after the observation window ends. If he edits the database himself, that night he is treated as a hero. The next day nobody can explain why the numbers changed.
The duty roster must cover night shift. A project with only day-shift support will still fall back to WeChat at night. He writes the duty phone where the warehouse clerk can see it, not deep in a project-group announcement.
How the observation window ends
End conditions are written in advance: several consecutive shifts with no open defect on the key path, opening-balance variance cleared, and no repeated misses in the duty log. When the conditions hold, launch support hands the watch to day-to-day technical support. What is handed over is the open list, stopped paths, and verification document numbers — not a new triage method. If they do not hold, extend observation. Do not declare stable because project people need to leave the floor.
A missing code on the first night
The first truck had an item with no code in the new system. By the rule it could not be received. Someone in the group told support to create a temporary item first. Launch support refused, registered the truck as pending, notified the master-data owner to add the code, and held the goods per the implementation plan. Once a temporary item is created, the stewardship rule is broken that day. After the code was added, receiving followed the original document, and the record shows the wait. That is what support should do. It is not a switch development should add overnight.
At shift handover he writes this document's state for the next shift. Three sentences at the end of every shift: paths that cannot be used now, document numbers still waiting, and actions the next shift must not try again. Without those three sentences, the next shift will receive the same truck again. Handover is written in the duty log, not in a private chat. Inside the observation window he watches whether a problem repeats: the same path failing in a row is stopped first, then fixed. He does not chase zero problems. When a recovered path is opened again, write a verification document number. A recovery with no verification document number is only development saying it is fine. On the shift the observation window ends, he hands the open list, stopped paths, and verification document numbers to day-to-day Technical support, and books the first look-back. Look-back follows tickets. Launch support no longer covers night shift. How tickets are numbered, how they are closed, and how not to promise a system change in the group is technical support's day-to-day method. It is not expanded into a handbook on this observation-window page.
Observation-window end conditions are written in advance on the back of the gate checklist, separate from the six ticks on open day, so the watcher cannot declare stable by saying “the list is all ticked.” The back also writes: a bypass with no delivery-manager signature must not be enabled on night shift. A bypass that was enabled must be closed back to the verified path before observation ends, with a verification document number left. The pending document that refused a temporary item, at handover, only writes the document number and who is waited on for the code. It does not write “receive it first and sort it later.” If the night watcher is also development, they must not fix a defect they introduced and declare recovery themselves. Recovery still needs a verification document number.