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