项目名称

技术参数

数量

采购预算(元)

品牌型号

第1包

合计

250000

校园信息化平台

一、 项目内容及要求

1.1 项目背景

黑龙江护理高等专科学校（以下简称学校），为满足学校发展和信息化管理的需要，建设学校信息化管理系统平台。

1.2 建设目标

本项目计划建立信息展示、业务流转、信息交换的协同办公平台，优化整合各业务系统的信息，并为领导提供决策依据。并为今后进一步深化应用打下基础。

系统应实现学校所有用户和应用系统的协同，提高办公效率，构建一个基于互联网的覆盖我校各个部门的协同办公、信息门户和应用集成平台，满足我校跨时间、跨区域、跨部门的协同办公需求。

1.3 总体技术要求

（1）明确系统架构，具有良好的开放性、扩展性、安全性、稳定性、实用性以及先进性。

（2）需提供成熟的协同办公平台应用，并能够结合学校的实际，具有很好的应用成熟度，数据的承载、展现、关联、流转、修改、报表分析能力等，平台本身具有较强的可维护性和扩展性。

（3）系统能够提供完整的接口规范以及针对第三方系统的Web service、API接口支持。

（4）明确开发语言，本项目建议采用可跨平台部署的JAVA语言为基础，平台本身需要基于B/S架构，能够支撑多种浏览器。

（5）需要能够支持多种常见中间支撑件、数据库名称、版本以及虚拟部署。

（6）充分考虑协同办公系统的安全保密性，具有严格的权限控制，将用户按一定的级别分类，可设置不同级别的用户访问、处理不同级别的经办流程和文件。根据不同级别和类别的用户进行访问权限控制、功能菜单的使用控制、流程及文件等的流向控制。用户身份鉴别成功后，当其空闲操作的时间超过规定值时，重新进行身份鉴别，当用户身份鉴别尝试失败次数达到规定次数后，对该用户进行锁定，只能由安全保密员进行解锁。充分考虑系统安全性，明确支持数字证书、动态验证码、动态口令等方式。能够实现提供基于角色的访问控制的权限管理，并提供相应系统实现说明。

（7）人性化的操作界面：界面美观大方，符合学校形象，同时系统操作更简洁、明确、友好。采用基于主题的设计方式，提供多套不同主题，个人用户改版调整非常便捷。

（8）系统性能要求：能够支持学校用户使用，，支持全天候的平台运作要求。

（9）系统架构要求：要求系统采用SOA架构，便于后期扩展；门户采用Portlet技术，支持自定义工作流，支持Web Service和消息中间件技术。

（10）需必要的网络安全和数据安全保障说明，保证系统的安全稳定运行和数据的安全使用。

1.4 系统总体功能

系统主要包括支撑平台（门户系统、工作流系统、文档管理系统、系统管理），公文管理系统、日程管理、日常公务管理、个人信息、邮件、报表、移动应用等。

1.5 支撑平台要求

1.5.1 门户要求

新建系统与现有业务系统实现用户统一管理，与学校数字化校园门户系统对接，方便业务应用系统的统一入口。

实现信息的集中发布，具有审核以及知悉范围的定义。

根据我校内部不同岗位、不同部门的工作范畴，建立内部的统一的、不同级别的信息门户，门户的展现形式、内容都可以根据用户的不同个性化的展现。

针对不同的门户可自定义分权管理维护者，并约束查看范围。由于所处部门、所在岗位的不同，用户可自行定义日常工作所需关注的信息及不同的处理事项。

对于一些基于B/S结构的信息系统，可在信息门户中可以看到各业务系统的页面或统计报表数据。

实现根据我校的形象快速调整信息门户的展现样式。并支持目前流行的各种浏览器。

权限要求：针对不同的门户可自定义分权管理维护者，并约束查看范围。

1.5.2 流程管理要求

建立统一的工作流程管理平台，进行跨部门的协作，支持工作流的分级管理和控制机制。

支持自定义各种简单到复杂的流程，从信息表单、流转步骤，到流转条件、操作人员等，可在平台中快速设置符合学校规范的流程。

