OA系统正在经历从简单线上化到智能决策的关键跃迁。本文深度拆解OA系统的三层架构与核心功能模块，从底层数据治理到前端工作台设计，揭示如何通过数据驱动实现办公自动化与智能化转型，尤其剖析了AI时代下OA系统从'流程自动'到'决策智能'的进化路径。
OA（办公自动化），是办公事务的线上化、流程化、信息化、数字化，进而智能化的一套应用软件系统。
线上化+流程化是针对在现实场景中办公室内员工间表单提交、公告发布、申请审批等工作事务，搬到线上系统中执行。
信息化是在实现办公线上化之后，将每个节点的数据按照一定规则保留下来，以备后期分析使用，也可称为数据结构化。
数字化是在信息化后，通过数据模型将不同纬度的数据进行整合统计分析，直观体现出业务、业绩、工作等表现情况，还可以通过数字进行预警，提前预防，减少损失。
智能化可能真的实现办公自动化的初衷，以往都是流程自动、决策人为，在AI兴起的当下，决策也可以让一部分给智能助手，他会通过历史数据和集团目标以及领导风格做出更完善的决策，有时候人为可能会忽略一些信息导致决策失误。
OA系统最早是用来节流的，也就是降本增效，但随着数据间交互的频繁，业务渗透度越来越高，后续也会朝着开源的方向发展，比如在数据沉淀中积累到一定程度后，可能会出现业务井喷，开拓新的业务出来，就像AI一样有智能井喷。
接下来我们一起看下OA有哪些功能，分别起到什么作用。
上文我们针对事说了OA系统的是什么，而事的操作者或者影响者都将是人，因此在拆解过程中会根据不同的角色或层面来归类功能模块。 我们遵循经典的MVC三层架构来对OA系统做个分解，这边将这三层称为：页面操作层（V）、操作服务层（C）和数据底层（M）。
下方是简易的OA功能结构示意图，主要涵盖的还是偏OA的功能，但OA也是一个办公中台，会与其他业务系统交互，这种交互存在于数据的交互，功能流程还在业务系统中。
这个在以往是忽略的部分，以往只重视功能，不重视数据，既然现在都往数字化方向转型，那么底层数据必须整理好，避免出现数据孤岛问题，以及数据缺失问题。
员工主数据
OA系统主要是员工使用，因此主数据也是员工主数据，每个系统的侧重点不同，像CRM是客户主数据。
这部分就需要将员工唯一性的数据进行存储，而一些其他不是太重要的数据，可以存在各自业务系统中，且存储的内容可以不一样，比如昵称、等级。
数据仓库
人的数据有了之后，就会在系统上产生行为数据，而这些行为数据也会产生结果数据，从过程看是日志，从结果看是统计，而这些数据都保存在底层的数据仓库中，可能一开始都是存在一张张单独的表中，而后续将会从仓库中一个个提取出来套入公式模型进行分析计算。
数据湖/数据集市
这是在数据仓库上进一步结构化分类的汇总数据，比如有考勤的、登录操作的、表单的等等，进一步数据分类后，在后续报表呈现的时候会更轻松。
BI/报表
通过一层层数据的归类，再结合不同部门或者业务的需求，套入公式和模型形成报表、驾驶舱、大屏展示等。
这是一整套系统在实现某些功能时调用的一些常规基础组件，不需要全部自己独立开发，节省时间，有些哪怕自己有时间也不一定有能力做，比如pay（支付）。
这边罗列的也是考虑在OA系统常用的一些功能：
还有很多组件没有列举出来，主要也是看公司实际管理中有用到什么。
这块内容其实是整个OA系统的重点对象，在办公领域，主要处理的就是公司办公和管理方面的事情，这就涉及到了公司不同职能部门之间的工作协作。
而在这些部门中以人事行政、财务部门为主要使用方，大部分功能会涉及这两个部门。
人事行政可能是贯穿OA始终的一个部门，涉及人、事、务、物每一个部分，从人员管理——>组织结构——>权限管理——>考勤管理——>绩效考核——>行政管理。在链路中人事行政执行着录入、配置、审批、统筹的职责。
人员管理
主要对人员信息、入离职、等级、升降级、调整部门等信息的管理。
人员来源可以从HR系统中对接录入，也可以手动添加，人员的账号可以用手机号进行唯一标识，毕竟名字可能重复，这里面需要注意名字重复的可能性，在其他模块展示的时候需要带有部门或者手机号来区分，或者直接在名字后面自动增加数字来避免误解。
人员信息部分可以通过常规的信息进行梳理填写，也可以通过配置信息填写，这个基于公司要求，如果公司往apaas方向走（对外输出OA系统，做saas服务商），可以做表单管理，甚至所有页面都可做成自定义，但这需要花费大力气做apaas底座；而常规的话，可以做小范围的表单自定义，这个主要为了灵活性；再者如果公司产研团队工期不够，且功能不是经常性变更的，也可以硬编码固定字段。
转正离职、等级、升降级、调整部门可能都是通过表单申请进行审批操作，也可能基于绩效规则自动化变更。
组织结构&权限管理
人员进入公司后，还需要给人员一个身份，就是挂靠组织，组织结构不仅仅体现团队与上下级关系，更重要的是在权限、流程和数据方面，因此在这边也把权限管理直接搭载在组织结构上，这套系统如果没有特殊要求或者更细颗粒度的话，直接使用RBAC的权限架构即可操作使用。
考勤管理
这可能是整个OA最常用的表单流程了（除日报等每日必须的），这里面包含了考勤打卡、补卡、请假、外勤、出差等人员日常出勤行为。
这边的重难点在于出勤工时和补贴工时的计算（如果有额外算补贴的话），还有就是外勤打卡的规则。
请假方面做得精细可以在年假、产假、哺乳假、陪产假、育儿假方面进行配置化，这样方便人事统计和审核。
绩效考核
绩效考核对于每个公司基本不相同，即使是相同的岗位，考核的内容也不一定相同，这就需要抓取考核行为和考核结果，有些能直接获取，有些则是主观判断。
这边的难点在于考核模型的复杂程度。
行政管理
这块内容看公司不同大相径庭，涵盖了公告消息管理、会议室管理、用品管理、报修管理等等。
像这种表单形式的同上面考勤管理类似，都可以做成表单配置形式。
另一个角度
从另一个方向来看是人的信息、人的归属、人的行为、人的结果、人的考核、人的所得。
其他内容
还有一些模块没有列举出来，在实际场景中也是有的，比如社保金信息、工资条、日报抽查、印章管理、文档管理等等。
这是掌管公司出入口（收入支出）的阀门，报销、薪酬、回款、采购支出以及各种清结算等等，这中间就涉及报销管理、薪酬管理、发票管理、税务管理、资产管理等等
报销管理
这块也属于表单流程性质，这块的难点在于审批节点以及对接业务系统（获取数据和传递结果）。
薪酬管理
这是工资条前的员工报酬数据，在人事核对好考勤数据、考核数据和社保金数据后自动生成员工薪资明细，这块难点在于薪酬结算的组成，以及数据获取。因为有些时候报销的、奖金或者社保金的缴纳可能会有补退。
发票管理
这是在做集团清结算时的凭证，可能会与开票系统进行对接，现在都是电子票了，对于票据储存会好一点。
业务支持内容会少一点，这些会对接到其他业务系统中去，只是所有数据会汇集到OA系统中作为统计和考核使用。
这块就分为了任务相关和客户相关，当然也有与客户相关的任务。
任务相关有项目、工单、任务计划、日报，基本是任务流转的完整流程，不同场景下任务流不一样，产研的会有立项、产品阶段、研发阶段、测试阶段、上线；客户的有：线索、商机、投标（可能没有）、报价、签约、维护；故障任务有：发起任务、定位任务（转移处理人）、处理任务、结果反馈等。
最典型的就是CRM系统，从线索-商机-跟进-投标-报价-签约-消费-账单-开票-回款整个阶段的服务，这里涵盖了合同系统、电签系统、开票系统，如果涉及线上支付，还涉及第三方支付系统
以上还有两个比较重要的功能没有讲解：报表和消息
报表
报表在最开始的数据底层的时候讲到过，在企业应用中，我们有了基础数据后，需要能够像excel一样可以拼装我们的数据，如现在的多纬表格，系统中无需做到绝对的灵活，只是在能获取到的数据基础上，通过简单的运算符号来进行计算，且能够从已有数据的多个维度进行合成数据表。
消息
消息在基础服务的时候说了一嘴，真正好用的消息系统还是比较复杂了，主要分为待办消息、通知、公告，其中待办消息则是需要提醒操作的，权重最大，通知和公告界限没那么大，通知是普通消息提醒，公告是官方消息推送。消息推送的途径有站内（所有设备）、短信、邮件，还可能有对接第三方IM的推送（钉钉、企微、飞书等）。
前端展示主要分为PC端和移动端，这就要根据实际使用人员在什么场景下需要用到这些功能，像OA系统，在PC端是涵盖全部内容，在移动端则包含最常用的功能，如考勤类的、任务类的、消息通知类、统计指标类。
在整个系统的灵魂部分是在工作台这边，可以说，观工作台可观所有。
工作台需要满足两个特点：清晰转达重要信息、快捷方便操作作业，而这两个特点在四个板块中体现——统计数据、快捷入口、日程待办、消息通知。
统计数据
数字最终也是服务于实际业务的，用来指导和优化业务工作流程的，不同的角色展示不同的数据统计。
快捷入口
快捷入口是每一位工作人员为了操作方便和易于进入某个页面的功能。
日程待办
日程待办主要让工作人员了解自己的行程，合理安排自己的时间，起到提醒的作用。当然也有可能是自己关联的人的行程信息，比如自己的下属的工作跟进，比如秘书对于上级的行程提醒等。
消息通知
消息可以和日程待办联合起来使用，有部分是从日程待办触发的消息，有部分是操作流程节点触发的消息和待办。消息中也有要求处理的，可进入待办；有些则只是提醒、告知，公告属于通知一类，级别比一般的消息高。
以上也只是讲了OA系统的骨架和主要的内容，每个公司对于OA系统的定位都不同，有些是真的作为一个办公协同的工具，有些希望做成一个全家桶，有些是部分全家桶。
系统也会随着公司发展而调整，后续即使各归各的核心功能，但是数据是需要统一在一起的，系统是数据的载体和流转通道就用以下的数据流转来结尾吧！
本文由 @诗忆录 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。