国资央企穿透式监管建设，经过组织领导体系的设计、制度体系的构建、监督追责体系的完善之后，最终要落到一个具体的载体上：智能化监管系统。
可以说，“三体系一系统”，前三个是“软”的。组织是人的安排，制度是纸上的规定，追责是流程的设计。只有最后一个“一系统”是“硬”的。
系统，是运行在服务器上的代码，每天自动执行的任务，管理者每天打开看的界面。
穿透式监管系统平台的建设虽是“最后一步”，但实践中往往出现这样的情况：组织体系有了、制度体系有了、追责体系也有了，系统也开发出来了，却用不起来：数据采集不上来、规则跑不通、预警没人看。
问题就出在对“系统平台”的定位上：它不是三个体系建完之后的一个“技术实现”，而是三个体系得以运转的“技术载体”。
01 穿透式监管系统与体系的区别与联系
先厘清一个基本问题：智能化监管系统与三个体系之间，是什么关系？
本文认为，其区别在于形态和作用方式。
组织体系是关于“人的安排”。谁负责什么、谁向谁报告。
制度体系是“纸上的规定”。什么能做、什么不能做、做到什么标准。
监督追责体系，则是“流程的设计”。预警怎么处置、违规怎么追责、效果怎么评价。
三体系共同的特点是：以“人”为中心。
组织靠人执行，制度靠人遵守，追责靠人推动。即使有了流程和规范，最终的执行者仍然是人。
而智能化监管系统，是“代码的运行”。
数据自动采集、模型自动分析、预警自动推送、工单自动派发、进度自动跟踪。
它以“机器”为中心。一旦配置完成，系统就会按照预设的规则自动运行，不需要人的持续干预。
这是本质区别。
体系与系统的联系，在于系统是体系的“技术载体”。
组织体系规定了谁有权限使用系统的什么功能。制度体系为系统提供了规则逻辑的来源和依据。监督追责体系定义了系统预警产生后的处置流程。
没有这三个体系的输入，系统就是一个空壳。不知道数据从哪里来、不知道规则怎么配置、不知道预警推送给谁。
因此，系统与体系的关系可以概括为一句话：体系定义“做什么”，系统实现“怎么做”。
体系提供需求，系统提供能力。体系回答“监管什么、谁来监管、依据什么监管”，系统回答“如何让监管自动运行”。
从体系到系统的必然性在于：穿透式监管的核心要求是“全量扫描”和“实时预警”。
人不可能每天扫描全集团所有子企业的全部业务数据，人不可能在深夜发现一笔异常支付并立即推送预警。
只有系统才能做到——7×24小时不间断运行，对全量数据进行持续扫描，在规则触发的瞬间推送预警。
体系提供了“监管什么”的答案，系统提供了“让监管持续运转”的能力。
没有系统，体系就只能停留在“有人管、有制度、有流程”的层面，无法实现真正的“穿透”。
对于智能化监管系统与司库系统、DRP系统的关系也需要厘清。
司库系统是企业资金管理的核心系统，负责银行账户管理、资金归集、支付结算、融资管理等资金业务的全流程处理，定位是“业务执行系统”。
DRP系统是1号文提出的企业全域数据中枢，整合会计核算、司库管理、全面预算、成本管理、税务管理、资产管理等模块，定位是“数据底座”。
智能化监管系统的定位是“监管执行系统”。
理想中的智能化穿透式监管，从DRP系统获取经过治理的数据，运行规则模型，识别风险信号，推送预警信息，跟踪处置进度。司库系统产生资金数据，DRP系统汇聚所有数据，监管系统用数据发现风险。
02 主流厂商的系统架构：共性特征提炼
对于电信、远光、中兴新云、用友、金蝶、久其、浪潮等七家穿透式监管主流厂商的穿透式监管平台（ 详细可参考：七家主流智能化穿透式监管平台厂商产品及实施思路汇总），虽在产品名称、技术路线、部署方式上各有差异，但在架构设计上呈现出高度的一致性。
这种一致性不是偶然的，而是由穿透式监管的业务逻辑决定的。
1. 共性一：数据底座+模型引擎+应用中心的“三层架构”
几乎所有厂商的平台都采用了“数据层—模型层—应用层”的三层架构。底层是数据底座，负责多源异构数据的采集、治理和存储。中层是模型引擎，负责规则模型的配置、运行和管理。上层是应用中心，负责预警推送、派单处置、整改跟踪、可视化展示等具体功能。
三层架构的逻辑清晰：数据是原料，模型是加工，应用是输出。
2. 共性二：驾驶舱+三中心的“应用架构”
在应用层，主流厂商普遍采用“一个驾驶舱+三个中心”的架构模式。驾驶舱是可视化展示层，面向决策者呈现全集团风险态势。
三个中心分别是数据中心（负责数据采集和治理）、监测中心（负责模型运行和预警生成）、调度中心（负责派单处置和整改跟踪）。
有些厂商称为“一平台五中心”，将功能进一步细分，但核心逻辑一致。
3. 共性三：知识库+引擎的“智能底座”
在模型层，主流厂商普遍采用“知识库+算法引擎”的架构。知识库沉淀监管制度、风险要素和历史案例，为规则设计提供知识基础。算法引擎包括策略引擎（规则配置和实时计算）、模型引擎（模型开发和迭代）、图计算引擎（关联关系挖掘）、AI引擎（大模型应用）。
四类引擎各有分工：策略引擎处理基于规则的实时预警，模型引擎处理基于机器学习的复杂风险识别，图计算引擎处理股权穿透和关联交易分析，AI引擎处理文本分析和智能问答。
4. 共性四：闭环管理的“流程架构”
所有厂商的平台都强调“闭环管理”。从风险发现到预警推送、从派单处置到整改跟踪、从效果验收到模型优化，形成完整的闭环。闭环管理的核心不是功能的有无，而是数据是否在各个环节之间自动流转。预警产生后自动生成工单，工单处置后自动反馈结果，结果反馈后自动更新模型。任何一个环节的“人工断点”都会破坏闭环的完整性。
03 管理视角与IT视角：为什么IT视角不够
主流厂商的架构设计解决的是“技术怎么做”的问题。数据怎么采集、模型怎么运行、预警怎么推送，这些都是技术实现。
但穿透式监管系统的核心问题不是“技术怎么做”，而是“管理怎么用”。
如果系统的架构设计，只考虑技术可行性，不考虑管理的实际需求，就会出现“系统做出来了，但管理者不用”的局面。
1. IT视角的设计思路是从数据出发。
有什么数据就做什么分析，有什么分析就做什么展示。这种思路的问题是：数据有、功能就有；数据没有、功能就没有。
而管理需求往往是超前的。管理体系要求监控某些风险，但相应的数据可能还不完备。数据不完备不是放弃监控的理由，而是启动数据治理的信号。
IT视角的另一个问题是功能模块按照技术逻辑划分，而不是按照管理流程划分。数据采集是一个模块、规则引擎是一个模块、预警推送是一个模块。技术上是合理的，但管理者使用时不关心“这是哪个模块”，只关心“我能不能看到我需要看的东西”。
2. 管理视角的设计思路是从管理需求出发。
管理体系要求监控什么，系统就必须提供什么功能。
数据不完备就启动数据治理补数据，规则不清晰就组织业务部门梳理规则。系统始终服务于管理，而不是让管理迁就于系统。
管理视角的核心问题是：谁需要看到什么？看到之后能做什么？做了之后效果如何验证？
这三个问题回答清楚了，监管系统的架构就有了方向。
IT视角关心“系统能做什么”，管理视角关心“管理者需要什么”。系统能做的很多，但管理者需要的才是有效的。
穿透式监管系统的价值，不在于功能的数量，而在于功能的精准匹配。
04 管理视角下的系统架构：五层结构
本文认为，从管理视角出发，穿透式监管系统应分为五层：数据来源层、数据层、规则层、执行层、视图层。
数据来源层是系统平台的前置条件，存在于系统平台之外但必须存在，后四层构成系统平台本身的功能层次。
（一）数据来源层：系统运行的前提条件
数据来源层不在系统平台内部，但它是系统运行的前提条件。没有数据来源，系统就是无源之水。
数据来源层包括各业务系统——ERP、司库、采购平台、合同管理系统、投资管理系统、人力资源管理系统等，以及外部数据源——工商数据、司法数据、舆情数据等。
这些系统产生的数据，是穿透式监管系统进行分析的原材料。
数据来源层的管理要求是：各业务系统必须按照统一的数据标准和接口规范开放数据。
这不是系统平台能解决的问题，而是数据治理的组织工作。数据治理先行，是系统能够运行的前提。
（二）数据层：回答“数据从哪来、谁负责”
数据层解决的是数据贯通问题，是系统平台的第一层功能。管理上要明确：数据标准由谁制定（集团信息化部门）、数据质量由谁负责（数据产生单位）、数据使用权归谁（集团拥有查看权）。
数据层的技术实现是数据采集和治理模块，它的管理逻辑是：子企业不再拥有“报什么、不报什么”的选择权，集团拥有数据的“全量查看权”。
在数据层的设计中，需要区分两种数据来源。
一种是业务系统自动采集的数据，如司库系统的资金流水、采购系统的招投标记录。另一种是尚无法自动采集的数据，需要通过填报方式补充。
对于后者，系统应提供标准化的填报模板和自动校验功能，确保填报数据的质量。
数据层不是等待数据完备之后再启动，而是在数据不完备的情况下就开始建设，通过系统运行倒逼数据治理。
数据层还需要实现数据血缘的可追溯。从驾驶舱的某个指标可以一路追溯到末级子企业的原始业务单据。这是数据层“可追溯”管理要求的技术实现。
（三）规则层：回答“风险怎么判、谁来定”
规则层解决的是规则及模型的问题，是系统平台的第二层功能。管理上要明确：规则骨架由谁制定（集团统一设计）、参数适配由谁完成（子企业在集团框架内适配）、规则迭代由谁驱动（运行数据反馈）。
规则层的技术实现是规则引擎和模型管理模块，但它的管理逻辑是“统一骨架、本地适配、双向迭代”。
规则层的设计需要区分三类规则。刚性规则是红线规则，全集团统一执行，子企业无权调整。适配规则是参数可调的规则，子企业在集团给定的参数范围内自行设定阈值。柔性规则是子企业自查规则，在集团框架内自行配置。
三类规则的区分，体现“管得住”和“放得活”的平衡。
制度体系中的量化标准在规则层转化为可执行的判定逻辑。如，制度规定“大额支付须经总经理审批”，规则层将其转化为“单笔支付超过100万元且审批层级低于总经理的，自动触发预警”。
规则层的另一个关键设计是规则的全生命周期管理。从需求提出、设计、评审、开发、测试、部署到运行、迭代，每一个环节都需要有明确的流程和责任主体。
规则不是一次性设计完就固化，而是需要在运行中根据命中率和准确率数据持续优化。
（四）执行层：回答“问题怎么发现、谁来管”
执行层解决的是预警闭环问题，是系统平台的第三层功能。管理上要明确：预警怎么分级（红色直通集团、黄色逐级派发、蓝色参考）、处置责任归谁（岗位化锚定）、超时怎么办（自动升级催办）。
执行层的技术实现是预警推送、派单管理、整改跟踪模块，但它的管理逻辑是：系统只负责“发现”和“推送”，不取代管理层的“判断”和“处置”。
平台让问题无法被隐瞒，但解决问题的权力和责任仍在管理层级中。执行层处理的是“事的闭环”：预警怎么处置、整改怎么跟踪、销号怎么完成。
执行层的核心是“工单”。预警产生后自动生成工单，工单包含预警编号、触发规则、风险等级、异常数据摘要、核查要求、处置时限、责任岗位。
工单推送至责任岗位后，责任人需要在系统中确认接收。核查、整改、验收、销号，每一个环节都在工单上完成。工单的状态变化，就是闭环的进度。
执行层的设计还需要考虑“升级机制”。超时未处置的预警，系统自动升级催办——超期1天升级至分管领导，超期3天升级至集团总经理。
升级机制是自动的，不需要人工判断和操作。这种设计确保了任何一个预警都不会“石沉大海”。
制度体系中的处置时限规定在系统平台中固化为超时规则，将制度要求转化为自动执行的技术逻辑。如，制度说“红色预警24小时内响应”，系统就在24小时后自动启动催办。
（五）视图层：承载管理意图的工作界面
视图层解决的是管理意图的实现问题，是系统平台的第四层功能，也是距离管理者最近的一层。
视图层不只是“给领导看的仪表盘”，而是承载管理意图的工作界面。
管理者在视图层发现问题后，可以直接在视图层发起管理动作——派单、督办、调整权限、作出决策。
视图层实现“看+做”的完整闭环。
视图层处理的是“人的决策”。管理者怎么看、怎么管、怎么推动问题解决。它与执行层的区别在于：执行层是系统自动运行的“后台”，处理的是“事的闭环”；视图层是人机交互的“前台”，处理的是“人的决策”。
执行层不需要人的干预就能运行，视图层是人与系统交互的界面。
视图层的设计需要区分三类用户角色。
决策层（集团主要领导）需要看到全集团的风险全景和绩效全景，以便作出战略决策和资源调配。
管理层（业务部门负责人）需要看到本条线的全级次运行状况，以便识别共性问题和推动改进。
执行层（子企业负责人及岗位人员）需要看到本企业的详细风险数据和经营数据，以便及时发现问题并组织整改。
不同角色的视图应当是不同的。集团董事长看到的不应该和三级子企业负责人看到的一样。视图的差异不是权限控制的结果，而是管理职责的映射。
视图层的核心功能是“穿透下钻”。
从集团总览点击某个风险类型，进入专题视图；点击某个子企业节点，进入该企业的详细视图；点击某个预警信号，进入工单详情。每一次点击，都向更细的颗粒度推进一层。
“一企一屏”让每一个法人主体都能看到自己的全貌，“一域一屏”让每一个业务领域都能看到全集团的全貌，两者的交叉构成完整的监管矩阵。
视图层承载管理意图的关键在于“可操作”。
管理者在视图上发现问题后，应该能直接从视图层发起管理动作。看到某个子企业风险排名异常上升，可以直接在视图层发起督办单；看到某条规则频繁触发，可以直接在视图层发起规则调整建议；看到某项整改超期，可以直接在视图层发起催办。
视图层不只是展示信息的仪表盘，而是承载管理意图的工作界面。组织体系中“谁有权限做什么”的规定，在视图层映射为不同角色可见的功能按钮和可执行的操作。
管理体系向系统平台的翻译，至此，才真正完整。
小结一下：穿透式监管的智能化监管系统，是三个体系得以运转的技术载体。管理视角下的系统架构，核心是“管理决定平台”。系统不是独立于管理体系之外的技术造物，而是管理体系在数字世界的精确映射。
数据来源层、数据层、规则层、执行层、视图层五个层次，分别对应管理体系中的不同要素。穿透式监管系统平台的最终目标，不是“上线一套软件”，而是让管理体系获得自动执行、持续运转、自我优化的能力。
作者介绍：陶光辉，律师、高级经济师、法学院客座教授，中国管理科学学会理事、中国人工智能学会会员等。擅长领域：穿透式监管、风险管控数智化升级，治理风险与合规（GRC）、法治央企建设等。
