办公OA系统简介

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

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

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

4、进步正在不断加速， 组织迫切需要一个可以实现内外资源 整合的高效的信息系统，从而提升其管理水平。具体表现在：1 ）需要一个高效的协同管理工作平台能够将组织管理中的业务活动、 管理活动及活动产生的信息在组织、 部门、 个人 之间进行及时高效、有序可控、全程共享的沟通和处理。2 ）需要一个有效的知识资产管理平台过去在组织的信 息化建设过程往往重视人、 财、物这些有形的物质资产管理， 忽 视了知识资产的管理，需要借助知识管理工具对组织内 外的知识 进行有效的获取、 沉淀、 共享、应用、学习和创新， 从而提高 员工的素质和技能、 执行力。3 ）需要一个个性化的系统访问门户传统的OA功能比较单一，员 工

5、容易使用，随着功能的不断扩展， 员工对功能的需 求也不尽相同， 这就要求系统必须具有人性化设计，能够根据不同员工的需要进行功能组合，将合适的功能放在合适的位置给合适的员工访问， 实现真正的人本管理。4 ）需要一个良好的组织文化管理平台开放的社会造就了开放的社会人，组织规模的不断扩大， 导致领导与员工、员 工 与员 工间的直接沟通机会越来越少，组织需要构建新的文化环境，便于员工相互沟通、增进了解、发现思想倾向并及时加以引导。5 ）需要一个集中的信息整合呈现平台办公系统是组织内使用面最广泛、频率最高的信息系统，希望能够通过办公系统实 时、直观地了解到组织的运营状况（如生产、营销、财务等数 据），同

6、时有效地解决组织内信息孤岛 问题。6 ）需要一个灵活的业务流程整合平台当组织面临客户不断提出端到端的服务时， 员 工办公环境将会越来越复杂， 因此 需要将日 常工作活动、 管理活动、业务活动有机的结合， 以快速 响应客户 需求，同时减少不必要的重复工作， 将管理流程与业务流程进行有效的整合。综合上述各种新的需求不难发现， 现阶段的OA系统将以 知识管理为核心、以实时协作为技术支撑手段，以统一的知识门户 为展现方式。编辑本段选择OA的误区案例越多越好在选择OA产品时单纯以软件产品的案例作为软件采购的标准，甚至唯一标准。然而这对于IT技术日 新月 异变化的软件来说， 这个标准往 往让你选到的恰恰是

7、过时的产品，甚至于即将被淘汰的产品。一个最有说服力的例子就是，3年前出的笔记本电脑或电视机 的案例肯定比今年新推出的笔记本电脑或电视机的案例多得多。可是3年前的电脑，3年前的电视机还有人要吗？同样，在移 动OA领域，技术的进步更是日 新月 异，智能机和3G的引入就 是最近一两年出现的， 显然基于非智能机和非3G环境的设计在技 术的先进性上已经落后但是案例必然比前者多。止匕外，前几年的第一代的移动OA采用的是短信技术，第二代移动OA采用的WAP技术，这种技术已经被淘汰，它们的案例也一 定比刚刚发展起来的采用 Web Service技术的第三代移动 OA多的 多，但是现在这种技术还有人使用吗？在技

8、术的进步以指数级增长的今天，一味地追求案例多， 只会选择到一个技术上即将被淘汰的 产品。因此选用软件第三条准则就是：绝对不要以案例多作为选择软件的唯一标准编辑本段自 己开发1 1 首先，OA系统已经涉及到 越来越多的学科技术， 包括计算机、通信、网络、管理与行为、多 媒体、数据库、图形图像等等， 是一个需要综合各种人才的团队 工程，一个或者几个普通程序员已经很难做好；其次，单位内部的程序员 受行业和职位限制，无法掌握最新的管理理念及其发 展趋势，往往只能对市面上的OA系统和自己单位的办公流程进行 简单模仿和克隆，不能够真正实现提升管理水平的目的； 再次，频繁调整OA系统会严重影响员工的快速掌握

