做SAP S/4HANA升级或转换项目的朋友应该都对“自定义代码分析”这几个字不陌生。工具跑起来很快但拿到结果以后呢我见过太多项目卡在“Analyzing the Findings”这一步——ATC报告几千行警告错误密密麻麻老板问你哪些代码必须改、先改哪个你盯着Excel里的几万行数据一时却不知道该从哪儿下手。这篇文章要聊的就是怎么把这堆分析结果读明白图表怎么帮你快速建立全局认知过滤器怎么帮你把上万条问题收敛成一张可以执行的改造清单以及我从多个项目里踩坑踩出来的实操经验。如果你正在负责S/4HANA迁移前的代码体检或者刚接手一个ABAP代码质量整改的摊子这篇文章应该能帮你省下不少弯路。1. 为什么自定义代码分析的“读结果”比“跑分析”更考验功力1.1 从一次S/4迁移实战说起做SAP S/4HANA迁移项目的人一般都要经历这么一条链路先盘点自定义代码再评估兼容性然后排优先级、做改造最后回归测试。自定义代码分析这个环节就是因为S/4HANA在底层数据模型、接口、权限模型上都做了变革你以前在ECC里写得很顺的ABAP代码到了S/4HANA上未必能用。所以SAP提供了整套工具链从Code InspectorSCI、ABAP Test CockpitATC到SAP Readiness Check 2.0以及后面推出的Custom Code Analysis应用目的就一个把自定义代码里的风险点尽量在迁移前找出来。我实际带过的项目里第一步“跑分析”基本都不是问题。SCI/ATC一把梭几分钟到几小时不等结果就出来了。真正折磨人的是后面的Analyzing the Findings——分析结果怎么读。这里的Findings不是简单的一句话它包含了出问题的对象名、所在的行号、违反了哪条检查规则、严重级别是多少可能还带着一段代码片段和解释。一个中型企业自定义代码动辄几千个对象Findings七八千条甚至上万条都很正常。没有一套读法光是把列表拉出来看一遍就能消耗掉好几天人力。这里我要插一句很多人误以为自定义代码分析等于ATC检查这理解有点偏。ATC检查跑的是静态代码扫描告诉你有语法错误、有废弃的语句、有潜在的性能问题。但Custom Code Analysis在S/4HANA迁移语境里常说的CCA更进了一步它把代码检查结果和系统使用情况绑定在一起。你怎么知道一个对象到底重不重要在ECC里根本没人调的报表改造优先级自然低每天被业务用的核心接口哪怕只有一条警告也得优先盯。这就是为什么SAP在这里多了一层“使用率/影响度”的维度用图表和过滤器的组合把优先级“烘”出来。1.2 分析结果的核心逻辑我们到底在看什么继续沿着结果解读的视角说。在CCA的应用里你点开一条Finding通常能看到这样几类信息首先是对应对象哪个程序、哪个类、哪个报表其次是对象所属的开发包、软件组件、应用组件然后是该Finding的类型和严重级别外加对应的检查器名称和检查规则ID最后才是代码位置和消息详情。严重级别这玩意儿特别容易误导人。我以前带过一个项目领导看到几条Error就慌觉得天要塌了。其实在ATC/SCI里Error、Warning、Info、Style的分级并不是按“影响业务”来定的而是按“对升级的阻扰程度”来定的。一条Error可能只是调用了某个S/4HANA里已经移除的Function Module不一定意味着业务马上挂掉但你得改造一条Warning可能是废弃语句不影响运行但影响后续升级路径。所以读数的时候不能只看红黄颜色还要看检查规则说明搞清楚它到底在说什么。再说一点同一个对象在不同系统里Findings可能不同。为什么因为使用场景不同。你在ECC生产环境里实际被调用的对象和开发机里顺手写了一个没人用的类评估的权重完全不同。CCA里会用颜色区分绿色代表已有对象且已被使用红色或灰色可能代表未使用或者废弃。这些状态配合过滤器才能让你真正区分“必须处理的”和“可以缓一缓的”。所以一上来就闷头看列表是最低效的做法正确姿势是先看图再上过滤器最后才落回明细。这也是这篇文章想给你建立的整体思路。2. 用图表读懂分析结果从“一堆清单”到“一张全景图”2.1 Dashboard页面的整体布局讲起如果你用SAP Readiness Check 2.0或者SAP的Custom Code Analysis应用进入分析结果后一般会先看到一个概览页面。概览通常包含几个部分分析的系统和范围、检查变体、扫描到的对象总数、总的Findings数量、按严重级别和类型的统计卡片。有些界面还直接给出新增代码、修改代码、未使用代码的分布。这些概览数据本身就是图表的原料。为什么第一步要看概览因为在几千个对象、上万条问题面前你需要先回答三个问题问题总量有多大集中在哪一类重不重这三个问题有了答案再往下一层钻取才有方向。不然你直接进明细列表光标都不知道往哪儿放。我用一个真实项目举例。某个客户从ECC 6.0升级到S/4HANA第一个版本分析完概览页显示自定义对象一共一万多个带Findings的对象只有四千二百多Error级别三千多条、Warning级别九千多条。这个数字一出来我和客户CIO就心里有数了工作量不小但因为Error占少数整体风险还是可控的接下来的重点就是看这四千多个对象集中在哪些模块、哪些包然后分批处理。这个决策过程不到十分钟靠的就是概览图表而不是列表。这里面有个细节容易忽略概览页上“新增、修改、未使用”这类分类信息往往比具体Findings更重要。因为S/4HANA改造里一个对象如果是完全未使用的SAP倾向于建议你归档甚至删除根本不用花力气改造。如果概览里显示有30%的对象属于未被使用那恭喜你改造范围直接可以缩一圈。前提是SAP要能采集到真实的使用数据所以在项目里我坚持在正式分析前先校准一段时间的usage数据别拿一个空的或刚开始监控的系统去跑否则未使用的可信度很低。2.2 四张最实用的图表解析概览页面之下通常会有一组可交互的图表。我把实战中最常用的四张逐一拆开来说。第一张按软件组件或开发包分布的问题图。这张图的用法很简单看看问题集中在哪些包里。一般企业自定义代码都放在Z开头开发包里但分布极不均匀有些包是历史遗留的报表集有些包是核心业务流程的增强。画成饼图或者条形图后你能一眼看到哪个包的Findings占了大头然后决定是整体改造还是分批外采人力处理。这里建议配合“对象数量”而不是“Findings条数”来看——一个包里有5个对象、每个对象100条问题和一个包里有100个对象、每个对象1条问题改造策略完全不同。第二张按应用程序组件Application Component分布图。应用程序组件是SAP标准的业务模块标记比如FI、CO、MM、SD这种。这张图的价值在于“责任到模块”财务模块的代码问题可以派给财务开发团队供应链的派给供应链团队。如果你们项目组是按模块分人的这张图就是天然的任务分配依据。第三张按对象类型的分布图。程序、类、函数组、接口、报表、屏幕……对象类型不同改造的技术难度和方式完全不同。类是重构函数组可能是换Function Module报表可能要调字段映射。按对象类型看分布能帮你估算需要哪些技能的人力也能帮你判断自动化工具和人工方式的适用程度。如果一个项目里大头是报表反而好办如果大头是接口类那要小心了接口改造通常牵一发而动全身。第四张按严重级别或优先级的分布图。这张图不是给你看总数而是给你排节奏的。错误级别、警告级别分开看结合使用状态你就得到了一个“紧急但不难”的集合——典型代表是那些“被使用且带Error”的对象这是第一波要处理的其次“被使用且带Warning”的可以排到第二波“未被使用且带Error”的可以考虑先验证可不可以归档。我用一张表格把这四张图的解读要点收一下图表维度优先关注信号典型后续动作软件组件/开发包问题集中在少数包按包分批、外包或集中攻坚应用程序组件某个模块占比失衡按模块分派给对应开发团队对象类型接口/类占比高提前准备接口类专项方案严重级别/优先级Error数量与使用状态组合排定第一波、第二波改造清单2.3 识别风险信号的两个经验图表不仅能看分布还能帮你快速识别一些隐藏的风险。这里我说两个实战中踩过的现象。第一个现象是“大对象”的高密度问题。有些几十万行的历史遗留报表Findings上千条占比大得吓人。第一反应可能觉得这个对象是最优先的但仔细看图表会发现其实问题高度集中在几个子过程里比如一段过了时的日期字段逻辑或一个被重复使用的子程序。如果你是顺着对象维度往下钻的可能已经找到答案了如果只看总数容易被吓到。所以读图表时我习惯先看每个对象平均Findings数超过均值很多的对象钻进去看看它的检查规则是否重复报很多是同一条规则在一个循环里反复命中真正要改的也许就一两个点。第二个现象是“未使用对象”被误判为要处理的对象。图表里如果按状态着色你会看到有些对象标红以为都是高风险实际它只是未使用。未使用不等于没用可能是一个接口只在月底批处理时才用一次或者是一个报表只在当年关账时跑。所以这里的死律是图表上的未使用只是给你一个候选清单最终要不要归档还得拉usage明细甚至问业务。我之前项目里就发生过一次客户按图表把一批未使用对象直接从改造清单划掉结果年底关账时发现其中一个报表还在被财务手工执行。后来我们改了流程未使用对象一律走“业务确认最后使用日期核实”双确认图表只作为初筛不再作为删除依据。3. 过滤器才是缩小战场的利器3.1 过滤器解决了什么问题图表给的是全局印象但要落到“我接下来这周改哪五十个对象”靠的是过滤器。在几万个Findings里直接翻效率低是一方面更麻烦的是分析结果里混着大量无关信息——不同系统的、不同模块的、严重级别不同的、状态不同的。过滤器就是把这些维度一层一层设成条件让结果列表收敛成一张真正可执行的任务清单。这个场景挺好理解你就像一个急诊科医生全院患者的检查结果都堆在你面前。你不能挨个看得先按ICU的筛一遍再按心脏指标异常的筛一遍最后再按年龄筛一遍才能定治疗顺序。同理自定义代码分析里的过滤器就是帮你从全院数据走到“这一个病人该吃什么药”的那几步。实际操作中我建议把这步当成项目管理工具来用而不是技术工具。很多人拿到分析应用后把过滤器当成查找点一下就出结果然后没有保存、没有导出、没有分派下次再来还要重新配。我的习惯是每个过滤器组合都起一个有意义的名字比如“FI已使用Error待改造”存成视图项目每个阶段的检查用同一套视图这样前后数据可比任务也不会丢。3.2 常用过滤器逐个拆解SAP的自定义代码分析里过滤器维度一般包括这些。对象名称支持通配符。这个最直接你想看某个程序的所有问题输入类似ZPP*的通配符就行。但要注意通配符滥用的问题比如只输一个Z那结果还是几万条等于没筛。软件组件和开发包用来限定范围。如果你只关心某几个业务包直接按包筛如果想按系统筛比如只看了生产开发和测试的结果也要在系统维度上动手。应用组件按模块筛。这个对项目周会很友好。我一般会跟开发经理说你只需要看FI这几个应用组件的图表和过滤视图其他模块的问题不用管。这样每个人打开系统就是自己关心的那部分。对象类型比如程序、类、函数组、报文和接口。筛完后你能马上切出一个“把所有接口的Error拿出来”的视图。严重级别这个不赘述就是Error、Warning、Info这些。检查类别或检查规则可以精确到只看废弃语句或者只看性能问题。很多ATC检查规则默认全开但项目的业务重点不同比如这个阶段只关心底表结构变化就可以针对相关规则过滤。使用状态Used/Unused这是从CCA这类工具带出来的关键筛选条件。配合刚才说的“未使用不等于不重要”原则这个过滤器要谨慎使用。最后一个是所有者或负责人以及最后变更日期之类。有些版本的分析应用里能关联到传输请求或者对象目录TADIR的字段你可以按包的所有者来筛甚至按最后修改时间来筛比如只评估最近两年修改过的代码。这类过滤器在“历史遗留代码太多”的时候特别有用帮你把关注范围集中在近期活跃代码上。3.3 一个实战过滤组合示例光说维度有点干我直接给三组过滤组合你在项目里大概率用得上。第一组只看要马上处理的。场景是项目启动第一周要快速圈出第一批必须改的代码。过滤条件设为系统开发与生产、类别已使用对象、严重级别Error、应用组件你负责的模块。这样出来的结果就是第一波改造清单数量不会太多可以直接分配给骨干开发去逐个看。第二组外包或新团队接手某批包。场景是找外包团队做代码治理。过滤条件设为开发包外包负责的包清单可以用通配符或过滤器分组对象类型程序或类严重级别不限使用状态不限。这样导出的时候外包拿到的就是一份完整且独立的清单不跟你内部的核心改造范围交叉。第三组评估“历史遗留能不能删”。场景是减负想把多年不用的报表清理掉。过滤条件使用状态未使用、最后使用日期超过一年如果系统里有这个维度、对象类型报表。但这组条件筛出来的结果绝对不是直接删除清单而是待业务确认清单。我一般会在导出的Excel里再加一列“确认人”和“最后使用证据”让模块顾问去填。为了让这几组示例更好记我列一个表格场景过滤器组合输出目标第一波改造已使用 Error 本模块 本系统骨干开发任务清单外包批量治理特定包 程序/类 不限级别独立完整的外包清单历史代码清理未使用 报表 最近一年未用待业务确认的删除候选4. 实操流程从运行分析到产出可执行的任务清单4.1 标准流程全链路讲完图表和过滤器的原理我把整个流程串一遍方便你直接照着做。第零步准备分析环境。在动手跑分析之前先确保开发系统DEV能正常通过SCI/ATC检查并且你有调用Custom Code Analysis应用或者Readiness Check的权限。很多项目卡在“没有权限看结果”上这步提前确认能省不少事。另外尽量用专门的沙箱或开发机做分析别在生产机上做全量扫描ATC在某些大系统里跑全量挺消耗资源的容易影响业务。第一步执行检查。可以用事务代码SCI进入Code Inspector在检查变体里选中SAP_CC_ATCV这是SAP预置的用于S/4HANA迁移评估的变体覆盖了跟迁移相关的检查然后执行对象集分析。也可以直接用ATC在ADT里发起或者通过Readiness Check 2.0触发。注意这一步是在单个系统上做的如果你有多套系统每套都要跑结果后面才能汇总。第二步收集使用信息。如果用的是CCA需要在系统里开启使用数据收集usage data collection并在分析时把usage数据一并带上。有些项目一开始没开等到要分析使用状态了才发现历史数据没有只能重新等收集周期白白浪费一两周。这块一定要提前规划。第三步汇总结果到分析应用。把各系统结果上传或同步到Custom Code Analysis应用或者分析系统形成统一的视图。这里常见问题就是结果重复多系统汇总后同一个对象可能有多条记录需要在应用里做去重和系统维度切换。我的经验是汇总完先按系统维度看总数是否合理再往下走否则后面所有的图表和过滤器都在重复数据上打转没意义。第四步分析Dashboard和应用过滤器。进入分析结果后先看概览图表确定总量和分布方向再按前面讲的方法建过滤器视图收敛到可执行范围。这里强烈建议把过滤视图保存起来并且在项目周报里固定引用同一视图这样每周对比Findings数量的增减才有意义。第五步导出和分派。把收敛后的清单导出到Excel加上状态列比如待确认、待改造、已改造、不处理原因然后分派给对应负责人。导出时注意大数量问题如果是几万条记录很多SAP前端导出会卡分组导出更稳妥。“常见问题”里我会再细讲。4.2 检查变体选择与配置建议选对检查变体是整个分析结果可用性的源头。如果你用系统默认的SCI全集变体去跑出来的结果可能会包含大量样式类提示淹没什么有用的东西。做S/4HANA迁移场景我优先推荐SAP_CC_ATCV或者包含Usage and Impact检查的变体。这个变体跑完后Findings分类相对干净跟“能否迁移到S/4HANA”直接相关。如果项目已经做过一轮整改我建议在预置变体基础上复制一个项目自定义变体把已经确认不重要的规则组排除掉把针对本项目的增强检查加进来。但注意保存好变体说明免得别人接手项目看不懂为什么某条规则没跑。自定义变体还有一个好处可以设置对象集的范围比如只扫Z开头的包或者排除SAP标准代码大幅缩短扫描时间。配置方面另一个容易被忽略的点是检查变体里的消息级别。同一条规则可以在不同变体里设成Error或Warning。我的习惯是迁移评估期把影响迁移的规则设为Error其他默认Warning到了代码质量治理阶段再把性能类和可维护性规则提高级别。阶段不同变体就不同这样不会被历史噪音干扰。4.3 与开发团队协作分工分析结果不是给顾问自嗨的最终要落到开发手上改造。这里分享一下我协作分工的做法。首先每个模块团队指定一个人当结果解读负责人他负责把过滤后的清单拆成可执行的小任务而不是让每个开发自己去几千条明细里挑。其次每个改造任务要有明确的出口标准——不能只说“这个问题改一下”要写明对象名、行号、检查规则、期望效果。SAP的详情页面里都给足了这些信息导出时尽量带全。最后复查流程不能省。开发改完之后把对象标成已处理然后回到系统里重跑一次对应对象的ATC检查确认Findings消失或级别降低才算闭环。这里我又要提一个容易出问题的点任务分派时不要只看对象还要看依赖。接口类和函数组经常被多个程序调用一个对象的改动可能影响其他对象。所以在分派清单里我习惯加一列“被哪些对象引用”让开发在动接口前先做影响分析。这一点在图表里看不出来得靠明细的依赖关系数据普通导出Excel不一定带我是把导出内容和系统上的依赖分析结果合并整理的项目里因为这个吃过亏翻车那次印象特别深。5. 常见问题与排查技巧实录5.1 高频问题速查表整理几个我真实遇到的、频率很高的问题按表格放在这儿方便你以后直接查。症状可能原因建议处理分析结果好几万条导出卡死单次导出数据量过大按包/模块分批导出或缩到本模块再看图表数字和列表对不上列表有全局筛选图表没跟着变或相反看界面上有没有全局筛选器先统一筛选条件某个对象明明在却找不到过滤器里被使用状态或日期筛掉了回退过滤器逐项排查先清所有筛选再加多系统汇总后对象重复结果同步没有做去重或系统维度未筛选先按系统维度确认数据范围再做汇总分析Error很多但对象全是未使用的历史遗留代码被收入分析范围用使用状态筛选先剔除未使用再评估分析结果里冒出大量SAP标准对象对象集配置过宽检查对象集排除SAP标准命名空间这张表看着简单实际项目里每一条都能拖住一个团队好几天。尤其是图表和列表数据不一致那条最容易让人怀疑人生。我亲身遇到过Dashboard上显示FI模块300条Error点进列表却只有100条翻来覆去找不到另外200条后来发现是列表页自动套了一个“当前用户”的上下文过滤器把另外一个客户端的数据过滤掉了。所以看到数字对不上时先去检查全局筛选器不要急着怀疑系统算错了。5.2 避开这些坑结果解读效率翻倍说几个常规教程里不会写的体会都是项目里磨合出来的。第一个关于过滤器层面的问题。SAP这类分析应用里筛选条件往往有两层一层是全局级影响所有图表和列表一层是局部级只影响当前报表或当前视图。我见过不止一个顾问在局部筛了模块然后拿着全局图表的数字去汇报结果对不上。应对方法很简单汇报前先做一个“口径检查”把全局筛选、时间段、系统范围这三个要素写进汇报材料的备注里管理层看到数字时就知道统计边界。第二个关于使用数据的时效性。前面说过“未使用”不等于不重要这里补充一个技术细节使用数据收集的周期如果只覆盖最近三个月遇到按年运行的报表比如年终关账报表很可能在分析期间没被调用过被误标成Unused。所以正式评估之前至少让使用数据的统计周期覆盖一个完整的业务年度或者采用“统计期间业务确认”的双保险。这事投入不大但能避免一批“假未使用”对象被误处理。第三个关于导出Excel后续怎么办。很多人的习惯是看完图表导出明细发给开发就完事了。我建议再往前走一步给每一条导出记录加上“优先级”和“负责人”两列然后开一次和开发团队的结果评审会逐条过一遍第一波清单把改不动的、需要业务确认的、可以接受的Warning分别打上标记整理成“改造基线”。有了这个基线后面每个迭代重跑分析才有对比价值不然只是重复劳动越看越乱。最后说点个人体会。自定义代码分析这工具跑一次谁都会但真正让它在项目里发挥价值的是Analyzing the Findings环节的功夫。图表的价值在于让你在十分钟内就能对全局的代码健康度建立起正确认知而不是陷在明细里数格子过滤器的价值在于让上万条问题最终变成一叠每位开发都能直接上手的任务卡。我做了这么多年的S/4迁移和代码治理项目越来越觉得“读结果”是一项比技术更稀缺的软技能它需要同时理解SAP的检查逻辑、业务的使用场景和团队的执行节奏。如果你刚接触这块我的建议是别急着把所有结果一次看完先选一个你熟悉的模块用图表把分布看清楚再用过滤器把Error级别且已使用的对象收敛出来跟着代码走一遍你会比那份几千行的Excel更快找到感觉。这个流程熟起来之后再处理全量数据就从容多了。说白了分析结果不是用来“看”的是用来“分”和“改”的把这一步理顺了你的迁移项目就已经赢了一半。