CN114119091A - 一种用于构建移动政企业务bc融合生态的运营方法及平台 - Google Patents

Abstract

本发明提出了一种用于构建移动政企业务BC融合生态的运营方法及平台，所述方法包括：根据客户潜在需求确定预订购产品；根据所述预订购产品确定原子产品；对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性；接收客户对原子产品的订购请求，提取对应原子产品的关联属性；根据客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作。所述平台使用了所述方法。本发明可以帮助移动客户快速完成产品订购，起到降本增效的作用，同时，本发明的业务开通方式灵活多样，可以满足政企客户的个性化定制需求。

Description

一种用于构建移动政企业务BC融合生态的运营方法及平台

技术领域

本发明涉及移动通信技术领域，具体涉及一种用于构建移动政企业务BC融合生态的运营方法及平台。

背景技术

目前政企客户对于信息化产品和增值业务的需求日益多元化，行业需求的个性化定制方案面临高频的迭代，移动公司传统政企产品体系中以传统的单一产品为主，九大行业平台级产品正在打造和完善中，而轻量化的SAAS(Software-as-a-Service，软件即服务)类信息化产品相对薄弱。

现有的部分客户的需求，需要以定制化项目的方案去满足，不能以订购传统产品融合包的订购受理来实现，受项目的金额限制，不利于业务的发展，且受理申请流程审批环节多、时间周期长，客户经理流程处理的人力成本大，不能及时满足客户的需求；客户经理无法按需将传统产品与IT产品进行融合，在收到客户需求后，客户经理需与公司确认产品方案是否可执行，过程繁琐复杂，不利于市场前端发展。

发明内容

针对现有技术的不足，本发明提出一种用于构建移动政企业务BC融合生态的运营方法及平台，解决了现有技术中移动政企产品体系产品单一、无法与IT产品融合、服务开通不灵活的缺陷。

本发明的技术方案是这样实现的：

第一方面，本发明提供了一种用于构建移动政企业务BC融合生态的运营方法，其特征在于，包括：

根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务；

根据所述预订购产品确定原子产品；

对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性；

接收客户对原子产品的订购请求，提取对应原子产品的关联属性；

根据客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作。

进一步，上述所述对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性的步骤，具体为：

获取原子产品的名称、数量信息、定价信息、折扣信息、生效时间信息、计费周期信息、协议期信息、付费模式信息、销售渠道信息和施工属性信息，确定原子产品的关联属性；

至少根据产品名称、折扣信息、定价信息和销售渠道信息确定所述销售属性，所述折扣信息包括折扣区间和折扣价格；

至少根据产品名称、数量信息和生效时间信息确定所述订购属性，所述生效时间信息包括生效时间和生效周期；

至少根据产品名称、施工属性信息确定所述交付属性；

至少根据所述计费周期信息和协议期信息确定计费规则。

进一步，上述所述接收客户对原子产品的订购请求，提取对应原子产品的关联属性的步骤，具体包括：

接收客户对主体产品和原子产品的订购请求，提取对应原子产品的关联属性；

所述工单自动生成操作具体包括：

根据客户对主体产品和原子产品的订购请求，以及客户对各原子产品对应关联属性的选取操作，生成订购工单；

所述业务受理协议生成操作具体包括：

通过BOSSCRM或ESOP系统将订购工单同步至服务开通系统，服务开通系统获取各原子产品的归属业务平台，根据各原子产品的开通流程，生成子订购工单，所述子订购工单包括原子产品的交付属性；

将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议。

进一步，上述所述出账操作包括：

根据各原子产品的销售属性和订购属性执行独立的出账操作；

所述计费操作包括：

根据各原子产品的生效时间信息和计费规则执行独立的计费操作；

所述费项列收操作包括：

根据各原子产品对应的归属业务平台和定价信息执行独立的费项列收操作；

所述账单生成操作包括：

合并处理主体产品、原子产品的账单和发票，生成统一的账单和发票。

进一步，上述所述根据客户对主体产品和原子产品的订购请求，以及客户对各原子产品对应关联属性的选取操作，生成订购工单的步骤之后，还包括：

根据主体产品和原子产品的价格比例，确定融合模型，所述融合模型包括紧密融合、松散融合和混合融合；

根据不同的融合模型，对所述折扣信息进行修正。

进一步，上述所述将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议的步骤之后，还包括：

确定客户已订购的原子产品颗粒，将所述原子产品颗粒与移动App自动组合生成前端应用；

