您的位置: 笔者从保障项目成功的角度归纳出9个问题。这9个问题涉及对OA的初步认知，也涉及对本质的探讨，希望与业界同仁共勉。
陷阱四：片面追求新技术
对新技术的片面性追求常常导致项目成为了项目负责人(特别是CIO)自娱自乐的畸形产物。探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性而言是高风险和高成本的。
技术先进性的价值不在于先进本身，而在于先进对扩展性、性能、安全性、集成性、易用性(常被CIO所忽视，其实对终端客户的影响排在第一位)等诸多应用的现实价值和升级成本的抑制。而且由于协同管理软件的价值并不仅仅依赖软件本身，其部署过程和应用推进能力也对其价值发挥起到至关重要的作用。我们绝不能忽视这样的现象：同样的软件在不同的单位对价值有截然不同的评估，所谓花巨资上马的大型软件成为摆设的情况比比皆是。
我们相信CIO对于软件的评估侧重应用和技术是理性的，但我们也同时注意到，CIO对于推动组织建立新型工作行为模式的艰巨性和挑战性的重视程度不够，常在对未来技术应用发展趋势的无限可能性的冥思苦想中忽略了组织与协调成本，导致系统实施成为踏入泥潭的第一步。
陷阱五：实施缺乏导向
实施被不少CIO理解为软件开放、安装调试、培训、测试、上线这一类的事务，但我们认为这不是实施，至少实施的目标错了，不是结束一个软件的部署过程，而是在这个过程中达成管理提升的目的。如果前面所说的工作是必需的过程，那么达成管理目标才是实施的结果。遗憾的是，极少有CIO在实施计划中明确地提出管理提升目标，最高的层次也就是具体枝节需求的满足。最理想的结果也就是安装了一套对大家没有价值感受的软件!
大部分客户把OA当成了一个阶段性项目，而没有意识到，如果能充分重视OA，它将成为一个强大的战略实施的支撑平台。
下篇：OA的成功实施
第六问：要产品还是要项目?
事实上，CIO在OA方面只能有三种选择，一是标准产品，二是个性化开发，三是产品+局部定制。信息化程度、管理成熟度不同的客户对OA的期望值是不同的，另外CIO的技术偏好会导致对需求的客观性认识不足。
1.产品化的优劣势
产品化从视觉上看到的是包装盒中的光盘、加密狗、印刷说明书(印刷品是批量的标志)、服务卡，但产品化实际上是一个复杂的商业系统，是由需求流程、概念设计、架构设计、程序代码、测试流程、销售、实施交付、售后服务、升级服务等多种岗位专业人员协作构成的。
产品化有产品化的好处，也有产品化的不足，好处是之前有无数用户验证了功能的适用性、性能、稳定性，并且可以持续升级，是成熟的象征，它是与客户的长期合作，如同婚姻。产品化还意味着高性价比，这是绝大部分客户所关注的。产品化总的来说是低风险的。
产品化是软件的一个发展趋势，因此不少厂商都在宣称自己的产品化，是否真的如此?其实识别办法很简单，可以通过该厂商的网站上识别。产品化供应商能看升级公告，没有版本升级公告的则属于“李鬼”。
产品化的不足是，不能一次满足所有细节需求，客户在选择时需要对需求有所舍弃，另外产品化的升级节奏与你需求的成长速度之间的匹配是个问题，这就需要你在产品化厂商中选择那些内部资源雄厚、流程顺畅、支撑保障机制健全的厂商。
2.项目化的优缺点
项目化的优势是为客户量身定做，但与此同时丧失了标准化升级的可能性，其关键在后者，而不是个性化代码的多少。
项目化是高成本的，首先技术人员比实施人员成本高，如果客户相信优质的程序员是价值昂贵的稀缺资源，客户就最好不要相信花1万元就能完成一个好项目;二是周期长的，短期赶出来的不可能没有问题，看看微软这么伟大的公司还有不少Bug呢，项目漫长的测试、优化周期造成了高成本;三是供应商的商业模式造成的，如果是项目型的厂商，只能尽可能通过每一个项目的价格最大化回报来挣钱，因为它们没有把握像产品化公司一样能够通过客户数量挣钱。
项目化是高风险的诱因之一。从需求分析开始，到技术路线选型、架构的扩展性设计考虑、优质高效的代码实现、完善的测试，所有这些环节，都需要客户和供应商双方投入最顶尖的人力资源，才足以做到业界一流水平。不幸的是，一个供应商只能有一两个顶尖项目经理，他不可能在每一个项目上投入，而客户方更是稀缺能够精通OA、具备战略思维、又能细致深入把握需求、协调实施的项目经理，这种人月薪身价都是在2万元人民币以上的。所以我们不难理解为什么有这么多OA的“烂”项目，很大程度上，就是二三流人员在瞎折腾。在前面提到的这些环节中任何一个失误都会让客户未来付出代价。
项目化最大的局限性是缺乏长期发展机制，如果没有每年配套的充足的预算，你怎么可能长期要求供应商持续研究、优化、升级?在技术日新月异的今天，没有最好的，只有更好的。
中国式项目化模式注重与客户的短期合作，急功近利的成分更大。
3.产品化+局部定制
比较了两种模式之后，客户无疑要做个决断，大部分客户会选产品化。有极少的客户选择项目化，但有一些客户还是期望在购买时获得承诺，满足产品化尚无法满足的个性化需求。这种情况下，导致了第三种模式的出现：产品化+局部定制。
“产品化+局部定制”仍然会导致两个结果，客户的需求如果产品架构可以支持，可以以扩展模块的方式满足，那么没有问题;如果产品化的技术架构不支持，客户的需求如果要满足，就只能以调整架构，牺牲升级来换取。以用友致远的A6为例，其架构最早根本不支持，现在开始逐步支持，逐步成体系，这是一个漫长的成长过程，需要漫长的实践积累才能保证软件接口的成熟度。
由于项目的个性，实际上持续服务是不可能的，反观产品，如此众多的客户不仅使得产品经受了个体完全无法达成的覆盖性测试，这些测试中的Bug反馈和需求反馈又进一步导致了产品加速完善。最重要的是使得客服能够形成版本知识库，有了这样的知识库，客服人员能够回答几乎90%稀奇古怪的问题——其中大部分是IT环境问题(病毒、插件、IE版本、补丁等)，而且并不会因人员的变动导致服务质量下降。总之，产品化让我们见多识广，知识库让我们专业化，众多的客户经验让我们从解决问题上升为专家指导。
笔者常告诉客户，项目化的验收之日就是OA的死亡之日，只不过要1～2年才显露出来，供应商撤离，客户项目经理转移到其他项目，对OA项目来说，无异于根须死亡，树叶发黄凋零是迟早的事情。
只有产品化才是中国大部分客户能接受的长期发展保障机制，项目化要想长期保障，太贵了，你要想想你是否玩得起!
