Lorsque les capacités du service cloud deviennent déjà rares et que la transition vers la version en boîte est considérée comme la prochaine étape logique pour le développement ultérieur du portail d'entreprise et du système CRM, la question se pose pour les entreprises, comment le faire, ce qui les attend et tout sera préservé après le transfert?
Il semblerait que tout soit assez simple:
- Développez l'hôte avec la boîte;
- Nous écrivons le support technique;
- Nous commandons une sauvegarde;
- Nous avons hâte de le recevoir;
- Nous déployons la sauvegarde et profitons des larges possibilités de la version box.
Mais la pratique montre que la transition du cloud à la version boxed est loin d'être anodine et nécessite un plan d'action clair, une analyse des risques possibles et une préparation au fait que tout ira mal.
Nous avons été approchés par un grand développeur avec un système CRM très chargé basé sur le cloud Bitrix24. Les directeurs des ventes de plusieurs succursales de l'entreprise ont travaillé activement dans le CRM, le portail a été intégré à la téléphonie IP Asterisk pour créer automatiquement des prospects, enregistrer les conversations avec les clients et enregistrer les faits des appels dans une carte client dans CRM. Plus de 100 leads ont été créés par jour dans CRM via différents canaux.
Il était clair que tout simple dans le temps lors du transfert vers la version en boîte menace le client de pertes énormes. Après avoir discuté avec le Client de la gravité de la transition et des risques possibles, nous nous sommes mis au travail.
Tout d'abord, nous avons analysé les cas et publications existants sur le transfert du cloud vers la box, fait une check-list détaillée des erreurs que nous pouvons rencontrer:
- Les applications s'exécutant dans le cloud ne sont pas sur la boîte;
- Le coût des licences pour les applications pour la version cloud et la boîte peut varier;
- Le risque de perdre certaines données en raison d'un décalage dans le temps pendant le transfert;
- Certains utilisateurs de différentes succursales continueront de travailler sur le service cloud après le transfert, et il sera également nécessaire de rechercher et de transférer les entités qu'ils ont créées dans CRM;
- Sur le portail fermé, l'application mobile du service ne fonctionnera pas;
- Après le transfert, certains utilisateurs ne pourront pas se connecter avec leur ancien mot de passe;
- Il peut y avoir des dysfonctionnements dans les robots de chat;
- Réinitialisation fréquente des autorisations lorsque vous travaillez sur le portail;
- Seule une partie des commentaires de tâche peut être affichée;
- La base de données sera sans index de recherche.
Ensuite, un algorithme clair des actions avec une ventilation par rôles a été compilé, qui devait être effectué à la fois par le contractant et par le client:
1 phase (moyen d'urgence)- Déploiement de l'environnement de production (entrepreneur);
- Tester l'environnement déployé (entrepreneur);
- Déploiement de la version en boîte sur les hôtes (entrepreneur);
- Achat et installation d'un certificat SSL pour la téléphonie (achat client, installation entrepreneur);
- Test de la version en boîte - performances, paramètres, tests internes (entrepreneur).
- Déploiement de l'environnement de pré-production - une copie complète de la production (entrepreneur).
2 phases (urgence élevée)- Demande de déchargement de sauvegarde. Coordination avec le support technique du service de la date de sauvegarde (Client);
- Informer les utilisateurs de la date de sauvegarde et établir un plan de stockage temporaire des informations du CRM (Client);
- Déploiement d'une sauvegarde en production (entrepreneur);
- Mise en place du portail après sauvegarde (entrepreneur);
- Mise en place d'un serveur de téléphonie pour travailler avec le portail (Client);
- Mise en place d'un module de téléphonie (contractant);
- Tests téléphoniques initiaux (Client);
- Tests approfondis de CRM, téléphonie, processus d'affaires CRM (service client);
- Déclaration de santé. Suppression des données de test (client);
- Arrêt des responsables commerciaux dans le service cloud (Client);
- Transfert des transactions, leads, contacts depuis la création de la sauvegarde de la version cloud vers la box (Contractant);
- Début des travaux des responsables commerciaux sur la version boîte (Client).
3 phases (urgence faible)- Test de la version en boîte dans les 2-3 jours (client);
- Approbation de la pleine performance (client);
- Mise à jour de la pré-production - transfert d'une copie complète de la production (entrepreneur).
Après avoir établi ce plan et avoir une check-list avec les erreurs possibles, nous avons réalisé que nous avons trop de risques en raison du grand nombre d'incertitudes:
- À quelle vitesse le service fournira-t-il une sauvegarde?
- Combien de temps faut-il pour déployer une sauvegarde, étant donné que la base de données CRM est énorme?
- En combien de temps puis-je reconfigurer le module et le serveur de téléphonie pour fonctionner correctement avec CRM?
- Quels bogues spécifiques peuvent apparaître sur le portail, à quel point seront-ils critiques pour le travail des utilisateurs et combien de temps faut-il pour les corriger?
Nous avons réalisé que nous avons un décalage indéfini qui, à mesure qu'il augmente, entraînerait de plus en plus de pertes pour le client. Pour minimiser le décalage, il était nécessaire de comprendre combien de temps nous consacrons au portage et au débogage du portail.
Nous sommes donc arrivés à la conclusion qu'une sauvegarde à partir du cloud ne sera pas suffisante, et afin de minimiser les pertes, il est nécessaire de déployer une sauvegarde - pour identifier tous les risques possibles et estimer le décalage temporel, puis une deuxième sauvegarde que nous pourrions planifier de manière à minimiser les pertes .
Bitrix ne fournit qu'une seule sauvegarde et une seule fois, car le processus de transfert du cloud vers la box est techniquement compliqué. En ce qui concerne le support technique et la connexion du client à ce problème, nous avons toujours le feu vert pour fournir deux sauvegardes à partir du cloud à des moments différents. L'heure de la première sauvegarde a été convenue et le travail de transfert a commencé.
Volume, vitesse et pièces cassées
Afin de comprendre combien et ce qu'il nous faudra du temps, nous avons commencé à tenir un journal dans lequel nous avons enregistré chaque étape.
Ainsi, le portail a démarré le service de sauvegarde jeudi soir, c'est-à-dire que le CRM avait les dernières données à la fin de jeudi, et nous a fourni un lien vers la sauvegarde vendredi après-midi. Ici, nous avons rencontré la première difficulté - la sauvegarde pesait environ 30 Go et la vitesse de téléchargement à partir des serveurs Amazon.com qui hébergeaient le cloud était loin d'être idéale (en moyenne 800 Kb / s). Après avoir calculé approximativement le temps pendant lequel plusieurs parties de la sauvegarde ont été chargées, nous avons réalisé qu'au total, il faudrait environ 10 heures pour télécharger la sauvegarde uniquement.
Le problème suivant a été l'apparition d'erreurs lors du pompage de différentes parties de la sauvegarde, qui n'a été détectée qu'une fois déployée. En règle générale, ces parties ont également causé une erreur de non-concordance de hachage, car il était nécessaire d'identifier la partie cassée de l'archive dans le texte d'erreur et de la transférer manuellement via SSH, après quoi le déballage a été redémarré à partir de zéro de la sauvegarde entière.
Après avoir téléchargé et déployé avec succès une sauvegarde sur nos hôtes, nous avons reçu une copie de travail du cloud dans la boîte et sommes passés à l'étape suivante - tester et déboguer le portail.
Bugs mineurs et push & pull insidieux
À notre grande surprise, les tests de boîtes se sont déroulés de manière relativement fluide. Nous avons testé le CRM, passé en revue tous les outils du service, vérifié la fonctionnalité du messager, effectué des tests internes et révélé seulement 3 erreurs:
- L'icône de pièce jointe dans le messager a disparu et l'envoi de fichiers dans le messager dans son ensemble n'a pas fonctionné;
- Les liens dans les notifications avaient une adresse sans domaine, par exemple: entreprise / personnel / utilisateur / 1250 / tâches / tâche / vue , respectivement, ne fonctionnaient pas;
- Certains utilisateurs n'ont pas pu se connecter au portail avec une erreur de connexion / mot de passe incorrecte.
Nous étions conscients de l'impossibilité de se connecter après le transfert à l'avance, le service en avertit immédiatement lors d'une sauvegarde. Malheureusement, ce problème ne peut être résolu que par les utilisateurs récupérant le mot de passe ou modifiant manuellement les mots de passe de chaque utilisateur par l'administrateur, car les mots de passe de Bitrix24.Network ne sont pas stockés sur le portail.
L'erreur avec les liens dans les notifications a été résolue assez rapidement - en enregistrant le domaine du portail dans les paramètres du site et les paramètres du module principal.
Mais l'icône de pièce jointe manquante dans le messager a causé pas mal de soucis. La tâche a pris quelques heures de tentatives infructueuses pour comprendre la raison de l'icône manquante. En conséquence, nous avons constaté que la raison était loin d'être dans le module de disque, comme cela était supposé à l'origine. La raison réside dans le serveur push déconnecté dans les paramètres du module push & pull, qui a automatiquement désactivé le transfert de fichiers dans le messager.
Test final
Après des tests et un débogage réussis du portail, un rapport détaillé a été préparé pour le client et la prochaine étape a été un test approfondi par le service commercial CRM Client, ainsi que la configuration du serveur de téléphonie pour fonctionner avec la box et le test des appels.
Pendant les tests, aucun problème significatif n'a été identifié. Nous avons déployé un hôte de test et y avons déployé une copie complète du portail de combat, au cas où nous aurions une version 100% fonctionnelle du portail et selon laquelle nous pourrions faire une comparaison dans les paramètres si des erreurs non standard ne se produisaient pas et n'étaient pas détectées lors du test de la première sauvegarde.
Après avoir déployé une copie du portail, nous avons procédé à l'analyse du journal, dans laquelle nous avons corrigé les erreurs et le temps de les résoudre. Après avoir analysé le magazine en détail, nous avons mis à jour le plan de transfert de la deuxième sauvegarde, réalisé combien nous pouvons perdre des prospects lors du transfert final et réservé du temps supplémentaire pour l'importation manuelle des prospects perdus à partir de la version cloud. Tous les détails et risques ont également été discutés avec le Client et une lettre a été envoyée au support technique du service avec une demande de préparation d'une seconde sauvegarde.
Deuxième sauvegarde et pourquoi tout peut-il mal tourner?
Après avoir convenu de l'heure de création de la sauvegarde également jeudi, nous avons préparé l'équipe pour les actions opérationnelles avant midi le vendredi. Dans la région des 12-13 heures, nous avons reçu le lien tant attendu et avons commencé le téléchargement. Quelques heures plus tard, il était clair que les archives ne seraient pas pompées pendant 10 heures, mais environ 14! La bande passante du canal de notre fournisseur et des serveurs Amazon.com ce jour-là laissait beaucoup à désirer. Nous nous préparions pour le travail de nuit, les leads continuant de baisser et le Client attendait un rapport pour commencer la configuration du serveur de téléphonie.
Comme cela arrive souvent, tout ne s'est pas déroulé comme prévu. L'étape suivante consistait à transférer les prospects accumulés de la version cloud vers la boîte - le processus est simple et clair, mais a ses propres nuances. Si dans la liste des pistes, vous sélectionnez les pistes qui doivent être exportées et cliquez sur «Exporter vers CSV», alors toutes les pistes existantes dans CRM seront déchargées, pas seulement celles sélectionnées. Il est logique qu'avec une grande base de données de leads, le cloud soit tombé en erreur. La solution était d'utiliser un filtre, mais dans ce cas, les câbles étaient déchargés correctement.
D'autres tests ont passé sans surprise, comme nous le savions déjà: ce qui ne fonctionnera pas, comment y remédier et où. Après avoir connecté et testé la téléphonie avec succès, le lundi, les directeurs commerciaux ont déjà pleinement travaillé avec CRM dans la version en boîte. Et déjà en état de marche pendant une semaine, nous avons réglé le portail, sauvegardé, fait une copie finale du portail sur l'hôte de test.
L'ensemble du processus de transfert a pris environ une semaine de travail depuis la planification jusqu'à la configuration finale.
En conséquence, je voudrais noter l'importance de planifier de tels projets complexes et risqués, une implication obligatoire du Client dans le processus et de parler des risques possibles, même si, comme le montre la pratique, les écarts par rapport au plan ne font pas exception.