1、合同系統需要利用IT技術

合同采購需要可靠的信息來作為決定和開始供應商談判的基礎——關于供應商績效、產品使用、預測需求、浪費百分比、生產問題、銷售等等的信息。同樣，當生產、銷售和物流部門的同事向供應商下訂單時，他們需要查看合同信息，計算最佳訂單數量，獲得最佳折扣和回扣。這里沒有單一的解決方案，但一流的采購團隊經常用應用程序和分析工具來補充他們的核心ERP系統，以滿足他們的需求。當然，技術對那些需要出去投標的人也有幫助——在供應商和采購團隊之間設置一個電子屏障，直到合適的時間，這有助于提高投標過程的效率。

2、合同過程需要優化供應鏈溝通

無論是在業務內部還是供應鏈外部，采購部門應與物流、供應鏈經理、合同經理和其他員工緊密合作，旨在確保開放、及時的溝通。由于缺乏溝通，企業無法履行一份經過良好談判的合同的承諾。
在折扣交易中經常出現這種情況。采購談判的條款很好，但在采購更多存貨時，如果系統和流程不能提供這些條款的充分可見性，就可能會錯過退稅門檻。最終的結果是項目成本高于預期。答案是確保各方都了解所有協議的機制，以便充分發揮其潛力。

3、采購關注總擁有成本，而不僅僅是價格

一流的采購團隊真正關注的是總擁有成本——考慮存儲、處理和其他成本。他們與其他部門的同事一起工作，真正了解參數，并考慮庫存和其他成本，如何獲得經濟訂單數量EOQ。
供應商提供的一種原料的價格可能是你能得到的最低價格，但如果它比更“昂貴”的替代品需要更多的人工處理或存儲，它可能不是你所需要的低成本解決方案。

4、與戰略供應商結盟

這不僅僅是供應商關系管理。一流的采購團隊努力成為供應商用他們最好的想法來尋求的客戶。他們對供應商和供應商所在行業有內幕消息，因此他們提前了解即將上市的新產品。這些結盟，加上上面第1點和第2點，使得擁有一流采購團隊的企業領先于競爭對手。他們已經準備好利用新的創意，而他們的競爭對手正在尋找最好的前進道路。

5、與企業各個關聯部門合作

最佳采購團隊與其他部門的同事一起制定戰略性采購決策。負責購買工作服的人會詢問員工的意見。食品生產原料的采購人員與貨物、物流、運營、生產、食品技術人員和其他人員合作，確定原料的標準和數量，以及包裝、運輸和存儲方式——所有這些都影響成本。

6、定期協商

最佳采購實踐不會“失之交臂”。這些采購領導人不斷監控合同的履行情況和周圍世界的變化，進而發現重新談判的機會。出現以下情況，應審查和重新談判合同：

• -潛在的替代品變得可用
  -競爭對手推出新的設計
  -需求超出/低于最初的預測
  -供應商行業的創新
  -出現生產或物流問題
  -你所在行業的創新

根據一項研究，一流的公司每年續簽60%的合同，而其他公司通常只續簽一半。

7、最小化風險

根據業務的不同，利潤率和風險是企業領導最關注的兩個問題。傳統上，買家非常關注壓低成本以提高利潤率，但越來越多的企業被迫考慮每個決定所涉及的風險。關于合規、賄賂、可追溯性、健康與安全以及奴役的立法;綠色問題和社會責任都是影響管理層及其下屬的因素。供應鏈風險、交付可靠性和物流問題都會給企業帶來一定程度的風險。采購團隊必須掌握所有這些要素的知識，并對其進行管理，以減少業務風險。

總之：提高透明度和優化運營對此至關重要，是將采購工作流程數字化和自動化的明智之舉。Gungho合同系統可以嚴密跟蹤和管理整個采購流程，使其簡化和高效。借助該軟件，組織能夠縮短采購周期、加快合同采購審批、減少開支、利用采購分析數據做出明智的決策，并始終保持政策合規性

硬件環境

8G 內存或更高 、8CPU或更高、200G硬盤（根據自己需求而定）

軟件環境

操作系統：

Windows 2008 r2 或 Windows 2012r2（支持 32及64）建議 Windows 2012R2

IIS環境：IIS + .NET4.0 +.NET4.5

若是WIndows 2008 ，需要IIS環境如下

