Triển khai UCaaS: Các bước, dòng thời gian và những cạm bẫy thường gặp

Giới thiệu

Hầu hết các dự án UCaaS không thất bại vì nền tảng đã được lựa chọn sai lầm. Họ thất bại vì cùng một số lỗi có thể tránh được: ngày chuyển bị trượt, bản ghi địa chỉ khẩn cấp không khớp với hệ thống mới hoặc nhân viên chủ chốt phát hiện ra một tính năng bị thiếu hai ngày sau khi hệ thống điện thoại cũ đã tắt. Triển khai UCaaS là ​​quá trình lập kế hoạch, định cấu hình, thử nghiệm và triển khai Truyền thông hợp nhất dưới dạng nền tảng Dịch vụ để thay thế hoặc bổ sung cho điện thoại và các công cụ cộng tác hiện có của doanh nghiệp và được thực hiện tốt, nó tuân theo một chuỗi các giai đoạn xác định thay vì một ngày cuối tuần chuyển tiếp duy nhất. Hướng dẫn này đề cập đến những gì việc triển khai thực sự liên quan, sáu giai đoạn mà hầu hết các lần di chuyển đều tuân theo, các mốc thời gian thực tế theo quy mô công ty, các kiểm tra kỹ thuật nhằm ngăn chặn các sự cố ban đầu, các cạm bẫy làm chệch hướng các dự án đã được lên kế hoạch tốt và cách khiến nhân viên thực sự sử dụng hệ thống mới khi nó đi vào hoạt động.

"Triển khai UCaaS" thực sự liên quan đến điều gì?

Việc triển khai UCaaS bao gồm mọi thứ từ việc ký hợp đồng đến việc cho một doanh nghiệp chạy hoàn toàn trên nền tảng mới: đánh giá cơ sở hạ tầng mạng và điện thoại hiện tại, định cấu hình hệ thống mới để phù hợp với cách doanh nghiệp thực sự vận hành, chuyển số điện thoại hiện có, kiểm tra thiết lập trước khi bất kỳ ai phụ thuộc vào nó, đào tạo nhân viên và loại bỏ hệ thống cũ.

Đó là một dự án có ngày bắt đầu và ngày kết thúc, không phải một lần cài đặt nào. Những doanh nghiệp coi việc này giống như bật công tắc thường là những doanh nghiệp gặp phải những cạm bẫy được đề cập ở phần dưới.

6 giai đoạn triển khai UCaaS là ​​gì?

Hầu hết quá trình di chuyển UCaaS được thực hiện tốt đều tuân theo cấu trúc sáu giai đoạn giống nhau, bất kể nhà cung cấp:

1. 1Khám phá và đánh giá — kiểm tra các hệ thống điện thoại hiện tại, dung lượng mạng, số lượng cuộc gọi và những tính năng mà các nhóm khác nhau thực sự dựa vào
2. 2Thiết kế và cấu hình — thiết lập định tuyến cuộc gọi, tiện ích mở rộng, thư thoại và tích hợp để phù hợp với cách hoạt động của doanh nghiệp ngày nay
3. 3Triển khai thí điểm — trước tiên triển khai hệ thống mới cho một nhóm nhỏ người dùng, thay vì toàn bộ công ty cùng một lúc
4. 4Kiểm tra song song — chạy hệ thống mới song song với hệ thống cũ trong thời gian ngắn, do đó các vấn đề sẽ xuất hiện trước khi hệ thống cũ ngừng hoạt động
5. 5Cắt giảm sản xuất — chuyển đổi toàn bộ tổ chức, thường được tính cho khoảng thời gian có khối lượng thấp hơn như cuối tuần
6. 6Tối ưu hóa sau di chuyển — điều chỉnh cấu hình, đào tạo lại khi cần thiết và khắc phục các sự cố chỉ xuất hiện khi sử dụng thực tế hàng ngày

