作者归档：admin

连接 SaaS 产品的未来：Salesforce API的演变之路

发表回复

前面我们聊了 Saleforce 关于开放能力的演化，今天我们聚焦聊一下 SaaS 产品 API 的开放。

因为 Salesforce 在 API 开放接口方面的发展历史反映了其作为一个 SaaS 平台不断演进的过程，以适应不同的集成需求和技术标准。

以下是 Salesforce API 的发展历史的概述，以及每种API解决的问题和它们的价值：

Salesforce API 发展历史

Salesforce Web Services API (早期的SOAP API)

Salesforce 最初的 API 是基于 SOAP（Simple Object Access Protocol）的 Web Services  API。

这个 API 自 Salesforce 平台在 2000 年代初推出之初就存在，它允许开发者通过网络进行远程调用，与 Salesforce 的数据进行交互。

SOAP API 允许企业和开发者在各种编程环境中利用 Salesforce 数据，为客户提供定制化的解决方案。

它使得 Salesforce 不仅是一个 CRM 产品，同时也是一个可以集成到企业 IT 环境中的平台。

尽管功能强大，但 SOAP 协议相对复杂，对网络带宽和处理能力有较高要求。

Salesforce REST API

随着 Web 2.0 概念的普及，RESTful 架构开始流行。它基于 HTTP 标准协议，使得 API 更简单、更易于使用，并且更加高效。

这种架构风格通过使用 GET、POST、PUT、DELETE 等 HTTP 方法来操作网络资源，简化了 Web 服务的实现。

在这样的背景下，Salesforce 在 2010 年左右，随着 Winter ’11 发布，推出了自己的 REST API，提供了一个更加轻量级和灵活的接口。

REST API 满足日益增长的轻量级集成需求，使得移动应用程序和现代 Web 应用程序可以更容易地与 Salesforce 平台集成。

Bulk API

随着企业对 CRM 系统的依赖程度日益增加，Salesforce 客户发现自己需要处理的数据量也在不断上升。这就带来了一个问题：如何高效地在 Salesforce 平台上进行大批量数据的导入、导出和更新。

尽管 Salesforce 提供了标准的 API，如 REST API，但这些 API 在设计时更侧重于在线实时交互和小批量数据处理。因此，它们在处理大量数据时可能会受到性能瓶颈和 API 调用次数限制的影响。

为了解决这些限制，Salesforce 引入了 Bulk API。

Bulk API 是一种基于 REST 原则的 API。

Bulk API 的设计意义在于它能允许开发者和管理员高效、快速地在 Salesforce 平台上导入、导出和更新大量数据。这种专为大规模数据处理量身定制的 API，解决了传统 API 在性能和调用次数上的限制，提升了数据管理的可行性和灵活性。

Bulk API 通过其异步执行的特点，优化了对系统资源的利用。它可以在服务器资源空闲的情况下处理请求，避免了同步处理可能导致的资源瓶颈，从而加速了数据处理操作，并提高了整体性能。

Bulk API 的使用极大地提高了开发者和管理员在数据迁移和大规模数据更新时的生产力。通过减少手动操作和等待时间，Bulk API 使得数据管理工作更加高效，从而节省时间和成本。

Streaming API

随着企业转向更加动态的业务操作，对实时数据同步的需求日益增长。企业需要一种机制来实时监控和响应数据的变更，以提高业务的响应速度和决策质量。

在实时数据同步的早期实现中，开发者通常使用轮询（polling）方法定期检查数据变化。这种方法不仅效率低，还会对系统产生不必要的负载，特别是当数据量大、变更频繁时。

为了解决轮询的问题，推送（push）技术逐渐兴起。与轮询不同，推送技术能够在数据发生变化时立即通知监听者，这样可以大大减少不必要的数据检查和网络负载。

Salesforce 顺应这一趋势，在 2011 年左右引入了 Streaming API，它是一种基于推送技术的服务，允许客户端订阅一个主题，当该主题下的记录发生变化时，Salesforce 会实时推送更新。

Streaming API 对 Salesforce 生态具有重要意义，因为它支持实时响应数据变更，减少了资源消耗，并通过实时数据更新提高了用户体验。此外，它促进了事件驱动架构的发展，使得系统更加模块化、易于扩展和维护。

