技术决策。
业务后果。

技术路线图可能会很忙而无法推进业务。我们从重要的客户旅程、运营限制和战略选择开始，然后确定支持它们所需的能力。该战略明确了权衡：保留什么、改变什么以及停止什么。

竞争项目经常使用不同的假设，忽略运营成本或依赖相同的稀缺团队。我们创建一个共同的比较基础，包括价值、风险、准备情况、总成本和交付所需的能力。强制性工作仍然是明确的，而不是隐藏在商业乐谱中。

应用程序、数据、基础设施和供应商通过业务流程连接起来。局部改进可能会引入重复记录、另一次集成或昂贵的依赖项。架构必须以业务和交付团队可以使用的方式解释这些后果。

较旧的管理、银行和企业系统通常保存多年的规则、记录和批次依赖性。更换屏幕并不会消除这些依赖性。在决定保留、公开、重构或替换哪些组件之前，我们会调查现有服务的行为。

一系列演示并不能建立企业人工智能能力。我们评估完整的工作流程、他们使用的数据的质量和权威、代理可能采取的行动以及必须审查例外情况的人员。采用包括评估、审查和持续运营的成本。

冲突的定义和延迟的协调会在运营、财务和人工智能之间造成摩擦。仅靠一个新平台并不能解决谁拥有数据、哪个来源是权威的或者应该如何计算指标。我们将架构与管理及其支持的业务决策联系起来。

基础设施整合和云迁移可以转移成本，而不是消除成本。我们评估应用程序的适用性、利用率、连接性、许可、支持和弹性以及消耗。只有当成本可以消除或产能可以投入有用的工作时，节省才变得可信。

项目可能会完成，但业务成果仍然无人拥有。我们围绕持久能力将业务产品所有权、工程、数据、安全和服务运营联系起来。资金和治理应支持学习和受控交付，并在优先事项发生冲突时明显升级。

有竞争力的购买价格可能会掩盖集成工作、限制性数据访问、续订风险或昂贵的退出。我们研究拟议的供应商如何适应企业的架构、服务职责和未来选择。

合并和分立将业务期限与不确定的库存、重复申请和临时服务安排结合在一起。当数据协调、访问更改和运营支持被视为次要工作时，集成成本很容易被低估。

现代化必须保持业务承诺，同时减少脆弱性。我们将可用性、恢复、网络风险和供应商依赖性与其支持的服务联系起来。可用的应用程序并不证明客户旅程或报告流程可以完成。

技术价值取决于实际行为和工作实践的变化。如果团队还必须维护旧流程，新工具可能会增加工作量。我们定义将实施转化为持续成果所需的角色转变、学习支持和流程退役。