Manager avec les ERP
96
© Groupe Eyrolles
rées dans l’histoire de la démarche qualité d’un grand nombre de fabricants. Elles
stipulent que, lors de la phase de définition des produits, le concepteur n’attribue
qu’une et une seule fonction primaire à un produit. Liberté lui est laissée d’enrichir les fonctionnalités du produit de plusieurs fonctions secondaires.
En langage simplifié, on ne peut demander à un produit de remplir avec la même
efficacité plusieurs fonctions, même s’il y a une corrélation entre elles. Par
exemple, on conçoit aisément que, sous prétexte de produire aussi de l’eau
bouillante, un fer à repasser électrique à vapeur ne peut avoir les deux fonctions
primaires liées à la production de vapeur d’eau : repasser des vêtements et faire du
café. Le fer à repasser a pour fonction primaire de repasser et pour fonction secondaire, accessoirement, de produire de la vapeur d’eau. La même remarque
s’applique au percolateur à café.
Cette analogie étant faite, si les normes AF 150 à AF 153 sont difficilement applicables aux progiciels 1 , elles sont parfaitement utilisables au niveau des modules.
Surtout quand il s’agit de pallier un manque de réponses à certains besoins.
Les origines des modules
La panoplie de modules est spécifique à chaque entreprise et à chaque profession,
leurs origines sont très diverses. On peut détecter quatre classes de modules qui
sont acquis au cours du cycle de vie du système applicatif.
◗ 1 re classe : les modules issus de l’héritage applicatif. Bien souvent, des développements maison ont été nécessaires pour prendre en compte des besoins réellement typiques à l’entreprise. Si aucune application n’existe sur le marché des
progiciels pour couvrir ces besoins, il faudra conserver la spécificité de ces
modules en étudiant la façon dont ils peuvent évoluer et s’interfacer avec le
progiciel intégré choisi. Peut-être, seulement une partie des modules sera conservée, les autres s’avérant inutiles par rapport aux fonctionnalités du progiciel.
Toutes les variations sont possibles :
– le simple portage ;
– la réécriture avec des outils de développement actuels ;
– la conception de nouveaux produits.
◗ 2 e classe : le développement sur la base de composants logiciels. Il est possible
d’opter pour l’utilisation de composants. L’intérêt de ce choix est de permettre
un assemblage, de type puzzle. Il conduit à une meilleure intégration aux pro1. Les progiciels ont, par définition, de nombreuses fonctions où il est impossible de définir la notion
de fonction primaire et de fonctions secondaires.
96
© Groupe Eyrolles
rées dans l’histoire de la démarche qualité d’un grand nombre de fabricants. Elles
stipulent que, lors de la phase de définition des produits, le concepteur n’attribue
qu’une et une seule fonction primaire à un produit. Liberté lui est laissée d’enrichir les fonctionnalités du produit de plusieurs fonctions secondaires.
En langage simplifié, on ne peut demander à un produit de remplir avec la même
efficacité plusieurs fonctions, même s’il y a une corrélation entre elles. Par
exemple, on conçoit aisément que, sous prétexte de produire aussi de l’eau
bouillante, un fer à repasser électrique à vapeur ne peut avoir les deux fonctions
primaires liées à la production de vapeur d’eau : repasser des vêtements et faire du
café. Le fer à repasser a pour fonction primaire de repasser et pour fonction secondaire, accessoirement, de produire de la vapeur d’eau. La même remarque
s’applique au percolateur à café.
Cette analogie étant faite, si les normes AF 150 à AF 153 sont difficilement applicables aux progiciels 1 , elles sont parfaitement utilisables au niveau des modules.
Surtout quand il s’agit de pallier un manque de réponses à certains besoins.
Les origines des modules
La panoplie de modules est spécifique à chaque entreprise et à chaque profession,
leurs origines sont très diverses. On peut détecter quatre classes de modules qui
sont acquis au cours du cycle de vie du système applicatif.
◗ 1 re classe : les modules issus de l’héritage applicatif. Bien souvent, des développements maison ont été nécessaires pour prendre en compte des besoins réellement typiques à l’entreprise. Si aucune application n’existe sur le marché des
progiciels pour couvrir ces besoins, il faudra conserver la spécificité de ces
modules en étudiant la façon dont ils peuvent évoluer et s’interfacer avec le
progiciel intégré choisi. Peut-être, seulement une partie des modules sera conservée, les autres s’avérant inutiles par rapport aux fonctionnalités du progiciel.
Toutes les variations sont possibles :
– le simple portage ;
– la réécriture avec des outils de développement actuels ;
– la conception de nouveaux produits.
◗ 2 e classe : le développement sur la base de composants logiciels. Il est possible
d’opter pour l’utilisation de composants. L’intérêt de ce choix est de permettre
un assemblage, de type puzzle. Il conduit à une meilleure intégration aux pro1. Les progiciels ont, par définition, de nombreuses fonctions où il est impossible de définir la notion
de fonction primaire et de fonctions secondaires.