UCaaS-implementering: trinn, tidslinje og vanlige fallgruver

Introduksjon

De fleste UCaaS-prosjekter mislykkes ikke fordi plattformen var feil valg.

De mislykkes på grunn av den samme håndfull unngåelige feilene: en porteringsdato som glipper, en nødadressepost som ikke samsvarer med det nye systemet, eller en nøkkelmedarbeider som oppdager at en funksjon mangler to dager etter at det gamle telefonsystemet allerede er slått av.

UCaaS-implementering er prosessen med å planlegge, konfigurere, teste og rulle ut en Unified Communications as a Service-plattform for å erstatte eller supplere en bedrifts eksisterende telefon- og samarbeidsverktøy, og gjort godt,

den følger en definert sekvens av faser i stedet for en enkelt cutover-helg.

Denne veiledningen dekker hva implementering faktisk innebærer, de seks fasene de fleste migrasjoner følger, realistiske tidslinjer etter bedriftsstørrelse, de tekniske kontrollene som forhindrer tidlige problemer, fallgruvene som avsporer ellers godt planlagte prosjekter,

og hvordan få ansatte til å faktisk bruke det nye systemet når det er live.

Hva innebærer "UCaaS-implementering" egentlig?

UCaaS-implementering dekker alt mellom å signere en kontrakt og å ha en virksomhet i full drift på den nye plattformen: vurdere gjeldende telefon- og nettverksinfrastruktur, konfigurere det nye systemet for å matche hvordan virksomheten faktisk opererer, portering av eksisterende telefonnumre,

testing av oppsettet før noen er avhengig av det, opplæring av ansatte og avskjæring fra det gamle systemet.

Det er et prosjekt med en start- og sluttdato, ikke en enkelt installasjon. Bedrifter som behandler det som å snu en bryter har en tendens til å være de som havner i fallgruvene lenger ned.

Hva er de 6 fasene av en UCaaS-implementering?

De fleste veldrevne UCaaS-migrasjoner følger den samme seksfasestrukturen, uavhengig av leverandør:

1. 1Oppdagelse og vurdering — revidere gjeldende telefonsystemer, nettverkskapasitet, samtalevolumer og hvilke funksjoner ulike team faktisk er avhengige av
2. 2Design og konfigurasjon — sette opp samtaleruting, utvidelser, talepost og integrasjoner for å matche hvordan virksomheten opererer i dag
3. 3Pilotutplassering — å rulle det nye systemet ut til en liten gruppe brukere først, i stedet for hele selskapet på en gang
4. 4Parallell testing — kjører det nye systemet sammen med det gamle kort, slik at problemer dukker opp før det gamle systemet tas ut av drift
5. 5Kutt i produksjonen — bytte hele organisasjonen over, vanligvis tidsbestemt for en periode med lavere volum som en helg
6. 6Optimalisering etter migrering – justere konfigurasjoner, omskolere der det er nødvendig, og fikse problemer som bare dukker opp under ekte daglig bruk

Å hoppe over pilot- eller parallelltestfasen for å spare tid er en av de vanligste måtene et ellers godt planlagt prosjekt får problemer senere.

Hvor lang tid tar en UCaaS-implementering?

Tidslinjer varierer betydelig etter bedriftsstørrelse og kompleksiteten til det eksisterende oppsettet, alt fra noen få uker til flere måneder.

Som et referansepunkt tar en veldrevet implementering for en virksomhet med rundt 50 personer vanligvis seks til ti uker fra kontraktsignering til en ren cutover.

Større organisasjoner, bedrifter med flere lokasjoner eller de med store integreringskrav til CRM-er eller andre forretningssystemer bør forvente en lengre rullebane.

Å skynde seg denne tidslinjen for å finne en vilkårlig startdato er en vanlig kilde til fallgruvene som dekkes nedenfor, spesielt hoppet over testing og undertrent personale.

Hvilke tekniske krav bør kontrolleres før migrering?

Nettverksberedskap er ikke valgfritt, og det er et av trinnene som oftest hoppes over i en forhastet implementering. Før du migrerer, bør en bedrift bekrefte:

• Båndbredde er tilstrekkelig til å håndtere forventet samtale- og videovolum uten å konkurrere med annen nettverkstrafikk
• Tjenestekvalitet (QoS) konfigurasjon er på plass for å prioritere tale- og videopakker fremfor mindre tidssensitiv trafikk
• Latens holder seg innenfor akseptable områder for sanntidsanrop, siden selv små forsinkelser er merkbare på en direkte samtale
• Fysisk maskinvare, der den fortsatt brukes, har faktisk blitt testet under ekte nettverksforhold i stedet for bare plugget inn og antatt å fungere

