SAP PS模块需求调研实战指南：从WBS到项目结算的避坑要点

做SAP PS模块的顾问，最怕听到一句话：“我们公司项目很多，管理比较乱，你帮我们上一套项目管理系统就好了。”这句话听起来简单，但一进入需求调研阶段，问题就全冒出来了。PS模块和FI、MM、SD这种纯单据型模块不一样，它是一条横跨市场、研发、工程、采购、库存、生产、财务的线索，调研范围天然就大，稍不留神就会变成“什么都想要、什么都定不下来”。

这篇内容主要面向刚接触PS模块的顾问、参与SAP项目的业务方项目经理，以及那些准备启动PS模块实施但还没想清楚怎么调研的企业内部IT。我会从头到尾讲一遍：调研之前要准备什么、访谈问什么、怎么判断需求的真伪、最后怎么把访谈记录变成一份能指导蓝图设计的调研报告。全程都是我在实际项目中踩过坑之后的总结，可以直接拿来当操作清单用。

1. 为什么说PS模块的需求调研是最容易翻车的环节

1.1 PS模块调研的三大特殊难点

PS模块在SAP里的位置很特殊，它不像MM的采购入库、SD的订单发货那样流程清晰，PS更像一个“项目业务的容器”：前端承接销售、市场、研发的需求，中间要协调物料、人工、服务、设备，后端还要把项目成本结算到财务或资产。这种跨模块特性，直接导致调研时面对的人特别多，业务场景特别杂，需求边界特别容易模糊。

我做过的PS项目里，最常见的翻车原因有三个。第一，访谈对象过于集中在高层，高层说“我们要精细化管理项目成本”，但一线人员根本不知道自己的WBS编号从哪来，最终蓝图设计出来没人会用。第二，调研问题过于依赖通用模板，问了一堆“你现在怎么管项目”这种开放问题，得到的回答全是抱怨，形不成需求输入。第三，也是最要命的，就是没有在调研阶段确认清楚“PS模块的边界”，把其他模块该做的事情也揽到PS头上，导致后面配置和开发量失控。

所以PS模块需求调研，核心不是“听用户讲需求”，而是“带着PS的标准功能框架去引导用户讲场景”。先把SAP PS能做什么解释成业务听得懂的语言，再请用户确认哪些场景需要做、哪些不需要做，这样才能把模糊的“要多管理系统”变成具体的业务需求清单。

1.2 调研前先统一语言：项目管理术语对表

很多调研会开到一半就卡住，不是因为双方不配合，而是因为术语不一致。业务方口中的“大项目”可能是SAP里的“项目定义”，也可能是“WBS”；用户说的“任务”可能是“网络活动”，也可能是“采购订单”。如果不先在调研阶段把术语对齐，后面蓝图评审基本没法看。

我的建议是，正式访谈前先做一个术语对照表，发给所有的访谈对象。不需要太复杂，列清楚几组核心概念就够了：项目管理里叫“项目”，SAP里有时对应“项目定义”；用户说的“分项工程”，其实就是“WBS”；说到“工序”或“任务”，对应的多半是“网络和活动”；“节点”不等于WBS，可能是“里程碑”。我第一次做PS调研时没有做这一步，结果业务方用Excel里的项目层级图给我讲了两个小时，原来他说的“三级节点”对应的是WBS第4层，如果我按他的说法去建WBS，后面成本归集全乱套。

这不是洗脑，而是为了后面每一次访谈、评审都建立共同语境。实际操作中，我会把术语对照表放在调研问卷的最前面，访谈开始前花5分钟过一遍。不要让用户背SAP术语，但要让用户知道“你说的这个词，顾问这边记录成什么”。不同人对同一词的理解不同，这一步绝对省不下来。

2. 调研前的筹备工作

2.1 资料收集清单

不少顾问一上来就约访谈，我认为这是最大的效率杀手。需求调研的第一步不是问问题，而是先收集现有的项目管理制度、项目清单、成本核算方法和报表样例。有了这些基础材料，访谈时才能直接切入关键细节，而不是从零开始听业务讲“项目是什么”。

我常用的资料收集清单包括：企业组织架构图，特别是项目型组织里项目经理、计划员、成本会计的职责划分；现有的项目立项、变更、关闭制度；最近两年实际执行过的代表性项目清单，最好覆盖不同类型、不同金额；项目成本核算办法，比如间接费用怎么分摊、人工怎么归集；还有最关键的，现在用的项目管理表格或系统截图，包括项目计划表、进度跟踪表、成本台账、付款申请表、项目结项报告。这些资料才是用户真正的“现状系统”，看一遍比听十遍介绍都有用。

