由于刚打仗OA时，对OA的观点较为模糊，市情上也较少干系的解释资料，只能在事情中不断摸索。
因此决定整理事情过程中对OA的认识，从整体上对OA平台进行大略先容。
一、什么是OA1. 什么是OA系统？
引用王泉老师的阐明，从广义上看：OA是企业除了生产掌握之外的信息处理与管理的凑集；再形象一点形容，如果一家企业的组织架构是骨架，员工是肌肉，管理者是大脑，那OA便是通报头脑意志的神经网络；因此面对不同层次的用户，OA就有着不同的代价表示：
1）对高层领导
OA是决策支持系统；OA以企业内/外部信息为根本，通过各种统计模式，为领导供应决策参考。
2）对中层管理者
OA是信息管理系统；OA利用业务各环节供应的数据，提炼出所需的管理信息，以把握业务进度，降落管理本钱，提高管理效率。
3）对普通员工
OA是事务/业务处理系统；OA为办公室职员供应便捷明确的办公手段，提高员工事情效率。
2. OA的发展进程
OA系统起源于海内政府的公函和档案管理，大体划分为4个时期：
1）原始OA时期（20世纪80年代~20世纪90年代）
以office软件处理文档，传真机、打印机、复印机开始运用。
2）办公OA时期（20世纪90年代~21世纪初）
以政府机关、奇迹单位、大型国企为利用重点，以Domino/Notes为技能平台，公函管理、会议管理、用车管理、档案管理、电子邮件等为核心运用，通过网络（LAN/WAN）完成数据传输和共享；但功能模块较为独立，缺少统一管理思想。
3）协同OA时期（21世纪初~现今）
以事情流为核心，从“紧密环绕办公管理”开始转向与企业业务管理相结合，手机短信、电子签章、移动办公、单点登录、门户等技能逐渐遍及。
4）移动OA时期（3G开始遍及后）
智好手机终端（包括平板）成为紧张接入和利用设备，结合手机二维码、移动舆图定位、各种通信软件的即时沟通，共同构建协作平台。
3. 协同OA的定义
如果说OA还只是一个工具系统，那协同OA是包含着管理思想和管理理念，通过信息化手段规范、提升企业管理的软件体系。
二、协同OA平台的构造
协同OA构造大致如下图所示：
用户通过PC、移动端或者其他运用终端（如业务厅自助做事终端）进入门户首页，门户根据用户身份供应运用做事。
业务运用紧张为用户供应业务做事；按照类型大致划分为6个分类并大略列举了各分类中的运用，实际上OA系统可以接入各种业务系统，为用户供应做事。
运用支撑层紧张为业务运用做事；例如事情流引擎和表单设计器支撑流程的个性化配置，门户平台工具搭建系统门户，统一用户中央对组织架构、用户信息、系统权限等进行管理，乃至掌握第三方运用的利用权限。
最底层的根本举动步伐，用于保障系统的正常运作，为系统的稳定、安全供应保障。
下面大略先容一下几个比较常见的平台运用。
1. 统一用户平台
统一用户平台紧张对各业务系统的用户体系进行统一管理，是实现单点登录的条件；实现统一用户管理，常日须要第三方运用提交注册申请，由平台供应标准做事接口完成接入，接入后在统一用户平台管理运用的利用权限。
1）用户管理
用于管理每个用户的基本信息，例如姓名、电话、证件、部门、职务、出生年月等；除了根本信息之外，还会承载密码管理、排序、运用利用权限等功能。
2）组织架构
组织架构是企业流程运转、部门设置及职能方案最基本的构造依据。一样平常按照单位-部门-人的层级进行划分，如果是大型企业或行政机构会更加繁芜。由于存在一人多岗的情形，方案需求时须要把稳判断这个业务功能是按组织架构身份进行划分，还是只因此人的维度进行划分（例如采购审批时必须利用采购部门下的身份进行审批，而填写和查看日程时则只须要按人进行划分）。
3）角色管理
角色是连接权限与用户的桥梁，通过创建角色并分配用户与权限，利用户得以管理或利用某些运用；除了权限分配，角色还用于流程的绑定，再向下细分乃至须要区分角色类型、考虑不同角色叠加的逻辑。
4）权限管理
权限管理是每个业务系统都要重点考虑的问题，基本分为菜单权限、数据权限、操作权限；菜单权限直接管理目录；数据权限除了基本的数据范围（例如单位、部门、个人），还有列表、表单字段的掌握等；操作权限紧张掌握当前查看数据的操作。
其余权限还有互斥需求；与详细的角色或用户解耦，根据业务需求灵巧配置等哀求。
5）接入管理
接入管理紧张用于第三方运用接入时提交申请，用于对运用的名称、地址、端口等材料的审核，实际上也可能直接通过邮件完成申请的接入。
6）运用管理
对付已接入系统的运用，管理员须要跟踪运用的接入状态，根据业务需求调度运用的利用范围；普通用户则须要查看可用的运用系统，乃至同步至门户首页。
2. 门户平台
门户是一个聚合多个信息源，并可让用户自定义所需内容的界面；门户上的信息可能来自系统内各个业务模块，也可能来自其他运用系统。但门户除了信息聚合以及个性化设置之外，常日还须要统一用户平台以及单点登录的支撑。
在信息来源根本上，通过权限的掌握，为不同角色的用户供应不同的门户架构与系统信息，用户根据自己可调度的门户架构以及信息来源，设置个性化门户。
1）信息源管理
门户对各业务系统的信息进行聚合，信息来源包括各业务系统的运用（例如待办），信息发布平台的文章（例如关照公告、知识分享，乃至文档管理等），还有第三方运用的利用管理。
2）排版管理
门户平台在搭建门户时，实际上是一个建站系统，供应框架及组件的支持；管理员通过各种组件搭建出门户的框架，再通过数据源的掌握完成门户信息的添补。如果要考虑用户的个性化排版，为了便捷、高效以及都雅，建议只在管理员搭建的框架下调度。
设计符合客户利用的门户，难点在于调研清楚客户的管理模式；部分业务须要按组织架构设计多层级门户，也有按业务类型设计门户构造的场景；其余对付不同角色的用户，可调度的门户区域、可设置的信息来源、可查看的信息范围都不一样。
3）提醒办法
OA系统个中一个主要机制是不间断机制，其目的是让用户在任何情形下都有路子获知OA中的信息。因此OA系统有多种提醒办法，业务系统在设计时也要把稳与OA提醒渠道做好对接。
3. 事情流引擎
事情流是OA的核心，配置事情流的过程便是将企业各种事变的流程通过打算机软件规范化实现的过程。本文把事情流引擎大略分为7个模块，以下解释各模块紧张知足的场景：
1）表单绑定
流程流转过程中须要在表单上完成审批见地，最基本的是一条流程一个表单；但也存在审批流程可能须要绑定多个表单的情形（例如生产过程中不同部门办理时须要不同单据），此时除了引擎与表单的关系之外，还须要考虑表单之间的关联。
2）步骤类型
步骤类型大体概括分为开始步骤、标准步骤、流程网关、结束步骤4种类型；标准步骤是用户在进行流转审批时的办理步骤，场景细分还包括办理和阅办；流程网关紧张用于流程分支与合并，乃至触发子流程。
3）步骤权限
步骤权限紧张管理包办人在当前步骤可操作的权限，包括表单可填写区域、附件增编削查以及部分业务功能，例如业务哀求只有在特定步骤才可以删除附件，或在某一步骤须要清空表单等。但是为了避免与业务系统过度耦合，引擎的步骤权限一样平常只管理表单干系的部分，别的限定由业务系统自行管理。
4）包办人配置
用于配置此步骤的办理人，紧张根据配置详细的人、条件（例如某一步骤包办人为此步骤包办人）、角色、表单字段等逻辑完成配置。除了配置包办人，还须要确定此步骤的办理逻辑，例如是否须要多人办理，是逐个审批还是协同审批、由谁决定流程走向等各种业务场景。
5）动作配置
步骤与步骤之前须要通过动作进行连接，根据不同动作流转至不同步骤，因此动作的意义紧张是给用户指明流转方向；但是在审批过程中，也存在不同动作流转至同一步骤但触发不同结果的场景（例如请假审批流程，赞许或不同意请假流程都会走向办结，但赞许时可能还须要记录请假日期，自动扣除此用户请假天数）。
除此之外，动作可能才会承载某些分外条件的触发，例如经由某个动作后，须要打算审批韶光。
6）版本管理
随着企业的发展，审批流程也须要不断的优化，但是流程调度难免会影响正在审批的业务，因此须要通过版本管理区分新旧流程，避免影响正在审批的业务。
7）权限管理
权限管理可以分为管理权限以及利用权限；管理员对流程进行增编削查，再通过利用权限分配至对应业务部门利用。
8）后续跟踪
以上紧张是流程配置以及管理的简要先容，但是流程在审批时，还有对流程各维度的监控；例如对每个步骤的监控，可及时催办、疏通审批流程，提高环节处理效率；对流程全过程的监控，可为企业优化流程、调度绩效考察供应参考。
其余对付审批过程中产生的信息，终极还可以汇聚成大数据进行统计剖析，搭建领导驾驶舱，直不雅观展示企业当前运转情形。
4. 表单设计器
表单与事情流每每相互合营，事情流卖力审批流转，而表单卖力数据的采集、打算与展示；但表单设计器除了卖力审批过程的数据采集，还有非流程的业务需求，例如问卷调查、投票等，因此表单设计器须要独立于引擎。
设计表单相对大略，紧张通过各种控件（如单行文本、多行文本、下拉框等）完成表单样式的搭建，再设置每个控件的属性、样式，即完成表单的设计。如果要考虑搭建的便捷性、规范性问题，可以通过表单模板快速导入实现高效配置。
三、写在末了
在OA系统构造中展示的，只是OA系统的骨架，而将每个细分的平台或业务系统剖开，都是一个值得我们仔细品味与理解的天下；而这些天下之间通过不断的数据互换，终极协同完成办公的任务。
其余，我们在方案一个如此弘大的平台时，除了关注系统功能的方案，还须要加强企业管理理论的学习，理解客户的管理模式，从更宏不雅观的角度不雅观察全体业务的布局。
OA系统要真正办理客户问题，必定须要理解客户的管理理念，在客户旧有理念与OA全新管理理论中寻求平衡，才能搭建出符合客户需求的、可以真正落地实行的业务平台。
以上是本文内容，希望本文可以让大家对协同OA平台有大致观点的认识；如有理解不到位的地方，欢迎互换补充~共勉！
本文由 @庞庞 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议