工作流平台必须采用图形化设计器，实现流程定制功能，流程的定制能与组织结构绑定；用户可自行定义流程表单信息内容以及所需要审批的路径环节；对复杂流程模式的支持，如并行、回退、条件分支、自由流等；支持子流程嵌套以及流程脚本语言编写；支持对各流程环节的编辑和控制功能；支持委托授权、移交、流程干预、流程跟踪与监控等；和文档管理系统集成；能够支持针对流程表单的Excel直接导入功能。

流程节点的权限可多种方式实施：系统事先确定、流程发起者指定、根据前一结点的执行情况由前一结点的执行者确定、根据流程的执行情况由某一结点的执行者确定后续结点的流向及流程结点的执行者。

系统应能提供独立的具有自主产权的工作流程引擎、表单建模功能，并能够方便的实现工作流程与其他模块之间信息的协同。

实现内部流程管理优化，通过效率分析产生数据，帮助适时优化内部流程；

提供流程数据报表：自定义的流程和数据报表，快速呈现数据统计；

灵活的工作流程配置：从字段、表单到流程路径的全面开放，方便日常流程的变更和快速调整。在流程中查看关联数据，使得数据帮助审批人快速审批；

按照学校各单位的工作内容，建设相关的工作流程。

工作流除日常审批外，还应包括剧场使用申请审批；会议室使用申请审批；合同审批申请；教学材料和耗材审批；出差审批；财务报销审批等各个方面；

1.5.3 文档管理要求

对文档的存放、阅读和查找进行有效的组织与控制，并提供快捷的检索工具。

建立学校级文档管理机制，实现文档在学校范围内的共享和传递。将各种文档分门别类进行层次化的目录管理，使用关键字或全文索引，方便员工检索和查阅文档。实现对文档处理周期的管理，包括文档的撰写、审阅、批准、发布、存档等各个环节。对文档进行版本控制，保证用户所访问的是最新和有效的文档。实现文档处理过程的工作流自动化，如自动发送审批请求、自动催办等。能够实现档案与流程模块的自动推送、管控等细节点的打通。

有效地进行安全性控制，以信息技术的手段对各种文档实行分层次、分级别的权限管理，通过系统日志等手段对重要文档的使用情况进行监督管理。

1.5.4 系统管理要求

组织架构要按原协同办公系统中的组织架构和用户体系来设置。用户可通过传统树状的组织结构形式逐级查询人员、也可以自定义组、自定义查询等方法来利用组织树查询。

组织机构配置管理主要用于定义部门的组织机构图，通过定义部门的属性及其之间的关系，可以形成树状组织机构图，机构配置中常包含的项目有：部门编号、部门名称、部门发文字号、部门排序号等。部门信息来自人事系统。需要实现角色管理、权限管理、界面管理、日志管理、其他管理。

要有一整套非常灵活的基于对象权限和用户角色概念的授权机制。系统既可以提供完整的预定义权限，也可以根据应用需要，设置各种细微、具体的权限控制，包括了对系统内的每一个操作的权限授权与管理。为便于用户自身进行个人工作内容的管理，满足个性化的办公习惯及需求，需要系统自身具备个性化界面配置，布局及内容的自定义。实现对系统的管理安全，以及对突发事件的及时处理与追逆，需要对系统的登录、操作、浏览等进行记录与管理。并且可以根据实际情况对日志文件进行保留、删除，并且对日志文件的大小以及保管的期限做设定。实现系统正常运行的一系列维护工具。在系统管理模块中，系统需要提供工作流定制工具、公文表单定制工具、报表定制工具等多种系统自定义工具。其中的工作流定制工具需要基于流转引擎，完全可以由客户根据需要定义出各种流程，不需要编写代码。另外，系统也要提供了完整的备份和恢复工具，帮助用户在系统出现问题时能够快速恢复整个系统，保证系统的正常使用。

1.5.5 公文管理要求

公文流转是学校的基本业务工作。公文管理的主要目的是完成公文的提交、审批、督办、催办、转办、监控、登记、通知以及查询等全过程的电子化，实现对发文、收文、请示、信息报送等文件的起草、审批、签发、套红、打印、分送、归档等环节的规范化、电子化、效率化管理，便于查询和统计。我校文件分文号文，套头文，函文等。

1.5.5.1 发文管理

公文发文包括学校及下属院系、部门的发文。实现文件起草、审核、会签（并行会签/串行会签）、签发、转办、督办、催办、自动编号、套红、校对、盖章、分发等。发文管理主要对正文处理及流程进行功能增强。增加如下功能：

