Implémentation d'UCaaS : étapes, calendrier et pièges courants

Introduction

La plupart des projets UCaaS n’échouent pas parce que la plateforme n’a pas été le bon choix. Ils échouent à cause de la même poignée d'erreurs évitables : une date de portage qui glisse, un enregistrement d'adresse d'urgence qui ne correspond pas au nouveau système, ou un employé clé qui découvre qu'une fonctionnalité est manquante deux jours après que l'ancien système téléphonique est déjà éteint. La mise en œuvre d'UCaaS est le processus de planification, de configuration, de test et de déploiement d'une plateforme de communications unifiées en tant que service pour remplacer ou compléter les outils téléphoniques et de collaboration existants d'une entreprise. Bien réalisée, elle suit une séquence définie de phases plutôt qu'un seul week-end de transition. Ce guide couvre ce qu'implique réellement la mise en œuvre, les six phases suivies par la plupart des migrations, des délais réalistes en fonction de la taille de l'entreprise, les contrôles techniques qui évitent les premiers problèmes, les pièges qui font dérailler des projets par ailleurs bien planifiés et comment amener les employés à utiliser réellement le nouveau système une fois qu'il est opérationnel.

Qu’implique réellement la « mise en œuvre d’UCaaS » ?

La mise en œuvre d'UCaaS couvre tout, entre la signature d'un contrat et le fonctionnement complet d'une entreprise sur la nouvelle plate-forme : évaluer l'infrastructure téléphonique et réseau actuelle, configurer le nouveau système pour qu'il corresponde au fonctionnement réel de l'entreprise, porter les numéros de téléphone existants, tester la configuration avant que quiconque n'en dépende, former les employés et passer de l'ancien système.

C'est un projet avec une date de début et de fin, pas une seule installation. Les entreprises qui traitent cela comme si on actionnait un interrupteur ont tendance à être celles qui se heurtent aux pièges évoqués plus loin.

Quelles sont les 6 phases d’une mise en œuvre UCaaS ?

La plupart des migrations UCaaS bien gérées suivent la même structure en six phases, quel que soit le fournisseur :

1. 1Découverte et évaluation — auditer les systèmes téléphoniques actuels, la capacité du réseau, les volumes d'appels et les fonctionnalités sur lesquelles les différentes équipes s'appuient réellement
2. 2Conception et configuration — configuration du routage des appels, des extensions, de la messagerie vocale et des intégrations pour correspondre au fonctionnement actuel de l'entreprise
3. 3Déploiement pilote — déployer le nouveau système d'abord auprès d'un petit groupe d'utilisateurs, plutôt que dans l'ensemble de l'entreprise en même temps
4. 4Tests parallèles — faire fonctionner brièvement le nouveau système parallèlement à l'ancien, afin que des problèmes surviennent avant que l'ancien système ne soit mis hors service
5. 5Arrêt de production — changement de l'organisation complète, généralement programmé pour une période de moindre volume comme un week-end
6. 6Optimisation post-migration - ajuster les configurations, recycler si nécessaire et résoudre les problèmes qui n'apparaissent que dans le cadre d'une utilisation réelle au quotidien

Sauter les phases pilotes ou de tests parallèles pour gagner du temps est l'une des façons les plus courantes pour un projet par ailleurs bien planifié de se heurter à des problèmes plus tard.

Combien de temps prend la mise en œuvre d’un UCaaS ?

Les délais varient considérablement selon la taille de l’entreprise et la complexité de la configuration existante, allant de quelques semaines à plusieurs mois. À titre de référence, une mise en œuvre bien gérée pour une entreprise d’environ 50 personnes prend généralement six à dix semaines entre la signature du contrat et un basculement net. Les grandes organisations, les entreprises possédant plusieurs sites ou celles ayant de lourdes exigences d'intégration dans les CRM ou d'autres systèmes d'entreprise doivent s'attendre à un parcours plus long.

Précipiter ce calendrier pour atteindre une date de mise en service arbitraire est une source courante des pièges évoqués ci-dessous, en particulier des tests ignorés et un personnel sous-formé.

Quelles exigences techniques doivent être vérifiées avant la migration ?

La préparation du réseau n'est pas facultative et constitue l'une des étapes les plus souvent ignorées lors d'une mise en œuvre précipitée. Avant de migrer, une entreprise doit confirmer :

• Bande passante est suffisant pour gérer le volume d'appels et de vidéo attendu sans concurrencer le reste du trafic réseau
• Qualité de service (QoS) la configuration est en place pour donner la priorité aux paquets voix et vidéo par rapport au trafic moins sensible au temps
• Latence reste dans des plages acceptables pour les appels en temps réel, puisque même de petits retards sont perceptibles lors d'un appel en direct
• Matériel physique, là où il est encore utilisé, a en fait été testé dans des conditions de réseau réelles plutôt que simplement branché et supposé fonctionner