Å hoppe over disse kontrollene er grunnen til at noen UCaaS-utrullinger får klager på anropskvalitet nesten umiddelbart etter lansering, selv når selve plattformen fungerer akkurat som designet.

Hva er de vanligste UCaaS-implementeringsfellene?

Den samme håndfullen feil står for de fleste UCaaS-implementeringene som får alvorlige problemer:

• Porteringsdatoer slips, forlate en bedrift midlertidig uten hovedtelefonnummeret eller kjøre to systemer lenger enn planlagt
• E911-adressepostene samsvarer ikke det nye systemet, og skaper et sikkerhetshull hvis noen trenger å tilkalle nødhjelp fra et nytt tillegg
• Nøkkelbrukere oppdager manglende funksjoner bare etter at det gamle systemet allerede er slått av, uten mulighet til å gå tilbake raskt
• Håndsett og softphones er ikke testet under reelle nettverksforhold før cutover, og dukker opp problemer med samtalekvaliteten på dag én
• Trening skjer én gang, rett før start, i stedet for å fortsette etter at systemet faktisk er i daglig bruk

De fleste av disse kan unngås med den trinnvise tilnærmingen og de tekniske kontrollene som er dekket ovenfor; de har en tendens til å skje når et prosjekt haster for å nå en tidsfrist i stedet for et kapasitetsgap i selve plattformen.

Hvordan får du ansatte til å faktisk adoptere en ny UCaaS-plattform?

En rapport fra Tangoe fant at bare 39 % av IT-beslutningstakerne følte at UCaaS-investeringene deres leverte fullt ut på kostnadsbesparelsene og administrasjonsfordelene de forventet, og svak bruk er en vanlig årsak til dette.

Ansattes motstand mot en ny kommunikasjonsplattform er en av de største adopsjonshindrene, spesielt blant team som er komfortable med eldre verktøy.

Å overvinne det krever mer enn en enkelt treningsøkt: lederskap må synlig bruke og forkjempe den nye plattformen, og IT-team bør gi kontinuerlig, rollespesifikk støtte i stedet for å behandle opplæring som en engangshendelse før den settes i gang.

Å ramme endringen rundt hva som faktisk er enklere for hver enkelt ansatts daglige jobb, ikke bare hvordan det nye systemet teknisk fungerer, har en tendens til å flytte adopsjonen lenger enn lengden på selve opplæringen.

Å pilotere med en liten gruppe før en full utrulling gir også en bedrift en sjanse til å fikse forvirrende arbeidsflyter før de når alle.

Følger Ringflows onboarding samme prosess?

Den underliggende disiplinen fortsetter selv om Ringflow ikke er en UCaaS-plattform.

Setter opp Anropsruting og tilkobling av eksisterende systemer drar fortsatt nytte av en gradvis utrulling, en pilotgruppe før full distribusjon, og samme type kontroll av nettverksberedskap som betyr noe for enhver skykommunikasjonsplattform. Hvor det er forskjellig er omfanget:

Ringflow-implementeringer fokuserer på kundevendte samtaleflyter, kampanjeruting og CRM-integrasjoner i stedet for å erstatte en intern PBX eller migrere ansatttillegg,

så oppdagelsesfasen fokuserer mer på hvordan et salgs- eller støtteteam faktisk håndterer samtaler i dag enn på nødadresseoppføringer eller bordtelefonbeholdning.

Bredere adopsjonsutfordringer som disse er dokumentert i Meridian ITsin forskning på vanlige UCaaS-utrullingshindringer, som gjenspeiler den samme pilot-første, pågående opplæringstilnærmingen som er skissert ovenfor.

Konklusjon

En UCaaS-implementering lykkes eller sliter basert på disiplin mer enn teknologi: om prosjektet går gjennom pilottesting og parallell drift før cutover, om nettverksberedskapen blir sjekket i stedet for antatt, og om treningen fortsetter utover den første uken i stedet for å stoppe ved den.

Plattformene i seg selv er modne nok på dette tidspunktet til at feilene det er verdt å bekymre seg for nesten alltid er prosessfeil, ikke produktfeil.

Ofte stilte spørsmål