本文关于OA系统一体化供应商管理方案是什么样的，你怎么看？，据
亚洲金融智库2022-05-27日讯:
不清楚你具体需求是什么，给你一份之前的方案参考看是否有帮助。
1 项目概述1.1 项目目标
在招标人制度优化及系统建设项目建设过程中，期望应标机构发挥自身方法论、行业实践及专业优势达到如下项目目标：
1) 按照招标人制度优化及系统建设项目的要求建设办公应用系统,与当前办公系统集成，满足全员日常办公需要的功能需求和非功能需求。
2) 按照招标人对移动办公要求，开发移动办公模块，实现移动办公的功能需求和非功能需求。
3) 实现与财务办公系统、物采系统的接入和整合。
4) 实现业务数据从现有系统到新建系统的平滑过渡，包括移动终端切换、系统后台切换、数据迁移、新旧系统数据汇总、历史数据转换与查询等。
5) 项目拟建的系统和软件应完全覆盖和超越现有系统的功能和性能。在业务上除了满足当前的业务需要，必须具备一定的前瞻性，系统能够满足未来 5 年办公信息化需求。
2 项目范围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 项目要求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 周内给出针对该问题的彻底解决方案和改进建议。
专题推荐：
风险管控一体化系统(2)
