Is S2P a process question or a technology question?

Neither on its own. S2P is a chain of ownership transfers that process describes and technology enforces. A process redesign that the systems do not enforce changes nothing. A system rollout without settled ownership freezes whatever ambiguity exists at configuration time.

We already have a suite. Do we need to replace it?

Usually not. Most S2P pain traces to seams the suite was never configured to hold, not to the suite itself. Establish which seam is leaking before assuming the tool is the constraint.

Where does the biggest leakage sit?

Rarely at payment, which is where it is measured. Most leakage originates at the first two seams, when the requirement reaches procurement already specified and already timed. Everything downstream inherits that loss.

Our adoption numbers are low. Is that a training problem?

Almost never. Adoption is a routing question. People use the path that is fastest to a working outcome. If the compliant path is slower, training makes people aware of a route they will still not take.

Where does this start?

With one senior read of which seam is actually leaking and whether the position is redesign, stabilise or scale.

S2P 转型咨询 | KULIC Advisory

症状

领导者通常看到的情况

审批跑到了系统之外
供应商、订单、发票和合同方面的变通做法不断重现
仪表盘显示了摩擦，却没有指定责任归属

诊断

我诊断什么

流程分类体系的缺口
决策与升级路径
业务、采购和财务之间的采用障碍

成果

您将带走什么

对 S2P 系统断点的清晰解读，以及重新设计、稳定或规模化的路径。

定义

当您不再去画它时，Source-to-Pay 究竟是什么

Source-to-Pay 通常被画成一条链：识别需求、寻源、签约、下单、收货、开票、付款。这张图是准确的，却几乎没有用。它描述了顺序，却掩盖了决定这个顺序能否运转的东西。

S2P 是一条责任移交的链条。每一步都有东西易手。需求变成规格。规格变成谈判。谈判变成合同。合同变成目录条目、采购订单、收货、发票、付款。流程很少在某一步内部失败。它失败在两步之间的接缝处：前一位责任人已经放手，下一位却还没有接住。

结构性错误

五条工作流，一个系统

大多数 S2P 项目被组织成并行的工作流，各有各的负责人、各有各的计划、各有各的指导机制。每一条都管得很称职。项目依然停滞，因为这五条并不是五件事。

流程

由不会去运行它的人设计，依据的又是财务和业务部门理解不一的分类体系。

数据

供应商、物料和合同主数据：流程假定它们是干净的，系统却知道它们不是。

责任归属

写在幻灯片上，却在品类、业务单元和共享服务交汇的每一道接缝处受到争夺。

技术

按照一个仍在变动的设计来配置，随后又被当成设计不能再改的理由。

采用

拿到预算最少、却决定成败的工作流。它不是培训。它是系统是否就是最省事的路径。

分开运行时，每条工作流都对照自己的计划做优化，并悄悄破坏其他几条。作为一个执行系统来运行时，五者会在早期相互制约，这令人不舒服，却便宜得多。

示意图

S2P 真正断裂的七道接缝

每一道接缝都是责任移交的点。每一道也都是变通做法诞生的地方。

01从需求到规格业务部门知道想要的结果。采购拿到的是一个产品名称。寻源的杠杆已经没有了。

02从规格到寻源时机决定杠杆。移交晚了，谈判就变成了确认。

03从寻源到合同当法务审核没有决策日期时，谈下来的和签下来的就会走样。

04从合同到目录几乎无人负责的接缝。从未进入采购渠道的条款，就是从未生效的条款。

05从订单到收货收货被当作行政事务。它却是让三方匹配成为可能的那项控制。

06从发票到匹配例外数量不是应付账款的问题。它是上游每一个不清晰决策的总和。

07从付款到洞察支出数据回到品类负责人手中时已经太晚，改变不了下一次寻源决策。

按顺序读这些接缝，模式就显现出来：流失并不是从付款开始的。它始于第一次移交，之后的每一道接缝都继承了它。

具体来看

症状在您看的地方。病因在上游。

