Le directeur d’un projet d’intelligence d’affaires connaît bien la nature critique du processus d’extraction, de transformation et de chargement. Il y consacre souvent plus de la moitié de ses ressources pour construire pièce par pièce les opérations servant à peupler l’entrepôt de données à partir des données des systèmes transactionnels. Même écho chez le responsable du processus ETC qui doit jongler avec la qualité, l’accessibilité, la disponibilité et la complexité des données. C’est en fait ce jeu de coulisse, invisible aux utilisateurs finaux, qui assure jour après jour la pertinence de l’intelligence d’affaires en entreprise et permet d’en tirer de la valeur pour l’organisation.

Alors quand mon programmeur dit « L’ETC, c’est juste du code », je frissonne.

Voir au-delà du code

Les programmeurs ETC ne sont pas légion, c’est vrai. Malgré cela, je devrais être en mesure d’attendre de mes spécialistes une compréhension qui dépasse les lignes de code SQL qui défilent sur leurs écrans. L’expert ETC ne peut se contenter de traduire des spécifications d’analyse en code. Pour preuve, la même personne occupe souvent, de façon concomitante, les sièges d’analyste et de programmeur ETC.  Elle doit maîtriser et allier les notions de systèmes transactionnels et décisionnels. Elle doit conjuguer vision d’ensemble et traitement du détail.

Intégrer les affaires

Plus important encore, l’expert ETC doit posséder une compréhension intime des règles d’affaires de l’entreprise afin d’assurer la qualité de l’information fournie aux dirigeants. Cette connaissance permettra de déterminer ce qui est idéal, souhaitable ou possible et d’intervenir rapidement en cas de problème. Encore aujourd’hui, une grande partie des règles d’affaires demeurent implicites au travail. Elles sont ancrées dans les pratiques quotidiennes ou dans l’utilisation des systèmes d’information. Un programmeur ETC qui n’a pas le réflexe de consulter les experts du métier pour résoudre un problème de données s’apparente davantage à un risque qu’à un atout… et disons que la communication est rarement l’apanage du programmeur, ETC ou pas.

Savoir s’arrêter

Le spécialiste ETC doit aussi démontrer la sagesse de renoncer à une tâche impossible. Il n’est pas ici question de perte sur le rendement marginal du programmeur, mais plutôt de reconnaître que certains problèmes relèvent des pratiques d’affaires ou de l’utilisation des systèmes transactionnels. Indépendamment de l’excellence et de la créativité de votre équipe, le processus ETC ne peut tout régler. Ici encore, le dialogue avec les unités d’affaires est de mise. Pour régler les problèmes à la source, il faut du tact, une vision inclusive et intégrée et… une bonne dose d’humilité, car l’équipe TI a souvent clamé qu’elle pouvait, avec assez de ressources, réaliser l’impossible.

Gérer les aléas

Le processus ETC est fragile. Il est intimement lié aux systèmes transactionnels auprès desquels il s’approvisionne et aux systèmes décisionnels qu’il fournit en données. Dans cette position précaire, le processus ETC est à la merci des changements imprévus dans les systèmes, des pannes de réseaux et de la disponibilité des serveurs. Les programmeurs ETC vivent chaque jour les aléas des technologies et pratiques d’affaires. Un programmeur à œillères, qui se limite à appliquer des recettes pour créer du code, ratera à coup sûr l’importance des stratégies de contrôle du flux de données et des mécanismes de détection et de récupération d’erreurs. Il recherchera, à tort, la robustesse dans le code plutôt que dans la gestion du processus.

Distinguer l’ETC du tableau de bord

Ce serait une erreur de chercher à dresser un parallèle entre les activités de l’équipe ETC et celle du tableau de bord pour caractériser le travail de programmation. Si elles œuvrent toutes deux en intelligence d’affaires, l’équipe ETC ne jouit pas de la latitude offerte à l’équipe du tableau de bord. En effet, un tableau d’indicateurs d’une convivialité, disons, passable, peut néanmoins être utilisé adéquatement par un décideur. Certes, celui-ci devra fournir un effort supplémentaire d’analyse, mais il pourra tout de même prendre une meilleure décision que s’il n’avait pas eu accès à des données.

Il en va autrement du processus ETC. Un processus approximatif ou partiel engendre des données erronées et peut causer préjudice à l’organisation lors d’une prise de décision contre-productive. Une telle catastrophe est exacerbée par le fait que l’utilisateur détecte difficilement (sinon pas du tout) cette situation, le fonctionnement normal du tableau de bord masquant l’état des choses. Dans les pires cas, ce contexte peut perdurer indéfiniment. Ainsi, le programmeur ETC n’a pas à se soucier que du flux de données, mais aussi de la nature des données, de leurs caractéristiques normales, de leurs liens aux affaires, de leurs utilisations, etc.

Développer une vision

Alors quand votre programmeur simplifie l’ETC à la création de code, portez attention. De deux choses l’une, soit il a intégré l’essence de l’ETC à un tel point qu’il ne conçoit plus la programmation autrement, soit sa position dénote une compréhension extrêmement limitée du rôle de l’ETC en intelligence d’affaires et réduit l’importance du travail accompli. Dans le second cas, sonnez l’alarme!

Que votre programmeur soit nouvellement arrivé en provenance d’une autre division, que ses tâches lui semblent répétitives ou qu’il ait une expérience limitée en entreprise n’a pas d’importance. Chaque membre de l’équipe ETC devrait comprendre l’importance du travail accompli collectivement tant sur le plan technologique que celui des affaires. Profitez-en au passage pour développer la culture d’intelligence d’affaires, les  compétences individuelles de vos employés comme la communication, et pourquoi, pas, un sentiment d’appartenance et de fierté à l’équipe. Important? Rappelez-vous que les travailleurs dans l’ombre des tableaux de bord sont rarement reconnus (ou même connus) par les utilisateurs finaux, or ils ont droit à leur part du mérite...

Daniel Chamberland-Tremblay

Professeur chargé d'enseignement à l’Université de Sherbrooke et chercheur associé au Pôle de recherche en intelligence stratégique et multidimensionnelle d'entreprise (PRISME)