办公OA系统简介.docx

《办公OA系统简介.docx》由会员分享，可在线阅读，更多相关《办公OA系统简介.docx（5页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、办公自动化系统介绍OA办公系统即OA，是Office Automation的缩写，指办公室自动化或自动化办公。其实OA办公系统是一个动态的概念，随着计算机技术、通信技术和网络技术的突飞猛进，关于OA办公系统的描述也在不断充实，至今还没有人对其下过最权威、最科学、最全面、最准确的定义。当今世界是信息爆炸的知识经济统治的时代，在这种情况下结合技术的各种进步所产生的OA办公系统已与十几年前的OA发生了很大的变化。原理OA办公系统不仅仅是企业办公的一种工具，更应该是一种有思想、有模式的懂管理的软件，目前市场上主流的协同OA办公系统就为现代企业发展注入了强劲的动力，协同OA办公系统是在研究现代组织实践案

2、例和管理理论发展方向的基础上，结合神经网络的研究成果而设计的协同管理系统。它以动态组织为行为主体，以工作流为传导模型，以任务为处理模型，将组织行为的复杂性通过三者的结合充分表现出来，从而帮助实际组织解决管理过程中的复杂课题。 OA办公系统管理模型组织价值在于“使用有限资源创造最大化价值”，现代组织的典型代表是企业，企业创造价值是通过三个层次进行体现的，即战略、战术与执行。战略，是领导意志的体现；战术，是管理方式的体现；执行，是操作能力的体现。任何战略和战术意图最终都是通过执行来实现的，但在战略决定战术、战术决定执行的同时，执行也反过来影响战术、进而影响战略。但遗憾的是，在企业的实际运行中，常常

3、出现的情况是：因为执行环节上出现问题，而最终使战略意图变得面目全非。 协同OA办公系统将执行中的三个要点：执行者、目标与过程管控，通过动态组织、工作流和任务三者，将执行相关的各种信息和应用紧密集成在一起，并用权变组织、网状沟通、关联结构和控制反馈四个管理模型实现各个执行体之间的融会贯通和统一管理，从而为企业提供实现人力资源、资金资源、产品资源、客户资源、知识资源的高度整合和统一的工具，帮助企业逐步走向虚拟管理、敏捷办事和互动沟通的高级形态。 编辑本段OA办公系统需求特征随着知识经济时代的到来，社会进步正在不断加速，组织迫切需要一个可以实现内外资源整合的高效的信息系统，从而提升其管理水平。具体表

4、现在： 1）需要一个高效的协同管理工作平台 能够将组织管理中的业务活动、管理活动及活动产生的信息在组织、部门、个人之间进行及时高效、有序可控、全程共享的沟通和处理。 2）需要一个有效的知识资产管理平台 过去在组织的信息化建设过程往往重视人、财、物这些有形的物质资产管理，忽视了知识资产的管理，需要借助知识管理工具对组织内外的知识进行有效的获取、沉淀、共享、应用、学习和创新，从而提高员工的素质和技能、执行力。 3）需要一个个性化的系统访问门户 传统的OA功能比较单一，员工容易使用，随着功能的不断扩展，员工对功能的需求也不尽相同，这就要求系统必须具有人性化设计，能够根据不同员工的需要进行功能组合，将

5、合适的功能放在合适的位置给合适的员工访问，实现真正的人本管理。 4）需要一个良好的组织文化管理平台 开放的社会造就了开放的社会人，组织规模的不断扩大，导致领导与员工、员工与员工间的直接沟通机会越来越少，组织需要构建新的文化环境，便于员工相互沟通、增进了解、发现思想倾向并及时加以引导。 5）需要一个集中的信息整合呈现平台 办公系统是组织内使用面最广泛、频率最高的信息系统，希望能够通过办公系统实时、直观地了解到组织的运营状况（如生产、营销、财务等数据），同时有效地解决组织内“信息孤岛”问题。 6）需要一个灵活的业务流程整合平台 当组织面临客户不断提出端到端的服务时，员工办公环境将会越来越复杂，因此

6、需要将日常工作活动、管理活动、业务活动有机的结合，以快速响应客户需求，同时减少不必要的重复工作，将管理流程与业务流程进行有效的整合。 综合上述各种新的需求不难发现，现阶段的OA系统将以知识管理为核心、以实时协作为技术支撑手段，以统一的知识门户为展现方式。 编辑本段选择OA的误区案例越多越好 在选择OA产品时单纯以软件产品的案例作为软件采购的标准，甚至唯一标准。然而这对于IT技术日新月异变化的软件来说，这个标准往往让你选到的恰恰是过时的产品，甚至于即将被淘汰的产品。一个最有说服力的例子就是，3年前出的笔记本电脑或电视机的案例肯定比今年新推出的笔记本电脑或电视机的案例多得多。可是3年前的电脑，3年

7、前的电视机还有人要吗?同样，在移动OA领域，技术的进步更是日新月异，智能机和3G的引入就是最近一两年出现的，显然基于非智能机和非3G环境的设计在技术的先进性上已经落后但是案例必然比前者多。此外，前几年的第一代的移动OA采用的是短信技术，第二代移动OA采用的WAP技术，这种技术已经被淘汰，它们的案例也一定比刚刚发展起来的采用Web Service技术的第三代移动OA多的多，但是现在这种技术还有人使用吗？在技术的进步以指数级增长的今天，一味地追求案例多，只会选择到一个技术上即将被淘汰的产品。因此选用软件第三条准则就是：绝对不要以案例多作为选择软件的唯一标准 。1 1 编辑本段自己开发首先，OA系统

