FDE岗位实务指南 · 第09篇“申请上写的是2箱目录里的基础单位是‘只’仓库说货够了系统算出来不够。你们先把数据口径统一一下吧。”第一次听到这种话很容易把它当成报表问题把两边的字段名改成一样数字就能对上。真正做下去会发现改名字只是最表面的一层。两个系统可以都叫“数量”、都叫“库存”各自说的却不是同一件事。引入AI之后这个问题不会自动消失反而更容易被放大。让模型把两张表“整合成一份分析”它会自作主张地补上换算、对齐字段输出一张看起来整齐的结果。没有确认过的口径就此被包装成确定的数字。本文回到澄川制造。第六、七篇出现过它的采购任务这一篇处理其中更基础的一层同一笔业务在申请与目录两边各有一套说法时FDE怎样把含义和对应关系理清。企业与记录均为教学设定。同名不等于同义。报表上相邻两列的“数量”一列来自采购申请填写人按提货习惯写“箱”另一列来自物料目录维护人按管理要求用最小单位“只”。名称相似含义、单位、来源都不相同。主例是一笔争议记录采购申请里物料M101的数量为2单位“箱”物料目录里M101的基础单位是“只”。周报把两张表拼在一起谁也说不清这笔申请到底是多少。把“统一口径”拆开至少要回答四个问题两边说的是不是同一个对象每个字段在那里是什么含义单位之间凭什么换算数字对应哪个时点和哪种状态。本文依次处理最后把确认过的内容落成可以复查的映射。范围也要说清。这一篇只解决含义与对应关系不展开完整的企业建模对象之间怎样组织成模型留给下一篇。两边都写“库存”为什么数字不同先看争议为什么会发生。采购申请和物料目录是两个系统里的两张记录本来各管各的事申请记录“这次要多少”目录记录“这个物料按什么管理”。把它们放进同一张周报是报表的需要不是数据本身已经对齐。对齐缺失时错误不会立刻暴露。申请人填2看报表的人按“只”理解得出的结论差一个数量级。更隐蔽的情况是两边数字看起来都合理只是互相解释不了直到对账那天才被翻出来。还有一个常见误会认为哪边是“对的”。申请侧说业务提货按箱方便目录侧说主数据必须用基础单位规范。两边都有道理。口径问题通常不是谁错了而是两套说法各自成立、中间缺一段被确认过的换算和对应关系。“库存”这个词的麻烦更典型。仓库说库存指实物在库计划说库存指可用量要扣掉已预留和不可用的部分财务说库存又可能按金额口径。同一时刻问同一个仓库三个答案都正确。第六篇画流程图时强调过交接处要写清状态这里遇到的是同一类问题在数据层面的样子。FDE在这类问题里的位置也值得说明。这不是纯技术任务改字段、写脚本谁都能做也不只是业务沟通聊完不留记录下周还会再吵。FDE要做的是把澄清过程变成有据可查的条目什么确认了、依据是什么、谁确认的、什么条件下适用。这样定位之后方法就围绕四个问题展开。下一节先从一笔具体记录开始走一遍完整过程。从一笔争议记录追溯口径第一步不是换算是保留原样。申请侧教学编号CG-2417物料M101数量2单位“箱”提交日期与申请人有记录。目录侧物料M101基础单位“只”包装规格栏空白目录版本有日期。把原始记录截留下来后面所有讨论才有共同对象。如果第一步就动手“清洗”把箱乘成只或者把只除成箱争议就从“两边说法不同”变成“你改过的数字和系统不一样”更难查。然后找含义与责任人。“箱”在申请语境里指什么最可能的说法是申请人沿用以往的提货习惯。但沿用不等于依据。谁有资格回答这个问题在澄川制造的分工里物料包装与单位归物料规则负责人管申请填写的习惯要问申请人或资料核验员目录字段由谁维护系统负责人清楚。含义没有记录时责任人就是唯一入口。问的时候有个技巧不要问“一箱是多少只”就结束而是请申请人说明这样填的理由并把说明原样记下来。一句“以前供应商的送货单都是按箱写的”是线索它指向送货惯例而不是企业规则后续要按线索去查真正的依据而不是把这句口头解释直接当成系数。接着核对标识。申请里的M101和目录里的M101是同一个东西吗编号相同只是第一条线索。物料可能改过型号旧名称的记录还在库里目录版本之间同一编号对应的规格也可能不同。核对时把两边的描述字段并排看规格、材质、适用设备逐项比不能只看编号一致就放行。历史名称也要查。如果目录曾经用旧型号收录过同类物料后来的申请可能仍沿旧名。库里有别名或历史版本时把相关记录翻出来看一眼确认CG-2417提交的那个时点目录里M101对应哪一版规格。这一步同时区分业务身份与系统记录。申请编号CG-2417是这笔申请的业务身份目录里那行M101是主数据记录两者本来就不是一类对象不需要也不能强行合并。要做的是确认“这笔申请指向目录中的哪一条记录”把引用关系说清楚。核对完标识才能碰单位。此时已经知道两边大概率指向同一型号但“箱”的含义没有依据包装规格栏空白。缺失的包装系数明确留空。不写“一箱大概10只”也不借别的型号的包装来填。有人会问留空会不会显得没完成工作恰恰相反。这一步的产物不是换算结果而是一份待确认清单确认人是谁、确认什么、凭什么确认、什么时候要。把“不知道”写成有责任人的待办比对齐一个错误数字更有用。清单也要有去向。CG-2417这笔申请处于待核实状态就不应进入已确认的合计与看板报表可以单独列出“待核实”一栏让读者知道还有多少数字悬而未决。让未确认的数字留在原处并标明状态比混进合计里安静地出错要好。待确认事项挂在物料规则负责人的工作清单上约定回复期限期限到了没有回复FDE跟进而不是让流程默默等下去。说明标识、单位、时间与状态上一节的动作背后有四类需要分别说明的属性。标识先说。《企业本体建模方法与实战指南》在对象标识一节列出几个必须明确的问题一个标识是否只对应一个实例标识会不会随名称、组织或系统迁移而变多个系统里同一对象如何对应对象合并、拆分、注销后历史事实如何归属对象不再活跃后历史是否保留。落到M101物料编码要保证唯一与稳定这次争议里真正起作用的是“型号与规格版本”这一层标识——申请指向的是某个版本的M101不是永远不变的编号本身。物料主数据将来合并或改版时历史申请仍要能按当时的版本解释。操作上可以把两边记录里所有起标识作用的字段列出来物料编码、规格描述、版本号、申请编号、目录记录的内部ID。然后逐个标注哪个是业务身份哪个是系统记录哪个在系统之间可以互相引用。标注完会发现“对不上”往往不是缺一个字段而是没人说过哪个字段算数。单位与换算有时间属性。“一箱10只”不是物料M101的永久属性而是某个包装版本的属性。包装版本有生效日期也可能有失效日期供应商换包装、企业改装箱规格都会产生新版本。解释历史申请应按提交时点有效的包装版本查当前库存用当前版本。默认按哪个时点解释要事先约定不能看哪边方便。来源与可信度也要记录。目录字段来自主数据可信度相对高申请人填写的“箱”是操作习惯属于待确认信息。两种来源进入映射表时待遇不同前者可以直接作为解释依据后者只能作为线索确认之后才升级。模型从文档里“读出”的换算关系同样只算候选不能自动当成依据。可信度还可以和自动化边界挂钩。来自主数据且在生效期内的换算依据可以放心让程序自动换算只有人工口头说明、尚未登记的只能用于人工核对不应写进自动计算的规则里。来源等级决定这条数据能走多远。状态是最后一层也是“两套库存”最常见的原因。补一个仓库侧的教学例子某批次实物在库1000kg其中可用900kg、待检80kg、留样20kg。待检中50kg经确认释放后实物仍是1000kg只是状态重新分类可用变950待检变30。随后实际出库100kg实物总量才变成900kg。在库与可用是两个口径差异来自状态不是谁算错了。这笔仓库例子是独立的教学数据与采购主例不混用。把状态说全还要看有哪些状态参与口径待检、留样、冻结、预留、在途各企业的划分不同。做口径条目时把参与计算的每个状态列出来写明它算不算进当前口径。漏一个状态两张报表的差异就永远解释不完。回看主例状态同样在场。CG-2417的申请数量在核验完成前是“待核实”它和“已确认2箱”是两个不同的业务处境前者不驱动任何后续计算后者才能作为依据使用。把状态从记录里抽掉剩下的只是一个孤零零的数字谁也不敢用。把这些并起来看一笔记录至少带着对象标识、字段含义、单位与换算依据、生效时点、质量状态和来源。缺任何一项两边数字对不上时都说不清差在哪里。把确认过的含义落实成映射口径澄清之后要落成条目否则下次争议还要重来一遍。条目可以放在词汇与映射表里至少包括对象标识、字段含义、两侧来源、单位、换算依据、生效期、责任人、确认状态。M101这笔记录经物料规则负责人与系统负责人共同核对后条目目前是这样对象物料M101规格版本V2教学版本号争议字段申请数量申请侧原值2原单位箱来源采购申请CG-2417提交日期见原记录目录侧基础单位只来源物料目录当前版本换算依据未确认包装规格栏空白申请人说明待记录确认数量空状态待核实责任人物料规则负责人确认人与确认时间确认后补记逐项看为什么这些字段不能省。两侧原值保留是为了任何时候都能回到争议起点来源指到具体记录是为了复核的人不用重新找换算依据单独一列是为了把“有依据的换算”和“临场估算”分开责任人和确认状态是为了这张表在三个月后仍然知道下一步该谁做什么。条目里“确认数量为空”是有意的。它和零不是一回事零表示“没有”空表示“还没确认”。这个区别后面还要用到。假设下一步物料规则负责人确认该型号现行包装为一箱10只自某日期起生效并登记了依据。此时这笔申请才能解释为20只。注意这是条件结论只在“该型号、该包装版本、生效期内”三个条件同时成立时可用。换个型号或翻回旧期间就要换依据。登记依据时把三样东西一起存依据内容现行包装为一箱10只、依据凭证包装规格确认记录或供应商装箱单、生效日期。缺凭证的确认也要标明“口头确认、待补凭证”它的可信度低于有凭证的条目。条目确认后用历史记录复核。抽取上一季度已完成的采购申请按条目重新解释数量再与当时的核验记录对照。能对上的说明映射对历史也成立对不上的标出是哪段时期的记录、差异多大交给责任人判断是口径变过还是记录有误。复核结果写回条目作为它可信度的证据。复核不必追求全部解释通。历史上口径本来就可能变过复核的目的恰恰是把“什么时候变的、依据哪一版”找出来而不是强行用今天的条目解释所有历史。解释不了的时期单独记一条历史口径与现行条目并存。这与《商业分析知识体系指南》中数据字典的做法一致为每个数据元素记录名称、别名、取值与含义、描述并明确维护责任。别名一栏对本篇尤其有用——申请侧的“箱”、仓库口头说的“整箱”都可以作为别名挂到同一术语下让后来者搜索时能找到。指南同时提醒数据字典需要日常维护否则元数据会过时或出错——所以条目里必须有责任人和复核安排而不是建一张表就结束。映射表本身也有边界。它回答的是“两边的字段怎样对应”不替代数据模型更不是完整的企业本体。出现新的争议对象时加条目条目多到难以人工维护时再考虑工具化。用反例验证并安排维护映射建好之后用几个反例检查它会不会失效。反例一名称相同对象不同。澄川制造的“申请”在采购语境里是采购申请在费用语境里是报销申请两个系统都叫“申请单”字段也相似。若按名称合并统计两类业务会混在一起。检查方法是抽几条记录看业务身份而不是看表名。反例二换算条件外推。把“一箱10只”用到另一型号或者用到包装版本变更之前的历史期会得到看似精确的错误数字。检查方法是把条目里的生效条件当真每次换算先问一句这个依据此刻适用吗。反例三未知填成零。包装系数没确认时填0或默认1都会改变业务含义还会顺着计算链污染后面的合计。检查方法是搜结果里的空值与零值追问每个值是“确认没有”还是“尚未确认”。对AI生成的结果同样适用模型补出的换算系数是候选值必须走同一条确认路径。三个反例指向同一件事映射不是一次性的对齐动作而是带条件的约定。条件失效时约定就要重新确认。维护安排跟责任人走物料规则负责人维护换算依据系统负责人维护记录映射包装版本变更、物料换型号、系统迁移时触发更新没有变更时按固定节奏抽查复核。触发条件写进各自的工作检查项比指望某人记得更可靠。读者可以把这套检查迁到自己的业务上选客户、付款或批次资料套同一条目——对象标识、两侧来源、单位、换算或折算依据、生效期、状态、责任人。重点检验三种情况一笔拆成多条时金额和数量怎样分摊多条并成一条时以哪条为准名称经历过变化时历史记录按哪个名字解释。每检查完一项列出仍然待确认的映射把它们变成有责任人的待办而不是继续留在各自的报表里。今天就可以做一件小事找出你们报表里两个对不上的数字把两边原始记录截下来按这五个问题走一遍——是不是同一个对象、字段各是什么含义、单位凭什么换算、对应哪个时点和状态、谁说了算——写下已确认与未确认的部分。口径统一的标志不是两列数字终于相等而是任何一个数字都能说出它是什么、按什么单位、依据哪个版本、在哪个时点、由谁确认。