如何有条不紊地举办新供应商接入日

针对已选定供应商的实操上线方案：筛选、站点、角色、异常处理台、就绪决策与后续跟进包。

供应商已经选定，协议已经达成，邀请也已发出。到了现场才发现，收到访问邮件的并不是对口的员工，财务部门不了解发票要求，银行信息还在等待核验，而所有复杂问题都挤在同一条队列里。如果团队没有提前确定流程路线和就绪标准，新供应商接入日很容易变成一间咨询服务中心。

我们在 Aventura 把这样的一天组织成一次工作上线，而不是又一场演示。共同环节保持简短。供应商的主要时间花在各个站点上：确认档案、文件、访问权限、接单渠道和开票流程。未解决的问题立即转入单独流程，并明确负责人和下一步行动。

这一形式从选定合作方之后开始。如果公司还在研究市场和未来要求，首先需要的是供应商预招标会议方案。如果任务范围更广，包括让市场了解公司、品类和专家，则适合采用供应商日。这里我们讨论的是下一阶段：已选定公司的实操上线。

什么结果才算供应商接入完成？

当供应商能够执行已商定的首个工作周期，或明确知道目前哪些条件阻碍启动时，接入才算完成。创建账户只能证明其中一个步骤。就绪状态包括经过验证的资料、必备文件、合适的角色、可用的订单接收渠道，以及清晰的账单和支持流程。

Oracle 官方材料将公司注册、填写资料、上传所需文件和创建用户访问权限区分开来。强制性资质要求和文件审核仍是独立环节。因此，“账户已创建”的绿色标记不应自动变成“供应商已获准”。

我们在邀请参与者之前就确定就绪的定义。它应回答以下问题：

1. 公司及其工作联系方式是否已确认？
2. 必填字段和文件是否已受理？
3. 用户能否登录系统并只看到所需功能？
4. 供应商是否清楚订单将由哪个法人实体、通过哪个渠道发来？
5. 财务部门是否了解账单要求及查询其状态的方式？
6. 每个未完成事项是否都指定了负责人和下一步行动？

部分检查可能在活动结束后继续进行。只要团队不用“已完成”一词加以掩饰，这就是正常结果。活动当天应给出可验证的状态，而不是承诺当场解决任何问题。

邀请前的准入筛选

在发出邀请之前，我们会将走标准流程的供应商与需要提前安排单独工作会议的情况区分开来。如果跳过筛选，集成项目、外国法人和普通服务供应商就会进入同一个流程。在第一个站点开放之前，排队现象就会出现。

我们请采购部门为每家公司填写一份简短的档案。其中不包含完整的供应商问卷。只需要填写会改变流程走向的特征。

活动前，供应商会收到文件清单、文件命名规则、系统要求和所需参与人员构成。商务联系人不能替代门户管理员或会计。如果关键员工不参与，档案会提前附带条件：部分站点无法通过。

付款前的交易对手核查仍是一项独立任务。可以方便地与我们关于预付款前承包商核查的材料进行对照。接入日的准入筛选并不取代尽职调查，也不重复法律审查。

供应商准备情况卡

统一登记册为每家公司保存一个已确认的状态版本。演示文稿、聊天和邮件可以辅助工作，但不能替代登记册。指挥部必须看到已通过哪个站点、阻塞点出现在哪里，以及谁负责下一步行动。

“已阅”和“处理中”这类表述几乎毫无用处。它们不会触发行动。最好写：“需要文件副本”“会计角色正在核查”“测试 PO 未送达”“将由流程负责人答复”。这样卡片就可以交给另一班次，无需口头转述。

卡片中的角色和决策最好按照活动责任矩阵的原则进行协调。对于涉及多个部门、且负责人同姓的情况，仅指定一个“总负责人”是不够的。每个站点都应有执行人、决策负责人和明确的升级路径。