install-windowsfeature web-server
install-windowsfeature web-windows-auth,web-app-dev,web-net-ext,web-net-ext45,web-asp,web-asp-net,web-asp-net45,web-cgi,web-isapi-ext,web-isapi-filter,web-includes,web-appinit,web-mgmt-console,web-mgmt-compat,web-scripting-tools,web-mgmt-service

若是WIndows 2012 ，需要IIS環境如下

install-windowsfeature web-server
install-windowsfeature web-windows-auth,web-app-dev,web-net-ext,web-net-ext45,web-asp,web-asp-net,web-asp-net45,web-cgi,web-isapi-ext,web-isapi-filter,web-includes,web-appinit,web-mgmt-console,web-mgmt-compat,web-scripting-tools,web-mgmt-service

數據庫系統：

SQLServer 2008R2 或更高 （建議 SQL 2008 R2）

若采用阿里云部署，建議如下

阿里云服務器ECS（基本配置：4CPU、16G內存，80G高性能系統硬盤，200G高性能數據盤，云服務器數據庫易云備份（包年）、3M帶寬、日常運維快照服務、Windows2012R2 64簡體中文版本，WinSQL 2008 R2數據庫）

客戶端使用要求

用戶是通過瀏覽器打開程序并使用的。我們的瀏覽器是有要求的 。需要谷歌、360極速、IE11 、火狐等瀏覽器 （建議：谷歌瀏覽器）

系統實施的時候，需要準備的資料

1）常用合同模版

2）人員組織機構清單

合同審核-合同基本面全面審核

合同審核-稅務相關審核

1.體現了設計采購施工相融合的理念，同時考慮到各階段工作的特點

《工程總承包管理辦法》第3條規定，工程總承包是指總承包人對工程設計、采購、施工或者設計、施工等階段實行總承包，并對工程的質量、安全、工期和造價等全面負責的工程建設組織實施方式。從上述規定可以看到，工程總承包模式的核心在于設計、施工、采購各階段的深度融合，并由總承包人以“總包負總責”的一體化組織方式實施，而非各階段工作的簡單拼接。

2011版《示范文本》在體例設置上，采取了將設計、施工、采購、試驗等工程建設實施階段相關工作內容分別作為獨立條款的方式，例如分別規定了設計和施工的質量標準、進度計劃、變更范圍等。這種方式便于發包人根據項目實施階段的具體內容和要求，對相關階段的條款內容進行取舍，但也導致了各階段內容割裂分散和重復規定，體系邏輯缺乏整體性的問題。

2020版《示范文本》則采用了更為一體化的體例，體現了工程總承包項目中設計、采購、施工各階段的整體融合。一方面，在質量標準、開工日期、進度計劃、項目經理、變更調價、價款支付等主要內容上，范本均以整體工程為基礎進行了規定，以明確總承包人對工程的整體責任，便于其對各階段工作進行統籌安排；另一方面，范本也考慮到了各階段工作的特點，對設計、采購、施工、試驗、竣工、保修等各階段條款的順序和內容進行了梳理調整，使得其更加符合項目實施流程，并明確了各階段的工作內容和雙方權利義務。

2. 引入了“工程師”概念，并明確其管理職權

工程總承包模式中發包人在專業知識、項目經驗、項目控制程度上通常與總承包人存在較大差距，往往需要聘請專業的咨詢機構協助其進行發包和管理。同時，目前國家正在推行全過程工程咨詢模式，并鼓勵在政府投資工程等項目中采用工程總承包和全過程工程咨詢。因此實踐中，發包人聘請咨詢機構乃至全過程工程咨詢單位代表其對工程總承包項目進行管理的情形日見普遍。

2011版《示范文本》中僅提到了監理人的概念，但其職權和工作范圍較為有限，主要為傳統施工監理所涉及的質量檢查驗收、現場安全管理、下達變更指令等，在較為核心的合同管理、變更管理、價款管理、索賠管理中都幾乎沒有涉及到監理人，而是主要由總承包人與發包人直接進行溝通。

