在穿透式监管的“三体系一系统”中，智能化监管系统是唯一一个“硬”模块。

它是运行在服务器上的代码，是自动执行的任务，是管理者每天看的界面。

这一点，与其他三模块，即组织体系、制度体系、监督追责体系完全不同。

这三个模块，属于管理方面，都是“软”的。

但笔者认为，这个“硬”的系统，其架构设计必须要从“软”的管理出发。

很多企业在建设穿透监管系统平台时，习惯于先看市场上有什么产品、什么技术先进，即进行所谓产品选型，然后让自己的管理去适应系统。

这种做法，其实是本末倒置，其系统运行效果必然有限。

正确的逻辑应当是：先搞清楚穿透式监管的管理架构，再基于管理架构，来设计系统架构。

穿透式监管系统架构，是穿透式管理架构的技术映射，不是独立于管理体系之外的技术创造物。

本文从穿透式监管的管理架构出发，阐述系统的功能定位、四层架构和各层功能设计要点，帮助建设者理解“为什么系统要这样设计”而不是“系统应该有哪些功能”。

01 管理架构是系统架构的前提

在讨论穿透监管系统架构前，先厘清两个概念：管理架构与管理体系。

管理体系，回答“穿透式监管是什么、怎么建、怎么运行”等管理问题，如组织怎么设、制度怎么定、模型怎么设计、数据怎么治理、预警怎么处置、评价怎么开展？

这是一套完整的管理制度、组织、流程、方法的集合。

管理架构，是管理体系中对“权力、职责、信息流向”的组织设计，它决定谁有权做什么、信息如何流动、决策如何做出。

管理架构不是管理体系的全部，而是管理体系中决定“谁来管、管什么、信息怎么走”的核心骨架。

这两者的关系是：管理架构是管理体系的“骨架”，管理体系是管理架构的“血肉”。

管理架构决定了信息的流向和权力的分配，管理体系在此基础上填充具体的制度、流程和方法。

在系统平台的建设语境下，穿透式监管管理架构是穿透式监管系统架构的直接输入。

穿透式监管系统架构本质上是将管理架构中规定的“谁来管、管什么、信息怎么走”转化为可运行的技术能力。

因此，管理架构回答“系统应该长什么样”的问题，这是穿透式监管系统架构的设计核心。

穿透式监管的管理架构，可概括为“三类主体、两条主线、一个闭环”。

1. 三类主体。监管者，指集团总部及各业务部门，负责制定规则、接收信息、下达指令、验证效果。被监管者，指各级子企业及其业务活动，是信息的源头和执行的主体。协同者，则指信息化部门（技术支撑）、审计纪检（独立监督）、人力资源（考核保障），为监管者和被监管者提供支撑和制衡。

2. 两条主线。数据流，包括从末级子企业向集团总部汇聚的原始业务数据，不经过中间层级的加工和修饰。管控流，包括从集团总部向各级子企业传导的规则要求（模型配置、制度规定）和预警指令（工单派发、整改跟踪）。

3. 一个闭环。指从规则制定、数据采集、模型运行、预警产生，再到派单处置、整改验收，评价改进等的完整回路。闭环的完整性决定了穿透式监管的有效性。任何一个环节的断裂，都会导致“看得见管不住”。

一旦管理架构厘清，系统架构就有了明确的设计依据。

系统的每一层设计，都对应着管理架构中的一个或几个要素。没有管理架构的清晰定义，系统架构就失去了方向。这也是为什么现在市场上一些系统产品，无法有效发挥其功能的根本原因。

02 穿透式监管系统的功能定位

穿透式监管系统架构的设计，源自本系统在整个企业数字化体系中的定位。这个定位，可从三个维度来理解。

（一）系监管系统，非业务系统

业务系统的核心功能是“运行业务”。如ERP处理采购订单，司库系统处理资金支付，合同系统处理合同审批等。

业务系统产生数据，是数据的“生产者”。

但穿透式监管系统的核心功能是“分析数据、识别风险、驱动行动”。

它从业务系统和DRP系统获取数据，运行规则模型，发现异常，推送预警，跟踪处置。它不产生业务数据，而是消费业务数据。

