制造业 vs 互联网：DCMM 差在哪

两类企业对照：一张表看清分叉点

先看全局。这张表的用法不是背下来，而是拿它去对照自己：哪一列的描述更像你，后面的准备重心就在哪一列。现实中不少企业是混合体——制造企业有自己的软件团队和工业互联网平台，互联网公司也做智能硬件、有自己的供应链。混合体更要在表里逐行判断，而不是整列照抄：哪块业务在造东西，就按制造那一列准备；哪块业务在运营线上用户，就按互联网那一列准备。

一、数据来源与采集：设备与工艺，还是埋点与日志

这是两边分叉的源头。3 级逐域落地那篇讲过一句话：八个能力域要拿得出"制度 + 执行 + 结果"三件套。而三件套的起点，都是"数据从哪来"。采集这一层没理清，后面的标准、质量、安全全是空中楼阁。

制造企业：三类来源，三种可信度

制造企业的数据来源可以切成三块，可信度和治理难度都不一样：

• 设备数据：PLC、SCADA、数控机床、机器人、注塑机、检测设备、能耗表。特点是频率高、字段窄、时间长，协议五花八门（OPC UA、Modbus、各家的私有协议），采集往往要经过边缘网关。这类数据"数量大但不一定有用"——采了几百个点位，真正参与质量判定和工艺优化的可能只有十几个。
• 业务单据数据：ERP 的订单、采购、库存、成本；MES 的工单、报工、投料、批次；PLM 的图纸、BOM、变更单；QMS 的检验与不合格品；WMS 的出入库。这类数据决定"账实能不能对上"，也决定追溯链能不能走通。
• 人工数据：班组长报工、质检员填检验记录、仓管点料、交接班本、纸质流转单、返工返修记录。这一块量大、口径随意、在评估现场容易出问题，因为它决定了"系统里的数"和"车间里的事实"是不是一回事。

制造企业具体要做的四件事：其一，做数据源清单——每个源写清是哪个系统或哪台设备、产生什么数据、由谁采集或录入、频率多少、落到哪张表、责任岗位是谁。其二，定时间基准——设备时钟、班次起止、工单开完工时间必须能对齐，否则后面做良率与节拍分析全是错位。其三，定补录规则——断网、设备故障、系统停机时的人工补录，谁补、多久内补、补录的数据要不要打标记，这条规则不写清，质量域永远说不清"这段空白是什么"。其四，采集先窄后宽——先做三到五个关键工序的关键参数，把链路跑通，比一上来全厂铺点位实用得多。

互联网公司：埋点是产品的一部分

互联网公司的数据几乎全部自动产生，但"自动"不等于"可靠"。主要来源是客户端与服务端埋点、网关与服务日志、业务库（订单、支付、账户）、第三方回传（渠道、投放、应用商店、客服工单）以及实验平台的分组记录。真正的治理难点不在采不采得到，而在埋点本身就是产品代码的一部分，它会随版本变：这个版本加了个参数，下个版本改了个上报时机，再下个版本把事件下线了，而看板还在按老逻辑跑。

互联网公司具体要做的四件事：其一，埋点规范——事件怎么命名、参数怎么定义、上报时机是什么、哪些字段必填，写成开发能直接照着做的东西，而不是一份 PPT。其二，埋点变更流程——新增、修改、下线都要走一次确认：谁提的、影响哪些下游报表和指标、通知了谁、什么时候生效。其三，采集质量的监控——上报量突降、某端某版本漏报、字段大面积为空，这些要能自动发现，而不是等业务方说"这个数不对"。其四，用户标识打通规则——设备标识、账号标识、匿名到登录的合并规则，写清楚之后，"一个用户算几个"才有答案。

二、数据架构：主数据与系统边界，还是数仓分层与实时链路

数据架构是八个能力域里容易"看起来有、其实没有"的一域。制造企业常拿一张系统集成拓扑图当架构，互联网公司常拿一张数仓分层图当架构，两者都只画了一半。

制造企业：架构的难点是异构与边界

制造企业的系统格局通常是这样的：ERP 管订单、采购、库存与成本；MES 管工单、报工、投料与追溯；PLM 管图纸、BOM 与变更；WMS 管库位与出入库；QMS 管检验与不合格品；SCADA 与设备层管实时参数。这些系统往往由不同厂商在不同年份交付，接口有的走标准 API，有的走中间表，有的靠文件定时导入，还有一部分靠人手工导 Excel。架构域真正要回答的是三件事：谁是源头、怎么同步、同步失败了谁管。

