La Gestion des Applications To-Be, mise en œuvre

La Gestion des Applications To-Be, mise en œuvre

Mise en œuvre de la Gestion des Applications : To-Be

1. Principes de conception

Dans les précédents chapitres, nous avons vu ce que préconisent les experts en terme de Knowledge Management, et l’intérêt de l’introduction du Knowledge Management dans le mode projet.

Dans la suite de cet écrit, nous n’allons pas essayer de coller les modèles de processus que l’on a présenté à la Gestion des Applications, mais plutôt de les adapter.

Le Knowledge Management est un projet qui ne peut pas se satisfaire d’une reproduction d’un modèle figé. Il faut l’ajuster en fonction du contexte particulier dans lequel évolue l’entreprise (métier, culture d’entreprise, processus, organisation…) et du niveau stratégique des connaissances dans cette entreprise.

La Gestion des Applications est une entité très jeune dans le groupe, elle est née en 2003. Les actions qu’elle doit mettre en œuvre sont souvent de l’ordre innovateur et de là découlent de nombreuses réactions réfractaires aux changements.

Parti de rien, il est donc nécessaire de mettre en place une stratégie permettant d’intégrer la GdA afin de répondre aux enjeux du Knowledge Management adaptés aux spécificités du groupe. Un plan d’action a été défini (Cf. figure 22), nous l’avons regroupé en 4 phases (afin d’apporter une vision plus générale).

Mettre en place une solution de Knowledge Management n’est pas qu’une question d’outils technologiques, mais cela touche plus particulièrement l’organisation de l’entreprise. Nous avons dû passer par une phase d’analyse du savoir et du savoir-faire de l’entreprise pour aboutir à des méthodes et des procédures.

Synthèse du plan d’action suivi par la GdA

Figure 25 : Synthèse du plan d’action suivi par la GdA

Dans la suite de ce chapitre, nous allons détailler les actions menées par la GdA en apportant des éventuels critiques. Ce modèle présente les stratégies menées par la GdA pour atteindre les buts qu’elle s’est fixée.

Map du To-be

Map du To-be

2. Création d’une cartographie

2.1 Les apports d’une cartographie

Cette architecture apporte des solutions claires à un nombre de problèmes courants d’aujourd’hui :

  • Communiquer clairement et réduire les ambiguïtés entre la maîtrise d’ouvrage et la maîtrise d’œuvre
  • Concevoir une architecture fonctionnelle et montrer clairement comment les fonctions sont attribuées aux systèmes.
  • Création et gestion d’un référentiel des systèmes de l’entreprise.
  • Délimiter nettement le périmètre du domaine étudié
  • Maîtriser et clarifier les conséquences de l’introduction d’un nouveau système de gestion, à éliminer la confusion entre le service et le processus
  • Comprendre et exprimer clairement les services attendus d’un système
  • Organiser les systèmes d’information afin de préserver le savoir-faire métier de l’entreprise et assurer sa continuité sur différentes technologies
  • Disposer de la vision globale d’un système, avec possibilité de focaliser sur les éléments composants sans être perturbé par les détails

2.2 Limites d’une cartographie

Nous pensons que les cartes actuelles offrent une certaine image des systèmes d’informations. Une carte est plus proche d’une photographie à l’instant donné T que la réalité du système information de l’entreprise comme organisme vivant.

C’est pourquoi le modèle n’est pas le modelé (la carte n’est pas le territoire…). En changeant d’angle de vision, on obtient des cartes différentes.

Ces représentations sont une des visions que l’on peut avoir si l’on met un poids plus fort par exemple sur la variable « flux des données », puis que l’on regarde ensuite la cartographie en prenant comme variable principale « nombre de processus interconnectées »etc…

Mais ces cartes, même si elles ne sont que des représentations limitées de l’entreprise permettent une meilleure maîtrise du S.I global.

Associées à des investigations internes puis à des systèmes experts, elles permettent de montrer l’inutilité de certaines applications, ou la redondance de traitement des données etc… En cela elles aident à optimiser et à rationaliser les systèmes d’informations.

2.3 Cartographie du Système d’Information des Collectives

2.3.1 États des lieux

Aucun rafraîchissement n’a été fait avant l’arrivée de la structure Gestion des Applications, c’est à dire depuis 1996, étant donné que la mise à jour de la cartographie n’a pas été prévue dans le périmètre des projets.

2.3.2 Périmètre couvert

La cartographie réalise une analyse fonctionnelle du domaine des collectives Gan, et à terme Groupama. Elle présente les fonctions du domaine d’activité du métier d’assurance et les informations échangées.

Actuellement, la cartographie des collectives couvre tous les systèmes d’information du domaine.

2.3.3 Source d’alimentation