这个不同的定位，决定了穿透式监管系统与业务系统的根本区别。

业务系统的设计围绕“如何高效处理业务”，穿透式监管系统的设计围绕“如何精准发现风险”。

这两者的目标、逻辑、评价标准完全不同。穿透式监管系统的架构设计，不能照搬业务系统的经验。

（二）系管理执行系统，非决策支持系统

决策支持系统的核心功能是“辅助人做判断”，如提供数据看板、分析报表、趋势预测，帮助管理者做出更好的决策。它的输出是“信息”，决策权在人。

但穿透式监管系统的功能是“自动执行预设规则”。规则是预先定义的，系统按照规则自动判断、自动预警、自动派单、自动跟踪。它的输出是“行动”，系统在规则框架内独立运行。

这个定位，决定了穿透式监管系统的设计逻辑：规则先行。

没有规则，就没有判断；没有判断，就没有行动。系统的智能不是“自己学会判断”，而是“严格执行预设的判断逻辑”。

（三）系管理架构的技术映射

穿透式监管系统的架构，是管理架构在技术层面的精确复制。

管理架构中“三类主体、两条主线、一个闭环”的每一个要素，都必须在系统中找到对应的功能模块。

监管者的信息需求对应视图层，被监管者的数据来源对应数据层，管控流的传导对应规则层和执行层，闭环的完整流转对应各层之间的数据联动。

这个定位决定穿透式监管系统架构的评价标准：不是“功能多少”，而是“映射精度”。

管理架构中的每一个要素是否在系统中得到了精确的技术实现，这是判断系统架构合理性的唯一标准。

（四）与其他系统的关系

1. 业务系统产生数据。司库系统产生资金流水数据，采购系统产生招投标数据，合同系统产生合同数据。这些数据，是穿透式监管系统进行分析的原材料。

2. DRP系统汇聚数据。DRP系统是1号文提出的企业全域数据中枢，它从各业务系统采集数据，经过治理和标准化，形成统一的数据视图。

穿透式监管系统，理论上可从DRP系统获取经过治理的数据，而不用直接连接各业务系统。

3. 穿透式监管系统分析数据并驱动管理行动。它从DRP系统读取数据，运行规则模型，产生预警信号，派发工单，跟踪整改。它的输出是管理行动，如核查、整改、追责、评价。

这三类系统的关系，是清晰的。

业务系统是数据生产者，DRP是数据汇聚者和治理者，穿透式监管系统是数据消费者和行动驱动者。穿透式监管系统不替代DRP系统，也不替代业务系统，它是在DRP系统之上搭建的监管应用层。

03 管理视角下的穿透监管系统架构

本文认为，从管理视角出发，穿透式监管系统应分为四层：数据层、模型层、执行层、视图层。

在这四层架构中，每一层都对应一组管理问题。每一层的设计，都服务于管理架构的需要，具体如下：

数据层负责“让数据可获取、可信任”，模型层负责“让风险可判断”，执行层负责“让问题可处置”，视图层负责“让管理可操作”。

这四层，不是技术分层，而是管理逻辑的递进。

（一）数据层：回答“数据怎么来、怎么管、怎么用”

数据层解决的是数据贯通与数据质量的管理问题。在管理上，要明确哪些数据需要采集、数据质量谁负责、数据标准谁制定、数据如何被使用。

数据层，至少涵盖四个管理动作。1）源头识别，明确每一类数据来自哪个业务系统、哪个数据库、哪个字段，建立数据资产目录。2）采集贯通，通过接口、数据库直连、文件传输等方式，将数据从源头系统采集到数据平台，确保数据传输的稳定性和及时性。3）治理标准，统一主数据编码规则、数据格式规范、字段定义标准，让不同来源的数据可比较、可关联。4）质量保障，建立完整性、格式、逻辑、时效性四类校验规则，对缺失、异常、滞后的数据自动报警，明确数据质量责任主体。

数据层的管理逻辑是数据从业务系统产生，经过采集和治理，最终成为规则引擎可读取的结构化数据。

这一层的设计必须服务于“让规则引擎能够准确获取所需数据”这个目标。

