如果想真正的成长，最好的途径莫过于成功地作过技术，读过实施模块的每一个USER GUIDE ，精通流程和系统设置的细节。

原先一直在Oracle EBS 肚子里面，只是觉得它设计得很精密，很复杂甚至是自找麻烦地存在着各种table ,view ,trigger, form ...当你面临着一个新的棘手的要实施的企业的时候，你又在千方百计地想ORACLE EBS里面到底有没有这个功能，也在想也许当初应该更耐心地把每个user guide读透，把EBS 每个设置弄明白。好像一个平地上的人仰望高山，并逐渐地接近它，逐渐地感受它的伟大。

最近见识了一个国内知名公司实施过的ORACLE ERP。因为界面是中文，开始就没有好感

我倒不是觉得英文更简单，只是界面语言设置为英文更习惯一些。因为我一直用过的一直都是英文界面。当然这是个小问题，呵呵。

头疼的是这个公司实施的时候竟然很多模块都是customize.如果是为了迎合用户的需求和所谓的流程而去把基本的module的模块客制化，麻烦

的不仅仅是TECHNICAL consultant. 也许我们technical consultant 只是开始的时候写form 接口等费尽心血，痛苦，真正麻烦的是用户和将来的升级 。

世界上没有静止的东西，企业应用也是。而参与企业应用的人最感到头疼的就是业务流程的改变，导致的结果往往是加班和成千上万的代码。

现在该说到ERP上面来了。ERP 是一个很大包涵各行业基本流程的企业应用计划，我们都知道，它不仅仅是一个应用软件，更重要的是要规划更

新企业新的业务流程，让这个流程更适合国际性企业的业务。而ERP 二次开发是站在巨人的肩膀上开发更适合的应用。如果客制化的东西多了，反而把流程变得很复杂，也许刚客制好的时候用得勉强，可是时间久了自然会有各种各样的问题和升级的麻烦。

所谓功能顾问，就是尽量把要实施的企业的流程改造成ERP流程，各行各业应用甚至是同行业不同企业厂别的应用也是不同，如果一味坚持企业的旧的繁琐的业务流程，那么客制化必然很多，而且ERP的也不能实施成功。当然我们可以去用JAVA 写个什么面向服务的SOA ，有新的需求再重新写吧？功能顾问的职责还在于不断接触自己的ERP软件，要很熟悉，非常精通，到底如何去改善流程，目前现有业务用ERP 能替代甚至是砍掉多少，如何指导开发人员合理地二次开发。

原先一直在Oracle EBS 肚子里面，只是觉得它设计得很精密，很复杂甚至是自找麻烦地存在着各种table ,view ,trigger, form ...当你面临着一个新的棘手的要实施的企业的时候，你又在千方百计地想ORACLE EBS里面到底有没有这个功能，也在想也许当初应该更耐心地把每个user guide读透，把EBS 每个设置弄明白。好像一个平地上的人仰望高山，并逐渐地接近它，逐渐地感受它的伟大。

学无止境，无论是technical 还是 founctional .做技术的也许更好一些，因为时刻用自己的代码体现理性。但技术更新很快，如果倦怠，那么很快自己就会过时。这时如果因为跟不上技术而去做功能，而同时又有对新事物的倦怠，那么泛泛地用粗糙的功能去实施，结果可想而知。

如果想真正的成长，最好的途径莫过于成功地作过技术，读过实施模块的每一个USER GUIDE ，精通流程和系统设置的细节。

因为自己是主要做技术的，所以有一定的局限性。即使不是如此，依然难免摆脱个人思想的局限。

如果你认为其中的一些观点是对的，请坚持和我一样的信念。