9、和正常使用，延长融合期； 最后，开发OA系统需要耗费大量的人力、 物力、 财力、管理、时间成本，不可控因素很多， 综合费用最低也要几 万元，很多都要数十万元， 显然得不偿失。因此除了个别特大型企业和敏感性单位，建议普通企业不 必自己开发。编辑本段技术架构及性能要求整体技术架构：采用系统为B/S架构， 采用客户端浏览器-WEB应用服务器- 数据库服务器三层结构， 采用基于履盖率最广的、 成熟的微软的. NE惊统构架；此类系统国内较为知名的有天络在线等主流品牌。系统一体化：系统采用统一部署，集中管理的方式， 实现统一登录、 统一权限、统一界面、 统一基础数据管理；开发工具：采用.NET或者JAVA

10、语言进行软件开发；数据库：支持SQL SERVE坏口 ORACLE据库作为系统数据库平台， 客 户端浏览器需支持IE6. 0 ,客户端操作系统需支持 Windows 98/me/2019/xp ; 系统实用性：系统采用搜索引擎的概念，通过一个操作界面的进入，尽可能 的把用户所有想查询的信息都关联起来，避免使用者进行大量的学 习 和记忆，让使用者操作起来轻松自 如；系统易用性：系统界面采用了 大量的图形化的方式， 使用人员操作更加的形 象，针对系统的界面以及各种信息的提示，系统也进行了二次的封装，全部是标准的中文提示，避免出来系统级的英文提示；系统适应性：系统本身采用的是三层技术架构以及模块式的

11、开放方式，即实 现了操作层、 业务层、数据层的分离， 以及各应用模块的独立， 这样适合公司根据实现情况进行调整；系统开放性：系统采用了市场上最成熟的编程语言.NET、数据库MSSQL 三层结构框架，这些技术对后期的维护与升级是非常简单；系统扩展性：系统本身 是一个工作流平台， 已经预留了 大量的数据接口 、 动作接口 ，可以实现与门户网站、 第三方业务系统、 第三方应用 系统的无缝对接；系统安全性：系统采用了 硬件加密锁、128位加密算法、IP地址锁定、在 线自 动检测等多重安全机制， 确保系统的稳定与安全；系统承受能力：系统运行稳定可靠， 系统资源占用低， 系统满足能无 限公司数， 能支持6

12、层以上组织结构， 支持1000以上的瞬时并 发数，能支持公司 或部门迁移等在线处理业务能力。通过LoadRunner负载及压力测试；权限设置灵活性：系统涉及到的部门、 公司比较多，公司权限比较分散，因此要 求系统比较灵活的对系统权限进行灵活分配。系统能够实现控制界面上的每一个菜单；系统的应用速度：系统可以同时支持1000人并发数据处理， 系统从数据底层架 构到应用层的处理， 都经过了 严格的数据压力测试保证了 系统的 高效运行，不会出现系统速度奇慢的现象。编辑本段oa测试一、经验不足：这个当然要靠不断的测试去弥补， 单纯的按照测试工作年限去 衡量一个人的经验是不对的， 因为如果结合理论和实际去

13、积累经验 的话，一年经验不比两年经验差。二、抓住测试重点：比如这个OA系统，包括好几个子系统在里面，有员 工管理，图书管理，招聘管理，考勤系统。当初测试的时候根本没有去比较这几个系统的轻重问题，后来我一想才知道， 重点应该是考勤系统，因为这个系统涉众最多。在实际测试中， 我测的最不仔细的恰恰是这个子系统。因为其他子系统的功能比较好测试，不涉及代码方面的东西。然而考勤系统比较复杂，特别是邮件方面的，一周发一次邮件，必须修改代码才能完成测试，后来开发的跟我说， 要么这个功能我自己来测试，但是后来就是邮件功能出了 问题。教训：测试的覆盖率要保证，抓住关注度比较高的主要功能进行仔细 测试，一定要自 己

14、确认！ 三、控制提交版本次数：个人觉得测试版本次数应该控制在三到四次， 不能修改几个BUG 就提交一个新的版本（当然，有时候要修改某个BUG以后才能方 便以下的测试， 这个就要特事特办了 ）。一般流程是：提交一个测试版本过来以后，按照测试用例跑一遍， 在跑的过程中，可能会想到新的扩展路径，这个时候一定要把扩展路径写到 用例中去， 一般都要完全跑完了 以后再提交下一个版本。这步完成了以后，开发人员肯定改BUG去了，利用这个时 间进行随机测试， 主要测试点当然是出现 BUG的地方。开发把BUG都出来好了 以后（FIXED的，postpone 的， reject的），提交第二个版本，这个版本提交过来以后，首先要做的肯定是BUG验证，