成文发文登记簿：可以依据选择条件自动生成按一定格式自动生成发文登记簿。

版本保留：在流程中的若干环节可保留word正文在多次修改中的不同版本，以备查阅。

返回任意历史环节：在流转过程中可返回到已经流转过的任意历史环节，如签发人可直接退还给拟稿人，从拟稿人处重新开始流转。

工作授权：若文件接收人对发文管理模块进行了工作授权，则处理发文的待办事宜将直接发给代理人，并在签署意见时留下代为处理的明显标记。

文件套红头：将文件正文在文印室成文阶段嵌入带红头的文件模板。

发布时自动转换为pdf格式。

规范部门发文字号。

1.5.5.2 收文管理

公文收文包括学校及下属院系、部门收文。在体系中，来文单位主要包括市政府、市教委、教育部及其他机关各部门、下级单位等。来文的形式包括传统的纸质文件和通过网络传输的电子公文两种。收文管理需要实现收文登记（支持扫描件、word、pdf、excel、wps、html等来文格式）、审核、拟办、承办（主办、协办）、传阅、催办，提供公文督办功能，通过设立公文监控员可随时调整流程情况，避免因流程意外影响收文正常流转。

成文收文登记簿：可以依据选择条件自动生成按一定格式自动生成收文登记簿。

返回任意历史环节：在流转过程中可返回到已经流转过的任意历史环节，如批示人可直接退还给收文秘书，从收文秘书处重新开始流转。

开放部分职能部门收文登记权限，如科研院、研究生院。

1.5.6 请示报告（邀请领导）

请示报告是学校内各部门经由办公室（或别的职能部门）在部门间批阅的途径。实现各部门请示报告的生成、部门意见的签署、办公室拟办意见的签署和领导批示等全过程的网上作业，实现流程的实时监控，保证请示报告单的安全、快速运转。需将邀请校领导功能融入请示报告模块中。

1.5.7 公文管理模块其他要求

必须支持不同版本的word、excel等office文档，也支持wps等国产软件的文档，支持视频、pdf、ppt等各种文档格式的存储。

图形化的流程显示，可以显示整个公文处理流程，即当前的处理节点，已经处理节点以及后续流程节点的图形化展示。

流转状态显示：可以显示每个流转节点的处理时间、接受时间、流转状态、处理人等信息。

公文统计：每月自动生成各部门公文办结报表，分类统计各种文件的流转情况，共多少文件，多少已办结、多少逾期未办结。

电子政务公文均应遵循国家规定相关规范。

支持从发文-公文交换-收文-归档全电子流程一体化的无缝流转，公文能够自动转为公告,发文正文可自动转为PDF格式。

对于纸质来文提供手动输入界面，录入来文标题、文号、发文单位、文件类型、附件信息、限办时间等信息，并自动生成收文编号和收文日期（录入日期），同时提供文件电子化扫描功能，并加盖收文章；可设置不同的范围和权限，同时提供状态跟踪和催办、督办、转办、撤办等流程控制功能。

文件流转中（包括主任转批、领导阅批、文件阅办环节），提供委托授权和强行干预功能，即如遇出差、请假等无法使用系统的情况，可选择提前进行委托授权，以免耽误文件的正常流转和办理，而委托授权后仍无法正常流转的情况下，允许文件管理部门或系统管理员使用强行干预手段，疏通文件流转的障碍环节。

提醒功能：文件流转到某一环节处，应在当事人待办事宜进行提醒；此外，当文件流转超过设定期限后，应在文件管理部门负责人和机要人员的工作界面弹出即时消息进行提醒。

期限设定：对于文件接收、所办转批、所领导阅批的环节，一般建议上限设定为一个工作日；对于仅需传阅的文件，一般建议上限设定为两个工作日；对于需要办理的文件，一般建议上限设定为文件中明确的限办日期之前。

催办督办：凡有权限参与文件流转的人员都可以随时查看文件的办理状态，提示公文滞留时间，系统可以自动对滞留文件进行催办，也可由文件管理部门进行人工催办；对于所有滞留办理的文件，自动生成文件列表，并支持直接打印输出功能，可形成报表导出。

