原文链接：https://mp.weixin.qq.com/s/sfDk-NOq03bwmDwE5nPugw

大家可以关注我个人公众号，所有分享内容，会在公众号第一时间推送，且阅读排版更好。

愿大家的学习，轻松且愉快。

如果大家觉得有用，希望转发关注，谢谢

导读

最近有一个做开发的朋友联系我说：想转行，想从SAP实施相关行业，听说：“SAP业务顾问是用户与开发人员之间沟通桥梁。”感觉这个更适合他。

这篇内容，就简单从SAP实施顾问在用户需求与开发之间的沟通作用方面，简单分享一点思考总结，希望对想了解、想从事SAP相关行业的朋友有用。

以下仅个人理解，还请大家批评指正。

正文

作为SAP顾问，得具备SAP系统的标准知识，同时又要具备一定的行业经验，还得了解一定系统开发及功能实现的知识。

因此，有很多人都将SAP业务顾问解释为：“用户与程序员之间的一座桥”，从而保证用户的想法被正确地实现。

如果一定从业务需求到技术实现的角度上看，那么这座桥，不是简单的传递，而是要至少包含以下三个方面。

1.对用户需求的合理分析

一般用户提出的需求和想法，都是基于自己本岗位的现状和问题的。

作为SAP顾问，不能直接按照用户的想法就进行系统实现的，这样的系统实现，最后，是无法有效使用的。

用户的需求想法，是有强烈的局限性和不全面性的。

从局限性而言，企业产线上的领料员提出了一些想法，做为SAP顾问，你不能期待一个产线上的领料员，帮你去思考从需求到采购，再到物料仓储，以及最后财务结算整条业务链上的合理性，但SAP大多数的系统功能，却是要贯穿整个业务链的。

从不全面性而言，业务用户提出业务需求时，多数情况是单一正向的，我们也不能过分依赖于用户能清晰地列举出各种不同的业务情况。

所以，在对用户需求进行收集和调研时，作为SAP业务顾问，需要有效地帮助用户去合理的管控需求。比如，某部门提出希望改变当前对物料需求的提报流程和功能，那我们就得考虑新需求的变化对其他部门的现有流程和系统功能是否影响，比如采购、物流、仓储，甚至生产及财务等部门。这是作为业务顾问，所应具备的基本的全局性思考方式。

同时，关于当我们在帮助用户梳理业务时，还要不断帮用户思考各种可能存在的业务场景，进而保证未来的系统功能，能够满足各种业务场景的使用。

比如，A部门提出其部门的物料需求，提给部门经理，审批通过后，再发给B采购计划部门进行评估采购，到货至C库存管理部门，A部门直接领用。刚听起来，这个业务流程不算复杂，很容易就梳理出来了。

但是作为一个SAP业务顾问，要考虑的问题就多了：

1.A部门提交物料需求后，部门经理审批不通过，后续流程怎么走，需求该是什么状态，打回去重新修改，还是默认自动关闭，用户重新提交？

2.A部门员工将物料需求提交后，部门经理也审批了，由采购计划部门发现物料号不对，或者数量维护不合理，后续流程又改怎么办？

3.A部门的需求提交到采购部门后，采购计划部门发现不需要采购，当前库存够用，或者发现当前库存只满足部分需求，剩下的需要采购，或者几天后就有到货，能够满足需求等等，这些业务情况发生后，后续流程又该怎么办？

4.甚至A部门发出了需求，B部门也帮着采购了，供应商已送货至工厂了，突然A部门因为某些意外发生，不需要这批物料，又有没有这种情况的发生，如果发生了后续该如何处理，等等。

除了启发用户考虑各种不同的业务情况，SAP业务顾问还得尽量建议用户去避免让系统去支持各种不合理的业务，并建议线下处理。如上述4中的描述，需求提了，也采购了，都送货到厂了，突然需求部门说不要了，这种业务本身就是不合理的。作为需求部门，对自己需求的合理性要有一个起码的预期。

上述举例，在实际需求梳理工作中，情况可能会更多更复杂。所以，作为有经验的SAP顾问，帮助用户合理地平衡规划业务流程，从而保证系统功能实现后，能够全面地支持健康合理的业务情况，且能有效避免不合理业务的发生。

其实，除了业务本身以外，我们还需要考虑开发成本。如果为了满足某种极少发生的特殊业务，我们开发了大量且不常用的系统功能，同时，给最常见的业务操作都带来干扰，这种情况下，我们就要考虑，这种功能有没有实现的必要了。

以上这些内容，都是我们在帮助用户对需求进行管控时，所需要考虑的事情。

2.将用户需求有效地传递给开发团队

作为SAP业务顾问是需要具备一些代码实现、数据库设计及接口实现原理等基本知识的。

当SAP业务顾问在和用户聊需求时，肯定是有一定开发难度的估算的。