想了解我们如何组织业务流、注册和现场团队工作，请参阅“Aventura”案例集。对于具体项目，站点构成和卡片会根据客户的系统和规则进行调整。

路线上需要哪些站点？

站点设在供应商执行操作并能获得可验证结果的地方。如果某个点位只是阅读幻灯片，那它属于整体介绍的一部分。工作站点接收输入数据、进行校验、更改卡片状态，并在必要时将案例转交升级处理。

Oracle 将供应商资料描述为公司、联系人、地址、分类、银行账户和类别等数据的集合。SAP 允许根据公司当前状态采用不同的接入方式。因此，对所有供应商采用同一条路线只在纸面上方便。在现场，它必须分叉。

在 PO 站点，团队确认对工作路径的理解。IBM 在供应商指南中单独讲解了订单的接收与执行、发票及其状态。对于发票，需要按照具体客户的规定核对法人实体、PO 编号和行项目、币种、银行信息及附件。不能将某家公司的内部检查清单当作通用规范照搬。

无需为了演示而创建虚构的财务文件。请使用测试环境、沙箱或约定的对照案例。如果没有此类环境，站点可以在不发送真实发票的情况下确认路线和数据。

无需排队的路线

我们以波次和分支的方式组织人流。供应商不必按同一顺序经过所有站点。准备情况卡片会显示所需节点，协调员则根据公司的状态和复杂程度，引导其走空闲路线。

我们采用以下筹备顺序：

1. 按注册状态、合作方式和复杂程度对供应商进行细分。
2. 为每个细分群体标注必经站点。
3. 将路线时长相近的供应商编成波次。
4. 错开需要安静环境、文件办理或技术诊断的站点。
5. 预留备用时段用于复核。
6. 在入口处安排协调员，并指定总指挥部负责人。
7. 在实时看板上显示各站点负载和未解决的阻塞问题。

活动参与者注册最好与 vendor portal 中的公司注册分开设计。前者负责到场、准入和波次分配，后者则属于供应商的工作档案。关于入场和备用方案的通用机制，我们已在活动参与者注册一文中详细说明。

这种形式适合采用综合性的商务活动组织：议程、场地、注册、导引、主持和指挥部都应按照同一张人流图协同运作。如果承包商只负责个别环节，建议通过活动承包商 SLA 明确响应时间和升级流程。

关于商务活动形式和人流管理的实务笔记，我们发布在Aventura 的 Telegram 频道。

异常处理台不会拖慢整体流程

独立处理点负责接收无法在标准时段内关闭的事项。它保存上下文、指定负责人，并向供应商返回明确的下一步。主流程在此期间继续运行。

提交到处理台的是带有具体症状的问题卡片：

处理台协调员不会替财务、法务或信息安全部门制定规则。他负责分派问题并跟踪状态。如果答复改变了整体流程，负责人会为所有受影响的供应商更新已确认的说明。

只有在供应商确认结果后，才能关闭异常。内部团队标记“工单已完成”并不能证明用户已登录、已看到订单或已发送修正后的文件。

每个环节由谁负责决策？

角色按决策划分，而不是按发言划分。采购负责关系与订单，IT 管理账户与角色，财务核对银行信息和发票，合规与法务负责强制性审查。供应商也要以团队形式到场，否则部分流程将没有负责人。

Oracle 建议围绕必要的权限构建访问控制，并将查看权与修改权分开。NIST 提出了更通用的原则：用户或设备属于组织这一事实本身并不产生信任。身份验证和授权在建立资源会话之前完成。对于上线当天而言，这意味着实名账户、按职能划分的角色以及单独的管理员更换流程。

共用“财务专用”登录名看似是快速解决方案，但会使操作审计和权限撤销变得复杂。在档案中最好直接注明主管理员、备用联系人和用户更换流程。

接入日流程

流程从通用规则版本出发，走向个人路线，最终到指挥部决策。我们不设定统一分钟数：时长取决于系统数量、检查组成和供应商复杂程度。在主时间表中，顺序和过渡条件更为重要。

