由于協(xié)作服務是用戶日常工作不可或缺的一部分，因此，大型組織的過渡過程需要精心策劃--使用新服務遇到的問題將立即引起挫敗感。這直接影響服務的采用率，也影響過渡期。如果在過渡期間運行多個解決方案，這將增加IT團隊和企業(yè)的復雜性和成本，從而降低ROI。目標是通過快速，平穩(wěn)地將用戶和房間移至新解決方案，從而最大程度地縮短實現(xiàn)價值的時間。

　　準備是關鍵。在進入Beta測試之前，請確保您具有運行所需的功能和支持結構，從而可以最大程度地降低用戶影響。在進行Beta版測試之前，請確保這些物品經過全面的測試和實驗室測試：

　　在大多數(shù)IT情況下，我們會在不同時間轉換組織內部的各個部分，從而擴展了服務新用戶所需的大量支持。通常，協(xié)作解決方案無法做到這一點，因為舊方法和新方法不兼容。

　　調度是一個典型的例子。如果我們要使用解決方案A安排協(xié)作會議室，并且希望移至解決方案B，則必須將組織中的所有用戶轉移到同時使用解決方案B的位置。如果我們不這樣做，用戶可能會嘗試在解決方案A和解決方案B上為相同的時間安排相同的會議室，這將成為雙人預訂。如果筆記本電腦或移動用戶需要新的客戶端來支持新的解決方案，則會遇到同樣的挑戰(zhàn)。協(xié)作解決方案的最大價值在于我們可以在整個組織中進行協(xié)作，因此隔離用戶組與我們的目標背道而馳。

　　但是，從部署支持方法來看，先過渡到較小的組具有巨大的優(yōu)勢，既可以幫助管理支持負載，又可以使IT查找并解決出現(xiàn)的問題，而無需讓整個用戶組都遇到這些問題。在可能的情況下，我強烈建議轉換一部分用戶群或部分解決方案。

　　諸如調度平臺，視頻會議室和特殊用戶組（例如，最高執(zhí)行組）之類的解決方案的某些部分是獨立過渡的候選對象。

　　如果視頻室是獨立于最終用戶轉換的，則需要一種臨時方法將最終用戶整合到包括會議室的會議中。如果新老供應商都可以輕松地支持此操作，或者您可以通過內部或受管服務供應商的視頻網絡運營中心（VNOC）來管理這些基于會議室的呼叫，則可以制定流程支持此拆分過渡。避免用戶在調度或呼叫發(fā)起時必須做一些不同的事情的情況，因為我們不想訓練他們兩次。

　　同樣，如果他們的電話是由VNOC或他們的執(zhí)行管理員高度管理的，則可以分別調換執(zhí)行人員。警告：兩次培訓執(zhí)行管理員也不是您想要的。

　　完整的解決方案準備就緒后，最終用戶可以作為一個組進行過渡。一些組織將擁有一部分用戶，這些用戶會在組內進行大量交流，這是由于業(yè)務結構或自然引起部門分化的地理或語言差異所致。我在眾多組織中發(fā)現(xiàn)，拉丁美洲或南美的團隊通常是視頻協(xié)作的狂熱用戶，由于文化和語言的差異，它們往往會作為一個團隊來運作。但是仍然存在不可忽視的跨組協(xié)作要求。

　　最終用戶也可以進行有機過渡。一旦有了管理和計劃解決方案，用戶就可以通過注冊過程或客戶端下載來遷移到他們認為合適的新功能。如果該解決方案具有吸引力，尤其是如果管理層正在積極使用該服務，則用戶將隨著時間的推移相對較快地接受。排定的時間可能不如您的ROI所需的速度快，使用此方法可能會使舊解決方案退役的時間更長，但這將減少不想被不熟悉的解決方案的用戶所困擾。

　　概念驗證（PoC）測試對于驗證您選擇的解決方案是否如廣告所宣傳的一樣重要，而且對于確定企業(yè)中所需的關鍵變更以及這些變更的影響非常重要。測試之前，您不知道你不清楚的是什么。

　　驗證供應商承諾的關鍵技術功能對你的組織來說是至關重要的。與您當前設備的兼容性，會議規(guī)模，日程安排方法，集成難度，管理界面，自動化和其他功能可能都是驗證時很重要的。確定這些項目并制定測試計劃以確保每個項目都經過測試。

　　作為此測試的一部分，請確定您的供應商對支持需求的響應速度。嘗試與供應商的支持團隊而非他們的技術銷售團隊互動，以便您可以體驗服務團隊的技能和響應能力。

