Blogue de gestion et études de cas

Retour

Déploiement de systèmes « objet », le SOA en mode gestion

Cube de Rubik

Le Web et la mobilité multiplient les dimensions opérationnelles d’un projet d’informatisation ERP. Les méthodologies classiques de déploiement de systèmes qui produisaient déjà des succès mitigés, font face maintenant à une réalité augmentée, un cube de Rubik de 10 par 10 sur le plan des variables à gérer.

Cette multiplication de variables peut plus que jamais diriger une entreprise vers des problématiques majeures si la gestion du projet d’informatisation n’est pas adaptée aux nouveaux paradigmes opérationnels introduits par les technologiques Web et mobiles.

Rappelons également que cet ajustement méthodologique doit continuer de s’effectuer dans le cadre des objectifs fondamentaux qui eux ne changent pas: rencontrer les délais de livraison et le budget prévus.

À la lumière du taux de succès historique moyen des projets ERP, il peut être naturel de se sentir au départ plus près de l’utopie que du changement de paradigme.

Bref, les approches de déploiement classiques doivent se réinventer sinon les nouveaux projets adressés dans cette approche généreront davantage de systèmes isolés en silo, un résultat qui désintègre les opérations d’une entreprise sur le fond.

Dans le cadre classique, plus de silos isolés est synonyme de perte de levier opérationnel global. Ce qui rend la situation subtile est qu’en apparence, à l’ère du Web et de la mobilité, la magie des interfaces très esthétiques peuvent faire croire le contraire et, par conséquent, même justifier une stratégie de déploiement déficiente à la base.

Voilà un enjeu critique, soit celui de ne pas revenir à la case départ sur le plan des méthodologies de déploiement sous le couvert justifié, mais à nuancer, d’une clientèle, interne ou externe, conquise par des interfaces plus belles et simplifiées.

Ma dernière affirmation vous créé un spasme rationnel? Comment pouvons-nous être contre une clientèle plus satisfaite? La nuance: Bien sûr toujours « Oui » à une clientèle plus satisfaite, mais…il faut aussi valider à quel coût.

Si votre clientèle est extrêmement satisfaite, mais que votre entreprise génère des pertes mensuelles, vous devrez fermer vos portes éventuellement. Comprendre qu’elle ne sera plus satisfaite par votre entreprise et qu’elle trouvera certainement un concurrent très heureux de l’accueillir. Il n’y a qu’un seul perdant dans cette situation: votre entreprise!

Je constate souvent avec étonnement cette espèce de distorsion de gestion qui créé pratiquement un lien direct entre « Clientèle satisfaite » et « Entreprise profitable » dans le cadre de réflexion stratégique.

Pour fermer cette boucle sur la satisfaction clientèle comme unique indicateur potentiel de succès d’un projet ERP, concluons qu’il peut s’agir d’un leurre donnant une fausse lecture car ce qu’il faut mesurer sur le fond, c’est levier opérationnel final, le gain de productivité global du projet, soit son impact mesurable, immédiat ou à terme, sur l’accroissement de la rentabilité de l’entreprise.

Cette mise en contexte de vecteurs d’influence subtile est nécessaire pour faire ressortir que les approches de déploiement de systèmes doivent s’attaquer dorénavant à un niveau de complexité beaucoup plus élevé de résistance au changement dans les projets. L’amplitude et la complexité du volet « humain » sont maintenant tellement élevées qu’ils peuvent désormais présenter à eux seuls le véritable défi d’un projet ERP.

Concept d'architecture orientée services

Pour aborder cette nouvelle complexité dans une approche de déploiement de système renouvelée, je propose donc d’adopter les concepts technologiques de l’architecture « SOA »  (Service Oriented Architecture), ou « Architecture Orientée Service » dans la langue de Molière, comme principes globaux d’une méthodologie d’implantation renouvelée.

Il est d’abord connu qu’à problématique complexe, il est efficace de découper le problème en ses composantes clés et de les adresser individuellement dans un premier temps.

