恒田企业大脑 Object 建模 Proposal 建议稿

输出人：CIO小田
日期：2026-06-15
适用场景：供 Lucas、Ben 起草 Object 建模方案参考；建议先提交给紫瑶审核，审核通过后再在群内发布正式版本。
资料口径：基于今天会议任务、此前与钱工同步的企业大脑建设方向、已核验过的后台数据规模和当前恒田制度/岗位/SOP资料覆盖情况整理。本稿是建议稿，不替代 Lucas、Ben 的正式建模方案。

---

一、管理结论

建议首批 Object 不要一次铺太大，先确认 8 类核心 Object，用来把恒田企业大脑从“文件可查”推进到“业务对象可理解、可追溯、可被小田使用”。

首批建议 Object：

建议第一阶段只把 SOP、岗位、部门做深；表单、流程步骤、业务术语、来源文件、待办作为配套对象。
这样既能让 Lucas、Ben 快速交付方案，也能让紫瑶审核时抓住重点：对象边界是否清楚、字段是否够用、小田是否能读懂并用于回答。

---

二、为什么首批从 SOP 和岗位开始

从恒田业务角度看，SOP 和岗位是企业大脑最容易产生管理价值的两个入口。

1. SOP 解决“事情怎么做”

SOP / 制度 / 流程文件能回答：

• 这件事应该怎么做？
• 谁负责？谁协同？谁审批？
• 输入资料是什么？输出结果是什么？
• 哪些地方影响交期、质量、成本、安全？
• 异常时怎么升级？
• 相关表单在哪里？

这直接影响现场执行、质量稳定、客户交付和管理稽核。

2. 岗位解决“谁来做、做到什么标准”

岗位 Object 能回答：

• 这个岗位属于哪个部门？
• 主要职责是什么？
• 参与哪些 SOP / 流程？
• 对订单、质量、成本、交期承担什么责任？
• 需要哪些能力、经验、培训？
• 和哪些岗位协作？
• 有哪些风险边界和升级要求？

这直接影响组织责任清晰、培训、交接、绩效和跨部门协作。

---

三、首批 Object 的建议字段

1. SOP Object：标准作业流程 / 制度流程

1.1 SOP 的业务定义

SOP Object 是指恒田企业内用于规定某项业务、管理或现场作业如何执行的制度、流程、作业规范、管理办法或操作手册。

它不是简单保存一个 Word 文件，而是要让小田知道：

这份 SOP 管什么事、谁负责、怎么执行、需要哪些表单、影响哪些业务风险、原始文件在哪里、是否还需要业务部门确认。

1.2 建议核心字段

1.3 SOP Object 面向小田的介绍解释

建议每个 SOP Object 必须有一段“小田可用解释”，长度控制在 100-300 字。

模板：

这是一份关于【业务场景】的【制度/流程/作业规范】。它主要规定【谁】在【什么情况下】按照【哪些关键步骤】完成【什么输出】。这份 SOP 对恒田的价值是保障【订单交付/质量/成本/安全/合规/效率】。小田回答相关问题时，应优先说明它的适用范围、责任部门、关键步骤、风险控制点和来源状态；如果版本、签批或生效日期不完整，要明确标注为待确认。

示例：晨会管理制度

《晨会管理制度》是一份用于规范公司级、部门级、班组级晨会的管理制度。它要求通过每日或每周晨会同步出勤、当日目标、质量要求、客户标准、安全事项、前日问题和改善进度。对恒田的价值是减少现场信息断层，提升订单交付、质量预防和问题闭环能力。小田回答时应重点说明适用范围、责任部门、晨会内容、记录和改善闭环要求；如果发布日期、实施日期或处罚条款合规性未确认，要标记为待补充/待复核。

---

2. Role Object：岗位

2.1 岗位的业务定义

Role Object 是指恒田组织中承担明确职责、协作关系、能力要求和业务结果责任的岗位。

岗位 Object 不等于员工个人信息，不应默认展开个人隐私、薪酬和绩效。它重点描述：

这个岗位负责什么、和谁协作、参与哪些流程、对交期/质量/成本/客户有什么影响、需要哪些能力、有哪些风险边界。

2.2 建议核心字段

2.3 岗位 Object 面向小田的介绍解释

模板：

【岗位名称】属于【部门】，主要负责【核心职责】。该岗位在恒田业务中影响【订单/质量/交期/成本/安全/客户沟通】。它通常需要和【上下游岗位/部门】协作，并参与【关联 SOP】。小田回答岗位问题时，不展开员工个人隐私，应说明岗位职责、协作边界、关键输出、风险点和需要升级的情况；如果岗位说明书版本或部门归属未确认，要标记为待补充。

示例：班组长

班组长属于生产现场管理岗位，主要负责班组人员安排、当日产量目标落实、质量要求传达、现场纪律、安全和异常问题上报。该岗位直接影响订单交付、生产效率、质量稳定和一线执行闭环。小田回答班组长相关问题时，应重点说明其在晨会、生产安排、质量提醒、问题反馈和人员协作中的职责，不应展开具体员工隐私；如岗位说明书版本未确认，应提示由生产/人力或企管补充确认。

---

3. Department Object：部门 / 科室

建议字段：

面向小田解释重点：

部门 Object 主要帮助小田判断“这件事归谁负责、哪些岗位参与、哪些 SOP 属于该部门、跨部门时谁协同”。

