应用者角度谈谈SAP中的开发功能

企业中或多或少都会有一些在标准功能基础之外的开发功能。虽然开发也是基于SAP的一些技术标准和框架。但从应用和运维的角度来说，拉长时间，总会产生一些相对客观的看法。

综合来说，对于开发功能有以下一些应用体会：

一、在遇到问题时没有标准功能那么强大的消息系统；有时可能完全找不到线索。

二、在较为复杂或跨模块的开发功能中，解决问题基本是业务顾问和程序顾问合作的模式。如果是外部，还要去了解甲方的业务流程，分析程序说明书（前提是有程序说明书）。这导致即便只是一个很小的问题，解决起来也要花较大的代价，最终原因和解决方法倒可能并不复杂。

三、个性化的开发功能出现问题时，在解决方法上几乎没有参照和标准答案。很多用户习惯在技术平台，SAP社区及网络上找答案。但这种方法显然并不适用于开发功能。

四、开发的功能有适用性的问题。标准的东西可以是对岗位用户的硬性要求，比如EXCEL,PPT。但开发的不可能要求别人会，需要企业自行培训。并且对于从业者形不成价值和竞争力。不像MRP这样标准的东西，应用逻辑上，换个企业，差别不太。掌握了，算一项职业技能，具有通用性。

五、从ERP的系统版本升级和业务发展变化的角度，随着时间的推移，开发的功能可能会由于无法或难以产生相适应的变化，而面临尚失部分或全部功能。最终导致被弃用的结局。试想在ECC版本的开发功能，升级到S4上还能用吗？可能要重新开发或做出重大调整才行？

当然，上面所述是以终端用户视角来说，这个视角显得缺乏格局。如果你从一个企业决策者的角度，你不会希望你的业务被某个系统绑死，失去选择权和灵活性。甚至于很多集团性质的大型用户还有自己的开发团队。广泛的用户基础，良好的用户体验，兼容性，可扩展性本身也是一个优秀系统的评价标准。

最后总结一下结论或建议是：

企业在产生开发需求时，最好还是要进行专业的，全面的分析评估。避免事先缺乏全盘考虑，草率决策。最容易出现的问题就是程序解决了这个问题，但导致了另一个问题（也有可能是另一堆问题），顾此失彼，有时甚至得不偿失。这其实不是开发的问题，这是管理的问题。