张屹---九问CIO

申请免费试用、咨询电话：400-8352-114

本来此文是一份用友致远内部与渠道代理伙伴交流客户对OA的认知的系列文章、以及部分发表在致远网站上的文章整理而成的，其中为了更加具体的说明问题或作为例证，我在不少地方使用了A6协同软件作为参照，并非出于对这些早已选择了A6产品作为事业的朋友进行推销的目的。在内部发布后，许多伙伴朋友鼓励我拿出来与更多的客户的CIO朋友分享，专业媒体和出版界的朋友听说后也向我约稿，于是我在原文的基础上略作整理以供抛砖引玉。

第一问：OA的成功率有多高？

在大多数人的心目当中，OA是一个很容易成功并且没有什么太大价值的软件。我不止一次问过客户这个问题，客户大部分都不知道，并认为相比ERP而言，OA技术难度不高，应用也不深奥，无需太多专业知识背景，只要领导一纸红头文件，就能顺利成功。

其实现实情况恰恰相反，OA的成功率低得可怜，虽然OA有15年以上的历史，真正成功的寥寥无几，现在从网络上能够查到的成功率数据是我在2002年调研走访客户后的得到的结论--低于15%，这大大低于用户和业界的感觉，其失败率直逼ERP。我也常问客户：你们单位方圆5公里范围内有什么成功的OA客户吗？或者，你们行业内部哪个单位的OA用得不错？答案是否定的或者不知道。我知道的一个曾经投资百万建设notes系统的OA的客户，实施范围1100人，但最后只有不到50人在上面用公文，可谓昂贵的摆设。其实深入了解，并非NOTES不好，失败是另有原因的。

另一个例证是：致远现有的客户当中，有超过15%的客户是抛弃了自己过去的OA，改用A6的。其中有一个国资委下属的特大型企业给我印象深刻，他们唯恐老总知道过去的OA已经失败，所以在项目报告上强调，他们原来买的是OA是用来处理公文的，而这次买的是“协同！”，实施三个月后，瞒天过海地停了老OA，全面迁移到A6，老板用A6用得很爽，每天上线最早，下线最晚，竟然乐在其中丝毫没有察觉老OA废弃了。这个老总后来受国资委指派调动到新的一个特大型企业作领导，第一个信息化要求就是上A6。

我估计在过去的15年中，中国至少有5000家厂商以项目的方式交付过10万套OA，有的极其简单如同网站，能够上传，有email、论坛就ok了，也有以公文、文档为主流的，更有极其复杂与mis、生产管理、erp、指挥调度、监控集成在一起的大型项目，但基本上上线率都大大低于实际应用覆盖范围。15%成功率其实是个乐观值。按照我的观点，即使致远的客户中能把A6的组织行为管理的价值发挥到了极致的也是极少数，大部分成功都是处于较为朦胧的价值认识情况下的初级自我满足。

关于OA的第一问其实答案很简单，但调整和纠正对OA项目的风险低估和盲目乐观，是走向成功的开始。

第二问：OA的本质是什么?

这个问题有点哲学性，但确是CIO非搞清楚不可的问题，否则你无法建立这个项目与管理的支撑关系，你苦心孤诣整理的需求可能许多与战略并无重要紧急的关系，只不过是个人的软件细节偏好。关于这个问题我们至少可以从2个角度来看。

首先从管理信息化的角度来，我先问CIO一个问题，尽管你可能亲自负责上线了各自系统，但它们真正覆盖了管理的主要范畴了吗？

管理是一个抽象的名词，其外延一般以组织为边界，没见过那个老板把管理延伸到了员工家庭，那是侵犯隐私。从其范畴可以简单划分为两大领域：业务管理与组织管理。

