值得深思的一个问题:是否要Say No

显示全部楼层 · 2007-10-20 08:38:44

今天看见一位MM很有见地的说法:
最初由瓷骨MM 发布
[B]这在其他ERP里面都是很easy的基本功能,居然在 SBO里面还要自己开发???? 太悲哀了.明天人家说了, 采购员也要这个功能, 你又得变,销售员按部门看订单和产品,你又要变代码 , 权限的需求是近乎无穷的.
这样到底有多大的意义???各位有深思过么???? [/B]
技术人员有很浓厚的“大侠”气质，他们有很强大的实力，而且通常喜欢独来独往等等。
通常技术人员最大的满足感在于通过自己高强的“武功”，帮助“弱小而无助”的业务人员或者项目经理解决工作中的大难题。
我认为这里是有误区的，尤其是在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，这是一个问题。
---------------------------------------

千问 · 2007-10-20 08:38:44

那开发在BONE中站什么样的角色呢？

千问 · 2007-10-20 08:38:44

Link 的见解发人深思。SBO的研发只是顾问后面的最后一道屏障，不到万不得已，最好不要使用。我建议顾问在项目咨询的过程中要把握住研发的度。

千问 · 2007-10-20 08:38:44

刚干这一行没多久,但是看到楼主说的一番话很受益,公司有个项目就是因为加了很多的ADDON,不仅系统速度变慢,而且一开始到现在搞了六七个月了还没有搞完,有需求是好事,但太多的需求未必.
还是要抓住核心,只要核心功能实现了,这个项目可以说成功了.

千问 · 2007-10-20 08:38:44

“技术人员有很浓厚的“大侠”气质，他们有很强大的实力，而且通常喜欢独来独往等等”
喜欢独来独往的技术人员，不管是大侠还是XX侠，都不会很有实力的! 我信任团队的力量
任何优秀的产品都是综合因素的体现! 当然做一二个自定义报表，二三个存储过程及类似的，都不要产品之列!
真正有能力的独行侠，可以做做以下的产品化工作，哈哈
1、整个生产管理的任何问题
2、整个成本核算的任何问题
3、预算
4、流程控制

千问 · 2007-10-20 08:38:44

谢谢你说我很有见地.我还以为这里的帖子是没人思考的.原来还让我很欣慰,是有人能思考的.

我同意SayNo,但是我认为当客户交钱完了, 而且调研发现需求再说No, 已经晚了,根本代理商在开始代理合同的时候就该跟 SBOne说No,做 AOne 肯定有前途,但是BOne 根本就不该做.
估计这帖子要被锁了. 或者把我这话删除.
考验下这里的民主气氛吧.!!!!!!!!!!!!!!!!!!!!!!!!!!

千问 · 2007-10-20 08:38:44

最初由瓷骨MM 发布
[B]谢谢你说我很有见地.我还以为这里的帖子是没人思考的.原来还让我很欣慰,是有人能思考的.

我同意SayNo,但是我认为当客户交钱完了, 而且调研发现需求再说No, 已经晚了,根本代理商在开始代理合同的时候就该跟 SBOne说No,做 AOne 肯定有前途,但是BOne 根本就不该做.
估计这帖子要被锁了. 或者把我这话删除.
考验下这里的民主气氛吧.!!!!!!!!!!!!!!!!!!!!!!!!!! [/B]
我懂得你的意思,在Pre-Sales阶段就应该对项目范围有一个清醒的认识.
但是这是一个追求利益最大化的社会,社会基础几十年来已经发展到现在这样,如果反其道而行，岂不变成“反社会”了。。。
何况这里不仅仅考验Sales的良心，其实更主要的，还是考验其能力。这个故事里，能力还是占很大的比重。
因为象我上面说的，Say Yes固然有可能是忽悠客户，但Say No也可能只是自己懒惰不想动脑筋罢了。因此这不是简单的一个判断题。
因此做项目就好象打仗，一城一地的得失固然重要，但如果可以抓住最终的战略目标，不用动武甚至打点败仗都是没关系的。
而我们的战略目标，其实最后就是实现用户在管理上的改进或改变。但真正做到这点的几乎没有。。。ERP/BPR在中国通常用来做人事倾轧或面子工程的多一些。。
------------
MM后面说的话我觉得有点矫枉过正了，SBO并非一无是处，中小企业市场也并非都应该由AONE来取代SBO。尤其是，中小企业灵活多变的风格下，廉价的SBO会越来越有生命力。
这里有一个奥妙的地方就是，既然连R/3都未必能满足所有的管理需求，那SBO在功能上薄弱一些显然并不应该成为其致命的弱点。
系统只是一个工具，最关键的还是“人”，合适的人，在合适的时间，做合适的时期。这里系统只是辅助，没有决定性的作用。
我也说句矫枉过正的话：如果没有网络，单机也可以；如果计算机也没有，那可以找纸和笔；如果纸和笔都没有。。。。难道我就没办法做管理了么？
尤其是小企业，有时候改进管理可能只要一个汉堡也可以实现，这时候我想上ERP或者上KFC是没有多大区别吧。。。

千问 · 2007-10-20 08:38:44

最初由瓷骨MM 发布
[B]谢谢你说我很有见地.我还以为这里的帖子是没人思考的.原来还让我很欣慰,是有人能思考的.

我同意SayNo,但是我认为当客户交钱完了, 而且调研发现需求再说No, 已经晚了,根本代理商在开始代理合同的时候就该跟 SBOne说No,做 AOne 肯定有前途,但是BOne 根本就不该做.
估计这帖子要被锁了. 或者把我这话删除.
考验下这里的民主气氛吧.!!!!!!!!!!!!!!!!!!!!!!!!!! [/B]

