汽車維修工時系統開發

郭 雄，曾海景

（上汽通用汽車股份有限公司，廣西 柳州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店、維修站、快修站的維修工時制定都有很好的指導、參考作用，以提高主機廠、維修站的售后管理水平，規范維修市場，統一維修工時費用。