船舶維修項目啟動標準作業程序
船舶維修項目啟動標準作業程序：規格受理、機械／電機／液壓審核、指派項目經理、拆分工作包、分包填補缺口、排期，以及開工前的確認／修訂啟動會議。
運作方式
把泳道對應到你們自己的部門名稱
這裡的五個角色泳道，銷售／客戶、技術審核、項目經理、採購及工場，對應 FAYARD 的組織方式。如果你們的船廠把技術審核拆分成獨立的機械、電機及液壓泳道，而不是共用一條，就加入它們；如果採購和項目經理在較小的工作上是同一個人，就合併泳道，而不是畫出一次根本不存在的交接。
在每個步驟上寫具體人名，而不只是角色
在每一列的「負責人」欄放上真實人名，並在旁邊填上實際的估算工時（小時），就像「由機械、電機及液壓主管進行範圍技術審核」附有三位具名主管及一個合併估算一樣。這正是讓工作量分析面板能在錯過審核日期之前，先讓你看到一位主管在兩個進行中的啟動項目上被重複指派的原因。
把第一道判斷背後的可行性準則寫出來
「範圍是否完整並在技術上可行？」只有在各主管對於甚麼算完整有一套共同的書面標準時，才是一道有用的關卡：圖紙、容差、可達性限制、過往勘查資料。沒有這套標準，這道判斷就會變成因審核人不同而有差異的主觀判斷，澄清迴路也會被不一致地使用。
訂定工作包甚麼時候交給分包商的規則
「內部產能是否涵蓋所有工作包？」應根據一套有紀錄的規則來走，而不是憑直覺：船廠沒有的具名技能、某個工場在入塢窗口內已經排滿產能，或者船廠內部不具備的專門測試。把這條規則記在判斷旁邊，讓一位受時間表壓力的項目經理，不能悄悄跳過分包步驟去保住某個日期。
在使用這張圖表之前，先確定啟動會議「已確認」的定義
「客戶在啟動會議上確認範圍、時間表及價格？」每一次都需要在會議桌上同時放着這三樣東西：工作包、入塢或泊位日期，以及價格。如果客戶在會議上永遠只看到三者之一，「已確認」這個分支作為審批就毫無意義，糾紛只會在後面、執行期間才浮現，而不是在這裡。
把這張圖表當作項目的即時紀錄系統，持續保持更新
因為這張圖表已經附有每個步驟的負責人和工時，請在整個執行過程中持續更新它，而不是把它當成一次性的啟動文件：新增的工作包或重新指派的主管，都應該記錄在同一張圖表上並附上版本，這樣工作量面板和時間表才不會與船廠實際發生的情況脫節。
常見問題
為甚麼技術審核需要三個獨立專業和一道共同判斷？
因為船舶維修規格實際上很少只涉及單一專業，即使表面看來如此：一項液壓操舵故障，背後往往同時有電機控制部分和機械連桿部分。由機械、電機及液壓主管一同審核，再以一道共同的可行性判斷把關，正是能在跨專業發現變成維修進行到一半的意外之前，把它捕捉出來的方法。把審核拆成三個各自獨立、沒有共同判斷的簽署，通常正是船廠最終落得三個專業各自都相信範圍完整，卻沒有人整體核實過的原因。
為甚麼自行處理或外判的判斷放在工作包拆分之後，而不是之前？
因為「內部產能是否涵蓋所有工作包？」只能按專業、對着有實際工時的真實工作包來回答，而不是對着整份規格作為一個整體來回答。先把範圍拆分為工作包，正是讓「我們能否自行處理」從一個猜測變成一份清單的關鍵：每個工作包要麼配得上現有的工場和技能組合，要麼配不上，只有配不上的工作包才需要交給分包商。
如果客戶在啟動會議上不確認，會發生甚麼事？
圖表把「要求變更」導向「修訂範圍或時間表並重開啟動會議」，這會循環回到風險審核階段，而不是進入執行階段。這一點很重要，因為修訂後的範圍或時間表，可能同時改變風險狀況、資源配置，或兩者皆有，所以流程會重新進入策劃階段，而不是悄悄修補分歧後直接跳到發出工作包。
分包工作在哪裡重新併入主時間表？
「為缺口物色並委聘分包商」直接進入「安排工場資源及入塢或泊位檔期」，跟內部路徑在「是」的答案下到達的是同一個步驟。這樣排期就只有一個步驟，同時涵蓋內部及外判的工作包，而不是兩份日後才要對照同一個乾船塢或泊位窗口去協調的獨立時間表。
這跟一般的項目變更申請流程有甚麼分別？
這份標準作業程序講的是啟動一個維修項目，由客戶的規格到一份已發出、已配置資源的工作；變更申請流程規範的，則是項目已經開始並確立基線之後，對範圍、成本或時間表的更改。這裡的啟動會議，是範圍、時間表及價格第一次獲得共識的時刻。此後任何變更，一旦工場已經開立工作，都應該歸入一個獨立的變更控制流程，而不是一次重新啟動的會議。
為甚麼工時估算要放在個別列上，而不是項目一個總數上？
一個項目層級的總工時估算，恰恰隱藏了項目經理在啟動時最需要知道的資訊：究竟是銷售部、某位技術主管、採購部，還是某個工場成為瓶頸。按列記錄的工時，經工作量分析面板彙總後，可以顯示一位項目經理或液壓主管在幾個同時進行的啟動項目上承擔了多少工時，讓你在它變成一次延誤的審核日期之前，就在更早、成本更低的階段捕捉到。