船舶维修项目启动标准作业程序：从技术规格到工作包
船舶维修项目启动标准作业程序：技术规格受理、机械／电气／液压评审、指派项目经理、拆分工作包、分包补缺、排期，以及启动会上的确认或修改环节。
运作方式
把泳道对应到你们自己的部门名称
这里的五条角色泳道——销售／客户、技术评审、项目经理、采购和车间——对应FAYARD的组织方式。如果你们船厂把技术评审拆成机械、电气和液压三条独立泳道，而不是共用一条，就把它们加上；如果在较小的项目上采购和项目经理是同一个人，就把这两条泳道合并，而不要画出一个实际不存在的交接。
在每一步上写明具体的人，而不仅是角色
在每一行的人员列上填一个真实的人，并在旁边填一个合理的工时估算，就像"由机械、电气与液压负责人对范围进行技术评审"这一行带有三位具名负责人和一个合并估算一样。正是这一点，能让工作量BI面板在某位负责人错过一个评审日期之前，先显示他已经被同时排在两次并行启动会中。
把第一个判断背后的可行性标准写清楚
"范围是否完整且按此规格在技术上可行？"只有在几位负责人对什么算作完整有一份共同的书面标准时才是一个有用的关口：图纸、公差、可达性限制、既往勘查数据。没有这份标准，这个判断就会变成因评审人而异的主观判断，澄清循环也会被不一致地使用。
定下一个工作包什么时候交给分包商的规则
"内部产能能否覆盖全部工作包？"应当依据一条书面规则来分流，而不是凭感觉：船厂没有的具名技能、某个车间在坞位窗口内已经排满，或者船厂内部不做的某项专业测试。把这条规则记在判断框旁边，这样一位承受排期压力的项目经理就不能悄悄跳过分包步骤来保住某个日期。
在使用本图之前，先确定启动会上"已确认"意味着什么
"客户在启动会上确认范围、排期与价格？"每一次都需要同样的三样东西摆在桌面上：工作包、坞位或泊位日期，以及价格。如果客户在会上只看到三者之一，"已确认"这一分支作为一次批准就毫无意义，争议只会在执行阶段之后才浮现，而不是在这里。
让这张图在执行过程中保持鲜活，作为项目的记录系统
因为图上已经带有负责人和工作量，执行过程中要持续更新它，而不是把它当成一次性的启动产物：新增的工作包或改派的负责人，都应记在同一张图上并保留版本，这样工作量面板和排期才不会与船厂实际发生的情况脱节。
常见问题
为什么技术评审需要三个专业和一个判断？
因为一份船舶维修技术规格在实践中很少只涉及单一专业，即使它读起来像是这样：液压转舵故障背后往往还有一个电气控制部分和一个机械连杆部分。让机械、电气与液压负责人一起评审，再统一由一个共享的可行性判断把关，正是能在它变成维修中途的意外之前捕捉到跨专业问题的关键。把评审拆成三个独立签字、没有共享判断的做法，通常正是船厂最终得到三个专业各自都认为范围完整、却没有人整体核查过的结果的原因。
为什么自制或外包的判断排在工作包拆分之后，而不是之前？
因为"内部产能能否覆盖全部工作包？"只能逐个专业地针对带有真实工时的真实工作包来回答，而不是针对整份技术规格。先把范围拆成工作包，正是把"我们能不能自己做"从一个猜测变成一份清单：每个工作包要么符合某个可用车间和技能组合，要么不符合，只有不符合的才需要交给分包商。
如果客户在启动会上没有确认，会发生什么？
本图把"需要变更"这一结果转入"修改范围或排期并重新召开启动会"，它循环回到风险审查阶段，而不是直接进入执行。这一点很重要，因为一份修改后的范围或排期可能改变风险图景、资源配置，或者两者都改变，所以流程会重新进入计划阶段，而不是悄悄修补分歧后直接进入下发工作包。
分包商的工作在哪里重新汇入主排期？
"为缺口寻源并委托分包商"直接汇入"排期车间资源与坞位或泊位档期"，与内部路径在"是"分支时到达的是同一步。这样排期就只有一步，同时统筹内部和外包的工作包，而不是两份独立的排期，需要事后再对照单一的干船坞或泊位窗口进行协调。
这与一般的变更请求流程有什么不同？
本标准作业程序讲的是启动一个维修项目，从客户的技术规格到一份已下发、已配置资源的工作单；变更请求流程管理的是在项目已经开工并确定基线之后，对范围、成本或排期的改动。这里的启动会，是范围、排期与价格第一次被达成一致的时刻。在那之后、车间已经下发工作包之后的任何变更，应当走一个独立的变更控制流程，而不是走一次修改后的启动会。
为什么工作量估算要放在单独的行上，而不是给整个项目一个总数？
一个项目层面的单一工时估算，恰恰会掩盖项目经理在启动阶段最需要的信息：瓶颈到底出在销售、某位具体的技术负责人、采购，还是车间。按行填写工作量、再由工作量BI面板汇总，能够在一位项目经理或液压负责人在几个并行启动会中已经累积了工时、而这一点还没有表现为一次延误的评审日期之前，就把它显示出来，这是更早、也更便宜发现问题的时点。