소개
대부분의 UCaaS 프로젝트는 플랫폼 선택이 잘못되었기 때문에 실패하지 않습니다. 피할 수 있는 몇 가지 실수로 인해 실패합니다. 이동 날짜가 늦어지거나, 긴급 주소 기록이 새 시스템과 일치하지 않거나, 기능을 발견한 주요 직원이 기존 전화 시스템이 이미 꺼진 지 이틀 후에 누락되는 등의 실수로 인해 실패합니다. UCaaS 구현은 기업의 기존 전화 및 협업 도구를 교체하거나 보완하기 위해 서비스형 통합 커뮤니케이션 플랫폼을 계획, 구성, 테스트 및 롤아웃하는 프로세스이며, 잘 수행되면 단일 컷오버 주말이 아닌 정의된 일련의 단계를 따릅니다. 이 가이드에서는 실제로 구현에 포함되는 내용, 대부분의 마이그레이션에 따르는 6단계, 회사 규모에 따른 현실적인 일정, 초기 문제를 방지하는 기술 점검, 잘 계획된 프로젝트를 탈선시키는 함정, 새 시스템이 출시된 후 직원들이 실제로 새 시스템을 사용하도록 하는 방법을 다룹니다.
"UCaaS 구현"에는 실제로 무엇이 포함됩니까?
UCaaS 구현은 계약 체결부터 새 플랫폼에서 비즈니스를 완전히 운영하는 것까지의 모든 작업을 다룹니다. 즉, 현재 전화 및 네트워크 인프라 평가, 비즈니스 실제 운영 방식에 맞게 새 시스템 구성, 기존 전화번호 이식, 다른 사람이 사용하기 전에 설정 테스트, 직원 교육, 기존 시스템 전환 등이 포함됩니다.
단일 설치가 아닌 시작 날짜와 종료 날짜가 있는 프로젝트입니다. 이를 마치 스위치를 켜는 것처럼 취급하는 기업은 더 아래에 있는 함정에 빠지는 경향이 있습니다.
UCaaS 구현의 6단계는 무엇입니까?
잘 실행되는 대부분의 UCaaS 마이그레이션은 공급업체에 관계없이 동일한 6단계 구조를 따릅니다.
- 1발견 및 평가 — 현재 전화 시스템, 네트워크 용량, 통화량 및 여러 팀이 실제로 의존하는 기능을 감사합니다.
- 2디자인 및 구성 — 현재 비즈니스 운영 방식에 맞게 통화 라우팅, 내선 번호, 음성 메일 및 통합 설정
- 3파일럿 배포 — 한 번에 회사 전체가 아닌 소규모 사용자 그룹에게 먼저 새 시스템을 배포합니다.
- 4병렬 테스트 — 이전 시스템과 함께 새 시스템을 잠시 실행하므로 이전 시스템이 폐기되기 전에 문제가 표면화됩니다.
- 5생산 컷오버 — 일반적으로 주말과 같이 작업량이 적은 기간에 맞춰 전체 조직을 전환합니다.
- 6마이그레이션 후 최적화 — 구성 조정, 필요한 경우 재교육, 실제 일상 사용에서만 나타나는 문제 해결
시간을 절약하기 위해 파일럿 또는 병렬 테스트 단계를 건너뛰는 것은 잘 계획된 프로젝트가 나중에 문제에 부딪히는 가장 일반적인 방법 중 하나입니다.
UCaaS 구현에 시간이 얼마나 걸리나요?
일정은 회사 규모와 기존 설정의 복잡성에 따라 몇 주에서 몇 달까지 크게 다릅니다. 참고로, 약 50명 규모의 기업에서 잘 실행되는 구현은 일반적으로 계약 체결부터 완전한 전환까지 6~10주가 걸립니다. 대규모 조직, 여러 위치에 있는 기업 또는 CRM이나 기타 비즈니스 시스템에 대한 통합 요구 사항이 높은 기업은 더 긴 활주로를 기대해야 합니다.
임의의 출시 날짜를 맞추기 위해 이 일정을 서두르는 것은 아래에서 다루는 함정의 일반적인 원인이며, 특히 테스트를 건너뛰고 직원의 교육이 부족합니다.
마이그레이션하기 전에 어떤 기술 요구 사항을 확인해야 합니까?
네트워크 준비는 선택 사항이 아니며, 급하게 구현하는 과정에서 가장 일반적으로 건너뛰는 단계 중 하나입니다. 마이그레이션하기 전에 기업은 다음을 확인해야 합니다.
- 대역폭 다른 네트워크 트래픽과 경쟁하지 않고 예상되는 통화 및 비디오 볼륨을 처리하기에 충분합니다.
- 서비스 품질(QoS) 시간에 덜 민감한 트래픽보다 음성 및 비디오 패킷의 우선 순위를 지정하도록 구성되어 있습니다.
- 숨어 있음 실시간 통화에서는 약간의 지연도 눈에 띄기 때문에 실시간 통화가 허용되는 범위 내에 유지됩니다.
- 물리적 하드웨어, 여전히 사용되는 곳은 플러그를 꽂고 작동한다고 가정하는 것이 아니라 실제 네트워크 조건에서 실제로 테스트되었습니다.
이러한 검사를 건너뛰는 것은 플랫폼 자체가 설계된 대로 정확하게 작동하는 경우에도 일부 UCaaS 출시가 출시 직후 통화 품질 불만 사항을 발생시키는 이유입니다.
가장 일반적인 UCaaS 구현 문제는 무엇입니까?
심각한 문제를 일으키는 대부분의 UCaaS 구현에서는 동일한 소수의 실수가 발생합니다.
- 포팅 날짜가 늦어졌습니다., 대표 전화번호 없이 일시적으로 사업장을 떠나거나 두 시스템을 계획보다 오랫동안 운영하는 경우
- E911 주소 레코드가 일치하지 않습니다. 새로운 시스템으로 인해 누군가가 새로운 내선 번호에 긴급 지원을 요청해야 하는 경우 안전 공백이 발생합니다.
- 주요 사용자가 누락된 기능을 발견함 기존 시스템이 이미 종료된 후에만 신속하게 되돌릴 수 있는 방법이 없습니다.
- 핸드셋과 소프트폰은 테스트되지 않았습니다. 컷오버 전 실제 네트워크 조건에서 첫날부터 통화 품질 문제가 발생함
- 훈련은 한 번만 이루어집니다., 시스템이 실제로 일상적으로 사용된 후 계속하는 대신 가동 직전
이들 중 대부분은 위에서 다룬 단계적 접근 방식과 기술 점검을 통해 방지할 수 있습니다. 이러한 문제는 플랫폼 자체의 역량 격차보다는 프로젝트가 마감일에 도달하기 위해 서두르게 될 때 발생하는 경향이 있습니다.
직원들이 실제로 새로운 UCaaS 플랫폼을 채택하도록 하려면 어떻게 해야 합니까?
Tangoe의 보고서에 따르면 IT 의사 결정자의 39%만이 UCaaS 투자를 통해 예상했던 비용 절감 및 관리 용이성 혜택이 완전히 구현되었다고 느꼈으며, 채택률이 낮은 것이 일반적인 이유입니다.
새로운 커뮤니케이션 플랫폼에 대한 직원의 저항은 특히 레거시 도구에 익숙한 팀 사이에서 가장 큰 채택 장애물 중 하나입니다. 이를 극복하려면 단일 교육 세션 이상이 필요합니다. 리더십은 새로운 플랫폼을 눈에 띄게 사용하고 옹호해야 하며, IT 팀은 교육을 실행 전 일회성 이벤트로 처리하기보다는 지속적인 역할별 지원을 제공해야 합니다. 새로운 시스템이 기술적으로 작동하는 방식뿐만 아니라 각 직원의 일상 업무에서 실제로 더 쉬운 것이 무엇인지 중심으로 변화를 구성하면 교육 자체의 기간보다 채택이 더 많이 진행되는 경향이 있습니다. 전체 출시 전에 소규모 그룹을 대상으로 시험해 보면 기업에서는 혼란스러운 워크플로가 모든 사람에게 도달하기 전에 수정할 수 있는 기회를 얻을 수 있습니다.
Ringflow의 온보딩은 동일한 프로세스를 따르나요?
Ringflow가 UCaaS 플랫폼이 아니더라도 기본 원칙은 그대로 유지됩니다. 설정 중 통화 라우팅 기존 시스템을 연결하면 단계적 롤아웃, 전체 배포 전 파일럿 그룹, 모든 클라우드 통신 플랫폼에 중요한 동일한 종류의 네트워크 준비 상태 확인 등의 이점을 얻을 수 있습니다. 범위가 다른 경우: Ringflow 구현은 고객과의 통화 흐름, 캠페인 라우팅 및 CRM 통합 내부 PBX를 교체하거나 직원 내선 번호를 마이그레이션하는 대신 검색 단계에서는 비상 주소 기록이나 사무실 전화 목록보다는 현재 영업 또는 지원 팀이 실제로 통화를 처리하는 방법에 더 중점을 둡니다.
이와 같은 광범위한 채택 문제는 다음 문서에 문서화되어 있습니다. 메리디안 IT일반적인 UCaaS 출시 장애물에 대한 의 연구는 위에서 설명한 것과 동일한 파일럿 우선, 지속적인 교육 접근 방식을 반영합니다.
결론
UCaaS 구현은 기술보다 규율을 기반으로 성공하거나 어려움을 겪습니다. 즉, 프로젝트가 컷오버 전 파일럿 테스트 및 병렬 작업을 통해 실행되는지, 네트워크 준비 상태를 가정하는 대신 확인하는지, 훈련이 중단되지 않고 첫 주를 지나도록 계속되는지 여부입니다. 이 시점에서 플랫폼 자체는 충분히 성숙하여 걱정할만한 실패는 거의 항상 제품 실패가 아닌 프로세스 실패입니다.
당신이 준비되면
커뮤니케이션 플랫폼 출시를 계획 중이신가요?
Ringflow의 Cloud Contact Center 및 AI Sales Platform이 고객 응대 통화 흐름 및 CRM 연결 팀을 위한 단계별 온보딩에 어떻게 접근하는지 알아보세요.
자주 묻는 질문
일반적인 UCaaS 구현은 검색 및 평가, 설계 및 구성, 소규모 사용자 그룹을 통한 파일럿 배포, 기존 시스템과 함께 병렬 테스트, 프로덕션 컷오버, 마이그레이션 후 최적화 등 6단계를 따릅니다. 파일럿 또는 병렬 테스트 단계를 건너뛰는 것은 구현에 문제가 발생하는 가장 일반적인 이유 중 하나입니다.
일정은 회사 규모와 복잡성에 따라 몇 주에서 몇 달까지 다양합니다. 대략 50명 규모의 기업에서 제대로 실행되는 구현은 일반적으로 계약 체결부터 완전한 컷오버까지 6~10주가 소요되지만 규모가 크거나 복잡한 조직에서는 더 오랜 시간이 소요됩니다.
가장 일반적인 원인은 날짜가 누락된 번호 이동, 새 시스템과 일치하지 않는 E911 주소 기록, 기존 전화 시스템이 이미 종료된 후에야 누락된 기능을 발견하는 핵심 직원, 가동 전 실제 네트워크 조건에서 테스트되지 않은 핸드셋 등입니다.
반드시 그런 것은 아닙니다. 현재 대부분의 배포에서는 직원의 기존 컴퓨터나 모바일 장치에 있는 앱을 사용하여 소프트폰 우선으로 진행되며 물리적 데스크폰은 모든 직원이 아닌 리셉션 구역과 회의실용으로 주로 예약되어 있습니다.
리더십이 새로운 플랫폼을 눈에 띄게 옹호하고 단일 온보딩 세션이 아닌 역할별 교육이 진행 중일 때 채택률이 향상됩니다. 시스템 작동 방식뿐만 아니라 각 직원의 일상 업무에 대해 실제로 더 쉬운 것이 무엇인지 중심으로 교육을 구성하는 것이 교육 기간보다 더 중요한 경향이 있습니다.
음성 트래픽을 염두에 두고 구축되지 않은 네트워크에서는 통화 품질이 빠르게 저하되므로 마이그레이션 전에 대역폭, 서비스 품질 구성 및 대기 시간을 모두 확인해야 합니다. 이 단계를 건너뛰는 것은 UCaaS 출시 초기에 통화 품질 불만이 발생하는 가장 일반적인 이유 중 하나입니다.
Ringflow가 UCaaS 제품이 아닌 클라우드 컨택 센터 및 AI 판매 플랫폼임에도 불구하고 기본 원칙은 유사하며 단계적 롤아웃, 전체 배포 전 파일럿 테스트 및 네트워크 준비 상태 확인입니다. Ringflow 구현은 내부 PBX를 교체하는 대신 고객과의 통화 흐름 및 라우팅에 중점을 두기 때문에 범위가 다릅니다.
