… il faut partir à point ou, en tout cas, bien préparer ses marques et ses starting blocks. Une évidence? Une porte ouverte qu’on veut enfoncer à coups de bélier? Pas forcément si l’on s’en remet à de nombreuses situations vécues sur le terrain.

Témoignage de la société Tri ICT, filiale de TriFinance, société de consultance qui propose à ses clients une approche transversale de leurs projets, mêlant aspects administratifs, financiers, informatiques voire juridiques.

Au fil de ses projets, auprès de clients actifs dans toute une série de secteurs (automobile, distribution, industrie pharmaceutique, secteur hospitalier, assurances…), la société a relevé une constante dans les erreurs que commettent les sociétés lorsqu’elles se lancent dans un projet d’informatisation ou d’optimisation: trop souvent, on commence par implémenter un produit sans avoir compris et documenté leurs processus.

Stabiliser d’abord la situation existante

L’une des problématiques qui se posait à un grand groupe hospitalier (que nous ne citerons pas) situé en région liégeoise était de pouvoir faire face de manière plus efficace aux changements intervenant dans la tarification des soins. “Ils avaient besoin d’outils structurés pour gérer les différents sites de manière harmonisée. Des tableaux de bord devaient leur permettre d’effectuer un pilotage direct.”

Dans ce cas précis, souligne Bruno Arnould, directeur de Tri ICT, “il s’agissait avant tout d’harmoniser les processus à travers les divers sites hospitaliers et maisons de repos qui constituent désormais ce groupe.” La situation était fort disparate- un fait classique après fusion d’établissements. Mais la disparité venait aussi du degré variable de “maturité informatique” de chaque organisme. “La comptabilité et la gestion financière de certaines maisons de repos reposent encore sur Excel, parfois même sans intégration avec les processus bancaires”, témoigne Juliette Duhamel, solutions manager chez TriFinance.

Autre constat souvent fait dans le secteur hospitalier: une réticence au changement et une fidélité inébranlable dans des solutions ponctuelles, chaque service ayant choisi et implémenté une solution spécifique: spécialisations médicales, chirurgie, urgences, soins des patients, gestion des seringues, catering, gestion des stocks, etc. Autant de facettes d’un vaste kaléidoscope que, souvent, les premiers intéressés ne veulent pas bouleverser.

“L’un des problèmes de base est que la situation existante, en soi, n’est déjà pas stable. Il est dès lors encore plus dur d’aller vers le to be.”

“L’une de nos premières actions a consisté à déterminer quels systèmes pouvaient ou non être intégrés. Ou, plus exactement, ceux qu’il était nécessaire d’intégrer, ce qu’on peut ou doit remplacer. Le groupe hospitalier se refuse par exemple à intégrer tout ce qui touche à l’INAMI. Consultations, facturations etc. resteront donc gérées par l’outil existant. Raison invoquée: les paramètres et législations évoluent trop vite pour changer l’outil. Mais cela n’est toutefois pas exclu… à terme.”

Savoir aller à contre-courant de certaines “bonnes pratiques”

Au lieu de vouloir imposer au client de faire table rase du passé ou de se lancer dans un projet de grande envergure, Tri ICT préconise souvent de se concentrer sur le (strict) nécessaire. Quitte à garder des outils existants qui ne sont pas idéaux ou qui sont quelque peu dépassés. “Parfois, il n’est pas possible de tout intégrer parce qu’il est trop tard… La situation est ce qu’elle est, les outils existent et le budget ne permet pas de procéder à un big bang. Si le département décide de tout intégrer, cela coûtera une fortune. Mieux vaut dès lors se placer dans une autre optique. Il s’agit par exemple de démontrer au client que tel outil est certes encore valable mais que sa maintenance lui reviendra trop cher. Cela permet de le convaincre d’évoluer.”

“Un outil IT est inutile si vous n’avez pas, au préalable, la solution en tête.”

En IT, le dicton “chacun chez soi, les vaches seront bien gardées” n’a pas cours. Business et IT ont tout intérêt à faire cause commune. Ce qui n’est pas toujours le cas. Patron qui croit mieux connaître les besoins que quiconque ou responsable IT (ou “chargé” de l’IT) qui décide en autarcie sont monnaie courante.

Source: NurdCartoon

La mise en oeuvre d’un projet d’automatisation nécessite que tous – responsables métier et responsables informatiques – s’approprient, à égalité, ce projet. S’il est initié par l’IT et si le business n’y adhère pas, les réticences, mauvaises volontés ou incompréhensions ralentiront l’implémentation, voire la feront capoter.

Si le projet est initié par le business, sans concertation avec l’IT, l’optimisation risque de ne pas être au rendez-vous.

Vincent Van Mol, “expertise manager” chez Tri ICT, l’exprime autrement: “qui est le chef, l’initiateur du projet? Si c’est l’IT, il faut absolument pouvoir compter sur quelqu’un dans le comité de direction qui a compris à quoi cela va servir et comment le projet- de la business intelligence par exemple- va fonctionner. Sans cela, il est inutile de commencer…”

Le fameux “garbage”- à l’entrée et à la sortie

Il a été de toutes les générations informatiques: garbage in? garbage out! Et Tri ICT joue évidemment de cet argument. “L’optique business doit primer et cela, dans une perspective à long terme. La première démarche est celle du changement- celui de l’IT mais aussi celui du métier”, souligne Vincent Van Mol. “Il faut en effet changer le processus avant de vouloir l’automatiser. Et il faut commencer par de petits volets à automatiser. Ensuite, on s’engage dans une boucle: les processus métier génèrent des informations, qu’il faut “nettoyer” avant de les injecter dans des indicateurs qui permettront de bien gérer les processus métier. Ce faisant, on améliore progressivement le processus.”

Papier-crayon vs souris-diagramme

“Pouvoir simplement mettre sur papier les processus de la société est déjà, dans bien des cas, une amélioration. Ce simple fait permet par exemple de préciser le rôle de chacun. Et le fait que certains se refusent parfois à cet exercice, est révélateur: peut-être n’ont ils pas envie d’éclaircir la situation…” Parce que cela risque de pointer leurs propres carences, voire de remettre en cause le rôle qu’ils jouent.

Usines à gaz et pragmatisme

Un client de Tri ICT, actif dans le domaine des assurances, se trouvait confronté à un problème de prolifération de ses outils IT et de ses systèmes source. Ils s’étaient multipliés comme des champignons, en raison de choix spécifiques, et souvent redondants, par département, voire par produit d’assurance.

Voulant résoudre la situation via une approche big bang, la compagnie s’est d’abood tournée vers une solution BI complète de l’un des grands acteurs du secteur. Mais a commis plusieurs erreurs:

• absence d’un chef de projet interne (ce qui a laissé les coudées franches au gestionnaire de projet proposé par l’implémentateur, sans prise directe avec le business)
• tentative de mise en oeuvre d’une solution qui avait certes fait ses preuves mais auprès d’un autre client et qu’il était en fait impossible d’adapter aisément aux spécificités de la compagnie
• solution choisie surdimensionnée, que Tri ICT qualifie d’usine à gaz
• un contrat libellé à prix fixe “alors que les processus n’étaient même pas définis. Autrement dit, le prestataire n’avait aucune visibilité sur la complexité de ce à quoi il s’était engagé…”.

“Le change management est toujours indispensable et souvent le facteur bloquant.”

“Nous avons été appelé pour accompagner ce méga-projet mais il n’a pas abouti”, explique Vincent Van Mol. “Nous avons donc repris le problème par le début. On a donc commencé par une rétro-ingénierie des processus, par la simplification des feuilles Access. Cela n’a rien à voir avec de la business intelligence mais cela a tout à voir avec les processus métier qu’il s’agit de documenter, de nettoyer, avant d’automatiser.” Petite idée de l’ampleur de la tâche- et de la raison du plantage initial: “nous avons mis un an à définir les besoins exacts.”

Les petits travers

Autre péché mignon souvent rencontré: la duplication sauvage de fonctions, feuilles Excel, fonctions, processus… dès que quelque chose “coince”. Juliette Duhamel cite une situation vécue. Une société avait laissé ses différents départements travailler en silos. Chacun créait de nouveaux clients selon ses propres procédures avec ses propres outils. Fouillis garanti. A telle enseigne que la mécanique s’était emballée. Si quelqu’un ne trouvait pas un client en moins de 5 secondes… il recréait une nouvelle fiche… Conclusion et conseil, en extrapolant ce genre de travers? “Rien ne sert de multiplier le nombre de serveurs dans l’espoir d’améliorer la qualité d’un processus si on ne commence pas par imposer une et une seule interface pour créer un nouveau client.”