OA协同软件选型指南.docx

目录选型指南1、认识协同1.1认识OA你想要什么？    这个问题看上去很可笑，如果不是准备找OA或协同软件，为什么到网上去查看相关资料。不过我们想探讨的是更深层次的目标以及与之相关的重要因素，如果那些问题在你的头脑中过于朦胧，那么无论你是否选择A6还是其他的OA产品，失败的可能性都远远超出你的想像。根据我们的经验，用户常低估OA成功的难度，究其原因是缺乏对OA项目本质的清楚认识。第一个认识误区：OA项目是很容易成功的。    大部分OA项目的负责人，都会认为这是一个小CASE，主要是办公室的人用，主要的功能是减少打印纸的消耗量；论技术水平的难度远远低于ERP、BI之类的项目；造价当然也会低很多；甚至自己身边所有作IT的朋友都说自己作过几家单位的OA，保证你能几个月就搞定这个事情。    如果你足够冷静和理性，你可以想像一下，这么多年来，在你的单位周围方圆5公里的范围内，从来没有你的同行或朋友向你炫耀过他们的OA的成功，是这样吧？事实的真像是OA项目实施成功率只有15%，过去的15年中这个比例更低。有很多比你的单位更有钱、计算机技术资源更雄厚的特大型企业，用了你不敢想像的庞大预算去实施过OA，绝大部分项目的结果还是黯然失败，最好的情况就是花了150万，大约只有25个办公室人员在用公文，其他人一概评价说，那玩意儿不大好用，我的很多工作在上面作不了。    也许你会想，没准是他们太笨了，需求搜集不完善，我会把白纸发给每一个部门和人员，把大家的需求都提取出来，逐一实现，这样OA就将成为一个对我们日常工作有价值的IT项目。如果你这么想，那么你离他们的结局就不远了，因为他们的需求不是太简单，而是太完善了，完善到了足以让一个CIO和供应商葬身泥潭。第二个认识误区：行政驱动就能成功    更聪明的你也许会从另一个角度想，是他们的信心不够坚决，如果是我，我一定要让总经理亲自下发一个公文，召集所有的中层干部开一个会，制定使用OA的规定，处罚一切该用OA而不用的OA的人，让所有不会用电脑的人下岗。    如果你这么想，至少你的思考方向是对了，不过糟糕的是你太极端了，你应该去为自己买一份人身安全的保险。而且你太乐观了，你能保证你的软件能真的适应不同部门的不同人员的工作的需求吗？要知道你甚至都不清楚他们的工作细节。更加可能的情况是，在领导赋予了你大权去推进OA后，对软件的抱怨、反对的声音越来越大，而且证据言之凿凿，最后领导只好杀了你以谢天下。    所以本文开始的哪个问题比你想像的更加复杂和深奥，如果你希望得到正确的答案，那么请让我们从以下的认知开始走向成功。1.2 OA项目的本质是什么？    OA项目和上一个财务软件不一样的是它的应用范围决定了它是一个“全员信息化”的大事，这期间，应用范围的量变积累已经使得项目产生了质变的层面，已经涉及到了整个组织的“行为变革”范畴，这在管理学中一个大大的事件甚至需要用革命来形容。也许HR软件或者进销存软件使用失败了没有什么，甚至别的部门根本就不知道发生过，但OA不同，从上线那一天起，到最后无论好坏，每个人都知道你干过一件漂亮或者很糗的事情。记住：OA项目的本质是一种组织行为变革的工具。    绝大部分CIO都是可爱的技术爱好者，也正因为技术的原因被领导指派作为OA项目负责人。不过组织行为学和组织管理学并不是CIO的擅长，所以CIO难以了结或者描述OA的价值，失去了以组织行为管理的价值准绳，只能凭借技术作为判断方向的依据，这样的选型想不失败都很难。    所以，你现在要清楚，可能并不熟悉管理的你要去推动一场组织行为的变革，代号是OA，你将在未来几个月中改变原来那些你熟悉的人的行为模式，把他们从电话、面谈、会议中拽出来，给他一个OA，让他们比以前的行为模式更加有效率，甚至感到比以前工作起来更快乐。    如果你选的产品或者方案让他们感觉很痛苦，他们会以没有时间学习、不好用等各种理由抵抗你，你应该知道改变整个组织的行为习惯是非常困难的，习惯是人性的一部分，改变习惯就是扭曲人性，那种痛苦你如果戒过烟就明白了。现在你面临的情况更糟，就像你需要让200个烟鬼集体戒烟或者300个懒人准时起床晨练那么难。还有，面对领导的信任，退出已经来不及了。掌握如何通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。1.3认识需求如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，那么你就离失败不远了。如何认识自己的需求？    99.99%的OA需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。    把一叠白纸发给单位内各个部门的10天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧.    也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给OA。依照这种需求，世上没有一套现成的软件能够100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案，依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？    我们研究发现这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个？    请不要轻率地回答这个问题，你说用公文？别逗了，公文只有组织中不到10%经常用；文档？文档可以分享，不过文档不能主动产生协同；IM？IM好像不能进行表单审批吧；邮件？邮件能作流程化审批吗？邮件能使得整个组织共享吗？邮件用于要事的授权你既不知道过程也不知道结果你能放心吗？要用邮件来完成组织的日常协同我们还作OA项目干什么？    所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，对本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了？没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求，我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需求，那个词叫协同。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果，无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎80%可以归结为这个需求。所以你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求！    另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量轻重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。1.4项目风险    正如你前文所知道的，现实中OA失败的例子远远多于成功的例子。    当你面对领导的信任和同事的期望，承担起建设一个涉及全局的IT应用系统的责任的时候，难免心潮澎湃，涌起建功立业的雄心壮志，希望无论于公于私都将此项目作成职业生涯中的一个里程碑。在这种心态的影响下，你可能不知不觉地滑入了一个新的误区。    失败案例：当全部需求都被供应商满足了之后，雄心勃勃的项目负责人在上线的头三个月内，被各种细节需求的满足性问题拽得到处团团跑，拼命催促项目开发商供应补丁修正程序，然而，这种未经仔细设计、严格测试的“急就章”式的补丁却带来了更多的bug，熬了多个通宵之后，项目负责人惭愧地向单位领导承认，我们无法在预定的时间上线了，问题多到了各个部门都不满意的程度，原因不能简单地责怪供应商，因为我们在提出需求的时候并没有精确的细节，供应商也是根据口头的沟通达成了对需求的认知，并开发了程序，交付之后才发现，双方还是有太多的细节的细节没有沟通到。贪大求全：    在“认识需求”一文中我们提到了“汇总式”需求对OA项目建设的副作用，缺乏共性需求的抽象提炼，主次不分，轻重不分，缓急不分，这必将导致前期实施目标点过多，局部各自兴奋，全局一盘散沙的局面，事实上你将成为需求平均主义泛滥的牺牲品，丧失把控实施进度的节奏的能力。急功近利    如果你认为软件只要会编程就能作，那你可就大错特错了！隔壁邻居家的高中男孩就能干的事情是写程序，属于个人娱乐，和摄影爱好差不多。而软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”，经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成 “应用设计”，评审后才会有“代码开发”，然后是“功能测试”(诸如白盒测试、黑盒测试、性能测试、压力测试、环境测试、安装测试等)，然后才能交给你。这期间，所有的环节都应该是最优质的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。片面求新：    对新技术的片面性追求常常导致项目成为了项目负责人（特别是CIO）自娱自乐的畸形产物，即使探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性无疑是高风险和高成本的。不少项目负责人会认为“最新的技术”“最先进的技术”。这种认知是非常片面的。    在我们看来，所谓技术先进性的价值不在于先进本身，而在于先进对扩展性、性能、安全性、集成性、易用性（常被CIO所忽视其实对终端客户的影响排在第一位）等诸多应用的现实价值和升级成本的抑制。所以理性的你，应该认真地去了解具体什么新技术，用在什么地方，并且了解这些新技术为你关注的各种特性带来了什么价值。所以说，最大的风险在于你自己。1.5价值评估如何评估OA的价值经过我们对OA多年的研究，与客户的探讨，致远协创成型了A6对组织价值的体系化认识，分抽象价值和量化价值价值两个方面，希望我们的认知能为你的立项报告提供领导决策所需的价值参考。  在这，我们只评估OA的组织级管理价值，至于对个人的价值，会因为个性化爱好见仁见智，对于不同角色的管理价值欢迎你和我们的咨询顾问更深入探讨。组织应用价值如下图如何认识A6的组织级应用价值？ 你可以注意到这些价值基本定位在组织行为学和组织管理学范畴，A6也是在业内唯一一套在理念和功能范畴同时具备强烈针对组织行为管理的产品。遵从这个理念的导引，我们创造了数以百计的功能，这些功能根据客户三规划的阶段性应用特点被呈现或隐藏在了不同的菜单或高级选项功能中，这些功能能够跨行业兼容客户的需求，完成ERP、HR、CRM、财务软件、BI、PCM等等所不能完成的组织行为管理的空白，与这些业务管理软件共同构成完备的信息化管理体系。如何认识A6在组织不同发展阶段的应用价值？        组织成长与应用价值关系如下图：         从第二张图中你可以看到渐进式的应用发展趋势，能够帮助你进行对于应用发展进行规划。如何评估A6对组织行为能效的提升？我们相信，你购买A6是一定有多种目的的，根据我们对用户的统计，A6在组织行为能效的提升方面可以从以下几个方面来观察评估。如何从财务角度评估A6的投入产出比？定量的价值评估将根据您的组织中关键参数计算而得， A6所带来的经济效益范围值，并测算你的投资回报比。你可以以此作为向您的领导进行量化的价值评估的参考。根据我们对用户的实际应用结果的统计，普遍的当年回报率在2倍以上。2、如何选型2.1方案选型如何判断自己需要项目化还是产品化？   这是一个痛苦的选择，项目化可以量身裁衣，看上去似乎能百分之百满足自己的需求，不过项目化也素以高风险著称。从整个社会的角度来看，项目化是新技术落地的探索先驱，是最大化实现自己需求的唯一方法。不过项目化挑战也极大，你或许知道PM（项目经理）的平均月薪都超过2万了，这说明项目需要高手才能把控，另外一个问题是，客户方的PM是你吗？你将有信心扮演客户方的那个角色吗？你能将纷繁复杂的需求举重若轻、分门别类、提炼归纳、创造性将理念和实际结合在一起锻造出逻辑清晰、体系化完备的需求吗？    就算你是高手，另一个问题又来了，当你和那个PM两大高手带领团队殚精竭虑、呕心沥血地研究需求，优先重点、屏蔽次要（和需求部门吵架你要自己解决）、约定设计原则、论证构架、实现代码、完成测试，时间也许已经过去1年了，对急需提升工作效率的组织来说，大家等得了吗？    更糟糕的还在后面，过去每一个OA历经劫难终于完成并上线了，当庆功会曲终人散，酒意半醒的你会不会有恐惧，结算完了工程款，未来OA出了问题谁帮你救火?你真的就那么相信那个和你耗了一年半的供应商PM？就算他是一个重信守诺的人，你还是要学会每天晚上祷告他不要跳槽、不要出国留学、不要遗失你们的项目文档、不要黄金周自驾游出什么车祸。当然你更不能期望未来还能升级，技术在进步，但那个伙计已经拿新技术去为别的项目忙活去了，你没有二期预算，你都不好意思自己提交情。    事实证明，绝大部分OA都会在2-3年技术和应用过时而被废弃不用，长期服务和发展需要长期的保障机制而不是酒桌上的豪言承诺。    回过头看看产品化的可能性。5年之前，业内的人还认为OA不可能实现产品化，因为各家的流程、表单形式、权限体系、信息分类都太不一样了。但我们认为那是因为没用从庞杂的需求中找到共性进而通过创造性的功能设计去满足客户需求的原因。现在，无论是国资委下的特大型企业，还是数十人的小型贸易公司，从中学到大学，从矿山到公安局，我们拥有超过3000个客户大约超过50万人每天都在使用同一套软件，这证明了我们的设计是兼容客户需求的，你不能只强调你有个性化需求，那么那些比你资金更多，技术实力更雄厚的组织难道没有自己的个性化需求吗？    产品化可能不能完全满足你现在所想到的需求，但满足最重要的最大范围共性的需求毫无问题，经过千百个用户的需求催化不断发展，即使在细节上也肯定大大超过你个人的思考能力能产出的程度。    产品化的另一个好处是经过诸多用户验证和实际使用，产品化的稳定性大大优于开发型项目。世界上最优秀的软件公司如微软IBM都有bug，难道一个急工搭建项目就不会有吗？产品化公司凭借后台的流程快速采集客户的bug反馈，推出serverpackage（SP）快速持续收敛bug，保障客户应用，具有项目完全不可比拟的优势。如何进行快速实施快速启用？    产品化的实施交付性也非常强，长期的大规模交付沉淀出的实施方法论将有助于下一个客户能够规避风险、快速规划和推进，并有清晰的标准达成验收，保障实施效果。我们拥有适合不同级别客户的实施包，内含实施阶段规划、主计划、需求采集表单集、培训教材、验收标准、OA运行制度、甚至有项目启动会的领导发言大纲和鼓励OA使用的标语和海报，你如果还想参考同行业其他客户的实施和应用情况，我们甚至可以提供实施总结供你参考。    致远协创的实施方法论将帮助你掌握如果通过应用的部署完成推进组织行为的变革。如何识别伪产品公司？    提醒你要注意另一个事情，由于产品化这两年发展迅速，不少项目厂商拿着项目代码简单伪装号称自己是产品化的供应商，你要学会识别。其实产品化并不是把软件刻成光盘，印刷而不是打印（打印说明其用户量太小）一本说明书塞进一个纸盒那么简单，这个盒子背后是庞大的组织和需求、设计、代码实现、测试流程以及分工明确的销售、实施、服务支撑体系。当然你无从通过网站了解这一切，唯一你能感知的是“升级公告”，因为每个用户的软件都不同，因此无法升级，所以一个伪装的产品公司是不敢发布升级包的。你难道几年后还在用今天选择的OA吗？    眼下需要你操心的事情太多了，所以你可能从来没有考虑未来升级的事情。需要说明的是过去15年，中国交付了超过10万套OA，估计有一少部分当时的开发和实施还是不错的，甚至成功验收了，但因为不能持续升级，几年后都停用了（致远协创客户中有20%是废弃了原有的OA而改用了A6的）。    从哲学的角度很容易理解这个现象，任何时候你、我、其他专家对一个事物的认知都是有局限性的，因此我们不能把3年后的组织需求、技术发展与实现都想得清清楚楚并且把实现思路方法都一一安排到位，我们能把今天搞定就很不错了。但你对未来的期望也绝对不要停留在招标说明书上写上：系统要有良好的扩展性，提供丰富的接口，以便适应未来的需求“，这是一种自欺欺人的愿望罢了，唯有持续的升级才能保障你达成这一目标。5年前OA都不支持和手机的互通，而今天，我们已经帮助客户通过智能手机完成审批了。总之，高性价比、低风险、快速实施、持续高品质服务和升级是产品化对你最大的价值。2.2规格选型什么样的版本规格适合你？致远协创拥有4个产品，分三个层次、兼容2类用户（政府和企业）。高端：企业版 101500并发、政务版 10-1500并发 功能丰富、支持全部插件（可选配），适合IT信息化建设基础较好的用户，或替代升级原有OA系统。 详细功能参见相关产品介绍。中端：标准版 10-500并发 功能完备、支持常用插件（可选配），适合快速部署的客户需求，可升级到企业版或政务版。 详细功能参见相关产品介绍。低端：基础版 1050并发 极佳性价比，基本无需学习，即安即用，适合小型组织低成本协同。除了价格差异以外，主要是功能、应用、实施方面的差别，采用同样的技术平台和研发流程，并且通过了严格的质量测试，由同一个客服中心提供服务.如何计算自己所需要的并发数？如果你确切地知道未来OA的大致使用人数，那么将这个人数除以2可以得到大致的并发数需求（A6并发数限制是指允许使用者同时在线的最大数量，对系统注册客户数量无限制）。你也可以根据单位使用率和预算的情况适当调整，从我们的经验来看，使用人数：并发数3:11:1都是可以的。如何判断自己需要什么版本？功能是为应用设计的，应用来自你的组织对管理的需求，你可以下载“管理成熟度测试表”评估一下，更详细的方案你可以和我们的咨询顾问探讨后确定。我们的忠告：如果你是个特大型组织，我们不主张你一上来就尽你的最大预算购买最高规格和最大并发数的产品，所以尽管可能少挣些钱，但我们还是期望你能根据情况确定较小但更稳妥的目标，因为我们太了解OA的挑战了（详见认识OA）。你相信吗？即使是我们的客户平均满意度达到了业界罕见的80%以上，却仍然有2.37%的客户购买后完全停用，主因绝非产品，而是目标、实施方法失当，在我们看来您用好比我们挣多少钱更重要。2.3阶段规划如何规划项目？一般来说，你应该把战略级规划分为三期。第一阶段是共性应用阶段，你应该聚焦共性应用，用2个月的时间完成从实施到培训以至于全局上线，这个阶段的目标是全员信息化扫盲和促进组织建立基于电脑和网络进行协同的新习惯。这个阶段如果实现目标过多将使得时间拉长，时间拉长将使得整个组织对变革的兴奋度下降，应用积极性下降将导致上线人员减少或达不到一个应用阀值，这个阀值将使得组织行为变革的目标失败，所以说第一阶段成败是关键的关键。第二个阶段为局部应用深化阶段，在第一阶段达到阀值以后，组织已经从整体上建立了新的行为模式，这个时候你会发现其实不同部门之间因为其电脑使用水平和部门领导的重视度的差异已经开始造成应用深度的差异。你可以鼓励和促进先进部门将自己的制度转化为部门级协同模板，搭建部门知识管理体系，推进部门计划管理和时间管理，尝试项目管理，总之在推动全局性应用深化的同时促进局部突出发展。这个阶段估计要1-2年。第三个阶段是整合应用阶段。在局部深化的过程中，你不仅会加大OA现有功能的使用深度，也可能会建设OA无法满足和替代的局部业务系统，这些系统的选择和实施同样有风险，幸运的是通过1-2年的第二阶段，你可能到了全局平衡、局部成熟的程度了，那么你可以考虑开始进行集成和整合，你需要以成熟的细节需求为基础，各系统之间的数据接口的发育成熟度为支撑，以新的应用目标为导向，动用精通构架的程序员，进行一个真正量身定做的项目。至此你是否会有疑惑？如何从产品发展成了项目？其实此项目和前文提到的项目有一个最大的差别是，在经过了前两个阶段后，你已经充分能够驾驭整合的深度和范围，此项目无论如何开发都将将不影响OA和局部业务系统的升级。如果整合就意味着停滞发展，那么我劝你还是不要干的好。至于支撑你的第一阶段的实施计划，那是我们实施顾问的责任，他将和你一起共同制定一个符合你的目标和实际情况的可执行计划。如何通过关键值衡量是否成功？衡量一个抽象的事物非常复杂，你会检查标书和实施计划中的子项目标是否在实施期限内达成。另外一个简单的方法就是在是实施启动的第天检查你们单位两个指标是否达到了应用阀值,检验实施成功有两个阀值：应用范围值A阀值人均上线频率>1次/人*天。举例：如果注册客户是300，那么300人每人每天应该有1次上线（A6有专门的后台统计功能可以查询到），A6现在已经实施的客户一般都>1.2。如果A值达不到阀值，应用范围会急剧缩减到少数积极的用户，大多数人会因上网交出去的协同事情没有当天处理而受到负激励，不再从网上协同回复到地面协同。如果达到，可以保持一个及格水平，但需要达到b才开始向深化应用发展。应用效率值B阀值注册人员经常性在线率>30%。举例：A6注册客户300，那么经常会有100人在线。 b值是响应效率，当b>30%时，响应的及时性会提高，A6的协同性效果会显著超过传统行为模式，从而使协同请求者和协同处理者都产生正激励效应，会越用越好。这样的用户通常会扩并发，A6已经有很多客户这样的客户。时间约束条件2月实施上线2个月内必须一鼓作气达成这两个值，否则再三而竭，组织不在兴奋，无心学习，二次实施很难成功。2个月之内实施效果不能达到AB阀值要求的项目风险会大大增加。2.4售前咨询事实上，OA项目因为涉及到这么多方面的知识，任何细节的疏忽都会导致项目的启动充满不可预期的变化。所以我们乐于向你提供如下服务来协助你规避风险，走向成功的道路。请联系我们 15910865568 51651326转821 郭兴瑞您将得到：需求规划、采集整理、分析评估 阶段规划、设置阶段策略、目标和里程碑资源规划、设备、环境清单实施规划、要事执行安排维护规划、运行制度日程考评