sap模块有哪些_SAP那些事-理论篇-18-如何做SAP售前

说到售前，SAP圈内通常称为“打单”、“拿单”，基本流程是这样的，根据客户招标的要求（可能公开招标或者邀标），通常提供技术标和商务标，技术标针对客户的需求进行响应，商务标针对客户的价格、售后服务进行响应，一般顾问参与的主要是技术标的制作，比如SOW的响应，技术方案的编写等，销售的同事则主要负责商务部分，无疑，如何最终能拿到单子，取决于很多因素（很多时候非技术层面的因素会很多，所以所谓业务顾问，尽力即可），有些甚至是公司注册资金大小。前面我们也有讨论过，ERP-SAP这个行业，本身的产品是标准化的成品，顾问本人的经验和职业操守是很重要的，一个好的项目经理加上水平过硬、经验丰富的顾问再加上高度配合的用户为项目成功会打下良好的基础。下面是个人参加售前工作的一些体会，供大家相互参考。

1. 目前企业对信息化的期望

1) 企业越来越重视管理咨询

目前企业对于信息化除了自身的需求外，更希望咨询顾问能够结合其他公司类似的经验，给企业的管理、流程提出建设性的建议，即提出了管理咨询的部分需求。这需要咨询顾问需要不断学习各自模块相关的理论知识以及主流的业务处理方式，从而给客户提供建议。

2) 数据分析包括KPI与业务处理同时满足，即OLTP和OLAP合二为一。

SAP ERP+BW可以满足，有部分企业已迁移BW到HANA平台，SAP最新的S4 HANA即把ERP更改底层软件的数据结构后迁移到了HANA平台，某种意义上来说已经实现了OLTP和OLAP合二为一。

3) 系统要满足灵活与自动化，

比如业务流程中某个节点的变化导致整体计划的变更，希望系统能够自动更改其他节点的计划。另外，对于需要提醒的业务或者信息，希望系统能够自动预警并通知到相关的部门或者个人。从实际业务角度来说，如果还停留在计划层面未下达和执行，那么计划的变更会比较容易，如果已经在执行阶段，那么只能根据不同情况进行相应的处理。关于自动通知和预警，就是数据出现异常偏差，通过工作流可以实现，不过SAP本身的工作流模块比较复杂，国内貌似没有几个顾问专门做这个模块，可以考虑使用SAP加邮件分发的方式的实现。

4) 财务核算和内部考核更为明细，除了部门，还需核算到班组或者个人。

实现多维度的核算比较容易，无非是多加几个字段就可以，目前SAP的比较新的版本都支持自定义增加核算字段。对于内部管理的考核，建议尽量使用SAP管理会计(成本对象、成本要素、成本流)的思路实现。

5) ERP系统与外围系统的集成，比如营销系统、OA系统、PDM系统，报价系统等。

对于不同系统的集成，ERP系统一定是核心，集成的方式建议采用中间件实现，兼容性较好且更改较为方便，比如SAP PI或者第三方的专门系统集成软件，用于统一管理系统接口。

2. SAP的优点和不足

优点：

1) 计划（物料需求的计划、能力计划、财务资金的计划、管理会计的成本费用计划） 计划举例：MRP/ATP/信用控制/成本（不同阶段，不同维度）

2) 集成（各模块间的无缝集成，灵活定义哪些业务数据按照什么规则生成财务凭证）

集成举例：采购订单对项目（内部订单）将来成本（承诺项）和资金计划的影响（计划层面）。实际层面就以自动过账为例即可。

通过这两点，真正使“事前计划、事中控制、事后核算”变为现实。

不足：

1) 系统过于复杂，实施难度大，这一点其实是几乎没办法避免，系统功能越强大，一定是越复杂的，就像稳定性和灵活性，无法兼得，只能是一个平衡。

2) 界面（UI）不够友好，输入不太方面。

3) 中文翻译不够准确。

4) 个别功能可以实现，却一直没有改进，比如发票校验时可以输入特别总账标识修改统驭科目，比如国内销售成本科目经常会细分，标准配置下难以实现。

3. 售前过程中的注意事项

1) 放空自己，倾听客户的声音

在第一次去客户了解需求时，最好的做法是什么都不想，不想就不会先入为主，放空自己，当自己对客户什么都不知道，只带着耳朵去，客户说多久都不需打断，倾听并记录。一方面，这是对客户的尊重和重视，另一方面，避免未全部了解全部情况前，就发表意见，万一不对，给客户留下不好的印象。在以后的接触中，也尽量保持这种态度。当然，如果客户需要我们反馈时，也需及时反馈，反馈时注意不是重复客户说的话，而是带有总结和建议性的表达。

2) 尽量使用客户化的语言

考虑到客户未必对SAP熟悉，那么尽量使用客户习惯的表达词句或者表达方式进行交流，那么客户比较容易接受。这点很重要，切忌一堆SAP术语。可以换位思考，如果你对SAP一无所知，别人对你大谈特谈SAP的术语，恐怕你也无法感兴趣。

3) 尽量暂时抛弃系统（SAP）