自动归档：当上级来文阅、办全部结束后，由文件管理部门最终确认后，点击归档，自动实现文件正文、文件阅办单的归档保存。

公文管理，实现文件的起草、部门领导对内容的审核、所办对格式的审核，赋予文件编号，分管领导的签发，套印、归档、发布、调阅等功能，可设置不同的范围和权限。支持多级审批、会签、电子印章等功能，支持公文的回退功能。

公文起草界自动套用标准公文模版，实现与word软件的无缝对接，自动填入相关信息。

公文编号登记，当文件管理部门对公文格式进行审核，点击确认后，由系统根据文件代字和数据库中已登记信息，自动分配文件字号；其他信息由系统根据公文内容或文件拟办单进行提取，自动完成公文编号登记，自动生成登记日期、文件名称、文件编号、印制份数、承办部门、签发人等信息。

公文编号登记环节预留手动输入功能；回退的公文保留原有的公文编号。

公文处理流转进程中（包括部门负责人审核和领导签发环节），提供委托授权和强行干预功能，即如遇领导长时间出差等无法使用系统的情况，可选择提前进行委托授权，而委托授权后仍无法正常流转的情况下，允许文件管理部门或系统管理员使用强行干预手段，疏通公文处理流转的障碍环节。

可实现任意条件的组合查询，包括发文日期（指定日期或时间段）查询，对文件标题、文件字号、附件信息的模糊查询，对文件类型、承办部门的选择查询等。

领导签发后，自动实现红头文件的套印、加盖电子印章和归档；归档后，原则上不得再对文件进行修改，如确实需要修改，必须履行公文更改审批手续，审批通过后执行公文更改及审签，更改的公文保留原公文编号，更改完成后自动归档并替换原公文。

自动归档：当红头文件套印和加盖电子印章后，由文件管理部门最终确认后，点击归档，自动实现文件正文、文件拟办单的归档保存。

1.5.8 会议管理要求

现有系统中的会议管理模块与实际的会议使用有区别，现在会议室资源、会议安排、会议议定事项的督办等工作仍是全部靠人工管理，容易产生冲突和遗漏。要求实现会议室资源和会议安排信息一目了然，提供冲突提醒功能，实现会议议定事项与相关人员个人待办事项的关联。会议申请、审批，会议统计情况的实时发布，会议人员通知、会议资料传递、会议记录、会议决议下达、会议决议与日程的关联、会议决议执行和监控、会议决议执行情况汇总等功能。

会议前期准备中可以提供会议多个主题、参会人员通知（系统内、短信、邮件）、上会资料准备；会议召开过程中人员参与情况，会议纪要的分发，决议的确认；会议决议督办中会议决议产生的任务，通过会议督办模块，实现跟踪功能；会议资料沉淀帮助学校完成会议准备相关文档、会议纪要等资料的收集。

用户可以发起会议通知，选定时间、地点、主题、会议参会人员（到部门秘书或者直接到个人），参会人员可回执是否参加，并可转办请其他人代为参会。同时可以提交议题，文字和附件均可，并明确是否公开；确认有校领导参加的会议需同时填写邀请校领导的请示单，有校领导参加的会议需写进公共日程。会议议题管理：会议议题的申请和报送、会议议题的审定、会议议题的选择、会议资料的发送。预设模版：为了提高会议筹备效率和规范性，可以在系统中预设会议通知的模版供参考和使用。优化目前的周会表模块，对全校级的会议进行协调管理。从后勤会议管理系统中同步信息，列入周会表；如有显示在学校周会表里需提交校办审核后。

1.5.9 日程管理要求

日程管理实现日程录入、日程提醒、日程共享、日程公开、日程汇总等功能。并可以与其他办公模块同步，如与会议管理、计划任务、文档管理等。可与数字化校园门户系统对接。

1.5.9.1 领导日程

授权人员可以看到校领导的日程安排，秘书可以协助校领导填写日程。日程展现方式为：1. 某一天全部校领导的日程；2. 某校领导一周或者一月的日程；3. 全体校领导本周的日程。

1.5.9.2 学校日程

学校公共会议及日程安排，包括行政会议、学术会议、校园活动等三个类别。各部门秘书可以填写全校重要的公共日程，填写后需校办领导审核，确认后显示在公共日程里。

