授權最佳化 - 模式
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 組織 | ✅ 將授權類型與實際的使用者需求和使用模式 (非職稱) 進行比對 |
| 平台 | 組織 | ✅ 僅存取自訂物件的使用者會收到「平台」授權,而非完整的 Salesforce 授權 |
| 平台 | 組織 | ✅ 外部使用者 (客戶、合作夥伴、社群成員) 會使用 Experience Cloud 授權,而非內部授權 |
| 平台 | 組織 | ✅ 僅需要無資料存取權驗證的使用者會收到 Identity 授權 |
| 平台 | 組織 | ✅ 每季授權稽核會將僅存取自訂物件的使用者識別為「平台」授權候選項目 |
| 平台 | 組織 | ✅ 自動化每季報告會識別 90 天內已有零登入的使用者、僅存取自訂物件的使用者,以及內部授權的外部使用者,以進行系統右側調整 |
| 平台 | 組織 | ✅ 系統會根據角色變更檢閱和調整授權指派,而不是將數年保持不變 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 組織 | ⚡️ 系統會根據工作職稱而非實際系統用量模式,將完整 Salesforce 授權指派給所有員工 |
| 平台 | 組織 | ⚡️ 僅存取自訂物件的使用者會收到完整的 Sales Cloud 或 Service Cloud 授權,而非「平台」授權 |
| 平台 | 組織 | ⚡️ 外部使用者耗用內部授權容量,而非 Experience Cloud 授權 |
| 平台 | 組織 | ⚡️ 儘管角色變更,初始部署期間設定的授權指派仍維持三年不變 |
| 平台 | 組織 | ⚡️ 從未執行授權稽核;40% 的授權未使用或不足使用 |
| 平台 | 組織 | ⚡️ 登入次數少於每月的使用者不會識別為候選授權召回 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 安全性 | ✅ Shield 元件 (平台加密、事件監視、欄位稽核追蹤) 會根據是否滿足特定合規性需求來個別評估 |
| Data 360 | 結構 | ✅ Data 360 投資是基於跨系統身分解析、即時客戶資料存取或區段啟用需求的理由 |
| AI | 業務 | ✅ AI 投資需要在定義的測量期間內示範的 ROI,而非假設未指定的值 |
| 平台 | Industry Cloud | ✅ 系統會根據自訂開發成本和上市時間需求評估 Industry Cloud (財務服務、健康、製造、Net Zero) |
| 平台 | Industry Cloud | ✅ Industry Cloud 評估識別標準工作流程的實作速度提高 40–60%,但自訂會降低時間節省的考量 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 安全性 | ⚡️ 系統會購買所有 Shield 元件,而不評估特定元件是否滿足實際合規性或安全性需求 |
| Data 360 | 結構 | ⚡️ 在未評估更簡單的整合方法是否符合需求的情況下購買 Data 360 |
| AI | 業務 | ⚡️ AI 投資缺少可測量的業務價值度量或 ROI 示範 |
| AI | 業務 | ⚡️ AI 投資假設不會定義特定測量期間或成功條件,才會提供價值 |
| 平台 | Industry Cloud | ⚡️ 在未與自訂開發成本比較或驗證上市速度的狀況下購買 Industry Cloud |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 佈建 | ✅ 新使用者提供工作流程會自動為僅存取自訂應用程式的使用者指派平台授權 |
| 平台 | 佈建 | ✅ 根據電子郵件網域,針對 Experience Cloud 授權指派,新的使用者提供工作流程會將外部使用者排入排隊 |
| 平台 | 佈建 | ✅ 指派原則會根據使用者角色和平台用量需求,為授權類型定義明確的條件 |
| 平台 | 佈建 | ✅ 批准工作流程需要高級授權類型的業務理由 |
| 平台 | 佈建 | ✅ 在佈建時間強制執行適當的授權指派,而非追溯地修正錯誤指派 |
| 平台 | 組織 | ✅ 召回流程會自動識別未啟用的使用者 (60-90 天) 並取回未使用的授權以重新指派 |
| 平台 | 組織 | ✅ 登入型報告會根據組織原則識別 60-90 天的未啟用使用者 |
| 平台 | 組織 | ✅ 每季重新整理可防止在員工變更角色或離開組織時累積授權廢棄物 |
| 平台 | KPI | ✅ 利用監視顯示面板可追蹤登入頻率、功能用量模式和授權類型的適當性 |
| 平台 | 公司 | ✅ 利用率資料會與業務主管共用,以在續約規劃期間啟用資料驅動的授權投資決策 |
| 報告與顯示面板 → 授權利用率顯示面板 設定 → 使用者 → 啟用使用者 | ✅ 模式:授權利用率顯示面板會顯示啟用中與未啟用的授權、登入頻率散佈、依授權類型與授權類型散佈的功能用量 ✅ 利用率顯示面板會顯示未啟用的使用者、過度授權的使用者,以及需要檢閱的授權類型不相符項目 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 佈建 | ⚡️ 授權指派原則不存在;每個要求都會臨時處理 |
| 平台 | 佈建 | ⚡️ 批准工作流程不需要高級授權類型的業務理由 |
| 平台 | 組織 | ⚡️ 未啟用使用者識別是手動且不常見,而非自動 |
| 平台 | 組織 | ⚡️ 只有在年度續約期間才會進行授權撤銷,而非每季 |
| 平台 | 組織 | ⚡️ 當員工變更角色或離職而無須取回授權時,授權廢棄物會累積多年 |
| 平台 | KPI | ⚡️ 不存在利用監視顯示面板;使用模式不明 |
| 平台 | 公司 | ⚡️ 業務主管在續約規劃期間無法看見授權利用率資料 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 契約 | ✅ 業務計畫支援使用者計數承諾,而非樂觀的預測 |
| 平台 | 契約 | ✅ 機場排程會將投資與實際使用者上線時間表比對,而非提前支付未使用的容量 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 契約 | ⚡️ 過度致力於使用者計數會造成立即浪費,因為未使用的授權會耗用預算而不會提供價值 |
| 平台 | 契約 | ⚡️ 如果成長預測證明不正確,則會簽署多年契約而不評估彈性需求 |
| 平台 | 契約 | ⚡️ 確定時間不符合業務規劃週期;調整延遲實際人數變更 |
| 平台 | 契約 | ⚡️ 組織攜帶 200 個未使用的授權達 18 個月,因為承諾達成批量折扣後,雇用計畫會延遲 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 結構 | ✅ 整合結構規劃預測 API 耗用,並評估 Enterprise 或 Unlimited Edition 是否提供更好的 TCO |
| 平台 | 結構 | ✅ 針對包含的功能 (API 限制、儲存空間、Sandbox 配置、Premier 支援) 每位使用者保費的版本成本比較模型 |
| 平台 | 結構 | ✅ 版本決策模型針對這兩種定價模型預測使用狀況,並使用記錄的假設來啟用未來重新評估 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 結構 | ⚡️ 版本選項會根據預算限制預設為最高或最低層級,而無須分析結構需求 |
| 平台 | 結構 | ⚡️ 選取 Enterprise Edition 可將每位使用者的成本降到最低,而無須預測整合需求和 API 超額成本 |
| 平台 | 結構 | ⚡️ 整合需求會在部署後超出限制,進而透過 API 超額加上結構重設造成 2 倍的成本 |
| 平台 | 結構 | ⚡️ 版本決策無須根據定價模型或文件假設來建模實際使用狀況 |
| 平台 | 組織 | ⚡️ 版本選項僅以每位使用者的年度訂閱成本為基礎,而無須建模結構限制 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 結構 | ✅ 採用多組織結構之前,會評估單一組織最佳化方法 (共用規則、權限集、記錄類型) |
| 平台 | 結構 | ✅ 多組織 TCO 模型會顯示 2-3 倍的營運成本乘法,包括管理、版本管理、監視、事件回應和合規性 |
| 平台 | 結構 | ✅ 只有在法規需求 (GDPR 資料落地、財務分隔) 抵銷增加的成本時,才會採用多組織結構 |
| 平台 | 結構 | ✅ 多組織理由會記錄具有權限邊界的單一組織無法符合的真實隔離需求 |
| 平台 | 契約 | ✅ 多組織授權成本模型化每個組織的個別授權集區,減少數量定價並需要重複的管理授權 |
| 平台 | 結構 | ✅ 多組織營運成本模型跨多個實作並行維護,會乘以開發和營運工作 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 結構 | ⚡️ 採用多組織結構,因為業務單位「想要獨立」,而無須建模 2-3 倍成本乘法 |
| 平台 | 結構 | ⚡️ 多組織採用會發生,而不會評估具有共用規則的單一組織是否以成本分數來符合實際需求 |
| 平台 | 結構 | ⚡️ 多組織 TCO 模型不包含營運成本乘法 (2-3x 適用於管理員、版本管理、監視和合規性) |
| 平台 | 結構 | ⚡️ 多組織結構缺少證明值超過永久和複合成本乘量的已記錄業務理由 |
| 平台 | 契約 | ⚡️ 多組織授權成本分析不會考慮個別授權集區失去數量定價優點 |
| 平台 | 結構 | ⚡️ 未模型化多組織營運負擔;部署後會發現跨組織的並行維護 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 整合 | ✅ 多組織 TCO 包括 MuleSoft 授權 (每年 $20,000-$200,000 以上)、整合開發、持續維護和 API 產能規劃 |
| 平台 | 整合 | ✅ 已明確模型化跨組織整合成本,顯示 MuleSoft 的投資、開發工作和持續的營運成本 |
| 平台 | 結構 | ✅ API 耗用乘以模型化:跨組織交易會同時耗用多個組織的 5-10 個 API 呼叫 |
| 平台 | 整合 | ✅ 維護跨組織同步化參考資料的資料一致性負擔,包括開發工作、監視和衝突解決 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 整合 | ⚡️ 根據授權成本比較批准多組織結構,但未模型化 $240,000 年的年度整合成本 |
| 平台 | 整合 | ⚡️ 未明確建模跨組織整合成本;單一組織會完全消除這些成本 |
| 平台 | 結構 | ⚡️ 產能計畫中不會考慮跨組織呼叫的 API 耗用乘數 |
| 平台 | 整合 | ⚡️ 同步化參考資料的資料一致性負擔不包含在多組織 TCO 模型中 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 設定 → Sandbox → 環境策略 DevOps → Sandbox 配置計畫 | ✅ 模式:小組使用 Developer Pro Sandbox 來使用模擬資料進行功能開發、使用目標帳戶進行部分複製以進行整合測試 ✅ 僅保留完整複本以供預先生產 UAT 和效能驗證,其中結構上需要完整的資料量 |
| 設定 → Sandbox → 平衡策略 財務 → 環境預算 | ✅ 模式:15 人員開發小組使用 15 個 Developer Pro Sandbox (每月 750 美元)、3 個 Partial Copy (每月 900 美元),1 個 Full Copy for UAT (每月 3,000 美元) 實作平衡策略 ✅ 每月總計 $4,650 以符合實際開發模式,而非過度佈建理論上最大平行符號 |
| 設定 → Sandbox 範本 → 資料選取 設定 → 部分複製組態 | ✅ 模式:Partial Copy Sandbox 範本包含過去 12 個月的機會和個案,但不包含已歸檔的資料 ✅ 提供 5 GB 容量內的代表測試資料,而不需要「完整複製」,透過策略性資料選取功能啟用低成本的 Sandbox 類型 |
| 流程 → Sandbox 生命週期 設定 → 暫時環境追蹤 | ✅ 模式:暫時 Sandbox 管理會使用記錄的刪除日期追蹤針對特定專案建立的環境 ✅ 實作需要續約理由的到期原則,以維護超出初始範圍的暫時環境,避免永久狀態漂移 |
| 設定 → Sandbox 重新整理排程 行事曆 → 重新整理最佳化 | ✅ 模式:重新整理步調最佳化可讓 Sandbox 重新整理符合實際的資料重新整理需求,而非任意排程 ✅ 當測試模式不需要每月重新整理時,每季完整複製重新整理會不足以釋出額外 Sandbox 的容量 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 過度佈建 → 浪費的投資 | ⚡️ 反模式:組織購買五個 Full Copy Sandbox,為每個開發小組提供專屬的環境 ⚡️ 當「部分複製」符合大多數測試需求時,成本乘以 5-10 倍;對於需要完整生產忠誠度的情況,應保留「完整複本」 |
| 無策略 → 保費預設 | ⚡️ 反模式:15 個人小組購買 30 個 Developer Pro 與 5 個 Full Copy Sandbox (每月 $18,000) 的頂級策略,因為「有更多環境總是更好的」 ⚡️ 沒有分析顯示開發速度受到環境可用性限制;平衡策略會以每月 4,650 美元的速度提供相同的速度 |
| 未篩選的範本 → 強制升級 | ⚡️ 反模式:Partial Copy 範本包含所有物件,不需篩選,耗用 5 GB 的容量並使用與測試無關的歷程記錄資料 ⚡️ 當策略性資料選取啟用「部分複製」時,每個 Sandbox 的成本會降低 5-10 倍 |
| Sandbox Sprawl → 永久暫時 | ⚡️ 反模式:暫時 Sandbox 擴充,因為專案 Sandbox 會轉換為永久狀態而沒有理由 ⚡️ 沒有使暫時環境無限期累積耗用預算的到期原則或續約需求 |