OA系統一體化供應商管理方案是什么樣的？

不清楚你具體需求是什么，給你一份之前的方案參考看是否有幫助。

1.1 項目目標

在招標人制度優化及系統建設項目建設過程中，期望應標機構發揮自身方法論、行業實踐及專業優勢達到如下項目目標：

1) 按照招標人制度優化及系統建設項目的要求建設辦公應用系統,與當前辦公系統集成，滿足全員日常辦公需要的功能需求和非功能需求。

2) 按照招標人對移動辦公要求，開發移動辦公模塊，實現移動辦公的功能需求和非功能需求。

3) 實現與財務辦公系統、物采系統的接入和整合。

4) 實現業務數據從現有系統到新建系統的平滑過渡，包括移動終端切換、系統后臺切換、數據遷移、新舊系統數據匯總、歷史數據轉換與查詢等。

5) 項目擬建的系統和軟件應完全覆蓋和超越現有系統的功能和性能。在業務上除了滿足當前的業務需要，必須具備一定的前瞻性，系統能夠滿足未來 5 年辦公信息化需求。

2.1 總體需求

為實現制度優化及系統建設項目的穩定性和靈活性，制度優化及系統建設項目技術上將

緊密依托 H3 流程引擎開發平臺，通過配置為主，代碼編寫為輔的開發模式、構建以下模塊：

l 門戶網站：建設公司外網和內網的門戶網站，包括但不限于：門戶網站及網站對應的后臺內容管理系統，風格上突出企業特色和企業文化宣貫。

l 工作臺：建設面向全員辦公的工作臺，包括但不限于：全員相關日常辦公流程管理、知識管理、會議管理、任務管理、郵件管理、日程管理及對應的基礎數據管理。

l 合同管理：實現合同管理模塊，并在工作臺中進行集成。

l 移動端建設：基于招標人現有移動端 APP，建設面向管理人員審批的移動 APP。基

于招標人微信平臺，完成面向全員常用流程的移動化辦公，包括不限于考勤管理。

l 外部系統接入：在工作臺中實現對財務、物采、即時通訊等辦公系統的接入。

l 數據遷移：新系統正式上線后，舊系統的所有數據需要無縫遷移到新系統中。數據包括不限于現有 OA 系統、合同系統、物采系統、財務管理系統的數據。

2.2 制度優化及系統建設項目需要完成的業務功能說明

2.2.1 門戶網站主要系統功能

2.2.1.1 外網門戶展示

面向外部訪客的門戶網站，包括不限于公司簡介、公司新聞、行業動態、產品服務、外部招聘等。風格簡潔明快，體現企業特色。

2.2.1.2 內部門戶展示

面向公司內部員工的門戶網站，通過公司新聞、行業動態、內部表彰等形式，突出門戶企業文化的宣貫作用，風格要簡約，重點突出。集成員工工作臺入口。

2.2.1.3 門戶內容管理系統

通過內容管理系統，實現內外部門戶以及微信新聞內容的動態發布，支持圖片、文字、視頻信息。發布界面友好，發布內容支持格式調整，支持預覽功能，支持預制模板。

2.2.2 工作臺主要系統功能

2.2.2.1 流程管理

面向全員的流程集成，實現流程的發起、流轉、歸檔功能。在發起環節支持樣例查詢、

流程引導等便捷操作，降低用戶使用的難度；審批環節支持歷史數據檢索、決策數據展示等輔助決策操作；對跨領域的場景化流程，要通過流程環節的集成展示，便于員工操作。

支持系統內、郵件、微信的消息提醒。

2.2.2.2 辦公輔助功能

提供便于員工辦公的輔助功能，包括不限于會議管理、任務管理、知識管理、郵件管理、日程管理等。

2.2.2.3 外部系統集成

在工作臺中，集成現有的物采系統、財務管理系統、物資采購系統等，支持功能權限分配，系統集成在安全的基礎上，突出用戶使用的友好性。支持對及時通訊系統、outLook 的集成。

