这需要一种快速知识捕获方法，平衡结构化的架构规范与加速的人种学研究技术。该方法集中于通过协作工作坊，利用能力映射框架来外化隐性知识。分析师必须同时对系统接触点进行逆向工程，以验证假设的价值流与实际交易数据之间的一致性。这种双轨方法确保文档化的能力反映了专家证词与系统现实的客观数据。
我被聘请分析一家中型物流公司，该公司正被全球第三方物流供应商收购。目标公司已经以口头传统为基础运营了20年。其所有客户入职逻辑只存在于两位在10天内退休的运营经理的脑中。收购方的 ArchiMate 企业架构要求能力分解到3级粒度。然而，虚拟数据室在72小时内根据 NDA 条款关闭。
我们考虑进行专家的一对一面谈，并录制会议以便后续抄写。这将获得深入的背景理解，并允许进行详细询问。然而，这种方法需要至少5-7天的时间来涵盖所有40个关键能力。这没有留下验证或对照 SAP ERP 交易日志的缓冲时间。在没有实时协调的情况下，两位专家之间的解释冲突风险仍然很高。
我们选择进行了12小时的并行强化工作坊，使用预填充的 TOGAF 能力模板的 Miro 白板。这迫使专家之间实时达成共识，同时将他们的陈述与来自遗留 AS/400 数据库的 SQL 查询结果进行交叉验证。这对声称的流程步骤与实际数据流进行了立即验证。这种方法对参与者来说是疲惫的，但确保了隐性知识在48小时内被外化和验证。
我们成功记录了38个所需能力的完整 ArchiMate 关系。其余两个能力被标记为高风险知识缺口。这使收购方能够协商出价降低15%，以应对未来流程重新设计的成本。在数据室关闭前，架构团队获得了足够的细节以开始在 ServiceNow 仓库中进行整合规划。
问题1：当主题专家故意模糊流程以保护工作安全时，您如何验证业务能力？
这需要通过比较专家证词与系统日志、实物文档以及输出成果的三角校验技巧。当专家抵制文档记录时，实施“流程排练”会议，让他们必须在叙述决策的同时演示工作流程。这有效地绕过了他们抽象或省略步骤的能力。通过交叉验证 Salesforce 案例历史或 Oracle 工作流引擎中的时间戳，验证声称的周期时间和决策分支。这创造了一条审计线索，揭示他们叙述中的空白，而不需要直接对抗。
问题2：企业架构中业务能力与业务流程的关键区别是什么，混淆它们为何会导致整合失败？
业务能力表示组织实现特定结果的能力，无论流程变化或技术转变都保持稳定。例如，“客户信用评估”无论是通过手动 Excel 审核还是自动化的 AI 风险评分进行，都是存在的。业务流程描述实现该能力的特定活动流程。混淆二者会导致刚性的整合，当目标公司修改其工作流程时就会中断。基于能力的规划使收购方能够替代流程，同时保持战略功能。
问题3：当没有文档存在，且原始开发人员不可用时，您如何处理嵌入遗留代码中的隐性业务规则？
采用代码考古学与输出分析相结合的方法。从 COBOL 复本、 PL/SQL 包或 Java 类等库中提取可执行逻辑。通过系统输入样本以观察输出，并使用决策表重构逆向工程条件逻辑。将这些发现与当前状态流程观察进行相关性分析。当代码行为与陈述的业务规则相矛盾时，将此代码视为合规目的的真实依据，并将其记录为“发现的约束”，而不是意图要求。