CIO关于OA的九个问题(1)
在大多数CIO的印象中，已有15年以上应用历史的OA（OfficeAutomation），其技术难度不高，实施不难，而实际上，OA项目的成功率极低。是什么原因导致OA项目的成功率不到15%，如何保证其成功实施？
由于工作的原因，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项目成功的要素有哪些？
&n
bsp; 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是否有这样的一个功能能够满足这个共性需求！
陷阱三：实施急功近利
如果你认为软件只要会编程就能做，那你可就大错
特错了！写程序是邻居家的高中男孩就能干的事情。
软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”；经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成“应用设计”，评审后才会有“代码开发”，然后是“功能测试”，最后才能交给你。这期间，所有的环节都应该是最优秀的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。