Dans la vision que je propose, bien comprendre ici qu’il ne s’agit pas de découper pour isoler, mais bien de découper en vertu de trois règles et objectifs précis:

  • Comprendre la nature et les dimensions fonctionnelles d’une composante opérationnelle (rôle, fonction, tâche, criticité, complexité, résultat ciblé, etc.) dans le cadre d’un processus d’affaires.
  • Évaluer le niveau de résistance potentiel des intervenants directement impliqués sur le plan fonctionnel (attentes, attitude, formation, etc.)
  • Analyser et décrire les points de communication et d’échange de la composante opérationnelle avec ses prédécesseurs et successeurs dans le cadre des processus d’affaires dans lesquels elle intervient.

C’est dans cette approche découpage ajustée et, plus particulièrement, dans le troisième objectif que le parallèle avec l’approche SOA apparaît.

De façon simplifiée ma proposition est la suivante:

« Isolons les composantes opérationnelles pour mieux les comprendre et réduire la complexité fonctionnelle et humaine, mais attaquons rigoureusement dès le départ, la question des liens et de l’intervention de la composante opérationnelle avec tout processus d’affaires de l’entreprise. »

Autrement dit, isolons pour faciliter et augmenter substantiellement les probabilités de succès du déploiement ERP mais en s’assurant constamment de la totale intégration opérationnelle de la composante tout au long du déploiement progressif du système.

Il y aurait plusieurs explications additionnelles à donner sur les mécanismes et les leviers naturels positifs de l’approche que je propose, mais j’y reviendrai suite à des questions ou dans un prochain article.

Ce qui importe ici c’est de constater l’adéquation et la similarité avec l’approche SOA qui s’appuie sur des principes tels que les suivants:

  • Indépendance et autonomie maximale des services
  • Interopérabilité maximale des services
  • Unification des protocoles d’échange interservices

La notion de « Service » de l’approche SOA est finalement simplement transférée en notion de « Composante opérationnelle » de l’approche renouvelée de déploiement de systèmes.

L’application et le transfert de principes fondamentaux de l’approche SOA vers le domaine des méthodologies d’implantation de systèmes ERP change donc le paradigme classique en appliquant priorisant une approche de travail locale, mais toujours adressée dans une vision analytique globale de la composante opérationnelle.

L’approche classique cible la modélisation et le support complet d’un processus d’affaires global comme seul objectif logique pour le succès du projet quitte à forcer des changements opérationnels important dans les composantes impliquées dans le processus.

L’idée maîtresse de la nouvelle approche suggérée est de permettre de s’attaquer à des composantes  opérationnelles de manière isolée, sans obligation d’en changer la nature et les mécanismes internes, en respectant une seule règle fondamentale: soit de s’assurer d’échanges et de communications standardisées avec les autres composantes impliqués dans un processus d’affaire global.

En termes de déploiement de systèmes, il s’agit donc d’intégrer dès le départ l’analyse des échanges d’information, exemple entre un département donné et un autre, dans le processus d’implantation d’un outil local dédié à un département.

Un des leviers stratégiques de succès de cette nouvelle vision est donc qu’elle se base sur un phénomène naturel en entreprise: le directeur ou chef de département souhaite toujours contrôler le choix et le déploiement d’un nouvel outil de gestion informatisée dans ses opérations. Ses responsabilités dictent d’ailleurs ce mode de pensée.

Ce responsable ne peut être en conflit constant contre l’idée de faire avancer globalement l’entreprise même s’il souhaite gérer tout changement au sein de son département.

Au moment où il est convaincu que le nouvel outil peut améliorer les performances de son département, il ne reste plus qu’à travailler sur les deux aspects centraux pour chaque composante opérationnelle (Service) impliquée de son département :

  • Quelle information est requise à l’entrée de la composante (input)?
  • Quelle information la composante doit fournir à l’externe (output)?

En travaillant les processus d’affaires globaux ciblés par un projet ERP dans cette nouvelle perspective méthodologique, l’efficience et l’efficacité globales sont constamment au centre des préoccupations de déploiement par le mécanisme naturel de validation constante de l’intégrité des échanges intercomposantes.

De plus, le focus et l’attention de l’équipe de déploiement s’attaque à des problématiques réduites sur le plan humain et opérationnel, ce qui réduit les risques de dérapage et augmente automatiquement les probabilités de succès du projet ERP.

Bonne gestion.

 

Retour
Questions fréquentesContactez-moiNous rejoindre