随着时间的推移，Salesforce 不断扩展 Streaming API 的功能，引入了平台事件、推送主题等特性，增强了其处理复杂事件的能力，满足了企业对多样化事件处理和实时数据集成的需求。

同时，它实现了业务流程自动化，如及时的库存更新和客户通知，同时支持了将 Salesforce 数据实时集成到外部系统中，提升了整个组织的信息共享速度。

Metadata API 和 Tooling API

Salesforce Metadata API 的出现是为了满足开发者和管理员对于更高效、可编程方式来管理 Salesforce 配置的需求。在 Salesforce 平台日益成熟和客户需求变得更加复杂的背景下，手动通过用户界面进行配置管理变得不切实际，尤其是在需要在多个环境之间迁移和同步大量配置信息的情况下。Metadata API 提供了一个可以通过代码自动化管理（检索、部署、更新）Salesforce 配置的途径，这对于加快开发过程、提高准确性和配置的可管理性至关重要。

Metadata API 在 Salesforce 配置和部署自动化方面发挥了巨大作用。它使得配置可以像代码一样进行版本控制和回滚，支持了持续集成和持续部署（CI/CD）流程，从而实现了敏捷开发和 DevOps 实践。此外， API 支持大规模部署和管理，特别适合于大型企业和多环境配置。它还使得开发者能够编写脚本来自动化常见的维护任务，比如备份配置和监控组织中的变更。

Tooling API 是 Salesforce 在 2013 年为了进一步提升开发者体验而推出的。随着开发者社区的成长，对于更细粒度控制、更灵活的开发工具和更快的迭代周期的需求增加了。Tooling API 应运而生，旨在为开发者提供一种能够更加便捷地访问 Salesforce 开发工具的编程方法。通过 Tooling API，开发者能够访问 Salesforce 内部使用的开发工具，从而进行更加高效的代码编译、测试和调试。

Tooling API 允许开发者以编程方式执行他们在 Salesforce 开发环境中常做的操作，如查询、修改、部署源代码和元数据。它提供了更快速的交互，特别是对于源代码编辑、调试和测试非常有帮助。Tooling API 也支持开发者创建更丰富的开发工具和 IDE 插件，从而提高了生产力和协作效率。此外，它使得开发者能够构建更加复杂和强大的自动化脚本和应用程序来与 Salesforce 环境交互。

Metadata API 和 Tooling API 都为 Salesforce 的配置和开发提供了自动化和程序化的能力，但它们的关注点和优化点略有不同。Metadata API 更侧重于整体的配置管理和部署，强调元数据的大规模处理。而 Tooling API 则专注于提升开发体验，优化细粒度操作，如源代码的编辑、部署和调试。

共同地，这两个 API 为Salesforce 生态系统内的自动化、集成和开发提供了全面的支持，极大地提升了开发者和管理员的工作效率。

随着 Salesforce 平台的不断扩展，这些 API 继续得到改进，并有新的 API 加入，以保持与新技术的同步和满足不断变化的业务需求。每个 API 的发布都围绕着提升开发者和最终用户的体验，增强 Salesforce 平台的功能以及其与其他系统的集成能力。

SaaS 产品 API 的作用分类

通过 Salesforce 的 API，我们大致可以将 SaaS 产品 API 的作用分为以下三类：

数据 API

数据 API 管理着 SaaS 产品的核心资产——数据。它们提供了一种方式，可以查询（阅读）、更新（编辑）、删除（移除）或者创建（新增）数据。

通过数据 API，SaaS 产品不仅打破了数据孤岛，还提供了一个强大的接口，使得企业能够流畅地访问、管理和操作存储在云中的关键数据。这些 API 将企业内部的各种系统连接起来，实现了前所未有的数据整合和自动化水平。

数据 API 的真正价值在于它们所带来的无缝集成能力。企业可以利用这些 API 从 SaaS 平台中提取所需数据，并将其推送到其他应用中，如 CRM、ERP 或自定义的内部系统。这种集成为业务流程打开了新的可能，从简单的数据同步到复杂的多系统协作，都能通过编程方式高效实现。

此外，数据 API 为数据的实时访问和分析铺平了道路，使得企业能够根据最新的信息做出快速决策。随着大数据和人工智能技术的不断进步，数据 API 成为了企业获取洞察力、优化运营和增强客户体验的重要工具。

