D365 Solution Blueprint用结构化架构访谈驱动 Dynamics 365 Finance and Supply Chain Management 实施方案设计【免费下载链接】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 技能展开系统讲解其核心产物——Solution Blueprint 模板含 5 个 Track、14 个章节的完整文档骨架以及配套的分章节访谈指南。读者将掌握如何按 Tracks 组织 D365 实施架构访谈、如何填写进度跟踪器与决策日志、哪些决策属于承重决策Load-bearing decisions必须现场拍板或挂起为显式开放项以及如何把访谈结果沉淀为一份诚实、可用、可追溯的 Solution Blueprint 文档。文中所有表格、字段与流程均直接继承自模板与指南并补充了技能运行机制与决策治理规则的实现说明。一、什么是 Solution Blueprint为什么要用结构化模板在 Dynamics 365 Finance and Supply Chain ManagementFSCM项目实施中Solution Blueprint 是介于项目章程与详细设计之间的关键架构交付物它记录范围、目标运营模式、应用架构、数据架构、集成格局、迁移策略、安全模型、ALM、测试、部署与支持方案以及支撑这些方案的每一项架构决策及其理由。本项目中的 d365-solution-blueprint 技能将其定位为一场多会话的架构访谈工作坊blueprint workshop series而非一次性的文档生成捷径。正如 SKILL.md 明确指出的The blueprint is the output of a decision process. Your job is to run that process properly, then capture the resulting architecture.技能强调的最高优先级失败模式是产出一份看似合理、实则充满客户从未真正做出的假设的蓝图。十四个章节草拟了十个、八个决策仍然 OPEN 的蓝图是诚实而有用的而十四个章节全部完成、没有任何开放项、答案都是你编造的蓝图是危险的——因为有人会照它去施工。这意味着模板的存在意义不是填满表格而是强制访谈过程不遗漏任何承重决策并让每一个未决事项显式可见、可追踪。技能包的文件构成文件作用skills/d365-solution-blueprint/SKILL.md技能入口定义技能触发条件、会话运行规则、五拍访谈节奏、决策治理纪律与输出规范skills/d365-solution-blueprint/assets/blueprint-template.md蓝图文档模板控制页 进度跟踪器 各类登记册 14 章节骨架 附录skills/d365-solution-blueprint/references/section-guide.md章节访谈指南每章决定什么 / 问什么 / 选项集 / 陷阱仅按需加载正在进行的章节模板中带⚑标记的章节2 Scope、4 Application architecture、5 Data architecture、7 Data migration、13 Deployment and cutover对应技能定义的八项承重决策下文将逐一说明。二、模板整体骨架控制页、跟踪器与登记册2.1 控制页Control Page模板开头是文档元信息表用于让任何读者包括后续会话的 AI 代理一眼判断文档状态字段说明Version文档版本初始为 0.1随签发或实质性更新递增Status进行状态如 In progress - Track ASolution Architect方案架构师负责人名而非项目组Client sponsor客户出资/发起人Last session最近一次工作坊日期Distribution分发范围2.2 进度跟踪器Progress Tracker进度跟踪器必须放在工作文件的最顶部、紧跟控制页之后SKILL.md 输出规范 明确要求 Keep the Progress tracker at the top of the working file, immediately after the control page并在每个会话结束时更新。它是恢复会话的第一阅读对象。跟踪器按 5 个 Track、14 个章节组织每章记录状态与开放项TrackSectionTopicStatusLast updatedOpen itemsA1Programme context and business caseNot startedA2Scope ⚑Not startedA3Target operating modelNot startedB4Application architecture ⚑Not startedB5Data architecture ⚑Not startedB6Integration architectureNot startedC7Data migration ⚑Not startedC8Security, compliance, and licensingNot startedD9Environment strategy and ALMNot startedD10Reporting and analyticsNot startedD11Performance and volumetricsNot startedE12Test strategyNot startedE13Deployment and cutover ⚑Not startedE14Support and operating modelNot started状态取值仅有四种Not started、In progress、Drafted - open items、Complete。这套受控词表controlled vocabulary让诚实有了可执行的形态——不允许出现已完成但还有未决事项的模糊中间态。2.3 承重决策登记Load-bearing decisions outstanding紧接跟踪器的是未决承重决策表#DecisionOwnerBlocking bySections provisional if it changes该表把尚未拍板、但一旦变化会推翻多个章节的决策单独拎出与决策日志分离保证下一会话恢复时第一眼就能看到当前最大的架构风险点。2.4 决策日志Decision log每一行决策记录六个字段缺一不可SKILL.md 决策记录规范字段为什么重要Decision决策内容表述必须无歧义Rationale为什么做此决策Alternatives rejected还考虑过什么方案、为什么落选Implications该决策约束了下游哪些工作Decided by具名的人而不是项目组Date决策日期2.5 假设登记册Assumptions registerIDAssumptionImpact if falseValidation ownerValidate byStatus假设是相信为真但尚未验证的陈述必须有验证负责人与验证日期。技能强调绝不允许假设悄悄漂移成决策——在章节正文与登记册两处同时标记防止后续读者误读。2.6 约束登记册ConstraintsIDConstraintSourceConsequence约束是外部强加、不可谈判的限制法规、合同、既有平台与可谈判的假设、待定的开放项严格区分。2.7 开放项Open itemsIDOpen itemSectionOwnerNeeded bySeverity开放项 尚未决策的事项负责人与截止日期Needed by为必填。章节正文中以**OPEN - [owner] / [date needed]**内联标记并在登记册中同步列出。2.8 风险登记册RisksIDRiskLikelihoodImpactSeverityMitigationOwner三、五种材料的正确分类Decision / Assumption / Constraint / Open item模板的多册结构背后是一条核心治理纪律蓝图中的每一句实质性陈述都必须被归类为恰好一种SKILL.md 决策记录规范Decision决策——已做出、有归属人、有日期Assumption假设——相信为真、尚未验证必须标注验证负责人与日期Constraint约束——外部强加、不可谈判Open item开放项——尚未决定必须有归属人与所需日期。Never let an assumption drift into being presented as a decision. 这是模板设计中最值得借鉴的一点它把不知道变成文档的一等公民让后续所有读者包括 AI 代理都能区分已经定的事和还没定的事。四、五条 Track 与十四章节模板骨架逐章拆解模板将 14 个章节组织为 5 条 Track。以下是每条 Track 的章节、核心产出与关键表格。TRACK A - FOUNDATION必须最先完成1. Programme context and business case项目背景与商业论证1.1 Drivers驱动因素遗留系统生命周期结束、增长、并购整合、合规、成本等1.2 Objectives and success measures可度量的目标与成功指标1.3 Governance and sponsorship治理与出资人1.4 The fixed constraint真正不可动的约束日期/预算/范围/法规1.5 History and prior attempts历史与既往尝试的教训2. Scope ⚑范围2.1 Applications and modules in scope范围内的应用与模块2.2 Legal entity register法人实体登记表EntityCountryFunctional currencyStatutory filingRationale for separate entityWave2.3 Countries and localisations国家与本地化2.4 Explicitly out of scope明确排除的范围2.5 Phasing decision and wave definition分阶段决策与波次定义2.6 Interim-state integration implications中间态集成影响3. Target operating model and process architecture目标运营模式与流程架构3.1 Operating model summary3.2 Process architecture mapped to modules流程到模块的映射3.3 Process ownership流程所有者表End-to-end processBusiness ownerD365 modulesChange from current state3.4 Standard-first posture and gap governance标准优先姿态与差距治理TRACK B - SOLUTION4. Application architecture ⚑应用架构4.1 Application landscape应用全景4.2 Instance strategy单实例 vs 多生产实例决策4.3 ISV registerISV 登记表ISVPurposeOne Version complianceSupport modelContract statusRisk4.4 Power Platform scopePower Platform 职责边界4.5 Logic placement principles逻辑放置原则4.6 Extension governance扩展治理5. Data architecture ⚑数据架构5.1 Chart of accounts design会计科目表设计5.2 Financial dimension design财务维度设计表DimensionMandatoryValues (approx.)Report / decision it servesConsumer5.3 Product model and inventory dimensions产品模型与库存维度5.4 Master data ownership主数据归属矩阵EntityMaster systemOwnerCreation processSync method5.5 Dataverse and dual-write scopeDataverse 与双写范围5.6 Dual-write failure behaviour双写失败行为5.7 Number sequence strategy编号规则策略6. Integration architecture集成架构6.1 Interface inventory接口清单表IDInterfaceSourceTargetDirectionPatternVolume (avg / peak)FrequencyTierOwner6.2 Pattern selection rationale模式选择理由6.3 Middleware strategy中间件策略6.4 Error handling, retry, and idempotency错误处理、重试与幂等性表InterfaceRetry policyPoison handlingIdempotencyAlert destinationReconciliation6.5 Monitoring and ownership监控与归属TRACK C - DATA AND CONTROL7. Data migration ⚑数据迁移7.1 Object scope by class按类别划分对象范围配置/主数据/未结交易/期初余额/历史7.2 Historical data decision历史数据决策7.3 Opening balance strategy期初余额策略总账/应收应付/库存/固定资产/银行等7.4 Data cleansing ownership数据清洗归属7.5 Reconciliation and sign-off model对账与签核模型7.6 Tooling工具选择8. Security, compliance, and licensing安全、合规与许可8.1 Role family design角色族设计8.2 Segregation of duties requirement and authority职责分离要求与授权主体8.3 Compliance and data residency constraints合规与数据驻留约束8.4 Record-level security assessment记录级安全评估即 XDS 需求判断8.5 Indicative licence shape指示性许可形态表Role familyHeadcountIndicative licence typeNotes模板在此处特别加注Indicative only. Verify against the current Dynamics 365 licensing documentation and the clients contracted entitlement.仅为指示性须对照官方许可文档与客户合同权益核验8.6 Access administration and joiner/mover/leaver process入职/调岗/离职访问管理TRACK D - PLATFORM9. Environment strategy and ALM环境策略与应用生命周期管理9.1 Environment topology环境拓扑表EnvironmentTierPurposeOwnerRefresh cadence9.2 Golden configuration approach黄金配置方法9.3 Source control and branching源码控制与分支9.4 Build and release pipelines构建与发布流水线9.5 Service update governance服务更新治理10. Reporting and analytics architecture报表与分析架构10.1 Report inventory报表清单表ReportConsumerDecision it drivesRequired latencyToolOwner10.2 Tool mapping rationale工具映射理由10.3 Analytics platform direction分析平台方向Power BI / Fabric / 既有数仓等10.4 Statutory reporting approach法定报表方法10.5 Post-go-live report ownership上线后报表归属11. Performance, scale, and volumetrics性能、规模与容量11.1 Transaction volumetrics交易量统计表ProcessDaily averageDaily peakMonthly3-year projection11.2 Data volumes and growth数据量及增长11.3 User concurrency profile用户并发画像11.4 Batch windows and hard constraints批处理窗口与硬约束11.5 Performance targets and acceptance thresholds性能目标与验收阈值11.6 Archiving and retention direction归档与保留策略TRACK E - DELIVERY12. Test strategy测试策略12.1 Test levels and ownership单元/功能/集成端到端/UAT/性能/安全/回归/容灾等层级12.2 Traceability approach可追溯性方法12.3 Test data strategy测试数据策略12.4 Regression automation decision回归自动化决策——模板要求量化不自动化的成本每小时循环成本 × 每年更新次数持续累计Include the calculated cost of not automating: hours per cycle x updates per year, ongoing.12.5 Exit criteria by phase各阶段退出标准12.6 Defect severity model缺陷严重级别模型13. Deployment and cutover approach ⚑部署与切换13.1 Deployment approach and wave plan部署方法与波次计划13.2 Cutover window constraint切换窗口约束——模板要求对照实测的全量演练计时来校验窗口Validate the window against measured full-volume dry-run timings.13.3 Parallel running decision并行运行决策13.4 Rollback position回滚位置与不可逆点13.5 Go/no-go authority and criteria framework放行权责与判据框架14. Support and operating model支持与运营模式14.1 Support model and tiersL1/L2/L3、内部/伙伴托管/混合14.2 Hypercare definition and exit criteria重点护航定义与退出标准14.3 Knowledge transfer plan知识转移表CapabilityClient recipientTransfer methodBy when14.4 Post-go-live change process上线后变更流程14.5 Service update ownership服务更新归属附录Appendix A - References参考文献Source / URL / Date checked三列与技能验证纪律呼应——每一项关于 D365 能力的断言都要记录来源与核查日期。Appendix B - Architects notes架构师备注#SectionRecommendationDecision taken insteadRiskAccepted by当你不同意客户的决策时如实记录客户决定同时在此附录写明你的建议与风险不默默绕过、也不拒绝记录。Appendix C - Version history版本历史Version / Date / Sections updated / Author初始版本 0.1。五、章节访谈指南每章的决定/提问/选项/陷阱模板提供了写什么references/section-guide.md 则规定了怎么问。每个章节的条目给出四要素该章决定什么、要问的问题、存在真实架构选择时的选项集、需要警惕的陷阱。技能要求只加载正在进行的章节Load only the sections you are working on避免一次性把二十个问题倒给用户。5.1 关键决策的选项集可直接用于访谈的表格分阶段部署方式Section 2ApproachWorks whenCosts youBig bangScope is compact or highly interdependentHighest single-point cutover risk; no learning between wavesBy geography / legal entityUnits can operate semi-independentlyLonger dual-running and interim integration complexityBy moduleA clear functional sequence is justifiedTemporary integration between D365 and legacy processesPilot then rolloutMany similar entities support a template approachFirst wave absorbs template learning and needs strong governance标准优先姿态Section 3PostureStatementSuitsStrict standardBusiness adapts unless a statutory constraint requires otherwiseCost-led programmes with strong change appetiteStandard with justified exceptionExtensions require a documented business/regulatory reason and named approval authorityMost enterprise implementationsFit to processSystem adapts heavily to existing business processRarely defensible without clear value and lifecycle-cost acceptance逻辑放置层Section 4LayerUse forAvoid whenD365 configurationParameters, workflow, policies, standard behaviourThe requirement genuinely needs new business logicElectronic ReportingDocuments, regulatory formats, file-generation scenariosComplex transactional logicPower PlatformTask apps, approvals, lightweight orchestrationHigh-volume transaction processing requiring ERP consistencyX extensionERP business logic requiring transactional consistencyStandard configuration or lower-code options can meet the needExternal serviceSpecialist domains and decoupled capabilitiesIt creates a platform the organisation cannot operate集成模式Section 6PatternSuitsWatchOData / custom serviceLow-volume synchronous accessThrottling and synchronous couplingData management / recurring integrationBatch and bulk movementLatency, staging, and error handlingBusiness eventsEvent-driven notificationsDuplicate delivery and idempotencyDual-writeNear-real-time FO/Dataverse synchronizationCoupling and failure behaviourService Bus / Logic AppsDecoupling, retry, orchestrationAdditional platform ownership and operationsAnalytics export/Fabric pathReporting and analytics consumptionNot an operational write pattern历史数据处理Section 7ApproachCostConsequenceMigrate detailed historyHighest reconciliation and database costFull in-system historyKeep legacy read-onlyOngoing legacy access costFastest migration, weaker user experienceExtract to archive / analytics storeModerate implementation costOften a strong reporting compromise报表工具映射示例Section 10NeedCandidate approachFinancial statementsFinancial reporting capabilitiesOperational documents and statutory formatsSSRS / Electronic Reporting where applicableOperational enquiryStandard D365 views and workspace capabilitiesCross-functional dashboardsPower BIEnterprise analyticsFabric / governed data platformAd-hoc finance analysisExcel integration where appropriate5.2 每章的核心陷阱访谈时的守门点指南为每章标注了一个陷阱用于防止访谈流于表面章节陷阱1 项目背景依赖没人真正同意做的流程变革的效率型商业论证2 范围 ⚑未经检验就从遗留系统照搬法人实体结构3 运营模式说尽量用标准却没有阈值、审批论坛或拒绝差距的授权4 应用架构 ⚑未检验更新兼容性、支持模型与退出策略就先选 ISV5 数据架构 ⚑脱离成本核算、仓库、质量、报表团队孤立决定产品/库存维度6 集成架构接口清单只按平均量级评估、只设计快乐路径7 数据迁移 ⚑出于习惯而非法律/审计/运营需要迁移历史数据8 安全与许可在角色设计前谈妥许可权益且从不对照实际访问权限复核9 环境与 ALM环境规划只够构建不够迁移演练、UAT、培训、切换并发使用10 报表实时需求未与实际决策节奏挂钩11 性能用年度平均值掩盖真实设计驱动是高峰时段/期末需求12 测试没有回归自动化也没有资助的手工回归能力13 部署切换 ⚑切换窗口基于偏好而非实测的全量迁移计时14 支持运营知识转移计划只写角色/团队名却没有分配具体接收人六、技能运行机制会话、五拍节奏与承重决策6.1 会话编排Session structure技能规定本技能是一场多会话multi-session参与Session 1 - Track A (Foundation). Must be first. Everything depends on it. Session 2 - Tracks B-E in any order the user prefers. Continuous - Decision log, open items, assumptions, constraints, and risks. Final - Consolidation pass and independent review.Track A 必须先完成这并非风格偏好。技能明确解释法人实体结构与分阶段决策会级联影响后面每一个章节。若在 Track B 草拟之后再推翻它们意味着重做架构。Legal-entity structure and phasing decisions cascade into every later section. Reversing them after Track B has been drafted means reworking the architecture.默认节奏下一轮会话只跑一个章节除非用户明确要求加快——价值在于盘问一旦赶进度就会崩塌The value is in the interrogation, and it collapses if you rush.。6.2 五拍节奏Five beats每个章节都遵循相同的五个节拍Frame框定——用两三句话说明本章决定什么、为什么约束后续工作Ask提问——一次只问 35 个问题绝不一次性倾倒二十个问题Propose提议——存在真实架构选择时给出 23 个带权衡的选项并附推荐Record记录——把决策写入决策日志含理由与被否决备选或标记为 OPEN含负责人与日期Draft and save草拟并保存——写出章节、展示给用户、持久化工作文件并更新进度跟踪器。6.3 会话连续性Session continuity工作蓝图是跨会话的持久记录每个会话结束时保存或更新蓝图文件并告知用户当前状态所在文件后续会话开始时先读当前蓝图读进度跟踪器与决策日志确认上次停在哪里、汇总开放项再继续——绝不重问决策日志已回答过的问题若用户恢复时没有工作蓝图副本要求用户提供最新文件而不是凭记忆重建决策。文件名规范为client-solution-blueprint-vN.md随签发或实质性更新递增版本号。6.4 八项承重决策Load-bearing decisions技能从 14 个章节中识别出八项实质上不可逆、或逆转成本极高的决策每项都在 section-guide.md 与 blueprint-template.md 中以⚑标记法人实体结构Section 2——多少个实体、每个实体放什么会计科目表与财务维度设计Section 5——维度数量、强制维度、报表基数单生产实例 vs 多生产实例Section 4部署分阶段Section 2Section 13 复核——大爆炸、按地域、按模块、按法人实体或试点后推广产品与库存维度模型Section 5——存储/跟踪维度、批次/序列、变体策略双写与 Power Platform 范围Section 4 与 5——哪些实体、哪个方向、失败行为扩展姿态Section 4——标准优先的阈值与可批准差距的人历史数据处理Section 7——迁移、遗留只读、或抽取到归档/数据平台。如果用户当次无法拍板其中一项必须做三件事记录为承重开放项load-bearing open item指定决策负责人与开始阻塞的日期明确列出因它而暂定provisional的下游章节。例如Sections 5 and 7 are drafted on the assumption of X. If X changes, both sections require review.——把暂定依赖显式写出来正是模板承重决策未决表Load-bearing decisions outstanding那一列开列受影响的章节的作用。6.5 访谈技巧从需求穿透到选项技能给出的访谈心法是问设计问题 → 深挖其背后的约束 → 揭示客户尚未考虑的选项。举法人实体结构的例子从有多少个法人实体追问驱动它的是什么法定申报、功能货币、管理报表还是历史结构然后指出这三个实体功能货币相同且合并申报考虑过在 D365 中它们是否都需要保持独立法人实体吗——考虑到公司间intercompany的额外开销三条转化规则值得在访谈中复用用户给出解决方案→ 回溯到需求用户给出需求→ 提出选项用户说和现在一样 → 追问这是目标运营模式还是仅仅是现状。6.6 验证纪律Verification discipline在断言D365 是否支持某能力、本地化覆盖了什么、许可允许什么、未来版本会提供什么之前若环境具备文档检索/搜索/MCP 能力必须对照权威 Microsoft 来源核验当前立场优先 Microsoft Learn 与现行 Dynamics 365 发布文档并在蓝图中记录来源与核查日期若当前无法核验则把该陈述标记为待验证而非当作事实。原因正如技能所述蓝图中对标准能力的错误假设会在实施后期变成昂贵的差距。6.7 详细设计边界Detailed-design boundary本技能只拥有蓝图级决策的所有权不应悄悄膨胀成所有详细实施产物的生成器。当讨论进入详细接口规格、角色目录、计时切换 runbook 或正式项目健康评审时若已安装合适的外部专业技能则移交给它同时保留蓝图决策作为治理输入若未安装则停留在架构决策深度明确标识后续详细交付物而不是凭空发明一套完整的下游方法论。6.8 输出与收尾工作会话 → Markdown.md客户分发 → Markdown 或环境支持可靠文档生成时的其他格式文件名 →client-solution-blueprint-vN.md收尾阶段 → 建议对完成的蓝图做独立评审作者不应是自身架构的唯一评审人。技能的基调要求同样值得记录You are in a room with people who know their business better than you do and know Dynamics 365 less well than you do.——解释权衡要用业务后果而非功能术语敢于说我不知道需要让某某进会议室回答绝不用一个貌似合理的假设填充沉默。七、落地建议如何在本仓库中运行这套模板7.1 安装与使用按仓库 docs/README.skills.md 的说明Agent Skills 是自包含文件夹含SKILL.md与捆绑资源遵循 Agent Skills 规范按需加载可通过 GitHub CLI 安装技能需要 GitHub CLI v2.90.0gh skills install github/awesome-copilot d365-solution-blueprint或把技能文件夹手动复制到本地 skills 目录在提示词中引用该技能或让代理自动发现。典型触发场景包括创建 D365 实施架构文档、启动 D365 实施、设计架构、准备 Solution Blueprint、识别项目必须做出的架构决策。技能描述同时声明不用于评审既有设计那是评审任务而非蓝图创作。7.2 从模板到工作文件的最小流程复制 assets/blueprint-template.md 为client-solution-blueprint-v0.1.md填写控制页与进度跟踪器初始状态从 Session 1 开始 Track ASection 1 → 2 → 3每章走完五拍节奏并即时更新跟踪器与决策日志之后按用户偏好进行 Tracks B–E每章加载 references/section-guide.md 中对应条目连续维护决策日志、开放项、假设、约束、风险五个登记册收尾做整合遍consolidation pass并安排独立评审。7.3 模板的使用边界模板是架构决策深度的骨架不是详细设计文档。它不替代接口级规格接口清单只到 inventory 级、角色目录安全章节只到 role family 级、计时切换 runbook切换章节只到窗口约束与 go/no-go 框架级。这是有意为之的边界蓝图保持可独立使用且不过度扩张后续细节交由专门技能或显式标识的后续交付物承接。结语d365-solution-blueprint 技能的价值不在生成文档而在强制一次完整的架构决策过程。其 blueprint-template.md 提供了五 Track、十四章节、五个登记册与三个附录的完整骨架section-guide.md 则给出每章的提问集、选项集与陷阱清单八项⚑承重决策贯穿两文件形成治理锚点。对任何正在启动或设计 Dynamics 365 Finance and Supply Chain Management 实施方案的团队这套模板可直接作为工作坊的记录载体与访谈剧本——它最大的贡献是让诚实的未决事项与被坐实的决策在文档中永远泾渭分明。【免费下载链接】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），仅供参考