2.2.3 移動終端主要功能

2.2.3.1 移動 APP 主要功能

基于招標方的面向管理人員的審批 APP，完成用于支持制度優化及系統建設項目涉及流程的審批、決策性報表的移動展示。

2.2.3.2 公司微信平臺主要功能

基于微信企業號，完成面向全員日常常用功能。

2.2.4 合同系統主要功能

實現對公司合同全生命周期管理和統計查詢功能。

2.2.5 版本內容

2.2.5.1 1.0 版本內容

完成需求梳理、系統架構、業務規劃，并通過招標方評審；

完成內外網門戶開發；完成工作臺開發；

完成移動端 APP 主要功能；

完成現有流程遷移、修改和新流程開發；完成場景化差旅流程開發；完成部分輔助應用開發。

2.2.5.2 1.1 版本內容

完成合同管理模塊開發；實現場景化流程開發；

完成微信全員相關功能開發；完成輔助應用開發。

3.1 功能需求分析要求

投標人根據招標人業務需求，利用投標人在信息化建設方面的經驗對系統需求進行完善，

并對系統進行功能需求分析和需求管理。投標人輸出的需求分析成果需經過招標人的評審，并根據招標人的要求對輸出成果進行修訂，直至滿足要求。

3.1.1 功能需求分析交付物

制度優化及系統建設項目的需求規格說明書，在功能需求說明書提交前根據項目計劃提交頁面示例。

3.2 非功能性處理需求

制度優化及系統建設項目應包括但不限于以下的非功能性需求：

3.2.1.1 可靠性、可用性和完整性

系統應至少但不限于滿足以下能力：

l 7 x 24 小時穩定運行。

l 工作日故障恢復時間 2 小時，非工作日故障恢復時間 24 小時；

l 應用崩潰重啟后，關鍵業務狀態可以快速恢復。快速恢復的前提是數據沒有丟失，數據在物理上完整性和業務上的一致性。

3.2.1.2 松耦合結構

要求各個子系統/功能之間耦合度盡可能低，不能因為一個子系統/功能出現問題立刻就擴散到其他子系統/功能，導致對業務服務的大面積故障。

3.2.1.3 標準化外部系統接口處理

為滿足統一辦公需求發展，制度優化及系統建設項目需具備與外部應用系統的集成能力。

系統方案需滿足：

l 滿足具備與各外部系統的數據交換能力；

l 滿足具備與各外部系統的應用集成能力。

l 統一的對外應用接口服務能力；

l 接口服務的高安全性能力；

l 接口服務的擴展性能力；

l 接口服務的穩定性能力；

l 接口服務的高并發行能力。

3.2.1.4 分布式處理能力

制度優化及系統建設項目需要具備分布式處理能力。

應至少但不限于滿足：

l 分布式的數據存儲能力；

l 分布式的計算能力；

l 分布式系統快速部署、備份、快速重建和快速恢復能力；

l 滿足系統服務 7 x 24 小時不間斷能力。

3.2.1.5 業務可擴展性

招標方業務處于高速發展的階段，為支持未來的業務開展，需要制度優化及系統建設項目提供靈活可擴展性。包括但不限于下面的擴展性：

l 服務能力的橫向擴展性，隨著招標方人員和業務的發展，可以通過增加服務器數量增強系統的業務處理能力。

l 功能擴展性。要求各子系統/模塊/功能之間耦合度盡可能低，各子系統/模塊/功能之間通過標準化的接口進行數據交互，保障各子系統/模塊/功能的高可擴展性。

3.2.1.6 高性能要求

投標人提供的總體技術方案應能夠滿足制度優化及系統建設項目未來 5 年的業務需要，至少需要支持如下業務規模：

l 支持 1000 人員規模使用，200 人同時在線。