8、已经涉及到越来越多的学科技术，包括计算机、通信、网络、管理与行为、多媒体、数据库、图形图像等等，是一个需要综合各种人才的团队工程，一个或者几个普通程序员已经很难做好； 其次，单位内部的程序员受行业和职位限制，无法掌握最新的管理理念及其发展趋势，往往只能对市面上的OA系统和自己单位的办公流程进行简单模仿和克隆，不能够真正实现提升管理水平的目的； 再次，频繁调整OA系统会严重影响员工的快速掌握和正常使用，延长融合期； 最后，开发OA系统需要耗费大量的人力、物力、财力、管理、时间成本，不可控因素很多，综合费用最低也要几万元，很多都要数十万元，显然得不偿失。 因此除了个别特大型企业和敏感性单位，建议普

9、通企业不必自己开发。 编辑本段技术架构及性能要求整体技术架构：采用系统为B/S架构，采用客户端浏览器-WEB应用服务器-数据库服务器三层结构，采用基于履盖率最广的、成熟的微软的.NET系统构架；此类系统国内较为知名的有天络在线等主流品牌。 系统一体化：系统采用统一部署，集中管理的方式，实现统一登录、统一权限、统一界面、统一基础数据管理； 开发工具：采用.NET或者JAVA语言进行软件开发； 数据库：支持SQL SERVER 和 ORACLE数据库作为系统数据库平台，客户端浏览器需支持IE6.0，客户端操作系统需支持Windows 98/me/2000/xp； 系统实用性：系统采用搜索引擎的概念

10、，通过一个操作界面的进入，尽可能的把用户所有想查询的信息都关联起来，避免使用者进行大量的学习和记忆，让使用者操作起来轻松自如； 系统易用性：系统界面采用了大量的图形化的方式，使用人员操作更加的形象，针对系统的界面以及各种信息的提示，系统也进行了二次的封装，全部是标准的中文提示，避免出来系统级的英文提示； 系统适应性：系统本身采用的是三层技术架构以及模块式的开放方式，即实现了操作层、业务层、数据层的分离，以及各应用模块的独立，这样适合公司根据实现情况进行调整； 系统开放性：系统采用了市场上最成熟的编程语言.NET、数据库 MSSQL、三层结构框架，这些技术对后期的维护与升级是非常简单； 系统扩展

11、性：系统本身是一个工作流平台，已经预留了大量的数据接口、动作接口，可以实现与门户网站、第三方业务系统、第三方应用系统的无缝对接； 系统安全性：系统采用了硬件加密锁、128位加密算法、IP地址锁定、在线自动检测等多重安全机制，确保系统的稳定与安全； 系统承受能力: 系统运行稳定可靠，系统资源占用低，系统满足能无限公司数，能支持6层以上组织结构，支持1000以上的瞬时并发数，能支持公司或部门迁移等在线处理业务能力。通过LoadRunner 负载及压力测试； 权限设置灵活性：系统涉及到的部门、公司比较多，公司权限比较分散，因此要求系统比较灵活的对系统权限进行灵活分配。系统能够实现控制界面上的每一个菜

12、单； 系统的应用速度：系统可以同时支持1000人并发数据处理，系统从数据底层架构到应用层的处理，都经过了严格的数据压力测试保证了系统的高效运行，不会出现系统速度奇慢的现象。 编辑本段oa测试一、经验不足：这个当然要靠不断的测试去弥补，单纯的按照测试工作年限去衡量一个人的经验是不对的，因为如果结合理论和实际去积累经验的话，一年经验不比两年经验差。 二、抓住测试重点：比如这个OA系统，包括好几个子系统在里面，有员工管理，图书管理，招聘管理，考勤系统。当初测试的时候根本没有去比较这几个系统的轻重问题，后来我一想才知道，重点应该是考勤系统，因为这个系统涉众最多。在实际测试中，我测的最不仔细的恰恰是这个

13、子系统。因为其他子系统的功能比较好测试，不涉及代码方面的东西。然而考勤系统比较复杂，特别是邮件方面的，一周发一次邮件，必须修改代码才能完成测试，后来开发的跟我说，要么这个功能我自己来测试，但是后来就是邮件功能出了问题。教训：测试的覆盖率要保证，抓住关注度比较高的主要功能进行仔细测试，一定要自己确认！ 三、控制提交版本次数：个人觉得测试版本次数应该控制在三到四次，不能修改几个BUG就提交一个新的版本（当然，有时候要修改某个BUG以后才能方便以下的测试，这个就要特事特办了）。一般流程是：提交一个测试版本过来以后，按照测试用例跑一遍，在跑的过程中，可能会想到新的扩展路径，这个时候一定要把扩展路径写到

14、用例中去，一般都要完全跑完了以后再提交下一个版本。这步完成了以后，开发人员肯定改BUG去了，利用这个时间进行随机测试，主要测试点当然是出现BUG的地方。开发把BUG都出来好了以后（FIXED的，postpone的，reject的），提交第二个版本，这个版本提交过来以后，首先要做的肯定是BUG验证，验证BUG是否真的已经修改。然后进行第二轮测试，这轮测试可以有选择的测试一些模块。接着再提交第三版本进行，这个版本花的时间不多，主要是扫除漏网之鱼。这个时候就可以根据系统情况，感觉还有问题的话，提交最后一个版本，按照用例跑一遍，OVER。 四、分类相似BUG：比如删除重要数据时，要给出确认删除的提示，通常如果一个模块有这个问题，其他模块也会有这个问题，这个时候一定要把这些全部找出来，提交到BUG管理工具中去（TD等）。