数据层对应管理架构中“数据流”从末级到总部的技术实现，从技术上可包括数据来源、数据治理、数据中台等内容。

（二）模型层：回答“风险怎么判、谁来定”

模型层解决的是规则统一与自动判断的管理问题。管理上要明确：模型由谁制定、参数由谁适配、模型如何迭代。

模型层的核心是“六要素”的转化。风险场景——明确模型应用的业务背景和边界。规则逻辑——将制度要求转化为“如果A则B”的条件表达式。数据来源——明确模型判断所需的数据及其来源系统。预警阈值——设定触发预警的临界值及风险等级划分。处置动作——明确预警触发后的自动操作和人工介入要求。迭代机制——明确模型持续优化的触发条件和流程。

模型层还需要区分三类规则的管理逻辑。刚性规则，红线规则，全集团统一执行，子企业无权调整。适配规则，参数可调的规则，子企业在集团给定的参数范围内自行设定阈值。柔性规则，子企业自查规则，在集团框架内自行配置。三类规则的区分在系统层面的实现，就是模型配置权限的分层管理。

模型层的管理逻辑是：规则是预先定义的，系统按模型自动判断，不依赖人的经验和判断。

模型层的设计必须服务于“让制度中的量化标准转化为可执行判定逻辑”这个目标。模型层对应管理架构中“管控流”中“判断”环节的技术实现。

（三）执行层：回答“问题怎么发现、谁来管”

执行层解决的是预警闭环的管理问题。管理上要明确预警怎么分级、处置责任归谁、超时怎么办。

执行层的核心是“工单”。预警产生后自动生成工单，工单包含预警编号、触发规则、风险等级、异常数据摘要、核查要求、处置时限、责任岗位。工单推送至责任岗位后，责任人确认接收。核查、整改、验收、销号，每一个环节都在工单上完成。工单的状态变化，就是闭环的进度。

执行层还有三个关键设计。分级派单，红色高风险预警自动推送至集团管理层并同步推送各级上级企业；黄色中风险预警按管理关系逐级派发；蓝色低风险预警推送至业务部门参考。时限与升级，红色预警24小时内响应、3个工作日内完成核查；超期1天系统自动催办，超期3天升级至分管领导，超期5天升级至集团总经理。岗位锚定：每条规则的处置动作明确到具体岗位，工单自动推送到该岗位对应的责任人。

执行层的管理逻辑是系统只负责“发现”和“推送”，不取代管理层的“判断”和“处置”。

平台让问题无法被隐瞒，但解决问题的权力和责任仍在管理层级中。执行层对应管理架构中“管控流”中“行动”环节的技术实现。

（四）视图层：回答“谁看到什么、怎么用”

视图层解决的是管理意图实现的管理问题。管理上要明确：不同层级的管理者需要看到什么、看到之后能做什么。

视图层的设计需要区分三类用户。决策层看到全集团的风险全景和绩效全景，可以从总览下钻到任意子企业、作出资源调配和战略决策。管理层（业务部门负责人）看到本条线的全级次运行状况，可以识别共性问题和推动条线改进。执行层（子企业负责人及岗位人员）看到本企业的详细风险数据和经营数据，可以及时发现问题并组织整改。

视图层的核心功能是“穿透下钻”。从集团总览点击某个风险类型，进入专题视图；点击某个子企业节点，进入该企业的详细视图；点击某个预警信号，进入工单详情。

每一次点击，都向更细的颗粒度推进一层。“一企一屏”让每一个法人主体都能看到自己的全貌，“一域一屏”让每一个业务领域都能看到全集团的全貌。

视图层承载管理意图的关键在于“可操作”。

管理者在视图上发现问题后，应该能直接从视图层发起管理动作。

如，看到某个子企业风险排名异常上升，可以直接在视图层发起督办单；看到某条模型频繁触发，可以直接在视图层发起模型调整建议；看到某项整改超期，可以直接在视图层发起催办。

视图层不只是展示信息的仪表盘，而是承载管理意图的工作界面。视图层对应管理架构中“监管者”职责的技术映射。

04 各层功能的设计要点

（一）数据层的设计要点