1.5.9.3 个人日程

可维护个人的日程安排，同时与手机端同步。

1.5.10 日常公务要求

1.5.10.1 通知公告

发布通知公告，可以向指定师生推送各种提醒、提示信息。通知可分层次，针对不同层级发送不同的通知。

1.5.10.2 印鉴管理

印鉴管理分为印鉴申请、注销和日常使用。印鉴日常使用是实现学校公章、法人章、钢印申请使用管理。部门可以通过网上申请开具组织机构代码证、法人证、介绍信网上申请、部门审批、校办登记等过程。

（1）用章单位或教职员工：需要盖学校公章、法人章、钢印以及开具组织机构代码证、法人证的单位或教职员工； 每个教职员工可以通过信息门户申请用章，并可查看审批结果。

（2）学校职能部处：负责初审用章材料的职能部处，包括财务处、人事处、教务处、研究生院、科研院、文科办、外事办等。

（3）校长办公室文秘科：负责盖章和盖章使用情况的登记、存储、查询、编辑等工作，以下简称校办。

校办主要为用章单位办理加盖学校公章、法人章、钢印以及开具组织机构代码证、法人证等事宜。盖章的整个流程可以分为盖章申请、材料内容审批、加盖印章等。

（1）用章单位或教职员工：在系统申请用印。申请人向学校相关审核部门提出用章申请；申请人将相关材料递交给相关职能部处审核等。

（2）职能部处或院系：负责初审相应的用印申请材料，部门对用章单位所提交的材料进行审核；审核通过后，提交给校办秘书，明确需要用印的类型、个数；若不通过，则退回用印申请。

（3）校办：接收来自职能部处提交的“用章申请单”， 校办秘书在协同办公平台查验后，给予盖章。

1.5.10.3 接待管理

对于各类考察访问，系统提供接待管理。包含接待事务登记、安排、审核、统计查询以及报销等。

接待登记：部门工作人员负责统一收集接待信息，详细记录客人的基本情况，包括人数、姓名、性别、民族、年龄、职务及时间、活动内容及要求等。

接待审核：部门人员提交后由部门领导审核，审核通过后可接待，接待完毕需填写产生的费用，再次提交审核，最后打印作为财务报销凭证。

统计查询：汇总统计，如可以按照费用，人数等统计生成报表。模糊查询，如可以就来宾单位，时间等进行查询。

接待管理主要实现接待任务申请、接待标准设定、接待任务审批、接待车辆申请、接待费用报销。

1.5.10.4 值班安排

学校两校区分别安排校领导和教职工进行值班；工作日安排晚班，节假日分别安排白班和晚班。各部门每学期初报送本部门分校区白晚班值班人员信息，校办编排发布值班表，所有教职工可在PC端和移动端查询各月值班表，并且在个人日程中提醒。

1.5.10.5 通讯录

提供界面供大家查询教职员工联系方式， 包括姓名、部门、办公电话、电邮、站内消息方式等。信息来源为人事系统。

1.5.10.6 文档相关信息

在公文审批过程中，比如收文、发文、请示报告侧边栏附上相关说明文档和示例文档即可。

1.5.11 个人信息管理

用户能够在信息系统中记录工作计划、日程安排、上下级工作的委派和汇报等一系列松散的信息。主要包括个人信息、通讯录、日程安排、工作委派、个人文档等。

1.5.11.1 个人基本信息

包括个人的基本信息，部门、联系方式等，从我校人事系统中获取数据。

1.5.11.2 个人日程

可维护个人的日程安排，若个人确认会议、活动等，可自动更新到个人日程。同时与手机端同步。

1.5.11.3 个人通讯录

可维护个人常用联系人通讯录，可根据权限查询学校工作人员基本信息，添加到个人通讯录。

1.5.11.4 委托授权

通过授权，可以将只有本人办理的事务在一段时间内交办给他人办理。

1.5.11 教务教学日志管理

可以按专业、班级管理教师的上课情况，包括授课日期、节次、课时、课程名称及授课内容，还要管理授课方式、授课地点、授课教师。

授课教师在上课前通过手机端即可填写教学日志，同时可以定位上课地点，上传授课信息的照片。建立每个教师的教务管理情况，个人的上课时间、地点（可提供地点定位）、课程安排情况，包括课堂现场的图片。能够记录教师的上课情况；