制造企业具体要做的：其一，明确源头系统——物料主数据在 ERP 还是 PLM，BOM 的准版本在 PLM 还是 MES，工单只在 MES 产生，检验结果只在 QMS 产生。源头一乱，下面所有报表都会打架。其二，主数据的新增与变更机制——谁申请、谁审批、多久同步一次、同步失败怎么补、历史编码怎么映射到新编码。其三，数据分布图按业务主线画，不要按系统画：物料 → BOM → 工单 → 批次 → 检验 → 入库 → 出货，这条线上每一段存在哪个系统、以什么键关联，画出来才有用。其四，把"手工导入"单列成一条链路——它往往是整条链上易断的一环，也常在访谈时被问住。其五，OT 与 IT 的分层——边缘采集、工厂侧汇聚、集团侧汇总各在哪一层做，决定了数据延迟和断网时的可用性。

互联网公司：架构的难点是分层与一致性

互联网公司的架构问题不在系统多，而在链路多：同一份业务事实，可能同时存在业务库、离线数仓、实时链路、指标平台和若干张自助分析表里。分层不清晰时，会出现"同一个 GMV 在五个地方五个数"的局面，而且每个人都认为自己那张表是对的。

互联网公司具体要做的：其一，分层职责写死——贴源层、明细层、汇总层、应用层各放什么，谁可以写、谁只能读，禁止跨层直连。其二，核心事实与维度建模——订单、支付、行为、用户、商品、渠道这几张核心表怎么建，粒度是什么，退化维度怎么处理。其三，实时与离线双链路的一致性监控——同一指标两条链路的差值要有日常监控，差值超过阈值要有人查，而不是等业务方发现。其四，数据服务的注册与版本——对外提供的数据接口要有清单、有责任人、有调用量与变更记录。其五，元数据与血缘自动采集——手工登记的元数据活不过三个月，这是普遍经验；现场随机点一张表能查出字段含义和上下游，才算这一域站住。

三、数据质量：对不上，还是来不及

质量是八个能力域里容易被误解的一域。很多企业以为质量就是"数据干净"，其实评估看的是问题能不能被稳定发现、发现后能不能闭环。而"什么问题算问题"，两边完全不是一回事。

制造企业：账实一致与批次可追溯

制造企业的质量问题，集中在四个地方：

• 一物多码与一码多物：同一个规格的物料因为不同时期、不同采购员、不同工厂各建了一次，库里躺着四个编码；反过来一个编码对应两种规格，采购和领料都会出错。
• BOM 版本错位：工单用的是旧版 BOM，实际领料按新版，成本核算和追溯两头都对不上。
• 账实不一致：系统库存与实物盘点差异长期挂着，没人核销，久而久之变成"系统里的数是参考"。
• 批次谱系断裂：原料批、在制批、成品批之间的关联只在部分工序记录，中间某道外协回来之后就对不上了。

制造企业具体要做的：其一，选三到五个关键数据项先做闭环——物料、BOM、工单、批次、库存这五项里挑影响业务的，不要一上来全量铺开。其二，规则要能说清"什么样算错"——物料编码重复、BOM 版本与工单不一致、报工数量与入库数量偏差超阈值、批次关联缺失、关键参数超出工艺窗口，每条规则配阈值和责任人。其三，问题台账必须有闭环四段——发现、分派、整改、验收，缺验收那一段，台账就只是清单。其四，做一次追溯演练并留记录：随机抽一个成品批号，正向查到原料批次与供应商，反向查到发货客户，限时完成并记录耗时与断点。这一次演练的价值，通常超过十页制度。

互联网公司：时效、完整与口径稳定

互联网公司的质量问题，集中在另外四个地方：时效（本该早上八点出的报表，十点才跑完）、完整（某端某版本的埋点漏报，导致这个渠道的数据整体偏低）、不重复（同一次点击被上报两次、同一订单被重复计入）、一致（口径改过之后，历史数据没有重算，趋势图上出现一个说不清的台阶）。再加上一类特殊问题：异常流量——刷单、爬虫、模拟器，会把所有下游指标一起带偏。