首先，没人去表达、争议，并不代表没人思考!
Say No也好，Say Yes也好，代理商要量力而行!
项目失败了!跟产品的功能和模式有一定关系，
但关健还是在于代理商和sale对项目和自身能力有
一个相对科学的评估! 一味的说某种产品不行，
而不去考虑产品定位和适用模式是没有意义的
我承认茶叶蛋和原子弹不是一个数量级别!
但在“茶叶蛋”这个行业中，茶叶蛋做不好的，我想也一定会影响收入的

千问 · 2007-10-20 08:38:44

最初由 Link_ 发布
[B]
我懂得你的意思,在Pre-Sales阶段就应该对项目范围有一个清醒的认识.
但是这是一个追求利益最大化的社会,社会基础几十年来已经发展到现在这样,如果反其道而行，岂不变成“反社会”了。。。
。。。。。。。。。。。
尤其是小企业，有时候改进管理可能只要一个汉堡也可以实现，这时候我想上ERP或者上KFC是没有多大区别吧。。。 [/B]
如果项目单纯或一味的追求利益最大化，就没有必要讨论
是Say NO还是Say YES了!
Addon本身就是细分行业的完善，非要做成 B1+Addon = A1
也算是“强人所难”吧
SDK存在的意义是什么呢？细分行业的定制开发!
行业的需求是千奇百怪、千变万化的，B1没有宣称自己
包罗万像，也没有谁敢这样做，B1优秀的地方，就是它提供了
一个开放的平台，使它成为ERP实施的一个工具、一个基点，
通过其定制才可以将实际需求得以实现，企业和软件只有经过
不断的磨合，才能成为一个整体，
企业需要定制，B1也需要addon
SDK及相关软件模型应用正是B1优秀性的体现!

千问 · 2007-10-20 08:38:44

最初由 DaChu 发布
[B]
如果项目单纯或一味的追求利益最大化，就没有必要讨论
是Say NO还是Say YES了!
Addon本身就是细分行业的完善，非要做成 B1+Addon = A1
也算是“强人所难”吧
SDK存在的意义是什么呢？细分行业的定制开发!
行业的需求是千奇百怪、千变万化的，B1没有宣称自己
包罗万像，也没有谁敢这样做，B1优秀的地方，就是它提供了
一个开放的平台，使它成为ERP实施的一个工具、一个基点，
通过其定制才可以将实际需求得以实现，企业和软件只有经过
不断的磨合，才能成为一个整体，
企业需要定制，B1也需要addon
SDK及相关软件模型应用正是B1优秀性的体现! [/B]
原则上同意楼上的看法
但我依然认为，当一个系统功能缺失的时候,首先应该从管理角度入手，而尽量避免定制的情况出现.因为没有任何系统是十全十美的，工具是否改善不等于管理是否改善.
我这人喜欢举例子，
比如改装车可以更酷更漂亮百公里加速3.6秒.但我开原厂车，我并不认为上面那些改装能改善我上下班的交通问题.我宁可花时间研究一下新路线，改善一下驾驶习惯等等.但有些客户没有我这么理智,他们发现上下班耗费时间太长，于是请工程师改装以提高车速,因为这是最直观的。
再比如我有个弟弟，非常喜欢拉风耍酷,于是买了一部法拉利,和改装到很酷很炫百公里加速3.6秒的马6比起来,显然法拉利更适合他.即便法拉利也并不是完美的.但同样有的客户就有不同想法，他们认为马6改装余地更大,可以更好地满足"未来"的改装需求(毕竟需求一直在提升吗)，比如加个翅膀之类的,而法拉利以后改起来比较贵....
我想这个例子可以很好地阐述我对于定制的看法.
需求决定产品.
而一个产品是否优秀，取决于曾经面临过多少需求.
只面临过一次需求且尚未实现的定制产品，与面临了上千次需求(或经验积累)的成熟产品相比,显然风险大的太多.
----------------------------------------------------------------------
这里涉及到对SDK的定位问题.
假设我现在有2个系统,
一个叫SBO,
一个假装叫OBS(下面还会用到这个名字),
它们负责不同的业务.
现在我需要这2个系统的数据可以共享,于是我就收集数据结构,编写了一套数据传输的接口,并封装了起来.这个东西，就是DI.
现在我又希望这2个系统的窗体颜色，按钮风格等可以比较相似，于是我做了一套控件"皮肤",并封装了起来。这个东西，就是UI.
一套单向的数据传输接口,一套封装的控件皮肤，这个东西,叫做SDK.
这时候,真正在业务中工作的不是SDK,而是SBO和OBS这2个系统.
于是应该清醒地认识到，SDK对于你的解决方案其实并没有什么意义.所谓企业定制,根本和什么SDK无关，定制是在那个OBS系统上实现的.
那个OBS系统,就是传说中的AddOn,去掉界面皮肤，根本就和SDK没什么关系,完全来自于另外一个独立的开发项目.通常是.net..
(当然,我们还发现SDK不是我自己做的，是SAP做的，SAP为了保护自己的数据，DI和UI增加了许多限制.针对定制的限制.)
--------------------------------------------------------------------------------
于是项目经理或售前顾问或客户本身的课题是:
是否有一个开发团队，是否有能力,在SDK限制之下,在一定的成本范围内,通过一个额外的.NET开发项目来满足客户的定制需求.
结合开发项目的各种问题，以及SBO的实施成本来看,我个人认为，AddOn/SDK的应用，应该以不超过DTW的应用水平为宜.SDK用的比DTW还多的时候...基本上就要开始头痛了
因为出身关系,SDK与DTW貌似不相干的东西其实有颇多相似性.......