在第一部分中，我们把从申请到付款的采购周期梳理为七个站点，并建议做一个简单的练习：取出最近十张已付款的供应商发票，逐张追溯到它的申请、审批、采购订单和收货记录。在这个练习中您寻找的第一份单据就是采购申请。如果有些发票根本没有申请，那我们就从这里开始，因为之后的每一份单据都需要有一个可以回溯的依据。

这一部分同时讲前两个站点：记录需求的申请，以及决定公司为此花钱的审批。它回答一个听起来像行政问题、实际上却是运营问题的问题：谁审批什么、额度到多少、审批人不在时由谁代为审批，以及需求等不及时该怎么办。

采购申请：之后一切都挂靠其上的单据

采购申请并不是在工作之外额外增加的文书工作。它是一项需求不再只是电话里的一句话、而成为一条带编号的记录的那一刻。没有它，采购订单就无所依据，工地上负责收货的人不知道该收什么，会计也不知道自己为什么付款。一份好的申请回答五个核心问题：

  • 谁需要？申请人的姓名和岗位，而不是转达消息的人的姓名：现场工程师、生产线主管、酒店的维修负责人。
  • 到底要什么？物品、规格、数量和单位。像“水暖材料”这样一行字算不上依据，因为事后没有人能拿它去核对到货。
  • 用于哪个项目、工地或物业？正是这个字段把成本归到应归的地方。一笔不属于任何项目的采购，就会变成一笔谁也追溯不了的一般费用。
  • 为什么？一句话就够：工程量清单中的一项、停机设备的一个零件、下个季节的耗材。这一句话能让审批人省去打电话询问。
  • 什么时候要？写实际需要的日期，而不是在每份申请上都写“紧急”。采购部门正是拿这个日期去对比供应商的交货期。

申请还需要一个预估金额，哪怕是粗略的，因为按金额审批就需要一个金额。如果申请人不清楚，采购部门会在申请提交审批之前补上。然后申请会得到一个编号，系统中之后的每一份单据都与它关联：审批、采购订单、收货记录和供应商发票。这与我们在工单与成本所挂靠的申请编号一文中阐述的逻辑相同：当每一份单据都关联到同一个编号时，您可以从链条上的任何一环出发，不必问任何人就能追溯到源头。

审批矩阵：只看金额是不够的

审批矩阵是一张回答一个问题的表格：谁可以对这份申请说“同意”？最简单的矩阵只建立在一个维度上，即金额：在某个额度以内由部门经理审批，超过则由财务经理审批，再往上由老板审批。金额是一个合理的维度，但采购类型会改变审批人所要回答的问题：

  • 库存物料。工地用的钢筋和水泥、生产线用的原材料、酒店用的清洁用品。这里的问题是：您是否真的需要这么多，以及在购买之前，它是否已经存放在另一个仓库或另一个工地。因此，让审批人在审批时看到该物品的库存会很有帮助。
  • 服务与分包商。电梯维保、分包商承做的保温工程、保洁合同。这里范围比价格更重要：到底要做什么，以及我们怎么知道它已经完成。所以这类申请需要针对两个不同问题的审批人：具备技术知识的人审批范围，矩阵为该金额指定的人审批支出。
  • 固定资产。设备、车辆、发电机、生产线上的机器。这是一项持续多年的承诺，并会带来运行和维护成本，因此让它提交到比仅凭金额所需更高的层级，是合理的。
  • 紧急采购。它们有自己的通道，下文会讲到，因为一个没有为紧急情况留出余地的矩阵，在第一次出现紧急情况时就会被人绕过去。

这些数字本身，也就是申请从一个层级转到下一个层级的额度，由老板设定，或者在设有董事会的公司由董事会设定，因为它们反映公司的规模、利润率以及老板希望亲自过目多少。不存在一个普遍正确、适用于所有公司的额度；从别家公司借来的额度，可能太紧，以致耽误工作，也可能太松，以致什么都管不住。

有两条规则适用于所有类型。第一，任何人不得审批自己的申请；审批人自己的申请要提交到上一级。第二，审批权属于岗位，而不属于个人，这样当一位工地经理调到另一个工地时，审批权会随新岗位一起转移，而不必等着有人想起来去修改。我们在权限：数据离开文件之后谁能看到什么一文中详细解释过这一原则；审批矩阵就是把同一原则应用到钱上。

审批人出差时由谁审批？正是在这里，一个从未考虑过人员缺席的矩阵会失灵，空缺就会被一条“你帮我批一下”的消息，或者两个人共用的一个密码填补。解决办法是在系统中预先设置授权委托：委托给谁、委托多久、在什么额度以内。被委托人的审批以其本人姓名显示，并标注为代表原审批人审批；委托到期自动终止；审批人回来后能看到自己不在期间批了哪些申请。如果一份申请超过老板设定的期限仍未得到处理，它会上报到下一个层级，而不是停在某个正在休假的人的收件箱里等待。

系统必须堵住的两条绕行之路

