关于OA的9个问题

关于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的成功实施第六问：要产品还是要