几周前我在旧金山参加了Jenkins World。突出的一点是CloudBees倡导新的市场概念，即软件交付管理(SDM)。CloudBees提供以下SDM定义：

软件交付管理可帮助组织简化CI / CD流程，促进软件开发和交付所涉及的所有功能之间的有意义协作。其目的是提高软件交付速度，质量，可预测性和价值，从而提高客户和用户的满意度并获得更好的业务成果。

似乎是一套合理的目标。正如CloudBees所描述的那样，SDM与价值流管理 (VSM)类似 。然而，在分析师的(记录中)简报中，CloudBees真正引起了我的注意，它将SDM愿景与企业资源规划(ERP)供应商SAP进行了比较。

树液?对于DevOps社区中的许多人来说，这可能会令人惊讶。但是，这对我来说非常有意义。

我一直想知道：大多数高级管理人员都得到SAP和Oracle等ERP供应商的良好服务。为什么不是世界的CIO?为什么他们的工具如此分散?鞋匠为什么赤脚走路?这不是一个新问题，也不是一个新的品牌推广理念。各种IT服务管理(ITSM)供应商已经尝试过“ERP for IT”消息传递，但没有太多牵引力。为什么不?SDM可能有什么不同?

我认为ITSM供应商面临的最大问题是它们是在数字价值流的最后阶段开始的，在运营和支持阶段，当软件开发中更难和更有价值的方面是上游时。

在持续交付之前，上游是一个项目管理的世界，其中(通常)构建和部署工具链对于每个项目是唯一的。现在，该行业对于跨越项目(越来越多地转变为稳态产品)的持续交付概念架构抱有坚定的愿景 。[i] 故事，提交，构建，打包，提供，部署，运营 - 这里深化的，DevOps驱动的行业共识向前迈出了一大步，很可能是“这一次有什么不同”。

但是，我们可以用这个统一的“数字供应链”数据做些什么呢?Magic不会因为我们将数据集成到公共存储库中而发生。这是 货物崇拜的思想。我们需要明确的用例。ERP系统及其MRP(材料需求计划)前身的目的非常明确 - 例如，通过更好的订单调度，通过重要因素降低库存持有成本。SDM需要进一步阐明这些好处。

我们能否减少库存(即Don Reinertsen称之为“过程中的设计”的无形库存)?[ii] 更好，更快地识别约束和瓶颈，例如在合适的时间没有足够的技能?加快上市速度?修剪产品选项更快?提高我们的学习速度?减少运营或改变风险?更快恢复服务? 这些新信息的可用性如何实现这些价值主张?我们可以为它做一个经济案例吗?

似乎那里应该有价值。但“看起来似乎应该”不是商业案例，我认为澄清价值的视线是一个优先事项。我目前的假设是，我们将通过构建模拟取得更大的进展，而不是试图通过分析解决数字管道的问题。