电力营销服务业务中台设计方法与支撑体系研究

周纲 王锦志 许道强 方学民 施明泰 杨维

[摘    要] 随着电力体制改革不断深化，新兴的业务出现和信息通信技术的持续发展，传统电力营销服务系统已难以满足用户需求，需要引入企业中台等架构和理念开展优化升级。参考互联网电商等企业业务中台设计经验，结合电力营销业务特点，分析了营销服务业务中台的构成，研究了营销服务业务中台的设计流程、各环节的设计原则和具体的设计方法，最后从技术支撑和运营支撑两方面阐述了营销服务业务中台支撑体系，为电力营销服务系统业务中台体系的落地提供参考。

[关键词] 电力营销;业务中台设计;中台支撑体系

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2020. 01. 037

[中图分类号] F270.7    [文献标识码]  A      [文章编号]  1673 - 0194（2020）01- 0083- 07

0      引    言

营销业务是电力企业的对外服务窗口，处于服务政府、企业、人民群众的最前端。随着电力市场化改革的持续深化，综合能源服务市场的快速发展和新兴业务的不断出现，营销业务内涵和发展模式也在发生深刻变化，需要广泛运用“大云物移智”等先进信息通信技术，引入企业中台、微应用等创新性架构和理念，优化升级电力客户服务体系，创新服务模式，提升服务质量，满足电力客户日益多元化的优质服务需求[1-2]。

现有的电力营销服务系统经过多年运行，与营销业务发展不相适应的问题逐渐凸显。业务协同方面，现有系统大多采用“烟囱式”建设模式，系统相对独立，集成和协作成本高;需求响应方面，各系统业务独立纵向开展，业务逻辑共享性差，复用率低，需求响应慢，难以支撑业务快速发展的需要;系统演进方面，现有系统整体升级往往以系统重建的形式进行，基础功能重复投资建设，多年业务沉淀难以保留;數据融通方面，系统沉淀的数据资源广泛分散在各个异构系统中，数据一致性和流通性较差，共享困难，无法最大限度地挖掘数据价值。

为了解决信息化建设过程中异构系统集成复杂，功能重复建设及需求响应效率低下等问题，阿里巴巴等部分互联网电商公司在IT架构转型过程中引入了中台思想及体系[3]，对业务形成了强力支撑。文献[3]对中台在互联网企业中发挥的业务价值、演进过程、服务体系搭建及相关案例进行了论述;文献[4]给出了云上数据中台顶层设计，并通过案例描述了云上数据中台建设及其业务模式的形成过程。以上文献基于互联网电商企业业务及工程实践对中台战略、思想、设计及运维体系进行了较为全面的普及性阐述，对中台体系在营销服务系统中的落地具有一定参考意义。面对数字化转型要求，包括电力行业在内的相关企业也针对业务中台在营销信息化中的应用进行了相关研究。文献[5]以数据驱动为出发点，通过大数据挖掘，产品紧关联，全渠道覆盖及场景化营销来构建企业中台，从而满足客户个性化需求并提升客户体验;文献[6]针对电子渠道建设现状，借鉴互联网企业的相关实践，为电信运营商构建电渠中台系统提供了思路;文献[7]提出电力物联网多渠道客户服务中台整体架构，并描述了用户中心、工单中心、账单中心等共享服务中心核心组件的业务内容;文献[8]基于中台技术对全渠道运营支撑平台架构进行设计，并研究了部署方式和面向电力营销的运营支撑平台业务内容。以上文献对中台体系的设计和在相关行业营销业务中的应用提出了总体思路和架构，但多为对业务中台设计的原则性介绍，尚缺乏设计过程的系统化阐述。

综上，结合电力营销业务实际，参考已有研究成果，针对营销服务业务中台设计方法开展研究，对中台体系在电力营销服务系统中的落地应用具有较强的工程实用价值。

1      营销服务业务中台的构成

营销服务业务中台作为一种战略性、体系性业务架构，其核心价值在于将营销业务能力IT化的模式转变为将业务能力资产化的模式，从而提高业务敏捷性及响应市场的速度。营销服务业务中台里提供的业务能力可以逐渐被更多的业务应用复用，从而逐渐累积企业业务能力资产，并通过中台赋能的方式，为面向电力客户服务的前台应用输出持续沉淀的核心业务能力和快速创新能力[7]。它不仅包括中台信息系统支撑，还包括与中台匹配的管理体系和标准。具体来说，营销服务业务中台由业务中台分析方法、各类业务服务能力中心及与之匹配的业务数据域、业务中台技术支撑及与之匹配的管理机制及标准构成。