Bỏ qua giai đoạn thử nghiệm hoặc thử nghiệm song song để tiết kiệm thời gian là một trong những cách phổ biến nhất mà một dự án được lên kế hoạch tốt sẽ gặp rắc rối sau này.

Quá trình triển khai UCaaS mất bao lâu?

Các mốc thời gian thay đổi đáng kể tùy theo quy mô công ty và mức độ phức tạp của quá trình thiết lập hiện tại, dao động từ vài tuần đến vài tháng. Như một điểm tham chiếu, việc triển khai tốt cho một doanh nghiệp khoảng 50 người thường mất từ ​​sáu đến mười tuần kể từ khi ký hợp đồng cho đến khi chuyển giao hoàn toàn. Các tổ chức lớn hơn, doanh nghiệp có nhiều địa điểm hoặc những tổ chức có yêu cầu tích hợp cao vào CRM hoặc các hệ thống kinh doanh khác sẽ có lộ trình dài hơn.

Việc đẩy nhanh tiến độ này để đạt được ngày đưa vào hoạt động tùy ý là nguyên nhân phổ biến gây ra những cạm bẫy được đề cập dưới đây, đặc biệt là việc bỏ qua quá trình kiểm tra và nhân viên chưa được đào tạo bài bản.

Những yêu cầu kỹ thuật nào cần được kiểm tra trước khi di chuyển?

Sự sẵn sàng của mạng không phải là tùy chọn và đó là một trong những bước thường bị bỏ qua nhất khi triển khai gấp rút. Trước khi di chuyển, doanh nghiệp nên xác nhận:

• Băng thông đủ để xử lý khối lượng cuộc gọi và video dự kiến ​​mà không cạnh tranh với lưu lượng mạng khác
• Chất lượng dịch vụ (QoS) đã có sẵn cấu hình để ưu tiên các gói thoại và video hơn lưu lượng truy cập ít nhạy cảm với thời gian hơn
• Độ trễ luôn nằm trong phạm vi có thể chấp nhận được đối với cuộc gọi theo thời gian thực, vì ngay cả độ trễ nhỏ cũng có thể nhận thấy được trong cuộc gọi trực tiếp
• Phần cứng vật lý, nơi nó vẫn được sử dụng, thực sự đã được thử nghiệm trong điều kiện mạng thực thay vì chỉ cắm vào và cho là hoạt động

Việc bỏ qua các bước kiểm tra này là lý do khiến một số đợt triển khai UCaaS gặp phải khiếu nại về chất lượng cuộc gọi gần như ngay lập tức sau khi đi vào hoạt động, ngay cả khi bản thân nền tảng này đang hoạt động chính xác như thiết kế.

Những cạm bẫy triển khai UCaaS phổ biến nhất là gì?

Một số lỗi tương tự gây ra hầu hết việc triển khai UCaaS gặp rắc rối nghiêm trọng:

• Phiếu ngày chuyển, tạm thời khiến doanh nghiệp không có số điện thoại chính hoặc chạy hai hệ thống lâu hơn dự định
• Bản ghi địa chỉ E911 không khớp hệ thống mới, tạo ra khoảng cách an toàn nếu ai đó cần gọi trợ giúp khẩn cấp từ tiện ích mở rộng mới
• Người dùng chính khám phá các tính năng còn thiếu chỉ sau khi hệ thống cũ đã bị tắt và không có cách nào để hoàn nguyên nhanh chóng
• Thiết bị cầm tay và điện thoại mềm chưa được kiểm tra trong điều kiện mạng thực tế trước khi chuyển đổi, giải quyết các vấn đề về chất lượng cuộc gọi ngay ngày đầu tiên
• Quá trình đào tạo diễn ra một lần, ngay trước khi đi vào hoạt động, thay vì tiếp tục sau khi hệ thống thực sự được sử dụng hàng ngày