剥离所述前端应用的公共属性，实现所述前端应用的数据与各归属业务平台的互通互享，所述公共属性包括组织架构、鉴权、通信录、流程和表单数据。

本发明另一方面还提供了一种用于构建移动政企业务BC融合生态的运营平台，其特征在于，包括：

第一确定模块，用于根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务；

第二确定模块，用于根据所述预订购产品确定原子产品；

第三确定模块，用于对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性；

处理模块，用于接收客户对原子产品的订购请求，提取对应原子产品的关联属性；

执行模块，用于根据客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作。

进一步，上述所述处理模块，具体用于接收客户对主体产品和原子产品的订购请求，提取对应原子产品的关联属性；

所述执行模块，包括：

第一生成单元，用于根据客户对主体产品和原子产品的订购请求，以及客户对各原子产品对应关联属性的选取操作，生成订购工单；

第二生成单元，用于通过BOSSCRM或ESOP系统将订购工单同步至服务开通系统，服务开通系统获取各原子产品的归属业务平台，根据各原子产品的开通流程，生成子订购工单，所述子订购工单包括原子产品的交付属性；

第三生成单元，用于将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议；

所述第三确定模块，具体用于获取原子产品的名称、数量信息、定价信息、折扣信息、生效时间信息、计费周期信息、协议期信息、付费模式信息、销售渠道信息和施工属性信息，确定原子产品的关联属性；

至少根据产品名称、折扣信息、定价信息和销售渠道信息确定所述销售属性，所述折扣信息包括折扣区间和折扣价格；

至少根据产品名称、数量信息和生效时间信息确定所述订购属性，所述生效时间信息包括生效时间和生效周期；

至少根据产品名称、施工属性信息确定所述交付属性；

至少根据所述计费周期信息和协议期信息确定计费规则。

进一步，上述所述执行模块还包括：

第一执行单元，用于根据各原子产品的销售属性和订购属性执行独立的出账操作；

第二执行单元，用于根据各原子产品的生效时间信息和计费规则执行独立的计费操作；

第三执行单元，用于根据各原子产品对应的归属业务平台和定价信息执行独立的费项列收操作；

第四执行单元，用于合并处理主体产品、原子产品的账单和发票，生成统一的账单和发票。

进一步，上述所述执行模块还包括：

第四生成单元，用于确定客户已订购的原子产品颗粒，将所述原子产品颗粒与移动App自动组合生成前端应用；

第五执行单元，用于剥离所述前端应用的公共属性，实现所述前端应用的数据与各归属业务平台的互通互享，所述公共属性包括组织架构、鉴权、通信录、流程和表单数据。

本发明实施例根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务；并根据所述预订购产品确定原子产品；可以将非标准化的客户需求封装成原子产品，允许客户可以直接订购原子产品满足需求，帮助客户快速完成订购，且客户经理无需对产品方案进行确认，可大力减少客户经理流程处理的时间和精力成本，起到降本增效的作用；同时，本发明实施例对所述原子产品进行标准化改造，对所述原子产品进行公共模型的构建，确定原子产品的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性；接收客户对原子产品的订购请求、以及客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作，使得原子产品完成标准化操作，产品标准化有利于产品融合，产品均以标准化的价格上架至库内(示例性的，以一次性/12个月/24个月/36个月分别上架)，客户经理可在现场根据客户需求，库内适配需求后即可与传统产品进行融合，快速封装为整体解决方案，以最快速度促成项目签约，开通方式灵活多样，可以满足政企客户的个性化定制需求。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明第一实施例的一种用于构建移动政企业务BC融合生态的运营方法的流程图；

图2为本发明第一实施例的标准化的原子产品结构模型；

图3为本发明第二实施例的一种用于构建移动政企业务BC融合生态的运营方法的流程图；

图4为图3中S203的扩展步骤的流程图；

图5为本发明第三实施例的一种用于构建移动政企业务BC融合生态的运营优化平台的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。

第一实施例：

请参照图1和图2所示，本发明实施例公开了一种用于构建移动政企业务BC融合生态的运营方法，包括：

S11，根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务。

不同于移动下属传统产品，本实施例的预订购产品可以是第三方信息化应用产品或移动增值业务产品，示例性的，预订购产品包括但不限于考勤打卡、移动办公、智能报表、时间管理等应用或业务。本步骤根据所有潜在客户的潜在需求确定预订购产品，根据客户所有可能订购的第三方信息化应用产品和移动增值业务确定预订购产品，纳入产品目录中。