（1）业务中台分析方法：营销业务中台服务化建设方法，涉及服务中心规划、服务识别、设计、实现、治理等一系列方法标准。

（2）业务能力中心：营销业务服务中心由基于领域模型分解的业务能力池及从业务域、流程、功能、时序图等业务分析中梳理出的服务组成。

（3）业务数据域：与上述业务能力中心匹配的业务数据集合，该业务数据域的操作一般必须通过该业务能力中心，从而天然保障数据的高度一致性。

（4）业务中台技术基础设施：是对业务中台的业务能力中心、业务数据域、管理机制及标准提供标准技术支撑的技术体系，如分布式服务框架、分布式数据库、分布式消息队列、分布式业务监控、分布式事务等。采用统一的技术基础设施对于业务中台的落地、运维、迭代更新等具有非常重要的作用。

（5）管理体制及标准：稳定的团队和规范标准保证业务中台的能力建设方、能力使用方形成良好的流程运转机制，实现业务能力的持续稳定迭代，保证营销业务中台的持续演进。

以上五个方面构成客户服务业务中台的核心。营销服务业务能力中心构成已有相关文献[7]进行了详细研究，本文不再赘述，主要针对业务中台设计方法及包括技术基础设施和管理体系在内的业务中台支撑体系展开论述。

2      营销服务业务中台设计流程

参考互联网企业以客户为中心的以提升IT协同效能，促进业务创新，构建行业生态为目标的业务中台建设方法经验，结合电力营销自身的业务特性，本文提出涵盖整体客户服务业务中台设计实施过程。设计过程分为服务中心规划、服务识别、服务设计、服务实现及服务治理5个步骤，涉及业务相关提交件的输入要求，业务中台相关提交件的输出，设计过程的一系列标准、模板和规范，前后步骤相互验证，迭代演进，如图1所示。

（1）在服务中心规划阶段，基于业务领域模型的输入根据服务中心规划方法和决策流程及指标确定电力营销服务系统的服务中心，根据服务中心确定电力营销服务业务中台架构。

（2）在服务识别阶段，依赖业务需求分析产出的四级或五级流程、业务时序图、业务规则、业务功能等作为服务识别的输入，再根据各种需求输入对应的服务梳理方法梳理出备选服务。针对备选服务依据服务中心规划做筛选、聚合、归类形成电力营销服务系统的服务模型，同时根据服务的非功能需求产出业务中台技术能力支撑。

（3）在服务设计阶段，根据服务识别阶段产出的服务模型，设计对外暴露的服务接口和操作，设计各个服务中心的数据模型，设计服务中心的部署模型。

（4）在服务实现阶段，根据服务设计阶段的产出，依据代码开发规范、微服务开发最佳实践，进行服务接口的代码业务逻辑实现及开发完成后的服务单元测试、服务集成测试、服务非功能测试、服务部署上线等。

（5）在服务治理阶段，针对服务的持续运营，收集及反馈服务实际运行信息，促进服务的持续迭代，持续的满足和促进业务创新，真正达到以客户为中心、服务好客户的核心主旨。

2.1   服务中心规划

2.1.1   原则与思路

服务中心规划分为业务领域建模阶段、服务中心推导规划阶段、服务中心评审阶段、业务中台架构形成等阶段，如图2所示。在业务领域建模阶段，由业务专家和业务架构师使用领域分析方法来分析营销现有和未来的业务，根据营销业务所涵盖的全量用户用例模型分析抽象其中的业务对象和业务实体及其之间的关系，从中推导规划出营销业务领域模型作为下一阶段营销服务中心规划的业务输入;在服务规划阶段，由中台架构师与业务架构师根据营销业务领域模型推导出营销的服务中心规划蓝图;在中心评审阶段，由中台管控组主持审核服务中心规划，根据预先指定的服务中心评审标准，确定中心规划的合理性和中心实施计划和资源安排;最终根据服务中心规划审批的意见和结果，形成营销服务业务中台架构，作为后续营销服务梳理的范围和依据。

2.1.2   服务中心规划方法

（1）业务领域建模。业务领域建模是对业务中台所涉及的需求业务进行业务分解及业务边界划分，形成“高内聚低耦合”的业务子域过程。首先，采用用例建模进行业务需求的收集及分析，用例建模的最主要功能就是用来表达系统的共性需求或行为。该阶段产出“用例模型”，包括“用例”及“用例描述”;然后，基于“用例模型”同时结合领域建模分析方法，来挖掘和分析重要的业务实体，并建立业务实体之间的关系，最终形成领域模型。领域模型包括业务实体及业务实体之间的关系。

