4.7 KiB
4.7 KiB
5–10 人内部 OA 适配性复审设计
复审方法
采用“真实工作是否需要 → 风险是否值得系统化 → 是否已有更便宜主办系统 → 长期维护成本”四层判断：
- 只有高频、多人协作、容易丢失或需要审计的工作才值得进入 OA。
- 低频且可由明确 SOP、共享表格或线下双人确认可靠完成的事项，不优先编码。
- 企业微信、银行、代账等已有系统能稳定主办的能力，OA 只保留必要入口、摘要和留痕。
- 每个保留的模块必须能说明谁每月使用、失败会造成什么损失、谁负责恢复。
企业微信分层模型
每项能力先按以下三层裁决，不再默认由 OA 自研完整闭环：
- 企微主办：入口、免登、通讯录、基础组织、应用消息、HR/考勤、公告和字段简单的低风险审批。移动端优先使用企微原生页面，OA 不复制一套表单和处理 UI。
- 企微发起/审批，OA 最小留存：一般行政申请以及无需后续财务处理、敏感附件和跨模块台账的简单采购可作为迁移候选。OA 只在确有业务关联时保存外部审批 ID、申请人、类型、状态、实际审批链和必要审计。
- OA 主办：报销全流程、发票 PDF/OCR 与去重、合同正文、高敏附件、财务台账、付款/AP、回单、maker-checker、跨模块关联和长期审计。企微只提供免登入口、脱敏消息和指向具体 OA 单据的 deeplink。
优先选择企微的判据是：移动操作为主、字段和状态简单、敏感度低、无需复杂跨模块关联、企微能够可靠留痕。任一项不满足时，保留 OA 主办或采用“企微审批 + OA 最小索引”。
业务旅程完整性优先于技术上的能力复用。报销天然连续经过申请、票据识别/去重、审批、财务复核、付款与回单，拆到企微原生审批和 OA 财务处理会产生重复录入、状态同步、附件搬运和跨平台查询，因此无论金额大小均保持 OA 单一主办；员工仍从企微工作台进入 OA，并在企微接收待办和结果通知。
企微审批规则不能通过 API 完整读取，也无法仅靠 API 证明申请人是否可以自行改选审批人。任何正式模板迁移必须经过后台人工确认、真机提交页确认和提交后的实际审批链校验；本调研只提出行政/简单采购候选，不宣告任何流程已经迁移。
调休边界
- 调休属于企微“请假”模板中的假别，与年假、事假、病假同属
leave，不扩展第五个企微审批目标。 - 员工在企微提交和查看调休，审批人在企微处理；OA 普通页面只读展示同步到的假别、时间、状态和必要审批摘要。
- 首批不在 OA 建设调休余额、加班自动换休、跨年度结转、薪资计算或复杂假期引擎。余额若由企微原生能力管理，以企微为事实源；否则由 HR 按简明制度人工维护。
- 正式启用前必须验证企微后台确有“调休”选项、真机申请页可见、实际审批链禁止自审，并证明 OA 最小历史能区分“调休”与其他请假类型。
评估维度
- 业务价值：月使用频率、参与人数、金额/合规风险、跨人交接价值。
- 认知成本：导航数量、角色切换、配置项、状态数量、重复录入和培训成本。
- 工程成本：代码与测试规模、依赖、后台任务、集成、数据迁移和故障面。
- 运维成本：部署、备份、恢复、监控、密钥、外部 API 和人工值守要求。
- 替代成本：企微原生能力、银行/代账流程、共享文档或简单 SOP 是否更可靠。
输出模型
每个主题归入以下一类：
KEEP：内部运营底座，继续维护并保持简单。SIMPLIFY：业务需要，但应合并入口、状态、角色或配置。FREEZE：现状可读/可用，停止扩展，仅修安全和数据损坏问题。TOUCH-TO-REMOVE：不立即大删；未来触达相关代码时有证据地移除。DEFER：没有当前收益，保留决策记录但不投入。
风险边界
- “内部使用”不降低认证、最小权限、敏感资料隔离、付款 maker-checker、审计、备份恢复和离职权限回收要求。
- “人数少”允许一人多岗和短审批链，但不能允许同一人完成高风险付款制单与复核、系统运维与敏感业务授权的全部闭环。
- 精简优先通过隐藏入口、冻结扩展和减少配置完成；涉及历史数据或审计链的物理删除必须另建任务。
交付物
- 当前状态简报。
- 模块级裁剪矩阵。
- 工程/运维/安全建议。
- 30 天优先行动与后续按需清单。
- 明确的“不再建设”清单。