第一问:OA的成功率有多高? 问题,客户大部分认为相比ERP而言,OA技术难度不高,应用也不深奥,无需太多专业知识背景,只要领 导一纸红头文件,就能顺利成功。 ,根据笔者在2002年调研走访客户后得到的数据是低于15%,这大大低于用户和业界的感觉,其失败率直 逼ERP。笔者也常问客户:你单位方圆5公里范围内有成功的OA客户吗?或者你行业内哪个单位的OA用得 不错?大多数时候,答案是否定的或者不知道。笔者知道的一个单位曾经投资近百万元人民币建设Notes系 统,实施范围1100人,但最后只有不到50人在上面用公文,可谓昂贵的摆设。其实深入了解,并非Notes 不好,失败是另有原因的。 ,能够上传文件,有Email、论坛就算OA了;也有以公文、文档为主流的,更有极其复杂与MIS、ERP、指挥 调度、监控集成在一起的大型项目,但基本上上线率都大大低于实际应用覆盖范围。15%的成功率其实是 个乐观值,在笔者看来,所谓OA成功者,大部分都是处于较为朦胧的价值认识情况下的初级自我满足。 苦心孤诣整理的需求可能许多与战略并无重要紧急的关系,只不过是个人的软件细节偏好。 ,是全员参与的一场革命洗礼。 变积累已经使得项目产生了质变的层面,已经涉及到了整个组织的“行为变革”范畴,也许eHR软件或进销存 软件使用失败了没有什么,甚至别的部门根本就不知道发生过,但OA不同,从上线那一天起,到最后无论 好坏,每个人都知道你干过一件漂亮或者很糟糕的事情。 和组织管理学并不是CIO的擅长,所以CIO难以了解或者描述OA的价值,失去了以组织行为管理的价值准绳 ,只能凭借技术作为判断方向的依据,这样的选型想不失败都很难。 个月中改变原来那些你熟悉的人的行为模式,把他们从电话、面谈、会议中拽出来。从本质上说,掌握如何 通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。因为OA是在用创造力开创管理软件 业中另一大分支——组织管理软件,是在将新技术不断带入这一范畴中,把软件变成对组织中每一个人都有 价值的工具。 度作为最高权重指标,另外关注的是技术的先进性和安全性等等,这些都过于偏重技术了。他们到底忽略了 什么?笔者看过一份IDC专门的调查研究报告,与笔者实践中求证的答案一样,那个答案却是CIO背景的人 最容易忽视的。 质是组织行为模式的变革,特别是协同模式的变革。 间之后,通过项目化开发得到了满足,但实际情况是根本没有人愿意用,是什么导致了这些需求的提供者拒 绝使用系统? 在那些成功的OA案例中,位高权重的领导者常常是最早上线、最晚下线的人群之一。另外就是群众的高度 参与,在评估成功的关键阀值中我们提到应用范围值就是这个特性的量化。 出来专门去从事学习的,我们可以把财务部几十个人停下来专门学习财务软件,加班加点在电脑上重新输入 凭证、记账,但我们无法让整个组织停下来3个工作日,专门学习OA软件,最多是轮流培训2天,绝大多数 是一天甚至半天。 解组织行为学,如果再不具备对OA的哲学认知,会在相当程度上忽略易用性。以前的OA失败,至少有50% 可以归罪为易用性问题。 多周全,都是穷举模式的,而组织行为是无法穷举的,即使一一满足那些穷举的需求,你可能发现仍然有 80%的事情无法在OA上处理。过去OA失败的原因就是只做关键性应用,如我们熟知的公文、文档管理、办 公室常用的功能等,就算有流程化审批,也只能穷举部分组织级审批,到部门级就太多了,干脆就不做了。 他们草率地把80%的无法穷举的应用需求的责任推给了邮件!套用那句“名言”的语法: “如果道歉有用,还 需要警察做什么?”如果邮件能解决还要OA干什么?” 能对易用性容易理解,但对实用性却没有深入认识,我们通过大量调研,才认识到第二个问题,那是传统 OA失败的根本原因之一。 略眼光来思考,不能把OA作为急就章项目来看待,在笔者看来成功的要素至少有三点。 择真的就能成功吗?为什么那么多能够理清自己需求的项目仍然不成功?这是因为没有搞清楚产品和项目对 自己的意义。 ,笔者所在的用友致远在长期的客户实践中,总结了实施三段论(共性应用的二八原则、局部深化、集成应 用),因为涉及到很多方面,限于篇幅,笔者在后面的“如何实施阶段规划”中讨论。 拍胸口的豪言壮语,你必须清楚,一切可持续的事物都不是靠愿望,而是某种内在的东西在支撑。 和正确决策是保障项目成功的关键中的关键。因此下一问中我们先不对上面三个分支问题做出深入的阐述, 我们从另一个角度,即那些曾经失败的CIO为何踏入了所谓OA的“CIO陷阱”来了解更多的细节。 建设职责的同时,不少CIO却也还满怀激情地冲向陷阱。 施阶段规划) 何认识自己的需求? 近20年几乎所有的OA都走项目化,或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的,那简 直就是自杀,这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。 而且充满着本来应该归纳到业务范畴的应用需求,甚至包含着个别领导的软件嗜好。依照这种需求,世上没 有一套现成的软件能够100%地满足。依据这样的需求开发出来的OA软件,可能功能看上去非常丰富,但 实际上却形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的,最后大家用起来一头雾水 ,这些看上去都是我们想要的功能为何总感觉那么别扭?问题到底出在哪? 在一起的功能是哪个? 文档不能主动产生协同;IM(即时通信)?IM并不能进行表单审批;邮件?邮件能完成流程化审批吗?能用 邮件来完成组织的日常协同,我们还实施OA项目干什么? 的需求,最后才是重要角色的需求。我们先后研究了中国数十家OA厂商,走访了数十家OA成功或失败的客 户,仔细评估了超过200种常见OA的功能菜单,最后找到了那个共性的需求,这就是协同。你在选型的时 候一定要看,这个OA是否有这样的一个功能能够满足这个共性需求! 和检验标准。从需求开始,有专业的人员进行需求的采集、提炼、评估,形成应用的“概念设计”;经过评审 后,技术高手会充分考虑诸多因素后提出“构架设计”,评审后才会到开发部形成“应用设计”,评审后才会有 “代码开发”,然后是“功能测试”,最后才能交给你。这期间,所有的环节都应该是最优秀的人力资源在保障 质量,所以你千万不要指望找到一个非常廉价还百依百顺的供应商,根据你的指令快速而完美地帮你达成目 标。 可厚非,但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性而言是高风险和高成本的。 视,其实对终端客户的影响排在第一位)等诸多应用的现实价值和升级成本的抑制。而且由于协同管理软件 的价值并不仅仅依赖软件本身,其部署过程和应用推进能力也对其价值发挥起到至关重要的作用。我们绝不 能忽视这样的现象:同样的软件在不同的单位对价值有截然不同的评估,所谓花巨资上马的大型软件成为摆 设的情况比比皆是。 工作行为模式的艰巨性和挑战性的重视程度不够,常在对未来技术应用发展趋势的无限可能性的冥思苦想中 忽略了组织与协调成本,导致系统实施成为踏入泥潭的第一步。 少实施的目标错了,不是结束一个软件的部署过程,而是在这个过程中达成管理提升的目的。如果前面所说 的工作是必需的过程,那么达成管理目标才是实施的结果。遗憾的是,极少有CIO在实施计划中明确地提出 管理提升目标,最高的层次也就是具体枝节需求的满足。最理想的结果也就是安装了一套对大家没有价值感 受的软件! 施的支撑平台。 程度、管理成熟度不同的客户对OA的期望值是不同的,另外CIO的技术偏好会导致对需求的客观性认识不 足。 化实际上是一个复杂的商业系统,是由需求流程、概念设计、架构设计、程序代码、测试流程、销售、实施 交付、售后服务、升级服务等多种岗位专业人员协作构成的。 并且可以持续升级,是成熟的象征,它是与客户的长期合作,如同婚姻。产品化还意味着高性价比,这是绝 大部分客户所关注的。产品化总的来说是低风险的。 ,可以通过该厂商的网站上识别。产品化供应商能看升级公告,没有版本升级公告的则属于“李鬼”。 与你需求的成长速度之间的匹配是个问题,这就需要你在产品化厂商中选择那些内部资源雄厚、流程顺畅、 支撑保障机制健全的厂商。 码的多少。 客户就最好不要相信花1万元就能完成一个好项目;二是周期长的,短期赶出来的不可能没有问题,看看微 软这么伟大的公司还有不少Bug呢,项目漫长的测试、优化周期造成了高成本;三是供应商的商业模式造成 的,如果是项目型的厂商,只能尽可能通过每一个项目的价格最大化回报来挣钱,因为它们没有把握像产品 化公司一样能够通过客户数量挣钱。 实现、完善的测试,所有这些环节,都需要客户和供应商双方投入最顶尖的人力资源,才足以做到业界一流 水平。不幸的是,一个供应商只能有一两个顶尖项目经理,他不可能在每一个项目上投入,而客户方更是稀 缺能够精通OA、具备战略思维、又能细致深入把握需求、协调实施的项目经理,这种人月薪身价都是在2万 元人民币以上的。所以我们不难理解为什么有这么多OA的“烂”项目,很大程度上,就是二三流人员在瞎折 腾。在前面提到的这些环节中任何一个失误都会让客户未来付出代价。 续研究、优化、升级?在技术日新月异的今天,没有最好的,只有更好的。 客户还是期望在购买时获得承诺,满足产品化尚无法满足的个性化需求。这种情况下,导致了第三种模式的 出现:产品化+局部定制。 ,那么没有问题;如果产品化的技术架构不支持,客户的需求如果要满足,就只能以调整架构,牺牲升级来 换取。以用友致远的A6为例,其架构最早根本不支持,现在开始逐步支持,逐步成体系,这是一个漫长的 成长过程,需要漫长的实践积累才能保证软件接口的成熟度。 法达成的覆盖性测试,这些测试中的Bug反馈和需求反馈又进一步导致了产品加速完善。最重要的是使得客 服能够形成版本知识库,有了这样的知识库,客服人员能够回答几乎90%稀奇古怪的问题——其中大部分是 IT环境问题(病毒、插件、IE版本、补丁等),而且并不会因人员的变动导致服务质量下降。总之,产品化 让我们见多识广,知识库让我们专业化,众多的客户经验让我们从解决问题上升为专家指导。 项目经理转移到其他项目,对OA项目来说,无异于根须死亡,树叶发黄凋零是迟早的事情。 否玩得起! 、测试、上线、正式运用等,实施顾问会和你一起根据项目的大小、难度、重点去制订对应的方案。 发言提纲,但这是不够的,你完成的不过是当期的实施规划,你如果了解OA的本质,认识到这是一个长期 而艰巨的组织行为变革的挑战,而你没有战略规划,你可能会把不该在这个阶段完成的事情纳入进来,混淆 了主要问题和次要问题,甚至会导致失败。 都能在今天解决。 非常重要的了,所以你必须对这一阶段的需求进行准确的确定,如果你不加控制,你可能会无意中设定了过 多的目标,最糟的是每个部门都有自己的重点目标,大家都陷入到自己的细节需求的满足、扯皮之中,仍然 没有协同起来。 必不可少的应用,你首先应该推动的是“自由协同”,自由协同会快速地让所有人感受到电脑协同方式相较于 传统协同的优势。很快,最多两周,如果你能促进每个人每天上线2~3次,那么大家都会爱上协同的。当 你看到这样的情况:领导在走廊抽烟,远远的一个下属喊道:“x总,我昨天把项目材料搞完了!”然后你听 到x总大声地回答:“好了,你把它协同给我吧。”你就知道,第一阶段大功告成了! 将在第9问中提到:衡量成功的简单指标的2个阀值和2个月期限。 部门领导重视流程梳理和效率,文档如山的注重文档管理,知识变化快的注重知识管理,总经理工作部、办 公室注重结果,项目经理注重过程和跨部门信息对称…… 通过深度实施解决掉,而且刚才说到的问题很多还需要组织保障——在部门中设置兼职岗位落实到人,这样 才可以检查和推进。 程设定的流程,一个又一个新流程在自由协同的实践中逐渐成熟,转化为模板,上升到制度;你们单位的每 一个大一点的部门都有了肩负OA深化使用的兼职人员甚至是专职人员,并且可以考核他们。单位第一次设 置了总监或副总级别的知识管理负责人,有了知识的筛选标准、强制的采集上报制度、知识贡献的激励…… 注意这是一场变革,没有组织保障是不行的,没有激励也是不能持久的。 自讨苦吃。要知道,整合的基础是两个或更多的系统在完成了自己的深化应用(复杂的系统都有这3个阶段 )基础上才有整合的价值,如果你像笔者一样在软件业干了18年苦活,你一定会像笔者一样感慨,在通往 信息化的道路上有多艰难!没有任何一个CIO有把握能让任何一个系统都应用成功,用上1~2年就换掉系统 的比比皆是,更郁闷的是系统还行,而厂商已死掉了,这样,需求的细节没有清楚、缺乏深度分析和前瞻性 的设计、当前技术发展尚不足以支持扩展性,那么草率地把整合愿望付诸实施将成为你职业生涯的梦魇。 ,超越自己远远比完成一个项目更难。所以,最后项目多半以两败俱伤而草草收兵。 段2~3年内实现,比较现实。这里的建议仅供参考,谬误之处请包涵并指正。 、激励等综合反映。机制不是靠一纸公文就能搞定的,需要认真的分析和慎重决策。 展机制。 段性项目,而没有意识到,如果能充分重视OA,OA将成为一个强大的战略实施的支撑平台。如果说基于互 联网的库存管理系统将支撑你的企业全国性扩张的战略,那么OA可以成为你在全国范围内进行组织管理的 支撑工具,无论是收购、兼并、内部重组,OA都将忠实而快速地反映组织的变化,并支撑快速流程调整, 汇总并建立中央知识管理,与ERP的结构化信息相辅相成覆盖整个管理范畴。 高生来完成数据备份,定时升级之类的小事也确实无可厚非。但如果定位在组织管理和战略实施平台,那么 OA的发展将影响到整个组织能力的提升,你就不能再考虑用高中生了,你需要考虑一个在单位有多年工作 经历,熟悉各个业务部门情况,具备协调组织能力、至少是对组织管理充满兴趣的人。他在单位如何?他的 使命是在上线后未来的2年中完成对二阶段和三阶段的领导。按照笔者的理解,非资深人士不可,而且他还 得不断学习。 当然,这些人只需兼职即可。 充满敬意,他们会不自觉地抵抗任何改变习惯的变革,他们会因为打字慢而不愿意输出任何东西,他们会解 释说销售压力大、事情多,没时间学习,没时间打字,给你电话汇报就行了,这时候你该如何? 常业务,但你也必须在众人面前给他树立威信,给他对不按照审定的规划取得进展的部门或人员有处罚的建 议权。 应该建立“xx单位OA使用规范”,把OA的使用变成制度、使之合法化,明确高压线——那些绝对不能违背的 事情(比如非出差生病的情况下多日不上线之类的)和处罚标准(最好是经济手段)。 多的奖励,我们可以结合知识管理设置知识贡献奖,可以征求对流程的建议给流程优化奖,可以鼓励员工在 论坛分享竞争情报,鼓励管理建议,奖励部门文档管理水平率先达标的团队,表彰第一个使用关联项目进行 跨部门协同的动态团队……在鼓励和表彰的过程中,企业的价值观中推崇什么一目了然,文化逐渐成型。 过论坛了解组织运转的问题,及时提到解决日程中来。 基本的决策,你将选择哪一家OA供应商作为支撑OA长期发展的伙伴?正如你想象的那样,你要选择的供应 商不仅其产品要有关联理念,符合组织管理的需要,还要功能设计得非常简易,能帮助你快速达成阶段的成 功,更要有对组织管理实践的深入认知,能给你提供咨询和建议,最最重要的是要寿命长,能存活到你成功 的那一天! 另外一个简单的方法就是在实施启动的第60天检查你们单位两个指标是否达到了应用阀值。 减到少数积极的用户,大多数人会因上网交出去的协同事情没有当天处理而受到负激励,不再积极从网上协 同,而回复到地面协同。如果达到,可以保持一个及格水平,但需要达到下一个阀值才能开始向深化应用发 展。 OA的协同性效果会显著超过传统行为模式,从而使协同请求者和协同处理者都产生正激励效应,会越用越 好。 再兴奋,无心学习,二次实施很难成功。2个月之内实施效果不能达到A和B阀值要求的项目风险会大大增加 。当然,也有一些经验计算公式可以计算OA的直接效益和投入产出比,帮助CIO在进行项目效益分析时为 领导提供决策的依据。 为有趣和有价值的。 |
|