討論IBM智慧分析雲的特定價值

儘管企業以前只依賴直覺，但它們現在可以利用業務智慧及分析做出基於事實的決策並回答以下這些問題：如何設計產品價格，新服務以哪些市場為目標，以及如何降低風險。 在本系列中，我們將討論在業務智慧及分析中應用雲計算的價值。 在第一部分中，我們介紹了業務智慧及分析的原因。 在本文中，我們將討論智慧分析雲的特定價值。

資訊和推動資訊不斷發展的技術，以及資訊的各種方式改變了我們的生活和工作方式。 業務智慧及分析旨在通過將大量資料轉換為有價值的洞察來改進我們的決策。

因為有較好的分析和理解資料能力，從首席高管到一線員工都有權展現基於事實的分析，並可能影響重大決策的制定。 企業可以挑戰現狀並採取大膽的措施來提高性能。 最終的目標是在適當的時候獲得合適人群的正確資訊。 但面臨的挑戰是轉變企業功能來提供有效的業務智慧及分析服務。

除了處理不斷增加的資料，另一個挑戰是將資料轉變成相關資訊。 如今，資訊流動得非常快。 訪問相關資料和更好地預期未來成果的功能具有重要價值。 這種前瞻性能力可説明企業權衡利弊並對未來追求做出更好的決策。 業務智慧及分析技術有助於將不斷增加的資料量轉換為洞察。

電腦的使用範圍已經擴大。 引入資訊技術的同時，業務也通過將電腦簡單用於自動化表格處理這樣的重複任務而得到改進。 現在的創新可以整理大量資料，並將資訊轉換為直觀的報表和計分卡。 要考慮這些潛在影響。 在許多其他機會中，您可以利用創新技術做出更好的決策，即在哪裡銷售新產品和服務，或使用醫療資訊以提供更好的治療，或改善城市交通狀況。 業務智慧及分析背後的基本概念並不新鮮。 在一段時間內，定量分析法曾用在業務中，如金融市場貿易。 現在的變化是提供業務智慧及分析服務的技術和工具日益成熟。 現在的工具可以輕鬆訪問整個企業中的所有業務智慧及分析工具，而不是僅僅訪問指定使用者群，例如，IBM Cognos 8 BI 這種工具具有直觀的使用者介面，而且與雲計算部署策略結合。

想像這樣一個組織，在組織中可以有效且及時地共用相關資訊（可能是客戶或庫存量資料）。 員工個人可使用公共服務生成自訂報表，而不是每個人都將相似資訊存儲在自己的試算表中。 企業可通過該服務和相似場景利用業務智慧及分析方法改善資訊共用，並將基於事實的分析引入主流業務中。

但是，技術僅僅是開始。 如何使用技術會提供更大的增值。 比如，企業執行了一項軟體和硬體解決方案。 在典型模型中，商務分析師將請求提交到 IT 服務組進行分析並提供報表。 技術嫺熟的 IT 員工可能瞭解他們從事的業務，但未必是這方面的專家。 如果商務分析師不需要深層技術知識就能夠分析資料，那麼就可以實現效率並獲得深入洞察。 這樣的話，決策制定的速度會提高。 商務分析師可以直接存取分析和資訊，而不必等到 IT 資源變得可用。 應刪除不必要的通信級別。 通過移動任務，如創建來自 IT 服務組的報表，可釋放這些資源以開發新的創新。

雲計算

在轉換 IT 功能以提供有效的業務智慧及分析服務之前，考慮雲計算的樣子非常重要。 您可能要類比一項基於當前成功服務模式的 IT 服務，如水或電力設施，而不是重新發明車輪。 公共設施可服務于許多客戶，同時還能標準化並集中化交付。 他們使用規模經濟提供有競爭力的價格和附加價值。 進一步考慮之後，您可能會考慮這些運營需求：可擴展、有彈性、靈活、自動化和標準化。 您也可以想像這樣一種環境，終端使用者用簡單的方法請求服務，而且有添加、維護和退出服務的簡易流程。 由於存在許多不同的方面，開發業務智慧及分析服務時我們應從哪裡開始呢？ 首先，考慮服務的運營部分，並確定它們（比如，公用設施）是否是集中化的良好選擇。

服務的四個關鍵運營部分是：

硬體 軟體 資料 業務應用

硬體基礎架構可由企業進行集中管理，或由業務線進行本地管理。 本地管理辦法會使服務場激增，而且這會產生逆轉，因為企業正在利用虛擬化並想要從經濟規模中獲益。

可基於部門級別或企業級別購買業務智慧軟體和中介軟體。 隨著時間的推移，部門可能會開發不同的首選項和技能組合，但在協商產品的較大量許可或較小系列的企業範圍軟體時實現的節約經常會超過這些首選項。

在管理和維護成本方面也會看到進一步的成本降低。 但是部門強烈反對資料集中化。 資料責任是一個敏感話題。 業務線必須控制資訊，因為這些資訊對其所負責的業務而言十分重要，因而業務線想要自己管理資料，這就使它們有足夠的靈活性來應對市場變化。

商務應用程式為每個業務線提供戰略價值。 雖然可集中基礎軟體和中介軟體，但將同樣的方法用於區別終端使用者應用程式的價值是行不通的。

在可操作元件中，硬體和軟體基礎架構元件為自己提供了集中化方法。 該基礎架構的集中化和標準化就稱為雲計算。 雖然雲計算標誌著從分散式狀態轉變到集中化狀態，但在這種變化仍然有實際價值。 業務線可以重點關注其資料和商務應用程式哪個更重要，並且還可從指定雲供應商處獲得可靠的基礎架構。

