Evolution du système d'information par l'implantation d'un Progiciel de Gestion Intégrée Systématiser la mise en correspondance entre le
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Evolution du système d’information par
l’implantation d’un Progiciel de Gestion
Intégrée
Systématiser la mise en correspondance entre le
système et l’organisation
Iyad Zoukar, Camille Salinesi, Colette Rolland
Centre de Recherche en Informatique - Université Paris 1 – Panthéon – Sorbonne
90 rue de Tolbiac 75013 Paris – France
iyad.zoukar@malix.univ-paris1.fr , {camille,rolland}@univ-paris1.fr
RESUME : Assurer l'adéquation entre les besoins de l’organisation et les fonctionnalités du
Système d’Information (SI) est une question fondamentale qui se pose principalement dans le
cadre d’évolution du SI. C’est en particulier le cas quand une organisation fait évoluer son SI
par l’installation d’un Progiciel de Gestion Intégrée (PGI). L’une des causes importantes de
l'inadéquation résulte de la disparité des langages utilisés par les divers intervenants
d’intégration de PGI. Notre approche pour résoudre ce problème est de matérialiser la
relation de correspondance entre les fonctionnalités du nouveau système incluant le PGI et
les processus métier de l’organisation. En posant l'hypothèse qu’un formalisme abstrait à
base de buts peut être employé pour trouver cette correspondance, nous avons développé à la
SNCF une méthode qui aide à analyser les exigences du métier relatives à l’installation d’un
PGI. Cet article présente des éléments de cette méthode et les questions qui ont été soulevées
lors de son application dans un projet d’installation d’un PGI pour supporter les processus
logistiques à la SNCF.
ABSTRACT: Ensuring the adequacy between Information System (IS) functionalities and
business requirements is still an issue that needs to be addressed in the domain of IS
evolution. It’s specially the case when an organization evolves its IS by adapting an
Enterprise Resource Planning (ERP). One important cause of inadequacy results from the
gap between the languages used by ERP implementers and the other stakeholders. Our
approach to this issue is to materialize the relationship between the functionalities of the new
system including the ERP and the business processes that it supports. Based on the
assumption that an abstract goal-based formalism can be used to achieve this, we have
developed at SNCF a method that helps eliciting ERP implementation requirements together
with business adaptation requirements. This paper outlines this method and the issues that
were met while using it in an SNCF project in which an ERP is being implemented to support
the Supply Chain processes.
Mots-clés : Evolution du SI, Ingénierie des besoins, PGI, Processus métier, Carte.
Keywords: IS Evolution, Requirement Engineering, ERP, Business Processes, Map.
11. Introduction
Assurer l’adéquation entre un système d’information de type PGI et les besoins
et exigences d’une organisation demeure un problème de fond qui doit être résolu si
l’on veut que les PGI fournissent les avantages attendus. Une des raisons majeures
de l’inadéquation résulte de la différence de langages utilisés par les différentes
parties impliquées dans un projet d’intégration des PGI (l’éditeur de progiciel, les
intégrateurs, les experts métier et les utilisateurs, etc.).
Notre travail à la SNCF consiste à développer une méthode qui aide à assurer la
mise en adéquation de PeopleSoft, que l’entreprise est en train de mettre en place,
aux besoins de la chaîne logistique de l’entreprise.
Généralement, dans ce type de projet et comme le montre la Figure 1, le travail
est guidé par les fonctionnalités du PGI. Pourtant, ces fonctionnalités sont exprimées
à un bas niveau d’abstraction avec beaucoup de détails comme les transactions à
réaliser, les opérations à exécuter ou les données à gérer, et se focalisent sur une
vision locale des processus concernés par le PGI ; au contraire, les gestionnaires de
l’organisation ont une vision globale et pensent en terme de buts ou résultats à
atteindre. L’organisation a des difficultés à s’adapter au langage des experts en PGI,
et par conséquent, ces personnes ne voient pas comment le nouveau système peut
répondre à leurs exigences. Ceci expose le projet au risque d’échec (Standish 1995)
(Esteves et al., 2003), (Davenport, 1998), (Davenport, 2000).
Approche guidée
par les besoins de
Organisation Systéme PGI
l’entreprise
Besoins et exigences Descriptions
Expression à haut niveau Description à bas niveau
Orientée objectif et stratégie Orientée fonction
Vision globale Approche guidée Vision locale
par le PGI
Figure 1. L’organisation et le système - deux approches différentes
Deux approches sont possibles pour rapprocher ces deux parties :
- Une approche guidée par les besoins de l’organisation : cette approche est
classique et souhaitée par tous les acteurs métier de l’entreprise afin d’installer un
système qui répondrait exactement à leurs besoins.
- Une approche guidée par les fonctionnalités du PGI : cette approche est
souhaitée par l’éditeur et les intégrateurs qui souhaitent installer les fonctions
standard du PGI par simple paramétrage et configuration sans être obligés de re-
développer des fonctions particulières pour prendre en compte les spécificités de
l’organisation.
2Nous ne préconisons pas une et une seule de ces deux approches. Nous pensons
qu’il faut suivre les deux approches de manière combinée. C’est donc un équilibre
entre les deux approches qu’il faut rechercher. En fonction de l’organisation, de sa
taille, de sa culture et de son secteur d’activité, l’équilibre peut être plus ou moins
proche du système ou de l’organisation.
Pour trouver cet équilibre, on doit mettre en relation les besoins de l’organisation
et les solutions proposées par le PGI. Cette tâche n’est pas simple du fait que les
deux entités n’expriment pas leurs exigences de la même façon ni au même niveau
d’abstraction.
Comme le montre la Figure 2, les experts du métier de l’organisation expriment
leurs besoins au niveau intentionnel, alors que les experts techniques en PGI
expriment les fonctionnalités du PGI au niveau opérationnel. On a besoin de
rapprocher ces deux parties et de les faire communiquer au même niveau. Notre
proposition est de ramener les deux parties à communiquer au niveau intentionnel.
Cette façon est naturelle pour les gens du métier qui préfèrent exprimer leurs
souhaits en terme d’objectifs et de moyens pour les réaliser. Par contre, ce n’est pas
le cas des intégrateurs de PGI qui pensent en termes opérationnels comme les
fonctions, les transactions ou les données. Disposant de leur propre modèle
d’entreprise, les experts en PGI essayent de forcer l’organisation à s’adapter aux
processus proposés par le PGI. En fait, cela pose un problème majeur : la quantité de
détails est énorme et les maîtriser devient une activité très coûteuse en temps et
ressources. En plus ce n’est pas naturel pour les gens du métier dans l’organisation
de penser en termes des processus du PGI. C’est pourquoi une activité d’abstraction
est donc nécessaire pour extraire les buts et stratégies qui sont cachés derrière ces
objets opérationnels. Le niveau intentionnel oblige les experts techniques à aller à
l’essentiel en faisant abstraction des détails opérationnels et techniques. On peut
alors procéder à la mise en correspondance des buts et stratégies de l’entreprise et
ceux proposés par le PGI. Après avoir trouvé cette correspondance, on peut
répercuter au niveau opérationnel les points communs.
Entreprise PGI
Objectifs Objectifs
Niveau Matching
Intentionnel
Abstraction Abstraction
Opérationalisation Opérationalisation
Niveau Entreprise PGI
Opérationnel Modèle d’entreprise
Processus
Fonctionnalités
Alignement Modules
Figure 2. Les niveaux intentionnel et opérationnel
3Notre approche pour répondre à la problématique de l’alignement est de
matérialiser la relation entre le système (le PGI) et l’organisation par un modèle
unique, appelé modèle de la Carte ou Map (Rolland et al., 2000)(Rolland et al.,
2001).
La section suivante présente un cadre méthodologique général d’évolution du SI.
La section 3 introduit la notion de carte. Le processus de mise en correspondance est
détaillé en section 4. Nous illustrons la méthode présentée sur le projet SNCF en
section 5. Enfin, la section 6 propose une discussion à partir de travaux similaires et
notre agenda de recherche ainsi qu’une conclusion.
2. Cadre méthodologique de l’évolution du SI
Jarke (Jarke et al., 1993) a proposé un cadre pour l’évolution du SI présenté dans
la Figure 3. Nous avons étendu ce cadre par une typologie d’évolutions (Salinesi et
al., 2003). Ce cadre méthodologique introduit quatre types de modèles :
Existant Cible
MM MM
Correspondance
Correspondance
Processus
du
changement
Existant Cible
MFS MFS
MM: Modèle Métier MFS: Modèle des Fonctionnalités du Système
Figure 3. Cadre méthodologique général pour l’évolution du SI
- Modèle métier de l’existant (Existant MM)1 : représente les processus métier
actuellement en place dans l’organisation.
- Modèle des fonctionnalités existantes du système (Existant MFS) 1 : représente les
différentes fonctionnalités disponibles dans l’actuel système informatique de
l’organisation.
- Modèle métier de la cible (Cible MM) 1 : représente les processus métier cible que
l’organisation aimerait avoir après l’évolution de son SI.
- Modèle des fonctionnalités cibles du système (Cible MFS) 1 : représente les
fonctionnalités du système informatique après l’évolution du SI de l’organisation.
1
Les termes anglais utilisés dans la littérature sont :
Existant MM = As-Is Business Model (BM) ; Cible MM = To-Be BM
Existant MFS = System Functionality Model (SFM) ; Cible MFS = To-Be SFM
4Le cas étudié dans cet article correspond au type présenté à la Figure 4. Il
correspond au ‘paramétrage d’une famille de produits’. Pour prendre en compte ce
type d’évolution, on a adapté les modèles proposés par Jarke dans le cadre général.
Les quatre modèles proposés dans ce cas sont :
Souhaité Cible
MM MM
correspondance
Processus
de mise en
Possible Cible
correspondance
MFS MFS
MM: Modèle Métier MFS: Modèle des Fonctionnalités du Système
Figure 4. Cadre méthodologique spécifique pour l’évolution du SI de type
paramétrage d’une famille de produits
- Modèle métier souhaité (Souhaité MM)2 : représente les processus métier que
l’organisation souhaite mettre en place en implantant un PGI.
- Modèle des fonctionnalités possibles du système (Possible MFS) 2 : représente les
différentes fonctionnalités fournies par le PGI.
- Modèle métier de la cible (Cible MM) : représente les processus métier de
l’organisation une fois que le PGI a été installé (après le projet).
- Modèle des fonctionnalités cibles du système (Cible MFS) : montre les
spécifications du PGI après la fin du projet, c’est-à-dire après le paramétrage du PGI
et les développements des fonctions spécifiques.
Un processus de mise en correspondance entre les deux premiers modèles est
nécessaire pour produire les deux derniers modèles ainsi que pour assurer leur
adéquation, c’est-à-dire s’assurer que les fonctions du système répondent aux
besoins et exigences de l’organisation. Nous appelons cette adéquation par
‘correspondance’. Au niveau de l’organisation, cela implique une adaptation des
processus métier. Au niveau système, cela nécessite le paramétrage et la
configuration du PGI et des autres SI.
La situation à la SNCF est un peu plus complexe. En fait, différents formalismes
sont utilisés pour établir les quatre modèles précédents. Dans la Figure 5, nous
proposons une adaptation du cadre méthodologique pour la SNCF. On a introduit un
cinquième modèle (Existant MM) qui représente le modèle métier de l’existant
avant la mise en place du PGI car la SNCF souhaite s’assurer que le futur sera au
moins équivalent au présent.
2
Les termes anglais utilisés dans la littérature sont :
Souhaité MM = As-Wished BM ; Possible MFS = Might-Be MFS
5A la SNCF, chacun des cinq modèles précédents est construit en utilisant un
formalisme différent. Par exemple, le Souhaité MM est modélisé en utilisant les
processus Mega, alors que le Possible MFS est modélisé en utilisant les Réseaux de
Petri ; l’Existant MM utilise un formalisme interne à l’entreprise, etc.
En outre, chacun des modèles a été développé ou sera développé par une partie
différente de l’équipe projet, et chaque membre de l’équipe n’est pas forcément
familier avec les différents formalismes utilisés dans le projet.
Existant Souhaité
Formalisme Possible Cible
MM MM
MM MM
SNCF
Correspondance
Carte Carte
utilise
Écarts
Processus de
Mise en correspondance & Carte Intégrée
Correspondance
Similarités
Carte
Formalisme Existant Souhaité Cible
PGI MFS
MFS MFS MFS
Possible
MM: Modèle Métier MFS: Modèle des Fonctionnalités du Système
Figure 5. Cadre méthodologique spécifique pour la SNCF
Notre proposition est d’utiliser le formalisme de la « Carte de processus » (Map)
pour représenter les modèles Existant MM, Souhaité MM et Possible MFS. Ceci
correspond aux exigences de l’équipe projet de ne pas influencer ou remplacer le
développement des modèles existants. On remarque que le travail supplémentaire
nécessaire pour développer les différentes cartes était utile puisqu’il permet de
synthétiser les modèles traités en termes abstraits et de supprimer les détails
encombrants. D’ailleurs, un travail similaire, si ce n’est pas plus important, serait
nécessaire si nous voulions établir les modèles Existant MFS, Souhaité MFS et
Possible MM.
Le processus de mise en correspondance concerne essentiellement deux familles
de modèles (cartes) : les cartes du Souhaité MM et les cartes du Possible MFS. Deux
techniques d’ingénierie peuvent être utilisées pour pourvoir réaliser cette mise en
correspondance : les écarts et les similarités. Les Similarités sont mieux adaptées
dans le contexte de l’évolution du SI par la mise en place d’un PGI (Salinesi et al.,
2004).
63. Modèle But-Stratégie Map
Dans cette section on introduit les concepts clés du modèle de la carte qui seront
utilisés dans la construction des différentes familles de cartes mentionnées dans la
section précédente. Une description détaillée du modèle de la carte peut être trouvée
dans (Rolland et al., 2000) (Rolland et al., 2001) et (Nurcan et al., 2004).
Le model de la Carte (Map) est un modèle de processus exprimé au niveau
intentionnel. Il fournit un système de représentation qui repose sur un
ordonnancement non-déterministe de buts et de stratégies. La Figure 6 présente les
concepts clés de la carte et leurs relations en utilisant la notation UML. La Figure 7
montre un exemple d’une carte dans le cadre de la planification de production à la
SNCF.
0..1
Carte
Chemin
Segment
Paquet
* ** 2..* Affiné par
1
Section
1 1 1
But source A pour
Stratégie A pour But cible
source cible
But
Figure 6. Le méta-modèle de la carte
Une carte est composée d’une ou de plusieurs sections. Une section est une
agrégation de deux types de buts (le but source et le but cible) et d’une stratégie. La
carte est représentée par un graphe orienté et étiqueté. Les buts sont représentés par
les nœuds et les stratégies par les arcs reliant ces nœuds. La nature orientée de la
carte est due au fait qu’une stratégie indique le flux du but source au but cible.
Un but est un objectif que l’on peut atteindre par l’exécution d’un ou plusieurs
processus. Par exemple, Etablir le plan multi-sourcing et Définir le plan
d’entreprise sont deux buts dans le domaine de la planification de production dans
une entreprise industrielle. En plus, chaque carte possède deux buts particuliers,
Démarrer et Arrêter, pour commencer et terminer l’exécution de la carte.
Une stratégie est une approche, une manière ou un moyen pour réaliser un but.
Dans notre exemple, nous pouvons définir le plan de production Par produit ou Par
unité de production.
Une section est un triplet composé d’un but source, d’un but cible et d’une
stratégie. Une section exprime la réalisation du but cible en utilisant la stratégie une
fois que le but source a été réalisé. Par exemple, l’agrégation du but source Définir
le plan d’entreprise, du but cible Etablir le plan multi-sourcing et de la stratégie Par
7Planning Solvers définit la section < Définir le plan d’entreprise, Etablir le plan
multi-sourcing, Par Planning Solvers>. Ici Par Planning Solvers caractérise le flux
du but source Définir le plan d’entreprise au but cible Etablir le plan multi-sourcing
et la manière de réaliser la cible.
Stratégies
C1.Par unité
Démarrer de gestion
C5.Par réseaux de d’approvisionnement
C9.Révision/Maintenance
C2.Par produit
C6.Planification multi-site
C3.Planification
en ligne
C7.Par Planning Solvers
Définir le plan d’entreprise Établir le plan multi-sourcing
C8.Par simulation «What-If»
C11.Par produit
C4.Révision/Maintenance C12.Révision/Maintenance C10.Par unité de
production
Définir la plan de production Multi-segment
Buts
C14.Par consommation C13.Par validation
des prévisions
Arrêter
Figure 7. Un exemple de carte de planification de la production dans PeopleSoft
Le graphe de la carte montre les relations de précédence/succession entre les
différentes sections. Pour qu’une section S1 succède à une autre section S2, son but
source IS1 doit être le but cible IC2 de l’autre section S2. Dans notre exemple,
considérons que nous voulons définir le plan de production pour une unité de
production. La carte de la Figure 7 indique clairement que l’on ne peut pas faire cela
si le plan multi-sourcing n’a pas été établi au préalable. Donc, on peut dire qu’il y a
une relation de précédence/succession entre la section et la section < Etablir le plan
multi-sourcing, Définir le plan de production, Par unité de production>.
Multi-segment : dans une carte, il est possible de réaliser un but cible à partir
d’un but source en utilisant plusieurs manières. Chacune de ces manières est
exprimée comme une section dans la carte. Cette topologie est appelé multi-segment.
Quand les différentes stratégies composant un multi-segment sont mutuellement
exclusives, on parle d’un Paquet. Dans notre exemple, et à partir du plan multi-
sourcing, le plan de production peut être défini Par produit et/ou Par unité de
production.
Multi-chemin : Dans une carte, il est possible de réaliser un but en utilisant
différentes combinaisons de sections. En d’autres termes, un but donné peut être
réalisé en suivant plusieurs chemins dans le graphe. Par exemple, pour Définir le
plan de production, il existe plusieurs possibilités :
8- Définir le plan d’entreprise par produit, puis établir le plan multi-sourcing en
utilisant une simulation de type « what-if », ensuite définir le plan de production par
produit.
- Définir le plan d’entreprise par unité de gestion, puis établir le plan multi-sourcing
en utilisant une planification multi-site, ensuite définir le plan de production par
unité de production.
- Définir le plan de production par la stratégie de révision et de maintenance. Etc…
Niveau n Niveau n+1 Démarrer
C10.2.Par atelier C10.1.Par unité de production
Planifier l’adéquation
charge/capacité
C10.3.Pour les commandes
Établir le plan multi-sourcing C10.4.Par atelier
C10.6.Par réactualisation
mensuelle C10.5.Pour les prévisions
C10.Par unité de production
Déterminer
C10.9.Pour les moyens
les PDP prévisionnels
de réception
Définir la plan de production
C10.7.Pour les
commandes
C10.8.Pour les C10.10.Pour les moyens
prévisions de transport
Déterminer C10.11.Par transmission Planifier
les PDP fermes aux unités de production les besoins de livraison
C10.12.Par transmission
C10.13.Par validation
aux unités de production
Arrêter
Figure 8. Affinement de la section C10
Relation d’affinement : La Figure 6 montre qu’une section de la carte peut être
affinée par une autre carte complète par la relation d’affinement. Cela permettra de
décrire une section à un niveau d’abstraction donné n, par une carte à un niveau
d’abstraction moins élevé n+1. Ce mécanisme permettra de modéliser les exigences
à plusieurs niveaux de détails. Par exemple, dans la carte de la Figure 7, on peut
affiner la section C10 par la carte de la Figure 8. Cette carte est plus
opérationnelle que la carte principale dont une section a été affinée. Des sections de
cette nouvelle carte peuvent elles aussi êtres affinées par de nouvelles cartes et ainsi
de suite…
4. Processus de mise en correspondance
Pour conduire les projets d’installation de PGI, il existe plusieurs méthodes
comme ASAP (Khan, 2002) ou ARIS (Scheer et al., 2002). Mais ces méthodes se
concentrent sur la gestion de projet et ne fournissent que peu d’outils d’ingénierie
nécessaires pour répondre à la problématique de mise en correspondance. Comme
9un certain nombre d’auteurs (Maiden et al., 1998) et (Finkelstein et al. 2002), nous
pensons que les méthodes d’ingénierie sont toujours nécessaires pour guider le
processus d’analyse des exigences dans les projets de type PGI. Pour cette raison,
nous avons développé un modèle de processus. Ce modèle a été construit de façon
itérative et des améliorations sont apportées tout au long du projet.
Comme le montre la Figure 9, notre méthode possède deux activités principales :
la construction des modèles Existant, Souhaité et Possible et la construction des
modèles Cibles. En fait, les modèles Cibles peuvent être construits au fur et à
mesure par un processus de mise en correspondance dirigé par l’Existant, le
Souhaité ou le Possible. Les modèles Existant, Souhaité et Possible peuvent être
abstraits par des cartes et améliorés à partir des modèles Cibles par une rétroaction.
Chacune de ces approches nécessite une manière différente de travail, mais des
techniques de similarités peuvent être utilisées dans les différents cas.
Processus de
mise en correspondance
Dirigé par
L’Existant
Existant
Dirigé par
le Souhaité
Souhaité
Cible
Dirigé par
le Possible
Possible
Rétroaction
Figure 9. Processus d’analyse des exigences dans un projet PGI
Le processus de construction de l’ensemble des modèles Existant, Souhaité,
Possible et Cible est décrit dans le Tableau 1. Cette description affinée montre que :
- la construction des modèles Existant, Souhaité ou Possible est entrelacée ;
- chaque type de carte est construit en utilisant des démarches spécifiques ;
- la construction d’un type de modèles informe sur la construction des autres types.
Le processus de mise en correspondance est au cœur du modèle présenté dans la
Figure 9. Il se résume au passage entre la Construction des modèles Existant,
Souhaité et Possible et la Construction des modèles Cibles. Le produit de ce
processus est la famille des cartes du modèle Cible qui représentent les exigences de
l’organisation et du PGI. Ces cartes servent ensuite de point d’entrée au processus
d’installation du PGI. La majorité des buts et stratégies des cartes du modèle Cible
sont obtenus à partir des cartes du PGI qui correspondent aux besoins exprimés dans
les cartes du modèle Souhaité. D’autres buts et stratégies qui ne sont pas inclus dans
les cartes du PGI mais figurent dans celles du modèle Souhaité peuvent être
considérés en proposant de faire des développements spécifiques. Dans ce cas, les
cartes du modèle Cible aident à identifier et spécifier ces développements
10spécifiques. Par contre, tous les buts et stratégies du PGI peuvent ne pas être repris
dans les cartes du modèle Cible. Ceux-ci correspondent aux fonctionnalités du PGI
dont l’organisation n’a pas besoin.
Activité A partir de démarche utilisée
page blanche To-Down retro analyse
Construire l'Existant
Cible Rétroaction
page blanche To-Down
Dirigé par les écarts
Existant Non-régression
par les contraintes
Construire le Souhaité
par les meilleurs pratiques métier
par les dysfonctionnements
Possible par réutilisatin des meilleurs pratiques du PGI
Cible Rétroaction
page blanche abstraction
Construire le Possible Souhaité dirigé par le projet
Cible Rétroaction
page blanche Directement
Existant Mise en correspondance dirigée par l'Existant
Construire la Cible
Souhaité Mise en correspondance dirigée par le Souhaité
Possible Mise en correspondance dirigée par le Possible
Tableau 1. Le processus de construction de chacun des quatre modèles
La construction des cartes du modèle Cible peut être dirigée par les cartes du
modèle Possible, les cartes du modèle Existant ou les cartes du modèle Souhaité.
Dans chacun de ces cas, nous considérons les buts et les stratégies situés entre le but
Démarrer et le but Arrêter et nous décidons : (i) si elles correspondent aux
exigences à incorporer dans les cartes du modèle Cible ; (ii) si des adaptations sont
nécessaires avant des les intégrer dans les cartes du modèle Cible ; (iii) ou si on ne
les prend pas en compte dans les cartes du modèle Cible.
Nous pensons que l’approche dirigée par les cartes du PGI est la plus utilisée
dans les projets d’implantation de PGI surtout dans les petites et moyennes
entreprises, dans la mesure où le concept de PGI est de pouvoir proposer des outils
supportant les meilleurs pratiques métier du marché. Par contre, les approches
dirigées par l’Existant ou le Souhaité, puisqu’elles partent des besoins spécifiques,
limitent les possibilités de mise en correspondance. Cette dernière approche est très
pertinente dans le cas où l’organisation détiendrait des processus métier spécifiques
grâce auxquels l’organisation possède un avantage concurrentiel sur les autres
acteurs de son marché. C’est souvent le cas des grandes entreprises.
La mise en correspondance étant un processus proactif, des affinements de
l’ensemble des modèles sont possibles à tout moment du processus en suivant la
démarche rétroactive dès que la construction des cartes du modèle Cible a
commencé.
Finalement, et pour que la mise en correspondance soit valide, les exigences
exprimées à travers les cartes du modèle Souhaité doivent être vérifiées.
115. Exemple : le cas de la SNCF
Nous travaillons avec la SNCF depuis deux ans. Nos recherches concernent un
projet d’implantation d’un PGI (PeopleSoft). Ce projet a été choisi pour servir de
pilote à l’étude menée. Ce projet présente beaucoup d’aspects intéressants pour
conduire une étude de recherche. Les aspects les plus importants sont :
- un très grand projet industriel ;
- une organisation très complexe qui fait intervenir des acteurs très variés ;
- il concerne la problématique de l’étude ;
- le projet utilise une méthode propre pour la modélisation et la gestion de projet ce
qui va nous permettre de procéder à une comparaison ;
- les solutions techniques envisagées dans le projet présentent un intérêt pour nos
recherches dans le cadre de l’évolution du SI.
L’objectif du projet est de participer à l'optimisation des processus
d'approvisionnement. Son périmètre couvre l’ensemble de la problématique de
l’approvisionnement depuis l’expression des besoins par l’utilisateur jusqu’à la
réception et la facturation. Les acteurs concernés par ce projet sont très variés : des
unités de production, de stockage, des achats, du contrôle et des utilisateurs du
matériel. La solution informatique envisagée dans le projet concerne un PGI qui
permettra de piloter, d’optimiser et de maîtriser en terme de coût et de qualité la
chaîne d’approvisionnement. Le développement de modules de GPAO (Gestion de
la Production Assistée par Ordinateur) pour les unités de production sur la base de le
PGI permettent d’optimiser et de mieux maîtriser les coûts de production.
Activité A partir de démarche utilisée
Construire les cartes page blanche To-Down retro analyse
de l'Existant Cible Rétroaction
page blanche To-Down
Dirigé par les écarts
Existant Non-régression
Construire les Cartes par les contraintes
du Souhaité par les meilleurs pratiques métier
par les dysfonctionnements
Possible par réutilisatin des meilleurs pratiques du PGI
Cible Rétroaction
page blanche abstraction
Construire les cartes
Souhaité dirigé par le projet
du Possible
Cible Rétroaction
Tableau 2. Les différentes démarches utilisées dans le projet SNCF pour la
construction des cartes
Dans le projet SNCF, nous avons adapté le cadre méthodologique général pour
prendre en compte les spécificités du projet (voir Figure 5). Le processus d’analyse
présenté dans la Figure 9 a été exécuté partiellement, surtout la première partie
concernant la construction des modèles Existant, Souhaité et Possible qui est
détaillée dans le Tableau 1. Dans cette application, les modèles correspondent aux
cartes, et le Possible concerne le PGI PeopleSoft. Un certain nombre de démarches a
été utilisé pour la construction des trois familles de cartes. Dans le Tableau 2, les
démarches qui n’ont pas été utilisées sont représentées en fond gris. Le contexte du
12projet SNCF impose l’utilisation de certaines démarches. Mais dans le cas général,
toutes ces démarches peuvent être utilisées afin de construire les différentes familles
de cartes.
Le domaine du projet SNCF étant très large, nous avons essayé de suivre
l’avancement du projet et de respecter les étapes préconisées par l’équipe projet.
Cette contrainte nous a conduit à suivre un ordre prédéfini dans la construction des
cartes. Les cartes de l’Existant ont été construites pour l’ensemble des macros
processus. Après leur validation, les cartes du modèle Souhaité ont à leur tour été
dessinées et validées avant de commencer l’établissement des cartes de PeopleSoft
en fonction de certains processus de la cible, c’est pourquoi nous avons choisi la
démarche Dirigé par le projet pour la construction des cartes du modèle Possible.
Vu la complexité des processus concernés, on a adapté l’approche top-down, et
on s’est limité à quelques niveaux d’affinement (entre 4 et 5). Le but étant de se
concentrer sur l’essentiel du métier et de ne pas se noyer dans les détails
opérationnels.
3 Stratégie
d’arbitrage
1 Stratégie prévisionnelle
Démarrer Analyser les besoins
2 Stratégie ferme
5
Stratégie de 7 Stratégie
4 Stratégie Production d’achat
de Stock
8 Stratégie de livraison
Gérer les ressources Servir le client
6 Stratégie de retour du matériel
10 Stratégie comptable 9 Stratégie comptable
11 Stratégie de 12 Par litige
litige récupération Arrêter
Existant
Démarrer 1 Stratégie Démarrer 1-Stratégie
prévisionnelle prévisionnelle
5 Stratégie d’achat 5-Stratégie d’achat
2 Stratégie 2-Stratégie
ferme 6 Stratégie de Stock ferme 6-Stratégie de Stock
7 Stratégie de Production 7-Stratégie de Production
Gérer les besoins Servir le client Gérer les besoins Servir le client
8 Stratégie de livraison 8-Stratégie de livraison
3 Stratégie 3-Stratégie
du catalogue du catalogue
9 Stratégie de retour du matériel 9-Stratégie de retour du matériel
4 Stratégie de 4-Stratégie de
planification planification
10 Stratégie comptable 10-Stratégie comptable
11 Stratégie de litige 11-Stratégie de litige
Arrêter Arrêter
Souhaité Possible
Figure 10. La carte de plus haut niveau des modèles Existant, Souhaité et Possible
La Figure 10 montre un aperçu sur les cartes de plus haut niveau des trois
familles : l’Existant, le Souhaité et le Possible.
13Des affinements de ces 3 cartes ont donné lieu à un grand nombre de cartes. Les
cartes du PGI sont beaucoup plus nombreuses et plus riches en stratégies dans la
mesure où un PGI propose des solutions génériques à paramétrer en fonction de
l’entreprise.
Établir le PIC
1-À partir des grandes
orientations prévisionnelles
Démarrer 3-Par simulation 2-Par révision tous les 6 mois
Choisir
le plan multi-sourcing
5-Pour le centre de stockage
4-Pour les unités de production
Déterminer
Déterminer le PDP
les plans d’appro
6-Par consommation par
7-Par consommation par des DA
les commandes fermes
Arrêter
Figure 11. Un exemple de carte du modèle Souhaité
1-Par planification collaborative 7-Stratégie 8-Stratégie de
de révision maintenance
2-Par planification en ligne
3-Par unité de gestion
Démarrer 4-Par produit Établir le PIC
5-Par contrainte
10-Planification 12-Par réseau
6-Par Work Center
multi-site de sourcing
13-Par planning slovers
11-Par la disponibilité
9-Par simulation de production
what-if
Choisir 15-Stratégie de maintenance
14-Stratégie de révision
le plan multi-sourcing
22-Pour le centre de stockage
17-Pour les unités de production 21-Par produit
18-Stratégie de révision
16-Par produit 20-Par équilibrage entre
l’inventaire et la planification
pour le réappro de matériel
Déterminer Déterminer
26-Par validation
les plans de production les plans d’appro
29-Par validation 30-Par validation
28-Par consommation 31- Par consommation 24-Stratégie de 23-Stratégie
19-Stratégie de des prévisions des prévisions maintenance de révision
maintenance
27-Par transfert des ordres Arrêter
de production planifiées
25-Par validation
Figure 12. Un exemple de carte du modèle Possible
14Les Figures 11 et 12 montrent un exemple de comparaison des cartes à un niveau
donné (niveau 2). Nous avons sélectionné deux cartes, la première concerne le
Souhaité (Figure 11) tandis que la deuxième décrit le Possible (Figure 12). On
remarque très clairement que la carte du PGI est beaucoup plus riche que celle du
Souhaité. Cependant, il existe des stratégies dans la carte de la cible comme Par
révision tous les 6 mois qui n’ont pas de correspondant dans la carte du PGI, ce qui
nécessitera des développements spécifiques dans le nouveau système à mettre en
place.
6. Discussions
Ce papier a présenté un cadre méthodologique que nous sommes en train
d’expérimenter dans le contexte de l’évolution du SI par l’implantation d’un
système de type PGI à la SNCF.
Malgré le grand nombre de projets d’installation des PGI dans des entreprises de
différentes tailles (Joseph et al. 1998), les recherches académiques concernant les
problématiques liées aux aspects d’ingénierie restent limitées (Borell et al., 2000).
Les discussions avec des membres d’équipes d’autres projets d’installation de PGI
ont montré que notre approche est appropriée dans ce genre de projet, et que
beaucoup de décideurs adoptent des PGI sans explorer la mise en correspondance
entre leurs besoins et les fonctionnalités proposées dans le PGI en question. En fait,
l’un des plus importants facteurs d’achat d’un PGI est que ce genre de systèmes
propose les meilleurs pratiques métier. De plus, comme l’idée est d’adopter ces
pratiques métier en installant le PGI, l’évaluation des coûts et de la valeur ajoutée de
leur adoption à travers un processus de mise en correspondance avec les exigences
métier est souvent oublié (Robey et al., 2002).
Deux familles d’approches ont été développées pour traiter le problème de mise
en correspondance : l’approche du management et l’approche du système. Dans
l’approche du management, les recherches visent à définir l’impact de l’installation
de PGI sur la culture d’entreprise (Krumbholz et al. 2000), sur l’organisation (Robey
et al., 2002) ou sur les processus métier (Esteves et al., 2002). Dans l’approche
système, l’objectif était de guider l’identification et la sélection du PGI le plus
approprié (Ncube et al., 2000), et d’analyser les besoins pour proposer le meilleur
paramétrage du PGI (Finkelstein et al., 2002).
Notre approche (Salinesi et al., 2003), (Zoukar et al., 2004a), (Zoukar et al.,
2004b) est à mi-chemin entre ces deux familles. L’hypothèse essentielle est que,
dans un projet d’installation d’un PGI, la question du changement organisationnel et
celle de l’ingénierie du système sont entrelacées. Par conséquent, la mise en
correspondance du PGI et des exigences de l’organisation ne devrait pas être dirigée
ni par le management ni par les fonctionnalités du système, mais par les deux en
même temps.
15Des discussions ont été entreprises pour choisir parmi les solutions alternatives
résultant du processus de mise en correspondance. On a constaté que ces décisions
ont été prises en utilisant un certain nombre de critères tels que le pourcentage des
développements spécifiques, la non-régression, les coûts, les délais de mise en place,
les compétences nécessaires, les marges de négociation, la valeur ajoutée, etc. Il s'est
avéré pendant les discussions que nous avons eues avec l’équipe projet que non
seulement ces critères n'ont pas le même poids, mais également le poids de chaque
critère pouvait changer selon le contexte. L'analyse de profit peut être supportée par
des techniques telles que l'Aide à la Décision Multicritères (Roy et al., 1993), ou
l’AHP (Analytic Hierarchy Process) (Saaty 1988). Cependant, ces techniques ne
tiennent pas compte du fait que les poids de critères peuvent changer, et donc elles
ne sont pas appropriées quand un grand nombre d’exigences est traité. Des
techniques plus avancées sont donc nécessaires.
Nos recherches courantes et futures incluent donc :
- Le développement d'un processus méthodologique pour guider la découverte
des exigences par les écarts et les similarités ;
- La formalisation d'un processus de mise en correspondance dans un contexte
de personnalisation des composants ;
- L’évaluation de la méthode proposée.
Bibliographie
Borell A., Hedman J. CVA Based Framework for ERP Requirement Specification. Procs. of
IRIS 23. Laboratorium for Interaction Technology, University of Trollhattan Uddevalla,
2000.
Davenport T.H. Putting the Enterprise into the Enterprise System. Harvard Business
Review.(76:4), pp. 121-131, 1998.
Davenport T.H. Mission Critical: Realizing the Promise of Enterprise Systems. Harvard
Business. School Press, MA, 2000.
Esteves J., Pastor J., Casanovas J. Monitoring Business Process Redesign in ERP
Implementation Projects. Americas Conference on Information Systems, Dallas, 2002.
Esteves J., Pastor J. Strategic and Tactical Critical Success Factors Behavior Along the ERP
Implementation Phases. The European Conference on Information Technology Evaluation
(ECITE), Madrid (Spain), September 2003
Finkelstein A., Bush D. Requirements Elicitation for Complex Safety Related Systems. Procs
London Communication Symposium. London, UK, Sept. 2002
Jarke M., Pohl K. Establishing visions in context: towrd a model of requirements processe. In
Procs 12th International Conference Information System. Orlando, FI, 1993.
Joseph T., Swanson E.B. The Package Alternative in Systems Replacement: Evidence for
Innovation Convergence, in Information Systems Innovation and Diffusion: Issues and
Direction. Larsen & McGuire (eds.), IDEA-Group, Hershey, PA, pp. 375-389, 1998.
16Khan A.H. Implementing SAP with an ASAP Methodology Focus. Paperback (0595233988),
July 2002.0595233988
Krumbholz M., Maiden N.A.M. How Culture might impact on the Implementation of
Enterprise Resource Planning Packages. Procs of CAISE'00, Springer Verlag, Ref.
HCID00/04, 2000.
Maiden N.A.M., Ncube C. Acquiring COTS Software Selection Requirements. IEEE
Software March/April 1998, pp. 46-54, 1998.
Ncube C., Maiden N.A.M. COTS Software Selection: The Need to Make Tradeoffs Between
System Requirements, Architectures and COTS/Components. Procs of the COTS*2000
Workshop for ACSE*2000, Limerick, Ireland, ref. HCID00/02, 2000.
Nurcan S., Etien A., Kaabi R. Zoukar I. A Strategy Driven Business Process Modeling
Approach. Special issue of the Business Process Management Journal on "Goal-oriented
Business Process Modeling", Emerald. To appear. 2004.
Robey D., Ross J.W., Boudreau M-C. Learning to Implement Enterprise Systems: An
Exploratory Study of the Dialectics of Change. Journal of Management Information
Systems, Summer 2002
Rolland C., Prakash N. Bridging the Gap Between Organisational Needs and ERP
Functionality. In Requirements Engineering Journal, 5(2000).
Rolland C., Prakash N. Matching ERP System Functionality to Customer Requirements. The
5th IEEE International Symposium on Requirements Engineering, Toronto, Canada. 2001.
Roy B., Bouyssou D. Decision-Aid, An Elementary Introduction with Emphasis on Multiple
Criteria. Journal of Information Science and Technology, 2(2), pp 109-123. 1993
Saaty T.L. The Analytic Hierarchy Process. University of Pittsburgh, 1988.
Scheer A.W., Jost W., Abolhassan F. Business Process Excellence: Aris in Practice. Springer
Verlag, Berlin. (2002).
Salinesi C., Rolland C. Fitting Business Models to Software Functionality : Exploring the
Fitness Relationship. Procs of the 15th Conference on Advanced Information Systems
Engineering, (CAISE'03), Springer Verlag (pub), 2003.
Salinesi C., Etien A. Zoukar I. A Systematic Approach to Express IS Evolution Requirements
Using Gap Modelling and Similarity Modelling Techniques. Procs of the 16th Conference
on Advanced Information Systems Engineering (CAISE'04), Riga, Latvia. June 2004.
The Standish Group. Chaos. Standish Group Internal Report. www.standishgroup.com/
sample_research/chaos_1994_1.php, 1995.
Zoukar I, Salinesi C. Engineering the Fitness Relationship between an ERP and the Supply
Chain Process at SNCF. IRMA' 2004, 15th International Conference of the Information
Resource Management Association, New Orleans, Louisiana, USA. May 2004
Zoukar I, Salinesi C. Matching ERP Functionalities with the Logistic Requirements of French
railways - A Similarity Approach. ICEIS' 2004, 6th International Conference on
Enterprise Information Systems. Porto, Portugal, April 2004.
17Vous pouvez aussi lire