一是管理事情，如生意、业务，我们熟知的财务软件、销售管理、库存管理、采购管理、客户关系管理、分销、制造、合同管理、质量管理都属于这个范畴，关于成本的几块整合起来称为MRP-2，而关于物品的管理整合起来称为进销存，更多部分软件联通起来，提供更高层次的资源管理称为erp。但这仅仅只是覆盖了管理的一半--我称之为“业务管理”。这些软件最大的特点是管理初衷或对象是事情。至于不同环节是哪些人不重要，库管是张三采购是李四不重要，甚至互换一下也不重要，重要的是物品数量的准确性。

管理的另一个领域是大家天天都在经历的，常常警醒，为之疲惫，但常不得要领，觉得非常困难的--管人！作为管理者，我们每天发号施令，找人谈话，听取汇报，批评表扬，有时候我们会被气得暴跳如雷，员工敬而远之，有时心花怒放，对员工笑脸如掬，这些现象都属于“组织管理”的范畴，组织管理和业务管理（政府也有业务管理），共同构成一个完整的组织管理范畴，二者相辅相成不可能截然分割。

接下来我们再看，组织管理中的软件非常少，就目前来看，也不过只有HR和kpi两种软件，后者还是初级阶段，组织管理软件的对象是人！其实所有的领导都模糊地意识到了组织管理的重要性，所以自发地采用了一些不包含任何管理理念的软件，特别是工具软件来完成组织管理的目标。比如，我们常见的用im进行沟通，用email进行反馈和协作，用网站进行对组织的大面积影响和信息对称，用论坛来提供群众参与的多元化沟通。 组织行为管理是现代管理学的重要基石，是研究组织的分工、个体行为、群体行为、工作管理、激励、变革……的科学，你只要买任何一本《管理学简史》都能看到，从古典管理思想，到泰勒的科学管理学派，梅奥的人际关系学派、德鲁克的经验学派、马斯洛的层次需求模型、授权模型、领导力模型，人性善、恶假说……真的是博大精深，我等不过是初窥门径。

如果说，这些术语太过于晦涩，那么“执行力”、“文化建设”、“有效沟通”、“时间管理”、“有效授权”、“领导力建设”……这些以《执行》、《赢在执行》、《基业长青》、《赢－韦尔奇自传》、《谁说大象不会跳舞》、《蓝海战略》等出版物的形式在最近几年深入影响了从张瑞敏到柳传志以及你、我和客户的领导的概念大家应该不陌生。其衍生出无数的出版物、培训课程、咨询项目正在逐渐影响一个又一个的组织。

世界上有无数的成功企业，其公认的核心竞争力无外乎有成本领先、差异化服务、品牌领先、技术领先，但从来没有一个企业领袖敢宣称自己靠管理领先，因此我们就知道组织管理范畴就算穷一生之力也难以成就巅峰，需要我们不断努力追求，才能在竞争中处于安全一点的位置。

我曾经和一个美国的投资银行代表交流过A6，他认为在美国也会非常有价值，另一个上海科技开发区的A6客户领导是加拿大裔华人，曾非常期望我们开发英文版，他愿意在加拿大代理销售，我相信A6是中国第一个真正意义上基于组织管理中最核心的部分组织行为管理设计的软件，其价值和市场不可估量，必将成为未来组织的基本工作平台。

从另一个角度看，OA的本质是什么？

其实是组织行为变革的革命，只不过手段是用OA，负责人是CIO或办公室主任，实际领导是大老板，全员参与的一场革命洗礼。

OA项目和上一个财务软件不一样的是它的应用范围决定了它是一个“全员信息化”的大事，这期间，应用范围的量变积累已经使得项目产生了质变的层面，已经涉及到了整个组织的“行为变革”范畴，这在管理学中是一个大大的事件甚至需要用革命来形容。也许HR软件或者进销存软件使用失败了没有什么，因为别的部门甚至根本就不知道发生过。但OA不同，从上线那一天起，到最后无论好坏，每个人都知道你干过一件漂亮或者很糗的事情。
记住：OA项目的性质是一种组织行为的变革工具。