资料收集的方式不建议只发一个邮件然后等，一定要拿到后快速翻阅，并标注出你看不懂的地方。看不懂的地方就是访谈时最值得问的切入点。比如如果项目台账里有一列叫“内部结算价”，那就要专门去问它怎么算、谁负责维护、和SAP里的什么逻辑对应。很多时候，资料里的一个特例比资料本身更有价值。

2.2 组织架构与项目管理现状摸底

PS模块调研里，组织架构是最容易忽略但影响最大的部分。这里说的不只企业行政组织，而是“项目怎么管起来”这一套组织体系。比如谁发起项目、谁批准项目、谁当项目经理、谁维护WBS、谁做日常进度跟踪、谁负责项目采购、谁做成本核算，这些角色在SAP里会映射成不同的权限和主数据责任人。

我习惯画一张项目组织图：最上面是项目决策委员会或投资委员会，中间是项目管理办公室或计划部，下面是具体执行的项目组、采购、财务、仓库。画完之后要确认每个节点上的人和系统角色怎么对应。很多企业虽然组织里有PMO，但实际项目计划还是工程师自己用Excel做，PMO只做汇总；这时候你就要评估，SAP里要不要启用正式的项目构造器权限给一线工程师，还是统一由PMO的计划员维护。

现状摸底还要了解项目分级分类规则，比如投资类项目、研发类项目、客户订单类项目，有没有不同的管理流程。这直接影响SAP里项目参数文件的划分逻辑。我在一个制造业项目里就吃过亏，当时默认所有项目都用一个模板，后来发现基建项目走预算强控、研发项目走柔性控制，根本不兼容，被迫配了多套参数文件。这些业务差异在调研阶段都能挖出来，关键是要主动问，别等蓝图设计时才发现。

3. 核心调研内容：从WBS到项目结算

3.1 项目主数据：项目定义、WBS、网络与活动

PS模块的主数据是调研中第一个要咬死的主题。核心问题有这么几个：项目定义怎么建，是按客户订单建，还是按年度投资计划建，还是按产品研发项目建；WBS的层级结构大致分几层，每层代表什么业务含义，最后一层（叶子层）是不是承担成本归集；要不要用网络和活动，如果要用，网络活动的颗粒度是什么，是做到工序级还是阶段级。

很多用户初期都会说“我们要用网络来做进度管理”，但在SAP里做进度计划并不像Project那样拖拽方便，网络和活动的设计往往需要结合关键路径、里程碑、物料组件一起规划。调研时必须问清楚项目团队用什么工具做进度计划，如果大家已经习惯用MS Project，那就要讨论是替换为PS的计划板还是保留集成方案。我做过一个工程公司，最终选择了只用WBS做结构分解和成本归集，用网络做关键里程碑，而不是全覆盖到工序级，原因就是项目组明确表示工序级进度不需要在SAP里管，这个判断就只能在调研阶段通过业务访谈得出，不能靠顾问拍脑袋。

还有个容易被忽略的点是里程碑。WBS元素和里程碑在PS里是两回事，里程碑可以用来做发票开票、进度确认、预算释放等触发。调研时要问清楚：项目在哪些关键节点要对外开票，内部有没有按里程碑考核，里程碑由谁维护。这直接关系到要不要配里程碑开票功能，以及里程碑趋势分析报表怎么设计。

3.2 计划与控制：日期、成本、预算、物料、资源

这部分是PS模块调研的重头戏，也是用户表达需求最强烈的地方。日期管理方面，要问清楚项目整体周期怎么定，是倒排计划还是正排计划，有没有客户强制节点，WBS层级之间日期关系是自动传递还是手工维护。成本计划方面，要确认是按整个项目做一笔总体成本计划，还是按WBS逐年、逐月做详细计划；计划成本由谁来录入，是做手工计划还是从外部估算系统导入。

预算控制是调研中必须掰开揉碎的一个主题。我先会问：现在项目成本超支是事中发现的还是事后发现的？很多企业回答“项目结束算账才发现超了”，那说明现有管理缺少事中控制。在SAP里可以用预算（Budget）对WBS做控制，当实际成本加上承诺成本超过预算时，系统可以给出警告或错误信息。但这里要问清楚：超支由谁审批，是项目经理还是财务，预算要不要在项目内部进行转移，这类细节决定了预算参数的配置方式。

