经常有用户向我提出这样的问题：

对于用户来说，定制化开发带来的好处是否足以抵销其负面因素呢？比如开发风险，不能象通用产品随着市场的前进而自然的upgrade。用户组织生产流程是否应该着重于围绕市场上现有产品进行组织呢？

这个问题困难在于因为个案不同，你很难给出一个准确的回答，而且即使你能列尽定制化开发的好处，但你却既无法否定它的负面影响，也难以证实：只通过集成或主要通过集成市面现有软件不能满足用户的大部分需求。

美国的稍微大一点的公司是从不做定制化开发的，而欧洲和亚洲的一些公司却愿意做，是什么造成这种不同呢？从理论上说，定制化开发很难长期做下去，因为不合算，也不好做大。但现实情况是你经常不得不用定制化开发吸引客户。

我们经常说，这是一个定制化的时代，但当大规模定制生产尚遥不可及的时候，如何保障客户的长期利益。避免因产品缺乏标准以及公司缺少长远目标而给用户带来的潜在转移成本。如何使用户能在集成现有产品和寻找开发商定制开发之间做出合理的选择？

希望大家讨论。

　

现在操作系统很少自己做了，关系数据库也很少自己做了，像目录服务、消息服务这样的也集成在App Server这样的中间件产品中了，接下来可能还有通用的行业应用框架，最上面一层是每个企业特殊的应用。

不能说定制没有前途，系统集成总是要有人做的。而且对做的人要求还不低。

至于有的公司只做产品不接项目，那是公司定位问题。

给企业信息化提供的一个解决方案，在做需求时就要考虑是否有一些COTS（commercial off-the-shelf）解决方案可以用，适用性和费用如何。SEI对此有专门的研究。对于长期使用的企业系统，应该将以后的升级维护成本也算在内。基于框架和组件的开发也有相当的市场。

信息系统的开发商与客户也应该形成一个双赢的关系，只有保证了客户的利益，才有开发商长远的利益。

新项目开发的新代码量可能少，但这不表示定制的工作量少。就算全部使用商用软件，也需要事先了解客户的需求。

你说的很有道理，我十分同意你的观点。

关于企业信息化方面可以给推荐几个网站吗？

信息管理（Information Management） 中国社会科学出版社

很多IT人员一直把太多的注意力放在了技术上。实际上，信息和知识才是问题的关键。对于所有与信息相关的人员来说，这本书是值得一读的。特别是在我发现信息与知识的不对称造成的巨大力量之后。我认为所有的人都应该好好研究一下信息问题。而且我发现中国农民正在靠知识和信息来改变处境。

第一次在季风书苑看到这本书，不太想买。它是由《金融时报》和一些世界顶尖的国际商学院联合编写的教程。封面上写着“信息管理领域最全面的MBA指南”。现在看到“MBA指南”之类，就有一种千万别上当的警觉。

再次拿起时忽然动了买的念头。因为它是由很多不同的人写的文章组成的，所以必然会有不同的视角和重点，也会有不同的实例。仅从增广见闻的角度来看，也是值得买的。

回来看了以后果然没有失望，书中不乏精到的见解。我和朋友开玩笑说，这是一本讲CIO、CKO怎么做的书。CIO怎么做呢？第一阶段的任务是构建企业信息基础设施；第二阶段是为企业决策层提供做决策所需的信息；第三阶段是教育企业员工主动地发布、利用和处理信息。这三步是有重叠的，难度是递增的。每个企业都是信息企业，优劣在于信息运用的水平。

 我觉得还是定制开发好！
　

---

不是昧良心。不同企业有不同企业的具体情况，是没有一个东西可以一竿子全收的。企业需要信息系统是用于改善企业管理、提高企业效率、改进企业流程，以期在信息系统生命周期之内获得远远超于信息系统投入的价值。
在假定定制的信息系统能够达到最佳效果的前提下，定制所产生的经济效益是远远大于通用系统的。至于现在很多系统投入感觉是浪费，其实就是实现的系统和最佳效果的目标系统的差距过大造成的。
软件技术不断发展以及我们的不懈研究和努力，就是为了缩小这个差距。

阴在阳之内，不在阳之对。

通用系统在定制系统考虑之内，不在定制系统考虑之对。不需要对立起来考虑。

当你使用了windows，weblogic，基至SAP这样的通用系统时，你也是在上面做定制开发。哪些部分使用通用系统，哪些部分由自己来定制，是系统分析员、架构设计师要考虑的问题。

航空航天系统通过使用一些标准商用零件，节省了相当的费用。