2020版《示范文本》結合國家推行的全過程工程咨詢政策，借鑒FIDIC黃皮書引入了“工程師”的概念取代“監理人”，并在內容上進行了調整，以更為貼合我國的工程管理實踐。范本中的“工程師”從定義來看既包括監理人，也包括發包人聘請的項目管理、造價咨詢、招投標代理等其他咨詢機構，以及負責統籌管理的全過程工程咨詢單位。同時，范本在第3.3款[工程師]、第3.5款[指示]、第3.6款[商定或確定]等規定了工程師的配套制度，賦予了工程師進行合同管理、設計管理、造價管理、質量管理、商定確定等職權，使其在合同管理中發揮更大的作用。最后，考慮到國內項目中發包人往往更為深入地參與項目管理，規定了對于發包人未委托工程師管理的特定事項，其職責自動由發包人行使。

3. 明確了發包人要求的定義、內容和相關責任承擔

“發包人要求”是描述工程目的、范圍、功能、技術要求等內容的核心文件，也是確定工程總承包范圍和合同履行要求的重要依據。發包人要求是否完整、準確、合理，直接影響發包人能否獲得滿足其合同目的工程成果。同時，由于發包人要求內容較多且地位重要，一般會作為獨立的合同組成文件明確列出。
2011版《示范文本》并未將發包人要求作為單獨的合同文件組成部分，而是分散在合同協議書、合同專用條款、合同通用條款、招投標文件、資料和圖紙等各類合同文件之中。除此之外，范本對于發包人要求出現錯誤應如何處理和承擔責任也未進行明確系統的約定。

2020版《示范文本》則將發包人要求明確定義為“列明工程的目的、范圍、設計與其他技術標準和要求”的名為《發包人要求》的文件，以區別于合同簽訂和履行過程中發包人提出的其他要求。同時，范本將《發包人要求》列為合同文件組成部分“專用合同條件”的附件1，其效力優先于“通用合同條件”和“承包人建議書”，并就其內容和編制要求提出了指導性意見。最后，范本就《發包人要求》存在錯誤的歸責進行了規定，要求發包人承擔因此導致的承包人費用、工期和利潤損失，但承包人有義務就發現的錯誤及時書面通知發包人。

4.對聯合體和分包的相關條款進行完善和細化

鑒于我國工程總承包市場仍在發展之中，很多企業僅持有設計或施工的單一資質，目前以聯合體或分包形式開展工程總承包的情況較為普遍。《工程總承包管理辦法》要求總承包人需具有設計和施工“雙資質”的規定出臺后，市場上組成聯合體承接工程的情形又進一步增加。
2011版《示范文本》中對聯合體進行了定義，并規定聯合體各方向發包人承擔連帶責任，但并未就聯合體的具體權利義務設定條款。分包條款則規定承包人和分包人應就分包工作向發包人承擔連帶責任；但承包人只能對專用條款約定的工作事項進行分包，否則需要經發包人同意；同時未經承包人同意發包人不得對分包人進行支付。

2020版《示范文本》專門設置了“聯合體”條款，并進一步規定總承包人應在專用合同條件中明確聯合體各成員的分工、費用收取、發票開具等事項，同時聯合體協議經發包人確認后應作為合同附件。在履行合同過程中，未經發包人同意，不得變更聯合體成員和其負責的工作范圍，也不得修改聯合體協議中與合同履行相關的內容。而在分包方面，則進一步考慮到在“雙資質”要求下，總承包人不得將主體部分對外分包，因此規定分包應按照專用合同條件的約定或經發包人同意后方可進行，但發包人逾期未提出意見的，承包人有權自行對外分包。同時，承包人應當對分包人進行必要的協調與管理，包括進行現場實名制管理等。

5.雙方風險和責任分擔更為平衡對等

2020版《示范文本》在起草初期也考慮了設置兩個范本，對應不同的發承包模式以及風險和責任分配，但最終僅保留了較為平衡對等的范本。一方面，范本借鑒了FIDIC黃皮書，在保密、保障、索賠、合同解除、提前預警、知識產權、設計責任等方面都設置了雙方對等的條款，并在安全生產責任、工程的照管責任等方面增加了雙方存在混合責任時的處理原則，盡可能平衡分配雙方間的風險和責任。另一方面，范本根據《工程總承包管理辦法》第15條關于風險分擔的規定，明確了發包人應承擔的價格波動、法律變更、不可預見的地質條件、不可抗力等主要風險，以及承包人有權進行合同價格調整的情形。最后，范本在第1.13款[責任限制]首次引入了責任限制條款，規定承包人對發包人的賠償責任原則上不應超過簽約合同價，進一步合理平衡雙方可預見的風險范圍。