绝大部分CIO都是可爱的技术爱好者，也正因为技术的原因被领导指派作为OA项目负责人。不过组织行为学和组织管理学并不是CIO的擅长，所以CIO难以了解或者描述OA的价值。失去了以组织行为管理的价值准绳，只能凭借技术作为判断方向的依据，这样的选型想不失败都很难。

所以，你现在要清楚，可能并不熟悉管理的你要去推动一场组织行为的变革，代号是OA；你将在未来几个月中改变原来那些你熟悉的人的行为模式，把他们从电话、面谈、会议中拽出来，给他一个OA，让他们比以前的行为模式更加有效率，甚至感到比以前工作起来更快乐。如果你选的产品或者方案让他们感觉很痛苦，他们会以没有时间学习、不好用等各种理由抵抗你。你应该知道改变整个组织的行为习惯是非常困难的，习惯是人性的一部分，改变习惯就是扭曲人性，那种痛苦你如果戒过烟就明白了。现在你面临的情况更糟，就像你需要让200个烟鬼集体戒烟或者300个懒人准时起床晨练那么难。还有，面对领导的信任，你想退出是肯定已经来不及了，呵呵。掌握如何通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。

所有的致远人都明白自己是在从事一项伟大的事业，我们正在用创造力开创管理软件业中另一大分支--组织管理软件，我们会将新技术不断带入这一范畴中，把软件变成对组织中每一个人都有价值的工具。

第三问：OA的挑战是什么？

对OA的挑战的研究一定要建立在对OA的本质的认知基础上，我们常见的现象是，CIO在立项中把需求的满足度作为最高权重指标，另外关注的是技术的先进性和安全性等等，这些都过于偏重技术了。他们到底忽略了什么？我看过一份IDC专门的调查研究报告，与我实践中求证的答案一样，那个答案却是CIO背景的人最容易忽视的。

在OA的本质探讨中，我们已经明确了，OA其实是一次组织行为变革的代号，其形式是软件部署和使用，实质是组织行为模式的变革，特别是协同模式的变革。

过去曾有无数的OA，在立项阶段cio和办公室主任，殚精竭虑地整理完整的需求，在支付了大量的金钱和时间之后，通过项目化开发得到了满足，但实际情况是根本没有人愿意用，是什么导致了这些需求的提供者拒绝使用系统？

这样的变革需要两种力量的参与，一是领导真正的重视，不仅仅停留在口号或者愿望上，需要身体力行。凡是成功的A6客户，在实施阶段都会给我们一个账号，我常看到那些位高权重的领导者常常是最早上线，最晚下线的人群之一。另外就是高度的群众参与，在评估成功的关键阀值中我们提到应用范围值就是这个特性的量化。

领导和群众，最大的共性是电脑应用水平低下。事实上一个在运作中的组织是难以从业务惯性中摆脱出来专门去从事整体的学习的。我们可以把财务部几十个人停下来专门学习财务软件，加班加点在电脑上重新输入凭证、记账，但我们无法让整个组织停下来3个工作日，学习OA软件，最多是轮流培训2天，绝大多数是一天甚至半天。

因此有个规律，应用范围越大的系统，其学习成本就应该越低，易用性是最大的挑战之一。关于A6的具体易用性体现可参见《回复伙伴如何理解易用性在A6中的体现与价值》。

如果没有良好的易用性，学习的时间成本过高，应用范围值就达不到阀值，就会出现上协同的效率不如不上协同，OA的实施就走向负循环，走向失败。如果没有第一步成功，无论需求满足度有多高，都会失败。

CIO相对组织中其他人员来说，他太了解电脑了，这也是被挑选出来承担OA选型责任的原因，但他又不了解组织行为学，如果再不具备对OA的哲学认知，会在相当程度上忽略易用性。当我看到研究报告中“易用性”在总共10项诸如先进性、安全性、成本之类的要素调查中排名第一位的时候，深刻感觉到这真的是一个决策方面的悖论。CIO务必要清楚，对摄影家非常合适的专业级相机，性能参数都远高于民用消费级相机，但未必就适合普通的菜鸟爱好者。如果挑选OA时不注重易用性，那么不仅仅是造成曲高和寡的尴尬的可能性问题，而且要知道，个体的菜鸟可以通过学习成为摄影家，而组织内部的耗散特征则使得群体的菜鸟永远成为不了复杂软件的操作者（见第9问成功评估指标中的阀值效应）。以前的OA失败，至少有50%可以归罪为易用性问题。