记得XP那个起源项目吗？，为克莱斯勒开发薪资系统，这应该算是为大公司做的定制系统吧？
其实越是大公司，越对定制系统有需求，因为他们的系统往往更复杂，有更多独特的需求，而这些需求是现成的产品难以满足的。
在定制开发和现成软件之间并没有明确的界限。SAP也是需要“客户化”的，其实就是根据用户需求做定制化的二次开发，在有些大客户中，这些二次开发的量还非常大。
定制化开发常常只有一个原因：没有现成产品能满足需求。
集成现有产品的风险在于：能不能很好的集成，市场上能提供的产品是否具有很好的可集成性？集成部件之间的缝隙如何填补？不同供应商的产品集成时带来的复杂性，并由此带来的潜在风险。
定制还是购买，这是需要权衡各种风险、利弊才能做出的选择。越是大公司，定制和购买混合的可能性越大。
定制和购买，都将是长期存在的信息系统建设模式。

你说的对，我忘记了是有一些上亿美元的项目是定制开发，比如IBM给CNN做的那个，还有给美国空中交通管制做的那个（几十亿，做了10年，以失败告终）。我那样说主要是因为我接触的一些美国人或公司，他们不愿意做单独的定制开发。所以我的说法比较片面。

关于定制开发的优点我也同意你的看法，关键是难以把握度，尤其你是决策者或支持某项决策，就会总有人出来质疑你的决策，而开发与集成是两个不同的领域，很少有人能同时是两个领域的专家，所以我想向大家学习学习。

从需求文档开始的完全的定制开发也面临着与其它系统集成的问题，系统集成也会有开发一些部件、模块填补集成缝隙的需求。而且开发和集成需要的知识方面有什么很大的区别吗？

再就美国的“定制或购买”的问题说几句。
从接触到的一些零星资料看，即使在美国，软件定制开发也是一个很大的市场，在很多软件开发过程和方法的资料中，举的例子也常常是软件定制开发项目。但从事这些业务的公司是不会在中国做广告和宣传的，因为这不是他们的市场，所以有时我们会忽略他们的存在。

　

 步履蹒跚的中小软件企业
　

---

软件产品，定制还是通用？这个问题经常纠缠于软件企业中，尤其是无行业品牌的中小软件公司，国内的中小软件公司最典型的模式可能是这样的：几个技术牛人，一定的风险投资，一定的行业项目关系和背景，一个或几个可以养活十几个人的项目。所以在这种情况下作出来的软件大多数都是以定制为目标的，原因很简单，大订单就那么一两担，开发定制软件不仅经济效益颇丰，还可以帮助深入该行业。但很快问题就出现了，奶酪即将吃完了，市场等待自己拓展，这时需要面对的是形形色色的客户群，彼此之间几乎没有信任关系，很显然，沿用定制模式生产软件成本高的夸张（即使是不同定制软件中好多模块可以重用），一年也完成不了几个项目，最糟糕是项目延期、质量下降、信誉受损、现金流紧张，等等。既便是定制让企业疲惫不堪，但为了讨好客户、稳住市场，又不得不这样去做。
怎样才能兼得鱼与熊掌呢？我的想法是不妨借鉴其它行业的一些做法，比如DELL的PC产品，它的PC定制很值得思考，为什么DELL不会被千万种客户的要求拖入泥潭，却能够驾熟就轻，因为DELL有一种能力、一种体系可以保障定制带来的成本上升被有效控制，他的设计、生产、配送体系是保证这种能力的根本，也就是说，这种由定制产生的成本只占到整个PC成本的极小部分。同样的道理，如果我们的软件公司努力通过各种方法达到降低定制成本的话，就可以即满足不同客户的需要，又不会让企业超负荷运转，这些方法可能是通用软件实体+定制升级模块，可能是通用软件体系+定制软件产品，因企业团队不同而不同吧。

DELL的定制中，主板不能选择，显卡和声卡种类有限，硬盘厂商有限。
DELL是集中资源在20%的定制范围上满足80%的客户。不能放弃那些需要大幅度增加定制难度的20%客户，就不会有DELL的成功。
当然，我们的目标是要做天下第一优秀产品，所以永远不会有成品。

备左则右寡，备右则左寡。无所不备则无所不寡。