Les sources d’alimentation disponible pour la mise à jour de la cartographie sont :

  • Base de cartographie des référentiels applicatifs (systèmes applicatifs)
  • Endevor (sources programmes, clauses-copies, écrans, paramètres)
  • OPC (arborescence des chaînes, jobs, steps)
  • E-GEN (jcl’s utilisés en Production)
  • Catalogue DB2 (bases, tables, vues, programmes)
  • Déclarations IMS (transactions, programmes, DBD’s, PSB’s)
  • Déclarations CICS (transactions, programmes, fichiers)
  • Neumics (statistiques sur les transactions, chaînes, fichiers utilisés en Production)
  • Dossier de mise en production

La fréquence de rafraîchissement de la cartographie doit être en phase avec chaque mise en production des projets, afin de pouvoir répercuter les transformations qui ont été fait par les projets.

2.3.4 Une cartographie à jour

La cartographie existante était en partie obsolète, il a donc nécessité soixante deux jours/homme de travail effectif pour obtenir une cartographie à l’image du système d’information du domaine des collectives. Chaque sous-système d’information a soulevé des problématiques différentes.

Par exemple, les sources d’alimentation sont différentes selon les SI, dans un cas on a un modèle conceptuel de données, dans un autre un enchaînement de chaîne batch applicatif etc…

Après avoir construit la cartographie, la GdA a fait appel à la maîtrise d’ouvrage pour valider la cartographie.

Le schéma ci-dessous illustre une partie de la cartographie qui couvre un sous ensemble du sous- système d’information des collectives. Chaque chaîne batch (rectangle) est reliée par un flux entrant et un flux sortant, et elles sont regroupées par sous-système d’information (schématisé par des ellipses).

Une partie du système d’information des Collectives

Figure 27 : Une partie du système d’information des Collectives

2.4 Fiche de recette

La fiche de recette est un élément essentiel de la constitution de référentiel de test qui doit permettre rapidement à un « opérationnel » d’appréhender-le quoi et le comment d’une recette.

On a une fiche de recette par sous-système d’information, ou par chaîne batch. Dans le cas où la fiche de recette couvrirait seulement une chaîne batch cela implique que la modification de cette chaîne n’a pas généralement d’impact sur les autres chaînes.

La description faite par cette fiche consiste à présenter :

  • les chaînes à recetter à minima et en optionnel,
  • la liste des chaînes en amonts et en avales,
  • les éléments nécessaires pour « recetter » la chaîne ou le sous-système d’information ( variables, fichier en entrée, etc…),
  • les livrables (états imprimés, fichiers en sorties, etc..),
  • les particularités du sous-système d’information ou de la chaîne batch,
  • et toutes la documentation relatif au sous-système d’information ( ou chaîne batch) accessible via des liens hypertexte.

3. Retro documentation

Au sein des collectives, il y a deux types de documentation existante, la documentation des anciens projets qui se trouvent sur le disque de travail, et la documentation papier. La documentation d’un projet devra suivre un processus d’archivage que la GdA a mis en place.

Par contre le format papier doit être remplacé par la version électronique, qui elle aussi sera archivée dans un premier temps sous l’arborescence cible, et dans second temps sous une Base Lotus Notes.

La transition d’une version papier à une version électronique ne se fera pas toujours par une numérisation. En effet, le test de numérisation a mis en évidence que le résultat n’est pas toujours positif, prenons l’exemple des :

  • documents écries manuellement et souvent au crayon, ils ont donc des formes diffuses difficilement reconnaissables par les logiciels.
  • organigrammes des chaînes batch au format A3 doivent être scannés en deux temps, car le support du scanner est de format A4.
  • le fond des organigrammes papiers (pré-dessin de l’emplacement des éléments) est numérisé.

C’est pourquoi, la Gestion des Applications a décidé que les dossiers de mise en production et les organigrammes de chaînes batch seront ressaisis sous word, et sous Flow Charter (logiciel graphique). La réécriture des dossiers sera fait par des stagiaires d’été, et cette réécriture permettra d’obtenir une bonne documentation, en terme de :

  • stockage sur support magnétique
  • mise en conformité des dossiers par rapport à la dernière version des dossiers d’exploitation
  • document évolutif
  • document disponible pour toutes les personnes qui œuvrent sur ces projets aussi bien aux études qu’en exploitation.

Pour les Spécifications Fonctionnelles, on passera par une étape de « scanérisation ». La reconnaissance de caractères ne se fait pas de manière évidente, certains caractères sont remplacés par d’autres. Dès lors le résultat de la numérisation va être conditionné par l’état du document initial.

Dans un cas, il sera possible d’obtenir un document word, et dans un autre sous un format d’Acrobate (image seulement du document). Le logiciel Word offre une possibilité d’enrichissement, et de suppression de certaines informations obsolètes, alors qu’Acrobate limite la manipulation du dossier en lecture simple.

Tous ces travaux requièrent l’acquisition d’un scanner, et cela a soulevé des problèmes techniques. Une amélioration du poste de travail sur lequel sera branché le scanneur a été nécessaire. En effet, la numérisation nécessite l’utilisation simultanée de plusieurs logiciels