教务教学日志可以通过PC端及移动端分别展现；教务部门还可以按日期及教师名字查询日志情况，并对每位教师的日志进行统计汇总，并导出Excel表格；

1.5.12 微信集成应用(移动)

通过手机，利用移动网络连接到业务办公平台，实现微信企业号与协同办公平台集成及同步,达到移动办公目的。微信集成提供的主要功能包括最新信息、通知公告、待办事项、公文审批、公文处理、信息查询、日程、会议、通讯录、数据同步、系统设置、值班表、教务教学日志。

公文处理：待办公文列表：点击公文处理，显示待办公文列表；待办公文详情：点击经办过程和处理意见列表可以查看详情点击附件列表，自动下载附件，下载完成后会弹出对话框，询问您是否要打开；待办公文处理：点击公文处理按钮，进入公文处理页面， 点击按钮 ，进行审批人的选择，选择完毕点击确定；点击意见模版按钮，弹出常用意见，方便用户的操作。

通知公告：公告列表：显示内部公告详细列表；公告详细： 显示单条公告的详细信息。

通讯录：显示从服务器端同步过来的组织架构列表，并可以拨打电话，发送短信。可以查询或者按照组织树来找相关人员。

日程管理：管理自己的日程。

1.5.13 报表管理平台

信息化管理系统中的相关业务数据以及效率数据的梳理显得尤为重要，通过协同办公系统，系统提供了针对于所有自定义流程和表单的数据统计功能以及效率统计功能；根据用户配置需求，系统可以通过报表门户展示相关信息。比如说可以集中展示会议过程统计信息、公文处理过程统计、简报处理过程统计等等。

实现业务数据的综合分析展示，并提供管理驾驶舱功能。支持多种数据源，支持XML、Web Service等数据交换标准与服务；提供报表工具，提供算术公式和常用图表组件，支持基于地图、几何图形、仪表盘等的数据综合统计分析与展现。通过门户元素或门户菜单的方式将数据报表展示在门户上。基于角色的权限控制。

1.5.14 数据接口、数据集成

新建的协同办公系统要求扩展性好，集成度高。能够与我校未来的信息化系统数据共享与系统互联，即软件具有开放性及扩展性，未来能实现与其他第三方软件的扩展数据接口。

接口原则：保持数据一致性、保持数据的完整性、保持数据库的效率、数据库的安全性。

二、其它要求

2.1 相关标准和运行环境要求

（1）支持的标准：

门户产品必须支持JSR-286 (Portlet 2.0)标准

支持WSRP远程web service 接口标准

支持标准BPEL、JBPM等工作流标准

（2）产品运行环境

浏览器：要求支持主流浏览器，如：IE8-10，Firefox，Chrome等

操作系统：支持主流操作系统，如：Windows 2008、Linux、Unix等

应用服务器：支持主流J2EE应用服务器，如：Weblogic、

数据库：Oracle

网络环境：支持SSO、统一用户管理、门户分布式部署

（3）系统主要性能指标如下：

项目性能指标

注册用户数：本项目包含系统注册用户数≥500人；

在线人数：同时支持≥500人在线；

业务办理：单笔业务录入/修改的响应时间≤1秒；

单笔业务以外的其他业务响应时间≤3秒；

业务并发：系统至少支持峰值2500笔/分钟的实时查询或处理业务；

批量数据交换：非并发大批量数据交换≤2000秒/百万条；

查询：百万级数据量下单记录本地查询的响应时间≤3秒；

简单统计报表查询的响应时间≤10秒；

统计：百万级数据量下单项统计的响应时间≤5秒；

复合汇总统计响应时间≤120秒；

生成复杂统计报表的响应时间≤180秒；

系统稳定性系统能全年稳定连续运行，故障时间不超过1‰ ，导致业务连续停止时间不超过8小时，满足高峰时段数据交换的响应时间的要求；

2.2 实施

合理的、具有针对性的项目实施计划与解决方案。

负责完成客户化工作，满足招标文件要求的功能需求，同时还应满足实施过程中我校提出的具体需求，及时响应与完成客户化修改。

能够妥善分析我校业务中的复杂问题与个性化问题，并提出合理的解决方案，以保证系统实施不走弯路。

