連鎖門店資產設備維修管理App設計與應用

方媛 詹鳳 馬多春

(馬鞍山學院經濟與管理學院 安徽馬鞍山 243100)

對連鎖門店來說，盡管各連鎖零售企業設有內控機構并且配備了一定專職人員[1]，但因為門店分布廣泛，依然基本依賴于門店管理人員進行門店資產設備維修管理。各門店資產設備維修管理標準不一，連鎖門店資產設備維修管理是個相對薄弱的環節。門店管理人員應對突發狀況時，要求能夠妥善地處理各類緊急事件，抵消各種糾紛，更好地改善門店的經營水平和環境[2]。

傳統的門店資產設備報修方式是門店員工通過撥打公司相關部門電話，記錄故障，然后相關部門安排人員上門維修或者授權門店當地維修。這種方式效率較為低下，因為各種原因不能及時響應，相互推諉的情況屢有發生。甚至還有門店利用管理漏洞故意破壞門店資產。對于公司來說，資產設備的記錄清單也多數停留在人工統計階段，錯誤率高，記錄不夠及時準確。資產設備故障也分為很多種類，出現故障時，門店員工比較難以描述出故障的類型，也給維護維修準備帶來困難，也容易出現本身非故障誤認為是故障。隨著移動互聯網技術的發展，為此設計了一個連鎖門店資產設備維修管理App，門店員工可以通過App的技術支持、知識庫模塊識別判斷常見小問題，根據維護手冊可以解決。對于真正的故障，門店員工在可以隨時通過App進行拍照上傳、資產設備定位等功能進行報修，報修信息傳入系統后臺。根據技術人員識別判斷，報修接入企業的工單系統，形成信息閉環。需要上門維修的通過工單系統安排維修人員上門，在App 可以查看上門時間及人員。同時，App 資產設備管理信息會接入企業ERP 系統，企業管理人員可以隨時查看門店資產設備的維護維修進程，隨時更新門店的資產設備記錄，也為維護維修人員的工作量進行量化統計，便于薪酬績效核算。通過該App，提升了門店資產設備的維護維修的精準度，提升了維護維修效率，彌補管理漏洞，提升門店形象[3]。

1 系統功能設計

門店資產設備維修管理App 可劃分為前端（手機App、微信小程序）功能和后端（服務端）功能[4]。其中前端功能包括用戶注冊登錄、掃描二維碼快捷報修、普通報修、門店資產設備保養提醒、查看知識庫、用戶報修記錄查詢等主要功能，還包括App的常用功能，如微信登錄、修改密碼、消息中心等輔助功能。后端功能包括系統故障類型管理、報修管理、資產清單、工單管理、知識庫管理、常見問題管理等功能。系統功能結構如圖1所示。

圖1 系統功能結構圖

1.1 手機App主要功能

1.1.1 登錄流程

打開App展示歡迎頁，采用動圖方式，如果用戶未登錄，進入登錄頁，用戶輸入門店賬號和店長手機驗證碼登錄，或者采用微信一鍵登錄，微信登錄后需綁定手機號和門店賬號，門店賬號作為該App系統中唯一的用戶標識。登錄成功后系統將生成該用戶唯一的token，該token 保存在App 本地。之后所有App 發起的訪問請求都必須攜帶該參數，用作后端用戶身份的合法性校驗[5]。

如果用戶已經登錄過，則本地存在token，驗證token的合法性及有效期，驗證通過后則打開App展示歡迎頁，直接進入App 首頁。如果驗證失敗，則重新登錄。

1.1.2 報修功能

報修功能是該App的重要業務功能。用戶在使用報修功能時，首先允許獲取當前位置鎖定當前門店，掃描資產設備二維碼或條形碼，然后選擇填寫故障類型，同時可以輸入故障描述并拍照設備故障圖片上傳。以方便維修人員識別判斷，是需要公司派人上門維修還是授權門店當地維修，是需要維修還是直接報廢更換資產。

1.1.3 記錄查詢

HIV是一種變異性很強的病毒，各基因的變異程度不同，env基因變異率最高。HIV發生變異的主要原因包括反轉錄酶無校正功能導致的隨機變異；病毒在體內高頻率復制；宿主的免疫選擇壓力；病毒DNA與宿主DNA之間的基因重組；以及藥物選擇壓力，其中不規范的HAART以及患者依從性差是導致耐藥性的重要原因。

