搜索
1目录选型指南...................................................................................................................................11、认识协同.............................................................................................................................11.1认识OA...............................................................................................................................11.2OA项目的本质是什么？...................................................................................................21.3认识需求.............................................................................................................................31.4项目风险.............................................................................................................................41.5价值评估.............................................................................................................................62、如何选型...........................................................................................................................102.1方案选型...........................................................................................................................102.2规格选型...........................................................................................................................122.3阶段规划...........................................................................................................................132.4售前咨询...........................................................................................................................14选型指南1、认识协同1.1认识OA你想要什么？这个问题看上去很可笑，如果不是准备找OA或协同软件，为什么到网上去查看相关资料。不过我们想探讨的是更深层次的目标以及与之相关的重要因素，如果那些问题在你的头脑中过于朦胧，那么无论你是否选择A6还是其他的OA产品，失败的可能性都远远超出你的想像。根据我们的经验，用户常低估OA成功的难度，究其原因是缺乏对OA项目本质的清楚认识。第一个认识误区：OA项目是很容易成功的。2大部分OA项目的负责人，都会认为这是一个小CASE，主要是办公室的人用，主要的功能是减少打印纸的消耗量；论技术水平的难度远远低于ERP、BI之类的项目；造价当然也会低很多；甚至自己身边所有作IT的朋友都说自己作过几家单位的OA，保证你能几个月就搞定这个事情。如果你足够冷静和理性，你可以想像一下，这么多年来，在你的单位周围方圆5公里的范围内，从来没有你的同行或朋友向你炫耀过他们的OA的成功，是这样吧？事实的真像是OA项目实施成功率只有15%，过去的15年中这个比例更低。有很多比你的单位更有钱、计算机技术资源更雄厚的特大型企业，用了你不敢想像的庞大预算去实施过OA，绝大部分项目的结果还是黯然失败，最好的情况就是花了150万，大约只有25个办公室人员在用公文，其他人一概评价说，那玩意儿不大好用，我的很多工作在上面作不了。也许你会想，没准是他们太笨了，需求搜集不完善，我会把白纸发给每一个部门和人员，把大家的需求都提取出来，逐一实现，这样OA就将成为一个对我们日常工作有价值的IT项目。如果你这么想，那么你离他们的结局就不远了，因为他们的需求不是太简单，而是太完善了，完善到了足以让一个CIO和供应商葬身泥潭。第二个认识误区：行政驱动就能成功更聪明的你也许会从另一个角度想，是他们的信心不够坚决，如果是我，我一定要让总经理亲自下发一个公文，召集所有的中层干部开一个会，制定使用OA的规定，处罚一切该用OA而不用的OA的人，让所有不会用电脑的人下岗。如果你这么想，至少你的思考方向是对了，不过糟糕的是你太极端了，你应该去为自己买一份人身安全的保险。而且你太乐观了，你能保证你的软件能真的适应不同部门的不同人员的工作的需求吗？要知道你甚至都不清楚他们的工作细节。更加可能的情况是，在领导赋予了你大权去推进OA后，对软件的抱怨、反对的声音越来越大，而且证据言之凿凿，最后领导只好杀了你以谢天下。所以本文开始的哪个问题比你想像的更加复杂和深奥，如果你希望得到正确的答案，那么请让我们从以下的认知开始走向成功。1.2OA项目的本质是什么？OA项目和上一个财务软件不一样的是它的应用范围决定了它是一个“全员信息化”的大事，这期间，应用范围的量变积累已经使得项目产生了质变的层面，已经涉及到了整个组织的“行为变革”范畴，这在管理学中一个大大的事件甚至需要用革命来形容。也许HR软件或者进销存软件使用失败了没有什么，甚至别的部门根本就不知道发生过，但OA不同，从上线那一天起，到最后无论好坏，每个人都知道你干过一件漂亮或者很糗的事情。记住：OA项目的本质是一种组织行为变革的工具。绝大部分CIO都是可爱的技术爱好者，也正因为技术的原因被领导指派作为OA项目负责人。不过组织行为学和组织管理学并不是CIO的擅长，所以CIO难以了结或者描述OA3的价值，失去了以组织行为管理的价值准绳，只能凭借技术作为判断方向的依据，这样的选型想不失败都很难。所以，你现在要清楚，可能并不熟悉管理的你要去推动一场组织行为的变革，代号是OA，你将在未来几个月中改变原来那些你熟悉的人的行为模式，把他们从电话、面谈、会议中拽出来，给他一个OA，让他们比以前的行为模式更加有效率，甚至感到比以前工作起来更快乐。如果你选的产品或者方案让他们感觉很痛苦，他们会以没有时间学习、不好用等各种理由抵抗你，你应该知道改变整个组织的行为习惯是非常困难的，习惯是人性的一部分，改变习惯就是扭曲人性，那种痛苦你如果戒过烟就明白了。现在你面临的情况更糟，就像你需要让200个烟鬼集体戒烟或者300个懒人准时起床晨练那么难。还有，面对领导的信任，退出已经来不及了。掌握如何通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。1.3认识需求如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，那么你就离失败不远了。如何认识自己的需求？99.99%的OA需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。把一叠白纸发给单位内各个部门的10天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧.也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给OA。依照这种需求，世上没有一套现成的软件能够100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案，依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？4我们研究发现这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个？请不要轻率地回答这个问题，你说用公文？别逗了，公文只有组织中不到10%经常用；文档？文档可以分享，不过文档不能主动产生协同；IM？IM好像不能进行表单审批吧；邮件？邮件能作流程化审批吗？邮件能使得整个组织共享吗？邮件用于要事的授权你既不知道过程也不知道结果你能放心吗？要用邮件来完成组织的日常协同我们还作OA项目干什么？所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，对本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了？没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求，我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需求，那个词叫协同。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果，无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎80%可以归结为这个需求。所以你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求！另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。1.4项目风险正如你前文所知道的，现实中OA失败的例子远远多于成功的例子。当你面对领导的信任和同事的期望，承担起建设一个涉及全局的IT应用系统的责任的时候，难免心潮澎湃，涌起建功立业的雄心壮志，希望无论于公于私都将此项目作成职业生涯中的一个里程碑。在这种心态的影响下，你可能不知不觉地滑入了一个新的误区。失败案例：当全部需求都被供应商满足了之后，雄心勃勃的项目负责人在上线的头三个月内，被各种细节需求的满足性问题拽得到处团团跑，拼命催促项目开发商供应补丁修正程序，然而，这种未经仔细设计、严格测试的“急就章”式的补丁却带来了更多的bug，熬了多个通宵之后，项目负责人惭愧地向单位领导承认，我们无法在预定的时间上线了，问5题多到了各个部门都不满意的程度，原因不能简单地责怪供应