功能 API

功能 API 使开发者能够利用 SaaS 产品的内置功能，其本质上是功能的复用和开放，如流程自动化、任务管理和用户界面定制等。这类 API 可以使开发者无需从头开始构建复杂的系统功能，而是可以直接集成和扩展现有的强大功能。

功能 API 是 SaaS 平台的实用魔杖，它们让开发者能够将 SaaS 产品的强大功能轻易嵌入到他们的应用程序中。这些 API 如同构建块，帮助开发者在不重复发明轮子的情况下，快速构建复杂的功能。它们消除了许多通用任务的复杂性，从而加速了新应用的开发和现有应用的迭代。

在竞争激烈的市场中，功能 API 的灵活性成为了 SaaS 产品的一个重要竞争优势。它们使得 SaaS 解决方案可以轻松集成到业务流程中，为用户提供了无缝、定制化的工作流程。因此，功能 API 是创新和效率的催化剂，为企业提供了迅速适应变化和市场需求的能力。

开发 API

开发 API 设计用来增强开发者与 SaaS 产品之间的交互，让他们能够更深入地定制和扩展产品功能。这些 API 提供了工具和接口，以便开发者可以构建自定义的应用程序、集成其他服务、自动化开发流程，以及管理和监控 SaaS 产品的实例。

开发 API 是企业技术创新的关键驱动力。 它们让开发者能够利用 SaaS 产品提供的强大引擎，定制符合企业特定业务需求的解决方案。通过使用开发 API，企业可以扩展产品的功能，增加新的服务和能力，同时保持产品的核心稳定和安全。

开发 API 还允许企业通过编程方式控制产品的部署、配置和管理。这意味着企业可以自动化常规任务，提高效率，减少人为错误，同时确保一致性和合规性。

开发 API 还促进了开发社区的形成，开发者可以共享他们的扩展和集成，进一步丰富了 SaaS 产品的生态系统。这种协作和共享的文化不仅加速了创新，还为企业带来了解决问题的新思路。

总的来说，开发 API 提供了定制化和扩展性， 这对于企业在不断变化的技术环境中保持竞争力至关重要。

这三种分类覆盖了一个 SaaS 产品从数据管理到功能集成，再到开发和定制的全方位服务，为企业提供了丰富的工具来构建、扩展和优化其业务流程和客户体验。

小结

在 SaaS 领域，开放 API 的战略价值在于它能够加速产品的市场渗透，通过允许第三方创新来增加产品的吸引力和竞争力。

开放 API 也是一种商业模式，它可以将 SaaS 产品从单一的解决方案转变为一个平台，促进合作伙伴和开发者在此基础上构建自己的产品和服务。这样的平台策略可以极大地增加 SaaS 产品的市场影响力，通过网络效应增强产品的价值。

此外，通过 API 提供的数据和功能，SaaS 提供商可以开发新的收入来源，例如数据分析服务、额外的集成功能或定制应用。

在一个以客户为中心的商业环境中，API 的开放性和互操作性是构建强大生态系统的关键。通过 API，企业可以构建一个围绕客户需求设计的平台，从而更好地服务客户并提供更加个性化的体验。API 战略的成功实施，可以成为企业获得竞争优势、加速创新和实现可持续增长的重要驱动力。

API 不仅仅是技术上的桥梁，它们代表了一种业务战略，使得企业能够快速适应市场变化，创新其产品和服务。 API 使企业能够以更加敏捷和成本效益的方式进行扩张，实现全新的商业模式，比如将服务转变为可通过 API 访问的微服务。API 经济正在改变企业与合作伙伴、供应商和客户的互动方式，为创造新的收入流打开了大门。

从 Salesforce 看 SaaS 产品开放能力的演化

发表回复

在当今快速变化的软件行业中，SaaS（Software as a Service）模式因其灵活性、可扩展性和成本效益而广受欢迎。

作为这个领域的先驱之一，Salesforce 不仅仅是一个 CRM 工具，它通过不断扩展其开放能力，已经成为了一种全方位的商业解决方案平台。

通过观察 Salesforce 的发展，我们可以清晰地看到 SaaS 产品开放能力的演化路径，以及这种演化过程给技术和商业带来的机遇与挑战。

