今天看见一位MM很有见地的说法:
QUOTE:
最初由 瓷骨MM 发布
这在其他ERP里面都是很easy的基本功能, 居然在 SBO里面还要自己开发 ???? 太悲哀了. 明天人家说了, 采购员也要这个功能, 你又得变, 销售员按部门看 订单和 产品,你 又要变代码 , 权限的 需求是 近乎 无穷的.
这样到底有多大的意义??? 各位有深思过么????
技术人员有很浓厚的“大侠”气质，他们有很强大的实力，而且通常喜欢独来独往等等。
通常技术人员最大的满足感在于通过自己高强的“武功”，帮助“弱小而无助”的业务人员或者项目经理解决工作中的大难题。
我认为这里是有误区的，尤其是在ERP项目上，大侠可以解决眼前问题，但并不能真正解决项目问题。
在ERP项目上，Say No是很重要的一点。哪怕这未必是Mission Impossible，但还是要一开始就Say No。
而在技术的世界里，Say No却是无能的体现。
这经常会和项目管理起冲突。我们知道项目管理最终是项目完成，而不是项目完美，必定需要有很多Say No的地方。
古人云：良将者，无赫赫之功。很形象地说明这个问题。战争的目的是胜利，而不是积累军功。项目成败取决于是否达成目标，而不是解决了多少客户需求。。卖了多少AddOn。。花了多少钱。。。。。
----------------------------------------------
尤其是SBO，SAP很狡猾地提供了一个完全开放到底层表的透明架构，同时提供了保护性很强的SDK工具，因此SBO系统是一个可以任人打扮的小姑娘，挂着SAP LOGO之下，是一个可以几乎任意定制开发任何需求的系统。
一方面，这可以帮助许多项目顺利推进；
但是也要看到，这其中很可能隐含着容易被忽视的风险：管理需求永远不是通过技术手段可以实现的。
开发达人不等于项目经理，更不能替代企业管理。这是一句废话，但很多时候都会在“大侠”神奇的光环之下，使大家忘记了这一点。
上面MM举的例子就很说明问题，SBO没有销售员权限过滤，我们可以创建一个完美的AddOn实现这个功能。那接下来采购员呢？按部门和产品类别呢？这一类的需求是无穷的。
在这时候，大侠的成功对项目可能是有害的。为什么这样说呢？
就以这个例子来说，我们现在实现了销售员权限功能，客户提出其他需求的时候，我们该怎么应对？
从技术上说，在之前成功的基础上，解决方案的原理是类似的，开发实施成本更小，做还是不做？似乎没理由不做。行，做。
然后客户继续提出类似需求，我们的大侠继续做。。。。。
一个，两个，这都不是问题。
但十个，二十个。。。积累下来以后，就会发现眼前的是一个庞大复杂的，定制僵化的，价格昂贵而且难以维护的系统。
而此时再想逃出来，恐怕没有那么容易了吧。。。
（我不是要影射R/3，毕竟我要到甲骨文去领津贴人家也是一脚踢出来。。。）
注意，我这里说的还只是特别经验丰富工作认真细致重视测试的技术人员。而大多数情况下，我们还需要为新开发的模块不断出现的BUG做斗争！这更是要命的。
Windows做了十几年都不断地有一堆漏洞，工作2-3年的同学独立熬夜一星期开发出的模块直接可以在商务业务里使用而不出BUG？天方夜谭。。。
----------------------------------------------
Say No 是在挑战技术人员的自尊心，但同时也可能助长每个人都可能有的惰性。如何在其中取得平衡？
其实最后还是得把板子打在项目经理的屁股上。
或者说，技术人员多多了解项目管理思想也是很重要的。尽量让项目问题按项目管理解决，技术问题通过技术解决。（基督说：恺撒的还给恺撒，神的还给神）
资深的项目经理能协调开发项目，但未必能解决技术问题；资深的技术人员能解决客户需求，但未必对项目有益。
但是在一些面子，甚至绩效考核的压力下，以及现在SBO顾问（PM）的项目经验。。未必比资深的开发技术人员要强。。。。真正能按照项目管理来做其实并不容易。
---------------------------------------------
当然，我们也可以说，AddOn开发是收钱的，为公司/个人带来了实际利益，客户（之前提出的）需求也得到了满足，那么双赢的局面，客户都没有反对，你现在倒跳出来说这是有害的，简直是荒谬。
其实，这要看客户在上这个项目时，究竟“项目目标”定的是什么。项目管理无非是按成本范围内实现项目目标就算阿弥陀佛。但我们很多项目其实是做到哪算哪，事后再来核算。。。。届时想抽回来也没办法了，只好推倒重来。
额外的SDK开发是可以创造利润这不假，但是当客户最后终于发现，他投入了过多的成本，获得的系统是永远都无法彻底满足需求，而维护成本和难度却越来越高，这时候，他肯定会重新审视和这家服务公司的战略合作关系。更不必说如果开发的东西里BUG很多的话，这是在给自己制造麻烦。
当然我们也可以说SBO小项目短平快做一票捞够了钱就走，SBO卖40万，AddOn卖出60万，就是值得庆祝的好项目。那我只能说，多出一堆在系统中苦不堪言的用户，这对整个行业未必有什么好处。
不过这也跟社会大环境有关，你去店里请服务员介绍个好菜，他说吃条鱼吧，那不是最贵的，就是最卖不出去要坏掉的，“企业追求利润最大化”。。。。这就扯远了。。。。
-------------------------------------------
把话题拉回来，我认为SBO有以下一些客户肯定会提出的需求,而技术人员除非重新创建一个系统,否则是不应该轻易拿技术手段去碰的：
1、整个生产管理的任何问题
2、整个成本核算的任何问题
3、预算
4、流程控制
5、。。。。
这些需求可能客户一开始描述时是十分简单的而有诱惑力的，我假装举个例子：
我现在只需要有个表让我记录未来一段时期的预算（或预测）就可以了，然后可以按月按季度查询就行。我给你5W块钱。
简单，写个需求变更申请单，花一星期收他5W块开发完毕。
然后不出一星期他肯定说，我们合作愉快，你开发的东西真好用,能不能再加个功能，当科目余额超过预算的时候不让他保存日记帐？应该很简单吧，大不了我再给你们公司签1W块钱。
也简单，日记帐分录约束连接自定义表，5分钟搞定收他1W块。
再然后他在未来的一年里又说：
我一样做预算，总要分成本中心吧？简单(?)
按照额度提出警报行不？简单
领导特批放行可以吗？简单
我预算频繁能按照以前的经验出预算建议吗？简单
导入可以吗？简单
总不能做了一堆没有报表给老板看吧，查询分析预算与实际YTD的比较可以有吗？简单。。。
这些都是我自己凭空想到的最最基本的需求，剩下还有许多更恶心的需求。。构建和谐社会我就不说了
但这些需求，在技术上，都是可以“轻松”实现的，都能做完，也能收点钱。。。。
但当你在技术上把这些都实现（并且还可能是断断续续象补丁一样实现的）以后，你再看这家人家的SBO系统。。。即使这位大侠新开发的模块从没有出过什么BUG，哪天你不做了，换个人来维护看看。。。。。
我们把时间回到客户第一次提出需求的时候再看。。。。。Yes 还是 No，这是一个问题。
---------------------------------------
