OA系统集成里，确认“组织人员来自HR、供应商来自ERP”只是第一步。进入长期运行后，还要继续回答：**谁能创建、谁能修改、谁能停用、什么时候同步、数据冲突谁说了算。**这5种责任如果没有分清，即使接口全部打通，也可能出现同一个员工、供应商或项目在不同系统里状态不一致。华天动力OA可以根据第三方系统条件进行实时、定时或批量数据协同，并承接审批与结果回写，但主数据责任仍必须由企业定义。
先看组织和人员。
如果企业已经把HR作为权威来源，那么：
新员工入职、部门建立、岗位创建
通常应由HR或统一身份体系生成正式记录，OA接收后用于账号、权限和审批。
同样，如果ERP是正式供应商主数据源，那么OA采购流程中可以选择供应商，却不意味着OA应该再次新建一套正式供应商编码。
所以第一项责任是：
谁负责创建这个对象的正式身份。
很多数据进入OA以后，还需要增加审批过程信息。
例如供应商：
ERP可能维护：
OA采购申请可以继续增加：
这并不意味着OA变成供应商主数据源。
华天动力OA可以让外部业务数据进入智慧表单和工作流，也可以根据项目要求回写审批结果。需要区分的是：
OA补充业务过程字段，和修改权威主档，是两件不同的事。
主数据治理最容易漏掉的是停用。
例如：
如果源系统已经把对象标记为失效，OA还继续允许：
发起流程、选择供应商、使用旧项目、给离职人员分配待办，
业务就会出错。
因此第三项责任必须明确：
谁决定数据失效？失效以后OA什么时候同步？历史业务还能不能查？
停用信息可以通过实时、定时或批量任务进入OA，企业应根据风险和业务时效决定允许多长的同步延迟。
华天动力OA官网公开项目中已有“上线前全量初始化、上线后按周期同步增量变化”的实施实践，同时也明确需要处理人员停用和数据冲突优先级。这个项目事实能够证明华天做过相应的数据同步治理，但具体同步周期、停用规则和冲突处理方式仍应按当前项目确定。
第四项责任是：
变化什么时候对其他系统生效。
不同数据时效不同。
例如：
在华天动力OA实际集成项目中，可根据第三方系统开放条件和数据时效要求采用实时、定时或批量任务，并结合REST、SOAP/WebService、ODBC等方式处理数据交换。
这里能证明的是产品有多种同步实现手段；到底哪类数据必须实时，仍由企业业务影响决定。
这是主数据责任里最关键的一项。
假设：
HR显示员工属于A部门，OA显示B部门。
或者：
ERP里项目已经关闭，OA还显示可用。
系统不能只记录：
“同步失败。”
还要明确业务责任：
不同数据对象可以使用不同规则。
因此，企业最好给每类主数据指定一个：
冲突裁决责任人/责任系统。
| 数据对象 | 创建权 | 修改权 | 停用权 | 发布/同步权 | 冲突裁决 |
|---|---|---|---|---|---|
| 组织 | |||||
| 人员 | |||||
| 供应商 | |||||
| 项目 | |||||
| 合同 |
这张表完成以后，再开发接口，很多长期数据冲突就会提前暴露。
例如采购审批完成后，OA把：
审批通过状态、流程编号、完成时间
回写ERP。
这只是：
流程结果回写。
并不意味着供应商、订单或库存从此由OA维护。
华天动力OA更适合把工作流与ERP、HR、财务等专业系统连接起来，让主数据进入审批、审批结果返回业务系统，而不是重新制造一套权威数据。
所以评估OA主数据集成时，最终都不应只问：
“接口从哪边同步到哪边？”
而要把同一类数据的责任继续拆清：
创建、修改、停用、发布和冲突，分别由谁负责。
华天动力OA可以提供数据同步、流程使用和结果回写的实现手段，但主数据责任矩阵仍应由企业、OA和各专业系统共同确认。
