開發比較復雜的企業多用戶管理信息系統(MIS)，不可能不涉及到系統內多個用戶之間的數據文件的流轉、審批等功能的開發。由於企業的需求總是隨著時間推移不斷發生變化，加之各個企業內部所設置的辦公流程不盡相同，一套通用性比較好的管理信息系統應該能讓系統管理員自己定義公文轉發的流程。
盡管筆者沒有機會在已參與開發了的MIS中實現出文件轉發流程自定義的功能，但是，早在2002年初就曾深入思考過這方面的設計。當時由於某些原因不能公開自己的設計思路，現在市面上已經有不少MIS產品提供這樣的功能，筆者又已離職，所以是時候把我的設計思路整理出來，和大家分享。
首先，讓我們分析需求，制定目標。
1)一般情況下，企業內的公文轉發、審批是按部門或職位來轉送，即對崗不對人。例如：某個流程的某個環節需要財務總監審批，日後財務總監換人，該流程應該不受影響。而且，流程中某個環節可能出現某個部門中的任何一人都能審批，或者需要該部門的所有人員共同審批。
2)流程中轉送，審批的公文一般分為文件和表單2種格式。文件格式的公文應該支持批處理，即一次可以轉發多個文件，審批時可以只退回其中某一個不合格的文件，其他的文件可以轉送到下一個環節繼續處理。表單格式的公文應該能讓用戶自己定義表單格式，確定表單中的表項。同理，表單也應該支持批處理。
3)流程中處理公文的動作應該能讓用戶自己定義。這樣一旦日後增加了新的處理動作，也不用修改MIS系統的底層數據建模。當然，要實現新的處理動作，還是需要在業務邏輯層編寫相應的代碼，不過和修改底層數據建模比起來，工作量要少得多。
4)每個流程的環節數不一定相同，應該能讓用戶設定環節數，指定公文流轉中每個環節的發送部門和接受部門，處理模式，最長等待時間。
5)當待處理的公文發出後，系統應該在等待時間中定期向該流程中下個環節的用戶(們)發出通知，提醒該用戶(們)及時處理，直至公文已被處理。如果超出最長等待時間，公文還未被用戶(們)處理，此次流程處理失敗。企業管理層可能會要求記錄相關信息，以便在日後業務流程重組(BPR)時參考。
6)某些企業由於特殊原因，在某個流程中要求實現跨環節處理。例如，該流程有6步，執行到第二個環節時要求處理後可以跳過中間三個環節，直接轉到最後一個環節等候處理。其實，這種情況下，並不一定要在技術層面上實現其靈活性，這種特例畢竟是少數。用戶只需定義一個新流程，把上面流程的第1，2，6步復制加入進來，2個流程之間用流程名來區分即可。一個優秀的系統架構設計師應該充分利用現有的工具，不要什麼都自行架設開發。
上面的需求對靈活性要求較高，抽象化程度較深，所以在表現層和業務邏輯層的開發量較大，初期投資較多，不過開發完畢後估計不需對底層數據庫修改，即可滿足日後不斷變化的公文流轉需求。如果不需要這麼高的靈活性，可以按實際項目簡化某些假設條件。下面按照上面的需求進行用例(use case)分析和數據建模。
1)由於流程環節的發送方和接受方是對崗不對人，我們應該先描畫出整個企業的機構設置，確定每個部門的權利職責。其中大的部門內可能有若干子部門，每個子部門內又有不同職位，負責處理相應的事務。所以，可先建立一個樹形關系的數據表來保存企業結構，然後，采用權限表和用戶組相結合的方式來保存每個部門每個職位的職能。這塊的設計思路見我之前發布的“淺談數據庫設計技巧(上)、(下)”，我在下面直接給出大致的數據表結構：
部門表(Department_table)
名稱 類型 約束條件 說明
Dp_id int 無重復 類別標識，主鍵
Dp_name varchar(50) 不允許為空 類型名稱，不允許重復
Dp_father int 不允許為空 該類別的父類別標識，如果是頂節點的話設定為某個唯一值
Dp_layer varchar(6) 限定3層,初始值為000000 類別的先序遍歷，主要為減少檢索數據庫的次數
功能表(Function_table)
名稱 類型 約束條件 說明
f_id int 無重復 功能標識，主鍵
f_name varchar(20) 不允許為空 功能名稱，不允許重復
f_desc varchar(50) 允許為空 功能描述