当需求被确定时，作为SAP业务顾问一定是大致系统功能已经形成了，同时，支撑这些功能背后的数据库表间关系也有了初步结构。也就是说，SAP业务顾问设计出来的系统功能，其数据库表的基本表间关系、表关键字以及具体字段等也就被设计出来了。

当然，如果用户需求涉及增强，大致的增强点，业务顾问也应该清楚；如果需求涉及系统接口，与外部系统哪些数据需要交互，如何产生数据，并发送数据给外部系统，如何接受外部系统的数据，并如何处理这些外部系统的数据。

上述这些问题，在SAP业务顾问确认需求后，大致框架应该已经形成了，后续只需要具体实现细节上的进一步讨论了。

曾经一个项目上，甲方要做一个采购平台，采购平台上的数据直接传输至SAP，生成相应的采购订单，收货等联动。这个采购平台系统，有产品经理，数据库团队，后端团队，前端团队，以及设计团队。

产品经理负责业务调研和需求整理，设计部门也做了设计。由于是to B业务，对业务的闭环要求比较高，同时多次收货、或者取消收货、发票校验等，会有大量单据间多对多的情况，这对数据库表关键字及表间关系的设计，就提升了一定的难度了。

而这个产品经理收集的需求后，也没有任何结构化的整理，每天跟传话筒一样，将需求直接交给数据库团队进行设计。数据库团队由于不了解实际业务，各种认为不合理，不可行，经过大量讨论后统一意见了，也经常是，会上都觉得可行了，会后执行又发现问题，这是典型的没有带着数据库表设计的思路，去分析业务流程，其实这在SAP顾问看来，就是业务没有理解透彻，对SAP顾问来说，理解业务绝不仅是将用户的业务需求背过，而是能够业务从技术实现的角度进行彻底解构。

我还记得那个项目最后上线时，从下午7点开始，表间关系一直没梳理清楚。最后SAP顾问被要求帮忙，重新梳理了几个关键表的关系，重新修改了代码，才保证首笔业务正常流转，那晚我是凌晨4点下班的。

聊到这里，很多朋友会问，为啥没怎么测试就能上线呢。因为对方系统的开发，属于边开发边理解需求，最后要上线了，才算是对需求有点儿认识了，当时又有回款合同条约，而且因为某种关系，乙方比甲方还强势，要求必须在那个时间上线，所以，最后就这么“正常”上线了。

其实，作为业务顾问了解一些开发的基本原理也是非常有用的。曾经，在一个项目上，一个不算复杂的报表，在单元测试环境中运转正常，当我们在集成测试环境中进行测试时，就发现很慢，但也可以执行出来。当时的开发顾问，不算是一个特别上心的哥们儿，当我提出异议时，这哥们儿的回复是：“这不能用么？别想太多，给用户解释一下就行了。”

经过多次交涉后，这哥们消极反馈。这样，实际上就把问题交到我手里了，我得用这个很慢的功能去说服用户，而且我自己也认为，复杂度一般的报表，这么慢的运行速度是不太合理的。后来就自行分析了一下，单元测试环境的数据少，而集成测试环境数据和生产环境一样，数据多，很有可能是报表取数时，并没有按照选择条件，先取部分数据再做计算，最后展示。大概率是直接先取了表里面的所有数据，再做筛选，再做计算，最后展示。最后，自行debug了一下，果然如此，有了这些，问题就好解决多了。

说白了，如果项目中碰到好队友啥事儿都不难，要是队友不是很靠谱，再简单的事情都很难。当然，我碰到的大多数开发顾问都是很靠谱的，现在也都是很好的朋友。

所以，没事儿学点儿ABAP知识，在某些时候还是很有用的。给大家推荐一下我最近在梳理的基本语法：https://mp.weixin.qq.com/s/duqoiqWTre1Bk2GnUn5ecg

3.对系统上线前后的有效评估

一般我们系统上线时，会有大量的测试工作，SAP业务顾问相关的测试，多数是基于各种业务情况在系统中能否合理运转进行测试的。当然，有的项目也有对代码本身，进行一点压力测试，看看大量数据下的运转速度等。

其实基于各种不同的业务场景，我们要清楚地知道，我们在上线前要准备哪些静态和动态数据，在上线的那个时间节点，我们得知道不同状态的业务数据，该如何处理，才能保证该笔业务在新功能上线后，应该如何进行等。

同时，我们也能大致预测到当新功能上线后，用户大致的新需求会提在什么地方？比如进一步自动化需求，比如功能可能被推广到其他工厂或部门的应用，比如哪些报表用户可能会需要，比如某个业务流程的进一步优化等等。

当我们大致掌握了这些方向，下一期的项目方向，整个项目团队就心理有数了，具体的项目工作量、功能难度、项目周期等，就大致就有一个初步的预估了。

这在某种程度上来说，不是只是把用户需求传递给开发这么简单，而是根据当前的系统评估，要预测用户未来的需求走向了。

这对于后续系统建设工作来说，是非常有利的。

本篇就分享这些，后续在结合其他方面给大家分享相关内容。