汽车维修工时系统开发

郭 雄，曾海景

（上汽通用汽车股份有限公司，广西 柳州545007）

0 引言

近年来，国内汽车保有量持续增长，数据显示，2018年全国汽车保有量已达2.29亿辆。这是一个庞大的汽车售后市场，诸多的汽车维修服务，服务站如何给用户提供高效快捷的维修服务，售后汽车维修，除了维修汽车配件外，还需有更换配件及相关调整的时间，而汽车维修工时系统的开发正是体现了这个需求。下面将详细阐述汽车维修工时系统开发。

1 工时系统开发的背景

2017年之前，汽车维修行业内较多维修服务站使用的工时系统为单机版Access数据库、各经销商体系内独立的工时系统，已不能适应当前的汽车售后业务发展及信息收集分析等业务变化的需求，因此，各大汽车公司都在开发适用于自己业务流程、统一的维修工时管理系统，以实现汽车售后业务高效、管理优化、反馈及时准确的目标，从而满足公司未来的发展需求。

同时，在与经销商、服务站的沟通交流会、市场走访等场合，收到不少服务站建议，汽车主机厂能否开发一个结合汽车主机厂售后维修工时的服务站端工时系统，并向全国的服务站统一推广应用，利用汽车主机厂的资源，由汽车主机厂用户服务部开发、维护全国统一的工时基础数据、工时系统功能的更新与维护等，为服务站提高售后业务管理水平。基于这样的一个背景下，从2017年起，准备开发维修工时系统。在经过业务调研，系统开发，人员培训等一系列准备工作后，2018年底维修工时系统在全国服务站统一上线。

2 工时系统开发的意义和作用

汽车工时系统的开发和使用，对汽车生产公司和服务站在以下方面发挥积极的重大作用：

（1）在公司总部端，对工时基础数据库的维护和管理更快速有效，响应速度更高；

（2）公司能够提供统一的维修工时标准给服务站使用；

（3）公司能够及时分析售后市场车辆的质量现状，与同行业的对比情况并持续改进产品质量；

（4）方便公司对服务站的异常索赔进行监控；

（6）提供了公司总部与服务站的信息管理平台，加速了服务站和公司总部信息沟通的速度；

（7）规范服务站连带换件索赔工时，同时提高三包结算员工作效率。

3 工时系统开发

根据整体售后业务蓝图，工时系统在公司总部端与配件仓储管理系统和SAP系统进行连接，包含工时审核、单据审核、发票录入管理、车辆数据自动获取并校验、用户卡数据自动获取并校验、一般数据查询统计分析导出、card质量分析系统接口、基础数据维护功能。满足GM Globalwarranty系统的数据格式和数据要求，数据库设计满足GM Global warranty系统和CARD系统的数据要求。对现有车型的历史工时数据进行数据转换，确保维修工时历史数据能够成功转换到新工时系统中。按年建立工时归档机制，对已经索赔结算通过的工时、批次相关信息进行归档，并对归档数据提供查询和导出功能。

工时系统在经销商端与DMS系统进行连接，服务站在DMS系统根据VIN码查询工时数据，选定工时数据，然后提交索赔申请，数据流入工时系统，通过工时系统再传到本地SAP系统，在总部端进行索赔工时审核、结算。在服务站将需要返回的旧件在DMS系统上按要求发运，经由运输商送到配件库后，系统要求将零件在配件库的收货、上架等流程进行管理，并要求将零件的状态实时同步到SAP本地系统。针对配件库的业务需求由此设计了配件仓储系统。该系统将满足配件库的操作人员仓库管理进程的需要。工时系统开发业务流程如下图1。

图1 工时系统业务流程

3.1 工时系统网络架构设计

汽车工时系统网络架构设计如下图2，分为公司总部端、服务站端、服务器组、防火墙和网络5部分。公司总部端的功能设计是工时基础数据维护、索赔预申请审核、三包结算审核、维修信息统计、通知信息发布；服务站端的功能设计是工时基础数据查询、索赔预申请填报、索赔申请单提交、通知信息查询；服务器组设为数据服务器和应用服务器；防火墙和网络将公司总部端和服务站端连为一体，并满足在家办公和出差办公功能。

图2 工时系统网络架构

3.2 工时系统结构设计

工时系统结构采用分层式结构，分层式设计可以达到分散关注、松散耦合、逻辑复用、标准定义的目的。本系统分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层，如图3所示。

图3 工时系统结构

（1）数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表的 Select，Insert，Update，Delete 的操作。数据访问层（DAL）中，采用DAL Interface抽象出数据访问逻辑，并以DAL Factory作为数据访问层对象的工厂模块。对于DAL Interface而言，分别有支持MSSQL的SQL Server DAL和支持Oracle的Oracle DAL具体实现。而Model模块则包含了数据实体对象。在数据访问层中，完全采用了“面向接口编程”思想。抽象出来的IDAL模块，脱离了与具体数据库的依赖，从而使得整个数据访问层利于数据库迁移。DALFactory模块专门管理DAL对象的创建，便于业务逻辑层访问。SQLServerDAL和OracleDAL模块均实现IDAL模块的接口，其中包含的逻辑就是对数据库的Select，Insert，Update 和 Delete操作。因为数据库类型的不同，对数据库的操作也有所不同，代码也会因此有所区别。

（2）业务逻辑层：是整个系统的核心，它与这个系统的业务（领域）有关。如果涉及到数据库的访问，则调用数据访问层。在业务逻辑层中，不能直接访问数据库，而必须通过数据访问层。对数据访问业务的调用，是通过接口模块IDAL来完成的。

（3）表示层：是系统的UI部分，负责使用者与整个系统的交互。在这一层中，不包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关。在本系统中，是利用ASP.Net来设计的，因此包含了许多Web控件和相关逻辑。