S12，根据所述预订购产品确定原子产品。

本步骤将第三方信息化应用产品或移动增值业务产品，根据预设规则提取出的可帮助客户实现其潜在需求的功能操作或信息内容，原子产品在支撑前端灵活快速销售的同时，也便于生态产品的标准化快速上架。

S13，对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性。

需要说明的是，各类原子产品对应的关联属性是不同的，有些小类的销售属性只存在于特定原子产品中，而大部分原子产品并没有对应小类的销售属性，作为一种优选方案而非限定，本实施例的标准化的原子产品结构模型可以参照图2所示，图中：

1、产品为标准化产品单元，即商品集合；商品为库存量单位，即面向销售的对象。

1)产品是某种商品的集合，不可进行销售。产品配置包括产品分类和/或产品类目和/或属性库和/或品牌库和/或有效期和/或归属供应商和/或产品合同和/或产品详情等，产品配置的内容为其属下的商品共有。

a)产品分类包括实体类产品、服务类产口和虚拟类产品。

b)产品类目为一个树形目录结构，产品归属于某个类目下。

c)品牌库包括品牌中文名称、品牌英文名称、品牌LOGO、状态等，品牌库集中管理品牌，为产品配置品牌提供服务。

d)属性库包括关键属性、规格属性、施工属性、回单属性、协议期属性、其他属性等属性类型，包括属性编码、属性名称和属性值。

i.其中关键属性+规格属性是生成商品的依据，系统根据两个属性类型的属性值的个数组合生成商品。

ii.属性库用于抽象相关产品的公共属性管理，为产品配置属性提供服务。属性关联类目，关联后该类目下的产品默认具有该属性。

平台支持自定义属性类型和属性值。

e)有效期包括生效时间和失效时间。

f)供应商用于定义产品归属某个供应商。

g)产品合同为平台与供应商签定产品合同，供应商授权该产品在平台进行销售，双方并约定产品的销售价格、销售区域、结算规则、履约要求、售后服务、销售有效期等相关条款，配置产品时需关联产合同。

h)产品详情为产品的详细内容图文介绍。

2)商品归属于的某个产品，是该产品属下的叶子节点，也是进行销售的对象。商品配置包括商品属性和/或商品标签和/或商品状态和/或商品定价和/或商品上下架和/或商品库存和/或商品销售规则和/或商品费项和/或商品分组和/或商品依赖互斥规则和/或商品归属供应商和/状态和/有效期。

a)商品属性继续自商品所在产品的产品属性，且关键属性+规格属性为固定的、唯一的属性值。

b)商品标签用于区分商品的不同群组，标签支持自定义。标签库集中管理标签记录，为商品配置标签提供服务。

c)商品状态用于标识该商品是否可用。

d)商品定价用于定义商品的价格，支持多种价格的定义，如正常销售价格、区间价格规则、折扣价格规则等，为营销活动提供差异价格支撑。

e)商品库存用于管理商品的库存，库存可分为渠道库存、区域库存。

f)商品销售规则用于定义商品销售的限制条件，如可销售渠道、可销售区域、客户订购时的限购数量等。

g)费项用于定义商品在移动BOSS系统出账时，其归属的账务科目、账单科目、发票科目。

h)商品分组用于定义商品组别。用组别来识别某个商品的集合。

i)商品组合用于将某几个原子商品组合为一个新的商品，订购该组合商品时自动订购组合中的所有原子商品。

j)商品依赖互斥规则用于定义商品和/或商品组合和/或商品分组之间的依赖关系、互斥关系，用于支撑复杂的业务规则。

k)有效期包括生效时间和失效时间。

3)营销方案用于配置商品销售方案，配置内容包括商品组合、目标客户、优惠内容、有效期。

a)商品组合用于定义方案中包含的商品，可包含一个或多个商品(商品包括原子商品和组合商品)。

b)目标客户用于定义方案的销售对象，可指定具体的客户列表或客户标签(如客户类型、标签等)。

c)优惠内容用于定义该方案的具体优惠内容，如价格优惠、资源优惠、其它优惠等。价格优惠用于定义该方案的销售价格。资源优惠用于定义免费资源、计费资源和最高计费金额(即封顶金额)。

d)有效期用于定义该方案的开始生效时间和失效时间。