雲計算這個術語用於不同的領域。 但是，雲計算的用途有著共同的主題。 一方面，雲計算是一種基礎架構和服務方法。 另一方面，雲計算也是一種使用者體驗和業務模式。

雲計算是：

可擴充性：可在不影響功能的同時增加容量。 靈活性: 允許應用程式在基礎元件發生故障的情況下仍然繼續運行。 彈性: 可在不改變或妨礙當前功能的同時添加或更改功能。 自動化和標準化：以標準化方式添加資源，可能的話以自動化方式添加資源。 服務生命週期支援：設置新的基礎架構和軟體，並對其進行維護或使其淘汰。 自助服務：提供便於使用的介面，允許無深厚技能的終端使用者請求新的資源。 雲計算不僅僅是對資料中心基礎架構的改進，還是一種使用者體驗和業務模式。 在雲部署中，終端使用者會看到易於訪問且快速提供的標準服務產品。 圖 1 描述了雲計算及其基本元件。

圖 1. 雲計算的元件

雲計算的基本內部元件是資料中心基礎架構、服務目錄和元件庫。 資料中心基礎架構包括硬體（如 System z）、軟體（如 IBM Cognos 8 BI）和中介軟體（如 DB2）。 元件庫包含硬體、軟體和交付服務所需的服務元件。 軟體目錄列出為客戶提供的服務，例如，服務目錄可包括 Linux 客戶的安裝，Cognos 許可，甚至是一項完整的智慧分析雲服務。

雲計算中的關鍵角色是服務消費者、管理員、軟體發行商和元件供應商。 服務消費者通過具有標準使用者介面的訪問服務提出請求。 雲管理員監控並管理交付的服務和資源。 軟體發行商可能是開發自訂服務的內部部門。 元件供應商（如 IBM）也會提供智慧分析雲這樣的服務。

討論雲計算時，區別兩種類型的雲是十分重要的。 雖然命名方式不同，但仍存在主要分類，即公共雲和私有雲。

服務供應商擁有和管理公共雲，並通過訂購進行訪問。 公共雲在每使用者價格的基礎上提供一系列標準化的業務流程、應用程式和基礎架構服務。 公共雲的優點包括標準化、資本保持、靈活性和較短的應用程式部署時間。 私有雲只能通過公司或合作夥伴網路進行訪問。 私有雲提供更多的自訂能力，推動效率，並且保持標準化和實現最佳實踐的能力。 其他優點是可用性、彈性、安全性及隱私的級別根據不同于外部供應商的企業水準確定。

對很多企業來說，公共雲不是十分安全可靠。 而私有雲提供了更大的靈活性，並用於企業級的解決方案。

IBM 智慧分析雲

業務智慧及分析功能的轉換會導致改變重要的決策，説明預期未來成果並授權于員工。 IBM 智慧分析雲服務產品旨在克服挑戰，以改變並使客戶成功提高其自身的業務智慧及分析功能。

IBM 智慧分析雲是：

在私有雲部署的客戶位置上支援業務智慧及分析交付的服務產品。 IBM 智慧分析雲的目標是使業務更智慧，授權于企業並使所有員工（尤其是與客戶和供應商密切接觸的員工）做出更好的決策。

要想既從服務產品中獲益又能證明其價值，IBM 在內部執行智慧分析雲。 該內部解決方案被稱為 Blue Insight，而且目標是通過開發企業範圍的業務智慧及分析策略轉換 IBM，而且該策略利用：

分析與業務智慧領域的公共服務、基礎架構、知識和流程。 集中式基礎架構，即授權企業利用其領域的專業知識轉換計畫。

執行 Blue Insight 的結果會產生很多益處，包括：

整合的業務智慧和軟體產品集合 一個終端使用者可以挖掘更大量的資料來源 服務 200,000 多名使用者的能力 硬體、軟體的成本節約和經營效率的提高 增強的彈性

沒有挑戰就沒有 IBM 的變化。 不同的業務線擁有自己的業務智慧方法以及不同的軟體和硬體產品。 在對資料和其他服務方面集中化時還存在阻力。 但是最後，IBM 實現了重要價值。

IBM 下一步準備説明客戶瞭解自身體驗，並使他們獲得基於雲的業務智慧及分析的益處。

IBM 智慧分析雲大大減少了單個 BI 環境的部門解決方案數量，而且這種環境支援整個業務線上的大量使用者。 此外，智慧分析雲：

通過對部門業務流程、企業安全性及合規性的單點控制改善標準化。 更有效地使用技術資源以支援常見的業務智慧及分析交付工具。 降低支援企業範圍服務所需的資本和運營費用。 支援分配業務智慧及分析服務的自助服務方法，而且這些服務降低了向新的分部、部門和使用者交付服務的時間、資源和成本。

借助智慧分析雲，IBM 可説明用戶端創建業務智慧及分析服務。 像 IBM 一樣，您可以期望看到雲計算的積極結果，如成本節約、支援大量使用者的能力以及軟體產品集合的簡化。 更有效的進程提高了可訪問性，並使整個企業的服務客戶能夠挖掘智慧及分析功能。 業務線可以使用常見的分析服務整理資訊，並做出更加基於事實的決策。 基於雲的業務智慧及分析提供了巨大潛力。 啟動後，這些功能展現了前所未有的機遇。

結束語

下一部分我們將討論智慧分析雲所包括的服務。 本文和下一部分所提出的需求組合是以下架構的基礎：「架構概述」、「功能架構」 和「運營架構」。