每一个 S2P 症状都有一个显而易见的责任人和一个真正的责任人。两者很少是同一个。选择一个症状，看看病因通常在哪里。

支出不断发生在约定渠道之外。

被归咎于: 纪律。通常的答案是再发一次政策提醒。
通常的原因: 合规路径比不合规路径更慢。
看这里: 接缝 04。谈下来的条款是否曾进入一个可以下单的渠道。
检验: 把合规路径从头到尾计一次时。如果它输了，政策也赢不了。

这不是对您的环境的诊断。这是一次诊断所呈现的形态：症状、被认定的责任人、真正的接缝，以及一项能下定论的检验。

次序

重新设计、稳定或规模化。不要三者同时进行。

大多数 S2P 项目同时尝试这三种定位，然后纳闷为什么什么都完不成。三者需要不同的治理、不同的节奏和不同的“完成”定义。

重新设计当模型本身是错的最慢。在决策权确定之前不要开始。

稳定当模型是对的却没有守住见效最快的缓解。不解决任何结构性问题。

规模化当一个实体已经运转良好只有在第一个实体无需靠人硬撑也能守住之后才安全。

选择定位本身就是决策。把不稳定的模型规模化，只会成倍放大不稳定；在现有模型着火的时候重新设计，则两头都落空。

系统的现实

套件会强制执行一种模型。问题是谁的模型。

S2P 套件不是中立的。每一个审批阈值、每一个必填字段和每一条工作流分支都是一项运营模式决策，在配置时做出一次，之后每天被执行成千上万次。

当运营模式在配置时尚未确定，就会由实施伙伴来确定。这不是出于恶意，而是因为项目需要一个答案才能推进。被固化下来的，是一个由没有相应授权的人做出的合理猜测。日后推翻它的代价，高于现在就把它定下来。

自动化之前

自动化，以及它对一道断裂接缝的作用

用在干净的接缝上，自动化消除的是工作。用在不清晰的接缝上，它消除的是那个默默替模糊补位的人。例外数量不会下降。它只是换了形态，变得更难追踪。

就绪度问题范围很窄，也可以回答。对于您想要自动化的那个决策：责任人是否已指定，阈值是否已定义，决策所依赖的数据在决策的那一刻是否可信。三个“是”才值得去做自动化。少于此数，您就是在放大模糊，比以前更快，也更不透明。

领导者最先问的问题

在下一个 S2P 项目之前

S2P 是流程问题还是技术问题？

单独看都不是。S2P 是一条责任移交的链条，由流程来描述，由技术来强制执行。系统不去强制执行的流程重塑什么都改变不了。在责任归属未定的情况下上线系统，会把配置时存在的模糊原样固化。

我们已经有一套套件了。需要更换吗？

通常不需要。大多数 S2P 的痛点可以追溯到套件从未被配置去守住的接缝，而不是套件本身。在认定工具是瓶颈之前，先确定是哪道接缝在流失。更换是发现“问题其实出在模型上”的最昂贵方式。

最大的流失在哪里？

很少在付款环节，尽管它是在那里被衡量的。大部分流失源于最初两道接缝：需求到达采购时已经定好了规格、定好了时间。下游的一切都继承了这一损失，然后又为它背锅。

我们的采用数据很低。这是培训问题吗？

几乎从来不是。采用是一个路径问题。人们会走最快能办成事的路径。如果合规路径更慢，培训只是让人们知道一条他们仍然不会走的路。在设计干预措施之前，先把两条路径从头到尾各测一遍。

从哪里开始？

从一次资深解读开始：究竟是哪道接缝在流失，以及定位应当是重新设计、稳定还是规模化。这个答案会改变未来十二个月应当花多少钱。

证据

证据先于方法论。

先用证据降低采购风险，然后从一次资深诊断开始，再考虑增加项目、工具、工作坊或咨询层级。

打开证据

S2P 转型咨询：当 Source-to-Pay 需要一个受治理的执行系统时。