La société a
été créée en 1997 par des anciens
consultants de la société IRI Software. A sa
création, la société n’est implantée que
dans la région parisienne et est connue sous le nom de DSA
Systèmes.
L’activité de DSA Systèmes à sa
création était essentiellement fondée sur la
technologie Oracle Express. DSA Systèmes est rapidement devenue
le premier partenaire d’Oracle sur son offre de Business Intelligence
(Oracle Express, Oracle Sales Analyzer, Oracle Financial Analyzer,
etc.).
Depuis 2001, la société a étendu
progressivement son offre en intégrant les technologies majeures
du marché de la Business Intelligence. C’est ainsi que se sont
créés progressivement les pôles de
compétences suivants : Hyperion Solutions, Business Objects,
Cognos, et Microsoft.
En 2001, DSA Systèmes acquiert MIDI-PARTNERS, pôle
Décisionnel de MIRIAD Technologies à Toulouse. En 2003,
DSA Systèmes devient i-d6, la société comprend
alors deux sites d’implantation : Levallois-Perret (siège
social) et Toulouse. L’acquisition de Prospective Software,
basée à Nantes fin 2006 permet à i-d6 de
consolidée sa position dans l’Ouest.
Enfin, i-d6 rejoint le groupe Novedia à
Boulogne-Billancourt en 2007 pour compléter son
offre et devient par la même occasion Novedia Décision.
Figure 2 : Novédia
Décision [3]
Novedia Décision propose une offre complète de services,
de l’analyse de l’environnement jusqu'à
l'intégration des solutions. Elle est depuis plus de 10 ans au
service de la Business Intelligence et accompagne ses clients sur toute
la chaîne décisionnelle :
-
Intégration de données
- Définition et gestion des
entrepôts de données
- Analyse et reporting
- Gestion de la performance
Conseil
:
Spécialiste des solutions
logicielles et spécialiste métiers, Novedia
Décision guide ses clients dans la préparation de leurs
projets et garantit leur bon déroulement :
- Choix d’outils
et de solutions
décisionnelles
- Conseil d’architectures
- Assistance à maîtrise d’ouvrage
(rédaction de cahier des charges, suivi et gestion de projet...)
- Audits et optimisations
Intégration
- L’engagement
de Novedia Décision se poursuit en phase d'intégration
pour une meilleure cohérence entre la solution
préconisée et les structures de
l’entreprise cliente afin
d’avoir une maîtrise sans faille des coûts et des
délais du projet.
Accompagnement
- Novedia
Décision assure la pérennité de l’investissement
de ses clients sur le long terme depuis le transfert de
compétences auprès des utilisateurs cibles
jusqu'à
la maintenance de leurs applications.
- Mise à disposition de ressources
- Formation, Transfert de compétences
- Expertises (installation, migrations,
optimisations…)
Externalisation
- Le pôle
dédié à l'externalisation prend en charge le
rapprochement et le traitement des données avec la garantie
d'une exécution rapide et la mise à
disposition de
tableaux de bords dynamiques et personnalisés, essentielles
à une performance opérationnelle durable.
- Prise en charge complète du
Système d’Information Décisionnel
- Tierce Maintenance Applicative (à
distance ou chez le client)
- Mise à disposition de
reporting/tableaux de bords directement aux utilisateurs
Compétences
métier
Cette offre complète de
services est associée à une forte compétence métier, notamment dans les domaines de la
finance, du marketing & ventes, de la santé et du
développement durable.
II.3 BU SOLUTIONS
DECISIONNELLES
La « BU Solutions Décisionnelles »
à l’origine « BU Pharma
»
a
été
créée
par
Nicolas
Faivre
d’Arcier
depuis
1998.
Ses
clients
était des Laboratoires
Pharmaceutiques à 90 % ,à savoir : GSK, SP, ABBOTT,
SOLVAY, MUNDI, MENARINI, ALMIRALL, BOUCHARA, CONVATEC, ZAMBON, et le
GERS Groupement pour l’Elaboration et la Réalisation de
Statistiques. Ce dernier est un groupement d'intérêt
économique (GIE), créé par les entreprises de
l'industrie pharmaceutique, qui ont décidé de mettre en
commun leurs données de ventes Ville et Hôpital, utiles
pour la compréhension et le suivi de leurs marchés [1].
Depuis la fusion d’i-d6 et Novédia Group en 2008, la BU
pharma fait parti de l’entité Novédia Décision.
Elle a connu l’arrivée de nouveaux clients dans d’autres
domaines, voulant bénéficier de ses services, tels que :
Mattel Télécom(Mauritanie), Tunisie
Télécom(Tunisie), Colipost et dernièrement SFR.
D’où la raison de la renommer en « BU Solutions Décisionnelles ».
Actuellement, l’équipe de la BU est composée de 6
acteurs, le manager et 5 consultants ayant suivi une formation de
type Master 2 en Informatique Décisionnel. Depuis Février
2010, je fais partie de son équipe pour y effectuer mon stage de
fin d’étude. L’organigramme ci-dessous situe la «BU Solutions Décisionnelles» par
rapport
à
«Novédia
Décision».
Figure 6 : Situation de la BU
Solution décisionnelle [3]
La « BU
Solutions Décisionnelles
» propose plusieurs offres adaptées à
ses clients dans le but de mieux exploiter leurs données
et établir des analyses pertinentes, avec un réel impact
décisionnel :
- L’offre
Dyn@Reports : application lancée il y a maintenant 5 ans,
est une solution simple et modulable de reporting interactif sous
Excel, qui permet aux forces de vente suivre, sur des tableaux de bord
dynamiques et personnalisés, la réalisation de leurs
objectifs, leurs parts de marché et de les croiser avec leurs
indicateurs d'activité pour analyser leurs performances commerciales. Il s’avère que plus de 80% des clients de
la « BU
Solutions Décisionnelles
» sont favorable à l’adoption de cette solution.
Figure 7 : L’offre Dyn@Reports
[3]
- Des Tableaux
de Bord personnalisés envoyés automatiquement aux
Directions des Ventes et Marketing. (Hors Dyn@Reports).
- L’offre NAVBOARD : c’est une solution
innovante développée en Flash/flex. Elle est
orientée web, elle vise la souplesse dans la navigation de
l’utilisateur en utilisant des interfaces interactives et ergonomiques.
Elle couvre les mêmes fonctionnalités de
l’offre Dyn@Report , avec un aspect esthétique attirant l’œil de
l’’utilisateur.
Figure 8 : L’offre Navboard
[3]
L’organisation du travail dans la « BU Solutions
Décisionnelles » consiste à administrer les comptes
des clients, de manière à ce que chaque membre de
l’équipe a en charge un ou plusieurs comptes. L’administration
consiste à réaliser chaque mois :
- La mise à jour la base de
données du client
- La mise à jour les demandes de
modifications du client
- La génération des tableaux
de bords
- La diffusion des tableaux de bords
- L’Aide à la compréhension
des tableaux de bords
III.1 PHASE DE
FORMALISATION :
III.1.1
CONTEXTE ET ENJEUX DU PROJET :
La mission du stage concerne
l’administration du compte du laboratoire GLAXOSMITHKLIN (GSK) deuxième
laboratoire pharmaceutique mondial. Il affiche une présence
forte dans une vingtaine de domaines thérapeutiques. Sans
oublier une place prépondérante en vaccinologie et dans
les domaines de l'hygiène buccodentaire et
l'automédication. [2]
GSK fait confiance au service d’externalisation du traitement des
données brutes de NOVEDIA
DECISION depuis 5 ans. Un service qui a comme enjeux
de garantir à la fois rapidité d'exécution et la
qualité de l’information transmise.
Selon le manager responsable du projet d’externalisation de la
gestion de ses ventes chez GSK,
le
choix
s’est
porté
sur
NOVEDIA
DECISION. Compte
tenu de
la complexité des données à traiter et de la
capacité de ses services à raccourcir
considérablement le cycle de production des TDB. De plus, NOVEDIA DECISION est
familière au langage des laboratoires et sait s'adapter à
l'évolution du besoin de GSK et constitue, au-delà de sa
mission de maintenance applicative, une force de proposition.[3].
GSK envoie un volume
important d'informations sur ses ventes, provenant de sources de
données multiples. L’objectif étant de produire des
TDB en transformant ces données brutes en en indicateurs
de performances. Le traitement informatique s’effectue en interne chez
la «BU SOLUTION
DECISIONNELLE».
A
savoir,
le
traitement
de
l’information,
chargement
dans
une
base
de
données,
traitement et corrélation des différentes
sources entre elles et constitution des TDB qui sont transmis par la
suite dans les 24h.
Face à la multiplicité et la complexité des
informations à traiter, le client n’a pas forcement le temps de
vérifier les données qu’il envoie à la «BU SOLUTION
DECISIONNELLE».
Après
le
traitement
de
ces
données,
il
s’avère
que
souvent
elles
peuvent
contenir des erreurs qui altèrent la
qualité des TDB.
Pour la «BU SOLUTION
DECISIONNELLE»
la satisfaction du client est primordiale, cependant la production de
TDB contenant des anomalies devient de plus en plus fréquente.
En effet, cette problématique a des conséquences à
la fois sur la qualité des TDB transmis au client et sur la
durée de leurs traitements qui devient de plus en plus longue,
soit au-delà des 24h.
D’où la nécessité de mettre en place une
méthodologie de contrôle de la qualité des
données brutes reçu par la «BU SOLUTION DECISIONNELLE».L’objectif
est d’améliorer le processus de traitement et de
production de TDB. Ce processus sera appliqué par la suite pour
l’ensemble des clients de la «BU SOLUTION DECISIONNELLE».
III.1.2 CLARIFICATION DE LA
PROBLEMATIQUE :
Dans un premier temps, une réunion a été
faite avec le consultant chargé de l’administration du compte
GSK pour l’encadrement et la clarification de la problématique
ainsi que la définition de ses objectifs. Le QQOQCP ci-dessous fait un récapitulatif de la
problématique :
Figure 9 : QQOQCP [8]
Il s’est avéré que l’on ne s’aperçoit de
l’existence d’anomalies qu’après avoir envoyé les TDB
finaux au client. En effet, c’est après que le processus de
traitement des données soit terminé que le client
intervient pour valider les TDB. Par conséquent lorsque ce
dernier s’aperçoit d’une non-conformité, il fait un
retour pour établir de nouvelles modifications sur les
données d’entrée et le processus de traitement se refait
à nouveau. Il arrive que parfois ce processus se
répète jusqu’à 5 fois par mois.
Le réel problème fut donc de trouver d’où
proviennent les erreurs et qu’est ce qui fait que l’on ne
s’aperçoive pas dans la «BU SOLUTION DECISIONNELLE» avant
de
transmettre
les
livrables
au
client.
III.1.3 ANALYSE DE
LA SITUATION ACTUELLE :
III.1.3.1 Analyse des
ressources humaines
et matérielles:
III.1.3.1.1 Ressources
humaines &
Organisation:
Sur l’administration du compte GSK collabore deux interlocuteurs
directs : un consultant chez la «BU SOLUTION DECISIONNELLE» et
un responsable des études chez le client. Il représente
la seule personne à contacter en cas de production d’incidents.
L’organisation entre ces deux acteurs se fait à base
d’échanges d’e-mails ou d’appels téléphoniques en
cas d’ambigüité. Un planning approximatif a
été établi pour pouvoir se repérer dans le
temps les dates d’échanges des données selon leurs types.
Il a été constaté que ce planning n’a pas
été souvent respecté, dû soit à
l’indisponibilité de l’un des interlocuteurs soit à
cause de leurs surcharges de travail ou à un retard de
réception des données des sources externes. En effet les
données que le client envoi sont livrés par d’autres
organisme, parmi eux le GERS. Un retard de livraison d’un de ces
organismes implique donc un retard d’envoi des données au
consultant et don décalage dans le planning établi.
III.1.3.1.2 Ressources
matérielles
& Système d’archivage:
Pour se baser sur des faits réels, il a été
nécessaire de consulter les historiques des incidents
produits précédemment. Mais malheureusement le compte de
ce client a été précédemment
géré par plusieurs consultants et le mode d’organisation
dans l’administration du compte n’a pas été identique,
par conséquent des archives régulières n’ont pas
pu être identifiées.
Les seuls enregistrements sauvegardés étaient les
résultats finaux de chaque mois, à savoir que les TDB
validés par le client. Les TDB contenant des erreurs n’avaient
pas de trace dans les archives de l’administration de compte client. De
plus, il n’y avait pas de traçabilité des
différents incidents produits au cours des dernières
périodes. Un nombre important d’incidents se produisent
mensuellement, ils doivent être corrigés rapidement et
renvoyer les TDB modifiés au client dans les plus courts
délais. Dans ces situations de traitement d’urgence, le
consultant ne se préoccupe pas principalement d’archiver
à chaque fois le type d’incidents.
III.1.3.2 Analyse du
processus de
traitement des données :
Un état des lieux initial a été
effectué pour mieux comprendre comment se
déroule le processus de traitement des données au sein de
la « «BU SOLUTION
DECISIONNELLE»
et de production des TDB pour le client.
Figure 10: Processus de
production des TDB-1[8]
Ce qui a été
remarqué est que tout au long du processus il n’y a pas de
vérification des données intermédiaire. La seule
vérification s’effectue après la production des TDB, par
le client externe. Par conséquent, toute anomalie dans un des
TDB oblige à refaire le processus de traitement dés le
départ.
Chaque mois, environ 500 TDB sont produits de différents
types. En effet, la «BU SOLUTION DECISIONNELLE»
reçoit différents types de sources de données par
GSK, elles sont classées en 9 catégories:
• GERS + Ville
• Performance GERS + Ville
• GERS + Hôpital
• Performance GERS + Hôpital
• Ventes Internes
• SDM TOT
• SDMSP
• Pharma TOT
• Labo Générique
A Chacun de ces types fichiers s’applique le même processus
de traitement décrit ci-dessus (Figure 10), ce qui fait que pour
obtenir l’ensemble des TDB il faut appliquer 9 fois le processus
classique de production des TDB, soit en moyenne ½
journée de travail par processus et 5 jours pour l’ensemble en
temps normal.
Sachant que la vérification du client se fait à la
fin du mois sur l’ensemble des TDB, c à d les 500, une
détection d’une non-conformité oblige à
répéter l’ensemble des processus de nouveau pour extraire
une nouvelle version de TDB, jusqu’à leurs validation.
Ces fichiers arrivent dans un ordre chronologique tout au long du mois. Il est à noter qu’un fichier particulier
est reçu en premier, il sert à mettre en place la
structure des produits. Ce fichier suit un processus de traitement
différent :
Figure 11 : Processus de
traitement de la structure des produits [8]
Le chargement de la structure des
produits sert à préparer la base de données pour
la réception des autres fichiers des données de ventes
qui arrivent par la suite. Le client possède à peu
près de 6000 produits dans sa base de données, ce qui est
impossible à vérifier à l’œil nue.
Les données de structures de la base de données,
notamment la structure hiérarchique des produits, la structure
hiérarchique du temps et la structure hiérarchique des
géographies, sont des données transversales pour
l’ensemble des types de fichiers à charger,
énumérés ci dessus. Il est important de les avoir
mis à jour au début avant l’intégration de tout
autre type de données dans la base. Une fausse
hiérarchie, implique des données défectueuses en
sortie et donc des TDB incorrectes.
III.1.3.3 Les sources
d’erreur :
Pour en savoir plus sur les types des non-conformités qui
se produisent, une enquête a été effectuée
sur les sources des erreurs et à quel moment les
détecte-t-on.
Malheureusement, l’historique des différentes erreurs
produites précédemment n’a pas été
sauvegardé, ainsi pour répondre au questionnaire, il a
été fait appel à la mémoire de consultant
interne sur les incidents les plus importants qu’il a
eu dernièrement avec un détail approximatif sur leurs
fréquences. Le tableau suivant résume les 4 types
d’incidents les plus marquants :
Figure 12: Fréquence des
Erreurs produites [8]
Les problèmes retenus proviennent de deux fichiers sources
différents, 3 d’entre eux proviennent du fichier de structure
des produits et le dernier concerne les données provenant du
GERS.
Dans le domaine de l’industrie pharmaceutique, chaque forme de
médicament d’un laboratoire est appelée «
Présentation », elle est identifiée par un
code Club Inter Pharmaceutique ou code CIP. Ce code est unique par
présentation, il correspondant à l'autorisation de mise
sur le marché (AMM) d'une présentation d'un
médicament. Ce code est composé de 7 chiffres dont le
dernier numéro est la clé de contrôle du
médicament.
Les fichiers de données envoyés par le client sont
transmis au niveau présentation. Cependant dans la base de
données, ces présentations font partie d’une
structure qui détermine le nom du produit, la famille de
produits, le marché auxquels chaque présentation fait
partie. Cette structure des produits est définie par le client
qu’il nous envoie sous format d’un fichier Excel à chaque
début de mois pour mettre à jour la base de
données. Dans la figure 13, on représente la
manière dont sont structurées les présentations de ce client :
Figure 13: Structure des produits
[8]
Ici, la hiérarchie est constituée de 10 niveaux
où les CIP des présentations représentent les
feuilles de l’arbre. Chaque niveau possède un code et un
libellé. Une ligne du fichier forme une hiérarchie
complète d’une présentation. De plus, chaque
présentation possède un historique de ses coefficients
d’une durée de 36 mois, soit 36 coefficients par ligne. En
effet, une présentation a un coefficient par mois, il
sert pour le calcul de quelques indicateurs.
En total la base de données du client contient
jusqu’à 5938 présentations, elle est en croissance
continue. Dans le document de la structure des produits, le client
indique uniquement le détail des présentations à
ajouter et celle à supprimer. Ce fichier est maintenu
manuellement par l’interlocuteur externe, chez le client
Omettre un espace ou en ajouter un dans un des codes ou
libellé est considéré comme une erreur. Pour
éviter ce genre d’incident, à la fin de chaque mois et
après avoir produit l’ensemble des TDB, un formulaire de la
structure des produits mis à jour est envoyé au client.
Ceci lui permettra de faire les modifications directement dessus sans
avoir à réécrire les codes manuellement, sauf pour
les nouveaux codes.
Mais, malgré ceci, il a été aperçu que
les incidents provenant de ce fichier continuent à survenir, Les
plus récurrentes sont:
• CIP Attaché à une mauvaise
hiérarchie
• Code ou Libellé incorrecte
• Un ou plusieurs coefficients erronés
Les deux premiers incidents sont qualifiés de haute
gravité (Niveau 5) à cause de leurs fréquences qui
s’élève à 5 fois tout les mois et à leur
impact sur les TDB à extraire, en effet si un de ces incidents
se produit ceci fausse la totalité des TDB extraits
mensuellement. Le troisième incident, est qualifié de
gravité moyenne, vu qu’il se produit soit une fois par trimestre
malgré qu’il ait un impact sur tous les TDB.
Ces incidents sont qualifiés d’externes, cependant dans le
processus interne de traitement de la structure des produits, il
n’existe pas de moyens fonctionnels, mis à part la
vérification visuelle, pour alerter le consultant sur
l’existence d’anomalie dans le fichier.
Il existe un autre type d’incident d’une gravité moyenne,
il concerne la publication des chiffres dans le Journal officiel et
ceux diffusés dans les TDB. En effet les chiffres
publiés dans le JO doivent correspondre aux chiffres des TDB.
Dans les spécialités d’un laboratoire
pharmaceutique, il existe ce qu’on appelle des
spécialités génériques. Un
médicament générique est la copie d'un
médicament original (=princeps) dont le brevet est tombé
dans le domaine public. Un laboratoire qui découvre une
molécule la fait breveter et conserve ce brevet pour environ 20
ans à l’origine. On estime qu'il faut 10 ans pour mettre au
point un médicament depuis sa découverte jusqu'à
sa commercialisation, de sa commercialisation à la fin du brevet
il reste alors 10 ans en moyenne pour rentabiliser son
médicament. Une fois les 20 ans passés depuis la
découverte de la molécule et donc le brevet tombé,
d'autres laboratoires peuvent copier le médicament original, on
parle alors de générique ou médicament
générique [4].
Et, comme pour toute spécialité pharmaceutique, une
spécialité générique doit faire l’objet,
avant sa commercialisation, d’une AMM délivrée par le
Directeur général de l’Agence, dans le cadre soit d’une
procédure purement nationale, soit d’une procédure
européenne de reconnaissance mutuelle. [5]
L’inscription ou modification au répertoire des groupes
génériques sont mises en ligne sur le site internet de
l'Afssaps à titre indicatif. La substitution des
spécialités génériques respectivement
inscrites dans ces décisions ne devra intervenir qu'après
la publication de ces décisions au Journal officiel [5]
Cependant, des écarts ont été
constatés dans les chiffres publiés dans le JO du mois de
février et ceux des TDB Fournis au client. Ceci était
dû au fait qu’une spécialité
générique n’avait pas été
ajouté au répertoire des génériques par le
Gers, malgré son apparition comme étant
générique au JO.
Comme d’habitude, ces données fournis au client par le
GERS, ont été transmis au consultant interne pour les
traiter. La raison pour laquelle les TDB produits pour le client furent
non conforme. Ceci est un incident rare mais reste important vu que la
qualité des TDB fournis s’évalue chez le client en
fonction de la concordance entre les chiffres fournis et ceux
publiés au JO.
Le diagramme cause-effet ci-dessous, résume les origines
des erreurs identifiées qui altère la
qualité des TDB produits. Elles ont été
classées selon leur origine externe ou interne :
Figure 14 : Diagramme Cause-Effet
[8]
III.1.4
OBJECTIFS
:
A présent, les missions du projet se sont clarifiées
et les premiers objectifs mesurables ont été
identifiés. Le PDS ci-dessous résume le cercle
d’améliorations continues qui sera suivi pour arriver aux
résultats attendus, à partir de la
spécification des besoins du client interne.
Figure 15 : Planification
dynamique Stratégique [8]
Les 3 objectifs mesurables identifiés sont les suivant :
1- Authentifier 100% des anomalies avant la
production des rapports finaux.
2- Réduire le nombre de
répétition de création des TDB à 0.
3- Produire la totalité des TDB en une
durée de 5 jours au total.
III.2 PHASE DE DEFINITION :
Les axes sur lesquels les solutions seront proposées
agissent particulièrement sur l’amélioration de
l’organisation en interne, elles ont été définit
en suivant les étapes suivantes :
- Solutions pour analyser &
contrôler les données.
- Evaluer les risques
- Suivre et mesurer les écarts.
- Informer & communiquer
- Archiver & capitaliser
III.2.1 Solutions
pour
analyser & contrôler les données :
Dans les informations fournis par
le client, il faut faire la distinction entre les fichiers de
données chiffrés et les fichiers de structures des
données. Pour attribuer une priorité sur quel type de
fichier source d’erreur faut il agir, On s’est basé sur la
gravité des incidents énuméré lors de la
phase d’analyse des causes.
Par conséquent, il a
été décidé de se focaliser dans un premier
temps sur le contrôle des données du fichier de la
structure des produits.
Suite à un brainstorming, plusieurs solutions furent
proposées dont le but était de valider
les données avec le client avant chargement des données
dans la base. La figure ci-dessus montre où seront placé
les procédures de contrôle dans le processus de traitement
des de la structure des produits.
Figure 16 : Processus de
production des TDB-2 [8]
En effet, deux types de contrôles doivent être
réalisés :
- Contrôle de la forme du fichier
- Contrôle du contenu
Le premier est une vérification visuelle du format des
données, à savoir : la date, le nombre de colonne au
total doit être égale à 96, le nombre de produit
à ajouter et ceux à supprimer, en plus de la moyenne des
coefficients par CIP.
Pour le second contrôle, il faut mettre en place un
programme informatique qui contrôle la structure des produits
reçues par le client tous les mois. Le programme doit
vérifier SI :
- Les codes existent déjà dans la
base de données.
- Les libellés des codes
déjà existants sont identiques.
- Les coefficients des codes déjà
existants sont modifiés.
Le programme génère par la suite, un rapport pour chaque
présentation du fichier de structure avec un message d’alerte en
cas de modification d’un des champs par rapport à son homologue
dans la base de données. Il donne également le nombre des
nouvelles présentations à ajouter et le nombre de celles
à modifier.
Pour les données numériques, la seule solution
possible à mettre en place est de créer des TDB de
validation des indicateurs de bases fournis avec les fichiers de
données tel que : le chiffre d’affaire et les unités de
ventes. Cette solution sera étudiée plus en détail
une fois que la première sera opérationnelle.
III.2.2
Analyser les
risques :
Quelques risques liés à la mise en place de cette
solution furent identifiés, par
conséquent un plan d’actions préventives et correctives a
été établi, comme le montre la figure ci-dessous.
Figure 17 : Analyse des risques
[8]
Le premier risque est que des erreurs identifiées par le
client externe peuvent continuer à survenir, malgré
le résultat fourni par le programme informatique. Par
conséquent, il faut créer un fichier de capitalisation de
ces retours pour pouvoir proposer une solution pour les authentifier
avant que le client ne le fasse.
D’autre part, le fichier envoyé au client peut être
mal interprété à cause du manque de temps de ce
dernier ou encore la quantité de l’information qui figure
dessus. Dans ce cas là, il faut revoir la mise en forme du
rapport envoyé en allégeant l’information dessus ou en
ajoutant des repères attirant l’œil du lecteur plus facilement,
par exemple en changeant les couleurs ou encore la police. De plus, il
est nécessaire de mettre des indicateurs de performance pour
pouvoir guider les ressources interne au plan d’action à
appliquer.
III.2.3 Suivre et
mesurer les écarts
Pour le suivi de ce processus ci-dessus et prévenir les
risques identifiés, il a fallut créer des indicateurs de
performances. Ces indicateurs sont suivis chaque mois à chaque
réception des données de structures des produits. Ils
permettent d’évaluer la performance de la solution
proposée et de mesurer les écarts par rapport aux
objectifs définis au départ.
Pour rappel les objectif initiaux furent de :
1- Détecter 100% des anomalies avant la
production des TDB
2- Réduire le nombre de
répétition de création des TDB à 0.
3- Produire la totalité des TDB en une
durée de 5 jours au total.
Les paramètres à prendre en compte sont
mesurés tout au long du processus de traitement réparti
en trois phases :
1-
AVANT validation du client
Figure 18 : Indicateur de la
phase avant validation du client [8]
Il est clair que pour mesurer la performance du programme mis en place,
il faut calculer le pourcentage d’anomalies authentifiées par le
programme (Tb). Ces anomalies peuvent être des erreurs
potentielles si le client externe les identifie, sinon
elles représenteront des informations valides qu’on pourra
charger dans la base données.
2-
APRES validation du client
Figure 19 : Indicateurs de la
phase APRES validation du client [8]
«TVALIDE»
est le pourcentage d’anomalies qui furent identifié comme
étant des erreurs par le client externe. Cet indicateur permet
d’approuver à 100%, ou moins, la précision du programme
dans la détection des erreurs potentielles dans la
structure des produits.
«%VALIDE» correspond
au
taux
d’anomalie
(Tb)
après
la
validation
du
client.
Globalement
c’est
pour
observer l’évolution du taux d’anomalies
authentifié par le programme durant les trois phases. Le but
étant que celui mesurée lors de la
première phase reste constant tout au long du processus.
3- APRES production des
rapports finaux
Figure 20 : Indicateurs de la
phase APRES envoi des rapports au client [8]
Cette dernière phase est l’évaluation du processus
d’amélioration mis en place. Ici la fiabilité du
programme de contrôle est mesurée suite aux retours du
client. En effet, le taux d’erreur détectée (Ta)
correspond au pourcentage d’erreurs repérées soit par le
client externe ou le consultant interne après la production des
rapports.
Ces retours son comptabilisés (N3) dés lors ou le
processus de production de TDB se répète.les erreurs
authentifiées à ce stade doivent être
archivés, pour faire l’objet d’une amélioration continue
du processus mis en place.
L’ensemble des indicateurs identifiés sont suivit tout les mois
avec des seuils d’exigence, présenté
dans la figure ci-dessous :
Tableau 1 : Niveaux d’exigence
[8]
L’objectif est d’avoir un taux de fiabilité du processus
mis en place égal à 100% en s’assurant que toutes autres
erreurs ne doivent pas être authentifiées après la
production des rapports. Ceci implique que le nombre de
répétitions (N3) du processus de traitement des
données et production des TDB doit être nul.
Par ailleurs, il faut suivre la durée du traitement de
toutes les données du client, en mettant le seuil d’exigence
à 5 jours. Actuellement, cet indicateur est fait pour
l’observation de son évolution de mois en mois. Un fichier
de suivi doit donc être créé pour cet objectif.
III.2.4 Informer &
communiquer
Au niveau interne, cela consiste
à mettre en place une cartographie du processus de traitement du
fichier de structure des produits et rédiger une
procédure assurant aux collaborateurs l’utilisation et la
réalisation des étapes du processus.
Figure 21 : Cartographie du
Processus interne de traitement de la structure des produits
[8]
Au niveau externe, cela consiste à mettre au courant le
client de la mise en place de ce contrôle et son objectif
avec un document lui expliquant la manière dont il doit lire le
rapport. De plus, il faut l’informer de ce qui est attendu de sa part
et qu’est ce qu’il faut qu’il nous transmette en retour.
D’ailleurs, le rapport sorti par le programme doit être
transmis au client externe pour qu’il puisse le valider, confirmer
et/ou corriger les anomalies authentifiées.
III.2.5 Archiver et
capitaliser
Pour améliorer le système d’archivages, il est
important d’ajouter au processus de traitement des données cette
étape. En effet, il faut créer des versions à
chaque production de TDB. Cela permettra, à la fois de ne pas
perdre l’information même si elle n’est pas valide pour le
client, car elle le sera pour le suivi du processus en interne et
aidera à établir des études pour la mise en place
de solutions d’amélioration.
De plus, un fichier Excel doit être créé
pour capitaliser les différents échanges entre les
interlocuteurs internes et externes. Ainsi, des études
statistiques peuvent être faites sur les anomalies les plus
récurrentes, pour qu’elles soient transmises par la suite au
client. Ce dernier mettra en place des améliorations à
son processus de récupération et envoi des données.
III.3 Phase de
réalisation :
III.3.1 Résultats
obtenus :
Le processus fut mis en place et
appliqué sur les données du mois de Mars traitées
pendant le mois d’Avril. En effet le programme informatique a
été créé sous Oracle Express. Le fichier de
structure envoyé par le client est constitué de deux
onglets « Ajout » et « suppression ».Le
programme permet de lire onglet par onglet du fichier transmis et
établir des contrôles sur chaque ligne. En effet, il
reprend le code CIP de chaque présentation du fichier de faire
les tests suivant :
• SI les codes
existent déjà dans la base, alors il vérifie
l’orthographe de son libellé puis la correspondance de son
hiérarchie dans le fichier par rapport à celle dans la
base de données. A chaque fois que le programme trouve une
différence dans la hiérarchie existante, ce dernier
affiche un message avec le code CIP concerné en indiquant qu’il
s’agit d’une modification en précisant c’est à quel
niveau qu’elle se trouve (cf. ANNEXE 1).
• Si les codes
CIP son de nouveaux codes, le programme affiche un message dans le
rapport avec le code CIP correspondant, puis il vérifie si les
niveaux de la hiérarchie de ce dernier existent ou pas dans la
base de données. Dans le cas ou le programme ne détecte
aucune différence rien n’est affiché, par contre dans le
cas inverse un message affiche qu’elle niveau sera ajouté.
Au fur et à mesure de l’exécution du programme, deux
compteurs s’incrémentent : un pour les nouvelles
présentations et l’autre pour celle qui font l’objet de
modification. Ces deux compteurs sont affichés à la fin
pour permette au client de les valider.
AVANT validation du
client
Lors de la première application du programme sur le fichier
de structure des produits du mois de Mars. Le programme a
authentifié 21 sur 156 CIP déjà existants dans la
base de données, le rapport donnait le détail de chacune
d’entre elle (cf. ANNEXE 1).
Tableau 2 : Indicateurs Avant
validation [8]
Ce rapport muni d’une une procédure explicative ont
été transmis par la suite à l’interlocuteur
externe. La procédure décrit la forme du rapport
envoyé et explique au client la manière dont il doit
interpréter les messages affichés. De plus, un plan
d’action lui est proposé au client pour montrer comment il
pourrait agir par rapport à chaque message (Cf. ANNEXE 2).
La procédure prévient aussi le client que tant que ces
données ne sont pas validées, c'est-à-dire que
tant qu’on n’a pas de retours de sa part sur le rapport envoyé,
la structure des produits ne sera pas chargée dans la base de
données.
Dans un premier temps le client n’a pas pris en compte
l’importance de ses retours sur ce rapport envoyé, il a
continué à transmettre les autres données à
charger comme prédéfini dans le planning
d’échanges. Cependant, il a fallut le relancer une seconde fois
pour avoir une réponse à ce sujet et pouvoir passer
à l’étape du chargement des données.
APRES
validation du client
Il s’est avéré que les 21 présentations
authentifiées comme déjà existantes
furent
à
supprimer
et
non
pas
à
ajouter.
A
cette
étape
voici
les indicateurs enregistrés.
Tableau 3 : Indicateurs
Après validation du client [8]
APRES production des rapports finaux
Le traitement des données
de Mars fut un peu particulier. En effet, durant ce mois ci des
modifications devaient être intégrées dans les TDB
suite à la demande du client. Ce qui rendu la durée total
du processus beaucoup plus longue que d’habitude.
Tableau 4 : Indicateurs
Après production des rapports [8]
Les indicateurs obtenus pour les données de ce mois sont
conformes au seuil d’exigence attendu. En effet on a obtenu 100% sur la
fiabilité du processus et 0% sur l’authentification d’autres
erreurs après chargement du programme. De plus,
l’exécution du processus ne s’est déroulé qu’une
seule fois, il n’y a pas eu de répétition à cause
des erreurs de la structure des produits.
III.3.2 Capitalisation
&
Prévisions
Les premiers résultats obtenus sont satisfaisants mais pas
absolus. Un mois d’observation n’est pas suffisant, en effet les
indicateurs doivent être enregistrés chaque mois pour
pouvoir suivre leur évolution dans le temps au moins pendant 6
mois. Il peut y avoir d’autres anomalies particulières qui ne se
sont pas produites ce mois ci. Par conséquent, il n’a pas
été possible d’intégrer des améliorations
sur le nouveau processus mise en place pour ce mois.
Cela a donc permis d’avancer sur l’amélioration du suivi du
planning des tâche effectuées mensuellement par les deux
interlocuteurs et qui font l’objets des échanges entre eux.
Dans un premier temps un fichier de suivi du planning a
été créé, pour pouvoir observer le
déroulement des échanges entre interlocuteurs, pendant un
mois de traitement, suite à l’intégration de cette
nouvelle étape de contrôle de la structure des produits.
Cela permettra d’identifier les origines des retards dans le planning
et les tâches qui provoquent plus de retard que d’autres.
Ensuite, une étude sera réalisée pour
l’amélioration du planning de traitement des données et
mettre en place une procédure adaptée à son suivi.
(Cf. ANNEXE 3)
Une fois les objectifs de la solution apportée sont
atteints, on entamera la seconde partie de notre démarche
qualité menée qui concerne le contrôle des
données chiffrés. La mise en place des rapports de
validation des données chiffrées est indispensable pour
assurer la validité des TDB envoyés par la suite.
De plus le choix de faire une intégration progressive des
différentes solutions a été fait
intentionnellement pour ne pas brusquer le client par rapport à
ses habitudes de traitements et lui faire accepter ces nouvelles
méthodes petit à petit.
A moyen terme, cette démarche qualité englobera
l’ensemble du processus de traitement des données en interne,
à savoir le processus de production de chaque type de TDB. Elle
fera l’objet de la mise en place d’un autodiagnostic des bonnes
pratiques pour pouvoir assurer sa pérennité et suivre
l’évolution de son application dans le temps.
Les gains et les résultats obtenus vont assurer
l’efficience du processus de traitement des données en interne.
Ceci permettra d’impliquer le client pour assurer la qualité de
la partie externe de ce processus et le rendre efficace. Ainsi, la
démarche qualité mise en place sera complète.
Une fois que cette démarche sera valide pour le compte GSK,
en perspective elle sera adaptée aux autres comptes
gérés par la «BU
SOLUTION
DECISIONNELLE».
A long terme, il serait envisageable de préparer
l’organisation à mettre en place une démarche
d'amélioration basée sur le modèle CMMI
(Capability Maturity Model Integrated).
Le CMMI (Capability Maturity Model Integration) est l’outil d’une
démarche dynamique d’entreprise pour améliorer ses
processus. Ses bénéfices sont nombreux :
Amélioration de la satisfaction des clients, de la
qualité des produits, réduction des coûts, des
délais, des risques. [6]
Son référentiel a pour objet de mettre en place
l'amélioration continue au centre des activités d'une
entreprise ou d’un organisme afin que celle-ci puisse mûrir et se
développer dans un environnement international très
concurrentiel. L’amélioration porte principalement sur les
méthodes et pratiques métiers.
La mise en œuvre de ce modèle se traduit par :
• le
développement du professionnalisme et de la
compétitivité.
• la capitalisation.
• des gains en productivité.
• la réduction des coûts et des
risques
• la diminution des défauts. [6]
Mener une démarche qualité dans le secteur de
l’informatique décisionnelle n’est pas aussi courant que dans le
secteur de production ou encore la santé. La mise en place d’une
méthodologie de contrôle qualité au sein de NOVEDIA DECISION et
particulièrement dans la «BU
SOLUTION
DECISIONNELLE» n’a jamais été
pratiquée précédemment. Cela représentait
un enjeu très important pour une première
expérience professionnelle en management de la qualité.
Le fait d’avoir la responsabilité à mener cette
démarche, seule, était à la fois une source
motivation pour réussir ces tâches et une source
d’inquiétude sur l’incertitude des résultats que j’allais
obtenir et comment ils allaient être perçus par mes
collaborateurs.
Muni de ma mallette des connaissances qualité acquises en
master Management Qualité, j’ai pu descendre
l’échelle d abstractions progressivement en m’appliquant
sur cycle WV et 7 étapes de résolution de
problème.
En me basant sur les connaissances acquises, la
créativité, l’expérience de mes collaborateurs,
leur implication dans mon projet et l’application des solutions
proposées pour obtenir des résultats, j’ai pu
lancer la démarche de contrôle qualité du processus
de traitement des données du client externe, un des plus
important clients de la BU
SOLUTIONS DECISIONNELLES et en obtenir les premiers
résultats.
La durée, de 4 mois, du stage est malheureusement courte
pour pouvoir mettre en place toute les améliorations
prévues. C’est pour cette raison que seules les
problématiques identifiées comme étant
prioritaires qui ont été traitées et ont fait
l’objet d’améliorations.
Sur le plan personnel, NOVEDIA
DECISION a très bien organisé mon arrivée
et le déroulement de mon stage au sein de ses locaux. En effet,
mon intégration s’est aisément et rapidement
déroulée, grâce à la sociabilité de
mes collègues. Le fait d avoir travaillé avec plusieurs
personnes de différents statuts professionnels m’a permis de
développer mes relations en sachant mesurer mon comportement
avec chacun.
En plus, le fait de participer aux activités sportives de
l’entreprise a élargit le périmètre de mes
connaissances en rencontrant d’autres personnes qui travaillent dans
d’autres filiales de l’entreprise.
Ce stage fut une riche expérience, sur le plan personnel et
professionnel. Il m a permis de mettre en évidence toutes les
théories enseignées en master MQ. Par ailleurs, il m’a
confronté à des situations réelles et appris
telles que, l’indisponibilité des collaborateurs, la surcharge
de travail, etc.
Finalement, obtenir des résultats positifs de cette
première partie du travail réalisée fut la plus
belle récompense et une motivation pour continuer la suite du
projet.
V.Références
Bibliographiques |
[1] Groupement pour l’Elaboration et la Réalisation des
Statistiques, http://www.gie-gers.fr/,
rubrique
«
groupement
»
Consulté
le
13/05/2010
[2] Laboratoire pharmaceutique Glaxo Smith Klin,
http://www.gsk.fr/gsk/gsk_monde/monde.html
Consulté
le
13/05/2110
[3] Novédia décision – Services,
http://www.i-d6.com/, rubrique
« services/accompagnement »
Consulté le 13/05/2110
[4]CREAPHARMA- Définition des termes du domaine pharmaceutique,
http://www.creapharma.ch/generiqueN.htm#expli
Consulté le
13/05/2110
[5] Répertoire des medicaments génériques, http://www.afssaps.fr/Afssaps-media/Publications/Repertoire-des-medicaments-generiques
Consulté
le 13/05/2110
[6] Le CMMI (Capability Maturity Model Integration)
http://www.afnor.org/certification/inf003#p17193
Consulté le
20/05/2110
[7] Fondements méthodologique de l’amélioration
continue et de la résolution de problèmes,
Gilbert.FARGES, MASTER Management de la Qualité (MQ), UTC,
2009-2010 https://www.utc.fr/master-qualite/,
rubrique
«
QP01
:
Pilotage
du
progrès
et
de
la
performance »
référence du cours : «
02a_MQ_M2_QP01_2009_GF_rpb.pdf »
[8] Intégration d’une
démarche qualité dans le processus de traitement des
données, Sana HANDOUF,
MASTER Management de la
Qualité (MQ-M2), UTC, 2009-2010, https://www.utc.fr/master-qualite
, rubrique «
Travaux»,
référence n°147
ANNEXE
1 : Rapport résultant du programme [8]
ANNEXE
2 : Procédure de mise en place du contrôle [8]
ANNEXE
3 : Planning client externe – consultant interne : Légende
[3]
ANNEXE
4 : Planning client externe – consultant interne : Suivi [3]