l 在 5 年數據量的基礎上，50 人同時在線壓力下，支持報表內頁面打開響應時間 5 秒，支持非報表類頁面打開響應時間 3 秒，復雜頁面打開響應時間 5 秒。150 人同時在線壓力下，支持報表內頁面打開響應時間 10 秒，支持非報表類頁面打開響應時間 5 秒，復雜頁面打開響應時間 8 秒。

在滿足以上業務規模的前提下，技術方案還應該具備很高的可擴展能力，方案涉及的軟硬件均需要具備可橫向擴展的能力。

3.2.1.7 信息安全

制度優化及系統建設項目需通過招標人信息安全部門組織的信息安全測試。

3.3 概要設計要求

制度優化及系統建設項目的概要設計需要滿足以下格式和內容的要求。

3.3.1 概要設計的規范要求

3.3.1.1 概要設計的基本要求

概要設計作為項目的重要文檔輸出，必須滿足招標人的規范和要求。包括但不限于：

l 文檔及格式要求。文檔命名格式要求、修訂歷史要求、文檔章節命名和格式要求、各章節格式要求、圖表及說明要求

l 文檔評審要求。概要設計文檔需要交由招標人項目組進行統一評審，從格式和內容兩方面進行評審，評審不合格的文檔需要修訂合格后再評審，直到評審合格。

l 文檔版本管理要求。要求所有的文檔必須提交到招標人的配置管理庫上進行管理，所有的修訂都要有修訂歷史。

l 源代碼、文檔一致性的要求。要求保持源代碼和文檔的一致性，任何一邊修改后，需要在同一個版本內修改文檔或源代碼。

3.3.1.2 概要設計的內容要求

3.3.1.2.1 程序概要設計要求

要求所有的子系統、模塊、類都需要有概要設計。概要設計的內容需要包括：

l 系統，及系統的組成部分。子系統，及子系統的組成部分。

l 類，模塊與類的關系。類的主要方法和屬性，主要方法的流程說明。

l 主要業務的整體流程說明

3.3.1.2.2 數據庫程序概要設計要求

要求所有的數據庫表、視圖、存儲過程、包等實體都有概要設計說明，包括但不限于下面的內容：

l 表的說明，及表的字段屬性的說明，約束屬性的說明，鍵、索引等說明。

l 視圖的說明

l 存儲過程、函數、包的說明

3.3.1.2.3 接口設計詳細說明

要求所有與外部系統和內部系統之間的接口都要有詳細的接口說明，包括但不限于下面的內容：

l 同物采系統的接口詳細說明

l 同財務管理系統的接口詳細說明

l 同移動端 APP 的接口詳細說明

l 同微信企業號的接口詳細說明

l 同即使通訊系統的接口詳細說明

l 同郵件服務的接口詳細說明

3.3.2 概要設計交付物

制度優化及系統建設項目每一個子系統都需要進行概要設計。所有的概要設計文檔都需要招標人項目組進行評審，只有評審通過的概要設計才是有效的交付物。

所有的概要設計交付物都必須是有效的，正式的，并已經提交到招標人的配置管理系統進行配置管理。

3.4 代碼開發要求

3.4.1 符合發行管理平臺的代碼開發規范

所有代碼和配置都必須符合代碼規范約定，包括但不限于：

l 代碼必須符合招標方的代碼編寫規范要求；

l 代碼需完成單元測試，測試通過后才可提交到配置管理庫；

l 招標人項目組會組織代碼評審，對不符合規范和招標人要求的代碼將要求投標人進行修改，直到滿足規范要求為止。

3.4.2 符合招標人的版本管理規范

所有的代碼和配置都必須提交到招標人的配置管理庫中，并按招標人的版本管理規范要求進行相關的操作。包括但不限于：

l 所有代碼、配置文件、腳本文件、編譯文件、第三方依賴庫等必須提交到版本控制系統中

l 集成測試的版本必須且僅只能從版本控制系統中獲取。

l 除 H3 流程引擎開發平臺提供的庫外，第三方依賴庫必須經過招標人的確認才可以使用。

l 不得使用盜版和其他未得到授權的源代碼、庫、執行程序。

