采购制度与流程草稿编写

用途

采购做法主要靠口传，新人不清楚权限和例外，修改制度时又容易把理想流程写成已执行规则。本任务把现行制度、真实做法和拟改要求分别整理，起草可审议的制度或 SOP，不自动发布或改变权限。

准备事实与改动范围

准备有效制度版本、授权矩阵、现有流程文字、表单字段及操作说明、岗位职责、常见例外和真实案例，明确本次要编写或局部修改的范围。 将材料分为“现行批准规则”“实际做法”“拟议改动”。口头做法不自动升格为制度，已有批准规则不被 AI 静默覆盖。法律或公司层级要求由法务和负责人提供有效依据。

先形成规则与缺口

仅整理本次范围：[范围]。
逐项列现行规则出处、实际做法、拟改意见、冲突与未说明。检查入口条件、岗位、审批权限、表单字段、完成证据和例外处理是否有依据。
没有金额门槛、审批人、期限或罚则时列待确认，不能借通用模板自行设定。
输出需负责人确定的问题和建议文档结构，等待确认。

负责人先解决权限和制度冲突。一个真实案例可以说明实际流程，但不能证明所有采购都适用；按品类、金额或紧急情形区分前提。

起草条文和执行步骤

依据确认意见起草采购制度/SOP草稿，包含目的、范围、职责、入口资料、执行节点、审核与记录、例外、版本维护。
每条写清谁、收到什么、做什么、产出什么、下一步交给谁、怎样检查完成，并注明依据。
现行规则和拟变更条文清楚标识；未决项留待确认，不写进强制执行条款。
按公司真实表单名称和字段写，不虚构系统入口或审批按钮。语言使用岗位能理解的中文，不编通用处罚。

例如教学情境：紧急采购需先提供需求说明和急需时间，谁有权批准仍以公司矩阵为准；若未给权限，条文只能留“审批岗位待确认”，不能设置经理可以事后补批。 多路径流程逐条写条件，例如服务采购与实物验收证据不同，不能硬用同一张收货单结束。

用真实案例走读

选择一笔常规和一项实际例外，由各岗位按草稿说明需要哪些资料、哪里等待、如何结束。WorkBuddy 根据走读文字查找缺节点和冲突，不能把桌面走读称为系统实测。 系统与制度不一致时列待解决清单，由负责人决定修改方向。跨岗位责任不以“相关部门处理”含糊带过，条件未明就保留问题。

审议与生效

输出草稿、拟改对照和待确认事项，法务、流程负责人及批准人审核后才发布。生效日期、培训通知和旧版替换由公司执行，AI 不代签或删除历史制度。 验收时核对入口、一个审批、一条例外和结束证据。完成标准是读者知道按哪些有效要求做事，未决条款明显，不把拟议方案当现行制度。