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

 
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.

                                               1
1. 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.

                                                 2
Nous 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

                                                        3
Notre 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

                                                       4
Le 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

                                                     5
A 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).

                                                       6
3. 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

                                                  7
Planning 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

                                                                            9
un 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

                                              10
spé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.

                                                  11
5. 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

                                                     12
projet 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.

                                                                                                              13
Des 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

                                                                                          14
Les 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.

                                          15
Des 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.

                                             16
Khan 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.

                                             17
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler