关于作者 马克 施瓦茨是 Amazon Web Services 的企业策略家，也是The Art of Business Value和 A Seat at the Table: IT Leadership in the Age of Agility 的作者。
过去这二十年，IT 行业推出了多种新的工作方式，目的是帮助客户更快、更好地实现业务价值，同时降低风险。
当然，这些技术与 IT 中的所有内容一样有着术语：这里的关键词是敏捷、精益和开发运营。遗憾的是，这些技术通常以 IT 为重点，对企业带来的利益却不明确。他们甚至看似会破坏首席财务官或首席执行官监督 IT 相关计划的能力。
随着首席财务官的角色不断扩大，新技术的采用对于提供业务价值变得至关重要。本文展示敏捷、精益和 DevOps如何简化数字交付、促进创新，并让企业更加敏捷。以上方法很可能是自电子表格发明以来对于首席财务官而言最棒的事情：帮助他们提高回报、监督投资、实施控制、获取透明度、为企业提供更好的数据，当然还有管理成本。
精益
精益 IT 交付基于与精益生产和精益六西格玛相同的概念。这些概念均来自作为先驱的丰田生产系统。总的来说，精益就是通过集中精力缩短交货时间来消除浪费现象。当一家企业采用精益的观点时，它会绘制出价值交付的的整个流程，并检查其中每个步骤，以找出使流程花费不必要时间的浪费因素。通过消除各种类型的浪费，企业可以缩短交付周期并降低成本。精益运作的方法适用于 IT 产品的制造与交付。不过，IT 必须被视为一种产品开发过程，而不是制造过程（即每次运作时都拥有不同的运行过程）。出于这个原因，试图减少方差的六西格玛技术通常不适用。但与其他业务流程一样，交付 IT 产品及功能会涉及一系列的步骤，而每个步骤通常都包含浪费。IT 流程中的典型浪费来源与制造流程中的浪费种类非常相似。
作者 Mary 和Tom Poppendieck 蘒已将其确定为：部分完成的工作、额外流程、额外功能、任务切换、等待、动态和缺陷。
为什么消除浪费和缩短 IT 交付的交付周期如此重要？一个明显的原因是缩短产品上市的用时，或者对于内部使用来说，缩短从投资中获得价值的时间。另一个原因是：速度有助于确保 IT 功能尽可能高效。IT 团队现在可以快速地向用户提供最低的可行产品，检查以确保它们如设计般运行，然后继续添加功能或进行更改。业务敏捷性源自业务处理速度，越快越敏捷。由于功能不断地在完善，IT 能够在不浪费任何先前工作的情况下转向并处理其他更重要的任务。最后，速度降低风险，因为公司一来可以快速解决无法预料的事件，二来降低了 IT 能力交付的风险。
交付 IT 能力的价值工作流在每个组织中都是不同的，但通常包括以下步骤：业务需求得到认可和表达，编写需求，根据需求创建计划，准备业务计划，治理流程被用在业务计划上，获取资源，开发软件，测试软件，验证安全性，部署软件，将软件知识传递给用户，至此这一能力得以实现。这是一个漫长的过程 - 它可能隐藏大量的浪费。大部分流程（以及浪费的可能性）超出了 IT 组织的直接控制范围，或者由该组织与其他业务部门共同控制。
通过仔细研究由精益软件交付技术支配的流程，会对业务成效产生重大影响。
敏捷
敏捷 IT 交付基于一个简单的原则：在复杂的环境中（当然，IT 交付的环境必然是复杂的），学习和调整比严格遵循事先制定的计划更好。（待会儿我会解释这与精益有什么关系）。
不再一味遵循既定计划可能听起来风险很大。
这种想法让团队似乎无法控制并且不可能让有关员工承担责任。但事实上并非如此。它通过不同寻常的机制得到了严格的控制。
有时，我会将敏捷技术想象成风险缓解能力。如果我们制定一个详细的计划，比方说一个为期三年的项目，然后尝试去实施它，我们同时等于在接受一些大的风险，特别是：
1. 计划会出差错的风险。
2. 各种条件在项目期间会产生变化的风险。
3. 三年后产品不能及时完成的风险。
在传统的 IT 交付方式（所谓的瀑布式或执着于甘特图式的方法）中，产品直到项目结束才交付。因此整笔投资金额都冒着风险，直到三年后项目结束后，结果才会明了（或者没有结果）。
这些风险到底有多严重？答案是：非常严重。
· 正如我们在数十年的经验中所发现的那样，IT 系统的详细计划总是错误的。研究还表明，IT 产品/系统被要求的功能中有一半以上很少或从未被使用过。即使一切都按计划交付，它仍然可能无法满足原本的业务需求。
· 我们预计三年之间的变化量取决于业务和技术环境的不确定性，而我们恰好处于快速变化和高度不确定的时期。在三年的时间里，随着各类创业公司的创立，各行各业都会受到不同程度的影响。敏捷性是企业应对变化的能力，与坚持计划相反，却极具价值。
· 微软的一项研究表明，只有三分之一的想法实际获得了预期的结果，另外三分之一具有相反的效果，而另外三分之一则没有任何效果。我们都曾看到应该降低成本但却没有成功的 IT 系统，或者本来应该增加收入但却无功而返的情况。另一项研究发现，公司每年用于无法实现预期回报的计划的浪费有近 4000 亿美元。
·大量研究表明，IT 项目越大，无法交付的风险就越高。短暂的工作增量更有可能实现其目标，并且更可预测。
而敏捷交付方式则采用不断学习和调整的做法，由多个小周期配合完成产品的研发，并最终提供给用户以获得反馈。它由多个小型、自主、独立的团队实施，可以轻装上阵快速学习和调整。由于敏捷团队正在努力快速地完成产品，因此将敏捷原则与精益实践相结合是很自然的。这种实践专注于缩短周期时间。两者的结合为企业提供了敏捷性、风险缓解和成本效益。
开发运营
在精益理论中，两个重要的浪费来源是交接（动态和等待）和大批量。传统的 IT 实践基于部署产品的各部门交接各自的开发、测试和运营成果。DevOps 是精益和敏捷 IT 领域最先进的一套实践。它通过将开发、测试和操作技能结合在一个对整体结果负责的小团队中来解决这些问题。
IT 中的大批量意味着大量的需求。开发运营团队一次只处理一小组需求，使用高度自动化的流程快速向用户部署功能，然后再转向另一小组需求。因此，开发运营团队经常部署代码 - 有时在一天内会部署数百或数千次。
开发运营中大量使用自动化有利于控制和合规。许多本来可以手动操作的组织级控制方式现在可以自动实施，它们更为可靠、更容易记录，从而可以连续使用，而不是定期使用。
开发运营是培养创新的绝佳方式。有了它，公司可以快速、低成本、低风险地测试新点子。在云中工作可以增强这些优势：公司可以当下立即配置基础架构，然后在稍后的时段再取消配置。需要企业很长时间才能构建的 IT 功能可以作为预先创建好的基础数据块，并纳入实验。
精益、敏捷和 DevOps 的商业效应
· 快速推向市场或使内部使用产品更快体验其价值
· 不再产生不需要的功能，从而减少浪费
· 减少产生无法实现目标所带来的浪费
· 减少流程浪费（IT 内部和外部）
· 降低风险
· 增加创新
· 通过自动化改善操作控制
让我们回到控制问题。在监督 IT 计划的传统方法中，治理主要是一个前期面临的问题：一旦做出决定/不通过决策，监督员通常不再参与过程，除非项目违反阈值或发生一些特定的重大事件。
这是一个独立的监督过程。它每隔一段时间会突然出现，但除此以外不复存在。敏捷的方法则拥有持续的监督和透明度。项目团队经常交付，结果显而易见。由于流程的灵活性，监督机构可以随时选择改变方向，结束投资，增加投资或用其他目标以代之。
通过敏捷流程，企业可以修复并遵守计划或预算，它只需修改项目范围即可满足时间或预算的需要。我建议将大多数的费用类别固定下来，就像做预算一样。预算会限制组织单位在单个预算周期内可以执行的操作 - 一旦您的预算用完，您就会停止支出。所谓的 “要求” 也是如此。（我说“所谓的”，因为它们并非必需的功能，且受预算可用性限制。） 但如果在敏捷 IT 项目期间资金耗尽，项目不会遭受任何损失，因为已经完成的产品是可用的。实际上，即使仍有预算，也可以根据不断变化的优先事项或因为已经取得足够的成功而提前停止该项目。企业也可以有意识地决定增加预算以实现剩余的功能。“敏捷” 是一个持续的投资过程，是公司每时每刻（有效地）重新计算业务案例的方法。
敏捷方法是高度重视在获取信息时调整计划，而不是一味的跟着原计划走。但这不意味它不受控制。我认为它受到业务目标符合性的控制。随着项目的进展，各项功能的推出，在衡量业务影响后，项目将会根据对预期目标的影响进行调整。目标是从任何投资中获得最佳回报。
但是此时大家必须对 “回报” 的定义达成一致。它是节省成本吗？还是增加收入？是提供更好的客户服务吗？还是长期的灵活性？
它们都是合理的回报。另一方面，满足项目开始时指定的所有要求不是真正的业务目标；构建一组特定的功能也不是。一个健康的项目是满足其目标的项目，而不是满足其所有要求的项目。鉴于现实，它应该不断调整，以便最好地实现这些目标。
首席财务官应该像首席信息官一样对这些新的 IT 方法感到振奋。它们利用 IT 工具现有的功能，为企业提供更好的绩效。
联系客服
