制造企业招进一名员工表面上只是花名册里多了一行。真正发生的事情却远不止这些。用人部门提出招聘需求人事收集简历、安排面试、确认录用。员工报到以后要建立档案、签订合同、进入试用期。部门负责人要完成试用评价和转正审批日常工作中还会发生考勤、请假、调岗、奖惩、续签和离职。每一个动作都会改变员工状态也会影响组织关系、审批路径、系统权限、生产排班和管理统计。如果 OA 只做成通讯录这些动作仍然要靠 Excel、纸质表单和聊天消息推动。真正的企业级 OA需要让一名员工从进入企业到离开企业的每一次状态变化都被同一套底座连续承接。这不仅是用户端多做几个页面更关键的是设计端要先把数据对象、业务动作、角色权限和自动化规则组织起来。先看底座27 个模块承接一条员工生命周期进入 OA 应用设计器可以看到服务台、工作台、数据看板、审批待办、审批管理中心、员工管理、人事管理、考勤管理、文档管理和系统信息等模块。设计端顶部还提供版本管理、表达式、引用、模型和日志等能力。全局设置里则包含角色权限、定时任务、API、监听器、选项值字典、脚本和国际化。员工数据要进入审批审批结果要触发状态变化状态变化要影响权限和后续任务外部考勤、门禁或薪资系统还可能通过 API 交换数据。只有这些能力在同一套底座上协同员工生命周期才能真正连续。第一层不要用一张员工表承担所有业务很多 OA 项目最初只有一张员工表。随着业务增加表里不断加入试用状态、合同日期、调岗信息、请假天数和离职原因。字段越来越多但历史过程反而越来越难追溯。在设计端的数据模型中花名册、合同管理、招聘需求、入职记录、简历管理、转正表、转正记录和调岗记录都是独立的数据对象。花名册负责员工当前主数据。招聘需求记录岗位从哪里来。简历和入职记录保留候选人进入企业的过程。转正记录保留试用期结束时的业务决定。调岗记录保留组织关系变化前后的信息。合同、请假和离职也各自拥有独立记录。这些对象通过员工、部门、岗位和业务单据相互关联既能看到当前状态也能追溯历史过程。这比把所有信息塞进一张大表更接近企业真实运行方式。第二层招聘结束后入职要正式接管业务招聘需求被批准以后候选人会经历简历筛选、面试和录用。到了报到当天业务对象要从“候选人”切换成“员工”。用户端的入职记录把关联招聘申请、开始时间、结束时间、面试人员姓名、面试官、简历信息和登记表连接起来。这意味着“张三已经报到”不再只是一条群消息。系统能够追溯这名员工来自哪个招聘需求由谁参加面试什么时候完成报到相关资料存放在哪里。入职完成以后可以继续创建员工档案、分配员工编号、写入部门岗位并生成试用期记录。招聘不是在录用通知发出时突然结束它要把完整上下文交给后续员工管理。第三层花名册是主数据不是静态名单员工完成入职后当前有效信息进入花名册。花名册维护员工编号、姓名、部门、性别、职务岗位、职称、入司时间、联系方式和入职年份。这些字段会被后续业务持续引用。员工编号关联考勤和薪资。部门与岗位决定审批路径和数据范围。入司时间影响工龄、年假和合同周期。员工类型影响用工规则。在职状态影响账号、权限和任务分配。所以花名册不能被每个模块复制一份。招聘、合同、考勤、请假、调岗和离职都应引用同一个员工对象员工信息变化以后下游业务才能保持一致。第四层试用、转正和调岗要变成业务动作试用期管理最容易退化成一个到期日期。日期到了人事再逐个询问部门负责人能否转正。真正需要管理的是试用目标、辅导过程、评价结论和最终决定。试用期页面直接形成待处理人员清单并提供转正动作。但按钮本身不是闭环它背后还需要自动化承接后续变化。设计端已经配置了“创建【转正记录】”“创建【调岗记录】”和“离职审批”等自动化。转正通过后创建转正记录并更新员工类型。调岗通过后保留原部门和岗位再更新员工当前组织关系。离职通过后改变在职状态并推动账号停用、工作交接和资产归还。员工状态不能靠人事手工改完一列就结束。每一次状态变化都要让相关业务继续向前走。第五层考勤结果要能被业务单据解释员工进入日常工作以后考勤数据会持续产生。考勤记录承接姓名、部门、工号、职位、日期、班次、上下班打卡时间和打卡结果。但一次缺卡并不一定等于异常出勤。员工可能请假、出差、调班也可能需要补卡。因此打卡数据还要和请假、出差、调班及补卡单据一起判断。审批通过的请假记录要进入月度统计。调岗后要使用新部门或新班次的考勤规则。离职以后则不应继续生成在职员工的考勤异常。这样月末核算面对的才是一组已经被业务流程解释过的结果而不是等待人工核对的异常列表。第六层权限要跟着角色和组织变化员工生命周期包含大量敏感信息。普通员工只能查看自己的档案和申请部门负责人需要看到本部门人员和待审批事项人事专员负责日常办理人事经理负责规则、复核和管理统计总经理和董事长关注组织层面的结果。设计端已经划分管理员、董事长、总经理、副总、人事经理、人事专员和部门负责人等角色。企业级权限不能只解决“能不能打开页面”。还要控制能看到哪些员工、能操作哪些字段、能执行哪些动作以及流程走到哪个节点时由谁处理。员工调岗以后旧部门负责人不应继续查看其后续业务。员工离职以后也不应继续保留原岗位权限。角色、组织和员工状态联动才能让 OA 在规模扩大以后仍然可控。用户端看结果设计端保证链路不断管理层最终看到的是员工分析看板。人数、员工类型、学历、年龄、部门和入职走势只是结果。结果是否可信取决于前面的招聘、入职、转正、调岗和离职是否持续产生结构化数据。数据模型负责定义业务对象。页面负责让不同岗位完成操作。流程负责审批和责任流转。自动化负责创建记录、更新状态和发出提醒。权限负责控制角色与数据边界。API、监听器和脚本负责连接外部系统与复杂规则。业务发生变化时企业可以继续调整数据对象、流程、权限和自动化而不必推倒整套系统重新建设。一名员工从招聘、入职、试用、合同、考勤走到调岗离职OA 的价值就藏在这些连续的组织动作里。而这些动作能够连续运行依靠的正是同一套可持续扩展的企业级应用底座。