雲端組織反面模式

  • 發行項

客戶常會在他們的組織結構內碰到雲端採用的反面模式。 許多因素可能會導致下列問題：

  • 工具
  • 合作夥伴
  • 工程師
  • 未經整合的 IT 部門

了解這些因素在成功採用雲端之案例中扮演的角色十分重要。

反面模式：將 IT 視為成本中心

許多公司將 IT 部門視為成本中心。 此法可能會造成 IT 部門不會為公司增加價值的印象。 若員工只將 IT 視為提供者，而非協助者時，可能會讓他們感到沮喪， 公司也很難吸引到適當的人才， 進而導致其幹勁不足，生命週期拉長的結果。 IT 的工作品質可能會受到影響，並可能會發展出本位主義與封地主義思想。

範例：將 IT 視為成本中心

公司將 IT 部門視為成本中心進行管理，並須對財務長 (CFO) 負責。 管理階層將 IT 視為耗時的服務提供者，是公司最大的成本花費之一。 管理階層不了解 IT 部門訂購的大部分資產中，行動業務單位的取用量最大。 IT 購買資料中心供所有業務單位使用，而行動業務單位多會超量使用這項資產。 管理階層未將 IT 視為協助者或合作夥伴。

期望的結果：將 IT 視為協助者

與其將您的 IT 部門視為成本中心，不如考慮下列幾種方法：

  • 計費：業務單位將 IT 費用視為預算中的營運費用。
  • 虛擬計費或提醒計費：將 IT 視為代理人。 在交回給公司的報表中，IT 會將費用直接歸入相關的業務單位。

使用雲端可以提高費用和業務的透明度。 例如，實作 成本管理專業領域 來增加成本透明度。 讓您更加清楚各個業務單位的成本狀況。 在這裡，IT 部門是這些單位的協助者。

若要改善透明度，在移轉到雲端時，應專注於可見度、當責與最佳化。 如需詳細資訊，請參閱建立合乎成本的組織。

反面模式：投資新技術時，未將業務單位納入考量

IT 部門常會投資大量的人力和財務資源，建立及部署穩固的平台與工具組。 但有時候 IT 在設計和開發時，未兼顧到業務單位和他們的需求。 這項疏失會讓新平台之於業務單位，幾乎完全派不上用場， 進而導致員工不願意接受新的技術， 乃至於無法採用新技術，或推行進度緩慢。 業務單位不使用平台，也會讓 IT 產生挫折感。

範例：設定平台時，未將業務單位納入考量

資料分析公司的 IT 部門，在設定和自訂 Azure 平台時，未將業務單位納入考量。 在使用平台時，業務單位開發人員：

  • 發現他們沒有部署所需的權限。
  • 只能使用少量的服務。
  • 發出支援票證時，核准週期的時間長。
  • 開始質疑新平台。

最後，一些開發人員自行購買 Azure 訂閱，規避 IT 規則和法規的麻煩。 影子 IT 應運而生。 因為公司幾乎無法管控影子 IT，所以衍生出高度的安全性風險。

期望的結果：制定決策時，將業務單位納入考量

部署符合企業需求的雲端平台時，避免 IT 本位主義心態。 在進行設計和開發的過程中，邀集業務單位的開發人員和技術決策者 (TDM) 共同討論。 若要提升平台的使用率，應聆聽業務單位的想法。

若要了解專為開發人員規劃的 Azure 最佳做法與設計原則，以加快採用速度，請參閱雲端採用架構企業規模登陸區域入門。 在合規性與彈性之間求取適度平衡。 比方說，找出可以同時滿足治理和安全性原則，又能保有開發環境敏捷度的方法。

反面模式：將核心業務功能外包

諮詢合作夥伴和受控服務提供者 (MSP) 在雲端旅程中扮演著重要的角色。 但公司必須了解，合作夥伴與 MSP 的工作，無法為公司業務提供最大的價值。 將責任外包給 MSP 或雲端顧問的公司，不應變成完成依賴這些提供者。

範例：將雲端採用和移轉外包

某研究機構有一個時間緊迫的雲端移轉專案。 為縮短雲端採用旅程，該機構聘用了一位 MSP 協助建立 Azure 基礎及實作移轉。 該機構捨棄了解雲端採用階段和學習建立技能，改而將所有 Azure 責任交付給 MSP。 因為該機構沒有任何雲端或 Azure 知識，所以 MSP 主導了一切決策，致使該機構必須全然依賴 MSP。

期望的結果：公司應負責重大設計領域

請注意，外包是節省成本的一大良策， 但在制定重大設計領域相關的決策時，應由您的公司主導：

  • 控管
  • 風險
  • 法規遵循
  • 身分識別

由公司負起這些和其他領域的責任，對您的您的安全資產十分重要。 您可以使用外部合作夥伴加速採用速度， 但為了避免過度依賴提供者，請勿將所有事物全部外包。

反向模式：聘用技術決策者，而非開發雲端工程師

公司會將重點放在尋找正確的人員。 因此常會在雲端採用階段初期，聘用或組織 TDM。 成功的雲端旅程需要 TDM。 但更重要的是，雲端採用需要工程師有著全體總動員的心態，而且必須具備深度的技術技能。

範例：只聘用 TDM

某研究機構聘用了數名 TDM 來領導他們的雲端旅程。 當初始高階概念階段結束之後，實作階段隨即開始。 該機構隨後發現，雲端部署與內部部署大不相同， 需要額外的雲端工程工作，才能適當地實作基礎結構為程式碼 (IaC) 概念，以及使用原則進行治理。

期望的結果：實作階段聘用雲端工程師

請注意，工程師在正確實作雲端自動化和登陸區域概念上，是不可或缺的角色。 當您採用服務模型時，責任與工作可能會出現大幅的變動。 將責任轉交給雲端提供者，可以更快進入生產。 您也可以交由 TDM 制定決策，但對於需要深度工程知識的工作，請交付給資深的雲端工程師。 接下來就是體會雲端為您帶來的好處。

後續步驟