FDE落地

Q: 开通科技 / FDE 是做什么的？

重庆开通网络科技有限公司（开通科技，品牌 FDE）提供 AI 能力与落地实践服务：智能体开发与运营、电商 AI 应用（AIEC）、企业智能营销 GEO，并配套诊断、咨询、培训与社区内容。

Q: 三大场景应用分别是什么？

FDE智能体（/agents）做企业级智能体开发与运营；AIEC（/aiec）做电商履约采销与上架自动化；GEO（/geo）做生成式引擎优化，提升品牌在 AI 回答中的正确引用。

Q: 如何开始 AI 落地？

可从免费诊断（/offers/diagnose）摸底优先级，再进入 AI 能力（/ai）、AI 落地路径（/delivery）或对应场景应用站点深入了解。

很多数据治理项目都经历过同一个剧本：治理团队花了大半年把存量数据清了一遍，报告交了，指标也漂亮了。可没过多久，业务侧上了个新系统、新报表、新接口，同一批问题又冒出来了——客户编码又多了一套写法，订单金额的口径和财务对不上，必填字段在源系统里根本没人校验。 这不是治理团队不努力，而是治理动作的位置放错了。存量清理是"减量"，前置卡点是"断增量"。只做前者，问题会不断以新系统为载体重新长出来。 ## 一、先看清：为什么治完存量，增量还会继续脏 把治理动作全部放在数据产生之后，会形成一条固定的时间差： - **需求阶段**：需求文档写的是功能，不是数据。指标怎么算、字段从哪来、编码引用谁，没人问。 - **设计阶段**：表结构由开发按自己的理解定，字段长度、枚举值、是否允许为空各写一套。 - **开发阶段**：接口能通、页面能开就算完，没人检查字段是否落在标准上。 - **上线阶段**：系统上线了，治理团队第一次看到这批数据——此时问题已经沉淀在库里。 - **事后阶段**：治理团队发现问题、开单、整改，成本最高，还容易和业务扯皮。 这条链路里，治理团队永远在最后一个环节出现，天然处于被动。所以真正要改的不是"清得更勤"，而是把治理关卡往前挪，让问题在需求评审和设计评审时就被拦下来。 ## 二、五道卡点：把治理从"事后体检"变成"事前规定 + 事中拦截" 行业里通常把这类动作叫治理前置或事前治理，核心是在数据进入系统之前就把它规定清楚，在进入系统的过程中做入口校验。落到执行层面，可以拆成五道卡点。 ### 卡点一：需求评审加一张"数据需求卡" 需求评审会通常只评审功能范围和优先级，数据相关的内容一句"按现有规范来"就带过了。建议在评审材料里固定加一页数据需求卡，只回答四个问题： 1. **指标口径**：这个需求涉及的指标怎么算？分子分母是什么？时间维度按哪个字段取？ 2. **主数据引用**：客户、物料、组织、供应商这些实体，是引用主数据平台，还是自己新建一套？ 3. **字段标准来源**：新增字段对应哪条数据标准？如果标准里没有，走新增标准的流程，而不是直接建。 4. **数据 Owner**：上线后这批数据出问题，找谁？ 这张卡不需要写得很长，一页纸即可。它的价值不在于文档本身，而在于**逼着需求方在动手之前把口径说清楚**。很多口径冲突，其实在需求阶段就能暴露，只是从来没人问。 实操提醒：数据需求卡不要做成"治理团队单独审一遍"的流程，那样容易被绕过。更有效的做法是把它作为需求评审的必备附件，没有这张卡，需求不进排期。 ### 卡点二：设计阶段做落标检查 需求说清楚了，接下来是设计。这一阶段最容易失控的是表结构和字段定义——每个系统都按自己的习惯建表，字段名、类型、枚举值各不相同，等到要打通时才发现对不上。 落标检查要做三件事： - **字段级元数据与标准绑定**：新增字段在设计文档里必须标注对应的标准条目，没有对应标准就走标准新增流程。 - **编码规则从主数据引用，而不是各写一套**：客户编码、物料编码这类主数据编码，设计时直接引用主数据的编码规则，不在业务系统里重新定义一套生成逻辑。 - **表结构评审（数据模型评审）作为独立关卡**：把表结构评审从技术评审里单独拎出来，由数据管理员参与，重点看命名、类型、枚举、主外键关系是否符合规范。 这里有个常见阻力：开发觉得这是在拖慢进度。可以换个说法——设计阶段改一个字段，成本是一行文档；上线后改一个字段，成本是数据迁移加下游适配。落标检查省下的其实是后面的返工。 ### 卡点三：开发与上线设质量门禁 设计对了，还要防止开发过程中走样。质量门禁的思路是：关键字段的校验不通过，不放行。 门禁规则不用一开始就铺得很全，先盯住四类： | 校验类型 | 检查什么 | 典型场景 | |---|---|---| | 完整性 | 关键字段是否为空 | 客户名称、订单日期、金额 | | 唯一性 | 主键与业务唯一键是否重复 | 客户编码、合同编号 | | 参照完整性 | 外键是否能在主数据中找到 | 组织、物料、供应商 | | 口径一致性 | 同一指标在不同系统中的计算结果是否一致 | 收入、成本、库存 | 门禁放在哪个环节很关键。放在上线验收时，问题发现得还算及时；放在开发自测阶段，成本更低。比较务实的做法是分两级：开发环境跑全量规则，发现问题自己改；上线验收跑核心规则，不通过不进生产。 需要注意，门禁规则本身也要有人维护。规则只增不减，跑一段时间就会变成噪音源，开发开始习惯性忽略告警——那时候门禁就名存实亡了。建议每季度回看一次规则的命中情况，长期零命中的规则要么下线，要么重新校准阈值。 ### 卡点四：变更走影响分析 新系统上线是一次增量，源系统改字段是另一次增量，而且更隐蔽。 一个业务系统把"客户等级"字段从两位字符扩成三位，或者把枚举值从 A/B/C 改成 1/2/3，看起来是小事，但下游可能有十几个报表、接口、模型在用它。等报表算错了才发现，排查成本很高。 变更影响分析要解决的就是这件事：源系统提变更时，先通过血缘关系扫描下游影响范围，把受影响的报表、接口、指标列出来，再决定是同步改造还是做兼容映射。 这件事能不能做成，取决于血缘数据是否可用。血缘不是画一次就完的图，它需要跟着变更持续更新。实操上可以这样起步：先对核心指标和主数据相关表建立血缘，覆盖不全没关系，但要求"变更必须登记"，让血缘在变更过程中逐步补全。 ### 卡点五：把"新增问题来源"做成可观测指标 前四道卡点是动作，第五道是反馈。治理做得好不好，不能只看存量问题的数量下降，还要看新问题的来源结构。 建议在治理月报里固定放三个数： - **新增数据问题中，来自新上线系统的占比**：占比高，说明前置卡点没起作用。 - **需求与设计阶段拦截的问题数**：这个数从零开始增长是好事，说明关卡真的在拦。 - **上线后返工的问题数**：这个数下降，说明前置质量在提升。 这三个指标合起来，能回答一个管理者最关心的问题：治理投入到底是在救火，还是在防火。 ## 三、落地顺序：别全面铺开，先跑通一条链路 看到这里，最容易犯的错误是"五道卡点一起上"。五个环节同时改流程，涉及需求、开发、测试、运维多个团队，阻力会大到推不动。 更稳的做法是选一个切口，把全链路跑通一遍。切口的选择有两个建议： 1. **选一条主数据**，比如客户或物料。它被多个系统引用，问题最集中，收益也最容易被看见。 2. **选一个核心指标**，比如收入或库存周转。它跨系统、口径争议大，最能检验前置卡点是否有效。 然后按"需求—设计—开发—上线"的顺序，把五道卡点在这条链路上依次落地。跑通一条之后，流程、模板、评审机制都有了现成的样板，再复制到下一条主数据或下一个指标，阻力会小很多。 ## 四、几个容易踩的坑 **坑一：把前置做成审批。** 治理关卡如果只是多签一个字，很快会变成走过场。关卡要能真正拦住东西，就必须有明确的检查项和不通过的后果。 **坑二：只加关卡不加工具。** 靠人工核对字段是否落标，规模一大就撑不住。字段与标准的绑定、血缘的采集、门禁规则的执行，都需要平台承载，否则关卡会退化成形式。 **坑三：把责任全压在治理团队。** 前置卡点的本质是把数据责任前移到需求和开发环节，业务方要对口径负责，开发方要对落标负责，治理团队负责定义规则和提供工具。责任不重新分配，治理团队就会变成所有问题的兜底方。 **坑四：只看拦截数量不看拦截质量。** 拦截得多不代表拦得对。要定期回看被拦截的问题里，有多少是真问题，有多少是规则误报，据此调整规则。 ## 结语 数据治理做不下去，很多时候不是方法不对，而是位置不对。存量清理解决的是"已经脏了的数据"，前置卡点解决的是"还会不会继续脏"。 开通科技数据治理平台围绕数据质量、元数据、主数据、数据标准、数据治理平台落地五个方向提供平台能力与方法支撑，其中平台落地与流程前置部分，覆盖治理关卡嵌入数据开发流程、变更影响分析、上线治理验收的推进支撑。对多数企业来说，先挑一条主数据或一个核心指标，把"需求—设计—开发—上线"这条链路的前置卡点跑通，比全面铺开更有效——跑通一条，才有复制的基础。 （本文所述方法与指标为通用实践建议，具体治理节奏取决于数据规模、治理域范围与组织配合度，需结合实际情况评估。）