Hầu hết những điều này đều có thể tránh được bằng cách tiếp cận theo từng giai đoạn và kiểm tra kỹ thuật được đề cập ở trên; chúng có xu hướng xảy ra khi một dự án được gấp rút hoàn thành thời hạn thay vì khoảng cách về năng lực trong chính nền tảng.

Làm cách nào để khiến nhân viên thực sự áp dụng Nền tảng UCaaS mới?

Một báo cáo từ Tangoe cho thấy chỉ 39% những người ra quyết định về CNTT cảm thấy khoản đầu tư UCaaS của họ mang lại đầy đủ lợi ích tiết kiệm chi phí và dễ quản lý mà họ mong đợi và việc áp dụng yếu là lý do phổ biến.

Sự phản đối của nhân viên đối với nền tảng truyền thông mới là một trong những rào cản lớn nhất trong việc áp dụng, đặc biệt là giữa các nhóm thoải mái với các công cụ cũ. Để vượt qua nó cần nhiều hơn một buổi đào tạo: lãnh đạo cần sử dụng và ủng hộ nền tảng mới một cách rõ ràng, đồng thời các nhóm CNTT nên cung cấp hỗ trợ liên tục, theo vai trò cụ thể thay vì coi đào tạo là sự kiện một lần trước khi đi vào hoạt động. Định hình sự thay đổi xung quanh những gì thực sự dễ dàng hơn đối với công việc hàng ngày của mỗi nhân viên, chứ không chỉ cách hệ thống mới hoạt động về mặt kỹ thuật, có xu hướng thúc đẩy việc áp dụng xa hơn thời gian đào tạo. Việc thử nghiệm với một nhóm nhỏ trước khi triển khai đầy đủ cũng mang lại cho doanh nghiệp cơ hội khắc phục các quy trình làm việc khó hiểu trước khi chúng tiếp cận tất cả mọi người.

Việc giới thiệu Ringflow có tuân theo quy trình tương tự không?

Kỷ luật cơ bản vẫn được áp dụng ngay cả khi Ringflow không phải là nền tảng UCaaS. Đang thiết lập Định tuyến cuộc gọi và việc kết nối các hệ thống hiện có vẫn được hưởng lợi từ việc triển khai theo từng giai đoạn, một nhóm thử nghiệm trước khi triển khai đầy đủ và cùng một loại kiểm tra mức độ sẵn sàng của mạng vốn quan trọng đối với bất kỳ nền tảng truyền thông đám mây nào. Điểm khác biệt nằm ở phạm vi: Việc triển khai Ringflow tập trung vào các luồng cuộc gọi hướng tới khách hàng, định tuyến chiến dịch và Tích hợp CRM thay vì thay thế tổng đài nội bộ hoặc di chuyển tiện ích mở rộng của nhân viên, do đó, giai đoạn khám phá tập trung nhiều hơn vào cách nhóm bán hàng hoặc hỗ trợ thực sự xử lý các cuộc gọi ngày nay hơn là vào bản ghi địa chỉ khẩn cấp hoặc kho điện thoại bàn.

Những thách thức áp dụng rộng hơn như thế này được ghi lại trong CNTT kinh tuyếnnghiên cứu của chúng tôi về những trở ngại phổ biến khi triển khai UCaaS, phản ánh cùng một phương pháp đào tạo liên tục, đầu tiên là thí điểm đã nêu ở trên.

Phần kết luận

Việc triển khai UCaaS thành công hay gặp khó khăn dựa trên kỷ luật hơn là công nghệ: liệu dự án có chạy thử nghiệm thí điểm và vận hành song song trước khi chuyển đổi hay không, liệu mức độ sẵn sàng của mạng có được kiểm tra thay vì giả định hay không và liệu việc đào tạo có tiếp tục qua tuần đầu tiên thay vì dừng lại ở đó hay không. Bản thân các nền tảng tại thời điểm này đã đủ trưởng thành nên những lỗi đáng lo ngại hầu như luôn là lỗi về quy trình chứ không phải lỗi về sản phẩm.

Câu hỏi thường gặp