CIO关于OA的九个问题

由于工作的原因，5年以来笔者认识了许多CIO并成为了朋友。回顾笔者和他们认识的过程，几乎都源于OA选型，这个过程中，笔者注意到一个有趣的现象：越是大型或特大型企业的CIO，在OA项目选型时越是谨慎（因为他们在OA项目上大都经历过挫折）。而与之相反，越是年轻的、单位小一些、初次选型OA的CIO，越是信心十足。

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

后来笔者逐渐明白，正是这种认知上的先天不足导致在中国过去的15年中，超过10万套上马的OA项目成为了毫无价值的摆设和2～3年即废弃的项目。这一现象激起了笔者的兴趣，笔者开始关注OA项目的选型和事实的价值观和方法论，经过总结，笔者从保障项目成功的角度归纳出9个问题。这9个问题涉及对OA的初步认知，也涉及对本质的探讨，希望与业界同仁共勉。其中还有些问题内涵十分丰富，这里无法展开，有兴趣的朋友可以与笔者交流。

上篇：认识OA的本质

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

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

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

笔者估计在过去的15年中，中国至少有5000家厂商以项目的方式交付过10万套OA，有的简单得如同网站，能够上传文件，有Email、论坛就算OA了;也有以公文、文档为主流的，更有极其复杂与MIS、ERP、指挥调度、监控集成在一起的大型项目，但基本上上线率都大大低于实际应用覆盖范围。15%的成功率其实是个乐观值，在笔者看来，所谓OA成功者，大部分都是处于较为朦胧的价值认识情况下的初级自我满足。

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

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

这个问题有点像哲学命题，但却是CIO非搞清楚不可的问题，否则将无法建立这个项目与管理的支撑关系，苦心孤诣整理的需求可能许多与战略并无重要紧急的关系，只不过是个人的软件细节偏好。

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

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

记住：OA项目的性质是一种组织行为变革的工具。

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

所以，作为CIO要清楚，可能并不熟悉管理的你要去推动一场组织行为的变革，代号是OA，你将在未来几个月中改变原来那些你熟悉的人的行为模式，把他们从电话、面谈、会议中拽出来。从本质上说，掌握如何通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。因为OA是在用创造力开创管理软件业中另一大分支——组织管理软件，是在将新技术不断带入这一范畴中，把软件变成对组织中每一个人都有价值的工具。

第三问：OA项目面临哪些挑战？

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

1. 易用性

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

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

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

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

因此有个规律：应用范围越大的系统，其学习成本要求就应该越低，这里易用性是最大的挑战之一。

CIO相对组织中其他人员来说，他太了解电脑了，这也是被挑选出来承担OA选型责任的原因，但他又不了解组织行为学，如果再不具备对OA的哲学认知，会在相当程度上忽略易用性。以前的OA失败，至少有50%可以归罪为易用性问题。

2. OA的粘着度

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

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

第四问：

OA项目成功的要素有哪些？

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

1．正确地选择产品或者项目方案。

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

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

常见的对实施的认识大多局限于软件安装、公文流程定义、表单设计等等，大部分都缺乏对实施的整体认识，笔者所在的用友致远在长期的客户实践中，总结了实施三段论（共性应用的二八原则、局部深化、集成应用），因为涉及到很多方面，限于篇幅，笔者在后面的“如何实施阶段规划”中讨论。  

3．持续服务和持续升级

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

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

第五问：CIO陷阱有哪些？

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

陷阱一：缺乏长期规划

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

陷阱二：需求贪大求全

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

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

让我们仔细看看这份需求吧！也许每个部门都提出了自己的需求，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包含着个别领导的软件嗜好。依照这种需求，世上没有一套现成的软件能够100%地满足。依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上却形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？

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

请不要轻率地回答这个问题，有人说用公文？公文只有组织中不到10%经常用；文档？文档可以分享，但文档不能主动产生协同；IM（即时通信）？IM并不能进行表单审批;邮件？邮件能完成流程化审批吗？能用邮件来完成组织的日常协同,我们还实施OA项目干什么？

所以你必须从繁杂浩瀚的细节中脱出身来，放下本位主义，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。我们先后研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求，这就是协同。你在选型的时候一定要看，这个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项目来说，无异于根须死亡，树叶发黄凋零是迟早的事情。

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

第七问：

如何制订OA实施阶段规划？

大部分客户的项目经理都会根据老板的期限制订一个实施规划，分为调研、制订方案、启动会、实施、培训、测试、上线、正式运用等，实施顾问会和你一起根据项目的大小、难度、重点去制订对应的方案。

经过多年的实践，OA的实施方法论已经非常完善，有几种不同的模板，甚至能够提供启动董事长、总裁的发言提纲，但这是不够的，你完成的不过是当期的实施规划，你如果了解OA的本质，认识到这是一个长期而艰巨的组织行为变革的挑战，而你没有战略规划，你可能会把不该在这个阶段完成的事情纳入进来，混淆了主要问题和次要问题，甚至会导致失败。

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

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

第一阶段：共性应用阶段

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

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

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

第二阶段：深化应用阶段

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

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

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

第三阶段：整合应用阶段