（2）服务中心规划。在业务领域模型产出之后，要对模型进行归纳和划分形成业务域，归纳是为了保证相近的职责模型聚拢在一起从而保证职责的单一且内聚，同时明确出来的两个域的边界，保证业务域之间的低耦合。当业务域架构产出之后，服务中心架构的骨架初步形成，业务域基本上可以对应到相应的服务中心，后续就是在这个框架上去填充内容。先根据业务流程开始对服务进行识别，从而进行服务化的架构建模，同时把服务所在的业务范围归属到相应的服务中心。另外服务中心还可以从技术维度横向纵向抽象各个服务中心共同依赖的技术能力，形成技术视角的服务中心，例如多个服务中心都需要内容发布能力，如果希望能提供统一的内容管理、发布、存储与挖掘的功能平台，可以形成内容发布中心。

2.2   服务识别

2.2.1   原则与思路

通过流程识别、时序图识别、功能识别等方法初步梳理出备选服务，产出初步的营销服务模型。根据初步的营销服务模型，进行抽象归纳，相同业务能力的进行合并，类似业务能力的进行归集形成服务操作，并抽象服务操作的输入输出，尽可能共用同一个服务操作，多个业务相对固定的连续操作考虑形成组合服务;根据服务评测标准进行分析、合并、过滤等处理，最终形成服务模型，如图3所示。

2.2.2   服务识别方法

服务识别依赖于业务流程、规则、功能、时序图的输入，根据不同输入使用不同的服务梳理方法进行服务梳理，形成服务模型。

（1）业务流程分析方法：以当前业务流程为参考，识别其需要改进的地方，尽可能以目标业务流程为分析对象来识别服务。目标业务流程的定义一般应该在服务识别前完成，可以以当前流程为基础，以行业的最佳实践为指导，参考行业标准规范，优化重构而成。优化和重构的核心在于两个方面，一是以有效地支撑企业业务目标和愿景（如简化业务流程、提高执行力等）为根本原则;以消除冗余（共同活动、规则、数据）和增强灵活性（识别易变活动、规则、数据）为基本方法，二是在分析过程中，注意总结参与的业务角色（内外人员或系统）、业务实体（数据层面）、构成流程的业务活动（子流程）之间的依赖和顺序关系、活动分支依据的判断规则以及各活动自身依赖的规则和策略。一般对业务流程拆解最多到四级子流程（即第五级）即可识别出合适粒度的业务能力作为备选服务。可以明确归属为某个服务中心的业务任务/操作就是备选服务，比如所有对于用户的操作都归属于用户中心;如无法确定该业务操作属于哪个服务中心，但又是通用的业务能力，作为备选服务，為后续分析服务中心服务涵盖了业务做迭代。

（2）功能分析方法：根据业务功能的输入，按照业务中台服务化方法根据电力营销服务系统业务功能的输入，采用功能服务梳理方法的能力中心分析方法、原则，从业务应用功能中去分析、抽象、归类、设计支撑系统业务应该具有的能力中心和能力中心大颗粒度的服务。整体业务中台能力中心分析推导过程的步骤包括业务及应用能力输入、业务能力分析、关键要素拆解、关键要素分布分析及中心能力汇聚。

（3）时序图分析方法：根据业务域/系统间的业务调用动作，梳理出备选服务，包含动作的输入输出、非功能要求、服务发布范围等，形成服务模型;上述梳理出的服务综合抽象归类，形成服务模型。作为下一阶段服务设计的输入。可以明确归属为某个服务中心的业务动作就是备选服务，比如所有对于用户的操作都归属于用户中心;如无法确定该业务动作属于哪个服务中心，但又是通用的业务能力，作为备选服务，为后续分析服务中心服务涵盖了业务做迭代。

2.3   服务设计

2.3.1   原则与思路

服务设计以服务识别出的服务模型为基础，针对服务粒度、依赖关系做合理调整;并对服务接口、服务应用分组、以及部署方式，以契约先行和更好地支持可伸缩高可用为目标做进一步的设计，同时在性能、管控、安全等非功能性需求方面对服务实现提出明确的要求，在这个过程中，逐步明确完善系统整体架构，包括架构主题决策、系统组件模型、系统部署模型、信息数据模型等，如图4所示。

2.3.2   服务设计方法