另一项挑战是OA的粘着度（用户对系统的依赖程度）。大部分OA系统都不具备粘着度，要知道无论需求有多厚，都是穷举模式的，而组织行为是无法穷举的，即使照猫画虎一一满足那些穷举的需求，你可能发现仍然有80%的事情无法在OA上处理。过去OA的失败原因就是只作关键性应用，我们熟知的公文、文档管理、办公室常用的功能等等，都是这种思路，就算有流程化审批，也只能穷举部分组织级审批，到部门级就太多了，干脆就不做了。他们草率地把80%的无法穷举的应用需求的责任推给了邮件！套用那句名言的语法--“如果道歉有用，还需要警察作什么？--如果邮件能解决还要OA干什么？”

A6最大的创新就是有一个既能作关键性应用，又高度满足经常性无法穷举的“新建协同”，并且有高度的易用性，使得A6的客户几乎无论什么要求都能在协同中被满足或变相满足，这样使得客户对A6有高度的依赖性，从而形成易装易用－好用－爱用－深化应用的正向循环。
因此，系统是否能够平衡“关键性”和“经常性”应用是另一个最大的挑战。

OA还有很多挑战，诸如实施风险之类的，但最大的还是在产品本身的，易用性和实用性，而大部分人可能对易用性容易理解，但对实用性却没有深入认识，我们通过大量调研，才认识到第二个问题，那是传统OA失败的根本原因。
第四问：OA的项目成功的要素是什么？

OA的选型实施范围大、涉及面广，如果想让OA项目成为持续支撑组织发展的基础IT平台，CIO们必须以战略层面的眼光来思考，不能把OA作为急就章项目来看待，在我们看来成功的要素至少有这三点。

1、正确的选择产品或者项目方案：

你必需选择一个可以满足当前需求的产品或项目，否则以后就很难说了，但真得是以自己的需求为导向的选择就能成功吗？为什么那么多能够清理自己需求的项目仍然不成功？这是因为没有搞清楚产品和项目对自己的意义。

2、阶段清晰的渐进式实施

常见的对实施的认识大多局限于软件安装、公文流程定义，表单设计等等，大部分都缺乏对实施的整体认识，致远在长期的客户实践中，总结了实施3段论（共性应用－2:8原则、局部深化、集成应用），因为涉及到很多方面，限于篇幅，我在以后的9问的如何实施阶段规划中展开谈。    

3、持续服务、升级的进步保障机制
持续升级的好处不说了，说说持续服务。持续的服务也许是供应商的一种良好愿望，但也许只是为了收款时拍胸口的豪言壮语。你必需清楚，一切可持续的事物都不是靠愿望，而是某种内在的东西在支撑。

本章内容比较简约，但确是影响项目成败的最主要的价值观和方法论的基础，CIO们对此问题的充分认识和正确决策是保障项目成败的关键中的关键。因此下问中我们先不对上面三个分支问题作出深入的阐述，让我们从另一个角度，那些在过去曾经失败的CIO为何踏入了所谓OA的“CIO陷阱”来了解更多的细节。

第五问：CIO的项目陷阱是什么？

CIO通常是OA项目的负责人，中国的OA应用发展史可谓成也CIO败也CIO，在组织赋予CIO肩负起OA项目建设的职责的同时，不少CIO却充满激情地冲向陷阱。

陷阱一：缺乏长期规划

有些CIO一般有当前的项目规划，而无长期战略规划，为项目的早夭埋下了伏笔。详情参见第7问：如何进行实施阶段规划。