这个阶段的关键在于整合什么？很多CIO错误地把深层次紧耦合整合需求当成了第一阶段目标，从一开始就自讨苦吃。要知道，整合的基础是两个或更多的系统在完成了自己的深化应用（复杂的系统都有这3个阶段）基础上才有整合的价值，如果你像笔者一样在软件业干了18年苦活，你一定会像笔者一样感慨，在通往信息化的道路上有多艰难！没有任何一个CIO有把握能让任何一个系统都应用成功，用上1～2年就换掉系统的比比皆是，更郁闷的是系统还行，而厂商已死掉了，这样，需求的细节没有清楚、缺乏深度分析和前瞻性的设计、当前技术发展尚不足以支持扩展性，那么草率地把整合愿望付诸实施将成为你职业生涯的梦魇。

深度整合就是项目！看过上一问的项目和产品比较你就会知道，你在挑战的是你自己的综合素质的极限发挥，超越自己远远比完成一个项目更难。所以，最后项目多半以两败俱伤而草草收兵。

有CIO曾经问我，这三个阶段需要多长的时间？根据笔者对众多组织的信息化发展的了解，笔者认为三个阶段2～3年内实现，比较现实。这里的建议仅供参考，谬误之处请包涵并指正。

第八问：如何建立OA项目的

长期发展机制？

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

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

从实践层面来看。笔者认为要想让OA成为一个组织管理的重要平台，真正发挥作用，那么必须考虑长期发展机制。

首先要考虑解决OA的定位问题。

对项目的定位将决定项目的价值贡献和发展，由于缺乏对OA本质的了解，绝大部分客户把OA当成了一个阶段性项目，而没有意识到，如果能充分重视OA，OA将成为一个强大的战略实施的支撑平台。如果说基于互联网的库存管理系统将支撑你的企业全国性扩张的战略，那么OA可以成为你在全国范围内进行组织管理的支撑工具，无论是收购、兼并、内部重组，OA都将忠实而快速地反映组织的变化，并支撑快速流程调整，汇总并建立中央知识管理，与ERP的结构化信息相辅相成覆盖整个管理范畴。

其次是要解决岗位职能设置，设立OA专员。

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

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

第三是授权。

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

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

第四是制度化保障。

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

第五是正向激励。

如果变革没有好处，谁愿意变？所以激励很重要，激励不是心血来潮的赏罚，除了处罚，我们应该去创造更多的奖励，我们可以结合知识管理设置知识贡献奖，可以征求对流程的建议给流程优化奖，可以鼓励员工在论坛分享竞争情报，鼓励管理建议，奖励部门文档管理水平率先达标的团队，表彰第一个使用关联项目进行跨部门协同的动态团队……在鼓励和表彰的过程中，企业的价值观中推崇什么一目了然，文化逐渐成型。

这一过程中，领导的参与也是一种奖励，更多的管理者应该习惯于在论坛中回复基层员工对战略的疑问，通过论坛了解组织运转的问题，及时提到解决日程中来。

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

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

第九问：你的OA系统成功吗？

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

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

应用范围值A：人均上线频率 > 1次/人·天。

如果注册客户是300人，要求300人每人每天应该至少有1次上线。如果A值达不到阀值，应用范围会急剧缩减到少数积极的用户，大多数人会因上网交出去的协同事情没有当天处理而受到负激励，不再积极从网上协同，而回复到地面协同。如果达到，可以保持一个及格水平，但需要达到下一个阀值才能开始向深化应用发展。

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

比如，注册客户300人，要求经常会有100人在线。B值是响应效率，当B>30%时，响应的及时性会提高，OA的协同性效果会显著超过传统行为模式，从而使协同请求者和协同处理者都产生正激励效应，会越用越好。

另外，还有个时间约束条件，也就是实施上线2个月内必须一鼓作气达成这两个值，否则再三而竭，组织不再兴奋，无心学习，二次实施很难成功。2个月之内实施效果不能达到A和B阀值要求的项目风险会大大增加。当然，也有一些经验计算公式可以计算OA的直接效益和投入产出比，帮助CIO在进行项目效益分析时为领导提供决策的依据。

此外，真正衡量OA成功的是管理贡献，那将是一个更加复杂的话题，其中推动管理的创意和实践结果是最为有趣和有价值的。

后记

关于OA的9个问题，是笔者这几年对OA的认识的一个总结。文中为了阅读感受，不少地方将CIO作为了第二人称的探讨对象，恐有咄咄逼人之感，但并非笔者本意。笔者并不想指责CIO，也没有资格以CIO的导师自居，笔者期望的是与CIO进行客观、坦诚、深入的交流。事实上笔者的探索认知正是来自于笔者的CIO朋友们无私坦诚的分享，甚至包括他们曾经经历过的失败教训。这里笔者不过是将这些心得整理出来，与那些从未谋面的CIO朋友分享，希望能为大家在实施OA选型和实施过程中提供参考。只有通过我们共同的努力，我们才有可能实现双赢！

张屹国内知名的产品化OA软件供应商用友致远软件技术有限公司创始人之一、常务副总裁。IT从业18年，曾于1998年发起连邦软件店，任主管副总裁；2000年联合创办8848电子商务网站，任资深副总裁。对产品、市场、销售有着丰富的实践管理经验。对用友致远的主要产品A6的成功推出具有举足轻重的作用。(ccw)