---

4. FormTemplate Object：表单 / 模板

建议字段：表单名称、编号、用途、适用 SOP、填写人、审核人、关键字段、提交时点、保存位置、风险控制点、来源文件、状态。

面向小田解释重点：

表单不是附件，而是 SOP 执行是否留痕的证据。没有表单或记录，很多管理动作就无法证明是否执行、是否闭环。

---

5. ProcessStep Object：流程步骤 / 节点

建议字段：步骤名称、所属 SOP、步骤顺序、执行岗位、输入、动作、输出、判断条件、异常处理、时限要求、控制点。

面向小田解释重点：

流程步骤用于把长篇 SOP 拆成一线能执行、系统能追踪、小田能解释的动作链。

---

6. BusinessTerm Object：业务术语

建议字段：术语名称、正式定义、同义词、所属分类、来源文件、适用场景、相关 Object、是否人工确认、审核人、状态。

面向小田解释重点：

业务术语用于统一恒田内部语言，避免同一个词在营业、生产、品控、财务、人力之间解释不一致。

---

7. SourceDocument Object：来源文件

建议字段：文件名、路径、文件类型、版本、上传/同步时间、来源系统、关联术语、关联 SOP、关联岗位、正文抽取状态、可信度、是否过期。

面向小田解释重点：

来源文件是企业大脑可信度的根。小田不能只给结论，还要知道结论来自哪里、是否正式、是否过期、是否需要业务负责人确认。

---

8. ActionItem Object：待办 / 改善事项

建议字段：事项名称、来源对象、问题描述、责任人/部门、审核人、截止时间、风险等级、状态、关闭标准、复盘结论。

面向小田解释重点：

ActionItem 用来把“发现问题”变成“有人负责、有限期、有关闭标准”的管理闭环。

---

四、Object 之间的关系建议

首批不要只做孤立字段，要把关系一起定义清楚。

建议第一批关系：

---

五、审核规则建议

Lucas 和 Ben 的方案做好后，建议紫瑶审核时重点看 6 件事：

1. 对象数量是否克制：第一批不建议超过 8 类 Object；先做深 SOP、岗位、部门。
2. 字段是否能服务业务问题：不是为了字段完整，而是为了回答“谁负责、怎么做、风险在哪、如何闭环”。
3. 是否有面向小田的解释字段：每个 Object 都要有 xiaotian_summary，否则小田只能读字段，不能用业务语言回答。
4. 是否保留来源和可信度：必须能追溯原文件、版本、审核状态。
5. 是否保护敏感信息：岗位 Object 不展开员工隐私、薪酬、个人绩效；客户、合同、财务也不能在首批随意展开。
6. 是否能形成 Action 闭环：发现版本缺失、责任不清、表单缺失时，要能形成待办。

---

六、建议交付格式

建议 Lucas 和 Ben 输出的正式方案至少包括：

1. 首批 Object 清单：明确本阶段确认几个 Object。
2. 每个 Object 的业务定义：用恒田业务语言说明，不只写技术字段。
3. 字段清单：区分必填、建议、后续扩展。
4. 关系清单：说明对象之间怎么连。
5. 小田解释模板：每个 Object 必须有面向小田的介绍解释。
6. 示例对象：至少用一个 SOP、一个岗位做完整样例。
7. 审核规则：哪些字段由谁确认，哪些状态可以发布。
8. 信息缺口清单：版本、生效日期、owner、表单、责任部门等缺口要列出来。

---

七、建议本周落地节奏

---

八、CIO小田建议的第一批样例

为了快速验证，建议不要先抽象讨论太久，直接拿样例跑一遍。

SOP 样例建议

1. 《晨会管理制度》

   • 价值：能验证公司级、部门级、班组级执行逻辑。
   • 可检查字段：适用范围、责任部门、会议内容、记录、改善闭环、风险点。

2. 《订单评审作业规范》

   • 价值：连接营业、面料、生产、交期、客户要求。
   • 可检查字段：客户要求、订单风险、评审节点、责任部门、输出表单。

3. 《采购作业流程》或《供应链管理作业流程》

   • 价值：连接供应商、物料、采购、验收、交期。
   • 可检查字段：采购申请、审批、供应商、到货、异常处理。

岗位样例建议

1. 班组长

   • 价值：一线交付和质量闭环关键岗位。

2. 面料计划员 / 采购员

   • 价值：连接订单交付与物料齐套。

3. 检验员 / QA

   • 价值：连接质量标准、检验记录、异常闭环。

---

九、风险提醒

---

十、最终建议

我建议 Lucas 和 Ben 的正式方案采用这个原则：

第一批 Object 先确认 8 类；第一阶段主攻 SOP、岗位、部门；每个 Object 不只定义字段，还必须定义“小田怎么向业务人员解释它”。

这样企业大脑不会停留在“资料入库”，而会开始具备三种能力：

1. 管理层能问清楚：这是什么、归谁管、风险在哪里。
2. 一线能用起来：怎么做、用什么表单、异常找谁。
3. 小田能持续学习：每个回答都有来源、状态、审核人和待补事项。

建议紫瑶审核时重点把关：对象边界、字段必填项、小田解释、来源可信度和敏感信息边界。审核通过后，再由 Lucas 和 Ben 在群里发布正式方案。