干货分享 | 业务管理后台的设计方案
编辑导读：业务管理后台对于很多企业来说都是必备的工具，不同的行业对管理后台的要求有细微的区别。本文作者从自身工作经验出发，提出了一套业务管理后台的设计方案，希望对你有帮助。
本人关于管理后台的一些设计有一部分的思考和总结，期望分享给大家后能有启发，进而对产品研发等工作有一部分帮助~
本文将从以下几个维度来分享对应内容：
竞品及行业分析
梳理业务需求和使用场景
设计方案详述
填坑经验分享
一、竞品及行业分析
1. 行业
不同的行业对管理后台的要求有细微的区别，以行业的角度来看：
大致可以分为以上几类，商城类的注重订单管理和产品发布，开放平台注重开发者和技术应用，客户管理（CRM）注重客户信息和订单管理，财务关注资产管理和工资管理，oa注重业务流和审批层级，特殊类如ota和金融监管也有各自的业务诉求，如ota注重软件管理和任务管理，双录注重监管和订单；
虽然管理后台面向各行各业都有不一样的特性，但一般都是有账号体系、角色体系、审批流程和操作日志等基础功能，下面基于其中一类以及笔者经历较深的领域-ota和开放平台；
单从ota来看，市面有分三种，FOTA、SOTA和集成OS三类；
FOTA-固件远程升级，一般是涉及到汽车底层电子元件的软件升级，刹车、座舱底层和仪表盘等软件的升级，大部分的传统车企都有这部分的能力，并且对安全性和稳定性要求都非常高，毕竟涉及到挡位这类行驶的控制，如果没有必要的缺陷，基本都不会随意升级；
但在汽车行业的资本渗透和新兴玩家入场，如特斯拉\小鹏等，现在逐步的开放FOTA的远端升级，但一般都是集成类升级，不会单独分开升级FOTA；
SOTA-又称软件系统升级，一般都是中控台的os层及应用升级，类似手机系统升级，但在汽车行业，这块还是跟手机端有所不同，区别在于以下几点：
交互模式；
应用稳定性安全；
语音交互为主；
云端能力&车联网；
举个简单的例子，如果车企需要升级某个应用层的bug或者有新的应用可以发布，一般都是通过SOTA的形式推送给到各端，包括已销售出去的汽车；
再举个其他领域的管理后台-开放平台。
本人接触的有语音语义和小程序开放平台，这类管理后台一般是面向三方开发者提供技术底层能力和应用框架；
类似于小程序管理后台，这类平台会提供开发者接入手册和底层小程序的技术框架，开发者基于这个框架定制化开发多个小程序，这类平台注重生态的扩充和开发者入驻的数量，所以一般都是技术能力或者市场实力较为雄厚的科技平台公司在布局，这类平台既具备To C能力也有To B的能力，区别在于两者的资质认证；
可以看出，各行各业的管理后台，五花八门，那么我们现在就基于单个应用领域去切入，进行详细的产品设计工作；
2. 竞品
单从OTA，我们就可以找出三类玩家：
传统ota厂商tier1：松下、博世多、伟世通、德赛西威、华阳等；
新型车企：特斯拉、小鹏、理想、蔚来等；
科技巨头及合资子品牌：百度、小米、阿里斑马等；
而传统车企一般都是和传统OTA厂商合作，当随着科技能力的渗透和智能化、新能源化越来越高，车企也逐步和科技公司一起合作，在这里我就举百度的ota能力(给BAIDU打个广告)；
从百度提供的ota后台可以看出类似开放平台的产品定位，以通用能力提供技术能力，输出较为丰富的行业理解能力和技术底层能力，使接入方能快速接入上线服务；
但如果我们从项目的角度出发，我们需要从平台中抽象出ota的特征通用需求出来作为参考，如下：
产品线管理：FOTA&SOTA；
设备接入管理：接入终端硬件信息和系统要求；
软件升级及任务包管理：android差分\整包；
数据管理：活跃\版本\地域分布；
在抽取了ota的特征需求后我们需要针对真实的项目情况去落地设计；
二、梳理业务需求和使用场景
一般而言业务管理后台都是面向TO B产品，而TO B的产品最大的特点就是定制化程度高，私有化部署；
而这对产品设计带来的挑战就是业务诉求频繁变化和场景复杂，如果考虑不全面，后续平台返工的成本、概率就会随着功能的堆叠变得越来越高；
所以第一步我们需要对业务需求和使用场景进行梳理，并且需要基于项目背景及终端设备出发，制定核心可落地的功能；
我们假定手头有以下信息：
车载应用系统：android 10.1.X;
终端芯片：XXX;
是否具备辅助设备：T-box；
设备型号：XXX；
有了以上的信息，咱们就以车载OTA（云端更新系统软件包）的服务端简化流程举例，可以参考以下的思路尝试整理：
经过上面的整理，我们就可以从中抽取出具体的平台功能，如下图标蓝部分：
当然这个也还算是初略的版本，所以下一步，我们就需要进入详细的方案拟定；
三、设计方案描述
在进行详细的需求设计时，遵循三个原则：
合理运用中台思路；
能简化就简化；
关注业务流程闭环；
前面两点简单地说，就如下图展示的情况，模块高度集成且互相关联；
然后在制定详细的需求书时需要先制定基础功能，类似于角色数量、权限管理及审批、账号登录\登出等，如下图：
还是以OTA作为例子，在这个例子中，由于首先是面向的对象是车企研发和测试的人员，使用对象不会外授权给外部开发者和市场人员。
毕竟如果更新包或者策略出问题了，这个肯定是会造成车企经济损失和名誉损伤。
这时候其实角色数量和审批的流程就可以简化处理，角色定义管理员和普通角色、审批流采取二级审批或者验证码二次确认即可，如果为了保险，其实也可以增加一个密钥验证；
确定好角色和审批，就需要确认账号体系，但一般TO B大型项目都会有一套通用的账号体系，所以直接沿用即可；
当我们制定了完整闭环的业务流程后，我们就可以参考之前的需求分析抽取的功能点和业务流程制定几个大的功能模块；
如：
首页：呈现业务数据和报表，涉及设备、系统版本、升级成功率等数据类型等；
软件包管理：管理软件包和上传通道，涉及软件包校验、软件包大小要求及信息、产品线管理等；
任务管理：制定OTA的规则和策略，涉及OTA任务信息、升级版本要求、重复推送机制、基于VIN码和系统版本推送、任务中止条件等；
操作历史记录：记录每个用户对应的操作记录，涉及软件包上传、产品线信息变更、任务发布等；
账号中心和通知中心：记录审批的通知和用户角色管理，涉及角色梯度、任务发布通知管理等；
由于OTA的领域要求，一般都是会对数据及升级情况有比较明确且具体的要求，下面就以数据上报和报表呈现展开；
在我负责项目中，接收的数据要求有：
推送及升级情况：包括推送和下载情况；
设备及分布情况：当前主流设备版本号、版本分布情况、在线设备数量；
任务及详细情况：单次升级包推送情况、单次任务成功率、失败及对应日志；
针对推送及升级情况这类数据：
在初始化项目时，一般我们都是需要有初步的数据源导入到平台中，因为从0-1的项目中，设备未激活，无法上报对应的数据，我们就无法发布任务推送到端上，所以是需要默认的数据源作为平台的基础数据；
而一般这类基础数据都会由车企或者tier1来提供，我们需要导入到平台中进行初始化；
有了基础数据，我们还需要定义好具体的数据指标，方便项目交付后的验收，呈现的数量虽然能满足车企的诉求，但不够直观，所以一般我们还是需要定义具体指标；
如推送成功率=下载成功量/成功推送量等；
针对设备及分布情况这类数据：
这类数据需要基于客户端下载的情况进行上报，如设备在接收到软件包升级时，需要在升级成功时同时上报升级结果、当前版本，如果涉及到地区分布需求，还需要上报经纬度，然后后台进行推演按照地区或者省份进行展示；
针对任务及详细情况这类数据：
任务对于每次的ota都是至关重要的部分，需要准确记录每一个VIN码的升级情况（VIN码、升级成功与否、推送成功与否等），任务的推送情况及错误日志上报；
另外任务的详细信息也许准确在后台上做展现，方便后续的维护和迭代运营；
四、填坑经验分享
最后我就以个人的经验分享“坑”，方便大家避避雷；
坑一：平台审批权限不够细分
一般权限分几种：操作权限、菜单权限、数据权限和用户权限；
我遇到过之前有个平台只有菜单权限，整个平台中只要具备菜单的权限就可以进行操作，细分颗粒度不够，导致管控的力度比较粗；
这样导致的后果，就是无法有效的管理用户的操作和数据泄密的问题，而且如果还没有操作记录功能的话，那完全无法知道是谁做了哪些操作，追溯起来十分麻烦；
坑二：交互方式不太符合主流
一般而言，平台化的交互模式都是自上而下，模块放置左侧，右侧放置模块内容信息，并且以列表的形式呈现；
这样的结构符合用户的习性和查看习惯，如果刻意追求标新立异的模式，如从左到右的模式，就有种画蛇添足的感觉；
如之前接触过一个平台顶部放置功能栏，左侧放置数据报表和数据，右侧放置模块内容信息，整个交互即让人眼花缭乱，交互起来又经常出问题；
另外平台需要注意尽量不要出现以下几点：
弹框之后再出现弹框；
不知道操作路径在哪里，即用户无法知道进入的是二级还是三级；
能用弹框就用弹框，不要轻易新增页面；
以上就是本文的全部内容，希望能在业务管理后台的设计上提供一些建议和帮助！
作者 @SiegZhong
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
