Manager avec les ERP
218
© Groupe Eyrolles
Évoluer
Les évolutions des progiciels utilisés
Parmi le nombre important de progiciels, quelle doit être la politique de mise à
jour ? La mise à jour systématique au gré des évolutions est à exclure. L’attitude
attentiste qui consiste à ne mettre à jour que quand on est contraint et forcé peut
être la cause de problèmes à terme (par exemple, l’utilisation de versions anciennes
non maintenues, le déphasage dans le couplage entre le matériel et le logiciel, les
pertes de performances relatives, etc.). Or, toute mise à jour, dans un environnement multi-éditeurs, pose les problèmes qui suivent :
◗ la synchronisation entre éditeurs par rapport aux nouvelles versions de ses couches basses est absolument non maîtrisable ;
◗ la mise à jour d’un seul élément progiciel de l’ensemble intégré peut perturber
l’ensemble du système ;
◗ la mise à jour d’un seul composant du système peut demander celle de toutes
les couches logicielles qu’il utilise.
Exemple 5.1 : La synchronisation des versions
Un industriel s’est équipé d’une CAO de conception de cartes électroniques
et d’une gestion de stock de composants électroniques ; cette dernière étant
dans le cadre d’un MRP, lui-même, volet d’un ERP. Ses choix se sont portés sur
des produits tournant sur le même SGBD-R et sur le système d’exploitation
Unix.
L’intégration est forte : la gestion de stock utilise la même base de données de
composants que la CAO.
Une version majeure du SGBD est disponible, sur une nouvelle version de
l’Unix du constructeur. L’éditeur de CAO met à jour son produit, mais pas l’éditeur de la gestion de stock. Or la CAO alimente certaines données du stock :
celles concernant les cartes fabriquées par l’entreprise. L’évolution de version
du SGBD assure une compatibilité descendante et non ascendante. L’entreprise ne peut se permettre la mise à jour. Cependant, son donneur d’ordre
principal rend obligatoire l’évolution de la CAO.
Cet exemple montre que les interfaces doivent être conçues avec soin pour
éviter les fortes dérives.
La cellule d’homologation, de test, d’intégration et de développement
Il restera toujours une partie spécifique dans un ensemble hétérogène intégré,
aussi poussée que pourrait l’être l’intégration.
218
© Groupe Eyrolles
Évoluer
Les évolutions des progiciels utilisés
Parmi le nombre important de progiciels, quelle doit être la politique de mise à
jour ? La mise à jour systématique au gré des évolutions est à exclure. L’attitude
attentiste qui consiste à ne mettre à jour que quand on est contraint et forcé peut
être la cause de problèmes à terme (par exemple, l’utilisation de versions anciennes
non maintenues, le déphasage dans le couplage entre le matériel et le logiciel, les
pertes de performances relatives, etc.). Or, toute mise à jour, dans un environnement multi-éditeurs, pose les problèmes qui suivent :
◗ la synchronisation entre éditeurs par rapport aux nouvelles versions de ses couches basses est absolument non maîtrisable ;
◗ la mise à jour d’un seul élément progiciel de l’ensemble intégré peut perturber
l’ensemble du système ;
◗ la mise à jour d’un seul composant du système peut demander celle de toutes
les couches logicielles qu’il utilise.
Exemple 5.1 : La synchronisation des versions
Un industriel s’est équipé d’une CAO de conception de cartes électroniques
et d’une gestion de stock de composants électroniques ; cette dernière étant
dans le cadre d’un MRP, lui-même, volet d’un ERP. Ses choix se sont portés sur
des produits tournant sur le même SGBD-R et sur le système d’exploitation
Unix.
L’intégration est forte : la gestion de stock utilise la même base de données de
composants que la CAO.
Une version majeure du SGBD est disponible, sur une nouvelle version de
l’Unix du constructeur. L’éditeur de CAO met à jour son produit, mais pas l’éditeur de la gestion de stock. Or la CAO alimente certaines données du stock :
celles concernant les cartes fabriquées par l’entreprise. L’évolution de version
du SGBD assure une compatibilité descendante et non ascendante. L’entreprise ne peut se permettre la mise à jour. Cependant, son donneur d’ordre
principal rend obligatoire l’évolution de la CAO.
Cet exemple montre que les interfaces doivent être conçues avec soin pour
éviter les fortes dérives.
La cellule d’homologation, de test, d’intégration et de développement
Il restera toujours une partie spécifique dans un ensemble hétérogène intégré,
aussi poussée que pourrait l’être l’intégration.