上海招标网

一、项目名称：

东航新一代PSS之票证管理系统2.0采购项目

二、项目编号

JZTP ***

三、项目内容及需求

东航新一代PSS之票证管理系统2.0采购,具体内容见附件

四、供应商资格要求

（1）注册资金大于或等于1000万人民币。

（2）行业资质：具有良好的商业信誉和健全的财务会计制度，提供2013年-2016年财务报表；有依法 (略) 会保障资金的良好记录，提供近三个月的 (略) 保证明；具有良好的售后服务体系，能提供良好的技术支持。

（3）不接受被列入东航《供应商黑名单》及有违法违规记录的供应商报名。

四、供应商报名截止时间： * 日，需携带材料：

（1）企业法人营业执照

（2）税务登记证

（3）组织机构代码证

（4）财务报表

（5） (略) 业资质文件

（6）相关产品供货合同原件

（7）…………

五、供应商报名地址及联系方式

报名地址：上 (略) 内空港三路99 (略) 120室

联系人：王浩

联系电话：021- ***

邮箱： * eair.com

六、其他要求

1、对于未在东航电子采购平台注册过的新供应商，请报名同时在东航电子采购平台（网址 *** ） (略) 上注册，并于X月X (略) 上注册和品类认证，否则无法参与此项目询价。

技术需求:

技术需求说明书

1. 项目背景和定义

1.1 项目背景

随着全球航空附加服务的迅速发展及日 (略) 竞争环境下，旅客的诉求不仅是方便、 (略) 方式，更需要个性化、 (略) 体验。同样，航空公司的综合竞争力不仅体现在安全，准点的航空运输上，更体现在持续创新产品和服务，不断满足旅客需求等方面的能力上。根据公司的战略转型规划，实现从传统的单一航空承运人向综合服务商的转变，将航空运输产品和旅客日益个性化、精细化的诉求结合在一起，大力拓展附加服务业务， (略) 新的利润增长点。

2016年9月票证管理系统一期上线后，实现创建符合IATA EMD标准的票证库存，支持票证状态变化的业务规则校验和状态变更控制，标准的结算销售、运输报文组装解析等功能。

票证管理系统二期（iDoc2.0）建设将完成电子客票（ET）和电子杂费单（EMD）数据的存储关联及对外提供相关票面查询。基于IATA标准的票证管理体系可采用灵活配置方式全面支撑东航个性化附加服务产品，并完整支持包括销售、交付和 (略) 有业务流程，实现业务全流程闭环管理。

1.2 项目定义

东航新一代票证管理系统（iDoc2.0）是创建自有的EMD票证库存，实现EMD附加服务和非航产品的票证管理。支持销售到结算确认收入、报表统计的全闭环流程。

2. 项目建设目标与原则

2.1 项目建设总体目标

1. 1.0基础上完整存储EMD及ET数据，为EMD-A类型附加服务提供票证支持

2. 在IATA EMD的标准之上，支持东航个性化附加服务产品。

3. 实现100% IATA EMD标准推广， (略) 有纸质单据。

2.2 项目建设原则

2.2.1 统一性原则

(略) 业相关技术规范，严格遵循统一性建设原则。

2.2.2 整体化原则

采用先进的技术平台，通过统一的系统或体系，实现对东航自有票证及航信电子客票、电子杂费单票证管理业务运作的全面支持。

2.2.3 适用性原则

要求系统软件建设方案满足东航现有业务和技术需求，并至少满足未来3至5年业务发展的需要。

2.2.4 先进性与实用性相结合原则

基于业界开放性标准，采用先进的技术和产品，兼顾技术的成熟度，选择符合发展趋势的业界主流的技术架构。

2.2.5 开放性与可扩展性原则

支持多种硬件平台，采用通用软件开发技术、第三方开放的组件产品，具备良好的扩展性和可移植性并提供系统API。

2.2.6 安全可靠性原则

具备 (略) 全可靠性，并通过采用多种安全技术手段保障系统软、硬件 (略) ， (略) 络和信息 (略) 的要求。

2.2.7 可维护性原则

软件应具备高可维护性，便于功能的加载、扩展、更新和修正。

3. 项目实施范围

供应商作为本项目的主要软件开发供应商， (略) 署业务知识的提供、软件方案的设计、产品定制化开发。 (略) 分，包括但不限于以下几个方面：

3.2 整体方案建议与实施

依据票证管理系统2.0项目的业务需求和实现技术，协助东航制定与实现票证管理系统2.0建设和业务变革的路线图。

对软件 (略) 详细说明以及从如 (略) 署建议并提交完整的软件平台实施方案：

a) 评估现有业务量和业务转型后的业务增量。

b) 根据业务特点给出合理的产品建议、功能说明和建议配置清单。

c) 根据交易量及交易特点给出合理的硬件配置建议、功能说明和建议配置清单。

d) (略) 署要求给出第三方软件配置建议、功能说明和建议配置清单。

