SAP项目小悟随语

随着项目的一步一步发展，对SAP产品和项目的理解也发生着变化。刚开始对mySAP ERP软件产品本身的感知：就是巨大、繁琐，不友好，可以说是很排斥的。我相信大部分人初次接触SAP都会有这种感觉。项目中我主要涉及的是BASIS和开发方面的，随着项目里不断的发现问题、查阅文档、解决问题的过程，我感觉到SAP系统的博大与精深（这是让人肃然起敬的），毕竟SAP不是徒有虚名的。与此同时我也感觉到SAP封闭的技术路线带来的问题。

SAP项目耗资源于几方面：软件本身和每年的维护费昂贵；硬件投资昂贵；SAP顾问人员成本高。由于门槛高、培训费用昂贵还有SAP技术的封闭，造成人员稀缺，抬高了顾问成本。

SAP软件精华不在于其技术（老实说，SAP所采用的技术都不算是先进的，他们的策略一定是要求稳定的，成熟的）实现，而是其中蕴含的众多行业和客户的成功管理流程和管理思想。如果在SAP实施中客户不接受这些流程，而系统又无法通过配置来满足客户需求时，矛盾应该如何解决？定制开发的风险和难度该如何规避？SAP所提供的有限的增强开发接口（User Exit，BAdi）是远远满足不了用户的“自动化”需求的，而完全定制开发的功能要去和SAP标准程序、标准表去统一融合也是非常有限的。这些疑问都会成为我下阶段探寻的重点课题。

SAP项目里顾问角色的搭配和合作关系。我接触的SAP外部业务顾问大多是没有技术背景或很少的，我认为这也是目前我们项目里重大的问题。没有技术背景的顾问提出的解决方案只能是SAP本身提供的（可以通过配置完成的）业务解决方案（当然还有两个前提：一是如果确实可能；二是顾问是experienced顾问），而一旦要涉及通过开发完成的solution，可以说大部分顾问的solution就变得no sense。这个时候，他们的作用是仅仅把客户的需求重新描述一遍就让技术ABAP顾问去完成吗？方案的可行性论证吗？方案的局限性、前提条件谁来定义？诚然，开发顾问需要了解业务模块，但是是限于对该模块的表和关联关系的了解，ABAP顾问不可能指导业务顾问去提出solution的，如果这样ABAP顾问的待遇会低于模块顾问吗？不懂技术实现的业务顾问能是qualified的顾问吗？

项目经理的角色是推动项目良好有序前进的关键。按照ASAP的实施方法论，在各个check point是需要严格把控的。check point不通过，必须纠正，永远不要把问题带入下阶段，实时的监控和调整人员和计划。再有就是接口确定在前，模块之间的接口一定要尽早确定，接口的调整给项目带来的effort总是很大的，所以在全局上一定要对模块间interface定义清楚，而且尽早为好。

随笔随语。