以下为 Salesforce 的开放能力的演化过程。

SalesForce 开放能力的时间线

我们先从时间线来看 SalesForce 在开放能力上所做的事情。

2000 年： API 接口

Salesforce 最初作为一款 CRM 软件服务亮相，在 2000 年代初期，它引入了 API 接口，允许第三方应用程序与 Salesforce 集成。

Salesforce 提供了基本的 API，允许用户读取和更新其 CRM 数据。

随着时间的发展，Salesforce 推出了更加强大和灵活的 API，例如 REST API、 Bulk API、Streaming API 等，这些 API 支持更大规模的数据操作和更复杂的交互。

2005 年：Salesforce AppExchange

2005 年，Salesforce 推出了 AppExchange，这是一个企业应用市场，允许第三方开发者创建和销售与 Salesforce 产品集成的应用程序。这极大地推动了 Salesforce 的开放能力和生态系统的成长。

到 2012 年，AppExchange 平台上总共的应用数量也才两千多个，但到 2013 年，就已经有超过 400 个应用加入，其中还包括诸如 Dropbox、Evernote 这些知名的从消费者市场起家的明星产品。

从 0 到一百万的下载量，耗费了 AppExchange 平台的五年时间，但是 2013 年的总下载量已经达到了两百万。

在过去的几年里，AppExchange 经历了显著的增长，不仅在应用数量上，还包括了解决方案、组件、库和咨询合作伙伴的列表。

到 2023 年，根据公开的报告和官方数据，AppExchange上的应用数量已达到数千个，涵盖了从小型企业到大型企业不同规模的业务需求。

这些应用包括各种各样的解决方案，如销售自动化、客户服务、市场营销自动化、人力资源管理、财务管理等，以及行业特定的解决方案，如医疗保健、金融服务和零售。

2007～2008年：Force.com 平台推出及开发者工具和社区

在 2007 年，Salesforce 推出了 Force.com，允许开发者使用 Salesforce 的底层架构来构建和运行应用。

Force.com 是 Salesforce 的原始云平台，它允许开发者快速构建和部署强大的企业应用。

作为一个完全托管的平台即服务（PaaS），Force.com 提供了一个无需担心底层基础设施的环境，开发者可以专注于创新和应用逻辑的实现。它把复杂性隐藏在了一个易用且功能丰富的集成开发环境（IDE）背后，通过这个环境，即使是非技术用户也能使用拖放组件和声明式编程来构建应用程序。

在架构上，Force.com 引入了多租户架构，它可以让不同的客户可以在同一个应用实例上操作，而不会互相干扰。这有效地提高了资源的利用率，同时确保了高度的可扩展性和安全性。每一个客户的数据和配置都存储为元数据，使得个性化和升级变得容易。

Force.com 的核心是其元数据驱动的框架，它允许应用以定义而不是代码的形式存在。这种方法简化了应用的构建、部署和维护过程。

平台还内置了强大的工具，如 Apex（一种类似于Java的编程语言）和Visualforce（一个创建用户界面的框架），使得开发者可以构建定制的逻辑和用户界面，进一步扩展应用的功能。

随着时间的推移，Salesforce 不断发展其平台，引入了更多的AI和自动化功能，但Force.com 的这些初始架构原则依然是支持 Salesforce 生态系统的基石。

2008 年推出了 Apex 和 Visualforce。

Apex 是 Salesforce 的后端编程语言，专为云计算环境设计。它允许开发者编写执行流程控制、事务控制以及数据库操作的代码。作为一种强类型、面向对象的语言，Apex 使得在 Salesforce 平台上编程变得强大而灵活，提供了类似于 Java 的语法，但同时添加了一些销售力特定的功能和简化。Apex 代码可以用来创建自定义业务逻辑（如触发器和类），它被托管和执行在 Salesforce 的服务器上，提供了与 Salesforce API 的高度集成。

Apex 在 Salesforce 生态中起到了重要的作用，尤其是在处理复杂的业务逻辑、数据校验、记录操作前后的自动化任务以及构建复杂的 Web 服务时。它使得 Salesforce 变得更加强大和灵活，允许企业根据具体需求定制其 CRM 解决方案。

