OA办公系统.docx
《OA办公系统.docx》由会员分享，可在线阅读，更多相关《OA办公系统.docx（11页珍藏版）》请在冰豆网上搜索。
OA办公系统
OA办公系统
百科名片
泛东软件-代表性的OA办公系统总体架构
OA办公系统即OA，是OfficeAutomation的缩写，指办公室自动化或自动化办公。
其实OA办公系统是一个动态的概念，随着计算机技术、通信技术和网络技术的突飞猛进，关于OA办公系统的描述也在不断充实，至今还没有人对其下过最权威、最科学、最全面、最准确的定义。
当今世界是信息爆炸的知识经济统治的时代，在这种情况下结合技术的各种进步所产生的OA办公系统已与十几年前的OA发生了很大的变化。
简介
协同oa与企业管理
1.管理的范畴
2.协同oa的定位
协同oa与落地式咨询
1.用好oa软件的两种标准
2.软件项目的四个阶段
3.软件选型的咨询
4.软件推广案例
5.软件应用案例
6.常见误区
7.咨询中的蚁穴原理
原理
OA办公系统需求特征
选择OA的误区
自己开发
技术架构及性能要求
oa测试
简介
协同oa与企业管理
1.管理的范畴
2.协同oa的定位
协同oa与落地式咨询
1.用好oa软件的两种标准
2.软件项目的四个阶段
3.软件选型的咨询
4.软件推广案例
5.软件应用案例
6.常见误区
7.咨询中的蚁穴原理
原理
OA办公系统需求特征
选择OA的误区
自己开发
技术架构及性能要求
∙oa测试
展开
简介
落地堂：
企业协同oa建设是指为了管理的提升而进行的一系列软硬件系统的搭建、推广、应用与维护升级等工作。
协同oa软件是企业管理推行落地的必要环节，对现实管理意义重大，也是落地式咨询的主要内容之一。
协同oa与企业管理
管理的范畴
从管理对象来分，可以将管理分成业务管理和行为管理。
业务管理更侧重于对组织的各种资源的管理，比如财务、材料、产品等相关的管理。
而行为管理则更侧重于对组织成员行为的管理，以此而产生了组织的设计、机制的变革、激励、工作计划、个人与团队的协作、文化等等的管理。
企业的业务管理和行为管理应该是相辅相成的，就像人的两只手一样，要配合起来才能更好的发挥管理的作用。
如果其中任何一只手出了问题，都会对管理的整体带来损失，甚至让企业管理停滞不前，受到严重的阻力。
协同oa的定位
相对应的，作为管理落地的工具，信息化软件也可以分为两大类：
ERP软件系与协同软件系。
其中，ERP软件系包括：
财务软件、物流软件、CRM、HR、库存软件甚至各种行业性业务管理软件等，其作用主要是帮助企业业务管理推行落地的。
协同软件系包括：
协同OA、HR、CRM、绩效、网络、门户、IM、邮件等，其作用主要是帮助企业实现行为管理落地的。
协同oa与落地式咨询
用好oa软件的两种标准
现实中关于什么是用好了oa软件，有两种标准。
其一是实施验收成功标准，指的是厂商在客户那成功完成了软件项目的实施验收，收到了项目尾款。
各个软件厂商市场宣传时所说的“客户数量”就是以此为标准的。
其二是客户真正将软件推广及深化应用成功，该类客户往往都是软件厂商的标杆客户。
这两种标准差异很大，所以造成了各个厂商的客户数很多，但标杆客户很少。
软件项目的四个阶段
oa管理分四个阶段：
OA选型、OA实施、OA推广、OA深化应用。
之所以出现两种标准的巨大差异，原因在于厂商和客户都只重视和关注了软件管理的前两个阶段，而忽略了后两个阶段。
前两个阶段（软件选型、软件实施）是软件厂商能协助或者提供的服务；后两个阶段（软件推广、软件深化应用）不属于软件生产范畴，而属于管理咨询范畴，是软件厂商并不擅长的，也不应该是软件厂商的责任，而是落地式咨询的内容。
软件选型的咨询
落地堂：
软件选型是企业单位软件项目的第一个阶段，主要分以下几个步骤：
第一步：
知己，即真实的把握企业单位自身的软件需求。
软件需求一般包括两个层面，其一是企业管理需求；其二是业务实现需求。
在这两个需求中，企业管理需求把握起来比较困难，需要与企业高层管理者做深入全面的探讨，但非常重要，因为这是软件项目最核心的需求；业务实现需要把握起来相对比较容易，也是最现实选型中最常见的需求表现。
第二步：
知彼，即全面的了解各个相关厂商及其软件产品的优势和特点。
这一步必须在第一步顺利完成的基础上实施才会更有效，否则容易造成盲目选型，从而被软件厂商引导而偏离自身需求及项目目标。
第三步：
商务，即软件选型的最后一步，与合适的厂商进行商务谈判，签订合约。
软件推广案例
案例背景：
落地堂某杭州集团企业客户，软件项目得到总裁高度重视，但项目初期推广依然艰难，两千多员工上线量却不足一百，每天的平均上线时间不足2小时。
集团会议讨论，准备高压强制推行，却遇到极大阻力，效果不佳。
落地式咨询策略：
经过与落地堂的深入交流，集团总裁决定采用落地堂的建议，暂时收回强压政策，并于某周二早上，总裁亲自在软件上发表一则公告：
凡见此公告者，均可于今日下班前，到财务部领取2000元奖金。
由于上线率太低，当日真正领到奖金的只有5人。
不过，第二天，有关这则公告的事情却迅速在整个集团传开，而且软件上线率一下子得到飞跃性增长。
落地堂点评：
软件推广过程中，单纯的强压策略最多只能起到短期表面效应，却很容易让人们产生抵触心理。
从长远的角度看，软件推广需要的是培养人们对软件的好感，并引导人们产生上线的习惯，所以，适当的策划一些激励性质的事件是一种行之有效的手段。
软件应用案例
案例背景：
落地堂某北京企业客户，主要业务为煤炭运输及买卖。
员工常年从山西和陕西向天津港运煤，并由天津港海运到日本销售给固定大客户。
老板李总发现许多员工在运输过程中常常偷偷卖煤，中饱私囊。
每每追究起来，员工们均称为自然损耗。
李总虽然心知肚明，却查无实据，困惑不已。
落地式咨询策略：
经过与落地堂的探讨，李总决定运用软件管理。
首先，分别给每个煤炭供应方开通账号，并记录下每批煤的初始过磅数据。
其次，给天津港过磅人员开通账号，记录下每批煤的最终数据。
接着，定期计算出当期每个员工每批煤的损耗率。
这些数据都只有运煤员工当事人及老板知道。
最后，在公司最显眼的地方公布出当期损耗率匿名排行榜（只公布煤的相关数据，不指明员工姓名）。
实行之后，效果明显，损耗率迅速下降，三个月后达到让李总惊喜的程度。
落地堂点评：
要想让员工更自觉的遵守制度，就不能留下过多的借口空间，借口空间越大，员工的自觉性就越小。
软件的深化应用之一便是企业制度落地及执行体系建设，通过软件缩小借口空间是其中的关键应用之一。
常见误区
1、在实施过程中强调二次开发。
落地式咨询：
软件项目初期，最核心的工作是迅速提升上线率，而不是个性功能的完善。
软件是个全员应用的系统，如果上线率不高，功能再强大都是摆设，所以，一旦确定软件，在内部正式启动软件项目的时候，首先要重视的并不是二次开发，而是推广。
落地式咨询之所以能广泛的成功，关键之一便是把二次开发放到二期，而在项目一期把一切精力都放到软件项目的推广之上，迅速提升软件系统的上线率。
从咨询的角度看，一个新软件就是一种新的工作模式，在1到2个月内，没能迅速获得全员应用，哪怕仅仅是几个最简单的功能，后期想再次推广成功将付出更大的努力和成本。
2、过分依赖于“一把手工程”。
落地式咨询：
一把手重视只是软件项目成功的必要条件，绝不是充分条件。
软件项目的执行主体一般是信息主管或者办公室主任，而不是“一把手”，所以，软件项目执行负责人需要做的不仅仅是让“一把手”重视，还必须为“一把手”提供整体的方案，“安排”“一把手”帮忙我们去推行软件。
这里的难点在于：
“一把手”关注的不是功能，而是软件的管理价值，而且不是简单的应用价值，而是战略层面的管理价值。
但信息主管往往并不擅长这些，这就导致大多数企业软件项目“夭折”。
落地式咨询的解决手段是管理讲座——《执行力引擎——沟通落地》、《执行力引擎——制度落地》、《执行力引擎——文化落地》，通过讲座真正获得“一把手”的重视和支持。
3、全员强制推行。
落地式咨询：
强制推行只能获得短暂的表面效应，如此推行对厂商收尾款有利，对客户长远应用不利。
全员推行一个新软件，是一种组织行为的变革，实际上是一种人性管理问题。
当人们被强制接受一个新的办公模式时，会自然的产生人性的反抗——尤其是一上来就采用罚款的形式，一旦有人被罚，自然就会反感到软件上来，也就会反感到推行软件的人身上来。
这种反感可能短时间内不会爆发（比如项目验收前不爆发），而终有一天会突然蹦出来。
这就是大多数企业的软件项目在实施过程中表面上看很不错，但验收后一段时间后无缘无故用不起来的主要原因。
落地式咨询的解决办法是，尽量采用激励的形式，先让员工“喜欢”上软件，再顺势推行，这才是长久之计。
4、先做流程梳理咨询，再上软件。
落地式咨询：
大多数软件实施遇到的困难都是客户的流程本身不清晰，而这确实不是厂商的职责，所以这种愿望变得很广泛而强烈，但从客户长远角度讲，这并不是最佳方案。
从客户的角度看，没上软件时要做咨询其实很难彻底。
原因很简单，咨询需要数据，也就是客户现有的真实流程及管理情况。
而且对咨询而言，这些数据最好是整理过的，体系化的，有条理的。
但事实上大多数客户是提供不出来的。
所以，在这种情况下，只能靠顾问自己去调研。
这种调研得出来的数据也只能反映部分情况，很难全面，细致，甚至有许多时候还会出现偏差。
如此，这种没有数据支撑的咨询往往会失败。
反过来，上软件后，这些数据会自然在软件上保留下来，当这些数据足够了，再咨询就更有效，更顺利。
同时，这也给客户提出了一个建议和要求，当自身流程还不够清晰的时候，在实施阶段不要过于要求厂商给出全面的流程搭建要求，而是根据自身情况，先上部分简单的，而后在实际应用中逐步利用软件来自行搭建。
这一策略正是落地式咨询的核心原理之一——蚁穴原理。
咨询中的蚁穴原理
面对厚厚的水坝，汹涌的波涛也很难从整体上冲垮它。
但是，一群小小的蚂蚁，悄悄在水坝上钻个洞，水坝就变得很危险。
一开始只有一点点水从蚁穴中渗出，慢慢的，水带动泥土的流失，蚁穴会变得越来越大，洞中的水流也会越来越急，导致泥土流失速度也越来越大。
最后，很可能就因为一个小小的蚁穴，而冲垮整个水坝。
软件推行也是如此。
当我们从整体上强制推行流程的时候，就会受到整个企业强大的人性阻力；我们强制的力度越大，人性阻力也就越大。
从整体上强制推行流程，就和波涛拍岸一样，水势很大，水坝更结实。
水冲击坝的力量越大，水坝反击的力量也就越大。
这种推行是很难成功的。
但是，如果我们能够先找到几条甚至一两个，涉及到全员的、最简单、最容易推行的流程，先百分百的推行下去，就很容易形成蚁穴。
当这代表性的几个流程推行成功后，慢慢就会形成蚁穴效应，员工们会自然而然的认同并习惯这些流程，甚至感受到制度落地带来的便捷和快乐（事实上，制度真正落地会给员工们带来便捷和快乐；而不能落地的制度才是激起员工反抗的罪魁祸首），并且随着这种快乐感的蔓延和渗透，蚁穴效应会越来越大。
在这种基础和环境下，顺势陆续推行其它制度，直到大部分流程都推行到位了，制度落地的大势就形成了，推行起来就会更加顺利。
如此一来，人性不仅不会成为制度落地的阻力，反而会变成主要动力。
这也就实现了用人性帮助我们推行制度的目的了。
原理
OA办公系统不仅仅是企业办公的一种工具，更应该是一种有思想、有模式的懂管理的软件，目前市场上主流的协同OA办公系统就为现代企业发展注入了强劲的动力，协同OA办公系统是在研究现代组织实践案例和管理理论发展方向的基础上，结合神经网络的研究成果而设计的协同管理系统。
它以动态组织为行为主体，以工作流为传导模型，以任务为处理模型，将组织行为的复杂性通过三者的结合充分表现出来，从而帮助实际组织解决管理过程中的复杂课题。
泛东软件-代表性的OA办公系统管理模型
组织价值在于“使用有限资源创造最大化价值”，现代组织的典型代表是企业，企业创造价值是通过三个层次进行体现的，即战略、战术与执行。
战略，是领导意志的体现；战术，是管理方式的体现；执行，是操作能力的体现。
任何战略和战术意图最终都是通过执行来实现的，但在战略决定战术、战术决定执行的同时，执行也反过来影响战术、进而影响战略。
但遗憾的是，在企业的实际运行中，常常出现的情况是：
因为执行环节上出现问题，而最终使战略意图变得面目全非。
协同OA办公系统将执行中的三个要点：
执行者、目标与过程管控，通过动态组织、工作流和任务三者，将执行相关的各种信息和应用紧密集成在一起，并用权变组织、网状沟通、关联结构和控制反馈四个管理模型实现各个执行体之间的融会贯通和统一管理，从而为企业提供实现人力资源、资金资源、产品资源、客户资源、知识资源的高度整合和统一的工具，帮助企业逐步走向虚拟管理、敏捷办事和互动沟通的高级形态。
OA办公系统需求特征
随着知识经济时代的到来，社会进步正在不断加速，组织迫切需要一个可以实现内外资源整合的高效的信息系统，从而提升其管理水平。
具体表现在：
1）需要一个高效的协同管理工作平台
能够将组织管理中的业务活动、管理活动及活动产生的信息在组织、部门、个人之间进行及时高效、有序可控、全程共享的沟通和处理。
2）需要一个有效的知识资产管理平台
过去在组织的信息化建设过程往往重视人、财、物这些有形的物质资产管理，忽视了知识资产的管理，需要借助知识管理工具对组织内外的知识进行有效的获取、沉淀、共享、应用、学习和创新，从而提高员工的素质和技能、执行力。
3）需要一个个性化的系统访问门户
传统的OA功能比较单一，员工容易使用，随着功能的不断扩展，员工对功能的需求也不尽相同，这就要求系统必须具有人性化设计，能够根据不同员工的需要进行功能组合，将合适的功能放在合适的位置给合适的员工访问，实现真正的人本管理。
4）需要一个良好的组织文化管理平台
开放的社会造就了开放的社会人，组织规模的不断扩大，导致领导与员工、员工与员工间的直接沟通机会越来越少，组织需要构建新的文化环境，便于员工相互沟通、增进了解、发现思想倾向并及时加以引导。
5）需要一个集中的信息整合呈现平台
办公系统是组织内使用面最广泛、频率最高的信息系统，希望能够通过办公系统实时、直观地了解到组织的运营状况（如生产、营销、财务等数据），同时有效地解决组织内“信息孤岛”问题。
6）需要一个灵活的业务流程整合平台
当组织面临客户不断提出端到端的服务时，员工办公环境将会越来越复杂，因此需要将日常工作活动、管理活动、业务活动有机的结合，以快速响应客户需求，同时减少不必要的重复工作，将管理流程与业务流程进行有效的整合。
综合上述各种新的需求不难发现，现阶段的OA系统将以知识管理为核心、以实时协作为技术支撑手段，以统一的知识门户为展现方式。
选择OA的误区
案例越多越好
在选择OA产品时单纯以软件产品的案例作为软件采购的标准，甚至唯一标准。
然而这对于IT技术日新月异变化的软件来说，这个标准往往让你选到的恰恰是过时的产品，甚至于即将被淘汰的产品。
一个最有说服力的例子就是，3年前出的笔记本电脑或电视机的案例肯定比今年新推出的笔记本电脑或电视机的案例多得多。
可是3年前的电脑，3年前的电视机还有人要吗?
同样，在移动OA领域，技术的进步更是日新月异，智能机和3G的引入就是最近一两年出现的，显然基于非智能机和非3G环境的设计在技术的先进性上已经落后但是案例必然比前者多。
此外，前几年的第一代的移动OA采用的是短信技术，第二代移动OA采用的WAP技术，这种技术已经被淘汰，它们的案例也一定比刚刚发展起来的采用WebService技术的第三代移动OA多的多，但是现在这种技术还有人使用吗？
在技术的进步以指数级增长的今天，一味地追求案例多，只会选择到一个技术上即将被淘汰的产品。
因此选用软件第三条准则就是：
绝对不要以案例多作为选择软件的唯一标准。
自己开发
首先，OA系统已经涉及到越来越多的学科技术，包括计算机、通信、网络、管理与行为、多媒体、数据库、图形图像等等，是一个需要综合各种人才的团队工程，一个或者几个普通程序员已经很难做好；
其次，单位内部的程序员受行业和职位限制，无法掌握最新的管理理念及其发展趋势，往往只能对市面上的OA系统和自己单位的办公流程进行简单模仿和克隆，不能够真正实现提升管理水平的目的；
再次，频繁调整OA系统会严重影响员工的快速掌握和正常使用，延长融合期；
最后，开发OA系统需要耗费大量的人力、物力、财力、管理、时间成本，不可控因素很多，综合费用最低也要几万元，很多都要数十万元，显然得不偿失。
因此除了个别特大型企业和敏感性单位，建议普通企业不必自己开发。
技术架构及性能要求
整体技术架构：
采用系统为B/S架构，采用客户端浏览器-WEB应用服务器-数据库服务器三层结构，采用基于履盖率最广的、成熟的JAVA系统构架；此类系统国内较为知名的有天络在线等主流品牌。
系统一体化：
系统采用统一部署，集中管理的方式，实现统一登录、统一权限、统一界面、统一基础数据管理；
开发工具：
采用.NET或者JAVA语言进行软件开发；
数据库：
支持SQLSERVER和ORACLE数据库作为系统数据库平台，客户端浏览器需支持IE6.0，客户端操作系统需支持Windows98/me/2000/xp；
系统实用性：
系统采用搜索引擎的概念，通过一个操作界面的进入，尽可能的把用户所有想查询的信息都关联起来，避免使用者进行大量的学习和记忆，让使用者操作起来轻松自如；
系统易用性：
系统界面采用了大量的图形化的方式，使用人员操作更加的形象，针对系统的界面以及各种信息的提示，系统也进行了二次的封装，全部是标准的中文提示，避免出来系统级的英文提示；
系统适应性：
系统本身采用的是三层技术架构以及模块式的开放方式，即实现了操作层、业务层、数据层的分离，以及各应用模块的独立，这样适合公司根据实现情况进行调整；
系统开放性：
系统采用了市场上最成熟的编程语言.NET、数据库MSSQL、三层结构框架，这些技术对后期的维护与升级是非常简单；
系统扩展性：
系统本身是一个工作流平台，已经预留了大量的数据接口、动作接口，可以实现与门户网站、第三方业务系统、第三方应用系统的无缝对接；
系统安全性：
系统采用了硬件加密锁、128位加密算法、IP地址锁定、在线自动检测等多重安全机制，确保系统的稳定与安全；
系统承受能力:
系统运行稳定可靠，系统资源占用低，系统满足能无限公司数，能支持6层以上组织结构，支持1000以上的瞬时并发数，能支持公司或部门迁移等在线处理业务能力。
通过LoadRunner负载及压力测试；
权限设置灵活性：
系统涉及到的部门、公司比较多，公司权限比较分散，因此要求系统比较灵活的对系统权限进行灵活分配。
系统能够实现控制界面上的每一个菜单；
系统的应用速度：
系统可以同时支持1000人并发数据处理，系统从数据底层架构到应用层的处理，都经过了严格的数据压力测试保证了系统的高效运行，不会出现系统速度奇慢的现象。
oa测试
一、经验不足：
这个当然要靠不断的测试去弥补，单纯的按照测试工作年限去衡量一个人的经验是不对的，因为如果结合理论和实际去积累经验的话，一年经验不比两年经验差。
二、抓住测试重点：
比如这个OA系统，包括好几个子系统在里面，有员工管理，图书管理，招聘管理，考勤系统。
当初测试的时候根本没有去比较这几个系统的轻重问题，后来我一想才知道，重点应该是考勤系统，因为这个系统涉众最多。
在实际测试中，我测的最不仔细的恰恰是这个子系统。
因为其他子系统的功能比较好测试，不涉及代码方面的东西。
然而考勤系统比较复杂，特别是邮件方面的，一周发一次邮件，必须修改代码才能完成测试，后来开发的跟我说，要么这个功能我自己来测试，但是后来就是邮件功能出了问题。
教训：
测试的覆盖率要保证，抓住关注度比较高的主要功能进行仔细测试，一定要自己确认！
三、控制提交版本次数：
个人觉得测试版本次数应该控制在三到四次，不能修改几个BUG就提交一个新的版本（当然，有时候要修改某个BUG以后才能方便以下的测试，这个就要特事特办了）。
一般流程是：
提交一个测试版本过来以后，按照测试用例跑一遍，在跑的过程中，可能会想到新的扩展路径，这个时候一定要把扩展路径写到用例中去，一般都要完全跑完了以后再提交下一个版本。
这步完成了以后，开发人员肯定改BUG去了，利用这个时间进行随机测试，主要测试点当然是出现BUG的地方。
开发把BUG都出来好了以后（FIXED的，postpone的，reject的），提交第二个版本，这个版本提交过来以后，首先要做的肯定是BUG验证，验证BUG是否真的已经修改。
然后进行第二轮测试，这轮测试可以有选择的测试一些模块。
接着再提交第三版本进行，这个版本花的时间不多，主要是扫除漏网之鱼。
这个时候就可以根据系统情况，感觉还有问题的话，提交最后一个版本，按照用例跑一遍，OVER。
四、分类相似BUG：
比如删除重要数据时，要给出确认删除的提示，通常如果一个模块有这个问题，其他模块也会有这个问题，这个时候一定要把这些全部找出来，提交到BUG管理工具中去（TD等）。
升级会员 