1. 课程导入与全景认知
在制造企业信息化演进过程中，Teamcenter 往往不是一次性上线完成的系统。它通常经历从产品数据管理起步、逐步扩展到工艺规划、变更管理、BOM 协同、供应商协同等多个阶段。每一次业务扩展、组织调整或系统升级，都会在 Teamcenter 中沉淀大量历史数据：早期版本的零组件、已停用但仍有引用关系的图文档、迁移过程中产生的重复物料、字段缺失的 BOM 行、命名规则不统一的数据集，以及跨站点同步后出现的孤儿对象。这些数据不会因为业务向前走而自动消失，它们会持续影响查询效率、变更影响分析、报表准确性和新系统上线质量。
本课程围绕“历史数据迁移”与“数据质量治理”两条主线展开。迁移解决的是“数据从哪里来、如何安全到达新环境”的问题；治理解决的是“到达之后数据是否可信、可用、可维护”的问题。两者不是先后关系，而是交替推进：迁移前需要治理以降低搬运风险，迁移中需要质量校验以发现异常，迁移后还需要持续治理以维持数据健康度。理解这一点，是后续所有章节的认知基础。
业务背景：为什么历史数据会成为问题
Teamcenter 的历史数据问题通常不是单一原因造成的，而是多个阶段叠加的结果。常见来源包括：
- 多系统并行期：CAD 文件、ERP 物料、MES 工艺路线各自独立，同一零件在不同系统中编码不同，合并时产生一对多映射。
- 版本升级与补丁：旧版本对象模型与新版本不一致，部分属性在升级过程中被默认值填充或丢失。
- 组织与流程变更：部门合并、工厂搬迁、供应商切换导致责任人、分类、状态字段失效。
- 人工操作与批量导入：Excel 导入、脚本迁移、接口同步过程中缺少校验，产生重复、空值、非法字符。
- 长期运行的自然衰减：对象被反复修订、引用关系断裂、附件丢失、权限继承混乱。
这些问题在系统运行初期可能不明显，但随着数据量增长，会逐渐表现为：查询超时、BOM 展开错误、变更单无法闭环、报表统计偏差、新项目复用旧数据时引入错误。因此，历史数据治理不是“清理垃圾”，而是恢复数据作为企业资产的可信度。
核心挑战：迁移与治理的四个难点
第一，数据量与时序压力。 大型企业 Teamcenter 库中对象数量可达千万级，附件容量以 TB 计。迁移窗口通常只有停机维护的几小时到几天，必须在不完整停机的前提下完成增量同步与最终切换。这要求迁移方案具备分批、断点续传、差异比对和回滚能力。
第二，关系完整性难以保证。 Teamcenter 数据不是孤立记录，而是由对象、版本、数据集、关系、权限、分类、BOM 行等构成的图结构。迁移时如果只搬对象不搬关系，或关系指向了未迁移的对象，就会产生孤儿数据。治理时必须先识别关键关系链，再决定迁移顺序。
第三，质量规则难以统一。 不同产品线、不同工厂、不同历史时期的数据标准不同。例如，物料编码有的用 8 位数字，有的用“字母+数字”混合；版本命名有的用 A/B/C，有的用 01/02/03。治理不能简单“一刀切”，需要先建立可配置的规则库，再按数据域分批执行。
第四，业务连续性与可追溯性。 历史数据往往仍在被在用产品、售后、质量追溯引用。治理动作不能破坏已有引用关系，也不能让用户突然找不到熟悉的数据。因此，治理方案必须包含影响分析、备份策略、灰度验证和用户沟通。
课程目标：学完之后能做什么
本课程不追求覆盖 Teamcenter 所有模块，而是聚焦历史数据迁移与质量治理这一条主线。完成学习后，你应该能够独立完成以下任务：
- 对一个给定的 Teamcenter 历史库进行数据盘点，识别对象类型、数量、关系密度和主要质量问题。
- 设计一份可执行的迁移方案，包括抽取范围、字段映射、批次划分、增量策略和回滚预案。
- 建立一套数据质量规则库，覆盖完整性、唯一性、一致性、有效性和及时性五个维度。
- 使用查询、报表或脚本对迁移结果进行抽样验证，判断是否达到上线标准。
- 针对迁移后出现的孤儿对象、重复物料、关系断裂等问题，定位原因并给出修复方案。
- 建立持续治理机制，让数据质量不因新数据进入而再次恶化。
整体学习路径
课程按“认知—规则—执行—运维”四个阶段推进。第一阶段建立全景认知，明确迁移与治理的边界和风险；第二阶段深入规则与方案设计，包括数据建模、映射表、质量规则和批次策略；第三阶段进入执行与验证，覆盖试迁移、差异比对、质量评分和异常修复；第四阶段关注上线后的持续治理，包括监控指标、定期巡检和规则迭代。工具与案例贯穿始终，每一阶段都会结合真实场景中的对象、参数和判断依据展开。