某车企营销数据管理平台的构建,市场营销论文

某车企营销数据管理平台的构建,市场营销论文随着汽车企业的发展和车型的不断增加，日益膨胀的营销数据信息给车企带来的影响也越来越明显，除大量的客户信息需进行分析外，潜客、三表卡等信息对广告的精准投放产生重要的影响，售后信息、配件信息除经销商、服务站等需及时把握，车企也需对此进行精准管理，降低B／O率。若缺乏统一的营销数据管理平台，车企将无法及时了解到整个市场资源的分配及使用情况。鉴于以上情况，迫切地需要建设一套统一的营销数据管理平台〔下面简称DMS系统〕，并实现经销商、服务站管理的规范化、有序化。1DMS系统概述DMS的前身是服务站的售后维修管理系统，该系统从20世纪90年代初就开场建设了。伴随着2002年以来的汽车行业井喷，各车企纷纷提出建设DMS〔DealerManagementSystem〕的要求，即整合整车厂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环境，方便易用。经太多个项目的实践和提炼，构成稳定高效的软件架构InfoFrame，其体系架构如此图2所示。某车企DMS系统软件架构特点：〔1〕遵循J2EE标准的MVC架构，简单易用。〔2〕运行稳定，环境依靠程度低，可部署在Windows，Linux，Unix等多种操作系统平台上。〔3〕各个逻辑层之间耦合度低，容易扩展。〔4〕通过不同层次的封装，使代码复用程度高，维护调试愈加方便，成熟度非常高。此软件架构经过上海通用，一汽群众，上海汽车等多个大型项目验证，可靠性和稳定性非常高。图3是某车企DMS整体架构介绍。系统主要完成车企销售公司和经销商之前的协同业务。通过DMS的协同平台，为某车企建立与经销商及服务维修站之间的整车销售和售后服务业务平台，达成如下业务目的：〔1〕向经销商和维修站输出管理标准，使经销商的整车销售和售后服务流程获得良好的系统支持。〔2〕通过系统构建某车企对经销商销售和售后服务的支持和协同工作平台，提高车企与经销商之间沟通的透明度和效率，充分支持经销商的业务开拓。〔3〕收集经销商销售和售后服务经过的数据作为相应业务分析的基础，通过分析发现弱项和差距，进而进行量化的绩效管理和针对性提升，数据的收集是对车企和经销商的业务流程进行持续优化和提升的基础。2．1某车企DMS系统数据库构造介绍某车企DMS系统数据库采用的是Oracle11g两个节点的RAC，通过分享存储介质使两个节点同时访问唯一数据文件，应用层服务器通过RAC提供的VIP〔VirtualIP〕负载平衡地连接到任何一个节点对外提供服务，当华而不实的一个节点发生故障时，另一个正常的节点能够自动接管其服务，对于应用来讲不需做任何更改，VIP自动跳转来实现节点的切换，在故障切换时Oracle会自动恢复故障节点中的事务，以使整个数据库处于一直运行状态。详细的网络拓扑图如此图4所示。2．2某车企DMS系统工作原理及技术先进性从系统架构原理，也就是部署方面来讲，某车企DMS信息系统支持集中式和分布式兼容的部署形式，宽带网络不稳定的地区或规模大的经销商为获取更好的系统可用性〔不依靠网络实时在线〕，进行一定的软硬件投资，能够选择分布式部署，宽带网络很稳定或规模较小的经销商能够选择使用集中式系统，无需服务器软硬件投资即可使用DMS系统，规模变大后还能够再选择分布式部署，数据和应用能够无缝迁移到本地服务器中。某车企DMS系统整体系统架构如此图5所示。〔1〕集中式经销商用户需在本机安装经销商应用客户端，发送HTTP请求，可直接或经过VPN虚拟专用网，穿越防火墙，WebServer接受HTTP请求并响应。〔2〕分布式部署的经销商需要在本地安装DMS应用服务和数据库；经销商应用通过DE模块和车厂应用进行数据交换。DE模块基于中间件Infox，保证数据的可靠传输。〔3〕车厂内部用户通过IE访问主机厂应用，发送请求，请求经过WebServer，发送到DMS主机厂应用。假如内部用户需在公司外部使用DMS系统，则可将WebServer映射一个外部域名或IP地址。〔4〕主机厂应用客户端和服务端均采用J2EE开发标准，部署在WebSphere应用服务器上，数据库采用稳定且强大的Oracle。〔5〕经销商应用〔DMS〕与车厂应用〔DCS〕之间的数据传输由DE模块实现，此DE模块基于中间件Infox，保证数据的可靠传输。〔6〕对于小规模经销商或者业务量较小的经销商，能够采用集中式部署的形式，经销商无需第三方的软硬件投资，对于大规模的经销商，或者小经销商业务量增大，经销商为获得更为稳定的使用支持，能够切换到分布式部署