对于定制开发而言，你需要熟悉软件开发方面的知识，开发周期与成本的估算，团队的组织，可能的技术风险等等，而集成需要的是你对某一领域及其相关领域产品的熟悉程度，这些产品如何使用，如何协同工作，各自的价格是多少，同类产品如何搭配选择以发挥最大效率等等，也就是说需要产品方面的知识。虽然二者都需要做需求，但也还是有细微的不同，完全的定制开发更侧重于需求导向，而集成在需求导向的前提下，更侧重于方案的推销，另外也存在第三种混合型的，即已有较为成熟的产品，以集成自己产品为主，而作少量定制开发的，这种也是在需求导向的前提下，侧重于方案的推销。所以，你很少会看到一个公司的方案经理或产品经理和开发经理或系统分析员是一个人的，就是因为知识背景，价值取向都不同的原因。

在平衡金钱成本，运用开始时间，培训成本和时间，回报期间等等之后

我在三年前在我们公司提出此种有望走向软件大规模定制的开发模式，包括具体的组织形式和方法，也获得管理层的肯定，但最终因投入太大而放弃。

定制化开发对目前的国内企业来说仍然是一个最好的选择.
在整体这么低的信息化普及基础来说, 期望 "用户组织生产流程是否应该着重 于围绕市场上现有产品进行组织呢？" 是不现实的. 信息化在大多数企业中目前并不是最决定性的因素,
怎么可以让用户围绕信息产品组织? 要知道这个成本是无比高昂的. 炒得很热的 ERP 的全面失败
非常准确地反映了"企图教育用户该怎么做" 与用户企业的思考操作方式之间的巨大差异.
　

 回复: 最大的价值回报未必最佳
　

---

在平衡金钱成本，运用开始时间，培训成本和时间，回报期间 等都是衡量一个系统价值的要素。

必须看到很多企业是受了流行的影响而跟风的.在如今 BPR/ERP 炒得这么热的情况下这是不可避免的, 特别是在中国, 连红茶菌都能全民大流行的地方.. 呵呵.

过滤掉这些之后, 对于那些认为自己需要改进的企业...首先它必须能认识到信息化能带给它什么, 这一点不是由软件公司来做的, 而必须由企业自身认识到. 信息化始终只是工具而已. 或许一个人看到一样工具能想起来, 这个工具能够把家里的煤气灶修好, 作为工具, 则最多告诉人我能修煤气灶, 它无从知道这个人家里是否需要修煤气灶. ..

再过滤掉这些, 剩下的就是真正需要的了, OK. 这时已经有了前提, 企业已经知道信息化能带给它什么, 这个不是笼统的而应该是细节的. 是否跟着市场流行的软件走还是需要针对自己的特殊情况定制也应该由企业决定, 毕竟只有适合的才是最好的, 不适合的盲目跟从只能 crash. (嘿嘿, 现状是企业的情况各个不同). 然后就是开发 + 实施. 在这个过程中, 一步一步来永远比彻底推翻重来要好要有更多成功的可能

若干年前，看Netscape Navigator的版权声明中就可以看到它用了多少第三方的软件和技术。

今天再看看象JBuilder这样的产品，Tomcat也被它打包在里面。

今天的产品和今天的系统集成项目，早就抛弃了“Not Invented Here”的偏见，软件生产已经国际化，只有运用全世界的优秀产品，才能做出自己的优秀产品。

上次看到一篇文章介绍航空工业的并行工程，讲到空客的散布各国的超过1500家零件供应商。后来听到一个新闻说10架波音有7架的尾巴是中国生产的，感觉好象还很得意。

还有一些人追求国产化率多少，还有人要开发自主产权的操作系统。

从本质上，用户需要的是满足自己需求的系统。至于系统是从头定制还是简单集成只是一个成本的选择问题。
可以告诉用户某几项需求导致系统只能从头定制，将增加用户多少成本和时间。也可以告诉用户如果改变某几项需求，就可以直接利用某个成熟产品集成，可以减少多少开支。但最终用户的选择，用户对自己需求的重要度的判断，甚至用户是不是真的清楚自己的需求，比任何技术和管理因素对项目成败的影响更大，更有决定性。尤其是对失败的项目而言。而这是开发公司无力干涉的。

没有完成任务，赔款条款能否被执行。
一般说来，即便是现成产品，也有一些用户的定制化设定。通常用户为了适应现成产品的设计，也会放弃一些原有需求。
问题就是如果集成环境没有设定好该怎么办，用户放弃的需求是真的无足轻重还是用户在不知不觉中把整个系统的价值点放弃了。
成本，风险，回报的考虑和取舍应该是商务上的考虑。

一般赔款条款不会被真正执行，客户一般不愿意与供应商搞僵，因为到了这时候那个供应商已经是收拾烂摊子的唯一希望了。：）

