迁移前的系统评估：如何盘点现有ERP模块、数据量估算、接口依赖分析、性能基线采集

系统评估这件事，说白了就是给老ERP做一次全面体检。

我见过太多团队，上来就动手迁移，结果发现模块不全、数据量远超预期、接口断链……最后项目延期三个月。嗯，咱们别踩这个坑。

一、盘点现有ERP模块：别漏掉任何一个角落

我个人习惯，第一步先拉清单。不是简单列个模块名字，而是要把每个模块的启用状态、版本号、定制程度、用户数都摸清楚。

这里有个坑：已停用的模块也要记录。我曾经遇到一个客户，说生产模块早不用了，结果迁移时发现历史工单数据还在，而且跟财务成本模块有勾稽关系。你不盘点清楚，迁移后对账对不上，那才叫头疼。

二、数据量估算：别被“大概几个T”忽悠了

数据量估算，我建议分三步走：

1. 按表统计：查每个模块核心表的行数和存储空间
2. 按年增长：看过去3年的数据增量，推算迁移窗口期的数据量
3. 按归档策略：哪些历史数据可以归档不迁移

举个例子，我去年做的一个项目，客户说“库存数据大概500G”。结果我一查，光MTL_TRANSACTION_HISTORY这张表就1.2T，加上索引快2T了。为什么？因为他们从来没做过数据归档，10年的交易记录全堆着。

我常用的估算SQL（以Oracle为例）：

-- 按表统计存储空间
SELECT 
    segment_name,
    bytes/1024/1024/1024 as size_gb,
    num_rows
FROM dba_segments s
JOIN dba_tables t ON s.segment_name = t.table_name
WHERE t.owner = 'APPS'
ORDER BY bytes DESC;

嗯，跑完这个SQL，你心里就有底了。别光看业务表，接口表、日志表、临时表往往是数据量的隐形杀手。

三、接口依赖分析：牵一发而动全身

接口依赖，说白了就是你的ERP跟外面哪些系统在“谈恋爱”。

我建议画一张接口依赖图，包含：

• 接口方向：ERP→外部，还是外部→ERP？
• 接口协议：REST API？SOAP？文件传输（SFTP）？数据库直连？
• 数据频率：实时？每小时？每天？每月？
• 数据量级：每次传输多少条记录？
• 依赖关系：A接口挂了，B接口还能跑吗？

我曾经遇到一个案例：客户说只有5个接口，结果一挖，发现还有12个隐藏的数据库直连视图、8个触发器同步、3个定时任务。这些“影子接口”在迁移时最容易出问题。

四、性能基线采集：没有基线，你怎么知道迁移后是快是慢？

性能基线，就是迁移前的“体检报告”。没有它，迁移后用户说“系统变慢了”，你拿什么反驳？

我建议采集以下指标：

• 响应时间：核心业务操作的95分位响应时间（比如订单录入、凭证过账）
• 吞吐量：高峰期每小时处理的事务数
• 资源使用率：CPU、内存、磁盘IO、网络带宽
• 并发用户数：高峰期同时在线用户数
• 数据库等待事件：Top 5等待事件是什么

举个例子，我习惯用awrrpt.sql生成Oracle的AWR报告，重点关注：

-- 查看Top 5等待事件
SELECT * FROM (
    SELECT 
        event,
        total_waits,
        time_waited_micro/1000000 as time_waited_sec,
        average_wait_micro/1000 as avg_wait_ms
    FROM dba_hist_system_event
    WHERE wait_class != 'Idle'
    ORDER BY time_waited_micro DESC
) WHERE ROWNUM <= 5;

嗯，这里要注意：基线采集要覆盖业务高峰期和低峰期。我一般建议采集7天数据，包含2个完整的周末（很多批处理在周末跑）。

五、综合评估报告：把碎片拼成一张图

做完以上四步，最后要出一份系统评估报告。我习惯用这样的结构：

1. 现状总览：模块清单、数据量汇总、接口数量、性能基线
2. 风险点：高定制模块、大数据量表、关键接口、性能瓶颈
3. 迁移建议：分阶段迁移策略、数据归档方案、接口改造计划
4. 资源估算：需要多少存储、多少带宽、多少人力

说白了，这份报告就是迁移项目的“作战地图”。你评估得越细，后面踩的坑就越少。

好了，系统评估这部分就聊到这儿。下一章咱们聊聊数据清洗的具体打法——那些脏数据、重复数据、孤儿数据，怎么一个个收拾干净。