Ignorer ces vérifications est la raison pour laquelle certains déploiements d'UCaaS donnent lieu à des plaintes concernant la qualité des appels presque immédiatement après la mise en service, même lorsque la plateforme elle-même fonctionne exactement comme prévu.

Quels sont les pièges les plus courants de la mise en œuvre d’UCaaS ?

La même poignée d’erreurs explique la plupart des implémentations UCaaS qui rencontrent de sérieux problèmes :

• Bordereau de dates de portage, laissant temporairement une entreprise sans son numéro de téléphone principal ou faisant fonctionner deux systèmes plus longtemps que prévu
• Les enregistrements d'adresse E911 ne correspondent pas le nouveau système, créant une faille de sécurité si quelqu'un doit appeler de l'aide d'urgence depuis une nouvelle extension
• Les utilisateurs clés découvrent des fonctionnalités manquantes seulement après que l'ancien système a déjà été arrêté, sans aucun moyen de revenir rapidement
• Les combinés et les softphones ne sont pas testés dans des conditions de réseau réelles avant le basculement, faisant apparaître des problèmes de qualité d'appel dès le premier jour
• La formation a lieu une fois, juste avant la mise en service, au lieu de continuer une fois que le système est réellement utilisé quotidiennement

La plupart de ces problèmes peuvent être évités grâce à l’approche progressive et aux contrôles techniques évoqués ci-dessus ; ils ont tendance à se produire lorsqu'un projet est précipité pour respecter une date limite plutôt que lorsqu'un manque de capacité dans la plate-forme elle-même.

Comment amener les employés à adopter réellement une nouvelle plateforme UCaaS ?

Un rapport de Tangoe révèle que seulement 39 % des décideurs informatiques estiment que leurs investissements UCaaS ont pleinement porté leurs fruits en termes d'économies de coûts et de facilité de gestion qu'ils attendaient, et la faible adoption en est une raison courante.

La résistance des employés à une nouvelle plateforme de communication est l’un des plus grands obstacles à l’adoption, en particulier parmi les équipes à l’aise avec les outils existants. Pour y parvenir, il faut plus qu'une seule session de formation : les dirigeants doivent visiblement utiliser et défendre la nouvelle plateforme, et les équipes informatiques doivent fournir un soutien continu et spécifique à leur rôle plutôt que de traiter la formation comme un événement ponctuel avant la mise en ligne. Encadrer le changement autour de ce qui est réellement plus facile pour le travail quotidien de chaque employé, et pas seulement du fonctionnement technique du nouveau système, tend à faire progresser l'adoption au-delà de la durée de la formation elle-même. Le pilotage avec un petit groupe avant un déploiement complet donne également à une entreprise la possibilité de corriger les flux de travail déroutants avant qu'ils n'atteignent tout le monde.

L'intégration de Ringflow suit-elle le même processus ?

La discipline sous-jacente perdure même si Ringflow n'est pas une plateforme UCaaS. Mise en place Routage des appels et la connexion des systèmes existants bénéficie toujours d'un déploiement progressif, d'un groupe pilote avant le déploiement complet et du même type de contrôles de préparation du réseau qui sont importants pour toute plate-forme de communication cloud. Là où cela diffère, c'est la portée : les implémentations de Ringflow se concentrent sur les flux d'appels destinés aux clients, le routage des campagnes et Intégrations CRM plutôt que de remplacer un PBX interne ou de migrer les extensions des employés, la phase de découverte se concentre davantage sur la façon dont une équipe de vente ou d'assistance gère réellement les appels aujourd'hui que sur les enregistrements d'adresses d'urgence ou les inventaires de téléphones de bureau.

Des défis d’adoption plus larges comme ceux-ci sont documentés dans Méridien informatiquesur les obstacles courants au déploiement de l'UCaaS, faisant écho à la même approche de formation continue axée sur le pilote d'abord décrite ci-dessus.

Conclusion

Une mise en œuvre d'UCaaS réussit ou connaît des difficultés en fonction de la discipline plutôt que de la technologie : si le projet passe par des tests pilotes et des opérations parallèles avant le basculement, si l'état de préparation du réseau est vérifié au lieu d'être supposé, et si la formation se poursuit au-delà de la première semaine au lieu de s'y arrêter. Les plates-formes elles-mêmes sont suffisamment matures à ce stade pour que les défaillances dont il faut s'inquiéter soient presque toujours des défaillances de processus et non de produits.

Foire aux questions