按照系统业务流程设计，工时系统主体的总部端设为工时代码、工时开发、计算逻辑和数据维护4部分。

3.3 工时代码设计

根据整车零件分类、零件数量及售后质量问题分析需要，维修工时代码设计要能够区分整车零件系统，维修位置及多个零件更换的关联性，具体如下，前面三位是确定车辆零件装配位置的，维修位置不超过1000个，所以取3位数字；中间五位是确定具体零件的，第1位需要用来区分零件系统，根据技术中心零件名称UPC FNA规则，取1个字母表示，后面4位确定系统内部零件，由于每个系统内部零件都不超过10000个，所以取4位数字；如果有左右名称一样的零件一起维修，三包结算时需要一起填报结算单，所以取字母L/R区分。这样整个工时代码就是由8位或9位数字和字母编制，设为装配位置编码、零件系统编码、左右工位的字母3部分。

○○○ ○○○○○ （L/R）

装配位置编码 零件系统编码左/右工位编码

（1）装配位置编码：由3位数字编制，指明该维修操作是在车辆的哪一部份，并在索赔系统中对其进行工时约束。根据整车零件布置位置，设为9大区域，见表1。

表1 整车零件布置划分

（2）零件系统编码：由1位字母和4位数字编制，按零件系统进行定义，表示每个零件维修操作的号码。具体如表2。

表2 零件系统编码规则

（3）左/右工位编码：由字母L/R编制，在8位标准工时代码的基础上，添加后缀L/R的主要目的，是为了区分维修工位、满足售后结算系统索赔的需要。对于高价值的零部件，同类的左右件（如左右制动钳总成）需要一起填报索赔预申请，填报索赔单，通过L/R区分维修工位，可以叠加计算维修工时数，减少索赔预申请和索赔单填报和审核数量，方便索赔结算。

3.4 标准工时开发

标准工时开发是在特定的工作环境条件下，确定用规定的作业方法和设备，以一般中级技师的正常速度完成一定质量和数量的维修工作所必需的时间，其计算标准制定如下：

标准工时=（实测工时数＋车辆准备时间）×（1＋补偿系数）

名词定义如下：

补偿系数：此系数设定为25%，包括以下5项组成：

6%－准备配件、辅料时间

4%－研究维修资料、获取工单、与客户沟通具体故障时间

3%－准备特殊专用工具时间7%－技师个人差异补偿时间

5%－由于车龄、车况不同的补偿时间

车辆准备时间：车辆简单检查、举升及清洁时间等，固定为5min。

实测工时数。由秒表测量，具体的测量方法及步骤：

（1）准备秒表，笔和记录本《工时测量统计表》。

（2）清理顺畅维修车间，记录每道拆装步骤的名称和用秒表测试的操作时间。其中，不正常的拆装步骤需要重新测量，以便于计算出标准工时，并能确定更合理的工时数据。

（3）维修手册的拆装步骤必在记录本上体现，便于清楚知道维修拆装的顺序和正确性。

（4）在拆装过程中，影响维修时间的专用工具，维修设备必须在记录本上体现。

（5）计算每个换件维修的标准工时。

3.5 关联工时计算逻辑设计

车辆维修时，经常会有多个零件一起更换，并且大部分零件拆装步骤一样，为了准确计算多个零件一起更换的总工时数，所以设定关联工时，就是工时代码的装配位置编码设定一样，多个零件一起更换的总工时数不是简单累加，而在索赔系统设计计算逻辑，以达到最合理总工时数。关联工时计算方法逻辑设计如下：

（1）装配位置编码相同时，先将所有工时代码带有后缀L的工时数作比较，取最大工时数，再将所有工时代码带有后缀R的工时数做比较，取最大工时数；

（2）将工时代码带有后缀L和R的最大工时数相加；

（3）将相加后的工时数与其它装配位置编码相同且后缀不带L或R的工时代码做比较，取最大工时数。

3.6 索赔系统工时维护设计

工时代码和工时数据开发完成后，导入索赔系统运行，流入到服务站端供查询和使用。

（1）零件号与工时标准匹配。按照工时系统的结构设计工作流程，处理索赔工时工作的原始数据关键字设为车型-零件号-零件名称-OPTIONS，车型就是说明零件是用在那个车型上面，OPTIONS是该零件的一些用法备注。根据车型和OPTIONS信息，共同决定该零件的工时标准。有些零件OPTIONS栏的信息为空，说明在不同的动力配置上都会用到，那么该车型所有的工时标准，都设为与该零件进行匹配。

（2）零件号与工时代码匹配。零件号-零件名称是一一对应关系，在处理索赔工时工作时，会采用直观的零件名称从工时库中选择对应的工时代码。经过以上三个步骤，就能形成以车型-工时标准-零件号-零件名称-工时代码为关键字的数据链。

（3）工时数确认。零件号与工时标准、工时代码匹配完成后，就需要确定工时标准对应工时代码的工时数。确定工时数是整个索赔工时工作的核心，也是最关键的步骤，具体确定每个零件更换的操作时间。

（4）系统工时数据导入。经过以上步骤，就会形成一条数据链，其关键字设为：车型-工时标准-零件号-零件名称-工时名称-工时数，按照工时系统的结构设计要求，选择其中的关键字，导入工时库和工位-材料库，其中工时库的设定关键字为：工时标准-工时代码-工时名称-工时数，而工位-材料库的设定关键字为工时标准-工时代码-材料号。

4 结束语

随着国内汽车后市场进入一个较高的增长期，我们开发的这套汽车维修工时系统，对于汽车主机厂、4S店、维修站、快修站的维修工时制定都有很好的指导、参考作用，以提高主机厂、维修站的售后管理水平，规范维修市场，统一维修工时费用。