无论矩阵设计得多好，它周围总会留有两条绕行之路。走这两条路并不需要恶意；只要审批慢、工作又等不起就够了。所以系统要从两方面堵住它们：用一项控制来阻断绕行，再用足够快的审批让人根本不需要绕行。

  • 拆分申请。一份超过工地经理额度的申请，被拆成两三份低于额度的申请，在几天之内向同一供应商采购同一物品。每份申请单看都没问题；合在一起却超过了额度，而且从未送到有权审批的人手里。系统的做法是看合计，而不是看单份申请：同一项目中、在老板设定的期间内、涉及同一物品或同一供应商的申请会被加总，如果合计超过额度，就转到有权审批的层级。
  • 在 WhatsApp 上审批。经理在一个有几十条其他消息的群里，对一张报价单的照片回复了“OK”。这次批准是真实的，但批准的是什么？哪个版本的报价、多少数量、哪个项目？两个月后，这条消息已被成千上万条其他消息淹没，或者留在一部早已换掉的手机里。与此同时，对于需缴纳增值税的企业，依据它付款的发票，按照《增值税实施细则》第66条，必须自其所属纳税期结束起保存至少六年，而采购背后的那份批准会在哪里，却没有人知道。

解决办法并不意味着回到纸张和手写签名。《电子交易法》在其规定的条件下赋予电子交易、电子记录和电子签名约束力（第5条），并且在衡量电子交易的证据效力时，会考虑创建、存储或传输该记录所用方法的可靠程度，以及记录是否可能被篡改（第9条第(4)项）。WhatsApp 审批的问题不在于它是电子形式，而在于它与所批准的申请脱节。因此，审批要在系统内直接在申请上进行，带上审批人姓名、时间、金额和所批准的版本；如果申请之后在数量或金额上发生变化，就要重新审批。WhatsApp 仍然是提醒渠道：审批人收到一条带有申请链接的通知，不用打开笔记本电脑就能在手机上审批，这样审批慢就不再成为绕开它的理由。

紧急采购：用公开声明的通道代替绕行

客人入住前酒店客房漏水，生产线上的水泵停了，工地正在等材料来完成一次已经开始的混凝土浇筑。在这种时候，没有人会等走完一个完整的审批流程，也不应该等。一个无视这一现实的矩阵并不能阻止紧急采购；它只会把紧急采购推到系统之外，于是物品用现金或员工自掏腰包买下，两周后才在账上出现，既没有申请，也没有审批。

诚实的做法是让系统承认紧急情况确实存在，并给它一条条件清晰、公开声明的通道：

  • 谁可以启动。特定岗位，例如工地经理或值班的维修负责人，而不是每一位员工。
  • 什么算紧急。要有书面定义，而不是凭感觉：安全风险、运营停顿，或随拖延而扩大的损失。这与我们在从报修到结单：如何管理维修请求一文中为维修请求建议的逻辑相同。
  • 最少的信息。要什么、为什么紧急，可能的话附一张照片，在现场用手机录入，而不是填写一整张表单。
  • 支出上限。由老板设定紧急通道可采购的额度；超过该额度时，审批人要在采购之前，用手机直接在申请上审批。
  • 事后审批，设有期限。采购立即进行，其审批在老板设定的期限内补完。如果期限已过仍未审批，这份申请就会出现在老板亲自查看的清单上。

然后关注紧急申请占全部申请的比例。真正的紧急情况确实会发生，但当紧急在某个部门或工地变成了常规路径时，这并不是员工失职；而是一个信号，说明那里的计划需要重新审视，或者常规审批比工作所能承受的更慢。

Origami 的观点

当我们为一家公司搭建采购流程时，我们从它当前实际运行的矩阵出发，而不是制度手册上写的那一套：今天由谁审批，审批卡在哪里，大家在哪里绕过它以及为什么。一个团队所走的绕行之路，会先告诉我们设计需要在哪里调整，然后才告诉我们控制需要在哪里收紧。

然后，我们把矩阵变成一张由系统执行的表格：老板设定的额度、采购类型、授权委托与逐级上报，以及带期限的紧急通道；审批会推送到审批人的手机上，并记录在申请本身。我们的设计让老板在组织结构变化时可以自行修改额度，不需要程序员。这是我们所构建的定制系统的一部分，详见我们的服务。

本周练习：把您的矩阵画在一页纸上

在引入任何系统之前，先把您公司今天实际使用的矩阵写下来，哪怕它从未被写成文字。老板可以和运营经理、财务经理用一两次会议完成：

  • 把采购类型列为各列：库存物料、服务与分包商、固定资产和紧急采购。如果贵公司采购的东西不属于这四类中的任何一类，就再加一类。
  • 把金额层级放在各行，额度按您认为适合贵公司的标准设定，并在每个单元格中写上负责审批的岗位，而不是某个人的姓名。
  • 为每位审批人指定一名被委托人，在其不在时代为审批，并设定申请超过多长时间未处理就上报到下一层级。
  • 用书面形式定义紧急，并决定谁可以启动、支出上限是多少，以及补完审批的期限。
  • 回到第一部分练习中的那十张发票，逐张问自己：如果这个矩阵当时已经生效，会由谁来审批？那个人实际上审批了吗？

在最后这个问题上，纸面与现实之间的差距，正是系统需要弥合的。如果发现差距，先检查审批人当时是否只是无法联系上，因为如果是这样，解决办法是明确的授权委托，而不是更严格的控制。

下一部分

现在，需求有了一份带编号的申请，决策有了一份审批人明确的批准。下一部分将进入接下来的两个站点：供应商与报价，然后是采购订单。我们先从一份只录入一次、并在添加供应商时经过核查的供应商档案开始，接着在同一基准上比较报价，再把选中的报价转成一份写明价格、数量和条款并关联到其申请的采购订单，使它成为老板在任何发票到来之前就能看到的一项承诺。

资料来源