跨国企业于各业务单元推行D365 Finance 及 Operations时，常轻估环境策略之决断将如何塑造其ERP生命之来世十年。各业务单元所处行业不同，其流程、法规遵从及数据敏感度亦各异。初选结构若误，悔之晚矣。

建筑工坊有三式浮现。各有所倡；唯一式可成规模.

其二隅之例不效

单例一统，诸业部皆归一法团。尚简：一配置，一安模，一主数据。然业部异则立破：

• 财政历法（年历与财历异）
• 账户明细表（制造业与服务业之会计科目结构迥异）
• 法定报税之责（医疗业与零售业之监管体系殊别）
• 公司间之界限（统一之成本核算不可自相交易）

跨行业合并之议，初则兴味渐消。

各业单元分设租户。致各业单元截然孤立。遂生可预之患：

• 跨业单元之合并报告，成 Azure Synapse 之项目
• 每租户各持其许可，各循其升级之序，各负其管理之费
• M&A 若欲重组业单元，必迁租户之居
• 规模经济于共享配置渐消

团队于共享环境有所顾忌时，常倡此法。其忧，多可藉共享租户内之安全界限以解。

定制集成层，合并自不同D365环境之输出。构建新系统，以解决平台已能处理之问题。永久持续之成本；引入新之真源；减缓每新业务单元之入驻。

可扩展之模式

单租户，多法律实体，以组织层级与安全角色实现业务单元隔离。

架构：

• 一D365租户承载数产与非数产境域
• 一法体每BU（或一BU一国若BU跨国营）
• 国别本地化包按法体所需施用
• 组织层级——企→BU→营运单元→部——助成财报分界与安界
• 安全是按组织层级限定于业务单元的——业务单元的用户仅可见其自身业务单元的数据，虽共享租户
• 共享主数据，业务单元间共享供应商或客户，通过全球地址簿；业务单元专属主数据按法律实体配置
• 分层模型中的定制——共享逻辑的核心模型，业务单元专属的行业变体模型，共同部署

其果也：BU得独立自主，而企业得整合、共享管理及平台经济之效。

组织层级之设

层级者，租户支财务与运营之裁也：

• 财务报告层级：LE↔BU↔部门↔企业。试算表滚上以合之。
• 运作之序：总管↔️事业部↔️部门↔️团队。主司安全与流程之导引。
• 法理之序：总管↔️直属总管↔️终极总管。为法定所有权之披露。

多序并存。各司其职。混而为一，乃常见之设计谬误。

具有事业部隔离之安全模态

共享租户之內，安全之制，使BU之資料獨立，其道有二：

• 角色之範圍，定於法律實體——BU之會計，唯見其LE之內事
• XDS（可擴展數據安全）之策，過於LE之範，如LE內部之部門範圍
• XDS之中，組織之階層，作為策參，引用使用者之BU於階層之間
• 企业职能之权责集中——企业财会、企业审计、IT管理诸权，遍及各层级单位，并需核准

此较之“仅用分立租户”更繁，然得单租之利，不损数据之界

按业务单元分层定制

F&之延展模式，支持分层定制。其式：

• 基础模型——企业标准之延展，凡事业部皆承之（特定地域之税赋延展，中央审批之框架）
• 行业模型——各行业共享之延展，供该领域事业部所用（制造延展，零售延展）
• 事业部专属模型——独属于某事业部之需而设之延展

各版本模型分而治之，如链式部署。某业务单元之定制，可及之而不染他物。

跨业务单元的ALM

多BU租户，ALM须支持：

• 共筑基业与行业模型之构建流水线
• 按BU专属模型之管道
• 环境之策——各事业部别立开发，共沙盒以合流，共UAT以协试，产线共享诸部

建设之协乃新之繁难。常由卓越中心之众主基业与行业模型，协诸部之列车以应

分立之户适其时

间有独居者，诚合其宜。

• 法所要求之监管隔离（特定国防或医药情形）
• 租户区域部署内无法调和的数据驻留冲突
• 摩&一境也，所获之单元终将自旋而出
• 大小悬殊，BU之规模足以自成一行政团队

此等情形甚稀。跨国多BU之默认模式乃单租户、多法律实体

具备此模式之配备

运作中之多BU D365租户具备：

• 每BU之法律实体，配以适宜之本地化
• 财务与运营之组织层级
• 以层级与XDS界定BU之安全角色
• 共享主数据框架，具BU专属发布模式
• 分层定制模型（基础、行业、BU）
• 共享配置之CoE治理
• 支持模型分层之ALM流程

此纹枯寂，盖因履之者众。此正其意。新境之策，乃多年悔恨所积之地也。