D365 Solution Blueprint 分区访谈指南：14 个架构决策节拍的提问框架、选项权衡与承重决策管理
【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot
本篇技术指南完整解析 awesome-copilot 仓库中d365-solution-blueprint技能的核心参考文档——分区访谈指南。该文档是 Dynamics 365 Finance and Supply Chain Management（D365 F&SCM）解决方案蓝图（Solution Blueprint）工作坊的"提问剧本"：它把整场架构访谈拆解为 5 条 Track、14 个章节，并为每个章节规定"本节约定什么、问哪些问题、在真正存在架构选择时给出哪些选项、以及最常见的陷阱是什么"。读完本篇，你将掌握一套可以直接照搬的 D365 实施架构访谈方法论，理解 8 个"承重决策"（load-bearing decisions）为何必须在会话中被钉死，以及如何用决策日志、开放项和假设登记表把访谈结果沉淀为可交付的蓝图文档。
这份指南在技能中的定位
d365-solution-blueprint技能本身被定义为"从零开始、通过逐章节架构师访谈，撰写一份 D365 财务与供应链管理解决方案蓝图"。其工作方式不是一次性的文档生成，而是一个多会话的决策过程：蓝图是决策过程的产出物，而不是假设的堆砌。技能主体 SKILL.md 明确警示了要避免的最严重失败模式：
一份 14 个章节中草拟了 10 个、还有 8 个决策标记为 OPEN 的蓝图是诚实且有用的；一份 14 个章节全部完成、没有任何开放项、却由你编造答案的蓝图是危险的，因为会有人照着它去建设。
分区访谈指南 正是这场访谈的执行手册。SKILL.md 要求"只加载当前正在推进的章节"（Load only the sections in play），而不是一次性把 14 个章节的全部问题倾倒给客户。每个章节的条目都回答四件事：
- Decides——本小节要敲定什么架构决策；
- Ask——向客户提出的问题集；
- Options to propose——在存在真实架构选择的地方，给出 2~4 个候选方案及其权衡；
- Trap——该章节最常见、最昂贵的思维陷阱。
其中带⚑ 标记的是承重决策：会话不允许在没有决策、或没有指定决策负责人与阻塞日期的情况下滑过去。
总体结构：五条 Track 与 14 个章节
| Track | 覆盖章节 | 主题 |
|---|---|---|
| Track A - Foundation | 1–3 | Programme context | Scope ⚑ | Target operating model |
| Track B - Solution | 4–6 | Application architecture ⚑ | Data architecture ⚑ | Integration architecture |
| Track C - Data and control | 7–8 | Data migration ⚑ | Security and licensing |
| Track D - Platform | 9–11 | Environment and ALM | Reporting and analytics | Performance and volumetrics |
| Track E - Delivery | 12–14 | Test strategy | Deployment and cutover ⚑ | Support and operating model |
Track A 必须最先完成，这不是风格偏好而是结构性要求：法人实体结构与分阶段部署（phasing）决策会级联影响后面所有章节。如果 Track B 起草完成后再推翻它们，意味着整份架构返工。
⚑ 承重决策：八个不可逆或逆转代价高昂的决定
SKILL.md 的 "Load-bearing decisions" 一节将承重决策归纳为八个，并在 section-guide 与 蓝图模板 中用 ⚑ 标记：
- 法人实体结构（第 2 节）——多少个实体，每个实体放什么；
- 会计科目表与财务维度设计（第 5 节）——维度数量、必填维度、报表基数；
- 单一 vs 多生产实例（第 4 节）；
- 部署分阶段方式（第 2 节，第 13 节复核）——big bang、按地区、按模块、按法人实体或试点后推广；
- 产品与库存维度模型（第 5 节）——仓储与追踪维度、批号/序列号、变体策略；
- Dual-write 与 Power Platform 范围（第 4、5 节）——哪些实体、哪个方向、故障行为；
- 扩展姿态（extension posture）（第 4 节）——standard-first 阈值与谁能批准 gap；
- 历史数据处理方式（第 7 节）——迁移、遗留只读、或单独归档/数据平台。
如果客户当场无法决策，必须做三件事：将其记录为承重开放项；指定决策负责人与开始阻塞的日期；声明哪些下游章节因此处于临时（provisional）状态。例如："第 5、7 节基于假设 X 起草。若 X 变更，两节均需复审。"
TRACK A - FOUNDATION：先钉死地基
1. Programme context and business case（项目背景与商业论证）
Decides：这个项目为什么存在、成功长什么样、什么真正不可妥协。下游所有工作都以此为优先级基准。
Ask：
- 现在推动它的因素是什么：遗留系统生命周期终结、业务增长、收购整合、合规、成本，还是其他？
- 商业论证以可衡量的方式承诺了什么？谁对这些结果负责？
- 执行发起人是谁，谁有决策权？
- 哪个约束是真正固定的：日期、预算、范围、法规，还是别的？
- 以前尝试过什么，学到了什么？
Options to propose：无固定选项表——本节的核心是识别"真正固定的约束"而非提出方案。
Trap：一个依赖流程变更来支撑的效率型商业论证，而该流程变更根本没有人同意去做。
Produces：驱动力、可衡量目标、发起人与治理结构、固定约束、项目历史。
2. Scope ⚑（范围）
Decides：哪些应用、模块、法人实体、国家与部署波次（wave）纳入范围。
Ask：
- 哪些 Dynamics 365 应用和模块在范围内，哪些明确排除？
- ⚑ 拟采用多少个法人实体？每个实体存在的原因是什么：法定申报、功能货币、监管需要、管理模式，还是继承下来的结构？
- 需要哪些国家和本地化（localisation）？
- 什么留在其他系统上，谁拥有那个边界？
- ⚑ 部署分阶段方式：big bang、按地区、按法人实体、按模块，还是试点后推广？
Options to propose - 分阶段方式：
| 方式 | 适用场景 | 代价 |
|---|---|---|
| Big bang | 范围紧凑或高度相互依赖 | 单点切换风险最高；波次之间没有学习期 |
| 按地理 / 法人实体 | 各单元可半独立运营 | 更长的双轨运行期与临时集成复杂度 |
| 按模块 | 有清晰的功能推进顺序 | D365 与遗留流程之间存在临时集成 |
| 试点后推广 | 大量相似实体支持模板化方式 | 第一波吸收模板学习成本，需要强治理 |
始终要问：临时状态的集成与控制会花多少钱。
Trap：把遗留系统的法人实体结构原样照搬，而不去检验当初的理由是否仍然成立。
Produces：应用/模块范围、法人实体登记表、国家/本地化范围、明确的 out-of-scope 声明、波次计划。
3. Target operating model and process architecture（目标运营模式与流程架构）
Decides：上线后业务如何运作，D365 支撑哪些流程。
Ask：
- 已有目标运营模式，还是在对照现状设计？
- 共享服务中心还是分布式处理？哪些职能？
- 审批权限将落在哪里，是否会变化？
- 哪些流程真正差异化，哪些是商品化的？
- 谁拥有每个端到端流程并有权限决策？
- 公司间（intercompany）流程是在变化，还是仅仅换个系统？
Options to propose - standard-first 姿态：
| 姿态 | 陈述 | 适合 |
|---|---|---|
| 严格标准 | 除非法定约束要求，否则业务适应系统 | 强变更意愿的成本驱动项目 |
| 标准 + 有据例外 | 扩展需要书面业务/监管理由与指定审批权限 | 大多数企业实施 |
| 贴合流程 | 系统重度适配现有业务流程 | 若无明确价值与生命周期成本接受度，很少站得住脚 |
Trap：空喊"尽可能用标准"，却没有阈值、没有审批论坛、也没有拒绝 gap 的权限。
Produces：运营模式摘要、流程架构、流程负责人、gap 治理姿态。
TRACK B - SOLUTION：解决方案形态
4. Application architecture ⚑（应用架构）
Decides：应用版图、实例策略、ISV、Power Platform 角色与扩展姿态。
Ask：
- ⚑ 单一生产实例还是多个？什么需求能证明多个合理？
- 哪些 ISV 在范围内？他们的支持与服务更新姿态如何？
- ⚑ 什么应该放在 Power Platform 而不是 Finance/SCM 中，为什么？
- 哪些现有 Power Apps、Power Automate 流或 Dataverse 依赖必须存活？
- ⚑ 扩展审批阈值是什么，谁能批准一个 gap？
Options to propose - 逻辑放置（logic placement）：
| 层 | 用于 | 避免当 |
|---|---|---|
| D365 配置 | 参数、工作流、策略、标准行为 | 需求确实需要新的业务逻辑 |
| Electronic Reporting | 单据、监管格式、文件生成场景 | 复杂的事务型逻辑 |
| Power Platform | 任务型应用、审批、轻量编排 | 需要 ERP 事务一致性的高量交易处理 |
| X++ 扩展 | 需要事务一致性的 ERP 业务逻辑 | 标准配置或低代码选项能满足需求 |
| 外部服务 | 专业领域与解耦能力 | 它创造了组织无法运营的平台 |
Trap：先于架构选定 ISV，却没有测试更新兼容性、支持模式与退出策略。
Produces：应用版图、实例决策、ISV 登记表、Power Platform 范围、扩展治理。
5. Data architecture ⚑（数据架构）
Decides：会计科目表、财务维度、产品模型、主数据归属，以及 Dataverse/dual-write 范围。
Ask：
- ⚑ 会计科目表是共享还是按实体独立？科目精简（rationalisation）是否在范围内？
- ⚑ 需要哪些财务维度、哪些是必填的，每个维度服务于什么决策/报表？
- ⚑ 需要哪些产品、仓储、追踪、批号/序列、变体维度？
- 谁拥有客户、供应商、产品等主数据？有没有 MDM 平台？
- ⚑ 哪些实体（如有）被 dual-write，写入哪个方向？
- 如果 dual-write 或其他数据同步依赖不可用，运营上会发生什么？
Options to propose - 维度设计：
| 方式 | 后果 |
|---|---|
| 少数、受治理的维度 | 过账更干净、采用更容易、报表更简单 |
| 大量可选维度 | 分析灵活，但复杂度更高、数据质量更弱、基数更大 |
对每个拟议维度都要追问：它服务于哪个报表或决策，谁消费它？
Trap：产品/库存维度决策与成本核算、仓储、质量、报表团队隔离做出。
Produces：COA/维度设计、产品模型、主数据归属矩阵、dual-write 范围与故障行为。
6. Integration architecture（集成架构）
Decides：接口版图、模式原则、中间件方向与故障设计标准。
Ask：
- 完整接口清单是什么：源、目标、方向、量、频率、延迟、关键度？
- 每个关键接口停机四小时的业务后果是什么？
- 中间件策略是什么：直连、Azure Integration Services、现有 ESB，还是其他平台？
- 上线后谁拥有每个接口，谁接收告警？
- 哪些遗留契约或外部接口约束了设计？
Pattern options：
| 模式 | 适合 | 留意 |
|---|---|---|
| OData / 自定义服务 | 低量同步访问 | 限流与同步耦合 |
| Data management / 周期性集成 | 批量和海量移动 | 延迟、暂存、错误处理 |
| Business events | 事件驱动通知 | 重复投递与幂等性 |
| Dual-write | 近实时的 F&O/Dataverse 同步 | 耦合与故障行为 |
| Service Bus / Logic Apps | 解耦、重试、编排 | 额外的平台归属与运维 |
| Analytics export/Fabric 路径 | 报表与分析消费 | 不是运营写入模式 |
对关键接口，蓝图层面必须要求：重试、毒消息处理、幂等性、告警、归属、对账。
Trap：接口清单按平均量估算、只按 happy path 设计。
Produces：清单、模式原则、中间件决策、故障原则、归属模型。
TRACK C - DATA AND CONTROL：数据与控制
7. Data migration ⚑（数据迁移）
Decides：哪些数据搬移、历史如何处理、期初余额如何处理、正确性如何被证明。
Ask：
- ⚑ 历史数据：迁移、保留遗留只读、还是抽取到归档/数据平台？背后是哪个具体的义务或业务需求？
- 哪些对象落入配置、主数据、未结事务、期初余额、历史这些类别？
- GL、AR/AP、库存、固定资产、银行等领域需要什么期初余额处理？
- 数据清洗在哪里进行，谁负责？
- 谁对迁移数据签字验收，对照哪些源/控制报表？
- 迁移计划使用哪些工具和环境？
Options to propose - 历史处理：
| 方式 | 成本 | 后果 |
|---|---|---|
| 迁移明细历史 | 对账与数据库成本最高 | 系统内完整历史 |
| 保留遗留只读 | 持续的遗留访问成本 | 迁移最快，用户体验较弱 |
| 抽取到归档 / 分析存储 | 实施成本中等 | 通常是较强的报表折中方案 |
Trap：历史迁移只是出于习惯，而不是法律、审计或运营需要。
Produces：迁移范围、历史决策、期初余额策略、清洗归属、对账、签字模型与工具方向。
8. Security, compliance, and licensing（安全、合规与许可）
Decides：安全原则、职责分离（SoD）要求、数据访问边界、许可形态与访问管理。
Ask：
- 存在哪些岗位族与用户群体，跨哪些法人实体？
- 适用什么 SoD 期望，谁是控制权威？
- 是否存在数据驻留、隐私或行业特定约束？
- 除法人实体与组织边界外，是否需要记录级限制（XDS）？
- 当前签约了哪些许可，数量背后的假设是什么？
- 谁管理入职、调岗、离职、特权访问与重认证？
Trap：在角色设计之前就敲定许可权利，此后从未对照实际访问重新验证。
Produces：角色族模型、SoD 期望、合规约束、XDS 需求、指示性许可形态、访问管理模型。
TRACK D - PLATFORM：平台与运维
9. Environment strategy and ALM（环境策略与 ALM）
Decides：环境拓扑，以及代码/配置如何在环境中流转。
Ask：
- 已授权哪些环境，需要什么额外容量？
- 每个环境用来做什么、谁拥有、刷新节奏如何？
- 黄金配置（golden configuration）保存在哪里，配置如何传输？
- 跨所有交付方采用什么分支与源码控制策略？
- 构建、发布、审批与生产部署如何自动化？
- 谁拥有服务更新计划与回归门禁？
Trap：环境规划只按开发规模设计，没有为迁移演练、UAT、培训与切换的并发需求预留容量。
Produces：环境拓扑、刷新策略、黄金配置方法、分支/流水线设计、更新治理。
10. Reporting and analytics architecture（报表与分析架构）
Decides：需要哪些信息产品，以及由哪些技术提供服务。
Ask：
- 哪些报表真正业务关键？谁消费，驱动什么决策？
- 每份报表实际需要什么延迟？
- 各国存在哪些法定与监管报表？
- 分析平台方向：Power BI、Fabric、现有数仓，还是其他？
- 上线后谁构建和维护报表？
Tool-selection examples：
| 需求 | 候选方案 |
|---|---|
| 财务报表 | Financial reporting 能力 |
| 运营单据与法定格式 | SSRS / Electronic Reporting（视情况） |
| 运营查询 | D365 标准视图与工作区能力 |
| 跨职能仪表盘 | Power BI |
| 企业级分析 | Fabric / 受治理数据平台 |
| 即席财务分析 | 适当的 Excel 集成 |
Trap：要"实时"，却没有把延迟连接到实际的决策节奏上。
Produces：报表清单、延迟需求、工具映射、分析方向、法定方案、归属。
11. Performance, scale, and volumetrics（性能、规模与数据量）
Decides：设计能否支撑预期生产负载，以及后期必须测试什么。
Ask：
- 每个关键流程的平均与峰值事务量是多少？
- 未来三年当前与预计的数据量是多少？
- 按职能的峰值用户并发是多少？
- 存在哪些批处理窗口与硬性截止时间？
- 今天月结或其他关键业务周期耗时多久，目标是多少？
- 哪些运营截止时间构成不可妥协的性能约束？
Trap：用年度平均值设计，而真正的设计驱动力是峰值小时或期末需求。
Produces：数据量基线、增长预测、并发画像、批窗口约束、性能验收目标。
TRACK E - DELIVERY：交付与运营
12. Test strategy（测试策略）
Decides：上线前如何证明质量，以及如何通过未来的服务更新维持质量。
Ask：
- 需要哪些测试层级：单元、功能、集成/端到端、UAT、性能、安全、回归、灾备？
- 谁编写并拥有测试，测试如何追溯到需求/流程？
- 使用什么测试数据与数据量？
- 需要什么回归自动化，人工替代方案的成本是多少？
- 每个阶段适用什么数值化退出标准？
- 谁签字认可 UAT 与就绪状态？
Trap：没有回归自动化，也没有经费支撑的人工回归容量。
Produces：测试层级模型、可追溯方法、测试数据策略、自动化决策、退出标准、缺陷严重度模型。
13. Deployment and cutover approach ⚑（部署与切换方案）
Decides：上线形态，以及后续详细 runbook 必须满足的约束。
Ask：
- ⚑ 第 2 节的分阶段决策在理解了其余架构后仍然成立吗？
- 可用的切换窗口是什么，什么驱动其边界？
- 需要并行运行吗？谁需要，它能证明什么？
- 回滚位置与不可回退点（point of no return）是什么？
- 谁宣布 go/no-go，依据哪些可测量标准？
- 业务能容忍什么程度的数据冻结？
Trap：切换窗口基于偏好，而不是基于实测的全量迁移耗时。
Produces：部署方式、切换窗口约束、并行运行决策、回滚位置、go/no-go 权限。
14. Support and operating model（支持与运营模式）
Decides：实施后谁运营方案，知识、更新、支持与变更如何治理。
Ask：
- 目标支持模型是什么：L1/L2/L3、内部、伙伴托管还是混合？
- 超期支持（hypercare）的时长、人员与退出标准是什么？
- 上线后哪些具名人员掌握功能、技术与架构知识？
- 谁拥有服务更新日历与回归门禁？
- 上线后的变更流程是什么——增强、新实体、新需求？
- 谁负责与 Microsoft/产品路线图的关系？
Trap：知识转移计划只写了角色或团队名，却没有分配实际的接收人。
Produces：支持层级与归属、hypercare 模型、知识转移计划、更新治理、变更流程。
配套机制：这场访谈如何真正跑起来
section-guide 提供"问什么"，而 SKILL.md 规定"怎么问、怎么记"。二者配合才构成完整的访谈纪律：
五个节拍（five beats）。每个章节都遵循同一节奏：Frame（用两三句话说明本节决定什么、为什么约束后续工作）→Ask（向用户抛 3~5 个问题，绝不一次倾倒二十个）→Propose（在存在真实架构选择处给出 2~3 个选项与权衡，并给出建议）→Record（把决策连同理由与备选方案记入决策日志，或标记为带负责人与日期的 OPEN）→Draft and save（写章节、展示、持久化工作文件、更新进度跟踪器）。默认不在一个回合推进两个章节——访谈的价值在于追问本身。
访谈技巧。产生真实蓝图的模式是：提出设计问题 → 探查其背后的约束 → 浮出客户没考虑过的选项。例如法人实体结构："多少个实体？" → "什么驱动它：法定申报、功能货币、管理报表还是历史结构？" → "其中三个实体功能货币相同且合并申报。考虑到公司间开销，你有没有考虑过它们在 D365 中是否都需要保持独立？"当用户给出方案时，回溯到需求；给出需求时，提出选项；当对方说"跟今天一样"时，追问今天代表的是目标运营模式还是仅仅现状。若你不同意某项决策，如实记录客户决策，并加一条Architect's note说明你的建议与看到的风险——不能默默绕开，也不能拒绝记录。
决策日志的六字段纪律。决策日志中的每条记录必须携带六个字段：Decision（毫不含糊地说了什么）、Rationale（为什么）、Alternatives rejected（还考虑了什么、为何落选）、Implications（现在约束了下游什么）、Decided by（具名的人，而不是"项目"）、Date。蓝图中的每个实质性陈述都必须归类为且仅归为四类之一：Decision（已决策、有主、有日期）、Assumption（相信为真但未验证，必须有负责人与验证日期）、Constraint（外部强加、不可协商）、Open item（未决策，必须注明负责人与最迟日期）。开放项在正文中写成**OPEN - [owner] / [date needed]**，同时列入登记表。绝不允许假设漂移成决策。
会话连续性。蓝图工作文件是会话之间的持久记录：每次会话结束保存并告知用户文件位置；每次后续会话开始先读蓝图，读 Progress tracker 与 Decision log，确认上次停在哪里，先总结开放项——决策日志已回答的问题绝不重问。若用户没有工作文件且无持久副本，要求提供最新文件，而不是凭记忆重建决策。
验证纪律。在断言 Dynamics 365 支持什么、某本地化覆盖什么、某许可允许什么、未来版本提供什么之前，只要有文档、搜索或 MCP 能力，先对照权威 Microsoft 来源核实，首选 Microsoft Learn 与当前 Dynamics 365 发布文档，并在蓝图中记录来源与核验日期；若无法核实，标注为"需验证"而非当作事实断言。原因很直接：对标准能力的错误假设，会在实施后期变成昂贵的 gap。
把访谈结果落成文档：蓝图模板
产出物的骨架由 蓝图模板 提供。其结构要点：
- 控制页：Version / Status / Solution Architect / Client sponsor / Last session / Distribution；
- Progress tracker：位于工作文件顶部、紧随控制页，逐节记录
Not started | In progress | Drafted - open items | Complete，并单列"Load-bearing decisions outstanding"表（决策、负责人、阻塞日期、受影响临时章节）； - 决策日志 / 假设登记表 / 约束表 / 开放项表 / 风险表：五张注册表贯穿全程；
- 14 个章节正文：每个章节又细分为若干小节（如第 2 节含 Legal entity register 表格，第 4 节含 ISV register，第 6 节含 Interface inventory 与错误处理矩阵，第 10 节含 Report inventory，第 11 节含 Transaction volumetrics，第 14 节含 Knowledge transfer 计划表）；
- 附录 A–C：References（来源与核验日期）、Architect's notes（建议 vs 实际决策 vs 风险 vs 接受人）、Version history。
工作文件用 Markdown（.md），文件名为<client>-solution-blueprint-v<N>.md，每次正式签发或实质性更新时递增版本。工作坊收尾时，技能会建议对完成的蓝图做独立评审——作者不应是自身架构的唯一评审人。
实践要点速查
- 顺序不可乱：Track A 必须先行，法人实体与 phasing 决策级联影响一切；
- 承重决策不许滑过：八个 ⚑ 决策要么当场拍板，要么登记为带负责人与阻塞日期的 OPEN，并声明哪些下游章节因此临时；
- 一个回合一个小节：每次只推进一个章节的 Frame→Ask→Propose→Record→Draft 循环；
- 表格是选项库：phasing、standard-first 姿态、logic placement、维度设计、集成模式、历史处理、报表工具这七张表，是访谈中"提出选项"的直接弹药；
- 四类陈述严格区分：Decision / Assumption / Constraint / Open item 不混用，假设必须带验证负责人；
- 事实先核验再落笔：涉及平台能力、许可、本地化与未来版本的内容，先查权威来源并记录核验日期；
- 产出即档案：进度跟踪器、决策日志与工作文件持久化，是下一次会话与独立评审的共同基础。
这份指南的价值在于：它把"D365 实施架构设计"从一次性的文档撰写，还原为一场被严谨提问、选项权衡与决策记录纪律约束的多会话访谈——最终交付的不是一份看起来完整的文档，而是一份每一步都有据可查、每个开放项都有主有时限的架构决策记录。
【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