4)营销活动用于定义某一时间段内执行某种目的的市场活动，包括商品、优惠渠道和/或目标客户和/或时间计划和/或优惠内容。

a)商品列表用于配置活动包含的商品，可包含一个或多个商品(商品包括原子商品和组合商品)或营销方案。

b)时间计划用于定义当前活动的开始时间和结束时间。

c)目标客户用于定义活动的销售对象，可指定具体的客户列表或客户标签(如客户类型、标签等)。当营销活动与营销方案的目标客户不一致时取其交集。

d)优惠内容用于定义当前活动的优惠商品范围和商品优惠价格。

5)优惠卡券包括可用商品和/或可用渠道和/或目标客户和/或使用条件和/或优惠内容和/或有效期

a)可用商品用于定义当前卡券可使用的商品。

b)可用渠道用于定义当前卡券可在哪个渠道使用。

c)目标客户用于定义当前卡券适用于哪个客户群体，可指定具体的客户列表或客户标签(如客户类型、标签等)。

d)优惠内容用于定义当前卡券的商品优惠价格。

e)有效期用于定义当前卡券的生效时间和失效时间。

6)上下架用于管理商品和/或营销方案和/或营销活动是否可办理，其中上架为可销售，下架为禁止销售，上架包括渠道、区域、主体产品。

a)渠道用于定义哪些渠道可进行业务办理。

b)区域用于定义哪些地市、行政区域可进行业务办理。

c)主体产品用于定义哪些产体产品可进行业务办理。

d)如果商品和/或营销方案和/或营销活动的渠道、区域、主体产品不一致时，取其交集。

S14，接收客户对原子产品的订购请求，提取对应原子产品的关联属性。

作为一种优选方案而非限定，当用户订购某几个原子产品时，对应原子产品的关联属性会以复选框的方式弹出，供用户进行选择确认。

S15，根据客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作。

在本实施例中，原子产品的订购则按BOSSCRM或ESOP系统同步到服务开通系统，再同步到能力开通系统，能力开通系统通过实时消息接口(业务受理工单同步接口)，将订购请求同步至本发明的运营平台，再由运营平台进行原子产品的调度施工和交付。

本发明实施例根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务；并根据所述预订购产品确定原子产品；可以将非标准化的客户需求封装成原子产品，允许客户可以直接订购原子产品满足需求，帮助客户快速完成订购，且客户经理无需对产品方案进行确认，可大力减少客户经理流程处理的时间和精力成本，起到降本增效的作用；同时，本发明实施例对所述原子产品进行标准化改造，对所述原子产品进行公共模型的构建，确定原子产品的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性；接收客户对原子产品的订购请求、以及客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作，使得原子产品完成标准化操作，产品标准化有利于产品融合，产品均以标准化的价格上架至库内(示例性的，以一次性/12个月/24个月/36个月分别上架)，客户经理可在现场根据客户需求，库内适配需求后即可与传统产品进行融合，快速封装为整体解决方案，以最快速度促成项目签约，开通方式灵活多样，可以满足政企客户的个性化定制需求。

第二实施例：

请参照图3和图4所示，本发明实施例公开了另一种用于构建移动政企业务BC融合生态的运营方法，包括：

S201，根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务。

S202，根据所述预订购产品确定原子产品。

S201-S202与第一实施例的对应步骤相同，在此不再赘诉。

S203，获取原子产品的名称、数量信息、定价信息、折扣信息、生效时间信息、计费周期信息、协议期信息、付费模式信息、销售渠道信息和施工属性信息，确定原子产品的关联属性。

在本步骤中，通过提供丰富的原子产品的关联属性，方便客户在订购原子产品时，通过选择不同的关联属性，为客户提供更加丰富个性定制化的产品服务，利于自动生成专属化的优惠方案。

在本实施例中，S203还可以具体包括S2031-S2034。

其中，S2031，至少根据产品名称、折扣信息、定价信息和销售渠道信息确定所述销售属性，所述折扣信息包括折扣区间和折扣价格。

本步骤S2031销售属性中的折扣价格为按照产品成本价格和市场价定义，支持前端销售人员可以根据客户实际需求和友商的竞对信息，最终确认销售价格；折扣区间为下述不同融合模型对应的价格折扣区间，示例性的，紧密融合的价格折扣区间较高，而松散融合的价格区间较低，以引导客户订购移动增值业务相关的原子产品，同时可以提升第三方信息化应用产品的附加价值；作为一种优选方案而非限定，本实施例的销售属性还包括是否支持数量订购等。

