Système d’information éclaté : quel impact sur le décisionnel ?

Voila de quoi remettre un peu en avant le débat sur l'opportunité de recentraliser physiquement l’ensemble des données de l’entreprise.Les faits cités dans l’article démontrent bien la difficulté d’assurer la qualité de données dans un SID dont les origines sont autant éclatées.Il existe aujourd’hui des systèmes de DWH virtuels utilisant des caches locaux permettant d’assouplir tous ces phénomènes complexes d’alimentation.La partie technique doit pouvoir venir au secours de lourds besoins fonctionnels !

Arf ! ! …vous avez « posé la question directement aux utilisateurs ».(Ne rigolons pas svp ! ) Il serait temps que je vous éclaire un peu sur le profil type de l’utilisateur, du moins tel qu’il apparaît de plus en plus dans des entreprises de taille importante, notamment les grands comptes et les multinationales. Dans la plupart des cas, avec la mobilité anarchique qui s’est développée dans nombre d’entreprises pour des raisons diverses, la seule base de stabilité humaine qui échappait plus ou moins au chambardement permanent était constituée des informaticiens qui tentent de garder et de maintenir un squelette cohérent permettant de relier les divers éléments, packages, outils, et suites diverses . Ces mainteneurs du système informatique de l’entreprise, sont devenus, plus encore que par le passé, les seuls garants des données, des applications, et de la sécurité et de la continuïté de ce système. Par ailleurs, les « techniques HR » modernes qui consistent à développer la précarité et l’incertitude, quand ce n’est pas du management by terror, à grands coups de plans de licenciement anachiques, aboutissent logiquement à une hyper-volatilité des compétences, une mercenarisation et une acculturation des managers, qui, dans les sphères supérieures de la hiérarchie perdent de plus en plus les compétences métiers pour se cantonner dans des rôles de simples « gestionnaires de ressources » . Des gestionnaires souvent pédants et gonflants qui cherchent à dissimuler leur mauvaise connaissance du métier et des difficultés intrinsèques de celui-ci, ainsi que leur méconnaissance totale d’un système opérationnel qui a souvent connu un parcours historique pour le moins chaotique (à coup de fusions, absorptions, etc.. ) qu’ils ne maîtrisent aucunement, en passant leur temps à cracher dans la soupe, à grands coup d’onomatopées irokoises (1), comme : « yaka », « yavaika », « yapuka. ». . et à tirer leur épingle du jeu dès que se pointent les difficultés et les erreurs, à coup d’autres onomatopées, cette fois : « yavaikapa », « yfallaipas », etc…(1) généralement dues à un manque abyssal de connaissance de l’existant, une sous-spécification fonctionnelle proche de l’indigence, une sous-estimation tout aussi abyssale des coûts de reprise de celui-ci, des interfaces à mettre en œuvre avec le reste du système d’information, et des moyens à mettre en œuvre pour gérer la transition (quand ces coûts et ses difficultés ne sont pas tout simplement ..ignorés), et j’en passe et des meilleurs. Lorsqu’un nouveau responsable utilisateur arrive en place (place qu’il quittera en moyenne dans les trois ans), la tentation est alors grande de décréter que tout est mauvais, et de pratiquer la fuite en avant, en mettant en chantier n’importe quelle « innovation » technique ou n’importe quelle « solution clé-sur-porte » (ne rigolons pas, svp) vue au hasard d’un magasine, ou lors d’une rencontre avec un vendeur particulièrement pugnace. Après un processus d’évaluation plus au moins bâclé (mais à coup de documents ronflants comme des RFI, RFP, et autres..) et une étude de « functionnal gap » généralement pour le moins légère, l’utilisateur demande à l’informatique de greffer sa solution miracle, comme un furoncle supplémentaire, sur une chaîne logistique qui a déjà connu bien d’autres auparavant. Quand, après de multiples déboires suite à un cahier des charges insuffisant et imprécis, dû à l’impéritie et l’impréparation crasse des acteurs, avec à la clé, une description lacunaire des fonctionnalités, une absence de spécifications fonctionnelles détaillées, et une sous-estimation des coûts et des risques liés au changement dont je parle plus haut, le système finit par se stabiliser et les erreurs se résorber (après un impact négatif auprès de la clientèle qu’on oublie souvent de prendre en compte) , les trois ans sont passés, et le responsable utilisateur, qui commençait à prendre de la bouteille et à comprendre la couche métier, s’en va vers de nouvelles fonctions, et est remplacé par un nouveau qui réamorce le cycle suivant. Alors, imaginez ce que ça donne avec des sous-traitants off-shore, qui n’ont aucune proximité avec le système et le contexte de l’entreprise, et qui ne travaillent que sur base de documents lacunaires fournis par ces mêmes utilisateurs. Alors, on met en place à grands frais des procédures de qualité comme CMMI, ITIL et compagnie, ce qui a encore comme effet de contracter encore les maigres sources d’information forunies en amont. L’utilisateur se retranche alors derrière le « day-to-day », et on engage une kyrielle de consultants censés remplacer l’utilisateur (et ses gestionnaires, qui peinent déjà à exécuter les opérations courantes) pour dire à leur place leurs besoins. Enfin, n’oublions pas les coûts de réalisation (si on va jusqu’à la réalisation, ce qui n’est pas acquis d’office) avec des va-et-vient incessant entre les équipes situées en Inde, et les équipes de spécification et de contrôle sur place, qui testent et demandent qu’on rectifie au fil de l’eau la programmation où la paramétrisation d’un logiciel acheté à la hâte, ou d’une application dont on a décrit sommairement ce qu’on en attendait. Et on constate souvent amèrement que les « gains » sur les réalisations effectuées dans des pays à bas coûts salariaux, ont été largement épongés par des surcoûts liés à d’interminables phases récursives de tests, de demandes de rectifications et de mises au point laborieuses et tâtonnantes qui en résultent.Pour parfaire ces, hum !, « économies » (retenons-nous toujours de rigoler, svp !) , on peut aussi sous-traiter le traitement des problèmes avec la clientèle par un de ces call-centers off-shore, histoire que le malheureux s’arrache les cheveux en « dialoguant » en « petit nègre » fait de quelques mots de mauvais français, d’anglais de cuisine, et émaillé de quelques mots en roumain (exemple vécu : ne rigolons toujours pas, svp) avec un survivant du régime de Nicolae Ceaušescu, avant de finalement abandonner ce combat titanesque et kafkaïen, parce que son cas ne rentre pas tip-top dans les cases prévues a priori dans le framework de traitement des incidents, et que l’opérateur roumain a pour seules possibilités de clicker sur les trois ou quatre actions prévues dans Saint Framework, actions qui, malheureusement, ne correspondent nullement à ce qu’il faudrait faire pour résoudre le problème du client (ici, je me place dans le cas, somme toute encore favorable, où l’incident du client apparaît dans le framework. Ce qui n’est pas toujours le cas, loin s’en faut). Client qui finira par abandonner, tout en y perdant des plumes, pour se tourner vers la concurrence, ..tout en se jurant, mais un peu tard, que l’on ne l’y reprendrait plus. (2)(2) pardon à Monsieur Jean de La Fontaine pour cet emprunt osé..Voilà ma réaction « en forme de coup de gueule », mon cher Philippe (dont je souligne, en passant, que j’apprécie beaucoup la rubrique). Je suis bien consciente que ce que je dis va peut être provoquer un tollé (alors, disons que j’offre un « Tollé Général ! » ). Mais avant d’examiner l'impact de l’éclatement du système d'information opérationnel sur l'organisation du système décisionnel, il faut peut-être faire l’inverse : examiner l’impact de l’éclatement de l’organisation et des circuits de décision sur le système d'information opérationnel, non ?Et puis, vous aviez bien demandé de commenter, non ? Système informatique éclaté, aviez-vous dit ? Ví víí.. c’est pour sûr que l’on s’éclate !Bien à vous,Naibed

trés bien