项目组织机构完整，保证实施期间有充分的实施技术人员保障，上线期间现场常驻工程师。

项目负责人与参与项目实施技术人员具有相关实施经验。

具有规范的项目组织与项目管理体系与方法。

2.3 开发维护

自验收之日起提供3年及以上免费维护。维护内容是指合同涉及到的功能、性能维护，其他如新增功能模块等要求除外。

系统出现故障时，技术人员到达现场小于8小时，做到1个工作日内解决。

提供项目相关技术文档资料。

2.4 时间的要求

本建设项目要求合同签订之日起30日内实施部署完毕。

2.5 项目培训

培训应贯串于整个项目的实施过程中，包括在从项目准备、研发到项目运行的全过程中。提供详细的培训方案、培训内容、培训计划、人员数目、开发工具、软件使用、后期维护。需要提供以下几方面关于培训的描述：

2.5.1 运行管理培训

为了使招标方相关人员掌握有关应用系统的使用、维护和管理方法，达到能独立进行管理、故障处理、日常测试和维护等工作的目的，应进行系统的技术培训，以保证所建设的系统能够正常、安全、平稳地运行。

2.5.2 培训要求

投标人派出的培训教员应具有丰富的同类课程的教学经验和应用经验；所有的培训教员必须用中文授课；投标方必须为所有被培训人员提供培训用文字资料和讲义等相关材料，如果培训地点在外地，投标人还应为所有被培训人员提供免费食宿；投标人应按合同规定安排培训时间和培训名额。

2.5.3 培训方式

包括课堂讲解、上机操作和实际工作的参与。

2.5.4 培训工作的内容和对象描述

投标人进行的培训工作包括：培训方案的设计、培训制度的制定、培训开发、培训实施和培训效果评估，及时监控培训效果，保证培训课程符合招标方的实际需要。在系统运行（含试运行）的各个阶段相应的培训内容描述，培训阶段安排包括：项目管理人员培训、系统分析人员培训、系统开发人员培训、系统管理人员培训、系统维护人员培训和系统使用人员培训。各个阶段描述包括：培训内容、培训教师水平、参加对象、授课时间和上机操作时间。

2.6 服务保障与承诺

投标人应承诺保证该项目按时正式稳定地运行，并承诺提供至少3年免费服务。投标人应承诺根据对招标方相关业务运作的规律来有计划地制定服务保障体系。

本项目一旦运行起来，就占有很重要的地位，稍有差错就会引起各方面的反映和损失，所以系统的售后维护服务和技术支持工作也应有足够保障。投标方作为具有丰富信息化项目经验的系统集成和软件开发企业，应通过自身不断的努力，针对客户的不同的系统的需求，制定不同的运行保障方案，建立完善的本地售后服务体系。

除了上述的有关承诺之外，投标人关于服务保障体系的描述应具体包括如下内容：

1. 运行保障机构

主要描述公司对于对本项目的运行保障能力描述。

2. 运行服务内容

投标人应确保本次招标的各类应用支撑平台安全稳定的运行，并承诺提供至少3年的免费服务，售后服务期自验收合格之日开始计算。方案中应对服务的范围和内容进行详细阐述，并至少包括以下内容：

1. 应急故障处理：系统运行环境出现故障或意外情况导致系统不能正常运行时，投标人响应的情况描述，包括针对不同故障级别的响应时间和响应内容。

2. 系统升级：提供应用平台的软件补丁版本的升级服务，质保期内如果有版本升级，小版本免费升级至新版本。

3. 文档服务：整个服务过程均需有完善的文档记录，便于跟踪、分析问题；对各项服务提供详细的书面报告，包括故障处理报告、健康巡检报告、系统性能检测调优报告、维护总表报告、服务年度报告等。

4. 运行支持：对系统运行过程中师生用户及业务部门的问题提供解答和问题解决跟踪，对于关键业务点的上线推广与运行提供现场保障。

5. 服务请求流程

投标方需对用户支持或维护请求处理的流程进行详细描述。

6. 服务请求方式

对招标方与投标方联系沟通的方式进行详细描述，以方便招标方便利的获取各类即时的和非即时的服务支持。投标方提供的服务请求方式至少应包括：服务热线电话和联系人、联系单位信息、信函/传真、电子邮件、服务网站。

