|
基本特征
?定位于大中小型组织（政府、企业）的行为管理，标准化、快速交付、低成本、低风险是标准版的主要客户应用特征。
?关键应用：组织流程、制度管理与执行，组织行为控制与管理，沟通，知识积淀与共享，异地、分时协作执行，个人工作管理、团队工作管理与执行控制，计划管理、邮件管理和知识文档管理体系的建设。
?特色：标准化、快速实施见效、支持企业不断成长中的流程、制度建设，支持大中型组织的公文、综合办公等应用。
?优势：全员信息化普及的组织级行为管理工具，利用Internet技术优势与应用特征，企业信息化建设。
?应用规模：大中小规模的全员信息化。
?用户行业特征：大中小型工、商、服务业、事业、政府机关。
?用户分类建议：大型企业事业单位部门、行业管理部门、协会、大专院校、政府厅局、集团总部、分部等各种组织。
?标准化、快速实施的高速部署、支持企业不断成长中的流程、制度建设，支持大中型组织的公文、综合办公等应用。
?提供基于互联网的协同工作平台和个人工具，提高组织沟通能力和工作效-率。
?规范管理行为，流程、模板化管理等非结构化信息，减少信息传递的衰减和变形，实现有效授权，从而提高组织的工作质量。
?通过文档管理扩大信息共享能力，通过管理行为和过程沉淀管理知识，形成组织的知识资产。
?增强对事务、事件的过程管理，实现透明的过程控制，提高团队的执行力。
?提高个人和团队的计划和时间管理能力，支持领导对下属、助理（秘书）对领导的工作安排、会议管理等，提高团队的时间、事件的协调与执行。
?支持移动办公和其他互联网应用工具（如及时通信等）。
?提供对其他应用系统的应用整合，提供标准化的单点登录集成。
?通过A6精灵整合桌面Outlook、Word、Excel应用，实现桌面OFFICE与组织和系统的协同。
?功能齐备，扩展性强，行业特征不明显，通过模板和流程实现行业应用；
?流程功能更强大、仍然保持良好易用性，久经市场检验，稳定；
?支持A6精灵进行桌面整合
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后，对软件的抱怨、反对的声音越来越大，而且证据言之凿凿，最后领导只好杀了你以谢天下。
所以本文开始的哪个问题比你想像的更加复杂和深奥，如果你希望得到正确的答案，那么请让我们从以下的认知开始走向成功。
OA项目的本质是什么？
OA项目和上一个财务软件不一样的是它的应用范围决定了它是一个“全员信息化”的大事，这期间，应用范围的量变积累已经使得项目产生了质变的层面，已经涉及到了整个组织的“行为变革”范畴，这在管理学中一个大大的事件甚至需要用革命来形容。也许HR软件或着进销存软件使用失败了没有什么，甚至别的部门根本就不知道发生过，但OA不同，从上线那一天起，到最后无论好坏，每个人都知道你干过一件漂亮或者很糗的事情。
记住：OA项目的本质是一种组织行为变革的工具。
绝大部分CIO都是可爱的技术爱好者，也正因为技术的原因被领导指派作为OA项目负责人。不过组织行为学和组织管理学并不是CIO的擅长，所以CIO难以了结或者描述OA的价值，失去了以组织行为管理的价值准绳，只能凭借技术作为判断方向的依据，这样的选型想不失败都很难。
所以，你现在要清楚，可能并不熟悉管理的你要去推动一场组织行为的变革，代号是OA，你将在未来几个月中改变原来那些你熟悉的人的行为模式，把他们从电话、面谈、会议中拽出来，给他一个OA，让他们比以前的行为模式更加有-效率，甚至感到比以前工作起来更快乐。
如果你选的产品或者方案让他们感觉很痛苦，他们会以没有时间学习、不好用等各种理由抵抗你，你应该知道改变整个组织的行为习惯是非常困难的，习惯是人性的一部分，改变习惯就是扭曲人性，那种痛苦你如果戒过烟就明白了。现在你面临的情况更糟，就像你需要让200个烟鬼集体戒烟或者300个懒人准时起床晨练那么难。还有，面对领导的信任，退出已经来不及了。
掌握如何通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。
2 认识需求
如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，那么你就离失败不远了。
如何认识自己的需求？
99.99%的OA需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。
把一叠白纸发给单位内各个部门的10天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧.
也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给OA。依照这种需求，世上没有一成的软件能够100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案，依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？
我们研究发现这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个？
请不要轻率地回答这个问题，你说用公文？别逗了，公文只有组织中不到10%经常用；文档？文档可以分享，不过文档不能主动产生协同；IM？IM好像不能进行表单审批吧；邮件？邮件能作流程化审批吗？邮件能使得整个组织共享吗？邮件用于要事的授权你既不知道过程也不知道结果你能放心吗？要用邮件来完成组织的日常协同我们还作OA项目干什么？
所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，对本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了？没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求，我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需求，那个词叫协同。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果，无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎80%可以归结为这个需求。
所以你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求！
另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量敬重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。
3 项目风险
正如你前文所知道的，现实中OA失败的例子远远多于成功的例子。
当你面对领导的信任和同事的期望，承担起建设一个涉及全局的IT应用系统的责任的时候，难免心潮澎湃，涌起建功立业的雄心壮志，希望无论于公于私都将此项目作成职业生涯中的一个里程碑。在这种心态的影响下，你可能不知不觉地滑入了一个新的误区。
失败案例：当全部需求都被供应商满足了之后，雄心勃勃的项目负责人在上线的头三个月内，被各种细节需求的满足性问题拽得到处团团跑，拼命催促项目开发商供应补丁修正程序，然而，这种未经仔细设计、严格测试的“急就章”式的补丁却带来了更多的bug，熬了多个通宵之后，项目负责人惭愧地向单位领导承认，我们无法在预定的时间上线了，问题多到了各个部门都不满意的程度，原因不能简单地责怪供应商，因为我们在提出需求的时候并没有的细节，供应商也是根据口头的沟通达成了对需求的认知，并开发了程序，交付之后才发现，双方还是有太多的细节的细节没有沟通到。
贪大求全：
在“认识需求”一文中我们提到了“汇总式”需求对OA项目建设的副作用，缺乏共性需求的抽象提炼，主次部分，轻重不分，缓急不分，这必将导致前期实施目标点过多，局部各自兴奋，全局一盘散沙的局面，事实上你将成为需求平均主义泛滥的牺牲品，丧失把控实施进度的节奏的能力。
急功近利
如果你认为软件只要会编程就能作，那你可就大错特错了！隔壁邻居家的高中男孩就能干的事情是写程序，属于个人，和摄影爱好差不多。而软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”，经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成 “应用设计”，评审后才会有“代码开发”，然后是“功能测试”(诸如白盒测试、黑盒测试、性能测试、压力测试、环境测试、安装测试等)，然后才能交给你。这期间，所有的环节都应该是质的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。
片面求新：
对新技术的片面性追求常常导致项目成为了项目负责人（特别是CIO）自娱自乐的畸形产物，即使探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性无疑是高风险和高成本的。不少项目负责人会认为“的技术”＝“的技术”。这种认知是非常片面的。
在我们看来，所谓技术先进性的价值不在于先进本身，而在于先进对扩展性、性能、安全性、集成性、易用性（常被CIO所忽视其实对终端客户的影响排在位）等诸多应用的现实价值和升级成本的抑制。所以理性的你，应该认真地去了解具体什么新技术，用在什么地方，并且了解这些新技术为你关注的各种特性带来了什么价值。
所以说，的风险在于你自己。 |