1、九问 CIO针对 OA 的几个问题用友致远 张屹 2007-10 / 2008-05本来此文是一份用友致远内部与渠道代理伙伴交流客户对 OA 的认知的系列文章、以及部分发表在致远网站上的文章整理而成的，其中为了更加具体的说明问题或作为例证，我在不少地方使用了 A6 协同软件作为参照，并非出于对这些早已选择了 A6 产品作为事业的朋友进行推销的目的。在内部发布后，许多伙伴朋友鼓励我拿出来与更多的客户的 CIO 朋友分享，专业媒体和出版界的朋友听说后也向我约稿，于是我在原文的基础上略作整理以供抛砖引玉。即使在原文中，我也没有任何对特定指名的竞争友商的贬抑之辞，或者对非 J2EE 技术的偏见；另外在
2、项目化和产品化部分的观点，我是基于更多数的客户所具备的客观基础条件以及其所可能的选择而谈的，这并非否定项目化的社会化价值，也无损于 IBM、富士通这些以客户经营为导向的真正的项目化成功厂商的声誉，但我期望客户不要接受那些毫无持续客户保障能力的一夜情性质的短期功利性项目厂商，是他们损害了 OA 事业的发展。不过令人欣慰的是，越来越多的同业友商开始意识到这个问题，开始以自己适合的形式注重与客户的长期合作，谋求共赢。由于工作的原因，5 年以来我能经常和客户的 CIO 交流，通过他们，我学习到了很多东西，在对问题的探讨中，我与许多 CIO 成为了朋友，他们是一群特点相同的人，无论他们身处何地、无论行业
3、如何、无论其过去是做什么的，都有极强的学习能力，善于思考抽象而复杂的事物，忠于组织的战略目标，在权限、资源不足、领导重视不够的情况下，长期勤奋、努力地想把工作做好。我感到非常荣幸的是，他们把信任给了我，选用了我们的协同 OA 产品 A6，在共同的实践中，我们长期地保持着沟通，得到了许多对 OA 项目、协同软件的认知心得，我知道我的使命是将这些心得映射到产品的进化中，以功能和应用的形式回馈给这些支持我的朋友。回顾我和他们认识的过程，几乎都源于 OA 选型。这个过程中，我看到了有趣的现象：越是大型或特大型企业的 CIO，在 OA 项目选型的过程中，越是没有把握，越发表现得谨慎。他们不少人其实在 5
4、年前甚至 10 年前就开始推广 OA，但都不同程度地遭遇了挫折，而当时他们拥有充足的预算、健全的技术型项目组、优良的硬件环境，甚至有领导的支持和强制推广的政策保障。与之相反，越是年轻的CIO，单位小一些的 CIO，第一次选型 OA 的 CIO，倒是信心指数普遍超过更有经验的 CIO 们，但这些年轻的 CIO 们几乎都忽略了一个事实，仅仅在几年以前在他们任何一位所在单位方圆 5 公里内，都很难找到一家成功应用 OA 的可以参观学习的单位；在行业 CIO 峰会上，你也很难听到哪个 CIO 将其 OA 项目作为一个成功经验进行分享。难道 OA 是个不重要的应用领域吗？那么为什么每家似乎都在考虑上马？
5、在与这些信心十足的 CIO 的沟通中，我发现由于种种原因导致这些 CIO 们对于 OA 项目的哲学层面的本质很少有深入的思考，大多过于从技术角度的眼光去关注具体的功能或应用。更多时候在我看到的标书的技术标中全是从网络上下载各家厂商的白皮书、根据自己理解的需求拼凑而出的细节功能特征要求，而组织发展的具体战略与 OA 之间的关系、从管理角度对 OA 的要求连只言片语都没有，似乎这些功能要求足以暗示领导的管理意图，难道需求功能？功能管理？后来我明白，正是这种认知上的先天不足导致在中国过去的 15 年中，超过 10 万套上马的 OA 项目成为了毫无价值的摆设和 2-3 年即废弃的项目。限于篇幅，我们在
6、此将聚焦到 OA 项目的选型和实施的价值观和方法论层面，从保障项目成功的角度探讨 9 个问题。至于 OA 与管理思想、管理实践、管理者之间的关系，请参见拙作 致远为什么造A6？ 。A6 协同与传统 OA 的不同请参见A6 为什么能协同？ ，对于管理者关心的 OA 对组织管理方式的变革请见管理思想如何“落地”？ 针对 CIO 所关注的关乎项目成败的 9 个问题分别是：1. OA 的成功率有多高？ 2. OA 的本质是什么?3. OA 的挑战是什么？4. OA 的项目成功的要素是什么？5. CIO 的项目陷阱是什么？为什么？6. 如何认识项目和产品化对自己的意义？7. 如何进行 OA 的实施阶段规
7、划？8. 如何建设 OA 项目的长期发展机制？9. OA 成功的简单量化标准是什么？这 9 个问题涉及到对 OA 的初步的认知，深入到对本质的探讨，从而推导面临的挑战，然后再换一个角度，从成功到风险的对应，然后再到如何解决这些问题的思路。其中有不少逻辑是相关联的，看上去未免有些头晕，但好在这样没有太多探索范围的遗漏，只好请读者宽容了。另外还有些问题虽然看上去很小，但其内涵却丰富，所以没有展开，采用的引用其他文章的方式作为解释，供有兴趣的朋友阅读了解第一问：OA 的成功率有多高？在大多数人的心目当中，OA 是一个很容易成功并且没有什么太大价值的软件。我不止一次问过客户这个问题，客户大部分都不知道
8、，并认为相比 ERP 而言， OA 技术难度不高，应用也不深奥，无需太多专业知识背景，只要领导一纸红头文件，就能顺利成功。其实现实情况恰恰相反，OA 的成功率低得可怜，虽然 OA 有 15 年以上的历史，真正成功的寥寥无几，现在从网络上能够查到的成功率数据是我在 2002 年调研走访客户后的得到的结论低于 15%，这大大低于用户和业界的感觉，其失败率直逼 ERP。我也常问客户：你们单位方圆 5 公里范围内有什么成功的 OA 客户吗？或者，你们行业内部哪个单位的 OA 用得不错？答案是否定的或者不知道。我知道的一个曾经投资百万建设 notes 系统的 OA 的客户，实施范围 1100 人，但最后
9、只有不到 50 人在上面用公文，可谓昂贵的摆设。其实深入了解，并非 NOTES 不好，失败是另有原因的。另一个例证是：致远现有的客户当中，有超过 15%的客户是抛弃了自己过去的 OA，改用 A6 的。其中有一个国资委下属的特大型企业给我印象深刻，他们唯恐老总知道过去的 OA 已经失败，所以在项目报告上强调，他们原来买的是 OA 是用来处理公文的，而这次买的是 “协同！” ，实施三个月后，瞒天过海地停了老 OA，全面迁移到 A6，老板用 A6 用得很爽，每天上线最早，下线最晚，竟然乐在其中丝毫没有察觉老 OA 废弃了。这个老总后来受国资委指派调动到新的一个特大型企业作领导，第一个信息化要求就是上
10、 A6。我估计在过去的 15 年中，中国至少有 5000 家厂商以项目的方式交付过 10 万套 OA，有的极其简单如同网站，能够上传，有 email、论坛就 ok 了，也有以公文、文档为主流的，更有极其复杂与 mis、生产管理、erp 、指挥调度、监控集成在一起的大型项目，但基本上上线率都大大低于实际应用覆盖范围。15%成功率其实是个乐观值。按照我的观点，即使致远的客户中能把 A6 的组织行为管理的价值发挥到了极致的也是极少数，大部分成功都是处于较为朦胧的价值认识情况下的初级自我满足。关于 OA 的第一问其实答案很简单，但调整和纠正对 OA 项目的风险低估和盲目乐观，是走向成功的开始。 第二问
11、：OA 的本质是什么? 这个问题有点哲学性，但确是 CIO 非搞清楚不可的问题，否则你无法建立这个项目与管理的支撑关系，你苦心孤诣整理的需求可能许多与战略并无重要紧急的关系，只不过是个人的软件细节偏好。关于这个问题我们至少可以从 2 个角度来看。首先从管理信息化的角度来，我先问 CIO 一个问题，尽管你可能亲自负责上线了各自系统，但它们真正覆盖了管理的主要范畴了吗？管理是一个抽象的名词，其外延一般以组织为边界，没见过那个老板把管理延伸到了员工家庭，那是侵犯隐私。从其范畴可以简单划分为两大领域：业务管理与组织管理。一是管理事情，如生意、业务，我们熟知的财务软件、销售管理、库存管理、采购管理、客户
12、关系管理、分销、制造、合同管理、质量管理都属于这个范畴，关于成本的几块整合起来称为 MRP-2，而关于物品的管理整合起来称为进销存，更多部分软件联通起来，提供更高层次的资源管理称为 erp。但这仅仅只是覆盖了管理的一半我称之为“业务管理” 。这些软件最大的特点是管理初衷或对象是事情。至于不同环节是哪些人不重要，库管是张三采购是李四不重要，甚至互换一下也不重要，重要的是物品数量的准确性。管理的另一个领域是大家天天都在经历的，常常警醒，为之疲惫，但常不得要领，觉得非常困难的管人！作为管理者，我们每天发号施令，找人谈话，听取汇报，批评表扬，有时候我们会被气得暴跳如雷，员工敬而远之，有时心花怒放，对员
13、工笑脸如掬，这些现象都属于“组织管理”的范畴，组织管理和业务管理（政府也有业务管理） ，共同构成一个完整的组织管理范畴，二者相辅相成不可能截然分割。接下来我们再看，组织管理中的软件非常少，就目前来看，也不过只有 HR 和 kpi 两种软件，后者还是初级阶段，组织管理软件的对象是人！其实所有的领导都模糊地意识到了组织管理的重要性，所以自发地采用了一些不包含任何管理理念的软件，特别是工具软件来完成组织管理的目标。比如，我们常见的用 im 进行沟通，用 email 进行反馈和协作，用网站进行对组织的大面积影响和信息对称，用论坛来提供群众参与的多元化沟通。 组织行为管理是现代管理学的重要基石，是研究组
14、织的分工、个体行为、群体行为、工作管理、激励、变革的科学，你只要买任何一本管理学简史都能看到，从古典管理思想，到泰勒的科学管理学派，梅奥的人际关系学派、德鲁克的经验学派、马斯洛的层次需求模型、授权模型、领导力模型，人性善、恶假说真的是博大精深，我等不过是初窥门径。如果说，这些术语太过于晦涩，那么“执行力” 、 “文化建设” 、 “有效沟通” 、 “时间管理” 、 “有效授权” 、 “领导力建设”这些以执行 、 赢在执行 、 基业长青 、 赢韦尔奇自传 、 谁说大象不会跳舞 、 蓝海战略等出版物的形式在最近几年深入影响了从张瑞敏到柳传志以及你、我和客户的领导的概念大家应该不陌生。其衍生出无数的出
15、版物、培训课程、咨询项目正在逐渐影响一个又一个的组织。世界上有无数的成功企业，其公认的核心竞争力无外乎有成本领先、差异化服务、品牌领先、技术领先，但从来没有一个企业领袖敢宣称自己靠管理领先，因此我们就知道组织管理范畴就算穷一生之力也难以成就巅峰，需要我们不断努力追求，才能在竞争中处于安全一点的位置。我曾经和一个美国的投资银行代表交流过 A6，他认为在美国也会非常有价值，另一个上海科技开发区的 A6 客户领导是加拿大裔华人，曾非常期望我们开发英文版，他愿意在加拿大代理销售，我相信A6 是中国第一个真正意义上基于组织管理中最核心的部分组织行为管理设计的软件，其价值和市场不可估量，必将成为未来组织的
16、基本工作平台。从另一个角度看，OA 的本质是什么？其实是组织行为变革的革命，只不过手段是用 OA，负责人是 CIO 或办公室主任，实际领导是大老板，全员参与的一场革命洗礼。OA 项目和上一个财务软件不一样的是它的应用范围决定了它是一个 “全员信息化”的大事，这期间，应用范围的量变积累已经使得项目产生了质变的层面，已经涉及到了整个组织的“行为变革”范畴，这在管理学中是一个大大的事件甚至需要用革命来形容。也许 HR 软件或者进销存软件使用失败了没有什么，因为别的部门甚至根本就不知道发生过。但 OA 不同，从上线那一天起，到最后无论好坏，每个人都知道你干过一件漂亮或者很糗的事情。记住：OA 项目的性
17、质是一种组织行为的变革工具。绝大部分 CIO 都是可爱的技术爱好者，也正因为技术的原因被领导指派作为 OA 项目负责人。不过组织行为学和组织管理学并不是 CIO 的擅长，所以 CIO 难以了解或者描述 OA 的价值。失去了以组织行为管理的价值准绳，只能凭借技术作为判断方向的依据，这样的选型想不失败都很难。所以，你现在要清楚，可能并不熟悉管理的你要去推动一场组织行为的变革，代号是 OA；你将在未来几个月中改变原来那些你熟悉的人的行为模式，把他们从电话、面谈、会议中拽出来，给他一个OA，让他们比以前的行为模式更加有效率，甚至感到比以前工作起来更快乐。如果你选的产品或者方案让他们感觉很痛苦，他们会以
18、没有时间学习、不好用等各种理由抵抗你。你应该知道改变整个组织的行为习惯是非常困难的，习惯是人性的一部分，改变习惯就是扭曲人性，那种痛苦你如果戒过烟就明白了。现在你面临的情况更糟，就像你需要让 200 个烟鬼集体戒烟或者 300 个懒人准时起床晨练那么难。还有，面对领导的信任，你想退出是肯定已经来不及了，呵呵。掌握如何通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。 所有的致远人都明白自己是在从事一项伟大的事业，我们正在用创造力开创管理软件业中另一大分支组织管理软件，我们会将新技术不断带入这一范畴中，把软件变成对组织中每一个人都有价值的工具。 第三问：OA 的挑战是什么？对 OA
19、的挑战的研究一定要建立在对 OA 的本质的认知基础上，我们常见的现象是，CIO 在立项中把需求的满足度作为最高权重指标，另外关注的是技术的先进性和安全性等等，这些都过于偏重技术了。他们到底忽略了什么？我看过一份 IDC 专门的调查研究报告，与我实践中求证的答案一样，那个答案却是 CIO 背景的人最容易忽视的。在 OA 的本质探讨中，我们已经明确了，OA 其实是一次组织行为变革的代号，其形式是软件部署和使用，实质是组织行为模式的变革，特别是协同模式的变革。过去曾有无数的 OA，在立项阶段 CIO 和办公室主任，殚精竭虑地整理完整的需求，在支付了大量的金钱和时间之后，通过项目化开发得到了满足，但实
20、际情况是根本没有人愿意用，是什么导致了这些需求的提供者拒绝使用系统？这样的变革需要两种力量的参与，一是领导真正的重视，不仅仅停留在口号或者愿望上，需要身体力行。凡是成功的 A6 客户，在实施阶段都会给我们一个账号，我常看到那些位高权重的领导者常常是最早上线，最晚下线的人群之一。另外就是高度的群众参与，在评估成功的关键阀值中我们提到应用范围值就是这个特性的量化。领导和群众，最大的共性是电脑应用水平低下。事实上一个在运作中的组织是难以从业务惯性中摆脱出来专门去从事整体的学习的。我们可以把财务部几十个人停下来专门学习财务软件，加班加点在电脑上重新输入凭证、记账，但我们无法让整个组织停下来 3 个工作
21、日，学习 OA 软件，最多是轮流培训2 天，绝大多数是一天甚至半天。因此有个规律，应用范围越大的系统，其学习成本就应该越低，易用性是最大的挑战之一。关于A6 的具体易用性体现可参见 回复伙伴如何理解易用性在 A6 中的体现与价值 。如果没有良好的易用性，学习的时间成本过高，应用范围值就达不到阀值，就会出现上协同的效率不如不上协同，OA 的实施就走向负循环，走向失败。如果没有第一步成功，无论需求满足度有多高，都会失败。CIO 相对组织中其他人员来说，他太了解电脑了，这也是被挑选出来承担 OA 选型责任的原因，但他又不了解组织行为学，如果再不具备对 OA 的哲学认知，会在相当程度上忽略易用性。当我
22、看到研究报告中“易用性”在总共 10 项诸如先进性、安全性、成本之类的要素调查中排名第一位的时候，深刻感觉到这真的是一个决策方面的悖论。CIO 务必要清楚，对摄影家非常合适的专业级相机，性能参数都远高于民用消费级相机，但未必就适合普通的菜鸟爱好者。如果挑选 OA 时不注重易用性，那么不仅仅是造成曲高和寡的尴尬的可能性问题，而且要知道，个体的菜鸟可以通过学习成为摄影家，而组织内部的耗散特征则使得群体的菜鸟永远成为不了复杂软件的操作者（见第 9 问成功评估指标中的阀值效应） 。以前的 OA 失败，至少有 50%可以归罪为易用性问题。另一项挑战是 OA 的粘着度（用户对系统的依赖程度） 。大部分 O
23、A 系统都不具备粘着度，要知道无论需求有多厚，都是穷举模式的，而组织行为是无法穷举的，即使照猫画虎一一满足那些穷举的需求，你可能发现仍然有 80%的事情无法在 OA 上处理。过去 OA 的失败原因就是只作关键性应用，我们熟知的公文、文档管理、办公室常用的功能等等，都是这种思路，就算有流程化审批，也只能穷举部分组织级审批，到部门级就太多了，干脆就不做了。他们草率地把 80%的无法穷举的应用需求的责任推给了邮件！套用那句名言的语法“如果道歉有用，还需要警察作什么？如果邮件能解决还要 OA 干什么？”A6 最大的创新就是有一个既能作关键性应用，又高度满足经常性无法穷举的“新建协同” ，并且有高度的易
24、用性，使得 A6 的客户几乎无论什么要求都能在协同中被满足或变相满足，这样使得客户对 A6有高度的依赖性，从而形成易装易用好用爱用深化应用的正向循环。因此，系统是否能够平衡“关键性”和“经常性”应用是另一个最大的挑战。OA 还有很多挑战，诸如实施风险之类的，但最大的还是在产品本身的，易用性和实用性，而大部分人可能对易用性容易理解，但对实用性却没有深入认识，我们通过大量调研，才认识到第二个问题，那是传统 OA 失败的根本原因。第四问：OA 的项目成功的要素是什么？OA 的选型实施范围大、涉及面广，如果想让 OA 项目成为持续支撑组织发展的基础 IT 平台，CIO们必须以战略层面的眼光来思考，不能
25、把 OA 作为急就章项目来看待，在我们看来成功的要素至少有这三点。1、正确的选择产品或者项目方案你必需选择一个可以满足当前需求的产品或项目，否则以后就很难说了，但真得是以自己的需求为导向的选择就能成功吗？为什么那么多能够清理自己需求的项目仍然不成功？这是因为没有搞清楚产品和项目对自己的意义。2、 阶段清晰的渐进式实施常见的对实施的认识大多局限于软件安装、公文流程定义，表单设计等等，大部分都缺乏对实施的整体认识，致远在长期的客户实践中，总结了实施 3 段论（共性应用2:8 原则、局部深化、集成应用） ，因为涉及到很多方面，限于篇幅，我在以后的 9 问的如何实施阶段规划中展开谈。3、 持续服务、升
26、级的进步保障机制持续升级的好处不说了，说说持续服务。持续的服务也许是供应商的一种良好愿望，但也许只是为了收款时拍胸口的豪言壮语。你必需清楚，一切可持续的事物都不是靠愿望，而是某种内在的东西在支撑。本章内容比较简约，但确是影响项目成败的最主要的价值观和方法论的基础，CIO 们对此问题的充分认识和正确决策是保障项目成败的关键中的关键。因此下问中我们先不对上面三个分支问题作出深入的阐述，让我们从另一个角度，那些在过去曾经失败的 CIO 为何踏入了所谓 OA 的“CIO 陷阱”来了解更多的细节。 第五问：CIO 的项目陷阱是什么？CIO 通常是 OA 项目的负责人，中国的 OA 应用发展史可谓成也 C
27、IO 败也 CIO，在组织赋予 CIO 肩负起 OA 项目建设的职责的同时，不少 CIO 却充满激情地冲向陷阱。陷阱一：缺乏长期规划有些 CIO 一般有当前的项目规划，而无长期战略规划，为项目的早夭埋下了伏笔。详情参见第 7 问：如何进行实施阶段规划。陷阱二：需求贪大求全如果你坚信自己采集的需求是一种客观的需求，是必须被 100%满足的需求，那么你就离失败不远了。如何认识自己的需求？99.99%的 OA 需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近 20 年几乎所有的 OA 都走项目化或者看着别人的 OA 还凑合拿来就用。如果你也是这样整理需求的，那简直就是
28、自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。把一叠白纸发给单位内各个部门的 10 天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧。也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给 OA。依照这种需求，世上没有一套现成的软件能够 100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你
29、未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案。依据这样的需求开发出来的 OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。第一代的 OA 都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？我们研究发现这类 OA 普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个？请不要轻率地回答这个问题。你说用公文？别逗了，公文只有组织中不到 10%的人经常用；文档？文档可以分享，不过文档不能主动产生协同；IM ？IM 好像不能进行表单审批吧；邮件？邮件能
30、作流程化审批吗？邮件能使得整个组织共享吗？邮件用于要事的授权你既不知道过程也不知道结果你能放心吗？要用邮件来完成组织的日常协同我们还作 OA 项目干什么？所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了？没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家 OA 厂商，走访了数十家 OA 成功或失败的客户，仔细评估了超过 200 种常见 OA 的功能菜单，最后找到了那个共性的需求！我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需
31、求，那个词叫“协同”。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果。无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎 80%可以归结为这个需求。 所以你在选型的时候一定要看，这个 OA 是否有这样的一个功能能够满足这个共性需求！另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久
32、拖不上的覆辙。“汇总式”需求对 OA 项目建设的副作用在于缺乏共性需求的抽象提炼，主次不分，轻重不分，缓急不分，这必将导致前期实施目标点过多，局部各自兴奋，全局一盘散沙的局面，事实上你将成为需求平均主义泛滥的牺牲品，丧失把控实施进度的节奏的能力。陷阱三：实现急功近利如果你认为软件只要会编程就能作，那你可就大错特错了！隔壁邻居家的高中男孩就能干的事情是写程序，属于个人娱乐，和摄影爱好差不多。而软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计” ；经过评审后，技术高手会
33、充分考虑诸多因素后提出“构架设计” ，评审后才会到开发部形成 “应用设计” ，评审后才会有“代码开发” ，然后是“功能测试”(诸如白盒测试、黑盒测试、性能测试、压力测试、环境测试、安装测试等) ，然后才能交给你。这期间，所有的环节都应该是最优质的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。陷阱四：选择片面求新对新技术的片面性追求常常导致项目成为了项目负责人（特别是 CIO）自娱自乐的畸形产物，即使探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性无疑是高风险和高成本的。不少项目负责人会认为“最新的技
34、术”“最先进的技术” 。这种认知是非常片面的。在我们看来，所谓技术先进性的价值不在于先进本身， （许多 CIO 会认为，使用新发明的技术就是先进的标志，这实在是本末倒置了，全球银行业和证券业用的技术至少都落后于新技术好几年）而在于先进对扩展性、性能、安全性、集成性、易用性（常被 CIO 所忽视其实对终端客户的影响排在第一位）等诸多应用的现实价值和升级成本的抑制。而且由于协同管理软件的价值并不仅仅依赖软件本身，其布署过程和应用推进能力也对其价值发挥起到至关重要的作用。我们绝不能忽视这样的现象同样的软件在不同的单位对价值有截然不同的评估，所谓花巨资上马的大型软件成为摆设的情况比比皆是。我们相信 C
35、IO 对于软件的评估侧重应用和技术是理性的，但我们也同时注意到，CIO 对于推动组织建立新型工作行为模式的艰巨性和挑战性的重视程度不够，常在对未来技术应用发展趋势的无限可能性的苦思冥想中忽略了组织与协调成本，导致系统实施成为踏入泥潭的第一步。只有对诸如布署的阶段性、短期用户学习、中期应用感受、长期需求发展、总体拥有成本等诸多方面与软件本身的综合形成的价值观和方法论是否适合特点的客户才是评估所谓先进性的标准。陷阱五：实施缺乏导向实施被不少 CIO 理解为软件开放、安装调试、培训、测试、上线这一类的事务，但我们认为这不是实施，至少实施的目标错了。实施不是结束一个软件的部署过程，而是在这个过程中达成
36、管理提升的目的。如果是前面所说的工作是必需的过程，那么达成管理目标才是实施的结果。遗憾的是，极少才有CIO 在实施计划中明确地提出管理提升目标，最高的层次也就是具体枝节需求的满足。最理想的结果也就是安装了一套对大家没有价值感受的软件！ 第六问：如何认识产品和项目对自己的意义事实上，CIO 在 OA 方面只能有三种选择，一是标准产品，二是个性化（项目化）开发，三是产品局部定制。信息化程度、管理成熟度不同的客户对 OA 的期望值是不同的，另外 CIO 的技术偏好会导致对需求的客观性不足。先认识一下产品：产品化的 OA 从视觉上看到的只是包装盒中的光盘、加密狗、印刷说明书（印刷品是批量的标志） 、服
37、务卡，但实际上它是一个复杂的商业系统，由需求流程、概念设计、构架设计、程序代码、测试流程、销售、实施交付、售后服务、升级服务等多种岗位专业人员协作构成的。产品化有它的好处，也有它的不足。好处是意味着在你之前有无数用户验证了功能的适用性、性能的稳定性，并且还可以持续升级，是成熟的象征，是与客户的长期合作，如同婚姻。产品化还意味着高性价比，这是绝大部分客户所关注的。产品化总得来说是低风险的。由于用友致远开创了 OA 的产品化格局，因此最近不少厂商都在宣称自己是产品化。有 CIO 为此困惑，问及我如何识别，我告诉他很简单，可以通过该厂商的网站来识别，产品化供应商能看到升级公告，没有版本升级公告的则属
38、于李鬼。客户可以从致远的网站上的客服公告中看到我们是如何从 2.1 版花了近 5 年数万个人工日一步步走到今天的。产品化的不足是，不能一次满足所有细节需求，客户在选择时需要对需求有所舍弃，另外产品化的升级节奏可能与你的需求的成长的速度之间的匹配是个问题，这就需要你在产品化厂商中选择那些内部资源雄厚，流程顺畅，支撑保障机制健全的厂商。再看看项目：项目是只有些代码是为客户量身定做，与此同时丧失了标准化升级的可能性的系统，其关键在后者而不是个性化代码的多少。其实大部分项目化供应商都恨不得一行代码都不改就交付给另一个客户，但局限于上一个客户的个性化代码的存在，使得他们不得不吃下自己为满足一个客户的需求
39、代来的苦果。项目化是高成本的，首先技术人员比实施人员成本高，你们要告诫客户，如果优质的程序员是价值昂贵的稀缺资源，客户最好不要相信花 1 万元就能作出个好项目。二是长周期的，短期赶出来的，不可能没有问题，看看微软这么伟大的公司还有不少 bug 呢。项目漫长的测试、优化周期造成了高成本；三是供应商的商业模式造成的，如果是项目型的厂商，只能通过尽可能通过每一个项目的价格最大化回报来挣钱，因为他们没有把握像产品化公司一样通过客户数量挣钱。项目化是高风险的，从需求分析开始，到技术路线选型、构架的扩展性设计考虑、优质高效的代码实现、完善的测试，所有这些环节，都需要客户和供应商双方投入最顶尖的人力资源，才
40、足以做到业界一流水平，悲惨的是，这根本不可能大面积出现这种理想情况，一个供应商只能有一个顶尖项目经理，他不可能在每一个项目上投入，而客户方，更是稀缺能够精通 OA，具备战略思维，又能细致深入把握需求、协调实施的 PM（项目经理） ，这种人月薪身价都在 2 万以上的。所以我们不难理解为什么这么多OA 的烂项目，说穿了，就是 2-3 流人员在瞎折腾。他们在我提到的这些环节中任何一个失误都会让客户未来付出代价。项目化最大的局限性是长期发展机制，如果没有每年配套的充足的预算，你怎么可能长期要求供应商持续为你研究、优化、升级？在技术日新月异的今天，没有最好的，只有更好的。中国式项目化是与客户的短期合作，
41、是一夜情模式。比较了两种模式之后，客户无疑要作个决断，大部分客户会选产品化。有极少的客户选择项目化，但有一些客户还是期望在购买时获得承诺满足产品化尚无法满足的个性化需求。这种情况下，导致了第三种模式的出现产品化局部定制。产品化局部定制仍然会导致两个结果，客户的需求如果产品构架可以支持以扩展模块的方式满足，那么万事大吉，如果产品化的技术构架不支持，客户的需求如果要满足，就只能以调整构架，牺牲升级来换取。A6 的构架最早根本不支持，现在开始逐步支持到逐步成体系，这是一个漫长的接口的发育过程，需要漫长的实践积累才能保证接口的成熟度。我也曾经多次遇到客户个性化需求的重压，提出如果不满足就不买或者不付余
42、款之类的，我会客观地与研发评估其需求实现属于可升级型或不可升级型，成本有多大。如果属于可升级型，我会坦率提出版本升级或付费局部定制成本问题，如果属于不可升级型而用户又坚持要这个功能，我会告知用户我作的先决条件是客户签署一份“放弃升级的声明” 。有意思的是，这种鱼和熊掌不可兼得的局面下，我们与所有的客户都达成了一致部分版本升级满足、部分以不影响升级的局部定制满足，部分舍弃。从而保持了系统的可升级性，因为从长远看，升级所换来对全局性的价值远远多于局部的个性化满足所带来的价值。由于项目的个性，实际上持续服务是不可能的。我曾经和一个 CIO 开玩笑，当他宣称必须完全满足需求的时候，我说，你只能选项目。
43、另外一个问题是你有宗教信仰吗? 他说他是党员。我回答说:你最好选择一个宗教，管他是佛教还是基督教，重要的是你要养成每天祷告的习惯，你要学会相信老天和神灵保佑你这些事情：项目文档不要在 2 年后丢失、供应商项目经理不要离职、不要跳槽、不要考研究生、不要出国、不要开车超速出车祸或者游泳淹死这些情况中任何一种发生，都将导致你不能享受到以前的服务水平；你不能期望一个对你项目代码、构架需求毫不了解的家伙能够给你高质量服务。呵呵，想到这一切的可能性，他差点当即晕倒。反观产品，如此众多的客户不仅使得产品经受了个体完全无法达成的覆盖性测试，这些测试中的bug 反馈和需求反馈又进一步导致了产品加速完善。最重要的
44、是使得我们的客服能够形成版本知识库，有了这样的知识库，我们几乎能够回答 90%稀奇古怪的问题 其中大部分是 IT 环境问题（病毒、插件、IE 版本、补丁没有打之类的） ，而且并不因个体人员的变动导致服务质量下降。致远的客服不仅在积累知识，而且在学习和研究不同阶段客户的应用特点，早已经从被动客服（出了问题找客服）上升到了主动式客服。我们知道新客户会遇到什么问题，在应用深化时能够给客户来自其他客户应用的经验参考，我们的主动式客服月刊就体现了这一点。总之产品化让我们见多识广，知识库让我们专业化，众多的客户经验让我们从解决问题型上升到专家指导型。这几年来，约有 15%的 A6 客户是废弃了原先的 OA
45、 重新购买了 A6，这是因为过去的 OA 的项目化导致了项目发育停滞我常告诉客户，项目化的验收之日就是 OA 成长的死亡之日，只不过要 12年才显露出来.供应商撤离，客户 PM 转移到其他项目，对 OA 项目来说，无异于根须死亡，树叶发黄凋零是迟早的事情。 产品化是中国大部分客户能接受的长期发展保障机制，项目化要想长期保障，太贵了，你想想你是否玩得起！ 第七问：如何进行 OA 的实施阶段规划？ 大部分客户的项目经理都会根据老板的期限有一个实施规划，分为调研、方案、启动会、实施、培训、测试、上线、正式运用等等，实施顾问会和你一起根据项目的大小、难度、重点去作出对应的方案。经过多年的实践，致远的实
46、施方法论已经非常完善，有几种不同的模板，甚至能够提供启动会上董事长、总裁的发言提纲，你想大张旗鼓地推进 A6 的全面应用吗？给我们打电话，我们甚至会帮你搞到一份 A6实施海报，上面有一个职业佳丽伫立在电脑旁，笑意吟吟地看着你的同事，旁边有文字曰：今天你协同了吗？但这是不够的，你不过完成的是当期的实施规划，你如果了解了 OA 的本质，认识到这是一个长期而艰巨的组织行为变革的挑战，而你没有战略规划，你可能会把不该这个阶段完成的事情纳入进来，混淆了主要问题和次要问题，甚至会导致失败。首先，你应该有一个长期战略规划，你需要知道 OA 的应用不是一蹴而就的，所以你不要期望把所有的问题在今天解决。根据我们
47、的经验，我们建议你至少要规划三个阶段：第一阶段：共性应用阶段第一阶段的使命是保障快速上线，尽快建立组织级协同方式的新的习惯和模式。你现在已经知道这个速度是非常重要的了，所以你必需对第一阶段的需求进行准确的确定，如果你不加控制，你可能会无意中设定了过多的目标，最糟的是每个部门都有自己的重点目标，大家都陷入到自己的细节需求的满足、扯皮之中，仍然没有协同起来。我们有一句很哲学的话描述第一阶段的应用特点：最大范围的最小应用。够抽象吧，意思是你除了公文、文件夹之类必不可少的应用，你首先应该推动的是“自由协同” ，自由协同会快速地让所有人感受到电脑协同方式相较于传统协同的优势，放心吧，很快，最多 2 周，
48、如果你能促进每个人每天上线 2-3 次，那么大家都会爱上协同的。当你看到这样的情况。领导在走廊抽烟，远远的一个下属喊道，xx 总，我昨天把项目材料搞完了，然后你听到 x 总大声地回答：好了，你把它协同发给我吧。你就知道，第一阶段大功告成了！第一阶段是成功的第一步，不积跬步无以至千里，如果第一步倒下，就不会有未来。关于第一步的衡量指标就是我在第 9 问中提到的:衡量成功的简单指标的 2 个阀值和 2 个月期限。第二阶段：深化应用阶段即使在同一个单位，也不是每一个部门的管理水平都是一样的，同样 A6 的应用深度也会不同。流程繁杂的部门领导重视流程梳理和效率，文档如山的注重文档管理，知识变化快的注重
49、知识管理，总经理工作部、办公室注重结果，项目经理注重过程和跨部门信息对称因此，你要在第二阶段，进行二次实施，这次是以部门为中心的管理深化，通过 A6 把部门管理的难点、重点通过深度实施解决掉，而且刚才说到的问题很多还需要组织保障在部门中设置兼职岗位落实到人，这样才可以检查和推进。如果运气好，你大约可以用半年到 1 年的时间完成这一切。那时候，你们单位的流程有序了，而且建立了流程设定的流程，一个又一个新流程在自由协同的实践中逐渐成熟，转化为模板，上升到制度；你们单位的每一个大一点的部门都有了肩负 OA 深化使用的兼职人员甚至是专职人员，并且可以考核他们。单位第一次设置了总监或副总级别的知识管理负责人，有了知识的筛选标准，强制的采集上报制度，知识贡献的激励注意这是一场变革，没有组织保障是不行的，没有激励也是不能持久的。第三阶段：整合应用阶段这里的关键在于整合什么？单点登录，A6 现在一配就行，A6 的关联系统支持单点登录访问其他系统的松耦合，甚至支持接口数据交换方式的整合，比如 U8 插件能通过 U8eai 接口实现 A6 报销单U8待记账凭证之间的转换。但你如果选择深层次两个系统之间进行数据级紧耦合，那一切都不一样了。很多 CIO
