审批流：不是画个流程图就能上线
审批流是OA系统里用得最多、也最容易做僵的模块。我接过不少从标准SaaS迁过来的客户，卡点几乎一样：系统只能处理直线上报，一旦遇到并行审批、条件分支、转交、加签、超时升级，就得靠人工线下补流程。定制开发的差别就在这里——流程规则按企业自己的审批习惯来设计，而不是让管理习惯去适配系统。这类迁移项目在柬埔寨、菲律宾、越南的客户里都出现过，原因集中在标准产品对多层会签和条件路由支持不足。
实际开发中，审批流需要处理几类典型情况：
- 串行与并行混合：例如报销单需要部门经理和财务同时知会，但最终由总经理在金额超过阈值时审批。系统需要支持同一节点多人并行处理，也要支持逐级串行上报。地产和金融类客户里，多层审批加会签是常态，并行节点上还要处理“一人驳回即整单退回”还是“多数通过即通过”的规则差异。
- 金额与条件路由：报销金额低于1000元可直接通过，超过10000元自动升级到更高层级。这类规则用表达式引擎动态计算，调整时不用改代码，财务规则变了直接改配置。表达式引擎我们用的是结构化规则表加条件解析器的做法，每条规则对应一个条件组合和优先级，解析结果会缓存，避免每次审批都重新解析整棵规则树。缓存失效策略按规则版本号控制，规则发布后旧缓存自动作废。
- 超时处理：审批人24小时未处理时，系统自动触发提醒或把任务升级给上级。我们给一个做物流的客户加过这个机制。具体做法是审批节点创建时写入一个带超时时间的任务，由调度器定时扫描到期任务，先触发一次站内和Telegram提醒，再给一个宽限窗口，窗口内仍未处理才执行升级动作，同时记录完整时间线用于事后追溯。这个客户在菲律宾、越南、泰国都有站点，超时规则支持按站点分别配置，各站点的宽限窗口时长可以不同。
- 与业务数据联动：请假审批通过后，考勤系统自动扣减年假余额；合同审批完成后，财务系统生成对应凭证。审批状态和业务数据要保证最终一致，不能出现“审批通过了但考勤没扣”的情况。这块我们的做法是加事务补偿和状态校验，不靠前端触发。具体来说，审批结果落库后，业务动作进入一个待执行队列，执行完成后回写状态；如果中途失败，会按预设的补偿动作回滚或标记为待人工处理，而不是静默丢失。一个做过交易类系统的客户对这块要求最严，上线前专门核对过审批记录和业务流水的一致性。
一个典型场景是请假审批流：员工提交后，系统先校验剩余年假是否充足，再按组织架构找到直属主管；主管通过后，自动通知考勤模块完成扣减。整个过程不需要HR手动干预。这类流程在标准SaaS产品里通常要额外配置或者根本不支持，也是很多客户找我们重做的主要原因。
权限管理：决定谁能看什么数据
权限问题在OA系统上线初期容易被忽略，但一旦出现数据越权，影响往往比流程卡顿更严重。金融和交易类客户对这点最敏感——销售看不到别人的客户合同、部门经理只能看本部门考勤、财务字段对非财务人员隐藏，这些都属于必须隔离的范畴。
权限设计通常分三层来做：
- 功能权限：按角色控制菜单、按钮和接口。比如普通员工能看到考勤查询入口，但没有修改排班的权限；部门经理可以导出本部门考勤报表，但不能修改全局设置。
- 数据权限：控制数据行级可见范围。销售员只能查看自己名下的合同，销售总监可以看全部门数据。实现方式是在查询层做动态过滤，而不是靠前端隐藏按钮，否则接口层还是可能越权。具体做法是统一封装数据访问入口，根据当前用户的数据权限范围自动拼接过滤条件，业务代码不需要自己写权限判断，漏掉一处也不会直接暴露数据。交付前我们会专门做一轮越权测试，用不同角色账号直接调接口验证，不经过页面。之前有过一个地产项目，接口层漏了一个查询参数，页面看着正常，直接调接口能拉到全量合同列表，就是在这一轮测出来的。
- 字段权限：对薪资、身份证号、合同金额这类敏感字段做加密存储或脱敏显示，同时记录访问日志，方便事后审计。访问日志里会记录谁在什么时间通过哪个接口访问了哪个字段，字段级审计在金融类客户那边是基本要求。
组织架构本身用树形结构存储，部门下面嵌套小组和岗位，支持动态调整。查询时配合缓存避免递归遍历带来的性能问题，这在组织层级较深、员工数量较多时会明显影响响应速度。团队28人，长期维护着几十家客户在运营的系统，这类性能坑踩过不少，后来都沉淀成了固定写法。
| 权限层级 | 控制对象 | 典型场景 |
|---|---|---|
| 功能权限 | 菜单、按钮、API | 普通员工不能进入系统配置页 |
| 数据权限 | 数据行级可见范围 | 销售只能看自己的客户合同 |
| 字段权限 | 敏感字段显示与访问 | 薪资信息仅HR与财务可见 |
考勤与通知：决定系统是否被真正用起来
OA系统上线后，员工最直接的感知来自两件事：考勤好不好用、通知到不到位。这两块做不好，系统再强大也很难推下去。交付过的项目里，最后真正天天在用的，往往就是审批、考勤、通知这三样。
考勤模块需要支持弹性工时、多班次排班，并能和薪资系统对接，自动计算加班、缺勤和调休。对于有外勤或跨地区团队的企业——物流和地产客户里很常见——移动端打卡和定位是基本要求。考勤异常，比如迟到、早退、漏打卡，需要在短时间内通知到主管，而不是等月底汇总时才发现。通知链路我们走的是事件触发机制：打卡数据落库时同步比对排班规则，命中异常条件就立即产生一条通知事件，由消息分发模块推送到对应主管，不依赖定时轮询。这样做的好处是异常通知的延迟从“等下一次轮询”变成“落库即触发”，主管当天就能处理。
通知模块的关键是实时性和多渠道触达。审批提醒、考勤异常、公告通知可以通过WebSocket或SSE实时推送，同时结合邮件、短信、企业微信或钉钉做兜底。实际项目中，我们会在系统内建一套消息分发机制，确保重要通知不会因为某个渠道故障而丢失。具体做法是每条消息先进入发送队列表，按渠道分别记录发送状态和回执，失败的渠道自动重试，重试次数耗尽后标记为失败并汇总到告警。这套机制在给越南和印尼客户部署时帮了大忙，当地网络环境不同，多渠道兜底是刚需。有个印尼客户的短信通道偶尔会延迟十几分钟，Telegram通道正常，消息分发机制保证了通知不丢。
移动端与企业微信/钉钉集成
中小企业员工大量时间在手机上处理审批和考勤，OA系统如果只做PC端，使用率会非常低。目前比较务实的做法是通过H5微应用或小程序嵌入企业微信或钉钉，员工不需要额外下载App，也不用记新的账号密码。在柬埔寨、菲律宾、越南交付的项目，基本都走这个路线。
集成时用OAuth2.0实现免登录，员工从企业微信或钉钉进入后直接进入OA系统。消息推送走企业微信或钉钉的通道，审批提醒、考勤异常通知都能实时到达。移动端需要做离线策略：网络不好时，员工可以先把审批内容填好，系统在网络恢复后自动提交，避免因为信号问题丢失内容。这一点在柬埔寨本地尤其重要，部分地区移动网络不稳定，离线提交能省掉很多重复操作。离线提交的实现方式是本地先落草稿，提交时先写本地存储，再由后台同步任务检测网络状态后逐个上传，上传成功前草稿状态一直保留，不会因为切后台或杀进程丢失。
企业微信和钉钉的开放平台都提供打卡、定位、拍照、通讯录同步等API。定制开发时需要注意的是数据同步延迟，这个指标受企业规模、同步策略、网络环境影响很大，不能一概而论。我们给一个在多个国家有分支机构的客户做集成时，专门重写了同步逻辑，因为默认的定时全量同步在几千人规模下会拖慢整个系统，改成增量同步加变更事件触发之后，同步效率和时效性都有显著改善。这个客户在泰国和马来西亚都有办公室，通讯录变更后基本能在很短时间内同步到OA侧，不再等整点全量跑批。
开发周期与成本怎么评估
OA办公系统定制开发的周期和成本，取决于模块复杂度和集成深度。根据在金边团队的实际交付节奏，一个小型OA项目从需求梳理到上线，通常按以下节奏推进：
- 需求分析与设计：梳理现有审批流程、组织架构、考勤规则，输出原型和数据库模型。小型项目几天就能完成，复杂项目需要2到4周。
- 核心功能开发：实现审批流引擎、权限系统、考勤模块、移动端集成。小项目几天可交付，大项目约2个月。
- 测试与部署：包括功能测试、压力测试、安全检查和数据迁移。上线前会做一轮完整的越权测试和数据一致性校验，用不同角色账号直接调接口验证，不经过页面；数据迁移后抽样核对审批记录和业务流水的一致性。
团队在金边从事软件开发12年，目前28人，每年交付约100个项目，客户覆盖柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚，主攻电商、娱乐、金融/交易、地产、物流等行业。OA类系统属于经常交付的类型之一，部分成品系统有几十家客户在运营使用。
报价方面，按功能清单逐项评估，不提供笼统的“套餐价”。支付方式为先付30%，验收后结清尾款。具体报价需要面谈或通过Telegram详谈，因为不同企业的流程复杂度和集成需求差异很大，没有看到实际需求前给出的数字没有参考意义。支付通道由客户提供资源，我们负责对接，不提供支付通道本身。
关于系统维护和技术支持
系统上线后，维护响应速度直接影响使用体验。我们提供Telegram分钟级响应，并有AI运维辅助监控系统运行状态。系统本身的bug修复免费；如果后续需要新增功能，按实际工作量单独评估收费。服务语言为中文，方便国内团队或出海企业直接沟通。
有一点需要提前说明：如果OA系统涉及支付场景，比如报销打款或费用结算，支付通道需要由客户提供资源，我们负责技术对接，不提供支付通道本身。这个在项目边界里很明确，金融和交易类客户尤其需要提前对齐。
另外，电商类系统我们有现成的成品模块，可以开箱即用，交付速度比完全从零开发快很多。如果OA需求里包含和电商业务系统的对接，这部分可以复用现有模块，减少开发量。主攻的行业里电商占很大比重，这类对接做过不少。