互联网公司具体要做的：其一，核心表的通用规则先落地——主键不重复、关键字段非空、枚举值在范围内、金额与订单表可对账，这四条覆盖了大部分低级错误。其二，时效要有约定和告警——每张核心表承诺什么时间就绪，延迟了通知谁，而不是靠人早上刷。其三，口径变更要登记影响面——改一次口径，谁通知、要不要重算历史、看板上的注释怎么标，这三件事决定了下游会不会集体返工。其四，异常流量识别规则——设备指纹、行为序列、频次阈值，规则本身也要有责任人和复核周期。其五，质量看板要有人看——本期检查多少、发现多少、闭环多少，能在例会上被讨论，才算质量工作进了机制。

四、数据标准：编码，还是口径

数据标准这一域，两类企业的产物长得完全不一样：制造企业的标准是一本本编码规则，互联网公司的标准是一张张指标定义。评估看的东西也不同——前者看"编码落到系统字段没有"，后者看"两个部门报出来的同一个指标是不是同一个数"。

制造企业：把标准做成编码

制造企业要立的标准，基本是这几类：物料编码（一物一码，含分类、规格、材质、单位、图号与版本）、BOM 结构标准（层级、替代料、版本生效与失效规则）、工序与工作中心编码、设备编码、供应商与客户编码、检验项目与缺陷代码、计量单位与换算规则。

制造企业具体要做的：其一，先做物料与供应商两个主数据——争议大、见效直观，也容易拿到业务支持。其二，编码规则要写清每位代表什么、由谁申请、谁审批、谁能改；只写"编码不重复"没有意义，写清申请路径才有约束力。其三，历史一物多码要清洗并保留映射——直接合并会让历史单据对不上，保留新旧映射表是务实做法。其四，标准必须落到系统字段：ERP 的物料主数据字段、MES 的工序编码、QMS 的缺陷代码，字段级对得上才算贯标；新系统上线前按标准做一次符合性检查，这条记录在评估时分量很重。

互联网公司：把标准做成口径

互联网公司要立的标准，是另一套东西：指标字典（定义、公式、取数范围、责任团队、版本）、维度体系（渠道、终端、版本、地域、人群）、事件命名规范、用户标识与去重规则、码表（行业、品类、内容标签）。

互联网公司具体要做的：其一，指标字典要可查——任何人搜一个指标名，能看到定义、公式、口径边界和责任人。字典放在共享盘里没人打开，等于没有。其二，同名不同义的指标要么合并要么改名——"活跃""留存""有效订单"这类词，在不同团队里含义经常不一样，这类冲突不解决，跨部门会议会一直吵口径。其三，维度值要收敛——渠道名从投放后台抄过来时五花八门，同一个渠道因为大小写、空格、后缀不同被拆成七八个值，这类脏数据会一路污染到报表。其四，标准变更要评估下游影响——改一个指标公式，哪些看板、哪些接口、哪些对外报表受影响，要有清单。

五、数据安全：图纸出门，还是数据被导出

数据安全在八个能力域里权重不低，但两类企业的保护对象几乎是两套东西。制造企业保护的是"东西"——图纸、配方、工艺参数；互联网公司保护的是"人"——用户的身份、行为、位置与支付信息。DSMM 那套数据安全视角在这里可以借力，但对象要换。

制造企业：分级要落到文件与字段两级

制造企业的敏感对象很具体：产品图纸与三维模型、工艺配方与关键参数、BOM 与成本、客户提供的技术文件、报价与投标文件、模具与加工程序。这些对象的出口也很具体：外协厂、模具厂、设备厂商的远程维护通道、驻场工程师、报废的设备与硬盘、以及车间里那台谁都能用的共用终端。

制造企业具体要做的：其一，分级分类落到两级——文件目录一级（哪个共享目录、哪个图纸库属于哪一级），系统字段一级（MES 里的工艺参数、ERP 里的成本字段属于哪一级）。只写"公开/内部/秘密"三档而不落到具体对象，这一域等于没做。其二，岗位—权限矩阵——研发、工艺、生产、品质、采购、财务各自能看什么、能改什么，由业务部门签字确认，IT 负责实现。其三，外发台账——对象、版本、用途、是否回收或销毁、经办人，这本台账同时证明"识别了风险"和"措施在执行"。其四，远程维护管住——申请、限时段、有人在场、留会话记录，四项缺一项就会被追问。其五，别忘了可用性——制造企业的数据安全不只是保密，还包括"这条产线不能停"，断网权限、备份与恢复、设备程序的可恢复性都属于这一域的边界。

互联网公司：分级要落到个人信息字段

互联网公司的敏感对象是个人信息与用户数据：手机号、身份证件、地址、位置轨迹、设备标识、支付与账单、通信与内容、以及能间接识别个人的组合字段。出口则集中在：数据导出、跨部门取数、共享给合作方与广告主、测试环境取生产数据、外包与实习生权限、以及离职后的账号残留。

互联网公司具体要做的：其一，个人信息清单——哪张表、哪个字段属于个人信息，敏感度如何，谁在用、用在什么场景。这份清单是安全域的地基，也是与数据资产目录对齐的关键。其二，权限四步留痕——申请、审批、开通、定期复核，敏感字段单独授权；只开通不复核，是常见的缺口。其三，导出与外发单独设卡——谁导出了什么、导给谁、用途是什么，要有审批和记录；这一项在现场被抽到的概率很高。其四，测试数据脱敏——不要把生产库直接搬到测试环境，脱敏规则要成文并有执行记录。其五，日志要能查——不是"开了日志"，而是能按人、按表、按时间段现场查一次，并且过去真的查过、有核查记录。

六、数据应用：现场改了什么，还是指标动了多少

数据应用是八个能力域里"看结果"的一域，也容易被做成"项目清单"。评估关心的不是做了多少个报表、上了多少个模型，而是数据有没有真的改变过一个决策或一个动作。

制造企业：价值要落回参数、批次和现场

制造企业的典型应用场景是：排程与产能优化、良率与缺陷分析、设备预测性维护、能耗与工艺窗口优化、质量追溯、供应商绩效评价、成本与存货分析。这些场景的共同点是价值回收慢、验证周期长、结论必须回到现场——分析说某段温度该降五度，得工艺确认、得试产、得看连续几批的良率才算数。

制造企业具体要做的：其一，场景清单按"问题—数据—动作—效果"四段写，效果必须有基线（改之前是多少）和对比（改之后是多少），没有基线的效果描述在访谈时撑不住。其二，挑三到五个能讲出成效的场景把过程记录补齐，比列二十个没人用的场景有说服力。其三，应用要嵌进既有流程——MES 看板、质量例会材料、月度经营分析，挂在这些地方才会有人看；单独建一个数据平台然后没人登录，是很常见的浪费。其四，追溯类应用要能现场演示——点一个批号，几秒钟出结果；演示不出来，前面所有追溯制度都会被怀疑。

互联网公司：价值要落回指标和实验

互联网公司的典型场景是：拉新与召回、留存与分层运营、推荐与搜索、风控与反作弊、投放效果评估、A/B 实验。共同点是闭环快、可实验、指标直接对应收入或留存——这也是为什么互联网公司的数据应用证据往往比制造企业"好看"，但同样容易空洞：报表很多，能说清"哪个决策用了它"的很少。

互联网公司具体要做的：其一，实验要有台账——假设是什么、怎么分流、看哪些指标、结论是什么、是否上线，五项齐全。实验台账是这一域分量很重的证据。其二，每个场景写清"用了哪些数据、影响哪个指标、结果如何"，而不是只写"上线了推荐系统"。其三，数据服务要有目录和调用记录——谁能申请、怎么申请、给了谁、调用了多少次，四问有答案才算开放共享落地。其四，别只看涨的那条线——体验指标、投诉率、退款率这些负向指标也要在看板上，只报好消息的分析在访谈时经不起追问。

七、评估现场容易被追问的点

评估的思路是一致的：顺着数据源—标准—质量—应用抽一条链，看它能不能一路走通，再回头核对治理、安全、架构、生存周期有没有托住。但抽到的东西，两类企业完全不同。

制造企业常被追的

• 产量、良率、直通率这三个数，生产、品质、财务各报一个，差异来自哪条口径？
• 给我一个成品批号，现在查它的原料批次与供应商，再反查发给了哪些客户。
• 同一个规格的物料为什么有四个编码，哪个是准的，历史单据怎么处理？
• 设备数据的时间戳是谁打的，和班次、工单怎么对齐，断网那一段补了没有？
• 这些报表是系统自动出的，还是有人每月手工导 Excel？谁做的、多久做一次？
• 物料主数据新增和变更谁审批，改了之后下游系统多久同步，失败过没有？
• MES 里的工单状态和车间纸质流转单不一致时，以哪个为准？
• 数据治理例会谁主持、多久一次、上次议了什么、决议跟到哪一步？

