由于工作的原因，5年以来笔者认识了许多CIO并成为了朋友。回顾笔者和他们认识的过程，几乎都源于OA选型，这个过程中，笔者注意到一个有趣的现象：越是大型或特大型企业的CIO，在OA项目选型时越是谨慎。

在与这些信心十足的CIO的沟通中，笔者发现由于种种原因，与这些CIO们对于OA项目的哲学层面的本质很少有深入的思考，大多过于从技术角度的眼光去关注具体的功能或应用。同时，在众多厂商关于OA的宣传册或者标书中，很多只是提供了根据自己理解的需求拼凑出来的功能特征细节要求，而组织发展的具体战略与OA之间的关系、从管理角度对OA的要求等连只言片语都没有。

　第六问：如何认识产品和项目对自己的意义

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

　　先认识一下产品：

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

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

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

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

　　再看看项目：

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

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

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

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

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

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

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

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

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

　　由于项目的个性，实际上持续服务是不可能的。我曾经和一个CIO开玩笑，当他宣称必须完全满足需求的时候，我说，你只能选项目。另外一个问题是你有宗教信仰吗? 他说他是党员。我回答说:你最好选择一个宗教，管他是佛教还是基督教，重要的是你要养成每天祷告的习惯，你要学会相信老天和神灵保佑你这些事情：项目文档不要在2年后丢失、供应商项目经理不要离职、不要跳槽、不要考研究生、不要出国、不要开车超速出车祸或者游泳淹死……这些情况中任何一种发生，都将导致你不能享受到以前的服务水平;你不能期望一个对你项目代码、构架需求毫不了解的家伙能够给你高质量服务。

　　呵呵，想到这一切的可能性，他差点当即晕倒。

　　反观产品，如此众多的客户不仅使得产品经受了个体完全无法达成的覆盖性测试，这些测试中的bug反馈和需求反馈又进一步导致了产品加速完善。最重要的是使得我们的客服能够形成版本知识库，有了这样的知识库，我们几乎能够回答90%稀奇古怪的问题——其中大部分是IT环境问题(病毒、插件、IE版本、补丁没有打之类的)，而且并不因个体人员的变动导致服务质量下降。致远的客服不仅在积累知识，而且在学习和研究不同阶段客户的应用特点，早已经从被动客服(出了问题找客服)上升到了主动式客服。我们知道新客户会遇到什么问题，在应用深化时能够给客户来自其他客户应用的经验参考，我们的主动式客服月刊就体现了这一点。总之产品化让我们见多识广，知识库让我们专业化，众多的客户经验让我们从解决问题型上升到专家指导型。

　　这几年来，约有15%的A6客户是废弃了原先的OA重新购买了A6，这是因为过去的OA的项目化导致了项目发育停滞——我常告诉客户，项目化的验收之日就是OA成长的死亡之日，只不过要1-2年才显露出来.供应商撤离，客户PM转移到其他项目，对OA项目来说，无异于根须死亡，树叶发黄凋零是迟早的事情。

　　产品化是中国大部分客户能接受的长期发展保障机制，项目化要想长期保障，太贵了，你想想你是否玩得起!