物料和资源更是不能跳过。项目需要领用物料时，是通过什么方式产生采购申请，是手工建PR，还是通过网络中的物料组件自动生成MRP需求；项目人工工时怎么报，是报在WBS上还是报在内部订单上；外部服务合同怎么管理，是一揽子采购订单还是跟WBS关联。这些每一个都能单独展开一场访谈。

3.3 项目结算与报表需求

PS模块最后都要面对“项目成本去了哪”这个问题。调研阶段必须问清楚结算规则：项目成本是结算到资产（资本化），还是直接进费用，还是结算到销售订单或获利能力段（CO-PA）。不同的结算目标对应完全不同的配置，而且这个决定受财务核算制度影响很大，不能等到配置阶段再去问财务。

我记得有个项目，工程部门一直说项目要资本化，调研时财务也没细看，结果开发完成后资产模块负责人说这类项目按公司制度是要进费用的，最后项目组回头改结算规则，重新测了一轮成本和报表。所以说，调研阶段最少必须包含一次财务与项目业务人员的沟通会，会上直接确认项目分类与核算方式。

报表需求也要单独收集。用户通常说不出“我要CJ20N里的哪个字段”，但能告诉你“我要每天看到每个项目的合同额、累计成本、应付金额和进度百分比”。这时候顾问要做的，是把这些信息需求映射到SAP标准报表或报表开发需求清单里。我建议访谈时准备一张标准功能表，比如项目信息系统、项目结构报表、成本汇总报表、里程碑报表等，让用户对照勾选，而不是让用户凭空发挥。

3.4 与其他模块的集成点

PS模块的调研如果不聊集成，就等于没调研。要单独安排与各模块的关键用户对谈：和MM聊，项目采购的预算检查、物料入库到项目库存如何处理；和PP聊，项目生产订单和网络物料组件的关系，是否启用项目相关的计划订单；和SD聊，一个项目对客户开票，是按里程碑开票还是按WBS特定元素开票；和FI/CO聊，项目费用核算、结算、固定资产转资；和HR聊，项目人工成本收集，是通过CATS（跨应用时间表）还是成本中心工时。

别看集成点这么多，真正要落到调研报告里的，是“业务事件在哪里发生，系统在哪里记录”。比如工程领料，业务上是在工地发生，但系统记录可能是通过MB1A发货到项目库存。如果这个流程不问清楚，到时候用户就会拿着SAP的标准流程说“我们不是这么干的”，返工成本极高。

我在集成调研时会做一个很简单的矩阵表：左侧列业务场景，比如“项目物资采购”“项目人员出差报销”“项目设备折旧”“项目对客户发票”，右侧标出涉及模块、主责部门、现有系统操作人。这个矩阵在后面画流程图、定接口范围时非常有用，也方便在调研现场及时发现跨部门扯皮的问题。

4. 调研的方法和访谈技巧

4.1 找谁谈：访谈对象地图

不要只看职位就去安排访谈，应该先画出访谈对象地图：上线后谁会天天用这个系统，谁每周用，谁只在月底看一眼数据。天天用的用户，比如项目计划员、项目核算会计，是核心访谈对象，要安排到每个人的一对一访谈；每周用的，比如采购跟单员、仓库管理员，可以安排小组访谈；月底看数据的领导层，更多是通过汇报会议收集需求，而不是逐个访谈。

按这个逻辑，一个中型PS项目我一般会安排这些角色：项目管理办公室主任（问制度和标准）、项目经理代表（问日常管理）、项目计划员（问WBS和网络维护方式）、采购专员（问项目采购和预算检查）、成本会计（问成本计划和结算）、财务经理（问核算和预算控制口径）、销售运营人员（问项目开票和合同管理）。每个人访谈时长控制在一到一个半小时，宁可多安排一轮，也不要一次塞进太多人。

访谈顺序也有讲究。先管理层、后执行层。先搞清楚“公司为什么要上SAP PS”，再了解“具体岗位每天做的操作是什么”。如果反过来，执行层面讲了很多细枝末节，方向上却跟管理层的目标冲突，就容易白做。我一般会先做一轮项目启动会式的管理层访谈，再铺开做岗位调研。

4.2 提问清单与追问技巧

提问清单按主题分成几块，每块先问现状，再问痛点，然后问期望。以WBS为例，先问“现在项目分解结构用什么工具做，谁来做”，再问“分解到第几层，每层管理什么信息”，再问“现在遇到最大的问题是什么，是分解不一致还是编号乱”，最后问“上了新系统后希望怎么管理WBS”。