　　跟蹤使新解決方案生效所需的防火墻更改。PoC測試通常在實驗室環(huán)境中完成，因此團隊可以快速進行更改并使解決方案快速運行。在此實驗室設置中，可能無法仔細跟蹤防火墻的更改。使用可以捕獲所需防火墻更改的所有詳細信息的過程，以便可以與您的安全團隊一起檢查這些細節(jié)，以確保符合公司標準。

　　此外，在PoC跟蹤過程中，關注服務的可用性，尤其是如果您正在測試提供商的新功能時。這些功能是否已準備好用于生產部署？

　　使用PoC可以識別企業(yè)流程中將需要的更改�？紤]如何啟用和許可用戶和房間，如何將其與活動目錄集成，將需要進行多少工作以及如何使該管理自動化�？紤]如何進行使用情況跟蹤，尤其是當您考慮在企業(yè)的部門或企業(yè)之間分擔服務成本時。服務是否提供足夠的詳細信息來進行這些分配？

　　服務臺支持如何？當用戶無法安排，發(fā)起或參與呼叫時，用戶將如何與您的團隊或供應商的團隊聯(lián)系以獲得所需的支持？您當前的服務臺需要多少培訓才能為他們提供支持用戶所需的知識？您是否需要與供應商共享ticket，并且是否可以自動進行ticket共享？

　　Beta測試在兩個重要方面不同于PoC。首先，使用生產防火墻在生產網絡上進行Beta測試。其次，一定程度的擴展很重要，這意味著您需要為服務提供商和支持用戶的周圍流程提供足夠的負載。這將確定它們在服務需求量增大時是否能夠滿足需求。

　　如果您嘗試將用戶從舊技術轉移到新技術，則Beta測試可能會具有挑戰(zhàn)性，因為系統(tǒng)之間可能不兼容。選擇一個主要在該組內進行協(xié)作的組（例如，部門或具有共同語言的地理區(qū)域）。這將有助于最小化跨組協(xié)作需求，并使Beta團隊獲得成功。

　　在Beta測試期間，我們正在尋找PoC中未出現(xiàn)的問題，因為我們的規(guī)模不足。例如，筆記本電腦的電源不足或與新解決方案不兼容的舊版OS軟件。耳機和免提電話是另一個面臨集成挑戰(zhàn)的領域，尤其是當用戶在多個應用程序上使用他們的耳機并從一個切換到另一個時。房間系統(tǒng)的兼容性可能已在PoC期間進行了測試，但可能還有一些較舊的系統(tǒng)或未經測試的供賣方使用的系統(tǒng)仍在使用。團隊中可能還存在一些用例或功能，但新解決方案中沒有這些用例或功能，無法復制它們。而且還會有更多。如果我們能夠預測它們全部，我們將在此階段之前解決它們。此步驟是在將解決方案推廣到整個公司之前，找出未解決的問題并解決它們。

　　隨著過渡的進行，請了解您不了解的內容，并且過渡過程肯定會為您找到這些問題。知道會出現(xiàn)問題后，為用戶和支持團隊制定介入流程，因此可以及早發(fā)現(xiàn)問題并迅速解決。這種方法看起來很像一個敏捷的開發(fā)過程，需要頻繁召開會議，確定問題，根據(jù)受影響的用戶數(shù)量（或用戶等級）確定優(yōu)先級，并在下一個時間段內解決這些問題的分配（例如下一個24小時）。

　　分析是確保取得進展且問題不會拖延的關鍵。看板是一個有用的工具。使用此面板，您可以保留所有列出的主題，并確定哪些主題可以等待，哪些主題需要立即關注。將團隊排在前25位的優(yōu)先級通常意味著沒有任務要完成，因此應對前三位進行處理，然后在第二天再進行研究。

　　使用相同的過程來確定每個期間內打開，關閉或未清算的ticket數(shù)量以及每個ticket已打開多長時間。隨著時間的推移繪制此數(shù)據(jù)，并使用它來確定何時需要更多的支持資源，以及何時可以重新分配它們，因為隨著系統(tǒng)的成熟和用戶的適應，問題正在減少。并行跟蹤用戶的采用情況，以確保支持電話的減少與使用率的下降不匹配。

　　計劃周密且得到良好支持的過渡將收獲按采用率衡量的大筆紅利，提高員工的生產率，縮短實現(xiàn)價值的時間，縮短解決方案的ROI以及實現(xiàn)這一目標的積極IT團隊的積極可見性。

　　作者：約翰·巴特利特（John Barlett）

　　原文網址：https://www.nojitter.com/team-collaboration-tools-workspaces/keys-transitioning-cloud-service-effectively%20