SAP那些事-理论篇-如何做SAP的售前
本文标签: SAP ERP 

以下是个人对企业信息化售前尤其是SAP售前工作的一些体会。 

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

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

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

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

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

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

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

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

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

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

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

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)   方案是否能够使用企业后续业务的变化和发展

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

 

发表于: 2016-11-17 16:35 阅读(383) 评论(0) 收藏 好文推荐

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册