自从 Marc Andreesen 高调宣称「软件正在吞噬世界」以来过去了十多年。他是对的。现在，我们处于一个新阶段：到处都是强大的软件，而我们对暴增的不同软件没有太多长远的思考。所以今天，我们面临一个颇具讽刺意味的问题：软件过剩了吗？
我们的「盘子」里肯定装满了可以想象的各种软件应用，而且它们都非常诱人。你知道你曾经注册过多少个应用吗？也许几十个，甚至几百个？在过去 4 年中，每个 Okta 客户部署的平均应用数增加了 22%。与我交谈的 IT 负责人经常开玩笑说，他们的公司拥有的 SaaS 应用程序比员工还要多。
这可能是一个问题，您应该关心这一点。（对软件暴增）放任自流的组织面临三大风险：
成本：随着远程工作成为标准，我们已经看到软件成为许多公司的第二大支出项。但是，多达 25% 的 SaaS 应用和许可证未被使用。如果您公司的前两项开支是人员和技术，那么您就是在其中一项开支上浪费了一大笔钱。
合规风险：要销售基于云的软件或在云中存储客户端数据，您需要成为或保持 SOC2、ISO 27001 甚至 SOX 合规性。将您的公司及其数据视为一座城堡。你需要向审计员证明它受到了很好的保护。现在，将每个应用程序想象成您城堡的窗户、门口、桥梁或入口点。应用程序越多，您从审核员那里收到的审查要求就越多。
运营效率：优秀厨师和世界级厨师的区别在于——他们如何管理员工以处理手头的所有食材。当您的团队使用多种类型的同一应用程序（例如 Monday、Jira、Asana 或 ClickUp）时，他们肯定不会很好地协作。此外，内部客服支持的需求会随着企业应用数量呈指数增长。
尽管如此（为了将食物比喻更进一步），贵公司使用的许多应用程序实际上是构建出色产品的要素。毕竟，建立一家科技公司很复杂。要有效地做到这一点，您需要正确的组件和工具。然而，利用它们的诀窍——成为一家 3 星级的「米其林软件餐厅」——是思考如何巧妙地管理你的所有软件。
实现这一目标、通过技术释放公司全部潜力的一种方法是改变 IT、安全和采购的优先级——这些团队通常关心软件运营。与其让他们解决问题（例如解决 IT 故障修复请求），不如帮助他们创建基础架构，使员工能够自己操作软件并成为自治的劳动力。
但首先：我们是如何走到今天的？当公司生活在 SaaS 上并经历（我开玩笑地称为）「世界末日」的时候？我们「软件成瘾」的原因是什么？
员工使用越来越多的专业应用软件以便取得本职工作的成功。我们过去几乎所有事情都使用 Microsoft 产品。现在，我们使用 Airtable 代替 Excel，使用 Notion 代替 Word，使用 Pitch 代替 PowerPoint。用一些数字来说明我们许多人在日常生活中看到的情况：超过 42% 的 Okta 的 Office365 客户现在也部署了 Zoom，而不仅仅是使用 Microsoft Teams，其中 26% 的人尽管拥有 OneDrive，但也使用 Box。
传统上，企业产品是自上而下销售的：CIO 决定购买 Salesforce 或 Microsoft Office，它们成为整个公司的默认产品。但像 Slack 和 Dropbox 这样的初创公司普及了自下而上的增长模式。如今，67% 的软件开发工具公司（例如 Datadog 或 AWS）都有免费计划或试用版。我们不再需要与销售人员通话或征求 IT 部门的许可——我们只需注册该工具的免费版本即可。
简而言之：应用程序无处不在。但我们做得过火了吗？事实上，我们是否使用了太多的应用程序？我不这么认为。相反，软件可以赋予我们推动业务更快发展的超能力。
拿您驾驶的汽车为例。仅制造一辆汽车就需要 30,000 个零件。但汽车制造商并没有缩减零件数量，而是开发了最有效的汽车组装方法。创新来自他们如何将不同的部分组合在一起。例如，丰田生产系统，也称为「精益制造」，成为丰田的核心竞争优势。一项原则是通过迅速将问题浮出水面来最大限度地减少浪费并不断改进运营。敏捷软件开发和「精益创业」方法受到丰田「构建、测量、学习」系统的启发。
与丰田类似，企业应该思考如何围绕软件改变他们的运营原则，并将其转变为竞争优势。管理技术的传统方法是不够的。公司通常认为集中化是答案，但在这种情况下，事实并非如此。除了安全性和合规性等其它因素之外，还有太多的应用程序需要应对。
1944 年，中央情报局发布了一份关于如何破坏工作场所的指南。第一点是永远不要走捷径，始终走一个集中的「渠道」。想想您上次需要访问应用程序或权限的时间。您必须通过由 IT 工单创建的通道，并且一直在等待。或者您最后一次需要购买新软件是什么时候？您可能需要 2 到 3 个月的时间才能获得购买应用软件所需的所有上级批准。
这就是为什么中心化不起作用的原因，以及为什么修复它的方法可能会错失良机。
超过一半的软件是由不同团队的领域专家采购和管理的——其中许多人只是想获得他们的工具并开始工作。但是，IT、安全或采购等部门需要帮助处理大部分请求。从我们看到的情况来看，40% 到 60% 的 IT 故障单与软件访问问题有关，平均需要大约 19 小时才能解决。员工被困在等待中，而管理员则被诸如创建帐户之类的繁忙工作压垮了。每增加一个应用程序，管理开销就会增加。
公司还集中监督以降低成本、合规性或安全风险。逻辑是合理的，因为员工不应该只是购买重复的软件或获得过多的管理员权限。然而，审查数百个应用程序和数千个帐户无法通过集中式方法进行扩展——它会带来「木桶短板」，员工仍然会在不知情的情况下接收并保留对软件的不必要访问权限。例如，大多数公司中有 25% 或更多的软件未被使用。或者，Segment 的安全团队去年表明，其 669 个管理员角色中有 60% 没有被活跃使用。
通常，运营团队会反对他们没有像其他部门那样有充足的资金，这使得他们的行动比他们实际想要的要慢。那么，我们为什么不随着我们使用的软件数不断增加管理员人数呢？然而，问题恰恰在于这个问题，并且假设问题只能通过集中帮助和监督来解决。这是一个无法扩展的解决方案。
软件管理的集中化是一件奇怪的事情。它试图让事情变得更容易，但不知何故，随着软件数量的增加，它让每个人的事情变得更糟。那么，我们如何重新构想关心软件运营（即 IT、安全和采购）团队的角色？
让我们面对现实吧：员工几乎总是会选择最容易实现价值的途径。如果您管理软件的方法仍然集中并存在许多瓶颈，那么员工将继续通过秘密购买软件等事情来应对您的政策。这是一个恶性循环。为了让许多人采取负责任的行动——并改变 IT/安全/采购与组织其它部门之间的关系——合规路径需要成为最方便的路径。
只有当我们将控制权和责任交还给员工及其团队时，才能解决这种复杂性。你（作为 IT 部门领导）不是给人们食物，而是教人们如何做饭而不烧伤自己的人。基本上，我们的目标是找到一种使激励措施保持一致的方式，以便以最具成本效益和最安全的方式做事的员工，也能最快地解决他们自己的问题。
在购买食物和汽油时，我们已经习惯于自己动手——甚至是办理登机手续——那么为什么不管理企业软件呢？与其向 IT 寻求支持（或像 CIA 在其工作场所破坏指南中所描述的那样通过统一「渠道」工作），IT 可以使员工能够快速、负责任地自助管理企业软件。安全、采购和 IT 不是集中执行部门，而是需要成为公司内部平台，为员工提供正确的基础设施。
（工作流）自动化很棒，但它需要集中支持，并且无法与数百个应用软件一起扩展。
采用自治的流程和结构是一个需要解决的重要问题，因为它直接影响（企业软件管制）底线。不专注于从系统集中演变为自助服务的组织，可能会在未使用的软件上浪费大量资金，阻碍下一次合规审计，并导致整个组织运行效率低下。改变组织的工作方式是领导力的首要任务，因此，它可以通过战略性地使用第三方软件来释放其全部潜力，而不是被它们淹没。
公司应该问自己的问题是：如何在尽可能多的方面实现（企业软件）自助服务。例如：
一旦 IT 部围绕谁应该批准哪个软件创建工作流，员工就可以在没有 IT 帮助的情况下请求应用、权限、内部工具甚至开发人员资源。
如果采购部门围绕谁需要批准购买什么类型的软件建立一个系统，那么员工可以继续使用该自助服务系统。
如果安全部门实施了一种仅在特定时间窗口内授予对敏感应用程序或权限的访问权限的方法，他们就不需要一直集中审查员工的访问权限。
所有这些例子都展示了软件运营团队的角色可以如何改变：他们可以专注于以正确的方式对系统进行梳理，并在此过程中指导整个组织，而不是解决内部技术支持或处理告警事件。除此之外，通过自治的工作团队改变技术管理的另一种方法是：鼓励组织中的所有团队领导将自助服务纳入他们的 OKR 或 V2MOM 流程。
例如，IT 通常的目标是通过自动化减少运营人员需求。自动化很棒，但它需要集中支持，并且无法与数百个应用程序一起扩展。相反，IT 可以尝试通过自助服务来减少运营人员的需求。或者，IT 有时会增加一个目标，即减少响应工单所需的时间。同样，这个目标是在需要集中帮助的假设下制定的。相反，请尝试添加一个目标，以减少不需要 IT 支持人员亲自动手处理请求比例。
多达 25% 的 SaaS 应用和许可证未使用。如果您公司的前两项开支是人员和技术，那么您就是在其中一项开支上浪费了一大笔钱。
（企业软件管理）自治也可以从减少 SaaS 支出的小练习开始。集中管理数百家供应商是不可能的，但它可能会做一些简单的事情，比如向每个 Outreach.io 或 Smartsheet 用户发送一封电子邮件，说明您正在努力节省软件支出。如果他们不再使用该软件，请请求
加载中,请稍侯......