船舶维修交接标准作业程序：从完工审查到离港
船厂船舶维修完工交接标准作业程序：未完成事项审查、测试与调试、QA文件整理、客户与船级社检查、清单关闭与出坞，每一步都带有负责人和工时。
什么是船舶维修交接标准作业程序：从完工审查到离港流程
交接，是维修项目的文书工作追上船舶实际状态的地方，也是车间自身的乐观情绪造成最大损害的地方。一个工作包被报告为完成，是因为装配工自己相信它完成了，而不是因为有人对照订购内容、以对整个范围负责的权限核实过它。这正是为什么本图在"所有工作包均由车间报告完成"之后紧接着放的是一道审查步骤，而不是一枚橡皮图章：项目经理会在任何事项进入测试之前，先对照范围核实报告，判断"是否仍有工作包未关闭？"会经由"催促车间完成未完成事项"把流程送回去，而不是让一个未完成的事项跟着进入调试阶段——在那里被发现的代价要高得多。
同样的逻辑又重复了两次，因为像FAYARD这样的船厂，交接会在三个不同的时刻失败，而不是一个：一个工作包可能在测试甚至还没开始之前就仍未关闭，一个维修好的系统可能没有通过自己的调试测试，客户或船级社验船师也可能干脆不接受车间和船厂自己的QA/QC已经签字认可的东西。这三种情况，每一种都被建模成一个带有返工循环的判断——调试测试未通过对应"退回车间整改未通过的系统"，检查被拒绝对应"退回车间进行大返工"——而不是留一条备注让人以后自己记得处理。验船师的拒绝，是这三种失效中代价最高的一种，因此本图被有意设计成让前面两道更早、代价更低的检查，在船舶真正走到那次检查之前，尽可能多地把问题拦下来。
清单阶段之所以存在，是因为在修船厂，"接受"和"完成"并不是同一回事：验船师可以签字确认船舶适航，与此同时仍有少数几项次要事项——补漆、一份缺失的证书、一个松动的配件——还没有关闭。把这些事项导向它们自己的判断"所有清单事项是否均已关闭并签字？"，并配上一条回到"继续关闭剩余清单事项"的循环，既不会让这些琐事拖住离港，也不会在船舶回到海上之后被悄悄遗漏。而每一行上的人员和工作量列，并不只是记账：项目经理陈静同时承担着未完成事项审查、检查排期、清单汇编与最终档案整理的工时，而刘颖的QA/QC工时则横跨调试、通过／不通过判断与文件整理。在一个同时运行不止一次交接的船厂，工作量BI面板正是让排期员看到，同一位项目经理是否已经排满，才不会在同一周里又答应另一艘船的清单关闭。
本流程图涵盖的内容
本模板包含
- 完工审查：从"所有工作包均由车间报告完成"经"项目经理对照范围审查未完成事项"，到判断"是否仍有工作包未关闭？"，它会经由"催促车间完成未完成事项"循环，直到每个工作包都真正关闭
- 测试与调试："对维修后的系统进行测试与调试"由"所有系统是否均测试与调试成功？"把关，未通过的系统会经由"退回车间整改未通过的系统"循环，之后才会重新尝试调试
- QA文件与客户／船级社检查："汇编QA文件、测试记录与证书""安排客户与船级社检查"以及"客户与船级社验船师检查已完成的工作"，由判断"客户与船级社是否接受该项工作？"收尾，被拒绝的结果会一路转回"退回车间进行大返工"
- 清单关闭："汇编双方商定的次要未完成事项清单"和"关闭清单事项并取得客户签字"，由"所有清单事项是否均已关闭并签字？"把关，仍有剩余的事项会循环回到"继续关闭剩余清单事项"
- 最终文件与离港："整理最终维修档案与保修文件"和"出坞或解除泊位，船舶离港"，终止于"维修项目完成，船舶已离港"
- 每一步都带有具名人员和数值化工作量，横跨"车间""QA/QC""项目经理"与"客户／船级社"泳道，让工作量BI面板能够按人员和阶段对整个交接流程的工作量进行汇总
何时使用本模板
- 你正在FAYARD结束一个维修项目，需要一套从车间完工报告到离港为止、受控且经过批准的流程，而不是一份关于接下来会发生什么的口头理解
- 此前有一次交接让一个未完成的工作包一路带进了测试阶段，或者一项清单事项在船舶启航之后被遗漏，你需要审查判断和清单判断，让这种情况变得不可能发生
- 你正在同时为多艘船的维修项目运行调试与检查，需要人员和工作量列显示项目经理或QA/QC负责人在你向客户承诺下一个检查档期之前，是否已经排满
- 此前一次客户或船级社验船师的拒收，没有留下任何书面原因就直接被退回车间，你需要"不接受"分支强制形成一份书面理由，并经过大返工返回，而不是一次非正式的修补
- 你正在为新任项目经理或QA/QC负责人做入职培训，需要一份从完工审查经调试、检查、清单关闭、最终文件到出坞的参考流程，而不是靠口耳相传知道接下来会发生什么
运作方式
把泳道对应到你们自己的项目组织架构
示例使用车间、QA/QC、项目经理与客户／船级社。如果你们的交接流程把车间工长的签字和坞长的签字分开，或者把船级社检验交给一位专职验船联络人负责，就为它单独设一条泳道，而不要把它并入某条已有的泳道——泳道正是让读图的人一眼就知道谁负责某一步的关键。
用你们自己的花名册和工时替换示例的人员和工作量数值
把陈静、刘颖、王强等示例姓名换成你们实际的项目经理、QA/QC负责人和车间工长，并把工作量设成每一步实际需要的投入工时，而不是它所占的日历时间。这正是工作量BI面板要汇总的数字，占位工时只会得到一张占位的工作量图。
把你们自己的验收标准写进判断框
"所有系统是否均测试与调试成功？"和"客户与船级社是否接受该项工作？"背后都需要真实的标准：一个系统必须通过哪些测试标准，以及船级社验船师实际是对照什么在核查。一个没有明确标准的判断，只能靠个人判断来回答，而这正是返工分支存在的目的。
按你们自己对次要事项的容忍度来设定清单判断
"所有清单事项是否均已关闭并签字？"假定清单上的都是检查时双方商定的、真正次要的事项。如果你们船厂的清单里经常出现原本就应该阻止验收通过的工作，就收紧检查判断中"接受，尚有次要事项"的认定范围，而不要让它一路流入清单关闭。
让最终文件保持为独立步骤，而不是离港的附注
"整理最终维修档案与保修文件"是客户和FAYARD日后如果遇到保修问题时都要依赖的记录。把它保留为"出坞或解除泊位，船舶离港"之前的一个独立行，意味着即使离港被赶工，这份档案也不会被跳过。
常见问题
这份标准作业程序为什么设置了三个独立判断点，而不是一个交接步骤？
因为在修船厂，交接会在三个不同的时刻失败，而不是一个：一个工作包可能在测试开始之前就仍未关闭，一个维修好的系统可能没有通过自己的调试测试，客户或船级社验船师也可能不接受车间和QA/QC已经认为完成的工作。每一个判断都设在对应失效变得可以核查的那一刻，并且都分支回返工而不是转发到一条备注上，因为在未完成事项审查阶段就发现一个未完成的事项，远比在验船师检查时才发现要便宜得多。
本图上的人员和工作量列起什么作用？
每一步都带有对其负责的人员，以及一个代表该步骤实际所需投入小时数、而不是所占用时长的工作量数字。工作量BI面板读取全图这两列，按人员和阶段汇总投入，例如一位排期员能够看到，项目经理已经在一次交接上承担了审查、检查排期与清单相关的工时，然后第二艘船的收尾工作又被加进她这一周的日程。
如果客户或船级社验船师不接受已完成的工作，会发生什么？
判断"客户与船级社是否接受该项工作？"会把拒收的结果转入"退回车间进行大返工"，再转回未完成事项审查，而不是把这次拒收当成一场私下沟通处理。只有"已接受，尚有次要事项"的结果才会进入清单关闭，这正是防止一项有争议的维修悄悄走到离港这一步的关键。
清单事项和调试测试未通过有什么区别？
调试测试未通过，意味着某个系统没有通过自己的测试，在客户或验船师介入之前就直接被退回车间。清单事项则是客户和船级社验船师已经共同认定足够次要、不会阻碍验收通过的事项，它会在"所有清单事项是否均已关闭并签字？"这里被单独追踪和关闭，而不需要重新打开整个检查。
这份标准作业程序能否用于没有船级社参与的维修项目？
可以。阶段结构可以照搬：未完成事项审查、测试与调试、文件整理、验收检查与离港前的清单关闭。变化的是客户／船级社泳道上坐的是谁，以及检查判断实际对照的是什么，因此只需修改这一步及其标准，而不是整体顺序。