« Epson smart pannel » pour les images, Omnipage pro pour l’OCR et Word, Powerpoint ou Excel pour le stockage des dossiers. Par exemple, l’absence de mémoire entraîne de fréquentes interruptions plantages (écran bleu) qui nécessite le redémarrage de l’ordinateur, donc une perte de temps conséquente.

Cette phase de retro documentation est très importante, la GdA capitalise sur la documentation existante, ce qui permet à terme de transférer au projet à venir. Ce capital immatériel inclut le savoir et savoir-faire, les expériences, la culture de l’entreprise.

4. Référentiel d’une documentation applicative

4.1 Référentiel des processus métier

4.1.1 Apport d’un référentiel des processus métier

La modélisation par processus clarifie le fonctionnement de l’entreprise. Ce nouveau type de cartographie (par processus) est un bon outil pour appréhender les situations complexes. En effet, on obtient un référentiel partagé, lisible, et cohérent par tous les acteurs du groupe.

Documenter les processus permet de capitaliser les connaissances et les savoir-faire métier afin de former les nouveaux arrivants, de guider les opérationnels, d’harmoniser les pratiques, et in fine de gagner en qualité et en productivité.

Il est également possible maintenant de porter un regard critique sur le modèle et mettre en évidence des points d’amélioration. Et nous pensons que cette cartographie par processus va faciliter notre dialogue avec la MOA et les utilisateurs de l’application.

4.1.2 Constitution d’un référentiel des processus métier

Faire remonter l’information de façon explicite est une tâche très difficile. L’inaptitude à écrire un document pour qu’un autre individu, qui ne fait pas partie du même environnement ou qui n’a pas la même connaissance du contexte est le plus gros frein auquel la GdA se confronte.

En effet, il est déjà difficile de garantir que l’ensemble des collaborateurs écrivent correctement, mais il est encore plus ardu de faire remonter de façon explicite ce qui est implicite.

Ce sont souvent sur des éléments qui apparaissent comme des évidences au rédacteur et qui n’ont pas été rapportés que s’arrêteront les personnes qui souhaiteront réutiliser les connaissances capitalisées, les rendant ainsi inexploitables.

C’est pourquoi, la GdA a préféré faire intervenir une personne de l’extérieur afin de formaliser à la fois les connaissances métier explicites et implicites.

4.2 Référentiel de test

4.2.1 États des lieux

Actuellement la couverture des cahiers de recette est souvent insuffisante par manque de ressource et de délais. La MOA manque de temps pour fabriquer les cahiers de recette et exécuter les tests.

4.2.2 Apport d’un référentiel de test

Un référentiel de test répond essentiellement à deux objectifs de haut niveau, qui sont :

  • Large disponibilité
  • Nomenclature ajustée

La notion de large disponibilité évoque un référentiel accessible et partageable entre les différents acteurs projets et un référentiel utilisable aussi bien par un expert métier que par un profil débutant.

La nomenclature offre un référentiel de test structuré, ce qui permet de sélectionner les scénariis de tests avec beaucoup plus d’aisance et de supporter l’évolution du référentiel.

4.2.3 Constitution d’un référentiel de test

La constitution d’un référentiel de test doit se faire en trois étapes. La première étape consiste à définir un découpage fonctionnel et une architecture technique. Le résultat de cette étape se matérialise par l’obtention – d’une définition du formalisme des fiches de test – création d’une nomenclature – choix d’architecture technique.

Durant la seconde, il est nécessaire de développer les outils permettant la valorisation des fiches de tests, sélection de jeux de tests, stockage et comparaison des résultats. Cette dernière phase n’a pas encore été réalisée.

4.2.4 Entretien d’un référentiel de test

Le plus simple n’est pas de constituer un référentiel de test, mais c’est de l’entretenir et de le revaloriser. Il a été donc décidé que suite aux mises en production cet enrichissement s’effectuera simultanément à :

  • l’enrichissement du référentiel de documentation (SFG/STG, SFD/STD, Dossiers de MEP, … )
  • la mise à jour des JCLs des bibliothèques de JCLs de développement
  • la mise à niveau des différents environnements (de développement, d’intégration, de recette, de pré-production, de formation, de réfection, … )

Cette revalorisation consiste donc à :

  • Ajouter des cas de tests relatifs aux nouvelles règles de gestion,
  • Mettre à jour des cas de tests relatifs aux règles de gestion modifiées,
  • Éliminer des cas de tests relatifs aux règles de gestion supprimées.

Pour citer ce mémoire (mémoire de master, thèse, PFE,...) :
📌 La première page du mémoire (avec le fichier pdf) - Thème 📜:
Choc démographique : Knowledge Management ou bug 2010 ?
Université 🏫: Université PARIS I – Panthéon Sorbonne – Institut d’Administration Des Entreprises
Auteur·trice·s 🎓:
Imène DALY

Imène DALY
Année de soutenance 📅: Mémoire de D.E.S.S. Systèmes d’Information Et De Connaissance En Apprentissage
Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top