我國目前的建設工程市場屬于“買方市場”，發包人處于強勢地位，通常會要求承包人承擔工程實施的大部分風險和責任，而在工程總承包項目中承包人承擔的風險和責任將進一步增加。風險和責任分擔的不平衡，一方面損害了承包人的利益，不利于市場的健康可持續發展；另一方面也可能導致項目爭議和事故頻發，發包人的合同目的無法實現。

我國之前發布的工程總承包合同范本在條款設置上總體較為平衡對等，但在某些方面仍存在約定不夠具體，或對承包人保護不夠的情況。其中《標準設計施工總承包招標文件》參照FIDIC黃皮書和銀皮書，按照風險劃分的不同設置了AB條款，供當事人根據自己工程項目的特點進行選擇。但實踐中，發包人作為招標人往往選擇對己方風險更小的B條款，較為平衡的A條款則得不到使用。

6.完善多級爭議解決機制，鼓勵雙方友好高效解決爭議

工程總承包項目體量大、時間長、工期緊、人材機投入巨大，并且由于發包階段較早，工程細節尚未確定，在項目實施過程中經常會發生爭議。如雙方在爭議初期就進入對立局勢，勢必對項目實施產生較大影響，甚至導致項目停工，造成雙輸局面。因此，在合同中合理設置多級爭議解決機制，鼓勵雙方友好高效地解決爭議，減少上升為訴訟或仲裁的可能，對項目的順利實施具有重要作用。
2011版《示范文本》中的爭議解決方式包括雙方友好協商、提請有關單位調解、進行仲裁或訴訟。盡管其中設置了多級爭議解決機制，但內容非常簡短，并且前置的協商和調解程序，本質上還是取決于雙方能否達成一致，在缺乏第三方有力介入的情況下，仍然較難高效解決爭議。

2020版《示范文本》借鑒2017版FIDIC合同等國際工程最新實踐經驗，就多級爭議解決機制進行了完善和補充。一方面，范本在第3.7款[會議]和第8.6款[提前預警]中規定，任何一方可請求就工程的實施安排召開會議，并應將可能產生不利影響的情形盡快通知對方，以確保雙方及時得知和著手解決潛在爭議；另一方面，范本在第3.6款[商定或確定]詳細規定了工程師的商定或確定程序，使得雙方就特定事項出現潛在爭議時，工程師可以及時介入協調雙方達成一致或就爭議事項暫時作出確定。最后，范本在第20.3款[爭議評審]中設置了將爭議提交專家進行爭議評審的解決機制，使得遇到爭議時可由專家及時協助雙方進行非正式討論并給出意見或建議，直至最終作出有約束力的爭議評審決定。但與此同時，范本也充分尊重當事人的意思自治，規定由雙方選擇是否采取爭議評審機制，并可自行約定該機制的程序、專家組成定、費用承擔、評審結果約束力等事項

一、合同管理系統目的

公司通過合同管理系統簽署的電子合同，可以在共好合同管理系統平臺輕松實現電子合同的草擬、 流轉、歸檔、查詢、下載等免費功能，解決紙質合同管理繁瑣、成本大等痛點，滿足企業無紙化辦公的需求。

二、合同管理系統需要實現的特點

高效便捷：全程在線管理，省去了線下打印、快遞、歸檔、查詢等流程。

成本可控：電子合同省去了紙質合同在管理、快遞中的時間和人力物力的成本。

永久保存：采用了異地容災、分布式架構、灰度升級等安全技術， 通過云合同簽署的電子合同將永久保存在服務器中。

在線存證：通過簽署的電子合同可以直接存證到公證處直接作為司法舉證使用，而紙質合同證明力低，鑒定程序繁瑣。

安全合規：通過時間戳、數字簽名、加密傳輸等技術，可以保證電子合同在傳輸過程中防篡改、防抵賴。

三、合同管理系統需要具備的技術能力

本地合同上傳：支持Word、PDF、圖片多種格式。

合同模板導入：總結公司自己的合同模板。

在線草擬合同：支持在線草擬合同，草擬完直接經過流程審批后簽署。

第三方合同管理：可以查看后臺草擬中、待簽名、已完成的電子合同，并支持關鍵字檢索、分類、查看或者下載