Can't approve ready while the two suppliers mean different things

LuisBaker0521 · 30 Aug 2025, 05:08 UTC

Closed
LU
LuisBaker0521
Our lathe supplier uses ready for request received. FR5 integrator uses it for loading area available. I can't sign a handover built on both.

17 replies

JA
JasperChan1073
Replying to LuisBaker0521

Put a normal request on paper and ask each side what happens next. Name receipt separately from area available before arguing over which ready is correct.

24 points
LU
LuisBaker0521
Replying to JasperChan1073

Machine team says it can acknowledge while still finishing the previous operation.

16 points
JA
JasperChan1073
Replying to LuisBaker0521

Then that acknowledgement cannot serve as loading-area availability in the integrator's sequence. Give those conditions different names in the proposed interface.

6 points
RE
ReeceBarnes0558
Replying to LuisBaker0521

Do both teams have the same view of when the request ends? Renaming ready helps, but it may reveal a second disagreement about clearing the request.

8 points
LU
LuisBaker0521
Replying to ReeceBarnes0558

No. Machine team clears on receipt. Integrator expects it retained until the transfer is complete.

19 points
AD
AdaBennett0738
Replying to LuisBaker0521

You need one agreed lifecycle, not just two renamed bits. Identify who raises each condition, who acknowledges it, what keeps it valid and what clears it. Walk through a busy machine as well as the easy idle case.

10 points
OW
OwenBarnes0573
Replying to LuisBaker0521

Our display called both states waiting. Name the thing each side is waiting for.

7 points
JA
JasperChan1073
Replying to OwenBarnes0573

Owen, could your operator tell which team to call from the revised wording? That's where our first draft usually falls short.

7 points
LU
LuisBaker0521
Replying to AdaBennett0738

Draft now separates request received, loading area available and transfer complete. The suppliers are reviewing the clear conditions together.

20 points
RE
ReeceBarnes0558
Replying to LuisBaker0521

Include connection loss in that review. A retained request can look perfectly reasonable on each side while they disagree about whether it still belongs to the current transfer.

10 points
OW
OwenBarnes0573
Replying to JasperChan1073

Jasper, yes, after we added the station name and an escalation contact. Waiting alone sent everyone to maintenance.

6 points
LU
LuisBaker0521
Replying to ReeceBarnes0558

Busy-machine walkthrough agreed. Connection loss exposes an old request that the integrator wants to retry automatically. Machine team hasn't agreed.

7 points
AD
AdaBennett0738
Replying to LuisBaker0521

Leave automatic retry out until the outcome can be reconciled. A lost connection does not tell either team whether the requested work happened. The interface owner needs to define what evidence permits recovery.

7 points
RE
ReeceBarnes0558
Replying to LuisBaker0521

Who is acting as interface owner here? Two suppliers agreeing their own halves is how you got this ready problem.

5 points
LU
LuisBaker0521
Replying to ReeceBarnes0558

Our controls lead is taking that role. Unknown outcomes will remain held for the reviewed recovery path.

18 points
JA
JasperChan1073
Replying to LuisBaker0521

Have the controls lead keep the interrupted example with the interface document. It explains why request received must not be presented as completed, even after the labels look tidy.

9 points
LU
LuisBaker0521
Replying to JasperChan1073

Normal sequence definitions agreed. Recovery still under review. New names are in both drawings; no automatic resend approved.

-2 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .