方媛 詹凤 马多春
(马鞍山学院经济与管理学院 安徽马鞍山 243100)
对连锁门店来说,尽管各连锁零售企业设有内控机构并且配备了一定专职人员[1],但因为门店分布广泛,依然基本依赖于门店管理人员进行门店资产设备维修管理。各门店资产设备维修管理标准不一,连锁门店资产设备维修管理是个相对薄弱的环节。门店管理人员应对突发状况时,要求能够妥善地处理各类紧急事件,抵消各种纠纷,更好地改善门店的经营水平和环境[2]。
传统的门店资产设备报修方式是门店员工通过拨打公司相关部门电话,记录故障,然后相关部门安排人员上门维修或者授权门店当地维修。这种方式效率较为低下,因为各种原因不能及时响应,相互推诿的情况屡有发生。甚至还有门店利用管理漏洞故意破坏门店资产。对于公司来说,资产设备的记录清单也多数停留在人工统计阶段,错误率高,记录不够及时准确。资产设备故障也分为很多种类,出现故障时,门店员工比较难以描述出故障的类型,也给维护维修准备带来困难,也容易出现本身非故障误认为是故障。随着移动互联网技术的发展,为此设计了一个连锁门店资产设备维修管理App,门店员工可以通过App的技术支持、知识库模块识别判断常见小问题,根据维护手册可以解决。对于真正的故障,门店员工在可以随时通过App进行拍照上传、资产设备定位等功能进行报修,报修信息传入系统后台。根据技术人员识别判断,报修接入企业的工单系统,形成信息闭环。需要上门维修的通过工单系统安排维修人员上门,在App 可以查看上门时间及人员。同时,App 资产设备管理信息会接入企业ERP 系统,企业管理人员可以随时查看门店资产设备的维护维修进程,随时更新门店的资产设备记录,也为维护维修人员的工作量进行量化统计,便于薪酬绩效核算。通过该App,提升了门店资产设备的维护维修的精准度,提升了维护维修效率,弥补管理漏洞,提升门店形象[3]。
门店资产设备维修管理App 可划分为前端(手机App、微信小程序)功能和后端(服务端)功能[4]。其中前端功能包括用户注册登录、扫描二维码快捷报修、普通报修、门店资产设备保养提醒、查看知识库、用户报修记录查询等主要功能,还包括App的常用功能,如微信登录、修改密码、消息中心等辅助功能。后端功能包括系统故障类型管理、报修管理、资产清单、工单管理、知识库管理、常见问题管理等功能。系统功能结构如图1所示。
图1 系统功能结构图
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 故障类型管理
大型连锁门店使用的各类资产设备复杂,故障类型较多,并且含有子类型。在后台提供常见故障类型的多级管理维护功能,对各故障类型进行增删改查。
1.2.2 资产设备清单
管理平台详细记录门店所有资产设备的详细信息:各类资产何时购入、数量、价值、维修更换记录等。资产设备信息只读,不可删除和修改,与ERP系统中资产设备信息保持同步。
1.2.3 故障报修管理
该功能是对用户端App或者小程序提交的报修单进行处理。报修单首先通过公司技术人员识别是否是属于故障,如果是属于故障,则向企业内部工单系统发出一个报修处理工单,数据接入工单系统,并接收工单系统的处理结果,并返回给门店人员。各系统之间的数据交换采用RESTful API完成[6]。
1.2.4 知识库管理
后台管理员在此模块发布资产设备说明书以及与该资产设备相关的技术资料等信息,并定期进行更新技术资料,用户在App 查看该知识库。该知识库也是用户在线支持模块的全文检索来源。全文检索采用Elasticsearch引擎实现。
1.2.5 系统管理
系统管理包括用户管理、机构管理、角色管理、权限管理、菜单管理、日志管理、运行监控等常用的基础功能[7]。这是一个管理系统安全有序运行的基础,通过给不同的用户分配不同的权限,不同的用户可以使用不同的管理功能,如有的用户可以处理资产设备故障报修功能,有的用户可以进行知识库维护。该管理模块只向系统管理员角色开放,系统管理员拥有全部的权限,系统管理员可以创建其他业务管理员用户,并设置相应角色并分配权限,实现权限的分组分级管理。
客户端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 系统架构图
数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。数据模型设计是系统开发的核心,数据库的设计若不合理,服务器负担就会很重,也可能会导致客户端程序没有响应,系统经常出问题,运维人员缺乏信心,导致软件项目失败、程序不可用。该项目数据库的设计按照第三范式(3NF)要求,尽量减少冗余数据的产生,避免客户端统计数据、数据分页,在服务器端执行数据分页、存储过程计算、触发器,避免大表交叉运算,减少设计表外链接[9]。主要的数据模型设计如下。
故障类型数据模型,用于记录故障的所有类型,该类型是分级的数据模型,要准确记录出故障的分级关系。故障类型表的字段包括主键(id)、故障类型名称(name)、直接父级故障id(parent_id)、所有父级故障id(parent_ids)、故障类型说明(remark)、显示排序(display_order)等字段。故障类型数据模型的详细设计如表1所示。
表1 故障类型数据模型设计
设备报修模型,用于记录用户的报修信息,要能准确地记录设备故障的详细信息以及图片。其记录主要内容有报修单号、用户编号、设备序列号、使用单位、故障类型、故障描述等。故障报修表的字段主要包括主键(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 故障报修数据模型设计
在线支持模块常见问题数据模型,用于存储展示用于最常用的问题列表。主要记录问题及关联的知识库,以及从知识库中全文检索的相关答案。常见问题表的字段主要主键(id)、问题(question)、关联知识库(knowledge_id)、答案(answer)等字段,常见问题数据模型的详细设计如表3所示。
表3 常见问题数据模型设计
为减轻应用服务器的访问压力,所有的文件都独立存放在服务器一个目录,部署一个文件服务器,将应用服务器和文件服务器相分离。文件存储模型包括主键(id)、原始文件名(original_file_name)、服务器存储的新文件名(file_name)、文件类型(file_type)、文件大小(file_size)、文件服务器存储路径(file_path)等,文件存储模型的详细设计如表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 系统部署架构图
随着移动互联网技术的飞速发展和广泛应用,连锁零售行业资产设备的管理模式也在发生着改变,传统的靠人工进行管理方式已经不再适应当下时刻变化着的经营环境。为了提升公司对连锁门店的资产设备维修管理水平,推出此连锁门店资产设备维修管理App系统。该系统改变了传统的资产设备维修管理作业模式,优化了公司对门店资产设备维护维修的工作流程,实现了公司分散在多个信息系统的信息有效集成和联动,避免了多部门信息割裂的状态,同时也为相关人员的薪酬绩效核算提供量化标准。该App操作简单、方便,实现了定位、扫码、报修、处理、上传照片、知识库、用户查询等系列完整功能,实现了业务流程的自动化,大大提高了门店员工使用的便捷性,也提高了业务人员的知识技能水平和工作效率以及资产设备维修维护的精准度,通过对故障的跟踪,实时为企业管理人员展示报修工作处理过程和结果,显著提升了连锁门店企业对门店资产设备维修管理的水平。今后将进一步对其进行不断的升级与优化,推动其在多行业中的连锁门店资产设备维修管理中的广泛应用。