3.4.3 代碼開發交付物

需要交付完整的代碼、配置、腳本、編譯文件以及編譯輸出的文件。所有代碼開發交付物在交付前都需要招標人評審通過，未通過的評審的代碼交付物都不是有效的交付物。

所有的代碼交付物都必須是有效的，正式的，并已經提交到制度優化及系統建設項目的配置管理庫進行配置管理。

3.5 集成測試要求

3.5.1 測試工作范圍

按照需求文檔中的需求范圍，進行功能測試及性能測試，每輪測試通過后需分別出具具有明確測試結論的功能測試報告和性能測試報告；

投標人進駐現場后，應與招標人商討所測試項目的進展情況，并合理計劃安排各項工作；形成整個測試工作的詳細測試計劃。

根據上述描述的系統要求對軟件系統進行全面測試，至少應從應用系統的功能性、性能、易用性、可靠性、兼容性、可擴展性和用戶文檔等質量特性方面開展測試。

工作包括但不限于：

1） 制定測試計劃，設計測試用例和測試場景，執行測試，報告缺陷，分析測試結果，提交以上所有文檔。

2） 功能測試

a) 根據系統《需求說明書》，分析各功能點測試的優先級別。用戶經常使用、關系到系統核心功能、優先級別較高的功能點，測試覆蓋率應達到 100%；

b) 功能測試必須既包括正常輸入和正常業務流程測試，也包括對非法數據輸入和異常處理的測試，且對系統非正常操作的測試用例應占到總數的 20%-30%。

3） 性能測試：

a) 根據《需求說明書》等相關文檔，測試在大用戶量、大數據量和長時間連續運行等條件下，系統的響應時間和穩定運行情況。

b) 模擬系統真實環境，測試系統處理高峰數據量的性能指標。

4） 易用性測試：從最終使用者的角度，對系統界面風格一致性、友好性和可用性等方面進行測試。

5） 可靠性測試：對系統在運行過程的持續穩定性，包括系統的容錯能力和對數據的保護能力進行測試。

6） 兼容性測試：通過兼容性測試，確認應用系統軟件與相關的各種硬件設備、操作系統、相關支撐軟件以及其他相關應用系統的兼容性。

7） 可擴展性測試：通過系統可擴展性測試，確認應用系統軟件是否可通過開發新的軟件以保證功能的可擴展性；是否可通過開發或調整程序以達到性能的可擴展性。

8） 用戶文檔檢查重點檢查所提交文檔的完備性及與實際系統的符合性。

3.5.2 測試標準

投標人應在投標書中列出測試所執行的主要標準。

3.5.3 測試方案

投標人應根據測試工作制定相應的測試方案，完成《制度優化及系統建設項目測試方案》，方案內容包括但不限于：

l 測試背景

l 測試標準

l 測試流程

l 采用的測試方法

l 預期的輸出結果

l 參與各方的職責。

3.5.4 測試計劃

投標人需針對每一個系統制定測試計劃，完成《制度優化及系統建設項目測試計劃》。測試計劃中需規定被測試的對象、被測試的特性、應完成的測試任務、人員職責及風險等，確定要完成的測試活動，評估完成活動所需要的時間和資源，設計測試組織和崗位職權，進行活動安排和資源分配，安排跟蹤和控制測試過程的活動。

3.5.5 測試用例

投標人需根據測試范圍設計科學合理有效的測試用例及測試腳本，并對測試用例和腳本統一管理，要求測試用例具有可重復性、有組織性、可回溯性和可操作性；

3.5.6 測試實施及評估

投標人將獲得的運行結果與預期結果進行比較和分析，記錄、跟蹤和管理系統缺陷，測試后對測試過程進行分析評估，對各系統的缺陷進行分析評估并提出改進意見，最終提交測試報告。

3.5.7 安全測試

制度優化及系統建設項目需通過招標人信息安全部門組織的信息安全測試。

3.5.8 測試報告