投标人是否设有用户投诉受理电话对用户的意见做出反应。如果有用户投诉受理电话，请描述以下内容：电话号码（或传真）、投诉中心负责人和受理答复时间。

2.7 成果移交

1. 技术转移

通过本期项目的合作开发，将合作公司先进的开发技术、项目管理模式和经验与招标方的需求资源相结合，真正建立招标方的综合管理平台系统和专业技术队伍。同时，招标方的工作人员全面深入地参与开发的全过程，包括需求分析、系统设计、代码生成、测试运行以及使用维护五个阶段，掌握各个环节的主要技术，具有对软硬件系统平台、各个业务系统的技术维护能力以及二次开发能力，实现知识和技术的转移。

2. 交付成果和文档资料

在本期项目的开发过程中和交付使用后，要求将各个阶段产生的全面、规范的成果和文档资料交付给招标方，而且要提供明确的交付清单。同时，成果和文档资料必须符合软件工程的相关要求。要交付的成果和文档资料主要包括以下部分：

（1）可运行的系统。

（2）技术文档：包括项目开发中的各种技术文档，如开发环境配置说明、软件工具清单、需求分析说明、变更说明、系统设计说明、用户手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明等。3）管理文档：包括项目开发中的一些工作文档，如：计划、报告、讨论纲要、会议记录等。

（3）版权归属及使用要求：该系统的使用权为招标方完全拥有。

2.8 项目验收

1. 项目总体完成以后，须向招标方提交项目验收申请，招标方组织数字化校园工作组对项目进行验收。

2. 双方确定，按以下标准及方法对中标方完成的研究开发成果进行验收（上线、初验、试运行及终验）：

（1）上线、初验、试运行及终验标准的确定：由招标方和中标方根据合同内容、需求分析、技术协议及双方均认可的其他文件载明的内容，共同确定上线、初验、试运行及终验标准。双方及实际使用人根据上述标准共同完成上线、初验、试运行及终验。

（2）上线

中标方根据实施计划，向招标方提出书面上线申请。招标方应在中标方提出申请之日起3（三）个工作日内，给予是否同意上线答复，如同意上线，则在同意答复之日起5（五）个工作日内配合中标方完成上线工作。

（3）初验

中标方根据实际情况，向招标方提出书面初验申请。招标方应在中标方提出申请之日起3（三）个工作日内，给予是否同意初验答复，如同意初验，则在同意答复之日起7（七）个工作日内配合中标方完成初验工作。

（4）试运行

中标方根据实际情况，向招标方提出书面试运行申请。招标方应在中标方提出申请之日起3（三）个工作日内，给予是否同意试运行答复，如同意试运行，则在同意答复之日起7（七）个工作日内配合中标方开展试运行工作。

（5）终验

终验条件：招标方软件满足下列条件之一的，视为达到终验条件：

①系统安装调试完成，软件进入试运行后 6 个月，运行良好；

②中标方实施完成，具备进入试运行条件满 6 个月，但由于非中标方原因未进入试运行。

终验的进行：

①中标方根据实施计划，在软件达到终验条件后，向招标方提出书面终验申请。

②招标方在收到申请后应在5（五）个工作日内回复中标方申请，如拒绝中标方申请应详细说明原因并及时和中标方取得联系；如同意验收应及时组织对软件运行情况进行测试、验收，及时发现并提出软件运行中的重大问题，提交中标方立即整改。如招标方未发现软件运行重大问题，则视为终验通过，进入系统维护阶段，并将终验结果在5（五）个工作日内通知中标方。

③软件运行中的细节性修改和完善调整，以及个别功能模块由于招标方内部原因的需求未确定、应用不够等因素不影响项目的终验，上述问题在维护阶段逐步解决。

④招标方如在中标方提出正式书面终验申请后无正当理由拒绝中标方申请，或在中标方提出正式书面终验申请后1（一）个月内未就软件质量问题向中标方提出书面异议或招标方已安装中标方开发的软件，都将视为软件终验合格。

2.9 报价的要求

1、投标报价应包含系统开发、安装调试及售后服务等费用。

2、系统按功能模块分别报价。

1

250000

TH-ERMS电子管理系统；

朝阳软件V1.0；

OA上海泛微

总计

250000