从经验管理到可追溯系统

本文目錄 · 5 個章節

页面都齐了，为什么仍然对不上账？

设想销售、履约和财务都已经有了自己的页面，三边却无法回答“这笔业务究竟属于哪个客户”。这时再加一张总览表，未必能解决问题：如果每个模块对同一件事使用不同含义，连接接口只会更快地传递分歧。问题不是有没有数据，而是大家是否在谈同一个对象。

德馨星云的公开说明将主数据、角色权限与关键业务闭环纳入分阶段建设。我关心的是，这些基础约定如何让后续模块真正接起来。下面用说明性对象模型讨论设计顺序与代价；具体经营成效仍需要运行记录验证。^[1]

设想销售按联系人记客户，履约按收货地点记客户，财务按结算主体记客户。它们都可能对本地工作有用，却不应该未经区分就共用一个名称字段。把同名记录直接合并，可能把两个主体混为一谈；完全不关联，又会让同一组织的记录无法追溯。

说明性对象模型 · 主体、联系人和地点有关联，但不是同一种对象

一种可讨论的方案是给主体稳定标识，把联系人、收货地点和结算关系独立表达。订单引用相应标识，同时保留当时需要的业务快照。这样，之后修改联系信息，不必把历史单据悄悄改成“今天看起来正确”的样子。这是设计建议，不是公布德馨星云的内部数据库结构。

说明性责任表 · 不是企业实际岗位分工

“数据归业务所有”仍然太抽象。至少需要知道：谁能提出变更，谁有权确认，谁处理争议，旧记录是否保留。当这些问题没有答案，权限列表越长，责任也未必越清楚。

可追溯也不等于把每一次鼠标移动都记下来。记录应围绕有意义的状态变化，同时限定访问与保留范围。无节制地存储敏感信息，并不能自动提高治理质量。

先做一个小功能完全可能是正确选择。它能暴露真正的使用习惯，避免在会议里设计一个没人需要的完美模型。这里反对的不是原型，而是把临时约定当作稳定事实，在没有校验的情况下继续扩散。

更可取的顺序是限定一个小闭环：先统一其中最关键的对象与责任，保留少量真实异常，再用可验收的结果决定是否扩展。边界太大，协调成本会吞掉反馈；边界太小，只验证页面又可能遗漏跨角色交接。两者之间需要根据现场证据调整。

与其只问“模块是否上线”，不如抽取一条说明性记录，检查它能否从建立、使用、变更到更正完整追踪：当时是谁依据什么信息作出决定，今天又怎样发现口径不一致？如果仍要靠某个人的记忆拼出答案，就还没有真正完成这个闭环。

这也解释了我的取向：数字化首先是在建立可共同理解的对象与责任，然后才是更快地处理它们。产品结构提供方向，实际成效仍需要运行记录和使用者反馈来验证，不能用一张架构图代替。