作为一种优选方案而非限定，本实施例中，原子产品还包括产品属性，产品属性为原子产品自身具有的属性，示例性的，产品属性包括产品名称、产品是否支持重复订购、产品是否为签约客户下属成员订购等。

S2032，至少根据产品名称、数量信息和生效时间信息确定所述订购属性，所述生效时间信息包括生效时间和生效周期。

本步骤中，订购属性为与客户订购原子产品相关的属性，其中，生效周期可以是实时生效、当月生效、次月生效或指定生效。

S2033，至少根据产品名称、施工属性信息确定所述交付属性。

本步骤中，交付属性为客户订购产品后，客户经理完成交付过程的相关属性，其中，施工属性包括安装不同品牌、性能的硬件设备等。

S2034，至少根据所述计费周期信息和协议期信息确定计费规则。

本步骤中，计费周期信息可以是一次性计费、按年计费或按月计费等，协议期按照最小原子产品单元独立生效，其分为无协议期、12期、24期或36期等，在客户同时订购原子产品和主体产品时，原子产品协议期将自动带入主体产品，从而锁定进主体产品协议。

需要说明的是，本领域技术人员可以预见的是，销售属性、订购属性和交付属性中的具体内容和类别，是可以根据实际需要进行有限变动的，在本实施例的整体构思下，对其进行的同等置换和改动，均应属于本发明的保护范围。

S204，接收客户对主体产品和原子产品的订购请求，提取对应原子产品的关联属性。

本发明的产品订购支持单独订购和基于主体产品的下附加融合订购，客户可以根据自身需求单独订购主体产品或原子产品，具体到本实施例中，客户也可以在选择主体产品后，勾选所需原子产品，并依据原子产品的销售属性、订购属性、交付属性进行勾选，一键提交，进行融合产品包的订购。

S205，根据客户对主体产品和原子产品的订购请求，以及客户对各原子产品对应关联属性的选取操作，生成订购工单。

作为一种示例而非限定，待生成订购工单后，将按照先主体产品、后原子产品的开通逻辑进行开通。

S206，根据主体产品和原子产品的价格比例，确定融合模型，所述融合模型包括紧密融合、松散融合和混合融合。

在本实施例中，紧密融合形态下可设计主体产品和原子产品融合比例、范围，仅供客户基于融合后的框架产品选择，其中原子产品价格不能高于融合所设定的临界值上限；松散融合是基于主体产品下，由客户面向全域原子产品清单自主选择，不设定原子产品融合上限；混合融合为紧密融合和松散融合模型的综合应用。

S207，根据不同的融合模型，对所述折扣信息进行修正。

如上所述，在本实施例中，不同融合模型对应不同的价格折扣区间，示例性的，紧密融合的价格折扣区间较高，而松散融合的价格区间较低，以引导客户订购移动增值业务相关的原子产品，同时可以提升第三方信息化应用产品的附加价值。

S208，通过BOSSCRM或ESOP系统将订购工单同步至服务开通系统，服务开通系统获取各原子产品的归属业务平台，根据各原子产品的开通流程，生成子订购工单，所述子订购工单包括原子产品的交付属性。

本步骤中，子订购工单包含各原子产品单独的开通流程和交付属性。

S209，将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议。

本步骤所有子订购工单发送至对应的归属业务平台，进行受理开通，同时，根据所有订购的原子产品的子订购工单，按照标准化模板，生成业务受理协议。

传统多产品的订购需要客户签订多份协议而后受理开通，客户体验较差，本实施例将所有子订购工单生成业务受理协议，客户只需签订一份合同即可完成融合业务的开通，既提高了业务的开通效率，也提升了客户的使用体验，节省了人力成本，起到了降本增效的作用。

S210，根据各原子产品的销售属性和订购属性执行独立的出账操作。

S211，根据各原子产品的生效时间信息和计费规则执行独立的计费操作。

S212，根据各原子产品对应的归属业务平台和定价信息执行独立的费项列收操作。

S213，合并处理主体产品、原子产品的账单和发票，生成统一的账单和发票。

本步骤根据主体产品、原子产品的关键属性、规格属性、费项对应的账务科目、账单科目、发票科目，进行账单、发票的合并处理，最终形成一张账单、一张发票。

