尧图网站建设 
简介这份《集团IT蓝图总体规划方案.pptx》面向大型集团信息化负责人、企业架构师与咨询顾问解决从战略愿景到IT落地路径缺乏系统方法论的问题。方案遵循德勤成熟方法论覆盖业务模式分析、IT信息化蓝图设计、业务与信息化协同等关键环节并串联智慧城市、人工智能、物联网等热点技术的应用场景。内容重点拆解业务架构、应用架构、数据架构、基础架构、治理架构与信息安全六大模块逐层展开应用能力组合、集成架构、部署架构、功能描述与信息交互关系同时统一客户、供应商与基础数据管理建立集成平台以简化系统间交互。压缩包为单一pptx文件约8.35MB便于直接演示或作为内部汇报模板。已有124人学习下载适合需要撰写集团级信息化规划、进行架构分层设计与实施预算编排的读者参考借鉴。1. 一份集团 IT 蓝图 PPTX翻完图之后真正要复现的是什么「集团IT蓝图总体规划方案.pptx」这类文件在企业里流通得很广多数人翻完只记住几张彩色方块图然后就没有然后了。真正有价值的是它背后那条推演链战略愿景拆到业务架构业务架构再拆到应用架构、数据架构、基础架构、治理架构最后落到项目群、实施计划和预算。德勤这套方法论的关键不在于图好不好看而在于每一层都有明确的上游输入和下游交付物——改动任意一层都能顺着链条找到受影响的系统、数据和接口。这份方案针对的是一家多业态集团整车、零部件、分装制造、多式联运、仓储、金融服务、监管服务同时在跑。这类组织最典型的病是系统按板块竖着长采购、销售、运网、结算各自一套基础数据流程到部门边界就断掉。方案给出的解法是流程化、平台化、标准化三条线端到端流程管事同类功能收进同一平台按权限分数据非关键节点保留差异化。顺着这套逻辑往下读还会看到它和智慧城市项目在架构层是同构的只是场景从城市治理换成了物流资源调度数据源从市政设施换成了物联网终端。谁该细读负责集团级架构设计、系统集成、主数据治理的人以及需要把一份规划文档翻译成可执行任务清单的项目经理。2. 用 python-pptx 拆解蓝图 PPTX 并还原五层架构拿到一份几十页的规划 PPT第一件事不是画新图而是把里面的文本抽出来做结构化。规划文档里的信息密度极不均衡业务架构那一页塞了几百个能力项应用架构页只有二十几个方块交互清单页又是四张长表格。人工抄一遍既慢又容易漏用 python-pptx 跑一遍十分钟能拿到干净的数据底稿。2.1 为什么先解析再设计规划类 PPTX 有个特点架构图基本是文本框的视觉拼接没有真正的语义结构。也就是说你在 PowerPoint 里看到的「采购管理」方块和它下面挂的六个子能力在文件里只是几个坐标相邻的 shape。解析的目的就是把这种空间关系翻译成层级关系后续无论是做能力盘点、生成架构资产清单还是做系统覆盖率分析都有数据可依。另一个现实原因是评审。架构评审会上最常见的争论是「这个能力到底归谁承载」如果事前把所有文本框抽成表按名称去重排序争论范围会立刻收窄到真正有分歧的几十条上。2.2 抽取形状文本并还原阅读顺序下面的脚本递归处理组合形状把每个文本块连同坐标一起导出再按视觉顺序排序。规划 PPT 里大量使用组合不递归会漏掉一大半内容。# extract_blueprint.py from pptx import Presentation from pptx.enum.shapes import MSO_SHAPE_TYPE import json def iter_shapes(shapes): 递归展开组合形状规划 PPT 里嵌套组合很常见 for sh in shapes: if sh.shape_type MSO_SHAPE_TYPE.GROUP: yield from iter_shapes(sh.shapes) else: yield sh def extract(path): prs Presentation(path) pages [] for idx, slide in enumerate(prs.slides, 1): blocks [] for sh in iter_shapes(slide.shapes): if not sh.has_text_frame: continue text \n.join( p.text.strip() for p in sh.text_frame.paragraphs if p.text.strip() ) if not text: continue blocks.append({ text: text, left: sh.left or 0, top: sh.top or 0, width: sh.width or 0, height: sh.height or 0, }) # 纵向按 0.55cm 聚桶再按横坐标排序近似还原人眼阅读顺序 blocks.sort(keylambda b: (round(b[top] / 200000), b[left])) pages.append({slide: idx, blocks: blocks}) return pages if __name__ __main__: data extract(集团IT蓝图总体规划方案.pptx) with open(blueprint_raw.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(pages:, len(data), blocks:, sum(len(p[blocks]) for p in data))排序里那个200000是 EMU 单位下的聚桶宽度约等于 0.55 厘米。规划图里同一行的几个文本框 top 值往往差几千 EMU直接排序会错行聚桶之后基本对齐。如果某页架构图是竖排的把排序键换成先left后top即可。2.2.1 文本清洗与去重抽出来的文本有大量噪声页眉页脚、页码、图表编号、重复的板块名。常见做法是用一组规则过滤比如长度小于 4 的中文块、纯数字块、包含「注1」「目录」的块直接丢弃。同一名称在多个页面重复出现是正常的用字典按名称聚合记录它出现在哪些页反而能得到一个粗略的「该概念重要性」指标。2.3 从散落文本到五层架构目录有了原始文本接下来按规则归层。方案里的五层架构分别是业务架构、应用架构、数据架构、基础架构、治理架构每层都有稳定的关键词特征。架构层识别关键词典型条目后续用途业务架构运营计划、职能管理、采购管理、销售管理采购执行管理、招投标管理提取业务能力清单应用架构企业门户、计划调度管理、运网资源管理仓储服务管理、计费结算管理生成应用系统台账数据架构基础数据管理、主数据、口径客户、供应商、物料编码主数据治理范围界定基础架构部署、区域、集中、边缘区域部署节点、集成平台部署拓扑与容量规划治理架构IT服务管理、信息安全、运维管理需求管理、应用建设管理制度与流程落点规则用字典维护命中即打标一条文本可以同时命中多层比如「运网资源管理」既在业务架构页出现也在应用架构页出现。这种情况保留双标签反而是后续做映射的入口。LAYER_RULES { 业务架构: [运营计划, 职能管理, 采购管理, 销售管理, 物流, 人力资源], 应用架构: [企业门户, 统计与经营分析, 计划调度管理, 运网资源管理, 仓储服务管理], 数据架构: [基础数据, 主数据, 口径, 数据模型], 基础架构: [部署, 集中, 区域, 集成平台], 治理架构: [IT服务管理, 信息安全, 运维管理, 应用建设管理], }参数上建议把关键词表单独放配置文件不要硬编码在脚本里。集团规划文档迭代频繁第二版把「运网资源管理」改名成「运力资源管理」很常见改配置不用改代码。3. 业务能力到应用系统映射应用架构与主数据建模抽完数据就要做真正的架构活了。方案里的核心动作是把业务架构页面上的几百个能力项组合成二十来个应用系统。这个过程有两个约束一是同类功能必须收进同一平台二是应用系统数量要可控否则集成复杂度会指数上升。3.1 业务能力提取与归并业务架构里有三个大板块核心业务、运营计划、职能管理。核心业务覆盖采购、销售、仓储、运输、加工、监管、金融服务运营计划覆盖战略管理、资源计划、投资管理职能管理覆盖人力、财务、审计、法务、设备、档案。归并时的原则是按「管事」而不是按「部门」切分一个端到端流程里的多个能力项应落在同一个应用系统下。常见的误用是照搬组织架构图做应用划分结果每个部门一个系统流程一到边界就得靠接口硬拼。正确做法是先画流程再定系统边界。比如客户订单从接入到结算这条链涉及销售订单管理、计划调度管理、运网资源管理、运输服务管理、仓储服务管理、计费结算管理、财务管理七个系统协作完成缺一个流程就断。3.2 应用系统台账与能力覆盖建模把映射关系落进数据库后续各种覆盖率分析都能用 SQL 跑出来。-- 应用系统台账 CREATE TABLE app_system ( app_code VARCHAR(32) PRIMARY KEY, app_name VARCHAR(64) NOT NULL, layer VARCHAR(16) NOT NULL, -- 展现层/应用层/数据层/集成层 deploy_mode VARCHAR(16), -- 集中/区域/边缘 owner_dept VARCHAR(64), lifecycle VARCHAR(16) -- 在建/在用/待退役 ); -- 业务能力清单 CREATE TABLE biz_capability ( capability_code VARCHAR(32) PRIMARY KEY, capability_name VARCHAR(64) NOT NULL, domain VARCHAR(32) -- 采购/销售/物流/职能 ); -- 多对多映射coverage 表示该应用对该能力的承载程度 CREATE TABLE app_capability_map ( capability_code VARCHAR(32), app_code VARCHAR(32), coverage DECIMAL(3,2) DEFAULT 1.00, gap_flag TINYINT DEFAULT 0, PRIMARY KEY (capability_code, app_code) );coverage字段用来处理一个能力被多系统分摊的情况比如「合同管理」在采购、销售、工程三个系统里各有一部分各自的覆盖度加起来接近 1。gap_flag是用脚本预计算的标记但更稳的找空洞方式还是直接用外连接查。-- 找出规划里提到、但没有任何系统承载的业务能力 SELECT c.capability_code, c.capability_name, c.domain FROM biz_capability c LEFT JOIN app_capability_map m ON m.capability_code c.capability_code WHERE m.app_code IS NULL ORDER BY c.domain;这条查询在评审前跑一遍输出往往能直接变成下一期的立项清单。参数上没什么可调的注意biz_capability要保证已去重否则同一能力多个编码会重复出现在结果里。3.3 主数据统一数据架构的第一道闸方案里反复强调「全公司范围内基础数据统一定义、统一口径」。落到实现就是主数据表加统一编码规则各系统对外只暴露集团统一编码内部主键不外泄。CREATE TABLE md_customer ( cust_id VARCHAR(32) PRIMARY KEY, -- 集团统一编码 cust_name VARCHAR(128) NOT NULL, cust_type VARCHAR(16), -- 主机厂/供应商/社会客户 source_sys VARCHAR(32), -- 首次建档来源系统 version_no INT DEFAULT 1, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_name_type (cust_name, cust_type) );source_sys记录了建档来源用于追责和回溯。实际项目里主数据最难的不是建表是清洗历史数据同一个客户在四个系统里有四个名字合并规则要提前定通常按营业执照号或税务登记号做唯一匹配匹配不上的走人工确认队列。运网资源管理这类系统还会接入大量物联网终端数据——车辆定位、设备状态、场站闸口记录。这类数据不适合塞进主数据表走独立的时序存储主数据表里只保留设备台账和归属关系两者通过设备编号关联。4. 交互清单落地把四张关键交互表变成接口契约方案里最能直接干活的部分是那四张「关键交互信息列表」。每行记录本端系统、对端系统、交互信息和传输方式一共覆盖几十条主要交互。这四张表如果只留在 PPT 里集成就只能靠口口相传把它导成结构化清单并生成接口契约才算真正落地。4.1 交互矩阵的结构化先从表里抽几条典型记录观察规律本端系统对端系统交互信息传输方式建议接口形态销售订单管理计划调度管理用户订单信息实时REST 幂等键计划调度管理运网资源管理资源需求实时RPC 或消息投资管理工程项目管理投资预算、计划实时REST经营计划与预算管理采购管理采购预算定时/年批量文件人力资源管理财务管理薪酬绩效实时/定时消息 批量能看出一个规律传输方式写「实时」的基本都是业务执行链路对延迟敏感且大多需要一个幂等键防止重复投递写「定时」的多数是预算、报表、归档类数据用批量文件或者消息队列的定时投递更划算写「实时/定时」的要拆开看比如薪酬绩效发放时点必须实时归集统计可以定时。4.2 从表格行到接口契约 JSON给每条交互生成一份契约描述重点是把主数据引用和幂等策略写死。下面是一条订单下发的契约示例。{ interface: order-to-dispatch, provider: 销售订单管理, consumer: 计划调度管理, mode: realtime, protocol: HTTPS/JSON, idempotencyKey: orderNo, sla: { p99Ms: 800, retry: 3, dlq: true }, fields: [ { name: orderNo, type: string, required: true }, { name: customerCode, type: string, required: true, mdRef: md_customer.cust_id }, { name: planQty, type: number, unit: TEU }, { name: expectTime, type: string, format: date-time } ] }idempotencyKey指定订单号消费端据此去重。dlq表示失败消息进死信队列规划阶段就该定下来否则上线后丢消息没人知道。mdRef字段把接口字段直接绑到主数据表评审时一眼能看出哪些接口引用了未统一的口径这是数据架构和应用架构的交叉检查点。4.3 用脚本检查交互清单的完整性交互清单最容易出的问题是漏写。两个系统之间明明有数据往来规划表里没有实施阶段才发现工期直接爆掉。写个脚本做图结构检查能提前暴露。import json from collections import defaultdict def audit(interfaces, systems): out_deg, in_deg defaultdict(int), defaultdict(int) for it in interfaces: out_deg[it[provider]] 1 in_deg[it[consumer]] 1 islands [s for s in systems if out_deg[s] 0 and in_deg[s] 0] sinks [s for s in systems if out_deg[s] 0 and in_deg[s] 0] sources [s for s in systems if in_deg[s] 0 and out_deg[s] 0] return { islands: islands, # 既无出边也无入边未进入核心链路 sinks: sinks, # 只进不出通常是分析、归档类需确认 sources: sources, # 只出不进通常是采集、录入类需确认 } if __name__ __main__: data json.load(open(interfaces.json, encodingutf-8)) systems json.load(open(systems.json, encodingutf-8)) print(audit(data, systems))islands里的系统要重点看规划里列了但没有任何交互要么是漏画了线要么是它本来就该独立运行——比如某些内控审计类系统。sinks和sources不必强行消灭但要有明确解释不能是「忘了写」。4.4 端到端场景串测单条接口校验完还要按业务场景把链路串一遍。方案里给的两个例子很有代表性一个是客户订单从接入到结算的八步流程一个是客户通过企业门户查运输在途状态。后者链路是门户到客户关系管理、再到运输服务管理查询类接口可以走缓存没必要每次穿透到业务库。把这两条场景写成可执行的链路测试用例用桩数据跑一遍能提前发现字段缺失、状态机不闭环的问题。常见做法是用契约文件自动生成桩服务评审时现场跑一遍比对着 PPT 讲半小时管用。5. 物联网终端与 AI 特征接入蓝图的落地校验规划落到执行阶段物联网和人工智能这两块最容易变成口号。物联网终端数据进运网资源管理、人工智能做运力预测和经营分析写在 PPT 上都成立真要落地得先把数据链路和特征口径钉死。物联网数据的特点是量大、时序、质量参差。落库时建议加质量标记而不是直接过滤掉脏数据。CREATE TABLE iot_device_metric ( device_id VARCHAR(64), metric VARCHAR(32), -- gps.lat / engine.status / gate.in ts TIMESTAMP, value DOUBLE, quality TINYINT, -- 0 正常 1 补传 2 异常 PRIMARY KEY (device_id, metric, ts) );quality字段保留补传和异常标记训练模型时可以按需过滤追溯问题时又能查全。若直接丢弃异常值事后排查运力预测偏差会非常被动。AI 侧最容易翻车的地方是训练特征和线上特征口径不一致。上线前跑一次分布比对把差异超过阈值的特征挑出来。def feature_drift(train_stats, online_stats, tol0.05): 比对训练集与线上特征统计输出漂移明细 drift {} for k, v in train_stats.items(): if k not in online_stats: drift[k] missing_online elif abs(online_stats[k] - v) / max(abs(v), 1e-9) tol: drift[k] round(online_stats[k] - v, 4) return drift # 例单均运距、平均装载率、车辆在线时长三个特征的均值比对 train {avg_distance: 320.5, load_rate: 0.78, online_hours: 9.2} online {avg_distance: 412.0, load_rate: 0.71, online_hours: 9.0} print(feature_drift(train, online)) # 输出 avg_distance 最大说明训练样本偏向短途模型上线后大概率高估运力tol取 0.05 是经验值业务波动大的场景可以放宽到 0.1但放宽的代价是漂移发现得更晚。这个函数只是最小可用版本实际项目里还要按分位数比对均值相同但分布形态变了的情况并不少见。还有一个容易忽略的校验点主数据编码在物联网链路里的传递。设备台账用集团统一编码终端上报的数据里如果带的是厂商私有编号中间必须有映射层否则运网资源管理里会出现一批「查不到归属」的设备。校验方法很简单把终端数据里的设备编号全集和主数据表做一次左连接统计匹配率低于 99% 就先修数据再做后续分析别急着上模型。本文还有配套的精品资源点击获取 用python-pptx拆解集团IT蓝图：还原五层架构与接口契约
简介这份《集团IT蓝图总体规划方案.pptx》面向大型集团信息化负责人、企业架构师与咨询顾问解决从战略愿景到IT落地路径缺乏系统方法论的问题。方案遵循德勤成熟方法论覆盖业务模式分析、IT信息化蓝图设计、业务与信息化协同等关键环节并串联智慧城市、人工智能、物联网等热点技术的应用场景。内容重点拆解业务架构、应用架构、数据架构、基础架构、治理架构与信息安全六大模块逐层展开应用能力组合、集成架构、部署架构、功能描述与信息交互关系同时统一客户、供应商与基础数据管理建立集成平台以简化系统间交互。压缩包为单一pptx文件约8.35MB便于直接演示或作为内部汇报模板。已有124人学习下载适合需要撰写集团级信息化规划、进行架构分层设计与实施预算编排的读者参考借鉴。1. 一份集团 IT 蓝图 PPTX翻完图之后真正要复现的是什么「集团IT蓝图总体规划方案.pptx」这类文件在企业里流通得很广多数人翻完只记住几张彩色方块图然后就没有然后了。真正有价值的是它背后那条推演链战略愿景拆到业务架构业务架构再拆到应用架构、数据架构、基础架构、治理架构最后落到项目群、实施计划和预算。德勤这套方法论的关键不在于图好不好看而在于每一层都有明确的上游输入和下游交付物——改动任意一层都能顺着链条找到受影响的系统、数据和接口。这份方案针对的是一家多业态集团整车、零部件、分装制造、多式联运、仓储、金融服务、监管服务同时在跑。这类组织最典型的病是系统按板块竖着长采购、销售、运网、结算各自一套基础数据流程到部门边界就断掉。方案给出的解法是流程化、平台化、标准化三条线端到端流程管事同类功能收进同一平台按权限分数据非关键节点保留差异化。顺着这套逻辑往下读还会看到它和智慧城市项目在架构层是同构的只是场景从城市治理换成了物流资源调度数据源从市政设施换成了物联网终端。谁该细读负责集团级架构设计、系统集成、主数据治理的人以及需要把一份规划文档翻译成可执行任务清单的项目经理。2. 用 python-pptx 拆解蓝图 PPTX 并还原五层架构拿到一份几十页的规划 PPT第一件事不是画新图而是把里面的文本抽出来做结构化。规划文档里的信息密度极不均衡业务架构那一页塞了几百个能力项应用架构页只有二十几个方块交互清单页又是四张长表格。人工抄一遍既慢又容易漏用 python-pptx 跑一遍十分钟能拿到干净的数据底稿。2.1 为什么先解析再设计规划类 PPTX 有个特点架构图基本是文本框的视觉拼接没有真正的语义结构。也就是说你在 PowerPoint 里看到的「采购管理」方块和它下面挂的六个子能力在文件里只是几个坐标相邻的 shape。解析的目的就是把这种空间关系翻译成层级关系后续无论是做能力盘点、生成架构资产清单还是做系统覆盖率分析都有数据可依。另一个现实原因是评审。架构评审会上最常见的争论是「这个能力到底归谁承载」如果事前把所有文本框抽成表按名称去重排序争论范围会立刻收窄到真正有分歧的几十条上。2.2 抽取形状文本并还原阅读顺序下面的脚本递归处理组合形状把每个文本块连同坐标一起导出再按视觉顺序排序。规划 PPT 里大量使用组合不递归会漏掉一大半内容。# extract_blueprint.py from pptx import Presentation from pptx.enum.shapes import MSO_SHAPE_TYPE import json def iter_shapes(shapes): 递归展开组合形状规划 PPT 里嵌套组合很常见 for sh in shapes: if sh.shape_type MSO_SHAPE_TYPE.GROUP: yield from iter_shapes(sh.shapes) else: yield sh def extract(path): prs Presentation(path) pages [] for idx, slide in enumerate(prs.slides, 1): blocks [] for sh in iter_shapes(slide.shapes): if not sh.has_text_frame: continue text \n.join( p.text.strip() for p in sh.text_frame.paragraphs if p.text.strip() ) if not text: continue blocks.append({ text: text, left: sh.left or 0, top: sh.top or 0, width: sh.width or 0, height: sh.height or 0, }) # 纵向按 0.55cm 聚桶再按横坐标排序近似还原人眼阅读顺序 blocks.sort(keylambda b: (round(b[top] / 200000), b[left])) pages.append({slide: idx, blocks: blocks}) return pages if __name__ __main__: data extract(集团IT蓝图总体规划方案.pptx) with open(blueprint_raw.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(pages:, len(data), blocks:, sum(len(p[blocks]) for p in data))排序里那个200000是 EMU 单位下的聚桶宽度约等于 0.55 厘米。规划图里同一行的几个文本框 top 值往往差几千 EMU直接排序会错行聚桶之后基本对齐。如果某页架构图是竖排的把排序键换成先left后top即可。2.2.1 文本清洗与去重抽出来的文本有大量噪声页眉页脚、页码、图表编号、重复的板块名。常见做法是用一组规则过滤比如长度小于 4 的中文块、纯数字块、包含「注1」「目录」的块直接丢弃。同一名称在多个页面重复出现是正常的用字典按名称聚合记录它出现在哪些页反而能得到一个粗略的「该概念重要性」指标。2.3 从散落文本到五层架构目录有了原始文本接下来按规则归层。方案里的五层架构分别是业务架构、应用架构、数据架构、基础架构、治理架构每层都有稳定的关键词特征。架构层识别关键词典型条目后续用途业务架构运营计划、职能管理、采购管理、销售管理采购执行管理、招投标管理提取业务能力清单应用架构企业门户、计划调度管理、运网资源管理仓储服务管理、计费结算管理生成应用系统台账数据架构基础数据管理、主数据、口径客户、供应商、物料编码主数据治理范围界定基础架构部署、区域、集中、边缘区域部署节点、集成平台部署拓扑与容量规划治理架构IT服务管理、信息安全、运维管理需求管理、应用建设管理制度与流程落点规则用字典维护命中即打标一条文本可以同时命中多层比如「运网资源管理」既在业务架构页出现也在应用架构页出现。这种情况保留双标签反而是后续做映射的入口。LAYER_RULES { 业务架构: [运营计划, 职能管理, 采购管理, 销售管理, 物流, 人力资源], 应用架构: [企业门户, 统计与经营分析, 计划调度管理, 运网资源管理, 仓储服务管理], 数据架构: [基础数据, 主数据, 口径, 数据模型], 基础架构: [部署, 集中, 区域, 集成平台], 治理架构: [IT服务管理, 信息安全, 运维管理, 应用建设管理], }参数上建议把关键词表单独放配置文件不要硬编码在脚本里。集团规划文档迭代频繁第二版把「运网资源管理」改名成「运力资源管理」很常见改配置不用改代码。3. 业务能力到应用系统映射应用架构与主数据建模抽完数据就要做真正的架构活了。方案里的核心动作是把业务架构页面上的几百个能力项组合成二十来个应用系统。这个过程有两个约束一是同类功能必须收进同一平台二是应用系统数量要可控否则集成复杂度会指数上升。3.1 业务能力提取与归并业务架构里有三个大板块核心业务、运营计划、职能管理。核心业务覆盖采购、销售、仓储、运输、加工、监管、金融服务运营计划覆盖战略管理、资源计划、投资管理职能管理覆盖人力、财务、审计、法务、设备、档案。归并时的原则是按「管事」而不是按「部门」切分一个端到端流程里的多个能力项应落在同一个应用系统下。常见的误用是照搬组织架构图做应用划分结果每个部门一个系统流程一到边界就得靠接口硬拼。正确做法是先画流程再定系统边界。比如客户订单从接入到结算这条链涉及销售订单管理、计划调度管理、运网资源管理、运输服务管理、仓储服务管理、计费结算管理、财务管理七个系统协作完成缺一个流程就断。3.2 应用系统台账与能力覆盖建模把映射关系落进数据库后续各种覆盖率分析都能用 SQL 跑出来。-- 应用系统台账 CREATE TABLE app_system ( app_code VARCHAR(32) PRIMARY KEY, app_name VARCHAR(64) NOT NULL, layer VARCHAR(16) NOT NULL, -- 展现层/应用层/数据层/集成层 deploy_mode VARCHAR(16), -- 集中/区域/边缘 owner_dept VARCHAR(64), lifecycle VARCHAR(16) -- 在建/在用/待退役 ); -- 业务能力清单 CREATE TABLE biz_capability ( capability_code VARCHAR(32) PRIMARY KEY, capability_name VARCHAR(64) NOT NULL, domain VARCHAR(32) -- 采购/销售/物流/职能 ); -- 多对多映射coverage 表示该应用对该能力的承载程度 CREATE TABLE app_capability_map ( capability_code VARCHAR(32), app_code VARCHAR(32), coverage DECIMAL(3,2) DEFAULT 1.00, gap_flag TINYINT DEFAULT 0, PRIMARY KEY (capability_code, app_code) );coverage字段用来处理一个能力被多系统分摊的情况比如「合同管理」在采购、销售、工程三个系统里各有一部分各自的覆盖度加起来接近 1。gap_flag是用脚本预计算的标记但更稳的找空洞方式还是直接用外连接查。-- 找出规划里提到、但没有任何系统承载的业务能力 SELECT c.capability_code, c.capability_name, c.domain FROM biz_capability c LEFT JOIN app_capability_map m ON m.capability_code c.capability_code WHERE m.app_code IS NULL ORDER BY c.domain;这条查询在评审前跑一遍输出往往能直接变成下一期的立项清单。参数上没什么可调的注意biz_capability要保证已去重否则同一能力多个编码会重复出现在结果里。3.3 主数据统一数据架构的第一道闸方案里反复强调「全公司范围内基础数据统一定义、统一口径」。落到实现就是主数据表加统一编码规则各系统对外只暴露集团统一编码内部主键不外泄。CREATE TABLE md_customer ( cust_id VARCHAR(32) PRIMARY KEY, -- 集团统一编码 cust_name VARCHAR(128) NOT NULL, cust_type VARCHAR(16), -- 主机厂/供应商/社会客户 source_sys VARCHAR(32), -- 首次建档来源系统 version_no INT DEFAULT 1, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_name_type (cust_name, cust_type) );source_sys记录了建档来源用于追责和回溯。实际项目里主数据最难的不是建表是清洗历史数据同一个客户在四个系统里有四个名字合并规则要提前定通常按营业执照号或税务登记号做唯一匹配匹配不上的走人工确认队列。运网资源管理这类系统还会接入大量物联网终端数据——车辆定位、设备状态、场站闸口记录。这类数据不适合塞进主数据表走独立的时序存储主数据表里只保留设备台账和归属关系两者通过设备编号关联。4. 交互清单落地把四张关键交互表变成接口契约方案里最能直接干活的部分是那四张「关键交互信息列表」。每行记录本端系统、对端系统、交互信息和传输方式一共覆盖几十条主要交互。这四张表如果只留在 PPT 里集成就只能靠口口相传把它导成结构化清单并生成接口契约才算真正落地。4.1 交互矩阵的结构化先从表里抽几条典型记录观察规律本端系统对端系统交互信息传输方式建议接口形态销售订单管理计划调度管理用户订单信息实时REST 幂等键计划调度管理运网资源管理资源需求实时RPC 或消息投资管理工程项目管理投资预算、计划实时REST经营计划与预算管理采购管理采购预算定时/年批量文件人力资源管理财务管理薪酬绩效实时/定时消息 批量能看出一个规律传输方式写「实时」的基本都是业务执行链路对延迟敏感且大多需要一个幂等键防止重复投递写「定时」的多数是预算、报表、归档类数据用批量文件或者消息队列的定时投递更划算写「实时/定时」的要拆开看比如薪酬绩效发放时点必须实时归集统计可以定时。4.2 从表格行到接口契约 JSON给每条交互生成一份契约描述重点是把主数据引用和幂等策略写死。下面是一条订单下发的契约示例。{ interface: order-to-dispatch, provider: 销售订单管理, consumer: 计划调度管理, mode: realtime, protocol: HTTPS/JSON, idempotencyKey: orderNo, sla: { p99Ms: 800, retry: 3, dlq: true }, fields: [ { name: orderNo, type: string, required: true }, { name: customerCode, type: string, required: true, mdRef: md_customer.cust_id }, { name: planQty, type: number, unit: TEU }, { name: expectTime, type: string, format: date-time } ] }idempotencyKey指定订单号消费端据此去重。dlq表示失败消息进死信队列规划阶段就该定下来否则上线后丢消息没人知道。mdRef字段把接口字段直接绑到主数据表评审时一眼能看出哪些接口引用了未统一的口径这是数据架构和应用架构的交叉检查点。4.3 用脚本检查交互清单的完整性交互清单最容易出的问题是漏写。两个系统之间明明有数据往来规划表里没有实施阶段才发现工期直接爆掉。写个脚本做图结构检查能提前暴露。import json from collections import defaultdict def audit(interfaces, systems): out_deg, in_deg defaultdict(int), defaultdict(int) for it in interfaces: out_deg[it[provider]] 1 in_deg[it[consumer]] 1 islands [s for s in systems if out_deg[s] 0 and in_deg[s] 0] sinks [s for s in systems if out_deg[s] 0 and in_deg[s] 0] sources [s for s in systems if in_deg[s] 0 and out_deg[s] 0] return { islands: islands, # 既无出边也无入边未进入核心链路 sinks: sinks, # 只进不出通常是分析、归档类需确认 sources: sources, # 只出不进通常是采集、录入类需确认 } if __name__ __main__: data json.load(open(interfaces.json, encodingutf-8)) systems json.load(open(systems.json, encodingutf-8)) print(audit(data, systems))islands里的系统要重点看规划里列了但没有任何交互要么是漏画了线要么是它本来就该独立运行——比如某些内控审计类系统。sinks和sources不必强行消灭但要有明确解释不能是「忘了写」。4.4 端到端场景串测单条接口校验完还要按业务场景把链路串一遍。方案里给的两个例子很有代表性一个是客户订单从接入到结算的八步流程一个是客户通过企业门户查运输在途状态。后者链路是门户到客户关系管理、再到运输服务管理查询类接口可以走缓存没必要每次穿透到业务库。把这两条场景写成可执行的链路测试用例用桩数据跑一遍能提前发现字段缺失、状态机不闭环的问题。常见做法是用契约文件自动生成桩服务评审时现场跑一遍比对着 PPT 讲半小时管用。5. 物联网终端与 AI 特征接入蓝图的落地校验规划落到执行阶段物联网和人工智能这两块最容易变成口号。物联网终端数据进运网资源管理、人工智能做运力预测和经营分析写在 PPT 上都成立真要落地得先把数据链路和特征口径钉死。物联网数据的特点是量大、时序、质量参差。落库时建议加质量标记而不是直接过滤掉脏数据。CREATE TABLE iot_device_metric ( device_id VARCHAR(64), metric VARCHAR(32), -- gps.lat / engine.status / gate.in ts TIMESTAMP, value DOUBLE, quality TINYINT, -- 0 正常 1 补传 2 异常 PRIMARY KEY (device_id, metric, ts) );quality字段保留补传和异常标记训练模型时可以按需过滤追溯问题时又能查全。若直接丢弃异常值事后排查运力预测偏差会非常被动。AI 侧最容易翻车的地方是训练特征和线上特征口径不一致。上线前跑一次分布比对把差异超过阈值的特征挑出来。def feature_drift(train_stats, online_stats, tol0.05): 比对训练集与线上特征统计输出漂移明细 drift {} for k, v in train_stats.items(): if k not in online_stats: drift[k] missing_online elif abs(online_stats[k] - v) / max(abs(v), 1e-9) tol: drift[k] round(online_stats[k] - v, 4) return drift # 例单均运距、平均装载率、车辆在线时长三个特征的均值比对 train {avg_distance: 320.5, load_rate: 0.78, online_hours: 9.2} online {avg_distance: 412.0, load_rate: 0.71, online_hours: 9.0} print(feature_drift(train, online)) # 输出 avg_distance 最大说明训练样本偏向短途模型上线后大概率高估运力tol取 0.05 是经验值业务波动大的场景可以放宽到 0.1但放宽的代价是漂移发现得更晚。这个函数只是最小可用版本实际项目里还要按分位数比对均值相同但分布形态变了的情况并不少见。还有一个容易忽略的校验点主数据编码在物联网链路里的传递。设备台账用集团统一编码终端上报的数据里如果带的是厂商私有编号中间必须有映射层否则运网资源管理里会出现一批「查不到归属」的设备。校验方法很简单把终端数据里的设备编号全集和主数据表做一次左连接统计匹配率低于 99% 就先修数据再做后续分析别急着上模型。本文还有配套的精品资源点击获取