基本流程圖範本（由申請到結案）
基本流程圖範本，由提出申請走到結案：一個起點、四個帶標籤的判斷、一條在第二次不合格封頂的重做迴路，以及三個各自獨立的結局。這是可以直接複製改名的最小完整流程。
運作方式
把五個階段改成你們自己的階段
申請、核查、執行、檢查與結案只是進件、分流、執行、驗證與結案的佔位名稱。把它們換成你們團隊平時真的會講出口的階段名稱。如果你們根本沒有驗證階段，就把檢查併入執行，而不是留下一個空欄，暗示有一次沒有人做的覆核。
為三個角色命名，並把覆核人分開
把申請人、流程負責人與覆核人改成你們真實的角色——一個決策者一條泳道，而不是一個人一條泳道。唯一要抵住的合併，是把覆核人與執行工作的人放在同一條泳道。如果他們本來就是同一個人，那道檢查只是裝飾，你應該在圖上直說，而不是畫一次永遠不會不合格的覆核。
把你們的最低申請欄位寫進第二行
「說明需求與期限」故意寫得含糊，因為你們的欄位不是我們的。逐項列明：要甚麼、為甚麼要、需要的日期、有問題找誰。同一份清單就是兩行之後「資料是否足夠開始？」用來判斷的標準，所以在備註欄寫一次，兩處共用。
訂你們自己的重做上限
覆核判斷在第二次不合格時升級。如果你們的流程確實容許升級之前試三次，就加一條分支並寫明；如果一次都不容許，就刪掉退回「完成工作」的箭嘴，把每一次不合格都直接送去升級。要緊的是這條迴路有一個寫明的出口，因為沒有上限的迴路，正是工作一整季消失無蹤的方式。
決定升級交到誰手上，以及他可以做甚麼
「改用其他做法還是結束申請？」假設有人有權在未解決的情況下結束一份申請。如果你們機構裡沒有人有這個權，就刪掉「未符合準則而結案」，令升級永遠回到「議定驗收準則」——然後老實承認這條流程沒有辦法停下來，並指名由誰承擔這個風險。
只用你們真正需要的形狀
這張圖只用六種方框，不多過這個數：一個起點、普通處理步驟、判斷、一個記錄步驟，以及兩種終止符，覆蓋它的三個結局。這是刻意的。Microsoft 為自己的 Basic Flowchart 範本所寫的指引就說明，任何形狀都可以承載製作與閱讀流程圖的人所議定的任何含義，而大部分流程圖傾向只用三、四種形狀。議定一套細小的形狀集，寫下每一種代表甚麼，然後就此為止。
常見問題
基本流程圖有哪些階段？
一般情況下是五個。進件，工作在這裡被申請並說明。核查，由某人判斷這份申請是否完整到足以動手。執行，工作在這裡完成並記錄。驗證，由第二個人對照事先議定的準則檢驗結果。結案，確認結果並正式關閉這份申請。上面這張圖的階段欄正好就是這五個——申請、核查、執行、檢查與結案——因為由一項維修工作到一次文件修改，幾乎任何運作流程一旦不再按擁有它的部門去命名階段，都吻合這條脊骨。
這樣畫出來的流程由誰負責？
三個角色，各自負責三件不同的事。申請人負責資料：申請不完整，流程就開不了，而這張圖會把它退回，而不是靠猜。流程負責人負責流程本身——隊列、指派、到期日，以及覆核兩次不合格時的升級。覆核人負責準則並執行它，這也是為甚麼準則在工作開始之前就在覆核人的泳道裡議定，而不是到了檢查那一步才臨時想出來。把端到端的問責交給流程負責人。沒有一位具名的流程負責人，一份卡在兩條泳道之間的申請就不屬於任何人，而這是工作失落最常見的方式。
工作兩次通不過覆核時應該怎樣處理？
應該停止打圈。第一次不合格是平常事：覆核人列出具體缺口，工作退回重做。同一份申請第二次不合格，意味著出錯的不是努力程度——可能是準則不清、可能是這套做法根本達不到準則，也可能是這份申請本身做不到。再走第三圈，只是用更慢的速度重複同一個結果。在這張圖中，第二次不合格會升級至流程負責人，由他在改用其他做法（回到議定驗收準則那一點）與在未解決的情況下結束申請之間選擇。兩種結果都有紀錄。兩種都不會令工作懸在半空。
流程圖的形狀有沒有標準含義？
比大部分人以為的少。確實存在廣泛的慣例——圓角方框代表起點或終點、長方形代表一個步驟、菱形代表一個判斷——而遵從它們會令一張圖更容易被陌生人讀懂。但 Microsoft 為自己的 Basic Flowchart 範本所寫的文件明確表示，任何形狀都可以承載製作與閱讀流程圖的人所議定的任何含義，並指出大部分流程圖傾向只用三、四種形狀。所以並不存在一套要先學會才能開始的形狀庫。挑一小撮，在圖例中定義它們，然後保持一致。清晰來自為判斷的出口加上標籤，而不是來自幾何形狀。