传统多产品的订购不能满足合并发票、账单的需求，只能由省公司统一费项、地市分公司无权定制。本实施例的原子产品按照最小单位进行出账、计费、计列、合账处理，面向客户实现一张账单、一张发票、可以按分公司需求进行产品列收配置；同时，第三方产品可以进行分期支付，减少客户资金成本的压力。

S214,确定客户已订购的原子产品颗粒，将所述原子产品颗粒与移动App自动组合生成前端应用。

作为一种优选方案而非限定，本步骤在确定客户已订购原子产品后，对原子产品进一步进行功能细化、拆分和关联功能重组，得到原子产品颗粒，将原子产品颗粒模块化并融入移动App(如“和应用”)中，并同步弹出应用升级提示，将客户已订购原子产品以原子产品颗粒的形式植入“和应用”界面。

同样，当已订购产品到期后，通过应用升级，可去除过期的原子产品颗粒，以实现简化应用界面的目的，提升了客户的使用体验。

S215,剥离所述前端应用的公共属性，实现所述前端应用的数据与各归属业务平台的互通互享，所述公共属性包括组织架构、鉴权、通信录、流程和表单数据。

本实施例的“和应用”承载客户订购的原子产品的模块化组合，形成单点登录，通信录、流程、表单等基础数据互通共享，原子产品之间的使用无感知切换和交互；本实施例还可以在“和应用”中提供客户经理小助手为政企渠道营销人员提供原子产品信息的快速查询、融合套餐设计测算、订单状态跟踪、典型案例的分享、平台知识库等功能。

传统多产品的订购，应用入口众多不统一，各产品数据不互通，界面多样，客户交付和使用体验较差。本实施例在生态产品融合时，将原子产品功能进行颗粒化，待客户完成产品订购后，按照所订购的原子产品颗粒，基于“和应用”自动组合前端应用，并将公共属性(组织架构、鉴权、通信录、流程、表单数据等)剥离，实现数据互通互享，最终面向客户提供一个app、单点登录、一套界面、实现无感知应用操作。

第三实施例：

请参照图5所示，本发明还提供了一种用于构建移动政企业务BC融合生态的运营优化平台100，包括第一确定模块110、第二确定模块120、第三确定模块130、处理模块140和执行模块150，其中：

第一确定模块110，与第二确定模块120连接，用于根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务。

第二确定模块120，与第三确定模块130连接，用于根据所述预订购产品确定原子产品。

第三确定模块130，与处理模块140连接，用于对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性。

作为一种优选方案而非限定，第三确定模块130，可以具体用于获取原子产品的名称、数量信息、定价信息、折扣信息、生效时间信息、计费周期信息、协议期信息、付费模式信息、销售渠道信息和施工属性信息，确定原子产品的关联属性；

至少根据产品名称、折扣信息、定价信息和销售渠道信息确定所述销售属性，所述折扣信息包括折扣区间和折扣价格；

至少根据产品名称、数量信息和生效时间信息确定所述订购属性，所述生效时间信息包括生效时间和生效周期；

至少根据产品名称、施工属性信息确定所述交付属性；

至少根据所述计费周期信息和协议期信息确定计费规则。

处理模块140，与执行模块150连接，用于接收客户对原子产品的订购请求，提取对应原子产品的关联属性。

作为一种改进方案，处理模块140，具体用于接收客户对主体产品和原子产品的订购请求，提取对应原子产品的关联属性。

执行模块150，用于根据客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作。

在本实施例中执行模块150包括第一生成单元151、第二生成单元152和第三生成单元153，其中：

第一生成单元151，与第二生成单元152连接，用于接收客户对主体产品和原子产品的订购请求、以及客户对各原子产品对应关联属性的选取操作，生成订购工单。

第二生成单元152，与第三生成单元153连接，用于通过BOSSCRM或ESOP系统将订购工单同步至服务开通系统，服务开通系统获取各原子产品的归属业务平台，根据各原子产品的开通流程，生成子订购工单，所述子订购工单包括原子产品的交付属性。

第三生成单元153，用于将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议。

执行模块还150包括第一执行模块154、第二执行模块155、第三执行模块156和第四执行模块157，其中：

第一执行单元154，与第二执行单元155和第四执行单元157连接，用于根据各原子产品的销售属性和订购属性执行独立的出账操作；

第二执行单元155，与第三执行单元156和第四执行单元157连接，用于根据各原子产品的生效时间信息和计费规则执行独立的计费操作；