初期接触并不需要给出特定的方案，以了解需求为主，如果客户问到SAP如何实现，那么可以谈，如果不问，尽量以业务本身和流程为主进行讨论，了解什么样的业务流程或者管理制度甚至是市场环境、政策本身导致了目前存在的问题，企业有没有尝试过什么办法去解决，是否可以从管理层面或者业务流程上去解决该问题。如果实施了ERP系统，系统可以提供什么帮助，以普遍ERP的思路去谈，而非动辄SAP怎么样怎么样，这给客户以强势推销的嫌疑，也会给客户认为顾问除了SAP功能，业务方面不够了解的印象，效果反而不好。其实说到底，系统也是实际业务逻辑在软件中的映射，如果实际业务无法做到的事情，而是要求系统帮忙实现，这已经是本末倒置了。

4. 售前方案的设计

1) 客户需求的准确理解

这是方案设计的前提，客户最好能够有实际业务举例（可以考虑把客户实际业务例子体现在方案中，有助于提高方案的说服力），对于理解需求有较大的帮助。

2) 整体性和关键点

方案首先应有个整体的框架和思路，然后再考虑在此整体方案下的关键点如何实现。

3) 方案的明确性

方案应相对明确，哪些能够满足，如何实现？哪些不能满足，为何？对于明明无法实现的需求进行模糊化，或者说想蒙混过关，我认为是自己给自己在挖坑，并不值得鼓励。

4) 方案的建设性

需求回应：不管是否能够实现，对客户列示的所有需求，均应作出相应的回应和答复，且答复应尽量详细说明理由。

5) 方案的展示方式

有Demo最好，次之有PPT图片说明，次之有文字逻辑说明。展示内容需要注意细节，需要向客户展现的地方重点突出。

6) 方案的讲解

好的方案还需要好的讲解。讲解的基本原则我们的方案满足了是客户的什么需求，具有针对性，并尽量使用客户易于听懂的语言进行表达。

讲解要有信心，讲解时对自己提出的方案一定要有信心，相信是解决了客户的问题的，是有价值的 ，这点很重要。

如果讲解过程中不仅满足了客户的现在需求，还考虑到了客户没有想到的需求，即超出了客户的期望，那就是完美！

方案中尽量充分体现对客户需求的重视，使客户感受到我们真心为客户考虑，并做了大量扎实有效的工作。

5. 如何评价一个方案是否合适

1) 方案解决了企业的什么问题

比如解决了流程衔接、信息传递、内部控制、数据统计、报表需求、提高工作效率等，需明确说出。就像一个流程，如果说不出这个流程存在的必要性，那么这个流程是否要保留就要打个问号。

2) 业务点的方案是否和整体方案兼容

是否和整体流程和整体方案有良好的衔接，不要说这个点的方案可以单独实现，却和整体方案冲突，那么这个方案就是有问题的，需要调整，很简单，部分服从整体。

3) 方案是否有良好的可行性

即方案落地的问题，尤其要考虑最终用户操作的工作量与复杂程度，如果操作量过大或者过于复杂，用户体验较差，可能在系统上线后会影响系统平稳运行。

4) 方案是否能够使用企业后续业务的变化和发展

方案不仅需解决目前的问题，还需考虑未来的变化和发展，即方案有良好的可扩展性与挑战的灵活性，目的是尽量降低企业的运维成本。

-------------------------------------------------------------------------------------------

20190222更新：

今天参加了一个售前，昨天晚上11点多到，写PPT写到凌晨5点，7点钟起床，8:40到客户讲方案（不是我讲的），精神状态不好，有个问题提前做了准备，没有及时接过来回答，有点遗憾，不过没什么，继续总结前进就是了。

今天还是总结一下客户对于售前的期望，第一不太希望乙方长篇大论的讲自己公司怎么怎么好，有什么资质，做了什么项目，有哪些客户，顾问多有经验，有多少行业经验等等，第二也不希望讲SAP标准的模块方案（随着SAP的普及，大家多少都有所了解，关键是没有针对性）。反过来说，客户就是希望针对客户的业务（甚至是具体需求）提出具有针对性、可落地的方案（有细节更好，没有细节，至少把需求的理解讲请求，把方案的逻辑讲清楚），另外就是可以强调如果你来接这个项目，你具有什么优势。

对于参加售前的顾问来说，有几个细节注意，提前熟悉行业背景和客户需求，另外就是你对这个项目的理解以及项目方案的重点和难点（结合实际业务讲解），这几点几乎一定会被问到。对于客户的提问需要迅速理解，迅速反应，迅速回答（这个需要练习）。另外就是帮讲述方案的同事提醒时间什么的。

总之，参与售前，弄清楚自己的定位，然后根据定位确定自己能做哪些事情，提前做好准备，在场上有信心的回答就是了（记住，在信息化领域，你就是专家，我们的态度是平等的讨论，但是经验上一定要相信自己对信息化的理解比客户要好的多）。

方案中内容上要有整体，有细节，有实也有虚，虚实结合，粗细结合。