事实上，CIO在OA方面只能有三种选择，一是标准产品，二是个性化（项目化）开发，三是产品＋局部定制。信息化程度、管理成熟度不同的客户对OA的期望值是不同的，另外CIO的技术偏好会导致对需求的客观性不足。

先认识一下产品：

产品化的OA从视觉上看到的只是包装盒中的光盘、加密狗、印刷说明书（印刷品是批量的标志）、服务卡，但实际上它是一个复杂的商业系统，由需求流程、概念设计、构架设计、程序代码、测试流程、销售、实施交付、售后服务、升级服务等多种岗位专业人员协作构成的。

产品化有它的好处，也有它的不足。好处是意味着在你之前有无数用户验证了功能的适用性、性能的稳定性，并且还可以持续升级，是成熟的象征，是与客户的长期合作，如同婚姻。产品化还意味着高性价比，这是绝大部分客户所关注的。产品化总得来说是低风险的。

由于用友致远开创了OA的产品化格局，因此最近不少厂商都在宣称自己是产品化。有CIO为此困惑，问及我如何识别，我告诉他很简单，可以通过该厂商的网站来识别，产品化供应商能看到升级公告，没有版本升级公告的则属于李鬼。客户可以从致远的网站上的客服公告中看到我们是如何从2.1版花了近5年数万个人工日一步步走到今天的。

产品化的不足是，不能一次满足所有细节需求，客户在选择时需要对需求有所舍弃，另外产品化的升级节奏可能与你的需求的成长的速度之间的匹配是个问题，这就需要你在产品化厂商中选择那些内部资源雄厚，流程顺畅，支撑保障机制健全的厂商。

再看看项目：

项目是只有些代码是为客户量身定做，与此同时丧失了标准化升级的可能性的系统，其关键在后者而不是个性化代码的多少。

其实大部分项目化供应商都恨不得一行代码都不改就交付给另一个客户，但局限于上一个客户的个性化代码的存在，使得他们不得不吃下自己为满足一个客户的需求代来的苦果。

项目化是高成本的，首先技术人员比实施人员成本高，你们要告诫客户，如果优质的程序员是价值昂贵的稀缺资源，客户最好不要相信花1万元就能作出个好项目。二是长周期的，短期赶出来的，不可能没有问题，看看微软这么伟大的公司还有不少bug呢。项目漫长的测试、优化周期造成了高成本；三是供应商的商业模式造成的，如果是项目型的厂商，只能通过尽可能通过每一个项目的价格最大化回报来挣钱，因为他们没有把握像产品化公司一样通过客户数量挣钱。

项目化是高风险的，从需求分析开始，到技术路线选型、构架的扩展性设计考虑、优质高效的代码实现、完善的测试，所有这些环节，都需要客户和供应商双方投入最顶尖的人力资源，才足以做到业界一流水平，悲惨的是，这根本不可能大面积出现这种理想情况，一个供应商只能有一个顶尖项目经理，他不可能在每一个项目上投入，而客户方，更是稀缺能够精通OA，具备战略思维，又能细致深入把握需求、协调实施的PM（项目经理），这种人月薪身价都在2万以上的。所以我们不难理解为什么这么多OA的烂项目，说穿了，就是2-3流人员在瞎折腾。他们在我提到的这些环节中任何一个失误都会让客户未来付出代价。

项目化最大的局限性是长期发展机制，如果没有每年配套的充足的预算，你怎么可能长期要求供应商持续为你研究、优化、升级？在技术日新月异的今天，没有最好的，只有更好的。

中国式项目化是与客户的短期合作，是一夜情模式。

比较了两种模式之后，客户无疑要作个决断，大部分客户会选产品化。有极少的客户选择项目化，但有一些客户还是期望在购买时获得承诺满足产品化尚无法满足的个性化需求。这种情况下，导致了第三种模式的出现——产品化＋局部定制。

产品化＋局部定制仍然会导致两个结果，客户的需求如果产品构架可以支持以扩展模块的方式满足，那么万事大吉，如果产品化的技术构架不支持，客户的需求如果要满足，就只能以调整构架，牺牲升级来换取。A6的构架最早根本不支持，现在开始逐步支持到逐步成体系，这是一个漫长的接口的发育过程，需要漫长的实践积累才能保证接口的成熟度。

我也曾经多次遇到客户个性化需求的重压，提出如果不满足就不买或者不付余款之类的，我会客观地与研发评估其需求实现属于可升级型或不可升级型，成本有多大。如果属于可升级型，我会坦率提出版本升级或付费局部定制成本问题，如果属于不可升级型而用户又坚持要这个功能，我会告知用户我作的先决条件是客户签署一份“放弃升级的声明”。有意思的是，这种鱼和熊掌不可兼得的局面下，我们与所有的客户都达成了一致——部分版本升级满足、部分以不影响升级的局部定制满足，部分舍弃。从而保持了系统的可升级性，因为从长远看，升级所换来对全局性的价值远远多于局部的个性化满足所带来的价值。

1 2 下一页>>