Visualforce 是 Salesforce 的一种标记语言，用于构建定制的用户界面组件。它允许开发者创建具有专业外观和感觉的页面，这些页面可以显示和操作 Salesforce 数据以及其他逻辑。Visualforce 的标记语言让开发者能够定义用户界面的布局和样式，同时它提供了一套丰富的标准组件，比如表单、按钮和列表视图，这些都可以直接嵌入到Visualforce页面中。

Visualforce 为 Salesforce 开发者提供了极度灵活性，以定制个性化的用户体验。它广泛应用于创建复杂交互的企业级应用，无论是在内部员工的应用程序中还是在面向客户的社区和门户中。通过 Visualforce，企业能够构建完全符合品牌要求和业务流程的自定义用户界面。

2010年代：移动应用扩展

随着智能手机的普及，Salesforce 在 2010 年开始推出了移动应用开发工具，允许开发者创建可在移动设备上使用的应用程序。

在 2013 年，Salesforce 发布了 Salesforce1 平台。

Salesforce1 平台是 Salesforce 专为移动设备设计的应用，它让用户能够随时随地通过智能手机或平板电脑访问 Salesforce 的核心功能。该平台提供了全面的 CRM 功能，包括数据查看和管理、报告和仪表板、工作流和审批以及任务和日历管理，使移动工作比以往任何时候都更加高效和连贯。

此外，Salesforce1 平台支持高度的自定义，允许企业根据自己的业务需求定制应用和页面，同时通过集成 Chatter（一种企业社交网络工具） 功能促进团队成员之间的沟通和协作。用户还可以安装来自 AppExchange 市场的第三方应用程序，进一步扩展移动应用的功能。

安全性方面，Salesforce1 平台提供了企业级的数据保护，确保在移动环境中的数据安全。平台设计考虑了跨设备兼容性，并且支持在无网络连接的情况下离线访问数据，连网后则自动同步更改，确保工作的连续性和数据的实时性。

Salesforce1 平台标志着 Salesforce 对移动策略的重视，以及为开发者提供构建移动优先解决方案的工具。

2014年：Lightning 平台的诞生

Salesforce Lightning 首次亮相是在 2014 年的 Salesforce Dreamforce 大会上，但它的大范围推广是在 2015 年左右。

随着 Lightning 的推广，Force.com 更名为 Salesforce Lightning Platform。这个平台包括了原有的 Force.com 功能，并且增加了一些新的工具和功能，如 Lightning App Builder、Lightning Component Framework 等。

Lightning 平台的诞生是为了满足现代化企业软件在用户体验和开发效率上的新要求。它是对 Salesforce 经典用户界面的彻底革新，引入了更直观、响应式的设计和更强大的移动功能，旨在改善最终用户的日常使用体验。

随着技术的发展，Salesforce 看到了简化应用开发流程的必要性，因此在 Lightning 平台中集成了声明式的开发工具，如 Lightning App Builder，这些工具使得应用的构建和部署变得更加迅速和容易，即使是非技术用户也能够轻松上手。

为了提高开发的灵活性和可维护性，Lightning 平台采用了基于组件的开发模型，允许开发者创建可重用和易于维护的应用组件。这种模式强调了模块化和复用性，加快了开发速度，并且提高了应用的质量和扩展性。

Lightning 平台的推出不仅增强了 Salesforce 作为企业级应用开发平台的能力，而且通过提供一个一致且功能丰富的开发生态系统，它激励了创新，为企业提供了一个强大的平台来构建、部署和管理他们的业务应用，同时推动了 Salesforce 生态系统的整体进步。

