Référence DSI : quand nos outils de capitalisation réalignent un projet…

Présentation de Phoenix Contact

Le groupe PHOENIX CONTACT est le leader innovant sur le marché de la connectique industrielle, de l’automatisation, des systèmes d’interface électroniques et de la protection de la foudre. C’est une entreprise familiale, dont le siège est en Allemagne. Le groupe compte 47 filiales dans le monde, et 14 000 collaborateurs.

La filiale française emploie plus de cent collaborateurs, répartis sur 3 sites en France. Elle compte une trentaine de commerciaux.

Les clients sont essentiellement des distributeurs et des grands comptes évoluant sur plusieurs marchés (agroalimentaire, énergie, infrastructure, ferroviaire, eau, automobile, …).

Le contexte

Un audit des logiciels de la filiale va pointer du doigt un manque de suivi des dérogations tarifaires accordées lors des négociations, en vue de l’obtention de gros marchés.

Le logiciel répondait à ce besoin, il possédait en sus un outil de gestion des devis.

De quoi faire une pierre deux coups dans la tête du dirigeant, le budget est annoncé,  un chef de projet métier est nommé, pas besoin d’impliquer la DSI, et le projet prend le nom du logiciel…

L’apport de Référence DSI, accompagnement et appropriation du projet par les utilisateurs clés

Tout DSI qui se respecte, n’ayant pas (encore) de connexion directe avec le cerveau du dirigeant, reste dubitatif devant ces raccourcis. L’argument budget est utilisé pour écrire à minima un « cahier d’expression des besoins » mais réaliser ce document ?

Après 3 mois sans avancée et l’échéance approchant, la direction demande à Référence DSI de prendre en main le projet et de l’accompagner.

Les outils de capitalisation développés chez REFERENCE DSI pour la rédaction de cahiers des besoins ont apporté :

  • Une appropriation de la méthodologie par les utilisateurs clés,
  • Une structuration et une hiérarchisation des besoins métiers,
  • De la rapidité dans la rédaction de l’expression des besoins,
  • Un script de démonstration à respecter par les éditeurs permettant de comparer et d’étayer le choix,
  • Une réutilisation des outils tout au long du projet (expression des besoins, démonstration, tests solution)

Suite aux démonstrations :

  • L’outil prévu initialement n’a pas été retenu et seul un outil de cotation a été choisi,
  • La fonctionnalité d’origine pour la gestion des dérogations a été développée en interne avec les outils existants,
  • La démarche et le choix final ont reçu l’aval de la maison mère.

La mise en œuvre du logiciel de cotation peut démarrer sereinement.

0 réponses

Répondre

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *