穿透式监管平台架构的设计，从表面上看是一个技术问题。数字化服务商通常会给出一张五层或六层技术架构图，从数据采集层、数据存储层、数据中台层、规则模型层、智能应用层，到展示层等，看上去非常清晰。

企业管理者看到这些图，往往觉得"很专业"，但真正开始推进建设时，大量困惑随之而来。

这不仅是技术上的问题，而是一个深层的问题：在穿透式监管实施之后，集团各部门，以及与各级子企业之间的管理关系，发生了什么变化，或应该发生什么变化？

例如，数据从哪来，规则由谁定，预警怎么发，责任谁来担？

数据中台是为数据贯通服务的，但数据贯通首先是一个管理及责任问题。谁有权看数据，谁对数据质量负责？至于“数据在各级之间如何流动”，这才是一个技术问题。

再如，规则引擎是为规则统一服务的，但规则统一首先是一个治理问题。规则骨架由谁制定，参数适配由谁完成？适配结果由谁审核，这才是一个技术问题。

这些问题的答案，不是一张看上去高大上，很炫的技术架构图，能够给出的。

要回答这些，必须回到穿透式监管实施之前，先理清在没有统一平台、依赖人工审计和线下报告的时代，集团对子企业的风险管控是如何运作的。

只有理解了"前穿透式监管时代"的管理架构，我们才能看清穿透式监管平台到底改变了什么，也才能说清楚平台架构的管理逻辑究竟是什么。

一、前穿透式监管时代：依赖人的事后管控

在穿透式监管实施之前，集团对子企业的风险管控，主要依赖三种手段。

1. 第一种是定期报告。子企业按月、按季、按年向集团报送财务报表、经营报告和风险报告等。这些报告经过层层汇总和加工，到达集团总部时往往已经滞后数周甚至数月，且数据在逐级上报过程中可能出现粉饰或遗漏。

传统监管模式依赖人工填报、层层汇总，数据滞后、错报漏报频发。子企业的管理者大概率知道，只要报告做得漂亮，问题就可以被掩盖。

2. 第二种是现场审计。集团审计部门或外部审计机构定期对子企业进行现场审计，通过抽样检查来发现问题。

但审计资源毕竟有限，通常三年才能覆盖所有子企业一次，每次审计只能抽查部分业务和部分时段。大量业务活动在两次审计之间处于"无监控"状态。

3. 第三种是专项检查。国资委巡视、集团专项治理、行业检查等不定期开展，针对特定领域进行深度排查。这种方式发现问题的概率较高，但覆盖面有限，往往"检查什么领域就发现什么问题，不检查的领域就看不到"。

这三种手段的共同特征是依赖人、依赖层级、依赖抽样、依赖事后追查。

在这种模式下，集团总部对子企业的真实经营状况始终处于"间接感知"的状态。看到的是加工后的报告，而非原始的业务数据。

子企业的管理者很清楚，审计不一定能发现全部问题，即便发现问题也是"过去时"，整改可以慢慢来。

这种管理架构下的风险管控，本质上是"人盯人"的模式——依赖个别人的责任心和专业能力来维持。

在这种管理架构或管理模式下，集团的风险管控往往呈现以下几个特点。一责任主体是模糊的。出了问题，集团说是子企业管理不善，子企业说是集团指导不到位。二信息是断裂的。集团看不到子企业的实时数据，子企业不知道集团的整体判断。三流程是滞后的。从风险发生到发现到报告到处置，周期漫长。四追责是软性的，查到了处理，查不到侥幸，缺乏持续的压力传导。

这种"看得见但穿不透"的困境，正是穿透式监管要解决的核心问题。

二、穿透式监管实施后：管理架构的重塑

国资委明确提出，穿透式监管要"打破层级壁垒、穿透股权表象、直抵业务实质"。这一表述揭示了穿透式监管的本质：它不是简单地"加强监管"，而是对传统监管模式的根本性重构。

穿透式监管平台的建立，看上去是用技术手段替代人工手段。用系统自动采集替代人工逐级上报，用规则模型全量扫描替代审计抽样检查，用实时预警替代事后追查。但在这些技术变革的背后，真正发生的，其实是管理架构的重塑。

这个重塑的核心，可概括为数据权、规则权、预警权、处置权的重新配置。

1、数据权：从子企业上移到集团

传统模式下，基本上由子企业掌握着数据的主动权。报什么、报多少、什么时候报，子企业说了算，集团只能看到"被允许看到的数据"。

穿透式监管平台，改变了这一格局。数据直接从子企业的业务系统汇聚到集团统一数据底座，不经过中间层级的加工和转发。

集团总部可以实时看到末级子企业的原始业务数据，包括资金流水、合同台账、采购记录。这种"数据直连"模式，终结了人工填报表的历史。

但数据权的上移，不是要架空中间管理层，而是用技术手段打破了信息垄断。

二级（集团）企业同样可以通过平台实时查看下属企业的数据，只是视角从"报上来什么"，变成了"下去看什么"。

这里还有一个关键问题需要厘清。集团拥有的是数据的"查看权"和"使用权"，而非"所有权"。

数据的所有权，仍然在产生数据的法人主体，但数据的查看权和使用权通过平台实现了跨层级贯通。

这一权责边界的设计，是平台架构管理逻辑的关键一环。它既保证了集团能够"看到"全级次的数据，又不会改变各法人主体对自身数据的法律所有权。

2、规则权：统一在集团

在传统模式下，每个子企业、每个业务领域各自制定自己的管控规则，集团层面的制度往往是原则性的，具体执行标准由各级自行把握。

穿透式监管平台要求规则模型统一设计。集团制定全集团统一的监控方向和规则逻辑骨架。

子企业在集团统一框架下进行本地化参数适配。在集团给定的参考区间内选择阈值、将派单职能锚定到本企业具体岗位。

这种"统一骨架、本地适配"的模式，既保证全集团监管标准的统一性和可比性，又尊重了子企业的业务差异和管理弹性。

3、预警权：形成"发现"与"管理"的平衡

在传统模式下，问题的发现依赖于人的主动报告或外部检查，发现什么、什么时候发现、发不报告，都有较大的弹性空间。

穿透式监管平台让预警信号自动生成、自动推送，消除人为的发现延迟和隐瞒可能。但平台不取代管理层的判断。系统发出的是"疑似"信号，需要人工核查确认。

预警信号的派发路径尊重管理层级。红色高风险预警由集团直接派发至风险发生企业并同步通知各级管理层，黄色中风险预警按管理关系逐级派发。

这种设计在"及时发现"和"分级管理"之间，找到了平衡。

4、处置权：落实到具体法人主体

在传统模式下，责任归属容易模糊。一个问题的发生，是经办人的错、是部门负责人的错、还是子企业负责人的错，这往往需要漫长的调查才能确定。

穿透式监管平台要求执行责任清单的岗位化锚定。

每条规则的处置动作，必须明确到具体岗位。数据质量责任，要明确到具体填报人和审核人。预警触发后，工单自动推送到锚定的岗位，核查整改有明确的时限要求，超期自动升级催办。

这种处置责任的清晰化，让穿透式监管的闭环不至于断裂在"不知道谁负责"的模糊地带。

三、穿透式监管平台的管理架构

基于以上分析，穿透式监管平台的管理架构可以分为四个层次。这四个层次，就笔者看来，不仅是技术上的分层，更是管理逻辑的厘清与递进。

1、数据汇集层：回答"数据从哪来、谁负责"

这一层解决的是数据贯通问题，是穿透式监管的技术根基。

没有全级次、全业务、全系统的数据汇聚，任何穿透都无从谈起。

在管理上，这一层需要明确几个关键问题。

1. 数据归属的权责边界。数据产生在子企业。每一笔业务数据在末级企业生成，这是数据产生的源头。数据标准由集团制定。主数据标准、编码规则、接口规范由集团统一，这是确保数据可比较、可汇总的前提。

数据质量由子企业负责。填报人对真实性负责，审核人对准确性负责，这是权责对等的管理机制。数据使用权归集团。集团有权实时查看全级次原始数据，这是穿透式监管得以实现的数据基础。

2. 数据汇集的路径。纵向路径是从末级子企业到三级子企业到二级子企业再到集团数据底座，数据"向上流动"但不经过中间层加工。

横向路径是从各业务系统（ERP、司库、采购、合同）到数据集成层再到数据中台，各系统数据"同层汇聚"。这两条路径的交叉，构成了数据汇集的基本网络。

3. 数据采集的方式。对于信息化基础较好的子企业，通过系统自动对接实现数据实时采集。对于信息化基础薄弱的末级企业，可采用离线填报或由上级企业代为采集的过渡方案，待条件成熟后再进行系统对接。过渡期一般不超过两年。

这一层在管理上的含义是：子企业不再拥有"报什么、不报什么"的选择权，集团拥有数据的"全量查看权"。

但数据质量的责任仍在子企业。这形成了一个"权责对等"的机制：集团有权看，子企业有责保真。正如15号文所要求的，要实现"数据自动采集"，就必须在管理上首先确立"数据必须被采集"的权力依据。

2、规则模型层：回答"风险怎么判、谁来定"

这一层解决的是规则统一问题，是穿透式监管的智能中枢。规则模型的质量，直接决定了穿透式监管的有效性。

1. 规则制定的分层治理。集团级刚性规则是红线规则，如严禁虚假贸易、严禁违规拆借，全集团统一执行，子企业无权调整。板块级适配规则考虑行业差异的参数可调，如不同板块的资金周转率阈值不同。

企业级个性化规则是子企业自查规则，在集团框架内自行配置。这种"三层分级"的设计，既保证了监管底线的刚性约束，又兼顾了业务差异的管理弹性。

2. 规则模型的设计方法。根据我们的规则模型方法论，一个完整的规则模型包含六个核心要素：风险场景——明确规则应用的业务边界；数据来源——明确判断所需的数据及来源系统；规则逻辑——将制度要求转化为"如果A则B"的表达式；预警阈值——设定分级预警的临界值；处置动作——明确预警触发后的自动操作和人工介入要求；迭代机制——建立持续优化的流程和触发条件。这六个要素构成规则模型从设计到运行到优化的完整生命周期。

3. 规则模型的分类。结构性规则基于财务报表逻辑，如资产负债率异常波动超过设定阈值。行为性规则基于业务流程异常，如审批流程绕过规定节点。关联性规则基于多源数据交叉验证，如供应商工商信息与内部人员关联关系。三类规则各有侧重，覆盖了从财务数据到业务流程到跨主体关联的完整风险谱系。

4. 规则迭代的双向反馈。集团负责规则骨架设计，子企业负责运行效果反馈。子企业定期提交《规则运行反馈报告》，包含命中率、准确率、误报案例。集团汇总分析后迭代规则模型。这种双向反馈机制让子企业从"被评价者"转变为"体系共建者"。

这一层在管理上的含义是：规则不是集团单方面强加的，而是"统一骨架、本地适配、双向迭代"的治理模式。子企业也不是规则的被动接受者，而是通过反馈机制参与体系的持续优化。

4、预警处置层：回答"问题怎么发现、谁来管"

这一层解决的是预警闭环问题，是穿透式监管的价值出口。发现不是目的，整改才是目的。系统预警信号必须进入处置闭环才能真正发挥作用。

1. 预警分级的管理映射。红色高风险预警由集团直接派发至风险发生企业，同步推送至所有上级企业——四级到三级到二级到集团，确保高风险信号第一时间到达责任主体，同时保障各级管理层及时掌握风险信息。

黄色中风险预警按管理关系逐级派发——集团到二级到三级到四级，保留了管理层的日常监督职能，避免集团总部越级指挥导致的管理层级混乱。蓝色低风险预警推送至业务部门参考，不强制限期。

2. 处置责任的岗位化锚定。每条规则的处置动作明确到具体岗位。红色预警要求24小时内响应、3个工作日内完成核查。黄色预警要求3至5个工作日内完成核查和情况说明。超期自动升级——超期1天升级至分管领导，超期3天升级至集团总经理。

3. 闭环机制的关键环节。核查由风险发生子企业负责，核查人员需确认预警信号的业务准确性、分析异常原因、判断是否构成违规、提出处置建议。整改由风险发生子企业负责，核查确认为违规的问题在规定时限内制定整改方案、明确整改措施和责任人和完成时限。验证由直接上级企业或内控部门负责，确认问题是否得到实质性解决，通过后在系统中销号，不通过的退回重新整改。

这一层在管理上的含义是：系统只负责"发现"和"推送"，不取代管理层的"判断"和"处置"。平台让问题无法被隐瞒，但解决问题的权力和责任仍在管理层级中。

这是一个"发现—核查—整改—验证—销号"的闭环，每个环节都有明确的责任主体和时限要求。

5、视图呈现层：回答"谁看到什么、怎么用"

这一层解决的是管理视图问题，是平台管理逻辑的最终呈现。视图呈现层不是某种界面设计的事，而是管理架构在技术平台上的映射。

1. 在视图上，很多企业提出要构建"一企一屏"，从管理逻辑上，这其实是在指法人主体责任。

每个法人主体在平台上有独立的监管视图，不是集团强加的"监控器"，而是该企业管理层履行监管职责的"驾驶舱"。

它呈现的是该法人主体全部业务领域的穿透式监管效果，不是部分经选择的典型问题。

这个屏的存在，让每个企业的管理层都无法推卸风险事实。对本企业的风险状况实时可见，问题无法隐瞒，处置必须及时。

集团总部的"一企一屏"展示全集团的汇总视图和各子企业的风险评级分布，并可下钻到任意子企业。

二级企业的"一企一屏"展示本企业及下属全部企业的汇总视图。三四级企业的"一企一屏"展示本企业的详细视图。

2. 另外，还有"一域一屏"的说法。其管理实质是指职能管控责任。集团各业务部门通过领域视图，看到全集团范围内该领域的全级次风险态势。

不是集团总部本级的数据，而是全集团全部子企业在该领域的数据集成和监控汇总。

如，采购领域"一域一屏"，展示全集团围标串标预警数量及分布、虚假贸易预警趋势、各子企业采购领域风险评级排名。

资金领域"一域一屏"展示全集团大额异常支付预警、资金归集率趋势、各子企业资金管理风险分布。

这个屏也让集团业务部门无法推卸一个事实。对下级企业该领域的监管盲区，在平台上一览无余。

3. 不同层级的差异化视图。集团董事长看到的是全集团汇总视图和各子企业风险评级分布，可以下钻到任意子企业、作出资源调配决策。二级集团总经理看到的是本企业及下属全部企业的汇总视图，可以向下穿透监管、向上接受监管。三级子企业负责人看到的是本企业的详细视图，可以查看预警、组织核查、落实整改。业务部门总监看到的是全集团该领域的跨企业视图，可以进行横向比较、识别共性问题和薄弱环节。

一企一屏和一域一屏，在平台上交叉形成监管矩阵。这个矩阵实现了管理上的"双向穿透"。纵向的法人穿透让信息从末级直达总部，横向的领域穿透让问题从孤立变为关联。

“一企一屏”和“一域一屏”，是管理架构在技术平台上的映射。

四、平台架构与管理架构的关系

如前述，现有软件厂商的架构图，通常包括数据中台层、规则模型层、智能应用层、驾驶舱层等。

这种架构的问题在于，它是从技术实现出发的，而非从管理需求出发的。

它默认了一个前提：穿透式监管就是一套技术系统。

但穿透式监管，首先是管理工具。它的用户不是技术人员，而是不同层级的管理者。

本文认为，真正符合管理逻辑的平台架构应该是这样的：管理架构决定数据架构，数据架构决定规则架构，规则架构决定视图架构，视图架构决定技术架构。

管理架构是"宪法"，技术架构是"执行细则"。先有管理架构的清晰定义，才有技术架构的正确方向。

具体来说，每一层管理逻辑，都对应着具体的技术实现。技术只是实现管理的手段。

集团拥有数据查看权，子企业承担数据质量责任这一管理决策，在技术上的实现是数据直连采集和数据质量监控模块。

集团制定规则骨架、子企业本地适配参数这一管理决策，在技术上的实现是规则引擎支持分层配置和备案审核流程。

红色预警直达集团、黄色预警逐级派发这一管理决策，这在技术上的实现是分级派单引擎和超期自动升级机制。

可以说，如果没有管理架构的清晰定义，技术架构就会失去方向。

这也是很多企业在推进穿透式监管平台建设时感到困惑的原因。

数据接口开发了但数据质量不行、规则模型部署了但预警不准确、驾驶舱上线了但管理者不看——根源都在于管理架构没有先行定义。

数据质量不行，是因为没有明确数据质量的责任主体和问责机制。预警不准确，是因为规则模型的阈值设定没有经过充分的业务论证和反馈迭代。管理者不看驾驶舱，是因为视图展示的内容与他们的管理职责不匹配。

总之，穿透式监管的内在逻辑是不取消管理层级、不替代基层决策，通过信息透明，让总部对风险看得见、看得清、管得住。

这一逻辑在平台架构中的映射，就是管理架构决定技术架构，技术架构服务管理架构的关系。

综上，我们提出穿透式监管平台的建设，不应从"选型软件"开始，而应从管理定义与管理架构开始。