陷阱二：需求贪大求全

如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，那么你就离失败不远了。
如何认识自己的需求？

99.99%的OA需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。

把一叠白纸发给单位内各个部门的10天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧。

也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给OA。依照这种需求，世上没有一套现成的软件能够100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案。依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？

我们研究发现这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个？

请不要轻率地回答这个问题。你说用公文？别逗了，公文只有组织中不到10%的人经常用；文档？文档可以分享，不过文档不能主动产生协同；IM？IM好像不能进行表单审批吧；邮件？邮件能作流程化审批吗？邮件能使得整个组织共享吗？邮件用于要事的授权你既不知道过程也不知道结果你能放心吗？要用邮件来完成组织的日常协同我们还作OA项目干什么？

所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了？没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求！我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需求，那个词叫“协同”。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果。无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎80%可以归结为这个需求。
所以你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求！

另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。

“∑汇总式”需求对OA项目建设的副作用在于缺乏共性需求的抽象提炼，主次不分，轻重不分，缓急不分，这必将导致前期实施目标点过多，局部各自兴奋，全局一盘散沙的局面，事实上你将成为需求平均主义泛滥的牺牲品，丧失把控实施进度的节奏的能力。

陷阱三：实现急功近利

如果你认为软件只要会编程就能作，那你可就大错特错了！隔壁邻居家的高中男孩就能干的事情是写程序，属于个人娱乐，和摄影爱好差不多。而软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”；经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成 “应用设计”，评审后才会有“代码开发”，然后是“功能测试”(诸如白盒测试、黑盒测试、性能测试、压力测试、环境测试、安装测试等)，然后才能交给你。这期间，所有的环节都应该是最优质的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。

陷阱四：选择片面求新

对新技术的片面性追求常常导致项目成为了项目负责人（特别是CIO）自娱自乐的畸形产物，即使探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性无疑是高风险和高成本的。不少项目负责人会认为“最新的技术”＝“最先进的技术”。这种认知是非常片面的。
在我们看来，所谓技术先进性的价值不在于先进本身，（许多CIO会认为，使用新发明的技术就是先进的标志，这实在是本末倒置了，全球银行业和证券业用的技术至少都落后于新技术好几年）而在于先进对扩展性、性能、安全性、集成性、易用性（常被CIO所忽视其实对终端客户的影响排在第一位）等诸多应用的现实价值和升级成本的抑制。而且由于协同管理软件的价值并不仅仅依赖软件本身，其布署过程和应用推进能力也对其价值发挥起到至关重要的作用。我们绝不能忽视这样的现象――同样的软件在不同的单位对价值有截然不同的评估，所谓花巨资上马的大型软件成为摆设的情况比比皆是。我们相信CIO对于软件的评估侧重应用和技术是理性的，但我们也同时注意到，CIO对于推动组织建立新型工作行为模式的艰巨性和挑战性的重视程度不够，常在对未来技术应用发展趋势的无限可能性的苦思冥想中忽略了组织与协调成本，导致系统实施成为踏入泥潭的第一步。只有对诸如布署的阶段性、短期用户学习、中期应用感受、长期需求发展、总体拥有成本等诸多方面与软件本身的综合形成的价值观和方法论是否适合特点的客户才是评估所谓先进性的标准。

陷阱五：实施缺乏导向

实施被不少CIO理解为软件开放、安装调试、培训、测试、上线这一类的事务，但我们认为这不是实施，至少实施的目标错了。实施不是结束一个软件的部署过程，而是在这个过程中达成管理提升的目的。如果是前面所说的工作是必需的过程，那么达成管理目标才是实施的结果。遗憾的是，极少才有CIO在实施计划中明确地提出管理提升目标，最高的层次也就是具体枝节需求的满足。最理想的结果也就是安装了一套对大家没有价值感受的软件！
第六问：如何认识产品和项目对自己的意义

事实上，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项目来说，无异于根须死亡，树叶发黄凋零是迟早的事情。