測試報告和測試結果應包含但不局限于分析說明測試數據值的范圍（包括動態數據和靜態數據）。陳述經測試證實的系統缺陷和限制，陳述系統質量缺陷產生的原因，說明每項缺陷和限制對性能的影響，并說明全部測得的性能缺陷的累積影響和總影響。同時，對每項缺陷提出改進建議，包含但不局限如：各項修改可采用的修改方法；各項修改的緊迫程度等。

除過程性報告外，測試方需在測試通過后，出具結論性報告，包括《制度優化及系統建設項目功能測試報告》、《制度優化及系統建設項目測試性能測試報告》。

3.5.9 測試環境

招標人為測試提供系統工作所需的軟硬件測試環境，投標人將使用招標人指定的測試環境。測試所需專用軟件由投標人提供。

投標人應根據本項目實際情況在投標書向招標人提出測試環境的合理建議。

3.5.10 測試工具

測試工具及測試管理工具由投標人提供。

3.5.11 集成測試交付物

項目測試過程中，投標人必須提交（包含但不限于）下列文件：

? 整體測試規劃

? 測試范圍分析

? 測試方案

? 質量等級和評估標準

? 測試用例和測試數據

? 測試系統功能測試計劃、測試報告及測試缺陷日志

? 測試計劃、測試報告及測試缺陷日志；

? 進度及測試工作匯報

對于投標人提交的文檔，當招標人要求時，要經過招標人組織的評審，對文檔進行修訂需要進行重新評審。

3.6 新舊系統遷移、兼容性、歷史數據要求

3.6.1 系統遷移的基本要求

為了保障當前辦公系統涉及功能平滑遷移到遷移到制度優化及系統建設項目，中標方在項目上線期間，必須按要求完成從現有辦公系統到制度優化及系統建設項目的遷移工作。

投標人在技術方案中需要包含從現有辦公系統到制度優化及系統建設項目的遷移方案，遷移方案需要滿足下面的條件：

l 遷移過程中、遷移后的所有關鍵數據不丟失，特別是流程數據，歸檔數據。

l 遷移后，正在進行中的流程可以無縫流轉，已完結的流程數據可以查詢。

3.6.2 遷移工作投標人承擔的工作

中標方將承擔遷移主要工作，需要招標人協助和確認的工作，需要體現在遷移方案中。中標方承擔的遷移主要工作包括但不限于下面的工作：

l 制定遷移方案，并提供詳細的實施計劃，所有的遷移方案和實施計劃必須得到招標人的評審通過。

l 開發遷移過程中所需要的全部程序和腳本。

l 開發遷移過程中所需要的全部兼容性功能，滿足招標人對遷移過程中的功能和性能要求。

l 實施遷移過程。

l 保障遷移、及遷移后的系統功能的完整性、一致性的要求的其他事項。

3.6.3 兼容性要求

1. 移動終端應用軟件支持自動升級，兼容主流 Andriod 版本和 IOS 版本。

2. PC 版兼容 Win7、Win10，兼容 IE8 及以上、360、chrome、firefox、safari 等主流瀏覽器。

3.7 項目管理要求

3.7.1 入場時間、地點

投標人在收到中標通知書后，五個工作日內項目經理、需求分析師、UI 設計人員入場給招標人提供駐場服務。駐場服務地點為北京，具體地址由招標人指定。

除現場辦公用房和研發、測試所需服務器外，為完成項目工作所需的其他設施、設備和物品均由投標人自行解決，包括生活設施、交通設施、通訊設備、辦公設備等。

3.7.2 項目計劃管理

1. 項目必須編制進度計劃，要求采用 Project 編制，計劃應當涵蓋完整工作范圍，包括關鍵里程碑、任務責任人信息；項目計劃采用漸進明細原則，原則上最近 1 個月的任務分解的粒度不大于 5 個工作日，并體現任務之間的依賴關系。

2. 項目計劃應當通過招標人的審核，在項目管理平臺上發布并形成基線。