追问技巧上，最容易犯的错是听到答案就往下走。用户说“我们WBS大概分四层”，一定要追问一句“每一层的编码规则是什么，是部门编码开头还是项目类型开头？”很多问题就是这样追出来的。还有一个技巧，多问“如果……怎么处理”，比如“如果项目中途预算不够了，你的流程是什么”，这种场景化追问比“你希望怎么做”更能激发出真实的业务规则。

我还会让用户现场演示一遍他日常最常用的那张项目管理表，一边点一边问“这个数哪来的，那个数去哪了”。这种访谈效率特别高，比拿着问卷一条条问快得多。用户讲完自己搭的表格，你基本也把他的管理逻辑摸透了。

4.3 需求分级：区分刚性需求与优化需求

用户提到的需求不一定都要做，但你不能当场否定，要学会分级。刚性需求是“不做系统没法上线”的，比如项目成本必须归集到WBS、项目采购必须有预算检查，这类需求直接影响核心配置。优化需求是“不上也能跑，但工作了会好很多”的，比如自动发邮件提醒项目进度延期。还有一类是“听起来美好但当前阶段不该做”的，比如复杂的项目组合管理、跨系统项目管理协同。

为了不让调研结论变成“什么都要做”，我会在访谈记录里为每条需求标注优先级：P0代表必须满足，P1代表建议本阶段做，P2代表可以后置。调研结束时再把所有P0需求汇总成一页纸，发给业务负责人签字确认。有了这个清单，后面需求变更时就有依据，也不容易出现“当时调研时明确说了不做这个，现在你却说是需求”的扯皮。

这个方法还有一个好处：能有效控制项目范围。很多SAP项目做不下去，不是技术难，而是什么需求都接，最后开发量爆掉。需求分级不是不负责任地砍需求，而是把有限的资源集中到最关键的事情上。实际操作里，提出P2需求的用户往往自己也没想清楚，给他们一个“后续再考虑”的缓冲期，比当面争论有用得多。

5. 从调研到蓝图：如何写一份能落地的调研报告

5.1 报告结构

调研报告不能写成访谈纪要大杂烩，应该有明确的结构，让看的人一眼知道现在是什么情况、未来要怎么做。我习惯按这个结构来组织：调研范围与对象、现状业务流程与痛点分析、业务需求清单与优先级、SAP PS模块功能映射与差距分析、关键流程初步方案、风险与待确认问题。

现状与痛点部分要结合收集到的资料和访谈记录，用“现状是……结果是……影响是……”的句式描述。不要只写“项目进度管理混乱”，要写“项目进度由各项目经理用Excel维护，无法实时汇总，公司管理层每周需要电话催报”。这种描述才有说服力，到了签字确认时业务方也没法否认。

功能映射与差距分析部分是报告价值最高的地方。列一个表：左列是用户需求，中间是SAP标准功能点，右列是Gap及处理方式（配置解决、开发解决、流程规避、手工替代）。这个表做完，需求是否可行、开发量有多大，基本上就一目了然了。调研报告不是为了做文档而做文档，它是给后续配置开发团队看的操作指引。

5.2 需求确认会的组织方法

调研报告初稿出来后，一定要开需求确认会，而且不是全体大会，是分主题的小型确认会。成本和管理层的人关心预算和结算，项目计划员关心WBS和网络，采购关心物料需求。把不同主题的关键人拉在一起，逐条过需求清单，比发一封邮件等回复有效得多。

确认会上最重要的一个动作，是把每条需求都用业务场景再讲一遍，并得到明确答复。“确认”不只是用户点了头，而是要当场在报告上签字或至少在会议纪要里写明“同意该方案”。这个动作在项目后期特别有用。我经历过几次需求确认会上大家都说“可以”，结果上线时业务换了一个关键用户，说“这不是我们要的”，因为没有签字记录，项目组只能吞下返工成本。

确认会还有一个隐形任务：消除跨部门之间的理解偏差。比如工程部想要“每个项目实时显示利润”，但财务部告诉我项目利润要等月底成本结算完才能算，两拨人当场对齐，才能避免上线后互相指责。这个环节看起来只是开会，其实是在管理业务预期。

6. 常见问题与避坑实录

6.1 只说“要做个项目管理系统”，怎么往下挖