2015年以后：整合和创新

  • Salesforce App Cloud的形成：在 2015 年，Salesforce 将 Force.com 合并入Salesforce App Cloud，这是一个更广泛的 PaaS 解决方案，包括 Force.com、Heroku 等服务。
  • 整合 Heroku：Salesforce 进一步整合了 Heroku，这是一个支持多种编程语言的云平台即服务（PaaS），使得开发者能够使用他们选择的语言和框架来构建应用，并且轻松地将这些应用与 Salesforce 数据和流程集成。
  • Einstein AI平台的推出： 在 2016 年 Salesforce 推出了 Einstein AI，一个内建于 Salesforce 平台中的人工智能层。Einstein AI 提供 API 和服务，允许开发者和管理员为他们的应用添加智能功能，使得企业应用能够更智能地服务于最终用户。
  • Salesforce DX：在 2017年，Salesforce 推出了Salesforce DX，提供了新的工具和特性，以支持现代化的开发实践，如版本控制、持续集成和交付。
  • MuleSoft 的整合:在 2018 年，Salesforce 收购了 MuleSoft，一家提供 API 管理和企业集成软件的公司。MuleSoft 的技术被整合到 Salesforce Integration Cloud，进一步加强了 Salesforce 在企业集成和 API 管理方面的能力。 Salesforce 通过收购 MuleSoft，进一步加强了其在数据集成和 API 管理领域的能力，为 Lightning Platform 提供了后端集成支持。
  • Salesforce Evergreen: Salesforce Evergreen 提供了无服务器函数和全面的数据服务，进一步加强了 Salesforce 平台的后端开发能力。
  • Hyperforce: 在 2020 年，Salesforce 还推出了 Hyperforce，这是一种重新架构的 Salesforce Platform，使其能够在公共云基础设施上运行，提高了灵活性和全球扩展能力。

SaaS、PaaS、IaaS 三层的开放逻辑

从 SaaS（Software as a Service）、PaaS（Platform as a Service）和 IaaS（Infrastructure as a Service）的角度来看 Salesforce 的开放能力演化：

SaaS层 – 软件即服务

SaaS 是 Salesforce 的核心层面，它以提供 CRM 服务开始，随后扩展到了全客户体验的管理。Salesforce 的 SaaS 解决方案包括销售云、服务云、市场营销云、商务云等，所有这些都是构建在 Salesforce 的 PaaS 之上的。

在 SaaS 层面，Salesforce 的开放能力体现在它提供的各种云服务可以通过 API 与其他系统集成，以及它的 AppExchange 生态系统，后者允许第三方开发者构建和销售自己的应用程序，这些应用程序可以无缝集成到 Salesforce 平台中。

PaaS层 – 平台即服务

在 PaaS 层面，Salesforce 的开放能力尤其显著。Salesforce 原生的 PaaS 解决方案，如 Force.com（后来发展为 Salesforce Lightning Platform）和 Salesforce App Cloud，为开发者提供了创建、测试、部署和管理应用程序的平台。这些平台支持了 Salesforce 强大的 API、开发框架、集成工具、数据服务以及安全性和合规性功能。

Force.com 最初提供了开发者工具和服务，允许构建在 Salesforce 数据上的自定义应用程序。随后，Salesforce 引入了 Heroku，这是一个更为开放的 PaaS，支持多种编程语言，为开发者提供了更大的灵活性，并且使得 Salesforce 的 PaaS 层能够支持更广泛的应用场景和开发需求。

IaaS层 – 基础设施即服务

在 IaaS 层面，Salesforce 本身并不直接提供传统意义上的基础设施服务，如服务器、存储或网络资源，这些通常由传统的 IaaS 提供商如 Amazon AWS、Microsoft Azure 或 Google Cloud 提供。

然而，Salesforce 的 Hyperforce 重新架构使得 Salesforce 平台能够在这些公共云基础设施上运行，从而在全球范围内提供服务。这种架构变革提升了 Salesforce 的开放能力，因为它允许 Salesforce 利用现有的全球 IaaS 提供商的规模和服务，以更加灵活和可扩展的方式运行其平台。

开放能力在 SaaS、PaaS、IaaS 的体现重点

Salesforce 的开放能力在不同层次上体现了不同的重点：

  • 在 SaaS 层次上，开放能力体现在提供了可扩展的、集成的业务应用程序上，这些应用程序可以通过强大的 API 和生态系统与外部服务和应用程序进行互操作。
  • 在 PaaS 层次上，开放能力体现在提供了一个功能丰富的开发环境和集成的服务上，允许开发者和企业快速构建、部署和管理业务应用程序。
  • 在 IaaS 层次上，开放能力体现在平台的可移植性和在多个云基础设施上的可用性上。

通过不断增强各层的开放能力，Salesforce 成功地将自身定位为一个全面的企业软件解决方案提供商，不仅满足了企业的 CRM 需求，也支持了更广泛的业务流程自动化和客户体验管理。

小结