用戶可實時查看歷史報修的所有記錄，包括每個報修單的處理狀態、是否已接單、是否開始處理、處理人員是誰、是進行遠程維護還是安排人員上門維修、何時安排人員上門、是否需要更換物料等工單處理跟蹤信息。

1.1.4 知識庫功能

系統以列表的方式展示了門店資產設備維修維護手冊以及常見問題等。門店員工可從知識庫了解掌握常見小問題及處理方法，該功能大大減少了門店資產設備的誤報率，提高了門店員工對門店資產設備維修維護的知識水平，提升了門店運營的穩定性。

1.1.5 在線支持

門店員工可在App上對系統運行中出現的問題在線提問，系統會通過關鍵詞對知識庫進行全文檢索并將相關資料自動呈現給用戶，實現客服機器人人機對話的功能。在非辦公工作時間，以及重大節假日的時間，門店員工也可以通過這樣的方式得到技術支持。

1.2 管理平臺功能

1.2.1 故障類型管理

大型連鎖門店使用的各類資產設備復雜，故障類型較多，并且含有子類型。在后臺提供常見故障類型的多級管理維護功能，對各故障類型進行增刪改查。

1.2.2 資產設備清單

管理平臺詳細記錄門店所有資產設備的詳細信息：各類資產何時購入、數量、價值、維修更換記錄等。資產設備信息只讀，不可刪除和修改，與ERP系統中資產設備信息保持同步。

1.2.3 故障報修管理

該功能是對用戶端App或者小程序提交的報修單進行處理。報修單首先通過公司技術人員識別是否是屬于故障，如果是屬于故障，則向企業內部工單系統發出一個報修處理工單，數據接入工單系統，并接收工單系統的處理結果，并返回給門店人員。各系統之間的數據交換采用RESTful API完成[6]。

1.2.4 知識庫管理

后臺管理員在此模塊發布資產設備說明書以及與該資產設備相關的技術資料等信息，并定期進行更新技術資料，用戶在App 查看該知識庫。該知識庫也是用戶在線支持模塊的全文檢索來源。全文檢索采用Elasticsearch引擎實現。

1.2.5 系統管理

系統管理包括用戶管理、機構管理、角色管理、權限管理、菜單管理、日志管理、運行監控等常用的基礎功能[7]。這是一個管理系統安全有序運行的基礎，通過給不同的用戶分配不同的權限，不同的用戶可以使用不同的管理功能，如有的用戶可以處理資產設備故障報修功能，有的用戶可以進行知識庫維護。該管理模塊只向系統管理員角色開放，系統管理員擁有全部的權限，系統管理員可以創建其他業務管理員用戶，并設置相應角色并分配權限，實現權限的分組分級管理。

2 系統架構設計

客戶端App 分為3 種形態，包括Android 手機端、iOS手機端、微信小程序端。客戶端和服務端之間是C/S 架構，客戶端App 通過RESTful API 和后端進行交互[8]。后端管理系統運行在辦公PC 上，系統采用B/S架構，使用基于MVC模式的Spring Boot框架開發，包括核心服務程序和后端管理平臺界面。后端服務部署在公司內部私有云平臺，通過防火墻和網關提供互聯網接入，后端用戶使用瀏覽器通過公司內網訪問該應用。同時通過外網映射域名解析方式提供HTTPS RESTful API給客戶端App訪問，因為微信小程序必須使用具有SSL證書的接口訪問方式。3個客戶端采用統一的API接口，做到一次接口開發適用于所有的客戶端，便于系統的升級維護。系統架構如圖2所示。

圖2 系統架構圖

3 數據模型設計

數據庫設計（Database Design）是指對于一個給定的應用環境，構造最優的數據庫模式，建立數據庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求（信息要求和處理要求）。數據模型設計是系統開發的核心，數據庫的設計若不合理，服務器負擔就會很重，也可能會導致客戶端程序沒有響應，系統經常出問題，運維人員缺乏信心，導致軟件項目失敗、程序不可用。該項目數據庫的設計按照第三范式（3NF）要求，盡量減少冗余數據的產生，避免客戶端統計數據、數據分頁，在服務器端執行數據分頁、存儲過程計算、觸發器，避免大表交叉運算，減少設計表外鏈接[9]。主要的數據模型設計如下。

3.1 故障類型數據模型