这是最典型的开场白，越空旷越要小心。应对方法是把它拆成几个可执行的问题：你说项目管理，最想管的是进度、成本还是资源？如果只能优先解决一个，选哪个？现在最占用你时间的统计工作是什么？每个问题的答案都能帮你快速定位用户真正的关注点。

我以前遇到一个用户，不停强调要做项目管理系统，但细问才知道他真正痛的不是管理，是月底要向老板报每个项目的销售额和回款，而销售数据不在手上。最后方案重心就从PS做了偏移，变成项目和SD的集成以及报表开发。如果当初不做追问，直接按“全套PS模块”去设计，调研方向就完全错了。

6.2 WBS层级与成本对象如何确定

关于WBS层级，常见的问题是问“你们项目一般分几层”，这没有标准答案。正确问法应该是“你希望成本最小核算到哪一级”，比如按区域、按标段、按专业，那一级就是WBS叶子层。叶子层之上加几层汇总结构，根据管理报表需要来定。

还有一个概念要分清楚，WBS用于做结构分解，而成本对象不等于WBS叶子，成本可以通过结算规则从WBS再转出去。调研阶段就要确认：是要把项目成本留存在WBS上做项目利润分析，还是把成本结算到生产订单、内部订单、固定资产？很多企业初期只让顾问建WBS，却不谈结算目标，等到FI顾问介入时才发现整个核算路径是错的。

6.3 预算控制口径：硬控还是预警

预算控制是PS模块里最容易被业务方误解的功能。用户往往说“我们要控制预算，超支了不让做”，但真做到采购入库时弹红叉，业务又受不了，说太死了。所以要问清楚：采购环节、收货环节、发料环节，哪个环节必须强控，哪个环节允许警告后放行。

还有一个更细的点：预算控制的对象是WBS还是网络？如果企业以WBS为控制点，那所有采购申请都要挂到WBS，PM和财务统一按WBS审预算；如果企业项目操作习惯于按网络任务下达采购，那预算控制就要放在活动对应的WBS上。这个差异不搞清楚，配置出来的控制逻辑一定会在上线后爆发问题。

6.4 结算规则不清，结不了账

项目结算问题通常不是调研时发现的，而是月结时爆发。为了避免这种情况，调研阶段必须做一次模拟：拿一个真实项目，从立项、采购、发生费用到最后月结，把结算路径走一遍，看看能不能形成闭环。不能等到开发阶段才找资产会计确认资本化规则。

我见过很多企业项目费用混在一起，不知道哪些资本化哪些费用化。问了工程部门，工程部门说交给财务了；问了财务，财务说没有明确标准。这是典型的结算规则未定义问题。调研时要专门安排一次会议，让财务和项目管理人员一起对项目分类表进行逐行确认，该资本化的挂在资产结算规则下，该费用化的结算到成本中心或内部订单。这笔专项工作，再麻烦也得在调研阶段完成。

以下是我基于常见问题整理的排查对照，供大家在访谈中快速参考：

7. 写在最后：几点个人体会

7.1 需求调研不是一次访谈就能完成

我开始做SAP PS模块时，以为需求调研就是把所有关键用户访谈一遍就结束了。后来发现，真实需求往往在第二轮、第三轮才浮出水面。第一轮大家谈的是理想中的系统，第二轮会围绕第一轮形成的问题清单深入讨论，第三轮才是真正接近业务操作细节的交流。

所以每次访谈结束后我都会做一件事：把现场记录里所有模糊点整理成一份追加问题清单，在下一次访谈时带回去。哪怕只是电话沟通，也要把确认结果补充进调研报告。这样做看起来多花时间，实际上是在减少蓝图设计阶段的返工时间。一个项目里的需求不可能是静止的，持续追踪、逐轮收敛，才是调研该有的节奏。

7.2 留白与迭代：别试图在调研阶段解决所有问题

需求调研很容易陷入一个误区：今天发现一个问题，今天就想着把解决方案定下来。但完整方案需要和多个模块的顾问一起讨论，牵一发动全身。调研阶段的重要产出不是“完整解决方案”，而是“清晰的问题清单和需求边界”。把每个问题的业务规则、相关人员、影响范围描述清楚，就足以支撑后续设计了。

如果你问我做PS模块调研最重要的一项能力是什么，不是懂多少SAP技术，而是能不能把业务方零散的表述转化成结构化的系统需求。这件事没有捷径，只能靠一个个访谈、一张张表格、一次次确认会磨出来。希望这篇内容能让你在下一场PS调研中少走一点弯路，真刀真枪上手时，少一次返工。