Intégrer un logiciel GED et un logiciel de Workflow.
Quels sont les risques ? Part 2
Dans le précédent article, nous avons constaté les risques liés à l’intégration d’une brique logicielle de gestion électronique de document (GED) avec une brique logicielle BPM de gestion des processus métier (Workflow). Dans ce second article, nous allons creuser le risque d’inadéquation.
2éme risque : inadéquation
L’inadéquation, c’est ce qui n’est pas adéquat, pas adapté au but à atteindre. Et en l’espèce, il n’est pas rare que des projets de GED+BPM soient atteints de ce mal.
Ce risque est lié à la méconnaissance mutuelle de :
- La DSI
- La direction métier
La DSI ne connait pas les spécificités du métier et a une vision souvent macro des besoins. De son côté, la direction métier n’est pas compétente sur le domaine de l’informatique et a des difficultés à « guider » la DSI vers la solution qui répond à ses besoins.
Ce postulat est communément admis et le Leitmotiv est : « le métier ne parle pas le langage de la DSI et vice versa ». De plus, il est n’est pas rare d’entendre la DSI revendiquer l’importance de « fitter » au besoin métier.
Malgré ces effets d’annonce, il est habituel de rencontrer des Chefs de Projet IT qui propose une solution technique avant même d’avoir réellement compris le besoin fonctionnel. Pourquoi ?
On ne change pas une équipe qui gagne
Pour répondre à un besoin transversal de l’organisation, il arrive que le Chef de Projet IT propose, à raison, deux briques transversales : une solution logicielle GED et un moteur de Workflow.
En effet, une Gestion Électronique de Document (GED) est un outil bien utile pour gérer des fichiers de toutes sortes. De même, un outil de gestion des workflows collaboratifs (BPMS en vérité) est adéquat pour modéliser un processus métier selon la norme BPMNv2 et offrir une interface pour piloter ce processus est pratique sur une échelle macro.
Mais pour une application métier, l’important c’est le contenu des fichiers, la spécificité de ce contenu est le véritable différenciateur entre, par exemple, le métier RH et le métier Qualité. Surtout, transmettre le bon fragment d’information à la personne qui doit réaliser l’action, au moment où cela permet de gagner en productivité, est le vrai gisement de performance. Et je peux vous assurer que le métier ne se contente pas d’une échelle macro, le métier est dans le micro. Car le praticien de la RH ou de la Qualité a déjà optimisé le macro, dorénavant les gains de performance se jouent dans le micro et c’est cela qui doit être automatisé via l’application.
Si l’intégration GED + moteur de Workflow ne fait rien d’autre que de stocker, versionner, éditer en ligne et faire le « passe plat » d’une personne à l’autre, quelle est la plus value pour le métier ?
Oui, pour celui qui n’est pas au fait des possibles techniques, cela peut sembler une avancée. Mais en tant que professionnel de l’informatique, je vous le dit, cette solution n’est pas l’optimum de ce qui peut être réalisé aujourd’hui. En 2016, alors que l’on parle d’intelligence artificielle et de voiture autonome, on ne propose au métier qu’un stockage de fichier amélioré avec un workflow linéaire à 4 étapes ?
Ce risque, d’inadéquation au besoin métier est souvent rencontré pour une bonne raison, lorsque le Chef de Projet IT a réussi un projet avec les briques A+B, pourquoi ferait-il autrement ? Pourquoi se mettrait-t-il en danger alors que son rôle est justement de limiter les risques ?
No Pain, No Gain !
Si vous lisez cet article, c’est que vous cherchez à réduire les risques sur un projet en cours, à venir ou hypothétique. Pourquoi, aller à l’encontre de ce Chef de Projet IT qui, pour ne pas prendre de risque, choisi comme solution, à votre besoin métier, les mêmes briques de GED et Workflow qu’il connait et avec lesquelles il a déjà réussi un projet précédemment ?
Vous devez aller à l’encontre de ce Chef de Projet IT, uniquement si :
- Votre projet est une application métier spécifique et vous cherchez à atteindre des objectifs précis : conformité, productivité, qualité, traçabilité, …
- Vous souhaitez structurer l’information contenue dans vos fichiers car vous êtes conscient que c’est la seule manière de valoriser vos données métier et créer à la volée des requêtes pour construire votre reporting ;
- Vous avez déjà expérimenté l’intégration d’une brique GED et d’une brique de Worklow et que vous en connaissez les limites.
Dans un autre cas de figure, le risque encouru, à faire sortir de sa zone de confort le Chef de Projet IT, est difficilement justifiable. Soit vous n’avez pas suffisamment creusé votre besoin métier, soit vous avez simplement besoin d’une solution de GED+Workflow transversale ne prenant pas en compte vos spécificités métier.
A contrario, si vous êtes dans un des cas précédemment cités, vous avez tout intérêt à prendre le risque. Car oui, c’est prendre un risque, mais c’est surement le seul risque qui en vaut la peine.
Si vous souhaitez vous orienter vers une solution, où la donnée métier conserve sa spécificité et où l’animation des processus métier permet un vrai gain de performance, alors n’hésitez pas à étudier la solution Anakeen Platform.
Quels sont les risques ? Part 2