数据层的设计要从管理需求出发，而不是从“有什么数据”出发。先问“规则模型需要什么数据”，再问“这些数据在哪里、质量怎么样”，最后问“怎么把这些数据采集上来”。顺序不能颠倒。

数据质量的源头责任必须在制度中明确：“谁产生、谁负责”。系统层面可以监控和报警，但数据质量的根本保障不在技术，在管理。

数据层的系统功能是辅助管理，不是替代管理。对于尚无法自动采集的数据，系统应提供标准化的填报模板和自动校验功能，确保填报数据的质量。

（二）模型层的设计要点

模型层的配置权限必须与组织职责一致。集团级刚性规则由集团统一配置、加密锁定，子企业无权查看规则细节更无权修改。子企业级适配规则在集团给定的参数范围内由子企业自行设定，设定结果自动备案到集团。

模型层的设计也要考虑模型的版本管理。模型修改后，不能立即替换旧版本，需要并行运行一段时间，对比新旧版本的命中率和准确率，确认优化后再完全切换。

模型层的异常处理设计至关重要。当数据不可获取时，系统应如何处理？是“跳过这条规则”还是“暂缓判断”。对于程序合规类模型，数据不可用时默认执行“暂缓放行，等待人工确认”的策略，而不是默认“通过”。

这套异常处理逻辑，本质上是管理上“无法验证合规即默认不合规”原则在系统层面的体现。

（三）执行层的设计要点

工单是执行层的核心数据对象。工单的设计必须包含完整的处置信息——谁负责、做什么、何时完成、向谁汇报。缺少任何一个字段，闭环都可能断裂。

执行层各环节的权限设计要与组织职责一致。核查环节的责任人就是规则模型中预设的责任岗位。验证环节的责任人必须是独立于核查和整改的第三方——通常是直接上级企业或内控合规部门。不能在系统层面允许“自己核查自己、自己整改自己验证”。

超时升级的规则必须预先配置在系统中，不能依赖人工判断“是否应该升级”。升级是自动的，不需要人工操作，也不需要人工批准。这是执行层区别于传统人工跟踪的本质特征。

（四）视图层的设计要点

视图的设计要从管理职责出发，而不是从数据维度出发。

每个视图都必须有明确的管理角色和该角色的核心管理动作。这个角色是谁、他需要看到什么、看到之后要做什么。没有明确管理角色的视图，就是“好看但没用”的展示。

下钻路径的设计，也要与管理决策路径一致。决策者发现问题后，需要按什么顺序获取更多信息来做出判断，这条路径就是下钻的设计依据。不是“能下钻就下钻”，而是“需要下钻才下钻”。

视图层的数据时效性，要与管理决策的时效需求匹配。决策层需要实时或准实时的数据来掌握风险态势，执行层需要当前周期的数据来完成处置工作。不是所有数据都需要实时刷新，不同视图有不同的时效要求。

05 确保系统服务于管理而非摆设

系统平台上线后，如何确保它不是“建了没人用”的技术摆设？有三个检验标准。

1. 管理需求是否被完整翻译成了系统功能？

检验方法是拿出管理架构图和管理体系文件，逐项检查。每个管理主体的职责在系统中是否有对应的功能模块支撑，每个管理流程的节点在系统中是否有对应的操作界面，每个管理制度的要求在系统中是否有对应的校验规则。

如果有管理需求在系统中找不到对应的功能，说明翻译不完整。

2. 管理流程是否在系统中形成了完整闭环？

检验方法是追踪一个完整的预警信号——从产生到派单到核查到整改到验收到销号——在系统中是否全部有记录、全部可追踪。

任何一个环节在系统中缺失或需要线下人工衔接，闭环就是断裂的。闭环断裂之处，就是管理失效之处。

3. 管理职责是否在系统中得到了精确映射？

检验方法是查看系统的权限配置和工单流向——是否每个岗位的权限与其管理职责一致，是否每张工单都推送到了正确的责任岗位。如果权限与职责不匹配，系统就会“该管的看不到、不该管的乱插手”；如果工单流向错误，预警信号就会“石沉大海”。

这三个标准全部满足，才能说系统是“服务于管理”，才是企业真正想要的系统架构。