» » » Conduite du changement

Conduite du changement

Posté dans : Méthodes | 0

Conduite du changement et redévelopement d’outils

Changement

Nous avons déjà évoqué l’importante proportion d’échecs des projets conduits de manière classique et mettions en avant l’intérêt des démarches de développement itératives[1]. Un autre aspect des difficultés des projets informatiques est lié aux changements induits par ces projets informatiques sur l’organisation et les pratiques opérationnelles. Il est par exemple courant de rencontrer des clients ou des utilisateurs qui, face à un outil dont la technologie est obsolète ou qui s’avère difficilement maintenable après de nombreuses années souhaitent redévelopper l’outil en question à « iso fonctionnalité ». L’expérience montre qu’il s’agit d’un très mauvais point de départ pour un projet car :

  • Si cette entreprise a laissé cet outil devenir obsolète au fil des années, elle n’aura pas non plus pris le temps de remettre en cause cet outil dans son contexte. C’est-à-dire sa cohérence avec l’organisation et le contexte de l’entreprise, avec les processus qu’il est censé supporter et les ressources qui l’utilisent.
  • Même en imaginant que l’outil correspondait parfaitement à l’organisation et aux processus à sa mise en place, qui peut sérieusement prétendre qu’aucun changement n’est intervenu dans l’organisation pendant le temps où cet outil est devenu obsolète ? Or si cette évolution de l’organisation réelle était connue, le besoin de modifications le serait également et on ne parlerait pas de développement à « iso fonctionnalités ».
  • Les utilisateurs n’ont pas une bonne vision d’ensemble des processus. Par contre ils ont intégrés dans leurs activités les limitations de l’outil pour pouvoir accomplir leurs tâches ou contribuer à celles de leurs collègues (compilation de données dans Excel, impressions et reprise de données dans d’autres outils, etc.). A moins de vouloir reconduire ces rustines organisationnelles, il y aura forcément un ensemble de petits changements, qui, mis bout à bout constitueront de vrais bouleversements.
  • Les équipes en place ne sont pas naturellement en position d’imaginer des processus plus simples et l’outillage correspondant. Cette identification n’est pas naturelle, elle demande un effort et de la méthode. J’aime bien cette citation attribuée à Henri Ford (même s’il n’est pas prouvé qu’il ait prononcé ces mots) : « Si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondus des chevaux plus rapides ». Voulez-vous vraiment prendre le risque d’acheter des chevaux plus rapides ?

Il est donc primordial de ne pas nier le changement opérationnel qui a eu lieu au fil des années et qui sera immanquablement mis en évidence au déploiement du nouvel outil. Et l’impact de ce changement sera d’autant plus facilement maitrisé que :

  • La vision de la situation future et des changements (organisation et outil) seront claires et partagées.
  • L’apparition de besoins complémentaires sera anticipée.

C’est donc un vrai projet de changement qu’il convient de mener sur les trois composantes de l’organisation (les équipes, les processus et les outils) et non un simple redéveloppement logiciel sans changements.

Très bien mais alors, concrètement, que faire ?

Et bien, pour prendre un exemple, il conviendra de partager au plus tôt une représentation globale et transverse de la situation future. A ce titre et sur la base de l’existant ou d’un premier cahier des charges, passer par une représentation intermédiaire et globale des processus supportés par l’outil avant de finaliser les spécifications fonctionnelles détaillées permettra :

  • De valider la compréhension par tous les acteurs avant de finaliser l’ensemble des spécifications fonctionnelles détaillées.
  • De fournir une vision d’ensemble synthétique et donc compréhensible par l’ensemble des parties prenantes. Ce que ne fournissent pas des spécifications fonctionnelles détaillées.
  • De faire converger les représentations de la situation future (en utilisant cette représentation synthétique), de préparer les utilisateurs et donc d’éviter les effets de surprise et les réactions de rejet en mettant en place les actions appropriées.
  • De mettre en évidence des écarts entre le fonctionnement de l’outil et l’organisation en place.

En conclusion, même si vous pensez que redévelopper un outil sans changement de fonctionnalités est possible, valider cette hypothèse au plus tôt vous aidera à lever le risque de très mauvaises surprises et de réactions de rejet au déploiement du nouvel outil. Impliquer les utilisateurs sur la base d’une représentation synthétique et globale des processus pris en charge par l’outil est nécessaire. Ce n’est pas la seule chose à laquelle il faudra penser et nous aurons l’occasion d’en reparler, mais c’est un début.

 


[1] Voir un article précédent sur le sujet ici: http://qualivia.fr/2014/03/le-dod-impose-les-developpements-agiles/

Partager cet articleShare on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn