business analytics telecom

Business Analyst TowerCo : au cœur de la transformation Telecom

La transformation d’une TowerCo ne consiste pas simplement à remplacer un outil par un autre.

Lorsqu’un opérateur d’infrastructure Telecom décide de faire converger plusieurs applications historiques vers une plateforme unique, il touche simultanément aux processus métier, au patrimoine, à la gestion des projets, à la maintenance, aux données, aux interfaces et aux habitudes de travail des équipes.

business analytics telecom

Dans ce type de programme, le Business Analyst TowerCo occupe une position particulière.

Il ne se limite plus à recueillir des besoins et rédiger des User Stories. Il devient l’un des points de convergence entre les métiers, le système d’information, l’intégrateur et la plateforme choisie.

Pourquoi les TowerCo cherchent à rationaliser leur système d’information

Les infrastructures Telecom sont historiquement gérées à travers de nombreux outils.

Gestion des sites, contrats, projets de déploiement, maintenance, patrimoine, référentiels, données financières ou interventions terrain peuvent s’appuyer sur des applications différentes.

Cette organisation peut fonctionner pendant plusieurs années.

Mais à mesure que le patrimoine et les activités se développent, ses limites deviennent plus visibles :

  • multiplication des interfaces ;
  • données dupliquées ;
  • différences de référentiels ;
  • processus métier hétérogènes ;
  • manque de visibilité globale sur les sites ;
  • opérations manuelles ;
  • difficultés à suivre un actif sur l’ensemble de son cycle de vie.

L’objectif d’une plateforme TowerCo est donc souvent de créer un environnement plus intégré couvrant plusieurs étapes du cycle de vie des infrastructures.

Des plateformes comme Sitetracker proposent par exemple de centraliser la gestion des projets, des sites et des actifs au sein d’un même environnement.

Mais la technologie n’est qu’une partie de la transformation.

Le principal défi : passer de plusieurs SI spécifiques à une plateforme standard

Lorsqu’une entreprise utilise plusieurs outils développés ou paramétrés au fil du temps, les processus finissent naturellement par s’adapter au système existant.

Chaque métier possède alors :

  • ses habitudes ;
  • ses règles ;
  • ses exceptions ;
  • parfois ses propres outils ;
  • ses propres données.

Le passage à une plateforme SaaS standard comme Sitetracker, ClickOnSite ou une solution reposant sur Salesforce impose une autre logique.

La question n’est plus uniquement :

« Comment reproduire notre fonctionnement actuel dans le nouvel outil ? »

Elle devient :

« Quels processus devons-nous réellement conserver, simplifier ou transformer pour exploiter le standard de la nouvelle plateforme ? »

Cette nuance est essentielle.

Reproduire toutes les spécificités historiques dans une nouvelle plateforme peut rapidement recréer la complexité que le programme devait justement supprimer.

Pourquoi le Business Analyst devient central dans une transformation TowerCo

Le Business Analyst se situe à l’intersection de quatre univers :

le métier, la plateforme, le SI existant et l’intégrateur.

Son rôle consiste notamment à identifier le meilleur compromis entre les besoins opérationnels et les possibilités offertes par la solution cible.

H3 – Comprendre le besoin derrière la demande

Un métier peut demander :

« Nous avons besoin de conserver cette fonctionnalité. »

Mais la véritable question du Business Analyst est différente :

Quel problème opérationnel cette fonctionnalité permet-elle de résoudre ?

Une demande exprimée sous la forme d’une fonctionnalité peut parfois être satisfaite autrement grâce au standard de la nouvelle plateforme.

Le rôle du Business Analyst est donc également de challenger le besoin.

Pas pour le réduire, mais pour éviter de transformer systématiquement une exigence métier en développement spécifique.

Standard ou spécifique : un arbitrage structurant

C’est l’un des sujets les plus sensibles des programmes de transformation SI.

D’un côté, les équipes métiers souhaitent conserver les fonctionnalités qui répondent précisément à leur quotidien.

De l’autre, multiplier les développements spécifiques peut augmenter :

  • le coût du projet ;
  • la complexité de maintenance ;
  • les délais ;
  • les risques lors des évolutions de la plateforme ;
  • les dépendances vis-à-vis de l’intégrateur.

L’enjeu consiste donc à déterminer ce qui doit réellement être spécifique.

Une approche efficace peut consister à classer chaque écart dans trois catégories.

1. Adopter le standard

Le processus existant peut être modifié pour fonctionner avec les capacités natives de la plateforme.

2. Adapter le processus métier

Le besoin reste légitime, mais le fonctionnement historique peut évoluer.

3. Développer une spécificité

Le besoin est critique et ne peut pas raisonnablement être couvert par le standard.

Cette démarche constitue le cœur d’une Gap Analysis.

La Gap Analysis : un exercice stratégique

La Gap Analysis permet de comparer les besoins opérationnels de l’organisation avec les capacités disponibles dans la solution cible. L’objectif est d’identifier précisément les écarts. Pour chaque écart, plusieurs questions doivent être posées :

  • Quelle est la valeur métier réelle ?
  • Combien d’utilisateurs sont concernés ?
  • Existe-t-il une alternative standard ?
  • Le processus actuel peut-il évoluer ?
  • Quel serait le coût d’un développement spécifique ?
  • Quel impact aurait-il sur la maintenance ?
  • Existe-t-il des dépendances avec d’autres systèmes ?

Une bonne Gap Analysis ne produit donc pas simplement une liste de différences. Elle contribue directement aux arbitrages du programme.

De la demande métier à la User Story : garantir la traçabilité

Sur un programme complexe, plusieurs centaines de besoins peuvent être exprimés.

Sans mécanisme de traçabilité, il devient rapidement difficile de savoir :

  • pourquoi une fonctionnalité existe ;
  • quel besoin elle couvre ;
  • qui l’a demandée ;
  • comment elle sera testée ;
  • si elle a réellement été livrée.

Le Business Analyst doit donc maintenir une chaîne cohérente.

Besoin métier → processus → exigence fonctionnelle → User Story → critères d’acceptation → tests.

Cette traçabilité permet notamment de limiter les ambiguïtés entre l’entreprise et l’intégrateur.

Challenger l’intégrateur sans ralentir le projet

Dans un projet de transformation SaaS, l’intégrateur apporte une connaissance approfondie de la solution.

Les équipes métiers possèdent quant à elles la connaissance des opérations.

Entre les deux, les incompréhensions sont fréquentes.

Une même phrase peut être interprétée différemment selon que l’on parle métier, architecture ou configuration d’une plateforme.

Le Business Analyst doit donc être capable de détecter les zones d’ambiguïté.

Il doit notamment challenger :

  • les interprétations des besoins ;
  • les choix de configuration ;
  • les impacts fonctionnels ;
  • les dépendances ;
  • les limitations de la solution ;
  • les propositions de contournement.

L’objectif n’est pas de créer une relation de confrontation avec l’intégrateur.

Il s’agit au contraire de sécuriser une compréhension commune de la solution.

Les interfaces : un risque souvent sous-estimé

Une plateforme TowerCo ne fonctionne presque jamais seule.

Elle doit généralement échanger avec plusieurs systèmes :

  • ERP ;
  • référentiels ;
  • outils financiers ;
  • systèmes de gestion documentaire ;
  • solutions de maintenance ;
  • outils cartographiques ;
  • applications métier ;
  • systèmes partenaires.

Ces échanges reposent souvent sur des API.

Lorsqu’une application historique est remplacée, certaines données peuvent donc continuer à circuler vers plusieurs autres systèmes.

Une transformation fonctionnelle devient alors également une transformation de l’écosystème SI.

Le Business Analyst doit comprendre suffisamment l’architecture pour identifier les conséquences fonctionnelles de ces interfaces.

Les tests de bout en bout : vérifier le processus, pas seulement l’outil

Tester une fonctionnalité isolée n’est pas suffisant.

Un utilisateur peut par exemple créer un site correctement dans la plateforme.

  • Mais que se passe-t-il ensuite ?
  • La donnée est-elle transmise au bon système ?
  • Le référentiel est-il synchronisé ?
  • Les informations sont-elles correctement reprises dans l’ERP ?
  • Les utilisateurs suivants disposent-ils des bonnes informations ?

C’est tout l’intérêt des tests end-to-end.

Ils permettent de reproduire un parcours opérationnel complet à travers plusieurs applications.

Le Business Analyst joue donc un rôle important dans :

  • la construction du plan de tests ;
  • la définition des scénarios ;
  • la rédaction des critères d’acceptation ;
  • l’organisation des tests métier ;
  • le suivi des anomalies ;
  • la validation des parcours de bout en bout.

La réussite d’une plateforme TowerCo ne se mesure pas uniquement à sa mise en production

Une migration peut être techniquement réussie tout en rencontrant des difficultés opérationnelles.

Le véritable indicateur de réussite apparaît lorsque les équipes utilisent réellement la plateforme.

Cela suppose notamment :

  • des processus compréhensibles ;
  • une donnée fiable ;
  • des parcours utilisateurs cohérents ;
  • un niveau de spécificité maîtrisé ;
  • une bonne intégration au SI ;
  • une conduite du changement anticipée.

Dans un programme concernant plusieurs centaines d’utilisateurs internes et externes, l’adoption devient donc un sujet aussi important que la technologie.

Quelles compétences rechercher chez un Business Analyst TowerCo ?

Un Business Analyst travaillant sur ce type de transformation doit combiner plusieurs compétences.

Connaissance métier Telecom

Comprendre les infrastructures Telecom et le fonctionnement d’une TowerCo permet d’identifier plus rapidement les enjeux métier.

Culture SI

Il n’est pas nécessaire d’être architecte.

Mais comprendre les interfaces, les API, les données et les dépendances entre systèmes devient indispensable.

Connaissance des plateformes SaaS

Une expérience de Salesforce, Sitetracker, ClickOnSite ou de plateformes comparables permet de mieux comprendre la logique du standard.

Analyse fonctionnelle

Formalisation des besoins, User Stories, BPMN, critères d’acceptation et Gap Analysis font partie du socle méthodologique.

Capacité à challenger

Un Business Analyst senior doit savoir expliquer pourquoi une demande doit être conservée, adaptée ou abandonnée.

Cela demande autant de méthode que d’intelligence relationnelle.

La transformation TowerCo est avant tout une transformation du modèle opérationnel

Le choix d’une plateforme est évidemment structurant.

Mais le succès d’un programme TowerCo repose surtout sur la capacité de l’organisation à aligner :

les métiers, les processus, la donnée, la technologie et les équipes.

Le Business Analyst devient alors bien plus qu’un traducteur entre métier et IT.

Il contribue à déterminer la manière dont l’entreprise fonctionnera demain.

C’est précisément ce type de profil que le Groupe BBU recherche actuellement dans le cadre d’un programme stratégique de transformation d’un opérateur d’infrastructure Telecom.

Découvrir la mission Business Analyst Senior

FAQ

Qu’est-ce qu’un Business Analyst TowerCo ?

Un Business Analyst TowerCo analyse et formalise les besoins métiers liés aux activités d’un opérateur d’infrastructure Telecom. Il assure la cohérence entre les processus opérationnels, le système d’information, la plateforme TowerCo et les solutions proposées par l’intégrateur.

Quel est le rôle d’un Business Analyst dans une transformation Telecom ?

Il recueille et challenge les besoins métier, réalise les analyses d’écarts, contribue au backlog, valide les User Stories, participe à la conception fonctionnelle et intervient dans la stratégie de tests et la validation des parcours de bout en bout.

Qu’est-ce qu’une plateforme TowerCo ?

Une plateforme TowerCo permet de centraliser tout ou partie de la gestion des infrastructures Telecom : sites, actifs, projets, contrats, opérations, maintenance, patrimoine ou référentiels. Sitetracker et ClickOnSite font partie des solutions présentes sur ce marché.

Pourquoi utiliser Sitetracker dans les infrastructures Telecom ?

Sitetracker est une plateforme conçue pour la gestion de projets, sites et actifs d’infrastructures distribuées. Elle permet notamment de centraliser le suivi des projets et du cycle de vie des actifs dans un environnement commun.

Quelle est la différence entre Salesforce et Sitetracker ?

Salesforce fournit une plateforme technologique et CRM très large. Sitetracker repose sur l’écosystème Salesforce mais ajoute des fonctionnalités spécifiquement conçues pour la gestion de projets, de sites et d’actifs d’infrastructures.

Qu’est-ce qu’une Gap Analysis dans un projet SI ?

Une Gap Analysis consiste à comparer les besoins d’une organisation avec les fonctionnalités disponibles dans une solution cible. Elle permet d’identifier les écarts et de décider s’il faut adopter le standard, modifier le processus métier ou développer une fonctionnalité spécifique.

Pourquoi privilégier le standard d’une plateforme SaaS ?

Utiliser autant que possible les fonctionnalités standards limite généralement les développements spécifiques, facilite les évolutions futures de la plateforme et réduit la complexité de maintenance.

Qu’est-ce qu’un test end-to-end ?

Un test end-to-end vérifie qu’un processus fonctionne correctement de bout en bout, souvent à travers plusieurs fonctionnalités ou plusieurs systèmes interconnectés.

Quelles compétences sont nécessaires pour devenir Business Analyst Telecom ?

Une bonne connaissance métier, des compétences en analyse fonctionnelle, une compréhension des systèmes d’information, la maîtrise des outils de backlog et une forte capacité à travailler avec les équipes métier, IT et les intégrateurs sont particulièrement importantes.

Pourquoi le Business Analyst est-il stratégique dans une transformation TowerCo ?

Parce qu’il permet de maintenir la cohérence entre les besoins opérationnels, les capacités de la plateforme, les contraintes du SI existant et les décisions prises avec l’intégrateur. Son intervention contribue à limiter la complexité et à sécuriser l’adoption de la solution.