e) (略) 署环 (略) (略) 络环境建议、功能说明和建议配置清单。

f) 根据产品数据要求和对业务的理解给出数据和接口建议、功能说明和详细数据项清单。

g) 结合东航现有业务状况，对 (略) 说明，如果对东航 (略) 门有特殊要求的必须详细说明。

h) 结合东航已建的存储系统给出票证管理系统2.0的存储和备份方案，充分考虑对东航现有资源的有效利用。

i) 详细阐述项目中对甲方的其他要求。

3.3 软 (略) 署

根据整体方案，结合东航需求与特点，对 (略) 定制与配置，明确各业务单元输入输出规格，整合东航业务流，在东航本地参照系统应用最佳实践和实际项目经验对 (略) (略) 署并协助东航启动与适应新方法与环境。

3.4 软件产品测试

制定全面的功能测试、性能压力测试、用户验收测试等测试计划和测试用 (略) 。

3.4.1 测试计划

a) 调研和明确测试需求。

b) 进行测试和上线风险评估。

c) 明确测试资源。

d) 制定软件产品测试计划。

3.4.2 测试设计

a) 制定测试案例。

b) 制定测试流程。

c) 检查并评估测试的涵盖度。

3.4.3 测试实施

a) 记录和编写测试脚本与测试用例。

b) (略) 数据清单。

c) 执行测试流程。

d) 评估测试的完成。

e) 验证测试结果。

f) 分析研究异常结果。

g) 记录缺陷。

3.5 数据迁移与装载

对后续多个接口和数据提供 (略) 质量跟踪和阶段性以及最终验证。根据上一阶段产出向新系统中的数据装载或迁移。保障数据装载或迁移的数据准确性、完整性以及高效率。

3.6 质保期支持

系统终验通过后1年内的免费技术支持服务。

4. 系统需求

(略) 分分为功能性需求、业务变革需求和非功 (略) 分。

功能性需求将考察供应商提供的软件系统在票证管理系统业务 (略) 功能，是对供应商提供的软件系统在该环境下必备的功能性要求也是评价供应商提供的软件系统对业务理解程度与覆盖度的重要指标。除必有功能外，供应商还需提 (略) 功能列表。

对供应商提供的软件系统主要功能需求及功能需求细节如下：

4.1.1建立ET电子客票销售库和票证库

1、使用PSDP实时数据解析ET票证出票、退票、废票、状态更新等操作（多票的连票组合、票号同步、连票的票号同步）

2、提供销售库提供出/退/废销售记录，票证库提供票证的操作历史。

4.1.2ET、EMD数据解析及入库

使用PSDP实时数据解析ET、EMD票证出票、退票、废票、状态更新等操作（多票的连票组合、票号同步、连票的票号同步）

4.1.3票面查询完整性保证

含票面数据完整性及票据关联的完整性

1、DETR/DEMD仿真接口调用。

2、PSDP实时数据解析。

3、数据检查。

4、与本地数据比对。

5、按逻辑拼装并存储。

6、数据的历史回溯。

4.1.4产品规则管理

1、规则新增、修改、生效、定时任务、预览、权限

2、解析事件，检查规则（结合Redis优化出、退、废、换开等操作时的规则校验）

4.1.5票证数据关联及解关联

1、ET、EMD票证关联及解关联，即ET和EMD状态变更时两者关联及解关联。

2、ET、IDOC票证关联及解关联，即ET和IDOC状态变更时两者关联及解关联

4.1.6出票基础校验

1、IATA标准，对数据项完整性做检查，如票号、姓名、航段、三字码等。

2、 (略) 门要求，处理重复出票检查（按具体产品性质结合渠道号、订单号等因素根 (略) 理）。

3、根据产品规则设定相关约束，如金额、航班、地理区域、白名单、退改限制（是否含手续费）、coupon数等等。

4.1.7产品支持

1、渠道对接，根据票证标准接口提供各渠道相应的个性化配置及维护。

2、产品支持，票原因代码、出票规则设定、销售报文组装、实时状态更新（支持套票类、权益类、升舱类）。

3、升级改造，用户接口（条件查询接口；标准的XSD）。

业务变革需求，指供应商应帮助东航完成系统上线后的组织转型和业务调整，以实现业务和系统之间的有效匹配。

4.2.1现状分析及风险评估

分析东航现有业务特点和问题，替换并优化原有的业务流程，其优化价值在于提高结算效率、提 (略) 理能 (略) 管理效益。同时，结合已经实施的成功案例，对东航上线系统可能会面临的 (略) 充分评估。

4.2.2业务流程

根据系统需要，建立收益管理各岗位工作的业务流程，并最终形成文档。

4.2.3本地支持

系统上线后，提供本地技术支持，为东航提供及时、现场的服务。

非功能需求是对供应商提供的软件系统 (略) 能力的考察和要求， (略) 效果密切相关，是评价 (略) 效果、成熟度和可维护度的重要指标。

4.3.1易用性

