如何由文件建立流程圖
如何把一份從來沒有為步驟編過號的文件變成流程圖：哪些段落根本不是步驟，範圍、定義和職責應該去哪裡，以及為甚麼畫出來的圖總是太長。
運作方式
把每一段歸進三堆
把文件通讀一次，為每一段標上動作、條件或兩者皆非。「提出人須將變更登錄入冊」是動作。「除同類替換以外的變更」是條件。範圍、定義、職責表和引用文件清單都是兩者皆非，而在一份政策裡，它們佔的頁數比動作還多。
把非步驟花掉，而不是畫出來
第三堆是拿來收割的，不是拿來丟棄的。一項範圍豁免變成流程前段的一個決策，帶著自己的一個結束。一個被定義的用語變成用到它那個決策上的判斷準則，原文則放進那一行的備註。職責表變成整組泳道。這一堆裡沒有任何東西會變成方框。
把動作輸入成行
在 QueryChart 裡每一行就是一個方框，所以把標記為動作的內容逐一填進每一行的「方框文字」欄，次序按動作實際發生的先後，而不是按它們被印出來的先後。標籤要短到一眼讀得完，它出自的那條條款留在該步驟的備註裡。然後用「連線至」欄把各行連起來，那一欄填的是行號。
為每一個條件加上帶標籤的出口
由條件變來的那些行會成為菱形：把它們的「形狀」欄改成「決策」，並把每一個改寫成一個問題。「連線文字」接著按「連線至」裡數字的次序，每條分支填一個標籤。一項點名三種情況的條款需要三個標籤——「低風險」、「中風險」、「高風險」——否則讀的人分不出哪一條路是自己那條。
把文件散落各處的路線放回去
把每一條分支指向它到達的那一行，包括回頭的：一項需要補充作業的授權會退回技術依據，而一項臨時變更到期時會重新進入同一場審查。然後由職責表填好「水平泳道」和「垂直泳道」欄，讓一個步驟坐落在「篩檢」階段、「MOC 協調人」名下。
拿圖表回頭對一次文件
逐條條款去對，把每一條對上一行、一個分支標籤、一條泳道或一則步驟備註。剩下來的會有三樣東西：屬於備註的細節、一條還沒有人畫過的路，以及廠區多年前就已經不再遵守的條款。把最後那份清單交給文件的持有人——那正是這次梳理換回來的修訂申請。
常見問題
怎樣把 PDF 變成流程圖？
先把文字抽出來，然後轉換文字，而不是轉換版面。PDF 的閱讀次序是一件排版產物——分欄、側邊欄、表格和頁尾交錯在一起——所以任何跟著它走的做法，都會產出一堆流程從來沒有過的次序的方框。把動作抽出來，把條件標出來，再由這份清單開始建。把抽出來的文字貼進 QueryChart 的 AI，可以拿到一份可用的行草稿；它解決不了的那些條件，正是需要人來處理的部分。
範圍和定義在流程圖裡應該放哪裡？
兩者都不會變成方框。一段範圍陳述變成流程前段的一個決策，並帶著自己的一個結束：在這裡的示例中，政策那項豁免就是「是否屬同類替換？」，而「同類替換」這條分支停在「按保養維修工作處理」，完全不碰流程的其餘部分。定義變成用到它們那些決策上的判斷準則——低、中、高風險之所以能夠作為分支標籤被判定，正因為文件寫明了每一檔由哪裡開始——而原文放進該步驟的備註。
為甚麼由文件做出來的流程圖總是太長？
兩種機制，而兩種都可以避免。第一種是把那些不描述任何工作的章節謄了下來：一張職責表每個角色貢獻一個方框，一份引用文件清單每份文件貢獻一個，而兩者都不描述任何人做任何事。第二種是決策處的膨脹——一句點名三種情況的話被畫成連續三個步驟，而不是一個帶三條標籤出口的菱形，於是圖長了，分支卻仍然看不見。兩者加起來，會為一個十二步的流程加上十來個方框。
政策或合約可以畫成流程圖嗎？
可以，而且這件事通常會發現一些東西。合約和政策是寫來分配義務的，不是寫來為工作排序的，所以它們的條件很密，而它們的行為者被點名一次之後，就改稱為「該方」或「收件人」。把它畫出來，會逼著每一項義務進入某個負責人的泳道，每一個條件進入一條帶標籤的分支，而那條沒有寫明後果的條款、那個背後沒有任何步驟的通知期，就是這樣浮出水面的。