1.       项目背景

目前使用的揽收系统是2000年针对上门揽收特快专递邮件和演出票而开发的系统，该系统能够实现的功能是把下单信息派单到各处理局，但因下单界面单一，近年来由于业务的增加，表单信息已经不能满足业务需求，很多信息是以文本形式存储的，致使无法实现业务数据的统计分析。

随着邮政业务信息化程度的深入，揽收系统信息的不规则存储导致和其它系统的数据交换存在困难，很多业务处理要同时操作多个系统，业务处理效率低下且容易出现操作错误。

为了提高业务处理效率和质量，协助11185电子商务中心发挥渠道优势，势必需要一个对业务处理全流程管理的揽收系统。

2.       项目目标

新的揽收系统能处理业务的全流程，能很好的和其它生产系统进行数据交换。系统定位为邮政业务订单处理平台，能处理来自邮政各个营销渠道（商务网站、11185话务、短信、支局、代理商等）的商务订单，支持网上支付、电话支付、营业厅收款、上门收款、汇款等支付方式。系统数据规范化存储，系统能统计各类营收结算报表，能在业务数据的基础上做BI分析，为邮政商务运作提供决策支持。

3.       业务需求

目前业务部门提供的需求主要在现在使用的揽收系统的基础上提出的，具体需求如下：

3.1.      整体需求

希望新的揽收系统能对业务的全过程进行管理，能和其它生产系统进行数据交换。

3.2.      网络鲜花/礼品

·增加“收款方式”、“产品名称（代号）”、“类别”、“配送日期”、 “合作商订单号”、“是否定时”等信息项。

·结算录入部分增加“合作单位”、“结算金额”、订货情况（是/否）、安排配送情况（是/否）、“说明”等，配送情况录入部分增加“配送人员”、“配送时间”、“配送结果”等信息项

·增加话务员工作量统计功能，能按日期（按日、按月）、揽收单位、业务类型、订单状态（185已确认、处理局已确认、揽收完成、185注销、处理局注销）、产品名称（代号）、数量、金额、话务员工号……等自行选择，采取自由组合成报表，并导出数据。（可多项选择，如订单状态选择处理局已确认及揽收完成。等等）

3.3.      处理局

处理局接收订单及录入数据的界面不相同，即处理局先到接收订单界面接收订单，待业务办理完毕后，到补录数据界面反馈办理情况，订单状态才能更改为揽收完成状态。

由于处理局界面操作繁琐，导致很多处理局不能及时录入数据，更改订单状态，使系统信息不准确，需要人工跟进订单情况。

3.4.      报表部分

·增加汇总表统计功能

·班结表、营业日/月报表

·话务员工作量统计

·揽收局确认定单情况统计

·所有报表需要增加导出功能（EXCEL），均可选择根据受理（或投递）日期按日（每一日的总量）、按旬、按月可以自行选择字段分别统计和导出数据

4.       解决方案

4.1.      业务分析

·流程分析

揽收处理流程分以下两种情况

1、信息交换的流程：

2、实物交换的流程：

3、两个流程可以抽象为：

揽收系统可以理解为以订单为主线的营销管理系统，商品以订单为载体做为订单明细参与业务流程。

·商品分析

目前在揽收系统上管理的商品很多，从大的类别上分为两类 “综合类”和“专业类”，现有的揽收系统采用两种表单形式来描述订单和商品属性，随着商品种类的增加，两个类别已经无法满足业务的需求，需要对营销商品进行重新分析规划以满足业务需求。从商品属性上看，综合类大多为一般商品（如：鲜花、票务等），可以统一在订单中存储陪送信息，商品编码、商品明称、单位、数量、价格、金额等资料，所以可以用统一的订单模式来处理；专业类为邮政业务，很多情况下需要使用各自独立的订单模式处理，如EMS揽收、港澳通行证再签业务除客户资料外两种业务需要存储的信息各有不同很难找到共性。

4.2.      系统架构

4.2.1.       架构说明

考虑到揽收系统作为统一的订单处理平台，要求具有较强的扩展性，能很好的和其它系统进行数据交换，特设计系统架构如下图所示：

（架构图）

从系统架构上看，揽收系统处理各营销渠道的订单，并反馈订单状态，在某些情况下需要和其它生产系统进行数据交换。揽收系统和各营销渠道之间以订单为对象进行数据交换 。系统各模块功能描述如下：

·基础数据管理

维护系统需要的基础数据，包括“组织架构、用户”、“客户资料”、“商品资料”、“网点资料”等。

·工作流处理平台

负责订单在整个深圳市邮政局组织架构内的处理过程及状态管理，工作流平台支持流程的灵活定义，在业务处理流程发生变化时只需要配置流程，而不需要修改系统功能，便于系统适合不同阶段的业务处理流程的调整。

·权限管理

管理全部用户的系统操作权限，能控制到某用户对某功能的可读、增加、修改、删除、打印权限，能控制用户对数据访问范围（全局、部门内、和自己相关）的控制。

·消息处理平台

通用的消息处理平台，能以短信、邮件、MSN等方式提醒用户处理业务。平台有统一的系统接口，可以处理来自各个系统的消息发送请求，应用系统只需要向消息处理平台提供消息模式（短信，邮件，MSN），消息内容，发送目标即可。

·订单管理

业务订单的增删改功能，订单以工作流为平台在全局组织架构内流转。开发订单时充分分析商品信息的共性，同类商品可以在同种订单内处理，这样便于用户一次购买多种商品，但是订单的规划要注意便于业务核算。

·订单支付

系统支持“网上支付”、“电话支付”、“上门收款”、“营业厅收款”、“汇款”等支付模式。

4.2.2.       架构要求

1、 要求揽收系统对数据进行规范化存储，便于以后对营销数据进行统计或BI分析

2、 系统在设计时考虑以后可以很方便的加入智能调度模块，智能调度能有效的使用邮政现有的揽收资源做到合理分配。

3、 处理局对订单状态的更新及时性会大大影响系统使用的整体效果，如果状态不能及时更新，11185无法看到订单的最新处理情况，如果用户电话至11185咨询时无法给予很好的回复，可以考虑业务员使用PDA终端，处理某些订单。

5.       应用部署

系统部署示意图如下：

订单的产生由三个渠道

·外网用户直接在电子商务站点下单，下单后和揽收系统应用服务器进行数据交换。

·手机用户发送短信后，由短信订单处理应用程序将短信内容解析为系统订单，然后和揽收系统应用服务器进行数据交换。

·各支局营业厅和11185话务员接单直接通过内网操作系统。

在开发电子商务站点时注意能支持代理商操作的功能。

联系人: 段青松  MSN:dqsemail@163.com   苏康胜 MSN: cancanwyq@hotmail.com   申明:加MSN前请先EMAIL