第三执行单元156，与第四执行单元157连接，用于根据各原子产品对应的归属业务平台和定价信息执行独立的费项列收操作；

第四执行单元157，用于合并处理主体产品、原子产品的账单和发票，生成统一的账单和发票。

所述执行模块150还包括第四生成单元158和第五执行单元159，其中：

第四生成单元158，与第五执行单元159连接，用于确定客户已订购的原子产品颗粒，将所述原子产品颗粒与移动App自动组合生成前端应用；

第五执行单元159，用于剥离所述前端应用的公共属性，实现所述前端应用的数据与各归属业务平台的互通互享，所述公共属性包括组织架构、鉴权、通信录、流程和表单数据。

本实施例的模块和单元与上述两个方法实施例中的步骤一一对应，在此不再赘诉。

本实施例的运营平台可以负责原子产品的供应商管理、订单管理、面向客户的交付管理、面向供应商的结算管理，便于统一融合市面生态产品，打造了一个生态合作型、与移动业务耦合性高的平台，充分融合生态属地化、差异化、行业细分信息化应用服务，解决生态SAAS(Software-as-a-Service，软件即服务)快速上架、内外部产品快速合融合、一体化办理三个核心问题，提升了移动政企2.0要求八大能力中的产品平台能力、运营支撑能力、生态整合能力，提升效率助力获取客情商机、快速合作交付、抢夺市场份额、有效应对竞争。

本实施例搭建了“货架式”的平台管理能力，通过引入机制承载第三方信息化应用产品，进行平台“货品模块化加载”。平台以A+B为基础融合模型，其中A为移动自有/自采产品，B为第三方信息化应用产品，根据客户需求进行组合，对接打通移动内部NGBOSS平台，实现了“快速上架”、“快速融合”、“快速办理”、“支持分期支付”四大产品平台能力，实现“一张发票”、“一张账单”“一键办理”三个业务办理能力，有助于提升成员号码或主体信息化产品收入。

本发明实施例通过根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务；根据所述预订购产品确定原子产品；可以将非标准化的客户需求封装成原子产品，允许客户可以直接订购原子产品满足需求，帮助客户快速完成订购，且可大力减少客户经理流程处理的人力成本，起到降本增效的作用；同时，对所述原子产品进行标准化改造，确定原子产品的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性；接收客户对原子产品的订购请求、以及客户对各原子产品对应关联属性的选取操作，生成业务开通协议，使得原子产品完成标准化操作，产品标准化有利于产品融合，产品均以标准化的价格上架至库内(示例性的，以一次性/12个月/24个月/36个月分别上架)，客户经理可在现场根据客户需求，库内适配需求后即可与传统产品进行融合，快速封装为整体解决方案，以最快速度促成项目签约，开通方式灵活多样，可以满足政企客户的个性化定制需求。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将平台的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，平台和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所述运营平台和方法，可以通过其它的方式实现。例如，以上所描述的运营平台的实施例仅仅是示意性的，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种用于构建移动政企业务BC融合生态的运营方法，其特征在于，包括：

根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务；

根据所述预订购产品确定原子产品；

对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性；

接收客户对原子产品的订购请求，提取对应原子产品的关联属性；

根据客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作。

2.如权利要求1所述的实现方法，其特征在于，所述对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性的步骤，具体为：

获取原子产品的名称、数量信息、定价信息、折扣信息、生效时间信息、计费周期信息、协议期信息、付费模式信息、销售渠道信息和施工属性信息，确定原子产品的关联属性；

至少根据产品名称、折扣信息、定价信息和销售渠道信息确定所述销售属性，所述折扣信息包括折扣区间和折扣价格；

至少根据产品名称、数量信息和生效时间信息确定所述订购属性，所述生效时间信息包括生效时间和生效周期；

至少根据产品名称、施工属性信息确定所述交付属性；

至少根据所述计费周期信息和协议期信息确定计费规则。

3.如权利要求2所述的实现方法，其特征在于，所述接收客户对原子产品的订购请求，提取对应原子产品的关联属性的步骤，具体包括：

接收客户对主体产品和原子产品的订购请求，提取对应原子产品的关联属性；

所述工单自动生成操作具体包括：

根据客户对主体产品和原子产品的订购请求，以及客户对各原子产品对应关联属性的选取操作，生成订购工单；

所述业务受理协议生成操作具体包括：

通过BOSSCRM或ESOP系统将订购工单同步至服务开通系统，服务开通系统获取各原子产品的归属业务平台，根据各原子产品的开通流程，生成子订购工单，所述子订购工单包括原子产品的交付属性；