但社会现实层面的问题在技术层面是无法讨论的。
理论上，如果有足够的能量，利用那些不可能完成的任务骗开发商的赔款是可能的。
不是据说在外贸上，我们有不少公司受害吗

全部标准化不太可能，就现实意义上讲，大家做系统软件不也都是传统模式改改，别人的软件抄抄（这个词不太好，不过也就是这样了），能这样做就是因为业务系统模型中有可以标准化的东西。
其实我想说得倒不一定是硬要将模写无法标准化的东西标准化来减少灵活性，增加成本。举DELL的例子，是想软件行业应该拓宽思路，不要总是自命清高，其实软件这个80年代才兴起的行业，又很多东西是需要想传统行业学习的。软件的标准化程度不高，比复杂的问题还有很多，但不能总是因噎废食，裹足不前吧。
光把解决问题的行动浪费在争论上，不敢尝试，这几年我是吃够了亏。
　

所以说，现在要有一些暂时性的解决办法，其实很多行业的标准模型已经有了，或者差不多完备了，即使推出这种通用+定制的软件产品概念，无论对研发还是对市场都是有好处的。
总不能等off shelf组件完成了，再开始吧。

希望中国的中小软件企业能够及时找到自己的发展道路

俺只是举想举一个例子，IBM。
IBM推崇的电子商务，到最后都是要为最终用户做定制的。
比如，IBM给通用做系统，通用就是客户，通用根本就不要市场上现有的东西，因为不符合他们的业务流程，所以要IBM为他们度身定做。再比如，IBM接到国内好多中小城市的银行项目，这些项目也是为中国的银行度身定做的，因为中国的银行与国外的银行业务完全不同，要中国的银行把业务改掉，根本是不可能的。

实现客户需求有以下方案
1，组织定制化开发，从需求分析，设计到开发测试。时间长，成本高，开发风险大。但能完全满足客户需求
2，利用现成产品做某些定制化设定。时间短，成本低。客户需要放弃某些原来的需求。开发风险变成了产品性能风险。产品是现成的，开发商对性能改进余地不大。客户为了适应该产品需要放弃的需求中有无关键需求也是需求风险。

客户综合成本，需求等因素决定采用何种方案。如果一开始就没有足够的信息。导致客户以为集成现成产品更好，结果最后发现某项关键需求不能完成，必须更换产品或是定制开发，我想如果对现成产品不熟，风险不见得比定制开发风险小。当然，如果对产品已经了如指掌，确信绝对能满足用户需求，利用现成产品集成就是极为有利的。

于是关键就是对客户需求的掌握程度，对开发和产品的技术风险了解程度，提供信息给客户后，客户对成本和需求的平衡取舍，具体采用何种方案还是一个商业决策，不是技术决策。如果客户全权委托，开发商就要冒用产品集成的收入做定制开发的风险。

定制是公司不容易做大，通用产品是竞争激烈。不存在谁必然有利的说法。根本的因素是客户肯用多少成本，打算获得多少回报。当客户预期回报1000万时，在乎的不是开发成本是100万还是20万，而是能不能确保1000万的预期成果。通常客户宁愿用100万换取1000万利润，也不会打算用20万换取500万以获得成本降低的效果。

不好意思，ibm是有名的靠服务赚钱的公司，它的每年的维护收费是非常高的，并不适合大多数公司的情况。何况在大型机市场，尤其在金融，保险，航空业他基本是垄断地位。

我那句论断有片面之嫌，下面已经解释过了，因为我们接触的通常是美国人即使不接你的单子他也不改他的软件，而同样规模的欧洲公司一上来就说我们给你定制。所以给我造成了一个“错误”的映像。

可惜，这种好事太少了。
用户只有不清晰的想象，开发商只有乱猜需求，用户今天确认一个需求，下个月就改的面目全非才是可悲的现实。
想象着没有见过的所谓完善的印度，美国，日本开发模式，于是拼命玩CMM，ISO等银弹。以为只要有银弹，必然能成功。这是更可悲的发展趋势。

为什么这么说呢？
现在说OOA之类的，就是要和客户打交道，要搞清客户的需求。
但是有一个问题，不同的客户的处理方法完全不一样，所以俺觉得软件的分析阶段，用什么分析，怎么分析，分析什么，反而不是很重要了。更重要的是你的客户是怎么考虑问题的，你怎么和他打交道？这是最主要的。当然，俺不是说要投其所好之类的，俺是说，知道客户是怎么样的人，定下自己处理分析阶段如何和客户打交道，才能够更顺利。
就这一点而言，美国，欧洲，亚洲，亚洲的新加坡，亚洲的日本，完全不同。