互联网公司常被追的

• 这个指标的口径改过几次，每次改了之后历史数据怎么处理，看板上有没有说明？
• 某端某版本的埋点漏报过没有，谁发现的，补数怎么补的？
• 离线与实时两条链路算出来差多少，差值监控在哪，超阈值谁看？
• 哪张表、哪些字段属于个人信息，谁在用，导出过没有，记录在哪？
• 测试环境的数据从哪来，脱敏规则是什么，谁执行？
• 上次实验的假设、分流、指标、结论在哪，后来上线了没有？
• 数仓分层的规范谁维护，新表建在错误的层有没有人拦？
• 现场点一张核心表，能查出字段含义、上游表和责任人吗？

两类企业共用的骨架

说清差异之后，也要把共同的部分讲明白——这部分不因行业而变，做了也不会因为行业不同而失效。DCMM 的八个能力域是同一套：数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准、数据生存周期；五个等级的名称也是同一套：1 级初始、2 级受管理、3 级稳健、4 级量化管理、5 级优化。流程同样一致：定级与范围 → 差距分析 → 补机制而非补文件 → 材料归集 → 文件评审 → 现场评估 → 结果与改进。整体流程与返工点，评估全流程那篇拆得更细；等级之间的差别，见 五级逐个拆。

下面这些做法，两类企业可以完全共用：

• 数据战略的写法：目标 → 分年动作 → 责任部门 → 资源 → 检查节点。每一条目标后面接一句"今年的具体动作是什么"，接不上的目标就删掉。
• 数据治理的骨架：分层治理组织（决策、协调、执行）、总纲加分域办法加操作细则的三层制度、认责到岗位并签字、例会必须有决议与跟踪、一两条数据指标进部门考核。
• 三处对得上：制度条款写的审批环节，系统里要有对应节点，台账里要有对应单据。这三处串起来，才叫证据链。
• 时间的连续性：例会、检查、整改、培训都要有跨月甚至跨季的记录。记录全挤在近两个月，机制的真实性就会被打问号。
• 责任的可追溯：每份记录能追到具体岗位和人，不写"相关部门"。被认责的人要知道自己被认责。
• 跨域一致性：安全域的分级分类要与数据资产目录对齐，标准域的指标口径要与质量域的规则对齐，治理域的认责清单要与安全域的权限复核人对得上。
• 访谈的准备：治理牵头人、各域对接人、能讲清投入的高层，这三类人必须真的在做事，顾问替不了。

不能共用的只有专业内核：制造企业的物料与 BOM、批次谱系、设备采集、工艺窗口、外协信息流；互联网公司的埋点体系、指标口径、实时链路、个人信息与实验机制。换句话说，骨架相同，填进去的对象、场景和证据不同。这也是为什么同一份制度模板在两类企业里都能用，但直接照抄内容一定出问题——文件里会留着别人家的系统名、岗位名和业务对象。

常见误区：两边各有一个"想当然"

制造企业：以为"上了 MES 就等于有数据管理"。 这是制造业项目里代价很大的一种误判。MES 解决的是"工单在系统里流转、报工有记录、批次能关联"，它不解决物料一物多码、不解决 BOM 版本错位、不解决产量口径三个部门三个数、不解决谁对哪类数据负责、不解决质量问题的闭环验收。系统是采集与流转的载体，标准、认责、质量闭环、治理机制都不在系统里。更现实的问题是：不少企业的 MES 只覆盖了部分车间，另外几个车间还在纸质流转，评估时一问"这条线为什么不在系统里"，如果答不出边界和计划，整个架构域的可信度都会掉。

互联网公司：以为"有数仓就等于有数据架构"。 数仓是架构的一部分，不是架构本身。评估要看的还包括：模型的分层设计与变更记录、数据分布与源头系统、集成与共享的接口台账、元数据的自动采集与血缘。很多团队数仓建得很漂亮，但模型改动没有评审记录、接口没有责任人、元数据靠手工维护且三个月没更新、数据服务调用量说不清。能跑数不等于有架构，这两件事在现场很容易被区分开：让你点一张表、说出它的上游和责任人，答不上来就是没有。