3. 項目經理應當根據實際執行情況對項目計劃進行及時調整，涉及到月度里程碑的調整應向招標方提交變更申請表；

4. 計劃應當每周五更新實際完成的百分比，并將更新結果同步到項目管理平臺；

3.7.3 項目質量管理

1. 招標方將針對關鍵里程碑進行評審應；

2. 項目重大質量問題應當及時向招標人報告。

3.7.4 問題與風險管理

1. 項目應建立問題與風險管理記錄表，記錄問題與風險，評估級別，明確責任人、解決日期。

2. 發現可能影響本項目、或項目群其他關聯項目的關鍵里程碑達成的高級別問題或風險，必須及時向項目管理組報告。

3. 并應當每周五更新。

3.7.5 溝通管理

1. 按規范填寫項目周報，在周報中準確匯報進展、是否延期及延期情況、主要問題及風險；

2. 定期發布項目周報；

3. 定期召開項目例會，對項目進展、下周計劃，問題及風險進行溝通。

3.7.6 項目周期

項目采用迭代和增量式開發方法，參考周期如下：

3.8 *資源投入和人員資質要求

投標方承諾至少投入 35 個人月來完成本項目，這是本項目投入資源的最低要求，如低于 35 個人月，將視為廢標。另外，由于本項目不是簡單的人員外包項目，所以如果投入資源達到 35 個人月，但沒有完成項目目標，也不能視為項目交付，需繼續投入資源，直至完成項目目標且通過招標方的驗收。投標方需要在招標現場提供工時承諾書。

具體投入項目的項目角色及資質要求見下表，項目經理角色可以和需求分析師/高級.NET 開發工程師人員重合：

投標人需提交本項目的組織結構、所有參與該項目人員的工作職責、常駐工作城市、工作簡歷、工作經驗說明及投入本項目的時間計劃，項目組所有成員提供半年以上的社保記錄證明。參與項目的項目經理、UI 設計師、需求分析師、高級.NET 開發工程師在駐場前需通過招標人的專業面試，如未通過，中標方需立即更換具備足夠技能的人員，直至面試通過；在項目過程中，若招標人認為中標方派駐人員不能勝任專業工作，中標方必須一周內更換人員，直至達到招標人的要求；拒不更換的，招標人有權終止合同。

投標人要保證項目經理、UI 設計師、需求分析師、高級.NET 開發工程師的穩定性,參與項目人員除招標人提出更換要求外，不得更換，如需更換，要征得招標人同意。投標人項目組成員在項目實施期間不得從事與本項目無關的工作。

3.9 培訓要求

3.9.1 知識轉移要求

投標人需要移交針對本項目的所有成果，并對招標人的研發、測試、運維人員進行系統性培訓，使其快速掌握并勝任相關工作。

投標人根據招標人的技術團隊，量身定做其匹配的知識轉移方案，方案內容包括但不限于代碼開發、系統部署等階段。以最終到達招標人團隊能夠實現系統的運維和后期開發工作。

3.9.2 用戶培訓要求

投標人需要提供對招標人系統用戶關于系統使用方面的培訓，包括課程設計、教材及課件編寫等。

投標人提供約 5 人天培訓。其他用戶的培訓工作由招標人自行負責。

3.10 技術支持服務要求

投標人需提供技術支持服務方案和服務承諾，投標人在投標書中必須明確承諾達到用戶的服務響應要求：

*系統終驗后 1 年內，系統出現不滿足《制度優化及系統建設項目需求規格說明書》中功能和非功能性需求的情況，由投標人負責解決。影響全員辦公的核心功能出現故障，需要在 2 小時內提供現場技術支持服務。

* 系統終驗后一年內，投標人提供一年的 7*24 小時技術支持服務，其中需要提供 7*10 小時的現場技術支持服務。非現場支持服務期間應提供電話服務，1 小時內做出明確響應和安排，電話支持不能解決問題，需要在 2 小時內提供現場技術支持服務，并在后續 1 周內給出針對該問題的徹底解決方案和改進建議。