业务中台服务设计方法包括服务化松耦合设计方法、命名方法、接口设计方法、操作设计方法等。以服务化松耦合设计方法为例，一是实现的松耦合，将核心业务实现抽成独立的服务成为服务提供方，将前端应用作为服务消费方，两者之间通过RPC（远程调用协议）进行通信，消费端与核心业务提供方解耦，服务提供方的内部变更不会影响到消费方，同时消费方可以根据需要切换提供方;二是时间的松耦合，实质上是将同步化为异步，在高并发的情况下，由于下游服务、业务链的各个服务的可用性、处理能力存在差异，让服务提供方在同一时间处理掉大量的数据是不现实的，需要降低服务之间的强依赖性，目前主流的方式是采用异步消息队列，牺牲一部分时间从而保证最终一致，服务高可用;三是位置的松耦合，应用系统启动的时候，无须关注服务提供方的位置，会根据一定的方式获取到需要的位置信息，目前的主流方式是采用服务注册中心，服务提供方将所有的服务注册到服务注册中心，当服务消费方想要调用其他系统的服务时，从注册中心查找对应的服务后再进行调用，一些主流的服务注册中心中间件同时提供了一系列机制可以保证服务实时发现、注册、刷新等;四是版本的松耦合，随着服务的升级会带来版本的升级，不能出现消费端需要依赖特定版本才能工作的情况，因此高版本必须要向下兼容。

2.4   服务实现

服务实现根据服务设计的产出文档，结合满足业务的稳定性和容量性需求，采用成熟的分布式服务框架进行服务开发实现。需按照统一的编码开发规范，保证服务实现的开发质量，主要包含服务实现决策和服务实现技术两大部分。服务实现决策确定接口定义、方法定义和实现模块，服务实现技术确定发布协议、访问端点及安全机制。

根据服务设计确定的服务模型的服务目录、服务关联、服务定义，并且在对系统整体架构的逐步完善中明确这些服务的分组分类，以及不同的服务暴露、交互场景等。在确定了该服务所采用的服务化框架实现的选型后，开始实现服务模型里面的服务，包括确定业务中台技术架构，根据业务中台技术支撑形成业务中台技术架构;确定服务化框架，确定产品来封装业务能力的实现，形成服务;确定实现业务能力依赖的技术产品，如使用什么规则、搜索、消息、缓存引擎，工作流和数据持久化框架等;编写、集成、组装、测试，形成应用部署交付件要求之前服务设计阶段提出的实现指导原则能够切实落实;最后部署服务，服务应用能够便捷甚至自动地适应不同的部署目标环境（如日常、测试、预发、线上）之间的切换。

2.5   服务治理

服务治理是使营销服务业务中台建立的服务体系顺畅运转而制定的指导原则，以及执行这些原则所需要的技术手段，涉及服务发布发现、服务鉴权授权、服务监控统计、服务故障预案、服务弹性伸缩、服务限流降级、服务链路追踪、服务链路压测、服务灰度发布等。通过服务的治理，使服务实时使用数据反馈到业务系统，推进业务持续梳理优化，从而引导业务中台持续优化迭代，以数据优化的手段促进营销业务真正往以客户为中心的方向上演进。

服务演进是服务治理的一部分，需要解决服务生命周期中的阶段性问题，即服务该如何更新以及该如何控制管理更新对已有服务消费者的影响。服务被消费后也会需要更新，这些更新可能是因为要加入新的功能，或者要修复问题和错误，或者是从易用性上要做改进，或者从业务耦合性和完整性上要做合并拆分，也可能是单纯因为服务本身代表的业务能力发生了变化，例如规则、流程变化等。这些变化，有的并不会影响到已有服务消费者的继续使用，有的却要求已有服务消费者做改造。表1列出了服务演进中服务更新的可能情况、原因及对应的处置原则。

3      营销服务业务中台技术支撑体系

3.1   业务中台技术支撑要求

营销服务业务中台为支撑业务的海量用户访问、快速迭代支撑业务创新、业务稳定的运行，数据化运维的辅助，从技术角度需要考虑解决上述几个关键问题，综合分析应满足以下技术要求。

（1）应用微服务化：未来营销的持续增长，应用会变得越来越臃肿，开发、维护成本会越来越高，任何小的改动影响面都越来越广，以上相关问题导致对于业务的响应变得越来越缓慢，传统架构已经无法满足互联网环境下的快速创新需求。为满足IT对于业务的快速支持和支撑业务的快速创新，能力中心的架构需要实现基于微服务开发框架，采用分布式应用服务框架组件搭建，微服务开发框架把业务能力发布成服务，以实现现有集中式系统的分布式改造，降低新业务应用的建设成本周期和风险。微服务开发框架将各部门的应用资源以业务能力的形式组织起来，通过该开发框架对这些业务能力进行封装形成易于共享的服务，从而实現业务能力粒度上的重用、组装、维护和管理。