热辣点击
赞助展示
最新图片

汽车售后服务系统设计doc

[点击图片进下一张 ] 跳转到

  1.本站不保证该用户上传的文档完整性,不预览、不比对内容而直接下载产生的反悔问题本站不予受理。

  汽车售后服务系统设计 摘 要: 近年来,我国的汽车生产企业不断发展壮大,各品牌保有量直线上升,原有的服务体系已不能满足日益膨胀的信息处理需求,同时随着服务促进销售的理念日益深入,被动的服务模式逐渐被主动客户关怀式的营销服务模式替代,这些都要求企业建立适应新形势的售后服务管理系统。本文基于上述思路,结合业务流程,采用数据驱动、组件化开发的设计思想,对新形势下的售后服务系统进行设计。 关键词: 汽车;售后服务;配件;保修;旧件 中图分类号: TP311.1;F426 [HT5H]文献标识码: A 文章编号: 10084738(2014)01011003 0 引言 近年来,我国汽车企业不断发展壮大,销售量和产品保有量不断提升,国家对汽车“三包”规定得越来越严格,售后服务又直接决定着汽车品牌的知名度和认可度,因此,汽车生产厂家对售后服务越来越重视。各大汽车公司均在大力推进全国服务站(4S店)布局建设,进行服务方式改进,以适应企业的发展需要。随之而来的是对信息采集、处理手段等方面要求的提高,而传统的售后信息处理模式与系统已无法满足需求。 汽车行业公认,售后服务的配件销售利润远高于整车销售利润[1] [2]。通过售后服务,挖掘更多的潜力客户,实现主动性营销,从而提高企业利润是各汽车生产厂家共同关心的问题。 为提升汽车生产企业的服务管理水平,提高服务质量和客户满意度,实现服务促进销售,提高企业利润与形象,建立适应新形式下的售后服务信息系统势在必行。 1 系统设计方法与目标 售后服务系统是在汽车销售后,对三包期内的各项服务进行管理的信息系统,涉及整车生产厂家、服务站、客户与供应商,对提升整车企业形象与管理水平具有不可替代的重要作用。 新形势下的汽车售后服务系统设计,要同时兼顾行业的通用性与企业的独特性。在对多家较有代表的汽车生产企业进行需求调研后,根据对汽车行业售后服务业务的理解,先确定产品定位,并设计出业务框架;再进行数据的私有化分析,设计出数据模型;然后依据业务框架的数据模型,进行功能框架的分析;之后进行数据加工过程分析,最终整理出系统的数据清单和组件清单,完成系统设计。 根据对企业需求的调研、分析与成本考虑,系统设计为B/S架构,可最大程度上减少对服务站、供应商的实施与培训工作,减少后期的运维工作量。 系统设计时,要充分考虑与周边系统的接口与衔接,并与服务站现有或未来建设的DMS系统实现无缝衔接。对于汽车生产企业已建设好的周边系统,可直接以接口的形式互相传递信息。如通过整车销售系统获取车辆信息与销售信息、通过BOM系统获取车型清单与配件清单、通过CRM系统获取客户信息。 系统设计实现以下主要业务目标: 根据产品保有量,对区域建设服务站(4S店)进行合理建议,促进整车销售及服务保障;为客户、服务站提供及时快速的服务保障与配件保障;及时提供车辆质量信息,作为改进产品的依据;建立完善的客户档案,实现主动客户关怀,定期发送服务建议与提醒,提升品牌知名度与用户认可度; 建立完善的车辆档案、保修和索赔档案,建立旧件返回管理机制,防止客户与服务站套保骗保;实现索赔与二次索赔结算的准确与及时,提升结算效率;引导服务站实现配件全部从总部采购,掌握服务站配件情况,促进配件营销。 2 系统业务框架设计 系统业务框架确定系统实现的业务范围与边界,如本系统只进行保修期内的售后服务管理,对于保修期外的维修,由DMS等系统管理。在对多家较有代表性的汽车生产企业进行业务现状与需求调研后,梳理出售后服务系统业务框架如图1所示: 3 业务数据模型设计与功能框架设计 在应用系统中,所有功能均会产生或操作数据,所有业务流程均对数据进行加工处理,业务角色或组织机构是数据的产生和操作对象,业务流程是数据的加工过程,数据是系统的核心。 根据数据的功能与操作对象,通常将数据分为主数据、标准数据和交易数据。 主数据(MD Master Data)指系统间共享数据(例如,客户、供应商、账户和组织部门相关数据),主数据一般变化较慢,在同一企业内,应对主数据进行一元化设计与管理,保证多个系统同一套主数据。 交易数据指记录业务活动的数据,在关系数据模型中,交易数据(如订单行项)可通过关键字(如,订单头或发票编号和产品代码)调出主数据。主数据必须存在并加以正确维护,才能保证交易系统的参照完整性。 标准数据指主数据以外的为交易提供支持的基础数据,如字典、参数类数据,一般维护量较小,有些仅需期初一次性初始化即可。 通过对业务框架的展开分析,可以建立主要业务数据模型,主数据有:车辆信息档案、客户信息档案、旧件清单、备件库存等;标准数据有:故障编码、工时定额、备件价格和车型备件目录等;交易数据有:各类服务申请单(外出救急报告单、大总成申请单、调件申请单等)、鉴定单(索赔申请单)、结算单、请购单与采购单等。 确立业务数据模型后,研究数据的公用性,进行数据私有化的配置设计,然后按产品组件可拔插和数据配置组件的设计原则,设计系统功能框架如图2所示: 4 数据加工分析 面向过程的设计方法通常使用HIPO的分析方法,分析每个功能节点上数据的输入、加工过程和输出。采用数据驱动模型的方法则以数据为线索,对业务数据模型中的数据项的产生、加工与结束的过程进行分析,得到各项功能节点。 数据加工分析分为两个阶段:数据清单阶段和数据加工过程清单阶段。 数据清单阶段,根据数据模型整理出系统所涉及的全部数据清单,包括:数据名称、数据类型、业务关键字、核心数据内容。 数据加工过程清单阶段,需要整理出每项数据及该数据每个加工过程的清单,包括:数据名称、数据类型、数据加工过程、加工过程说明、关联主数据、关联标准数据等。 进行数据库物理设计时,每项数据可以转化为一张基本数据表或一组主从数据表;业务关键字即表的主键;核心数据内容经细化后即为表的字段与属性;关联主数据、关联标准数据为表的约束或外键。 以交易数据中的鉴定单为例,其数据加工过程有:服务站填报、附加照片单据、预审规则设置、自动预审核、审核人分派、审核、驳回、复核、生成旧件单、冲单等;其业务关键字设计为鉴定单号,其核心数据内容有:主表:鉴定单号、鉴定章号、工时、VIN码、故障编码、审核人等;明细表:鉴定单号、备件编码、备件号、数量、价格、工时等;在鉴定单填报、审核等加工过程中,关联主数据有车型目录、车辆信息、备件目录,关联标准数据有故障编码、工时定额。 5 组件设计 组件可以分为业务组件、计算组件、报表组件、基础组件、技术组件。交易数据直接设计为业务组件;纯后台的计算设计为计算组件;权限、值列表等通用功能设计为基础组件;打印、导出、地图定位、短信发送等技术功能设计为技术组件;统计报表、分析设计为报表组件。 组件设计应遵循软件工程的高内聚、低耦合原则。 本系统中的新车整备卡、走保单、外出救急申请单、大总成保修申请单等每项数据均可设计为一个业务组件。如果使用系统的企业没有其中某项业务,即可不配置该组件。系统主要的业务组件有鉴定单、结算单、旧件单、备件采购单等。以鉴定单组件为例,其节点就应该对应加工过程中的:填写鉴定单、附加照片、相关单据、预审规则设置、自动预审核、审核人分派、审核、驳回、复核、生成旧件单、冲单。 其他业务组件有调件、质量信息、回访、供应商、客户、备件价格、车型备件清单、工时定额、故障编码等。 保修服务汇总分析、服务月报、服务年报、质量信息与培训分析统计、调件统计分析等设计为报表组件。 提醒短信发送、单据打印等设计为技术组件。 用户管理、权限管理、日志等设计为基础组件。 6 结束语 以数据驱动、组件化设计开发的方法,通过产品定位、业务框架、数据私有分析、功能框架、数据加工过程、数据清单、组件清单等步骤进行售后服务管理系统的设计,可快速有效的把握业务重点,实现功能可配置化,设计出适应新形势,既满足行业通用性又满足企业独特性的信息系统。 [参考文献] [1] 慧聪网.[EB/OL].http:///2013/06/0.shtml,20131210. [2] 人民网.[EB/OL].http:///GB/paper1668/8302/782275.html,20131210.


点击排行