产品化是中国大部分客户能接受的长期发展保障机制，项目化要想长期保障，太贵了，你想想你是否玩得起！
第七问：如何进行OA的实施阶段规划？

大部分客户的项目经理都会根据老板的期限有一个实施规划，分为调研、方案、启动会、实施、培训、测试、上线、正式运用等等，实施顾问会和你一起根据项目的大小、难度、重点去作出对应的方案。经过多年的实践，致远的实施方法论已经非常完善，有几种不同的模板，甚至能够提供启动会上董事长、总裁的发言提纲，你想大张旗鼓地推进A6的全面应用吗？给我们打电话，我们甚至会帮你搞到一份A6实施海报，上面有一个职业佳丽伫立在电脑旁，笑意吟吟地看着你的同事，旁边有文字曰：今天你协同了吗？

但这是不够的，你不过完成的是当期的实施规划，你如果了解了OA的本质，认识到这是一个长期而艰巨的组织行为变革的挑战，而你没有战略规划，你可能会把不该这个阶段完成的事情纳入进来，混淆了主要问题和次要问题，甚至会导致失败。

首先，你应该有一个长期战略规划，你需要知道OA的应用不是一蹴而就的，所以你不要期望把所有的问题在今天解决。

根据我们的经验，我们建议你至少要规划三个阶段：

第一阶段：共性应用阶段

第一阶段的使命是保障快速上线，尽快建立组织级协同方式的新的习惯和模式。你现在已经知道这个速度是非常重要的了，所以你必需对第一阶段的需求进行准确的确定，如果你不加控制，你可能会无意中设定了过多的目标，最糟的是每个部门都有自己的重点目标，大家都陷入到自己的细节需求的满足、扯皮之中，仍然没有协同起来。

我们有一句很哲学的话描述第一阶段的应用特点：最大范围的最小应用。够抽象吧，意思是你除了公文、文件夹之类必不可少的应用，你首先应该推动的是“自由协同”，自由协同会快速地让所有人感受到电脑协同方式相较于传统协同的优势，放心吧，很快，最多2周，如果你能促进每个人每天上线2-3次，那么大家都会爱上协同的。当你看到这样的情况。领导在走廊抽烟，远远的一个下属喊道，xx总，我昨天把项目材料搞完了，然后你听到x总大声地回答：好了，你把它协同发给我吧。你就知道，第一阶段大功告成了！

第一阶段是成功的第一步，不积跬步无以至千里，如果第一步倒下，就不会有未来。关于第一步的衡量指标就是我在第9问中提到的:衡量成功的简单指标的2个阀值和2个月期限。

第二阶段：深化应用阶段

即使在同一个单位，也不是每一个部门的管理水平都是一样的，同样A6的应用深度也会不同。流程繁杂的部门领导重视流程梳理和效率，文档如山的注重文档管理，知识变化快的注重知识管理，总经理工作部、办公室注重结果，项目经理注重过程和跨部门信息对称……

因此，你要在第二阶段，进行二次实施，这次是以部门为中心的管理深化，通过A6把部门管理的难点、重点通过深度实施解决掉，而且刚才说到的问题很多还需要组织保障--在部门中设置兼职岗位落实到人，这样才可以检查和推进。

如果运气好，你大约可以用半年到1年的时间完成这一切。那时候，你们单位的流程有序了，而且建立了流程设定的流程，一个又一个新流程在自由协同的实践中逐渐成熟，转化为模板，上升到制度；你们单位的每一个大一点的部门都有了肩负OA深化使用的兼职人员甚至是专职人员，并且可以考核他们。单位第一次设置了总监或副总级别的知识管理负责人，有了知识的筛选标准，强制的采集上报制度，知识贡献的激励……注意这是一场变革，没有组织保障是不行的，没有激励也是不能持久的。

第三阶段：整合应用阶段

