一个优秀的管理型系统是怎样的？

麋鹿产品 2023-07-21 13:44:55

前置思考：

首先，在定义优劣之前需要先定义用户期望，只有满足用户需求的系统才有存在的价值，而对用户的满足程度实际上就是我们可以拿来评判优劣的标准了。所以首先必须要明确：

系统是为谁服务的（用户）
用户希望获得什么（价值）
用户害怕什么（痛点）

1. 满足度的评价指标

针对于用户的期望和需求的整理，可以将维度分成以下几个（实际上，大部分的管理类系统都可以从以下几个方面进行评估）：

产品经理，产品经理网站

1.1 流程覆盖度

流程线上化是很多管理型系统都需要走的一条很漫长的路，因为几乎后期所有的数据积累、流程优化、智能化都是基于先一步的流程线上化。所以往往各个层级的用户都非常关注流程的搭建。

但同时，这也是一条一不小心就容易走歪的路。经常有用户提线上化需求，在需求价值分析和沟通的过程中，他们往往把“线上化程度提高”作为一个价值点。

不过这真的是价值点吗？

不，切记，流程线上化是途径而不是目的，管理系统并不是单纯为了用键盘代替纸笔。所有线上化的前提是确保流程数据的价值性或者效率的提升点（当然，还有线上化的实施难度）。

此外，在这个过程中，对系统和流程认知的固化也是十分危险的。比如，做仓储做WMS就一定会有上下架吗？盘点一定是对着实物数据和库存数据进行的吗？这个问题的答案可在后文中找到。

1.2 用户驱动力

上文提到，流程线上化只是途径，真正的目的应该是实现系统的自我驱动。如果只是单纯的线上化，那么从单次来看，或许确实可以省几个人员，那么长期看你的前进方向在哪里？

在此，个人认为系统的用户驱动力可以分成2部分来看——数据驱动、策略驱动。

数据驱动，这部分是需要结合用户关键指标来进行考量的。线上化的流程需要对关键数据和节点进行积累，提取关键指标，通过数据及报表的数据展现来驱动业务动作，并帮助业务进行决策（题外话：之前我们对用户的报表需求管控是十分严格的，并不是单纯因为资源问题，更多的是希望用户真正认识到“正确数据”的重要性，而不是报表越多越好）。需要注意对于不同层级/角色的用户，数据是需要有区分度的。
策略驱动，在线上化的过程中，针对用户对流程的期望进行策略设计，通过策略实现流程优化及对用户指导。如WMS中的入库策略、分拣策略，不是单纯的用系统代替纸笔，而是直接由系统提供决策结果，减少用户思考，实现最优方案。

1.3 系统容错性

人非圣贤孰能无过，这句话用在系统使用过程中真的是一点都不过时，因为我们无法确保使用者对系统的了解程度和个人的能力，所以在系统设计必须要系统的易用性、防呆和异常处理，以此来提高系统的容错能力。

易用度：减少用户思考，在适当的时候给用户提示；了解用户习惯和用户语言，让你的系统看起来更简单易懂。

防呆：尽可能设计不会出错或者更难出错的流程。简单的如二次确认或者入库前的扫码校验等，都是系统的防呆设计。

异常处理：如果还是难以避免用户犯错，那么还是要考虑必要的异常处理，最简单的“单据撤回”功能就是一个很典型的异常处理。甚至有时我们需要特意设计一些“后门功能”避免用户在出错时无计可施而影响正常业务（这些功能往往需要高权限人员操作）。

虽然说对员工的培训和管理是业务在推进系统实施中需要尽到的职责。但是，记住，人总会犯错。我们可以通过系统记录异常数据协助用户进行员工管理，但单纯通过提高系统使用门槛绝对不是最好的办法。

1.4 用户体验

虽然说对于管理系统来说，用户体验的重要性可能确实没有在2C应用中那么重要，但是也是不可忽略的。不同于C端的体验是侧重于体感，B端的体验依然是更侧重于流程。

比如，笔者之前接触了一款OMS，在新增发货仓库时，需要分别在多个页面配置仓库基础信息、仓库-物流对应信息、物流覆盖信息、物流成本信息、物流时效信息等基础资料，且系统并未提供任何指导，但是只要少配置一个信息，这个仓库都将无法使用，这对于不熟悉系统的用户是十分不友好的，用户学习成本也提高了，也容易让用户在不断的报错、尝试中感到沮丧。

当然并不是完全不注重体感，系统视觉设计的美观简洁当然也可以提升用户体验。

1.5 安全性

安全性往往是用户关注比较少，但是作为设计者又不得不考虑的事。主要体现在权限的管控、审批流的设计（哪些流程需要审批，达到什么条件需要审批，需要谁审批）、用户数据的安全性、内容数据的安全性（如供应商信息、客户信息的存储、可见性）、数据隔离等。

对不同的企业，甚至对同一个企业不同的发展阶段对不同维度的重视度必然是不同的，通常系统前期更关注流程，中期关注驱动，后期关注体验，而安全和容错则贯穿其中。

产品经理也需要根据当前企业的需求分阶段性设计，分资源投入。这样才能做到在不同的阶段实现“好系统”的目标。

2. 基于行业的适应度

最后基于个人的体会，我还想补充一点，系统需要对行业有一定的适应度。

什么叫行业适应度？

目前的经济环境下，行业内、甚至企业内其所运营和承载的业务往往都不只一种，比如电商公司的供应链按运营模式有自营、联营，按品类更是五花八门，同时还结合各种营销；比如仓储按目的可分为前置仓、品类仓、中心仓等；并且所有的行业、企业内部都在快速的发展着，尝试着不同的新业务。

所以，一个好的系统其底层搭建，是需要能够快速适应同行业不同业务模式的需求的。

这里我来分享个负面案例：

从业初期，我有幸先后负责过两个不同行业的WMS设计，电商的和生鲜的。

在电商WMS的设计过程中，对当时的电商仓储场景基本完全覆盖，所有的出入库及库内管控都是非常标准化的流程。

但是在接到了生鲜的需求后，几乎是傻眼了，当时我们只做前置仓，基本的库内作业就是验收、分拣。因为需要快速出入库（前置仓是为了满足近距离的配送需求是不做仓内存储的）的需求，且生鲜类目并不多，所以业务流程是不需要上下架的，通过线下的实体库位划分来管控；且生鲜类目的验收规则（涉及到称重）和普通商品也是完全不同的，而原来的那套WMS的流程是不具备任何可配置能力，如果直接套用反而造成现场浪费大量的时间在系统操作上，且原订单的来源是固定来源于上游X系统，也没有做标准的对外对接接口。所以当时为了满足生鲜业务的需求，几乎是新做了一套WMS。

所以，如果企业存在多业务运营的可能性，或者本身就考虑到SAAS化，那么前期就必须考虑到系统流程的可配置性去满足后期业务的快速拓展。