2023年B端入门：删除、禁用、失效怎么用

B端入门：删除、禁用、失效怎么用B端产品的设计，几乎都是在围绕新增、删除、修改、查询、显示、计算、传输、业务流做工作，而增删改查是原型设计中基础的基础。

今日的文章不长，围绕最近反复被争论的一个点共享一下我个人的看法：“删除”数据的方式有删除、禁用、失效，选择的规律是什么？

01数据删除的规律

两年前的时候我写过一篇文章《增删改查显算传，七字箴言搭建ToB系统底层框架》，至今看来还算是抽象、概括性比较高的，为便于读者理解，这里就直接引用了。

数据有新增的路径，就会存在删除的需求。通常说的删除，包含两种：

物理删除：真实删除，从数据库层面删除了数据，查询找不到该条数据，数据不行恢复。一般对于重要的基础数据，不建议设置删除功能，设计中要避开不行逆的操作；规律删除：假删除，只是从页面对数据进行了删除，数据库将数据的状态改写为“已删除”，可通过删除后撤回或者数据库备份恢复，产品设计中比较常用。数据的前后业务关联太强，不适合设计删除功能，那应当如何对数据进行合理的处理呢？个人理解的删除需求的存在，可能存在以下几种状况：

过期无用信息：可以设计数据库定时任务，依据实际的业务状况和指定条件，定期清理垃圾数据，适用于数据量较大的状况；信息录入错误：规律删除或者使用编辑功能修改数据；数据状态转变，或需要中止业务：使用字典状态来限制。文章中对删除规律和适用范围的理解依旧有效，但是不足之处在于详细使用场景的描述不够具体。接下来我们就聊一聊删除、禁用、失效的适用场景和区分在哪里。

02删除、禁用、失效的适用场景

1.删除的适用场景

依据尼尔森十大可用性设计原则，为了避开用户的误用和误击，系统应供应撤销和重做功能。日常高频新增的数据，人工输入就有可能产生误差。从体验的角度来看，系统要允许删除数据。

删除分为即时删除（提交信息之后的toast供应撤回和重做的选项）和事后删除（在列表或详情中供应删除功能）。

即时删除通常用于轻量化信息的提交，由于轻量化的信息内容简洁，提交后脑海中对信息还有整体的印象，而且和业务的耦合度低，从技术层面来说做数据的回滚也不简单出错，例如滴答清单笔记的马上撤回。

这里的撤回即软删除，并没有从数据库层面删除掉数据，而是将数据从已提交可撤回的状态变为了可编辑或者已提交的状态。

1）轻量化信息的删除——马上撤回

在后台系统的设计中，事后删除一般和列表同步消失。

这里有个点可以发散一下：为什么删除按钮不在详情页而是列表页呢？至少有一点，详情页的删除不满意批量删除的需求。

2）某电商后台的数据列表——删除

小结一下，除了高频新增这一个场景，使用删除还需要满意一个场景：非核心、低耦合的数据，这和“禁用”以及“失效”是对立的。

Tips:当删除数据是一项危急的操作时，也需要在确认过程中警示，例如二次弹窗确认（删除后不行恢复提示、删除影响提示）、高亮文字等。

2.禁用的适用场景

数据变得无用，不能被其他业务引用，又不能删除，怎么办呢？可以使用“禁用、停用、作废”功能来掌握数据的有效性和可见范围。

例如我司为以销定采（依据客户的订单进行选购，不提前选购库存）的业务模式，为了保证发货的准时性，在生成订单之后定时器会自动触发生成选购单。

但是难免存在客户临时取消、修改订单的状况，假如在数据库层面做删除操作，这类订单将不行追溯，会导致多采。

所以我们最终采纳了作废这种形式，通过作废标记的订单，指定人员可见，在特别的业务环节做核销即可。笔者对财务系统接触不深，这和发票的红冲应当是差不多的意思。

再例如Oracle中有一个设计是可以禁用物料分类，这也是出于业务的耦合度较高，信息需要留存，但是不适合再被后期的其他业务引用产生新的数据有关。

小结一下，业务的耦合度高，数据有变更会对其他业务产生影响需要保留的状况下，就可以采纳“禁用、停用、作废”这种形式来做数据的删除。

3.失效的适用场景

失效和禁用类似，区分在于数据的失效是否有明确的截止时间。

例如权限掌握中会通过有效期掌握员工的账号，由于员工的离职是有明确时间节点的，而且是在将来发生，在发生之前账号还要保持可使用的状态。

使用删除和禁用都不合适，一方面是要求当场操作，时效的要求较高（禁用），假如遗忘可能会产生损失；另一方面是会影响到其他相关数据，例如员工尚未完结的薪酬（删除）。

再例如Oracle中会推断物料的有效期来打算是否可以被其他业务引用，对应的场景就是B端商贸业务中，商品的调价或者产品下线均是有方案消失。通过截止时间使物料失效，便利选购、仓储人员提前做好物料管理方案。

价目表通过有效期来掌握数据的可见性也是一样的道理。

小结一下，在禁用的基础上，假如数据有明确的截止时间，可通过调整失效时间来提前做数据规划或“删除”。

03组织架构的“禁用”是要禁用人员的账号吗？

这个问题发生的背景是有学员提问，组织架构中有“禁用”的功能，这里的禁用是为了让组织架构下的员工账号失效，不能访问系统吗？

其实这个问题暴露了两个没有被理解的业务场景和一个产品设计原则：

组织架构是什么组织架构的变更意味着什么低耦合，高内聚看冯仑的《野蛮生成》（点击查看读书笔记）对于企业的组织架构设定有所感受，当时在读书笔记中写道：之前始终想输出一篇组织架构的变更对企业的影响，现在发觉自己的理解思路错了。组织是为目标服务的，人群行为的管理也是为了达成目标。所以，往上一层思索，应当讨论企业目标的变化对企业的组织架构、人群行为的影响。

Oracle（仅针对笔者接受的Oracle培训课，Oracle完整产品过于浩大，笔者还没有机会了解其全貌）将OMS产品的组织划分为四大类：库存组织、HR组织、业务实体、财务套账，这些对应的就是收入和成本数据。

在笔者接触的B端产品设计中，组织架构的划分就是根据成本组织和收入组织来规划的，严格匹配企业的战略目标，当目标发生变更，组织中资源的安排就会随之调整，所以产生了组织架构的新增和“删除”。（问题中学员提出的“禁用组织架构”其实也有误差，应当是使组织架构失效，由于组织架构的变更通常是有规划进行的，不是突然发生的大事。）

在某个组织被变更后，组织内产生的成本和收入依旧会进入财务体系核算，不宜删除，人员作为成本的一部分，数据自然也要保留在系统中。

所以组织内的人员会迁移到其他部门或者离职，因此需要对组织下个人账号做所属组织修改或者账号失效处理。

回到产品设计本身，我们有一个原则是一次只做一件事情，产品架构的设计要符合低耦合的原则。

组织的失效是对组织的相关数据做了冻结处理，冻结的前提条件是组织内正在有效的数据、账号需要迁移到其他组织下或者同时也使之失效。这个“前提”是另外要单独做的事情，禁用组织和禁用人员