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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　Beta測試在兩個(gè)重要方面不同于PoC。首先，使用生產(chǎn)防火墻在生產(chǎn)網(wǎng)絡(luò )上進(jìn)行Beta測試。其次，一定程度的擴展很重要，這意味著(zhù)您需要為服務(wù)提供商和支持用戶(hù)的周?chē)�流程提供足夠的負載。這將確定它們在服務(wù)需求量增大時(shí)是否能夠滿(mǎn)足需求。

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

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

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

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

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

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

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

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