协同软件 OA 到底是做什么的 我们是否经常碰到这种问题 1 我想找别的部门支持一下..
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
协同软件 OA 到底是做什么的
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口您现在的位置： >> >> >> >>
上海建工装饰OA系统实施经验谈
0:00:00&&&
　　随着企业信息化建设的重要性越显突出，上海市建筑装饰工程有限公司于2004年，根据企业实际情况，着手在全公司范围内实施OA办公系统。经过2年的系统实施和使用，总结了很多有益的经验，下面就将在这2年中总结的一些经验与大家一起来分享。　　目前对于OA软件的选购，用户可以通过购买现成的软件产品，或者由软件公司根据企业情况定制开发。但是如何来判断一个软件的好坏呢？按照软件质量国家标准GB-TG，软件质量可以用下列特征来评价：功能特征、可靠特征、易用特征、效率特征、可维护特征、可移植特征。对大部分使用OA的用户来说，系统的底层是什么，代码的质量如何，没有专业的知识，用户是无从判别的，所以用户对一个软件最直接感受就这个是软件是不是好用，这其实就是软件的易用性问题。易用性的判别标准相比其他的判别标准，用户更能自行掌握。易用特征是指由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。简单的说，就是用户为了使用该软件付出了多大的努力，做出了什么样的评价。如果用户可以很轻松、快捷的使用软件，那么付出的努力就少，评价自然就高，我们说它的易用性好，反之则易用性差。　　用户可以从下三个方面来评估，即易理解性、易学习性和易操作性。易理解性：易理解性是与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。该特征要求软件研制过程中形成的所有文档语言简练、前后一致、易于理解以及语句无歧义。　　个人认为，易理解性是软件易用的基础，它主要表现在以下三个方面：　　1. 宣传资料：宣传资料应实事求是，言简意赅，而不是过度包装，描绘理想化的景象。但是很多软件为用户提供的方案书上，为了显示自己的先进性，堆砌了一大堆抽象、时髦的概念和理论，并片面夸大软件的作用，好像无所不能，功盖千秋，花里胡哨的方案书洋洋洒洒上百页，其实这只能把用户对软件的理解引入歧途，这样的作法最终只能使用户在拿到开发完的产品后，发现与自己的预期想法相去甚远。　　2. 功能名称：功能名称和图标应该直接、明了，没有歧义，容易理解，让用户一看就知道是干什么的，而不是猜测其作用。但是很多软件对用户特点不够了解，如企业单位和政府部门对“文件”和“公文”，“通知”和“公告”的理解上就存在了一定的差异，如果太过随意的使用，而不考虑用户的特点，就会给用户的使用造成一定的困难。　　3. 使用手册：使用手册应该站在读者的角度，充分考虑普通用户的接受水平，语言直白、描述细致、逻辑清晰，尽量避免专业术语。由于很多使用手册是技术人员撰写的，使用了大量的专业术语，同时技术人员认为很简单的操作在电脑水平不高的用户看来却无法理解，造成手册的生涩、难懂。　　易学习性：易学习性是与用户为学习软件应用(例如运行控制、输入、输出)所花的努力有关的软件属性。该特征要求研制方提供的用户文档，主要是使用手册内容详细、结构清晰以及语言准确。　　我认为，手册内容当然重要，但OA软件本身也能引导用户使用，因为OA软件功能简单，贴近用户的日常办公内容，和一些专业性较强的专业软件相比，易用的OA软件，用户第一次使用软件可能会发现平时工作内容的影子。易学习的OA要求用户进入操作界面后一目了然，能够很直观、很容易的找到自己要使用的功能菜单，很方便的完成操作，即使遇到一些复杂的操作，只要通过一些适当的注解或查看用户手册，通过用户自己的学习，也能迅速的掌握。总的来说，对OA软件的学习不应占用用户太多的时间。　　OA软件功能简单，易用性远胜各种专业软件，所以很多用户感觉各个OA差不多，但是稍微比较就会发现差异明显。我们用一个比较简单通用的OA系统作比较，用户的电脑使用水平一般。易用性的OA，进行一次培训后，绝大部分用户能够在一天内熟练使用常用功能，一周内熟练使用70%的功能，即一周内让系统顺畅的运行起来。而不易用的OA，进行一次培训后，绝大部分用户还需要至少一周的时间方能用起来常用功能，需要一个月的时间使用70%的功能，即共需一个月的时间才能让系统真正运行起来。而在这一个月内，企业付出的学习成本将是很高的，这包括了时间成本、财务成本、人工成本、硬件成本、精力成本等等，所以降低用户的学习成本是非常必要的。　　易操作性：易操作性是与用户为操作和运行控制所花的努力有关的软件属性。该特征要求软件的人机界面友好、界面设计科学合理以及操作简单等。　　因为以上特征，操作性强的OA可以让用户直接根据窗口提示上手使用，无需过多的参考使用说明书和参加培训。而操作性差的OA则使用起来磕磕绊绊，别别扭扭。易操作的OA各项功能流程设计的很直接，争取在一个窗口完成一套操作，避免用户在多个窗口间来回的切换，比如发送文件时，打开发送文件窗口，即可一次性完成文件类型、标题、内文、附件以及接收者的编辑，然后就可发送出去。另外，考虑用户数据输入的重复性，易操作的OA默认值和可以选择项多，这样就能尽量避免操作者过多的重复手工字符输入操作，只要选择一个选项即可。　　OA的功能虽然越来强大，操作却应该越来越简单，因为任何产品的发展都是越来越傻瓜化。对OA来说，其最高境界就是做到“零手册”，即无需手册的帮助，就能够直接上手使用。　　优秀的软件可以帮助企业作好管理工作，但企业自身的内部管理工作也应及时的跟上。　　1. 为企业信息化建立做好充分的基础准备　　首先是打好物质基础，企业应建立起自己内部局域网和网络应用，并为每个部门配备一定数量的计算机作为日常办公的必需工具，而且员工也应能够熟练的使用计算机，日常的办公文档应尽量采用电子文档格式保存，便于部门间流转。　　优化和简化办公工作流程，由于计算机只适用于处理标准的和流程化的数据，建立起一套条线清晰的工作流程，对以后在OA办公系统中建立工作流程是至关重要的。　　2. 组建企业业务系统开发核心小组　　从各个部门抽调业务骨干组建核心小组，参与到软件公司的前期调研，中期的软件实施推进，和后期的持续改进。　　组建核心小组的作用，就是在软件调研前期帮助软件公司更快、更全面、更深刻的了解企业业务管理，为软件以后编写代码的质量奠定了基础。在中期软件实施阶段，由核心小组中业务骨干来推进软件使用，使得各部门通过业务系统有效的联系起来，避免群龙无首，造成在软件使用中由于没有总体协调管理和操作人员缺乏业务流的概念，最后产生出垃圾数据。在业务系统进入了平稳运行期后，继续由核心小组有组织、有计划地推进业务系统的改进工作。　　3. 业务部门应与技术支持部门紧密配合　　在没有真正投入到信息化建设中前，信息技术部门永远不可能真正成为企业运营的一份子，而总是以一个协助者的形象出现，各业务部门很少会主动地与他们沟通，那么让技术支持部门真正深入理解公司的运营流程，也就不太现实了，因此在不了解流程的情况下，可以想象系统开发的质量如何了。　　企业信息化建设是一根红线，它是业务与IT结合的红娘，只有业务部门和技术部门间的紧密配合，业务管理系统的充分开发和利用，才能使得销售、人、财、物充分意识到了IT技术的力量。流程精简，修改配置、报表开发，技术支持部门也在不断的需求满足过程中，锻炼了自己，逐渐熟悉了企业业务流程和各部门开发需求书背后真正的需求目的。　　4. 培养系统各模块/部门的关键用户　　关键用户就是对某个功能模块或者部门内的系统流程和操作非常的熟悉。通过他们由点带面的动员公司上下使用系统，推动系统的全面的上线。　　同时他们也担负着部门内的技术支持的角色，对部门内新进员工进行系统使用的培训。由于他们对系统的熟悉，所以比起一般的用户更容易发现系统存在的问题、提出建议和解决的方案，像前面提到的业务系统开发小组成员就可以作为系统的关键用户。　　当然后期对关键用户的培养和培训也很重要，组织对其他模块知识的学习和轮岗。通过学习其他模块，了解自己工作节点上下游的操作方法及信息查询，可以帮助员工了解流程设计原理，提高对工作的新鲜感，重视部门间工作配合的重要性，同时也提升了他们的知识储备。　　5. 系统培训手册的建立与完善　　手册的重要性自然不容质疑，企业内人员的流动频繁，特别是关键用户流失，一旦没有了可以提供系统化培训和支持的人员，别说系统原理的讲解了，就连新人入职的操作都会举步维艰，进入角色的速度非常慢，严重影响公司整体链条的运转，所以，操作手册的存在，对企业来说就是有利的保障。　　在系统测试开发完成后，进行了相关的培训后，应尽快着手建立起部门级的培训手册和各岗位的培训手册。部门级手册的内容应能提供本部门内大流程的概念以及和其他部门的数据交换内容，而部门内部各岗位的培训手册则是针对实际的使用用户而编写的，内容上应更侧重于操作，内容和形式上详尽而细致，照顾到各层面的用户。最后，还要建立手册负责制，有新的操作方法，必须不断更新，不断充实这个知识库。　　6. 领导层的决心是成功上线的保证　　装饰行业企业一般人员相对较少，组织结构比较扁平化，企业高层领导的决心和态度成为系统上线能否顺利推动的风向标。在实施的初期，考虑系统还处于试运行期间，必定是线下工作和线上的工作一起做，工作量比较大。由于新系统只是试用，业务人员的重点当然放在原来的线下工作上，一旦工作忙起来，随着时间的推移，对新系统中的数据跟进也就越来越慢，如果这个时候不加努力，经过一段时间的忙乱之后就会对系统失去信心。这时，如果企业领导者没有一定成功上线的决心，就有可能导致系统完全上线的时间表一拖在拖，甚至半途而废，所以企业领导者的决心和大力支持是系统上线的关键。　　7. 建立数据安全保障体系　　系统成功上线，平稳运行，日常的运营应该是比较顺滑了，但是未雨绸缪的意识在信息高度集中化、IT化的今天是至关重要的。试想，在你毫无防备的一天，突然间系统瘫痪了，数据丢失了，整个公司就像失去了大脑，业务运作也随之停止了。数据安全保障体系的建立就是在系统运营平稳后的一项大事。　　数据备份要字当头，有条件的企业可以选择专业设备实时备份，中小企业由于资金压力大，无法做到实时，但每天的备份是必须的，当然如果能够建立起异地的备份，那就是再稳妥不过了，否则一旦出现问题，企业将面临停止运营的巨大危险。同时不定期组织临时灾难恢复演习，核查备份的数据、总结经验、完善灾难恢复体系，防患于未然。　　企业发展信息化是必然之路，这其中除了企业外部的大环境的原因之外，更多的是企业对自身的要求。如果只有外部因素的压力，而没有自身的要求，企业信息化发展是没有内在动力的，企业信息建设也不会走远。但是一旦投入了这份工作，就应全力以赴，推动系统全面的运转起来，充分利用信息化带来的高效和便利，否则只能白白浪费大量的人力、物力和财力。企业信息化建设是一条漫长的道路，也是一条成功之路，希望信息化建设能够为装饰行业带来新一轮的发展契机。　　
金晶格林防火玻璃高新产品新闻发布暨创新应用技术研讨会成功落幕
幻腾智能开启一键操控全家新模式
丹瑞创意研发建筑设计新理念 与孔雀城品牌一起最美绽放
线上是“难啃的骨头” 双12橱柜业要双线结合
工人讨薪欲跳楼被救下 围观者"等太久没意思"
万达王健林：上市是今年“兴奋点”
家居企业电商路要点：产品为核心 攻克短板
中国最大的工程机械制造商“三一重工”要办银行了
卖场和家居企业争相绑定设计 设计离人们越来越近
金螳螂首获设计界“奥斯卡”奖 实现中国零突破
建筑欣赏：巴黎UNIQLO优衣库专卖店设计（组图）
建筑欣赏：多伦多香格里拉bosk餐厅设计（组图）
本期提要：
往期回顾：
您可能感兴趣的美图成功部署OA协同办公系统的9个问题
&&没有公告
您现在的位置：&&>>&&>>&&>>&正文
成功部署OA协同办公系统的9个问题
<FONT color=#7-10-8 15:22:59& 文章来源：
【】【】【】【】【】
―― 成功部署OA协同办公系统的9个问题
序本来此文是一份用友致远公司内部与渠道代理伙伴交流客户对OA的认知的系列文章、以及部分发表在用友致远公司网站上的文章整理而成的，其中为了更加具体的说明问题或作为例证，我在不少地方使用了用友致远公司A6协同OA软件（下面简称：A6）作为参照，并非出于对这些早已选择了A6产品作为事业的朋友进行推销的目的。在内部发布后，许多伙伴朋友鼓励我拿出来与更多的客户的CIO朋友分享，专业媒体和出版届的朋友听说后也向我约稿，于是我在原文的基础上略作整理以供抛砖引玉。
即使在原文中，我也没有任何对特定指名的竞争友商的贬抑之辞，或者对非J2EE技术的偏见；另外在项目化和产品化部分的观点，我是基于更多数的客户所具备的客观基础条件以及其所可能的选择而谈的，这并非否定项目化的社会化价值，也无损于IBM、富士通这些以客户经营为导向的真正的项目化成功厂商的声誉，但我期望客户不要接受那些毫无持续客户保障能力的一夜情性质的短期功利性项目厂商，是他们损害了OA事业的发展。不过令人欣慰的是，越来越多的同业友商开始意识到这个问题，开始以自己适合的形式注重与客户的长期合作，谋求共赢。
由于工作的原因，5年以来我能经常和客户的CIO交流，通过他们，我学习到了很多东西，在对问题的探讨中，我与许多CIO成为了朋友，他们是一群特点相同的人，无论他们身处何地、无论行业如何、无论其过去是作什么的，但都有极强的学习能力，善于思考抽象而复杂的事物，忠于组织的战略目标，在权限、资源不足、领导重视不够的情况下，长期勤奋、努力地想把工作做好。我感到非常荣幸的是，他们把信任给了我，选用了我们的协同OA产品A6，在共同的实践中，我们长期地保持着沟通，得到了许多认为对OA项目、协同软件的认知心得心得，我知道我的使命是将这些心得映射到产品的进化中，以功能和应用的形式回馈给这些支持我的朋友。
回顾我和他们认识的过程，几乎都源于OA选型，这个过程中，我看到了有趣的现象，凡是大型或特大型企业的CIO，在OA项目选型的过程中，越是没有把握，越发表现得谨慎。他们不少人其实在5年前甚至10年前就开始推广OA，但都不同程度地遭遇了挫折，而当时他们拥有充足的预算、健全的技术型项目组、优良的硬件环境，甚至有领导的支持和强制推广的政策保障。与之相反，越是年轻的CIO，单位小一些的CIO，第一次选型OA的CIO，倒是信心指数普遍超过更有经验的CIO们，但这些年轻的CIO们几乎都忽略了一个事实，仅仅在几年以前在他们任何一位所在单位半径5公里内，都很难找到一家成功应用OA的可以参观学习的单位，在行业CIO峰会上，你也很难听到哪个CIO将其OA项目作为一个成功经验进行分享。难道OA是个不重要的应用领域吗？那么为什么每家似乎都在考虑上马？
在于这些信心十足的CIO的沟通中，我发现由于种种原因导致这些CIO们对于OA项目的哲学层面的本质很少有深入的思考，大多过于从技术角度的眼光去关注具体的功能或应用，更多时候我看到的标书的技术标中全是从网络上下载各家厂商的白皮书，根据自己理解的需求拼凑而出的细节功能特征要求，而组织发展的具体战略与OA之间的关系、从管理角度对OA的要求连只言片语都没有，似乎这些功能要求足以暗示领导的管理意图，难道∑需求＝功能？∑功能＝管理？后来我明白，正是这种认知上的先天不足导致在中国过去的15年中，超过10万套上马的OA项目成为了毫无价值的摆设和2-3年即废弃的项目。
限于篇幅，我们在此将聚焦到OA项目的选型和事实的价值观和方法论层面，从保障项目成功的角度探讨9个问题。至于OA与管理思想、管理实践、管理者之间的关系，请参见拙作《用友致远公司为什么造A6？》。A6协同与传统OA的不同请参见《A6为什么能协同？》，对于管理者关心的OA对组织管理方式的变革请见《管理思想如何“落地”？》
针对CIO所关注的关乎项目成败的9个问题分别是：
1.&& OA的成功率有多高？
2.&& OA的本质是什么?
3.&& OA的挑战是什么？
4.&& OA的项目成功的要素是什么？
5.&& CIO的项目陷阱是什么？为什么？
6.&& 如何认识项目和产品化对自己的意义
7.&& 如何进行OA的实施阶段规划？
8.&& 如何建设OA项目的长期发展机制？
9.&& OA成功的简单量化标准是什么？
这9个问题涉及到对OA的初步的认知，深入到对本质的探讨，从而推导面临的挑战，然后再换一个角度，从成功到风险的对应，然后再到如何解决这些问题的思路。其中有不少逻辑是相关联的，看上去未免有些头晕，但好在这样没有太多探索范围的遗漏，只好请读者宽容了。另外还有些问题虽然看上去很小，但其内涵却丰富，所以没有展开，采用的引用其他文章的方式作为解释，供有兴趣的朋友阅读了解。
第一问：OA的成功率有多高？在大多数人的心目当中，OA是一个很容易成功并且没有什么太大价值的软件。我不止一次问过客户这个问题，客户大部分都不知道，并认为相比ERP而言，OA技术难度不高，应用也不深奥，无需太多专业知识背景，只要领导一纸红头文件，就能顺利成功。
其实现实情况恰恰相反，OA的成功率低得可怜，虽然OA有15年以上的历史，真正成功的寥寥无几，现在从网络上能够查到的成功率数据是我在02年调研走访客户后的得到的结论－低于15%，这大大低于用户和业界的感觉，其失败率直逼ERP。我也常问客户：你们单位方圆5公里范围内有什么成功的OA客户吗？或者，你们行业内部哪个单位的OA用得不错？答案是否定的或者不知道。我知道的一个曾经投资百万建设notes系统的OA的客户，实施范围1100人，但最后只有不到50人在上面用公文，可谓昂贵的摆设。其实深入了解，并非NOTES不好，失败是另有原因的。
另一个例证是：用友致远公司现有的客户当中，有超过15%的客户是抛弃了自己过去的OA，改用A6的。其中有一个国资委下属的特大型企业给我印象深刻，他们唯恐老总知道过去的OA已经失败，所以在项目报告上强调，他们原来买的是OA是用来处理公文的，而这次买的是“协同！”，实施三个月后，瞒天过海地停了老OA，全面迁移到A6，老板用A6用得很爽，每天上线最早，下线最晚，竟然乐在其中丝毫没有察觉老OA废弃了。这个老总后来受国资委指派调动到新的一个特大型企业作领导，第一个信息化要求就是上A6。
我估计在过去的15年中，中国至少有5000家厂商以项目的方式交付过10万套OA，有的极其简单如同网站，能够上传，有email、论坛就ok了，也有以公文、文档为主流的，更有极其复杂与mis、生产管理、erp、指挥调度、监控集成在一起的大型项目，但基本上上线率都大大低于实际应用覆盖范围。15%成功率其实是个乐观值。按照我的观点，即使用友致远公司的客户中能把A6的组织行为管理的价值发挥到了极致的也是极少数，大部分成功都是处于较为朦胧的价值认识情况下的初级自我满足。
关于OA的第一问其实答案很简单，但调整和纠正对OA项目的风险低估和盲目乐观，是走向成功的开始。
第二问：OA的本质是什么?这个问题有点哲学性，但确是CIO非搞清楚不可的问题，否则你无法建立这个项目与管理的支撑关系，你苦心孤诣整理的需求可能许多与战略并无重要紧急的关系，只不过是个人的软件细节偏好。关于这个问题我们至少可以从2个角度来看。
首先从管理信息化的角度来，我先问CIO一个问题，尽管你可能亲自负责上线了各自系统，但它们真正覆盖了管理的主要范畴了吗？
管理是一个抽象的名词，其外延一般以组织为边界，没见过那个老板把管理延伸到了员工家庭，那是侵犯隐私。从其范畴可以简单划分为两大领域：业务管理与组织管理
一是管理事情，如生意、业务，我们熟知的财务软件、销售管理、库存管理、采购管理、客户关系管理、分销、制造、合同管理、质量管理都属于这个范畴，关于成本的几块整合起来称为MRP-2，而关于物品的管理整合起来称为进销存，更多部分软件联通起来，提供更高层次的资源管理称为erp。但这仅仅只是覆盖了管理的一半－我称之为“业务管理”。这些软件最大的特点是管理初衷或对象是事情。至于不同环节是哪些人不重要，库管是张三采购是李四不重要，甚至互换一下也不重要，重要的是物品数量的准确性。
管理的另一个领域是大家天天都在经历的，常常警醒，为之疲惫，但常不得要领，觉得非常困难的是－管人！作为管理者，我们每天发号施令，找人谈话，听取汇报，批评表扬，有时候我们会被气得暴跳如雷，员工敬而远之，有时心花怒放，对员工笑脸如掬，这些现象都属于“组织管理”的范畴，组织管理和业务管理（政府也有业务管理），共同构成一个完整的组织管理范畴，二者相辅相成不可能截然分割。
接下来我们再看，组织管理中的软件非常少，就目前来看，也不过只有HR和kpi两种软件，后者还是初级阶段，组织管理软件的对象是人！其实所有的领导都模糊地意识到了组织管理的重要性，所以自发地采用了一些不包含任何管理理念的软件，特别是工具软件来完成组织管理的目标。比如，我们常见的用im进行沟通，用email进行反馈和协作，用网站进行对组织的大面积影响和信息对称，用论坛来提供群众参与的多元化沟通。&& 组织行为管理是现代管理学的重要基石，是研究组织的分工、个体行为、群体行为、工作管理、激励、变革。。。的科学，你只要买任何一本《管理学简史》都能看到，从古典管理思想，到泰勒的科学管理学派，梅奥的人际关系学派、德鲁克的经验学派、马斯洛的层次需求模型、授权模型、领导力模型，人性善、恶假说。。。。。。。。真的是博大精深，我等不过是初窥门径。
如果说，这些术语太过于晦涩，那么“执行力”、“文化建设”、“有效沟通”、“时间管理”、“有效授权”、“领导力建设”。。。。这些以《执行》、《赢在执行》、《基业长青》、《赢－韦尔奇自传》《谁说大象不会跳舞》、《蓝海战略》。。。。。等出版物的形式在最近几年深入影响了从张瑞敏到柳传志以及你、我和客户的领导的概念大家应该不陌生。其衍生出无数的出版物、培训课程、咨询项目正在逐渐影响一个又一个的组织。
世界上有无数的成功企业，其公认的核心竞争力无外乎有成本领先、差异化服务、品牌领先、技术领先，但从来没有一个企业领袖敢宣称自己靠管理领先，因此我们就知道组织管理范畴就算穷一生之力也难以成就巅峰，需要我们不断努力追求，才能在竞争中处于安全一点的位置。
我曾经和一个美国的投资银行代表交流过A6，他认为在美国也会非常有价值，另一个上海科技开发区的A6客户领导是加拿大裔华人，曾非常期望我们开发英文版，他愿意在加拿大代理销售，我相信A6是中国第一个真正意义上基于组织管理中最核心的部分组织行为管理设计的软件，其价值和市场不可估量。必将成为未来组织的基本工作平台。
从另一个角度看，OA的本质是什么？
其实是组织行为变革的革命，只不过手段是用OA，负责人是CIO或办公室主任，实际领导是大老板，全员参与的一场革命洗礼。
OA项目和上一个财务软件不一样的是它的应用范围决定了它是一个“全员信息化”的大事，这期间，应用范围的量变积累已经使得项目产生了质变的层面，已经涉及到了整个组织的“行为变革”范畴，这在管理学中一个大大的事件甚至需要用革命来形容。也许HR软件或着进销存软件使用失败了没有什么，甚至别的部门根本就不知道发生过，但OA不同，从上线那一天起，到最后无论好坏，每个人都知道你干过一件漂亮或者很糗的事情。
记住：OA项目的性质是一种组织行为变革的工具。
绝大部分CIO都是可爱的技术爱好者，也正因为技术的原因被领导指派作为OA项目负责人。不过组织行为学和组织管理学并不是CIO的擅长，所以CIO难以了解或者描述OA的价值，失去了以组织行为管理的价值准绳，只能凭借技术作为判断方向的依据，这样的选型想不失败都很难。
所以，你现在要清楚，可能并不熟悉管理的你要去推动一场组织行为的变革，代号是OA，你将在未来几个月中改变原来那些你熟悉的人的行为模式，把他们从电话、面谈、会议中拽出来，给他一个OA，让他们比以前的行为模式更加有效率，甚至感到比以前工作起来更快乐。如果你选的产品或者方案让他们感觉很痛苦，他们会以没有时间学习、不好用等各种理由抵抗你，你应该知道改变整个组织的行为习惯是非常困难的，习惯是人性的一部分，改变习惯就是扭曲人性，那种痛苦你如果戒过烟就明白了。现在你面临的情况更糟，就像你需要让200个烟鬼集体戒烟或者300个懒人准时起床晨练那么难。还有，面对领导的信任，你想退出是肯定已经来不及了，呵呵。掌握如何通过软件辅助推动组织行为变革甚至比采用什么类型的技术更为重要。
所有的用友致远公司人都明白自己是在从事一项伟大的事业，我们正在用创造力开创管理软件业中另一大分支－组织管理软件，我们会将新技术不断带入这一范畴中，把软件变成对组织中每一个人都有价值的工具。
第三问：OA的挑战是什么？对OA的挑战的研究一定要建立在对OA的本质的认知基础上，我们常见的现象是，CIO在立项中把需求的满足度作为最高权重指标，另外关注的是技术的先进性和安全性等等，这些都过于偏重技术了。他们到底忽略了什么？我看过一份IDC专门的调查研究报告，与我实践中求证的答案一样，那个答案却是CIO背景的人最容易忽视的。
在OA的本质探讨中，我们已经明确了，OA其实是一次组织行为变革的代号，其形式是软件部署和使用，实质是组织行为模式的变革，特别是协同模式的变革。
过去曾有无数的OA，在立项阶段cio和办公室主任，殚精竭虑地整理完整的需求，在支付了大量的金钱和时间之后，通过项目化开发得到了满足，但实际情况是根本没有人愿意用，是什么导致了这些需求的提供者拒绝使用系统？
这样的变革需要两种力量的参与，一是领导真正的重视，不仅仅停留在口号或者愿望上，需要身体力行，凡是成功的A6客户，在实施阶段都会给我们一个账号，我常看到那些位高权重的领导者常常是最早上线，最晚下线的人群之一。另外就是高度的群众参与，在评估成功的关键阀值中我们提到应用范围值就是这个特性的量化。
领导和群众，最大的共性是电脑应用水平低下，事实上一个在运作中的组织是难以从业务惯性中摆脱出来专门去从事整体的学习的，我们可以把财务部几十个人停下来专门学习财务软件，加班加点在电脑上重新输入凭证、记账，但我们无法让整个组织停下来3个工作日，学习OA软件，最多是轮流培训2天，绝大多数是一天甚至半天。
因此有个规律，应用范围越大的系统，其学习成本要求就应该越低，易用性是最大的挑战之一。关于A6的具体易用性体现可参见《回复伙伴如何理解易用性在A6中的体现与价值》
如果没有良好的易用性，学习的时间成本过高，应用范围值就达不到阀值，就会出现上协同的效率不如不上协同，OA的实施就走向负循环，走向失败。如果没有第一步成功，无论需求满足度有多高，都会失败。
CIO相对组织中其他人员来说，他太了解电脑了，这也是被挑选出来承担OA选型责任的原因，但他又不了解组织行为学，如果再不具备对OA的哲学认知，会在相当程度上忽略易用性。当我看到研究报告中“易用性”在总共10项诸如先进性、安全性、成本之类的要素调查中排名第一位的时候，深刻感觉到这真的是一个决策方面的悖论；CIO务必要清楚，对摄影家非常合适的专业级相机，无论性能参数都远高于民用消费级相机，但未必就适合普通的菜鸟爱好者。如果挑选OA时不注重易用性，那么不仅仅是造成曲高和寡的尴尬的可能性的问题；不同的是，个体的菜鸟可以通过学习成为摄影家，而组织内部的耗散特征则使得群体的菜鸟永远成为不了复杂软件的操作者（见第9问成功评估指标中的阀值效应）。以前的OA失败，至少有50%可以归罪为易用性问题。
另一项挑战是OA的粘着度（用户对系统的依赖程度），大部分OA系统都不具备粘着度，要知道无论需求有多厚，都是穷举模式的，而组织行为是无法穷举的，即使照猫画虎一一满足那些穷举的需求，你可能发现仍然有80%的事情无法在OA上处理。过去OA的失败原因就是只作关键性应用，我们熟知的公文、文档管理、办公室常用的功能等等，都是这种思路，就算有流程化审批，也只能穷举部分组织级审批，到部门级就太多了，干脆就不做了。他们草率地把80%的无法穷举的应用需求的责任推给了邮件！套用周星驰所说的那句名言－如果道歉有用，还需要警察作什么？－－如果邮件能解决还要OA干什么？
A6最大的创新就是有一个既能作关键性应用，又高度满足经常性无法穷举的“新建协同”，并且有高度的易用性，使得A6的客户几乎无论什么要求都能在协同中被满足或变相满足，这样使得客户对A6有高度的依赖性，从而形成易装易用－好用－爱用－深化应用的正向循环。
因此，系统是否能够平衡“关键性”和“经常性”应用是另一个最大的挑战
OA还有很多挑战，诸如实施风险之类的，但最大的还是在产品本身的，易用性和实用性，而大部分人可能对易用性容易理解，但对实用性却没有深入认识，我们通过大量调研，才认识到第二个问题，那是传统OA失败的根本原因。
第四问：OA的项目成功的要素是什么？OA的选型实施范围大、涉及面广，如果想让OA项目成为持续支撑组织发展的基础IT平台，CIO们必须以战略层面的眼光来思考，不能把OA作为急就章项目来看待，在我们看来成功的要素至少有这三点。
1、正确的选择产品或者项目方案：
& 你必需选择一个可以满足当前需求的产品或项目，否则以后就很难说了，但真得是以自己的需求为导向的选择就能成功吗？为什么那么多能够清理自己需求的项目仍然不成功？这是因为没有搞清楚产品和项目对自己的意义
2、 阶段清晰的渐进式实施
常见的对实施的认识大多局限于软件安装、公文流程定义，表单设计等等，大部分都缺乏对实施的整体认识，用友致远公司在长期的客户实践中，总结了实施3段论（共性应用－2:8原则、局部深化、集成应用） ，因为涉及到很多方面，限于篇幅，我在以后的9问的如何实施阶段规划中展开谈。&&&
3、 持续服务、升级的进步保障机制
持续升级的好处不说了，说说持续服务。持续的服务也许是供应商的一种良好愿望，但也许只是为了收款时拍胸口的豪言壮语，你必需清楚，一切可持续的事物都不是靠愿望，而是某种内在的东西在支撑。
&&&& 本章内容比较简约，但确是影响项目成败的最主要的价值观和方法论的基础，CIO们对此问题的充分认识和正确决策是保障项目成败的关键中的关键。因此下问中我们先不对上面三个分支问题作出深入的阐述，让我们从另一个角度，那些在过去曾经失败的CIO为何踏入了所谓OA的“CIO陷阱”来了解更多的细节。
第五问：CIO的项目陷阱是什么？ CIO通常是OA项目的负责人，中国的OA应用发展史可谓成也CIO败也CIO，在组织赋予CIO肩负起OA项目建设的职责的同时，不少CIO却充满激情地冲向陷阱。
陷阱一：缺乏长期规划有些CIO一般有当前的项目规划，而无长期战略规划，为项目的早夭埋下了伏笔。详情参见第7问：如何进行实施阶段规划
陷阱二：需求贪大求全如果你坚信自己采集的需求是一种客观的需求，是必须被100%满足的需求，那么你就离失败不远了。
如何认识自己的需求？
99.99%的OA需求都是发白纸给所有人采集汇总而得来的，以这样形式采集汇总的需求造就了中国过去近20年几乎所有的OA都走项目化或者看着别人的OA还凑合拿来就用。如果你也是这样整理需求的，那简直就是自杀，这种看上去合乎逻辑的需求成型方式里面却埋藏着失败的种子。
把一叠白纸发给单位内各个部门的10天后，或许你收到了他们的书面反馈，那么来让我们仔细看看这份需求吧。
也许每个部门都提出了自己的需求，详细无比，里面不仅是一个个以自我为中心的要求，而且充满着本来应该归纳到业务范畴的应用需求，甚至包涵着个别领导的软件嗜好。这些本位主义需求从来没有考虑别人的应用感受，只想着用起软件来自己更轻松，把任何没有用计算机处理的事情都推给OA。依照这种需求，世上没有一套现成的软件能够100%满足，甚至同行用的不错的软件也无法对你做到这一点。面对这些需求中复杂的术语和深奥晦涩的部门业务概念，作为项目负责人的你未必能够逐一甄别。你千万不可以简单地装订成册提交供应商，让他就这样去写应对方案，依据这样的需求开发出来的OA软件，可能功能看上去非常丰富，但实际上形成了一个个以部门为中心的应用孤岛。第一代的OA都是这么出生的，最后大家用起来一头雾水，这些看上去都是我们想要的功能为何总感觉那么别扭？问题到底出在哪？
我们研究发现这类OA普遍存在一个问题：如果我们要以整个组织高效协同为目标，那么那个把我们协同在一起的功能是哪个？
请不要轻率地回答这个问题，你说用公文？别逗了，公文只有组织中不到10%经常用；文档？文档可以分享，不过文档不能主动产生协同；IM？IM好像不能进行表单审批吧；邮件？邮件能作流程化审批吗？邮件能使得整个组织共享吗？邮件用于要事的授权你既不知道过程也不知道结果你能放心吗？要用邮件来完成组织的日常协同我们还作OA项目干什么？
所以你必须这么去整理需求，从繁杂浩瀚的细节中脱出身来，对本位主义一概放到后面，先找到一个组织共性的需求，然后才是关键部门的需求，最后才是重要角色的需求。这么说是不是太抽象了？没关系，你只要认识这个逻辑就行了。因为我们大约研究了中国数十家OA厂商，走访了数十家OA成功或失败的客户，仔细评估了超过200种常见OA的功能菜单，最后找到了那个共性的需求，我们发现它可能有成千上万种表现形式，但把其本质提炼出来就只有一个词最贴切地表达这个需求，那个词叫协同。这类需求的共性只有几个要素，包涵协同角色、协同诉求、协同流程规则、协同过程状态、协同资源需求、协同结果，无论你是什么行业，在什么样规模的组织，处于什么样的岗位级别，你日常的行为几乎80%可以归结为这个需求。
所以你在选型的时候一定要看，这个OA是否有这样的一个功能能够满足这个共性需求！
另外你可能有其他各种需求，有你敬畏的上级提出的，有强势部门提出的，有不起眼的人提出的，其技术难度和实施难度可能有天壤之别，你必须衡量敬重缓急以及其需求是否满足对全局的成败影响。否则这些汇总的需求将使得你毫无把握项目主干进度的节奏的能力，双方有限的资源被分解为千疮百孔补丁工程，重蹈前人久拖不上的覆辙。
“∑汇总式”需求对OA项目建设的副作用，缺乏共性需求的抽象提炼，主次不分，轻重不分，缓急不分，这必将导致前期实施目标点过多，局部各自兴奋，全局一盘散沙的局面，事实上你将成为需求平均主义泛滥的牺牲品，丧失把控实施进度的节奏的能力。
陷阱三：实现急功近利如果你认为软件只要会编程就能作，那你可就大错特错了！隔壁邻居家的高中男孩就能干的事情是写程序，属于个人娱乐，和摄影爱好差不多。而软件是包含责任关系的商品，需要复杂的支撑体系。软件业已经发展到工程学的水平，拥有严格的环节分工和检验标准。从需求开始，有专业的人员进行需求的采集、提炼、评估，形成应用的“概念设计”，经过评审后，技术高手会充分考虑诸多因素后提出“构架设计”，评审后才会到开发部形成 “应用设计”，评审后才会有“代码开发”，然后是“功能测试”(诸如白盒测试、黑盒测试、性能测试、压力测试、环境测试、安装测试等)，然后才能交给你。这期间，所有的环节都应该是最优质的人力资源在保障质量，所以你千万不要指望找到一个非常廉价还百依百顺的供应商，根据你的指令快速而完美地帮你达成目标。
陷阱四：选择片面求新对新技术的片面性追求常常导致项目成为了项目负责人（特别是CIO）自娱自乐的畸形产物，即使探索的精神无可厚非，但是毕竟尝试性的技术探索对于组织应用所期望的稳定性、实用性无疑是高风险和高成本的。不少项目负责人会认为“最新的技术”＝“最先进的技术”。这种认知是非常片面的。
在我们看来，所谓技术先进性的价值不在于先进本身，（许多CIO会认为，使用新发明的技术就是先进的标志，这实在是本末倒置了，全球银行业和证券业用的技术至少都落后于新技术好几年）而在于先进对扩展性、性能、安全性、集成性、易用性（常被CIO所忽视其实对终端客户的影响排在第一位）等诸多应用的现实价值和升级成本的抑制。而且由于协同管理软件的价值并不仅仅依赖软件本身，其布署过程和应用推进能力也对其价值发挥起到至关重要的作用。我们绝不能忽视这样的现象DD同样的软件在不同的单位对价值有截然不同的评估，所谓花巨资上马的大型软件成为摆设的情况比比皆是。我们相信CIO对于软件的评估侧重应用和技术是理性的，但我们也同时注意到，CIO对于推动组织建立新型工作行为模式的艰巨性和挑战性的重视程度不够，常在对未来技术应用发展趋势的无限可能性的苦思冥想中忽略了组织与协调成本，导致系统实施成为踏入泥潭的第一步。只有对诸如布署的阶段性、短期用户学习、中期应用感受、长期需求发展、总体拥有成本等诸多方面与软件本身的综合形成的价值观和方法论是否适合特点的客户才是评估所谓先进性的标准。
陷阱五：实施缺乏导向实施被不少CIO理解为软件开放、安装调试、培训、测试、上线这一类的事务，但我们认为这不是实施，至少实施的目标错了，不是结束一个软件的部署过程，而是在这个过程中达成管理提升的目的，如果是前面所说的工作是必需的过程，那么达成管理目标才是实施的结果。遗憾的是，极少才有CIO在实施计划中明确地提出管理提升目标，最高的层次也就是具体枝节需求的满足。最理想的结果也就是安装了一套对大家没有价值感受的软件！
第六问：如何认识产品和项目对自己的意义事实上，CIO在OA方面只能有三种选择，一是标准产品，二是个性化开发，三是产品＋局部定制。信息化程度、管理成熟度不同的客户对OA的期望值是不同的，另外CIO的技术偏好会导致对需求的客观性不足。
先认识一下产品：
产品化从视觉上看到的只是包装盒中的光盘、加密狗、印刷说明书（印刷品是批量的标志）、服务卡，但产品化实际上是一个复杂的商业系统，由需求流程、概念设计、构架设计、程序代码、测试流程、销售、实施交付、售后服务、升级服务等多种岗位专业人员协作构成的。
产品有产品的好处，也有产品的不足，好处是意味着在你之前有无数用户验证了功能的适用性、性能、稳定性、并且可以持续升级，是成熟的象征，是与客户的长期合作，如同婚姻。产品化还意味着高性价比，这是绝大部分客户所关注的。产品化总得来说是低风险的。
由于用友致远公司开创了OA的产品化格局，因此最近不少厂商都在宣称自己是产品化，有CIO为此困惑，问及我如何识别，我告诉他很简单，可以通过该厂商的网站上识别，产品化供应商能看升级公告，没有版本升级公告的则属于李鬼，客户可以从用友致远公司的网站上的客服公告中看到我们是如何从2.1版花了近5年数万个人工日一步步走到今天的。
产品化的不足是，不能一次满足满足所有细节需求，客户在选择时需要对需求有所舍弃，另外产品化的升级节奏可能与你的需求的成长的速度之间的匹配是个问题，这就需要你在产品化厂商中选择那些内部资源雄厚，流程顺畅，支撑保障机制健全的厂商。
再看看项目：
项目是只有些代码是为客户量身定做，与此同时丧失了标准化升级的可能性的系统，其关键在后者而不是个性化代码的多少。
其实大部分项目化供应商都恨不得一行代码都不改就交付给另一个客户，但局限于上一个客户的个性化代码的存在，使得他们不得不吃下自己为满足一个客户的需求代来的苦果。
项目化是高成本的，首先技术人员比实施人员成本高，你们要告诫客户，如果优质的程序员是价值昂贵的稀缺资源，客户最好不要相信花1万元就能作出个好项目。二是长周期的，短期赶出来的，不可能没有问题，看看微软这么伟大的公司还有不少bug呢。项目漫长的测试、优化周期造成了高成本；三是供应商的商业模式造成的，如果是项目型的厂商，只能通过尽可能通过每一个项目的价格最大化回报来挣钱，因为它们没有把握像产品化公司一样通过客户数量挣钱。
项目化是高风险的，从需求分析开始，到技术路线选型、构架的扩展性设计考虑、优质高效的代码实现、完善的测试，所有这些环节，都需要客户和供应商双方投入最顶尖的人力资源，才足以做到业界一流水平，悲惨的是，这根本不可能大面积出现这种理想情况，一个供应商只能有一个顶尖项目经理，他不可能在每一个项目上投入，而客户方，更是稀缺能够精通OA，具备战略思维，又能细致深入把握需求、协调实施的PM（项目经理），这种人月薪身价都在2万以上的。所以我们不难理解为什么这么多OA的烂项目，说穿了，就是2-3流人员在瞎折腾。他们在我提到的这些环节中任何一个失误都会让客户未来付出代价。
项目化最大的局限性是长期发展机制，如果没有每年配套的充足的预算，你怎么可能长期要求供应商持续为你研究、优化、升级？在技术日新月异的今天，没有最好的，只有更好的。
中国式项目化是与客户的短期合作，是一夜情模式。
比较了两种模式之后，客户无疑要作个决断，大部分客户会选产品化。有极少的客户选择项目化，但有一些客户还是期望在购买时获得承诺满足产品化尚无法满足的个性化需求。这种情况下，导致了第三种模式的出现－产品化＋局部定制。
产品化＋局部定制仍然会导致两个结果，客户的需求如果产品构架可以支持以扩展模块的方式满足，那么万事大吉，如果产品化的技术构架不支持，客户的需求如果要满足，就只能以调整构架，牺牲升级来换取。A6的构架最早根本不支持，现在开始逐步支持到逐步成体系，这是一个漫长的接口的发育过程，需要漫长的实践积累才能保证接口的成熟度。
我也曾经多次遇到客户个性化需求的重压，提出如果不满足就不买或者不付余款之类的，我会客观地与研发评估其需求实现属于可升级型或不可升级型，成本有多大。如果属于可升级型，我会坦率提出版本升级或付费局部定制成本问题，如果属于不可升级型而用户又坚持要这个功能，我会告知用户我作的先决条件是客户签署一份“放弃升级的申明”。有意思的是，这种鱼和熊掌不可兼得的局面下，我们与所有的客户都达成了一致－－部分版本升级满足、部分以不影响升级的局部定制满足，部分舍弃。从而保持了系统的可升级性，因为从长远看，升级所换来对全局性的价值远远多于局部的个性化满足所带来的价值。
由于项目的个性，实际上持续服务是不可能的，我曾经和一个CIO开玩笑，当他宣称必须完全满足需求的时候，我说，你只能选项目，另外一个问题是你有宗教信仰吗? 他说他是党员。我回答说:你最好选择一个宗教，管他是佛教还是基督教，重要的是你要养成每天祷告的习惯，你要学会相信老天和神灵保佑你这些事情：项目文档不要在2年后丢失、供应商项目经理不要离职、不要跳槽、不要考研究生、不要出国、不要开车超速出车祸或者游泳淹死。。。。这些情况中任何一种发生，都将导致你不能享受到以前的服务水平，你不能期望一个对你项目代码、构架需求毫不了解的新来的家伙能够给你高质量服务。
呵呵，想到这一切的可能性，他差点当即晕倒。
反观产品，如此众多的客户不仅使得产品经受了个体完全无法达成的覆盖性测试，这些测试中的bug反馈和需求反馈又进一步导致了产品加速完善。最重要的是使得我们的客服能够形成版本知识库，有了这样的知识库，我们几乎能够回答90%稀奇古怪的问题－其中大部分是IT环境问题（病毒、插件、IE版本、补丁没有打之类的），而且并不因个体人员的变动导致服务质量下降。用友致远公司的客服不仅在积累知识，而且在学习和研究不同阶段客户的应用特点，早已经从被动客服（出了问题找客服）上升到了主动式客服，我们知道新客户会遇到什么问题，在应用深化时能够给客户来自其他客户应用的经验参考，我们的主动式客服月刊就体现了这一点，总之产品化让我们见多识广，知识库让我们专业化，众多的客户经验让我们从解决问题上升专家指导型。
这几年来，约有15%的A6客户是废弃了原先的oa重新购买了A6，这是因为过去的OA的项目化导致了项目发育停滞－我常告诉客户，项目化的验收之日就是OA成长的死亡之日，只不过要1－2年才显露出来，供应商撤离，客户PM转移到其他项目，对OA项目来说，无异于根须死亡，树叶发黄凋零是迟早的事情。
产品化是中国大部分客户能接受的长期发展保障机制，项目化要想长期保障，太贵了，你想想你是否玩得起！
第七问：如何进行OA的实施阶段规划？大部分客户的项目经理都会根据老板的期限有一个实施规划，分为调研、方案、启动会、实施、培训、测试、上线、正式运用等等，实施顾问会和你一起根据项目的大小、难度、重点去作出对应的方案。经过多年的实践，用友致远公司的实施方法论已经非常完善，有几种不同的模板，甚至能够提供启动会上董事长、总裁的发言提纲，你想大张旗鼓地推进A6的全面应用吗？给我们打电话，我们甚至会帮你搞到一份A6实施海报，上面有一个职业佳丽伫立在电脑旁，笑意吟吟地看着你的同事，旁边有文字曰：今天你协同了吗？
但这是不够的，你不过完成的是当期的实施规划，你如果了解了OA的本质，认识到这是一个长期而艰巨的组织行为变革的挑战，而你没有战略规划，你可能会把不该这个阶段完成的事情纳入进来，混淆了主要问题和次要问题，甚至会导致失败。
首先，你应该有一个长期战略规划，你需要知道OA的应用不是一蹴而就的，所以你不要期望把所有的问题在今天解决。
根据我们的经验，我们建议你至少要规划三个阶段
第一阶段：共性应用阶段一阶段的使命是保障快速上线，尽快建立组织级协同方式的新的习惯和模式，你现在已经知道这个速度是非常重要的了，所以你必需对一阶段的需求进行准确的确定，如果你不加控制，你可能会无意中设定了过多的目标，最糟的是每个部门都有自己的重点目标，大家都陷入到自己的细节需求的满足、扯皮之中，仍然没有协同起来。
我们有一句很哲学的描述第一阶段的应用特点：最大范围的最小应用。够抽象吧，意思是你除了公文、文件夹之类必不可少的应用，你首先应该推动的是“自由协同”，自由协同会快速地让所有人感受到电脑协同方式相较于传统协同的优势，放心吧，很快，最多2周，如果你能促进每个人每天上线2-3次，那么大家都会爱上协同的。当你看到这样的情况。领导在走廊抽烟，远远的一个下属喊道，xx总，我昨天把项目材料搞完了，然后你听到x总大声地回答：好了，你把它协同发给我吧。你就知道，第一阶段大功告成了！
第一阶段是成功的第一步，不积跬步无以致千里，如果第一步倒下，就不会有未来。关于第一步的衡量指标就是我在第9问中提到的:衡量成功的简单指标的2个阀值和2个月期限。
第二阶段：深化应用阶段即使在同一个单位，也不是每一个部门的管理水平都是一样的，同样A6的应用深度也会不同，流程繁杂的部门领导重视流程梳理和效率，文档如山的注重文档管理，知识变化快的注重知识管理，总经理工作部、办公室注重结果，项目经理注重过程和跨部门信息对称。。。。。。。
因此，你要在第二阶段，进行二次实施，这次是以部门为中心的管理深化，通过A6把部门管理的难点、重点通过深度实施解决掉，而且刚才说到的问题很多还需要组织保障－在部门中设置兼职岗位落实到人，这样才可以检查和推进。
如果运气好，你大约可以用半年到1年的时间完成这一切。那时候，你们单位的流程有序了，而且建立了流程设定的流程，一个又一个新流程在自由协同的实践中逐渐成熟，转化为模板，上升到制度；你们单位的每一个大一点的部门都有了肩负oA深化使用的兼职人员甚至是专职人员，并且可以考核他们。单位第一次设置了总监或副总级别的知识管理负责人，有了知识的筛选标准，强制的采集上报制度，知识贡献的激励。。。。。注意这是一场变革，没有组织保障是不行的，没有激励也是不能持久的。
第三阶段：整合应用阶段。这里的关键在于整合什么？单点登陆，A6现在一配就行，A6的关联系统支持单点登陆访问其他系统的松耦合，甚至支持接口数据交换方式的整合，比如U8插件能通过U8eai接口实现A6报销单－U8待记账凭证之间的转换。但你如果选择深层次两个系统之间进行数据级紧耦合，那一切都不一样了。
很多CIO错误地把深层次紧耦合整合需求当成了第一阶段目标，从一开始就自讨苦吃，要知道，整合的基础是两个或更多的系统在完成了自己的深化应用（复杂的系统都有这3个阶段）基础上才有整合的价值，如果你像我一样在软件业干了18年苦活，你一定会像我一样感慨，在通往信息化的道路上有多艰难啊。没有任何一个cio有把握能让任何一个系统都应用成功，用上1-2年就换掉系统的比比皆是，更郁闷的是系统还行，厂商死掉了，这样的情况下，需求的细节没有清楚、缺乏深度分析和前瞻性的设计、当前技术发展尚不足以支持扩展性，那么草率地把整合愿望付诸实施将成为你职业生涯的梦魇。深度整合就是项目！看过上一问的项目和产品比较你就会知道你在挑战的是你自己的综合素质的极限发挥，超越自己远远比作一个项目难。所以最后项目多半以两败俱伤、潦草收兵。
整合阶段是一场艰巨的战斗，在此之前，你务必要做好足够的细节准备，否则就是对你、对你的单位、对供应商伙伴最大的不负责任。
有CIO曾经问我，这三个阶段需要多长的时间？根据我对众多组织的信息化发展的了解，我认为三个阶段2-3年内实现，比较现实，我的建议仅供参考，谬误之处包涵并指正。
第八问：如何建设OA项目的长期发展机制？&&&&&&&&&&&&&&&&
其实答案在阶段规划中已经谈到了，不过这次我们站在组织而不是实施的角度另外来看一看。
首先明白机制是什么，机制字面的含义是机能和体制，在组织中表现为分工和职能设置、授权、流程、考核、激励等综合反映。机制不是靠一纸公文就能搞定的，需要认真的分析和慎重决策。
从实践层面来看。我认为要想让OA成为一个组织管理的重要平台，真正发挥作用，那么必需要考虑长期发展机制。
首先要考虑解决OA的定位问题：
对项目的定位将决定项目的价值贡献和发展，由于缺乏对OA本质的了解，绝大部分客户都把OA当成了一个阶段性项目，没有意识到，如果能充分重视A6，A6将成为一个强大的战略实施的支撑平台。如果说基于互联网的库存管理系统将支撑你的企业在全国性扩张的战略，那么A6就将是你在全国范围内进行组织管理的支撑工具，无论是你收购、兼并、内部重组，A6将忠实而快速地反映组织的变化，并支撑快速的流程调整（在A6中更换模板的流程节点你甚至不用通知任何人，他们只需要用就ok了），汇总非结构化信息建立中央知识管理，与ERP的结构化信息相辅相成覆盖整个管理范畴。
其次是要解决的岗位职能设置－OA专员
因为定位的问题，所以很少有客户能为A6的发展设计专门的岗位，如果把A6定位在一个软件，那么找个职高生来完成数据备份，定时升级之类的小事也确实无可厚非。但如果是定位在组织管理和战略实施平台，那么A6的发展将影响到整个组织能力的提升，你就不能再考虑用高中生了，你需要考虑一个在单位有多年工作经历，熟悉各个业务部门情况，具备协调组织能力、至少是对组织管理充满兴趣的人。他在你们单位是谁？他的使命是在上线后未来的2年中完成二阶段和三阶段领导。按照我的理解，非资深人士不可，而且他还得不断学习。
另外随着应用的深化，要设置的岗位有：部门知识管理员、HR部门或企管办执行力和文化建设的监督员来配合，当然，这些人只需兼职即可。
第三是授权：
即使设置了专人，我还是很难相信业务部门那些扛销售指标的骨干甚至是高层大爷们会对一个这样一个角色充满敬意，出于人性的原因，他们会不自觉的抵抗任何改变习惯的变革，他们会因为打字慢而不愿意输出任何东西，他们会解释说销售压力大、事情多，没时间学习，没时间打字，给你电话汇报就行了，这时候你该如何？
作为企业管理者，你必需对OA专员授权，并且在公众场合，你可以审查他的规划，避免他过度实施干扰正常业务，但你也必需在众人面前给他树立威信，给他对不按照审定的规划进展的部门或人有处罚的建议权。
第四是制度化保障
如果要在一个组织中推出一个重要的举措，那么就不是仅仅通过公告告知那么简单的了，你应该考虑制度化，你应该建立“xx单位OA使用规范”，把OA的使用变成制度、使之合法化，明确高压线－那些绝对不能违背的事情（比如非出差生病的情况下多日不上线之类的）和处罚标准（最好是经济手段）。
第五是正向激励
如果变革没有好处，谁愿意变？所以激励很重要，激励不是心血来潮的赏罚，除了处罚，我们应该去创造更多的奖励，我们可以结合知识管理设置知识贡献奖，可以征求对流程的建议给流程优化奖，可以鼓励员工在论坛分享竞争情报，鼓励管理建议，奖励部门文档管理水平率先达标的团队，第一个使用关联项目进行跨部门协同的动态团队。。。。。。鼓励表彰的过程中，企业的价值观中推崇什么一目了然，文化逐渐成型。
这一过程中，领导的参与也是一种奖励，更多的管理者应该习惯于在论坛中回复基层员工对战略的问题，通过论坛了解组织运转的问题，及时提到解决日程中来。
最后只有一个需要解决的问题：谁与你同行？
从未来的理想远景中回过神来吧，就算你明白了所有的道理，你还是要在今天对这些所有的思考转化一个基本的决策，你将选择哪一家OA供应商作为支撑OA长期发展的伙伴？正如你想象的那样，你要选择的供应商不仅产品要有关联理念，符合组织管理的需要，还要功能设计的非常简易，能帮助你快速达成一阶段的成功，更要有对组织管理实践的深入认知，能给你提供咨询和建议，最最重要的是要命长，能存活到你成功的那一天！
第九问：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阀值要求的项目风险会大大增加。
另外我们还有一套经验计算公式，可以计算OA的直接效益和投入产出比，帮助CIO在作项目效益分析时为领导提供决策的依据。
此外，真正衡量OA成功的是管理贡献，那将是一个更加复杂的话题，其中推动管理的创意和实践结果是最有非常有趣和有价值的。
后记总算通过9问OA把我这几年对OA的认识给大家作了一个汇报，文中为了阅读感受，不少地方将CIO作为了第二人称的探讨对象，恐有咄咄逼人之感，此当非我本意。我并不想以指责CIO为乐，也没有资格以CIO的导师自居，我期望的是与CIO进行客观、坦诚、深入的交流。事实上我的探索认知正是来自于我的CIO朋友们无私坦诚的分享，甚至包括他们曾经经历过的失败教训。今天我不过是将这些心得其整理出来，供那些从未谋面CIO朋友分享，希望能为大家在实施OA选型和实施过程中提供参考。只有通过我们共同的努力，我们才有可能实现双赢！
在此我感谢我的CIO朋友们，特别是中电投集团的宋怡强先生、中电国际的黄云涛先生、中电霍煤集团的刘志强先生、孟庆海先生、中邮电集团的姜作旭、张墨春先生、中国国药集团的曹国钧、李慰先生、锦西化工集团的袁戎先生、深圳海洋王集团的黄修乾博士、吴中集团钱建明先生以及无数A6客户中的CIO朋友。我知道，你们所在单位中甚至还没有设置CIO的正式职位，但你们所作的正在履行CIO的职能，尽管你们在IT产业界中或在所处行业外默默无闻，但你们是我心目中的支撑中国组织信息化发展的真正的IT英雄。感谢你们过去、现在对我们的支持和信任，我们将继续努力来回报你们以及所有热爱事业的CIO朋友们。
上一篇文章： 下一篇文章：
&&&&&&&&&&&&&&&&