将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议。

4.如权利要求3所述的实现方法，其特征在于，所述出账操作包括：

根据各原子产品的销售属性和订购属性执行独立的出账操作；

所述计费操作包括：

根据各原子产品的生效时间信息和计费规则执行独立的计费操作；

所述费项列收操作包括：

根据各原子产品对应的归属业务平台和定价信息执行独立的费项列收操作；

所述账单生成操作包括：

合并处理主体产品、原子产品的账单和发票，生成统一的账单和发票。

5.如权利要求4所述的实现方法，其特征在于，所述根据客户对主体产品和原子产品的订购请求，以及客户对各原子产品对应关联属性的选取操作，生成订购工单的步骤之后，还包括：

根据主体产品和原子产品的价格比例，确定融合模型，所述融合模型包括紧密融合、松散融合和混合融合；

根据不同的融合模型，对所述折扣信息进行修正。

6.如权利要求5所述的实现方法，其特征在于，所述将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议的步骤之后，还包括：

确定客户已订购的原子产品颗粒，将所述原子产品颗粒与移动App自动组合生成前端应用；

剥离所述前端应用的公共属性，实现所述前端应用的数据与各归属业务平台的互通互享，所述公共属性包括组织架构、鉴权、通信录、流程和表单数据。

7.一种用于构建移动政企业务BC融合生态的运营平台，其特征在于，包括：

第一确定模块，用于根据客户潜在需求确定预订购产品，所述预订购产品包括第三方信息化应用产品和移动增值业务；

第二确定模块，用于根据所述预订购产品确定原子产品；

第三确定模块，用于对所述原子产品进行公共模型的构建，确定各类原子产品对应的关联属性，所述关联属性至少包括销售属性、订购属性和交付属性；

处理模块，用于接收客户对原子产品的订购请求，提取对应原子产品的关联属性；

执行模块，用于根据客户对各原子产品对应关联属性的选取操作，执行工单自动生成操作、业务受理协议生成操作、出账操作、计费操作、费项列收操作或账单生成操作。

8.如权利要求7所述的运营平台，其特征在于，所述处理模块，具体用于接收客户对主体产品和原子产品的订购请求，提取对应原子产品的关联属性；

所述执行模块，包括：

第一生成单元，用于根据客户对主体产品和原子产品的订购请求，以及客户对各原子产品对应关联属性的选取操作，生成订购工单；

第二生成单元，用于通过BOSSCRM或ESOP系统将订购工单同步至服务开通系统，服务开通系统获取各原子产品的归属业务平台，根据各原子产品的开通流程，生成子订购工单，所述子订购工单包括原子产品的交付属性；

第三生成单元，用于将子订购工单发送至对应的归属业务平台，进行开通受理，同步生成标准模板化的业务受理协议；

所述第三确定模块，具体用于获取原子产品的名称、数量信息、定价信息、折扣信息、生效时间信息、计费周期信息、协议期信息、付费模式信息、销售渠道信息和施工属性信息，确定原子产品的关联属性；

至少根据产品名称、折扣信息、定价信息和销售渠道信息确定所述销售属性，所述折扣信息包括折扣区间和折扣价格；

至少根据产品名称、数量信息和生效时间信息确定所述订购属性，所述生效时间信息包括生效时间和生效周期；

至少根据产品名称、施工属性信息确定所述交付属性；

至少根据所述计费周期信息和协议期信息确定计费规则。

9.如权利要求8所述的运营平台，其特征在于，所述执行模块还包括：

第一执行单元，用于根据各原子产品的销售属性和订购属性执行独立的出账操作；

第二执行单元，用于根据各原子产品的生效时间信息和计费规则执行独立的计费操作；

第三执行单元，用于根据各原子产品对应的归属业务平台和定价信息执行独立的费项列收操作；

第四执行单元，用于合并处理主体产品、原子产品的账单和发票，生成统一的账单和发票。

10.如权利要求9所述的运营平台，其特征在于，所述执行模块还包括：

第四生成单元，用于确定客户已订购的原子产品颗粒，将所述原子产品颗粒与移动App自动组合生成前端应用；

第五执行单元，用于剥离所述前端应用的公共属性，实现所述前端应用的数据与各归属业务平台的互通互享，所述公共属性包括组织架构、鉴权、通信录、流程和表单数据。

Images