这里的关键在于整合什么？单点登录，A6现在一配就行，A6的关联系统支持单点登录访问其他系统的松耦合，甚至支持接口数据交换方式的整合，比如U8插件能通过U8eai接口实现A6报销单－U8待记账凭证之间的转换。但你如果选择深层次两个系统之间进行数据级紧耦合，那一切都不一样了。

很多CIO错误地把深层次紧耦合整合需求当成了第一阶段目标，从一开始就自讨苦吃，要知道，整合的基础是两个或更多的系统在完成了自己的深化应用（复杂的系统都有这3个阶段）基础上才有整合的价值，如果你像我一样在软件业干了18年苦活，你一定会像我一样感慨，在通往信息化的道路上有多艰难啊。没有任何一个cio有把握能让任何一个系统都应用成功，用上1-2年就换掉系统的比比皆是，更郁闷的是系统还行，厂商死掉了，这样的情况下，需求的细节没有清楚、缺乏深度分析和前瞻性的设计、当前技术发展尚不足以支持扩展性，那么草率地把整合愿望付诸实施将成为你职业生涯的梦魇。深度整合就是项目！看过上一问的项目和产品比较你就会知道你在挑战的是你自己的综合素质的极限发挥，超越自己远远比作一个项目难。所以最后项目多半以两败俱伤、潦草收兵。

整合阶段是一场艰巨的战斗，在此之前，你务必要做好足够的细节准备，否则就是对你、对你的单位、对供应商伙伴最大的不负责任。
有CIO曾经问我，这三个阶段需要多长的时间？根据我对众多组织的信息化发展的了解，我认为三个阶段2-3年内实现，比较现实，我的建议仅供参考，谬误之处请包涵并指正。
第八问：如何建设OA项目的长期发展机制？

其实答案在阶段规划中已经谈到了，不过这次我们站在组织而不是实施的角度另外来看一看。

首先明白机制是什么，机制字面的含义是机能和体制，在组织中表现为分工和职能设置、授权、流程、考核、激励等综合反映。机制不是靠一纸公文就能搞定的，需要认真的分析和慎重决策。

从实践层面来看。我认为要想让OA成为一个组织管理的重要平台，真正发挥作用，那么必需要考虑长期发展机制。
首先要考虑解决OA的定位问题：

对项目的定位将决定项目的价值贡献和发展，由于缺乏对OA本质的了解，绝大部分客户都把OA当成了一个阶段性项目，没有意识到，如果能充分重视A6，A6将成为一个强大的战略实施的支撑平台。如果说基于互联网的库存管理系统将支撑你的企业在全国性扩张的战略，那么A6就将是你在全国范围内进行组织管理的支撑工具，无论是你收购、兼并、内部重组，A6将忠实而快速地反映组织的变化，并支撑快速的流程调整（在A6中更换模板的流程节点你甚至不用通知任何人，他们只需要用就ok了），汇总非结构化信息建立中央知识管理，与ERP的结构化信息相辅相成覆盖整个管理范畴。
其次是要解决的岗位职能设置－OA专员：

因为定位的问题，所以很少有客户能为A6的发展设计专门的岗位，如果把A6定位在一个软件，那么找个职高生来完成数据备份，定时升级之类的小事也确实无可厚非。但如果是定位在组织管理和战略实施平台，那么A6的发展将影响到整个组织能力的提升，你就不能再考虑用高中生了，你需要考虑一个在单位有多年工作经历，熟悉各个业务部门情况，具备协调组织能力、至少是对组织管理充满兴趣的人。他在你们单位是谁？他的使命是在上线后未来的2年中完成二阶段和三阶段领导。按照我的理解，非资深人士不可，而且他还得不断学习。

另外随着应用的深化，要设置的岗位有：部门知识管理员、HR部门或企管办执行力和文化建设的监督员来配合，当然，这些人只需兼职即可。
第三是授权：