Salesforce 在开放能力上构建了一个强大的生态系统，通过 AppExchange 为第三方开发者提供了一个平台，能够集成和销售他们的应用，从而增强了 Salesforce 的服务能力并提高了用户粘性。同时，Salesforce 的多租户架构和对 PaaS 的强调，使得它成为企业可以快速定制和扩展应用的强大平台，进一步通过低代码和专业编码的工具使得它能够服务于不同技能水平的开发者。

Salesforce 持续集成先进技术，如 AI 和数据分析，进一步增强了平台的智能化和自动化能力，提升了用户决策和业务效率。它的移动策略和对用户体验的不断改进，确保了 Salesforce 的解决方案在任何设备上都易于访问和使用，改善了用户满意度。

在其所有开放能力发展中，Salesforce 始终将安全性和合规性作为核心考量，确保了客户数据的安全并遵守各种数据保护法规。通过对基础设施的创新，如 Hyperforce，Salesforce 提供了高度的灵活性和全球扩展能力，同时保持了平台的可适应性，以响应市场和客户需求的不断发展。

别只是写OKR，得有自己的认知和思考

发表回复

最近比较多的文档专用时间都花在写 OKR 上，也有一些探讨，发现小伙伴们对于 OKR 在认知上是不一样的，有些多一些，有些少一些，有些甚至是为了写 OKR 而写 OKR，属于应付了事。

于是今天就聊聊 OKR，聊下 OKR 是为组织解决什么问题，如何生成 OKR，写 OKR 过程中对于上线时间这种要不要写进去，以及 OKR 和 OGSM 有什么关系。

先想一下一个组织为啥要用 OKR 这个工具，其解决的是什么问题？

OKR 是一种帮助组织设定、追踪和实现目标的目标管理工具。

其解决的主要问题包括以下 4 点：

一，聚焦和优先级的问题，因为组织经常面临资源有限的问题，需要确定优先关注的领域。OKR 通过设定明确的、优先级排序的目标，帮助团队和个人集中精力在最重要的任务上。

二，透明度和对齐的问题，通过公开共享 OKR，组织内的每个团队和成员都可以对其他部门和同事的目标有所了解，从而确保所有人的工作都朝着相同的方向推进，实现组织目标的一致性和对齐。

三，衡量和追踪过程的问题，OKR 提供了一种衡量进展的机制，通过定期检查关键结果，组织可以实时了解他们是否接近既定目标，从而及时调整策略或努力方向。

四，激发员工参与和动力，OKR 通过设定具有挑战性的目标来激励员工，同时关键结果的实现也让员工感受到成就感，从而激发他们的积极性和参与度。

除以上 4 个以外，OKR 在提高执行力也能发挥比较大的作用。

当一个组织用 OKR 来做战略执行，来管理目标时，我们作为一个技术团队的管理者，应该如何生成 OKR？

OKR 的生成是一个从上到下，再从下到上，反复进行的过程。

从上到下的逻辑是组织负责人先要确定组织的愿景和年度或季度战略目标，第一版的 OKR 应该是负责人先写，提供一个清晰的方向和预期的成果。这样才能有聚焦的方向，让参与的每个人或团队都有自己明确的目标。

从下往上的逻辑是下一层管理者和团队成员根据自己的角色和对业务的了解，对这些目标进行评估和反馈。这样做是发挥每个人的主动性，让他们感到自己在为明确的目标而战，而不是单纯服从领导的指令。

在生成的过程中，管理层和团队成员之间就 OKRs 进行多次探讨和沟通，根据实际情况和团队输入进行调整。这个过程确保了 OKRs 的共同所有权和承诺，每个人对结果都有责任感。

这样结合了管理层的指导和团队成员的具体知识，创造出既具有挑战性又实际可行的目标。还促进了全组织的参与和承诺，每个人都对共同的成功负责。

在具体写 OKR 的过程中，有一个点有时会有点纠结，上线时间要不要写到 OKR 里面来？取决于什么？

是否将项目的上线时间放入 OKR 中取决于该目标如何与组织的更广泛目标和优先级相结合。OKR 的关键在于设定可以推动组织向前发展的目标和可以量化结果的关键成果。在决定是否将项目上线时间纳入 OKR 时，可以考虑下面 3 个点：

  1. 目标关联性：项目上线时间是否与目标紧密相关，是否能显著推动业务价值或用户价值？
  2. 可衡量性：上线时间是否是衡量成功的关键指标？
  3. 控制性：团队是否有控制上线时间的能力？如果上线时间受到外部因素影响，是否有相应的应对策略？

