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

某车企营销数据管理平台的构建 　　 　　　　随着汽车企业的发展和车型的不断增加， 日益膨胀的营销数据信息给车企带来的影响也越来越明显， 除大量的客户信息需进行分析外，潜客、三表卡等信息对广告的精准投放产生重要的影响，售后信息、配件信息除经销商、服务站等需及时掌握，车企也需对此进行精准管理，降低 B／O 率。 若缺乏统一的营销数据管理平台， 车企将无法及时了解到整个市场资源的分配及使用情况。 鉴于以上情况，迫切地需要建设一套统一的营销数据管理平台（以下简称“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 技术框架，可以共享相同的基础设施，包括存储、数据库系统、应用服务器群等。 整个应用采用 B／S 架构，主机厂直接通过 Intranet／Internet进行访问，而经销商用户则通过 Internet 方式进行访问。 某车企DMS 系统架构设计基于当前流行的 B ／ S 结构， 不仅提供满足功能和性能的系统支持，而且整个体系考虑了高可靠性、高安全性和将来的扩展性。 　　在用户界面风格上，对于用户操作频繁的界面采用传统 C／S界面来实现，但逻辑实现还是在 J2EE 平台上，以保持软件体系的一致，如维修站售后服务管理模块。 其他模块均采用 B／S 结构的 IE 浏览器界面，以加强界面友好性和可视性。 　　某车企 DMS 系统软件开发基于开放的 Eclipse 或 Websphere开发工具 WSAD 的 IDE 环境，