訂單可視化2實戰-合同評審

1.1.  簡介

合同評審顧名思義即簽訂合同前，公司各相關部門大家一起開會商議合同是否可簽、合同存在的技術風險、計劃風險以及财務風險等，并需要通過此環節确定訂單可傳遞日期等。最後形成統一決論并進行執行，這麼做會存在以下幾個難點或缺陷。

1.  涉汲部門較多，人員事務較多，無法召齊人員

部門人員事務煩多，且經常有出差的，大會小會不斷。是以每召集一次會議比較麻煩。

2.  資料沒有存儲并電子化，不友善調取曆史資料進行新訂單參考

每當有新進的訂單時，如果是沿用某個訂單的資訊，無法自動參照填充值

3.  資料無法分析

沒有電子化的資料，無法對曆史評審的周期、技術進行資料分析，也沒有資料來源。紙質檔存檔不利于資料分析。

4.  無流程，無法框定部門、人員先後順序及職責

沒有流程，合同評審是的表格資料是有先後順序的。如果沒有流程，操作随意性大，各部門職責責任不清

1.2.  總體思路

1.  理順流程，将所有相關業務表單進行整理，分布至流程節節為表單填充内容

合同評審是各方意見的評價合集，是以我們的總體思路先将評審的流程理順，明确各節點責任與義務。此後，再将以前的所有的表格資料收集在一起，進行整理将分散至各個流程節點上。此思路也是其它流程功能子產品的總體思路。

2.  表單資料存儲方式考驗

表單裡面的資料結構複雜多樣，傳統型的二維表方式不适用此方式的靈活型，也反映不出表單的版面結構方式。是以我們采取直接将頁面的資料以JSON的方式進行存儲，采取VueJS技術直接将JSON檔案與頁面進行綁定來解決此問題。

在後面的完善性思考中，我們也思考出了用二維表進行存儲，即采取鍵值對的方式将每一個元素存取表中，但會犧牲表單的層次性。總的來說推薦進行JSON方式存儲，目前我們是采取的JSON檔案方式，在後期資料逐漸變多的時候，如果還是檔案會影響效率，我們再考慮采取大資料MongoDB的方式來解決搜尋、性能的問題。

1.3.  流程表單更新帶來的挑戰

流程更新後，與原來的流程釋出版本并存，新開的流程執行個體會使用最新的，不同的流程版本有不同的業務模式，每一次流程更新需要考慮新的業務功能實作的同時，還需要相容老流程的業務。

表單在内容改變後，增加、删除更新字段後，原來的資料表單如何保證在讀取的時候能夠正常展示。

新增内容：這個就簡單了，直接添加就可以，隻是以前的訂單展示出來，這個字段資料是空的。

删除内容：這個如果把原有的字段删除，如果不對頁面模版進行版本化，特定流程版本對應特定的模版表單頁，則會造成以存取的資料無法展現。這個也是在後面我們在實踐中漸漸發現的問題。

修改内容：如果修改了字段，那原來的資料也是無法展現的，如果修改的資料類型，也會出現與删除内容相同的模式。最後的處理方式應該參見删除内容的相容處理方式。

1.4.  資料價值

合同評審裡面評價了财務風險、技術風險、進度風險，所有後續業務均以此為基礎。我們可以此為基礎，再根據流程的實際運作情況進行對比，找出問題所在。

對于新來的訂單，我們也可以根據曆史經驗值分析，為新訂單提供評審依據，提高效率并增強可靠性。

作者：長沙大東家

日期：20170909

聯系:[email protected]