如果项目上线时间符合上述考量点，并且可以帮助团队或组织专注于关键的业务成长和客户价值提供，那么将它作为一个关键结果（KR）是合适的。然而，如果上线时间是一个单纯的截止日期，并不直接映射到可衡量的业务成果，那么它可能不适合作为 KR。在这种情况下，上线时间可能更适合作为团队的里程碑将业务的上线时间放入 OKR 中可能不太合适，因为 OKR 更倾向于衡量结果而不是活动或任务完成情况。上线时间更像是一个项目管理里程碑，而不是一个战略级的关键结果。

如果上线时间背后有更深层的战略目的，那么可以将这个目的转化为 OKR。如目标是：

  • 目标（Objective）: 成功推出新产品，以增加市场份额。
  • 关键结果（Key Result）: 新产品上线后的前三个月内达到10万用户。

在这个例子中，上线时间是实现关键结果的一个步骤，但关键结果本身关注的是上线后的用户增长情况，这是一个可以量化的结果。

如果上线时间对于业务战略至关重要，比如市场时机对于产品成功非常关键，那么可以把它与关键结果联系起来，如：

  • 目标（Objective）: 抓住市场先机，快速响应市场需求。
  • 关键结果（Key Result）: 在 XX 日期之前完成产品上线，以满足季节性市场需求。

在这种情况下，上线时间成为了实现目标的关键一步，但更重要的是，它与市场需求和产品成功的战略目标相联系。

聊完了 OKR，再聊一下 OGSM，OGSM 和 OKR 一样，都是战略规划和执行的框架，都旨在帮助组织设定目标并衡量进度，并且 OGSM 略早于 OKR 出现。

OGSM 的英文全称是：Objectives, Goals, Strategies, and Measures

  • 目的（Objectives）：与 OKR 中的目的类似，是组织希望实现的宏伟愿景或方向。
  • 目标（Goals）：通常是一系列的定量目标，它们定义了实现目的所需要达成的具体成果。
  • 策略（Strategies）：描述了将如何达到上述目标和目的的具体方法或途径。
  • 衡量标准（Measures）：用于跟踪策略执行情况和目标完成情况的指标。其中 Measures 包括 Dashboard 和 Plans。

和 OKR 的快速迭代相比，OGSM 通常用于年度规划，具有更长期的视角，侧重于持续的战略执行。

在写 OGSM 的过程中，有以下的点要注意：

  • Objective 要设定某个特定对象，能正确反映了组织、个人的愿景
  • Goal 要对应 Objective 的关键词
  • Goal 要符合 SMART 原则
  • Strategies 要承接 Goal 的达成
  • Measures 要对应 Strategies 的达成情况
  • Dashboard 要能够正确衡量如何执行策略，比如 如何找到策略资源？如何使用策略资源？能够衡量这些才是关键。
  • 要避免混淆 Dashboard 和 Plans

用一句话来说就是：先有目的（O），再有目标（G）来衡量 O 的达成，S 是用来支撑 G 的达成的，每个 S 都会有对应的 M 指标来衡量，而每个 M 指标都会有 Plan 来支撑。

所以顺序是  O –> G –> S –> M（KT）

OGSM 是一个更为全面的战略规划工具。OGSM 的力量在于它的结构性和层次性，它不仅帮助团队设定目标，还指导他们如何实现这些目标。OGSM 的一个关键优势是，它将策略和衡量标准结合起来，从而为实现长期愿景提供了一条清晰的道路。

通过使用 OGSM，组织可以确保其战略规划不仅仅停留在高层次的目标上，而是拥有一套清晰的行动计划和衡量标准。这种方法提供了一个框架，可以帮助团队在整个执行过程中保持关注，并及时调整策略以应对不断变化的市场和业务环境。

不管是 OKR 还是 OGSM，当我们在使用这些工具的时候都需要理解这些工具背后的逻辑，确保它和我们的组织文化、工作流程等相匹配。它们不仅仅是目标和结果的清单，而是组织文化、战略思维和团队协作的催化剂和润滑剂。