某车企营销数据管理平台的构建.docx

某车企营销数据管理平台的构建 随着汽车企业的发展和车型的不断增加， 日益膨胀的营销数据信息给车企带来的影响也越来越明显， 除大量的客户信息需进行分析外，潜客、三表卡等信息对广告的精准投放产生重要的影响，售后信息、配件信息除经销商、服务站等需及时掌握，车企也需对此进行精准管理，降低 BO 率。 若缺乏统一的营销数据管理平台， 车企将无法及时了解到整个市场资源的分配及使用情况。 鉴于以上情况，迫切地需要建设一套统一的营销数据管理平台（以下简称DMS 系统），并实现经销商、服务站管理的规范化、有序化。 1 DMS系统概述 DMS 的前身是服务站的售后维修管理系统，该系统从 20 世纪 90 年代初就开始建设了。 伴随着 2002 年以来的汽车行业井喷，各车企纷纷提出建设 DMS（Dealer Management System）的要求，即整合整车厂 ERP 系统与经销商、维修站内部的管理系统，使之成为一个在业务流程上完整、重要业务数据集中、覆盖车辆及客户的整个生命周期，并跨越整车厂、经销商、服务站的信息系统。 图 1 是行业内的完整 DMS 架构图。 DMS 系统上端与整车厂的 ERP、MES、TMS 等信息系统共同构成了整车厂信息系统应用框架。 DMS 系统下端则位于经销商 服务站端，集成了整车业务、客户管理、售后服务和中强保 三包结算等经销商与维修站日常主要业务流程，组成了支持其业务运作的主要信息平台。 DMS 系统上端与下端之间通过 Internet 进行连接。在这个系统模型下， 整个 DMS 系统跨越了整车厂和经销商两者，既与企业内部信息系统的模式有本质区别，又与信息系统之间 EDI 模式有很大不同。 首先，使用 EDI 方式进行数据交换的两个信息系统虽然可能分别位于不同的公司内， 但它们在结构上是互相独立、可以脱离对方独立运行的系统。 只是运用 EDI 使系统功能有所增强。而 DMS 系统上端和下端是同时存在，协同运作，其中任何一个都不能独立存在。 其次，使用 EDI 方式的两个信息系统在地位上是相同的，交换的信息也基本是平等的，不存在一方监控另一方、 支配另一方的情况。 而通常整车厂会要求DMS 上端收集渠道数据、 监控 DMS 下端运行；DMS 下端负责数据的收集和上报传递。 整车厂 ERP 系统为 DMS 系统提供基础数据源；DMS 系统下端提供经销商 服务站日常管理功能，同时它又与 DMS 系统上端交换数据。 它接收整车厂下发的车主信息、车辆的维修历史，整车厂各种促销活动数据以及最新的各车型工程信息等各类数据。 除接收整车厂 DMS 上端发来的信息外，它还负责把经销商 服务站运营过程中的重要业务数据上传给整车厂 DMS 上端，比如整车厂十分关心的潜在顾客接待、顾客投诉、最终用户档案、车主变更的信息；对营销决策至关重要的渠道存货、存货货龄、最终销售数据、顾客行业类型；对售后服务至关重要的维修站配件库存、客户维修工单历史、原厂配件使用率、车辆故障分析等数据。 而 DMS 上端主要负责收集数据、处理数据和分发数据。同时它还负责销售、服务业务流程审批功能，并将通过审批的整车、配件订单送入 ERP 系统。 除这些基本的功能外，由于各个车厂的销售业务模式的多样性， 使得不同的整车厂在 DMS 上端实现的功能差异性极大。 从技术角度看， 国内主流汽车厂商 DMS 系统的部署遵循J2EE 标准的 MVC 技术架构，简单易用，系统运行稳定，环境依赖程度低，弱耦合，容易扩展，可维护，测试、调试方便。 2某车企DMS系统平台介绍 某车企 DMS 系统不仅在功能上要求丰富， 而且涉及的用户量较大，所以建设完成的系统需要是高可用性的；同时随着企业的发展，系统的扩展性也是系统平台设计的要点。 某车企 DMS 信息系统应用是基于标准的 J2EE 技术框架，可以共享相同的基础设施，包括存储、数据库系统、应用服务器群等。 整个应用采用 BS 架构，主机厂直接通过 IntranetInternet进行访问，而经销商用户则通过 Internet 方式进行访问。 某车企DMS 系统架构设计基于当前流行的 B S 结构， 不仅提供满足功能和性能的系统支持，而且整个体系考虑了高可靠性、高安全性和将来的扩展性。 在用户界面风格上，对于用户操作频繁的界面采用传统 CS界面来实现，但逻辑实现还是在 J2EE 平台上，以保持软件体系的一致，如维修站售后服务管理模块。 其他模块均采用 BS 结构的 IE 浏览器界面，以加强界面友好性和可视性。 某车企 DMS 系统软件开发基于开放的 Eclipse 或 Websphere开发工具 WSAD 的 IDE 环境，方便易用。 经过多个项目的实践和提炼，形成稳定高效的软件架构 InfoFrame，其体系架构如图 2 所示。 某车企 DMS 系统软件架构特点： （1）遵循 J2EE 标准的 MVC 架构，简单易用。 （2）运行稳定 ，环境依赖程度低 ， 可部署在 Windows，Linux，Unix 等多种操作系统平台上。 （3）各个逻辑层之间耦合度低，容易扩展。 （4）通过不同层次的封装 ，使代码复用程度高 ，维护调试更加方便，成熟度非常高。 此软件架构经过上海通用，一汽大众，上海汽车等多个大型项目验证，可靠性和稳定性非常高。图 3 是某车企 DMS 整体架构介绍。 系统主要完成车企销售公司和经销商之前的协同业务。 通过 DMS 的协同平台， 为某车企建立与经销商及服务维修站之间的整车销售和售后服务业务平台，达成如下业务目标： （1）向经销商和维修站输出管理标准 ，使经销商的整车销售和售后服务流程获得良好的系统支持。 （2）通过系统构建某车企对经销商销售和售后服务的支持和协同工作平台，提高车企与经销商之间沟通的透明度和效率，充分支持经销商的业务开拓。 （3）收集经销商销售和售后服务过程的数据作为相应业务分析的基础，通过分析发现弱项和差距，从而进行量化的绩效管理和针对性提升， 数据的收集是对车企和经销商的业务流程进行持续优化和提升的基础。 21 某车企 DMS 系统数据库结构介绍 某车企 DMS 系统数据库采用的是 Oracle11g 两个节点的RAC， 通过共享存储介质使两个节点同时访问唯一数据文件，应用层服务器通过 RAC 提供的 VIP（Virtual IP）负载均衡地连接到任何一个节点对外提供服务，当其中的一个节点发生故障时，另一个正常的节点可以自动接管其服务， 对于应用来说不需做任何更改， VIP 自动跳转来实现节点的切换， 在故障切换时 Oracle会自动恢复故障节点中的事务， 以使整个数据库处于一直运行状态。 具体的网络拓扑图如图 4 所示。 22 某车企 DMS 系统工作原理及技术先进性 从系统架构原理，也就是部署方面来说，某车企 DMS 信息系统支持集中式和分布式兼容的部署模式， 宽带网络不稳定的地区或规模大的经销商为获取更好的系统可用性 （不依赖网络实时在线），进行一定的软硬件投资，可以选择分布式部署，宽带网络很稳定或规模较小的经销商可以选择使用集中式系统， 无需服务器软硬件投资即可使用 DMS 系统， 规模变大后还可以再选择分布式部署，数据和应用可以无缝迁移到本地服务器中。 某车企 DMS 系统整体系统架构如图 5 所示。 （1）集中式经销商用户需在本机安装经销商应用客户端 ，发送 HTTP 请求， 可直接或经过 VPN 虚拟专用网， 穿越防火墙，Web Server 接受 HTTP 请求并响应。 （2）分布式部署的经销商需要在本地安装 DMS 应用服务和数据库；经销商应用通过 DE 模块和车厂应用进行数据交换。 DE 模块基于中间件 Infox，保证数据的可靠传输。 （3）车厂内部用户通过 IE 访问主机厂应用 ，发送请求 ，请求经过 Web Server，发送到 DMS 主机厂应用。 如果内部用户需在公司外部使用 DMS 系统，则可将 Web Server 映射一个外部域名或IP 地址。 （4）主机厂应用客户端和服务端均采用 J2EE 开发标准，部署在WebSphere 应用服务器上，数据库采用稳定且强大的 Oracle。 （5）经销商应用（DMS）与车厂应用（DCS）之间的数据传输由DE 模块实现 ，此 DE 模块基于中间件 Infox，保证数据的可靠传输。 （6）对于小规模经销商或者业务量较小的经销商 ，可以采用集中式部署的模式，经销商无需第三方的软硬件投资，对于大规模的经销商，或者小经销商业务量增大，经销商为获得更为稳定的使用