另外几个两侧都常见的误区：

• 拿模板套。 文件里写着别的行业才有的数据对象与系统名，一眼就能看出不是自己写的。体系可以被参考，但不能被复制。
• 只做三个域。 治理、安全、质量写得厚，战略、架构、应用、标准、生存周期整段空白。缺的不是深度，是覆盖面；八个域可以写得轻，不能没有交代。
• 把自评当结论。 自评全项"基本符合"，一条真差距都没有，正式评估一抽样就掉。自评的价值在于提前发现，不在于好看。
• 记录集中在评估前。 所有例会纪要、检查报告、整改单都落在近一两个月，时间跨度说明不了机制在持续运行。
• 把 DCMM 做成 IT 项目。 制造企业只让信息部门推，工艺、品质、生产不参与；互联网公司只让数据团队推，业务与法务不参与。访谈那一关，这两个缺口都很显眼。
• 拿证即收工。 评估结论有适用范围与时效，机制停了、记录断了，下次复评等于重来一遍。复评与维持的要求以发证机构当期规定为准。

行动清单：共用先做，分叉后做

下面这份清单按"先共用、再分叉"排列。用法是：带【共用】的先做，做完再按自己的行业做【制造】或【互联网】那一段。混合型企业两段都要做，按业务占比排先后即可。

• ⬜共用定范围：用一句话写下评估覆盖的业务、系统与组织单元，逐个确认"有数据、有人管、有记录"
• ⬜共用定人：一位能跨部门调人的牵头人，八个能力域各一名对接人，写下来并让人知道
• ⬜共用盘家底：数据源清单、系统清单、主要业务表清单，每项写清责任岗位与存放位置
• ⬜共用做差距：八个域逐条对照，产出二三十条具体差距，标清是制度、执行、记录还是平台缺口
• ⬜共用建骨架：总纲加分域办法加操作表单，认责到岗位并签字，例会开起来并留跟踪表
• ⬜共用跑一轮：让机制真的跑几个周期，把记录长出来；记录要跨月，不要集中补
• ⬜共用横着核：人名、系统名、岗位名、日期在八份材料里过一遍，别出现互相矛盾与日期倒挂
• ⬜制造主数据：物料与供应商先做，编码规则、审批路径、一物多码的清洗与映射表
• ⬜制造追溯演练：抽一个成品批号，正查原料与供应商、反查发货客户，限时完成并记录断点
• ⬜制造设备链路：时钟对齐、断网补录规则、关键工序先采，点位清单有责任人
• ⬜制造口径统一：产量、良率、直通率三个数先统一，把差异来源写成口径说明
• ⬜制造外发与远程：图纸台账、远程维护审批与陪同、报废介质清除，三项都要有记录
• ⬜互联网指标字典：核心指标有定义、公式、口径边界、责任团队、版本，且可被搜到
• ⬜互联网埋点治理：命名规范、变更评审、漏报监控、用户去重规则，四项成文
• ⬜互联网质量规则：核心表的主键不重复、非空、枚举、对账四类规则上线，问题台账有闭环
• ⬜互联网个人信息：字段清单、分级、权限四步留痕、导出审批、测试脱敏
• ⬜互联网实验与应用：实验台账齐全，数据服务有目录与调用量，负向指标也在看板上
• ⬜共用问机构：评估范围、等级口径、材料形式与排期，以评估机构当期评估规则为准

把两类企业放在一起看，结论其实很朴素：DCMM 检查的从来不是"你有没有一套数据管理文件"，而是"你知不知道自己有哪些数据、谁在动它、它准不准、它改变了什么"。互联网公司回答这四个问题时，答案大多在系统里；制造企业回答同样四个问题时，答案一半在系统里、一半在车间里。搞清楚自己属于哪一种，准备就不会从错误的清单开始，也不会在评估现场被一句"那具体是谁在做"问住。

▍不确定自己企业该按哪一类准备？留言备注"行业对照"，把主营业务、组织规模与主要系统发给我们，我们按行业给一份数据源清单框架与场景提问表。

普华智科 / CertFastLine 普华认证｜出口认证 & 检测 & 管理体系咨询 本文为合规科普参考，非法律或评估结论；等级划分、能力域要求、评估程序、机构受理范围与判定尺度以主管机构当期文件及承担评估的机构要求为准