a) 软件应具有容易被理解和使用，具有详细的帮助信息等，系统参数的维护与管理以及数据的导入导出均通过操作界面完成。

b) 个性化的界面设计，界面简洁规范，美观大方，操作方便；具备人性化、简单的人机交互方式，减少客户误操作率。

4.3.2可维护性

a) 分析定位问题容易、软件产品使指定的修改容易实现、防止意外修改导致程序失效、软件修改后容易测试。

b) 使系统管理员集中方便地配置、监视、控制、诊断整个系统，并且能够监视和控制用户情况，快速定位故障点，及时消除隐患。

c) 对于系统各功能模块的配置、控制、监视、诊断等工作能够通过专用的系统管理工 (略) ， (略) 专门的编码工作。

4.3.3安全性

a) 具备安全管理机制，保证信息存储安全、 (略) 理安全，保证系统 (略) ，不被非授权访问，不被攻击破坏。

b) 根据用户业务环境，从软件架构方面提供多种角色认证方式，按组织结构划分操作人员的操作权限，且各 (略) 能调用的应用软件模块可按要求自由组合，由系统管理员统一配置。并保证在实际业务操作中各业务权限的隔离。

c) 保证数据操作和系统功能操作权限的安全性，系统建立完善的备份和数据恢复功能。

4.3.4可追溯

a) 建立集中式、可查询和备份的系统操作日志。记录用户事件，如登录、修改、更新等。

b) 可以对用户在软件系统中 (略) (略) 后期审计。

4.3. (略) 级监控

建立应用系统监控报警机制，实时监控与反应 (略) 情况，及时发现系统问题并给予报警。

4.3.6系统方案完整性

根据功能需求和其它实施要求，供应商需在软件架构、软件功能、实施服务、售后保障等多方面提供完整的票证管理解决方案。需要供应 (略) 完整、细致地描述。

4.3.7软件参数化配置

实现完全模块化设计，支持参数化配置，支持组件及组件的动态加载。

4.3.8扩展性

a) 系统应具备较强的扩展能力，支持东航收益控制领域未来5至10年的发展要求。需要描述如何在不改变技术基础架构的前提下，增加额外的业务功能以及软件负载能力。

b) 根据东航发展规划描述如何实现软、硬件平台的升级。

4.3.9可靠性

a) (略) 错误导致软件失效、软件出现 (略) 理、失效情况下易恢复，且完整恢复到失效前。

b) 软件应能够7×24小时连续不间断稳定工作，运行可靠率≥99.99%，出现故障应能及时告警，软件系统应具备自动、手动恢复措施，自动恢复时间≤15分钟，以便在系统发生错误时能够快速地 (略) ，同时软件系统应能有效防止因系统资源消耗过多而导致系统异常崩溃。

c) 详细描述软件平台的冗余和负载均衡设计。

整体可用性基于多个服务和组件的可用性，需要详细描述各个组件的服务的可用性、硬件平台的冗余和负载均衡设计、软件平台的冗余和负载均衡设计描述、在线备份和增量备份方案，集中存储方案。

4.3.10兼容性

软件解决方案应具有在多 (略) 的能力，对通用硬件和第三方软件均 (略) 支持，可以在不同平台中平滑移植。

满足向下兼容的要求，软件版本易于升级，任何一个模块的维护和更新以及新模块的追加都不应影响其他模块，且在升级的过程中不影响系统的性 (略) ，保证系统可以稳定、平滑过渡。

4.3.11互操作性

详 (略) 用技术架构以及和东航主要业务系统的接口交互。

4.3.12可移植性

适应不同平台、容易安装、可与其他软件共存。

4.3.13软件性能

要求供应商提供在收益管理转型后的业务量预估，并提供完整的硬件架构建议，在此架构之上保证达到以下指标。

4.3.13.1主要性能指标

a) 软件可支持不同类型用户200人并发访问不同类型业务。

b) 软件GUI平均响应时间≤5秒。

c) 每查询请求最大响应时间≤2秒。

d) 每查询请求平均响应时间≤1秒。

e) 每销售请求平均响应时间≤0.1秒。

4.3.13.2软件可用性指标

a) 保证软件进程7×24小时不 (略) 。

b) 软件进程日常平均CPU占用率小于30%，忙时小于65%。

c) 软件进程日常平均内存占用率小于40%，最大并发时小于75%。

4.3.13.3软件可靠性指标

a) 软件整体平均无故障率≥99.99%。

b) 软件系统应具备自动或手动恢复措施。

c) 在充分备份情况下，系统意外宕机后的恢复时间不超过4小时。

4.3.13.4软件容错性指标

a) 集群中一台主机宕机或应用进程失效，另一台主机或应用进程仍然可以正常工作。对系统的性能没有大的影响。

b) 软件产品出现BUG时，确保业务数据一致性。

c) 供应商要在谈判响应文件中对以上容错性指标提出具体的解决方案。

d) 系统提供报错保存进入日志，并支持根据情况控制日志输出详细程度。