即使设置了专人，我还是很难相信业务部门那些扛销售指标的中干甚至是高层大爷们会对一个这样一个角色充满敬意，出于人性的原因，他们会不自觉的抵抗任何改变习惯的变革，他们会因为打字慢而不愿意输出任何东西，他们会解释说销售压力大、事情多，没时间学习，没时间打字，给你电话汇报就行了，这时候你该如何？

作为企业管理者，你必需对OA专员授权，并且在公众场合，你可以审查他的规划，避免他过度实施干扰正常业务，但你也必需在众人面前给他树立威信，给他对不按照审定的规划进展的部门或人有处罚的建议权。

第四是制度化保障：

如果要在一个组织中推出一个重要的举措，那么就不是仅仅通过公告告知那么简单的了，你应该考虑制度化，你应该建立“xx单位OA使用规范”，把OA的使用变成制度、使之合法化，明确高压线--那些绝对不能违背的事情（比如非出差生病的情况下多日不上线之类的）和处罚标准（最好是经济手段）。

第五是正向激励：

如果变革没有好处，谁愿意变？所以激励很重要，激励不是心血来潮的赏罚，除了处罚，我们应该去创造更多的奖励，我们可以结合知识管理设置知识贡献奖，可以征求对流程的建议给流程优化奖，可以鼓励员工在论坛分享竞争情报，鼓励管理建议，奖励部门文档管理水平率先达标的团队，第一个使用关联项目进行跨部门协同的动态团队……鼓励表彰的过程中，企业的价值观中推崇什么一目了然，文化逐渐成型。
这一过程中，领导的参与也是一种奖励，更多的管理者应该习惯于在论坛中回复基层员工对战略的问题，通过论坛了解组织运转的问题，及时提到解决日程中来。

最后只有一个需要解决的问题：谁与你同行？

从未来的理想远景中回过神来吧，就算你明白了所有的道理，你还是要在今天对这些所有的思考转化一个基本的决策，你将选择哪一家OA供应商作为支撑OA长期发展的伙伴？正如你想象的那样，你要选择的供应商不仅产品要有关联理念，符合组织管理的需要，还要功能设计的非常简易，能帮助你快速达成一阶段的成功，更要有对组织管理实践的深入认知，能给你提供咨询和建议，最最重要的是要命长，能存活到你成功的那一天！
第九问：OA成功的简单量化标准是什么？

衡量一个抽象的事物非常复杂，你会检查标书和实施计划中的子项目标是否在实施期限内达成。另外一个简单的方法就是在是实施启动的第６０天检查你们单位两个指标是否达到了应用阀值。

检验实施成功有两个阀值：

应用范围值A  阀值＝人均上线频率>1次/人*天。

举例：如果注册客户是300，那么300人每人每天应该有1次上线（A6有专门的后台统计功能可以查询到），A6现在已经实施的客户一般都>1.2。如果A值达不到阀值，应用范围会急剧缩减到少数积极的用户，大多数人会因上网交出去的协同事情没有当天处理而受到负激励，不再从网上协同回复到地面协同。如果达到，可以保持一个及格水平，但需要达到b才开始向深化应用发展。

应用效率值B  阀值＝注册人员经常性在线率>30%。

举例：A6注册客户300，那么经常会有100人在线。 b值是响应效率，当b>30%时，响应的及时性会提高，A6的协同性效果会显著超过传统行为模式，从而使协同请求者和协同处理者都产生正激励效应，会越用越好。这样的用户通常会扩并发，A6已经有很多这样的客户。

时间约束条件＝2个月

实施上线2个月内必须一鼓作气达成这两个值，否则再三而竭，组织不再兴奋，无心学习，二次实施很难成功。2个月之内实施效果不能达到AB阀值要求的项目风险会大大增加。

另外我们还有一套经验计算公式，可以计算OA的直接效益和投入产出比，帮助CIO在作项目效益分析时为领导提供决策的依据。
此外，真正衡量OA成功的是管理贡献，那将是一个更加复杂的话题，其中推动管理的创意和实践结果是非常有趣和最有价值的。