故障類型數據模型，用于記錄故障的所有類型，該類型是分級的數據模型，要準確記錄出故障的分級關系。故障類型表的字段包括主鍵（id）、故障類型名稱（name）、直接父級故障id（parent_id）、所有父級故障id（parent_ids）、故障類型說明（remark）、顯示排序（display_order）等字段。故障類型數據模型的詳細設計如表1所示。

表1 故障類型數據模型設計

3.2 設備報修模型

設備報修模型，用于記錄用戶的報修信息，要能準確地記錄設備故障的詳細信息以及圖片。其記錄主要內容有報修單號、用戶編號、設備序列號、使用單位、故障類型、故障描述等。故障報修表的字段主要包括主鍵（id）、報修人ID（user_id）、產品序列號（series_num-ber）、客戶名稱（customer_name）、故障類型（fault_type_id）、聯系人（contact_person）、聯系電話（contact_phone）、故障時間（fault_time）、故障描述（description）、故障圖片IDS（image_ids）、狀態（status）、工單編號（flow_id）等字段，故障報修數據模型的詳細設計見表2。

表2 故障報修數據模型設計

3.3 在線支付模塊常見問題數據模型

在線支持模塊常見問題數據模型，用于存儲展示用于最常用的問題列表。主要記錄問題及關聯的知識庫，以及從知識庫中全文檢索的相關答案。常見問題表的字段主要主鍵（id）、問題（question）、關聯知識庫（knowledge_id）、答案（answer）等字段，常見問題數據模型的詳細設計如表3所示。

表3 常見問題數據模型設計

為減輕應用服務器的訪問壓力，所有的文件都獨立存放在服務器一個目錄，部署一個文件服務器，將應用服務器和文件服務器相分離。文件存儲模型包括主鍵（id）、原始文件名（original_file_name）、服務器存儲的新文件名（file_name）、文件類型（file_type）、文件大?。╢ile_size）、文件服務器存儲路徑（file_path）等，文件存儲模型的詳細設計如表4所示。

表4 文件數據模型設計

4 應用部署架構

該應用的客戶端分為3 種，包括Android 客戶端、iOS 客戶端、微信小程序客戶端。Android 客戶端軟件發布在應用寶、華為、小米、Oppo等應用市場，iOS客戶端發布在App Store，微信小程序發布在微信公眾平臺。

后臺應用部署在公司內部信息中心私有云平臺[10]，分配3 臺Linux 虛擬機，其中兩臺作為Web 服務器，一臺作為數據庫服務器。第一個Web 服務器部署核心Java應用服務，通過maven打包成jar包文件，可啟動多個服務運行在服務器多個端口，通過Nginx反向代理對外暴露端口訪問，通過該端口對外提供統一的API 給3 個客戶端訪問。第二個Web 服務器是文件服務器，管理所有該應用上傳的各種文件，包括故障的圖片文件，各種說明書，知識庫的PDF、Word 文件，提供文件瀏覽、下載服務，不占用應用服務器的計算資源，可擴展性強。隨著業務的增大，客戶的增多，可通過部署多個應用服務器，通過Nginx進行負載均衡。數據庫服務器采用mysql8.0。系統的部署架構如圖3所示。

圖3 系統部署架構圖

5 結語

隨著移動互聯網技術的飛速發展和廣泛應用，連鎖零售行業資產設備的管理模式也在發生著改變，傳統的靠人工進行管理方式已經不再適應當下時刻變化著的經營環境。為了提升公司對連鎖門店的資產設備維修管理水平，推出此連鎖門店資產設備維修管理App系統。該系統改變了傳統的資產設備維修管理作業模式，優化了公司對門店資產設備維護維修的工作流程，實現了公司分散在多個信息系統的信息有效集成和聯動，避免了多部門信息割裂的狀態，同時也為相關人員的薪酬績效核算提供量化標準。該App操作簡單、方便，實現了定位、掃碼、報修、處理、上傳照片、知識庫、用戶查詢等系列完整功能，實現了業務流程的自動化，大大提高了門店員工使用的便捷性，也提高了業務人員的知識技能水平和工作效率以及資產設備維修維護的精準度，通過對故障的跟蹤，實時為企業管理人員展示報修工作處理過程和結果，顯著提升了連鎖門店企業對門店資產設備維修管理的水平。今后將進一步對其進行不斷的升級與優化，推動其在多行業中的連鎖門店資產設備維修管理中的廣泛應用。