1. 团队开启指挥部，检查各站点、名单和备用渠道的就绪情况。
2. 协调员接待供应商，确认参与并发放路线。
3. 在全体会议上，客户说明当天目标、边界、状态和升级流程。
4. 第一波人员前往工作站，其余人员按各自时间表开始。
5. 协调员更新卡片并重新引导参与者，无需返回总服务台。
6. 复杂情况连同背景信息转至例外服务台。
7. 指挥部多次核对负载、重复阻塞点和负责人决策。
8. 供应商获得最终状态和后续行动清单。
9. 流程关闭后，团队将登记册移交给后续负责人。

如果部分受众在线参与，需要为其配备单独的 moderator，而不是在会场角落架一台摄像机。材料提前发送，场内所有发言均通过麦克风，字幕和备用渠道在开始前检查。对于复杂的混合活动，可采用会议、论坛和研讨会组织的制作方案。

对于在公司内部组织商务活动的人，系统化资料Event-Skill会有所帮助。在本文中，我们只保留具体某一天的操作方案。

如何做出 go、conditional go 或 no-go 决定？

由流程负责人依据事先商定的标准做出决定。活动组织者不能代替采购、财务、合规或信息安全部门宣布供应商已获准通过。工作组负责收集证据，并将结果记录在卡片中。

Conditional go 不能用作不确定性的漂亮名称。它必须有边界。例如：资料和访问权限已就绪，但在核对银行账户信息之前暂不允许发送发票。或者供应商可以接收材料，但在分配所需角色之前看不到订单。

决定须附有依据、负责人和下次检查日期。如果具体采购规则要求单独审批，则卡片中的事件将成为该审批的输入，而不是替代正式程序。

混合模式与个人数据

混合形式需要两条平等的路径：线下和远程。线上参与者必须能够看到材料、听到现场提问、提出自己的问题，并获得相同的卡片状态。专门的 moderator 负责监控聊天、字幕、访问权限以及远程参与者在各站点之间的切换。

W3C 建议提前询问无障碍需求，在活动前将材料发送给参与者和支持专家，使用麦克风并检查字幕。自动功能若未在真实平台和真实声音环境中测试，就不能视为就绪。

活动日的注册表单只收集参与、访问和支持所需的数据。个人数据法要求将处理与特定的合法目的挂钩，不收集多余信息，且不保存可识别个人身份的数据超过必要期限。对于境外平台和跨境传输，需要单独进行最新的法律审查。本文不提供通用的法律指引。

活动后资料包

活动后的材料将一次性活动转化为清晰的延续。供应商获得确认的联系方式、状态及其应采取的行动。客户获得就绪登记表、例外队列以及应纳入下一轮次的变更清单。

资料包包括：

1. 每个供应商的最终就绪卡片。
2. go、conditional go 或 no-go 的决定及依据。
3. 未决例外登记表，含负责人和检查点。
4. 根据问题反馈更新的确认说明。
5. 支持联系方式及创建请求的规则。
6. 面向表单、角色和流程负责人的重复性阻碍因素清单。
7. 未完成事项的复检计划。
8. 面向团队的简要复盘：在下一波次前需要改变什么。

我们认为，事项在结果确认后即告关闭，而非在发送邮件后。自身指标可按卡片阶段统计：有多少公司完成注册、获得角色、确认 PO 并通过账户审核，有多少例外已开启和关闭。这些数据保持内部使用。不应将其冒充为行业标准。

资料来源

• Oracle：供应商注册流程
• SAP：供应商启用方法
• IBM：Buy@IBM 供应商资源
• IBM：全球采购开票说明
• Oracle：配置供应商门户用户
• NIST：SP 800-207 零信任架构
• 俄罗斯劳动部：联邦法律第 152-FZ 号《个人数据法》
• W3C WAI：打造无障碍活动
• W3C：远程会议的无障碍性